Rethinking Robustness Assessment: Adversarial Attacks on Learning-based Quadrupedal Locomotion Controllers

In short: legged robots are heading into places where a fall is costly, and their brains are neural networks nobody can inspect line by line, so we need a systematic way to find where they break.

Quadruped robots are expected to take over “3D” work, meaning dull, dirty and dangerous: transport, underground inspection, rescue. What makes that possible today is the controller, the program that decides every 20 milliseconds how to move twelve joints. Modern controllers are neural networks trained with reinforcement learning in huge parallel simulations. Instead of an engineer writing down the robot’s physics and solving it online, the network learns a mapping from sensor readings to motor commands by trial and error.

These controllers are remarkably tough. One of them, the perceptive controller of Miki et al. (2022), which this paper calls the Miki policy, walked ANYmal robots through caves, tunnels and snowy mountains and was part of team CERBERUS’s win at the DARPA Subterranean Challenge. Failures in the field are rare.

Rare is not never. Neural networks are known to be sensitive to small, well-chosen changes in their input (the classic example is an image classifier fooled by invisible pixel noise). For a walking robot the question becomes: is there a sequence of small, realistic disturbances that makes this controller fall? The paper argues that the answer matters for safety, and that the mildest such sequence is itself a useful measure of how robust a controller really is.

In short: standard push tests check whether a robot survives big shoves, but a failure usually needs the right small things at the right moments, and only a search finds that.

Why is finding the weak spot hard? The space of possible disturbances is high-dimensional (several commands, three tilt angles, forces on four feet) and sequential (a new value every 0.02 s). Trying random combinations is hopeless, the “curse of dimensionality”. And a controller trained to be robust has already learned to shrug off the random noise it saw in training.

The existing toolbox, which the paper treats fairly, consists of:

• Standard push-recovery tests: apply fixed or random forces to the robot’s body and count falls. Useful to compare controllers against large pushes, but they cover a narrow set of scenarios.
• Domain randomization: randomize masses, friction, noise and pushes in simulation so the controller works “on average”. The paper later shows this is not enough (section 8).
• Search-based testing, well established for self-driving cars, where reinforcement learning finds the pedestrian movements that make a car crash. For quadrupeds, a prior study used evolutionary search on joint torques, but on a simplified simulated “Ant” model and without a real robot.

To show the gap, the paper uses a deliberately simple “didactic” controller (the open-source blind controller of Rudin et al., a small network that sees only the robot’s own body sensors), walking forward at 0.4 m/s in simulation. Four standard tests with the same force limits as the adversary were run 1000 times each:

What this means: a controller can pass every standard test and still have a weakness that a searching attacker finds every single time.

The paper also runs an attack–patch–re-attack loop on this controller. First the adversary may only push from one side and finds a fall; the controller is then fine-tuned against it; a new adversary allowed both sides immediately finds the side that was never patched. Section 7 shows a cleaner version of this experiment.

In short: the attacker is itself a small neural network, trained by trial and error to make the robot fall, but only with disturbances a real robot could plausibly meet.

The key design decision is what the attacker may touch. The authors picked three sources of failure from field experience, each with a realistic range and a limit on how fast it may change (at most 10 % of its range per 0.02 s step):

What this means: no attack exceeds what a working robot routinely experiences; the paper rules out things like a 10 000 N shove on a 50 kg robot, which would teach nothing.

The adversary sees the same inputs as the controller it attacks and outputs its disturbances 50 times a second. It is trained with PPO, a standard reinforcement-learning algorithm. The walking controller is never changed during the attack and needs no special access: it is treated as a black box.

What the attacker is rewarded for

The attacker’s score has one main term and three helpers:

The first term makes a fall the goal: every step the robot survives costs the attacker. The bonuses give a signal before the first fall happens, which makes learning much faster. On top of this sits the smoothness penalty of section 4.

Why not simply use the negative of the walking controller’s own training reward, the textbook “zero-sum” game? Because that reward is dominated by performance terms such as how well speed commands are tracked, foot clearance and energy. An attacker minimizing it learns to make the robot walk badly, not to make it fall. A fall even ends the episode, which in that reward is worth less than a long stretch of sloppy walking. The ablation confirms this:

What this means: for safety testing, the attacker must be rewarded for the failure you care about, not for making the robot’s task harder in general.

Why three channels at once

Earlier legged-robot studies attacked one channel at a time. With the small ranges above, the paper finds that no single channel is enough to topple the Miki policy, but every combination of two or three is (Table III). Real failures of a mature controller also tend to come from several factors together.

In short: an unconstrained attacker learns to flicker its signal between the extremes; a smoothness penalty makes it produce slow drifts that look like real sensor errors.

Reinforcement learning happily finds “bang-bang” solutions: the attacker slams the tilt error from +3° to −3° and back many times a second, which is effective in simulation but tells us little, because no real estimator behaves that way. The authors measured their robot’s tilt estimate against motion capture while it walked on a flat indoor floor: the error drifts slowly and peaks at almost 3°, and it grows on slippery or uneven ground or under pushes.

The fix is Lipschitz regularization. A network’s Lipschitz constant bounds how much its output can change when its input changes a little. For a stack of layers with ReLU-type activations, the product of each layer’s weight norms (here, infinity norms) is an upper bound on that constant. Adding this product, times a weight λ, as a penalty to the attacker’s training loss keeps the constant small, so the attack becomes smooth.

In short: with only command nudges and tilt errors of 3°, the attacker makes the DARPA-winning controller fall on flat ground, in simulation and on the real robot alike.

The second case study attacks the Miki policy, a perceptive controller with a recurrent memory that sees a 208-point height map of the terrain around the robot and is known from field use to be robust to sensor noise and pushes. The attacker (a network with three hidden layers) sees the same inputs.

For the real-robot test, only the two channels that can be reproduced on hardware were used: velocity commands and tilt-estimate errors. The same learned attacker was then run against the real ANYmal walking on a flat lab floor, with a safety stop that caught the robot before it hit the ground. To find the smallest attack that works, the tilt error was rescaled to different maximum sizes:

What this means: the weakness found in simulation is real: the threshold is the same on hardware (between 2° and 3°), and it sits inside the range of errors the estimator produces anyway.

In short: experienced roboticists poking the robot by hand rarely find the weakness; the learned attacker finds it faster and exploits it harder.

A common way to harden a controller is intuition: an engineer kicks the robot, adds noise, watches. Is that enough? The authors organized an AI safety challenge. In simulation, the simple didactic controller walked forward at 0.4 m/s. Participants used joysticks to push its body (up to 100 N along each horizontal axis) and to override its sideways and turning commands (within 0.5 m/s and 0.5 rad/s). For a fair match, the machine attacker got no joint readings, since humans only see the rendered robot, and could act only 5 times per second.

100 volunteers with a robotics background each had 5 minutes. Three made the robot fall.

What this means: the adversary topples the robot about three times faster than the best human and with a much more violent fall, and 97 of 100 experts found nothing at all.

In short: the attacks found in testing become training material; the patched controller resists new attacks, on hardware too, and walks as well as before.

Closing the loop is simple. Training of the controller resumes from its last version (actor and critic networks warm-started). Most simulated robots keep the usual random disturbances, and some meet the learned adversary instead. The objective does not change; only the situations the controller practices on do. Too many adversarial robots make the controller over-cautious, so the share is kept small.

The patched Miki policy

New attackers were then trained against the fine-tuned controller, with a larger budget of up to 5° tilt error. None could topple it, neither in simulation nor on the real robot, even while an operator pushed it by hand in addition (Fig. 9). On a wet whiteboard and a soft mattress, where the original controller quickly lost balance under perturbation, the fine-tuned one reacted and recovered (Fig. 7). Outdoors it still crossed rough slopes, slippery ditches, sand and steep gravel roads (Fig. 8).

Did robustness cost performance? Compared with the original controller in simulation:

What this means: speed tracking changes by less than a centimetre per second and effort barely moves, so the extra robustness came essentially for free.

Patching one weakness at a time

A controlled experiment shows the mechanism. The didactic controller was trained with random pushes that only came from within 45° of straight ahead or behind, leaving its sides “unguarded”. Push tests confirmed it was weak sideways. The first adversary found a fall by pushing it leftward; after fine-tuning against it, the left was patched but the right was still weak. A second adversary found exactly that, and after a second round of fine-tuning the controller resisted pushes from both sides.

In short: randomizing the simulator is not enough, the smallest successful attack can serve as a robustness score, attackers that can see terrain use it, attacks can be steered toward different failures, and the method also breaks a classical model-based controller.

Is domain randomization enough? No.

A controller trained with random pushes of up to 100 N, re-drawn 5 times a second, still fell to a learned attacker with the same 100 N limit. It survived larger pushes than a controller trained without randomization, so randomization helps, but attacks are a complement, not a replacement.

Attacks as a robustness score

Give the attacker a variable budget and shrink it until the controller survives: that smallest budget is a number you can compare across controllers and terrains. Three controllers were compared: no randomization (“policy”), randomized pushes (“policy-DR”), and randomized pushes plus adversarial fine-tuning (“policy-DR-ft”). The paper reports the ordering policy < policy-DR < policy-DR-ft on every terrain, with the biggest gains from fine-tuning on uneven terrain. The exact values are only given in the chart.

Attackers that use the terrain

When the attacker also sees the height map, it exploits the ground: on stairs it first turns the robot toward the edge, then attacks. On flat ground it attacks directly. The real-robot attacks were done on flat ground for safety, so uneven terrain may hide even easier failures.

Different failures on demand

One training run converges to one attack strategy, but a controller may have several weaknesses. Changing the weights of the attacker’s bonus terms steered it to different kinds of damage: falling over, the body hitting a front leg (self-collision), or a knee motor exceeding its torque limit during a single-foot touchdown. (The paper’s image of these three failures, Fig. 13, is omitted here because it did not convert cleanly.)

Not only neural controllers

The method only needs to run the controller, not understand it. The authors attacked an open-source model predictive controller (Kim et al.’s MIT Mini Cheetah controller, adapted to the Unitree A1) through commands and observations with the same ranges and score, and toppled it in simulation.

In short: this is a first step toward measuring robustness, not a certificate.

• Only body sensors were attacked. The Miki policy also reads a 208-number height map of the terrain, which is probably vulnerable too; generating such high-dimensional attack sequences may need generative models rather than reinforcement learning.
• No guarantee of completeness. A learned attacker finds a weakness, not all of them. Diverse rewards help, but covering every weakness needs further work.
• Fair comparisons are hard. Using attacks to rank controllers or training methods requires each controller to be the best its method can produce, and robots and sensors differ. The authors leave rigorous comparisons to future work.
• Pushes stay in simulation. External forces could not be reproduced precisely on hardware, so the real-robot attacks used commands and tilt errors only.

The authors’ hope is practical: that legged-robot researchers treat worst-case testing as a standard step before large-scale deployment of neural controllers.