1 — Navigation independent of any single sensor
The estimator must survive temporary source loss and honestly increase its reported uncertainty.
MARS BIBLE — REFERENCE GUIDE
Guidance, navigation and control: the nervous system of a Mars vehicle
From the first sensor measurement to an engine command, understand the architecture that lets a vehicle know, decide, act, and verify without waiting for Earth.
ESTABLISHED FACTACTIVE ENGINEERINGPROSPECTIVE CHOICE
Why this deserves a full guide
A spacecraft is never piloted by one formula. A complete chain transforms the physical world into measurements, measurements into a state estimate, that estimate into decisions, and decisions into physical actions. This chain is called GNC: Guidance, Navigation and Control.
For Mars, the architecture is fundamental because Earth cannot close fast loops. A lander descending, a rover avoiding a rock, or a cargo vehicle executing a trajectory correction must act locally in fractions of seconds or seconds while interplanetary radio delay is measured in minutes.
1. Keep the three functions separate
Navigation estimates where the vehicle is, how it moves, and how it is oriented. Guidance decides where it should go or what attitude it should target. Control computes physical actions that reduce the difference between desired and estimated state.
The separation supports diagnosis. Correct guidance with bad actuation points toward control or hardware; good actuation driven by a wrong state estimate points toward navigation. Clear architecture improves verification and safety.
2. State is a compact model of the vehicle
Flight computers use a state containing position, velocity, attitude, angular rate and, when needed, mass, sensor biases or actuator states. The state is only as useful as the conventions attached to it.
Every component needs a frame, unit, time tag, and uncertainty. A vector of numbers without those attributes can be perfectly processed and still describe the wrong physical situation.
3. Sensors do not directly output truth
IMUs provide angular rates and specific force, star trackers provide absolute attitude when usable, cameras observe terrain, radio tracking provides range or Doppler, and altimeters measure local geometry. No single sensor gives a perfect complete state.
Navigation combines observations with dynamics. Noise, bias, update rate, validity domains and failures are modeled. Fusion is not blind averaging; inconsistent measurements must be detected and rejected.
4. Guidance turns mission goals into commands
Guidance may follow a precomputed path or recompute a target from observed state. A correction maneuver requires attitude, ignition time and desired delta-v. A lander may adapt its target as altitude, velocity and terrain information change.
Commands must remain within physical capability: thrust, propellant, gimbal, thermal and geometric limits. Mathematical optimality never overrides real vehicle constraints.
5. Control closes the feedback loop
The controller compares command with estimated state. A beginner may start with e = command - measurement and proportional action, while real vehicles add dynamics, prediction, saturation, actuator allocation and protection logic.
The result is measured again. Did the wheel turn? Did the burn produce the expected delta-v? Is the vehicle oscillating? Feedback turns a one-time command into a controlled system.
6. Actuators are where software meets physics
Reaction wheels provide precise internal torque but store momentum; thrusters provide external torque while consuming propellant; main engines change trajectory; mechanisms point antennas and arrays. Every actuator has resolution, delay, saturation and failure modes.
Software must allocate an abstract command into realizable wheel torques, pulse durations, gimbal angles or valve positions, including degraded configurations after failures.
7. Delay exists inside the vehicle too
Mars light time is dramatic, but onboard loops also contain camera exposure, sensor readout, filtering, bus transfer, computation, mechanical response and measurement delay. A delayed control action can destabilize a fast system.
Stability therefore belongs to the whole chain, not just one gain. Hardware-in-the-loop testing is valuable because real timing and interfaces are exercised before flight.
8. FDIR enables safe autonomy
Fault Detection, Isolation and Recovery detects abnormal behavior, identifies likely sources, and reconfigures the system. A blinded star tracker, saturated reaction wheel, or inconsistent sensor must not automatically create dangerous actuator commands.
Mars systems need explicit degraded modes. Sometimes the safe response is to stop a maneuver, enter a survival attitude, and wait rather than continue at all costs.
9. Redundancy must avoid common causes
Extra hardware does not automatically multiply safety. Two computers sharing one power converter can fail together. Common software and connectors can also defeat redundancy.
Functional diversity can help: cameras may provide coarse attitude after a star-tracker loss, and thrusters may replace some wheel capability. Diversity improves resilience but increases verification complexity.
10. Validation is more than one successful simulation
GNC is tested with dispersions in mass, sensors, atmosphere, engines and initial state, often through Monte-Carlo campaigns. Nominal, limit and fault conditions are explored.
Ground testing may include dynamic rigs, star simulators, injected radio signals and closed-loop hardware. Qualification asks whether model assumptions remain valid across manufacturing and environmental variation.
11. GNC becomes city infrastructure
A Mars settlement will use the same logic in transport rovers, cranes, drones, drills, pressurized vehicles, landing pads and pointing antennas. Position, attitude, command and feedback become a common automation language.
Shared local mapping, timing and interface standards could let machines from different suppliers exchange navigation state and operate safely together.
12. Humans remain in the strategic loop
Autonomy does not remove people. Humans define objectives, limits, abort criteria and procedures. Software closes fast loops within the approved envelope.
This division fits Mars: Earth retains delayed expertise and oversight while local crews and onboard systems manage real time. Clear authority avoids both impossible teleoperation and uncontrolled delegation.
18. Validation from simulation to hardware
A control law that works in an ideal simulation is not enough. Models must be challenged with computation delays, sensor noise, actuator saturation, mounting errors, mass-property dispersion and component failures. Testing can progress from software simulation to hardware-in-the-loop, benches and representative environmental demonstrations.
The practical validation question is: which errors were injected, which limits were reached, and how did the system respond? Nominal performance is only part of engineering confidence. Margin, failure behavior and recovery evidence matter just as much.
17. Degraded modes, safe mode and recovery
A reference system is designed not only for nominal operation but also for reduced capability. Loss of a star tracker may force a gyro-and-Sun-sensor mode. Loss of an actuator may restrict maneuver authority. Sensor disagreement should trigger comparison, isolation and possibly safe mode rather than blind trust in the most recent value.
The same philosophy applies to surface systems: slowing down, stopping, preserving energy and asking for local validation may be safer than continuing with uncertain navigation. Degraded modes should be designed and tested before failure; inventing them after the anomaly is not fault tolerance.
16. Control-loop rates and time hierarchy
Not every GNC function runs at the same rate. Inner stabilization loops may update tens or hundreds of times per second while strategic path planning changes far less often. Mixing these time scales creates fragile behavior: a slow planning task must not block rapid stabilization, and sensor noise must not rewrite the mission plan every millisecond.
Architecture therefore specifies what runs where, how often, with what priority and what happens when data arrives late. This becomes especially important on Mars, where local operations cannot wait for Earth and flight computers may be constrained by power, thermal limits and radiation tolerance.
15. Actuators must produce real torque
Attitude control can use reaction wheels, thrusters and other actuators. A reaction wheel exchanges angular momentum with the spacecraft: changing wheel speed rotates the body in the opposite direction. But the wheel cannot store unlimited angular momentum; eventually it approaches a speed or momentum limit and needs momentum unloading using an external torque source.
Earth-orbit spacecraft can sometimes use magnetic torquers against the ambient magnetic field. An interplanetary or Mars design must verify that the local field and mission geometry actually support that approach instead of copying it blindly. Thrusters are broadly applicable but consume propellant and create thermal, contamination and minimum-impulse constraints.
14. Absolute references, relative sensors and drift
Gyroscopes are excellent at tracking short-term rotation but integrated bias causes drift. A star tracker can provide an accurate absolute attitude reference by comparing observed stars with a catalog, yet it can be unavailable during some geometries or maneuvers. Sun sensors are simpler but provide less complete information. The engineering answer is usually sensor complementarity rather than one supposedly perfect instrument.
Position estimation follows the same logic. Inertial propagation is continuous but drifts; terrain images, radio measurements or orbital references can reset the estimate. A Mars settlement operating rovers, aircraft, cranes and landers therefore needs sensor fusion and explicit confidence estimates rather than coordinates treated as magically exact.
13. GNC is not one monolithic autopilot
Guidance, navigation and control are distinct functions. Navigation estimates the vehicle state: position, velocity, attitude and often sensor biases. Guidance decides which state should be reached next. Control turns the difference between desired and estimated state into commands for actuators. A failure can therefore originate in state knowledge, in the commanded target, or in the physical execution of that command.
This separation matters for diagnosis. A controller may perfectly execute a correction that is wrong because the attitude estimate is wrong. Conversely, navigation may be accurate while a saturated reaction wheel can no longer produce the requested torque. Robust architecture monitors these layers separately and checks consistency between sensors, estimators, guidance laws and actuators.
23. Minimum operational glossary
Attitude means vehicle orientation. State is the set of variables describing dynamics. An estimator combines models and measurements. A setpoint is a desired value. An actuator produces physical force or torque. Saturation is the limit beyond which an actuator cannot provide more effort.
Bias is a systematic measurement offset. Drift is growing error over time. Safe mode preserves the vehicle during serious anomalies. Redundancy provides alternatives only when common causes cannot disable all of them together.
22. Human interfaces for GNC
Even autonomous systems must present an understandable state to operators: estimated position, attitude, velocity, navigation quality, invalid sensors, saturated actuators and active mode. Coordinates and angles without uncertainty create false confidence.
Human commands also need error resistance: confirmation for irreversible actions, safety limits, predicted consequence displays and logging. Local Mars operators must be able to intervene without waiting for an Earth team several light-minutes away.
21. Define control authority
Control authority is the real physical ability of actuators to reject disturbances and follow commands. It depends on available force or torque, lever arms, mass, inertia, time and operating limits. A digital command of 100 percent cannot create physical capability that is not present.
Requirements should state which disturbances and maneuvers must be handled with margin, including credible failures. Robust engineering asks what remains controllable after one plausible actuator or sensor failure.
20. Case study: a fast rover on uncertain terrain
A slow rover can often stop when uncertainty rises. A faster vehicle needs a short perception-navigation-guidance-control loop so it can detect terrain, estimate state, choose a path and brake before travelling into danger. Computation delay becomes a safety distance.
At 10 metres per second, one extra second of delay means 10 additional metres travelled before response. This simple relation shows why local autonomy, software latency and update rate are safety parameters rather than mere software details.
19. Case study: a descent vehicle must stay aligned while braking
Imagine a vehicle braking while keeping its thrust axis precisely oriented. Gyros sense rapid rotation, an estimator reconstructs attitude, guidance provides a target orientation, and control commands thrusters or other actuators. If the real center of mass differs from the model, thrust can create an unexpected torque that the controller must cancel within its available authority.
This shows why structure, mass properties, propulsion and GNC cannot be designed independently. Changing payload can move the center of mass and alter inertia. Major hardware changes therefore require revalidation of control models and actuator margin.
27. What a Mars reference architecture should publish
A reference architecture should state frames, sign conventions, coordinate definitions, time standards, sensor and actuator assumptions, nominal loop rates, degraded modes, safe-mode entry conditions and the performance margins that matter. These details prevent teams from using the same words with different meanings.
Publishing the architecture does not mean exposing every implementation detail. It means making interfaces and assumptions explicit enough that navigation, propulsion, structures, communications and operations can integrate without hidden contradictions. That is the level of discipline required for a city rather than a one-off prototype.
26. GNC data belongs in the maintenance system
Bias trends, wheel momentum, thruster pulse counts, estimator residuals and sensor temperatures can reveal degradation long before complete failure. A mature settlement should preserve these time histories and relate them to maintenance records, software versions and environmental events.
That turns GNC telemetry into condition-based maintenance data. Operators can replace a degrading unit before a critical mission rather than discovering its weakness during descent or a remote traverse. The same philosophy supports fleet learning: one vehicle's anomaly becomes evidence for every comparable vehicle.
25. Common-cause failures can defeat redundancy
Two sensors are not truly independent if they share the same power rail, connector, software driver or viewing direction. Three flight computers do not provide threefold protection if a single corrupted software update reaches all three. Redundancy must therefore be analyzed against common causes, not merely counted as component quantity.
This matters especially on Mars where spare mass is expensive. The goal is not to duplicate everything blindly but to create diverse, testable recovery paths for the failures that matter most. Functional diversity may sometimes provide more resilience than identical duplication.
24. Engineering workflow from requirement to verified behavior
A GNC design begins with mission-level requirements: where the vehicle must go, how accurately it must point, which disturbances it must reject, how quickly it must respond and which failures it must survive. Those requirements become sensor accuracy, actuator authority, processor timing and software performance allocations. The process then runs backward during verification: each subsystem provides evidence that the integrated mission requirement can still be met.
The key discipline is traceability. If a pointing requirement becomes tighter, engineers should know which star tracker, structural stability, reaction-wheel and software requirements are affected. A Mars settlement with many reusable vehicles needs configuration management so that a change in one subsystem does not silently invalidate the validated behavior of another.
EXPERT LAYER — SYSTEM ARCHITECTURE
Design Mars GNC as a safety system, not just an algorithm
A reference GNC architecture remains understandable from sensor to actuator. Every transition has units, uncertainty, delay, limits and failure behavior.
2 — Guidance bounded by physics
A trajectory must not demand thrust, angle or energy the vehicle cannot provide.
3 — Control with explicit saturation
Actuator limits are part of control so internal states do not become inconsistent.
4 — FDIR and degraded modes
Every critical failure has detection criteria, a response and a strategy to return to a safe state.
Check before depending on the system
- coherent reference frames and time
- calibrated sensors with documented uncertainty
- validated dynamics simulator
- fault modes and transitions tested
- actuator saturation handled
- decision logging and traceability
- local authority defined during Earth loss
What this changes for a real Mars city
For a Mars city, GNC should not be an invisible proprietary black box in every machine. Position, time, map and diagnostic interfaces benefit from standards so rovers, cranes, drones and rescue teams can share a common operational picture.
The ultimate reference is not one algorithm but an engineering culture: explicit conventions, time-tagged data, uncertainty estimates, validation, redundancy and the right to enter a safe mode. That culture turns autonomy into reliability rather than opacity.
Learn the calculations in Space Academy
Institutional and primary sources
Go further with Arcadia
This public guide stands on its own. Arcadia — Manual of the First Martian City develops these systems as an integrated city architecture.