Dog Quadruped Embedded Controller

Dog Quadruped: Embedded Controller for Competition Obstacles

ROBOCON | 2023 | Nanjing, China

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
Case Type Embedded control deep dive
Technical Center STM32F407, dual CAN, IK/Jacobian VMC, obstacle-state FSM
Outcome Cleared the double-board bridge and 40 cm high-bar obstacles; the project won National Second Prize at ROBOCON.
Ownership Owned the Dog quadruped slice inside the broader ROBOCON team: wiring, motor allocation, gait control, jump states, and field tuning.

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

Dog quadruped STM32, VMC, FSM, and CAN-bus control architecture
The quadruped controller was built as a full embedded slice: SBUS tuning input, STM32F407 runtime, gait and VMC layers, a flat FSM, and two CAN buses driving eight brushless servos.

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 moduleResponsibilityWhy it was structured that way
Dog runtimeRuntime clock, contact phase, leg update loop, and motor command dispatch.Kept gait timing centralized and inspectable.
FSM14 states with enter/run/exit function pointers.Flat C state table was easier to debug than a hierarchy under match pressure.
Leg and VMC mathIK, Jacobian, foot velocity, and force-to-torque mapping.Fit the STM32F407 compute budget while staying explainable.

Control / Simulation Methodology

Dog quadruped leg-control pipeline from foot target through IK, VMC, FSM, and CAN motor commands
The controller is easiest to read as a pipeline: foot target, cycloidal trajectory, inverse kinematics, Jacobian/VMC mapping, state-specific gains, and CAN motor commands.

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.

Dog quadruped obstacle finite-state-machine map for walking, bridge, jump, swing, fall, and recovery states
The FSM map explains why the controller stayed practical: obstacle behavior was split into visible phases, so each phase could carry its own gains, tolerances, and exit checks.

Code Evidence

ModuleWhat it shows
Dog/Src/vmc.cClosed-form inverse kinematics and Jacobian math for the parallel-linkage leg.
Dog/Src/Leg.cCycloidal foot trajectory generation and per-leg phase behavior.
FSM/Src/FSM.cFlat state table with enter, run, and exit handlers.
FSM/Src/State_catJump2.cObstacle-specific jump phases, gains, and arrival-triggered transitions.
Dog/Src/Remote.cSBUS channel mapping for live field tuning of gait period, height, state, and jump behavior.

Validation & Debugging

Dog quadruped field tuning loop from SBUS parameters through FSM phase, obstacle run, observed result, adjustment, and repeat validation
The tuning loop makes the field method explicit: SBUS parameters selected gait and jump behavior, obstacle runs exposed clearance or failure, and gains/trajectory height were adjusted before rerunning the bridge and high-bar tasks.

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.