Servo speed problem in SES-arm

Lynxmotion Robot Arms
1

Hi everybody,

I am controlling my SES-arm via Matlab (serial port) and ran into a really strange problem.
The same command sometimes just seems to disregard the speed argument.

When I first do this:

comm('write', 2, '#1 P1000 #2 P1000 #3 P1450 S300' 13]);

it moves at the specified speed. Then I do some other movements and in the end, when I want to move back to this position and execute the exact same line of code again, the servos just move at maximal speed.

Does anybody have an idea as to why this could be happening?
Thanks very much!
Julia

2

My first reaction is the SSC-32 may be resetting. The first command received can’t use S or T parameters because the servo controller does not know where the servos shaft is pointing until after it has been initialized. Then the S and T commands are usable. So if the SSC-32 is powered off then on, or reset it will ignore the S or T command.

A reset can be caused if you are powering VS and VL from the same supply. If this isn’t it then it must be the program sending data to the SSC-32.

3

Hi,
Thanks for the quick answer!
It is not the first command since I already do a couple of movements where the speed works fine, before the one when it suddenly moves at maximal speed. It also should not be the power supply because I am powering the SSC-32 seperately with a fresh 9V-battery. Also I had problems with the power supply before but they only resulted in the robot going limp. This is not the case here and all commands after this too fast movement also work fine again. I also suspected the command to be wrong but as I mentioned earlier the exact same command works fine 3 movements earlier.
The board does not reset as far as I can tell (lamp only flashes briefly while receiving input)
I am really lost! Any more suggestions? Thanks a lot!
Julia

4

To completely eliminate the power reset issue… Are you sure the VS=VL jumper is removed?

Other than that. It has to be something dealing with how the commands are sent. The S and T commands are a very “core” feature, I’m quite sure it’s not the SSC-32. I mean there are no other complaints like this.

Beyond that, I got nothin… :frowning:

5

Hi again,
and thanks again for the quick help!
Yes the jumper is off. Too bad!
So the only possible explanation would be that the servos somehow “forgot” their current position right?
And that could only happen if the board reset or power goes down?
The lamp on the board would stay on though in case of an error or reset though, right?
Yeah, thanks again though! I’ll keep looking…
Julia

6

Just checking… I think the speed (S) command is per servo. Only the time (T) command affects all servos. So in your example, only servo #3 would ever move at the given speed. Servos #1 and #2 would always move at full speed. … I think. If so, then you probably want to do this:

comm('write', 2, '#1 P1000 S300 #2 P1000 S300 #3 P1450 S300' 13]);
7

This is a better manual.

lynxmotion.com/images/html/build136.htm

The speed command does indeed effect all servos in the group. You can’t set a different speed for each servo. There is a hierarchy of how the speed command works with the group of servos with or without the T command. It’s explained in the manual.

8

I’ve had the same issue in the past with a single servo. It got to be very fustrating. I was using Just Basic as the control program. It appears that the timed move part of the command is ignored or not processed. The ssc-32 isn’t resetting as the servo continues its move. Below is the post I made about the issue. In the origional setup I was reading the output voltage of the servo pot, but don’t see how that would affect the ssc-32 handling the timed command. I haven’t seen this issue yet in the bottom setup.

lynxmotion.net/phpbb/viewtopic.php?p=37648

lynxmotion.net/phpbb/viewtopic.php?t=4658

9

As mentioned in other posts, the S command applies to only one servo, but indirectly affects all servos in the move. On receiving the command above, the SSC-32 will first calculate how long it will take to move servo #3 to its new position at 300 microseconds/second; then it will move all 3 servos in that amount of time. If servo #3 has a long way to go, then the move will take a long time and servos #1 and #2 will move slowly; if servo #3 is near its final position, then the move will take a short time and servos #1 and #2 will move quickly.

If the S command is used on all of the servos, then the SSC-32 will pick the move that will take the most time, and then move all 3 servos in that amount of time. This is good if you want to limit the maximum speed of the servos, maybe to protect a linkage in your robot.

If a consistent and predictable move time is desired, use the T command instead of (or in addition to) the S command.

Mike

10

Thanks everybody,

Looks like the speed argument was really the problem. I thought it would just apply to all servos.
If it really calculates the speed of the remaining servos relative to calculated beginning and end of movement of the one for which the speed was specified, it makes perfect sense, that the speed is different depending on which position the move is started from.
So if I want to move every servo at the same speed I need to specify the speed for every single one individually, right?
Thanks again everybody!
Julia

11

I read the SSC-32 document again just now and I still don’t see things as described in this thread, at least not without some ambiguity. I was looking specifically at the section in the HTML link above with heading: “Servo move or Group Move”. It has table that lists parameters; the relevant ones being:

and then this text:

I understand that if a time parameter is given for the move, then all channels will start and end the move simultaneously with certain rules around what the speed param means in that case. I still don’t see anything in the docs that explains what happens when multiple speed params are given in a group move command without the time param though. Based on the params table, I assumed it worked as I described above. Perhaps I’m just missing it again though. Either way, it would be easy to test with an SSC-32.

Based on discussion above, yes, and you’d have to do it with three different position commands I guess. Something like this:

comm('write', 2, '#1 P1000 S300' 13]);
comm('write', 2, '#2 P1000 S300' 13]);
comm('write', 2, '#3 P1450 S300' 13]);

But that would mean the start of movements might not be synchronized exactly. I’m not sure of myself at this point though, and standard disclaimers apply about me being wrong as least as many times as I’m right.

12

The #1 rule in a group move command is that all servos start and stop together, so unless the servos are all moving the same amount they must move at different speeds. In general, it is not possible for the SSC-32 to honor the S and T commands in a group move command. It resolves the conflict by looking at the T command and all the S commands, and honoring the one that results in the longest move time. So the servo will never move faster than specified in the S command, but may move slower. Another way of looking at it is that the S command is considered to be the maximum speed.

If you really want multiple servos to move at the same speed, you will need separate commands as suggested by kaliatech. But in this case they will probably end their moves at different times. If, on the other hand, you want the servos to all take the same amount of time for the move, then use the T command in a group move.

I hope this explanation eliminates more confusion than it causes.

Mike

13

So I can make the manual more clear by putting an example in the group move that uses only the S modifier in addition to the T modifier example.

Any move with more than one servo involved and using either the S or T modifier is considered a group move and all servos involved will start and stop at the same time.

I will also add text explaining the only method to have servos move at the same speed is to do them in separate commands. That’s how I thought it was done, but I don’t use the S modifier much. So thanks for the clarification Mike!