Tommelise 2.0

In which your narrator suspects that we are using the wrong model of evolution...

Darwin has been a roaring success by virtually any measure you'd care to name. In April of 2008 we had exactly five reprap and repstrap printers more or less operating. Last month, Dr. Bowyer estimated that several thousand were either operating or under construction. That's not exponential growth. It's hyperbolic. I, personally, have no doubt that in 5-10 years Dr. Bowyer is going to find himself on the Queen's annual Honor's List. Mind, in my opinion he richly deserves it. That said, I wanted to share a few ponderings that I've been nursing on the nature of change in the reprap movement for the past few months.


Basically, Reprap has two models of evolution going on in parallel. In the core team, we see what I will call a punctuated animal model of evolution while the larger reprap community is a very vibrant bacterial model.


Back at the end of 2006 and the beginning of 2007, the Reprap Core Team had several prototypes for a first release Reprap machine; Da Witch in New Zealand,




A.R.N.I.E. at Bath






and Tommelise 1.0 in the US.





By March of 2007, Darwin, which was to become the first official release reprap machine had grown out of the A.R.N.I.E. prototype...

...and by the second quarter of 2008 Vik Olliver had managed to print a full parts set for a Darwin with his Darwin machine.

Then a very curious and totally unexpected thing happened. Fully 6 months went by before a Darwin replicated again, this time in Canada.

By that time, however, by Dr. Bowyer's estimate the population of Darwins were in the low thousands. What had happened?

Basically, Darwin morphed into a fully industrial product. It began with the controller boards being outsourced for production by the Reprap foundation and has culminated with a shippable kit purchasable for US$1,100 {shipping not included} requiring little more than the sort of assembly you'd be expected to apply to something bought from Ikea. What is getting built out there in its thousands, to use Dr. Bowyer's metaphor, is 100% vitamins - 0% replicated parts.

These aren't really Darwins, they're repstrap machines. You could use one to make a Darwin, but they aren't. Further, because they are repstraps, the machine you print with one isn't even the machine you're printing. The parts in it are laser cut, not printed. Now I suppose you could, if you wanted, print the laser cut parts. I haven't seen anybody attempt this, though.

A few tentative attempts have been made towards coming up with a second generation mainstream reprap machine. The most notable effort in this regard has been undertaken by eD at Bath university.

eD's new design promises to be considerably simpler to build and less materials-intensive than our current Darwin design.

We've found ourselves increasingly sliding towards designing with industrialisation in mind from the onset. Instead of designing simpler electronics that would be easy to cobble together, we have been designing boards with parts like surface-mount chips friendly to outsourcing and short production runs. Design, for absolutely the best of reasons, has been getting more and more centralised and unified.

I think that this has been happening in large measure because of the model of evolutionary development that the core Reprap team have been using. While we have been giving lip service to Darwin's original theory of natural selection, in practice we've been using Richard Goldschmidt's Saltation theory in which very large changes happen from one generation to the next.

I think, and this is my personal opinion, that we really haven't thought about the implications of what we are doing when we come up with a single specification for a particular generation of Reprap machines. Single specifications presume a particular environment of parts availability. As practice has shown us there ain't no such thing as a general availability of a particular set of parts for the Earth as a whole or even large parts of Earth.

If we look, however, at the larger Reprap community we see a very interesting thing happening. For example, lathes are relatively expensive and have a learning curve associated with them so in one place we see things like this



In another place nichrome wire and ceramic potting material is difficult to obtain so magical solutions like this occur...



While the Reprap Core Team is practicing Saltation, the larger Reprap community is practicing Horizontal Gene Transfer, a method of exchanging recipes that enhance adaptability and communal robustness that bacterial populations employ to manage extremely rapid evolutionary rates and exploit new environments.

If you look at Darwin, for example, you can subdivide it into a set of different parts or systems, depending on how you look at it.  A quick partial tree structure of Reprap Darwin looks a bit like this...

     3D modeling software
     Slice and Dice software
     PC-side control software
          communications
     Positioning system
          mechanics
          firmware
     Toolheads

There are, for example, at least half a dozen solutions in the community to controlling a Reprap machine.  Some depend on open source compilers, some don't.  Similarly, there are a variety of kinematic solutions to the question of positioning the toolhead.

As a practical matter this means that the Core Team needs to climb down from more than a few articles of faith that it holds about what belongs in a Reprap machine and concentrate more on the much more difficult task of managing and interfacing the rich diversity of parts and pieces that have been developed by specific community members trying to solve specific problems in particular environments.

Recently, I'd bought some spring clamps and my son, this morning, was noting how much force it took to force the jaws apart. As he was working with one of the larger plastic ones I had, it occurred to me that it could clamp the Dremel toolhead as well easily as it could clamp two pieces of poplar together while I drilled a common hole through them.

The width was right and with a length of 36 inches, half of it was just what I needed for my z-axis table. The biggest plus was that the whole thing weighed four ounces where HDPE or poplar would have weighed 24.

Retaining rails were made with extruded aluminum L-profiles; one with the L-profile up to give lateral and normal guidance and the other with the L-profile down to provide normal guidance only.

Standard M8 (skateboard) bearings were used to provide alignment compression. On the side opposite the lateral guide the bearings were positioned at 45 degrees from normal to provide both vertical and lateral compression. Bearings on the other side provided normal compression only.

Here you see the front side of the z-axis in situ.

And here from the back side where you can see the tensioning spring for the bearings providing the normal compression.

All that I reported some days ago.

Having got to that point the next thing I had to do was identify the individual traces so that I could develop the toolpaths around them. Experience with ordinary milling toolpaths made that a simple enough exercise.

As you can see, I've colour coded the individual traces. I used a random number generator to assign the RGB values for each trace.

It should be mentioned that early on in his career, our own Dr. Adrian Bowyer developed an algorithm for doing Voronoi, also called Dirichlet, tesselations. I'm not sure what the algorithm he developed looked like in that it was published in a journal in 1980 and I wasn't able to get at it on the web. I was going to ask Adrian for a copy of the paper, but hadn't got around to it. This morning, not having the paper in hand, I decided to have a go at writing my own and seeing how it came out.

I use a finite element rather than a geometric approach in all of the Slice and Dice apps that I've written. The PCB app I've written follows the same prejudice. Coming from that prejudice, it seemed to me that Voronoi tesselations could be generated rather simply from a bitmap of the traces, suitably identified by trace, by simply wrapping each trace in successive layers of pixels until the accreting traces ran up against one or more other traces. At that point growth along those boundaries would stop and growth would continue by accretion until the PCB was filled.

Here is what the USB/18F4550 circuit board looked like when you applied that rule.

It may not be completely kosher, but worked fairly well. As abstract art, it wasn't too bad, either.

Here, I've overlaid the original components and traces on top of the Voronoi expansions of the traces so that you can see how things fit on the board.

My next task is to generate a drill file consisting of the centres of the little red circles on the layout.  Those are where the chip pins fit.  That should be trivial.

Here you see the edit and build window. You choose the footprints of the basic components from a pull-down menu and click the pin 1 of each onto your grid. The grid resolution is standard 0.1 inch (2.54 mm). It works sort of like stripboard, but in two dimensions instead of one.

You can see from the layout that the 18F4550 is an extremely easy chip to set up communications for.

Once you have your components laid out and connected up to your satisfaction you can just look at the layout sans the grid.

Then you can click to just look at the copper.

I will scan that window directly in VB.NET to generate the array that the milling routes app needs.  I suppose I could also simply put it out as an image so that anybody who wanted to do chemical etching could do so.  It would be easy enough, but it's not something I am personally interested in.

Once you're milling your own PCBs, the economics change rather dramatically.  Aside from not having to worry about front end costs and placing a substantial order to spread my overheads, I can get single or double sided board material for about $0.6/square inch.  A 150x150 mm board costs a bit over $2.  Because of that, the incentive to make the boards as tight as possible simply isn't there.

I'd decided some time ago that Tommelise 2.0 was, as part of it's ability to print parts, going to be able to mill the printed circuit boards (PCBs) for Tommelise 3.0. One of my long-standing goals for the whole Tommelise Reprap project has been that a reasonably bright twelve-year-old should be able to build one from printed parts received from another Tommelise owner.

In order to make that happen I needed to be able to convert the output from a PCB design app to something Tommelise could understand. On the face of it this was no big deal. Eagle can spit out G-Code via a plug-in while KiCad and FreePCB can handle Gerber format plus a few others. As I've discovered, however, appearances can be deceiving.

A few months ago, I ran across a lovely paper on applying the Voronoi Isolate notion to the calculation of toolpaths for milling PCBs. Recapping briefly, most PCBs are made by one of several chemical etching processes. The end result tends to look something like this.

When you convert the G-Code or Gerber files over to toolpaths for a milling machine you get an end result that looks like this.

If you look closely several helpful pieces of text that were included on the chemically etched PCB have been translated, more or less, whole cloth into milled paths which, incidently, have nothing to do with connecting one pin or component to another electrically. Traditions which developed over the years in chemically etched PCB design encourage this sort of thing. Eagle, KiCad and FreePCB all do this sort of thing. While that's helpful, when Vona and Rus at MIT popped this Gerber file into their Voronoi Isolate app, this resulted.

If you look on the board in the position where printed text appears on the etched and conventionally etched PCBs, you see that the text has been transmogrified into something looking like vaguely like an insect larva. While that was somewhat distracting, I began to see real problems in their coding when I stumbled across this little bon mot in their report.

As it relies on the above-stated assumption about the Gerber input, Algorithm 1 does not work in all cases. Some parts of some traces may not have segment endpoints and flash center points which precisely match-up, even when most parts do. An example is shown in Figure 3 (left), in which Algorithm 1 has already run and assigned primitives to traces as best as it could. Such cases can only be detected by searching for geometric overlaps.

My original plan was to use the MIT Voronoi app along with KiCad to generate nice toolpaths for Tommelise. When I read the paper closely, however, I discovered that the authors had apparently implimented Algorithm 1, which had the sorts of all-to-common problems caused by less than perfect Gerber formatted input files. As well, they'd used a rather complex geometric approach to creating Voronoi Isolates and implemented it in, the good Lord save me, Java. While they proposed another, presumably more bullet-proof, approach and even sketched out how it ought to work in some detail, there was no evidence that they had ever coded their Algorithm 2, much less tested it.

I've played sleight-of-hand in enough research reports over the years to know that if they'd actually written and tested Algorithm 2, the authors would have been bragging about it and have written subsequent papers about it. As it is, nothing is out there. That means that it either never got written or the authors are keeping it under wraps in hopes of commercialising it, quod erat demonstrandum (QED).

{Update, please note:  Marty Vona has corrected my misapprehension about the state of Algorithm 2.  Indeed, Algorithm 2 was coded and is available at the link...

http://www.mit.edu/~vona/Visolate/visolate/processor/TopologyProcessor.java

I wrote some code that did Voronoi Isolates years ago using a much simpler grid approach and had most of the routines in Slice and Dice to do the job again.

That left me with learning how to design PCBs with one of the available, preferably open source, apps. As I spent more time with the apps, I tossed Eagle in that although it was very good, it was a commercial app. While they let you use a severely cut-down version of Eagle for free, if you needed more than that, you were looking at paying $750 for just their standard version. While I've never shunned software just because it's commercial, I've got a severe allergy to paying more than a very few hundred dollars for one app.

It was a matter of a few moments to locate a torrent for a recent cracked version of Eagle on Pirate Bay which would have got me around this obstacle. Thinking about it, though, it became clear that it was just bad business to predicate the success of an open source project on a commercial app that users would be tempted to pirate. Thus, Eagle became history.

The more I worked with learning KiCad and FreePCB the more I kept thinking about that hypothetical bright 12 year old that was my professed target audience. If he or she had the slightest touch of attention deficit disorder, the learning curve on either of the PCB apps was well over a magnitude too long. It was like learning Algebra in Middle School, it takes far too many hours "learning" things that turn your mind to slag before you get anything back to convince you that it's worthwhile going on.

The authors of both packages began to write their apps years ago with the notion of creating a simple app that would draw in a lot of new users. Over the years, however, both apps became more and more like commercial bloatware, and their original simplicity deteriorated with each upgrade even while their power and flexibility increased dramatically.

As my spare time, hour by hour and day by day, evaporated, I began to realise that I was caught in the old, old situation which is most efficiently described as...

...when you are up to your ass in alligators, it is difficult to remember that your initial objective was to drain the swamp.

Briefly, I felt like I was trying to drive a lawnmower from the cockpit of the Space Shuttle.  I'd only wanted to mill single, or at most double layer PCB's.  I'd gone to a LOT of trouble to keep my controller designs simple and using as few parts as possible.  By 1830 yesterday evening it had become crystal clear that the situation had spun completely out of control.

With considerable trepidation, I began to write my own app.

I got acquainted with KiCad, a French app, some years ago and had got quite used to and liked Eeschema, the schematic module.   It was quite useful for documenting my controller designs.  As well, I'd generated my own component library to get me somewhere between schematics and physical board layouts.  Ordinarily, chip pins in the Eeschema libraries are grouped, more or less, by function rather than actual physical position on the chip.  I'd rewritten those chip descriptors to reflect the real pin positions on the perimeter of the chips that I was using.  I found being able to look at my board and look at my schematic and see, more or less, the same thing was very handy for quality assurance. 

Having come on the Reprap project quite early on, I'd got, with considerable pain, into using stripboards, specifically Euroboard stripboards, as a development tool.  Stripboards are rather handy for blocking out new circuits and are more permanent than a powered breadboard.  Recently, however, my use of hex inverter chips to reduce the number of microcontroller pins needed to run T2's stepper motors have rather overwhelmed the ability of the Euroboard stripboard to cope and the poor things have been covered with a mass of jumper wires.

When I thought about it, I wanted to mill PCBs not much more complicated than stripboards before the mare's nest of jumper wires began to collect on them.  I want there to be a one-to-one match between my schematics and my boards whenever possible.  What I coded last night pretty much does that.

I can...

• place footprints of the components I need on my board
• put solder pads under the pins
• connect the pins with traces
• generate an XML formatted equivalent of a G-Code file that my milling module in Slice and Dice can make sense of
• geneate an XML formatted drill file that tells T2 where to drill the holes for the component pins

I've got maybe one or two more man-days to add in a few editing and file save/refresh capabilities and then one or two more to interface the file formats with the milling modules.  I should be able to cut some test PCB designs that actually mean something next weekend.

What you are looking at is a six-toothed involute profile sprocket gear cut on Tommelise 2.0. It has a pitch radius of 6 mm, a pressure angle of 20 degrees and with its involute profile surface defined by six planes. I cut it with a 1/16th inch cutter mounted in a flexible drive shaft on a standard Dremel hand tool mounted to Tommelise 2.0's positioning robot. It was cut in commercial 1/4th inch black, HDPE sheet.  This sprocket is probably smaller than it needed to be. 

I wanted, however, to test the envelopes of my Slice and Dice software, the cutter and the positioning accuracy of the Tommelise positioning robot.  I could probably get eight teeth on a 6 mm pitch radius gear, but that would be right at the limits of my system.

It took me about two and one-half hours to cut it. Most of that time was spent worrying that I'd mar the piece. It should go quite a bit faster in future now that I have the parameters for working HDPE on this machine.

I developed the gear profile using a script that I wrote in Java two years ago as an add-on for the Art of Illusion 3D modeling system. Testing out the profile on a poplar blank went on yesterday after what seemed like a lifetime of tweaking my Slice and Dice routine to do milling work instead of additive extrusion. You can see the relative size of this sprocket gear with respect to the original ten-toothed prototype that I cut some weeks ago.

Yesterday, however, everything seemed to come together and this morning during a break from my day job I found the final bug in the routine that turns the XML description of the gear into print instructions that are sent over the PC/Tommelise USB link and burned on the EEPROM print buffer.

My first attempt to cut this sprocket was tried with a sheet of 1/4th inch polypropylene. The handling of this material, however, proved to be tremendously different than HDPE, so after work I decided to do a trial cut in HDPE, a material I've had some prior experience with, instead.

Here, you can see the scale of the sprocket. I designed the gear to have a precut hole that would give me a good friction fit on one of my little tin can stepper motors. The sprocket looks a little fuzzy because I didn't have any fine grit sandpaper to clean the swarf off with. Knocking off the swarf was a matter of a minute or so with a fine screwdriver and a loose cutter.

It needs saying that this sprocket is only sort of a demonstration piece. I've actually designed it as part of a fist-sized alti-azimuth positioning system for an infrared radar environmental mapping system that I'm building for a mobile robot project that I began recently. That project is most definitely not open source so you'll not hear it mentioned again for some time, if ever. Tommelise is getting put to very practical work from the get-go.