The Heads on Fire Community

The whole goal behind this version of a repstrap is to radically reduce cost and lay a framework for scaling the RepRap up to larger sizes. There are some major differences between my design and the RepRap. Here is a short list of them:

Some of these changes seem quite drastic and might cause some flame wars to erupt, but here is my reasoning for these changes.

First I choose to base my design off of a robotic arm as compared to a cartesian robot. The robotic arm design is not as stable as a cartesian robot and it is far more difficult to control. However, the upside is that an arm can print out things bigger than itself. I would like to increase the scale of my design by about 50% per generation. I'm also a big believer of monolithic design, printing out very complex parts that combine multiple functions. That's the beauty of a 3D printer. Also, the weight/cost is better as I scale the design up.

Second is the choice of FPGA based electronics instead of the ATMega based design we currently have. When I design something I tailor the design electronics to the type of computing that will occur. You can think of two different classes of calculations. Those that would occur in your frontal lobes and those that occur in your brain stem. The frontal lobes would control things like user interface, converting G code to optimized paths and anything with a lot of if/then branching statements. The brain stem interfaces with the hardware, controls timing of signals, pwm and adaptive filtering. Brain stem functions belong on an FPGA. Frontal lobe functions belong on a microprocessor.

We already have a very powerful microprocessor in my system. It's a PC, Mac or Linux box that the device is connected to. I'm going to move these functions into the 'print driver'. The print driver will output something I call t-code. It's similar to a .wav file. It will record the desired angle of the joints at a certain sampling rate. The rate is built into the file. The PC will write this code into a ram buffer on board my repstrap. The FPGA reads these points out, upsample/interpolates them to a higher rate and uses adaptive filtering to make the joints of the robot match what is recorded in the t-code.

In the future I hope that this will allow more intelligence in the code which converts from model to g-code. It will allow this block of code to optimize the acceleration and motion profiles offline. It will also allow much more number crunching to optimize the paths. Perhaps some of this will be added into the modeling tools allowing you to specify tolerances on the surfaces. Some surfaces don't need to be exact and this can be used to increase the print speed or reduce the materials. Some need to be very precise and this would allow the tools to adjust the print head accordingly.

As the above paragraph comments on, I don't natively support g-code. I hate g-code. It does not contain any acceleration/velocity data. This makes writing a good motion controller very difficult. Especially writing a motion controller which acts in real time. This is better to evaluate the motion offline in unreal time and record it to file. My design takes in T-code. A simple file with sample points with specified time. I'm sure someone will write something that evaluates G-code and converts it to t-code specific to this machine (all t-code is device specific by nature).

I choose DC gear motors because they are much cheaper and offer a better power to weight ratio. My whole design is based around choosing components that offer the best power or strength to weight ratio. Also, by designing using servos I'm paving the way for printable motors. I'm sure that the initial motors that we design will not be on par with the performance we can buy off the shelf. However, using a servo loop and adaptive filtering we should be able to work with a wider range of motion systems. From air muscles to flat voice coils. Hopefully we can handle anything that moves and control it.

 

Currently I have a first draft of the mechanical system for my design. I'm working on a better version which will use motors with 2x torque, larger encoders and shorter arms. I have a angle sensor put together but not tested. I'll hopefully be getting the FPGA board in next week or the week after. Then I need to order the extruder head. I'm going to use the Bowden extruder because I need as low weight as possible.

What you see here is about $70 worth of components. The motors are about $5 each and the bamboo came from ponoko.com for about $40. Each joint has a 15x28x7 mm bearing (about $1 each). Then some assorted screws and wires. Add to this the price of the electronics motherboard (using a $100 FPGA board right now, but a custom solution could be under $30) and the sensors (could be as low as $3 each for finished boards). I think this design could be copied for under $200 in quantities of 1 and under $100 in quantities numbering in the 100's.

... if it works ...

-to be continued