Hi guys,
With the T(A)-Hex coming together pretty fast and Kurt willing to join me on this project I want to share some thoughts and work I did on this.
[size=150]TA Methods[/size]
The following methods came up to my path. There might be more or better ones. Feel free to fill me in.
1. Small steps
I won’t go in to detail on this one since I’ve already demonstrated this in a video on youtube and talked about this a lot in my previous posts. It is pretty easy since there is no need to do FK for the legs and IK for the body. But it is very slow.
2. Stop command
Like explained earlier, the leg goes down until it hits an object (ground). The BAP will see this end sends the stop all command to the SSC to stop further movement. Then the servo positions will be queried. The positions of the legs and body will be determined using Forward Kinematics for the legs and Inverse Kinematics for the Body. With the new known position the gait can move to his next step.
3. Time measurement
I read this idea from Kurt on the forum. The idea is that once the leg is going down. The full sequence should take 200mS to travel from position A(0,0,0) to position B(12,20,40). If the leg hits the ground after 150mS it means that it only took 3/4 of the total time. This should mean that the distance traveled is also 3/4 of the total distance. The final position will be at (4,15,30).
[size=150]Route to follow[/size]
With the 3 TA methods laid out I want to talk about which method would be the best.
Method 1 is shown in this youtube video. As I said, it is to slow. It sure can be improved with the faster binary command set and the full speed connection. It even can be increased a bit by using the ARC since there is no communication between the 2 boards. But still, the hex should take really small steps to decrease the amount of overshoot and accuracy. Method 3 shouldn’t be to hard to implement. But I’ve got kinda doubts about how accurate it will be. And I kinda have a strange feeling about determine position by measuring time. This would only work if we have the exact time of the movement and the movement should be fully linear. Maybe the errors will be small enough to get away with it though. Method 2 is the hardest of 3 but also the most accurate, has almost no overshoot and is pretty fast. The reason why this method is so hard to accomplish is that once the leg touches the ground all servos stop and a lot of positions are lost! it is possible to query the servo angles but we still need to calculate so see where the leg(s) and body really are. This doubles the calculations needed.
I’ve been currently working to method 3 since I think this is the most professional way to go…
[size=150]Balance Calculations are the key to success[/size]
I’m convinced that Zenta’s Balance Calculations are the key to success then wit comes to Terrain Adaption. As most of you may know the balance calculation ensures that the body always stays relative to the position of the 6 tars. This is not only in all positions (x,y,z) but also in all angles (pitch, yaw, roll). Since TA will make our Gait engine into a full closed-loop system needs to take care of the environment. This means that the origin = ground will change from now on. To show this I made a small drawing.
img713.imageshack.us/img713/3163/functionbalancemode.jpg
In the first set of drawings you can see that the origin will stay put when the hex crawls over an object. Even if we increase the height Y it will still become a problem since it isn’t possible to put a infinite large number in a word
With the balance calculations turned on, the origin will move with the hex. This makes the height Y always the relatively height between the tars and the body. Not the height from the origin starting point to the body.
This is why the balance calculations is the key to success
Next up I will talk more into detail about the needed calculations for method 3 and how to implement in the current phoenix code.