I had some free time this afternoon, so I built a box to act as the base for the BoaArm. Despite all the time I spent marking and measuring, some of the legs are still slightly warped. I guess my carpentry skills need some work, so apparently does my work with a scroll-saw.

Not quite a circle, but close enough that the outer ring of the RoboBoa's joint fits in quite snugly. This is what it looks like assembled. One axis down, two to go.

Once I have mounted the electronics inside, I will cut and mount some side panels. Unfortunately, this was the easy part. Mounting one side of the RoboBoa's joints is as simple as cutting an appropriately shaped hole. The other side, however, requires more. Inside the RoboBoa, the other side of the joint attaches to a rod that extends from either side of the shell. Things are made more problematic by the fact that the two holes (one for each side) that attach the rods to the joint, are different sizes.

What I think I will have to do, is find a suitably sized piece of dowel, and turn down one end, to fit through the other side. And then mount the rod. I am slightly concerned about the weight though. To much weight and the arm won't be able to support itself.

The cartridge programmer for the RoboPanda is going well. Fixing the voltage issue, while helping things a lot, did not actually solve all my problems. There was still an issue revolving around the baud rate. Which a computer, baud rates tend to be exact, with a micro controller, they tend to be a little more inexact. This is because a micro controller uses the primary clock (usually crystal based) signal, and divides it to get a close approximation of the baud rate. Micro controllers have to allow for a wide range of primary clock speeds (ie the one I am using can be clocked at anywhere from 1mhz to 20mhz), as such it can generate a whole lot more baud rates that your average computer, but unless you have exactly the right crystal, you can usually only get withing a few percent of a given baud rate.

In this instance, my chosen baud rate is 115.2k (or 115200baud). The closest the code I am using from the appnote can get to that baud rate is 111.11k (or 111111baud). Which for intermittent, spaced out, data, is fine. Not so good when you are transmitting data rapidly. The first 100bytes or so are fine, but then, as the error builds up, the transmitter and receiver lose sync, and everything goes bad.

Fortunately, most new AVR chips include a U2X bit, which "doubles" the UART clock rate. What it actually does, is halve the number of sample per bit the UART uses. Which means a slight decrease in noise resistance, but it sometimes also can get you a lot closer to your chosen baud rate.

Modifying the code in the appnote to use the U2X bit, allowed me to get a baud rate of 117.65k (or 117647buad), which may not seem closer, but actually is. Without the U2X bit, the AVR's baud rate is off by -3.5%, with the U2X bit, its only off by 2.1%. While 1.4% may not seem like a whole lot, its the difference between being able to transmit an entire 134byte packet without error, and not being able to transmit an entire packet without error.

So now I am able to transfer an 8meg image to the programmer without issue. I haven't checked if the chip has actually been programmed yet (I'll have to dump out the entire contents in order to be absolutely certain), but that's not an area in which I am expecting a whole lot of problems. I do know the programmer is talking to chip properly (I can successfully read the chip ID), so it should just be a case of making certain the correct commands are being sent in the correct order, and checking that I am stripping the X-Modem packets correctly, before transfer the data to be programmed into the chip.

Edit : Oh yeah, more images of the BoaArm base construction, can be seen in the BoaArm gallery.