CADRE

NASA/JPL-Caltech. Public domain (NASA / US government work).

Overview

CADRE is a JPL technology demonstration of cooperative multi-robot operation on the lunar surface: three mobile rovers and one static base station mounted on the lander [9]. Conventional planetary surface operations command one vehicle at a time through a ground-generated sequence, which does not scale to multi-agent systems because each additional vehicle adds operator effort and consumes bandwidth that is already latency-limited. CADRE tests whether a team accepts a high-level goal such as “explore this region” and decomposes it onboard into commands for individual mobility systems and instruments [1], [9].

Two experiments are planned. In the exploration experiment the team is given the boundary of a region whose contents are unknown, and must observe every reachable portion of it with onboard stereo cameras and classify each portion as traversable or obstacle. In the distributed sensing experiment the rovers drive in formation between assigned waypoints while collecting multi-static ground-penetrating radar soundings [1], [9].

The exploration algorithm is semi-centralized: an elected leader partitions the unexplored area by k-means into non-overlapping subregions, one per robot, and each robot then explores its own subregion from frontier points without further coordination, which is what keeps inter-robot communication low and spreads the work evenly [8]. It was tested on prototype Mercury-7 rovers running a ROS navigation stack in JPL’s Moon Yard, then on development model rovers running the CADRE flight software in JPL’s Mars Yard, including night testing under floodlighting and 30 minute wake-sleep duty cycles; across 15 development model runs the rovers explored 2,724 square meters in about 25 hours, averaging 0.035 square meters per second over the last five [8].

Specifications

Parameter	Value	Source
Agents	3 mobile rovers plus 1 lander-mounted base station	[9]
Locomotion	four wheels	[9]
Power	solar, with rechargeable battery per rover	[9], [1]
Minimum battery state of charge modeled by the planner	20 percent	[1]
Flight computer	ModalAI VOXL, Qualcomm Snapdragon with integrated GPU	[2], [10]
Flight software framework	F Prime, inherited in part from the Mars Helicopter VOXL port	[1], [10]
CPU operational temperature limit	65 degrees C
Enforced wake-sleep cycle	shutdown at 25 and 55 minutes past each hour, restart at 0 and 60 minutes past
Onboard sensing	stereo camera pair per rover, navigation sensors, ground-penetrating radar	[1], [9]
Inter-agent link	mesh network radios between rovers and the base station	[9]
Flight software size	73,239 hand-written F Prime component lines on the rover deployment, 59,833 on the base station deployment	[10]

Rover mass, dimensions, top speed and battery capacity are not published in the retrieved sources or on the program page.

Mission profile

The parameters below describe the flight CADRE has been assigned, not the vehicles.

Parameter	Value	Source
Lander	Intuitive Machines Nova-C, CLPS task order CP-11, flown as IM-3, Intuitive Machines’ third lunar delivery	[7], [9]
Landing site	Reiner Gamma, western edge of the lunar near side
Launch	2026, in a mission window extending into early 2026
Surface duration	the daylight hours of a single lunar day, about 14 Earth days
Base station	carried on the lander, gateway to Earth	[1], [9]
Deployment	each rover lowered from the lander by tether on its own deployer	[7]

The retrieved planning literature gives flight as 2025 or 2026 [1]; the program page gives 2026 in a window extending into early 2026 and names the flight IM-3 [7], which is the same vehicle as the CP-11 task order. The physical characteristics of the CP-11 landing site and the payload manifest it was chosen to serve are not published.

Mobility

Each rover has four wheels [9]. Published mass, dimensions and speed figures are not published or given on the program page. In-situ lunar soil relative density is about 65 percent in the top 15 cm and exceeds 90 percent below 30 cm [4], and regolith bulk density runs 1500 to 1640 kg/m3 across highland and mare samples [3].

The rover chassis itself is a conventional aluminum 6061 box structure, distinguished in launch-vibration analysis from JPL’s flexible-hinged PUFFER chassis: for a rigid box like CADRE’s, qualifying to a Gaussian random vibration spectrum with a few dB of margin adequately bounds the non-Gaussian response a real launch produces, which is not true of flexible structures [12].

Driving is invoked by the planner as a task with a destination and a modeled duration, power impact, and thermal impact. A separate task exists purely to stop a drive early when time or resource constraints approach violation, because drives otherwise terminate only on arrival. Guidance, navigation, and control runs below the autonomy layer and reports back when a commanded trajectory cannot be followed [1], [9]. The single-agent mobility stack beneath that layer combines visual-inertial-solar state estimation with multi-resolution local mapping and global and local path planners [9].

For formation driving, the leader computes a team trajectory by sampling-based motion planning over the rovers’ joint state space, then assigns each rover a time-stamped corridor, or tube, around its nominal path. If every rover stays inside its tube, the maximum allowable deviation in inter-rover distance is guaranteed not to be violated. If one rover cannot stay in its corridor, all rovers stop and the leader computes a new collision-free team trajectory [1], [9].

Power and energy

The rovers carry batteries recharged by solar arrays; the base station is powered by the lander and has no battery of its own. The rover battery design uses Saft MP176065-xtd lithium-ion cells selected from a wider JPL wide-temperature battery development effort spanning low-temperature electrolytes for missions such as InSight and high-temperature formulations for hot environments [13].

Battery state of charge is one of three resources the onboard planner models explicitly, and must be held above a minimum threshold, given as 20 percent by way of example [1], [9]. State of charge is modeled through the MEXEC impact mechanism, in which each task declares the state change its execution produces so later tasks can be checked against predicted values [5]. The planner predicts state of charge linearly from a roll-up of the power loads of every behavior a task starts, against the known battery capacity. Recharge and heater discharge are estimated coarsely from lunar time of day. Heater draw appears as a background discharge rate that is reduced during power-consuming tasks, on the modeling assumption that a uniform 80 percent of any electrical load is dissipated as usable heat, and solar array performance loss due to rover tilt is omitted from the planning model for simplicity [1], [9].

Simulation showed that when the sun is high, stopping the drive and other tasks allows the arrays to recharge the batteries. At other times the agent must be commanded into a low-power mode through an explicit shutdown task [1], [9]. Solar geometry at Reiner Gamma gives near-equatorial illumination rather than the grazing incidence of a polar site [3].

Thermal

Thermal limits and power limits bind at opposite ends of the lunar day. When the sun is low, energy is scarce but overheating is not a risk. Around lunar noon the rovers can drive for only a few minutes before CPU temperature exceeds its operational limit of 65 degrees C [1]. Lunar surface temperature at 45 degrees latitude reaches a mean 350 K at local noon and falls to a mean 89 K before sunrise; Reiner Gamma lies close to the equator, where the equatorial maximum of 391 K applies [3].

Task impact on temperature depends nonlinearly on starting temperature, ambient temperature, rover tilt, and applied power load. Simulations were run at solar elevations from 20 to 90 degrees in 10 degree steps [1], cycling through the rover operating modes repeatedly. Sun angle and operating mode emerged as the two dominant factors in rate of temperature change, and CPU temperature was the most constrained thermal state in every simulation, so the planner models CPU temperature alone, treating each rover as a single-node thermal model [1], [9].

CPU temperature at the start of an operating mode had minimal effect on the subsequent heating rate, so it was dropped from the model. The rate of change was nonlinear, steep initially and levelling off after about two minutes, consistent with conduction and radiation [1]. MEXEC task impacts model state change at linear rates [5], and analysis showed that piecewise task splitting would gain little compared with replanning more often, so a linear rate was retained.

Compute and avionics

Each agent runs a ModalAI VOXL system-on-a-chip module, built on a Qualcomm Snapdragon with an integrated GPU, which is what makes high-resolution local traversability mapping fast enough for real-time rates onboard [2]. The VOXL port itself was inherited from the Mars Helicopter, contributing about a fifth of the hand-written flight software lines on each deployment; roughly 40 percent of the rover deployment and half of the base station deployment is code shared between the two, with the remainder specific to each [10]. Flight software uses F Prime, the open-source JPL framework for small-scale flight software, running under Linux [1], [10]. Radiation tolerance approach and memory sizing are not described in the retrieved literature.

An FPGA outside autonomy control runs a hardware timer that shuts all agents down at 25 and 55 minutes past each hour and restarts them at 0 and 60 minutes past [1], [9]. This enforced wake-sleep cycle is the hard boundary the planner works within: every experiment must make progress in bounded 25-minute increments, and the planner must anticipate the shutdown, stop driving, and place the agent in low-power mode before the timer expires so that logs and state can be written out [1], [9].

Autonomy

Autonomy is organized as leader election, centralized planning on the leader, decentralized execution on every agent, and multi-agent constraint checking on the leader [1], [9]. Leader election, consensus and distributed spanning-tree construction are standard families in the multi-agent algorithm literature, cataloged alongside formation control and task allocation, where relatively few published algorithms have actually been field-tested and most of those exchange only simple information such as agent positions [6].

Leader election. A distributed minimum spanning tree algorithm, GHS, selects a unique appointer among the agents every ten seconds. The appointer designates as leader whichever agent’s state is farthest from violating its thermal and power constraints, then broadcasts that designation [1], [9]. The algorithm adds properties an embedded robot team needs beyond the textbook GHS construction: persistence across agents leaving and rejoining, reelection driven by changing health rather than a fixed leader, tolerance of clock drift through a hardware rate-driven query that queues or drops messages depending on whether the sender’s clock leads or lags, and an added weight on the incumbent to damp excessive leader churn, so hysteresis prevents the leader changing except on large state excursions, and the module names a designated survivor holding a copy of the leader’s information. In a four-agent case study with rovers dropped and reconnected one by one, message counts fell as the graph shrank and leader ordering tracked the expected normalized state of charge and CPU temperature ranking [11].

Shared state database. The shared state database is implemented over SQLite with a custom application-layer synchronization protocol. State needed for strategic planning that cannot be inferred locally is synchronized to the leader and the designated survivor every ten seconds. The database deliberately does not guarantee inter-agent consistency in the CAP sense, preferring availability and tolerance of network partitions; stale leader information degrades plan quality but cannot produce uncoordinated action, because only the leader plans. All planning-relevant information is held on at least two agents, so information is lost only if both leader and designated survivor fail within the ten seconds before a replacement pair is elected [1], [9].

Strategic planning. The leader runs a strategic planner implemented in MEXEC, the Multi-mission EXECutive [1], [9]. MEXEC comprises a planner, an executive and a timeline library the planner searches for valid intervals in which to place tasks; the ground sends a task network, the planner schedules against system state read from a state database, and sufficiently close to a task’s start time the planner hands it to the executive, which performs real-time constraint checking [5]. A task carries a unique ID, a name, a ground-specified priority, a command, expected impacts describing the state change executing it produces, and constraints describing the conditions required for execution; impacts and constraints may apply before, during or after the task. In the CADRE formulation a task is a tuple of flight software command, expected duration, constraint set and impact set; constraints are either state constraints bounding a system state between limits or precedence constraints, and state constraints divide into pre-execution constraints checked before start and maintenance constraints checked throughout. MEXEC flew previously on the ASTERIA CubeSat, from 4 to 20 September 2019, where it planned and executed uploaded task networks for astronomical and Earth observations and, in a second experiment forced by the spacecraft’s later loss, recovered a momentum-maintenance violation by dispatching a momentum dump and resuming observations rather than losing them to a reset, within a 2 MB memory allocation capping task networks at about 100 tasks [5]. Its design contrast with the Mars 2020 Onboard Planner is that MEXEC is multi-mission while the Onboard Planner has a specialized algorithm with limited choice points and a fixed timeline library [5].

The planner runs at 1 Hz, evaluating replan triggers, committing new tasks, deleting old ones and checking multi-agent constraints [5]. Replanning is triggered by conflict detection, task failure and experiment milestones. A task whose scheduled start falls within a five-second window is committed to the relevant agent controller [5]. The rate and the window are the two MEXEC timing parameters: the plan process interval must exceed the worst-case duration of a planner cycle, and the commit window must be at least as long as the plan process interval, because tasks are committed only at the start of a cycle and must be committed before they start [5]. Committed tasks are excluded from conflict checking, since they may already be executing, and conflicts arising during their execution are handled by the executive rather than the planner.

The scheduling algorithm unschedules any uncommitted task, applies current measured state, then greedily schedules the remaining tasks in priority order, each as close to its preferred start time as constraints allow, rejecting any task that cannot be placed without violation [5]. Valid intervals come from the MEXEC timeline library, which holds each referenced state or resource as its own timeline of atomic, state, claimable, cumulative or cumulative-rate type, projects task impacts forward on those timelines to predict future values, and reports a conflict where a constraint’s window contains a projected value outside its prescribed bounds; impacts may assign a value, a change in value, or a change in rate [5].

Work already completed is not carried in the planning state, because its effects are fully captured by the rovers’ maps in the exploration experiment and by their positions in the distributed sensing experiment. That property is what allows one scheduling process to serve every replan regardless of cause [1], [9].

Decentralized execution. Every agent runs an agent controller that observes only its own state [9]. The controller checks task constraints before and during execution, may delay a task whose starting constraints are unmet, and may declare a task failed when a maintenance constraint is violated, in which case it issues cleanup commands to leave the agent recoverable. Execution state is reported back to the leader’s strategic planner, which uses it to trigger rescheduling [1], [9]. MEXEC allows an immediate executive response to task failure to be defined as a command, and allows the planner to add tasks to the network from templates that were not explicitly requested in the schedule [5]. Where execution deviates from the scheduled time, the task’s impacts and constraints are moved on the timelines to reflect actual execution.

Multi-agent constraints. Constraints that no single agent can evaluate, because they depend on another agent’s state, are checked on the leader. A multi-agent pre-execution constraint cannot delay a task directly, since the leader does not control execution; the leader instead issues an abort. Abort messages are reduced to a single task ID to maximize the probability of timely delivery over a disrupted link [1], [9].

Exploration. Unknown portions of the target region are partitioned by the leader into as many k-means sub-regions as there are rovers and assigned one per rover. Each rover then runs frontier-based exploration in its own sub-region with no further coordination during driving, which removes inter-robot collision management from the exploration task. Maps are periodically synchronized to the leader, which merges them into a joint map, and sub-regions are recomputed as the unknown area shrinks [1], [8]. Frontier candidates are computed from the shared traversability map and rovers are assigned to targets that minimize cost while maintaining communication with the base [2]. Global map construction runs on MoonDB, a centralized database on the base station that stores and fuses the per-agent traversability maps; its data volume grows with agent count and exploration extent and bottlenecks map construction.

A federated alternative has been evaluated against the same problem: each agent trains a 2D neural-field map representation on its own local traversability map online and transmits only network parameters, about 399 KB for a 200,000-parameter network at 16 bits, to the base station, which are aggregated into a global model and redistributed [2]. Communication payload falls by 89.5 to 93.8 percent against transmitting raw maps, though against a JPEG-compressed grayscale map at similar quality the reduction is only 0.7 percent; meta-training the network with Reptile on Earth mapping datasets such as KITTI before flight cuts the iterations needed to reach target map performance by about 80 percent against random initialization, validated on the Athabasca Glacier dataset and the DoMars16k Martian geomorphology dataset [2].

Communications

The base station acts as the communication gateway between the rovers and Earth, and also performs computational tasks for the team. The rovers communicate over an inter-agent network; the planning literature characterizes it operationally rather than by band, noting that the lunar surface differs from the low Earth orbit multi-agent case because surface obstructions interrupt links and partition the network, which is why the shared state database is designed for partition tolerance rather than consistency [1], [9]. Radio bands, data rates, and link margins are not published.

Payload and instruments

The primary payload is a distributed ground-penetrating radar [2]. Each rover carries a radar unit and the measurement is multi-static: transmission from one rover is received by the others, so the subsurface return depends on the geometry of the team rather than on any single traverse. Formation keeping is therefore a data-quality requirement. Ground operators specify a team waypoint, typically tens of meters from the rovers’ starting position, a formation expressed as a set of inter-rover distances, and a maximum allowable deviation from that formation which, if respected, ensures sufficient radar data quality. Each rover also carries stereo cameras, used for the exploration experiment’s traversable and obstacle classification and for onboard mapping [1], [9].

Modes of operation

Operation is structured by the FPGA-driven wake-sleep cycle rather than by a conventional mode table. Within each 25-minute wake period [1] the team pursues one of two goals, continued exploration or continued distributed measurement. Testing exercised transitions among autonomy, nominal, and safe modes. A shutdown task places an agent in low-power mode, used both ahead of the scheduled FPGA power-off and when solar recharge is insufficient. Task-level states include delayed start, when pre-execution constraints are unmet, and failure with cleanup, when a maintenance constraint is violated during execution [5].

Ground operations

Ground operators uplink goals rather than sequences: for exploration, the boundary of the region to be explored; for distributed sensing, a team waypoint, a formation specification, and a formation tolerance [1], [9].

Operators retain one explicit lever over team composition. By default all agents participate in an experiment, but operators may exclude one or more, either after a failure or to support anomaly investigation. This is implemented as a task constraint requiring the assigned agent’s state to report it as participating. For exploration, where tasks execute independently, that constraint behaves like any other. For formation sensing it cannot, because driving may only be scheduled if the tasks for all participating rovers can be scheduled together; the task network therefore contains alternate hierarchies, one per possible subset of the three rovers, with larger subsets assigned higher priority [1], [9].

Verification used a graded set of venues: batch planning, ROS simulation, the Dragonfarm testbed of networked ModalAI VOXL modules running the full flight software deployment, development model rovers with flight-equivalent computing and actuation but a reduced sensor suite, and the flight models themselves [1]. That ladder runs from block driver stubs through these venues to flight models [10]. Development models were driven outdoors in the JPL Mars Yard across exploration regions from 6 by 6 m to 22 by 13 m, with distributed sensing goals 6 to 20 m from the starting position, in terrain ranging from sparse to cluttered rock and crater fields and including night-time testing under harsh shadows [8]. Flight models, confined to the cleanroom, carried temperature and state of charge sensors the development models lacked, and ran Autonomy Day-in-the-Life tests exceeding 9 hours of continuous FPGA-driven wake-sleep cycling with all four agents present, which the three-agent development model fleet could not reproduce [1].

Technologies developed

The mission’s intended product is demonstrated technology readiness for multi-agent planning, scheduling and execution on a planetary surface, for infusion into later science-driven missions [1], [9]. Task-based onboard commanding was adopted because conventional ground-generated sequences respond to unexpected states by entering safe mode, which forfeits subsequent scheduled science; a planner holding intent and modeled effects onboard can instead replan and continue executing whatever tasks remain constraint-safe [5].

Specific transferable results already visible are the leader-election architecture with a designated survivor, which makes centralized planning survivable under agent loss [1], [11]; the availability-over-consistency shared state database, which makes centralized planning workable over a partition-prone surface network; the time-stamped corridor formulation, which converts a formation-keeping requirement into per-rover constraints checkable locally; and the extension of MEXEC from single-spacecraft to multi-agent use [1], [9]. The wide-temperature battery cell selection and the F Prime component structure, including the fraction of the flight software inherited from the Mars Helicopter VOXL port, are both intended for reuse on later lunar rovers rather than treated as CADRE-specific engineering [13], [10].

The V and V campaign is itself presented as a contribution, on the grounds that validating autonomy across simulation, flight-equivalent compute, and flight hardware, each of which can exercise only part of the system, is a general problem for autonomous multi-agent spacecraft [1], [9].

What is not established

Rover mass, dimensions, top speed, battery capacity, radio bands, data rates and link margins are not given in the retrieved planning and architecture papers or on the program pages, and radiation tolerance approach and onboard memory sizing are not described. The mission has not yet flown: the exploration and distributed-sensing algorithms, the flight software line counts, and the leader-election and formation results above come from ground testing, simulation, and one prior flight of the MEXEC executive on a different spacecraft, not from lunar operation. The landing site’s physical characteristics and the payload manifest driving the CP-11 task order are not published.