Dog Quadruped Embedded Controller
Dog Quadruped: Embedded Controller for Competition Obstacles
Team: Jiacheng Li Yongye Hu Zhixiong Zhang Kehao Chen Guanshao Lin Junbo Shan Minkang Gong Chao Liu Xingzhi Li Yeying Wang Show all
Advised by: Professor Yu Hou
Embedded Controls / Robot Builder
Cleared the double-board bridge and 40 cm high-bar obstacles; the project won National Second Prize at ROBOCON.
- STM32F407
- Embedded C
- CAN bus
- VMC
- PID control
Hardest engineering problem: The robot needed obstacle-specific motion that was explainable and tunable on STM32 hardware, without relying on heavy MPC or learned policies.
Overview
This quadruped was built for a ROBOCON obstacle course with a double-board bridge and a 40 cm high bar. The design constraint was practical: deliver reliable motion on STM32F407 hardware within a competition timeline, without heavy MPC or learned policies.
My Role
I owned the dog quadruped as a self-contained slice of the broader team build: hardware design, motor wiring across two CAN buses, and the embedded control stack for gait, jumping, and obstacle-specific states.
Key Results
- Cleared the double-board bridge and 40 cm high-bar obstacles that drove the controller tuning.
- Built a 33-source-file embedded-C controller for 8 brushless servos across two CAN buses.
- Implemented inverse kinematics, Jacobian-based force/velocity mapping, cycloidal foot trajectories, gait selection, and a 14-state FSM.
- Contributed to a project that won National Second Prize at ROBOCON.
3D Model Overview
System Architecture

Hardware Interface
Eight HT brushless servos were split across two CAN buses, with each leg modeled as a two-motor 5-bar linkage.
Motion Stack
Closed-form inverse kinematics, Jacobian mapping, cycloidal foot paths, and per-leg phase bias generated obstacle-specific motion.
Debug Surface
SBUS channels exposed gait period, body height, state selection, and jump tilt for live field tuning.
Software / Firmware Architecture
| Firmware module | Responsibility | Why it was structured that way |
|---|---|---|
| Dog runtime | Runtime clock, contact phase, leg update loop, and motor command dispatch. | Kept gait timing centralized and inspectable. |
| FSM | 14 states with enter/run/exit function pointers. | Flat C state table was easier to debug than a hierarchy under match pressure. |
| Leg and VMC math | IK, Jacobian, foot velocity, and force-to-torque mapping. | Fit the STM32F407 compute budget while staying explainable. |
Control / Simulation Methodology

The control architecture used Virtual Model Control instead of MPC or reinforcement learning because it was the fastest reliable path for the deadline, hardware, and team skill profile. The finite state machine stayed flat rather than hierarchical because C enum states with enter/run/exit function pointers were easier to inspect, tune, and debug on embedded hardware.
Jumping was promoted into first-class states instead of being hidden inside a trotting mode. READY, JUMPING, SWING, and FALLING each needed separate PD gains, arrival tolerances, and exit conditions, so explicit states made tuning and verification cleaner.

Code Evidence
| Module | What it shows |
|---|---|
Dog/Src/vmc.c | Closed-form inverse kinematics and Jacobian math for the parallel-linkage leg. |
Dog/Src/Leg.c | Cycloidal foot trajectory generation and per-leg phase behavior. |
FSM/Src/FSM.c | Flat state table with enter, run, and exit handlers. |
FSM/Src/State_catJump2.c | Obstacle-specific jump phases, gains, and arrival-triggered transitions. |
Dog/Src/Remote.c | SBUS channel mapping for live field tuning of gait period, height, state, and jump behavior. |
Validation & Debugging

The controller was validated against the actual competition obstacles, not just a generic walk demo. Per-state PD gains and exit conditions were tuned for the double-board bridge and 40 cm high-bar tasks, while SBUS inputs let me adjust gait and jump parameters live during field testing.
The important engineering decision was choosing the architecture the team could stabilize: explicit states, visible gains, and inspectable transitions.
What I Would Improve
For a later version, I would add structured telemetry around state transitions, foot targets, and motor current so tuning could move from visual field judgment to logged evidence. The control architecture was practical and shippable, but better logs would make the next optimization cycle much faster.
