Saturday, September 19, 2009
BAMbot (bamboo robot)
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:
Arm based as compared to Cartesian robot.
FPGA based electronics
Does not natively support G code
DC gear motors and sensors as compared to stepper motors
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
On the other hand, if you can get this to work (it's very difficult and many have tried) then kudos. One way for you to maintain good control would be to have a motor pulling each axis both ways. They pull against each other and that is a way to get better control. It's the way muscles work and aparently is how Disney do it in all their anamatronics.
a design basis might be gleaned from this http://www.thingiverse.com/thing:781 printable arm that uses servo's that Simon Kirkby designed.
Actually the 5D G-Code interpreter firmware contains a linear acceleration capability and of course still the feed rate.
Have a look here:
I've been using it to reduce stringing because you can achieve much higher speeds.
I've noticed a few things that might lead to a slightly different design:
1. The smarter the process parsing the geometric data into motion control, the bigger bandwidth you need to the motion controller. You can help this somewhat by adding a buffer, but in the end bandwidth is better.
2. My laptop is overkill for the geometry to motion control parsing. An ARM or potentially a ARM-softcore on an FPGA, could easily handle the geometry to motion control parsing.
3. Having the laptop tethered to the machine isn't very much fun. Especially once you get to the point where you have several devices running, now your laptop is a single point of failure.
4. While GCode isn't pretty, it's the standard geometry description language. It also has the benefit of being semi easy for humans to generate. While your t-code sounds like binary, gcode is more like assembly. Supporting it as an input format or as an interactive (shell) format seems like a good thing to do.
So I'm leaning towards taking an arm core, slapping on some memory and running the device on that.
When operating as a servo the current is controlled to match the static load when stationary. As long as the load is not massive, after the gearing is taken into account, then the holding current will not be much, so the motor will be fine.
It is not the same as stalling a motor connected to an uncontrolled supply, when indeed the current does increase massively.
You are on the right track.
Things like furniture seems like it would be a really good application. It's a high dollar item that is relatively simple. We could even incorporate lighting into furniture with our current technology.
Then houses, car bodies... things like that. Large complex shapes which are composed of one or two materials.
I'd eventually like to shift print materials though. Plastic is kinda expensive. I think a mix of Grancrete and recycled paper would do very well and be low cost.
I don't know how to reply directly to a post on blogger. This is a reply to Erik de Bruijin.
I just feel that G code is a bad intermediary step. It looses all of the information in the model. I feel that this is quite useful information and shouldn't be discarded when figuring the toolpaths.
From what I understand it's a two step process. Generate G code from model in PC. Generate motion profile from G code in ATMega. I think these two steps should be combined because it will create better designs and allow for more capabilities.
I also think some of that intelligence should be moved into the design tools so that the user can specify tolerances of paths or infill or other TBD functions in the modeling tools.
Thanks for the support. :D
However, I respect everyones comments, even if they are negative. If I'm doing something stupid that won't work, I'd rather know right away rather than figure it out on my own.
Also, negative comments are like grit, which polishes my design and highlights future problems.
I'm a pretty stubborn guy. I'll make this work one way or another. It might take longer than I thought and it might be harder than I thought (usually is) but that's what makes it a worthwhile achievement.
So, if you have a negative comment, bring it on. The more eyes looking at the design and poking holes in it, the better the finished product.
If I was to do it all over again I would look into worm geared motors because they aren't back drivable which means that there isn't a load on a dc motor at rest. The only problem is that if your not careful or don't have the fancy ones with internal dampening springs, you can damage the whole setup by bumping into something too hard. But its a repstrap right?
Also, watch out for power issues. What you have there is in essence an unsupported crane without the counter balanced weight. Its going to take a hefty current to move it about with the tool head attached. In short, decouple the processor and motor driver power supplies.
And finally, good luck and post your progress!
I'll be using GM17's from solarbotics and the arms will be ~250 mm long. I've shortened them considerably to make this work.
Even if you want to build a big couch, if you are building it with .5 mm thread, you'll need accuracy, probably at least to probably half of that (.25mm) to ensure the thread you lay down actually combines to make the big object you intend, without gaps, holes, etc.
Theoretically, if you can lay down bigger thread (say, 1cm thread), your accuracy requirements will probably loosen. However, I don't think current reprap techniques will scale too large.. heating and cooling, for example, is a harder problem to solve with larger blobs of plastic.
One way you might be able to overcome this, since RepRap doesn't require a lot of force in it's positioning system, is to figure out a way to precisely measure the point of extrusion (without measuring joint angles). I think you'll be in a much stronger position to get the accuracy you need, as long as your feedback system is responsive enough and you can avoid introducing feedback degeneration.
Yea, I thought about this a while back. I've think I've come up with a way to make scalable encoders that increase with accuracy as they increase in size. Therefore the accuracy at the end point will remain constant as we scale up.
It's in a more recent post.
A big challenge sure, but definitely worth the effort.
It is pretty much doable, FPGA should give you quite fine grain control too.
Must admit I would have been tempted to try RC servo motors as an intial experiment.
As a person who favours servo over stepper I wish you every success.
I think it's a great idea to allow fabrication of larger pieces than the largest of components in the replicator !
Also, the machine is a lot simpler than a cartesian bot.
However, this type of robotic arm might be even easier to power and control: http://en.wikipedia.org/wiki/SCARA
(but probably moving the linear part to the first joint, instead of the last to reduce arm inertia)
The static loads on the motors will be zero, and vertical bending in the arms can be minimized by constructing the arms as torsion boxes.
I was intending to build a rep(st)rap/cnc extruder with a cartesian architecture and steppers, but your post inspired me to go SCARA style with DC motors and encoders!
I'm not sure about the utility of worm drives in a SCARA though, the non-reverse drive feature is not needed and high friction and low speed might not be desirable
I'll try to keep people updated here or start my own site.
(you've probly thought about this already, but the bowden extruder would lend itself well to this, decoupling the motor and all)
Trying to brainstorm ways to simplify servo control via motion caption wii mote style.
My first reaction was to score the hinge joint with teeth and to flood it with:
a clutchplate or shear pin arangement also comes to mind.
A brake drum and electromagnetically clamping brake pads would be another option.(Making the electromagnet the brake pad may be the way to go here)
Worm drive eliminates this problem of course.
As far as control systems:
this is a cheap open source encoder that is already affiliated with the reprap project:
Looks cheaper than a cartesian bot!
The only question is how much resolution has your A to D got ?????
Links to this post: