4.1.8 Combined Sensor Suites
This chapter brings the individual sensor models together into one spacecraft-level navigation architecture. The purpose is not merely to list compatible sensors, but to explain how different sensing principles contribute complementary information to the same estimated spacecraft state, how those measurements are aligned in time and frame, how their uncertainty is represented, and how the suite continues operating when one sensor becomes unavailable or unreliable.
In practice, a combined sensor suite is a complete system consisting of sensors, calibration models, frame transformations, clocks and timestamps, data interfaces, quality flags, health monitoring, navigation filters, sensor-selection logic, and mission-mode management. The quality of the final navigation solution therefore depends on the interaction of all these elements rather than on the advertised accuracy of any single sensor.
A spacecraft rarely depends on a single sensor for complete navigation or attitude knowledge. Individual sensors measure different physical quantities, operate at different update rates, possess different error characteristics, and fail under different environmental or geometric conditions. A combined sensor suite deliberately brings several complementary sensors together so that the weaknesses of one sensor are compensated by the strengths of another.
The central idea is
\[ \boxed{ \text{Multiple Complementary Sensors} \rightarrow \text{Time / Frame Alignment} \rightarrow \text{Measurement Validation} \rightarrow \text{Sensor Fusion} \rightarrow \text{Best Estimate of Spacecraft State} } \]A spacecraft navigation state may contain
\[ \boxed{ \mathbf x= \begin{bmatrix} \mathbf r\\ \mathbf v\\ \mathbf q\\ \boldsymbol\omega\\ \mathbf b_a\\ \mathbf b_g\\ b_c\\ \dot b_c\\ \cdots \end{bmatrix} } \]where the required states depend on the mission and estimator architecture.
Different sensors observe different portions of this state.
For example,
\[ \text{Gyroscope}\rightarrow\boldsymbol\omega \] \[ \text{Accelerometer}\rightarrow\mathbf f \] \[ \text{Magnetometer}\rightarrow\mathbf B^B \] \[ \text{Sun Sensor}\rightarrow\mathbf s^B \] \[ \text{Star Tracker}\rightarrow\mathbf q \] \[ \text{GNSS}\rightarrow\mathbf r,\mathbf v,t \]while RPO sensors may provide
\[ \text{LiDAR}\rightarrow\rho,\dot\rho,\text{relative geometry} \]and
\[ \text{Camera}\rightarrow\text{bearing / relative pose information}. \]The purpose of sensor fusion is therefore not simply to average several measurements. It is to exploit the different physical information, bandwidth, accuracy, observability, and failure modes of the available sensors.
4.1.8.1 Why Spacecraft Use Combined Sensor Suites
No practical spacecraft sensor is ideal.
A gyroscope offers excellent high-rate rotational information but develops drift.
A star tracker provides highly accurate absolute attitude but operates at a lower update rate and may become unavailable because of blinding or high slew.
A magnetometer is simple and robust but is affected by spacecraft magnetic fields and provides only one reference vector.
A Sun sensor is excellent for acquisition and safe mode but is unavailable during eclipse.
GNSS provides absolute position, velocity, and timing but depends on satellite visibility and RF conditions.
Therefore,
\[ \boxed{ \text{High Rate} + \text{Absolute Reference} + \text{Environmental Diversity} + \text{Redundancy} \rightarrow \text{Robust Navigation} } \]is one of the fundamental principles of spacecraft sensor-suite design.
4.1.8.2 Complementary Sensor Characteristics
The most useful sensor combinations usually contain sensors with complementary properties.
A common pattern is
\[ \boxed{ \text{Fast Relative Sensor} + \text{Slower Absolute Sensor} } \]For example,
\[ \boxed{ \text{Gyroscope} + \text{Star Tracker} } \]or
\[ \boxed{ \text{IMU} + \text{GNSS}. } \]The high-rate sensor propagates the navigation state between absolute measurements, while the absolute sensor periodically corrects drift.
This gives the general architecture
\[ \boxed{ \text{Propagation Sensor} \rightarrow \text{State Prediction} } \]combined with
\[ \boxed{ \text{Absolute Sensor} \rightarrow \text{State Correction}. } \]4.1.8.3 Sensor Fusion Is Not Sensor Averaging
Suppose two sensors measure different physical quantities:
\[ \boldsymbol\omega_m \]and
\[ \mathbf s_m. \]These cannot simply be averaged.
Instead, the spacecraft dynamics and measurement models connect them to a common state.
For example,
\[ \boldsymbol\omega_m = \boldsymbol\omega + \mathbf b_g + \mathbf n_g \]while
\[ \mathbf s_m^B = C_I^B(\mathbf q)\mathbf s^I + \mathbf n_s. \]Both contain information about spacecraft attitude, but through fundamentally different measurement equations.
Thus sensor fusion uses
\[ \boxed{ \mathbf x_{k+1}=f(\mathbf x_k,\mathbf u_k)+\mathbf w_k } \]and
\[ \boxed{ \mathbf z_k=h(\mathbf x_k)+\mathbf v_k } \]rather than simple arithmetic averaging.
4.1.8.4 Propagation Sensors and Correction Sensors
A useful division is between propagation sensors and absolute-reference sensors.
Propagation sensors include:
\[ \boxed{ \text{Gyroscope} } \]and, for translational navigation,
\[ \boxed{ \text{Accelerometer}. } \]They provide high-rate measurements that support continuous state propagation.
Absolute-reference sensors include:
\[ \boxed{ \text{Star Tracker} } \] \[ \boxed{ \text{Sun Sensor} } \] \[ \boxed{ \text{Magnetometer} } \] \[ \boxed{ \text{GNSS}. } \]These measurements prevent long-term divergence.
4.1.8.5 Typical Spacecraft Sensor Suite
A representative spacecraft may carry
\[ \boxed{ \text{Gyroscopes} + \text{Accelerometers} + \text{Magnetometers} + \text{Sun Sensors} + \text{Star Trackers} + \text{GNSS} } \]with mission-specific additions such as
\[ \boxed{ \text{Camera} + \text{LiDAR} + \text{Laser Rangefinder} + \text{Radar} } \]for proximity operations.
The complete suite does not necessarily operate continuously. Different sensors may be activated depending on spacecraft mode.
4.1.8.6 Hierarchical Sensor Architecture
A spacecraft often uses sensors in a hierarchy.
Conceptually,
\[ \boxed{ \text{Survival Sensors} \rightarrow \text{Coarse Navigation Sensors} \rightarrow \text{Fine Navigation Sensors} \rightarrow \text{Mission-Specific Relative Sensors} } \]For attitude determination:
\[ \boxed{ \text{Coarse Sun Sensor} \rightarrow \text{Sun + Magnetometer} \rightarrow \text{Gyro + Star Tracker} } \]For RPO:
\[ \boxed{ \text{GNSS} \rightarrow \text{Differential GNSS} \rightarrow \text{Camera / LiDAR} \rightarrow \text{Precision Relative Pose Sensor} } \]This permits both robustness and high accuracy.
4.1.8.7 IMU as a Combined Sensor Suite
An Inertial Measurement Unit usually combines
\[ \boxed{ 3\text{-axis Gyroscope} + 3\text{-axis Accelerometer}. } \]Its typical output is
\[ \boxed{ \mathbf z_{IMU} = \begin{bmatrix} \boldsymbol\omega_m\\ \mathbf f_m \end{bmatrix}. } \]The gyro measures angular rate while the accelerometer measures specific force.
The IMU therefore supports propagation of both orientation and translational states.
However,
\[ \boxed{ \text{IMU Alone} \rightarrow \text{Drifting Navigation Solution}. } \]It requires external aiding for long-term accuracy.
4.1.8.8 IMU Error State
A typical INS error state is
\[ \boxed{ \delta\mathbf x = \begin{bmatrix} \delta\mathbf r\\ \delta\mathbf v\\ \delta\boldsymbol\theta\\ \mathbf b_a\\ \mathbf b_g \end{bmatrix}. } \]More elaborate models can include
\[ \boxed{ \mathbf s_a,\; \mathbf s_g,\; \text{misalignment},\; \text{clock states}. } \]This is why combined sensor suites frequently estimate sensor errors as part of the navigation state.
4.1.8.9 IMU + GNSS
One of the most important navigation architectures is
\[ \boxed{ \text{IMU} + \text{GNSS}. } \]The IMU provides rapid propagation:
\[ \boxed{ \mathbf x_{k+1}^{-} = f(\mathbf x_k^{+},\mathbf z_{IMU}). } \]GNSS provides absolute correction:
\[ \boxed{ \mathbf z_{GNSS} = \begin{bmatrix} \mathbf r_m\\ \mathbf v_m \end{bmatrix}. } \]Thus
\[ \boxed{ \text{IMU High-Rate Propagation} + \text{GNSS Absolute Updates} \rightarrow \text{Bounded Navigation Error}. } \]4.1.8.10 Why IMU and GNSS Are Complementary
The IMU:
- operates at high update rate,
- provides continuous local measurements,
- works without external radio signals,
- has excellent short-term dynamics.
But IMU errors accumulate with integration.
GNSS:
- provides absolute position,
- provides absolute velocity,
- provides precise time,
- does not accumulate inertial drift.
But GNSS:
- operates at lower rate,
- may have latency,
- may suffer outages,
- depends on satellite geometry and RF visibility.
Therefore,
\[ \boxed{ \text{IMU Strengths} \approx \text{GNSS Weaknesses} } \]and vice versa.
4.1.8.11 Loosely Coupled GNSS/INS
In loosely coupled integration,
\[ \boxed{ \text{GNSS Receiver} \rightarrow \mathbf r_{GNSS},\mathbf v_{GNSS} } \]and
\[ \boxed{ \text{IMU} \rightarrow \text{INS Propagation}. } \]The navigation filter compares them:
\[ \boxed{ \mathbf y = \begin{bmatrix} \mathbf r_{GNSS}-\hat{\mathbf r}_{INS}\\ \mathbf v_{GNSS}-\hat{\mathbf v}_{INS} \end{bmatrix}. } \]Advantages include simplicity and clear hardware interfaces.
A limitation is that the GNSS receiver must first generate its own valid solution.
4.1.8.12 Tightly Coupled GNSS/INS
In tightly coupled integration, raw GNSS observables enter the integrated filter directly.
The filter may use
\[ \boxed{ \rho_i,\quad \dot\rho_i } \]together with IMU measurements.
A possible state is
\[ \boxed{ \mathbf x= [ \mathbf r, \mathbf v, \delta\boldsymbol\theta, \mathbf b_a, \mathbf b_g, b_c, d_c ]^T. } \]Benefits include:
- use of individual satellites,
- better degradation behaviour when fewer satellites are available,
- direct estimation of clock states,
- improved fault isolation.
4.1.8.13 Ultra-Tightly Coupled GNSS/INS
Ultra-tight integration goes deeper.
Rather than waiting for completed GNSS observables,
\[ \boxed{ \text{INS Prediction} \rightarrow \text{GNSS Tracking-Loop Aid}. } \]The INS predicts expected code phase and Doppler, assisting receiver tracking loops.
This can improve operation during:
- weak signals,
- high dynamics,
- short GNSS interruptions.
It is much more complex than ordinary spacecraft sensor fusion.
4.1.8.14 Gyroscope + Magnetometer
A gyro–magnetometer combination is a common low-cost attitude architecture.
The gyro provides:
\[ \boldsymbol\omega_m \]for propagation.
The magnetometer provides:
\[ \mathbf B_m^B \]as an absolute vector reference.
The expected magnetic-field direction is
\[ \boxed{ \hat{\mathbf B}^B = C_I^B(\hat{\mathbf q}) \mathbf B^I. } \]The innovation can be
\[ \boxed{ \mathbf y_B = \mathbf B_m^B-\hat{\mathbf B}^B. } \]The magnetometer therefore helps correct gyro drift.
4.1.8.15 Limitation of Gyroscope + Magnetometer
A magnetometer provides only one reference vector.
Therefore,
\[ \boxed{ \text{Magnetometer Alone} \neq \text{Complete Instantaneous Three-Axis Attitude}. } \]The gyro supplies dynamic continuity but does not independently remove every attitude ambiguity.
Performance also depends strongly on spacecraft magnetic cleanliness.
This architecture is therefore well suited to coarse attitude estimation but generally not high-precision pointing.
4.1.8.16 Gyroscope + Sun Sensor
Another complementary combination is
\[ \boxed{ \text{Gyroscope} + \text{Sun Sensor}. } \]The gyro propagates attitude.
The Sun sensor measures
\[ \mathbf s_m^B. \]The predicted vector is
\[ \boxed{ \hat{\mathbf s}^B = C_I^B(\hat{\mathbf q}) \mathbf s^I. } \]The difference constrains gyro drift.
But one Sun vector does not independently determine rotation around the Sun direction.
4.1.8.17 Gyroscope + Sun Sensor + Magnetometer
A highly useful coarse spacecraft architecture is
\[ \boxed{ \text{Gyroscope} + \text{Sun Sensor} + \text{Magnetometer}. } \]Here:
\[ \text{Gyro} \rightarrow \text{High-Rate Propagation} \] \[ \text{Sun Sensor} \rightarrow \text{Celestial Reference} \] \[ \text{Magnetometer} \rightarrow \text{Geomagnetic Reference}. \]The Sun and magnetic vectors provide two independent attitude references when they are sufficiently non-collinear.
Thus
\[ \boxed{ \text{Two Absolute Vectors} + \text{Gyro Dynamics} \rightarrow \text{Three-Axis Attitude Estimate}. } \]This is particularly attractive for CubeSats and safe-mode architectures.
4.1.8.18 Sun Sensor + Magnetometer Without Gyro
If spacecraft dynamics are slow enough, attitude may be determined directly from two vector measurements:
\[ \boxed{ \mathbf s^I,\mathbf B^I } \]and
\[ \boxed{ \mathbf s^B,\mathbf B^B. } \]TRIAD or Wahba-problem algorithms can estimate attitude.
However, without a gyro:
- temporal propagation is weaker,
- attitude estimates can become noisier,
- high-rate control is more difficult.
Therefore a gyro remains highly beneficial.
4.1.8.19 Gyroscope + Star Tracker
For precision spacecraft attitude determination,
\[ \boxed{ \text{Gyroscope} + \text{Star Tracker} } \]is one of the most important combinations.
The gyro provides high-rate attitude propagation.
The star tracker provides accurate absolute attitude.
Conceptually,
\[ \boxed{ \text{Gyro} \rightarrow \hat q^{-} } \]and
\[ \boxed{ \text{Star Tracker} \rightarrow q_m \rightarrow \text{Correction}. } \]4.1.8.20 Why Gyro + Star Tracker Works So Well
The gyro has high bandwidth but drift.
The star tracker has excellent absolute accuracy but lower bandwidth and potential availability constraints.
Together:
\[ \boxed{ \text{High-Bandwidth Relative Information} + \text{Low-Drift Absolute Information} \rightarrow \text{High-Accuracy Attitude}. } \]This architecture is common in high-performance spacecraft.
4.1.8.21 Star-Tracker Update in an MEKF
Suppose the estimated quaternion is
\[ \hat q. \]A star-tracker quaternion measurement is
\[ q_m. \]The attitude error can be formed using an error quaternion:
\[ \boxed{ \delta q = q_m\otimes\hat q^{-1} } \]for one convention.
For small errors,
\[ \delta q \approx \begin{bmatrix} 1\\ \frac12\delta\boldsymbol\theta \end{bmatrix} \]depending on scalar-first/scalar-last convention.
The MEKF estimates
\[ \delta\boldsymbol\theta \]rather than treating the quaternion as an unconstrained additive state.
4.1.8.22 Gyro Bias Estimation Using Star Tracker
A star tracker helps estimate gyro bias.
The gyro model is
\[ \boxed{ \boldsymbol\omega_m = \boldsymbol\omega + \mathbf b_g + \mathbf n_g. } \]Without absolute references, \(\mathbf b_g\) produces increasing attitude error.
Repeated star-tracker updates expose the accumulating drift, allowing the filter to estimate
\[ \boxed{ \hat{\mathbf b}_g. } \]The corrected gyro rate becomes
\[ \boxed{ \hat{\boldsymbol\omega} = \boldsymbol\omega_m-\hat{\mathbf b}_g. } \]4.1.8.23 Star Tracker + Gyro + Sun Sensor
Some spacecraft retain a Sun sensor even when star trackers are available.
A useful hierarchy is
\[ \boxed{ \text{Gyro + Star Tracker} } \]for nominal fine pointing, with
\[ \boxed{ \text{Sun Sensor} } \]providing:
- acquisition support,
- safe mode,
- independent cross-checking,
- recovery if star tracker is unavailable.
This is an example of functional redundancy rather than identical redundancy.
4.1.8.24 Star Tracker + Gyro + Magnetometer
A magnetometer may also serve as an independent backup/reference.
During nominal operation,
\[ \boxed{ \text{Star Tracker + Gyro} } \]may dominate the attitude estimate.
During star-tracker loss,
\[ \boxed{ \text{Gyro + Magnetometer} } \]can maintain a degraded but usable attitude solution.
4.1.8.25 Full Attitude Sensor Suite
A robust spacecraft can therefore use
\[ \boxed{ \text{Gyroscope} + \text{Star Tracker} + \text{Sun Sensor} + \text{Magnetometer}. } \]Their approximate roles are:
| Sensor | Main Contribution |
|---|---|
| Gyroscope | High-rate attitude propagation |
| Star tracker | High-accuracy absolute attitude |
| Sun sensor | Robust celestial reference and safe mode |
| Magnetometer | Independent vector reference and magnetic-control support |
This allows graceful degradation when one or more sensors become unavailable.
4.1.8.26 Accelerometer + Gyroscope + GNSS
A complete inertial-navigation suite can combine
\[ \boxed{ \text{Accelerometer} + \text{Gyroscope} + \text{GNSS}. } \]The accelerometer supports translational propagation.
The gyro supplies orientation needed to rotate measured specific force into the navigation frame.
GNSS corrects long-term position and velocity drift.
Thus attitude errors and translational errors become strongly coupled.
4.1.8.27 Attitude Error Coupling in GNSS/INS
The accelerometer measures specific force in its body/sensor frame.
It must be rotated into the navigation frame:
\[ \boxed{ \mathbf f^I = C_B^I(\hat q) \mathbf f^B. } \]If attitude contains error
\[ \delta\boldsymbol\theta, \]then acceleration contains error approximately
\[ \boxed{ \delta\mathbf f^I \approx -[\mathbf f^I\times] \delta\boldsymbol\theta. } \]Therefore gyro errors indirectly create velocity and position errors.
GNSS position/velocity updates can consequently make gyro and accelerometer biases observable under suitable motion.
4.1.8.28 GNSS + Star Tracker
GNSS and star trackers provide two different absolute measurements.
GNSS provides
\[ \mathbf r,\mathbf v,t \]while the star tracker provides
\[ q. \]Together they provide much of the spacecraft translational and rotational state.
However, high-rate dynamics still usually require gyro and possibly accelerometer propagation.
4.1.8.29 Complete Position and Attitude Navigation Suite
A high-performance spacecraft navigation architecture can be
\[ \boxed{ \text{IMU} + \text{GNSS} + \text{Star Tracker} } \]with optional
\[ \boxed{ \text{Sun Sensor} + \text{Magnetometer}. } \]The estimator can simultaneously estimate:
\[ \boxed{ \mathbf r,\; \mathbf v,\; \mathbf q,\; \mathbf b_a,\; \mathbf b_g,\; \text{clock states} } \]depending on architecture.
4.1.8.30 Centralized Sensor Fusion
In a centralized architecture, measurements from all sensors are processed in a single estimator.
Conceptually,
Gyro ----------+ Accelerometer -+ Magnetometer --+ Sun Sensor ----+ Star Tracker --+----> Central EKF / UKF / MEKF ----> State Estimate GNSS ----------+ Camera --------+ LiDAR ---------+
Advantages include:
- consistent covariance handling,
- access to raw measurements,
- strong cross-sensor coupling,
- potentially optimal use of information.
Disadvantages include:
- more complex estimator,
- larger state dimension,
- greater computational load,
- increased software coupling.
4.1.8.31 Federated Sensor Fusion
In federated architectures, local filters first process individual sensor groups.
For example,
GNSS + IMU --------> Navigation Filter ----+
|
Gyro + StarTracker -> Attitude Filter -----+--> Master Fusion
|
Camera + LiDAR -----> Relative Nav Filter -+
Advantages can include:
- modularity,
- fault containment,
- easier subsystem development,
- graceful degradation.
But care must be taken with covariance and shared-information correlation.
4.1.8.32 Hierarchical Sensor Fusion
A hierarchical architecture may first produce subsystem-level states such as
\[ \boxed{ \hat{\mathbf q} } \]from an attitude estimator and
\[ \boxed{ \hat{\mathbf r},\hat{\mathbf v} } \]from a navigation estimator.
These states are then supplied to guidance.
This is common in practical spacecraft software because it separates:
- attitude estimation,
- translational navigation,
- relative navigation.
4.1.8.33 Loose vs Tight Sensor Fusion
A general distinction exists beyond GNSS/INS.
Loose fusion
Fuse processed sensor outputs.
Example:
\[ \boxed{ q_{startracker} + \boldsymbol\omega_{gyro} } \]Tight fusion
Fuse more fundamental measurements.
Example:
\[ \boxed{ \text{Star centroids} + \text{gyro data} } \]or
\[ \boxed{ \text{GNSS pseudoranges} + \text{IMU}. } \]Tighter integration can exploit more information but increases model complexity.
4.1.8.34 Kalman Filter Sensor Fusion
For linear systems,
\[ \boxed{ \mathbf x_{k+1} = F_k\mathbf x_k + G_k\mathbf w_k } \]and
\[ \boxed{ \mathbf z_k = H_k\mathbf x_k + \mathbf v_k. } \]The Kalman update is
\[ \boxed{ K_k = P_k^-H_k^T (H_kP_k^-H_k^T+R_k)^{-1} } \]and
\[ \boxed{ \hat{\mathbf x}_k^+ = \hat{\mathbf x}_k^- + K_k (\mathbf z_k-H_k\hat{\mathbf x}_k^-). } \]Each sensor contributes through its own measurement equation and covariance.
4.1.8.35 EKF Sensor Fusion
Most spacecraft measurement functions are nonlinear.
Therefore,
\[ \boxed{ \mathbf z = h(\mathbf x)+\mathbf v. } \]The EKF linearizes:
\[ \boxed{ H = \left. \frac{\partial h}{\partial\mathbf x} \right|_{\hat{\mathbf x}}. } \]Different sensors simply supply different \(h_i(\mathbf x)\) and \(R_i\).
This makes the EKF a natural framework for combined sensor suites.
4.1.8.36 MEKF for Attitude Sensor Fusion
For quaternion attitude estimation, the Multiplicative Extended Kalman Filter is widely used.
The nominal quaternion is maintained separately, while the filter estimates a small three-component attitude error:
\[ \boxed{ \delta\boldsymbol\theta. } \]A representative state can be
\[ \boxed{ \delta\mathbf x = \begin{bmatrix} \delta\boldsymbol\theta\\ \mathbf b_g \end{bmatrix}. } \]Measurements from star trackers, Sun sensors, and magnetometers can all update this state.
4.1.8.37 UKF Sensor Fusion
The Unscented Kalman Filter avoids explicit first-order Jacobian linearization.
Sigma points are propagated through
\[ f(\cdot) \]and
\[ h(\cdot). \]This can be useful for strongly nonlinear sensor models.
However:
\[ \boxed{ \text{UKF} \not\Rightarrow \text{Automatically Better}. } \]Its suitability depends on state dimension, computational resources, model quality, and estimator design.
4.1.8.38 Complementary Filters
Not every spacecraft requires a full Kalman filter.
A complementary filter combines high-frequency information from one sensor with low-frequency absolute information from another.
For example,
\[ \boxed{ \text{Gyro High-Frequency Response} + \text{Sun/Magnetic Low-Frequency Reference}. } \]Complementary filters can be:
- computationally inexpensive,
- robust,
- easy to tune.
They are useful for small spacecraft and safe-mode systems.
4.1.8.39 Sensor Weighting
Sensor fusion depends on uncertainty.
For measurement covariance
\[ R_i, \]a more accurate sensor generally receives more weight.
Conceptually,
\[ \boxed{ R_i\downarrow \Rightarrow \text{Measurement Confidence}\uparrow. } \]However, covariance must reflect actual operating conditions.
A star tracker near blinding or a GNSS solution with poor geometry should not retain nominal high confidence.
4.1.8.40 Adaptive Measurement Covariance
Sensor covariance may vary:
\[ \boxed{ R_i = R_i( \text{signal quality}, \text{geometry}, \text{temperature}, \text{dynamics}, \text{mode} ). } \]Examples include:
\[ R_{GNSS}=R(DOP,C/N_0) \] \[ R_{Sun}=R(\text{incidence angle}) \] \[ R_{ST}=R(\text{slew rate},\text{star count}). \]Adaptive weighting can substantially improve robustness.
4.1.8.41 Sensor Availability
Combined suites must explicitly model sensor availability:
\[ \boxed{ valid_i\in\{0,1\}. } \]Examples include:
\[ valid_{Sun}=0 \]during eclipse,
\[ valid_{ST}=0 \]during blinding or lost-in-space recovery,
and
\[ valid_{GNSS}=0 \]during insufficient satellite visibility.
Fusion software must operate correctly as the measurement set changes.
4.1.8.42 Asynchronous Sensor Fusion
Sensors rarely operate at identical update rates.
For example:
\[ f_{gyro}=100\text{ Hz} \] \[ f_{star}=5\text{ Hz} \] \[ f_{GNSS}=10\text{ Hz} \] \[ f_{Sun}=1\text{ Hz} \]depending on hardware.
The estimator therefore runs asynchronously:
\[ \boxed{ \text{Propagate at IMU/Gyro Rate} } \]and
\[ \boxed{ \text{Update Whenever a Valid Measurement Arrives}. } \]4.1.8.43 Time Synchronization
Measurement fusion requires a consistent time base.
Each measurement should carry
\[ \boxed{ t_m. } \]If sensors report data at different epochs, they must not simply be fused as simultaneous measurements.
A timing error
\[ \Delta t \]can create
\[ \boxed{ \delta\mathbf r \approx \mathbf v\Delta t } \]and
\[ \boxed{ \delta\boldsymbol\theta \approx \boldsymbol\omega\Delta t. } \]Time synchronization is therefore part of sensor fusion, not merely avionics housekeeping.
4.1.8.44 Latency Compensation
Suppose a star tracker measurement corresponds to
\[ t_k \]but arrives at
\[ t_k+\tau. \]The estimator can:
- update a stored past state and repropagate,
- propagate the measurement to the current time,
- use an out-of-sequence measurement algorithm.
Ignoring latency can degrade accuracy substantially during fast maneuvers.
4.1.8.45 Frame Alignment
Different sensors use different coordinate frames.
For example:
\[ S_g \]for gyro,
\[ S_m \]for magnetometer,
\[ S_{ST} \]for star tracker,
\[ A \]for GNSS antenna,
and
\[ B \]for spacecraft body frame.
Measurements must therefore be transformed consistently.
For sensor \(i\),
\[ \boxed{ \mathbf z^B = C_{S_i}^{B} \mathbf z^{S_i}. } \]4.1.8.46 Sensor-to-Sensor Alignment
Even when two sensors are mounted on the same spacecraft panel, their axes are not perfectly aligned.
For example,
\[ \boxed{ C_{gyro}^{ST} = C_B^{ST} C_{gyro}^{B}. } \]Alignment uncertainty can become one of the dominant errors when fusing a high-accuracy star tracker with a gyro.
Thus sensor-suite calibration includes not only each sensor individually, but also their relative geometry.
4.1.8.47 Lever Arms
Different sensors may observe different physical points on the spacecraft.
An accelerometer offset from the centre of mass experiences
\[ \mathbf a_s = \mathbf a_{CM} + \dot{\boldsymbol\omega}\times\mathbf r_s + \boldsymbol\omega\times (\boldsymbol\omega\times\mathbf r_s). \]Similarly, a GNSS antenna phase centre may be displaced from the spacecraft navigation reference point.
Lever-arm compensation is required in precision combined navigation.
4.1.8.48 Covariance Transformation Between Frames
If a measurement covariance is defined in sensor frame \(S\),
\[ R^S, \]and the measurement is rotated into body frame,
\[ \mathbf z^B=C_S^B\mathbf z^S, \]then
\[ \boxed{ R^B = C_S^B R^S (C_S^B)^T. } \]Fusion becomes inconsistent if the measurement is rotated but its covariance is not.
4.1.8.49 Cross-Sensor Correlation
Sensor errors are not always independent.
For two sensor errors,
\[ \boxed{ E[ \mathbf e_1 \mathbf e_2^T ] = P_{12}. } \]Examples include:
- shared temperature,
- shared structural deformation,
- common timing source,
- common GNSS errors,
- common processing.
Ignoring correlation can cause the estimator to become overconfident.
4.1.8.50 Common-Mode Errors
Redundant sensors may share a common error:
\[ e_1=e_c+e_{1u} \] \[ e_2=e_c+e_{2u}. \]Their difference is
\[ e_1-e_2 = e_{1u}-e_{2u}. \]Thus the common error cancels in a comparison and may remain undetected.
This is why dissimilar redundancy can be valuable.
4.1.8.51 Homogeneous Redundancy
Homogeneous redundancy uses multiple similar sensors:
\[ \boxed{ \text{Gyro A} + \text{Gyro B} + \text{Gyro C}. } \]Advantages include:
- easy comparison,
- hardware commonality,
- voting.
Disadvantages include shared design weaknesses and common-mode errors.
4.1.8.52 Dissimilar Redundancy
Dissimilar redundancy uses sensors based on different physical principles.
For example,
\[ \boxed{ \text{Star Tracker} + \text{Sun Sensor} + \text{Magnetometer}. } \]A common failure mechanism is less likely to affect all three identically.
This is particularly valuable for spacecraft fault tolerance.
4.1.8.53 Triple-Modular Sensor Voting
For three comparable measurements,
\[ z_1,\quad z_2,\quad z_3, \]pairwise consistency can be checked.
If
\[ |z_1-z_2| \]and
\[ |z_1-z_3| \]are large while
\[ |z_2-z_3| \]is small, sensor 1 may be faulty.
Voting should consider measurement covariance rather than only raw differences.
4.1.8.54 Innovation-Based FDIR
For sensor \(i\),
\[ \boxed{ \mathbf y_i = \mathbf z_i - h_i(\hat{\mathbf x}^{-}). } \]Innovation covariance is
\[ \boxed{ S_i = H_iP^-H_i^T+R_i. } \]The normalized residual is
\[ \boxed{ d_i^2 = \mathbf y_i^T S_i^{-1} \mathbf y_i. } \]If
\[ d_i^2>\gamma_i, \]the measurement can be rejected or marked degraded.
4.1.8.55 Cross-Sensor Consistency Monitoring
Different sensors can independently observe related quantities.
For example:
\[ \boxed{ \text{Star Tracker Attitude} \rightarrow \text{Predicted Sun Vector} } \]which can be compared with
\[ \boxed{ \text{Sun-Sensor Measurement}. } \]Similarly,
\[ \boxed{ \text{Gyro-Propagated Attitude} } \]can be compared with
\[ \boxed{ \text{Star-Tracker Attitude}. } \]Cross-sensor consistency is a powerful fault-detection tool.
4.1.8.56 Graceful Degradation
A robust sensor suite should not jump directly from nominal operation to total loss of navigation.
Instead,
\[ \boxed{ \text{Nominal} \rightarrow \text{Degraded} \rightarrow \text{Safe} } \]should be possible.
For example:
\[ \boxed{ \text{Gyro + Star Tracker} } \]may degrade to
\[ \boxed{ \text{Gyro + Sun Sensor + Magnetometer} } \]and finally to
\[ \boxed{ \text{Coarse Sun Sensor + Magnetometer}. } \]4.1.8.57 Mode-Dependent Sensor Suites
Spacecraft sensors should be associated with operating modes.
A representative architecture is:
| Spacecraft Mode | Typical Sensor Suite |
|---|---|
| Detumble | Magnetometer + gyro |
| Sun acquisition | Coarse Sun sensor + gyro + magnetometer |
| Safe mode | Sun sensor + magnetometer + gyro |
| Nominal attitude | Star tracker + gyro |
| Orbit navigation | GNSS + IMU |
| Far RPO | GNSS / differential GNSS |
| Mid RPO | GNSS + camera / LiDAR |
| Final approach | Camera + LiDAR + IMU |
| Docking/capture | Precision relative pose sensors + IMU |
This architecture is mission-dependent but illustrates how sensor suites evolve with mission phase.
4.1.8.58 Safe-Mode Sensor Suite
Safe mode prioritizes survivability.
A typical suite may use
\[ \boxed{ \text{Coarse Sun Sensors} + \text{Magnetometer} + \text{Gyroscope}. } \]Why?
Sun sensors provide a robust power-related reference.
Magnetometers remain available in eclipse.
Gyroscopes provide short-term rotational propagation.
The safe-mode controller therefore retains usable attitude knowledge even if fine sensors are unavailable.
4.1.8.59 Nominal Fine-Pointing Suite
For fine pointing,
\[ \boxed{ \text{Star Tracker} + \text{Gyroscope} } \]may form the core architecture.
Optional aiding may include:
\[ \boxed{ \text{GNSS} } \]for orbit knowledge and
\[ \boxed{ \text{Sun Sensor / Magnetometer} } \]for redundancy and health monitoring.
4.1.8.60 RPO Sensor Suite
Rendezvous and proximity operations require a broader navigation architecture.
A representative chain is
\[ \boxed{ \text{Absolute GNSS} \rightarrow \text{Differential GNSS} \rightarrow \text{Camera / LiDAR} \rightarrow \text{Precision Relative Pose} } \]with IMU aiding throughout.
The exact transition ranges depend on mission requirements and hardware capability.
4.1.8.61 GNSS + Camera for RPO
GNSS provides absolute or cooperative relative translation.
The camera provides direct target line-of-sight information.
For a camera,
\[ \boxed{ \mathbf z_C = \begin{bmatrix} \alpha\\ \beta \end{bmatrix} } \]where \(\alpha,\beta\) are bearing angles.
A relative navigation filter can combine
\[ \boxed{ \delta\mathbf r_{GNSS} } \]and
\[ \boxed{ \alpha,\beta. } \]This improves relative observability as the target becomes visually detectable.
4.1.8.62 GNSS + LiDAR
A LiDAR can directly provide target-relative range:
\[ \boxed{ \rho_L = \|\delta\mathbf r\| + n_L. } \]Depending on design, it may also provide:
- range rate,
- bearing,
- 3-D point cloud,
- relative pose.
GNSS provides broader-range orbital navigation, while LiDAR becomes increasingly useful at shorter ranges.
4.1.8.63 Camera + LiDAR
Camera and LiDAR are highly complementary.
Camera:
- rich angular/feature information,
- relatively high spatial resolution,
- target identification capability.
LiDAR:
- direct range,
- active illumination,
- 3-D geometry.
Combined:
\[ \boxed{ \text{Camera Bearing} + \text{LiDAR Range} \rightarrow \text{Improved Relative Position}. } \]4.1.8.64 Camera + LiDAR + IMU
A close-range RPO suite can use
\[ \boxed{ \text{Camera} + \text{LiDAR} + \text{IMU}. } \]The IMU supplies high-rate propagation.
The camera supplies target direction and feature information.
The LiDAR supplies metric range and geometry.
This combination can support:
\[ \boxed{ \text{Relative Position} + \text{Relative Velocity} + \text{Relative Attitude} } \]depending on sensor processing.
4.1.8.65 Relative Pose Estimation
Docking requires more than relative position.
The navigation state may include
\[ \boxed{ \mathbf x_{rel} = \begin{bmatrix} \delta\mathbf r\\ \delta\mathbf v\\ \mathbf q_{rel}\\ \boldsymbol\omega_{rel} \end{bmatrix}. } \]Camera and LiDAR data can therefore contribute to relative pose estimation.
4.1.8.66 Sensor Handover During RPO
Sensor handover should not simply switch one sensor off and another on at one exact range.
A safer strategy is
\[ \boxed{ \text{Sensor A} \rightarrow \text{Overlap A+B} \rightarrow \text{Consistency Check} \rightarrow \text{Sensor B Dominant}. } \]For example,
\[ \boxed{ \text{GNSS} \rightarrow \text{GNSS + Camera} \rightarrow \text{Camera + LiDAR}. } \]4.1.8.67 Handover Consistency Test
Before accepting the new sensor,
\[ \boxed{ \|\hat{\mathbf r}_A-\hat{\mathbf r}_B\| < r_{threshold} } \]and possibly
\[ \boxed{ \|\hat{\mathbf v}_A-\hat{\mathbf v}_B\| < v_{threshold}. } \]The threshold should account for both sensor covariances.
A covariance-normalized consistency check is generally more rigorous than a fixed raw difference.
4.1.8.68 Sensor Scheduling
Sensors may be switched on only when needed.
Reasons include:
- power reduction,
- thermal control,
- computational load,
- instrument lifetime,
- optical protection.
A sensor manager can therefore decide
\[ \boxed{ \text{Which Sensors Should Be Active?} } \]based on spacecraft mode and navigation requirements.
4.1.8.69 Power-Aware Sensor Management
Suppose star trackers and LiDAR consume substantially more power than coarse sensors.
During safe mode, the spacecraft may use
\[ \boxed{ \text{CSS + Magnetometer} } \]rather than high-power precision sensors.
During final RPO, the high-power relative sensors may be enabled.
Thus sensor-suite design is connected to the spacecraft power budget.
4.1.8.70 Computational Load
Each sensor adds processing requirements.
Examples include:
- star-pattern recognition,
- GNSS signal processing,
- image feature extraction,
- LiDAR point-cloud processing,
- EKF updates.
The navigation architecture therefore depends on available flight-computer resources.
4.1.8.71 Measurement Preprocessing
Sensors often require preprocessing before fusion.
Examples include:
\[ \boxed{ \text{Raw IMU} \rightarrow \text{Calibration} \rightarrow \text{Bias Compensation} } \] \[ \boxed{ \text{Raw Magnetometer} \rightarrow \text{Hard/Soft-Iron Calibration} } \] \[ \boxed{ \text{Star Image} \rightarrow \text{Centroids} \rightarrow \text{Attitude} } \] \[ \boxed{ \text{GNSS RF} \rightarrow \rho,\dot\rho,\Phi } \] \[ \boxed{ \text{Camera Image} \rightarrow \text{Feature Measurements}. } \]The estimator should receive a well-defined measurement interface.
4.1.8.72 Common Measurement Packet
A useful software interface is
\[ \boxed{ \mathcal Z_i = \{ \mathbf z_i, t_i, R_i, valid_i, quality_i, status_i \}. } \]This allows all sensors to follow a common estimator interface despite different physical measurements.
4.1.8.73 Measurement Queue
For asynchronous sensors, measurements can enter a time-ordered queue.
Gyro ----------\
Accelerometer ---\
Star Tracker -----\
GNSS -------------+--> Time-Ordered Measurement Queue
Sun Sensor --------/
Magnetometer -----/
LiDAR -----------/
Camera ----------/
|
v
Navigation Filter
This architecture simplifies multi-rate fusion.
4.1.8.74 Out-of-Sequence Measurements
Some measurements arrive late.
If
\[ t_mPossible strategies include:
- discard it,
- update a stored past state and repropagate,
- approximate measurement propagation,
- use a delayed-state estimator.
The correct choice depends on latency and mission accuracy.
4.1.8.75 Sensor Initialization
Different sensors require different startup procedures.
For example:
\[ \boxed{ \text{GNSS} \rightarrow \text{Acquire Satellites} \rightarrow \text{PVT Valid} } \] \[ \boxed{ \text{Star Tracker} \rightarrow \text{Lost-in-Space Solution} \rightarrow \text{Tracking Mode} } \] \[ \boxed{ \text{IMU} \rightarrow \text{Bias Initialization}. } \]Sensor-suite management must handle these transitions.
4.1.8.76 Initial Attitude Acquisition
A spacecraft may not initially know attitude accurately enough for a star tracker to enter tracking mode.
A possible acquisition sequence is
\[ \boxed{ \text{Sun Sensor + Magnetometer} \rightarrow \text{Coarse Attitude} \rightarrow \text{Star Tracker Acquisition} \rightarrow \text{Fine Attitude}. } \]This illustrates how sensor suites can support one another operationally, not only mathematically.
4.1.8.77 Sensor Observability
Combining more sensors does not guarantee that all estimator states become observable.
Observability depends on:
- measurement type,
- spacecraft motion,
- geometry,
- sensor availability.
For example, one vector observation cannot determine rotation about that vector.
Two nearly parallel reference vectors also provide weak attitude observability.
Thus,
\[ \boxed{ \text{More Sensors} \not\Rightarrow \text{Better Observability} } \]unless their information is sufficiently independent.
4.1.8.78 Geometry of Vector Sensors
Suppose Sun and magnetic reference vectors satisfy
\[ \mathbf s^I \parallel \mathbf B^I. \]Then their cross product approaches zero:
\[ \boxed{ \|\mathbf s^I\times\mathbf B^I\| \rightarrow0. } \]TRIAD and related attitude solutions become poorly conditioned.
Thus vector geometry is a fundamental sensor-suite performance consideration.
4.1.8.79 GNSS Geometry in a Combined Suite
GNSS accuracy also depends on satellite geometry.
Therefore even if GNSS remains technically valid,
\[ PDOP\uparrow \]can imply
\[ R_{GNSS}\uparrow. \]An integrated GNSS/INS filter can then rely more heavily on inertial propagation until geometry improves.
4.1.8.80 Dynamic Observability
Spacecraft maneuvers can improve observability.
For example, accelerometer bias and attitude error may be difficult to separate during certain static conditions.
Controlled motion can provide excitation that helps the estimator distinguish them.
Thus calibration maneuvers can be deliberately designed to improve sensor-suite observability.
4.1.8.81 Calibration of a Combined Sensor Suite
A complete suite requires both individual-sensor calibration and cross-sensor calibration.
The latter may estimate:
\[ \boxed{ C_{gyro}^{ST} } \] \[ \boxed{ C_{mag}^{B} } \] \[ \boxed{ C_{Sun}^{B} } \] \[ \boxed{ \mathbf l_{GNSS}^{B} } \]and timing offsets
\[ \boxed{ \Delta t_{ij}. } \]Thus the calibration problem includes geometry and timing in addition to each sensor's intrinsic bias and scale factor.
4.1.8.82 In-Orbit Cross Calibration
A high-accuracy sensor can calibrate a lower-accuracy sensor.
For example:
\[ \boxed{ \text{Star Tracker} + \text{Sun Ephemeris} \rightarrow \text{Predicted Sun Direction} } \]which can be compared with the Sun sensor.
Similarly, star-tracker attitude plus geomagnetic-field prediction can help evaluate magnetometer alignment.
GNSS can help estimate IMU biases through integrated navigation.
4.1.8.83 Sensor Fusion and Calibration Are Coupled
In many spacecraft filters, calibration is performed continuously.
For example,
\[ \boxed{ \mathbf b_g } \]and
\[ \boxed{ \mathbf b_a } \]are estimated as navigation states.
Thus the filter performs both
\[ \boxed{ \text{Navigation Estimation} + \text{Sensor Calibration}. } \]4.1.8.84 Sensor Failure Modes in a Combined Suite
Failures include:
- complete loss of output,
- excessive noise,
- growing bias,
- stuck output,
- incorrect timestamp,
- intermittent dropout,
- corrupted data,
- degraded calibration,
- invalid quality flags.
The estimator should react differently to each type.
A sensor that reports no measurement is often easier to handle than one producing believable but incorrect data.
4.1.8.85 Fault Isolation
If the estimator detects inconsistency, the next question is:
\[ \boxed{ \text{Which Sensor Is Faulty?} } \]This can be difficult when several sensors disagree.
Isolation can use:
- pairwise residuals,
- model-based predictions,
- redundant sensing,
- independent reference models,
- consistency over time.
Dissimilar sensors can improve isolation.
4.1.8.86 Sensor Reconfiguration
After fault isolation, the sensor manager may reconfigure the suite.
For example,
\[ \boxed{ \text{Star Tracker Failed} } \]can trigger
\[ \boxed{ \text{Gyro + Sun Sensor + Magnetometer Mode}. } \]Similarly,
\[ \boxed{ \text{GNSS Lost} } \]can trigger
\[ \boxed{ \text{INS Propagation + Alternative Relative Sensors}. } \]4.1.8.87 Sensor Reacquisition
A failed or unavailable sensor may later recover.
The system should not immediately trust it at full weight.
A safer sequence is
\[ \boxed{ \text{Sensor Returns} \rightarrow \text{Acquisition} \rightarrow \text{Health Check} \rightarrow \text{Consistency Check} \rightarrow \text{Reintegration}. } \]4.1.8.88 Data Quality Flags
Useful status information can include:
\[ \boxed{ valid } \] \[ \boxed{ degraded } \] \[ \boxed{ saturated } \] \[ \boxed{ outlier } \] \[ \boxed{ tracking } \] \[ \boxed{ acquiring } \] \[ \boxed{ failed. } \]Sensor fusion should use these flags rather than assuming every packet is valid.
4.1.8.89 Sensor Health Manager
A spacecraft can maintain a centralized sensor health manager.
Sensors | v Measurement Validation | v Health / Quality Monitoring | +------ Good | +------ Degraded | +------ Failed | v Sensor Selection / Weighting | v Navigation Filter
This separates sensor-health decisions from state-estimation mathematics.
4.1.8.90 Sensor Suite Monte Carlo Analysis
Combined suites should be tested with simultaneous uncertainty in all relevant sensors.
For Monte Carlo run \(j\),
\[ \boxed{ \mathcal P^{(j)} = \{ \mathbf b_g, \mathbf b_a, \delta C_{ST}, \delta C_{mag}, \sigma_{GNSS}, \tau_i, dropout_i,\ldots \}^{(j)}. } \]The complete simulation should include
\[ \boxed{ \text{Truth} \rightarrow \text{Sensors} \rightarrow \text{Fusion} \rightarrow \text{Guidance} \rightarrow \text{Control} \rightarrow \text{Mission Outcome}. } \]4.1.8.91 Correlated Monte Carlo Errors
Not every sensor uncertainty should be sampled independently.
For example:
- two sensors on the same panel may share alignment deformation,
- several GNSS measurements share clock errors,
- temperature may affect multiple sensors simultaneously.
Thus correlated uncertainty may require
\[ \boxed{ \mathbf e \sim \mathcal N(0,P) } \]with nonzero off-diagonal covariance.
4.1.8.92 Sensor Availability Monte Carlo
Mission robustness also depends on availability.
Randomize or model:
\[ \boxed{ \text{Star-Tracker Dropout} } \] \[ \boxed{ \text{GNSS Outage} } \] \[ \boxed{ \text{Sun-Sensor Eclipse} } \] \[ \boxed{ \text{LiDAR Invalid Geometry}. } \]This is often more realistic than studying accuracy alone.
4.1.8.93 Fault Injection Testing
Combined sensor suites should be deliberately tested with faults such as:
\[ \boxed{ b_g\rightarrow b_g+\Delta b } \] \[ \boxed{ valid_{ST}\rightarrow0 } \] \[ \boxed{ \mathbf r_{GNSS}\rightarrow \mathbf r_{GNSS}+\Delta\mathbf r_{fault} } \] \[ \boxed{ z_{LiDAR}\rightarrow z_{stuck}. } \]The purpose is to verify:
- detection,
- isolation,
- reconfiguration,
- safe continuation.
4.1.8.94 Hardware-in-the-Loop Testing
Combined sensor suites should eventually be tested beyond pure software simulation.
A HIL setup may use:
- real IMU,
- GNSS RF simulator,
- star-tracker simulator,
- Sun-sensor light source,
- camera scene generator,
- LiDAR target emulator.
This validates:
\[ \boxed{ \text{Timing} + \text{Interfaces} + \text{Real Sensor Dynamics} + \text{Navigation Software}. } \]4.1.8.95 Software-in-the-Loop Architecture
A SIL architecture may be
SPACECRAFT TRUTH
|
+--------------+---------------+
| | |
v v v
IMU Model Attitude Sensors GNSS Model
| | |
+--------------+---------------+
|
v
Sensor Bus
|
v
Validation / FDIR
|
v
Navigation Filter
|
v
Estimated Spacecraft State
|
v
Guidance
|
v
Control
RPO sensors can be added as another branch.
4.1.8.96 Simulink Combined Sensor Suite
A reusable Simulink architecture can be
Spacecraft Truth
|
+---------------- Gyro Model
|
+---------------- Accelerometer Model
|
+---------------- Magnetometer Model
|
+---------------- Sun Sensor Model
|
+---------------- Star Tracker Model
|
+---------------- GNSS Model
|
+---------------- Camera / LiDAR Models
|
v
Frame + Timestamp Normalisation
|
v
Measurement Validity
|
v
Sensor Health Manager
|
v
Measurement Queue
|
v
EKF / MEKF / UKF
|
v
Estimated State + Covariance
|
v
Guidance and Control
4.1.8.97 Recommended Simulink Interfaces
Each sensor subsystem should ideally output
\[ \boxed{ \mathbf z_i } \] \[ \boxed{ R_i } \] \[ \boxed{ t_i } \] \[ \boxed{ valid_i } \] \[ \boxed{ status_i. } \]This makes the fusion architecture modular and easier to extend.
4.1.8.98 Sensor Fusion State Vector
A complete state vector might be
\[ \boxed{ \mathbf x = \begin{bmatrix} \mathbf r\\ \mathbf v\\ \mathbf q\\ \mathbf b_a\\ \mathbf b_g\\ b_c\\ d_c\\ \mathbf p_{cal}\\ \cdots \end{bmatrix}. } \]For RPO,
\[ \boxed{ \mathbf x_{RPO} = \begin{bmatrix} \delta\mathbf r\\ \delta\mathbf v\\ \mathbf q_{rel}\\ \boldsymbol\omega_{rel}\\ \mathbf b_{sensor} \end{bmatrix}. } \]Not every state should be included unless it is required and sufficiently observable.
4.1.8.99 Measurement Models in a Combined Filter
A gyro may be used for propagation rather than direct update.
A magnetometer measurement is
\[ \boxed{ \mathbf z_m = C_I^B(\mathbf q) \mathbf B^I + \mathbf v_m. } \]A Sun sensor is
\[ \boxed{ \mathbf z_s = C_I^B(\mathbf q) \mathbf s^I + \mathbf v_s. } \]GNSS position is
\[ \boxed{ \mathbf z_G = \mathbf r + \mathbf v_G. } \]A LiDAR range is
\[ \boxed{ z_L = \|\delta\mathbf r\| + v_L. } \]A camera bearing is
\[ \boxed{ \mathbf z_C = h_C(\delta\mathbf r,\mathbf q_{rel}) + \mathbf v_C. } \]All can coexist within one estimator.
4.1.8.100 Sensor Suite Selection
Selecting a sensor suite requires consideration of more than individual sensor accuracy.
The key questions include mission state requirements, update rate, accuracy, observability, coverage, environmental availability, redundancy, power, mass, processing, thermal limits, radiation tolerance, interfaces, calibration burden, cross-sensor alignment, FDIR capability, and mission-phase transitions.
The design process should be
\[ \boxed{ \text{Mission Objectives} \rightarrow \text{Required States} \rightarrow \text{Required Accuracy / Availability} \rightarrow \text{Sensor Observability} \rightarrow \text{Candidate Suite} \rightarrow \text{Fusion Design} \rightarrow \text{Monte Carlo / FDIR Verification}. } \]4.1.8.101 Accuracy Is Not the Only Requirement
A spacecraft sensor suite should be evaluated using:
\[ \boxed{ \text{Accuracy} } \] \[ \boxed{ \text{Precision} } \] \[ \boxed{ \text{Availability} } \] \[ \boxed{ \text{Continuity} } \] \[ \boxed{ \text{Integrity} } \] \[ \boxed{ \text{Robustness} } \] \[ \boxed{ \text{Recovery Capability}. } \]A very accurate sensor with poor availability may be unsuitable for a safety-critical mode.
4.1.8.102 Sensor Diversity
A well-designed suite may deliberately use different sensing physics.
For attitude:
\[ \boxed{ \text{Inertial} + \text{Optical} + \text{Magnetic}. } \]For translational navigation:
\[ \boxed{ \text{Inertial} + \text{RF Navigation} + \text{Optical / Active Ranging}. } \]Sensor diversity improves robustness to environmental and hardware-specific failures.
4.1.8.103 Sensor Suite for CubeSat
A basic CubeSat attitude suite might use
\[ \boxed{ \text{MEMS Gyro} + \text{Magnetometer} + \text{Coarse Sun Sensors}. } \]A more capable system might add
\[ \boxed{ \text{Star Tracker} } \]and
\[ \boxed{ \text{GNSS}. } \]The final architecture depends on mission pointing and navigation requirements.
4.1.8.104 Sensor Suite for Earth Observation
An Earth-observation spacecraft may require precise attitude knowledge and geolocation.
A representative suite may be
\[ \boxed{ \text{Star Tracker} + \text{Precision Gyro} + \text{GNSS}. } \]Optional coarse sensors support safe mode.
The relationship between payload boresight and star-tracker frame can be one of the dominant geolocation-error contributors.
4.1.8.105 Sensor Suite for Deep Space
GNSS may be unavailable or limited in deep-space missions.
The navigation architecture may instead use
\[ \boxed{ \text{Star Tracker} + \text{Gyroscope} + \text{Sun Sensor} } \]for attitude and external radiometric/optical navigation for translation.
Sensor-suite architecture must therefore be mission-environment specific.
4.1.8.106 Sensor Suite for RPO and Docking
A sophisticated RPO spacecraft can use
\[ \boxed{ \text{IMU} + \text{GNSS} + \text{Star Tracker} + \text{Camera} + \text{LiDAR} } \]with optional:
\[ \boxed{ \text{Differential GNSS} } \]and additional docking sensors.
The important point is not that all sensors are used continuously, but that their operational envelopes overlap sufficiently to maintain navigation continuity.
4.1.8.107 Sensor Suite for Formation Flying
Formation flying can use
\[ \boxed{ \text{GNSS / Carrier-Phase Differential GNSS} + \text{IMU} } \]for relative orbit determination.
Optical or RF inter-satellite measurements can add robustness and improve observability depending on formation geometry.
4.1.8.108 Sensor Suite for Safe Autonomous Operation
Autonomy requires not just multiple sensors, but a system capable of determining:
\[ \boxed{ \text{What Sensors Are Available?} } \] \[ \boxed{ \text{Which Are Trustworthy?} } \] \[ \boxed{ \text{Which State Components Are Observable?} } \] \[ \boxed{ \text{Which Mission Modes Are Safe?} } \]The sensor suite, estimator, FDIR, and mode manager must therefore be designed together.
4.1.8.109 Common Design Mistakes
Common mistakes include treating all measurements as synchronous, assuming constant covariance, ignoring sensor-to-body alignment, fusing duplicated information without accounting for correlation, trusting sensor validity flags blindly, assuming more sensors always improve observability, ignoring sensor handover transients, modelling only Gaussian noise, failing to model outages, and selecting sensors only from individual datasheet accuracy.
These mistakes can produce an apparently sophisticated fusion system that performs poorly in realistic mission conditions.
4.1.8.110 Recommended Combined Sensor-Suite Architecture
For a general spacecraft, a practical layered architecture is
SPACECRAFT TRUTH
|
+------------------+------------------+
| | |
v v v
Inertial Sensors Absolute Sensors Relative Sensors
Gyro + Accel ST / Sun / Mag GNSS / Camera /
LiDAR
| | |
+------------------+------------------+
|
v
Calibration / Frame Mapping
|
v
Time Synchronization
|
v
Validity + Quality Checks
|
v
Sensor Manager
|
v
Measurement Queue / Router
|
v
EKF / MEKF / UKF
|
v
State Estimate + Covariance
|
+-------------+-------------+
| |
v v
Guidance FDIR
| |
v v
Control Mode Reconfiguration
|
v
Actuators
This is a strong generic architecture because it separates sensing, normalization, health management, fusion, and mission control.
4.1.8.111 Complete Attitude Sensor Fusion Chain
For attitude determination:
Gyroscope
|
v
High-Rate Quaternion Propagation
|
v
Predicted Attitude
|
+--------------------+
| |
v v
Star Tracker Sun Sensor
| |
+---------+----------+
|
v
Magnetometer
|
v
Measurement Updates
|
v
MEKF / EKF
|
v
Attitude Estimate
|
v
Gyro Bias Estimate
|
v
Attitude Control
4.1.8.112 Complete Translational Navigation Chain
For spacecraft translation:
Accelerometer
|
v
Specific Force
|
+------ Gyro Attitude
|
v
Navigation-Frame Acceleration
|
v
Velocity / Position Propagation
|
+----------------+
| |
v v
GNSS Orbit Dynamics
| |
+-------+--------+
|
v
Navigation EKF
|
v
Position + Velocity
|
v
Guidance
4.1.8.113 Complete RPO Sensor Fusion Chain
For rendezvous and docking:
IMU
|
v
Relative-State Propagation
|
+------------------+------------------+
| | |
v v v
GNSS / DGNSS Camera LiDAR
| | |
+------------------+------------------+
|
v
Time / Frame Alignment
|
v
Measurement Validation
|
v
Relative Navigation EKF
|
v
Relative Position / Velocity
Relative Attitude / Rate
|
v
RPO Guidance
|
+---------------+---------------+
| |
v v
Nominal Approach Abort Logic
| |
+---------------+---------------+
|
v
Thruster Control
4.1.8.114 Combined Sensor-Suite Error Budget
The total navigation error cannot be derived by looking at each sensor independently.
A conceptual combined error budget is
\[ \boxed{ P_{nav} = f( P_{gyro}, P_{accel}, P_{ST}, P_{Sun}, P_{mag}, P_{GNSS}, P_{camera}, P_{LiDAR}, P_{timing}, P_{alignment}, P_{dynamics} ). } \]Because the estimator couples sensors through dynamics, the relationship is generally not simple addition.
4.1.8.115 Navigation Covariance as the Central Output
A combined sensor suite should output not only the best estimate
\[ \boxed{ \hat{\mathbf x} } \]but also its uncertainty:
\[ \boxed{ P = E[ (\mathbf x-\hat{\mathbf x}) (\mathbf x-\hat{\mathbf x})^T ]. } \]For autonomous guidance and safety systems,
\[ \boxed{ \hat{\mathbf x}+P } \]is far more informative than \(\hat{\mathbf x}\) alone.
4.1.8.116 Sensor Suite and Mission Safety
For critical operations such as docking, a navigation solution may only be accepted when
\[ \boxed{ valid_{nav}=1 } \]and covariance remains below required bounds.
For example,
\[ \boxed{ \sigma_{r,rel} < \sigma_{r,max} } \] \[ \boxed{ \sigma_{v,rel} < \sigma_{v,max}. } \]Therefore spacecraft safety logic should use estimated uncertainty as well as estimated state.
4.1.8.117 Capture-Readiness Sensor Fusion
For docking or robotic handover, the navigation system may evaluate
\[ \boxed{ \|\mathbf r_{rel}\| \le r_{capture} } \] \[ \boxed{ \|\mathbf v_{rel}\| \le v_{capture} } \] \[ \boxed{ \theta_{rel} \le\theta_{capture} } \] \[ \boxed{ \|\boldsymbol\omega_{rel}\| \le\omega_{capture}. } \]But these should ideally be checked using filtered states and sufficient confidence.
A stronger condition is
\[ \boxed{ \text{State Limits} + \text{Covariance Limits} + \text{Dwell} \rightarrow \text{Capture Ready}. } \]4.1.8.118 Sensor Fusion and Dwell Logic
Noisy sensors can repeatedly cross a threshold.
Therefore mode transitions may require
\[ condition(t)=true \]for
\[ \boxed{ t\ge T_{dwell}. } \]This reduces false transitions caused by measurement noise.
It is especially important for RPO hold points and capture readiness.
4.1.8.119 Hysteresis in Sensor-Mode Switching
Sensor switching thresholds can use hysteresis.
For example, activate a close-range sensor when
\[ rwith
\[ \boxed{ r_{out}>r_{in}. } \]This prevents rapid switching near the transition boundary.
4.1.8.120 Confidence-Based Sensor Management
Sensor selection can depend on confidence instead of only range.
Define a quality metric
\[ Q_i. \]Then the sensor manager can select or weight measurements based on
\[ \boxed{ Q_i = f( R_i, valid_i, geometry_i, signal_i, health_i ). } \]This produces more intelligent mode transitions.
4.1.8.121 Combined Suite Verification Metrics
Useful performance metrics include:
\[ \boxed{ \text{State RMSE} } \] \[ \boxed{ \text{3}\sigma\text{ Consistency} } \] \[ \boxed{ \text{Availability} } \] \[ \boxed{ \text{Sensor-Rejection Rate} } \] \[ \boxed{ \text{Fault Detection Time} } \] \[ \boxed{ \text{Recovery Time} } \] \[ \boxed{ \text{Mission Success Rate}. } \]These are more meaningful than evaluating individual sensors independently.
4.1.8.122 NEES and NIS for Fusion Validation
Estimator consistency can be evaluated using statistical measures.
The Normalized Estimation Error Squared is
\[ \boxed{ NEES = (\mathbf x-\hat{\mathbf x})^T P^{-1} (\mathbf x-\hat{\mathbf x}). } \]The Normalized Innovation Squared is
\[ \boxed{ NIS = \mathbf y^TS^{-1}\mathbf y. } \]These metrics help assess whether \(Q\) and \(R\) are consistent with actual navigation errors.
4.1.8.123 Sensor Suite Trade Study
A sensor-suite trade study should compare complete architectures rather than individual sensors.
For example:
\[ \boxed{ \text{Architecture A} = \text{Gyro + CSS + Magnetometer} } \]versus
\[ \boxed{ \text{Architecture B} = \text{Gyro + Star Tracker + Magnetometer} } \]versus
\[ \boxed{ \text{Architecture C} = \text{Dual Star Tracker + Gyro + CSS + Magnetometer}. } \]Trade criteria include accuracy, cost, mass, power, radiation tolerance, safe-mode capability, redundancy, FDIR and mission risk.
4.1.8.124 Sensor-Suite Design Philosophy
The correct question is not
\[ \boxed{ \text{Which sensor is the best?} } \]but
\[ \boxed{ \text{Which combination of sensors provides the required state knowledge, availability, integrity, and fault tolerance for every mission phase?} } \]This is a system-level GNC question.
4.1.8.125 Key Sensor Combinations
The most important architectures to remember are:
\[ \boxed{ \text{Gyro + Star Tracker} \rightarrow \text{Precision Attitude} } \] \[ \boxed{ \text{Gyro + Sun Sensor + Magnetometer} \rightarrow \text{Robust Coarse Attitude} } \] \[ \boxed{ \text{IMU + GNSS} \rightarrow \text{Integrated Position / Velocity Navigation} } \] \[ \boxed{ \text{Sun Sensor + Magnetometer} \rightarrow \text{Two-Vector Attitude Determination} } \] \[ \boxed{ \text{GNSS + Camera + LiDAR + IMU} \rightarrow \text{RPO Relative Navigation} } \] \[ \boxed{ \text{Star Tracker + Gyro + Sun Sensor + Magnetometer} \rightarrow \text{High-Accuracy + Safe-Mode Attitude Architecture}. } \]4.1.8.126 Final Engineering Perspective
The most important principle is
\[ \boxed{ \text{No Single Sensor Provides Everything}. } \]A robust spacecraft navigation system deliberately combines sensors with different strengths:
\[ \boxed{ \text{High Rate} + \text{Absolute Reference} + \text{Independent Physics} + \text{Redundancy} + \text{Availability} } \]to produce
\[ \boxed{ \text{Accurate} + \text{Observable} + \text{Fault-Tolerant} + \text{Continuous Navigation}. } \]The complete architecture is therefore
\[ \boxed{ \text{Sensors} \rightarrow \text{Calibration} \rightarrow \text{Frame Alignment} \rightarrow \text{Time Synchronization} \rightarrow \text{Validation} \rightarrow \text{Fusion} \rightarrow \text{State + Covariance} } \]followed by
\[ \boxed{ \text{Navigation State} \rightarrow \text{Guidance} \rightarrow \text{Control} \rightarrow \text{Mission Execution}. } \]For spacecraft autonomy, this must be expanded further:
\[ \boxed{ \text{Sensor Fusion} + \text{FDIR} + \text{Sensor Management} + \text{Mode Reconfiguration} \rightarrow \text{Robust Autonomous GNC}. } \]And for rendezvous and docking:
\[ \boxed{ \text{GNSS / Differential GNSS} \rightarrow \text{Camera + LiDAR Overlap} \rightarrow \text{Precision Relative Navigation} \rightarrow \text{Capture / Docking}. } \]So 4.1.8 Combined Sensor Suites becomes the bridge between the individual sensor models in 4.1.1–4.1.6, the common sensor-error theory in 4.1.7, and the formal filter measurement equations that will follow in 4.1.9 Measurement Models.