The final command for my serial servo controller is the most complex. The idea behind it is that with a hexapod leg you will want to be able to move the leg to a new position where the new position requires all three of the servos that manage the leg to move to potentially new locations. Ideally you want the “foot” to arrive at the final resting place in such a way that all of the servos complete their moves at the same time.
Work on the latest version of the serial servo controller is going well. I’d accumulated a pile of random nice to have ideas, some of which then necessitated some other ideas, and then there was the one must have command (the one which moves several servos to new positions over time and ensures that they all arrive at their final resting places at the same time). Of course I’ve worked on some of the nice to haves rather than dealing with the final ‘must have’ command that I need before I can move on to writing some gait controlling software to move multiple legs in sequence…
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.
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.
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.