Simba GaoMECHANICAL / MECHATRONICS
← All projects

ROBOTICS / MECHANICS & CONTROL

Quadruped
MPC Control

I built a simulated quadruped, reduced walking-speed error by 72% from its initial controller, and kept motor control running independently of motion planning.

My role Mechanical modeling, leg kinematics, walking controllers, and simulation testing.

  • MuJoCo
  • Robot kinematics
  • Model predictive control
  • Control architecture
Actual 12-actuator MuJoCo quadruped model with mirrored leg chains on a checkerboard ground plane.
Custom MuJoCo model · 3 powered joints per leg

CUSTOM MECHANICAL MODEL · SIMULATION-ONLY VALIDATION

11.8 kgModeled robot mass
12Actuated joints
72%Less walking-speed error*
5 / 5Walking trials passed after separating planning from motor control

*Compared with the initial joint-position controller in 20 s simulations with ideal motors; includes gait and controller improvements.

01 / ENGINEERING PROBLEM

Making the robot walk
and follow a command

Getting the legs to move was only the first step: the robot also had to follow a requested speed without slipping or exceeding motor limits. I progressed from joint-position control to choosing foot forces, then to planning those forces ahead of time. The final challenge was letting that slower planning run without interrupting motor updates.

02 / METHODS & ANALYSIS

How I developed the system

Model → walking control → independent planning

01

Build and check the robot model

TORSO / TOP VIEW500 mm240 mm8 kg torsoFree-moving body · modeled mass and inertiaMirrored hip offset: 50 mm / side ONE LEG / SIDE VIEWHip pitch · YKnee · Y200 mm200 mmR25 mm footAbduction · X (out-of-plane motion)
3 joints / legHip / thigh / knee: 12 / 18 / 18 N·m limits
1.5 Hz diagonal trot50 mm swing clearance · smooth ramp
Foot placement checked400 randomized leg poses
I defined the link geometry, masses, joint axes, and motor limits, then checked the relationship between joint angles and foot positions. After establishing standing with joint-position control, I generated smooth foot paths for a diagonal trot.
02

Improve how closely it follows the requested speed

The initial trot stayed upright but tracked speed poorly. I added ground-reaction-force (GRF) control to choose how each foot pushes against the ground, then model predictive control (MPC) to plan those forces ahead.

Walking-speed error m/s · root mean square error · lower is better

Requested speed: 0.15 m/s

Joint positions0.0836
Motion feedback0.0718
Foot forces (GRF)0.0263
Predictive (MPC)0.0231
Moved stance feet back 25 mm

This reduced the conflict between pushing forward and keeping the body balanced.

Added a leg-posture correction

A force plan could be valid while the legs still drifted; a small restoring torque controlled that motion.

Respect foot gripStay within motor torque limitsPlan 100 ms ahead
20 s trials with ideal motors. Gait settings changed with each controller, so the improvement reflects the complete control system.
03

Keep motor updates running while planning

A new motion plan took longer than one motor-update interval. I moved planning into a separate process so motor control could use the latest valid plan without waiting.

MOTOR CONTROLLER Updates targeted every 2 ms

  1. Read the robot’s motionJoint positions, body motion, and foot contact
  2. Use the latest valid force planSwitch to GRF control if the plan is unusable
  3. Update joint torquesContinue moving the simulated robot
Robot motion →A copy of the current measurements
← New force planHow each foot should push

The two processes run independently.

MOTION PLANNER (MPC) New plans targeted every 10 ms

  1. Read the copied measurementsStart from the robot’s current motion
  2. Plan the foot forcesAccount for balance, grip, and motor limits
  3. Send back the new planMotor control checks it before use
Planning delayed or unavailableSimpler GRF controller takes overMotor updates continue
Walking continued during tested planning slowdowns, stalls, and shutdown. If a plan arrived too late or no longer matched foot contact, the simpler GRF controller supplied forces instead.
Learn more: timing measurements and failure tests

How quickly did a new plan become usable?

Across five 20 s desktop trials, an average of 6.62 ms elapsed from reading robot motion to using a new foot-force plan; 99% of used plans took 8.65 ms or less. These figures include calculation and transfer time, and exclude rejected plans.

Did motor updates stay on schedule?

The target was one update every 2 ms. The average rate reached 500 updates per second, but 1.76% finished late, so this is not a guaranteed real-time controller.

What happened when planning failed?

I added computation load, paused planning for 120 ms, injected 20 invalid plans, and stopped planning 6 s into a 12 s test. The GRF controller took over and the robot passed the walking checks.

The simulated robot also pauses when its main program pauses; physical hardware would not. These tests demonstrate software behavior, not hardware safety.

03 / RESULTS & OUTCOME

Simulation results

TESTED IN DESKTOP SIMULATION

Nominal walking 10 s · normal speed

All three controllers completed the walking trial.

Lateral push 12 s · half speed

With simulated motor delay, the right-hand robot regained speed but made body-ground contact, failing the test.

In each clip, left to right: foot-force control, predictive control, and planning separate from motor control. Motor models differ.

5 / 5Repeated 20 s walking trials met gait and speed-tracking criteria with planning running separately.
Walking continuedThe simpler force controller took over when predictive planning was delayed, invalid, or stopped.

Simulation only; physical robot testing is still needed.