Adaptive Hexapod:
CPG Locomotion Engine

The Regolith Problem

Loose, granular regolith, the kind NASA's Lunabotics competition simulates and the kind that covers the Great Sand Dunes, is a nightmare for traditional rovers. Wheels spin out, dig holes, and get stuck.

To guarantee traversal over that terrain, I abandoned wheels entirely and designed a six-legged hexapod capable of stepping over loose sand rather than rolling through it. The real proving ground ended up being the Colorado Space Grant Robotics Competition, held right on the dunes.

Inverse Kinematics (IK)

I implemented a custom geometric IK engine in C++, validated to sub-millimeter round-trip accuracy across all six legs. It runs in under 0.6ms per leg on the Arduino Mega, fast enough to solve all 18 joints within the 25ms control budget at 40Hz.

The same IK math was independently ported to Python for simulation, where phase-plane visualization confirmed the geometric approach matched the firmware to floating-point precision. This IK engine is what both the CPG research below and the simpler gait that actually raced (05__GAIT) are built on top of.

Central Pattern Generator

Real insects don't compute gait keyframes: their spinal cord runs a self-organizing oscillator network called a Central Pattern Generator. The brain sends one signal ("walk faster"), and the CPG handles all inter-leg coordination automatically. I designed the same architecture for this robot.

The key insight: gait type is not a mode switch. It is a continuous function of ω. Change one number, and the wave→ripple→tripod transition emerges from the coupling dynamics automatically. No state machine. No hard-coded offsets. The fixed tripod gait that actually raced is the ω≈5.0 row of this table, hard-coded instead of emergent.

What Actually Raced

With the CPG unfinished, the fielded robot ran a fixed tripod gait adapted from markwtech's reference code, three legs down at all times, simple and proven, driven through our own IK engine. Obstacle handling was a straightforward bump-and-recover loop instead of continuous sensor fusion:

That's it: two front bump switches for obstacles, and the IMU periodically pulling the heading back to forward so small drift doesn't compound over a run.

Frame Replacement

The original FutureTrace kit mounts every servo as a cantilever, the output shaft is the only structural connection between the servo body and the driven leg segment. Every stance phase redirects the robot's full weight radially through that shaft. The stock plastic bushing grinds out within hours. The shaft deflects under load, and that deflection introduces positioning error that compounds through the entire IK chain. Cheap servos fighting shear loads they were never designed for.

Control Loop Budget

The Arduino Mega runs at 16MHz with no FPU. This is the budget for the gait that actually raced (fixed tripod gait, bump switches, and IMU heading correction) inside the 40Hz (25ms) loop.

Total used: ~4.6ms of 25ms available. Plenty of headroom left over: most of it would have gone to the CPG and the extra sensors in 04__CPG, had there been time to finish them.