DIY servo controller

[javafiend]

How would you make a servo controller similar in function to the SSC-32?  It seems like the $50 board is sorta along those lines except for the built in RS232 connection.

As a side question, on the SSC-32 are the servo connections considered ports or pins?

[ArcMan]

http://www.societyofrobots.com/robotforum/index.php?topic=5535.0

[javafiend]

So are you saying that it is the software and not the hardware that separates the $50 board from a SSC-32?  What about the hardware?  Is every pin dedicated to one servo with regulated or unregulated power?

[ArcMan]

A typical servo driver has a micro driving the servo signal pins with digital outputs.  The servo power pins are connected so that you can supply the servos with a voltage source external to the servo driver.  When you're driving several of servos, the board's regulated power source doesn't go very far.  Normally, one would connect a 6V battery source up to the board's servo power input.

[javafiend]

I apologize for revisiting this after 4 months, but I really didn't see any point in starting a new topic.  It's really just taken me this long to digest the information.

If I am understanding right, any of the pins, except the VCC, GND, AREF, and RESET can be used to control a servo on an appropriate voltage source, correct?  At least that is how I am reading the diagram.  So if you needed to connect sensors or anything that needed a separate voltage from the servos, and assuming all of the pins were full, you would need a separate MCU board, correct?  Which would mean that for the two boards to communicate, then the TX and RX pins would need to be utilized... I think.

Wow, this stuff is complicated.  I'm glad you guys understand it.

[Ro-Bot-X]

I have studied SSC-32 and it uses serial multiplexors to drive the servos, using SPI bus. So, SSC-32 differs by both hardware and software from $50 robot board or Roboduino for that matter.

Directly connected to ATmega168, you can use maximum 21 servos (keeping 2 serial pins free for communication). But there is no more room for sensors, so you need a second microcontroller to read the sensors. I would go for a microcontroller upgrade and use a 40 pin microcontroller (ATmega32 or better ATmega644). Funny thing is I have a mega32 on a development board laying around and haven't used is because it lacks nearby power busses. I guess I shoul build a shield for it, but I'm too lazy...

[javafiend]

That makes a lot of sense going with a microcontroller upgrade.  It's one I have never really considered, but makes a lot of sense.  Especially when I have no clue what a multiplexor or SPI bus is.

[Webbot]

Javafiend sorry if I'm stating the obvious  - You just need to be careful how you write your code if you are driving loads of servos.

The typical (ie simple) code says:

Set pin high
pause (between 1ms and 2ms) to change the servo angle/speed
Set pin low
pause for 20ms (since servos only expect one pulse every 20ms)

The 'problem' is that the pauses are not interrupt driven (ie they just sit there wasting time). If you only have a few servos then its ok. But if you have 20 servos it becomes an issue as each servo then only gets a pulse every 20 x 20ms = 400ms which means it will be very jerky. So rather than using this round robin approach you have to write a more sophisticated program to try to issue pulses simultaneously - which involves using timers/interrupts. If you are happy knowing how to do that - then great. But a controller upgrade to Mega32 wont help you with the software (as it is a servo timing issue made worse as the number of servos increases) - it will just give you more IO pins for more servos.

[Admin]

Javafiend sorry if I'm stating the obvious  - You just need to be careful how you write your code if you are driving loads of servos.

The typical (ie simple) code says:

Set pin high
pause (between 1ms and 2ms) to change the servo angle/speed
Set pin low
pause for 20ms (since servos only expect one pulse every 20ms)

The 'problem' is that the pauses are not interrupt driven (ie they just sit there wasting time). If you only have a few servos then its ok. But if you have 20 servos it becomes an issue as each servo then only gets a pulse every 20 x 20ms = 400ms which means it will be very jerky. So rather than using this round robin approach you have to write a more sophisticated program to try to issue pulses simultaneously - which involves using timers/interrupts. If you are happy knowing how to do that - then great. But a controller upgrade to Mega32 wont help you with the software (as it is a servo timing issue made worse as the number of servos increases) - it will just give you more IO pins for more servos.

Although mostly right, not entirely . . . the math is 1.5ms * 20, or 30ms

You don't need to delay 20ms after each servo . . . so if say you have 20 servos, on average 30ms will pass between the first and second pulse sent to that servo. The real issue is when you have this 30ms delay, plus another 100ms for other code to run (trig functions, camera vision, etc).

Thats when the servos can get a bit jerky. Using the interrupt or PWM method, your 100ms of code won't affect the servos. But all methods have their flaws . . .

[izua]

you can also configure a cpld or fpga to work as a high resolution multi-pwm generator. and you basically offload the software generator to dedicated hardware.