Guidance, navigation and control: the nervous system of a Mars vehicle

Guidance, navigation and control are three jobs that must not be confused

The acronym GNC groups three functions because they cooperate, but merging them conceptually hides responsibility. Navigation estimates vehicle state: position, velocity, attitude, biases and uncertainty. Guidance decides where to go and turns mission intent into an admissible trajectory. Control compares that trajectory with estimated reality and commands actuators.

This separation helps diagnose failures. If the vehicle believes it is somewhere else, look at state estimation and sensors. If state is correct but the objective becomes a bad trajectory, guidance is suspect. If the command is correct but motion does not follow it, investigate control and actuators.

A good GNC system is therefore not one monolithic “autopilot.” It is a chain of models, measurements, decisions and actions with verifiable interfaces. Modularity also helps degraded operation: a navigation source can change without rewriting all guidance logic.

On Mars GNC extends beyond spacecraft. Fast rovers, cranes, aircraft, conveyors, robot arms and construction machines all contain loops in which bad estimation can become a physical accident.

Navigation asks 'where am I and how am I moving?'. Guidance asks 'where should I go and what path respects the constraints?'. Control asks 'what command should I apply now to follow that path?'. Mixing these functions makes failures hard to diagnose. A vehicle can know its state perfectly and still receive an impossible goal, or have excellent guidance while an actuator can no longer deliver the required command.

The separation also clarifies software responsibilities. State estimation can publish position and covariance; guidance can produce a reference trajectory; control can check saturation and physical limits before commanding actuators. Clear interfaces allow each layer to be tested and degraded independently.

Estimation error and control authority should be budgeted together

Guidance can only command a trajectory that control can physically achieve, and control can only act on the state that navigation estimates. A position error is therefore not just a navigation metric: it can become additional propellant, time or landing dispersion. Similarly, an actuator saturation can make an otherwise accurate state estimate operationally useless. GNC review should connect covariance, update rate, sensor outages and actuator authority to mission events. When a critical sensor is lost, the question is not whether another sensor exists but whether the remaining set keeps the necessary state observable with enough accuracy for the available control authority. This coupling is especially important during short irreversible phases such as entry, landing and docking.

Vehicle state: a calculated truth built from imperfect measurements

An onboard computer never directly knows position or orientation. It receives accelerations, rotations, stars, images, altitude, radio velocity, pressures and mechanism positions. Measurements contain noise, bias and sometimes faults. State estimation fuses them with a dynamic model.

Uncertainty must travel with the state. A displayed position of 100.0 m is misleading if the real uncertainty is ±200 m. Kalman filters and related methods propagate uncertainty and correct predictions as new observations arrive.

Cross-sensor consistency is a defense. When sources disagree, majority voting is not automatically correct. The system considers expected dynamics, history, measurement quality and known fault modes. A precise but wrong value can be more dangerous than an honestly uncertain one.

This motivates FDIR — Fault Detection, Isolation and Recovery. Detecting an anomaly is only the first step; the system attempts to identify the faulty source, isolate its influence and rebuild an acceptable function with remaining resources.

State is not a single sensor reading. Position, velocity, attitude, angular rates, mass and sometimes environmental parameters are estimated from measurements containing noise, bias and delay. Navigation creates an operational truth from imperfect evidence. Covariance describes how uncertain that truth is and how errors are related.

Values also need trustworthy timestamps. A position that is two seconds old is not the current position of a fast vehicle. PNT, networking and GNC therefore meet at a common interface: measurement, measurement time and measurement quality must travel together. Data without uncertainty metadata can be more dangerous than missing data.

An estimator may also include parameters that are not directly observed: friction coefficient, effective wind, remaining mass or sensor bias. These augmented states allow the model to adapt to reality, but too many parameters can make the system poorly observable, meaning several causes can produce nearly the same measurements. Engineering therefore includes deciding what should be estimated and what should instead be bounded by design.

Observability reminds us that a sensor is useful only in relation to a question. An altimeter measures distance to the ground but not horizontal position by itself; a star tracker measures attitude, not velocity. Robustness comes from complementary information rather than sensor count alone.

Guidance: turning intent into a physically possible path

“Go to that point” is not directly a motor command. Guidance creates a path compatible with energy, speed, terrain, loads, reserves and forbidden zones. A lander must respect corridor, propellant and thrust capability; a rover must respect slopes, traction, obstacles and energy.

Guidance therefore works with constraints. A mathematically optimal path can be rejected because it leaves too little sensor margin or crosses an area with no rescue communications. “Optimal” has meaning only after the objective and constraints are declared.

In degraded conditions the objective changes. Guidance may abandon the destination and prefer a safe zone, beacon, stop or return. This reconfiguration should be designed before failure rather than improvised by nominal software.

At city scale guidance layers may eventually include traffic rules, emergency priority, dust zones and corridors reserved for heavy machinery. GNC then becomes part of urban infrastructure.

A human objective may sound simple — land near the base, reach a rover, keep an antenna pointed to Earth. Guidance has to turn it into a path compatible with propellant, speed, slope, obstacles, heating, acceleration and exclusion zones. It solves a constraint problem rather than drawing a straight line between two points.

When the environment changes, guidance may replan. But replanning is not always allowed: late changes during some phases can create more risk than they remove. Serious architectures define decision windows, abort criteria and fallback goals so autonomy knows when to change the mission and when to preserve a robust plan.

Control: closing the loop before physics has already won

Control receives a command and estimated state, computes error and demands action. Loop frequency depends on the phenomenon. Thermal processes can be slow; attitude, propulsion and aircraft may need rapid updates. Sensor, computation and actuator delay are part of stability.

A 10 Hz loop has a 0.1 s period. Even the smallest Earth–Mars delay spans thousands of such periods, so the control loop cannot run through Earth. Terrestrial operators define goals and limits while feedback remains local.

Actuators saturate. An engine has finite thrust, a reaction wheel stores finite momentum and a brake has a thermal limit. A controller ignoring saturation can command the impossible and accumulate dangerous error.

Validation therefore includes nonlinearity, delay, saturation, noise and off-nominal cases. Convergence in an ideal simulation is only the beginning of evidence.

The controller compares a reference with estimated state and produces an actuator command. Required frequency depends on dynamics: stabilizing a vehicle in flight demands far faster decisions than regulating a tank temperature. A loop that is too slow lets error grow; one that is too aggressive can excite structure, saturate actuators or become unstable.

Physical limits have to be explicit. A reaction wheel saturates, an engine may not throttle to zero, a valve takes time to move and a rover cannot change direction instantaneously on slippery ground. A controller that ignores these constraints can be mathematically elegant and operationally wrong.

Space and industrial control often use hierarchies. A fast inner loop stabilizes attitude or motor current, a slower loop follows velocity or trajectory, and an even slower supervisor changes goals. This respects the different time scales of the physics and mirrors the Earth–Mars latency problem: the fastest loops must close locally.

Actuator saturation deserves explicit treatment. Once an actuator reaches its limit, the controller no longer has the authority assumed by its equations. If software continues integrating error as though the command were achievable, it can build an excessive correction. Anti-windup logic, command limits and explicit control-authority margins are therefore practical safety features, not mathematical decoration.

FDIR and safe mode: surviving misleading data, not only clean failures

Easy failures are those that clearly announce disappearance. Hard failures continue to produce plausible values. A stuck altimeter, a camera matching the wrong terrain or a partially degraded actuator can mislead logic through critical seconds.

FDIR structures response: detect inconsistent behavior, isolate the suspicious equipment or measurement, reconfigure to a backup path, then verify that the recovered function is sufficient. The right decision may also be to slow down or abandon a maneuver.

Safe mode does not always mean “switch everything off.” In space, stopping heaters can kill electronics; during landing, stopping engines is impossible. Safe state depends on mission phase and time available. A rover can freeze; a lander must continue acting.

The same philosophy applies to Martian industrial systems. Conveyors, power systems and maintenance robots need local states that limit damage without waiting for Earth diagnosis.

A clean dead sensor can be easier than a sensor that continues transmitting plausible but false values. FDIR compares sensors, models and physical limits to detect inconsistency, isolate the suspected source and choose a fallback configuration. Redundancy only helps if redundant paths do not share the same common cause.

Safe mode must be designed before the failure. It does not necessarily mean stopping everything. A spacecraft can preserve thermal control, power and communications while reducing ambition; a habitat can isolate a loop and preserve minimum life support. Safety is the ability to reduce mission goals while protecting essentials.

The hardest failure is plausible but false data

A sensor that goes silent is easy to detect. A sensor that returns plausible but biased values is more dangerous. Imagine an inertial axis drifting slowly or a position measurement using the wrong time reference. The system can continue generating a clean-looking trajectory while reality diverges.

FDIR therefore compares independent sources and monitors residuals — the difference between model predictions and observations. Persistent anomalies can cause a sensor to be isolated, uncertainty to be increased or the system to enter safe mode. The correct response is not always to continue with the best available estimate; sometimes the safest decision is to stop.

Safe mode is not a button; it is a survival philosophy

A safe mode should reduce the number of things that can get worse. For an orbiter: stabilize attitude, protect power and thermal conditions, preserve communications. For a rover: stop on acceptable terrain, conserve energy, protect batteries and wait for a better navigation solution. For urban infrastructure: isolate a valve, disable autonomous commands and preserve life-support functions.

Safe modes must themselves be tested as real systems. Backup logic that is rarely used can contain latent defects. Hardware-in-the-loop testing is therefore essential because it confronts software with real timing, hardware limits and imperfect sensor behaviour.

Testing GNC: from mathematics to hardware that heats, vibrates and ages

Progressive validation prevents late discovery that a correct algorithm depends on an unrealistic sensor. Engineers move from analytical models to software-in-the-loop, hardware-in-the-loop, component tests, integration, environmental campaigns and injected anomalies. Each level hunts a different family of errors.

Hardware-in-the-loop connects flight software to real or representative hardware while a simulator supplies the outside world. Delay, sensor loss, saturation and faults can be imposed without sacrificing a vehicle.

Configuration must be controlled: software version, tables, calibration, filter parameters, firmware, sensors and actuators. A success with configuration A does not automatically qualify configuration B. This becomes even more important once locally repaired or manufactured parts appear on Mars.

Long-term autonomy therefore requires local test capability. Repairing an actuator without being able to measure its dynamic response is not true industrial independence. GNC connects software, metrology and manufacturing.

Pure simulation can explore thousands of cases, but it does not automatically reproduce bus delays, quantization, actuator saturation, wiring faults and thermal behavior. Hardware-in-the-loop testing replaces part of the model with real hardware while simulating the rest of the vehicle, revealing interface failures that do not exist in an ideal mathematical world.

Validation also needs degraded cases: intermittent sensors, delayed data, underperforming actuators, mass uncertainty, blinded cameras and congested networks. A robust architecture proves more than nominal success; it maps the region in which confidence breaks down and defines what the system does near those boundaries.

Testing builds a chain of confidence: Monte Carlo simulation explores dispersions, software-in-the-loop checks algorithms, hardware-in-the-loop tests interfaces, benches exercise actuators and integrated demonstrations bring subsystems together. Each level reveals a different family of defects; none alone qualifies the whole behavior.

Post-arrival software maintenance raises another question: how do you change a system whose safety depends on exactly what was validated? Updates need version control, testing on a reference representation, staged deployment and rollback. A settlement cannot treat flight software like a consumer application that silently updates overnight.

Testing autonomy means searching for cases where it succeeds for the wrong reason

A conventional test checks that a command produces the expected trajectory. Autonomy adds another question: did the system choose the action for the correct reason? An algorithm can reach its objective despite a calibration error because another error accidentally compensates for it. Testing must inject failures, plausible false values, delays, conflicting messages and mission changes.

The most valuable scenarios are those that require the algorithm to refuse action. Credible autonomy recognizes when information quality is no longer sufficient. Demonstrating that refusal behaviour can be harder than demonstrating nominal performance.

Decision autonomy: moving intelligence without blindly moving authority

Interplanetary delay forces some decisions onboard but does not justify unbounded autonomy. Architecture can separate reflex, tactical and strategic decisions. Reflexes live inside control loops; tactical choices can belong to vehicle or crew; strategic choices can be shared with Earth when time permits.

This hierarchy makes autonomy testable. Engineers define what a robot may do alone, which resources it may commit, which thresholds force a stop and which situations require human authority. Logs then explain why an action was chosen.

NASA has experimented with autonomous operations for years because communication delay grows with distance. The objective is not simply to replace people; it is to preserve mission capability when people cannot intervene quickly enough.

For a city the question becomes political: which decisions may be automated, which must remain human, and which can be made locally without Earth? Technical GNC naturally opens into governance.

Mars requires many decisions to move toward the vehicle or crew, but decisions do not all carry the same consequence. Perception autonomy can be broad: detect obstacles, diagnose sensors, estimate routes. Action autonomy can be bounded: avoid within a corridor, reduce power, enter safe mode. Irreversible actions or those consuming strategic reserves may remain human decisions.

This layered authority avoids two caricatures: the passive robot waiting for Earth and the sovereign AI running a colony alone. A credible architecture assigns each function a decision domain, boundaries, explainability and a human recovery path. Latency forces autonomy; it does not abolish responsibility.

AutoNGC: from autonomous navigation to autonomous execution

NASA now describes autoNGC as a software suite providing onboard navigation, autonomous maneuver planning, executive decision-making and control functions when reliance on the ground becomes too slow or unavailable. The important point is not vague “intelligence.” It is moving selected decision loops closer to the physics.

A vehicle that detects trajectory drift can compute a correction, verify constraints, schedule a burn and execute it without waiting for several radio exchanges. But that capability requires an authority hierarchy: which maneuvers may be executed automatically? Which limits force a stop? When is human approval required? Safe autonomy is autonomy whose boundaries are explicit.

Software has to distinguish “possible,” “permitted” and “desirable”

A trajectory can be physically possible but prohibited because it crosses a safety zone. A maneuver can be permitted but unnecessary. An optimizer can save propellant while increasing operational risk. Autonomy therefore has to manage several constraint layers: physics, mission, safety, traffic rules and human intent.

This becomes even more important in a city. A rescue rover may be allowed into an area normally closed to traffic; a delivery vehicle may not. Emergencies can relax some rules and tighten others. Authority has to be encoded in an auditable form rather than hidden inside an opaque objective function.

AutoNGC: onboard autonomy moves beyond science-fiction vocabulary

Guidance, navigation and control can be separated conceptually. Navigation estimates state: position, velocity, attitude and uncertainty. Guidance chooses a feasible path toward an objective. Control converts that path into commands for thrusters, wheels or other actuators. Mars delay adds a fourth concept: executive autonomy, the ability to replan without waiting for Earth.

NASA describes autoNGC in 2026 as combining autonomous navigation, manoeuvre planning, executive decision-making and control. The goal is not to remove humans but to move the timing boundary. A vehicle can handle an urgent correction, verify constraints and prepare a new plan before ground operators could respond.

Autonomy requires limits. Software may adjust a trajectory inside a permitted envelope but not consume a strategic reserve without authorization; it may shut a pump on overpressure but not abandon an occupied habitat; it may avoid an obstacle but not enter a protected zone. Safety rules become formal guidance constraints.

For a city, the question scales from one autonomous vehicle to many. Nobody can teleoperate every decision made by rovers, drones and industrial robots. The challenge is proving that a population of machines follows rules compatible with collective safety.

State estimation, covariance and confidence: know what the system does not know

The word 'position' sounds exact. In practice a navigation system has an estimate and uncertainty. The same is true for velocity, attitude, battery state or sensor health. GNC therefore tracks confidence as well as values. Covariance is one way of representing how errors evolve and how measurements constrain them.

That uncertainty changes behaviour. A rover localized to one metre can enter a narrow corridor; at fifty metres of uncertainty the same command is unsafe. A lander must know not only that it is aimed at a safe region but that navigation uncertainty fits inside that region.

Hard cases appear when sensors disagree. An IMU sees motion, imagery does not, and a radio measurement arrives late. The system must diagnose likely faults, isolate data when justified and increase uncertainty rather than invent certainty. The right response may be to slow, enter safe mode or request an additional observation.

This is a central lesson for autonomy: a reliable machine is not one that claims to know everything. It is one that recognizes when its model of the world is too uncertain for nominal operation.

FDIR, safe modes and local authority: contain errors before they cascade

FDIR means Fault Detection, Isolation and Recovery. A vehicle monitors sensors, computers, actuators and power, detects anomalies, isolates their domain and recovers an acceptable function. At city scale the same philosophy applies to networks, pumps, rovers and energy systems.

Safe mode does not always mean shutdown. A rover far from the base may need heaters and communications; a drone may need to land; a power system may reduce output rather than go dark. The refuge state depends on context, resources and time to assistance.

Validation is difficult because combined faults grow combinatorially. Sensor freeze, noise, latency, clock loss, map disagreement, weak actuators and software errors must be exercised in simulation and hardware-in-the-loop testing. No campaign proves every case, so conservative envelopes and simple recovery paths remain essential.

A command from Earth can arrive after the vehicle has already entered a safe configuration. The local system must decide whether the command is still valid. The ability to reject an obsolete but correctly formatted command is one of the most revealing features of interplanetary autonomy: authority is partly a problem of time.