• aditya mehrotra.

chip updates: a whole new world (of guess and check) [updates]

So up to this time we've been highly concerned with stability right. We've been like "oh it needs to balance on two legs, or it needs to keep its CoG within the triangle of its feet and so on." And honestly, these things aren't really true right. Because we walk by falling you don't see us balance on one leg before we move a foot. It's not like, shift/lift/balance, move foot, place weight on other foot in this really weird fashion. We've been looking at this problem all wrong. If we walk by falling, and chip is really good at falling, all we need to do is figure out how best to make it fall so it walks forward.


The problem is CHIP is really weird. The CoG is never where we think it is and getting this thing to balance or walk without that kind of model is going to be impossible. And I refuse to add wheels to the bottom so here's a new strategy.


What if we just programmed in a trajectory where we moved two legs in steps but very small and very quick steps. So let's say you had the FL and BR legs as the "grounded" legs. Make those move 0.05m in the +y direction to "boost" the platform. And while they're doing that retract the FR and BL legs by 0.01m, move them forward by 0.05m and then have everything return to normal. Because the movements are so small and the leg is quick. That might just make the robot walk forward. Why bother with balancing when we can do a baby shuffle that might work.


NO THIS SOLUTION is NOT IDEAL. But that doesn't mean it won't work you know. If we get this to work that shouldn't be an end-solution. We should develop past that but at least its a starting point.


So what we'll do is turn that IMU OFF because all it'll do is interfere at the moment especially because we'll need to use trajectory. We're also going to raise epsilon just a bit, sometimes that thing is really weird.


We're going to put this code in WALK mode not TEST because that seems like where it would be at home. With this test we're going to have to be really careful with zeroing because otherwise this might work today and not tomorrow or something. In general, we need a better - non-eyeball zero procedure.

Now let's put the trajectory points into defaults.py just so we can get them ready for programming.

Originally, I was like okay we'll step one diagonal then the other. Now I'm thinking one button just steps all four in the following sequence. (1) mini step for the first set. (2) larger step for the second. (2) mini step for the third to get it back to zero.


Now this trajectory as you see above, lifts, then moves, then places. This might be too much in itself. We might want to do more like a Lift AND Move and then a place. So gettin rid of ONE and immediately going to TWO above. We're going to see how both look and try them. Here are the two possible leg trajectories:

We're going to do this left-twix/right-twix style. Try both and pick a side you know. Now we're going to add two buttons to walk mode. And the left button will STEP the platform like above and the right will do nothing for now.

As you can see that adding multiple waypoints method came in handy in this trajectory thing. We also increased the epsilon of comparison to 0.015 so that means the leg really won't exactly follow this trajectory but its OK as long as it steps right. We might end up having to change this trajectory to the possible alt. above because I'm not so confident in this one but only testing will tell so let's try it anyways.


I think we're ready to test this out later in the evening. Exciting hopefully it works. At some point we'll find a Gate small enough where this strategy works.


#updates #omgrobots #lets_try_again #trajectories #walking_questionmark

1 view0 comments
© copyright 2019 | aditya mehrotra