A video is worth 10,000 words, so let’s start there!

Progress slowed a bit during the summer months, but I spent a lot more time working than writing about it, so you’re looking at a lot of changes.

First, I finished the basic mechanical design all the way through the gripper. While the arm in the video is a bit of a hodgepodge, it’s now possible to build one where all six joints share almost every part. This became a key goal to drive costs down. I only need to make a few more parts to have everything ready to test all 6 axes pretty soon.

Second, while the basic principle of having each joint controlled by its own Arduino has stayed, the implementation went through two big changes. I dumped the Uno-based boards for the Teensy 3.1 (final version will probably use the LC), because it’s capable of running Accelstepper at far higher pulse rates (10-20x, at least). It’s far more power for a lot less money, and it’s effectively as easy to use, so it’s pretty much a big basket of #win.

Next, I switched from the Pololu 8825-based boards to the Panucatt Devices version, and couldn’t be happier. They come pre-soldered with a heat sink for maybe $2 more, and are also much better designed. Setting the current limit on the Pololu boards required the hands of a neurosurgeon, and I killed three of them when my probe tip slipped a millimeter and shorted something. That gets old fast.

The Panucatt boards put most of the parts on the bottom and the pot and (larger) test point on the top, which makes them far more user-friendly. The only remaining question is whether they can run the “elbow” motor at ~1.8A without forced cooling. I’m still using an old Gecko drive for the “shoulder” motor which uses 2.6A. The Panucatt drives theoretically go up to 2.5A which would be enough, but I think they need a much larger heatsink to survive. It may just be easier to run that one joint with a $20 Chinese driver box.

There’s a lot left to do, but it’s starting to feel like I might have something like a final configuration. I’ll need to design and fab up the boards, and I’m still figuring out how to handle homing (which is necessary) and position feedback (which would enable “teach” mode and some other powerful things), but I have an idea in the mail which I should be able to try soon. I also have to make the gripper, but that looks to be easy enough. With a little luck, we’ll be picking things up before Halloween!

The past two weeks saw the first test of the arm using Arduino-based control for the joints. While the basic mechanical design is starting to firm up, the control model is still very experimental. This video shows the two largest joints of the arm running in (mostly) coordinated motion.

The basic idea here is that each joint is operated by its own Arduino running an Accelstepper-based control program, with one additional Arduino serving as the master controller. Communication happens over I2C, assisted by an Enable line so that multiple joint controllers can be triggered simultaneously. Here’s how it works:

1. The user decides where they want the robot to go
2. ____ performs an inverse-kinematic calculation to determine the target angular position for each joint that’s needed to put the tip of the gripper (or whatever) at the user’s desired location. (This part is TBD, but there are a variety of known solutions available to us so I’m saving it for later)
3. The master sends each joint its target angular position in degrees
4. After each joint has been issued its marching orders, the master pulls the enable line HIGH
5. For each joint, when the enable line is pulled HIGH, it moves to the target position

The actual routine is a little more involved, because in addition to issuing each joint a target position, the master tells each joint how fast it should go so that the motion is somewhat coordinated. Basically, the master takes the movement each joint needs to make, figures out how fast it can do it, and then adjusts the speed of each joint so that they take the same amount of time to complete the movement. This approach brings a variety of pros and cons.

Pros
The big advantage to this approach is that it allows us to control each joint with an Arduino, which everybody and their dog knows how to use, and gives us an extremely-modular system. Those two advantages are big enough that I’m willing to put them up against some significant downsides.

Cons
First, and biggest (depending on how you look at it), there will be some significant limitations on the types of motion you can do. Essentially, it will be a sort of point-to-point machine, and things like having a tool tip follow a complex path will be either difficult or impossible. In thinking through a variety of meaningful use cases, I feel like the simpler type of motion control will suffice, but there’s a risk my view is too narrow.

There’s also an issue of cost. If a single Raspberry Pi or Beaglebone Black might be sufficient to run the whole thing, then the eight or so Arduinos required for my design will cost anywhere from the same (Chinese knockoffs) to 2-3x the price for brand-name boards. The total difference in the worst case is about $100, so it’s not astounding, but you can’t take too many +$100 decisions before you end up with a $5,000 robot.

Ultimately, the good news is that this part of the robot isn’t set in stone. If someone (who may or may not be me) ultimately develops a all-in-one control, maybe based on the Machinekit/LinuxCNC project, it could be bolted on to this robot without too much waste.