Team CERBERUS Wins the DARPA Subterranean Challenge: Technical Overview and Lessons Learned

In short: DARPA built underground places that are as hard as real disasters, and asked teams to send robots in first, with only one person in charge.

The Subterranean (SubT) Challenge was a three-year, $82 million competition run by DARPA, the US defence research agency. Its goal was plain: give rescuers and soldiers a quick picture of an unknown, dangerous underground space before anyone enters, whether that is a collapsed mine, a basement after an earthquake or a cave system. More than 300 people in 20 teams from 11 countries took part.

Robots were tested in four events: a mine Tunnel circuit (August 2019), an Urban circuit in multi-storey underground buildings (February 2020), a Cave circuit (August 2020, cancelled), and the Final Event (September 2021), which combined all three into one course. DARPA named four areas where robots had to improve:

• Mobility: narrow passages, sharp turns, drops, stairs, mud, sand, water and debris that falls when you pass.
• Perception: sensing through darkness, dust, fog and smoke.
• Autonomy: exploring and mapping with little or no human help.
• Networking: getting information out when radio signals can’t pass through rock.

Points came from artifacts: mannequin survivors, phones, backpacks, drills, fire extinguishers, vents, helmets, ropes, gas-filled rooms and a “SubT cube”. In the final, each team had 60 minutes to find as many of 40 as it could. A report scored only if it named the right type of object and placed it within 5 m of the true spot, and a team had only 45 tries. Just one team member, the Human Supervisor, could talk to the robots once they were inside; four “pit crew” members could only set up and prepare the robots before the start.

Where earlier work stopped

Underground robotics is not new. The paper points to a coal-mine inspection robot, a tunnel-inspection platform with an arm, a robot that explored mines using a simplified “topological” map of junctions and corridors, drones that steered by the dark centre of a tunnel or flew along dam pipes, a method for sending compact maps over thin links, and a ground–air pair where the ground robot mapped coarsely and the drone filled in detail. Each solved part of the problem. The SubT rules ruled out the usual shortcuts: fragile autonomy, constant teleoperation, specialising in one kind of underground space, falling apart when sensors are degraded, or depending on a radio link that is always there.

The other finalists took different routes: CSIRO Data61 used tracked robots, Spot legged robots and Hovermap drones with their Wildcat mapping; CoSTAR built the NEBULA framework, which plans with an explicit estimate of its own uncertainty; Explorer combined wheeled robots, drones and a Spot; MARBLE ran Spot and Husky robots; CTU-CRAS-NORLAB fielded one of the most varied fleets; Coordinated Robotics and Robotika brought wheeled and flying robots.

In short: legs for rough ground and long missions, wings for places legs can’t reach, and a rover to carry the network; every robot able to work alone.

The name stands for “CollaborativE walking & flying RoBots for autonomous ExploRation in Underground Settings”, after the three-headed dog guarding the underworld in Greek myth. The team joined the University of Nevada, Reno, ETH Zurich, NTNU, UC Berkeley, the University of Oxford, Flyability and Sierra Nevada Corporation.

ANYmal C SubT: the workhorse

For the final the team switched from the older ANYmal B300 to the ANYmal C100 from ANYbotics, a water- and dust-proof (IP67) quadruped, and customised it. Each weighed 55 kg with payload and could walk continuously for 80 minutes. All carried a Velodyne LiDAR, an Alphasense camera unit (three black-and-white and four colour cameras looking front, left, right and up, lit by four high-power LEDs), a CO₂ sensor, a Bluetooth sensor and an NVIDIA Jetson AGX Xavier graphics computer. They came in two roles:

• Explorers went deep to find objects. They had two dome-shaped LiDARs for terrain mapping, which cope with dust, water and shiny surfaces, and a pan-tilt inspection head with a 10× zoom camera, a thermal camera, a microphone and a spotlight.
• Carriers used four lighter depth cameras instead, which freed room for four radio “breadcrumbs” held by electromagnets. To drop one, the robot tilts its body and switches off the magnet; the relay slides out on carbon tubes and lands upright.

Flying robots and a rover

For narrow shafts and stairwells the team built RMF-Owl, a 1.46 kg collision-tolerant drone 38 × 38 × 24 cm in size, with a LiDAR, a camera and LEDs, running the whole autonomy stack on a small board computer; it flies for about 10 minutes. The larger Kolibri (6 kg, 22 min, a multi-directional tricopter) was built but not deployed because the final course was so narrow. A roving robot (135 kg) reeled out a 300 m fibre-optic cable from the base station and carried a radio with a directional antenna; it was driven by the supervisor and parked at a junction as a network hub.

In short: every robot tracks its own position with several sensors stacked in layers, so when one goes blind the next one takes over.

The same camera unit, lenses, timing and lights went on every legged robot and on Kolibri. That made tuning simpler and helped the software recognise places seen by another robot. Getting sensors to agree took care: the team calibrated cameras with a large grid of AprilTag markers (6 × 6 tags about 10 cm wide) and found that automatic camera-to-LiDAR calibration didn’t work with a sparse 16-beam LiDAR, so they built a tool to align the two by hand.

CompSLAM: layers of fallbacks

Each robot ran CompSLAM on board, with no need for the base station. It works like a relay race in which each runner checks the baton before taking it:

1. Cameras + thermal camera + motion sensor (IMU) estimate motion first. Thermal images still show structure in smoke, and sparse LiDAR points help set the scale of what the cameras see.
2. LiDAR odometry matches each new laser scan to the previous one. Before using the camera estimate as a starting guess it checks that it is plausible (within the robot’s possible speed, with uncertainty not growing too fast). If not, it falls back, in order, on leg odometry (ANYmal counting its own steps), the IMU alone, or “keep the same speed”.
3. If the scan match itself is poorly constrained (a long smooth corridor looks the same everywhere along its length), the uncertain directions are taken from the starting guess instead.
4. LiDAR mapping matches scans to the growing map, with the same health check.

A shared map at the base: M3RM

When in radio range, robots also sent compressed map chunks (about 2 MB each) to M3RM, a server at the base that merged all robots’ maps and looked for places seen twice (“loop closures”) to cancel drift. It worked well afterwards but struggled during the run: a long, white, texture-free corridor at the urban entrance gave its camera features almost nothing to hold on to, so its maps skewed and it slowed down. The supervisor therefore mostly relied on each robot’s own CompSLAM estimate.

What this means: on the day, each robot’s own estimate drifted by 0.2–1.8 m over the whole run, well inside the 5 m scoring radius. Re-run afterwards with more time, the merged multi-robot map cut that to 0.2–0.4 m. (The “re-run” CompSLAM restores a finer point-cloud setting the team had coarsened as a safety margin; step errors from M3RM can’t be computed because it keeps only key frames.)

In short: one exploration planner on every robot keeps asking “which nearby route shows me the most new space?”, and remembers unexplored openings for later.

All CERBERUS robots, walking and flying, used the same graph-based exploration planner, GBPlanner2, with only robot-specific settings changed. It works on a 3-D grid map of free and occupied space (built with Voxblox) and has two layers:

• Local: inside a box around the robot, whose size adapts to the space, it scatters points and links them into a graph of collision-free moves. For walking robots each move must also have ground under it and a slope the robot can manage. It finds the shortest route to every point and picks the one that would reveal the most unknown volume.
• Global: a sparse graph spanning everything explored so far keeps “frontier” points that still promised new space. When the local layer finds nothing worth doing (a dead end), the global layer sends the robot back to a frontier. At every step it also checks whether the battery still allows one more round and the trip home; if not, it heads home.

Two details came straight from field testing. “Hanging vertices” keep points over gaps in the map (negative obstacles such as a drop the sensors saw only partly) without ever sending the robot there, and before the final the planner was tuned to squeeze through openings as small as 1 m × 1 m, which the final course had plenty of. After the second preliminary run showed routes over slopes that were too steep, the global layer was changed to compute several shortest routes and take the one whose steepest part is gentlest.

In short: a height map of the ground feeds both a learned walking controller and a planner that weighs the risk of a misstep five times more than lost time.

The elevation map

An elevation map stores one ground height per grid cell. ANYmal builds it around itself on its GPU from its depth sensors and odometry: 8 m × 8 m at 4 cm cells, updated at 20 Hz on Explorers and 45 Hz on Carriers. It also clears “ghost” obstacles by tracing rays from the sensor to each measurement: if a ray passes below a stored height, that height was wrong.

A walking controller learned in simulation

The legs were driven by a neural-network controller trained with reinforcement learning in simulation. It reads the terrain heights in circles around each foot, and during training it met random terrains, varied robot mass and ground friction, pushes, and deliberately corrupted maps, so it learned to rely on its sense of touch when the map is wrong. One controller handled the whole course (tunnel, urban stairs and cave) with no need to tell it which gait to use. It also learned to tilt the body to drop relays on slopes. (That controller is described in its own paper, Miki et al., Science Robotics 2022.)

A navigation planner that respects risk

The ANYmal navigation planner refines the exploration path locally. It models the robot as a torso that must stay clear of obstacles and four “reach” boxes (one per leg) that must touch steppable ground. A tiny network of only 120 parameters, trained on just 20 hand-labelled height maps, marks where feet can go. A second learned model predicts the risk, energy and time of a move from the height map, using data from a walking policy on random simulated terrain. Energy mattered little (the batteries outlasted the run), but one navigation failure could end the mission, so the cost was risk plus time, with risk weighted five times higher.

A behaviour tree (a flowchart of checks that runs over and over) coordinated all this: a watchdog made the robot retrace its steps if it stopped moving, the supervisor’s commands took priority, a timer called the robot home when its budget ran out, and the height map was reset automatically if the robot’s pose ever looked impossible, for example when drift made the map rise to the robot’s knees.

In short: the team carried its own radio network into the ground, and designed robots to keep working, and come back, when that network ran out.

The backbone was a 5.8 GHz mesh network of commercial Rajant radios: the base station, every ANYmal and the rover were mesh nodes that connect to as many neighbours as they can and route data between them; each also broadcast a normal Wi-Fi network for the drones. The base had two links: a radio in the staging area, and the rover’s 300 m fibre cable. Carriers could add up to eight breadcrumbs (four each), each weighing 245 g with a 2-hour battery and an antenna that unfolds 17 cm upright after landing. Where to drop them was left to the supervisor, since radio underground is so unpredictable.

On top of the radios, the software (ROS 1 with the Nimbro Network package) split data into essential streams (heartbeat, telemetry, object reports, map data) that every robot always sent, and heavy non-essential ones such as camera video, which only the robot the supervisor had selected could send. That kept the shared bandwidth free.

Working out of range

The supervisor could let a robot leave coverage with a time budget. It explored for that long, then walked back to where it started, so a task took about twice the budget. Without a budget, a “Wi-Fi safety” check made the robot backtrack as soon as its pings to the base kept failing. In the Prize Round budgets ran from 5 to 13 minutes. The team’s view: short, frequent trips, with the supervisor checking in often, paid off compared with sending robots on long missions and waiting for them until the end.

In short: robots spot objects themselves, turn a glimpse into a 3-D position, and only report when they are confident; the human makes the final call.

Each robot ran an object detector (a YOLOv3-style neural network) on its camera streams: 3 times a second per camera on ANYmal, next to the elevation mapping on the same Jetson. It was trained on 40,007 hand-labelled images collected in basements, tunnels, mines and caves, many lit only by the robots’ own LEDs, plus 384 images of scenes that had fooled it before. The team hunted deliberately for failure cases: look-alike background colours, motion blur, smoke, far-away objects.

What this means: the classes were roughly balanced. Phones were labelled too, but in practice they were found by their Bluetooth signal.

From a box in an image to a point on the map

For each pixel inside a detection box, the robot casts a ray into its 3-D map; the median of the hit points is the object’s position. A small sphere around it collects later sightings of the same object, the centre is averaged, and a Bayes filter (a running tally of evidence) raises its confidence with each sighting. Once past a threshold, one report goes to the base, or waits on board until the robot is back in range.

Phones and the SubT cube were located by clustering Bluetooth signal strengths, and gas by CO₂ readings; in the paper’s example a cube was still placed within 5 m even though the robot never passed right by it. Explorers also used their zoom-and-thermal head: an algorithm picked the fewest pan-tilt angles that would cover what the fixed cameras hadn’t seen (from 1,170 possible angles). The final course was so narrow that the head mostly made single-point scans: 25 for ANYmal 1 and 156 for ANYmal 2.

One supervisor, two screens

After the Tunnel and Urban events the team noticed that operator mistakes were a big share of their errors, and that juggling several computers made it worse. For the final, the supervisor used one computer with two interfaces: a mission-control panel to command a selected robot (explore, set an area, go home, reposition to a frontier, scan, go to a waypoint), and a monitoring and reporting view with the merged map, every robot’s position and mode, and a queue of incoming detections to accept, reject or relabel before sending to DARPA.

In short: 23 points, the same as CSIRO Data61, and a win because CERBERUS reported its last point earlier.

The Final Event ran on 21–24 September 2021 in the Louisville Mega Cavern, Kentucky: one entrance down an inclined tunnel into an opening with three doorways to tunnel, urban and cave sections, all interconnected over several levels.

Two preliminary runs

Each team had two 30-minute practice runs with 20 objects; the course changed between runs and no maps could be carried over. On day one CERBERUS sent three ANYmals and the rover with cautious settings. The Explorer got a foot stuck in a railway track and shut down from over-current; a Carrier needed two waypoints from the supervisor because the cautious planner refused a short staircase and its LiDAR never saw the bottom of a long one. Score: 7, joint lead with CSIRO Data61. They also learned the course started with a narrow tunnel, so launching drones from the start was risky and of little use. On day two no robot was allowed out of radio range, so they explored less and scored 6 (third overall across both practice runs).

The Prize Round

On 23 September each team had one 60-minute run, with 40 objects and 45 report attempts, on a course changed again, now with a hidden mechanism that closed an opening behind a robot and objects that fell from the ceiling. Teams were kept apart so no one could learn from another’s run. CERBERUS chose the day-one settings and decided not to deploy last-minute fixes to planning and mapping, a choice they believe was crucial.

The supervisor sent the two Explorers first (ANYmal 2 into the cave, ANYmal 1 into the tunnel), parked the rover at the three doorways with its antenna aimed down the tunnel and urban openings, then sent Carrier ANYmal 4 to the urban section and ANYmal 3 to the cave. With 18 minutes left the team launched RMF-Owl to explore the high cave chamber, but it climbed into the upper staging area instead: there was no way to mark a 3-D “no-go” zone there, and an older gate-crossing feature wasn’t used. The safety pilot landed it. At the end CERBERUS had 23 points and had used all 45 attempts.

What this means: the four walking robots scored all 23 points between them, covering 1.7 km in total. “Operating” is the share of time in the course a robot was actually moving or working; ANYmal 1’s is low because it spent the last half-hour trapped (see lessons).

The gap in that timeline is the CO₂ story from scene 7: ANYmal 4 had sent 30 CO₂ reports between minutes 10 and 15, because the team had set the gas threshold at 1500 ppm rather than DARPA’s 3000 ppm to catch leaks from further away. Each time the robot got closer, the cluster moved and another report went out, and the supervisor had to sort them all while also running the robots. ANYmal 2 later sent 11 more between minutes 37 and 42. In the last 7 minutes the supervisor stopped giving new goals and only chose which reports to submit.

In short: the hardest problems were not single algorithms but the seams between them, the human’s workload, and the gap between the lab and a real hole in the ground.

What went wrong in the final

• Obstacles that moved. The homing and repositioning routines weren’t built for obstacles that appear after the robot has passed. ANYmal 1 met one while repositioning, started retracing its path, and stayed stuck for the rest of the run: only the supervisor could stop that retreat, and the robot was out of radio range, so he never knew. ANYmal 4 got stuck the same way but in range, and the supervisor restarted exploration.
• Two planners that didn’t talk. The exploration planner, tuned to be optimistic, planned several times through a gap between two construction cones; the cautious navigation planner correctly refused every time. Safe, but there was no feedback, so time was lost.
• Low ceilings and a half-second lag. To see slopes and stairs, the height map accepted points above robot height, which turned low ceilings into ghost obstacles until the robot got close. A delay of up to 500 ms between planning a path and following it made ANYmal 2 clip a scaffolding pole, which then vanished from its map while too close to see, and it was stuck for about 20 s.
• A white corridor. The team’s camera features (BRISK) found few good landmarks in narrow, over-exposed or texture-less passages. Re-processing the run with a learned feature detector (SuperPoint) gave a clearly better multi-robot map.
• An overloaded supervisor. Switching to another robot meant requesting its map and waiting for it to stream, several seconds each time. A single interface for control, overview and reports would have helped. Partly because of this, only 3 of the 8 breadcrumbs were dropped.

What the team took away

• Legs plus wings. Quadrupeds were the main vehicle for long, large-scale exploration; drones are the only way up vertical shafts but have little endurance and payload. The team’s answer is a “marsupial” pair, a drone that rides on the walking robot, which they finished only after the competition.
• Legged robots came of age. Walking speed rose from 0.3 m/s (2019) to 0.45 (2020) to 0.7 m/s in the final, deliberately capped although the robot could exceed 1 m/s, with no falls. The authors call it a tipping point, and list what is still missing: climbing like animals do, planning and locomotion that are less separated, a semantic sense of terrain, and using legs to touch or move things.
• Perception must be multi-modal, and failures handled as a whole. The hand-written rules in CompSLAM’s hierarchy worked but may not generalise; the multi-robot map needs less hand-tuning and should be tested on its own.
• Autonomy that doesn’t need the radio. Robust single-robot autonomy made communication failures bearable. Multi-robot coordination was developed but never deployed; planning with semantics (doors, stairs) and explicit risk is next.
• Test in the field, often, and freeze before it counts. Weekly “shakeouts” (about 20-minute mock missions in a basement), at least one underground field test a month in the final year across 15 sites in four countries, a strict rule that anything failing the day-before check stays home, and no untested changes before the Prize Round.
• More simulation. Hand-labelling detector data was slow; photo-realistic simulation with smoke, lighting and radio effects could help, but no simulator replaces field data for sensors like thermal cameras.

The team released much of its software as open source, including GBPlanner2, the ANYmal navigation planner (ART Planner), GPU elevation mapping, maplab with the M3RM server, and simulation models of its robots in the SubT virtual environment, as well as a dataset from the Prize Round.