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.