Porting the locomotion code from the Processing simulation to the STM32 was relatively simple. Some safety checks had to be added to prevent the robot from accidentally crashing its legs into each other. The microcontroller manages the calculation for the locomotion, rotation, IK and everything else in just under 20ms. Surely some optimization is possible to make it run even smoother.
I wrote a simple protocol for controlling the STM32 over UART. This protocol can be used to receive commands either from USB or from the Raspberry Pi Zero. The Raspberry Pi runs a python script that handles the Websocket communication, UART and pygame. As soon as a client connects to the Pi, a website is loaded that can be used to control the hexapod with keyboard, mouse or touch inputs. Pygame allows for a Bluetooth connection with a game controller. The Raspberry Pi translates the commands and sends them via serial to the STM32. The Pi also sends a periodic heartbeat signal, so the STM32 can stop the servos in case the Raspberry Pi freezes up.
This combination of Raspberry Pi and microcontroller works really well. Controlling the hexapod is a lot of fun, especially with an Xbox controller. You can see a video below of how the controller is mapped to the hexapod axes:
Overall, I am happy with how this project turned out. The hexapod walks like I wanted to and can be controlled with surprising precision. The development didn’t always go as smoothy as it might appear from reading these project logs. I actually started working on a simulator in 2014 and shelved the whole project out of frustration, only to dig it up a few years later. Just at the start of this year it really clicked and I got the motivation to go through with the project. In retrospect the ESP32 might have been a possible replacement for both the Raspberry Pi and the STM32. Performance and compatibility with game controller might be an issue though.