In CNC we have Gcodes that do a “move until sense”. They are used to “digitize” a surface (Renishaw). I think that’s similar to what you’re talking about.
If the SSC-32 were to receive a “sense” input from a foot sensor and cause an interrupt, then the leg number could be used to “kill” the three axis moves for that leg (or joint?). the servo(s) would terminate their programmed move, and the position of the stopped servo(s) would be reported back to the host via the back channel (RS-232). This WOULD be through the SSC-32 rather then sensors going directly to the host.
If the SSC-32 were limited to the 24 servos required, maybe it would have more time for other things. Just a thought. Hafta call it an SSC-24 (w/sensors).
If I understand what you are alluding to, sending a sequence of shorter move commands instead of one large one was something I tried. It has the unfortunate effect of causing jerky movements which most times lead to oscillation and chattering in the servos…
You’ve interpreted my suggestion correctly. I think it’s worth pursuing this route for a couple reasons.
Moving your foot vertically in 3D requires non-linear speeds across the individual joints. This is the immediate limitation of using the built in sequences, but I think as you go you’ll find a lot more. I assume you’re intending to do real-time IK in the main controller. If you have it generating new joint angles every 20ms you don’t have to worry about trying to fit a non-linear peg into a linear hole.
Secondly, interpreting the sensor data from ground contact is unlikely to be as cut and dry as you’re hoping. Depending on what type of sensor you employ (I’ve tried many and found no good solutions yet) you’re probably going to end up with some sort of analog value for force. The simplest interpretation of this might be a threshold value which says “Contact = Value>Threshold”. You’re likely to want to have different thresholds for each sensor to calibrate them due to slight mechanical differences. You might want to have the threshold work against a moving average. Maybe go so far as to apply Kalman filtering or some such. My point here is that this problem can easily become complex enough that you’ll want to handle higher level than inside the SSC32 or a black box servo controller if you scratch build it.
I’m fairly certain you can work out the jerky motion. What the SSC32 is doing internally is nothing special. It has no data that you don’t externally. It’s just a question of getting high enough bandwidth between your IK engine and the SSC32 and I’m pretty sure I worked it out once before that the 115K and the protocol will just make it under 20ms for a full 32 servos. And as long as your using a hardware UART from your master, then there’s extremely little overhead beyond keeping a table of joint angles. Every 20ms you render that into a buffer and let the hardware UART do the rest.
If you use Open Servos, you can still control the servos using PWM as from an SSC-32, AND you can read position and status information back from it using i2c. You can detect stall conditions using the current sensing feature, like when a foot contacts the ground. This is something you might want to consider as your applications seems to be pretty much tailor made for the features of the Open Servos.
ahhh… I no longer have to be the only OpenServo evangelist
While OpenServos will probably provide much better current sense data than I managed with my early hacks, these are still very difficult data to use effectively. The internal PIDs in any servo work via pulsing power to the motor by an amount related to the error in position. If the load happens to get a bit ahead of the desired movement, the servo will pulse backwards to slow the movement. Uneven loading of a servo thwarts any simple methods of interpreting the data even during slow movements. This is likely better in the OpenServos because the PID bandwidth is high enough that it will likely yield a much smoother graph than a 20ms analog but it’s still very difficult data.
I had some very limited success doing ground detection via current sensing by training a neural net on the current sense data that came back from the movement of a leg while unloaded. So essentially it would flail its legs around and the net was trained to predict the loading that each joint would see based on the commanded movements with no obstacles. In this video it’s comparing these predictions against moving averages of the actual data, thresholded to determine contact. During the recording of this video is about as good as I ever had it working, which to be honest, was rather ham-fisted at best. That’s not to say that others can’t beat it or shouldn’t try, just that attempting to use servo loading as a means of ground detection is a non-trivial task, perhaps even harder than finding an effective means of directly sensing ground contact
Andy, there is a lot to take in there, I will definitely try and implement some of it. Firstly, I’m going to set up a streaming protocol to the SSC, find out exactly how fast I can hold a conversation with it without overrunning the buffers.
It is running via bluetooth on a bluesmirf and I would prefer to keep it that way but if necessary it will go hard-wired or IP to get rid of the overheads…
Open Servo is an option, I don’t deny it but cost (and risk of me doing damage) is also a big problem. The servos I have are already very powerful and relatively expensive so I wouldnt muck around with them. It would have to be a completely new set…
As to ground detection. I’ve looked at numerous implementations and I’m keen to follow matt at micromagicsystems who managed to implement a good system using nothing more than simple switches…
I know that there is a latency overhead to bluetooth but as I discovered a while back when I first started using bluetooth with my KHR, the latency on the bluesmirf is one of the lowest on the market. If its acceptible then it stays, if the delay stops me doing what I want then it goes…
But something will have to be used because to me a tethered robot is nothing more than a peripheral to my p.c. Just like my printer.
I tried the serial stream idea, it works but causes jerky movement when trying to generate smaller step increments so not going to go any further down that route.
Generating my own pulses works but running additional gait code on the chip causes too many glitches when its really busy…
One option is to change chip for a faster one. dsPIC’s can run at nearly 60Mhz but I suspect that is merely clock doubling on the 29Mhz chip so not a real benefit. A more skilled programmer could make it work I’m sure but the cost of dev board and programmer and compiler makes them too expensive.
I’ve spoken with rabbit semiconductors and they can provide a complete dev kit and module for £150 so thats a cheaper option.
Whichever way I do it, the gait code has to run on the same chip as the controller code to some degree so Atmels seem to be out of the question.
