PlanetCNC

7k course in 1h 25min. Searched for #4 first too much south, then too much north, 14 mins in total.

Dear fellow earthbound spacefarers,

tomorrow, Tuesday the 15th of May, Ella Saitta will give a talk elaborating on some of her investigations into the topic of fragile socioeconomic infrastructures - also known to the initiated as Collapsonomics.

The talk will start at 7pm at the Space Agency. It will last 45 minutes, and there will be time for discussion afterwards.

Talk outline:

The past century our infrastructure has seen both massive expansion and heavy centralization. When it fails, it fails big — this is the reality of our modern interconnectedness. We live in a world of crumbling bridges and bankrupt states, and our infrastructure will kill us. The people we're relying on to keep us safe are trying to accomplish long-term risk management with short-term thinking. So, what now? We can't opt out, but we can become more resilient, and we can start thinking about risk differently.

In this talk, we'll look at threat modeling in the real world, six ways to die, failing states, that big party in the desert, the failure of the humanitarian project, algae and the U.S. military, large-scale natural disasters, the power grid, and many other things. The problems we face are big in every sense of the word — they involve some of the biggest things we've ever built — but the solutions may not be. Can non-governmental networks step up when governments fail to provide basic services? Can we avoid a further expansion of neoliberalism in a post-infrastructural state? Are the power structures embedded in our infrastructure cultural destiny? What happens when maker culture grows up?

Interested? Come join us!

LG Optimus S (LG-LS670)

Her old phone was an LG Remarq (feature phone with slider keyboard), but the service on Sprint was costing her $82 a month, and she was starting to want smartphone features like decent access to Google calendars and her e-mail. Well, she can have it all, and for only about $30 a month on ting!

If this article helps you decide to switch to ting, please consider using my referral code to get $25 off your phone (and $25 off a monthy bill for me!)

Two mistakes, directly on #1 and then on #12. Ran past both of them and had to backtrack to find them..

Routegadget: http://rasti.kunnonelama.fi/gadget/cgi-bin/reitti.cgi?act=map&id=55&kieli=

3k sprint course. The sprint map is 1:5000 scale which caused some confusion directly at the start on #1. Then mostly OK until #14 which I searched for a bit. Total time 32 minutes so getting close to a reasonable pace of 10min/course-km.

101k in 5h 1min, avg 20.1km/h. Not exactly warm, around 9C with a cold wind.

Routegadget: http://www.rastihaukat.fi/cgi-bin/gadget/cgi-bin/reitti.cgi?act=map&id=42&kieli=

Spent an unbelievable 17 minutes looking for nr3... Should have gone directly east from nr2, but somehow drifted too much south, and then ran around in circles for a while, actually using nr7 to put myself back on the map.

Not sure I agree 100% with the placement of nr5 (and thus the squiggle in the gps-trace), I feel it was in reality placed slightly differently compared to how it was drawn on the map.

Otherwise mostly OK.

Routegadget: http://www.espoonakilles.fi/RouteGadget/cgi-bin/reitti.cgi?act=map&id=134&kieli=

SolarRoboFlower

Hackers are pretty much the mostly lovely people ever!

This is a gift to MakeHackVoid from Flo at Hackerspaceshop/Metalab. -- devdsp

[Reposted from alphabet]

96.3k in 4h 42min, avg. 20.5km/h. New Continental Gator Hardshell 700c 32mm tyres and Bontrager RXL shoes.

Routegadget link: http://www.rastihaukat.fi/cgi-bin/gadget/cgi-bin/reitti.cgi?act=map&id=41&kieli=

Playing around with the laser cutter at @metalabvienna (guess the game!) --@anlumo1

We use Norland Optical Adhesive (NOA-81) for gluing bits and pieces together in the lab. The glue cures in UV-light. So far we've used a fluorescent solarium lamp for this, but we broke one of the two remaining lamps and can't seem to source new ones.

So I decided to try an LED solution. These are LEDEngin LZ1-10U600 LEDs with a center wavelength of 365 nm, 28 euros each from Mouser. They are glued to an aluminium plate using a heat-conducting glue, Loctite Output 384:

For simplicity I used a LighTech 18 W 700 mA constant-current powersupply that runs directly off AC mains. The powersupply has a maximum output voltage of 24 V which is enough to drive the five UV-LEDs in series (the UV-LED has a voltage-drop of 4.1 V)

Here's how the lamp looks like:

Most of the blue in this picture is fluorescence from the white paper underneath the lamp. A quick test shows that the NOA-81 glue cures very quickly indeed (seconds) with this lamp. Much faster than with the old fluorescent lamp (minutes) anyway. This kind of lamp may be useful for PCB-making also? I didn't keep the lamp on for very long yet, so I don't know how adequate the alu-plate is as a heat-sink.

Warning: The UV-light from these LEDs may be more or less harmful for your eyes and/or skin. Don't try this at home unless you know what you are doing!

70.33 km in 3h 21min, avg. 21.0 km/h
#map_3 {clear: both; padding: 0px; margin: 0px; border: 0px; width: 100%; height: 100%; margin-top:0px; margin-right:0px;margin-left:0px; margin-bottom:0px; left: 0px;}#map_3 img{clear: both; padding: 0px; margin: 0px; border: 0px; width: 100%; height: 100%; position: absolute; margin-top:0px; margin-right:0px;margin-left:0px; margin-bottom:0px;}

Over view of the electronics on the test Jig

Side View of the test Jig
Showing 50V 500W PSU to drive the 4.2A Stepper motor

ie 2 Phases at 4.2A = 8.4A hence a 9.9A PSU at 50V

Close up of bodged together rev counter

7k course. A big mistake, due to not identifying the right road correctly, between 5 and 6, which took about 17 minutes. Otherwise mostly ok..

I put on new 32mm wide tires on the road-bike and took it out for a spin. Sunny but windy weather with what seemed to be a headwind in every direction...

59.2km in 3h 21min (avg 17.6km/h)
(You have to zoom in or out to see the GPX-track. I'm not sure why that is happening)
#map_2 {clear: both; padding: 0px; margin: 0px; border: 0px; width: 100%; height: 100%; margin-top:0px; margin-right:0px;margin-left:0px; margin-bottom:0px; left: 0px;}#map_2 img{clear: both; padding: 0px; margin: 0px; border: 0px; width: 100%; height: 100%; position: absolute; margin-top:0px; margin-right:0px;margin-left:0px; margin-bottom:0px;}

First orienteering event of the year. 5 km course.

Hey I'm trying the OpenStreetMap plugin for wordpress. It should allow showing maps, places, and GPX-tracks in the blog.

They did have a critical bikeride in March already this year, but it was quite snowy and rainy so I didn't participate.

Today there were 130-140 participants.

A quick set of  random-ish pictures of various stages of development of bits and bobs.

Here is a quick over view of some of the other projects:-

Top Side

Bottom side

60 BIQ opto end-stops made - only enough end-stops for 20 Huxley Seeding Kits

Pictorial guide on making leads for the BIQ opto end-stops.

Click a picture to enlarge

Colin was very shy to begin with .... 

 

Here's some benchmark data for constructing the Voronoi diagram (or its dual, the Delaunay triangulation) for random point sites. Code for this benchmark is over here: https://github.com/aewallin/voronoi-benchmark

OpenVoronoi is my own effort using the incremental topology-oriented algorithm of Sugihara&Iri and Held. Floating-point coordinates with all sites falling within the unit-circle are used. Fast double-precision arithmetic is used for geometric predicates (e.g. "in-circle") during the incremental construction of the diagram, since the topology-oriented approach ensures that the algorithm finishes and produces an output graph regardless of errors in the geometric predicates. Quad-precision arithmetic is used for positioning vd-vertices. This benchmark runs in ca 7us*N*log2(N) time.

Boost.Polygon uses Fortune's sweepline algorithm. Only integer input coordinates are allowed, which ensures that geometric predicates can be computed exactly. Lazy arithmetic, where a high-precision slower number-type is used only when required, is used. This benchmark runs in ca 0.2us*N*log2(N) time.

CGAL uses exact geometric computation, which is slow but supposedly robust. The run-time gets worse with increasing problem-size and doesn't seem to fall on an O(N*log(N)) line.

Some thoughts:

• OpenVoronoi is obviously too slow! Lazy arithmetic or other methods are required so that most vd-vertices can be positioned with fast double-precision code, and the quad-precision methods need to be called only rarely. OpenVoronoi uses a BGL adjacency_list to store the graph - this may also be too slow compared to a C-style "raw" data structure.
• Other libraries which might be added to the benchmark: Triangle and QHull.
• Held has, IIRC, reported around 0.5us*N*log2(N) for his closed-source VRONI algorithm. From the interwebs we also find this quote: "If your use is commercial, VRONI's license is a few thousand dollars."
• It's easy to measure run-time, but how do we measure the correctness of the output that these algorithms produce? A first simple approach is write the output to a PNG or SVG file and visually inspect it, but something more precise and automated would be nice.
• Neither Boost.Polygon nor OpenVoronoi support circular arc sites yet. Both can in principle be extended to do so.
• Are we comparing apples to oranges? Is the output of these algorithms the same? OpenVoronoi produces a half-edge data structure of the diagram with edge-parametrizations (lines, parabolas) that allow computing a point on an edge at a given offset-distance from an adjacent site. The data structure allows for iterating through the edges, vertices, and faces of the graph.

Low Current Microstepping. Intended for applications where the minimum on-time prevents the output current from regulating to the programmed current level at low current steps. To prevent this, the device can be set to operate in Mixed decay mode on both rising and falling portions of the current waveform. This feature is implemented by shorting the ROSC pin to ground. In this state, the off-time is internally set to 30 μs. 

I started working on arc-sites for OpenVoronoi. The first things required are an in_region(p) predicate and an apex_point(p) function. It is best to rapidly try out and visualize things in python/VTK first, before committing to slower coding and design in c++.

in_region(p) returns true if point p is inside the cone-of-influence of the arc site. Here the arc is defined by its start-point p1, end-point p2, center c, and a direction flag cw for indicating cw or ccw direction. This code will only work for arcs smaller than 180 degrees.

def arc_in_region(p1,p2,c,cw,p):
    if cw:
        return p.is_right(c,p1) and (not p.is_right(c,p2))
    else:
        return (not p.is_right(c,p1)) and p.is_right(c,p2)

Here randomly chosen points are shown green if they are in-region and pink if they are not.

apex_point(p) returns the closest point to p on the arc. When p is not in the cone-of-influence either the start- or end-point of the arc is returned. This is useful in OpenVoronoi for calculating the minimum distance from p to any point on the arc-site, since this is given by (p-apex_point(p)).norm().

def closer_endpoint(p1,p2,p):
    if (p1-p).norm() < (p2-p).norm():
        return p1
    else:
        return p2
 
def projection_point(p1,p2,c1,cw,p):
    if p==c1:
        return p1
    else:
        n = (p-c1)
        n.normalize()
        return c1 + (p1-c1).norm()*n
 
def apex_point(p1,p2,c1,cw,p):
    if arc_in_region(p1,p2,c1,cw,p):
        return projection_point(p1,p2,c1,cw,p)
    else:
        return closer_endpoint(p1,p2,p)

Here a line from a randomly chosen point p to its apex_point(p) has been drawn. Either the start- or end-point of the arc is the closest point to out-of-region points (pink), while a radially projected point on the arc-site is closest to in-region points (green).

The next thing required are working edge-parametrizations for the new type of voronoi-edges that will occur when we have arc-sites (arc/point, arc/line, and arc/arc).

dusub olddu newdu

Presently, dusub only knows how to deal with plain du, not 'du -h'.

Files currently attached to this page:

April marks the beginning of spring, with warm and dry weather. Witness my commuter-bike this morning:

“opening up spaces for arts & the public”

Ok, again, it has been a while but there has been a lot happening. The Thermal re-calibration worked and the filament no longer  burns which is much better. I have finally settled on a version of the Teacup Firmware that seems to be working very well and have got quite some way into the fine tweaking of Teacup's configurable bits. The net result being that I now have a machine that prints well enough for smaller components. Most of which at the moment have been parts contributed to the Sheffield RepRap group at the Gist Lab.

The configuration tweaking at the moment principally revolves around adjusting how much to retract/advance the filament for each stop/start of the extruder, whilst increasing the printing speed. My Bowden Tube is at the moment a little longer than I would like. The longer the Bowden Tube the greater is it's elastic length and the more I need to advance/retract the filament. These adjustments have a big impact on print quality and they seem to be interacting with the print speeds and influencing the quality adversely as the print speed increases. My parts are printing OK and I have little or no stringing but at the points in the printing where the head pauses there is a small amount of blobbing. I think this essentially means I need to retract more and quicker as the print head comes to a stop. Finalizing the extruder mounting and shortening the Bowden tube to the minimum practical length will reduce it's elastic length.

My Extruder is still not mounted on the Huxley itself but hangs from a hook on the shelf above. This is something of a chew when I take the machine to the RepRap groups build days, which we hold once a month on a Saturday, as I can never seem to find a way of standing it on something without the gears et al catching on something. AJ, a member of the group designed a mounting plate in Openscad but as I have no heated build plate the warping has proved too much to build it as yet. Making this plate then will be a manual hack and cut job, for another day.

I have also attempted to printout 4 Mendel frame vertices to make a filament spool roller, just like the one Nophead carries with him on visits. Again the warping proved too much. I may attempt them again, now I have persuaded the Huxley to print quicker and have found wide blue masking tape for the print bed that the ABS sticks to quite well. We had a brief experiment with a number of types of tape to see which would work best and found the wide blue decorators tape was it. I found it works better if it is applied and left for a day or two before usage. The glue on the tape seems to take a while to get a grip. The Blue narrow tape was feeble, principally because it seems to like to lift along the edges first and being narrow there were a lot of edges.

A colleague gave me an ASUS Eeepc that had a broken screen after he saw me scouring Ebay for them. I wanted something small, cheap and able to run Linux that could spend it's time dedicated to running the printer whilst I got on with other things. Having something that would also network connect for remote printing is great too. It was proving too easy to mangle print sessions part way through by doing other things on my laptop (updates etc) at the same time. A replacement screen came from ebay, and the RAM was upgraded,  finally adding in a larger SDHC card. The Eeepc was rebuilt with no swap and the SDHC card mounted on /home to expand the available SSD space (Only 4Gb). Configuring it without swap is intended to extend the life of what is now an old used SSD, and improve performance. Fortunately it would take enough RAM to let me do this. All in all it works extremely well although the screen is a little small. It is running Ubuntu 11.10, and has the Arduino build environment, Skeinforge and GtkTerm for firmware building, part slicing and printer driving.

Finally on to Heated Build Platforms. Yes I definitely need one of these, having experienced too much warping. It is preventing me progressing beyond small components. Increasing print speed helps reduce the warping but not enough really. Muhammad from the Sheffield RepRap group very kindly gave me a spare bed he had been experimenting with. The heating element measured out at 44Ohms so a little too high to get much wattage out of a 12V supply but probably do able if the voltage is increased. Attempts to make my own PCB heater plate are currently a little miserable as the size at 200mm by 200mm is just too big for my laser printers printable area (bits get chopped off, on printing). My Huxley is just too narrow to take one on of the usual heater plates that can be bought in. So still a work in progress. I did manage to find 4mm Mirror tiles at exactly 200mm by 200mm though to trial as the build surface. As well as self adhesive copper foil to act as a heat spreader and heatproof oven liner to stick the copper foil to and insulate it from the top track on a heater. When I get one made. So still much to be done.

Library video projector mounting overdone

I've built some fast pinewood derby cars in the past but this year was just about looking good.  I've always loved the way those lowriders bounce and thought it would be cool to make a derby car do that.  Here's my version.  A few more pictures and build details after the jump.

The body is a regular derby block with side panels added for the wheel wells.

I cut the side panels separately and then glued them on before sculpting the top.

The mechanism uses four tiny servo motors:

mounted in a 3d printed frame.

The servos are connected to the pinewood derby wheels and axles with a custom servo horn that I designed in FreeCAD.

The servos are driven with an Ardweeny

The ardweeny doesn't have any voltage control onboard so a friend showed me how to use an LM317 voltage regulator to step a 9V battery down to 5V.

The whole thing goes together like this.  It's a pretty tight fit and you can see some white areas that I had to trip with a utility knife because the wheels were still rubbing.

...läuft! Fast zeitgleich mit einem maintainance update beim gnuradio (3.5.2) ist der  FuncubeDongle-Treiber für gnuradio 3.5.x ( git) geupdatet worden. Er nutzt den FCD API code vom  Qthid Funcube Dongle Controller und stellt einen gnuradio-source-Block zur Verfügung:

If you'd like to look directly at the .xml file that specifies the search provider, it's google-literal-search.xml.

Rolling shutter image of propeller blades (from Wikipedia)

Take an ordinary CMOS digital camera sensor with a rolling shutter and since it only costs a few cents, add accelerometers and gyros.

Now, instead of merely capturing each row from the sensor into a finished image, record each row from the sensor separately, along with its location on the sensor and the time the capture started and ended; record this and the accelerometer and gyroscope data.

When you've got enough processing power available (in the camera if you have it, on a general-purpose computer if you don't), use [the integral of] the accelerometer and gyro data to estimate the orientation and position of each row within a larger image, refine it by using any overlap between rows to align them. Once all rows have an initial placement, refine the placements repeatedly until the best fit is achieved. Paint all the rows onto a larger canvas, trim the result down and interpolate at any spots you didn't cover. ALE and hugin have some excellent algorithms for these steps, though there are probably some additional tricks and wrinkles when all the input images are 1d.

You can even incorporate multiple complete scans of the sensor in this way, adding information without increasing smearing due to motion of the camera. This information can either be used to reduce sensor noise or increase output resolution using ALE algorithms.

You could also do your best without having accelerometers and gyros: use any simple motion estimate (such as zero between the first and second rows, and the previous alignment-based estimate from row N-1..N for row N..N+1) as input to the alignment step.

Finally, an altered CMOS sensor that reads out in an interlaced fashion (or other "non-linear" fashion) would be even better, because the first few rows read out would be spread over the sensor, "pinning down" rows that are read later. For instance, if the initial stride is 16 rows on a 1024-row sensor and the full exposure time is 1/8s then the basic geometry of the scene is captured in just 2ms (relatively little motion being possible in this time) and subsequent rows read will have the opportunity for overlap with both rows "above" and "below" during the initial alignment phase.

Lazzzorcut geneva drive at metalab --@wizard23

To that end, Chris gifted me with a compact B&W CRT from Goodwill, and I picked up a TellyMate, which can display 38x25 text on a TV.

Ignoring for the moment the difficulty of receiving the WWVB signal when all the interference from a CRT TV is right nearby, I've created a mock-up of what the display will look like (except that the font won't be nearly so good looking as this):

         0123456789
   0.. 9 M01100000M  Minute  = 30
  10..19 000000111M  Hour    = 07
  20..29 000000110M  YDay    = 66
  30..39 011000010M  DUT1    = +0.3
  40..49 001100000M  Year    = 2008
  50..59 100001000M_ nols LY nodst
   
  Local time:
  1:31:00.0 AM

  Thu Mar 6 2008
  UTC-0600 (CST)
   

At the top, the WWVB data is displayed, along with its interpretation. The previous minute and the current minute are mixed, with the cursor indicating the most recently read second of data. Whatever piece of data is currently being read or will next be read will be blanked out until all bits are received (for instance, during seconds 0..8, "minute" will be blank; from 9..18, "hour" will be blanked).

Most of the time the "_" shown after second 59 will be blank. During a leap minute it will be "_" and during the leap second it will read "M".

Below, in larger lettering, the local time will be displayed. I think I can achieve 10 updates per second, so I'll show tenths but not hundredths (or, say, thirtieths). The UTC offsets for standard and daylight saving time will be hardcoded (so if I move to Colorado to be closer to WWVB I'll have to fix my firmware).

The WWVB receiver and decoder is written and passes my tests. I have yet to write the display code (and optimize it--I can transmit fewer than 500 characters and control codes per 1/10 second to the tellymate), and I also have to work out how to get enough reception that having the WWVB display is not a big old waste of time. (or maybe I'll just display a simulated WWVB signal instead—with a disclaimer, of course. stop looking at me like that.)

$ time ssh olpc /home/olpc/bin/cmus-playpause
real  0m0.522s
$ time wget -O /dev/null http://olpc:8000/playpause
real  0m0.066s

It's nothing like the 384x speedup I got the last time I was complaining about the olpc's performance, but it's still nothing to sneeze at.

Dear carbon-based life forms,

the Space Agency would like to cordially invite you to the first installment of the monthly DIYBio Berlin meetup this Wednesday, March 7th, 19 o'yay local time.

As you may well know, DIYBio is a movement centered around getting biotech out into the open and into the hands of your average hacker, interested layperson, and passionate citizen scientist.

There has been a small biolab at the Space Agency for a while, but it's been a very lonely place for some time now, and it's time to get interested people together and talking to each other. For this purpose, there'll be a monthly meetup every first Wednesday of the month at the fabulous Space Agency.

Whether you're interested in actual bench work, bioinformatics, visualization porn, tinkering on electronics to make DIY lab equipment, or just conceptual work - it's all welcome.

A very rough agenda for this first meeting:

• Get to know each other
• Find out what each of us is interested in
• Take stock of what equipment is available
• Discuss project ideas
• Brainstorm on the possibility of starting a Berlin DIYBio lab where more than one person at a time can actually work
• Cake.

See you on Wednesday.

PS: Coordinates for the Space Agency: Gerichtstrasse 65, near S/U Wedding. Look for the big rocket sign and you'll find us.

Creeper made in Metalab.

I soldered a new capacitor to one of my stepper motor drivers. Just one question remains: What happened to the original capacitor? I could not find it anywhere ...

It does work, but I was stunned at how long it took to switch the outlet on or off: a couple of seconds! I should disclaim that it's running on a rather underpowered machine (the OLPC XO-1 with a Geode x86 CPU @ 430MHz), but this was way too long to be acceptable:

$ time py-usbpower query
Power: on

real    0m2.690s
user    0m1.484s
sys     0m0.096s

I set about to code this in C. For my reward, I got a very fast-executing program:

$ time c-usbpower status
ON

real    0m0.007s
user    0m0.000s
sys     0m0.000s

That's something like a 384x speedup. Lesson? ctypes has some very substantial startup costs for loading a library. It may be enough to make it unsuitable for a short-lived program.

In case it's useful to you, I enclose a copy of my usbpower program. It's under the terms of the GNU GPLv2.

Files currently attached to this page: