Featured on Hack-a-day!
What I love about robots is that you can make a thing that makes other things. So meta! It uses gcode draw any picture you like, or you can drive it around like an etch-a-sketch. You can scale this robot up to almost any size. The version in the photograph is my smallest model. I've built three of these now, the largest of which was 3m*2m. This particular robot costs $150 in parts and, if assembled correctly, can be up & running in about 20 minutes.
You can now buy this robot as a kit on the Drawbot's official page.
What I love about robots is that you can make a thing that makes other things. So meta! It uses gcode draw any picture you like, or you can drive it around like an etch-a-sketch. You can scale this robot up to almost any size. The version in the photograph is my smallest model. I've built three of these now, the largest of which was 3m*2m. This particular robot costs $150 in parts and, if assembled correctly, can be up & running in about 20 minutes.
You can now buy this robot as a kit on the Drawbot's official page.
Remove these ads by
Signing UpStep 1: How does it work?
The basic trick of this robot is high school trigonometry.
If you know the distance between the steppers and you know the length of the strings then you can calculate the XY position of the pen. If you know the XY position of the pen and the distance between the steppers you can find the length of the strings. From there you can figure out how much the strings have to change to move from one place to another and then you can draw lines and curves.
The rest is boring tricky stuff, nice but not vital. There's some code to make sure you can't draw outside the drawing area, and some code uses trapezoidal motion interpolation to draw accurate pictures faster.
If you know the distance between the steppers and you know the length of the strings then you can calculate the XY position of the pen. If you know the XY position of the pen and the distance between the steppers you can find the length of the strings. From there you can figure out how much the strings have to change to move from one place to another and then you can draw lines and curves.
The rest is boring tricky stuff, nice but not vital. There's some code to make sure you can't draw outside the drawing area, and some code uses trapezoidal motion interpolation to draw accurate pictures faster.
Visit Our Store »
Go Pro Today »
At first I thought my problem was indeed the software I was using - it uses linear interpolation, rather than your cool trapezoidal interoplation. However, the author of the code I'm using states that if I were to use timing belts and pulleys, it would work just fine :S
Do you wind your pulleys with a great deal of line? Or just enough to allow the pen carriage to address the entire canvas and no more? Also, what kind of line do you use? I used some cheap fishing line, but maybe there is something even smaller I could try.
Thanks! :)
I've been building a wall plotter based largely on the Der Kritzler bot (http://tinkerlog.com/2011/09/02/der-kritzler/ )
My blog posts: http://cs.unk.edu/~webb/tag/wall-plotter/
My personal wiki article: http://cs.unk.edu/~webb/wiki/index.php/Wall_plotter
In my opinion, the Kritzler software and hardware execution is far more elegant and clean than most of the others I've seen, so I have been really drawn to it. He uses two A4988 motor drivers from Pololu to drive his motors. Each of those drivers only require two data pins to be connected to an Arduino to work, so it is very easy to expand and hack. I was thinking of actually using my extra Arduino pins to interface with a bunch of sensors so that users can eventually draw images like an etch-a-sketch (distance sensors, photocells, etc).
Have you read my code? I'd be interested to know if you consider it "cleaner". I borrowed a lot from GRBL. Most of it is sanity checking for silly humans.
I think your code is decent and better than a few of the other plotters I've come acorss, but I still really enjoy the Der Kritzler code more. At the end of the day, if the bot performs the functions that you wanted it to perform, that trumps any bugs or programming mistakes, so I'm just expressing my personal taste in code (not how it 'should be'). The Der Kritzler code completely decouples the various aspects of the system so that you don't have to trace phenomena down through different files. For example, all of the geometry to be drawn by the plotter comes from a single external SVG file. A Processing sketch processes it as a series of vertices and lines, and uses a simple object to send commands to the Arduino. This way, if I change the protocol (to say, Bluetooth or XBee), I don't have to rewrite the main code - just implement a new class to handle it. Neither the Arduino or the Processing code have any hard-coded behavior about how to draw features, so artifacts and distortion can easily be traced to physical mechanics or faulty input.
The Der Kritzler designer did a great job of implementing very smooth object-oriented code, and ended up with far fewer lines of code than any other project I've seen. I feel that Processing is a good choice over raw Java for helping to reduce unnecessary complexity and 'sketch' out ideas, just like Arduino does for electronics. Also has the benefit of resulting in much simpler, easier to read code.
Here's a link to the Kritzler Github if you're interested in browsing around: https://github.com/tinkerlog/Kritzler
Like I said, if you get the results you want with your code, that's more important than what any internet 'expert' has to say! I just wanted to discuss my own style and reasoning for my choices :)
Great question!
I'm looking forward to the update promised in step 3...