Recently in Electronics Category

From a hardware point of view I had several things to work on. Firstly I needed to get the servo controller and I/O multiplexor chips off of a breadboard and onto something a little more permanent. Since I still find building things with perfboard a little hard I decided to build the controller itself on one board and build separate daughter boards for the I/O multiplexing. This should mean that I can replace the parts separately as long as the connections required remain the same. I decided that each I/O daughter board could contain 2 CD74HCT238E's with some header pins for each of the 16 output channels, 3 pins for the address selection lines and 2 more for the signal lines. I deliberately left off the power and ground pins for the servos as these really didn't work well on the perfboard. The power and ground pins are connected in one direction and the IC to servo control connections are in another direction; without some fairly hairy board trace cutting and cross soldering doing both on a single perfboard would have been impossible. My solution was to build yet another separate board from a different style of perfboard for the servo power and ground connections; this was just two long strips of headers connected as two buses.  The servo connectors themselves are then used to physically hold the two boards together. This has another advantage for me in that it will allow me to reuse the I/O board with a more complex power and ground supply board if I decide to investigate the servo torque feedback idea some more (this may require monitoring each of the servo power lines and so would require a different style of power supply board).

Here are some pictures of the resulting boards.

I now need to build another I/O board and I'll have 32 PWM channels for my servos. 

The servo controller itself ended up being on a board which could probably be used for all manner of ATMega projects. The board contains header pins for the I/O lines that I need, a reset button, a socketed crystal, power buses and an ISP programming header. About the only thing that's been specially done for the servo controller application is the fact that the I/O multiplexor address lines have 4 banks of headers broken out so that I can connect multiple I/O boards to the servo board easily. The board is pretty much complete and works well; I'm especially pleased with the ISP header as it was quite tricky to fit onto the board due to the connections required. All that's currently missing are the caps on the clock lines, but the board works pretty well without them and they're currently on order and there's space on the board for them. Note that a slight physical design error meant that the single power and ground pins that I had intended to use were in the way of the ISP plug. I cut those off and replaces them with the longer header strips which work better as they give me somewhere else to get a power or ground connection from...

Once all of this was done I tested things and then swapped out my Max232 board for the Sparkfun regulated XBee breakout board and connected the XBee in place of the hard wired RS232 connection. This worked well and left me with a set of boards that only required a power line to tether them; the battery system is on my list of things to work out. Unfortunately I managed to brick one of my XBee's. I'm still not quite sure what happened but I think it could have been either a spike on the 5v power line or a 5v splash onto the XBee TX line. The Sparkfun board regulates the 5v supply to the 3.3v required by the XBee and uses a diode to drop some voltage on the RX line so that the 5v TTL logic line from the ATMega is dropped to be within the tolerances of the 3.3v logic required by the XBee but it leaves the TX line unprotected (the 3.3v logic levels of the XBee are enough to register as valid levels for the 5v side of the circuit but if 5v were applied to it then it would cause problems...). Ideally I'd like to put together a more robustly protected circuit with level shifting on both RX and TX lines but right now I don't quite know how to do that (even the AdaFruit XBee board only level shifts the input lines and leaves the output lines vulnerable). I expect I'll use the Sparkfun level converter board when I get a replacement XBee.

With my electronics off of my breadboard I began working on the servo sequencer. This will deal with moving the servos in sequence to create various walking gaits. Once I'd played with a simple sequencer I decided that I needed to solve the 'hip joint' problem once and for all and then build more legs; after all,sequencing a single leg isn't that much fun.

The prototype leg that I built way back at the start of this project has always been weak as far as the hip joint is concerned. The need to connect two servos at right angles using only a piece of plastic window board creates many problems. My experiments with using metal brackets made from Mecanno failed as the pieces I had were insufficient to hold the servos correctly. Unfortunately I don't currently have access to the custom machining facilities that this guy has access to, so custom aluminium parts are out of the question. In the end I spent a lot of time with a craft knife and pieces of window board and eventually came up with a design that seems to work; at the very least it's stronger and more reliable than the original leg. The design is based on the custom aluminium pieces from the A-Pod hexapod. I expect it will still change somewhat but it's enough for me to move forward...

I now have 6 Hitec HS-645MG servos on order along with a couple more XBee radios and a few more bits and pieces. The plan is to build two legs with the new servos and get the sequencer working. Once I get to this point I should be able to purchase more servos, carve more legs and move to a full six legs. Perhaps this hexapod project will actually have a hexapod before we reach our one year anniversary in April.

The schematic, in Eagle format, is here: ATTiny2313-24ChannelServoController.sch

and a potential board layout is here: ATTiny2313-24ChannelServoController.brd

These were produced with Eagle and I don't think I could have worked out how to use Eagle without reading Build Your Own Printed Circuit Board by Al Williams. A great book for demystifying Eagle.

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.

Today another parts order arrived (this what what alerted me to the loss of the first order; they were both from the same supplier and I expected them to come as a single delivery). Today's order contained some CD74HCT238E's, these are the 3 to 8 line demultiplexors that I'm intending to use to expand the PWM channels that I can produce with the ATtiny2313. The microprocessor can use three address lines to control multiple 238s and then use a single PWM channel per 238 to expand the number of channels that it can produce. First we'll send a pulse on channel1 of all the 238s, then we'll increment the common address lines and send a pulse on channel2 of all the 238s, etc. If we do this quickly enough we'll satisfy the servos 50hz refresh requirement and we'll have a servo controller that can control more servos than it has I/O pins; using 1 pin for PWM for each of the 238s and 3 pins for addressing all of them at once.

This afternoon I breadboarded up one of the 238s to the Arduino and cycled through each of the channels flashing an LED on each channel in sequence. Woo! Proof of concept...

I've also ordered some 138s which are similar but are active low rather than active high. These should also do the job of demultiplexing the signals but, I think, will require more board space and a more complicated layout as they'll need pull-up resistors. I'm not quite sure that I understand how to use the 138s as replacements for the 238s but that's part of what I'd like to understand...

I decided that since I would be using a 5v power supply for most of the bits of this project that I'd grab and old mains transformer and wire up a 5v regulator and run from the mains rather than batteries. Since this took up a chunk of space on my breadboard I decided to make it a little more permanent on some strip board. 

I pretty much followed the Sparkfun power supply tutorial with a little artistic license for the 'front panel' and so had a PTC resettable fuse in there to limit the current in case of short circuits, etc. Anyway, it was the PTC that was causing the problem with the servos. It was doing what it should but the servos were trying to pull more current than it would allow and so it was cutting the power (and resetting the servo controller). 

Anyway, once I realised what I thought was going on I slapped the multimeter into the circuit and watched the PTC cut out as the servos pulled more current than it allowed. 

The new power supply is pretty much the same as the old one without the PTC (I'll rely on the protection in the voltage regulators for this one) and with a 3.3v output as well as a 5v output.

The servos run fine now and the current draw is within the spec of the regulator. One more small piece of knowledge acquired...

The errors were:

Also in the package were my XBee modems and several AVR microprocessors to play with; more on those items later...

Many modern microcontrollers have built in PWM generation capabilities but the number of channels is limited. For example the Atmel AVR ATtiny2313 has 4 PWM channels available. For a hexapod robot with 'standard design' legs each utilising 3 servo motors we need 18 channels. If we want to add a movable head (for sensor targeting, or mandibles) then we could add another 3 servos at least, the list goes on. However, we don't have to use the built in PWM facilities of the microcontroller, we could generate our own PWM signals and use any available I/O pin to output the signal; this means we can generate as many channels as the microprocessor has suitable I/O pins... This method is demonstrated here on a, now obsolete, Atmel AT90S4414. An alternative is to multiplex the available PWM channels to create the required amount of channels, we can do this because hobby servos generally require at most a 2.1ms pulse length with a 50Hz (20ms) refresh. Depending on the clock speed of your microcontroller the PWM signals you can generate are probably much faster than are required for a single servo, so by adding a 74xx138 to the output of each PWM channel from the micro and explicitly switching their channels and the pulse we're generating during the micro's PWM cycle we can create a number of PWM channels running at around 50Hz from a single PWM pin on our micro that runs at a faster refresh... Or so the theory goes.

The current plan for servo control is to multiplex an ATtiny2313's 4 PWM channels using multiplexers into a number of channels. Each micro should be controllable via a TTL serial interface from another controller (or a PC) and, since, potentially we'd need multiple ATtiny's, the serial link should be transparently chainable (that is each micro should only act on requests directed to it and should ignore all others...).  

And then we add another micro that talks to these servo controllers and deals with walking and the required gait to move the legs...

Of course, to get things going, I'm quite happy to use someone else's servo controller to get things moving, so to speak...

Other places of interest and sources of ideas include...