chip updates: doing some math for walking [updates]
Yes so today, I don't think I'm going to be able to do much on the physical testing of walking today since it's going to be raining soon. But I have to start with some math anyways using: https://www.adim.io/post/chip-updates-preliminary-experiments-with-weight-cog-motion-analysis-updates
Yes! CMA so we can see how best to place the feet and angles to get things working. So the new step strategy isn't to make the leg rise in y-position, it's actually to just lift up the foot with the knee joint, rotate the shoulder joint, and then place the foot at the stepping location. And we need to know how the CoG moves during this process.
And we're going to stick with the FL, BR, FR, BL order of stepping like all good robot dogs do.
Now... using the model above shows us that if we move one leg from the 45deg to the 90deg position, the CoG moves ~1cm forward. That's good to know. Now we just need to figure out how to make this puppy scuffle in whatever direction we tell it to. We have discovered, however, another problem:
Let's consider a two-leg-at-a-time walk where we move the FL and BR legs in a step together and the FR and BL legs in a step together. So essentially, the platform has to balance on two legs while it is walking (if we assume that it has to balance). Let's also assume we're moving the shoulder joint only to catch the robot when falling.
Now here's the problem, we know from the above stepping any leg moves the CoG forward right? What that means is, if we're balancing on two legs, the other two legs have to move forward to "catch" the robot from falling but the act of doing so, then MOVES the CoG forward with them.
Then the CoG while the feet are moving forward to catch the CoG, moves forward even more and the platform falls forward, and unstable system. So unless we only move the knee joint to stand on two legs, this idea isn't going to work. So the question becomes, how do we make the robot not fall over but also step two legs at the same time. So last time what we tried was maybe the opposite of what we should try. We tried keeping the two balancing legs stationary and just stepping the other two legs. Maybe we should do something like this. Let's do something where we ONLY use the knee joints to step.
But in the meantime, while I get that plan to work to whatever varying degree of success it'll achieve. I ended up trying to smooth the sitting and the standing for the platform while we're indoors and this is the result:
#only if the mode is stand_sit mode if(MODE==CONTROL_MODE.STAND_SIT): #then publish stand/sit commands if(LB==1.0 and len(trajRunner.waypoints)==0): trajRunner.addWaypoint([0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]) trajRunner.addWaypoint([0.0, 0.0, 8.0, 0.0, 0.0, 8.0, 0.0, 0.0, 8.0, 0.0, 0.0, 8.0]) trajRunner.addWaypoint([-10.5, 0.0, 10.0, -10.5, 0.0, 10.0, -10.5, 0.0, 10.0, -10.5, 0.0, 10.0]) COMMAND = [0.07, 0.47, 0.0, 0.07, 0.47, 0.0, 0.07, 0.48, 0.0, 0.07, 0.48, 0.0] trajRunner.addWaypoint(doIK(COMMAND)) COMMAND = [0.07, 0.47, 0.0, 0.07, 0.47, 0.0, 0.07, 0.47, 0.0, 0.07, 0.47, 0.0] trajRunner.addWaypoint(doIK(COMMAND)) if(RB==1.0 and len(trajRunner.waypoints)==0): COMMAND = [0.07, 0.47, 0.0, 0.07, 0.47, 0.0, 0.07, 0.47, 0.0, 0.07, 0.47, 0.0] trajRunner.addWaypoint(doIK(COMMAND)) COMMAND = [0.05, 0.2, 0.0, 0.05, 0.2, 0.0, 0.05, 0.2, 0.0, 0.05, 0.2, 0.0] trajRunner.addWaypoint(doIK(COMMAND)) trajRunner.addWaypoint([-8.0, 0.0, 0.0, -8.0, 0.0, 0.0, -8.0, 0.0, 0.0, -8.0, 0.0, 0.0]) trajRunner.addWaypoint([0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]) trajRunner.addWaypoint(DEFAULTS.STARTING_CONFIG)
The above lines of code outline two trajectories, one for standing and one for sitting. Here's the result of the above lines of code:
Overall it isn't terrible, I think sitting is much better than it was before, we get a slower "lower" onto the motor faces than we did with the old trajectory. And this is indoors.
While we have the robot on, let's check if the IMU of the robot is working since the IMU visualization wasn't yesterday...
Yes so, clearly we don't see an IMU marker, and that's weird because the MARKERS according to the settings panel are available but apparently nothing in the "tf" area is available over webviz at the moment. Hopefully this problem will fix itself later, here's the message:
Yea so I don't really know what that's about? I'm going to go through my code, check if Webviz had any updates and etc later, but for now I don't care too much about the IMU at this very second.
Okay so base_link_frd and imu_frame are both being published, webviz isn't picking them up? Or something?
Yea, not sure. We'll get to it later. For now it's time to think about walking/etc.