4.1.11 Sensor Selection for Space Missions

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor selection for a spacecraft is a system-level GNC design problem, not simply a comparison of datasheet accuracy. The correct sensor suite must provide the required state knowledge, observability, accuracy, update rate, availability, integrity, and robustness throughout every mission phase while satisfying spacecraft constraints such as mass, power, volume, thermal environment, radiation, interfaces, qualification, reliability, cost, and schedule.

The fundamental engineering chain is

\[ \boxed{ \text{Mission Objectives} \rightarrow \text{Mission Phases} \rightarrow \text{GNC Functions} \rightarrow \text{States to Estimate} \rightarrow \text{Measurement Requirements} \rightarrow \text{Sensor Requirements} \rightarrow \text{Candidate Sensors} \rightarrow \text{Sensor Suite} \rightarrow \text{Verification} } \]

4.1.11.1 Why Sensor Selection Is a System Problem

The system-level nature of sensor selection means that a device cannot be judged only by one performance number. Its real value depends on how it contributes to observability, estimation accuracy, control bandwidth, fault tolerance, mission-phase coverage, and spacecraft accommodation. A sensor that is superior in isolation can be inferior once power, geometry, latency, environment, or redundancy are included.

No spacecraft sensor should be selected independently of the mission.

A star tracker may provide extremely accurate attitude measurements but become unavailable because of Sun or Earth exclusion constraints.

A GNSS receiver may provide excellent position and velocity in LEO but become unusable or geometrically limited outside the GNSS service volume.

A magnetometer may be lightweight and reliable but cannot independently provide complete instantaneous three-axis attitude.

A camera may provide excellent target bearing during rendezvous while providing weak range observability.

A LiDAR may provide excellent range but consume more power and become useful only inside a particular operational range.

Therefore,

\[ \boxed{ \text{Best Individual Sensor} \neq \text{Best Spacecraft Sensor Architecture} } \]

The objective is to select a complementary sensor suite.

4.1.11.2 Start from the Mission, Not the Datasheet

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Before evaluating hardware, define the mission.

Important questions include:

What orbit will the spacecraft operate in?
What is the mission duration?
What attitude knowledge is required?
What position and velocity knowledge are required?
Is relative navigation required?
Is autonomous navigation required?
Are rendezvous, proximity operations, docking, landing, or formation flying required?
What pointing accuracy is required?
What are the maximum angular rates?
What accelerations occur?
Will GNSS signals be available?
Will celestial references be visible?
What are the radiation and thermal environments?
What failures must the spacecraft tolerate?
How long can individual sensors be unavailable?

Sensor selection begins with these mission questions.

4.1.11.3 Mission Requirements → GNC Requirements

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Mission requirements must first be converted into GNC requirements.

For example,

\[ \boxed{ \text{Payload Imaging Requirement} \rightarrow \text{Pointing Requirement} \rightarrow \text{Attitude Knowledge Requirement} } \]

Similarly,

\[ \boxed{ \text{Docking Requirement} \rightarrow \text{Relative Position/Velocity/Pose Requirement} \rightarrow \text{Relative Navigation Sensor Requirement} } \]

and

\[ \boxed{ \text{Orbit Determination Requirement} \rightarrow \text{Position/Velocity Knowledge Requirement} \rightarrow \text{GNSS / Ranging / Ground Navigation Requirement} } \]

This prevents arbitrary sensor selection.

4.1.11.4 Identify the States That Must Be Estimated

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

The navigation system may need to estimate some or all of

\[ \mathbf x = \begin{bmatrix} \mathbf r \\ \mathbf v \\ \mathbf q \\ \boldsymbol{\omega} \\ \mathbf b_g \\ \mathbf b_a \\ \mathbf x_{\text{relative}} \\ \mathbf x_{\text{calibration}} \end{bmatrix} \]

where

\(\mathbf r\): spacecraft position,
\(\mathbf v\): spacecraft velocity,
\(\mathbf q\): attitude quaternion,
\(\boldsymbol{\omega}\): angular velocity,
\(\mathbf b_g\): gyro bias,
\(\mathbf b_a\): accelerometer bias,
\(\mathbf x_{\text{relative}}\): relative navigation states,
\(\mathbf x_{\text{calibration}}\): sensor alignment, scale factor, clock, or other calibration states.

The required states determine the required measurements.

4.1.11.5 Measurement Requirements

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For each state, determine:

\[ \boxed{ \text{Accuracy} } \] \[ \boxed{ \text{Precision} } \] \[ \boxed{ \text{Update Rate} } \] \[ \boxed{ \text{Latency} } \] \[ \boxed{ \text{Dynamic Range} } \] \[ \boxed{ \text{Availability} } \] \[ \boxed{ \text{Integrity} } \] \[ \boxed{ \text{Continuity} } \]

A measurement requirement should ideally be traceable to a mission requirement.

4.1.11.6 Sensor Selection Is Mission-Phase Dependent

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

One of the most important concepts is:

\[ \boxed{ \text{One Sensor Suite Does Not Necessarily Serve Every Mission Phase Equally} } \]

Consider a spacecraft performing rendezvous and docking:

\[ \text{Launch} \rightarrow \text{Detumbling} \rightarrow \text{Nominal Orbit} \rightarrow \text{Far-Range RPO} \rightarrow \text{Mid-Range RPO} \rightarrow \text{Final Approach} \rightarrow \text{Docking} \]

Different sensors may dominate each phase.

For example:

Mission Phase	Important Measurements	Possible Sensors
Launch	high-rate motion	IMU
Detumbling	angular rate + coarse attitude	gyro + magnetometer + Sun sensor
Nominal orbit	precise attitude	gyro + star tracker
Orbit determination	position/velocity	GNSS
Far-range RPO	relative orbit	GNSS / differential GNSS
Mid-range RPO	relative range/bearing	camera + LiDAR
Final approach	precise relative pose	camera + LiDAR
Docking	close-range pose/range/rate	vision + LiDAR + dedicated docking sensors

Thus sensor architecture should be developed as a mission-mode matrix.

4.1.11.7 Sensor Selection by Measurement Type

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A useful first classification is by the quantity being measured.

Attitude

Possible sensors:

star tracker,
Sun sensor,
magnetometer,
horizon sensor,
camera,
GNSS attitude system.

Angular Rate

Primarily:

gyroscope,
IMU.

Absolute Position and Velocity

Possible sources:

GNSS,
ground tracking,
optical navigation,
radiometric navigation.

Specific Force

Primarily:

accelerometer,
IMU.

Relative Position and Velocity

Possible sensors:

differential GNSS,
camera,
LiDAR,
radar,
laser rangefinder,
RF ranging.

Relative Attitude/Pose

Possible sensors:

monocular camera,
stereo camera,
LiDAR,
structured-light or dedicated docking vision system.

4.1.11.8 Attitude Sensor Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Spacecraft attitude determination usually benefits from combining rate sensors with absolute/reference-vector sensors.

A common architecture is

\[ \boxed{ \text{Gyroscope} + \text{Absolute Attitude Reference} } \]

The gyro provides high-rate propagation.

The absolute sensor bounds gyro drift.

4.1.11.9 Gyroscope Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Gyroscopes are selected based on:

rate range,
angle random walk,
bias instability,
bias repeatability,
rate random walk,
scale-factor stability,
bandwidth,
update rate,
latency,
g-sensitivity,
vibration sensitivity,
temperature dependence,
radiation tolerance,
mass,
power.

A useful conceptual relationship is

\[ \boxed{ \text{Gyro Performance} \rightarrow \text{Attitude Propagation Performance Between Absolute Updates} } \]

For precision pointing, low bias and low ARW may dominate.

For detumbling, sufficient angular-rate range may dominate.

4.1.11.10 MEMS vs FOG vs RLG Gyroscopes

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

MEMS

Advantages commonly include:

low mass,
low power,
small size,
lower cost.

Limitations can include:

greater bias instability,
greater temperature sensitivity,
larger stochastic drift.

FOG

Fibre-optic gyroscopes generally provide:

better bias stability,
lower drift,
good precision.

But typically with increased:

mass,
power,
cost.

RLG

Ring-laser gyros can provide very high inertial performance but are generally associated with greater system complexity and SWaP than small MEMS devices.

The technology should be selected from mission requirements rather than technology reputation alone.

4.1.11.11 Star Tracker Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A star tracker is generally preferred when high absolute attitude accuracy is required.

Important parameters include:

cross-boresight accuracy,
around-boresight accuracy,
FOV,
limiting magnitude,
update rate,
lost-in-space acquisition time,
tracking rate,
maximum slew rate,
Sun exclusion angle,
Earth exclusion angle,
Moon exclusion angle,
latency,
thermal stability,
radiation tolerance.

A star tracker is particularly useful for

\[ \boxed{ \text{Precision Attitude Knowledge} } \]

but visibility must be analyzed over the actual spacecraft orbit and attitude profile.

4.1.11.12 Star Tracker Availability

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Nominal accuracy alone is insufficient.

Define approximate availability as

\[ A_{ST} = \frac{T_{\text{valid star tracker}}} {T_{\text{mission phase}}}. \]

Losses may occur due to:

Sun intrusion,
Earth limb,
Moon,
bright objects,
high slew rate,
excessive jitter,
radiation events,
thermal conditions.

A slightly less accurate tracker with better availability may produce better mission-level GNC performance.

4.1.11.13 Sun Sensor Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sun sensors are attractive because they can be:

simple,
lightweight,
low-power,
robust.

They are commonly used for:

safe mode,
Sun acquisition,
coarse attitude,
solar-array pointing.

Coarse Sun Sensor

Typically emphasizes:

\[ \boxed{ \text{Wide FOV + Robustness} } \]

Fine Sun Sensor

Typically emphasizes:

\[ \boxed{ \text{Higher Angular Accuracy} } \]

often with narrower useful FOV.

4.1.11.14 Magnetometer Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Magnetometers are commonly used in Earth orbit for:

coarse attitude determination,
detumbling,
B-dot control,
magnetorquer control,
momentum unloading support.

Selection parameters include:

range,
noise,
resolution,
bias,
temperature coefficient,
scale factor,
cross-axis error,
update rate.

But spacecraft magnetic cleanliness may dominate intrinsic sensor performance.

Therefore,

\[ \boxed{ \text{Magnetometer Selection} + \text{Magnetic Placement} + \text{Calibration} } \]

must be considered together.

4.1.11.15 Why Magnetometer Placement Matters

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Magnetic contamination can come from:

magnetorquers,
reaction wheels,
motors,
current-carrying harnesses,
DC/DC converters,
batteries,
ferromagnetic structures.

For an approximately dipolar disturbance,

\[ B_{\text{disturbance}} \propto \frac{1}{r^3}. \]

Therefore moving the magnetometer away from magnetic sources can dramatically reduce contamination.

4.1.11.16 Coarse Attitude Sensor Suite

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A common low-cost architecture is

\[ \boxed{ \text{Gyro} + \text{Sun Sensor} + \text{Magnetometer} } \]

The Sun and geomagnetic vectors can provide two non-collinear reference vectors.

This enables algorithms such as TRIAD.

The gyro provides propagation between vector measurements.

4.1.11.17 Precision Attitude Sensor Suite

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A common precision architecture is

\[ \boxed{ \text{Gyro} + \text{Star Tracker} } \]

The gyro supplies high-rate angular propagation while the star tracker provides low-drift absolute attitude updates.

The combination is well suited to an MEKF or related attitude estimator.

4.1.11.18 Why Sensor Fusion Changes Sensor Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A sensor does not necessarily need to satisfy the complete state-knowledge requirement by itself.

Suppose:

\[ \text{Gyro} \]

has high bandwidth but drifts.

A star tracker has:

\[ \text{Absolute Accuracy} \]

but a lower update rate.

Combining them provides:

\[ \boxed{ \text{High-Rate Propagation} + \text{Long-Term Absolute Correction} } \]

This complementary behaviour is central to sensor-suite design.

4.1.11.19 Accelerometer Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Accelerometers are important for:

inertial navigation,
maneuver reconstruction,
thrust estimation,
drag/non-gravitational acceleration measurement,
launch dynamics,
planetary descent,
precision navigation.

Selection parameters include:

range,
bias,
bias stability,
velocity random walk,
noise density,
scale factor,
nonlinearity,
bandwidth,
vibration rectification,
temperature stability.

4.1.11.20 Accelerometer Selection Depends Strongly on Mission

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A launch vehicle may require:

\[ \boxed{ \text{Large Dynamic Range} } \]

while a drag-free or precision orbital mission may require:

\[ \boxed{ \text{Extremely Low Noise and Bias} } \]

These are very different sensor problems.

A sensor optimized for \(\pm 50g\) launch measurements is not automatically ideal for measuring extremely small orbital accelerations.

4.1.11.21 IMU Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

An IMU generally combines

\[ \boxed{ 3\times\text{Gyro} + 3\times\text{Accelerometer} } \]

and may additionally include:

magnetometer,
temperature sensors,
processor,
calibration coefficients.

IMU selection must examine the complete device rather than only one gyro specification.

Important parameters include:

gyro ARW,
gyro bias instability,
accelerometer VRW,
accelerometer bias,
axis alignment,
synchronization,
update rate,
latency,
vibration performance,
environmental qualification.

4.1.11.22 GNSS Receiver Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

GNSS selection for spacecraft is fundamentally different from selecting a terrestrial receiver.

Important questions include:

Is the receiver intended for space operation?
What altitude is supported?
What velocity is supported?
What acceleration is supported?
What Doppler range can it track?
Which constellations are supported?
Which frequencies?
Are raw measurements available?
Is carrier phase available?
Is PPS available?
What are TTFF and reacquisition times?
What radiation testing exists?

4.1.11.23 GNSS Constellation Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Possible constellations include:

GPS,
Galileo,
GLONASS,
BeiDou,
NavIC,
QZSS.

A multi-constellation receiver can increase

\[ \boxed{ \text{Satellite Availability} } \]

and improve geometry.

However it can also increase:

RF complexity,
antenna requirements,
processing,
software complexity,
power.

4.1.11.24 Single-Frequency vs Multi-Frequency GNSS

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Single Frequency

Advantages can include:

simpler receiver,
lower power,
lower cost.

Multi-Frequency

Can improve:

ionospheric correction,
ambiguity resolution,
precision navigation,
robustness.

For high-precision navigation,

\[ \boxed{ \text{Multi-Frequency} } \]

may be highly beneficial.

4.1.11.25 GNSS Raw Measurements

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For advanced spacecraft navigation, verify availability of

\[ \boxed{ \rho,\quad \Phi,\quad D,\quad C/N_0 } \]

where

\(\rho\): pseudorange,
\(\Phi\): carrier phase,
\(D\): Doppler,
\(C/N_0\): carrier-to-noise density.

Raw observables are essential for many:

differential techniques,
tightly coupled filters,
carrier-phase algorithms,
custom navigation algorithms.

4.1.11.26 GNSS for Relative Navigation

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Two spacecraft can use GNSS measurements to estimate relative state.

The relative position is

\[ \boxed{ \mathbf r_{rel} = \mathbf r_c-\mathbf r_t } \]

and relative velocity

\[ \boxed{ \mathbf v_{rel} = \mathbf v_c-\mathbf v_t. } \]

Simply subtracting independent GNSS PVT solutions is possible, but high-precision RPO often benefits from common-measurement differential processing.

4.1.11.27 Differential GNSS for RPO

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Differential techniques exploit common errors between spacecraft.

Potential benefits include improved relative:

position,
velocity,
timing.

Carrier-phase processing can further improve relative navigation under suitable geometry and ambiguity resolution.

Therefore, for precision RPO,

\[ \boxed{ \text{Raw GNSS Capability} } \]

can be more important than headline standalone PVT accuracy.

4.1.11.28 GNSS Antenna Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

The GNSS receiver and antenna should be treated as one navigation subsystem.

Important antenna characteristics include:

frequency bands,
gain,
radiation pattern,
polarization,
axial ratio,
phase-center stability,
multipath sensitivity,
active/passive architecture,
LNA characteristics.

Spacecraft structure can significantly alter antenna performance.

4.1.11.29 GNSS Antenna Placement

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Placement should consider:

clear sky visibility,
spacecraft blockage,
solar arrays,
payload structures,
RF interference,
multipath,
antenna phase center.

For relative navigation, antenna location relative to spacecraft reference points must also be known.

4.1.11.30 Camera Selection for Spacecraft Navigation

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Cameras can provide:

target detection,
line-of-sight,
bearing,
feature tracking,
pose estimation,
optical navigation,
docking navigation.

Important parameters include:

detector resolution,
pixel pitch,
focal length,
FOV,
frame rate,
exposure,
dynamic range,
SNR,
global/rolling shutter,
radiation tolerance,
processing requirements.

4.1.11.31 Camera Angular Resolution

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For pixel pitch \(p\) and focal length \(f\),

\[ \boxed{ IFOV\approx\frac{p}{f} } \]

for small angles.

But navigation accuracy is not simply one IFOV.

Subpixel feature extraction can improve measurement precision, while optical distortion, blur, calibration, target geometry, SNR, and algorithm performance can degrade it.

4.1.11.32 Camera FOV Trade

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Wide FOV gives:

\[ \boxed{ \text{Easier Acquisition} } \]

but generally provides fewer pixels across a distant target.

Narrow FOV gives:

\[ \boxed{ \text{Better Angular Detail} } \]

but makes target acquisition and retention more difficult.

This motivates multiple-camera architectures in some missions.

4.1.11.33 Monocular Camera

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Advantages:

low mass,
passive sensing,
relatively simple hardware.

A key limitation is that instantaneous range can be weakly observable without additional information.

A monocular camera often measures bearing more directly than range.

4.1.11.34 Stereo Camera

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Stereo vision introduces a known baseline.

Idealized depth scales approximately as

\[ \boxed{ Z=\frac{fb}{d} } \]

where

\(f\): focal length,
\(b\): stereo baseline,
\(d\): disparity.

Stereo can provide range information but requires:

two cameras,
calibration,
synchronization,
sufficient target texture,
additional processing.

4.1.11.35 LiDAR Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

LiDAR is attractive for rendezvous and docking because it can provide direct range and 3-D geometry.

Important specifications include:

minimum range,
maximum range,
range accuracy,
range resolution,
angular resolution,
point rate,
FOV,
target reflectivity sensitivity,
update rate,
latency,
power,
radiation,
eye/laser safety where applicable.

4.1.11.36 LiDAR Range Equation Considerations

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Practical detection depends on factors such as:

\[ \boxed{ \text{Transmitted Power} + \text{Target Reflectivity} + \text{Range} + \text{Incidence Angle} + \text{Receiver Aperture} + \text{Background} } \]

Therefore a quoted maximum range should not automatically be assumed achievable against every spacecraft surface.

4.1.11.37 Camera + LiDAR

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

These sensors are highly complementary.

Camera:

\[ \boxed{ \text{Strong Angular / Feature Information} } \]

LiDAR:

\[ \boxed{ \text{Strong Range / 3-D Geometry} } \]

Together:

\[ \boxed{ \text{Camera + LiDAR} \rightarrow \text{Improved Relative Pose Observability} } \]

This is particularly useful during close-range RPO.

4.1.11.38 Radar Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Radar may be considered where:

long-range detection is needed,
illumination conditions vary strongly,
optical sensing is unreliable,
direct range/range-rate information is valuable.

Selection factors include:

operating frequency,
antenna size,
transmit power,
range,
range resolution,
angular resolution,
Doppler accuracy,
target radar cross section,
SWaP.

4.1.11.39 Laser Rangefinder

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A laser rangefinder can provide accurate scalar range:

\[ \boxed{ \rho=\|\mathbf r_{rel}\| } \]

but does not by itself provide full relative position or pose.

It can be combined with camera bearing measurements.

4.1.11.40 Sensor Observability

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor selection must ask:

Does the proposed measurement actually make the required state observable?

For nonlinear navigation,

\[ \mathbf z=h(\mathbf x)+\mathbf v. \]

The measurement Jacobian is

\[ H=\frac{\partial h}{\partial\mathbf x}. \]

If important state directions are not represented sufficiently in the measurement geometry, accuracy alone cannot solve the problem.

4.1.11.41 One Vector Does Not Give Full Attitude

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A Sun sensor provides

\[ \mathbf s^B. \]

But rotation around \(\mathbf s^B\) leaves that vector unchanged.

Therefore one vector cannot instantaneously determine all three attitude degrees of freedom.

A second non-collinear vector, gyro history, dynamics, or another measurement is needed.

4.1.11.42 Bearing-Only Navigation

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A camera may provide

\[ \hat{\boldsymbol{\ell}} = \frac{\mathbf r_{rel}} {\|\mathbf r_{rel}\|}. \]

This gives direction but not instantaneous range.

Thus

\[ \boxed{ \text{Excellent Bearing Accuracy} \not\Rightarrow \text{Excellent Range Accuracy} } \]

Range may become observable through relative motion, target size, dynamics, or another sensor.

4.1.11.43 Measurement Geometry

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Measurement geometry strongly affects navigation quality.

For GNSS, this appears through DOP.

For optical navigation, it appears through:

viewing angle,
baseline,
target geometry,
feature distribution.

For attitude sensors, it appears through reference-vector separation.

Sensor selection should therefore include geometry simulation, not only datasheet comparison.

4.1.11.44 Sensor Accuracy Allocation

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Suppose total allowable navigation error is

\[ \sigma_{\text{NAV,req}}. \]

A simplified error budget might satisfy

\[ \boxed{ \sigma_{\text{NAV}}^2 = \sigma_{\text{sensor}}^2+ \sigma_{\text{alignment}}^2+ \sigma_{\text{timing}}^2+ \sigma_{\text{model}}^2+ \sigma_{\text{estimator}}^2 } \]

when contributions can reasonably be treated as independent.

The sensor itself should therefore usually perform better than the complete system requirement.

4.1.11.45 Requirement Margin

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For a maximum allowable error,

\[ M=p_{\text{req}}-p_{\text{predicted}}. \]

For a minimum required performance,

\[ M=p_{\text{predicted}}-p_{\text{req}}. \]

Positive margin is desirable.

But the correct margin must include uncertainties and degradation.

4.1.11.46 Beginning-of-Life and End-of-Life

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A sensor may satisfy requirements at BOL but degrade due to:

radiation,
ageing,
thermal cycling,
contamination,
calibration drift.

Therefore,

\[ \boxed{ \text{BOL Compliance} \not\Rightarrow \text{EOL Compliance} } \]

Sensor trades should consider end-of-life performance whenever data are available.

4.1.11.47 Dynamic Range Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A sensor must survive and measure the maximum credible operational dynamics, not merely nominal conditions.

For gyroscope:

\[ |\omega|\leq\omega_{\max}. \]

For accelerometer:

\[ |a|\leq a_{\max}. \]

For optical sensors, dynamic limits may involve:

maximum slew,
exposure blur,
tracking rate,
target angular rate.

4.1.11.48 Why Excessive Range Is Also Undesirable

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Selecting the widest possible range is not always optimal.

For fixed digital resolution,

\[ \Delta \approx \frac{FSR}{2^N}. \]

Therefore increasing \(FSR\) can worsen quantization resolution.

The engineering objective is:

\[ \boxed{ \text{Required Range} + \text{Reasonable Margin} } \]

rather than maximum available range.

4.1.11.49 Sensor Bandwidth Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor bandwidth should exceed the important measurement dynamics with adequate margin.

But:

\[ B\uparrow \]

generally allows more noise.

Thus:

\[ \boxed{ \text{Bandwidth} = \text{Dynamic Fidelity vs Noise Trade} } \]

4.1.11.50 Update Rate Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A sensor update rate must support the estimator and control dynamics.

\[ f_s=\frac{1}{T_s}. \]

High-rate gyros may operate much faster than star trackers or GNSS.

Multi-rate estimation is therefore common:

\[ \boxed{ \text{High-Rate Propagation} + \text{Lower-Rate Absolute Updates} } \]

4.1.11.51 Latency Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For rotational motion,

\[ \delta\theta \approx \omega\tau. \]

For translation,

\[ \delta r \approx v\tau. \]

Therefore a low-noise but highly delayed sensor may be worse than a somewhat noisier low-latency sensor during high-dynamic phases.

4.1.11.52 Timestamp Accuracy

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Known latency and timestamp uncertainty are different.

A known fixed delay can potentially be compensated.

An uncertain timestamp creates state uncertainty.

\[ \boxed{ \delta\theta\approx\omega\delta t } \] \[ \boxed{ \delta r\approx v\delta t } \]

Accurate hardware timestamps can therefore be critical.

4.1.11.53 Sensor Synchronization

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

When measurements from several sensors are fused,

\[ \boxed{ t_{\text{IMU}} \approx t_{\text{GNSS}} \approx t_{\text{camera}} \approx t_{\text{LiDAR}} } \]

should be known accurately.

Useful interfaces include:

PPS,
external trigger,
hardware timestamp,
synchronization clock.

Synchronization becomes increasingly important for fast RPO and precision navigation.

4.1.11.54 Field-of-View Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For optical sensors:

\[ \boxed{ FOV \rightarrow \text{Measurement Availability} } \]

A wide FOV improves acquisition and retention.

A narrow FOV can improve spatial/angular resolution for fixed detector size and optics.

Therefore:

\[ \boxed{ \text{FOV} \leftrightarrow \text{Resolution} } \]

is a major optical trade.

4.1.11.55 Exclusion Geometry

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For star trackers and other optical sensors, visibility analysis should include:

Sun,
Earth,
Moon,
bright planets,
spacecraft structures,
plume or reflection geometry where relevant.

The mission should verify that sufficient attitude-reference availability exists throughout required operational modes.

4.1.11.56 Environmental Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Spacecraft sensors must operate under:

\[ \boxed{ \text{Vacuum} + \text{Temperature} + \text{Radiation} + \text{Vibration} + \text{Shock} + \text{EMI/EMC} } \]

The environment is part of sensor performance.

4.1.11.57 Thermal Environment

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Check:

operating range,
storage range,
baseplate limits,
temperature coefficients,
warm-up,
thermal gradients,
thermal cycling,
required heater power.

High-precision inertial and optical sensors may require thermal stabilization.

4.1.11.58 Radiation Environment

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Consider:

\[ \boxed{ TID + SEE + \text{Displacement Damage} } \]

where applicable.

The required radiation tolerance depends on:

orbit,
duration,
shielding,
solar environment,
device technology.

4.1.11.59 TID Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor capability should satisfy

\[ TID_{\text{qualified}} > TID_{\text{predicted}} \]

with appropriate program margin.

But TID alone is not sufficient to establish radiation suitability.

4.1.11.60 Single-Event Effects

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Evaluate susceptibility to:

SEU,
SEL,
SEFI,
SET.

Ask whether the event causes:

one bad measurement,
data corruption,
sensor reset,
permanent damage.

This determines required FDIR.

4.1.11.61 Vibration Environment

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Launch vibration can affect:

structural integrity,
alignment,
calibration,
optical focus,
inertial sensor bias.

Qualification should be compared with predicted launch loads.

4.1.11.62 Shock Environment

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Separation mechanisms can produce high shock.

A sensor may survive shock but not provide valid measurements during it.

Therefore distinguish:

\[ \boxed{ \text{Survival} } \]

from

\[ \boxed{ \text{Operational Performance} } \]

during the event.

4.1.11.63 EMI/EMC

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor operation can be affected by:

power converters,
transmitters,
motors,
reaction wheels,
magnetorquers,
digital electronics.

The sensor itself can also generate emissions.

Magnetometers and precision analog sensors require particular attention.

4.1.11.64 Optical Contamination

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Star trackers, cameras, Sun sensors and LiDAR optics can be degraded by:

molecular deposition,
particulates,
thruster contamination,
handling contamination.

Optical sensor selection must therefore consider spacecraft contamination control.

4.1.11.65 Mechanical Accommodation

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Check:

dimensions,
mass,
mounting pattern,
alignment datum,
connector access,
harness routing,
thermal interface,
optical keep-out zones.

A theoretically ideal sensor is useless if it cannot be accommodated physically.

4.1.11.66 Sensor Alignment

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A sensor's measurement frame \(S\) must be related to spacecraft body frame \(B\):

\[ \boxed{ \mathbf z^B=C_S^B\mathbf z^S. } \]

The alignment error may include:

\[ \boxed{ \text{Internal Axis Error} + \text{Mounting Error} + \text{Thermoelastic Error} } \]

For precision missions, alignment knowledge can dominate intrinsic sensor accuracy.

4.1.11.67 Lever-Arm Effects

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

If a sensor is displaced from the spacecraft reference point, translational measurements can contain rotational terms.

For a rigid body,

\[ \mathbf a_s = \mathbf a_O + \dot{\boldsymbol{\omega}}\times\mathbf r + \boldsymbol{\omega}\times (\boldsymbol{\omega}\times\mathbf r). \]

Therefore IMU location relative to the center of mass/reference point can matter.

4.1.11.68 Optical Boresight Alignment

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For a camera or star tracker,

\[ \boxed{ C_S^B } \]

must be accurately known.

If payload pointing depends on the optical sensor, the complete alignment chain may be

\[ \boxed{ \text{Star Tracker} \rightarrow \text{Spacecraft Structure} \rightarrow \text{Payload} } \]

Structural deformation can therefore become part of the pointing error budget.

4.1.11.69 Electrical Interface Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Possible interfaces include:

SPI,
I²C,
UART,
RS-422,
CAN,
Ethernet,
SpaceWire,
MIL-STD-1553,
LVDS.

Selection must consider:

data rate,
deterministic timing,
harness length,
redundancy,
flight-computer compatibility.

4.1.11.70 Sensor Data Rate

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Approximate payload data rate:

\[ R \approx N_{\text{bytes/sample}}f_s. \]

Camera and LiDAR systems may produce orders of magnitude more data than simple vector sensors.

Processing architecture must therefore be considered during sensor selection.

4.1.11.71 Onboard Processing Requirement

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Some sensors output nearly final measurements.

Examples:

star tracker → quaternion,
GNSS → PVT.

Others can require substantial processing:

camera images,
LiDAR point clouds.

Therefore compare

\[ \boxed{ \text{Sensor SWaP} + \text{Required Processor SWaP} } \]

rather than sensor hardware alone.

4.1.11.72 Sensor Software and Firmware

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Intelligent sensors may depend strongly on onboard firmware.

Evaluate:

firmware maturity,
deterministic timing,
update mechanism,
fault recovery,
boot time,
configuration management,
algorithm version.

Software is part of the sensor system.

4.1.11.73 Mass Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Do not count only sensor dry mass.

System mass can include:

\[ \boxed{ m_{\text{system}} = m_{\text{sensor}} + m_{\text{mount}} + m_{\text{harness}} + m_{\text{electronics}} + m_{\text{thermal}} } \]

and redundant units.

4.1.11.74 Power Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Consider all operating modes:

\[ P_{\text{startup}}, P_{\text{acquisition}}, P_{\text{tracking}}, P_{\text{standby}}, P_{\text{peak}}. \]

A sensor's peak power or heater requirement may be more important than nominal power.

4.1.11.75 SWaP

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A common metric is

\[ \boxed{ SWaP= \text{Size}+\text{Weight}+\text{Power}. } \]

With cost:

\[ \boxed{ SWaP-C. } \]

Small spacecraft are often strongly constrained by SWaP.

4.1.11.76 Reliability

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor reliability must consider:

component reliability,
mission duration,
radiation,
thermal cycling,
connectors,
firmware,
mechanisms,
laser lifetime,
detector lifetime.

Reliability cannot be represented adequately by nominal measurement accuracy.

4.1.11.77 Redundancy

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A critical sensor may require:

\[ \boxed{ 1+1 } \]

or another redundant architecture.

Possible architectures include:

cold redundancy,
warm redundancy,
hot redundancy,
multiple dissimilar sensors.

4.1.11.78 Cold Redundancy

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A backup sensor remains powered off until required.

Advantages:

lower operating power,
reduced accumulated operating life.

Disadvantages:

startup delay,
latent failure may remain undetected.

4.1.11.79 Hot Redundancy

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Both units operate simultaneously.

Advantages:

immediate switchover,
continuous comparison.

Disadvantages:

higher power,
simultaneous environmental exposure,
common-mode failures may remain.

4.1.11.80 Dissimilar Redundancy

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Different sensing principles can reduce common-mode failure.

For example:

\[ \boxed{ \text{Star Tracker} + \text{Sun Sensor} + \text{Magnetometer} } \]

provides multiple attitude-reference technologies.

This can improve resilience compared with relying entirely on identical sensors.

4.1.11.81 Fault Detection Capability

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor selection should consider whether the device provides:

BIT/BITE,
health flags,
temperature,
signal quality,
saturation flag,
tracking status,
number of tracked objects,
covariance,
checksum.

A measurement with a meaningful quality indicator is often more useful than a measurement without one.

4.1.11.82 Integrity

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Integrity concerns whether incorrect measurements can be detected before they corrupt navigation.

A useful architecture is

\[ \boxed{ \text{Measurement} + \text{Quality Information} + \text{Innovation Monitoring} } \]

For critical autonomous operations, integrity can be as important as nominal accuracy.

4.1.11.83 Availability

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Approximate sensor availability:

\[ \boxed{ A=\frac{T_{\text{valid}}}{T_{\text{required}}}. } \]

Availability analysis should include:

geometric outages,
eclipse,
blinding,
acquisition time,
thermal restrictions,
scheduled calibration,
failures.

4.1.11.84 Continuity

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Continuity asks whether valid service will remain uninterrupted during a critical operation.

For docking, the relevant question is not merely whether the camera works 99% of the mission.

It is whether it remains valid during the entire final approach and docking interval.

4.1.11.85 Graceful Degradation

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A good sensor architecture should allow degraded operation.

For example:

\[ \text{Gyro + Star Tracker} \]

may degrade temporarily to

\[ \text{Gyro Propagation} \]

during tracker dropout.

A safe-mode architecture may fall back to

\[ \text{Sun Sensor + Magnetometer}. \]

This should be designed intentionally.

4.1.11.86 Sensor Failure Modes

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Possible failure modes include:

no output,
frozen output,
biased output,
excessive noise,
intermittent output,
corrupted packet,
timing error,
saturation,
thermal failure,
optical blinding,
loss of tracking.

A dangerous sensor is not always one that stops working.

A plausible but wrong measurement can be more hazardous.

4.1.11.87 FDIR

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor selection should support:

\[ \boxed{ \text{Fault Detection} \rightarrow \text{Isolation} \rightarrow \text{Recovery} } \]

Possible techniques include:

residual monitoring,
cross-sensor comparison,
range checks,
rate-of-change checks,
consistency tests,
redundant voting,
covariance monitoring.

4.1.11.88 Space Qualification

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Check evidence for:

thermal vacuum,
thermal cycling,
random vibration,
sine vibration,
shock,
EMC/EMI,
radiation,
life testing.

“Space capable” should not replace actual qualification evidence.

4.1.11.89 Flight Heritage

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Flight heritage can reduce risk, but ask:

Which mission?
Which orbit?
How long?
Same hardware revision?
Same firmware?
Same environment?
Same operating mode?

Therefore,

\[ \boxed{ \text{Heritage} \neq \text{Universal Qualification}. } \]

4.1.11.90 Technology Readiness

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Technology readiness should be considered alongside performance.

A sensor with extraordinary laboratory performance but low maturity can introduce:

schedule risk,
qualification risk,
integration risk,
reliability uncertainty.

Mission schedule may favor mature technology.

4.1.11.91 Procurement Risk

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Evaluate:

price,
lead time,
minimum order,
export restrictions,
country of origin,
long-term availability,
vendor support,
calibration services,
documentation availability.

A technically excellent sensor that cannot be delivered on schedule is not a viable design choice.

4.1.11.92 Documentation Quality

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Good sensor integration requires:

interface control document,
user manual,
mechanical drawing,
electrical specification,
protocol documentation,
calibration report,
qualification report,
radiation report.

Documentation quality itself can affect engineering risk.

4.1.11.93 Commercial vs Space-Grade Sensors

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Commercial sensors may offer:

lower cost,
shorter lead time,
rapid technology improvement.

But may lack:

radiation characterization,
vacuum qualification,
long-life data,
traceability.

Space-grade hardware can reduce some of these risks but may have greater:

cost,
lead time,
SWaP.

Selection should be risk-based.

4.1.11.94 CubeSat Sensor Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

CubeSats are often constrained by

\[ \boxed{ \text{Mass}+\text{Power}+\text{Volume}+\text{Cost} } \]

A representative low-cost ADCS suite might contain:

\[ \boxed{ \text{MEMS IMU} + \text{Magnetometer} + \text{Coarse Sun Sensors} } \]

For improved pointing:

\[ \boxed{ +\text{Star Tracker} } \]

GNSS may provide orbit knowledge in LEO.

4.1.11.95 LEO Spacecraft Sensor Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A LEO spacecraft can often exploit:

GNSS,
geomagnetic field,
Sun,
stars.

Therefore a representative architecture might include:

\[ \boxed{ \text{Gyro} + \text{Star Tracker} + \text{Magnetometer} + \text{Sun Sensor} + \text{GNSS} } \]

The exact combination depends on pointing and navigation requirements.

4.1.11.96 Earth-Observation Mission

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Earth-observation spacecraft can have demanding pointing and geolocation requirements.

Possible sensors include:

precision gyro,
star tracker,
GNSS,
Sun sensor for safe mode,
magnetometer for backup/coarse modes.

Critical considerations include:

attitude knowledge,
timestamp accuracy,
payload-to-star-tracker alignment,
jitter,
orbit knowledge.

4.1.11.97 Communications Satellite

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Important requirements may include:

antenna pointing,
station keeping,
momentum management,
safe-mode Sun acquisition.

Possible sensors:

star tracker,
gyro,
Sun sensor,
GNSS where applicable,
magnetometer depending on orbit/control architecture.

4.1.11.98 GEO Sensor Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

At GEO, navigation architecture differs from conventional LEO.

Consider:

GNSS signal geometry and receiver capability,
ground ranging,
star tracker,
Sun sensor,
gyro.

A receiver suitable for terrestrial or ordinary LEO use should not automatically be assumed suitable for GEO.

4.1.11.99 Deep-Space Missions

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Deep-space missions cannot rely on conventional near-Earth sensor assumptions.

Possible navigation references include:

stars,
Sun,
planetary bodies,
optical navigation,
radiometric ground tracking,
inertial sensing.

A representative attitude suite may use

\[ \boxed{ \text{Star Tracker} + \text{Gyro} + \text{Sun Sensor} } \]

with optical navigation for trajectory determination.

4.1.11.100 Planetary Orbiters

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Potential sensors include:

star tracker,
gyro,
Sun sensor,
optical navigation camera,
altimeter where applicable,
radiometric tracking.

Local planetary magnetic fields cannot always substitute for Earth's geomagnetic reference.

4.1.11.101 Planetary Landing

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Landing requires different navigation information:

altitude,
velocity,
terrain-relative position,
attitude,
hazard information.

Possible sensors include:

\[ \boxed{ \text{IMU} + \text{Camera} + \text{Radar/Laser Altimeter} + \text{LiDAR} } \]

depending on the mission.

4.1.11.102 Terrain-Relative Navigation

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

TRN uses images or terrain measurements to compare observed features against known terrain.

Sensor selection considers:

altitude,
ground sampling distance,
illumination,
terrain texture,
camera FOV,
image processing,
onboard map quality.

4.1.11.103 Formation Flying

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Formation flying requires accurate relative state.

Possible approaches include:

differential GNSS,
inter-satellite ranging,
optical relative navigation,
RF ranging.

Selection depends strongly on:

\[ \boxed{ \text{Baseline} + \text{Required Relative Accuracy} + \text{Orbit} } \]

4.1.11.104 Rendezvous and Proximity Operations

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

RPO commonly transitions between sensor regimes.

Conceptually:

\[ \boxed{ \text{Far Range} \rightarrow \text{Mid Range} \rightarrow \text{Close Range} \rightarrow \text{Docking} } \]

Each regime has different observability, FOV and accuracy requirements.

4.1.11.105 Far-Range RPO Sensors

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Possible sources include:

absolute GNSS,
differential GNSS,
RF ranging,
ground-derived relative orbit.

At long distance, target pixels may be insufficient for useful vision navigation.

4.1.11.106 Mid-Range RPO Sensors

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Possible architecture:

\[ \boxed{ \text{GNSS} + \text{Camera} } \]

or

\[ \boxed{ \text{Camera} + \text{Range Sensor} } \]

This provides transition between orbital relative navigation and direct target sensing.

4.1.11.107 Close-Range RPO Sensors

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

At close range, requirements can include:

\[ \mathbf r_{rel}, \quad \mathbf v_{rel}, \quad \mathbf q_{rel}, \quad \boldsymbol{\omega}_{rel}. \]

Possible sensors:

monocular/stereo camera,
LiDAR,
laser rangefinder,
docking markers,
fiducial-based vision.

4.1.11.108 Docking Sensor Requirements

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Docking sensors may need to satisfy

\[ \boxed{ \|\delta\mathbf r_{rel}\| \leq r_{\text{req}} } \] \[ \boxed{ \|\delta\mathbf v_{rel}\| \leq v_{\text{req}} } \] \[ \boxed{ \|\delta\boldsymbol{\theta}_{rel}\| \leq \theta_{\text{req}} } \] \[ \boxed{ \|\delta\boldsymbol{\omega}_{rel}\| \leq \omega_{\text{req}}. } \]

The selected suite must provide all required observables with sufficient availability.

4.1.11.109 Cooperative vs Non-Cooperative RPO

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Cooperative target

May provide:

GNSS,
communication,
fiducials,
reflectors,
docking markers.

Non-cooperative target

May require:

natural-feature tracking,
silhouette processing,
model-based vision,
LiDAR point-cloud registration.

Sensor selection is significantly harder for non-cooperative RPO.

4.1.11.110 Target Properties Matter

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Relative-navigation sensor performance depends on target:

size,
shape,
reflectivity,
surface texture,
symmetry,
thermal/optical characteristics,
tumbling rate.

Therefore RPO sensor selection must include the target model.

4.1.11.111 Safe-Mode Sensor Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Safe mode should use sensors that are:

robust,
low power,
easy to initialize,
tolerant of uncertain attitude.

A common concept is

\[ \boxed{ \text{Coarse Sun Sensor} + \text{Magnetometer} + \text{Gyro} } \]

rather than relying solely on a precision sensor with restrictive acquisition conditions.

4.1.11.112 Sensor Selection for Detumbling

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

After deployment, angular rate may be high.

Important requirements include:

gyro range,
magnetometer range,
update rate,
robustness.

A magnetometer may support B-dot control:

\[ \mathbf m_c=-k\dot{\mathbf B}. \]

Sensor saturation must be avoided during initial tumble.

4.1.11.113 Sensor Selection for Precision Pointing

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Precision pointing may require:

\[ \boxed{ \text{Low-Noise Gyro} + \text{High-Accuracy Star Tracker} } \]

plus:

accurate timing,
thermal stability,
structural alignment knowledge,
low jitter.

At high precision, system-level alignment may dominate the sensor's intrinsic accuracy.

4.1.11.114 Sensor Selection for High-Dynamic Missions

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Launch vehicles and high-dynamic spacecraft require emphasis on:

high dynamic range,
high bandwidth,
high update rate,
low latency,
shock/vibration tolerance.

The selection priority can therefore differ greatly from precision astronomical spacecraft.

4.1.11.115 Sensor Selection for Autonomous Missions

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Autonomy increases importance of:

self-initialization,
quality flags,
integrity monitoring,
fault detection,
reacquisition,
onboard calibration,
deterministic interfaces.

A sensor requiring frequent ground intervention may be unsuitable for a highly autonomous mission.

4.1.11.116 Sensor Selection and Kalman Filter Design

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor selection and estimator design should be developed together.

The estimator uses

\[ \mathbf z_k=h(\mathbf x_k)+\mathbf v_k. \]

The selected sensor determines:

\(h(\cdot)\),
\(R\),
update rate,
availability,
observability.

Therefore,

\[ \boxed{ \text{Sensor Architecture} \leftrightarrow \text{Estimator Architecture} } \]

4.1.11.117 Sensor Selection and Process Noise

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A lower-quality sensor may require more states to be estimated.

For example:

\[ \mathbf x = [ \delta\boldsymbol{\theta}, \mathbf b_g, \mathbf s_g, \ldots ]^T \]

may include bias and scale-factor states.

Therefore sensor imperfections can increase estimator complexity.

4.1.11.118 Sensor Selection and Calibration

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Determine whether errors are:

factory calibrated,
spacecraft calibrated,
estimated online,
assumed fixed.

Possible calibration parameters include:

\[ \boxed{ \mathbf b,\quad \mathbf S,\quad \mathbf M,\quad C_S^B } \]

for bias, scale factor, non-orthogonality/misalignment, and installation alignment.

4.1.11.119 Calibration Observability

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

An error should not simply be added to the filter state because it exists.

Ask whether mission measurements make that parameter observable.

For example, some alignment or scale-factor terms may be weakly observable under limited spacecraft motion.

4.1.11.120 Sensor Selection and Control

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensors influence achievable closed-loop control.

Conceptually:

\[ \boxed{ \text{Sensor Noise} \rightarrow \text{Estimated-State Noise} \rightarrow \text{Control Command Noise} } \]

and

\[ \boxed{ \text{Sensor Latency} \rightarrow \text{Phase Delay} \rightarrow \text{Reduced Stability Margin} } \]

Therefore control performance must be considered during selection.

4.1.11.121 Sensor-Control Bandwidth Compatibility

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A control loop should not demand state information faster than the sensor/estimator architecture can reliably provide.

The complete chain is

\[ \boxed{ \text{Physical Motion} \rightarrow \text{Sensor} \rightarrow \text{Estimator} \rightarrow \text{Controller} \rightarrow \text{Actuator}. } \]

Every stage contributes bandwidth and delay.

4.1.11.122 Sensor Selection and Monte Carlo Analysis

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Candidate sensor suites should be tested in simulation with uncertainties including:

bias,
noise,
scale factor,
misalignment,
latency,
dropout,
environmental effects,
calibration residuals.

For run \(j\),

\[ p^{(j)}\sim\mathcal D_p. \]

The question is not merely whether the nominal case works.

It is:

\[ \boxed{ P(\text{Mission Success}) } \]

under realistic uncertainty.

4.1.11.123 Monte Carlo Sensor Comparison

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For each candidate architecture compare:

estimation RMS,
peak error,
convergence time,
requirement violations,
sensor availability,
recovery time,
mission success rate.

A sensor with slightly poorer nominal accuracy may outperform another if it has better availability or more benign failure behavior.

4.1.11.124 Hardware-in-the-Loop Verification

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor selection should eventually progress beyond numerical simulation.

Possible verification sequence:

\[ \boxed{ \text{Model} \rightarrow \text{SIL} \rightarrow \text{HIL} \rightarrow \text{Environmental Test} \rightarrow \text{Flight} } \]

HIL can reveal:

real latency,
packet timing,
communication failures,
quantization,
startup behavior,
processor loading.

4.1.11.125 Sensor Requirement Matrix

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A useful sensor requirement matrix contains:

Category	Requirement
Measurement	Quantity/state observed
Accuracy	Required measurement accuracy
Precision	Repeatability
Range	Required min/max
Noise	Density/RMS
Bias	Initial/stability
Update	Minimum rate
Latency	Maximum allowable
Timing	Timestamp/synchronization
FOV	Required coverage
Environment	Thermal/radiation/vibration
Interface	Electrical/data
SWaP	Mass/power/volume
Reliability	Mission requirement
Qualification	Required evidence
Heritage	Desired/required
Procurement	Cost/lead time

4.1.11.126 Hard Constraints

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Some requirements should be treated as pass/fail.

Examples:

\[ \boxed{ TID_{\text{sensor}} \geq TID_{\text{required}} } \] \[ \boxed{ \omega_{\max,\text{sensor}} \geq \omega_{\max,\text{mission}} } \] \[ \boxed{ f_s\geq f_{\text{required}} } \] \[ \boxed{ P\leq P_{\text{available}} } \]

A sensor failing a hard constraint should normally be eliminated before weighted scoring.

4.1.11.127 Soft Trade Criteria

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

After hard constraints are satisfied, compare:

accuracy,
mass,
power,
volume,
cost,
lead time,
heritage,
ease of integration,
vendor support.

These are trade criteria rather than absolute pass/fail requirements.

4.1.11.128 Normalization of Candidate Sensors

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For criterion \(x_i\), candidate values should be normalized before combining different units.

For a “smaller is better” quantity, one possible normalization is

\[ s_i = \frac{x_{\max}-x_i} {x_{\max}-x_{\min}}. \]

For “larger is better”:

\[ s_i = \frac{x_i-x_{\min}} {x_{\max}-x_{\min}}. \]

The exact scoring method should be documented.

4.1.11.129 Weighted Decision Matrix

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A simple trade score can be

\[ \boxed{ J_j=\sum_{i=1}^{N}w_i s_{ij} } \]

where

\(w_i\): criterion weight,
\(s_{ij}\): normalized score of sensor \(j\).

Usually,

\[ \sum_i w_i=1. \]

But weighted scoring should never hide a hard requirement failure.

4.1.11.130 Example Sensor Trade Criteria

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Possible categories:

Criterion	Example Weighting Importance
Accuracy	Mission dependent
Bias/Stability	High for inertial navigation
Range	Hard constraint
Update Rate	GNC dependent
Latency	High for fast dynamics
Availability	High for critical phases
Radiation	Hard constraint
Power	High for small spacecraft
Mass	High for small spacecraft
Heritage	Risk reduction
Cost	Program dependent
Lead Time	Schedule dependent

There is no universal set of weights.

4.1.11.131 Sensitivity of the Trade Study

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A sensor should not be selected solely because it wins one arbitrary weighting scheme.

Vary the weights:

\[ w_i\rightarrow w_i+\delta w_i. \]

If the winner changes dramatically with small weighting changes, the decision is not robust.

This is an important but often overlooked part of sensor trades.

4.1.11.132 Uncertainty in Datasheet Values

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Candidate values themselves may be uncertain.

For example:

“typical” performance,
incomplete radiation data,
estimated lead time,
unverified heritage.

The trade study should distinguish:

\[ \boxed{ \text{Measured / Guaranteed} } \]

from

\[ \boxed{ \text{Typical / Estimated / Unknown}. } \]

Unknown information represents risk.

4.1.11.133 Risk-Adjusted Sensor Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

The sensor with the highest theoretical performance may not provide the lowest mission risk.

Risk can be considered conceptually as

\[ \boxed{ R_i=P_iC_i } \]

where

\(P_i\): probability of undesirable event,
\(C_i\): consequence.

Examples:

procurement delay,
radiation failure,
integration failure,
calibration uncertainty.

4.1.11.134 Performance Margin vs Risk Margin

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Two sensors may both satisfy accuracy.

Sensor A:

much better accuracy,
low heritage.

Sensor B:

adequate accuracy,
extensive relevant heritage.

Depending on mission risk posture, Sensor B may be preferable.

Selection should therefore consider both:

\[ \boxed{ \text{Performance Margin} + \text{Program Risk} } \]

4.1.11.135 Requirement Traceability

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Every sensor requirement should trace to a higher-level requirement.

\[ \boxed{ \text{Mission} \rightarrow \text{System} \rightarrow \text{GNC} \rightarrow \text{Navigation} \rightarrow \text{Sensor} } \]

This is essential for design reviews and verification.

4.1.11.136 Sensor Verification Matrix

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For every requirement record:

requirement,
sensor,
datasheet evidence,
analysis,
test,
margin,
status.

Example:

Requirement	Verification
Mass	Inspection
Noise	Test
FOV	Analysis/Test
Radiation	Qualification report
Navigation accuracy	Monte Carlo
Latency	Interface/HIL test
Alignment	Calibration

4.1.11.137 Vendor Evaluation

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A vendor should be assessed on more than product performance.

Consider:

technical support,
responsiveness,
documentation,
calibration support,
configuration control,
quality system,
delivery history,
export constraints,
obsolescence management.

4.1.11.138 Questions to Ask the Vendor

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Important questions include:

Is the accuracy typical, maximum, RMS, \(1\sigma\), or \(3\sigma\)?
At what temperature was it measured?
At what bandwidth?
At what output rate?
What is the measurement latency?
Is latency deterministic?
How are timestamps generated?
What is the sensor coordinate frame?
What calibration is applied?
What is the residual calibration uncertainty?
Are raw measurements available?
Are covariance/quality outputs available?
What radiation testing exists?
What vibration and shock testing exists?
What TVAC testing exists?
What flight heritage exists?
Which firmware version was qualified?
What is the unit-to-unit variation?
What is the expected lifetime?
What are lead time and export restrictions?

4.1.11.139 Sensor Selection Review Gates

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor selection should mature progressively.

Concept Design

Identify sensing principles.

Preliminary Design

Shortlist candidate sensors.

Critical Design

Select hardware and freeze interfaces.

Qualification

Verify environment and performance.

Acceptance

Verify individual flight units.

This prevents premature commitment.

4.1.11.140 Technology Demonstration vs Operational Sensor

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

An experimental mission may tolerate:

lower heritage,
greater uncertainty,
manual recovery.

An operational or safety-critical mission may prioritize:

proven reliability,
redundancy,
deterministic behavior,
qualification evidence.

The “best” sensor therefore depends on mission risk tolerance.

4.1.11.141 Sensor Architecture for a Typical Small LEO Spacecraft

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A representative architecture might be:

\[ \boxed{ \text{GNSS} } \]

for orbit determination,

\[ \boxed{ \text{Gyro + Star Tracker} } \]

for precision attitude,

and

\[ \boxed{ \text{Sun Sensor + Magnetometer} } \]

for coarse/safe attitude.

This provides complementary sensing and graceful degradation.

4.1.11.142 Sensor Architecture for Precision RPO

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A representative architecture could be:

Absolute navigation

\[ \boxed{ \text{GNSS} } \]

Far-range relative navigation

\[ \boxed{ \text{Differential GNSS} } \]

where appropriate.

Mid-range

\[ \boxed{ \text{Camera} } \]

possibly combined with GNSS/ranging.

Close-range

\[ \boxed{ \text{Camera + LiDAR} } \]

Chaser attitude

\[ \boxed{ \text{Gyro + Star Tracker} } \]

This provides sensor transitions across the approach corridor.

4.1.11.143 RPO Sensor Transition Logic

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Sensor switching should not occur at a single fragile range threshold.

A better architecture uses overlapping validity regions:

\[ \boxed{ \text{Sensor A} \rightarrow \text{A+B Fusion} \rightarrow \text{Sensor B} } \]

This enables cross-validation before one sensor becomes primary.

4.1.11.144 Sensor Handover

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

During handover, check:

both sensors valid,
state estimates consistent,
covariance acceptable,
innovation acceptable,
required dwell satisfied.

Conceptually,

\[ \boxed{ \text{Handover} = \text{Validity} \land \text{Consistency} \land \text{Accuracy} \land \text{Dwell} } \]

This is especially important for autonomous RPO.

4.1.11.145 Sensor Selection for Final Docking

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Near docking, sensor selection should prioritize:

close minimum range,
relative pose accuracy,
low latency,
high update rate,
target visibility,
robust tracking,
fault detection.

The sensor must remain usable even when the target occupies a large fraction of its FOV.

This is often overlooked when selecting a sensor based primarily on maximum range.

4.1.11.146 Minimum Range

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For close-proximity sensors,

\[ \boxed{ \rho_{\min} } \]

can be as important as maximum range.

A LiDAR capable of detecting a target at hundreds of meters may still become invalid inside a minimum operating range.

The docking architecture must avoid this measurement gap.

4.1.11.147 Sensor Overlap

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Suppose:

\[ \text{GNSS valid: }1000\,m\rightarrow10\,m \]

and

\[ \text{Vision valid: }100\,m\rightarrow0.2\,m. \]

Then

\[ 100\,m\rightarrow10\,m \]

provides an overlap region.

This region can be used for:

cross-validation,
estimator transition,
calibration,
fault detection.

The numbers here are illustrative; actual validity limits are mission- and hardware-dependent.

4.1.11.148 Sensor Selection and Abort Capability

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

RPO sensor architecture must also support abort.

During an abort maneuver, the target may leave camera or LiDAR FOV.

The spacecraft still needs:

attitude knowledge,
inertial propagation,
absolute orbit knowledge.

Therefore close-range navigation sensors cannot be the only navigation capability.

4.1.11.149 Sensor Selection and Collision Avoidance

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Collision avoidance requires reliable knowledge of relative state.

Sensor selection should therefore support:

\[ \boxed{ \mathbf r_{rel}, \quad \mathbf v_{rel}, \quad P_{rel} } \]

where \(P_{rel}\) represents relative-state uncertainty.

A state estimate without credible uncertainty can be insufficient for autonomous safety decisions.

4.1.11.150 Sensor Selection and Robotics Handover

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For capture or robotic handover, the navigation system may need to certify conditions such as

\[ \|\mathbf r_{rel}\|\le r_{capture} \] \[ \|\mathbf v_{rel}\|\le v_{capture} \] \[ \|\boldsymbol{\theta}_{rel}\|\le\theta_{capture} \] \[ \|\boldsymbol{\omega}_{rel}\|\le\omega_{capture}. \]

The sensor suite must provide the observability and precision required to determine these quantities reliably.

4.1.11.151 Sensor Selection for Formation Flying

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

For loose formations:

\[ \boxed{ \text{GNSS} } \]

may be sufficient in suitable Earth orbits.

For precise formation:

\[ \boxed{ \text{Differential GNSS} + \text{Inter-Satellite Ranging} } \]

may be considered.

For extremely precise relative navigation, carrier-phase techniques can become important.

4.1.11.152 Sensor Selection for Non-Earth Missions

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Outside Earth orbit:

GNSS availability changes,
geomagnetic navigation may disappear,
planetary illumination changes,
thermal/radiation environments change.

Therefore Earth-orbit sensor architectures cannot simply be copied to lunar, Martian, or deep-space missions.

4.1.11.153 Lunar Mission Sensor Suite

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Possible elements include:

star tracker,
IMU,
Sun sensor,
optical navigation camera,
laser/radar altimeter for landing,
terrain-relative navigation sensors.

Architecture depends strongly on orbital versus surface mission phases.

4.1.11.154 Sensor Selection for High-Precision Scientific Missions

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Scientific missions may prioritize:

extremely low inertial noise,
thermal stability,
structural stability,
timing,
calibration,
long-term drift.

At these levels,

\[ \boxed{ \text{System Calibration} } \]

can become as important as nominal sensor resolution.

4.1.11.155 Sensor Selection for Drag-Free Missions

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Drag-free spacecraft may require very high-performance accelerometry.

The relevant acceleration levels can be extremely small.

Selection therefore emphasizes:

acceleration noise,
bias,
low-frequency stability,
thermal stability,
electrostatic/other precision sensor architecture.

A conventional navigation accelerometer may be inadequate.

4.1.11.156 Sensor Selection for Fast Slew Missions

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

High-agility spacecraft require:

gyro range,
gyro bandwidth,
high update rate,
star-tracker slew capability,
rapid reacquisition,
low latency.

A tracker with excellent static accuracy may be unsuitable if it repeatedly loses tracking during commanded slews.

4.1.11.157 Static Accuracy vs Mission Accuracy

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A central selection principle is:

\[ \boxed{ \text{Datasheet Static Accuracy} \neq \text{Mission Navigation Accuracy} } \]

Mission accuracy includes:

\[ \boxed{ \text{Sensor} + \text{Alignment} + \text{Timing} + \text{Environment} + \text{Geometry} + \text{Estimator} + \text{Dynamics} } \]

4.1.11.158 Sensor Selection Should Use End-to-End Simulation

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Candidate sensors should be inserted into the actual GNC simulation.

The flow is

\[ \boxed{ \text{Truth Dynamics} \rightarrow \text{Sensor Models} \rightarrow \text{Estimator} \rightarrow \text{Controller} \rightarrow \text{Actuators} \rightarrow \text{Mission Performance} } \]

This determines whether the system meets requirements.

4.1.11.159 Sensor Model Fidelity During Selection

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Early trade:

\[ \boxed{ z=z_{\text{true}}+n } \]

Later trade:

\[ \boxed{ z_k = h(\mathbf x_{k-\tau}) + b_k + Sx + M x + n_k } \]

plus:

saturation,
quantization,
dropout,
FOV,
environmental effects.

Model fidelity should increase as the design matures.

4.1.11.160 Requirement-Driven Selection Algorithm

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A systematic selection algorithm is:

Step 1 — Define mission phases

\[ \boxed{ \mathcal M=\{M_1,M_2,\ldots,M_N\} } \]

Step 2 — Define required states

\[ \boxed{ \mathbf x_{\text{required}} } \]

Step 3 — Define measurement requirements

Accuracy, range, rate, latency, availability.

Step 4 — Identify candidate sensing principles

Gyro, GNSS, camera, LiDAR, etc.

Step 5 — Identify actual candidate hardware

Step 6 — Eliminate hard-constraint failures

Step 7 — Normalize remaining specifications

Step 8 — Build sensor suites

Step 9 — Perform observability analysis

Step 10 — Run end-to-end simulation

Step 11 — Perform Monte Carlo analysis

Step 12 — Evaluate FDIR and degraded modes

Step 13 — Perform SWaP/cost/schedule trade

Step 14 — Verify environmental compatibility

Step 15 — Select architecture with margin

4.1.11.161 Sensor Selection Decision Tree

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Conceptually:

\[ \boxed{\text{What State Must Be Known?}} \] \[ \downarrow \] \[ \boxed{\text{Absolute or Relative?}} \] \[ \downarrow \] \[ \boxed{\text{Required Accuracy / Range / Rate?}} \] \[ \downarrow \] \[ \boxed{\text{What References Are Available?}} \] \[ \downarrow \] \[ \boxed{\text{Which Sensing Principles Can Observe It?}} \] \[ \downarrow \] \[ \boxed{\text{Which Devices Meet Hard Constraints?}} \] \[ \downarrow \] \[ \boxed{\text{Which Sensor Combination Is Robust?}} \] \[ \downarrow \] \[ \boxed{\text{Verify Through Simulation and Test}} \]

4.1.11.162 Complete Sensor Trade Matrix

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A comprehensive trade matrix should include at least:

Measurement Performance

accuracy,
precision,
resolution,
noise,
bias,
stability,
scale factor,
alignment.

Dynamic Performance

range,
bandwidth,
update rate,
latency,
slew capability.

Geometry

FOV,
minimum/maximum range,
exclusion angles,
antenna visibility.

Environment

temperature,
radiation,
vibration,
shock,
vacuum,
EMI/EMC.

Integration

mass,
power,
volume,
interface,
timing,
mounting,
thermal interface.

Reliability

lifetime,
redundancy,
BIT,
fault behavior.

Qualification

TVAC,
vibration,
shock,
radiation,
EMC.

Programmatic

cost,
lead time,
export restrictions,
heritage,
vendor support.

4.1.11.163 Sensor Selection Is an Architecture Optimization

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

The true design variable is not merely

\[ \boxed{ \text{Which Sensor?} } \]

It is

\[ \boxed{ \text{Which Combination of Sensors, Placement, Modes, Estimator, Calibration and Redundancy?} } \]

Thus sensor selection is an architecture problem.

4.1.11.164 Complementary Sensors

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Good sensor suites often combine different strengths.

Examples:

\[ \boxed{ \text{Gyro + Star Tracker} } \]

High-rate + absolute attitude.

\[ \boxed{ \text{Sun Sensor + Magnetometer} } \]

Two coarse celestial/environmental reference vectors.

\[ \boxed{ \text{GNSS + IMU} } \]

Absolute navigation + high-rate inertial propagation.

\[ \boxed{ \text{Camera + LiDAR} } \]

Bearing/features + range/3-D geometry.

4.1.11.165 Avoid Common-Mode Failures

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Redundant sensors are not fully independent if they share:

common power,
common processor,
common clock,
same FOV,
same thermal environment,
same software,
same sensing principle.

Therefore redundancy architecture should identify common-mode failures.

4.1.11.166 Primary, Secondary and Safe-Mode Sensors

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A useful classification is:

Primary

Provides nominal mission performance.

Secondary

Provides redundancy or complementary measurements.

Safe Mode

Provides robust minimum knowledge required for spacecraft survival.

For example:

\[ \boxed{ \text{Primary: Star Tracker} } \] \[ \boxed{ \text{Secondary: Gyro} } \] \[ \boxed{ \text{Safe Mode: Sun Sensor + Magnetometer} } \]

The exact roles depend on architecture.

4.1.11.167 Selection Should Consider Calibration Cost

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

A cheaper sensor can require:

extensive thermal calibration,
individual unit calibration,
frequent in-orbit calibration,
complex estimator augmentation.

Therefore total engineering cost may exceed hardware savings.

The appropriate comparison is:

\[ \boxed{ \text{Lifecycle Cost} } \]

rather than purchase price alone.

4.1.11.168 Selection Should Consider Processing Cost

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Similarly,

\[ \boxed{ \text{Low-Cost Camera} } \]

may require a powerful processor and complex software.

A more intelligent sensor may cost more but reduce onboard processing burden.

The system trade should include both.

4.1.11.169 Selection Should Consider Verification Cost

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Novel sensors may require additional:

test equipment,
simulators,
optical benches,
target simulators,
RF simulators,
HIL infrastructure.

Verification cost and schedule should therefore enter the architecture trade.

4.1.11.170 Final Sensor Selection Checklist

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

Before selecting a spacecraft sensor, confirm:

Measurement

What does it measure?
Does that measurement make the required state observable?

Performance

Is accuracy sufficient?
Is noise acceptable?
Is bias acceptable?
Is range sufficient?
Is update rate sufficient?
Is latency acceptable?

Geometry

Is FOV adequate?
Are exclusion zones acceptable?
Is minimum/maximum range suitable?

Environment

Temperature?
Radiation?
Vibration?
Shock?
Vacuum?
EMI/EMC?

Integration

Mass?
Power?
Volume?
Interface?
Timestamp?
Mounting?
Alignment?

Reliability

Availability?
Continuity?
Integrity?
Redundancy?
FDIR?

Qualification

TVAC?
vibration?
shock?
radiation?
heritage?

Program

Cost?
Lead time?
Export restrictions?
Vendor support?
Documentation?

GNC

Measurement model available?
\(R\) defined?
\(Q\) implications understood?
Calibration model defined?
Monte Carlo distributions defined?
Failure/dropout model defined?

4.1.11.171 Complete Spacecraft Sensor Selection Flow

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

The complete engineering workflow is

\[ \boxed{\text{Mission Objectives}} \] \[ \downarrow \] \[ \boxed{\text{Mission Phases and Modes}} \] \[ \downarrow \] \[ \boxed{\text{Required GNC States}} \] \[ \downarrow \] \[ \boxed{\text{State-Knowledge Requirements}} \] \[ \downarrow \] \[ \boxed{\text{Required Measurements}} \] \[ \downarrow \] \[ \boxed{\text{Observability Analysis}} \] \[ \downarrow \] \[ \boxed{\text{Candidate Sensing Technologies}} \] \[ \downarrow \] \[ \boxed{\text{Candidate Hardware}} \] \[ \downarrow \] \[ \boxed{\text{Hard-Constraint Screening}} \] \[ \downarrow \] \[ \boxed{\text{Sensor Suite Architecture}} \] \[ \downarrow \] \[ \boxed{\text{Error Budget + Measurement Models}} \] \[ \downarrow \] \[ \boxed{\text{Estimator / Sensor Fusion}} \] \[ \downarrow \] \[ \boxed{\text{End-to-End GNC Simulation}} \] \[ \downarrow \] \[ \boxed{\text{Monte Carlo + Failure Cases}} \] \[ \downarrow \] \[ \boxed{\text{SWaP + Environment + Qualification + Risk}} \] \[ \downarrow \] \[ \boxed{\text{Hardware / HIL Verification}} \] \[ \downarrow \] \[ \boxed{\text{Final Sensor Selection With Margin}} \]

4.1.11.172 Relationship with the Previous Sensor Chapters

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

The previous sections now connect naturally.

4.1.1–4.1.6

Explain the individual sensors:

\[ \boxed{ \text{Gyro, Accelerometer, Magnetometer, Star Tracker, Sun Sensor, GNSS} } \]

4.1.7 Sensor Error Sources

Explains:

\[ \boxed{ \text{How Measurements Become Imperfect} } \]

4.1.8 Combined Sensor Suites

Explains:

\[ \boxed{ \text{How Complementary Sensors Work Together} } \]

4.1.9 Measurement Models

Explains:

\[ \boxed{ \mathbf z=h(\mathbf x)+\mathbf v } \]

and how measurements enter KF/EKF/UKF architectures.

4.1.10 Sensor Specifications

Explains:

\[ \boxed{ \text{How Datasheet Numbers Become Engineering Parameters} } \]

4.1.11 Sensor Selection

Finally answers:

\[ \boxed{ \text{Which Sensors Should This Mission Actually Use?} } \]

4.1.11.173 Final Engineering Perspective

Sensor selection is the final system-level step of the sensor-model chapter. The preceding sections explain individual sensor physics, error sources, combined sensor suites, measurement equations, and datasheet interpretation. This page brings those topics together into a disciplined method for deciding which sensing architecture a particular spacecraft mission should actually fly.

The correct selection is rarely the device with the smallest quoted error. Instead, the architecture must provide the required state knowledge over every mission phase, remain observable under real geometry, preserve continuity through sensor outages and handovers, satisfy spacecraft environmental and SWaP constraints, support FDIR and degraded modes, and remain verifiable within program cost and schedule.

For that reason, this chapter treats the decision as an architecture optimization: mission → state requirements → sensing principles → candidate hardware → sensor suite → estimator → end-to-end verification.

The central principle of spacecraft sensor selection is:

\[ \boxed{ \text{Do Not Select the Sensor. Select the Navigation Architecture.} } \]

A spacecraft does not succeed because it contains the most accurate star tracker, the lowest-noise IMU, or the most expensive LiDAR.

It succeeds because the complete sensor architecture provides the required states:

\[ \boxed{ \mathbf r,\; \mathbf v,\; \mathbf q,\; \boldsymbol{\omega},\; \mathbf r_{rel},\; \mathbf v_{rel},\; \mathbf q_{rel} } \]

with sufficient

\[ \boxed{ \text{Accuracy} + \text{Observability} + \text{Update Rate} + \text{Low Latency} + \text{Availability} + \text{Integrity} } \]

while satisfying

\[ \boxed{ \text{SWaP} + \text{Environment} + \text{Qualification} + \text{Reliability} + \text{Cost} + \text{Schedule}. } \]

The final selection must therefore be demonstrated through the entire GNC chain:

\[ \boxed{ \text{Mission Requirement} \rightarrow \text{Sensor Requirement} \rightarrow \text{Sensor Suite} \rightarrow \text{Measurement Model} \rightarrow \text{Estimator} \rightarrow \text{Controller} \rightarrow \text{Monte Carlo} \rightarrow \text{HIL/Test} \rightarrow \text{Mission Compliance} } \]

That makes 4.1.11 Sensor Selection for Space Missions the final system-level section of 4.1 Sensor Models: it takes everything developed in the individual sensor, error, fusion, measurement-model, and specification chapters and turns it into a defensible spacecraft sensor architecture.