u/SphericalCowww

The walking video can be found here:
https://www.reddit.com/r/robotics/comments/1tghftd/cubic_doggo_full_github_record_it_can_now_walk/

But linking another video here instead. I just find it so cool that the robot moves in sync with RViz :)

Next steps will be to incorporate IMU using CHAMP:
https://github.com/chvmp/champ
If anyone has a recommendation on where to start, like a tutorial or guide, that would be much appreciated.

The robot can now turn in its walk mode, which is the reason for it having 4 extra servos (technically, 8 servos is all it needs for walking). The turning isn't super smooth, though. Will need some additional designs to make it more sturdy.

And here is the full record for the current version of Cubic Doggo (DYNAMIXEL XL430-W250-T with ROS2 Jazzy):
https://github.com/SphericalCowww/CubicDoggo
It covers sections on running 1 servo, 1 leg, and the full robot.

This project was developed by someone in his bedroom who has no robotic background. So no machining, no custom PCB, no special motor,  no gears or tiny delicate parts, and use only free software such as FreeCAD/Cura. Everything is brute, minimalistic, and "cubic". So, no curves in CAD design, all servos are the same, and all connections are made by electronics you can order online.

But if anyone is like me, who tried out the Stanford series and realized, geez, that's tough as heck. Feel free to try out my recipe :)

Update since: https://www.reddit.com/r/robotics/comments/1sq4rip/comment/oioxsel/

Resolved two subtle issues that I would never have been aware of without pondering for days about what the heck could go wrong with a manually coded walking gait. Hopefully, it can help someone in the future who tries to implement the same thing:

1. Avoid cycle-boundary pauses: when using trajectory solvers like TimeOptimalTrajectoryGeneration or RuckigSmoothing traj_gen, the solution always ends at the origin with 0 velocity as intended. To implement continuous gait, however, the JointTrajectory publisher should be used instead.
2. Avoid teleportation: teleportation happens when joints position changes without a trajectory. Like at the end of each gait cycle, I was assuming it always returns to the origin. But in a real robot, it rarely ends up exactly on the origin. Why does this matter? This turned out to be extremely problematic when I applied high friction on my feet (with kitchen sponge clothes), small relative motion on the ground exerted tremendous force in a completely unintended direction, which snapped out the robot's legs. To fix this, the gait needs to be state-aware: the gait starts not from the exact origin, but from when the last gait ends.
3. Extra: Wait for the clock on the Raspberry Pi before running ROS2; otherwise, quite a few nodes will die from having crazy timestamps for reference.

Will add directionality control next, still manually though, and finally tidy up the GitHub for those who are interested. Afterward, I really want to try out RL on ROS2, but will need to enable the IMU and probably strengthen the second servo joint first (the LIDAR so far is just a counterweight, lol)

Full ROS2 + all commercial/3D-print part:
https://github.com/SphericalCowww/CubicDoggo