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.

Making joystick buttons run simple CNC commands

It's pretty easy to get a button to do something simple (run any one line of G-code).

Create a new HALUI MDI command with one line in your .ini file:


[HALUI]
MDI_COMMAND = G92 X0 Y0


This causes a new HAL pin to be created, called halui.mdi-command-00. Then wire that pin up to the joystick button that you want to cause that command to be run, with an line in your .hal:


net setXYOrigin input.0.btn-thumb2 => halui.mdi-command-00


Now pressing that button (in this case, the thumb 2 button) runs G92 X0 Y0, just as if I'd typed it in the MDI box. This setup allows me to use the joystick to jog to the place that I want my origin to be, and then set that to be my XY origin by pressing the button.

You can have any number of MDI_COMMAND .ini lines, and they each make make their own mdi-command-xx pin, ordered in the order they appear in the file.

Each one can run any one liner. In the next post I'll talk about running more than one line from a single button.

The Joy(stick) of Machining

I control my router with EMC2, which rocks, BTW. It's extremely versatile and extensible, while being easy to use, and has a vibrant community of contributors. I thoroughly recommend it.

The most accurate way that I have of measuring the offset between the tool and some fixed point (for example, in order to set the tool length offset) is to move the tool to that point, and see the offset in machine coordinates. At the moment I do that through the jog GUI in AXIS, which is slow and awkward, so task number one is to improve that.

I've got a USB joystick, and I'm following these instructions on the EMC Wiki. The rest of this post assumes that you have read them.

If you don't understand EMC and the HAL the instructions and the logic behind them won't make much sense, in which case I recommend reading an introduction to EMC2.

The joystick setup process is simpler than it looks: download joypad_v3.hal, tweak it, put a reference to it in your .ini file, and install joyhandle. The two snags that I hit were with getting the hal_input module to see my joystick and getting joyhandle helper module to work.

I had trouble with the hal_input for two reasons: I hadn't followed the "setting the permissions for input devices using udev" instruction closely enough, and had to mess around with the name pattern for the joystick to get one that hal_input would accept.

joyhandle is a HAL module designed to set a deadband around the center of a joystick axis, and provide power law and linear scaling for the value of that axis. There is a precompiled version on the EMC2 Wiki, but it's for a rather old RT kernel, so it doesn't work. Luckily, there's also a .comp (source) file. I installed the emc2-dev package to get comp (the HAL module compiler). After that, building and installing the module was as simple as:

$ sudo comp --install joyhandle.comp

And the man page:

$ sudo mv joyhandle.9.gz /usr/share/man/man9

Then it just worked. :-)

By itself, the addition of the joystick has made my old method of measuring tool offset or stock position quicker and easier, but the full benefits will come when I combine it with automatic offset recording for X and Y, and automatic probing to detect the tool length.

The many steps to 4 axis machining

I'd like to run some "all round" machining jobs on my router. To do that, I need a rotary axis. I intend to convert a rotary milling table into a CNC rotary axis by fitting it with a servo (more on that later).

To do that, I need to do some 3 axis machining, but there are a few obstacles that I'd like to get out of the way first.

At the moment it takes me annoyingly long to set up my CNC router after I change the stock or tool, and even then the results are often compromised by poor calibration of tool length and stock position. The next few posts will explore faster and more accurate ways to do this calibration. At some point I'll have to find out how the pros do fixturing, too.

The old way (if you care)

To measure tool length I fit the tool, and then jog it down close to some datum (such as the router bed or the top surface of a flat piece of stock). Then I use a feeler gauge to measure the offset and setting that to be Z=n with:

G92 Zm

with m=n + measured offset, in the MDI window of AXIS (the tab that's in the background in http://www.linuxcnc.org/docview/html//gui_axis.html#cap:AXIS-Window).

I'm using oversize stock, positioning it by eye, fixing it down, and then jogging the router until the spindle is in approximately the right place above the stock and setting that to be X0 Y0 with:

G92 X0 Y0

in the MDI window of AXIS.

Time for a novel approach to CAM?

I'm now pretty familiar with SolidCAM (a SolidWorks CAM plug in), and I've had a look at the screen shots and sales blurb for a bunch of others. I am not impressed.

The state of the art CAM seems to be stuck on an unnecessary plateau: Slick but dumb. The user is presented with a fixed toolbox of slightly adaptive machining strategies and expected to choose an appropriate sequence of them to apply to various parts of the stock in order to produce an acceptable result. The process is both slow and demanding of human skill and attention, and the results are far short of optimal.

The better tools do have some optimisations that help a bit: Adaptive step over when milling with a ball nose, to limit the scallop to some maximum height; Feed rate adaption to varying cutting load; Solid modelling so that later machining steps only cut the material left by previous steps; etc.

However, this falls far short of what is possible: fully automatic generation of a far more optimal set of machining instructions. It seems to me that the local definitions of a good cut are fairly simple. A cut that is within the capabilities of the machine, at optimal feed rate and chip load, leaving only an acceptable scallop, and not gouging the part, is a good start, and would be better than the current approach can uniformly produce.

Ratings for all of these cut properties can be calculated, and a single merit function could be a weighted product of those ratings. This allows us to use any local search strategy to generate a complete tool path, by creating a sequence of locally (near) optimal cuts.

Global merit would include completing the task in minimum time, with minimum machine and cutting tool wear, with maximum quality. A simple hill climb optimisation would produce an improved but still substantially sub-optimal path. Simulated annealing, a genetic algorithm, or similar, would further improve the result.

In future posts I'll propose an algorithm in detail and get in to the implementation details, with the intention of cutting alpha release code in python and starting an open source project to get this in practical use.

In praise of a good workshop

Having a good space to work in makes it massively easier to do good work.

At first my workshop was the spare bedroom: a tiny child's room. Then I got my CNC router, took over the dining room too. This meant that most of my tools and materials were stored in one place, and I was working in another, which resulted in a huge waste of time and a perpetual battle against clutter. It was also impossible to keep the metal swarf out of the rest of the house.

Now I've moved, and I have a single garage as a workshop. It's still a bit cramped, but it's a massive improvement.

Here are some of the highlights of what I've set up.

CNC router enclosure with high static pressure extractor. The fan can easily be fitted with a flexible duct that I can put out of the door when I'm cutting anything noxious of especially dusty. The box keeps the extreme mess that routing makes off the rest of the workshop, and should contain the splashes from the flood coolant (more on that in a later post). The box walls are 4mm double wall polycarbonate intended for low cost greenhouses, on an Al angle frame.





CNC router. K2 KG-2539, which seems to offer pretty good performance for an excellent ~$7500 including the trimmings. I paid $5000 for a machine without a tabletop, cables, cable chains, or servo drive electronics, and built them myself. It wasn't a smart way to earn $2500 less the cost of the parts, since that didn't leave much actual saving and took a great deal of time that would have been better spent on other things.






Kress spindle, which has a surprising amount of torque and an very low run out. It was able to cut a big chunk off the top of a cast iron G cramp when I accidentally crashed the bit into it at 3600mm/min.

Around the spindle you can see the flood coolant delivery to the four orange nozzles, and the compressed air with optional mist to the grey locline with the red tip. I'll post later on building and using the coolant systems.

Between the flood nozzles is a ring brush that surrounds the bit. The open middle of the ring goes to a shop vacuum cleaner via the the big black hose.





Industrial shelves. Practically impossible to overload.



















Really Useful Boxes (TM). From Staples, quite cheap yet sturdy, and it's possible to see what's in them through the walls. They're Euro standard sizes and shapes, too.

















Home made work bench, from timber from a builders merchant.















Frankenstein's work bench, supporting the CNC router, (re)built from bench and desk parts salvaged from a skip. It's not really stiff enough: it wobbles at least 1cm when the router X axis starts or stops. I may stiffen it with X braces, or replace it, if I can see some evidence that the flex is actually a problem.









CNC controls. Joystick to control jogging. I haven't set up the HAL (hardware abstraction layer) to make it work yet, but that shouldn't be hard. I'll post about it when it's done.

Is this thing on?

Hello.

This is a blog about making things.

I find the transformation of idea into object uniquely satisfying, and oven the coming months I'll be sharing my projects with you as they bubble up in my fevered brain as ill-formed ideas, struggle and compete for the sunlight of my attention, and flower or wither by turns as may may be.

I expect to write about CAD (especially SolidWorks), CAM, CNC (especially Linux and EMC2), milling and machining, casting, composites, resins, elastomers, programming and electronics. It's my intention to share useful insights, techniques, and lessons in these areas as I learn them, and my hope to receive similar in return.

Some projects will be entirely for my personal amusement, while others may result in commercially exploitable products. I may be a little cagey about some of the latter.

I'm currently working on, amongst other things, a light weight high performance geodesic dome made from advanced fibre composites and metalised polymer film, a totally silent high performance PC, and a costume for next years Burning Man that includes a 3000 channel 1kHz LED PWM dimmer and 1000 lightguides cast in clear elastomer in the shape of feathers.

I hope that you get some part of the joy from reading about my projects that I get from working on them.