I’m currently developing an robot system which updates the SSC-32 through a class I have already developed. The group move command is used to update all servos at once, and the error occurs when one of the servos position is not changed.
For instance: #1P1500#2P1500S1000
Then : #1P1900#2P1500S1000
Will result in the #1 servo stuttering and taking for ever to get to its position, where as:
For instance: #1P1500#2P1500S1000
Then : #1P1900#2P1900S1000
Will work perfectly. Is this possibly an error in the group move timing? Or perhapse I have been silly in what I am passing to the SSC-32 in my code!
**Another possibility, the servos are rubbish and its an error due to them…? Tower Pro MG995 servos are being used…
Have you tried taking that servo that is jittering, and swaping it with a known good servo to see if the porblem follows? If the problem follows the servo on a different channel, then it could be a bad servo. This check will at least get you closer to an answer as to what is going on.
Isn’t the version 2 firmware on the new mega168 IC? It may be possible something was introduced with the change. I’d almost bet someone at lynxmotion will try it out next week and see if it is or is not an issue.
Ok, cheers for the feedback everyone, it seems that it might just be the useless servos I have. Im going to do the trajectory of each movment on the PC, continuously updating the position with small changes which seems to work a lot better with these cheap-o servos.
Group move is just a name we put on the “T” timed move. You are not using the group move. You are using the speed modifier. The group move relies on the T timed move command. So do this…
I would call this a group move, even though it doesn’t specify the T parameter. When multiple servo moves are issued in the same command, the SSC-32 will coordinate the moves by adjusting the speeds so they all finish together.
In this example, the S parameter applies only to servo #2, and specifies that the move should occur at a rate of 1000us/sec (i.e. it will take 1 second to change the pulse width by 1000us). All servo speeds in the move will be adjusted so they finish together.
In the first case the pulse width for servo #2 does not change, so servo #1 should move at top speed.
In the second case, servo #2 pulse width changes by 400us, so the total move should take 0.4sec. Since servo #1 is moving the same distance, it will move at the same speed as servo #2.
I have not seen any problems with this functionality–as somebody mentioned this has been well exercised over the past couple of years. This portion of the code did not change in the migration from ATmega8 to ATmega168. That doesn’t guarantee perfection (;-), but I am hopeful that the problem lies elsewhere.
Thanks for the clarification. You know I always thought group moves required the “T” command, but now I know it’s clearly not the case. Jesh, you think you know something…
Ive got the problem in group move. let say that the initial position for all of my servo is 1500. when i moved all my 18 servo to the new position(2000) with T1000, the servo didn’t reach new position in the same time? there is some servo that move very fast, faster than the other servo. or some time there a servo that reach the possition very late. what is the problems? is it because the ssc32 firmware?
