• aditya mehrotra.

chip updates: more walking, step-by-step [updates]

So we're actually getting much closer to walking. I want, by the end of the day, to have some form of a stable walking gate. We should remember that every time we turn on the robot he'll need his terrain offset tuned by 0.1-0.05 rotations.

Today we're going to try to get the platform to continue attempting to do a static walk. When we get to a stable static walk we can improve things with the IMU or other resources.

So working on this for this amount of time has showed me something else:

Incorporating the IMU into the walking algorithm initially might be simple, we might be able to use it to automatically edit the weight shift each time the platform turns on. Because changing it to -0.05 worked! Instead of -0.07!

Anwyaysss, let's get to walking.

OKAYYY turns out I was wrong. WE need to know what to look for when setting that terrain offset. I went down to 0.0 on the offset and now we need 0.07 on the walking. We shouldn't have to touch the walking if the terrain offset is right!

Here's my biggest problem: consistency. I know how to make the platform walk once it's on. But like standing and sitting now, we've made it such that it's REPEATABLE it's the simple change of a parameter and it stands just like it did before no matter the zeroing. So we need to figure out a way that allows us to walk, without the feet slipping, and have some parameters that make it repeatable. Instead of this mess of code we end up with each time. We need to find a leg trajectory that works for the legs you know? It also might be worth trying the old walking method now that we've simply improved the standing and sitting.

Anyways let's think about this before just diving in and coding it. Let's also give the platform a break it's doing some strange things right now. It usually does strange things when it's low on power (like FRC robots do). I blame the RIO for that. Let's try deleting all of the code here and re-trying this walking thing. I'm not sure this is the best approach you know.

Maybe the best way to do this is deal with the gate and the strafe together.

Let's try this out...

We use the joystick to set the motion and then we click the button when we're ready to step.

This didn't work either, it just kinda fell on its face again. And I'm not really sure why, maybe we need more of a shift like 0.07 you know.

Maybe we should try kinda like a slide-y walk. Where chip picks diagonal feet off the ground, slides them forward while sliding the other two back, and then places all four on the ground, and then moves the next two. But this way we can only lift the hinge joint instead of the whole leg meaning the CoG won't change. We might have to do a little more like a shuffle over here to get chip to walk around.

It's also important to note that now that we're getting a 3D printer we can 3D print mounts for WHEELS on the bottom of chip and see if that actually helps us make chip into a little more useful robot. It can transform and sit on its back you know. If we really want it to, add wheels on one side so that it gives it some drivability if we want.

But here's the problem, if we put additions on chip's arms that changes the CoG and knowing the CoG is how we're getting it to walk consistently right now. So we need to figure out a way to make this thing walk with the use of the IMU to keep its balance. And we've been saying this for so long but also it's important now that we have the time to figure something like this out.

Either way, I think we need to start with a MOVE_LEG method. You know? Something that will let us move an individual leg to any position because that'll simplify the programming a lot.

We also went ahead and fixed the CURRENT_XYZ topic I think the commands were in the wrong frame from when we changed the ZERO so it's been publishing the wrong thing. But now that that's fixed we're OK!

I think the first thing to do is test, with the standing calibrated, at what x's is the weight definitely off the front legs and definitely off the back.

The other reason might be since the platform is moving so fast from 0.0 to 0.06 x for example, it's just pushing itself over. It might be stable statically at 0.06 but it moved in that direction too fast. Dividing into 0.02 increments might help.

That's what a 0.02 shift looks like, and here...

And that is what a 0.04 shift looks like. But from our testing it looks like weight is on the rear legs at x=-0.01 or x=-0.02, and weight is on the front legs at x=0.06 or x=0.07. Let's try this out as a tactic.

Now we're going to try out this. JUST with that FL leg at the moment.

Let's try that! I think it should work but we will see. I think it's the right syntax too.

Well the good news is we can now say that every time the platform falls over he'll consistently sit down.

Okay so now I have good and bad news. As we can see the above program worked after tweaking things a little and dropping the height of the opposite leg. And then at the end the platform simply fell and I think weight need to fix the two shoulder gearboxes in the back which would be really really annoying so that means I don't want to do that today rather I'll do it tomorrow. SO I think instead of inspecting them now (they do seem like they need the fixing), I'll simply fix them tomorrow the same way we fixed that leg by removing a spacer. The good news is we might be partially on our way through method that can move one leg wherever. Which means we're partially on the way to walking.

#updates #omgrobots #yay

6 views0 comments
© copyright 2019 | aditya mehrotra