chip updates: startup scripts and hopefully walking again [updates]
So one annoying part about chip is every time the jetson restarts we need to type three things:
cd chip_v2 --> THIS ONE source devel/setup.sh --> AND THIS ONE roslaunch CHIP_ROS chip_basic.launch --> leave out for now
And maybe we don't want to launch on startup just yet since we aren't necessarily ready for that. But maybe we want to write the script anyways which would launch on startup and in the meantime write that script to run every time we open a new terminal. And we're going to do this by adding them to ~/.bashrc https://superuser.com/questions/591321/execute-a-command-every-time-terminal-is-open
So let's try that... we're going to be following commands very similar to the ubuntu installation of ROS. So let's do it.
echo "cd chip_v2" >> ~/.bashrc echo "source devel/setup.sh" >> ~/.bashrc source ~/.bashrc
And success!!! Let's try opening a terminal and trying to launch right when we open the terminal and see what happens.
See? It works. The moment we launched the terminal it took us to the chip_v2 folder with the devel already sourced. And now we can launch the program immediately not waiting. So when we do we can save some typing.
So today I want to get this thing walking. Last time what we did was write something that allows us to lift any individual leg and move it. Now we have to make it move in a walking pattern and I think we likely won't use the lift leg program because it's too forward/backward in the weight transfer department. With the new terrain offset we can hard-code in walking and it should work each time. So let's take that route.
This is a test to just move the FLL let's try it. Let's run this test and see if just the front-left leg steps properly now that the terrain-offset has been calibrated.
Okay he fell over. Time to try a better version of SHIFT. We're going to try adding a Z-shift in the legs you know leaning from SIDE - SIDE as well as front-back. Too much of a forward shift now the platform falls on its back. We're adjusting the terrain_offset as we go because otherwise the result won't be repeatable.
And... the system just lost power. For god knows what reason. I think the device itself is heavily under-powered and it could be we tried to move 8 motors at once instead of the typical 4. Maybe we'll change it to 4 at a time...
Can confirm the problem is moving 8 motors at once... my guess is the immediate spike in current goes above the platform's threshold of 40A and doesn't allow us to do anything besides FALL OVER YAY!!! Hello roborio brownout protection hello power-supply over-current protection.
So yes in the end we're going to move the two SEPARATELY the shoulder as well as the Z... also, while we're at it. I think we're moving the Z in the wrong direction right now...
Yes, so this time it didn't fall over. Now we're trying to see what's the smallest shift we can achieve such that we don't fall on the leg we're lifting. The reason any shifting we do now will be smaller is because we're doing Z-shifting too now instead of just X shifting.
We also need to fix that back left foot that keeps falling off at some point.
OK the FLL steps - now onto the BRL. We're using the SAME technique hopefully we don't fall on our face. So it stepped both but in a really strange way. I want to go look at the old walking videos just to see if those are better or worse or if we need to change the shifting a little more. https://www.adim.io/post/chip-updates-let-s-try-making-this-thing-take-a-few-steps-omg-it-walks-updates
Yes so if we look here this walking was slightly stranger I think we need to lean a little bit less actually. Maybe make the x-shift like -0.03 instead. Let's try that. I think this went too far on the back legs. We'll film the walk at the end when we get it right.
So it's still too much I'm curious to see what's happening with the Z-shift because that seems wrong. Well actually now that I think about it maybe it's just not ENOUGH of a shift... hmmm. -0.07? We'll know if the robot falls over.
One more test and then I think the platform is overheating a little and we might want to give it a break. Yep - just like we suspected 0.07 was too far forward maybe even 0.0 would be fine who knows. Or 0.01! This thing is really overheating - let's turn the robot back on, and then shut it down properly.
You know the jetson shutting down due to overheating could be because the fan inside is blocked. We should either unblock or un-plug the fan.
WE'll continue this later now that we've kind of figured out what's happening. And we'll shut the platform down now then.
At some point, maybe, we should time how long it takes for the jetson to overheat - or find a way for ROS to monitor and display the system temperature.
Let's wait a few hours and what we'll do is add this line into the launch file and install this as it WILL publish the CPU's temperature and etc. Then we can determine if the jetson shutting off is due to overheating or not.