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)
I am not familiar with the KHR and how it works, so am not going to be any real help there. What kind of timing issues are there? This seems really unusable if there are timing issues that prevent commands from being received.
Have you tried connecting with the KHR from a different Bluetooth device to see if there are still timing issues? It’s important to first figure out which end of the link is having the timing problems and then it should be easier to fix.
SEQ can create code for the Basic Atom, but you load that into the Basic Atom microcontroller. There is a fellow here named kurte who is creating a Visual Basic program to send command sequences to a robot (a BRAT in this case), but that should be workable for any type of robot. He has had success in sending command sequences to the robot and having the robot store and execute them. This sounds like the type of thing you want to do also.
With the Basic Atom or Atom PRO, you can do serial I/O on any pair of I/O pins. The Atom PRO has hardware serial I/O and servo control support, has twice the memory, and is much faster than the Basic Atom.
I have a robot design I call Walk 'N Roll that is an Octapod with four independently steerable and retractable wheels. This robot will have little grippers (or some kind of gripper) at the ends of its two front legs. 
Right now, I am in the process of building Mega Scout though.
8-Dale
The serial timing issues are all sorted as far as they can be. Its simply that KHR didnt envisage using BlueTooth and consequently it doesn’t work. Thats been my main drive for buying the SSC.
As to other projects, one thing I do intend to do at some point is to sue the servo’s etc from the bot to make a crawler of some sort. I’ll have to sneak those plans past the wife though
Hmmm, the SSC-32 can control up to 32 servos, and it has some analog and digital I/O capability also. If you don’t have a lot of senors on the KHR, you might be able to plug them into the SSC-32 also and read them that way. I say this because I am thinking you might be able to make better use of Bluetooth with it connected directly to the SSC-32. It’s a possibility, but I don’t know how well it would work for your KHR.
8-Dale
Sensors… Now there’s a whole nest of possibilities.
I’m just getting to master the bot let alone making it aware of its surroundings.
That bit is where the really impressive stuff comes in…
Ah yes! My WALTER has three different types of sensors now - IR Ranging, Ultrasonic Ranging, and IR Proximity Detector. For quite awhile, I just had the IRPD so mastered how to use it before I added anything new.
A robot without at least one sensor is pretty boring though. It has no way to tell if something is in its way or around it. I did pretty good with the IRPD as the only sensor for sometime.
8-Dale
I thought about Gyro’s first, mainly to overcome my inability to keep it on its feet but then I thought if I implement them badly too it will just compound by bad walking… Best learn to make it walk first…
Vision… One of my main reasons for wanting the bot untethered is that for around £40 I can add a wireless colour camera and bring video back to my P.C. A bit of motion detection stuff and some image processing plus of course the obligatory VB/C# coding and it should give it a bit of sensory perception. That combined with close proximity distance measuring (IRPD most likely) it should be able to react to quite a few things…
It’s better to start out with one easy to use sensor than to try and go right to a camera. There is code available for the Basic Atom to use the IRPD, Sharp IR Ranger, and some beta code for the PING sensor. This will get you up and running the fastest and then you can start working on your real goal - the vision.
8-Dale