MulBERRY: Enabling Bit-Error Robustness for Energy-Efficient Multi-Agent Autonomous Systems

Running the processor on a small drone below its rated voltage saves energy quadratically, but it also makes memory cells fail — and a corrupted neural network policy sends the drone off course, so it flies further, uses more battery, and completes fewer missions than if you had never saved the power at all; MulBERRY (Georgia Tech, IBM Research, Lawrence Livermore and Harvard) trains the flight policy with those bit errors deliberately present, lets each drone in a swarm learn its own chip's particular faults, and has the drones take turns running at full voltage so the shared model stays healthy while the heatsinks stay small.

Why this problem is worth solving

The failure mode here is not the one hardware is designed to survive.

The constraint that shapes everything is a budget where the parts are coupled.

What people did before, and where it broke

• Protect the hardware with error-correcting codes and redundancy. Every serious processor has these, and they work well for what they were designed for. Where it broke. They target transient faults producing one or two flipped bits. Low-voltage errors are multi-bit within a word and permanent at a given voltage, so a second read or a second copy reproduces the fault exactly. Neither correction nor voting helps.
• Fix it in the circuits. Redesign memory cells or add architectural support so the chip stays correct at lower voltages. Where it broke. Area and power overhead, which is the one thing a size, weight and power constrained machine cannot pay. The remedy consumes the resource it was meant to save.
• Train the model with the actual measured fault pattern of the chip. If you profile a specific device, you can train a model that works around its specific broken cells. Where it broke. It does not generalise. A model fitted to one chip’s error map fails on another chip or at another voltage, and profiling memories at all requires expensive equipment, detailed design knowledge and time — impractical across a fleet of drones each with its own pattern.
• Train with random bit errors instead. More general, and the direction this paper builds on. Where it broke. The existing method was designed for single-node supervised learning. It says nothing about several agents sharing a model, nothing about learning rather than inference, and nothing about what any of it does to a flying machine.
• Study how reliable autonomous vehicles are. A body of work characterises how transient faults and adversarial inputs affect drone navigation. Where it broke. Characterisation, not mitigation, and aimed at transient faults rather than the deliberate, persistent kind you get by turning the voltage down on purpose.
• The gap. Nobody had connected the three layers. The silicon literature knows what low voltage does to memory; the learning literature knows how to make a model tolerate noise; the robotics literature knows what payload does to flight. What none of them had is the end-to-end accounting showing that a compute saving only becomes a mission saving if the model survives, and that a swarm gives you a resource for making it survive that a single machine does not have.

How a swarm learns to fly on broken memory

The idea

Stop trying to make the hardware correct and make the model indifferent instead. The standard response to a chip that computes wrong answers is to repair the answer — with a correcting code, a second copy, or a circuit change. None of those work here, because the errors are persistent rather than transient and come several to a word. So the paper abandons repair entirely. During training, each step is computed twice, once on clean weights and once on a copy with random bit flips applied at the rate the target voltage implies, and the two gradients are averaged so that the resulting model performs acceptably in both conditions. Nothing about the deployment changes: the weights are quantised to eight bits and mapped linearly into memory without any knowledge of where the broken cells are. Refusing to demand correct hardware and instead adapting the algorithm to whatever defects a particular device happens to have is the same reversal that the work on co-designing error-correcting codes with defective chiplets covered elsewhere on this site performs in a completely different domain.

A swarm is a resource for tolerating faults, not just a way to cover more ground. This is the part that only exists because there are several agents. Two observations drive it. First, a policy learned collaboratively across agents turns out to be more robust than one learned alone — the paper measures a narrower weight distribution in the multi-agent model and hypothesises that spreading the decision across more weights dilutes the effect of any individual flip. Second, and more concretely, the agents can divide the roles. Borrowing the idea of computational sprinting from mobile processors, one drone runs at nominal voltage while the others run low, and the roles rotate in non-overlapping intervals. Every round therefore contributes at least one uncorrupted set of updates to the shared model, while no chip is ever hot for long. The server then leans into it, weighting a low-voltage agent’s parameters as heavily as the sprinter’s, on the reasoning that the slacking agent is the one actually learning its own chip’s faults. Giving members of a fleet deliberately different roles at any given instant, so the group achieves what no single member could, is the same structural move the heterogeneous satellite constellation covered elsewhere on this site makes with leader and follower spacecraft.

The compute saving is nearly worthless until it becomes a mechanical one. On this drone the processor accounts for 6.5 percent of total power and the rotors for 93.5, so saving four fifths of the compute energy is, by itself, almost noise. The chain that makes it matter runs through the heatsink. Lower voltage means lower peak temperature; lower peak temperature means a heatsink of 1.12 grams instead of 2.85; less payload means acceleration rises from 6.61 to 7.63 metres per second squared; higher acceleration means the drone can dodge obstacles at 5.44 metres per second instead of 5.08; and a faster mission is a shorter mission. The same chain is what makes the naive version of this idea backfire — without robust training, bit errors cause detours, and the extra flight time swamps the compute saving so completely that total mission energy goes up. A tiny compute budget that nonetheless determines the value of the whole mission is the same situation the onboard satellite filtering work covered elsewhere on this site is built around, where a few seconds of processing decide how much of a downlink is worth sending.

Following one volt down to more missions

A roofline analysis of the drone as a sensor-compute-control pipeline confirms that the decision rate is still bounded by the sensors rather than the processor, so slowing the clock does not slow the aircraft.

Why it works

• Averaging a clean and a corrupted gradient keeps both cases usable. Training only on corrupted weights would produce a model that needs the errors to be present → training only on clean weights produces the fragile baseline → averaging the two gradients at every step yields one model that is acceptable with errors and without, which is what lets a single trained policy ship to chips that fail in different places.
• Learning on the device beats learning about devices. Injected random errors teach a model to survive a distribution of possible fault maps → but the chip a drone actually has is one specific fault map, fixed and persistent → so continuing to learn after deployment lets each drone specialise to its own broken cells, which is what extends the usable voltage range further down.
• The persistence that makes these errors hard is also what makes on-device learning possible. A transient fault would be different on every read and impossible to adapt to → a low-voltage fault is the same on every read at a given voltage → so it behaves like a fixed property of the hardware that a learning process can simply absorb.
• Rotating the sprint keeps two constraints satisfied that conflict. Everyone sprinting overheats a small heatsink → everyone slacking means every contribution to the shared model is corrupted and learning fails → a rotation gives the model at least one clean contributor per round while peak temperature depends only on the fraction of time spent sprinting, not on the pattern, so a quarter duty cycle drops the peak by around 13 degrees Celsius.
• The mechanical dividend is larger than the electrical one. Processing is only 6.5 percent of power on this machine, so a four times compute saving is worth little directly → but it removes over half the heatsink weight, and payload feeds into acceleration, safe velocity and therefore flight duration → which is why the reported mission energy saving is around 19 percent rather than the fraction of 6.5 percent you would predict from compute alone.

What it costs (trade-offs and scope)

• Nothing flew. This is a simulation study of roughly 9,000 experiments. The authors are direct about it: they build on a simulator, an energy model and a roofline model that have been validated against real flights, and choose simulation to explore a design space that real drones would make prohibitive on cost and safety grounds. It is a reasonable choice and it is still simulation.
• On-device learning is expensive and its cost is excluded from the headline. The results table reports learning energy of roughly 870 to 1,500 joules depending on the number of steps, against a mission that costs about 65 joules — and a footnote states that the mission counts do not include the flight energy consumed while learning. Since on-device learning improves per-mission energy by a couple of joules over the offline version, the payback period is very long.
• The benefit shrinks sharply on larger drones, and the paper shows this. The 18.97 percent figure is for the smallest machine, where compute is 6.5 percent of power. On a larger drone running the same policy, where compute is 1.3 percent, the saving drops to 6.81 percent. Running a larger policy on the larger drone recovers some of it, but the headline belongs to the most favourable configuration.
• Success rate is maintained, not improved. The baseline at full voltage achieves 91.4 percent and the best robust low-voltage configuration reaches 91.2. The reported 22.07 percent increase is in missions completed per battery charge, which is a different quantity combining success rate with energy per mission.
• The whole mechanical argument turns on about 1.7 grams. The heatsink goes from 2.85 to 1.12 grams on a drone with a 15 gram payload allowance. The chain is real and measured, but it is a small lever, and it assumes the heatsink can be resized to match a lower thermal design point.
• The rotation has no free setting. Sprinting more often improves success rate but raises peak temperature, which demands a bigger heatsink, which costs payload and speed. On a twelve-drone swarm the best balance was a quarter of that, with both a lower and a higher duty cycle doing worse for different reasons.
• The server weights are hand-chosen constants. A learning low-voltage agent and the sprinting agent each get 0.4, and the remaining agents share 0.2. Nothing learns or adapts those values.
• The error model is abstracted. Bit flips are drawn uniformly at a rate read off a published memory characterisation curve, half in each direction. To the authors’ credit they also test against two profiled patterns from real test chips, including a column-aligned one, but the training itself uses the random model.
• The comparison against prior methods is a re-implementation. The strongest baseline was designed for single-node supervised learning and had to be ported to this multi-agent reinforcement learning setting by the authors, who acknowledge that a fair comparison across techniques targeting different platforms is difficult.
• Scope is one task family. Collaborative navigation among obstacles, three environments, swarms of four and twelve, three drone models. The suggestion that this extends to other resource-constrained swarms is offered as a direction rather than shown.

The evaluation

Check yourself

Sources

The paper is “MulBERRY: Enabling Bit-Error Robustness for Energy-Efficient Multi-Agent Autonomous Systems” by Zishen Wan, Nandhini Chandramoorthy, Karthik Swaminathan, Pin-Yu Chen, Kshitij Bhardwaj, Vijay Janapa Reddi and Arijit Raychowdhury, published at ASPLOS 2024, pages 746-762, DOI 10.1145/3620665.3640420. It is open access under a Creative Commons licence.

This explainer is written from the full 17-page text. Everything above comes from the paper’s own sections: the multi-agent formulation with its per-agent local learning, periodic server communication and weighted aggregation towards a unified policy; the characterisation of low-voltage memory failures, including the exponential rise in error rate as voltage falls, the persistence of a failing cell across reads and across lower voltages, the randomness of spatial patterns across chips, and the argument that standard correction and redundancy do not apply; the exploitation of the voltage gap between the first memory failures and the first logic timing errors, with frequency scaled alongside and a roofline analysis confirming the drone decision rate remains sensor-bound; the measured degradation of a four-drone swarm under bit errors across success rate, flight time, flight energy and missions per charge; the comparison showing multi-agent policies more robust than single-agent ones and exhibiting a narrower weight distribution; the offline training algorithm with its paired clean and perturbed passes and averaged gradients, eight-bit quantisation and linear mapping into memory; the on-device learning path with its four optimisations of payload reduction, collaborative sprint-or-slack rotation, dynamic communication frequency and dynamic server weighting with its stated constants; the thermal analysis showing peak temperature depending on duty cycle alone and swinging more than 18 degrees Celsius across the range; the experimental setup covering the four-core RISC-V platform in 12 nanometre technology, the simulation infrastructure and its validation status, the drone specifications and the 500 fault maps per scenario; and the evaluation covering the offline and on-device results tables, the heatsink, acceleration and velocity figures, the sweet-spot flight energy and mission counts, the sensitivity analyses across error patterns, environments, drone types, policy sizes and swarm sizes, the communication overhead accounting, and the comparison against two prior robust-training methods.