Very high servo count

Forum 2005-2010 (read only) Hardware Interfacing
1

I'm wanting to build a hexapod off my arduino, and having spent a bit of time playing around with code and hardware I think I know what I want to do, but don't quite know how to go about it.

If I'm going to run 18 servos off an arduino, they're definitely not all going to be able to be connected to IO ports. But instead of adding extra hardware between the arduino and the servos (like I'm almost resigning myself to at the moment), I had an idea that maybe I could set up the interrupts the way shane colton did in his blog (sorry first post so I can't link to his site, but google for "Shane Colton Arduino Interrupt Driven Servo Routine")

Instead of driving pins as signal however, I would drive both a set of pins for timing, and a set of pins to control the bank of servos currently being sent timing information.

so, simplest setup is four servos, pin 0+1 are servo bank select pins, pin 2+3 are the timing pulse pins. In my mind, the setup consists of transistors on the bank lines that let the timing pins access the actual servos. So, pin 0 collects T1 and T2, pin 1 collects T3 and T4, pin 2 is base on T1 and T3, pin 3 is base on T2 and T4.

That's my theory, however, my practice won't even bear out one servo's control being turned on and off by a transistor, it just seems to either always send signal, or not at all, which means I must be just not getting the right understanding of transistors or something.

Simply said: I can't get a transistor to act as a gate to my servo signal. What could I be doing wrong, what transistor types are best for controlling flow like this?

In the end I want to have four banks of five servos (two spare for other magic), where maybe pins 0-3 are bank control, and pins 4-8 are the signal lines that all matrix together.

The software would iteratre over the banks. For each bank it would pin-high all the timing pins, then pin-high the bank pin, then pin-low the timing pins. One bank should take 2ms, so it takes ~8ms for all four banks, leaving me 12ms to do any calculations ready for the next frame (that's if I do this the dumb way without interrupts).

2

If you need to save pins, it wouldn't be much effort to use a demux (eg 74hc138) or a plain shift register (eg 74hc595)attached to your pin. That's probably cheaper than a graveyard full of transistors, they'll cost you less than $1 per set 8 servos. As the Servo library feeds each pin after the other anyway, modifying it to control something else instead setting pins on the ATmega isn't much of a problem.

The main problem I see is whether you can refresh the servos fast enough. Usually each servo should be sent a PWM signal every 20ms or so, or it starts to lose the position under load. Each PWM-signal is up to 2.5 ms, which gives you the number of 8 to 12 servos per timer. On a ATmega 328 or 168 you just have 1 16-bit timer, thus attaching 18 servos will be pushing it. If it works, fine, but it might not. The limit of servos per timer can be easily changed in the library, it's just a define somewhere.

Korman

3

How many servos are you going to run?
I run 18 servos off of my Mega.

4

18 at minimum, but 20 would be useful for mounting some head movement control, also, leaving some IO lines free would be good for other stuff like light control.

I'm using a Duemilanove, so I don't have the luxury (or the power overhead) of a mega's many many IO lines.

5

For more than 18 servos, a different option might be to use a separate servo controller, using the arduino for communication via serial.

http://forum.pololu.com/viewtopic.php?f=16&t=2380

6

I connected my ssc-32 servo controller to my arduino and it worked very well.

7

I would drive both a set of pins for timing, and a set of pins to control the bank of servos currently being sent timing information.

That's a clever approach to some situations, but I think it'll fail with servos: I could be wrong, but my understanding is that they won't hold their position if you don't feed them pulses continuously.

Pololu products have a great reputation. Another alternative that looks interesting (but one I haven't tried yet) is this chip. However, I have to add that I had some problems with their LCD interface board: it worked fine in async serial mode, but had "overrun" errors when used on I2C. I had to add delays in my software because it couldn't keep up with the higher data rate. There may or may not be similar problems with the Flexel chip (which looks like it might be the same MPU with somewhat-different firmware).