An Open Source licence for Hardware

I'm helping the OSE choose a license for the designs that we produce.

A couple of days ago, I blithely recommended that Marcin license the Liberator compressed earth brick press under the GPL.

Licensing is a largely solved problem in OSS, but on further reading, I found that open hardware licensing is a mess. I'm not a Lawyer (thank goodness :-), but here's by best attempt to understand the situation.

The crucial difference appears to be that physical items are not covered by copyright, which only concerns itself with informational goods.

It's easy enough to do public domain, MIT, or BSD style openness with hardware. These licenses are so permissive that they don't change their behaviour in the new context. They don't need to use copyright to make their provisions enforceable.

The problem comes with the GPL copyleft provisions: Without copyright, enforcing openness of derived works is hard, and I'm not satisfied that any existing license does it well, if at all.

The Open Hardware License (as used by TAPR) was written by a lawyer, but was criticised by Eric Raymond, and I have some misgivings about it too.

There are a substantial number of open hardware projects that are using the GPL as is, and it doesn't seem to be doing them any harm. These include Arduino and RepRap.

I like the obligation to open derived works included in the GPL. I feel that it is politically consistent with the OSE values, and it acts against commercially exploitative freeloading. If it were easy, I would like to enforce that same obligation on anyone selling modified Liberators. I now think that this enforcement may not be possible through copyright.

I also think that it doesn't actually matter very much. We'd like to get the benefit of all modifications to our open designs, but we don't need it. So long as good complete designs and cheap good quality implementations of open hardware are always available then we have succeeded.

So long as there is a community of people using and building our designs the designs will be available and constantly improving. If some people don't share the results of their efforts with us, then that's a shame, but we don't need them anyway. If they're that inclined to be selfish then their grudging cooperation probably wouldn't be that useful anyway.

I think we should go with the GPL for the moment. We can re-license later if we need to.

Tomorrow, I'll contact Eric Raymond, the OSI, and the FSF for advice.

How do you tell if an open source project is successful

After a bit of musing, I came up with the following metrics:

Good structures

version control system for code

bug tracking system

documentation for developers and users (might be in a Wiki or similar)

mailing lists or equivalent

discussion fora or equivalent

Active Developer Community

traffic on developer mailing list or forum or similar

high rate of code commits to VCS

low bug fix latency

high bug fix rate

high new feature rate

full release calendar (lots of releases are being made)

Active User Community

traffic in user fora/mailing lists

download rate of installers

output produced (type depends on project)

professional support services

job openings for skilled users

Can you think of any others?

Working on Open Source Ecology

I'm contributing to the OSE effort, where my fabrication efforts have a chance to deliver enormous social benefits. Finally, I've got a something concrete to do that can have a widespread beneficial effect. It's very exciting.

The best place to read about it is http://openfarmtech.org/weblog/.

I'll be continuing with posts about fabrication soon, but I'll also be posting about open source hardware, and other related subjects, as I'm stimulated to write by my interactions with the other OSE contributors.

Vacuum Degassing PU resin experiments 00-02

I have some Smooth On resins that are past their use by, including Task8 that's 15 months old and some other that are ~2 years old. They are supposed to be used within 12 months of manufacture, so they're a bit dodgy.

These resins are interesting materials with a lot of promise, so I did some experiments to get a feel for them.

I'm interesed in Reaction Injection Moulding (RIM), which can including injecting the resin under pressure into a mold under vacuum to reduce trapped air bubbles. This doesn't work with the resins I tried, because they seem to evolve a gas as they cure, after they gel, and vacuum causes them to foam hugely. This might be because my samples are old, but I suspect that it's a 'feature' of the material.

Experiment 00

Mixed ~180 ml
Put in in to degass after about 1:30 of mixing
degassing happened late in the cure
Result: cup full of hard cured coarse partly open foam


Experiment 01

Mixed ~240 ml
Put it in to degass after ~50s of mixing, in two cups:
~70ml on two layers of Biaxial glass fiber mat
~160ml on its own
Degass happened early in the cure, but post gel
Result:
Large cup overflowed.
Cured as solid, not foam, but surface of both very uneven. Partly clear amber which is interesting because this resin is supposed to cure opaque tan. Is the opacity a volatile reaction product that is causing foaming under vacuum?
Resin appears to wet out mat well.
Thin section was strong, but breakable by hand. Showed evidence of delamination, probably from part cured layers touching as the gelled foam colapsed.

Experiment 02

pre-degass 2 minute
mix 120ml
Vacuum half of it after 30s, keep under vaccum during cure
Result:
Vacuumed half overflowed cup and produced rubbery Clear amber mess with large bubbles in it
Unvacuumed half foamed very sightly and set to rubbery tan.


Experiment 03

same, but with 2 year old Smooth Cast 326
Result:
The half cured under vacuum had a totally clear and nearly colourless bottom part and a tall deck of hard coarse foam on top.

The half cured at room pressure had a bunch of pinhead bubbles.

I suspect that a little gas was evolved during cure.

Awesomely huge 3D printing in stone

Big. 3x3x3m is the small scale demo.

The final version will be 10m tall.

Sand or ground rock with "inorganic binder".

Pretty sweet.

http://www.dezeen.com/2009/06/22/radiolaria-pavilion-by-shiro-studio/#more-33059

Noisebridge

While I was in the San Francisco Bay Area (where I'd like to live eventually), I hung out with a wonderful buch of hackers at Noisbridge. Massively inspiring, and constantly bubbling over with creativity and skill.

Just for example, some are working on a McWire RepStrap, and another created this bit of kinky steampunkery.

If you get the chance, check it out.

Moving to Zurich

I'm in the process of Moving to Zurich in Switzerland. I've got a job with Google there.

Over the last couple of months I've packed up my house, shipped my stuff to a warehouse, been to California, and I'm now in temporary accomodation in Zurich while I wait for my appartment to become available.

I should be moved in within a fortnight.

Amazingly easy CNC touch off

Very often I need to measure the length of a tool in the spindle or the hight of a piece of stock. With a feeler gauge or similar this takes ages.

How can you do it quickly precisely and easily?

As far as I know this is the simplest thing that that works: an electronic touchplate. If the tool tip is at IO signal ground, it is easy to detect when it touches a conductive plate, but attaching a pull up resistor to the plate and detecting its logic level.

Many spindles have grounded collets anyway, most CNC controllers have signal ground and mains ground at the same voltage, and tungsten carbide is conductive, even if it is coated with TiAlN, so the first part is usually automatic. If your controller has a small signal ground (0V) that is isolated from mains ground, or your spindle electrically isolates its collet, YMMV.

My spindle is not grounded at all (single phase mains and neutral, double isolated, plastic case, no ground), but it does have a metal collar for clamping it to the Z table. This collar is electrically connected to the collet, so I added a connection between the ground for the Z servo encoder and the Z table.

Connecting the touchplate was pretty easy too. My controller is not electrically isolated: it uses direct connections from the PC parallel port. I connected a 10k pull up resistor between the 5V supply from the PC and pin 15. Then I soldered a long wire between pin 15 and a blank PCB, which is 1.58 +-0.02mm thick.

I used the EMC Halscope to observe parport.0.pin-15-in. This does indeed go false when I touch the reference panel to the tool, and is true otherwise.



I can now run this program to set the z=0 level to the surface that the touchplate (the blank PCB) is resting on:


(restore offsets)
G92.3
(make this Z=20)
G92 z20
(probe down for a maximum of 10mm or until contact is made, at 50mm/min)
F50
G38.2 z0
(assume that we made contact, and set z=0 to be the surface that the touch off contact was resting on)
G92 z1.58
(back off so that we can get the plate out)
G0 z10

(end, which clears all the offsets)
M2


Using Joystick buttons to run complex CNC commands

Earlier I described how to run a single line of G code with a single button press. The problem with this is that it is limited to a single line. :-)

Earlier I wrote a short multi-line program for setting tool length, and now I'd like to run it at the touch of a button.

There is already a method for doing this with some classic ladder HAL logic, but one look at classic ladder turned my stomach. Fair enough for people who already think that way and don't want to change, but as far as I can see, it's like running an emulation of an abacus on your PC so that you can use it do your accounts: a deliberate step back into a far more awkward past. So I went looking for an easier and more powerful way. :-)

One piece of the puzzle is a user-defined M-code. This allows us to run any executable with a single M1xx command. Unfortunately for these purposes, this is an executable program, not a G-code program.

The next piece of the puzzle is emcrsh. This allows fairly complete control over emc via telnet.

To glue them together I needed a program to connect an emcrsh session, run the touch off program, wait for completion, and close the session. I used this as an excuse to learn a bit more Python, but my unsuccessful efforts to get telnetlib to work took too much time from the main task, so I did something a bit kludgy instead: I piped the stuff I wanted to send into telnet and hoped for the best.


#!/bin/bash

telnet localhost 5007 < ~/emc2/nc_files/util/InvokeProbeAndSetToolLength.commands

Note that this file must be executable.

And here are the commands:


hello EMC client 1.0
set echo off
set verbose on
set enable EMCTOO
set task_plan_init
set mode auto
set echo off
set set_wait done
set open util/ProbeAndSetToolLength.ngc
set run
get mode
quit


Note that ProbeAndSetToolLength.ngc must be in ~/emc2/nc_files/util for this to work.

This works well enough. If the probing program does not complete for some reason, AXIS is left in auto mode as if it were still running a program. This locks out the manual controls. To get back to manual mode, I click on the MDI tab and back to manual.

Now I can set Z=0 to correspond to something useful at the touch of a button.

Tuning EMC2 and Gecko servo drives

Tuning a PID loop usually involves repeatedly perturbing the thing that the loop controls, observing how the error changes over time, and adjusting the error feedback to improve the response.

My CNC router uses Gecko servo drives : a G320 for the Z (up/down) axis and G340s for the X and Y.

These use trim pots for the gain and damping of the PID loop. There's a good set of tuning instructions in the gecko user manual, but I came across some niceties that may be useful to someone else, both in how to measure the error and what I found.

How I Measured

In order to tune the servo I needed to apply an impulse to it in a repeatable way. I wrote a short G-code loop for each axis, to repeatedly rapid move and then reverse rapid move the axis. Here's the one for the x axis:

(restore G92 offsets cleared by M2)
G92.3

G0 x0 y0 z0
(go this far before immediately reversing)
# = 10

# = 0
O100 while [# lt 1000]
G0 x#
G0 x0
(wait for 2 seconds)
G4 P2
# = [# + 1]
O100 endwhile

(end)
M2

Running this code repeatedly in EMC2 subjects the chosen axis to worst case demands: accelerating from full speed one way to full speed the other as quickly as possible. This is a realistic benchmark for the worst case error that I'll see while I'm using the router, and it allows me to concentrate on twiddling trim pots and pondering the measurements.

I soldered short wires to the error and ground testpoints on the drive boards so that I could tune the drives with their covers on.

In order to tune an gecko servo drive properly you need an oscilloscope. The drives have an analog error output and you need to know how that varies over time in order to tune the drive and measure the maximum error. Anyone with their servo PID loop exposed to the EMC HAL can use the pure software Halscope, but that's no good for external hardware. I've just bought an MSO-19, which is seems to be a pretty reasonable mixed signal 'scope for an amazingly small $250. It does have a couple of shortcomings that I've found so far, though.

Firstly, the maximum timebase is 10ms which is slightly shorter than I would have liked for this job. There were times when I couldn't see the whole of the direction changeover period, which was about 120ms long for the X axis. The best I could do to work 'round that was set the trigger to detect the start of the increased error at the beginning of the reverse, examine the first screen full and then set a trigger hold off of 80ms or so that I could check a screen full starting 80ms after the trigger. This was good enough.

Secondly, the maximum voltage offset that I've been able to apply is 2V. The error signal is about 4V for no error, and varies by 0.04v for each encoder count of error, negative for lag, positive for lead. This means that I want to measure small voltage changes, but have to set a large voltage scale to keep the signal on the screen at all. This gives me insufficient precision on either the readings or (especially) the trigger setting.

The solution to this problem consists of a 3300uF cap, a 10K resistor, and a couple of crocodile clips:

(The negative side of the cap is attached to the resistor).

I connect the red wire to the error signal, and the black to the servo drive signal ground. It takes about a minute to charge the cap up, and then it blocks the DC part of the error signal.

I connect the scope probe between the cap and the resistor, and the the scope ground to the signal ground.

The error averages 0 over a few seconds, so now the short bursts of error as the axis starts, reverses, and stops, are measured as small variations around 0V, which is ideal.

What I Found

The first thing to tune was the top speed of the axis. I had calculated this to be 116mm/s from the spec of the servo motor (2800 rpm), the 2:1 step down on the belt, and the 5mm/rev ball screws. In practice the absolute maximum is between 105 and 110mm/s. Beyond that the servo can't keep up with the commands from the computer and the drive faults out. No acceleration setting that I tried allowed the servo to work at a higher top speed.

Having got an attainable max speed, I tuned the servo gain and damping to the maximum gain and minimum damping that didn't produce any ringing (ie: where the error was brought smoothly back to near zero with no overshoot).

Then I tuned the max speed and acceleration: For a chosen top speed I found the maximum acceleration that I could use while still seeing an acceptably small peak error.

When operating at 105mm/s I found that even with optimal drive tuning and a modest 300mm/s/s acceleration the error was unacceptably large: ~2.4V measured error signal maps to ~0.15mm following error. This is about 6 times the specified backlash on the ballscrews.

Reducing the top speed to 95mm/s gave a max error of only 0.05mm with an acceleration of 800mm/s/s. This improvement surprised me. Decreasing the top speed further doesn't seem to lead to any additional improvement. I couldn't see one at 85mm/s/s, anyway. Servo torque is supposed to be approximately constant with RPM, but this clearly isn't the case here. I have to guess that the max torque of my servo motors drops off quickly near their specified max RPM.

I tuned Y and Z by the same method, and found that they could support higher max accelerations for the same peak error (900 and 1350mm/s/s, respectively). This is to be expected since they are driving less inertia with the same torque.

CyberAngel: v0.5 in the works

The full project as I outlined in my earlier post is massive. Even more massive that I had thought. Since I last posted I've been mostly working on the electronics, and I have pretty much finished the schematics, but it's clear that what with one thing and another I won't be done in time for this year's Burning Man festeval.

I've decided to postpone the LEDs and accelerometers version and do a half way version with EL wire and an off the shelf controller. I've ordered the Super CAT-09 10 channel sequencer and 300m of EL wire from the lovely people at Funhouse Productions, and these should arrive on Monday.

This means that I can put the accelerometers, the garage SMD soldering, the PCB layout, the PCB contract manufacture, the PCB isolation routing, the LED heatsinks, the 3000+ wires to solder by hand and the FPGA programming on ice until the autumn.

I just need to design and make a mold for the costume, and for the battery pack, encapsulate the battery cells, put the components into the molds, and injection mold elastomer over them. Before the 5th of April. While learning to drive and preparing to move from the UK to Switzerland. That's all. At least I'm between jobs at the moment. :-)

CyberAngel: a wearable light sculpture

Picture a suit cast in one piece from translucent silicone rubber. It covers the outsides of the arms and legs, the hips, spine, shoulders, upper chest, and hoods the head, with just enough strapping over the rest of the body to keep it on. It is covered with feather light guides made of the same rubber, with a cluster of RGB LEDs at the base of each feather, and a network of fine black wires runs through it between the LEDs. The light from the LEDs fills the feathers.

The LEDs can display all possible colours at all intensities up to a very high brightness, and each changes individually. Rippling, shifting and writhing patterns of light and colour run over the surface of the suit in response to the wearer's movement.

This is what I'm working on at the moment. I'll post more about progress and the technical details as the project progresses.