Multi-Robot Coordination

A robot team on a planetary surface has to agree on where each member is, what each has seen, and who decides, over a radio link that is intermittent and slow, on processors that are individually weaker than one rover’s. Every mechanism a team needs on the ground, from consensus to shared maps to a single point of command, was designed for networks that stay up and nodes that stay reachable. Neither holds on a lunar surface, on the far side of a formation in orbit, or on a submerged or aerial team working out of line of sight of its operator, so the coordination layer has to assume the link will drop and the team will keep working anyway. CADRE is the flight article for the planetary-surface case: three identical rovers plus a base station, targeted at Reiner Gamma, sharing a single mesh radio the whole team must fit inside [1]. Its stated objective is to demonstrate the first autonomous exploration and distributed measurement by a team of rovers on another planetary body, with the least possible ground intervention.

The design space: how much do agents need to tell each other

Coordination algorithms are usefully sorted by how much communication they demand. Low bandwidth algorithms have each agent communicate with a subset of its neighbors; medium bandwidth algorithms have each agent communicate with all its neighbors at each time step; high bandwidth algorithms require every agent to reach every other, potentially over multiple hops, at each time step, which is the class that contains centralized algorithms implemented over a shared-world architecture, with scalability classified in tiers of 2, 20, 100 and over 1000 agents and maturity classified by whether a technique has been demonstrated in hardware in the lab or in flight; surveying the field this way turns up a negative result more useful than any positive one: outside of artificial potential functions, no single mathematical technique spans both low-level spatial tasks, such as formation keeping, and high-level coordination, such as task allocation, and relatively few of the algorithms in the literature have been field tested at all, with the ones that have generally exchanging only positions or relying on a centralized implementation [5]. A three-rover team sharing CADRE’s 1 Mbps mesh sits at the bottom of that scalability axis and cannot afford the top of the bandwidth axis [1][5].

Where a team sits on that axis is a decision forced by the radio, not a preference. CADRE’s Microhard mesh gives a minimum of 1 Mbps aggregate shared between all four stations, and motor-generated electromagnetic interference limits reliable transfer to specific windows when rovers are not driving, so a high-bandwidth, every-agent-to-every-agent architecture is not on the table [1]. The same forcing function shows up wherever a team has been flown or seriously field tested: SPHERES inside the ISS ran master/slave formation control and found performance highly sensitive to update transmission rate and comparatively insensitive to how much state each update carried, which argues for frequent small updates over infrequent full ones when bandwidth is the constraint [10]. JPL’s Robot Work Crew rovers, moving a rigid container between them outdoors, were deliberately built to avoid explicit inter-rover communication altogether, using the shared container itself, sensed through instrumented compliant gimbals, as the coordination channel [19][20]. A maritime team of four unmanned surface vessels running JPL’s CARACaS architecture kept plans in agreement across the team more than 80 percent of the time despite communication problems, without ever assuming a reliable link [16].

Who decides, and what happens when they cannot be asked

A team that cannot count on a ground cycle to arbitrate needs a way to pick who plans for the group, and a way to replace that choice when the network or the chosen agent stops cooperating. CADRE assigns three roles: a leader that runs strategic planning for the whole team, a designated survivor that holds planning state redundantly and takes over if the leader is lost, and standard rovers that run their own local controllers [2][7]. The election algorithm is built on Gallager-Humblet-Spira, constructing a minimum spanning tree over the possibly disconnected graph of agents and using its selected root to name the leader; because classical distributed leader election assumes properties embedded space robotics hardware does not provide, the practical additions are persistence across agents leaving and rejoining, reelection driven by changing agent health (normalized battery state of charge and CPU temperature, weighted equally) rather than a fixed leader, tolerance of clock drift, and an added weight on the incumbent to damp excessive churn. Raft and Paxos were both considered and rejected, Raft because it fails with fewer than three nodes and Paxos for its complexity relative to the redundancy available [2]. A leader is re-elected on a ten-second cadence, so losing the leader costs the team at most about ten seconds of idle planning time before the survivor takes over [7]. That number comes from CADRE’s own planner design, not from the election paper, which reports message counts falling as a four-agent test graph shrinks but no wall-clock election latency, so the ten-second figure has not been independently confirmed against the algorithm that is meant to produce it [2][7].

The stakes of getting this wrong are visible in a campaign where a comparable role assumption failed quietly: the SPHERES RINGS electromagnetic formation flight campaign on the ISS verified only one operating mode in checkout on the implicit assumption that a second, related mode would behave similarly, and a firmware bug in the untested mode went undetected for the rest of the campaign, degrading most of the science sessions that followed [13]. Nothing about that failure is specific to formation flight; it is a caution about validating every mode a coordinating system can enter rather than the ones convenient to test.

Dividing the work once a leader exists

With a leader in place, CADRE’s exploration planner partitions the unexplored area into sub-regions by k-means, one per rover, so each rover explores its own sub-region frontier by frontier without further inter-rover negotiation while driving [3]. Removing negotiation during exploration removes both the communication load and the collision management that a fully coordinated drive would need. A mission is counted complete when at least 95 percent of the total area has been explored [3].

Parameter	Simulation	Mercury-7 hardware	CADRE development model
Environment	ROS, 30 x 30 m	JPL Moon Yard, 6 x 6 m and 8 x 6 m regions	JPL Mars Yard
Map	150 x 150 cells at 0.2 m per cell	as simulation	flight-representative
Maximum velocity	2 m/s	0.05 m/s	flight-representative
Sensor footprint	2 m depth, 90 degree field of view	mapping reduced to 5 Hz	flight software mapping rate
Result	50 trials per scenario, 3 map layouts	3 scenarios including a resilience test	2724 m^2 explored across 15 runs, about 25 hours

Sources: [3] for simulation and Mercury-7 rows, [4] for the development-model row. The gap between 2 m/s in simulation and 0.05 m/s on hardware is the practical cost of running the algorithm on real compute and sensing rather than an idealized model [3]. On development model rovers running the actual flight software, the last five of fifteen runs averaged 0.035 m^2 per second of exploration rate, with most of those runs using two rovers rather than the mission’s three; the hardware numbers are terrestrial analog testing at Earth gravity under flood lighting, not lunar surface performance, and the paper that reports them predates flight [4].

Team-level division of labor is only half of the onboard planning problem; each rover also needs a planner-executive underneath it that turns a shared plan into commanded motion and recovers from the unexpected without waiting for a new plan from the leader. MEXEC, the integrated planning and execution approach CADRE’s onboard software builds on, merges planning and execution rather than separating them, sharing one timeline library between planner and executive so that when an unexpected event occurs the planner can replan while the executive keeps running the tasks the event did not affect. Its flight qualification ran on the ASTERIA 6U CubeSat, where it planned and executed observations of a star, a terrestrial city, the Moon and Vesta from 4 to 20 September 2019, and, once forced onto the testbed after the spacecraft was lost, recovered from a momentum-maintenance constraint violation and resumed observations all four times it was tested, within a 2 MB memory allocation that capped task networks at about 100 tasks, a limit specific to that spacecraft rather than a general planner bound [4]. CADRE’s flight software, including this planning and coordination stack, is built on F Prime, the flight software product line also flown on Lunar Flashlight and NEA Scout, and by the time of ATLO CADRE’s software had run multi-agent autonomy experiments on flight hardware in the cleanroom, though the product line’s own status briefing states no memory footprint, CPU utilization or timing margin for any of the missions it lists [8].

Shared state and shared maps under a bandwidth ceiling

Even with roles assigned and work divided, a team has to keep a consistent-enough picture of where things are. CADRE’s answer is MoonDB, which stratifies shared data into three classes by urgency: key data every agent needs for a consistent planning view, mission-critical data such as maps where total transmission matters more than latency, and time-sensitive data such as relative positioning between rovers on a collision course, whose value expires. Each class carries an explicit sharing policy of none, latest or all, tracked through replica and replication_log tables with per-agent acknowledgment, and the database persists across the periodic shutdowns the rovers undergo, so data from a previous wake cycle is still available when a rover wakes again [1]. Nowhere in the design paper is there an end-to-end bandwidth utilization, packet loss or synchronization latency measurement taken under the 1 Mbps EMI-limited link the whole scheme exists to accommodate, so the central claim that selective sharing keeps the link adequate is argued rather than measured [1].

Merging the maps rovers build independently is the specific case that motivated MoonDB’s multi-resolution and staleness rules. Higher-resolution information is taken as more accurate than lower-resolution information, and newer information at the same resolution as more accurate than older, and the merge is implemented in OpenGL so it runs on the GPU, giving an order-of-magnitude speedup over a naive CPU implementation once 100 or more maps are being merged, though the benchmark is reported only as that order of magnitude with no absolute time, hardware, or map size stated [1]. A rover glimpsed in another’s field of view is recorded as an obstacle in the observer’s map and persists there until the observer sees the region again with the other rover gone, because rovers do not share position directly into the map; the preference for newer data is what eventually clears it, so the failure is self-correcting only if the survey pattern revisits the area [1].

A different answer to the same bandwidth problem, explored specifically against CADRE as a motivating case rather than flown on it, is to share a model instead of a map: each agent trains an implicit neural network on its own local terrain and transmits only network parameters, about 399 KB for a 200,000-parameter network at 16 bits, which is an 89.5 to 93.8 percent reduction against CADRE’s converging covariance map but only a 0.7 percent reduction against a JPEG-compressed grayscale map of similar quality, and meta-initializing the network on terrestrial glacier traversability data before deployment cuts the iterations needed to reach a target reconstruction quality by about 80 percent [9]. The comparison against JPEG is the one that matters for a reader sizing a link, because the paper’s own numbers show the JPEG baseline reaching a better downstream path-planning F1 score than the compressed-model approach while costing about the same in bytes, so the transmission saving over an uncompressed map does not by itself argue for shipping model weights instead of a compressed image, and nothing in the comparison has flown: it is validated on a terrestrial glacier dataset and simulated Mars-like terrain, with CADRE only the motivating scenario [9].

Loss and prioritization when bandwidth is the binding constraint

The same bandwidth ceiling that shapes CADRE’s data-sharing policy shapes what a multi-robot team can afford to compute when the quantity of candidate information scales faster than the network. In multi-robot SLAM, the number of candidate loop closures between robots grows with the square of team size and environment size, but a communication-limited team can only compute a small fraction of them, so a terrestrial team working four DARPA Subterranean Challenge mines ranked candidates by predicted uncertainty reduction, by observability, and by radio beacon signal strength, and computed only the top-ranked ones, cutting median localization error by 51 percent against odometry alone while computing only 0.5 percent of the candidate loop closures in one four-robot run, though the result is inconsistent across environments: observability ranking performed worse than picking candidates at random in one dataset, and uncertainty ranking did not help in another, so no single ranking method is established as generally correct [14]. It is also entirely terrestrial, run under mine lighting, dust, and communication conditions that differ from planetary surface work, but the structural problem it solves, too much shared information for too little bandwidth, is exactly the one CADRE’s data-sharing policies exist to manage [1][14].

A team supervised by a single human rather than coordinating autonomously runs into the same ceiling from the operator’s side. Team CoSTAR’s heterogeneous ground and aerial robots, operating under one human supervisor in communication-degraded mines, drew little of that supervisor’s attention in one recorded run: 16 missions issued in total, four of them communication-node repositioning tasks each taking one to three minutes, and an information roadmap edited four times at about 40 seconds each, with the longest any robot spent out of contact before autonomously returning to communications being 800 seconds [15]. Nearly all failures traced to the commercial mesh radios’ 400 m line-of-sight range in tunnels rather than to the autonomy itself, and the quantitative interaction numbers come from a single run rather than a distribution [15].

The microgravity precedent

SPHERES flew the formation-flight version of the same coordination problem inside the ISS starting in the mid-2000s, well before CADRE, and its history is where several of the general lessons above were first learned in flight. The original design thesis validated the platform’s subsystems individually against the ISS requirements it would eventually have to meet: propulsion gave about 10 minutes of continuous station-keeping per tank, power gave at least 90 minutes, and laboratory global metrology gave 2 cm precision, with the vehicle’s formation-flight sensitivity to transmission rate over state size established in that same first hardware validation [10]. SPHERES performed the first autonomous docking to a tumbling target in microgravity on 11 November 2006, holding tangential alignment inside a 2 cm by 2 cm box for the last 20 seconds of a roughly 111-second approach, across nine on-orbit docking experiments of which seven succeeded cleanly and two made contact but misaligned due to ultrasound multipath in the state estimator [11]. In the March 2007 test session, two satellites starting back to back with pointing errors of 150 to 167 degrees ran two search strategies, a global search against the ISS beacon frame and a relative search using only satellite-to-satellite ultrasound, both converging to pointing errors under 10 degrees within about 60 seconds in the better runs, with multipath again repeatedly delaying convergence to 45 to 55 seconds in others [6]. A separate SPHERES study addressed reconfiguring a vehicle’s control system after its mass properties change through docking, finding the benefit significant only when the attached payload is comparable in mass to the satellite itself, and achieving about 5 cm steady-state error after reconfiguration in one hardware test while a companion autonomous-assembly demonstration at MSFC failed to execute for reasons attributed to test conditions rather than isolated as a design fault [12]. All of these results are two satellites or four software agents in a laboratory or the ISS, not a mission-scale team, and several of the underlying claims, such as the docking thesis’s headline success rate, mix sessions of very different sample size and completeness into one figure [10][11][12].

Coordination without a shared radio channel at all

Not every multi-agent coordination problem assumes a working mesh network. Lunokhod-1, the earliest vehicle discussed above, ran no inter-agent coordination at all; its five-person ground crew commanded it over a link with a round-trip delay of about 5 seconds and a programmed automatic stop 2.5 minutes after the last command, a baseline every later autonomy claim above is implicitly measured against [17]. Contemporary field tests of time-delayed teleoperated driving found that only about 15 percent of sortie time was spent actually driving, the rest spent studying terrain and correcting heading, and that stopping to wait out a communication delay before moving again produced fewer course departures than trying to drive through it, the opposite of what an operator’s intuition suggests [18]. JPL’s Robot Work Crew rovers, cooperatively carrying a rigid container across natural terrain, achieved this without any explicit radio coordination between the two vehicles at all, sensing the shared load through instrumented compliant gimbals instead, and one companion paper in the same research line reports the same rovers making stable 40- to 50-degree slope descents by reconfiguring their own wheel geometry from stereo terrain data, independent of the cooperative-transport work but from the same architecture [19][20]. A conceptual multi-robot scheduling study of assembling a proposed lunar radio telescope from tethered climbing rovers found that construction time has diminishing returns in team size, and that seven or more rovers complete the job within a single lunar day, removing any requirement for the assembly robots to survive lunar night, a design point drawn entirely from simulation with unbounded solver optimality gaps rather than from any built hardware [21]. Two flown helicopters and rovers on Mars solved coordination the same way JPL’s rock-moving crews did decades earlier, by geometry rather than negotiation: Ingenuity and Perseverance kept a minimum 45 m separation while the helicopter was in flight and a 3 m keep-out circle around it when parked, a rule enforced by distance rather than by any message passed between the two vehicles [22]. On the Moon, LEV-1 and LEV-2 deployed independently from SLIM in January 2024 and coordinated only once, when LEV-2 photographed the lander and handed the images to LEV-1 for relay to Earth, reported in an outreach article with no supporting telemetry [23].

What is not established

No flight has yet exercised CADRE’s coordination stack against the conditions it was designed for. The leader election algorithm has been demonstrated only as four software processes in simulation, not against the real EMI-limited mesh radio, and reports no wall-clock election latency to check against the ten-second cadence the planning paper assumes [2][7]. The team exploration algorithm’s hardware validation is terrestrial analog testing at Earth gravity under flood lighting, mostly with two rovers rather than the mission’s three, and predates flight entirely [3][4]. MoonDB’s central engineering claim, that stratified sharing policies make a 1 Mbps EMI-limited link adequate for a four-station team, has no end-to-end bandwidth, packet loss or latency measurement behind it in the paper that proposes it [1]. Alternatives to CADRE’s own map-sharing approach, such as transmitting learned terrain models instead of covariance maps, have been evaluated only on terrestrial and simulated data with CADRE cited as motivation rather than as a validation target, and the comparison against ordinary image compression undercuts rather than supports the case for the more complex approach [9]. Loop closure prioritization under bandwidth pressure, the clearest terrestrial precedent for managing exactly the kind of scarcity MoonDB is built around, gives inconsistent results across environments, so no ranking method there can be taken as generally correct [14]. Where teams have flown, in SPHERES and in Lunokhod, the numbers that exist describe two vehicles or a single ground-commanded rover, not the three-or-more-agent, largely autonomous teams the newer mission concepts assume, and several of the newer concepts, the lunar radio telescope assembly chief among them, are scheduling results computed against simulated, unbounded-gap optimizations rather than demonstrated hardware [11][21].