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
