Is there any reason NOT to upgrade the SSC-32 to the 1.06XE version?
Is this the function of the File field in the SEQ Firmware dialog?
I am seeing something kind of odd and have not been able to pinpoint wether it is the SSC-32, SEQ, or the servo.
The problem is a servo moves much slower than it is supposed to when a group move command is sent. As you can imagine this makes getting a walk sequence down pretty damn difficult. I’ve seen it happen on a knee and an ankle joint at this point, although not at the same time. If I drag a slider the servo tracks fine (in either LynxTerm or the SEQ). When a servo is moving slow though it “feels” like it’s jumping from position to position very slowly, and it does eventually get to the destination position after a few seconds. Mechanicaly there does not appear to be any binding or gear drag that feels different than any other servo. I am using the PO command (via a macro in LynxTerm) to make everything line up when set all 1.5ms is sent.
So, I can’t see anything I am doing wrong yet and hence my question about upgrading the firmware from the SSC32-1.03XE that came installed on the board.
I cant answer if it will fix your problem or not. I didn’t see any ill effects when I did it. I am still learning on the programming side. As the robotic stuff is new to me. I am starting to wonder if I am breaking things down to much.
Is it possible that you’re misunderstanding how the group moves work?
When you say that the servo is moving “slower than it’s supposed to”, do you mean that it’s moving slower than your speed command tells it to?
In case you aren’t aware:
The group move makes all servos start and stop at the same time, no matter how much distance each servo must move.
And, this goal of same start and stop time takes priority over any individual speed commands of the servos.
So, if your “problem” servos are stopping and starting with your other servos, then it’s working as intended.
If, however, your “problem” servos are stopping well after the other servos, then you indeed have something to worry about.
Oh, btw, I think that the changes of the most recent SSC-32 update was only to allow proper data rates for the ABB and to add in a PO command.
I may be wrong, but it seems a bit farfetched to think that either of those are causing your problem.
It doesn’t seem to matter if the SEQ issues the command or it is sent by a macro in LynxTerm. I have seen it happen on two different servos in different sessions.
The PO command appears to have been added in the 1.03 version. There is a vague reference to fixing a PO bug in the 1.06 description. The open source page only seems to have the 1.03 firmware source so, unless it’s documented in a thread here somewhere, I don’t see any way to know what the PO bug was that got fixed.
I guess I’ll just upload it and see if anything changes. Is uploading done with the Firmware button in the SEQ, or is there some other, better way to do it?
I would suspect there might be a power supply issue. If the servos are told to move as a “group”, then this might place too much load on the power supply at one time. Monitoring the voltage on the power supply when a group command is issued might be worth while.
Tried it. I have brand new 1600mAH packs from lynxmotion, fully charged on Friday, and connected to the BRAT with their switch harness. Even still, if the firmware upgrade doesn’t fix it I’ll wire up a DVM and see if maybe there is something up with the pack. Unlikely, and the way the servos move it doesn’t even seem like a power issue since using the all 1.5ms button they all snap back to 0, but you never know until you check it.
I don’t know what type of robot you have, but you might try suspending/supporting the robot such that there is minimum load on the servos and see if you still get the slow movement. If it is still slow, then the servo may be getting some type of slow move command (if such exist). If the movement is as expected when suspended/supported, then I would suspect either a power issue or a mechanical binding issue. Binding in itself can result in the power issue when the binding servo pulls excessive current.
Alright, at the moment it looks like I answered my own question. I downloaded the 1.06 firmware into the SSC-32 and the sluggish servo thing seems to be gone.
It also now appears that I need to adjust my walk routine because he’s draggin his heels when he steps.
Interesting oservation, using the Firmware button in the SEQ I could not get it to program the SSC-32 correctly. Hardwired it worked fine the 1st time. My guess is there is some sort of handshake relationship, in particular I never saw the “erasing” string displayed, that can’t handle the couple of mS lag you get through the WLAN connection.
Glad to here you got it working. I thought the same thing Nick mentioned at first, that the group move makes the all servos stop at the same time regardless of the distance traveled for ech servo, which would make some servos move much slower to allow the servos that have longer distances to travel end at the same time.
I’ll bet I will have a lot of questions when I get around to getting the SSC-32. Its a powerful controller.
Mike,
The problem was pretty obvious because at the end of my sequence the legs are returning to home position and the only servos moving “should” have been the left hip and knee. The ankle however was still moving from the previous group move command, and continued to move towards 0 position (1.5ms) even after the current group had completed.
zoomkat, it the SEQ was the only program I had used with the WLAN connection at this point then I might be inclined to think that way. However it is one of about 6 different programs I have experimented with through the WiPort at this time, all at 115.2KBaud, and it is the ONLY one to have presented an issue, and only for this single function. Everything else has been working great. It might STILL be the WLAN/WiPort, but statistically the data suggests otherwise at this time. Thank you.
Yes you found the position offset bug. Weird because I never did see the bug. But anyway yes the 1.06 firmware is bug free! I assume the firmware update feature would need a longer timout in order to be used with the wifi connection. Sorry you had to figure this out the hard way. We are currently shipping the 1.06 version, but there are a lot of the 1.03 ones out there.
Any chance of getting the 1.06 firmware source added to the open source page for reference? The revision comments in the headers likely would have let us nail this down much faster.
Thanks.
EB
:mrgreen:
I will ask Mike to make this information available. He has very limited time right now. And he is currently working on the new version of the general purpose sequencer firmware. This will replace the 12 servo hexapod sequencer part of the SSC-32 controller with a configurable (actually 4) sequencer engines. Each engine can be started, stopped, played in forward, or reverse, etc. Note this is not going to effect the normal SSC-32’s servo controlling job, just the built in sequencer engine.
Weird because I never did see the bug. But anyway yes the 1.06 firmware is bug free! 
I assume the firmware update feature would need a longer timout in order to be used with the wifi connection. Sorry you had to figure this out the hard way. We are currently shipping the 1.06 version, but there are a lot of the 1.03 ones out there.