Robust Rough-Terrain Locomotion with a Quadrupedal Robot

In short: robots that work in natural, urban and industrial settings need to get over steps and stairs, and legs are the way to do it, but only if the robot can plan its own climb.

The paper opens with a simple observation: to get robots working on real tasks, they first have to be able to move safely where the work is. Wheeled and tracked robots cannot reach many of those places. With legs, a robot can climb by choosing safe footholds, moving its limbs around obstacles and adapting its posture to the terrain.

The authors define “rough terrain” as ground with obstacles up to 40 % of the robot’s leg length. ANYmal’s legs are 0.5 m long, so that means obstacles up to about 20 cm. They also set three strict rules for what counts as “robust”:

• Unseen, changing world. The robot has never seen the place before. It must perceive and plan as it goes, and it may be pushed or the scene may change.
• Everything onboard. All sensing and computing is on the robot. Sensors and motors are noisy, drift and lag; nothing is assumed perfect.
• Real time. The robot never stops to “think” about its next step.

In short: a robot that only feels the ground can manage small steps, but for tall ones it has to see them coming and plan. Earlier robots that did plan needed outside help.

A “blind” legged robot relies on touch: it senses its joints and feet, and a good controller can react when a foot hits something. For the paper’s comparison the researchers even set the blind robot’s foot lift by hand to match each obstacle. That works for low steps. But it has two failure modes the paper observed directly:

• Feet placed badly. On a 14 cm step, the blind robot sometimes put a foot right against the step and then hit the edge on the next swing (70 % success stepping up).
• Can’t reach. On a 21 cm step, reaching that high without tilting the body is not possible, so the blind robot never got up (0 %).

What earlier systems could and couldn’t do

Only a few systems met all three rules. Boston Dynamics’ Spot and SpotMini climb terrain and stairs quickly, but little is published about how. Several research groups made the small LittleDog robot climb, but with an external motion-capture system and high-resolution terrain scanned in advance. The Messor II robot integrated foothold selection and motion planning in one sampling-based planner with online mapping, but was tethered to outside computing and power, and its obstacle heights and speeds weren’t reported. Closest is the 90 kg, 1 m tall hydraulic HyQ, which climbed previously unseen obstacles with online state estimation and mapping, still tethered, up to 15 cm (20 % of its leg length) at 7–13 cm/s.

In short: the robot turns its sensor readings into a grid of ground heights around itself, then marks every cell as safe or unsafe to step on.

The height map comes from the authors’ earlier robot-centric elevation mapping. Every cell holds a height plus a lower and upper confidence bound. The map is built from the range sensor and the robot’s own estimate of its motion (from leg kinematics and its inertial sensor) and is updated at 10–20 Hz. No GPS, no external cameras and no matching against a global map are needed, which matters in places with few visual or geometric features. It works with laser scanners, time-of-flight and structured-light sensors and stereo cameras. On ANYmal the team used either a rotating Hokuyo laser (one full turn every 2 s) or an Intel RealSense ZR300 depth camera (20 Hz), mounted front and back.

A few times a second (2–5 Hz) the map is processed into three things:

• Surface normals, the direction the ground faces, from a principal-component fit to the heights around each cell. The controller uses these on slopes (see Results).
• Foothold scores, one number between 0 and 1 per cell (below).
• A 3-D distance field, where every little cube of space stores the distance to the nearest surface. The swing planner uses it (Scene 6).

A score of 1 means a safe foothold; 0 means the foot might slip. Adding the map’s uncertainty as one of the measures keeps the feet away from steps and gaps, where the map is least trustworthy. That makes foothold choice robust even when the robot’s position estimate drifts. Finally the score is thresholded into a simple safe/unsafe flag.

In short: a quick rule suggests where each foot “should” go, and if the map says no, the planner searches nearby spots until one is both safe and reachable.

Step 1: the nominal footstep

The robot walks with a static gait, moving one leg at a time in the order right-hind, right-fore, left-hind, left-fore (a sequence from classic stability analysis). Before every step, a simple geometric rule lays a row of default stances along the straight line from where the robot stands to its goal, spaced by a default step length. The foot that moves next is sent to its place in the next default stance. This ignores the terrain on purpose: it is fast, works from any starting stance, always ends in a neat stance at the goal, and naturally settles into a small offset between left and right feet that helps speed and stability.

Step 2: adjust it

Spots around the nominal foothold are tried in order of increasing distance. A spot passes the terrain test if every cell in a circle of 8 cm diameter around it is marked safe; that is slightly larger than ANYmal’s foot, to allow for the foot rolling. It passes the reach test if the pose optimizer (next section) finds a stable body posture with that foot placed there. The first spot that passes both becomes the adjusted foothold. If the search area runs out, the planner reports that no valid step exists.

In short: to reach a high foothold without falling over, the robot lowers and tilts its body. A fast optimizer computes exactly how, and it is the paper’s key new piece.

When a foot has to go somewhere far from where it was, the body has to move too. Given where the feet are, the pose optimizer finds the body’s full position and orientation (6 numbers) that:

• keeps each foot close to its default, comfortable position under the hip (so the legs have room to move);
• keeps the centre of mass close to the middle of the support area, the shape spanned by the standing feet;
• must keep the centre of mass inside the support area (static stability, optionally with an inward safety margin);
• must keep every leg’s hip-to-foot distance between its minimum and maximum.

It is solved with sequential quadratic programming, using analytic gradients and a smart initial guess (a least-squares fit of the body to the feet that can be solved as an eigenvalue problem). In practice it found a solution in every situation within 0.5–2.5 ms and at most 30 iterations. It is fast enough to be called for every candidate foothold during the search, and it is also used by the controller to move the body smoothly between steps.

In short: the foot’s path through the air is optimized to be short but stay clear of the terrain, and it deliberately steps higher where the map is unsure.

With the foothold chosen, the planner finds the swing path. It simplifies the problem to the foot only, treated as a sphere of 6 cm diameter, and borrows the idea of the CHOMP trajectory optimizer: the path is a smooth spline whose inner points are moved to minimize a weighted sum of length and collision cost. The inner points must also stay between a minimum and a maximum height.

Two details make this robust. First, the distance field is built from the map’s upper confidence bound, not its best guess. Where the map is uncertain, typically at edges, the terrain is treated as taller, so the foot lifts higher and more carefully. Second, the collision cost is shaped into funnels at lift-off and touch-down so the foot can actually meet the ground. The cost is integrated every 50 ms along the path; if the optimizer gets stuck in a local minimum it restarts with more spline points.

In short: the robot plans only one step ahead, but redoes that plan before every step with the newest map, so it adapts to slips, pushes and objects that move.

All parts run in parallel at their own rates (paper Fig. 2). The map is updated at 10–20 Hz and processed at 2–5 Hz. The locomotion planner runs once per step: nominal footstep → foothold search with the pose optimizer → swing path. The resulting motion plan goes to the Free Gait framework, which uses the same pose optimizer to move the body between steps. A whole-body controller at 400 Hz tracks it together with the state estimator.

The controller does not blindly replay the plan. The footholds are given relative to the terrain map, so slips and body errors are corrected. It uses the map’s surface normals to keep contact forces within the friction limits on slopes. Its contact manager makes sure each foot really touches down, handling early and late contacts. This matters because real ground is soft (sand, grass) or moves (a plastic bag), and a plan is never perfect.

In short: with its map and planner, ANYmal climbed steps up to 38 % of its leg length about 9 times out of 10, where walking blind failed. It also handled stairs, slopes and a changing world.

Stepping up and down a single step

The robot was commanded over a flat step of three heights, starting from different positions, ten trials per condition. “Without map” is purely reactive walking with the foot lift set to match the obstacle; “with map” is the full system. Average speed is horizontal distance divided by the time to clear the obstacle.

What this means: the taller the step, the more the map and planner matter: at 21 cm they turn “never” into “nine times out of ten” going up. Going down, the controller’s own step recovery already does most of the work, so the map adds nothing there.

Tilted surfaces

Because ANYmal’s motors are torque-controlled, the controller can use the map’s surface normals to tilt each foot’s friction cone, the range of force directions that won’t slip. On a concave and a convex wooden structure the feet then push “inwards” or “outwards” as needed. Walking over the same obstacles without the normals was not possible.

Stairs and disturbances

Stairs are harder than a single step because the front and hind legs are often several steps apart. On a standard staircase (17 cm rise, 29 cm run), with no prior knowledge of its shape, ANYmal climbed up and down multiple times. Going up was more robust than going down, because heading downwards the robot sees the lower steps poorly. Beyond Fig. 10 and the moved board, the robot also walked over a thin ledge and climbed over a seesaw and over a person lying on the floor.

Compared with the closest prior system

What this means: relative to leg length, the paper reports about a 100 % increase in obstacle height and about a 50 % increase in speed over HyQ, with success rates around 90 %, and no tether for power or computing.

In short: the planner is greedy and simplified on purpose; the authors explain why that was enough here and what comes next.

• One step ahead. Planning only the next step is greedy. It worked reliably for everything tested, including stairs. Earlier work suggests looking several steps ahead only becomes necessary for obstacles above about 50 % of the leg length.
• Foothold first, swing second. The swing path is planned after the foothold is fixed, so a feasible swing isn’t guaranteed. Thanks to the body moving during the swing and ANYmal’s large range of motion, this was almost never a problem.
• Only the foot is checked for collisions. The rest of the leg is ignored. ANYmal’s shank shape avoids most shin collisions (visible in Fig. 8d).
• Going down stairs was less robust than going up, because of the limited view of the lower steps.
• Next: obstacles over 50 % of leg length with a multi-step planning horizon, and higher speed with dynamic gaits such as a trot.