Robot Gaits and Gait Training

Gaits in brief

Every gait is a repeating cycle called a stride. During one stride each foot spends part of the time on the ground, called the stance phase, and part in the air, called the swing phase. Two numbers describe most gaits. The first is the duty factor, the share of the stride that one foot spends on the ground. The second is when each foot lands relative to the others.

By convention, a duty factor above 0.5 counts as walking and 0.5 or below counts as running. A slow walk keeps each foot down for three quarters of the stride. A gallop keeps each foot down for about a third or less, so the body spends part of each stride in the air.

In the 1960s the zoologist Milton Hildebrand showed that any symmetrical gait can be described with three numbers. These are the duty factors of the front and hind feet and the delay between a hind foot and the front foot on the same side. Footfall charts like the ones below, which he used throughout his work, are still standard in biology and robotics.

Types of quadruped gaits

Each chart shows one stride, read from left to right. A bar shows when that foot is on the ground. Blue bars are front feet and teal bars are hind feet. Bars that run past the right edge carry on at the left, since the stride repeats.

Duty factors are typical values chosen to show each pattern. Real animals and robots vary them with speed.

Gaits in simulation

The clips below show a Unitree Go2 model doing each gait in MuJoCo. Each gait is a hand-written foot schedule with the timing from the charts above, with no trained policy behind it. The first hand-written bound and pronk let the back legs do most of the work, so their settings were tuned by a search program. It tries dozens of random variations of the settings in simulation, such as how long each pair of feet stays down and how hard it pushes. It scores each run, here on even front and back ground time, forward travel and staying level. It then tries new variations close to the best scorers and repeats until the results stop improving. This method is called the cross-entropy method, and it took about a minute per gait on a laptop. The robot only keeps its balance on this flat floor. Each clip plays in real time, then part of it again at quarter speed. The camera stays still, so the robot crosses the frame. The four squares in the corner light up while each foot is on the ground, with front feet on top and hind feet below.

The strips below take one full stride of four of these gaits and split it into six moments, left to right. They show the same patterns as the charts, now on the robot's legs.

Static and dynamic stability

A gait is statically stable when the body's center of mass stays above the area between the feet that are on the ground. A robot in a crawl could freeze at any moment and stay standing, since three feet always hold it up. That makes the crawl easy to program and hard to fall out of, but it is slow.

A trot has only two feet down at a time. The robot would tip over if it froze mid-stride, so it stays up by putting the next foot in the right place. This is called dynamic stability, and every fast gait depends on it. Dynamic gaits need sensors that report body tilt, usually an IMU, and motors that react quickly.

Gait and speed

Animals change gait as they speed up, from walk to trot to gallop. In 1981, Hoyt and Taylor measured the oxygen used by ponies on a treadmill. Each gait had a speed where it cost the least energy per distance, and the ponies chose speeds close to those minimums. A later study by Farley and Taylor in 1991 found a different trigger for the trot-to-gallop switch. Horses change gait when the peak force on their muscles and bones reaches a limit, whatever the speed.

The zoologist R. McNeill Alexander compared animals of different sizes with the Froude number. It divides the square of speed by gravity times hip height. Animals moving at the same Froude number tend to move in similar ways. Humans switch from walking to running at about 0.5. Horses switch from walk to trot at about 0.35.

The same idea helps robots. A small robot like the Pupper v3 should change gait at a much lower speed than a large one like Spot. Many robots keep a single trot at every speed, since one gait is simpler to control.

Robots that switch gait on their own as they speed up are still mostly research. In 2021, a Berkeley team trained a Unitree A1 with a reward for saving energy and nothing about gait. It walked at 0.375 m/s, trotted at 0.9 m/s and bounded at 1.5 m/s. A 2025 study got a Unitree Go1 and an ANYmal C to pick a four-beat walk at low speed and a trot at high speed. An EPFL policy for the A1 switched between trotting and pronking by itself to leap gaps of up to 30 cm.

Robots on sale offer a menu of gaits instead, chosen with the app, remote or code. The Unitree Go2 has modes such as classic walk, free walk, running, bound and cross step. The DEEP Robotics Lite3 has flat-ground and rough-terrain gaits, and its manual says which to use on each surface. The Xiaomi CyberDog 2 adds bound, pronk and a three-legged gait. Even Spot's automatic setting usually just picks a trot, with crawl, amble, jog and hop as separate choices. Its automatic stairs mode is the closest a commercial robot comes to changing gait on its own.

The usual way to compare gaits, robots and animals on efficiency is the cost of transport. It divides the power used by weight times speed, so it has no units and a lower number is better. Energy penalties during training lower it, and makers quote it less often than speed.

Biped gaits

Two-legged robots have fewer gaits than four-legged ones. Most of the difference between them is whether both feet are ever on the ground together, or both in the air.

Balance methods for bipeds

The hard part for a biped is balance. The support area under two feet is small, so small errors tip the robot. The same walk or run can be produced by very different control methods.

• Zero moment point. The zero moment point, introduced by Miomir Vukobratović and Davor Juričić in 1968, is the point on the ground where the floor's push on the foot produces no tipping moment. A robot stays upright while this point stays inside the area under its feet. Honda's ASIMO planned every step this way. It is reliable on flat floors but gives the careful, bent-knee walk of early humanoids.
• Pendulum models. The linear inverted pendulum model (Kajita and others, 2001) treats the robot as a weight on a stick with the body held at one height. It makes the math simple enough to plan steps in real time.
• Trajectory optimization. Boston Dynamics' Atlas parkour was built from a library of moves planned ahead of time. A model predictive controller adjusted force, posture and timing while it ran.
• Reinforcement learning. Cassie, from Agility Robotics and Oregon State University, ran 100 m in 24.73 seconds in May 2022 with a controller trained by reinforcement learning. That set the Guinness record for a two-legged robot. Most new humanoids, including the Unitree G1, H1 and Booster T1, now walk with learned policies.

The training methods in the rest of this guide work for bipeds as well. Bipeds usually need more training, since there are more ways to fall.

Hexapod and wheel-leg gaits

Six-legged robots such as the SpiderPi have an easier job. In the tripod gait, the front and back legs on one side move with the middle leg on the other side, so three legs are always down. The ripple gait moves two legs at a time and the wave gait moves one, each slower and steadier than the last. All three are statically stable, which is why hobby servos are enough for a hexapod.

Wheel-legged robots such as the Go2-W and Ascento roll on flat floors and only step when they meet a curb or stairs. Their trained policies command wheel speed and leg joints together, so the "gait" is mostly a choice of when to lift a wheel.

Gait control methods

These methods are often combined. Marc Raibert's one-legged hoppers at MIT in the 1980s treated running as a bouncing spring. That work is the root of most dynamic gait control and of Boston Dynamics. In 2018, MIT's convex MPC ran eight gaits on the Cheetah 3 with one set of settings, including trot, pronk, bound, pace and gallop, up to 3 m/s. Spot uses MPC. In 2024 Boston Dynamics added a learned policy that sets the targets for a single MPC, which replaced running many MPC plans at once and picking the best. In 2025 the RAI Institute trained a running policy for Spot that passed 5.2 m/s, more than three times its standard top speed.

Gait training with reinforcement learning

Most new legged robots learn to walk with reinforcement learning (RL). Thousands of copies of the robot practice in a physics simulator at the same time. A neural network, called the policy, reads the robot's sensors and outputs joint targets. A reward score tells it how well each attempt went, and the training algorithm, usually PPO, slowly improves it.

• Inputs. Body tilt and spin from the IMU, joint angles and speeds, the last action, and the command, such as "walk forward at 1 m/s". Robots that see the ground also get a height map.
• Outputs. A target angle for each joint, usually 50 times per second. A fast position controller on each motor turns those targets into torque. Some research robots run their policies faster, such as ANYmal at 200 to 400 times per second.
• Rewards. The main reward is for matching the commanded speed and turn rate. Smaller rewards and penalties shape the gait. Common ones include time each foot spends in the air, foot clearance, foot slipping, body tilt, motor torque, energy use and sudden changes in the action.
• Domain randomization. Friction, body mass, motor strength, sensor noise and delays change randomly in every practice run. A policy that copes with all of them is more likely to work on the real robot.
• Phase signals. Many policies get a clock input, the sine and cosine of the gait phase, and a reward for foot contacts that match it. This is how Walk These Ways picks a gait, and how MuJoCo Playground's feet-phase reward and Stanford's gait-tracking reward shape the trot.
• Commands. The command is usually three speeds, forward, sideways and turning. Training samples all three at random, so walking backwards, sideways and in circles comes with no extra gait.
• Curriculum. Training starts on flat ground. Robots that do well move on to slopes, rough ground and stairs. ETH Zurich's legged_gym raises stair height from 5 to 20 cm this way.

The simulator is the base of all this. The MuJoCo Guide covers MuJoCo itself, robot models, GPU versions such as MJX and how simulators compare. The sim-to-real glossary entry covers moving a trained policy onto hardware.

Reward hacking in simulation

The clips below come from a test run for this guide. A 7 kg robot dog model was trained in MuJoCo with PPO on an Apple M3 laptop, for 20 minutes and about 5.5 million steps per run. The model has realistic motor limits, a 3 to 5 ms command delay, sensor noise and battery sag. Its weight, floor grip and motor strength changed in every practice run. Only the reward changed between the three runs. The squares in the corner light up for each foot on the floor.

The clock policy walked in all 45 test runs on five versions of the model. These included one 10% heavier with weaker motors, one with a slippery floor and one with a lighter battery. At 0.9 m/s it drew 125 W. An earlier 8-minute policy trained without the gait rewards drew 329 W at the same speed and pattered at about 9 steps per second per leg. The clock policy still fell short at the top of its range, reaching 1.2 m/s on a 1.5 m/s command. Longer training, usually on a GPU, is the normal way to close that gap.

From simulation to the robot

The trained network is exported, usually to ONNX, and runs on the robot's own computer at the same rate as in training. The position controller on each motor must use the same gains as the simulator, or the gait changes. Many teams first run the policy in a second simulator, such as MuJoCo after Isaac Lab, to catch policies that only work in one physics engine. Unitree's own training code does this before every hardware test.

First runs on hardware are done with care. The robot hangs from a harness or gantry, torque limits are set low, and a person holds a controller with a stop button. Starting from a crouch and a slow trot, then raising the limits, is the normal order.

Milestones in learned gaits

Training platforms and computers

Fast RL training runs thousands of simulated robots at once on a graphics card. Most published robot dog training uses one of the frameworks below.

No local graphics card is needed to start. Stanford's CS123 course trains the Pupper v3 walking policy in Google Colab, which runs in a web browser on Google's GPUs. In the fall 2026 course, a run with 4,096 simulated robots takes about 18 minutes on Colab's RTX Pro 6000 runtime. Colab Pro costs $9.99 a month. The free tier sometimes offers a GPU, but sessions end after at most 12 hours, and Google does not promise which GPU is available. Rented cloud GPUs are another option. An RTX 4090 cost about $0.15 to $0.90 an hour on Vast.ai and RunPod in October 2026 (estimate).

Apple Silicon Macs can train small policies on the CPU with plain MuJoCo. JAX-based tools such as MJX and Playground fall back to the CPU on a Mac, and Isaac Lab does not run there at all. In a test for this guide, an Apple M3 laptop with 8 CPU cores simulated the Pupper v3 at about 146,000 physics steps per second across all cores. With a policy acting every 5 physics steps and the time spent updating the network, that works out to roughly 5,000 to 15,000 training steps per second (estimate). An A100 GPU runs MuJoCo Playground's Go1 task at about 417,000 steps per second. The robots differ, but the laptop is roughly 30 to 80 times slower. Laptops without a fan also slow down during long runs as they heat up.

Training specific gaits

A policy trained only to follow a speed command usually ends up trotting, since a trot is stable and efficient for a robot dog. Other gaits need extra rewards or a fixed foot schedule. The table gives rough training sizes for small robot dogs. Real numbers vary a lot with the robot, rewards and settings.

The GPU times match published results. legged_gym trained flat walking in under 4 minutes and rough ground in about 20 on an RTX A6000. MuJoCo Playground's Go1 walking policy trains in about 7 minutes on an RTX 4090. Its full recipe uses 100 million steps on flat ground, then 150 million more with wider commands and rough ground. Stanford's CS123 course uses at least 300 million steps for its final Pupper v3 policy, and a strong policy from scratch used about a billion. Most projects need many training runs to tune rewards, so a 20-minute run often turns into days of work.

Open-loop moves are a cheaper option. A fixed sequence of leg poses can be tuned on an ordinary laptop in minutes by the same kind of search program used for the bound and pronk above, as in the MuJoCo Guide's flip and jump examples. These moves do not react to the robot's sensors, so they break easily on a real floor. A trained policy is the usual way to make the same move reliable.

Purpose of gait training

• Speed. Hand-tuned controllers rarely reach a robot's full speed. Learned policies set speed records on ANYmal, Mini Cheetah and Spot.
• Energy use. Penalties on torque and energy give gaits that use less battery. ETH Zurich's 2019 ANYmal policy ran faster while using less torque and power than the hand-built controller.
• Robustness. Domain randomization gives policies that cope with slippery floors, carried weight, worn motors and shoves. Boston Dynamics reported about one fall per 50 km across its Spot fleet.
• Terrain. Trained policies cross grass, gravel, sand, snow and stairs, and adjust step height and timing as they go.
• Recovery. A robot that can get up after a fall can work without a person nearby. Pushes and falls below covers how this is trained and tested.
• New moves. Jumps, flips, handstands and parkour are trained the same way, using different rewards.

Steps, stairs and obstacles

To climb a step, a robot needs to lift each foot high enough, place it on the tread, and shift its weight at the right moment. Gait training handles this in two ways.

• Blind (proprioceptive) policies use only joint sensors and the IMU. They feel a step when a foot hits it and react, much like a person climbing stairs in the dark. ANYmal (2020), the Unitree A1 with RMA (2021) and Cassie on stairs (2021) all worked this way. Blind policies are robust, but they cannot plan ahead and can trip on tall or unusual steps.
• Perceptive policies also read a height map built from depth cameras or lidar. The policy sees the step coming, lifts its feet in time and places them on the tread. ANYmal's 2022 mountain hike and the parkour policies of 2023 and 2024 used this approach. The Robot Vision page compares the sensors.

Leg length sets a basic limit. Spot is rated for steps up to 30 cm, and the Unitree Go2 for about 15 to 16 cm. Learned parkour policies go well past these everyday ratings. One 2023 policy jumped onto boxes twice the robot's height. Ratings are lower than these record results, since a commercial robot needs to climb stairs reliably all day.

Pushes and falls

A robot dog in a home or on a street gets bumped, kicked and tripped. Two skills cover this. Push recovery keeps the robot on its feet, and fall recovery gets it back up when that fails.

• Training with pushes. Random shoves during practice teach a policy to catch itself. ETH Zurich's legged_gym gives the robot a push every 15 seconds that changes its body speed by up to 1 m/s. MuJoCo Playground's Go1 walking task has optional kicks of up to 3 m/s, lasting 0.05 to 0.2 s, every 1 to 3 seconds.
• Measuring push recovery. A common test is a short side force on the body, sized by the speed it would give the robot if nothing held it back. The result is the largest push the robot always survives, standing and walking.
• Getting up. Fall recovery is usually its own policy. Each practice run starts with the robot dropped in a random pose, on its side, back or belly. The reward is for being upright, at full height and in the standing pose. Playground's Go1 get-up task works this way.
• Switching between skills. A small supervisor decides which policy runs. ETH Zurich's 2019 ANYmal controller used four neural networks, for self-righting, standing up and walking, plus a learned selector between them. ANYmal got back up from any fall in under 5 seconds, failing 3 times in more than 100 falls. A hand-written state machine as the selector did worse in unusual cases.

Commercial robots ship fall recovery as a single command. The Spot SDK has a self-right command, and Unitree's SDK for the Go2 has a recovery stand call.

Push test in simulation

A push test like this one is a standard step in checking a new robot dog design, covered with the other tests in Quadruped Design Validation. The trot policy from the reward-hacking example was pushed from the side for 0.1 s, from the left and the right, standing and walking. It never saw a push in training. It always stayed up after a push worth 2 m/s, which is 142 N for 0.1 s on the 7 kg model. Walking at 1 m/s it also survived the largest push tested, 2.5 m/s. It caught itself by stepping sideways about 30 cm, tilting only 11°. The same model holding its standing pose without the policy fell over at 2 m/s.

Hardware limits

A trained gait is only as good as the motors that carry it out. Dynamic gaits need motors that are strong, fast and quick to respond, and that report torque or current accurately.

Software access matters as much as the motors. A learned policy needs to send commands to each joint many times per second. Many consumer robot dogs only accept walking commands such as "go forward". Unitree rates only the Go2 EDU as fully open for custom low-level control, and Walk These Ways needed the Edu version of the Go1. Kits built for research, such as the Pupper v3, give full joint control from the start.

Pupper v3$1,450 – $2,480Go2 EDU / EDU Plus$11,190 – $15,600Go1Was $2,700 – $8,500+MIT Mini CheetahNot for saleANYmal CWas about $150,000Bittle / Bittle X$289 – $469

Limitations of learned gaits

• The sim-to-real gap. Every simulator differs from the real robot. Motor delays, gearbox backlash, flexible parts and battery sag are hard to model. Policies that look perfect in simulation often shake, slip or fall on hardware.
• Reward hacking. A policy finds any loophole in the reward. Common results are dragging a knee, hopping on two legs or vibrating the feet. Fixing these takes many rounds of training, as in the simulation example above.
• Hard to explain. A neural network gives no clear reason for a fall, so problems are found by testing.
• Computing. Fast training needs a data-center or gaming GPU. Without one, training takes hours or days per attempt.
• Hardware wear. Dynamic gaits and jumps strain motors, gears and legs. Testing on real robots breaks parts.
• Narrow skills. A policy trained for one robot, gait or speed range can fail outside it. Changing the robot's weight or leg length often means training again.