This is rather nice; Chiara Robot from Carnegie Mellon University's Tekkotsu lab (via HackedGadgets.com).
June 2009 Archives
Here are some links that may help once I move onto fabricating the various pieces required to build the hexapod's body.
- This is a simple 4 legged walking robot that was machined from an A4 piece of 4mm ply wood.
- This is the guy's website, with more details of how he produced the robot.
- And this is the Dutch prototyping lab that he used to laser cut the pieces.
Finally, this is an interesting link to David Buckley's walking robots page.
A collection of links that I've been using recently for research.
- Hitec HS-422 Servo. The servos I currently have; likely not suitable for use as actual leg servos due to lack of torque. Useful link as www.superdroidrobots.com has links to the spec sheet for the servo and a selection of different spec servos with corresponding prices. More useful to me than the actual Hitec website as that doesn't list relative prices. Less useful to me than a UK supplier.
- Servo power and speed. What the spec sheet figures mean. Also ServoCity has another useful list of comparative prices for various servos...
- Society of Robots, USB Servo controller. This was vaguely useful when I was trying to work out how to build the electronics I needed; in the end it wasn't really what I needed. Something that looks more useful to me are the mechanics tutorials...
- Servo Magazine - looks interesting, perhaps.
- TomboT - Tom Elnar's website - useful robotics stuff.
- Serial Wombat Servo Controller - something for ideas regarding how to control the servo controller.
AVR programming
- Dick Cappel's Project Pages - a useful collection of non-trivial AVR assembler examples.
- AVR Tutorial - another useful assembly language tutorial.
Hexapod gait, movement sequencing, sensors, mapping, etc...
- The manual for the Phoenix Excel Program for creating servo position sequences for hexapod legs using inverse kinematics.
- Some interesting stuff on mapping based on the use of a sonar sensor.
In my opinion there's a fundamental design flaw in the both the 8 channel and the 64 channel servo controller firmware that I've presented. Both allow the serial data handling code to take priority over the PWM generation code. This means that there is no way to guarantee that the PWM generation code will produce a perfect pulse train in the presence of configuration changes being sent to the controller via the serial port. The problem is that although we were very careful to measure the clock cycles taken by the PWM code as it runs so that we can be sure that we're generating the correct pulses we then allow the arrival of serial data to interrupt the PWM code and throw a random number of operations into the mix thus disrupting the timings. This may cause a pulse to be longer than it should be and will also slightly shift the refresh rate.
I realise that it's actually pretty unlikely that the timings will get thrown out too much by the processing of the serial data as it stands but it may become a limiting factor as the commands exposed by the serial interface become more complex and require more operations (and therefore time) to accomplish their work. If the pulse lengths get extended significantly by serial operations taking place whilst they're being transmitted then this will manifest itself as a twitching in the servos.
Because of this I plan to redesign the code to use a timer interrupt to do the PWM generation work and to use polling in the main processing loop to deal with the serial data. Essentially I'll be turning the current code on its head... This means that the PWM generation will always have a higher priority than the serial data processing and so, assuming I get my timer interrupt and resulting PWM generation code correct this should mean that the PWM pulse train will be rock solid no matter how much work we need to do in the serial data processing code.
Or so the theory goes... Right now the servo controller code seems pretty robust and I haven't noticed any twitching when under heavy serial data load but who knows...
Here's the source code to the 64 channel ATtiny2313 servo controller. Note that you'll need to use up to 8 CD74HCT238E, or equivalent, demultiplexor chips and that you can adjust the number of servos that you can control in steps of 8 using as many or as few CD74HCT238E chips as you want. If you only want 8 channels then you can do this without any demultiplexor chips; see here for source code to the 8 channel version.
The controller uses the 'standard' three byte serial "SSC" protocol of 0xFF <servo> <position>. Where <servo> is a value between 0 and 63 (or as many servos as you decide to support) and <position> is a value between 0 and 254 where 127 gives a pulse length of 1500us. At present the timing gives us pulses of 579.25us for 0 and 2420.75us for 254. This is a greater range than we really need (at least for the Hitec servos that I'm using) but the issue here is the number of instructions required to check each pin each time through the loop. A faster clock speed would allow us to perform the real work faster and add a delay into this loop to allow us to fine tune the range a little better... Perhaps... Anyway, I hope to move away from the current design shortly to one that gives a finer control over the pulse lengths.
Source code can be downloaded here.
Continue reading Atmel ATtiny2313 Servo Controller v0.2 - source code.
I've been experimenting with the servo controller that I developed for the ATtiny2313 here and the demultiplexing chips that I mentioned here. The result is a 64 channel servo controller that seems to work pretty well. Right now I haven't breadboarded all 64 channels, I have two of the CD74HCT238E chips connected to the ATtiny but I/O pins and he firmware would drive 8 of them if they were connected to give 64 channels. Of course this is much more than I actually need for this project, but since there were enough I/O pins and since it was actually easier adjust the code from driving 8 channels to driving 8 x 8 channels I coded it up that way to see if it would work... It does, though I've had to adjust the timing loops considerably and I've switched from guaranteeing a min 900us pulse and a max 2300us pulse to simply making sure that the middle servo position is correct; this actually seems to be a better approach as I now have a clean 180 degree range of motion from the servo and the centre position is pretty much spot on where I would expect it to be...
Of course now I'm approaching the memory limits of the ATtiny. I only have 128 bytes of SRAM to play with and I need 64 of those bytes for the servo position data and a few bytes for the serial data input buffer. This means that my plans to have a mapping table that maps the servos from the physical location of the pins on the board to a nice sensible, easy to remember, logical sequence can't be implemented in this version as in itself it would require 64 bytes of memory to map the logical servo id to the physical servo control pin. The reason this would be handy is that with 8 demultiplexing chips on a board and all the associated connections the chances of getting the servo control pins to all end up in a nice sequence somewhere is pretty slim. All's not lost, the firmware itself can be tailored to match the board layout but this isn't quite as elegant as providing a simple mapping table that can be updated easily to change the mappings.
Of course I only selected the ATtiny2313 by chance as it happened to be a available for a good price and was in stock at one of my suppliers so running out of resources on it isn't such a terrible thing for the project. However, ideally I'd like to squeeze as many of my ideas for the more advanced servo controller onto it if at all possible. This should be made somewhat easier as I only need 24 channels, which gives me around 5 bytes of storage per channel rather than the less than 2 that I have with the 64 channel controller... And if all else fails I could 'cheat' and switch to using one of the ATMega168's that I have laying around...
Schematic and source will be available once I've worked out how Eagle works and once I've finished the firmware...
