The SSC-32 manual says you can’t issue a command with speed or time argument as the first command.
I can understand the technical reason behind this, but is there a way to avoid the servos jumping all over the place when i issue the first commands?
I think the only possible way would be to send just a few of the 20 mS pulses, wait 100 mS or so, then send a few more pulses, etc. Repeat the process long enough to allow the servo to move most or all of a complete 180 turn.
This may have the effect of allowing the servo to seek ‘slowly’ without the controller needing to know how far the servo needs to move.
A similar way might be to modulate the power going to the servo, so that before it has time to go too far too fast, it loses power.
Pete
Sorry for the dumb question, but with what command can i send just a few of the 20ms pulses ?
Um, that’s a good question - I don’t know how to do it without modifying the SSC-32 firmware.
The second approach (cycling the power to the servos, but leave the SSC-32 powered up) would be much easier overall.
Note that it’s really handy in general to have a way to power-down the servos, so that when your bot is ‘resting’ or charging it’s batteries, it isn’t burning a lot of juice keeping the servos alive. I will be doing this with my quad, using a FET switch to control servo power, and possibly another FET switch to power down the ‘optional’ electronics, such as the SSC-32 and some sensor hardware. There are times when only the brain needs to be alive - my brain uses 25 mA at 5 V, but I don’t know how that compares to other CPUs.
Although I’ve never used one, I suspect that an SN754410 “H-bridge” motor controller chip would be an easy device to use for the switching (But check the current ratings! I think it’s only about 1 amp continuous.) You could also use a generic MOSFET, and be able to control many amps of current, but driving the gate of the MOSFET requires a bit of electronics work. If interested, I can elaborate. My brain-board has SI4966 FET switches on it - they are tiny little surface-mount chips, but are rated for up to 7 amps(!). They can manage this because their “RDSon” parameter is only 0.025 ohms…
Pete
I think i found another option:
I will define a “resting stance” for my robot, before i power up the robot i will make sure that the servo’s are positioned in the robot’s resting stance. This stance is usually a stance which doesn’t require servo power to maintain. I assume if you would power off a hexapod it would automatically go into it’s “resting stance” due to gravity 
On power up i will instruct every servo 1 by one to move into its resting position. As that should be really close to it’s physical position there shouldn’t be too much jumping around of servos.
When i stop my robot program, i will return it into it’s “resting stance” before powering off.
All of the comments below refer to analog servos.
The servos will flail wildly when you first apply power without also providing the pulses. They will go CCW when this happens. This behavior can easily be replaced by a sudden jump to position by just sending the pulses right after powerup. The best way to avoid the “long jump” to position is to make sure the assembly is as close to the desired startup position when you start everything up.
The flailing with power only (no pulses) can be eliminated by gradually applying power, but most robot electronics don’t have the ability to do this. It would require some sort of an adjustable regulator and a control input to allow the voltage to gradually increase till it is at VS. There may still be a bit of a nudge when the pulses are then sent. But it should be much better.
The gradual pulse spacing idea will not work. Pulses spaced too far apart are ignored, till they arive close enough to make the servo actually move, and it will stutter. This is pretty ugly too. 
I can’t speak directly to the SSC32, but I have eliminated any power on jumping by powering the servos after already having the signal line held low. If the SSC32 has a power up delay where the signal lines are floating, this may be causing it. Perhaps a firmware that pulls them low as early as possible would help.
Interesting… I never though about that, but it makes sense. I always assumed it was the control circuit just settling… However I just tested it and it does work. I will see if it is possible to have the firmware set the outputs to low instead of floating on powerup. 
Just when you think you know everything about something. 
Thanks Andy!
glad to help!
I did some further testing with the SSC-32. If you power on the electronics (VL) first, then the servos (VS) there is no jump. The SSC-32 outputs can’t float, they are either a high or a low. Doh! So no firmware change needs to take place. Just a mindset change.
I wasn’t referring to the jump on powerup, but rather to the jump which occurs on the first SSC-32 command you send to it. As is stated in the manual you can’t add a Time or Speed argument to the first command as the controller doesn’t know the servo’s actual position yet.
EDIT: Oops, you were replying about the jump on powerup 