Xan and Mike D. were working on making some changes to the SSC-32 GP firmware to enable faster binary communications. We tried to hold off on releasing this for Xan to finish his terrain adaption code, but he’s not had time for robotics in a long time. I finally decided we must release it. I will post here with all of the information. The actual file will be attached in this thread.
Here is the firmware file, and a simple bas program to test it.
I will be adding information on how it works today.
test.bas (3 KB)
SSC32-V2.05Alpha3A-EGP.abl (43.2 KB)
Here is the information for the extended binary group move and stop commands. There is also a simple Basic Atom program that demonstrates the use of the extended binary commands. It’s compiled from some emails from Mike.
The STOP all command. Just type “STOP” and it will stop all moving servos where they are.
The new commands are binary 128-159, 160, 161, and 162.
0x80 - 0x9F are the pulse width commands, and specify a servo number 0-31 (0x80=servo0, 0x81=servo1, etc.). The next 2 bytes must be the desired pulse width in microseconds, MSB first.
0xA0 is the optional speed command for a servo. It must immediately follow the pulse width command for the servo, and the next 2 bytes must be the max speed in microseconds/second.
0xA1 is the move time. It is required for a group move, and the move will not begin until the move time is received. The next 2 bytes must be the move time in milliseconds. If you want the move to be as fast as possible, just specify a move time of 0.
0xA2 is the stop all command, which immediately stops all servos where they are. It does not require any additional bytes.
As an example, the group move "#0P1000 #1P1500S1000 #3P2000 T1000 " is equivalent to the following (hex) bytes in an extended binary command:
[code]80 03 E8 81 05 DC A0 03 E8 83 07 D0 A1 03 E8
#0P1000 #1P1500 S1000 #3P2000 T1000[/code]
Here is the information for the binary query command. We don’t have a Basic Atom program yet.
The binary query command is 5 bytes. The servos are specified using a bitmap, with each servo being represented by a bit. The 5 bytes are
- byte 1 = command byte, and servos 0-3
- byte 2 = servos 4-10
- byte 3 = servos 11-17
- byte 4 = servos 18-24
- byte 5 = servos 25-31
In more detail:
- byte 1 = (binary) 1 0 1 1 s3 s2 s1 s0
- byte 2 = (binary) 0 s10 s9 s8 s7 s6 s5 s4
- byte 3 = (binary) 0 s17 s16 s15 s14 s13 s12 s11
- byte 4 = (binary) 0 s24 s23 s22 s21 s20 s19 s18
- byte 5 = (binary) 0 s31 s30 s29 s28 s27 s26 s25
The numbers s0 through s31 represent servos 0-31. A 1 bit requests the value for the servo.
Byte 1 starts with bits 1011, or 0xB, which is the start of binary query commands. The other bytes all start with a 0 bit.
So, for example, to query servos 0, 3, 4, 12, 21, and 31, you would use the following bytes:
10111001 = 0xB9
00000001 = 0x01
00000010 = 0x02
00001000 = 0x08
01000000 = 0x40
serout p0,i38400,[0xB9,0x01,0x02,0x08,0x40]
The result of this command will be 12 bytes, 2 bytes per servo requested. They will be in order starting with S0 through S31. There is no prefix byte or anything.
You can request any number of servos, and it will take 5 bytes to make the request regardless of the number of servos requested. The number of bytes returned will be 2x the number of servos requested. Servo pulse widths are returned most significant byte first.
The SSC-32 will send the servos as fast as it can, honoring the delay and pacing values that have been set.
WARNING: After sending a query command, do not send any other commands until all of the servo pulse widths have been received back from the SSC-32. If you do, this may corrupt the servo pulse widths being sent, and you might get some garbage values.
Try it out and let us know how it works.
The following is a note from Mike,
A quick note on the WARNING in my last email. I realized that I have a way to remove that restriction, and will implement it in the next release. The SSC-32 might delay processing of an incoming command, but it will not corrupt the outgoing message.
This restriction is based on the size of the transmit buffer for the serial port. It is 32 bytes, which has been fine so far, but is not adequate to buffer the position of more than 16 servos. I am out of RAM in the SSC-32, so I had to use a command processing buffer to hold the overflow. This works fine, as long as the SSC-32 doesn’t try to process any commands while the buffer is being used to hold the query result.
What I will do in the next release is inhibit command processing whenever the command buffer holds overflow bytes. There is a 128 byte receive queue that will hold incoming characters until the command buffer is available. The command buffer becomes available as soon as there are 16 or fewer servo positions to send. So if you request 18 servos, the command buffer will become available after the first 2 servo positions are sent.
Mike
So that’s a binary message format for the SSC-32 commands?
Any new commands?
How about a checksum?
Neat!
Alan KM6VV
The new command is STOP,cr. to stop all servos. The rest is a much faster way to communicate with the SSC-32. I believe the old MiniSSC-32 emulation is gone, but the rest of the old commands are still there.
Are there still separate builds for GP and 12-servo hexapod (XE)?
STOP is good.
Alan KM6VV
The ascii versions are still there… But this firmware is based on the GP firmware. There will not be a binary version of the 12-servo hexapod version. Don’t think there needs to be. The GP version is the most capable and popular for advanced 3DOF hexapod builders.
Is the individual servo stop command still there?
Looks great, I will start experimenting with my version of the Phoenix2 code… It will be interesting to see how well it works and how much time we save on reducing the number of characters transmitted.
Kurt
Don’t really need a binary com for the 12-servo XE build, just the GP
I agree.
Alan KM6VV
Just an FYI - I hacked up my phoenix code (CHR-3) that I have converted to using the XBEE DIY remote control. I hacked up both versions of the servo output function (one that uses the TASerout function to try to output at full speed 115200) and one that uses the standard serout at 38400. I have not done much testing yet, but some moves appeared to work OK but part of the time 1 or more legs did not appear to work right. I did upload the file I changed under the XBEE DIY remote control thread as there is a zip file up on that thread with all of the code…
Maybe a checksum would help validate things. But also need to make sure yet if it is my code or problem in SSC. So I will now try again at slower output speed… May need to hook up logic Analyzer to verify what is output…
Kurt
Quick update: I hooked up the logic analyzer, found my 
bugs and updated and both methods appear to be working. But looking at the logic trace, I think I can speed up the use of my serial output functions by removing function calls and the like so we can speed up the output time… This is shown in the logic trace below…
In this trace you can see the output of two servos with a gap of time between the two outputs.
I updated the code in my other thread, but will now do some minor surgery and see if it can be sped up… Note Zenta I have not updated the wait timings here…
Kurt
Hi,
I know I’m asking for to much here… (An way to early… 
) But do you think the Visual Sequencer (or the RIOS) software will ever support the new binary format?
Nah, not too much. Yes I think we will add it. It needs to be tested and finalized. But then it’s no problem.
Sounds great!
Jim did a pretty good job of summarizing the new binary commands. There was a question on whether the individual servo STOP command is supported, and it is exactly as before.
This is a work in progress, so I am open to suggestions on enhancements (but I would resist a major rewrite at this point unless there was a very compelling reason). A checksum, or even full CRC, would be a possibility if people feel it would be a worthwhile enhancement. It would of course be additional data sent, and additional computation on the part of the message sender.
The binary commands and ASCII commands coexist, so you can use either command format to send a group move or query pulse widths. I could create binary versions of other commands as well, but I thought the group move and query commands were the most important to start with. Group move is pretty verbose in the ASCII format, and it is used a lot. The query command is also pretty verbose when used with a lot of servos, and it was one that Xan needed to be fast. I am not currently planning to create binary versions of all of the commands–I see these as fast shortcuts for some commonly used commands that are verbose in ASCII format. But like I said, I am open to suggestions.
Mike
Hi Mike,
Great work. Not sure yet if the checksum would help or not. As you said it would add extra overhead. However if an IO line is not overly robust it could help in those cases.
It was pretty easy to make changes in Xan’s code to integrate the new outputs, which should help out a lot. In addition to this, It would be great to run the SSC-32 at full speed 115200, so I merged in my own serial output/input functions and have the phoenix code running at that speed as well. We should be able to simply call serout with the baud set to i115200, …, but it was not working for me, so I put my logic analyzer on it and found that software appears to be outputting at closer to 125000. I notified Nathan (AcidTech) and provided him with the logic trace, so hopefully that will be fixed.
Have not tried the query or the new stop yet . It will be fun to experiment with these as well as other techniques for Terrain adaptation.
Again great work!
Kurt
I like CRCs, but they would take some time to compute. PS2 commands are using a simple checksum, which is fast to calculate.
Alan KM6VV
Kurt,
I am going to be sending you a complete T-Hex with 3DOF legs and ground contact sensors on the feet for testing. I’m planning to send the same thing to Xan if he gets more robot time. Zenta will be getting a set of ground contact sensors as well! I’m still waiting for a couple things, but very soon. 2010 is the year we close the loop on leg sensors! 8)
This sounds great 
. Can not wait to start playing!
Kurt