Method 2 seems the most practical way to go. Method 3 will be inaccurate at best and probably a waste of time. Method 1 looks interesting, but the methodology (as best as I have followed it) appears to be combersome. In the fifth post in this discussion (~1.5 years ago) I gave a quick statement of what I’ve seen what can be done with an ssc-32. With the current version of the ssc-32, the “all servos stop” does not have to be used. Individual servos can be stopped when they make ground contact. I can see moving three legs in the down direction at the same time, stopping each as it made ground contact. The positions of the three can be obtained from the ssc-32 to evaluate against the current down positions of all legs to determine the general position of the bot body in relation to the general ground position. As I’ve mentioned in the past ~2.5 years on the A topic, it may be good to start with getting a basic bot walking, then develop in all the extras.
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
I forgot to mention in the previous post, that if we use an Arc32 for this, it more or less makes #2 and #3 the same. That is we no longer have to keep our own idea of where we think the servos are, we simply do an HSERVOPOS for the 3/4 servos of that leg and then respond, with either simply setting those servos to stay where they are or back up slightly… We no longer have the serial delays involved, which is what #3 is trying to eliminate.
Personally I think Arc32 would be the best approach here… Should work for 3/4 DOF assume 4 so 24 servos, plus 6 IO pins for feedback. We hang a PS2 off of the 4 Aux pins, plus optionally XBee on second UART. The only issue would be if you wish to do an RC version, with 6 IO pins… I know there are hacks for Hitec and some other receivers to use one pin (did on mine to test), but wonder if we could do with spectrum as well. If so would be less overhead as welll…
Just a thought
Kurt
Just thinking out loud here, but if TE is to advance on the SSC-32, it would be nice to incorporate the foot sense in it’s code. I know, there is no concept of a “leg” in the SSC-32, I.E., no specific groupings of servos or tripods. This would get the “intelligence” of moving a leg down to where the critical timing is. No simple task!
Otherwise, as mentioned, the ARC-32 might be the (interim?) answer…
Alan KM6VV
… and timing is very easy in ARC32 using HSERVOTIME
Hi Zoomkat,
I do not totally agree with you on this part. Like said in my previous post, balance calc is the key to this. With balance mode on the body will always move relatively to all 6 legs. So if one leg goes down, the body will follow that leg. This means that ALL servos move with every step. So it is not possible to only stop a single leg since the body will still move downwards. I hope this makes sense.
Oh yes, I totally agree on this. There are a lot of issues to solve once we’ve got the basic steps to work. Think about what to do if the gap is to deep and the leg becomes overstreched. etc.
Thanks for your input.
Xan
Hi Kurt,
I’m my previous post I described how the balance calculations are involved in this process. Since the body moves with the leg that is going down it is not possible to only stop the single leg. We have to stop all servos at all time. To demonstrate this you could try the single leg control on your hex with balance mode on. You will see that if the leg goes down the body will follow as well.
My idea is to use the binary stop all command. Then use the binary query command to only query the needed bytes for the 24 servos. All @115200 offcourse.
I did some tests with the stop command to test the overshoot created by the mechanical sensor and delay in software. I created a small program which lowered the leg until the sensor was hit. Then it send the stop command. The overshoot was there, but not that big. Off course it got bigger once the speed went up but It’s a good thing to repeat this test once the T-Hex is in. I also hooked up the logic analyzer but I can’t remember the values. I really should start writing more down. 
Good question. I was planning on going into further detail later but lets talk about this now.
Let’s say we start with the most TA compatible gait.
If leg A is moving down from position 2 to position 3. At the same time a leg (say B) is moving from position 4 to 5. If leg A hits the ground at half hight all servos stop. This will also mean that leg B is half way. But let B is on the ground and that position is static at that time. Then we calculate so we know where all legs are. (I get back on that) Once all legs are on a known position again we can finish the rest of the move horizontal. This way ONLY the vertical movement stopped and the horizontal movement will be finished.
When you study the gait you will see that ALL gaits will have the same pattern that we can use as reference. In each gait the hex will have 3 legs on the ground that form a triangle. This triangle is always formed by left front, left rear and middle right OR right front, right rear or left middle. Since the legs are always on the ground we can calculate from the static tars to the body. From the body we can calculate to the unknown leg positions. I’m planning an detailed post on this including the needed Math.
I agree, this sure has some potential. I’m not throwing this idea from the table we just have to see what the best method would be. I really have to think about his one a bit more.
I do not agree on this part. In #2 we stop the servos and query the servo angles. We need to do FK to determain the position for each joint relatively to the origin. In method #3 we can do a approximation to the new position which lies somewhere in the path between point P1 and P2. This approximation should directly give us a position. So there is no need to do FK.
I’ve made a flow diagram that shows where to do what in the code. I think it should work for our first test setup. This is also the flowchart of the last program I’ve send to you kurt. But it isn’t bug free 
img40.imageshack.us/img40/8287/softwareflowdiagram.jpg
The red part shows the newly added parts. It would be great if you could study it and see if I forgot something.
Note: I used a masked byte for the flag. This makes it possible to have more legs which are going down at once. I suggest we only use a simple gait that only has one leg going down at the time but with the masked byte we could get this to work with a tripodgait in the future.
About the ARC vs SSC/BAP: the ARC has a big plus on his side that we don’t have to send commands down and forward the serial connection which spares us time. But with the send/receive part already done it is fine by me to go with either setups. The time it takes to send/receive the data only takes a bit more time that we could improve once we’ve got a working prototype.
That’s all for now.
Xan
Hi Xan,
Looks like you have a good handle on this stuff! Can not wait to get my hands on to it and see how well it is working. I will wait until then to comment much on the code flow until then.
It will be good to retry this type of code out again and see the different results. This will also help me to optimize the interrupt handlers and try out different approaches. As you mentioned we will should try to document this.
You are probably correct, that you would not need to do the FK. That is my initial thought as well. That is if we are moving from point (X,Y,Z) of lets say (100, 100, 100) to (500, 500, 500) in 100 units of time and we know we made contact in 50 units of time. We can guess that contact was made at (X, Y, Z) of (300, 300, 300). Likewise I would expect that the servo pulse widths for the Tars, Tibia, and coxa servos would each have 50% of their delta from the starting to ending pulse widths.
What I was wondering is that if I did a IK for the position (300, 300, 300), would the IK choose the same servo angles(pulse widths) of where we stopped, or might it choose a different solution. If so does that matter?
My initial thoughts on this was, yeah it might choose a different solution, but it will probably correct this when it issues a new move…
So I am hoping that this will be a non-issue. Not sure if I am making any sense here.
That is all for now.
Kurt
Has anybody tested sending the stop command in series to three servos that are moving to check the response time? I would think that due to the flex in the legs that undershoot might be the issue. Below is the simple aluminum foil/paper clip test I did ~2 years ago checking the position every 20ms at 9600bps. If you can shorten this time then better response would be expected. As to the balancing, a simple approach of averaging the positions of the legs on a side and comparing that value to a desired median position band would be a simple place to start. If the the average is outside the band, then add/subtract the difference from the center position of the median band and increase/decrease the positions of all the legs on that side the amount of the difference to reparallel that side with the assumed ground surface. And once again for those on a budget or those that don’t want to wait for the ground switches, the critical testing can be done using aluminum foil.
in my test
viewtopic.php?p=70612#p70612
using WKPINT it overshoot by apx. 1mm, but the error will be more if speed of HSERVO is more than servospeed
How maxed out is the AtomPro in processing?
As for the terrain adaption have you ever thought about using a Gyro mounted flat on the bot and working some code around that?
I had picked up a Gyro at sparkfun and wired it up to an LM315 I think it was made a nice little package that plugs into the botboard. I have some ideas for simple gyro code as I had written some to figure out exactly how a gyro worked electronically, so it appears to me you just sample data and run it though constant loops and monitor changes… so with that said, it seems like a cpu/io intensive task… I’m all ears if I’m wrong.
It would be cool if you could use the AtomPro with the DynaMixle servos since they are all serial and provide feedback, the phoenix would probably be 4x more money but HEY you could have it carry your groceries!
Looking cool so far guys.
–Aaron
Could probably implement PID loops to keep the body in the horizontal plane? Corrections would attempt to keep body level.
Alan KM6VV
Yeah from the diagrams above it looks like having the body level is the incorrect method, but then again I guess it depends on what your trying to accomplish… Haha I bet Zenta would make another A pod with a coaster on its back and walk over books while keeping the can of soda level on its back 
terrain adaptive quadruped robot. very cool. 8)
Note that it appears to move, set, and adapt one leg at a time. Hmmm…, that seems familiar. 8)
Very very good work !
How would one go about wiring up three gyros to the phoenix heaped using the ABB2 and SSC32? Also Im very curious to know about the type of output gyros give out and how this is programmed?
I’d think you’d have to use some sort of IMU, and read the values in order to use the data. I don’t think directly connecting gyros to R/C servos would help in the case of the Phoenix. Is that what you’re thinking about?
I want to play with the Razor 9DOF IMU.
Alan KM6VV
well my thoughts are that if connecting gyro’s to the ABB as input device’s then can this signal be used to interface the bodys XYZ axis?
An RC gyro has a servo pulse input and the servo connects to the output. I mentioned this because you mentioned connecting three gyros to the walker, not a 3 axis gyro. I believe a 3 axis gyro has simple 0-5vdc outputs.