I’ve just spent a while tracking down a but which ended up being in my PC based control software rather than in the serial servo controller firmware. The symptoms of the problem were that my servo controller would suddenly to process random, poorly formed commands. My control software was sending commands correctly but it wasn’t waiting for a command echo from the servo controller before sending the next command. Due to the design of the controller (i.

I was looking for information to help me decide which servos to buy for the legs; wondering about torque and cost and whatever when I followed a link to the Lynxmotion site and came across the documentation for their SSC 32 servo controller. Although I’d looked at their PC based control software that drives this servo controller I hadn’t seen the docs for the controller itself. It seems that it has most of the features that my controller has, including the ‘move multiple servos so that they get to the end at the same time’ command that I’m working on now.

Some of the new commands that I have planned for the servo controller will require that I load and save persistent settings from the ATMega’s eeprom. Having spent a little time looking at the example code in the datasheets it seems that you have to disable interrupts to safely read and write the eeprom. It’s not a problem to have interrupts disabled whilst I read the settings when the processor boots up but allowing new values to be written back to the eeprom as the result of a serial command will be problematic given the interrupt driven nature of our PWM pulse train.

This is the source code for the latest version of the 64 channel servo controller as detailed here. This is an ATMega168 version of the controller that was originally developed for the ATtiny2313 but which was ported to the ATMega when I ran out of memory on the ATtiny. The schematic required is similar to the one for the ATtiny2313, I’ll produce a new one for the ATMega168 when I get some time.

The new 64 channel ATMega168 serial servo controller accepts the following commands. All successful commands are echoed back. Parameters are validated and errors are indicated with an error response of [0xFF] [badParamIndex] [Command echo] where badParamIndex is a 1 based index of the parameters in the command and indicates which parameter failed validation. Set Servo Position [0x41] [servo] [position] - This command operates in the same way as the standard SSC compatible servo command that the original servo controllers supported.

Due to work pressure and then holidays and then more work pressure I had to take a break from the servo controller for a couple of weeks. Most of the code changes that I had previously been discussing have been implemented and I’m now in the process of testing an ATMega168 version of the 64 channel servo controller complete with new style commands! Since this version of the servo controller uses a custom serial protocol and since it can send unsolicited serial responses back to its controller I needed to write a new PC based control program to test it with.

As I mentioned back in April after I’d put together my first prototype leg, “the prototype leg has some fairly major failings from a mechanical point of view”. Ideally the real legs will be designed and cut from sheet material, either plastic or metal. Getting to that point is going to take some time though and right now I haven’t been able to locate a UK based laser cutting service at an affordable price.

The new functionality in my servo control takes more memory to implement due to the more complex state that we need to maintain for each servo. The simple controller could support up to 64 PWM channels on the ATTiny2313, the more advanced controller can, at the present stage of the design, support around 15. There’s scope to optimise the storage of the expanded 2 byte pulse duration values; they’re 12 bit values and so will fit in 1.

So far the servo controller development has been reasonably straight forward; once various design issues were considered and once I’d got my head around building the hardware and learning AVR assembly language. However I expect that my assembly code has many novice mistakes and that it’s probably not especially idiomatic. I haven’t been writing in the language long enough and I haven’t read enough of other people’s code for it to be otherwise.

Part of the new functionality that I’m developing for the serial servo controller for my hexapod robot is for the servo controller to take its time in moving a servo from where it is at the moment to where I want it to be. The idea being that the servo controller can worry about the required pacing of the servo moves and we can ‘step’ from the current position to the required position automatically within the servo controller.