Software

Flight software and autonomy, organized by the problem the code solves rather than by the vehicle that carried it. A page belongs here if it describes something that runs, on a processor, under a real-time or downlink constraint.

Round-trip light time sets the boundary, seconds at the Moon and hours in the outer solar system. Every technique here exists because some decision had to be made inside that window, or because the data to make it on the ground would not fit down the link. The processor sets the second boundary. On the Mars Exploration Rovers, stereo matching of a 256x256 pair took 24 to 30 seconds on the 20 MHz RAD6000, a full obstacle avoidance cycle about 70 seconds and a visual odometry step about 160 seconds, which held median net driving speed near 0.6 cm per second [1]. The same cost explains why rovers still stop, perceive, plan and step: the Stanford Cart worked that way in 1979 because one move took minutes of computation [2].

What the software knows

Localization and perception turn sensor data into a position and a map. The mathematical core is older than any flight program: gradient-based image registration [3], scale invariant keypoints [4], robust model fitting by random sample consensus [5], recursive estimation [12] and the uncertainty-weighted merging of perceptions into a world model [6]. Dense stereo, the range source on every flown rover, is compared by a common taxonomy of matching cost, aggregation, optimization and refinement [7]. Flown systems used a small, conservative subset of these methods on flight-qualified processors; most of the published literature has been demonstrated only in laboratories, test yards or simulation, and each page below states which.

What it decides

Planning spans three time scales. Local path selection repairs a cost-to-goal field when a sensor shows an arc cost was wrong, without replanning from scratch [8]. Onboard planning and execution was flown as the Remote Agent on Deep Space 1, with a shared goal profile between ground and spacecraft [9]. For rovers, a planner that replans during execution to handle over- and under-subscription and opportunistic science was demonstrated in the JPL Mars Yard, not on Mars [10]. Control covers attitude and trajectory, manipulators and free flyers. Null-space obstacle avoidance on a redundant arm dates to simulation work in 1985 [11], and real-time obstacle avoidance for manipulators and mobile robots was formulated in 1986 [30]. Curiosity’s traction control is a flown control algorithm with published flight results [31]. Formation flying controllers are now checked in a common simulator before running on air-bearing free flyers [24].

How it survives being wrong

Fault management rests on the dependability taxonomy of faults, errors and failures [13]. Two flight cases anchor the field. SIFT put redundancy in software, with each processor voting on its neighbors’ results and no hardware voter [15]. Flown fault protection is documented for the Mars Exploration Rovers [25] and for the Curiosity fault protection engine [26], and NASA’s study of flight software complexity [27] frames why that code is hard to verify. Mars Pathfinder’s resets were reported as a priority inversion in which a low-priority task held a bus mutex [14]; that account circulated as an email summary of a keynote, not a mission report, so its details carry that weight.

How it talks and what it runs on

Communications and data handling share one constraint: the link is narrow and intermittent. Delay Tolerant Networking was proposed for Mars and lunar relay and evaluated in simulation [17], then profiled for space use as a CCSDS standard [16]. Onboard compression is the other lever, for example a progressive wavelet compressor for hyperspectral images derived from the MER image compressor [18]. The ICER compressor itself is described in [29]. The MER relay and direct-to-Earth link design is documented in [28]. The platform side runs from the layered core Flight System [19] to the argument that commercial multicore parts, not FPGAs, are the route to higher onboard computing, a proposal with a stated requirements list rather than a flown part [20].

How people work with it and how it is verified

As command authority moves onboard, ground tools have to support goal and priority based commanding instead of sequences, a gap identified in a two year JPL study [22]. The flown reference for collaborative ground planning is the Mars 2020 activity planning tool [21]. Verification is covered through model-based software engineering practice on SMAP [23] and through simulation fidelity and hardware-in-the-loop pages.

What has flown and what is being tried

Flown perception and navigation. The Mars 2020 Lander Vision System reduced a 3.2 km initial horizontal position error to under 40 m within 10 seconds, matching up to 150 patches per image against a 6 m/pixel onboard map; it is the first operational terrain relative navigation on a planetary landing [32]. On the surface, visual odometry was used on 87 percent of Curiosity drives over nine years, and a flight software change to process images while driving was tested on a terrestrial testbed, not on Mars [45]. Perseverance flew onboard global localization by repurposing Ingenuity’s Snapdragon 801 base station as a co-processor, matching post-drive orthomosaics to a HiRISE map to within 1 m on benchmark data; the flight phases were open loop [33].

Flown planning and onboard science. The Mars 2020 onboard planner is a priority-first, non-backtracking scheduler, described before it took control of the rover [34]. The MEXEC planner and executive flew on the ASTERIA CubeSat in September 2019, with the reactive capability shown only on a testbed [39]. AEGIS ran 237 times on Curiosity between sols 1343 and 2830 and selected 284 ChemCam targets, usually in under 500 seconds on the RAD750 [41].

Flown software infrastructure. Ingenuity ran F Prime in three deployments on three processors [37]. Curiosity’s mobility downlink assessment is now largely automated: over 80 percent of the chair’s work, with nominal assessments falling from 30 to 45 minutes to under 10 [42].

Ground-tested or pre-flight. The CADRE three-rover lunar demonstration has a multi-agent architecture and planner tested in cleanrooms and the Mars Yard, with no flight data in the cited papers [36][35]. A learned traversability predictor cut perception latency from about 500 ms to 140 ms on an off-road vehicle in desert terrain, scored against its own training labels [43]. SPLICE hazard detection software was measured on helicopter-collected lidar maps, with true positive rates of 50 to 70 percent and false positive rates of 0.4 to 0.6 percent at operational step sizes [44].

Verification. Mars 2020 fault protection validation executed 265 scenario cases of a minimal set of 150 [38]. The Surface System Development Environment ran flight software against commercial avionics to relieve scarce flight-like testbeds, at the cost of fidelity gaps that surfaced later as operational problems [40].

Pages

Communications, control, data handling, fault management, flight software, human interaction, localization, multi-agent, perception, planning and verification each have a section. Every page carries the cost of the technique on the hardware it ran on, and says whether the method flew, was tested on the ground, or was only proposed.

What is not established

Cost figures are available for the Mars Exploration Rover processors [1]; comparable published figures for newer flight computers and for most of the learned perception and planning methods are not held in the corpus. The Pathfinder reset account [14] is a secondary source. Multicore and onboard-autonomy proposals [20][10] lack flight data. The CADRE papers report no flight data [36][35], and the SPLICE rates come from post-processed replay of one hazard field [44].