You can use the “Q” command with the SSC-32 to tell when a servo move has completed. Use the group move feature to move servos together. Use the T (time) command in a servo move to control how long it takes for the complete move, and the S (speed) command to control the speed of the move.
You should always have the electronics on a separate battery from the servos.
8-Dale
Hi Linuxguy
Was just composing a response to tillin when you posted.
It sounds like we have similar goals. I intend to P.C. control for a while but eventually implement a controller.
Perhaps something from rabbitsemiconductor which seems to have several UARTS implemented for a reasonable price…
If the source code for SSC is open source, might it be possible to implement a feedback mechanism?
Greetings, and welcome to the forums!
With the source, you have the power to create whatever you want, but I believe the SSC-32 already has the features you need. You just have to get a little creative in how you use them. 
I have posted my current Python code for the SSC-32 here somewhere and I am about to test it under Windows. 
I already tested it under Linux and FreeBSD, and only one line of code had to be changed to switch the software to a different OS.
8-Dale
The goal of the SSC-32 was to use an inexpensive atmel processor and shift registers to make a powerful servo controller for standard hobby servos. It has been a monumental sucess. However using shift registers in the outputs prevents getting data back from any servo whether it has feedback or not. In other words the hardware limits it to send only, no receive. No firmware will change this limitation. We hope to have an SSC-24 soon that will allow bidirectional communications with the attached servos. It will be open source as well, but it’s going to be a while for that one though.
Thanks for the Greeting, always a nice gesture.
I agree the SSC fits the bill better than anything else i’ve come across so far…
I’ll get an order sorted tomorrow and call my local supplier.
Gotta be a good move…
Hi Robotdude
From what LinuxGuy was saying, I can just query the SSC.
The Kondo servo’s suffer problems when you query them while in motion. If you do, then they stop moving momentarily to PWM the position back and this causes Jerky motion. It should be enough to Query the SCC and if it says it has finished the move then accept that as completed.
If the servo hasnt finished moving and the SSC has then there is a serious hardware failure anyway that no method of response is going to solve.
You can, but all you will get back is either the position of a servo that the SSC-32 has stored (current position), or the finished/not finished status of a servo move. You won’t get any data back direct from a servo.
Now, there is a servo modification called Open Servo, that can be controlled via i2c or standard R/C style PWM (like what we use to control the SSC-32) signals. With Open Servo, you can get direct feedback from a servo. This is also Open Source (hardware and software) where the new board replaces the electronics in an existing servo. I have two robot projects (Mega Scout and Walk 'N Roll) which I would love to use Open Servos in.
8-Dale
finished/not finished is perfect. It will let me know that I can move on knowing that the robot should be in a reasonably predictable state…
Hi Paul,
Yes the SSC-32 has two query commands for servo motion/position.
Q will return a “.” if the move is complete, or a “+” if the move is in progress.
QP will return a single byte indicating the servo position (10uS resolution) of the current commanded position. Note this will provide the position along the path if it is requested of a servo that is in motion. Multiple servos can be queried in the same command.
Linuxguy is incorrect in his comments that you can only get the stored (current position). This implies that only the destination position can be returned.
Oh, that’s right! I forgot that QP will return the current position of the servo if it is still moving. Sorry about that!
8-Dale
Thanks Robot Dude
Thats ideal for what I need…
Now to try and be patient until I get one delivered.
Sorry bout that. When I think interactive, I think both parties making active decisions. For example A sending data a and b, then B responding with choices a and d then A picking d. Generally such protocols have windows where if a decision isn’t made within a certain window, a default will be used or the command buffer will be cleared. The SCC-32 doesn’t do this. Nor does it by default give an output when a command is completed. However, since you can poll it many times in the time it takes for a servo to move, you can back out the behavior you want. I never really needed this as I was planning on having sensors on my micro to do do interrupts, and recording the time I tell for the move, etc. Nice to know. Its also nice to know that QP can recall the current position of the servo while moving, which is great if your micro senses a timeout and the servo is not yet where it should be (i.e. it encountered an obstruction).
Also, sorry I misjudged the issue. If the controller doesn’t have an UART, I can see how even small bluetooth hickups will cause dropped commands.
I don’t think this is quite accurate. I think the ssc-32 can only report what has been sent to the servo, and not the actual servo position. The ssc-32 probably can’t even tell if a servo is actually connected to it.
Robot Dude, who I assume from his sig, has something to do with LynxMotion confirmed that even if the servo has failed or is not even connected, the actual routine will be able to report how far it has progressed.
As to reporting the actual physical position, I’ve seen even the best of detection circuits fooled by the simplest of failures.
For what I want to achieve, knowing that the current routine has or hasn’t yet completed will be enough to signal that I can or can’t send the next routine. I suppose it equates to CTS and RTS…
It’s in the manual. If it isn’t there, please show me. The QP command reports the current position of the servo, whether it is moving or stationary.
8-Dale
well since the servos operate open loop what the ssc-32 is most likely returning is where it is telling the servo to be at a particular point in time, which with an r/c servo is all you can ever know without hacking the feedback pot in the servo or adding external position sensing. 
Received my board this morning.
Its a bit bigger but it does fit without looking too out of place.
All connected up and ready to go. BlueSmirf working perfectly so far, just have to remember that it doesnt auto-reconnect although so far its working fine without going into fast mode.
Quite a relief to remove all the voltage inverting and levelling required for the Kondo RCB Board…
Now to tackle the Sequencer. Got the Home position about sorted already, just needs fine adjustment of that.
All in all, so far spectacular product…
Managed to write a convertor to port the RCB movement files from the KHR to SSC and import them.
After several attempts, realised that although Kondo gratiously provide the ratio of degrees to steps, they overlloked informing us that these are not relative to 0 but to the angle at which it is constructed in their setup software…
Basically some angles had to be halved and some quartered…
So now I have an SSC powered bot that can do its original tricks and whatever new ones I have the patience (intelligence???) to teach it.
Now part 2 and 3
Part 2 is I want to be able to control it from my XDA (I think its a Jasjar in the states)
Part 3 is I want some brains on board. I’m looking mostly at the Rabbit boards but I’ve also seen some good write-ups about Stamps. I’m in foreign territory now so…
Excellent work!
Does the XDA have Bluetooth capability?
I would go with a Basic Atom or Atom PRO on a Mini Atom Bot Board. Those are all sold by Lynxmotion. I started out with the Mini Atom Bot Board and a Basic Atom and am now ready to move up to an Atom PRO which has more memory (doube that of the Basic Atom), is faster, and has hardware support for more functions like serial I/O and such. I ran out of memory on the Basic Atom.
8-Dale
The XDA has bluetooth and it recognises and connects the BlueSmirf as a serial port service. I wrote some code for the KHR RCB and got that working but because of the timing issues on the RCB I had to send the commands at time intervals rather than wait for a reply… Very hit and miss…
I know its feasible its just a matter of deciding how I’m going to implement it.
I was thinking along the lines of designing routines with SEQ and using the XDA to stream them rather than try and design on it. Its an amazing toy but its useability is limited. Lots of keys and the screens too small but it would be ideal as a remote control.
As to the Stamps, I was hoping to find something with 2 or more serial ports (one to the SSC and one to the BlueSmirf), like the Rabbits where I can program in-situ rather than having to remove the SBC each time to alter the code. I think its called In System Programming or ISP…
rabbitsemiconductor.com/prod … ndex.shtml
This is the one I think I most favour but not found anyone yet who’s used one.
Just remembered what part 4 was… Little Grippers on both hands…
Might do that first actually as been doing a lot of coding recently both at work and at home (unfortunately both the same place)
