AI for Spacecraft Sensing & Control

A useful model needs a place in the loop

A spacecraft does not experience a neural network as a benchmark score. It experiences the resulting state estimate, maneuver, actuator demand, and heat load. A model that predicts a visually convincing pose can still produce a state inconsistent with the vehicle's motion. A fast trajectory proposal can still violate a thrust or pointing constraint. The survey therefore asks how learned functions work within the rest of the flight system.

The recurring architecture is modular. Learning extracts image features, supplies a prediction, or proposes a candidate solution. Geometry, filtering, optimization, and feedback control then turn that output into an executable decision. This arrangement makes the contribution of a learned component easier to isolate and its limitations easier to test.

Navigation: follow the image all the way to state

Relative navigation around a non-cooperative target illustrates why interfaces matter. A learned detector or keypoint network provides observations; a geometric solver recovers pose; a temporal estimator checks consistency over time. Recognition, single-image pose estimation, and tracking solve different problems, even when they share a visual encoder.

The survey's SPNv2 example separates an offline model improvement from later adaptation using unlabeled laboratory images. It also identifies archived PRISMA flight images that were processed on the ground. These distinctions matter: evaluation on flight imagery establishes a kind of data relevance, but does not by itself establish onboard execution or closed-loop flight performance.

For deployment, ask which target geometry is known, how detections are obtained, how uncertainty enters the estimator, and what happens to rare large errors. A second camera, a wireframe model, and a learned shape prior each supply different information. Their costs and assumptions belong in the comparison.

Guidance and control: a proposal still needs checking

Trajectory prediction can accelerate an optimizer by providing a useful initial guess. In that role, the downstream solver remains responsible for the adopted dynamics and constraints. The meaningful measurements include final feasibility, solution time, fuel or energy use, and the cost of unsuccessful proposals—not merely network inference time.

Learned feedback control has a more direct relationship with the vehicle. The survey discusses LeLaR as evidence of learned attitude control in orbit, while emphasizing the calibration, sensing, and monitoring needed around the controller. The surrounding engineering determines what the experiment demonstrates and where the result applies.

A useful evaluation must include actuator saturation, uncertain inertia, observation errors, and asynchronous execution. A protective supervisor also needs a feasible backup action and enough time to complete it. Intervention counts and recovery outcomes reveal behavior that an average tracking error can conceal.

Thermal prediction changes what a maneuver costs

Computing, pointing, and motion share a physical platform. A change in attitude alters solar exposure and power generation. A larger inference workload increases processor demand and heat. An operational decision therefore has thermal and electrical consequences as well as a geometric trajectory.

Thermal surrogates can make repeated prediction cheaper. Steady-state models support design sweeps; recurrent models capture temperature histories; transfer learning can correct discrepancies using flight measurements. Prediction accuracy must be interpreted against the available component margin and the timing of the temperature peak. A low average error is not an upper bound on the next error.

A predictor also cannot create cooling authority that the hardware lacks. Radiators, conductive paths, heaters, and available operating modes define what a scheduler can actually change. Closing the loop requires testing both the forecast and the physical response to the proposed schedule.

Read the evidence along three axes

Keep three questions separate: where did the data come from, where did the software run, and what authority did it have? Synthetic images, laboratory measurements, and flight telemetry describe the data. A workstation, target processor, and spacecraft describe execution. Advisory predictions and actuator commands describe authority. One label such as ‘space-tested’ cannot replace these details.

The survey's practical progression is to reproduce a bounded task, validate the deployed implementation, test the coupled system, demonstrate restricted operational use, and then evaluate controlled updates. At every stage, retain failure cases and a comparable baseline. The question is whether learning enables more useful work under the same mission constraints.