A new library that lets ArduPilot walk on two legs for the first time.
Mentors: Nate Mailhot & Rhys Mainwaring | Timeframe: May to August 2026 | Project: Google Summer of Code
1. Introduction
Hello ArduPilot community! I am Neeta Misericordia, a Computer Science graduate student at St. Johnβs University in New York.
The GSoC 2026 ArduHumanoid project goal is to prove ArduPilot can command a small humanoid-style jointed frame, with a basic control interface and a simple simulated environment.
When I found this project on the Google Summer of Code 2026 list, one fact stopped me: ArduPilot runs on over a million vehicles and has never walked on two legs. A GSoC 2020 project added quadruped (four-legged) support [2], and that work is the foundation this project builds on. But a biped humanoid (two legs, upright, dynamically balancing) has never been attempted in ArduPilot. No codebase, no PR, no prior attempt. I applied the same day. My mentors are Nate Mailhot and Rhys Mainwaring, and I am grateful to be working on something this novel.
2. Problem Statement
This project builds AP_Biomimetic a new C++ library inside ArduPilot Rover that gives ArduPilot legs for the first time, with a bidirectional joint feedback interface that works in both simulation and on real hardware.
ArduPilot has never had to think about legs. The entire actuator model in the codebase is
one-way: send a command, the actuator moves, that is the end of the story. For drones and rovers
that is completely fine. For a humanoid robot it fails immediately.
Three things that do not exist in ArduPilot today:
-
A vehicle mode that understands legs, foot sequencing, weight shift, and coordinated
balance. -
Any mechanism to read joint position, velocity, or torque back from actuators.
-
A simulation setup that locks humanoid physics and flight control in step at the
timescales legged locomotion needs. -
This project builds all three inside Gazebo Harmonic and ArduPilot SITL without modifying
anything drones and rovers already depend on.
3. The Core Research Problem
Position control alone is not enough. The robot can stand because all joints are at 0 rad and
CoM is perfectly centered. The moment you move any joint that shifts CoM, it falls. This
means **ArduPilot** cannot just command raw joint angles. It needs to command*
***balance-aware joint targets**. That is the core research problem.
Think of it like a tightrope walker. The walker does not just move their feet wherever they want.
Every foot placement has to keep the body balanced over the rope. The robot is the same. Moving
joints without thinking about balance is like the tightrope walker randomly shifting their weight.
They fall every time.
The concept that makes this tractable is called the Zero Moment Point (ZMP), a well-established
stability criterion in legged robotics formalized by Vukobratovic and Borovac (2004) [1]. If the ZMP
stays inside the support polygon (the area under your feet), you stay upright. If it drifts outside,
you tip over.
4. What Is Working Today
One blocker took days to find: ignition-gazebo plugin names fail completely silently. Joint
controllers were never loading and there was nothing in the logs to find. No error, no warning, just
silence. Once that was fixed the stack came together fast.
Watch the prototype walk: github.com/Neetagrg/humanoid-ardupilot-sitl
Confirmed working as of this post:
- ArduBiped_Proto (8-DOF custom humanoid built from scratch) stable in Gazebo
Harmonic with correct joint limits, inertia tensors, and contact frames. - ZMP preview controller in Python: Linear Inverted Pendulum Model, 20-step lookahead
horizon, DARE-precomputed gains. - Lua library complete: joints, balance, gait, and IK modules. humanoid.lua loads and runs
inside ArduPilot. - EKF3 attitude feedback working via the ardupilot_gazebo plugin.
- Robot walks 3+ consecutive steps under Lua gait control.
The primary simulation target going forward is the ROBOTIS OP3, already validated in Gazebo
Harmonic by my mentor Rhys Mainwaring. ArduBiped_Proto stays as a secondary test at every
milestone to confirm the library ports cleanly between robots.
5. The Design
Bidirectional Joint Feedback: The Missing Piece
Humanoid servos are not like drone motors. Most AP controllers set servos to a value but get
no feedback from them at all. What makes humanoid robot servos fundamentally different is that
they are two-way devices: every control tick they report back position, velocity, and torque. That
bidirectional joint-state feedback is what a balance controller depends on to decide what to
command next. ArduPilot has no mechanism for this today. Building this return path is what this
project adds.
AP already handles servo telemetry via the existing AP_Servo_Telem library. The plan is to wire humanoid joint state into this existing infrastructure via DroneCAN actuator.Status messages β position, velocity, and force fields map directly to what the balance controller needs. For simulation, a Python bridge script reads joint state from Gazebo and publishes it as DroneCAN messages at 50 Hz, based on the prototype Rhys Mainwaring built for ESC telemetry [4]
6. One Library, Any Robot
The schema abstraction means AP_Biomimetic runs on both robots in this project with zero
code changes. ArduBiped_Proto has 8 DOF (6 currently active, ankles fixed). ROBOTIS OP3
has 20. Same library, same code, only the config file changes.
If you want to really understand how the joint map and gait planner fit together, I built an interactive walkthrough you can step through live: neetagrg.github.io/humanoid-ardupilot-sitl/stepper.html
7. Why Moving Joints Is Not the Same as Walking
The quadruped work that came before this project showed something important: moving joints
does not equal walking. What is missing between joint movement and forward locomotion?
The answer is coordinated stepping with weight shift and balance. Before the robot can lift a
foot, it has to move its entire body weight over the standing foot. Then step. Then shift weight
again. Then step again. Each of these weight shifts has to keep the ZMP inside the support
polygon the whole time or the robot falls.
That is why AP_Biomimetic needs gait primitives and a ZMP controller. Raw joint angles are not
enough. The planner has to think about where the body weight is at every moment during the step
cycle.
8. Next Steps and Final Submission Goals
The Lua gait controller proves the concept works. The next phase is replacing it with the full C++ AP_Biomimetic library and demonstrating it on the ROBOTIS OP3. The final two weeks will port to the Unitree H1 - two robots at very different scale is the strongest possible result for the project.
| What | When |
|---|---|
| Replace Lua gait controller with AP_Biomimetic C++ library on ROBOTIS OP3 | June |
| Wire humanoid joints into AP_Servo_Telem via DroneCAN actuator.Status | June / July |
| Activate hip roll joints for lateral weight shift during stepping | July |
| Port AP_Biomimetic to Unitree H1 β prove same library works on a full-scale robot | August |
| SITL test cases and automated checks | August |
| Setup guide: SIM_JSON bridge config, lockstep tuning, failure modes | August |
| Final demo video and PR to ArduPilot | August |
Stretch goal: MAVLink waypoint navigation in AUTO mode so the robot walks to a GPS waypoint. Arms and manipulation are planned for a future Google Summer of Code phase.
9. Get In Touch
Have you worked on legged robots, humanoid sim, or Gazebo with ArduPilot? I want to hear what
you ran into. Reply here, open an issue on GitHub, or find me on the ArduPilot Discord. Thank you for reading and stay tuned for more updates.
References
[1] Vukobratovic, M. and Borovac, B. (2004). Zero-Moment Point: Thirty-Five Years of Its Life. International
Journal of Humanoid Robotics, 1(1), pp. 157-173.
[2] ArduPilot GSoC 2020 β Walking Robot Support for ArduPilot. Available at:
[3] Bhajneet Singh Bedi (2025). GSoC 2025 Wrapping Up: Gazebo Plug-in Model of a Motor. Available at:
[4] Rhys Mainwaring (2024). Sending Gazebo sensor data to ArduPilot using DroneCAN. discuss.ardupilot.org/t/sending-gazebo-sensor-data-to-ardupilot-using-dronecan/125730
[5] AP_Servo_Telem: github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Servo_Telem/AP_Servo_Telem.h
