Sunday, September 27, 2009

 

PLA vs ABS - warping


Warping was a major issue for me when I was building larger objects out of ABS plastic. The lack of warping with PLA is quite striking; I thought I'd post a comparison photo here for the rest of you to enjoy. The x carriage on the left was made with ABS, and the x carriage on the right is PLA, as well as the idler bracket in front. That ABS x carriage isn't the best part I made out of ABS, but it isn't the worst either; most of my larger parts exhibited worse warping than that.



Sunday, September 20, 2009

 

Scaleable encoders




I've heard a lot of people talk about high resolution optical encoders being quite expensive. I've decided to use cheap optical sensors from optical mice to make optical encoders for little optical elves who live in optical cities making optical cookies with their little optical ... whoa ... shrooms are kicking in ... Anyway, Avago Technologies makes some pretty good ones. They optically measure the mouse sliding over a surface and convert this to a 16-bit delta X and 16-bit delta Y. The $2 encoders get 1600 dpi and the more expensive ~$6 encoders get 5000 dpi (claimed on the data sheet, not experimentally verified).

They perform multiple useful things.

First, they constantly measure the change in X and Y. This can be used to make a linear optical sensor or a rotary optical sensor (you measure the tangent). I think the rotary sensor might need a look up table to translate from delta Tangent to delta Angle, but this can be determined in the future. The linear sensor can measure travel in two dimensions. If it was possible to mount it under the table of the maker bot, it could record the XY motion at the same time.

Secondly, most can capture a 32x32 image. Some update this image over 1000 frames per second. This can be used to read a printed strip to update the absolute angle. In my design I have a strip of binary hamming encoded numbers that my sensor will periodically read to update the angle.

Third, the resolution scales linearly with the distance of travel. I use this to record angle. If I need a more accurate angle measurement, I increase the diameter of the strip it reads. I'm planning on printing my strips on CD labels (not how it looks in the picture). I'm using a half circle strip. The CD labels are about 118 mm in diameter. Therefore my strip is 118mm * PI / 2 (half circle) / 25.4 (mm to inches). About 7.29 inches long. My optical mouse sensor has a claimed resolution of 5000 dpi. Therefor my sensor has a theoretical resolution of 36468 ticks. I'm a bit skeptical of manufactures claims, but I should be able to get between 14 and 16 bits of resolution.

Fourth, as the machines scale up I want to maintain the same level of accuracy at the tip of the machine as the smaller machines have. This means that I will need much higher accuracy of the encoders. I accomplish this by making the encoder bigger.

Fifth, it might be possible to operate some of these devices as a camera to image objects far away. Some have a laser built into the device. These emit coherent light. Great thing about coherent light is that if your optics are focused to infinity then everything looks in focus. It doesn't depend on the distance. It might be possible to mount one of these next to the print head and use it to image the surface we are printing on or the object we are printing. This is a bit of a stretch, but it might work.

Sixth, one could be mounted on the print head to calibrate it's motion. A calibration algorithm would move the head down till the sensor is just above the surface of the table and then move the head in the XY plane. Using data from the sensor the motion of the print head can be characterized and corrected.

 

reprap/makerbot gcode visualzation from skeinforge

hi all,

i thought i'd post some preliminary screenshots and videos of a visualization tool that i started writing yesterday. the tool is for visualizing the toolpath of the reprap/makerbot extruder, and it's inspired by the visualization tool that Zaggy hinted he was creating in his Thingiverse post for the printed extruder ( http://wiki.makerbot.com/makerbot-127 ). my tool is also in a very early stage, so the visualization is still very simple, but it's still kind of pretty to look at. it's written in 'processing', a language i just learned yesterday, which is java-based and multiplatform. i think replicator-g is also java-based, so there may be the potential to incorporate some more interesting visualization tools (such as this) directly into replicator-g somewhere down the line, if that's something folks are interested in. it also might be useful in the near-term for demonstrations, if you're giving a presentation for a reprap/makerbot and would like some video or pretty pictures of the toolpath of the object that it's creating.













thanks for reading :)

Labels: , ,


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:

      1. Arm based as compared to Cartesian robot.

      2. FPGA based electronics

      3. Does not natively support G code

      4. 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






Friday, September 11, 2009

 

Printing with 2mm filament

I recently obtained a few feet of 2mm white ABS filament and decided to try printing with it.

I use a pinchwheel consisting of a small brass spur gear. A ball bearing is on a lever and presses the filament against the pinch wheel due to the force of a rubber band (with multiplication from the lever). There is not much holding a 3mm filament from sliding sideways and out from between the spur gear and the bearing, but 3mm filament is stiff enough that it is not a big problem. When I tried the 2mm filament, I had to modify the level a bit to allow it to come close enough to the spur gear to press the 2mm filament against it. I also printed out a better filament guide to prevent the 2mm filament from moving sideways.



Once I had done these modifications, and had tweaked the skeinforge settings (halved the feedrate and decreased the expected extrusion width slightly), I was able to print well with the 2mm filament. Here is a paperclip (http://www.thingiverse.com/thing:655) by "unfold". While I was extruding, I heard a slight popping noise (frying?) which I do not hear with the 'natural' colored 3mm ABS filament (from Village Plastics). I suspect that I may be running the tip a bit hot for this material.

Interestingly, I got good results with a 2mm filament in a 3mm+ hole, which holds 3mm filament fairly snuggly. When I pulled out the 2mm filament from the extruder, it looked like this:I described the heater end of my extruder here recently (builder's blog of August 29, 2009). It looks to me like the 2mm filament is just pressing up against the dished end of the acorn nut and not spreading out much. I am probably deluding myself, but it looks like this is a hint at a simpler extruder.

Frank Davies

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]