Autonomous Hexapod — NASA Colorado Robotics Challenge
A four-person team integrated and fielded an 18-DoF hexapod at Great Sand Dunes; my work centered on team integration, electrical/control interfaces, and a later coupled-oscillator gait study.
- Build and field a legged robot that can maintain useful behavior on loose sand under real power, sensing, and integration constraints.
- Fielded team robot + later simulation and verification extension
- It shows the difference between a locomotion idea and a robot that must be wired, powered, repaired, and operated outdoors by a team.
Who did what
- Team lead and systems integrator — electrical/control interfaces, field integration, and later CPG simulation/testing
- Four-person challenge team; physical integration and field operation were collaborative.
- Inherited firmware by Mark W, team-authored code under another GitHub account, and external reference geometry / IK.
Overview
The challenge required a walking robot to operate on loose sand and uneven terrain, where power distribution, sensing, gait stability, and field repair mattered at the same time. I led the four-person team and worked on the electrical/control integration: Arduino Mega, ICM-20948 IMU, bump sensing, LiPo/SBEC power, and a three-bit interface for selecting eight behaviors. After the field project, I built a Python Kuramoto coupled-oscillator simulator in which wave, ripple, and tripod phase relationships emerge from one model, then packaged it with a 34-test suite and visualizations.
Methodology
- Integrated sensing, power, behavior selection, and eighteen servo channels around an Arduino-based team firmware stack for outdoor operation.
- Studied wave, ripple, and tripod phase relationships later in a separate Kuramoto coupled-oscillator simulator with automated checks.
Sensors and a compact behavior interface feed Arduino-based control, which coordinates eighteen servos through inherited and modified gait code. The later CPG simulator studies gait phase relationships separately from the physical firmware.
- IMU + bump sensors
- Arduino Mega behavior logic
- Power + three-bit command interface
- 18-servo hexapod
- Separate Kuramoto CPG study
My contribution
- Led a four-person team through system integration and field operation at Great Sand Dunes National Park.
- Designed and integrated the Arduino/IMU/bump-sensor/power architecture and three-bit behavior-selection interface documented in project materials.
- Worked on heading-hold, calibration, and obstacle-response behavior within the team firmware stack.
- Built the later Kuramoto CPG simulator, gait visualizations, phase analysis, and 34-test CI suite.
- Published field photographs, wiring documentation, firmware context, CAD references, simulations, and explicit attribution notes in one evidence repository.
Provenance & claim boundary
- This is a team project, not a sole-authorship claim. The public repository includes firmware originally written by Mark W and modified for the project, team-authored code under another GitHub account, and geometry/IK derived from an external reference implementation.
- The Python CPG is a later simulation and verification extension; the site does not claim that this exact Python controller ran on the physical challenge robot.
Experimental design
- Fielded the team robot at Great Sand Dunes and preserved photographs, wiring documentation, and physical motion media.
- No repeatable terrain-success protocol was preserved, so field operation is evidence of integration rather than a quantified locomotion result.
Results & evidence
Evidence
Field evidence
attachedTeam and robot photographs at Great Sand Dunes plus physical walking media.
System documentation
attachedWiring, firmware, CAD context, control architecture, and challenge setup.
CPG verification
attached34-test suite with phase, gait, workspace, trajectory, and edge-case checks.
Attribution boundary
attachedTeam, inherited firmware, reference geometry, and later personal extension are identified explicitly.
Metrics
18
4 people
3 bits / 8 modes
34 passing
Failure analysis
- Power delivery, connectors, calibration, loose terrain, and recovery procedures became coupled parts of the locomotion problem.
- The later Python CPG was not the physical challenge controller and cannot be used retroactively to explain field performance.
Limitations
- No repeatable field success-rate protocol or terrain benchmark was preserved, so the project is presented as a fielded system rather than a quantified locomotion study.
- The CPG simulator and physical firmware are related conceptually but were not the same deployed controller.
- Ownership spans teammates, inherited firmware, and reference geometry; contribution claims therefore stay at the subsystem and integration level.
Lessons & tradeoffs
- Field conditions make power, connectors, calibration, and recovery first-class control problems.
- A mathematical gait model becomes more useful when its relationship to the deployed firmware is stated honestly.
- Precise attribution strengthens a team project because reviewers can see both collaboration and individual depth.
Next questions
- How would the coupled-oscillator controller perform when deployed on the physical robot under repeatable terrain conditions?
- Which field metrics can separate gait instability from power, sensing, and operator-recovery failures?