Uh,where have i been,I’ve never seen this topic before 
Thats one nice looking and an Amazing Robot you built there 
To be blunt, I think the Atmega128 has the ability to achieve what I want it to. It would make a good single chip implementation of the SSC with the addition of at least 8 analog and 8 digital inputs.
It possibly even has the ability to do a lot more in the background such as gait generation and command handling.
With the limited amount of time, 17mS at best, to do all this, the main reason why this will not work is going to be my coding ability. I have little knowledge of C as a language and even less of the specialist manner in which it is implemented for the AVR range.
I believe even more now that I need to find a faster processor based system that will make up for my shortcomings.
As Andy quite rightly says. It may be better to keep the logic and servos seperate. My work on the KHR showed that that way can be done but I may have to forego certain frills.
Thank you, much appreciated…
I agree that you can probably do everything you want with the single chip solution. I’ll reiterate though that it’s simply not worth the headache that will almost definitely come along with it.
From what you’ve described that you are trying to do, I’d say use the SSC32 slaved to your ATMega. Do all your analog I/O directly in the Mega (no need to mess with the SSC32s a/d inputs) and stream your output to the SSC32, let it worry about the pulses.
I don’t mean to discourage you from building a custom servo controller if it’s just for the exercise of doing it (I did the same, though only 6 channels per chip over I2C) but if you take my other advice of keeping the servo controller separate from the logic, then rebuilding the SSC32 seems excessive. Perhaps I’m missing something.
If your concern is about how quickly you can stream new positions to the SSC32, I’m pretty sure that over 115K and even in the rather verbose command syntax of the SSC32 you can get 32 new positions in there every 20ms. Given that, I don’t see how you’d be giving up frills?
Andy you are right in more ways than one, it is a headache and the results probably won’t justify the effort. SEQ runs all the servos over the serial link extremely effectively. Its all “do-able” and I’ve implemented them in some degree or other.
One requirement is all that is driving me at present and that is the absence of a STOP command for the servo.
To achieve a good terrain adaption I need to implement a “LOWER” function which essentially lowers the leg until it hits the floor.
I can issue a command that will lower the leg properly, more likely a sequence of shorter moves, but I have no way of stopping movement if contact is made part way through a movement.
say for example the leg starts at 1000 and I send it to 2000. If at 1600 it touchs the floor it will continue to 2000 before stopping thus trying to lift the whole body on one leg.
The only possible solution I could try is to set the leg moving and when the contact is detected, query the 3 servos involved, get the results and send those values as the position. Its not tidy but it might work. Again the only issue would be speed and delays.
Solving this one problem tidily would allow me to put aside the servo control aspect and move on. Admitedly, I have had an immense amount of fun and gratification from achieving what I have so far.
Assuming my prior assertion about how quickly you can update all the positions over 115K is correct, then you have no reason to use the speed capped move feature of the SSC32.
That routine simply adds to the current position the speed value until it reaches the desired position. If you can do full bot updates every 20ms, bring that logic to a higher level so that you never ask the SSC32 to do anything in the future beyond the next 20ms. Then you never have to ask it to stop 
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).
Alan KM6VV
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…
That is pretty much what I was hoping to achieve, tying an input to an interrupt that would halt the movement of the associated leg.
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.
8-Dale
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’ll just about guarantee that the bluetooth connection will be a bottleneck.
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.
Stunning.
Quite a clever unit from the spec…
I downloaded and looked at the code which is built in a BASIC compiler.
Its extremely SX specific and loaded with machine code…
DRAT was hoping to get some pointers there…
I wonder if its gonna be marketed coz it does look sweet…
Hope it helps.
I never looked at the code so I thought it would be mostly SX/B.