Smooth Connection of Group Moves with SSC over PC

Hey everybody!

I just started with programming the SSC 32 for my newly build hexapod.

As I am programming the movements, I stumbled across one problem:

I want to connect two group moves after another, but have issues with the smoothness. The question is, how do I know when to fire the next movement command exactly, so there is no delay between the two moves. If I fire the second command too early, the servos beginn to stutter. So I figured two ways, how to avoid this, but I am not 100% satisfied.

(I am programming over Serial Cable with VB6 right now)

First approach: Fire the first command and check in a loop with "Q " for the move to complete, then fire the second. The problem: Sometimes there is a small delay between the “real finish” and the “.” that is feed back. It is around 10-100 milisecs, with sometimes makes the moving seem a little bit awkward.

Second approach: Fire the first command, then check in a loop for the given time to elapse and then - without checking for the “.” feedback - firing the second command. But this is also not 100% perfect…

So how did you solve this problem? (If at all…) Which approach is best from your experience?

Is there a way, to queue Commands within the SSC 32, for seemless movements?

I am looking forward for any answers!

I’m asking Mike to verify my reply. The manual states the delay associated with the query command is between 50uS and 5mS, not the 10-100mS you are seeing. It’s possible that VB6 program is adding additional delay. What baud rate are you using to communicate with the SSC-32? If you changed it to a lower setting such as 9600 baud that could be adding additional delay. Use 115.2k baud if possible.

Note that the ssc-32 does not actually know where the servo is. It only knows if the command has been sent to the servo. Are you using timed or speed commands for the servos? If so, you may want to look at querying the pulse width of selected servos (Q) to see if the selected servo has been sent its final position command. Since you are using VB6, windows timing itself may be an issue. From what I’ve heard, windows normal timing resolution is limited to ~1ms, with 10ms being the lower practical limit.

The Group Move works the same as far as ensuring the servos start and end motion at the same time for Speed or Timed moves. The Q command should do nicely for either of these methods.

Hi again and thanks for the quick answers!

I’m using the full bandwidth (115K), so i guess, this is not the problem.

I am ordering the servo to its place via Timed Commands. I ran the whole sequence several times through, with always the same start position (no reset in between). Probably the unregular(!) delays really come from VB. I guess I’ll stick to C++ in near future.

But I’m still curious, how you implement this issue in your algorithms! Would be great to get some ideas!

Do you interpolate the steps between start and end of a sequence in regular steps or do you send new commands at angular points, where an angle stops increasing/decreasing and goes back? (Hope you know what I mean …)

So long

Do you sometimes have a servo immediately move to the final position instead of making the move gradually?

Hmm, not that i can remember, no!

Sometimes, it seems, that the “.” feedback is send too early.
I had some testing code, that looked like this Pseudocode:

"#8 P2000 T500 "
do
"Q "
loop until RESPONSE = “.”
"#8 P1000 T500 "

Sometimes it even doesn’t completely move to Position 2000 and already begins moving to Position 500 …

Would be the case for the first move, sure. But not if I initially moved the servo before. And in between there hasn’t been a reset.

I assume we are referring to an arm or some other multi axis assembly. If you want to do a straight line interpolation you send the commands using the T command modifier. As the assembly is in motion but before it reaches it’s destination, you send a new updated destination. It’s what we do with RIOS for our arms, and it’s what we do with the Basic Atom for 3DOF legs.

Furthermore it’s easy to use a standard T value and update the destinations with a value slightly smaller than the T value.

You may want to check your cpu useage while running your do loop. If it is at 100%, then you may need to put something like a 10ms delay/wait in it to have better control of the querys and allow windows to catch its breath. Are you using V1 or V2 of the ssc-32 firmware? I’m currently having issues with simple repeated timed commands being consistantly run. In about 20% of the timed commands the servo just goes directly to the final position instead of a timed movement. Still looking at this to see if it may be a problem with the program I made.

Zoomy, please post here. Mike will be looking at it later. I doubt very much there are issues with this in either version. That part of the code was not altered with the V2 168 port. And no one has reported any sort of issues like you are talking about. :wink:

I’ll start a seperate thread on my timing issue as the problems maybe totally different.