aaronbot3000: Pythagoras, Version 1

Goals

The goals for this robot is straightforward. Vectorize an image, draw it on paper, and do it reasonably well.

And so...

Here I go designing a robot. After figuring out the math discussed in the previous post, I head out and model it all out in SolidWorks. And it looks all fine and dandy. A complete parts list can be found at the bottom of this post, in the Appendix.

Since I was away from Tech, I had no access to their big fun machinery, and am thus forced to buy custom parts. I get the parts all cut out from Big Blue Saw, all from a sheet of 1/8" 6061 aluminum. Regarding Big Blue Saw, when they say the parts cut on standard quality will have taper, they mean it. I measured .02" of taper on a 1/8" thick part. Its definitely noticeable.

For the motors I used pretty cheap Hitec HS-5485HB hobby RC servos. I did spend a little extra money to get some better digital servos. When sent a signal that is out of range, instead of destroying themselves, they stop. Brilliant!

For the pen I chose one of the nicer pens I have lying around, a Pilot Precise v5, but honestly, any pen will work. Later I switched it out for fear of permanently damaging my nicer pens. The pen holder is very simple. Just a hole in a plate, with the pen held in by shaft collars.

The rods are 4-40 threaded rods. Nothing fancy, though they are a little flexible. Stiffer material (carbon fiber?) for a later version.

Soon, mail shipment!

After much tapping of screw holes and filing of slots and tabs, assembly!

And then after hacking away at steel rods with a cheap (< $2) hacksaw from Wal-Mart, complete assembly is complete.

All that's left to do is to program it, right?

For motor control, I use an mbed, an ARM Cortex M3 based prototyping board made by NXP. It is similar to Arduino in that it has its own IDE and libraries that nicely abstract away the peripherals to something nice like i2c.send(0x3F)instead of having to deal with registers and the like (of course, at the cost of control over your microcontroller). However, the mbed has way more peripherals and memory, both RAM and Flash, and it runs at a cool 93 Mhz, as opposed the Arduino's 16-ish Mhz. The downside are:

You have to be connected to the internet to program it, since it uses a nasty online IDE and compiler.
Due to the online IDE and compiler, no debugger is available, just print lines to serial.

While there does exist an offline compiler for the mbed, you lose access to the libraries, so I just sucked it up and worked with their online IDE. After a bit of code hackery, first movement. Huzzah!

But something was wrong. The first images were supposed to be straight lines, and they were distinctly curved.

Curved even more than the iffy servo control would suggest. As it turns out, I should have been more careful with inlined functions. Removing the explicit inlined function, and I get successful drawing!

Yes, I am very aware the square it should be is very reminiscent of a piece of toast.

But that's okay, acceleration and deceleration of the manipulator hasn't been implemented yet. But it was implemented and how the path planning works will be discussed soon.

How the Path Planning Works

The algorithm works by simple linear interpolation between two points given in 3-D space. It also adds in a linear acceleration and deceleration zone, near the endpoints. The zones are currently set to be 0.5" long at both ends, though that can be varied.

What happens is I have the current position of the manipulator, labeled (X1, Y1, Z1). I then create the step using the math as follows.

Basically, I am normalizing the line into a unit vector, then multiplying the vector by a step size to basically nudge the current position along the line.

The step size is how I control the acceleration and speed. Bigger step size, higher speed, at the cost of accuracy, due to the lack of control over the servos' velocity (this will be fixed in version 2, where I use stepper motors). The "checkpoints", or the set positions of the manipulator along the drawn line look like this.

Using inverse kinematics, I determine the angle of the motors, and since they are RC servos, I simply send the angle over a PWM signal and forget about it.

However, right now I have to program individual points into the microcontroller before it will draw them. Perhaps there is a better way of getting points to draw. Perhaps, from a vectorized image? Streamed from the computer?

Regarding Arm Lengths

After a couple days of experimentation, I realize the arm lengths are way too long for drawing. Over the entire drawing range, the arms move very little. A high upper to lower arm gives great range, especially in the Z direction. But that's not what I need. I need great accuracy over the X-Y plane. And so, after some guessing, I cut the arms shorter. To half their original length. Yes, those are leftover tips of arms being used as foot pads.

Protip, when you're cutting things with a cheap Wal-Mart hacksaw, and things have really really started to jam up, see if you have broken any, if not all of the teeth on said hacksaw.

With the shorter arms, I can draw a reasonably accurate star.