I think it will be a lot of fun to get this up and running and to see what techniques work and don’t work. As Xan mentioned there are issues with all of thd different techniques and it may easily turn out the best solution is some form of combination between the different ones.
#1 - Is too slow for normal type robot operation. I think this might be interesting if we for example had double sensor per leg. With for example some form of Sharp IR sensor that detects how close we are getting to something. You run at full speed until one of these sensors says you are about to hit something and then you scale down the movements to actually find the object…
#2 - Is interesting, but for sure you will always overshoot by some. That is by the time the switch triggers, the foot is on the ground, so much time will delay before the code (interrupt or the like happens). Then you have two choices. You can stop a servo with the STOP n command. Not sure if it handles: STOP n n n or not. But if it does than it will probably take something like: STOPnn nn nn or 13 characters at 115200 this will take something like 1.1ms to send out, which the servos will keep on moving during this time.
Alternatively we can issue the new binary stop command, but I believe this stops all servos, which only takes 1 byte so is reasonably fast. But then what do we do after this? If lets say the front right leg hits the ground about half way through 1 step of a gait what do we do next and all legs are stopped. What next. My assumption is that we reissue the last move for the other N legs that have not hit something, with a guesstimate of the time remaining in that last step… What about the leg that hit. Could not issue move for these servos, or we query it’s position and reissue it, or could try to fudge it with the idea of we were delayed by time N and move it back to where we think it should have hit. Do we leave the servos in the position where they hit, or do we calculate what the servos should be at for the position the foot currently is at? …
#3 - Is the approach I started to play with as I think it has some potential. It does have the problem of knowing exact timings, which may turn on not to work well. But as I mentioned before we may have the same issues in #2. Also are the moves linear or not? May not be, but we may be able to give reasonable guesses. That is we can also do our own ramping in the guess. As for computing power to do this, it may depend on which way we compute things. Example: if we are moving from (X1, Y1, Z1) to (X2, Y2, Z2) in time Tm and we hit at Th, we may compute this by percentages of the differences of X1 to X2, which may take some time and the like, or we could know that the Servo Pulses for the three servos are going from P1 to P2, which we can do a simple linear approximation for where the P is when the hit happened. The computation after this point would be the same as #2 as in #2 we would be doing a query command, for the three servos to get the actual positions… Again not sure it will work, but I think it is worth a try.
Regardless of what approach we take, I do have some concerns about how we organize the code. With the current code (without TA), in order to get as smooth as possible gaits, with as little as possible overhead, the code works sort of like:
Step 1: Get the time of when the Last SSC command commit happened: Tlast
Step 2: compute the next servo positions.
Step 3: Issue as much of the SSC command as possible with out committing it.
Step 4: Sleep appropriate time: - (Tcurrent - tLast)
Step 5: Issue the commit to SSC (1 byte if non binary, 3 bytes if binary…)
go back to step 1…
Above is simplified, like there is a step 0, that goes out to talk to your controller and the like. But there are issues with the above with TA. That is suppose we are in Step 4 when the leg hits, what happens with all of the data we already sent to the SSC-32? Can we cancel it? If we issue new data for all of the servos that would probably work… Note, even if we did away with step 3 like the original code and had step 5 issues the complete SSC-32 command, we still have issues of suppose we have issued the servo data for 4 of the legs when the leg hit happens…
As Xan mentioned, this would probably be simplified if we did this all on an Arc32 as we are in complete control here and you don’t have the serial delays in the mix…
That is all for now. Should be lots of fun!!!
Kurt