I built this hexapod robot by combining an existing leg design with a fully custom body, control system, and power architecture as a way to move beyond purely software-based systems and into something physical. Robotics forces you to deal with constraints that software alone often hides: power delivery, timing, mechanical limits, and the unpredictability of the real world.
The robot uses 18 servos, a custom control stack, and an Xbox controller for teleoperation. It implements a tripod gait for stable walking and supports turning, strafing, and custom movement patterns.
Why a hexapod?
I chose a hexapod specifically because it sits at an interesting point in robotics:
- More stable than bipeds or quadrupeds
- Complex enough to require real coordination and planning
- Simple enough to implement without advanced hardware
The goal wasn’t just to make it move — it was to understand how coordinated motion emerges from relatively simple rules and constraints.
Hardware + software working together
The system is composed of three tightly coupled layers: hardware, control, and software.
Hardware
- 18x MG996R servos (3 per leg)
- Raspberry Pi 5 (primary controller)
- Dual PCA9685 servo driver boards
- 4S LiPo battery
- Dedicated power regulation (buck + BEC)
Control System
- Xbox controller for real-time input
- Analog stick mapping for movement and turning
- D-pad for gait switching
- Buttons for custom actions and animations
Software
- Tripod gait implementation
- Interpolated motion between positions
- Leg grouping and phase coordination
- Real-time input handling
What I built vs. what I adapted
The leg design used in this project was adapted from an existing open-source hexapod design. I used this as a starting point to accelerate development and focus on system-level challenges.
Source: Hexapod Robot (Instructables)
I redesigned the core body structure, including the torso layout, mounting system, electronics integration, and overall system architecture. The project evolved into a full system build rather than a direct replication, with a focus on control, power distribution, and real-time behavior.
What actually made this hard
Building the robot was straightforward. Making it work well was not.
- Power distribution: Managing voltage and current across 18 servos without brownouts or instability.
- Coordination: Ensuring multiple legs moved in sync without conflicting forces.
- Gait stability: Early versions “worked” but were unstable or inefficient.
- Timing and interpolation: Smooth motion required careful control of transitions between positions.
- Debugging: Issues could come from hardware, wiring, power, or software logic.
One of the biggest lessons was that “working” is not the same as “stable” or “usable.” Getting from one to the other required iteration across both hardware and software.
- Hardware exposes flaws immediately — there’s no abstraction layer to hide behind
- Power systems are just as important as code
- Small timing changes can have large physical effects
- Coordination problems grow quickly with system complexity
- Iteration is unavoidable — and valuable
- “Working” hardware is easy — stable, repeatable motion is not
Where this is going
This robot is a foundation for exploring more advanced ideas:
- Switching to ESP32-based control for improved efficiency
- Adding onboard perception (camera, sensors)
- Moving from teleoperation to semi-autonomous behavior
- Exploring adaptive gait and terrain handling
Longer term, this project connects directly to a bigger question I’m interested in: how intelligence emerges when software is forced to operate in a physical world.
(Add photos or videos here as available — final build shots and short clips of movement are ideal.)