I am considering using the SSC-32 as a replacement for the RCB3 unit in my Kondo KHR-1HV (BlueSmirf connected)
I have scanned thru many of the topics and found answers to lots of my questions…
Can anyone please cross off my last few questions.
The KHR uses a 10.8V supply. I notice the SSC uses a LM 2937 as its Logic Voltage regulator which has a max input voltage of 26V. Will the 10.8V be a problem?
The KHR suffers badly on timing issues in Comms. It has very narrow response windows for commands making BlueTooth Latency a real issue.
Are there any comms timeouts etc that could cause problems with BlueTooth?
On KHR, reading the current servo position causes a momentary pause in movement. Overall this leads to very rough motions when trying to control from the p.c. Is this similar on the SSC.
Not all commands sent from the P.C. are acknowledged. In particular the instruction to move to a new position. Does the SSC send a reply when a motion has been completed?
If anyone can answer any of these questions, I would be very grateful.
Short answer, no, the 10.8V input should be fine. Actually using a separate 9V is recommended as servo draw can cause the voltage to drop and the device reset. The SCC-32 itself uses very little current. The only reason the regulator would get hot or might have issues is due to using it to provide a 5V source for additional electronics. A single BlueSMiRF shouldn’t be an issue though (I’ve used this setup).
No, the SCC-32 doesn’t have any response windows because it doesn’t have any interactive commands which require them. I believe bytes are stored in a FIFO until a is received when the command is executed, but may be wrong here. This is because I see the LED blinking when typing in a command on the terminal line, but nothing happens until I send a .
No. However, the SCC-32 is not made for servos that tell the controller their position (such as via I2C or Hitech’s MHI), it just echos back the position you told it to set the servo to. This is much better implemented by having a value in your software somewhere which holds this as the time it takes to transmit the command to the SCC-32, get a response, and parse it is considerable compared to the amount of time it would take to check a variable in memory either on a PC or in a microcontroller.
No, it does not give general feedback when a command is successful. However, the LED will let you know if data is being sent. Note, I’ve never had a command fail when running either of my SCC-32 off of a PC or my BS2 microcontrollers.
While I will definitely vouch for the SCC-32 as a good controller, it looks like your BlueSMiRF isn’t working right. I also have one, and on my PocketPC (which has a hacked Linux BlueZ stack running on Windows Mobile5) I sometimes get similar problems with my BlueSMiRF and other Bluetooth devices. Resetting the bluetooth subsystem stops this behavior (for a while). Sparkfun itself said some modules don’t work well with the BlueSMiRF. If I were you I would try resetting your dongle, or another driver for your dongle, or another dongle and see if that doesn’t improve things. Since if the problem is in the wireless connection, an SCC-32 isn’t going to help. If you also get these problems with a wire and have diagnosed your bluetooth link, then by all means the SCC-32 should solve them, though you might have to adjust your software. Lynx sells a nice Windows sequencer, but a C program or script which outputs to the serial port is easy enough to write yourself.
It depends on what you call interactive. There are commands you can give to the SSC-32 (like “Q”) to find out if a servo move has finished yet or not. It’s too bad LM didn’t create a bi-directional serial cable to go between the ABB and SSC-32. There are plenty of times when having that feedback from the SSC-32 would be helpful. For instance, I am going to write a Python routine to wait until the current servo move is completed before I issue another command to the SSC-32.
I have been using Python on Linux/FreeBSD to create scripts for my SSC-32’s, but haven’t done it under Windows yet. It should work as well under Windows though.
My question about feedback was because I had intended to sequence several motions together if possible. This would require knowing when one has finished so I can send the next motion.
The Smirf is working fine I believe. I have done some timing tests on the KHR RCB. To send any command, you have to first send a CR. It then sends a CR back. You can then send your command. It effectively puts the Controller into a listen mode.
Playing around with the timings over the USB lead, I have managed to ascertain that as long as the command starts sending within 20mS it will accept it. 22mS and it won’t. Its a timeout thats killing it. If I get a bluetooth transmission with no lags or byte gaps its fine but one gap kills it.
Similarly, when sending a motion( approx 40 bytes), if no gaps then its accepted otherwise its rejected.
Unfortunately the RCB3, which is a good controller for what it was designed for, doesn’t have a true UART implemented and simply clocks data in from an I/O pin. The timings of which are rather precise.
The SSC sounds to right toy. If a motion is a slow move, then I can always Poll it to find out how far its got as long as frequent polling won’t effect the motion.
I would prefer to keep everything on the same battery because KHR is already a bit lanky and top heavy and adding another battery would cause more problems than it solves.
BTW, I don’t want my moaning to be seen as any form of reflection on the KHR or RCB or even Kondo. Its just that it doesn’t do what I want it to.
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.
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.
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.
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.
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.
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…
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.
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. 