Code Documentation
This page will go over the code that Stewy runs on. This code contains 6 main files: stewy.ino, controller.cpp, inverse_kinematics.cpp, and walking_pattern.cpp, communication.cpp, and head.ino
All of the code is open source and can be found here.
This is the main file for stewy. It wires together all of the major systems: inverse kinematics motion control, and wireless communication. Stewy.ino also handles how the robot will respond to incoming commands.
On startup, it does three things: gets the WiFi running so you can send Stewy commands from your phone or computer, sets up listeners so it knows what to do when a command arrives, and figures out the right starting position for all six legs.
Once the setup is finished, the main loop runs on repeat. It's intentionally as simple as possible. it just ticks the controller and the Wi-Fi layer on every iteration, keeping all the real logic in the subsystems.
Below is a small snippet from stewy.ino. It shows how Stewy decides what to do when a command comes in over WiFi. Each route maps to a specific action on the controller, so sending "/pose1" moves Stewy to a position, "/setOffsets" trims the servos, and so on.
This file solves one core problem: given where we want Stewy's top plate to be in space, what angle does each of the six servos need to be at to get it there? That's what inverse kinematics means; instead of asking "if I move the servos here, where does the top plate end up?", we ask it backwards.
When the inverse Kinematics solver is first created, it takes in the physical measurements of the robot: arm lengths, how far apart the joints are, and so on. From there it builds a geometric model of Stewy's structure. This happens once at startup.
Now, any time the controller wants to move to a new position or angle, it hands a target pose to the Inverse Kinematics Solver and gets back six servo angles.
This file is responsible for actually moving Stewy. It takes high-level instructions like "walk forward" or "move to this position" and figures out how to execute them smoothly in real time.
There are two main things it handles. First, movement between poses. When you send Stewy a new position to move its top plate to, the controller plans a smooth path to get there instead of snapping directly to it.
Second, it handles the joystick. It reads the raw joystick input, applies a deadzone so small accidental nudges don't do anything, and maps the stick position to either a walking direction or a body movement depending on what mode you're in. Clicking the joystick cycles through the available modes.
It also has basic collision avoidance. If the distance sensor sees something close, it smoothly shifts Stewy's head back to get out of the way.
This file handles everything wireless. It's what lets you send commands to Stewy from your phone or computer without a USB cable plugged in.
On startup it creates a WiFi network that you connect to directly. Stewy acts as its own hotspot rather than connecting to your home router. It also spins up two ways to receive commands: HTTP for sending poses and settings, and UDP for the joystick. HTTP is better for one-off commands where you want a confirmation back. UDP is a lighter, faster protocol that just fires packets as fast as possible, which is what you want for real-time joystick and other sensor input.
This file doesn't know or care what any of the commands actually mean. It just receives them and hands them off to the callbacks registered in stewy.ino. That keeps the networking logic cleanly separated from the motion logic.
This file defines how Stewy walks. The gait is built around a set of sine waves that were found by a genetic algorithm. The genetic algorithm is a separate program that evolved thousands of candidate walking patterns and kept the ones that worked best. The algorithm I went into detail about in this video.
This file takes that solution and adds a few modifications on top to make the walking smoother and allow for variable speed and direction.
This is the firmware for the second ESP32 that lives in Stewy's head. It's completely separate from the main code. Its only job is to read the joystick and the ultrasonic distance sensor, then fire that data over WiFi to the main ESP32 20 times per second.
It connects to the hotspot that the main board creates, packages up the joystick position, button state, and distance reading into a small packet, and blasts it over UDP. The main board picks that up in communication.cpp and passes it along to the controller.