chip updates: PID tuning day! [updates]
Yes so today we really should do some PID tuning. We're going to start with the PID tuning of the IMU system that keeps that platform level. Then after we do that we'll implement the orientation/balance system and PID tune that. Hopefully this will all be done by evening so we can get to walking soon.
Now, let's finally get to tuning. We're going to increase Kp until the system starts oscillating. Then we will increase KD until it stops. Then we will repeat these steps until increasing KD does not stop oscillations, then we will increase KI until we get desired response.
So what we're doing is sitting here and trying to tune something that keeps the platform level. Frankly that's not what we want to do. What we want to do is ensure if I lift up two of the legs, the robot will stand. For now, I will reprogram the triggers to lift up alternating sets of legs. And we will add in the acceleration axis of the IMUs stabilization and we'll tune ALL THREE TOGETHER. Which may sound like a bad idea, but we really want the best response for keeping the robot standing when two legs are up. NOT the best response for flat trim so that's why we will approach it this way.
Let's try picking up the feet as is and see how bad it is. And be ready to catch the dog. With Kp=0.07 for the flat-stabilization. Yea so it's pretty bad. So let's try this IMU orientation thing and see what happens. It is likely we'll need to use the robot COG node though (and we will) but let's see how good we can get with the IMU. Let's just use the orientation of the IMU though, If the IMU sees positive pitch, let's move the legs backwards to counter, if the IMUs sees positive roll, let's move the legs left to counter. So yes, a little different than the last configuration. But it might work better.
So now we have 4-PID loops going. We have two that control the Y-loops that adjust the Y-height of the individual legs like before. And then two independent loops that control the X and the Z separately. We'll tune those gains separately later, right now they're all at Kp=0.07, and honestly, we're just going to go for it and see what happens.
Alright we tried that, and miserably failed. And I think that's because we're not even close to the position where the robot might be able to balance. We need to be close at least. So what we'll do next is implement a model where when it lifts up the legs and puts them back down, before it does that it shifts the feet that aren't being picked up in line with the CoG! That's what we have the CoG node for right. So after trying a few times to get the robot to stand on its two legs. We're going to have to go about this in a more systematic way. We need to use the IMU for local stabilization because otherwise it's too much of a correction and the robot will not be able to make it fast enough.
Okay this isn't working, I need to think.
Okay so here's a new plan. For now, we're going to leave the stabilization in the y-direction and get rid of it in the X/Z at the moment and code in single-legged walking. Which means it lifts one leg at a time (using the CoG information).
With that system, we'll tune the gains so that chip is able to walk at least one leg at a time until we do some more research. If we start here we'll be able to move towards two legged walking.
So let's get some more refined thoughts down here:
What the idea was going into today was if we program chip like you program a self balancing robot then if we use PID control to have chip balance on two legs, then we can lift and move the other two essentially however we want. So what we tried to do is say, okay, if chip is leaning towards the rear, we'll shift the legs backward to catch it, and to the side the same. The problem is chip is very back heavy, probably because of how the legs are oriented. The CoG moves significantly as the legs move which means we need a new control strategy. The self-balancing robot works well because we know the CoG is inline with the pivot point but in chip that's not the case it's a weird like we need to laterally move to get under the CoG kind of thing.
So if we want to get it walking soon we could use the three-legs-on-the-ground stepping theory. If we want to get it walking well, we need to eventually move to the two-legs-on-the-ground stepping theory. So I think the first thing to do is have a mode button that switches the platform into walking mode and when we put it into walking mode it just moves opposite legs up and down. Once it can balance in that mode. We're good to go!
Creating something like this means we're going to have to handle things like trajectories on the Jetson. But that's okay we'll just rewrite what we did for the rio on the Jetson itself. This is the challenge, I don't know how we are going to solve it yet so I'll leave it at that for this post. I'll get back to you when I know/have an idea of how we'll solve it.