Relative Navigation Sensor Fusion for RPO

4.2.23 Relative Navigation Sensor Fusion for RPO

Relative navigation is the process of estimating the motion of one spacecraft with respect to another spacecraft or target object rather than estimating only its absolute orbit.

This is fundamental for general rendezvous and proximity operations (RPO), formation flying, inspection, servicing, docking, cooperative navigation, and close-proximity autonomous operations.

In absolute navigation, the main quantities of interest are usually

\[ \mathbf r, \qquad \mathbf v, \qquad \mathbf q, \]

representing spacecraft position, velocity, and attitude with respect to a global reference frame.

In relative navigation, the primary states become quantities such as

\[ \boxed{ \mathbf r_{rel}, \qquad \mathbf v_{rel}, \qquad \mathbf q_{rel}, \qquad \boldsymbol\omega_{rel} } \]

where

• \(\mathbf r_{rel}\) = relative position,
• \(\mathbf v_{rel}\) = relative velocity,
• \(\mathbf q_{rel}\) = relative attitude,
• \(\boldsymbol\omega_{rel}\) = relative angular velocity.

For close-range operations, the estimator may also determine the complete relative pose:

\[ \boxed{ \text{Relative Pose} = \text{Relative Position} + \text{Relative Orientation} } \]

Different sensors contribute different pieces of this information.

Typical relative-navigation sensors include:

• GNSS,
• inter-spacecraft ranging,
• optical cameras,
• LiDAR,
• IMUs,
• star trackers,
• radio-frequency ranging systems,
• bearing sensors,
• pose-estimation algorithms.

The central sensor-fusion idea is

\[ \boxed{ \text{Relative-Dynamics Propagation} + \text{Relative Sensor Measurements} \rightarrow \text{Continuous Relative-State Estimate} } \]

The estimator should exploit each sensor according to:

• what it measures,
• its uncertainty,
• its update rate,
• its geometry,
• its field of view,
• its range of operation,
• its observability,
• its current validity.

4.2.23.1 What Is Relative Navigation?

Suppose two spacecraft are present:

• a chaser spacecraft,
• a target spacecraft.

Let their inertial positions be

\[ \mathbf r_C \]

and

\[ \mathbf r_T. \]

A simple inertial relative position is

\[ \boxed{ \mathbf r_{rel} = \mathbf r_C-\mathbf r_T. } \]

Similarly,

\[ \boxed{ \mathbf v_{rel} = \mathbf v_C-\mathbf v_T. } \]

These equations define the basic relative state in a common inertial frame.

However, RPO guidance and sensing often use a target-centered orbital frame rather than the inertial frame.

4.2.23.2 Relative Position Depends on the Chosen Frame

A relative vector can be expressed in different frames.

For example:

\[ \mathbf r_{rel}^{I} \]

may represent relative position in an inertial frame, while

\[ \mathbf r_{rel}^{H} \]

may represent the same vector in a Hill or LVLH frame.

The transformation is

\[ \boxed{ \mathbf r_{rel}^{H} = \mathbf C_{HI} \mathbf r_{rel}^{I}. } \]

The same physical geometry can therefore have different numerical components depending on the chosen frame.

Frame consistency is essential throughout:

• dynamics,
• measurement models,
• guidance,
• covariance,
• plotting.

4.2.23.3 Hill or LVLH Frame

A commonly used target-centered orbital frame contains three axes approximately associated with:

• radial direction,
• along-track direction,
• cross-track direction.

The precise naming convention must be stated explicitly because different organizations use different axis labels.

Conceptually,

\[ \boxed{ \text{Target Orbit} \rightarrow \text{Local Relative-Navigation Frame}. } \]

This frame is useful because small relative motions around a reference orbit have intuitive orbital interpretations.

4.2.23.4 Relative State Vector

A simple translational relative state can be written

\[ \boxed{ \mathbf x_{rel} = \begin{bmatrix} \mathbf r_{rel}\\ \mathbf v_{rel} \end{bmatrix}. } \]

This gives six states.

For full relative navigation, the state may be expanded:

\[ \boxed{ \mathbf x_{rel} = \begin{bmatrix} \mathbf r_{rel}\\ \mathbf v_{rel}\\ \mathbf q_{rel}\\ \boldsymbol\omega_{rel} \end{bmatrix}. } \]

Additional states may include:

• sensor biases,
• camera alignment,
• LiDAR alignment,
• timing offsets,
• scale factors,
• target angular motion,
• target feature states.

4.2.23.5 Relative Dynamics

The estimator requires a model describing how the relative state evolves.

At a general level,

\[ \boxed{ \dot{\mathbf x}_{rel} = f( \mathbf x_{rel}, \mathbf u, t ) + \mathbf w. } \]

Here

• \(f(\cdot)\) is the relative-motion model,
• \(\mathbf u\) represents known control inputs,
• \(\mathbf w\) represents process uncertainty.

The fidelity of the dynamics model can vary with range and mission phase.

4.2.23.6 Linearized Relative Orbital Motion

For nearby spacecraft in a nearly circular reference orbit, a linearized model such as the Clohessy-Wiltshire/Hill equations may be used.

A common form is

\[ \boxed{ \ddot{x}-2n\dot{y}-3n^2x=u_x } \]

\[ \boxed{ \ddot{y}+2n\dot{x}=u_y } \]

\[ \boxed{ \ddot{z}+n^2z=u_z } \]

where

\[ n \]

is the reference orbital mean motion.

These equations describe the coupling inherent in relative orbital dynamics.

4.2.23.7 Why Relative Motion Is Coupled

Relative position does not generally evolve as simple Cartesian straight-line motion.

For example, radial displacement can influence along-track relative motion.

This means

\[ \boxed{ \text{Relative Orbital Motion} \neq \text{Independent Motion Along Three Axes}. } \]

The estimator must therefore propagate the proper relative dynamics rather than independently integrating each Cartesian component.

4.2.23.8 Nonlinear Relative Dynamics

For larger separations, eccentric orbits, perturbations, or high-accuracy requirements, nonlinear dynamics may be preferable.

The two absolute spacecraft states can be propagated independently:

\[ \ddot{\mathbf r}_C = \mathbf a_C \]

and

\[ \ddot{\mathbf r}_T = \mathbf a_T. \]

Then

\[ \boxed{ \ddot{\mathbf r}_{rel} = \mathbf a_C-\mathbf a_T. } \]

The acceleration difference may include:

• gravity,
• higher-order gravity,
• atmospheric drag,
• solar radiation pressure,
• third-body effects,
• thrust.

4.2.23.9 Process Noise in Relative Dynamics

Relative-motion models are never perfect.

Therefore process noise may represent uncertainty due to:

• unknown target manoeuvres,
• unmodeled thrust,
• environmental perturbations,
• actuator uncertainty,
• imperfect mass properties,
• dynamics approximations.

Conceptually,

\[ \boxed{ \mathbf Q_{rel} \rightarrow \text{Uncertainty in Relative-State Propagation}. } \]

The process-noise model may change with mission phase.

4.2.23.10 Cooperative and Non-Cooperative Targets

Relative-navigation architecture depends strongly on whether the target cooperates.

A cooperative target may provide:

• GNSS data,
• inter-spacecraft communication,
• known markers,
• transponders,
• attitude information.

A non-cooperative target may provide no navigation data.

Then relative navigation must rely on sensing such as:

• camera,
• LiDAR,
• radar,
• passive optical measurements.

Thus:

\[ \boxed{ \text{Target Cooperation} \rightarrow \text{Available Measurement Set}. } \]

4.2.23.11 Relative GNSS

If both spacecraft receive GNSS, their absolute navigation solutions can be differenced:

\[ \boxed{ \mathbf r_{rel} = \mathbf r_C^{GNSS} - \mathbf r_T^{GNSS} } \]

and

\[ \boxed{ \mathbf v_{rel} = \mathbf v_C^{GNSS} - \mathbf v_T^{GNSS}. } \]

This is conceptually straightforward for cooperative vehicles.

However, the quality of the relative solution depends on the error structure of both GNSS solutions.

4.2.23.12 Common-Mode GNSS Errors

Some GNSS errors may be correlated between nearby spacecraft.

Suppose

\[ \mathbf r_C^{GNSS} = \mathbf r_C + \mathbf e_C \]

and

\[ \mathbf r_T^{GNSS} = \mathbf r_T + \mathbf e_T. \]

Then

\[ \hat{\mathbf r}_{rel} = \mathbf r_{rel} + (\mathbf e_C-\mathbf e_T). \]

If part of the errors is common,

\[ \mathbf e_C\approx\mathbf e_T, \]

that portion may cancel when differenced.

This is one reason relative GNSS can outperform two completely independent absolute solutions in some configurations.

4.2.23.13 Inter-Satellite Navigation

Cooperative spacecraft may exchange navigation information through an inter-spacecraft communication link.

Each spacecraft can transmit quantities such as:

• position,
• velocity,
• attitude,
• clock information,
• covariance,
• GNSS observables.

The receiving spacecraft can then form relative states.

A generic architecture is

\[ \boxed{ \text{Target Navigation Data} + \text{Chaser Navigation Data} \rightarrow \text{Relative Navigation}. } \]

4.2.23.14 Covariance of Differenced Navigation States

If

\[ \mathbf r_{rel} = \mathbf r_C-\mathbf r_T, \]

then the relative covariance is not always simply

\[ \mathbf P_C+\mathbf P_T. \]

More generally,

\[ \boxed{ \mathbf P_{rel} = \mathbf P_C + \mathbf P_T - \mathbf P_{CT} - \mathbf P_{TC}. } \]

The cross-covariance terms matter when the two solutions share common information.

Ignoring correlation can produce an incorrect relative uncertainty.

4.2.23.15 Inter-Spacecraft Range

A direct ranging sensor measures the distance between spacecraft.

For relative position

\[ \mathbf r_{rel}, \]

the ideal range is

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

The measurement model is

\[ \boxed{ z_\rho = \|\mathbf r_{rel}\| + v_\rho. } \]

Range provides only one scalar quantity.

4.2.23.16 What Range Does Not Tell Us

A single range measurement constrains the target to the surface of a sphere centered on the observer.

Therefore:

\[ \boxed{ \text{Range Alone} \neq \text{Full Relative Position}. } \]

At one instant, range gives no direct information about direction.

Full three-dimensional state information must come from:

• dynamics over time,
• additional sensors,
• additional geometry.

4.2.23.17 Range Measurement Jacobian

For

\[ \rho = \sqrt{x^2+y^2+z^2}, \]

the derivative with respect to relative position is

\[ \boxed{ \mathbf H_\rho = \frac{\mathbf r_{rel}^T} {\|\mathbf r_{rel}\|}. } \]

This is the line-of-sight unit vector.

Thus range primarily constrains the component of relative position along the current line of sight.

4.2.23.18 Range Rate

Range rate measures how quickly separation changes.

The ideal relation is

\[ \boxed{ \dot{\rho} = \frac{ \mathbf r_{rel}^T \mathbf v_{rel} }{ \|\mathbf r_{rel}\| }. } \]

Equivalently,

\[ \boxed{ \dot{\rho} = \mathbf u_{LOS}^T \mathbf v_{rel} } \]

where

\[ \mathbf u_{LOS} = \frac{\mathbf r_{rel}} {\|\mathbf r_{rel}\|}. \]

Range rate therefore measures the relative-velocity component along the line of sight.

4.2.23.19 Range Rate Does Not Give Full Relative Velocity

Because

\[ \dot{\rho} = \mathbf u_{LOS}^T\mathbf v_{rel}, \]

range rate constrains only one projection of the velocity.

Tangential relative motion may not be directly observable from one instantaneous range-rate measurement.

Therefore:

\[ \boxed{ \text{Range + Range Rate} \neq \text{Instantaneous Full 6-DOF Translational State}. } \]

Dynamics and measurement geometry provide the remaining information.

4.2.23.20 Line-of-Sight Measurements

Optical sensors often measure the direction to the target rather than direct range.

The normalized line-of-sight vector is

\[ \boxed{ \mathbf u_{LOS} = \frac{ \mathbf r_{rel} }{ \|\mathbf r_{rel}\| }. } \]

A camera may encode this direction using:

• azimuth/elevation,
• pixel coordinates,
• unit-vector components.

4.2.23.21 Bearing-Only Navigation

If a camera supplies line-of-sight direction but no range, the navigation problem becomes bearing-only.

The measurement contains angular information but no direct scale.

Therefore,

\[ \boxed{ \text{Bearing} \rightarrow \text{Direction} } \]

but not

\[ \boxed{ \text{Bearing} \rightarrow \text{Instantaneous Range}. } \]

Range can become observable through dynamics and changing viewing geometry.

4.2.23.22 Why Motion Helps Bearing-Only Navigation

Suppose the observer moves relative to the target.

The line-of-sight direction changes over time:

\[ \mathbf u_{LOS}(t_1), \quad \mathbf u_{LOS}(t_2), \quad \mathbf u_{LOS}(t_3). \]

These changing directions provide triangulation-like information.

Thus:

\[ \boxed{ \text{Observer Motion} \rightarrow \text{Changing LOS Geometry} \rightarrow \text{Range Observability}. } \]

This is one example of manoeuvre-dependent observability.

4.2.23.23 Camera Measurements

A camera provides image-plane measurements.

For a pinhole model,

\[ \boxed{ u = f_x\frac{X_C}{Z_C} + c_x } \]

\[ \boxed{ v = f_y\frac{Y_C}{Z_C} + c_y } \]

where

\[ [X_C,Y_C,Z_C]^T \]

is the target point expressed in the camera frame.

The camera measurement is therefore fundamentally geometric.

4.2.23.24 Camera Intrinsic Parameters

The image model depends on camera intrinsics such as:

• focal length,
• principal point,
• pixel scaling,
• distortion.

These can be represented through an intrinsic matrix

\[ \boxed{ \mathbf K = \begin{bmatrix} f_x&0&c_x\\ 0&f_y&c_y\\ 0&0&1 \end{bmatrix}. } \]

Calibration error in \(\mathbf K\) can produce systematic navigation bias.

4.2.23.25 Camera Extrinsic Calibration

The camera is mounted somewhere on the spacecraft.

The target vector must therefore be transformed between:

• navigation frame,
• body frame,
• camera frame.

For example,

\[ \boxed{ \mathbf r^C = \mathbf C_{CB} \mathbf r^B. } \]

An incorrect camera-to-body alignment matrix produces systematic line-of-sight error.

4.2.23.26 Camera Lever Arm

The camera optical center may not coincide with the spacecraft navigation reference point.

Let

\[ \mathbf l_{BC}^{B} \]

be the camera lever arm.

Then the target-relative vector from the camera differs from that at the spacecraft center.

This becomes increasingly important when:

• separation becomes small,
• lever arm is large,
• angular rates are high,
• precision requirements are tight.

4.2.23.27 Feature-Based Optical Navigation

A camera may estimate relative pose from detected target features.

The processing chain may be

\[ \boxed{ \text{Image} \rightarrow \text{Feature Detection} \rightarrow \text{Feature Association} \rightarrow \text{Geometric Measurement} \rightarrow \text{Navigation Update}. } \]

Typical features can include:

• corners,
• fiducials,
• structural points,
• natural visual features.

4.2.23.28 Feature Association

A detected image point is useful only if the estimator knows what physical target feature it corresponds to.

Incorrect association can produce a large measurement error.

Thus:

\[ \boxed{ \text{Correct Feature Detection} \neq \text{Correct Feature Association}. } \]

Robust relative navigation therefore requires both.

4.2.23.29 Perspective-n-Point Pose Estimation

If known 3-D target points

\[ \mathbf P_i \]

are matched to their image projections

\[ \mathbf p_i, \]

the camera can solve a Perspective-n-Point problem.

The result estimates:

• relative translation,
• relative orientation.

Conceptually,

\[ \boxed{ \text{Known 3-D Features} + \text{2-D Image Measurements} \rightarrow \text{Relative Pose}. } \]

4.2.23.30 Relative Pose

Relative pose contains six physical degrees of freedom:

\[ \boxed{ \text{Pose} = \begin{bmatrix} \text{3-D Position}\\ \text{3-D Orientation} \end{bmatrix}. } \]

It is therefore richer than relative position alone.

Close-proximity operations often require pose because guidance may need to know not only where the target is, but how it is oriented.

4.2.23.31 Relative Quaternion

Let

\[ \mathbf q_C \]

be the chaser attitude and

\[ \mathbf q_T \]

the target attitude.

A relative quaternion may be defined as

\[ \boxed{ \mathbf q_{rel} = \mathbf q_C \otimes \mathbf q_T^{-1} } \]

or the opposite order depending on convention.

The convention must be documented explicitly.

4.2.23.32 Relative Angular Velocity

Relative angular velocity describes how the target and chaser orientations change with respect to one another.

The exact expression depends on the reference frames.

A conceptual representation is

\[ \boxed{ \boldsymbol\omega_{rel} = \boldsymbol\omega_C - \mathbf C_{CT}\boldsymbol\omega_T. } \]

All terms must be expressed in the same frame before subtraction.

4.2.23.33 Pose Estimation From Camera Measurements

A pose estimator may produce

\[ \hat{\mathbf r}_{rel} \]

and

\[ \hat{\mathbf q}_{rel} \]

directly from images.

These can then be treated as measurements in a recursive filter.

Alternatively, the filter may use lower-level image features directly.

These represent two different levels of integration.

4.2.23.34 High-Level Versus Low-Level Vision Fusion

A high-level architecture uses

\[ \boxed{ \text{Camera} \rightarrow \text{Pose Solver} \rightarrow (\mathbf r,\mathbf q) \rightarrow \text{Navigation Filter}. } \]

A lower-level architecture uses

\[ \boxed{ \text{Camera Pixels/Features} \rightarrow \text{Navigation Filter}. } \]

The lower-level approach preserves more raw measurement information but is more complex.

4.2.23.35 LiDAR Measurements

LiDAR measures distance using emitted and returned light.

Depending on the sensor, it may provide:

• single range,
• multiple beams,
• point clouds,
• depth images,
• target surface geometry.

Conceptually,

\[ \boxed{ \text{LiDAR} \rightarrow \text{Direct Geometric Range Information}. } \]

This complements camera bearing measurements.

4.2.23.36 Camera and LiDAR Complementarity

A camera provides rich angular and appearance information but may have weak direct range observability.

LiDAR provides strong range information but may have less visual texture information.

Therefore,

\[ \boxed{ \text{Camera} + \text{LiDAR} \rightarrow \text{Improved Relative Geometry}. } \]

This is a natural multi-sensor fusion combination.

4.2.23.37 LiDAR Point Cloud

A scanning LiDAR may produce points

\[ \mathbf p_i^L \]

in the LiDAR frame.

If a target model is available, the observed point cloud can be aligned with that model.

The alignment can estimate

\[ \boxed{ \mathbf r_{rel} \quad\text{and}\quad \mathbf q_{rel}. } \]

4.2.23.38 Point-Cloud Registration

Point-cloud registration seeks the rigid transform

\[ \mathbf R, \mathbf t \]

that aligns measured points with a target model.

Conceptually,

\[ \boxed{ \mathbf p_i^{meas} \approx \mathbf R\mathbf p_i^{model} + \mathbf t. } \]

Algorithms such as iterative closest point or other registration methods may be used.

The output can become a pose measurement for the navigation filter.

4.2.23.39 LiDAR Limitations

LiDAR performance can depend on:

• target reflectivity,
• range,
• incidence angle,
• field of view,
• surface geometry,
• sensor resolution,
• sunlight/background illumination,
• scan pattern.

Therefore LiDAR measurement covariance should not necessarily be constant over all ranges and geometries.

4.2.23.40 Range-Dependent Sensor Performance

Many relative-navigation sensors change quality with distance.

For example:

\[ \boxed{ \mathbf R = \mathbf R(\rho,\text{geometry},\text{quality}) } \]

rather than

\[ \mathbf R=\text{constant}. \]

A camera may have excellent angular resolution at long range but weak range information.

A LiDAR may become highly useful at closer range.

Sensor-fusion architecture should reflect these changing strengths.

4.2.23.41 IMU Role in Relative Navigation

An IMU primarily measures the chaser spacecraft's own motion.

It does not directly measure target relative position.

However, it can propagate:

• attitude,
• angular rate,
• translational acceleration.

Thus it supports short-term relative-state propagation between external relative-navigation measurements.

4.2.23.42 Why IMU Alone Cannot Determine Relative Position

An IMU tells the chaser how it is moving dynamically.

It does not inherently tell the chaser where the target is.

Therefore,

\[ \boxed{ \text{IMU Alone} \not\rightarrow \text{Target Relative Position}. } \]

An external reference such as camera, LiDAR, range, GNSS, or radio measurement is required to anchor the relative state.

4.2.23.43 Relative-Navigation Error State

A general translational error state can be written

\[ \boxed{ \delta\mathbf x = \begin{bmatrix} \delta\mathbf r_{rel}\\ \delta\mathbf v_{rel} \end{bmatrix}. } \]

A more complete state may include

\[ \boxed{ \delta\mathbf x = \begin{bmatrix} \delta\mathbf r_{rel}\\ \delta\mathbf v_{rel}\\ \delta\boldsymbol\theta_{rel}\\ \delta\mathbf b_a\\ \delta\mathbf b_g \end{bmatrix}. } \]

Calibration and timing states can be added if observable.

4.2.23.44 Relative EKF Architecture

A typical EKF sequence is

\[ \boxed{ \text{Propagate Relative State} \rightarrow \text{Propagate Covariance} \rightarrow \text{Predict Sensor Measurement} \rightarrow \text{Compute Innovation} \rightarrow \text{Update State} } \]

This is the same Bayesian recursive structure used elsewhere in navigation.

What changes are:

• the state,
• the dynamics,
• the measurement model.

4.2.23.45 Measurement Function

For a sensor measurement,

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

Different sensors use different \(h(\cdot)\).

Examples include:

\[ h_{range}(\mathbf x) = \|\mathbf r_{rel}\| \]

\[ h_{LOS}(\mathbf x) = \frac{\mathbf r_{rel}} {\|\mathbf r_{rel}\|} \]

\[ h_{camera}(\mathbf x) = \pi(\mathbf r_{rel},\mathbf q_{rel}) \]

where \(\pi\) represents perspective projection.

4.2.23.46 Innovation

For every measurement,

\[ \boxed{ \mathbf r_k = \mathbf z_k - h(\hat{\mathbf x}_k^-). } \]

The innovation represents disagreement between:

• the sensor,
• the predicted relative state.

It is one of the most important diagnostic quantities in a relative-navigation estimator.

4.2.23.47 Innovation Covariance

The expected uncertainty of the innovation is

\[ \boxed{ \mathbf S_k = \mathbf H_k \mathbf P_k^- \mathbf H_k^T + \mathbf R_k. } \]

Thus a residual should never be interpreted only by its raw magnitude.

The same one-meter residual can mean very different things when expected uncertainty is:

\[ 0.01~\text{m} \]

versus

\[ 10~\text{m}. \]

4.2.23.48 Innovation Gating

Normalized Innovation Squared is

\[ \boxed{ \mathrm{NIS} = \mathbf r^T \mathbf S^{-1} \mathbf r. } \]

This can be used to reject abnormal:

• camera features,
• LiDAR poses,
• GNSS states,
• ranges,
• range rates,
• line-of-sight measurements.

Measurement gating is essential because one false relative-navigation measurement can produce a large navigation correction.

4.2.23.49 Sensor-Specific Gating

Different sensors may require different gating strategies.

For example:

• pixel reprojection error for camera features,
• point-cloud fit residual for LiDAR,
• NIS for filter innovations,
• quality indicators for GNSS,
• signal-strength or lock checks for ranging.

Therefore measurement validation can contain both

\[ \boxed{ \text{Sensor-Level Checks} } \]

and

\[ \boxed{ \text{Estimator-Level Statistical Checks}. } \]

4.2.23.50 Outliers in Camera Navigation

Camera outliers can arise from:

• false feature detections,
• incorrect feature association,
• background objects,
• glare,
• target occlusion,
• motion blur.

One false feature should not necessarily invalidate the entire camera.

Robust algorithms may reject individual feature measurements before pose estimation or filtering.

4.2.23.51 LiDAR Outliers

LiDAR outliers may arise from:

• multipath-like reflections,
• spurious returns,
• low reflectivity,
• edge effects,
• background objects,
• partial target visibility.

Robust point-cloud processing should prevent such returns from dominating pose estimation.

4.2.23.52 RANSAC-Type Robust Estimation

For vision measurements containing many candidate features, robust consensus methods can be used to identify a geometrically consistent subset.

Conceptually,

\[ \boxed{ \text{Candidate Measurements} \rightarrow \text{Find Consistent Subset} \rightarrow \text{Estimate Geometry}. } \]

This preprocessing improves the quality of measurements entering the navigation filter.

4.2.23.53 Measurement Dropouts

Relative-navigation sensors may temporarily become unavailable.

Causes include:

• target outside field of view,
• eclipse,
• optical blinding,
• communication loss,
• LiDAR range limits,
• GNSS loss,
• target occlusion.

During dropout,

\[ \boxed{ \text{Prediction Continues} } \]

but uncertainty generally increases.

4.2.23.54 Covariance During Dropout

When measurements disappear,

\[ \mathbf P \]

should reflect the loss of information.

Therefore,

\[ \boxed{ \text{Sensor Dropout} \rightarrow \text{Covariance Growth}. } \]

If covariance remains artificially small while measurements are absent, the estimator is overconfident.

4.2.23.55 Sensor Reacquisition

When a sensor returns, the predicted relative state may differ substantially from the measurement.

The estimator should check:

• measurement validity,
• innovation magnitude,
• field-of-view consistency,
• geometry,
• covariance.

Large residuals may require staged recovery rather than one aggressive correction.

4.2.23.56 Time Synchronization

Relative motion can make timing errors particularly significant.

Suppose a range measurement corresponds to time

\[ t_m \]

but is applied at

\[ t_k. \]

With timing error

\[ \Delta t=t_k-t_m, \]

an approximate position discrepancy is

\[ \boxed{ \delta\mathbf r \approx \mathbf v_{rel}\Delta t. } \]

Thus faster closing motion increases sensitivity to latency.

4.2.23.57 Camera Latency

Optical processing can include:

• image exposure,
• image transfer,
• feature extraction,
• pose estimation.

The measurement may therefore be significantly older than its arrival time.

The relevant timestamp is the image exposure epoch.

Using packet-arrival time can create a systematic relative-state error during motion.

4.2.23.58 LiDAR Latency

Scanning LiDAR presents another timing challenge.

A point cloud may be acquired over a finite scan interval rather than at one exact instant.

If relative motion is significant during the scan,

\[ \boxed{ \text{One Point Cloud} \neq \text{One Perfect Instantaneous Geometry}. } \]

Motion compensation may be required for high-accuracy estimation.

4.2.23.59 Out-of-Sequence Measurements

A delayed relative measurement may correspond to a state in the past.

A consistent architecture may:

1. store historical states,
2. return to the measurement time,
3. apply the measurement,
4. propagate the corrected state to the present.

This is especially important when measurement latency is comparable to the dynamics time scale.

4.2.23.60 Multi-Rate Relative Sensor Fusion

Relative-navigation sensors operate at different rates.

For example:

• IMU: high rate,
• camera: intermediate rate,
• LiDAR: lower or variable rate,
• GNSS: another rate,
• ranging system: independent rate.

The filter therefore naturally becomes event driven:

\[ \boxed{ \text{Propagate Continuously} + \text{Update Whenever a Valid Measurement Arrives}. } \]

4.2.23.61 Sequential Sensor Updates

Suppose camera and range measurements arrive at slightly different times.

They should not necessarily be forced into one combined update.

Instead:

\[ \boxed{ t_1:\text{Camera Update} } \]

\[ \boxed{ t_2:\text{Range Update}. } \]

Sequential processing preserves actual measurement timing.

4.2.23.62 Simultaneous Measurement Stacking

If independent sensors genuinely correspond to the same epoch, measurements can be stacked:

\[ \boxed{ \mathbf z = \begin{bmatrix} \mathbf z_{cam}\\ \mathbf z_{range}\\ \mathbf z_{lidar} \end{bmatrix}. } \]

Then

\[ \mathbf R \]

must represent their measurement covariance, including cross-correlations if present.

4.2.23.63 Sensor Correlation

Two sensors may share common errors.

For example:

• camera and LiDAR may share body alignment uncertainty,
• two GNSS solutions may share common GNSS errors,
• camera pose and feature measurements may originate from the same image.

Treating correlated information as independent can produce overconfidence.

4.2.23.64 Measurement Covariance

Each sensor has its own covariance:

\[ \mathbf R_{GNSS}, \quad \mathbf R_{cam}, \quad \mathbf R_{LiDAR}, \quad R_{\rho}, \quad R_{\dot{\rho}}. \]

These should reflect actual current measurement quality.

In many RPO sensors,

\[ \boxed{ \mathbf R = \mathbf R( \rho, \text{geometry}, \text{illumination}, \text{quality} ) } \]

is more realistic than a constant matrix.

4.2.23.65 Range-Dependent Camera Accuracy

For a camera with approximately fixed angular resolution,

\[ \sigma_\theta \]

may remain relatively similar while equivalent lateral-position uncertainty increases with range.

Approximately,

\[ \boxed{ \sigma_{cross} \approx \rho\sigma_\theta. } \]

Thus a small angular error can correspond to a large cross-track position error at long distance.

4.2.23.66 Why Range Helps Camera Navigation

A camera may provide highly accurate direction:

\[ \mathbf u_{LOS}. \]

A range sensor provides

\[ \rho. \]

Together,

\[ \boxed{ \mathbf r_{rel} = \rho\mathbf u_{LOS}. } \]

Thus combining direction and range can directly reconstruct relative position.

4.2.23.67 Sensor Geometry

Sensor geometry strongly affects estimation quality.

For example:

• range measures radial direction strongly,
• LOS measures angular directions strongly,
• multiple bearings from changing viewpoints improve scale,
• multiple range directions improve three-dimensional position.

This is why covariance often becomes anisotropic.

4.2.23.68 Anisotropic Relative Uncertainty

Relative-position covariance

\[ \mathbf P_r \]

may contain very different uncertainty levels along different directions.

For example,

\[ \sigma_x \neq \sigma_y \neq \sigma_z. \]

A single scalar position accuracy can therefore hide important geometry.

The complete covariance ellipsoid is more informative.

4.2.23.69 Relative-Position Error Ellipsoid

If

\[ \mathbf P_r \]

has eigenvalues

\[ \lambda_1,\lambda_2,\lambda_3, \]

then principal uncertainty lengths scale as

\[ \boxed{ \sqrt{\lambda_1}, \quad \sqrt{\lambda_2}, \quad \sqrt{\lambda_3}. } \]

The eigenvectors identify the directions of greatest and least uncertainty.

4.2.23.70 Observability in Relative Navigation

Observability asks whether the unknown relative states can be reconstructed from:

• dynamics,
• measurements,
• sensor geometry,
• motion over time.

A state may be mathematically present in the filter but remain weakly observable.

Therefore:

\[ \boxed{ \text{State Included} \neq \text{State Observable}. } \]

4.2.23.71 Range-Only Observability

Range-only navigation can become observable over time when orbital dynamics cause the range geometry to change.

However, observability may be weak for certain trajectories.

Thus:

\[ \boxed{ \text{Range History} + \text{Relative Dynamics} \rightarrow \text{Potential 3-D State Information}. } \]

The quality depends strongly on trajectory geometry.

4.2.23.72 Bearing-Only Observability

Bearing-only relative navigation is also highly geometry dependent.

If line-of-sight direction changes very little,

\[ \dot{\mathbf u}_{LOS} \approx0, \]

range may remain weakly observable.

A manoeuvre that changes the viewing geometry can significantly improve observability.

4.2.23.73 Manoeuvre-Dependent Observability

A deliberate manoeuvre may generate useful geometric diversity.

Conceptually,

\[ \boxed{ \text{Manoeuvre} \rightarrow \text{Changing Measurement Sensitivity} \rightarrow \text{Improved Observability}. } \]

This concept applies to:

• range-only estimation,
• bearing-only estimation,
• calibration estimation,
• timing estimation.

4.2.23.74 Relative Attitude Observability

Relative attitude may be estimated from:

• target features,
• target geometry,
• fiducial markers,
• target attitude broadcasts,
• multiple vectors.

If the visible target geometry is symmetric, some orientations may be ambiguous.

Therefore target shape itself can influence relative-attitude observability.

4.2.23.75 Symmetry Ambiguity

Suppose the target looks identical after a certain rotation.

Then optical measurements may not distinguish the two orientations.

This produces a multi-hypothesis or ambiguous pose problem.

A Gaussian single-mode estimator may not represent this ambiguity well.

Additional information or temporal tracking may be needed.

4.2.23.76 Target Model Knowledge

Pose estimation often assumes knowledge of the target:

• dimensions,
• feature coordinates,
• CAD geometry,
• fiducial locations.

Model error can become navigation error.

Therefore,

\[ \boxed{ \text{Target Geometry Error} \rightarrow \text{Pose Measurement Bias}. } \]

4.2.23.77 Target Motion

A target may be:

• attitude stabilized,
• slowly rotating,
• tumbling,
• manoeuvring.

The relative-navigation dynamics should reflect the expected target behaviour.

For tumbling targets, relative attitude and angular velocity may need explicit estimation.

4.2.23.78 Tumbling-Target State

A state may include

\[ \boxed{ \mathbf x = [ \mathbf r_{rel}, \mathbf v_{rel}, \mathbf q_T, \boldsymbol\omega_T ]^T. } \]

This allows the estimator to predict future target orientation between visual measurements.

However, it increases model complexity.

4.2.23.79 Target Angular Dynamics

A rigid-body target may approximately satisfy

\[ \boxed{ \mathbf J_T \dot{\boldsymbol\omega}_T + \boldsymbol\omega_T \times (\mathbf J_T\boldsymbol\omega_T) = \mathbf T_T. } \]

For a passive object,

\[ \mathbf T_T \]

may be small but not necessarily zero.

If target inertia is uncertain, process noise may represent the mismatch.

4.2.23.80 Relative-Attitude Error Representation

As with spacecraft attitude estimation, relative quaternion error should normally be treated multiplicatively.

Define

\[ \boxed{ \delta\mathbf q_{rel} = \mathbf q_{rel,true} \otimes \hat{\mathbf q}_{rel}^{-1}. } \]

For small error,

\[ \delta\mathbf q_{rel} \approx \begin{bmatrix} 1\\ \frac12\delta\boldsymbol\theta_{rel} \end{bmatrix}. \]

This gives a three-dimensional relative-attitude error state.

4.2.23.81 Pose Error State

A close-range pose error state may therefore be

\[ \boxed{ \delta\mathbf x_{pose} = \begin{bmatrix} \delta\mathbf r_{rel}\\ \delta\boldsymbol\theta_{rel} \end{bmatrix}. } \]

For dynamic tracking, relative velocity and angular-rate errors may also be included.

4.2.23.82 Relative Navigation and EKF

An EKF is commonly suitable when:

• the state remains approximately Gaussian,
• nonlinearities are moderate,
• initial uncertainty is not excessively large.

Camera and range models are nonlinear, but can be linearized around the current estimate.

The filter then uses

\[ \mathbf H_k = \frac{\partial h}{\partial\mathbf x} \bigg|_{\hat{\mathbf x}_k^-}. \]

4.2.23.83 When an UKF May Be Useful

An Unscented Kalman Filter can be useful when nonlinear measurement transformations are strong.

Examples include:

• bearing measurements,
• nonlinear pose models,
• large relative uncertainty.

The UKF propagates sigma points instead of relying only on first-order Jacobians.

It does not eliminate poor observability or incorrect measurement models, but it can better approximate nonlinear uncertainty transformation.

4.2.23.84 Particle Filters for Multi-Modal Relative Navigation

If the posterior is strongly non-Gaussian or multi-modal, a particle filter may be useful.

Examples include:

• ambiguous optical pose,
• uncertain feature association,
• bearing-only initialization,
• multiple geometric hypotheses.

A Gaussian EKF cannot naturally represent several separated hypotheses.

4.2.23.85 Relative-State Initialization

The estimator requires an initial estimate

\[ \hat{\mathbf x}_{rel,0} \]

and covariance

\[ \mathbf P_{rel,0}. \]

Initialization may come from:

• GNSS differencing,
• ground-provided ephemerides,
• coarse ranging,
• camera detection,
• LiDAR detection,
• previous navigation history.

The covariance should represent the actual uncertainty of that source.

4.2.23.86 Bearing-Only Initialization

Bearing-only initialization is difficult because range may be unknown.

The initial state may therefore have:

• relatively accurate LOS direction,
• very large range uncertainty.

This produces a highly elongated uncertainty region.

Using an isotropic covariance would misrepresent the actual information.

4.2.23.87 Range-Only Initialization

Range-only initialization gives a known radial distance but weak direction information.

Thus the uncertainty geometry differs fundamentally from bearing-only initialization.

This reinforces a general principle:

\[ \boxed{ \text{Covariance Should Represent Sensor Geometry}. } \]

4.2.23.88 Sensor Handover Across Range

Different sensors may dominate at different separation ranges.

A general architecture may transition between:

• long-range GNSS or inter-spacecraft navigation,
• intermediate optical navigation,
• closer-range LiDAR or detailed vision.

This is not necessarily a hard switch.

Sensors can overlap so that one measurement source is validated before another is removed.

4.2.23.89 Why Overlapping Sensor Regions Are Useful

If sensor A becomes unavailable exactly when sensor B becomes active, there is no opportunity to cross-check them.

An overlap region allows:

\[ \boxed{ \text{Sensor A} + \text{Sensor B} \rightarrow \text{Consistency Check}. } \]

This supports:

• calibration,
• fault detection,
• smooth transition,
• confidence assessment.

4.2.23.90 Sensor-Handover Transients

When a new sensor becomes active, its:

• bias,
• alignment,
• covariance,
• latency,

may differ from the previous sensor.

The estimator should avoid a discontinuous state jump simply because the measurement source changed.

Handover should be validated using innovations and covariance consistency.

4.2.23.91 Long-Range Relative Navigation

At longer range, practical information may come from:

• relative GNSS,
• absolute GNSS differencing,
• RF ranging,
• bearing measurements,
• inter-spacecraft communication.

The target may occupy only a few camera pixels, making detailed pose estimation impossible.

Thus long-range navigation may focus primarily on

\[ \mathbf r_{rel}, \qquad \mathbf v_{rel}. \]

4.2.23.92 Intermediate-Range Navigation

As distance decreases, optical measurements become more informative.

Camera line of sight can provide increasingly precise angular information.

Depending on target size and camera resolution, target geometry may begin to support:

• range estimation,
• relative attitude,
• pose estimation.

4.2.23.93 Close-Range Navigation

At close range, the estimator may use:

• detailed camera features,
• LiDAR point clouds,
• range,
• relative pose.

The required state may expand from simple relative translation to full 6-DOF relative pose.

Measurement models also become more sensitive to:

• sensor alignment,
• lever arms,
• target geometry.

4.2.23.94 Field of View

Optical sensors operate only when the target lies inside their field of view.

A measurement validity condition may involve

\[ \boxed{ |\alpha| < \alpha_{FOV} } \]

and

\[ \boxed{ |\beta| < \beta_{FOV}. } \]

Navigation and pointing are therefore coupled: losing pointing can cause loss of navigation measurements.

4.2.23.95 Target Visibility

Target visibility can be affected by:

• spacecraft attitude,
• lighting,
• eclipse,
• Sun angle,
• occlusion,
• target rotation,
• sensor pointing.

Therefore optical measurement availability is inherently state dependent.

4.2.23.96 Lighting Conditions

Passive cameras depend on illumination.

Possible challenges include:

• low illumination,
• high contrast,
• glare,
• Sun intrusion,
• Earth background,
• shadow transitions.

Measurement covariance or validity may therefore depend on image-quality metrics.

4.2.23.97 Motion Blur

During high angular or translational motion, image features may blur.

Approximate image displacement during exposure is related to

\[ \boxed{ \Delta p \propto \dot{p}T_{exp}. } \]

Long exposure improves brightness but increases blur.

This creates a tradeoff between:

• sensitivity,
• motion robustness.

4.2.23.98 LiDAR Field of Regard

LiDAR also has geometric limitations.

The target must remain within:

• angular scan limits,
• minimum range,
• maximum range.

Close-range navigation should therefore consider sensor geometry together with guidance trajectory.

4.2.23.99 Sensor Saturation and Minimum Range

Some range sensors become unreliable below a minimum distance.

Therefore,

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

may invalidate the sensor.

A sensor that works well at intermediate range may not necessarily work at extremely close range.

4.2.23.100 Navigation Accuracy Versus Range

Relative-navigation requirements may become more stringent as separation decreases.

For example, the acceptable relative-position uncertainty at long range may be much larger than at close range.

Thus performance requirements may be phase dependent:

\[ \boxed{ \sigma_r < \sigma_{r,\mathrm{req}}(\rho). } \]

4.2.23.101 Relative Position Error

Define

\[ \boxed{ \delta\mathbf r_{rel} = \mathbf r_{rel,true} - \hat{\mathbf r}_{rel}. } \]

A scalar error is

\[ \boxed{ e_r = \| \delta\mathbf r_{rel} \|. } \]

It is also important to examine components in the operational relative frame.

4.2.23.102 Relative Velocity Error

Similarly,

\[ \boxed{ \delta\mathbf v_{rel} = \mathbf v_{rel,true} - \hat{\mathbf v}_{rel}. } \]

and

\[ \boxed{ e_v = \| \delta\mathbf v_{rel} \|. } \]

Relative velocity is especially important because it determines closing behaviour and future separation.

4.2.23.103 Relative Attitude Error

Using the relative quaternion error

\[ \delta\mathbf q, \]

the principal attitude error can be calculated as

\[ \boxed{ \delta\theta = 2\cos^{-1} (|\delta q_0|). } \]

This provides a coordinate-independent scalar measure of relative orientation error.

4.2.23.104 Pose Error

Pose performance should normally be evaluated separately for translation and rotation:

\[ \boxed{ e_{pose} \rightarrow \{ e_r, e_\theta \}. } \]

Combining meters and degrees into one arbitrary scalar can hide important behaviour unless a physically meaningful weighting is defined.

4.2.23.105 Relative Navigation Covariance

Relative navigation should publish covariance together with the state.

For example:

\[ \mathbf P_r, \quad \mathbf P_v, \quad \mathbf P_\theta. \]

The covariance communicates not only the best estimate, but how much confidence the estimator has in that estimate.

4.2.23.106 \(3\sigma\) Relative Error Envelopes

For state component \(i\),

\[ \boxed{ \pm3\sqrt{P_{ii}} } \]

provides a useful covariance envelope.

In simulation, actual truth error can be plotted against these bounds.

A consistent estimator should show statistically plausible coverage over many runs.

4.2.23.107 Relative Navigation NEES

For truth error

\[ \delta\mathbf x \]

and covariance

\[ \mathbf P, \]

\[ \boxed{ \mathrm{NEES} = \delta\mathbf x^T \mathbf P^{-1} \delta\mathbf x. } \]

This evaluates whether the relative-state covariance is credible.

Good RMSE alone is not sufficient.

4.2.23.108 Sensor NIS

For each sensor,

\[ \boxed{ \mathrm{NIS}_i = \mathbf r_i^T \mathbf S_i^{-1} \mathbf r_i. } \]

Separate NIS monitoring may be maintained for:

• GNSS,
• range,
• camera,
• LiDAR,
• other measurements.

This helps diagnose which measurement source is inconsistent.

4.2.23.109 Innovation Whiteness

A correctly modeled innovation should ideally have little predictable temporal structure.

If camera residuals repeatedly oscillate or drift, possible causes include:

• timing errors,
• misalignment,
• target-model errors,
• unmodeled dynamics.

Thus innovation autocorrelation can provide useful diagnostic information.

4.2.23.110 Relative-Navigation Integrity

Accuracy asks:

How close is the estimated relative state to truth?

Integrity asks:

Can the system identify when the relative state should not be trusted?

Therefore,

\[ \boxed{ \text{Good Relative Navigation} = \text{Accuracy} + \text{Consistency} + \text{Fault Awareness}. } \]

4.2.23.111 Relative Navigation Validity

The estimator may publish

\[ \boxed{ \texttt{RELNAV\_VALID} \in \{0,1\}. } \]

Validity can depend on:

• covariance,
• sensor availability,
• innovation statistics,
• observability,
• numerical health,
• time since last valid update.

A filter can continue running internally while its relative solution is declared invalid.

4.2.23.112 Sensor Validity Flags

Individual sensors may also have flags:

\[ \texttt{GNSS\_VALID}, \]

\[ \texttt{CAM\_VALID}, \]

\[ \texttt{LIDAR\_VALID}, \]

\[ \texttt{RANGE\_VALID}. \]

This supports graceful degradation when one sensor fails.

4.2.23.113 Degraded Relative Navigation

Suppose the LiDAR becomes unavailable but the camera remains valid.

The estimator may continue with larger range uncertainty.

Similarly, if the camera is lost but range remains valid, direction uncertainty may grow.

Therefore degraded navigation should reflect the actual information lost, not simply declare all relative navigation unavailable immediately.

4.2.23.114 Sensor Fault Isolation

A sensor may repeatedly fail innovation tests.

If the behaviour persists, the system may isolate that sensor.

A conceptual chain is

\[ \boxed{ \text{Abnormal Residual} \rightarrow \text{Persistent Evidence} \rightarrow \text{Sensor Isolation} \rightarrow \text{Degraded Fusion}. } \]

This connects relative navigation with FDIR.

4.2.23.115 Redundant Sensors

Redundant sensors can improve:

• availability,
• fault tolerance,
• geometry.

Examples include:

• multiple cameras,
• multiple range sensors,
• multiple GNSS antennas.

But redundancy is most valuable when failure modes are sufficiently independent.

4.2.23.116 Redundant Camera Geometry

Two cameras with different viewing directions can improve:

• field-of-view coverage,
• triangulation,
• fault detection.

Stereo geometry can also provide direct depth information.

This is another example of sensor geometry creating observability.

4.2.23.117 Stereo Vision

For a stereo baseline \(b\), focal length \(f\), and disparity \(d\),

\[ \boxed{ Z \approx \frac{fb}{d}. } \]

Thus depth can be reconstructed geometrically.

Depth uncertainty grows rapidly as disparity becomes small, which commonly occurs at long range.

4.2.23.118 Target-Feature Geometry

Feature placement affects pose-estimation quality.

Features clustered in a small image region provide weaker pose geometry than features spread across the visible target.

Similarly, nearly coplanar or symmetric feature arrangements can weaken some pose directions.

Thus feature geometry should be treated as part of measurement quality.

4.2.23.119 Initialization From Detection

Before tracking can begin, the target must first be detected.

A general pipeline is

\[ \boxed{ \text{Search} \rightarrow \text{Detect Target} \rightarrow \text{Initialize Relative State} \rightarrow \text{Begin Recursive Tracking}. } \]

Detection and tracking are different estimation problems.

4.2.23.120 Lost-Track Recovery

If optical tracking is lost, the filter may continue propagating the target state.

When the target is detected again, the search region can be predicted using the propagated covariance.

Thus covariance supports not only estimation but also sensor tasking.

4.2.23.121 Covariance-Based Search Region

If predicted image location is

\[ \hat{\mathbf p} \]

with image covariance

\[ \mathbf P_p, \]

the camera processing algorithm can search a bounded uncertainty region around \(\hat{\mathbf p}\).

This is more efficient than searching the entire image.

4.2.23.122 Sensor Fusion and Target Tracking

Navigation and target tracking should not necessarily be treated as independent software functions.

The navigation estimate predicts:

• target image position,
• expected range,
• expected target orientation.

These predictions can aid sensor processing.

Sensor processing then returns better measurements to navigation.

This creates a feedback loop between perception and estimation.

4.2.23.123 Relative-Navigation Monte Carlo Testing

Monte Carlo testing should vary:

• initial relative position,
• initial relative velocity,
• attitude error,
• sensor noise,
• camera alignment,
• LiDAR alignment,
• timing offset,
• measurement dropouts,
• target-motion uncertainty,
• feature-detection error,
• GNSS uncertainty,
• ranging noise.

This reveals statistical performance across realistic conditions.

4.2.23.124 Monte Carlo Performance Measures

For run \(j\), record

\[ \delta\mathbf r_{rel}^{(j)}(t), \]

\[ \delta\mathbf v_{rel}^{(j)}(t), \]

\[ \delta\boldsymbol\theta_{rel}^{(j)}(t). \]

Then compute quantities such as

\[ \boxed{ \mathrm{RMSE}, \quad P_{95}, \quad P_{99}, \quad e_{\max}. } \]

Consistency metrics should be evaluated as well.

4.2.23.125 Phase-Dependent Performance Assessment

RPO relative-navigation performance should generally be assessed by operational phase or separation range.

For example:

\[ \boxed{ \text{Long Range} \neq \text{Intermediate Range} \neq \text{Close Range}. } \]

Different phases can use different sensors, dynamics, and accuracy requirements.

One mission-wide RMSE can hide poor performance during a critical phase.

4.2.23.126 Sensor-Handover Monte Carlo Testing

Monte Carlo cases should include transitions such as:

• GNSS to optical navigation,
• camera to camera + LiDAR,
• sensor dropout and recovery.

Metrics should include:

• state discontinuity,
• covariance consistency,
• maximum transient error,
• recovery time.

4.2.23.127 Measurement Latency Testing

Artificial latency should be introduced independently for:

• camera,
• LiDAR,
• GNSS,
• range sensors.

The navigation error can then be evaluated as a function of

\[ \Delta t. \]

This validates timestamp handling rather than only sensor accuracy.

4.2.23.128 Alignment-Error Testing

Inject camera or LiDAR alignment error:

\[ \delta\boldsymbol\alpha. \]

Then examine:

• innovation mean,
• relative-position bias,
• relative-attitude bias,
• filter consistency.

Persistent structured residuals often reveal alignment errors.

4.2.23.129 Target-Model Error Testing

If vision or LiDAR uses a target geometry model, perturb:

• dimensions,
• feature locations,
• surface geometry.

Then evaluate how these errors influence pose estimates.

This helps separate sensor error from model error.

4.2.23.130 Sensor Dropout Testing

For each sensor:

1. establish nominal fusion,
2. remove the sensor,
3. propagate using remaining information,
4. observe covariance growth,
5. restore the sensor,
6. evaluate reacquisition.

This tests graceful degradation and recovery.

4.2.23.131 Outlier Injection Testing

Inject isolated bad measurements such as:

• false camera feature,
• erroneous range,
• incorrect LiDAR pose,
• GNSS position jump.

Evaluate whether the measurement is:

• detected,
• rejected,
• prevented from corrupting the state.

4.2.23.132 Persistent Bias Testing

Persistent bias is more difficult than a single outlier.

For example,

\[ \boxed{ z_\rho = \rho+b_\rho+v_\rho. } \]

If \(b_\rho\) is small, each measurement may still pass an innovation gate.

Long-term residual monitoring or redundancy may therefore be necessary.

4.2.23.133 Sensor Failure Versus Geometry Loss

A measurement can become unusable even when the sensor itself is healthy.

Examples include:

• camera loses target outside field of view,
• LiDAR target outside range,
• GNSS geometry becomes poor.

Therefore:

\[ \boxed{ \text{Measurement Unavailable} \neq \text{Sensor Hardware Failure}. } \]

This distinction matters for FDIR and mode logic.

4.2.23.134 Relative Navigation Numerical Health

The filter should monitor:

\[ \mathbf P=\mathbf P^T \]

and

\[ \lambda_i(\mathbf P)\ge0. \]

For quaternion states,

\[ \|\mathbf q\|\approx1. \]

The implementation should also detect:

• NaN,
• Inf,
• invalid matrix factorization,
• impossible geometry.

Numerical health is part of navigation health.

4.2.23.135 Joseph Covariance Update

A robust covariance correction is

\[ \boxed{ \mathbf P^+ = (\mathbf I-\mathbf K\mathbf H) \mathbf P^- (\mathbf I-\mathbf K\mathbf H)^T + \mathbf K\mathbf R\mathbf K^T. } \]

This is particularly useful when measurement models and state dimensions become large.

4.2.23.136 Relative-Navigation Output

A relative-navigation system may publish

\[ \boxed{ \hat{\mathbf r}_{rel}, \quad \hat{\mathbf v}_{rel}, \quad \hat{\mathbf q}_{rel}, \quad \hat{\boldsymbol\omega}_{rel}, \quad \mathbf P. } \]

It may also publish:

• sensor validity,
• navigation validity,
• measurement quality,
• estimator health.

4.2.23.137 Relative State for Guidance

Guidance uses the estimated relative state:

\[ \hat{\mathbf r}_{rel}, \qquad \hat{\mathbf v}_{rel}. \]

Therefore:

\[ \boxed{ \text{Relative-Navigation Error} \rightarrow \text{Guidance Input Error}. } \]

The guidance system never sees the unknown true relative state directly.

4.2.23.138 Relative Attitude for Close Operations

For close-proximity tasks, guidance and control may also require

\[ \hat{\mathbf q}_{rel} \]

and

\[ \hat{\boldsymbol\omega}_{rel}. \]

This allows the chaser to reason about both:

• translational geometry,
• target orientation.

Pose accuracy may therefore become more important as separation decreases.

4.2.23.139 Navigation and Collision Avoidance

Reliable relative-state knowledge is also important for maintaining safe separation.

A covariance-aware system can consider not only estimated position, but uncertainty around that estimate.

Conceptually,

\[ \boxed{ \text{Estimated Separation} + \text{Relative Uncertainty} \rightarrow \text{Better Safety Assessment}. } \]

4.2.23.140 Covariance and Safety Margins

Suppose the estimated range is

\[ \hat{\rho}. \]

A safety assessment based only on \(\hat{\rho}\) ignores uncertainty.

A more meaningful interpretation considers:

\[ \hat{\rho} \]

together with the projected range uncertainty

\[ \sigma_\rho. \]

Thus a nominally acceptable distance with large uncertainty may deserve more caution than the same distance with small uncertainty.

4.2.23.141 Relative Navigation and Guidance Handover

As operations progress, guidance may use different navigation modes.

For example, a system may transition from:

• absolute/relative GNSS,
• to optical relative navigation,
• to detailed pose sensing.

Navigation should therefore supply a consistent state representation so that guidance is not forced to interpret unrelated sensor outputs directly.

4.2.23.142 Common Relative-State Interface

A useful architecture publishes one fused relative state:

\[ \boxed{ \mathbf x_{rel} } \]

regardless of which sensors currently contribute.

Then:

\[ \boxed{ \text{Sensor Changes} \rightarrow \text{Estimator Handles Them} } \]

while

\[ \boxed{ \text{Guidance Receives a Consistent Interface}. } \]

This reduces coupling between guidance software and individual sensors.

4.2.23.143 Navigation Modes

The estimator may operate in modes such as:

• GNSS-dominant,
• optical-dominant,
• LiDAR-aided,
• inertial propagation,
• degraded relative navigation.

Mode changes should depend on:

• measurement availability,
• covariance,
• geometry,
• mission conditions.

4.2.23.144 Avoiding Hard Sensor Switching When Possible

An abrupt switch from one independent navigation solution to another can produce a state jump.

A fused estimator can instead gradually change information weighting.

Thus:

\[ \boxed{ \text{Smooth Sensor Fusion} > \text{Blind Hard Switching} } \]

when overlapping valid measurements are available.

4.2.23.145 Relative-Navigation Accuracy Requirements

A position requirement may be expressed as

\[ \boxed{ e_{r,95} < r_{req}. } \]

Velocity requirement:

\[ \boxed{ e_{v,95} < v_{req}. } \]

Attitude requirement:

\[ \boxed{ e_{\theta,95} < \theta_{req}. } \]

The probability level, frame, phase, and range should be defined explicitly.

4.2.23.146 Requirement Dependence on Separation

Requirements may vary with range:

\[ \boxed{ r_{req} = r_{req}(\rho) } \]

and

\[ \boxed{ v_{req} = v_{req}(\rho). } \]

Close-range operations may require tighter relative-state knowledge than distant operations.

4.2.23.147 Performance Should Include Availability

A highly accurate estimator that is valid only occasionally may not be useful operationally.

Therefore relative-navigation performance should include:

• accuracy,
• availability,
• continuity,
• consistency,
• recovery.

These properties complement standard RMSE metrics.

4.2.23.148 Relative Navigation Availability

Define

\[ \boxed{ A_{rel} = \frac{ T_{\text{valid relative navigation}} }{ T_{\text{operation}} }. } \]

Validity should be linked to:

• accuracy requirements,
• covariance limits,
• health.

4.2.23.149 Continuity

Continuity asks whether a valid navigation solution remains continuously available throughout a required interval.

An estimator that repeatedly drops valid/invalid may be difficult for downstream guidance even if its average accuracy is good.

4.2.23.150 Recovery Time

After a sensor outage or fault,

\[ \boxed{ T_{\mathrm{recover}} } \]

measures the time required for:

• state error,
• covariance,
• validity,

to return to acceptable values.

Recovery should be tested as explicitly as nominal accuracy.

4.2.23.151 Closed-Loop Validation

Standalone estimation tests are necessary but not sufficient.

The relative-navigation solution ultimately affects guidance commands, which change relative motion, which changes future sensor geometry.

Therefore:

\[ \boxed{ \text{Navigation} \rightarrow \text{Guidance} \rightarrow \text{Vehicle Motion} \rightarrow \text{Measurements} \rightarrow \text{Navigation}. } \]

This closed loop should eventually be validated.

4.2.23.152 Sensor Geometry Can Be Changed by Guidance

Guidance can intentionally improve navigation geometry.

For example, a manoeuvre may create:

• stronger bearing parallax,
• better range geometry,
• improved target visibility.

This demonstrates that navigation and guidance need not be completely independent disciplines.

4.2.23.153 Active Perception

When vehicle motion is intentionally selected to improve sensing, the concept is sometimes called active perception or information-aware guidance.

Conceptually,

\[ \boxed{ \text{Choose Motion} \rightarrow \text{Improve Future Measurements} \rightarrow \text{Reduce State Uncertainty}. } \]

This is an advanced extension of relative navigation.

4.2.23.154 Sensor Tasking

Sensors themselves can also be actively managed.

Examples include:

• camera pointing,
• exposure control,
• LiDAR scan-region selection,
• GNSS antenna selection.

The estimator can provide predicted target location and uncertainty to assist sensor tasking.

4.2.23.155 Camera Search Window From Prediction

If the predicted target image location is

\[ \hat{\mathbf p} \]

and covariance is

\[ \mathbf P_p, \]

the image-processing algorithm can search within an uncertainty window.

As covariance increases, the required search region grows.

Thus estimator uncertainty has direct computational implications.

4.2.23.156 Relative Navigation for Non-Cooperative Targets

For a non-cooperative target, the navigation system cannot rely on transmitted target state.

The estimator must infer the state from measurements such as:

• camera LOS,
• target features,
• LiDAR geometry,
• range.

This generally makes:

• initialization harder,
• observability more dependent on motion,
• fault detection more dependent on sensor redundancy.

4.2.23.157 Relative Navigation for Cooperative Targets

A cooperative target can make relative navigation much easier by providing:

• known markers,
• ranging transponders,
• GNSS state,
• attitude telemetry,
• timing information.

Sensor fusion can still be useful because transmitted information may be delayed, noisy, or temporarily unavailable.

4.2.23.158 Communication Delay

If target state is communicated,

\[ \mathbf x_T(t_m) \]

may arrive at time

\[ t_k>t_m. \]

Using the old target state directly produces relative-state timing error.

The target state should ideally be propagated to the current epoch before differencing.

4.2.23.159 Clock Synchronization Between Spacecraft

Inter-spacecraft measurements can depend on time synchronization.

A clock offset

\[ \Delta t \]

can affect:

• range,
• range rate,
• communicated states.

Some systems may therefore estimate clock bias as part of the relative-navigation state.

4.2.23.160 Range Bias

A ranging sensor may contain a systematic bias:

\[ \boxed{ z_\rho = \rho + b_\rho + v_\rho. } \]

If \(b_\rho\) is stable and observable, it may be estimated.

Otherwise it should be represented in the measurement uncertainty or calibration.

4.2.23.161 Camera Alignment Bias

A small camera alignment error

\[ \delta\boldsymbol\alpha_C \]

can produce systematic bearing residuals.

If not modeled, the navigation filter may incorrectly attribute that residual to relative position.

This can bias the estimated trajectory.

4.2.23.162 LiDAR Alignment Bias

The same issue exists for LiDAR.

A sensor-to-body rotation error changes the reported direction of measured points.

Thus camera and LiDAR calibration should be treated as part of the navigation measurement model.

4.2.23.163 Online Calibration

Under suitable observability, the estimator may augment its state with calibration parameters:

\[ \boxed{ \delta\mathbf x = [ \delta\mathbf x_{nav}, \delta\boldsymbol\alpha_C, \delta\boldsymbol\alpha_L, b_\rho, \ldots ]^T. } \]

Adding calibration states is useful only when the measurements and motion provide enough information to estimate them.

4.2.23.164 Too Many States Can Hurt the Estimator

Adding every possible uncertainty as a state is not automatically better.

Poorly observable states can:

• increase covariance,
• create strong correlations,
• slow convergence,
• reduce numerical conditioning.

Thus:

\[ \boxed{ \text{More States} \neq \text{Automatically Better Estimation}. } \]

4.2.23.165 Relative Navigation With Model Uncertainty

The target may execute unexpected motion.

Rather than immediately declaring sensor failure, the estimator should distinguish between:

• model mismatch,
• measurement fault.

Unexpected target acceleration may appear as a persistent innovation pattern.

Increasing process noise may sometimes be appropriate if target manoeuvres are physically plausible.

4.2.23.166 Unknown Target Manoeuvre

Suppose the target experiences acceleration

\[ \mathbf a_T^{unknown}. \]

Then the relative-dynamics model contains an unmodeled term.

One approach is to represent this with process noise:

\[ \mathbf Q_{target}. \]

Another is to augment acceleration as a state.

The appropriate choice depends on manoeuvre characteristics.

4.2.23.167 Constant-Acceleration Augmentation

A target acceleration state can be added:

\[ \boxed{ \mathbf x = [ \mathbf r_{rel}, \mathbf v_{rel}, \mathbf a_{rel} ]^T. } \]

Then

\[ \dot{\mathbf a}_{rel} \]

may be modeled as process noise.

This can improve tracking of smoothly manoeuvring targets at the cost of additional uncertainty and state dimension.

4.2.23.168 Relative Navigation and Target Classification

For some advanced systems, sensor processing may first determine what kind of target geometry is visible.

However, classification and navigation should be distinguished.

Navigation asks:

\[ \boxed{ \text{Where is the target and how is it moving?} } \]

Classification asks:

\[ \boxed{ \text{What type of object is the target?} } \]

They may share sensor data but solve different problems.

4.2.23.169 Measurement Quality Metrics

Sensors may provide internal quality metrics such as:

• number of tracked camera features,
• reprojection error,
• point-cloud registration error,
• GNSS DOP,
• range signal-to-noise ratio.

These can help determine measurement covariance dynamically.

4.2.23.170 Dynamic Measurement Covariance

Instead of fixed

\[ \mathbf R, \]

one may use

\[ \boxed{ \mathbf R_k = f( \text{range}, \text{feature count}, \text{geometry}, \text{quality} ). } \]

This allows the estimator to trust measurements according to their actual current quality.

But the mapping must be calibrated carefully.

4.2.23.171 Overconfident Camera Measurement

If a vision algorithm reports extremely small covariance despite poor feature geometry, the filter may overcorrect toward a poor pose solution.

Therefore:

\[ \boxed{ \text{Measurement Accuracy} \neq \text{Algorithm Confidence Output Automatically}. } \]

The reported covariance should be validated statistically.

4.2.23.172 Overconfident LiDAR Pose

The same issue applies to point-cloud registration.

A low fitting residual does not always mean full pose is well determined.

For example, a nearly planar target surface may constrain some pose directions much better than others.

The measurement covariance should reflect that anisotropy.

4.2.23.173 Information Contribution

The information matrix associated with a measurement is approximately

\[ \boxed{ \mathbf H^T \mathbf R^{-1} \mathbf H. } \]

This shows that measurement usefulness depends on both:

• noise covariance,
• state sensitivity.

A precise sensor can still provide little information about a state direction to which it is insensitive.

4.2.23.174 Fusion Is Not Averaging

Sensor fusion should not be thought of as averaging camera, GNSS, and LiDAR estimates.

The estimator uses each sensor according to its measurement model:

\[ \boxed{ \text{Fusion} = \text{Model-Based Combination of Information}. } \]

Different sensors can measure completely different quantities and still constrain the same underlying state.

4.2.23.175 Why Multiple Sensor Types Are Valuable

A robust RPO navigation suite combines complementary observables.

For example:

\[ \boxed{ \text{Range} \rightarrow \text{Radial Information} } \]

\[ \boxed{ \text{Camera} \rightarrow \text{Angular Information} } \]

\[ \boxed{ \text{LiDAR} \rightarrow \text{Detailed Geometry} } \]

\[ \boxed{ \text{IMU} \rightarrow \text{High-Rate Propagation}. } \]

Together they can provide stronger observability than any single sensor.

4.2.23.176 General Sensor-Fusion Architecture

A representative architecture is

\[ \boxed{ \begin{array}{c} \text{Dynamics / IMU}\\ \downarrow\\ \text{Relative-State Prediction}\\ \downarrow\\ \hat{\mathbf x}_{rel}^{-}\\ \downarrow\\ \text{Predict Sensor Measurements}\\ \downarrow\\ \text{Form Innovations}\\ \downarrow\\ \text{Validate / Gate}\\ \downarrow\\ \text{Kalman or Nonlinear Update}\\ \downarrow\\ \hat{\mathbf x}_{rel}^{+} \end{array} } \]

with independent sensor measurements arriving asynchronously.

4.2.23.177 Flight-Software Processing Sequence

A practical sequence can be:

1. read propagation data,
2. propagate relative state,
3. propagate covariance,
4. check newly arrived sensor measurements,
5. transform all measurements into consistent frames,
6. compensate known timing and lever arms,
7. validate sensor-specific quality,
8. predict each measurement,
9. form innovation,
10. compute innovation covariance,
11. gate the measurement,
12. perform correction,
13. update validity and health,
14. publish relative state and covariance.

4.2.23.178 Published Relative-Navigation Solution

The estimator may publish

\[ \boxed{ \hat{\mathbf r}_{rel}, \quad \hat{\mathbf v}_{rel}, \quad \hat{\mathbf q}_{rel}, \quad \hat{\boldsymbol\omega}_{rel}, \quad \mathbf P_{rel}. } \]

It may also publish sensor-health information and confidence metrics.

Downstream guidance should use both state and uncertainty.

4.2.23.179 Practical Design Philosophy

A robust relative-navigation system should:

1. define all coordinate frames explicitly,
2. propagate physically consistent relative dynamics,
3. model each sensor according to what it actually measures,
4. maintain realistic covariance,
5. use true measurement timestamps,
6. account for sensor alignment,
7. account for lever arms where relevant,
8. support asynchronous measurements,
9. use measurement-quality indicators,
10. perform innovation gating,
11. handle sensor dropouts,
12. increase covariance when information is lost,
13. recover safely after reacquisition,
14. account for changing sensor geometry,
15. monitor observability,
16. handle phase-dependent sensor combinations,
17. test systematic biases,
18. validate covariance with NIS and NEES,
19. test performance statistically,
20. publish navigation validity.

4.2.23.180 Key Takeaways

1. Relative navigation estimates one spacecraft with respect to another.

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

2. Relative state depends on coordinate frame.

Inertial, Hill/LVLH, body, and sensor frames must not be mixed.

3. Relative orbital dynamics are coupled.

The three position axes should not automatically be treated as independent Cartesian motion.

4. Cooperative targets can provide GNSS, telemetry, ranging, or navigation information directly.

5. Non-cooperative targets depend more strongly on camera, LiDAR, range, and other external sensing.

6. Range measures scalar separation.

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

7. Range rate measures line-of-sight velocity.

\[ \boxed{ \dot\rho = \mathbf u_{LOS}^T \mathbf v_{rel}. } \]

8. A camera typically measures angular geometry rather than direct range.

9. Bearing-only navigation requires motion or other measurements to recover scale robustly.

10. LiDAR contributes direct range and surface geometry.

11. Camera and LiDAR provide complementary information.

\[ \boxed{ \text{Angular / Visual Information} + \text{Range / Depth Information} \rightarrow \text{Improved Relative Pose}. } \]

12. IMU provides high-rate propagation but does not itself determine target location.

13. Relative pose contains both translation and orientation.

\[ \boxed{ \text{Pose} = \text{Position} + \text{Attitude}. } \]

14. Sensor geometry strongly controls observability.

15. Range-only and bearing-only problems can become observable through time-varying geometry.

16. Manoeuvres can improve observability.

\[ \boxed{ \text{Motion} \rightarrow \text{Geometry Change} \rightarrow \text{More Information}. } \]

17. Measurement covariance should often depend on range and geometry.

18. Different sensors naturally dominate at different distances.

19. Overlapping sensor regions help validate handovers.

20. Optical and LiDAR measurements require careful sensor alignment and lever-arm treatment.

21. Timing errors directly become relative-state errors.

\[ \boxed{ \delta\mathbf r \approx \mathbf v_{rel}\Delta t. } \]

22. Reacquisition after dropout should be statistically validated.

23. Sensor availability and sensor failure are not the same.

A healthy camera can lose the target because of field of view or lighting.

24. Relative navigation should provide covariance as well as state.

25. NIS evaluates measurement consistency.

\[ \boxed{ \mathrm{NIS} = \mathbf r^T \mathbf S^{-1} \mathbf r. } \]

26. NEES evaluates state-covariance consistency when truth is known.

\[ \boxed{ \mathrm{NEES} = \delta\mathbf x^T \mathbf P^{-1} \delta\mathbf x. } \]

27. Monte Carlo testing should include initial errors, sensor noise, geometry, timing, alignment, dropout, and target dynamics.

28. Relative-navigation performance should be evaluated by operational phase and separation range.

29. A running filter is not necessarily a valid navigation solution.

30. Relative-navigation integrity requires knowing when the estimate should not be trusted.

31. Guidance should receive a consistent fused relative-state interface rather than directly interpreting multiple sensor outputs.

32. Navigation and guidance interact because manoeuvres change future sensor geometry and observability.

33. The central engineering principle is

\[ \boxed{ \begin{array}{c} \text{Relative dynamics predict how the chaser and target geometry evolves,}\\[4pt] \text{while GNSS, ranging, camera, LiDAR, IMU, and other sensors}\\[4pt] \text{constrain different components of the relative state.}\\[4pt] \text{A robust estimator combines these complementary measurements}\\[4pt] \text{according to their geometry, uncertainty, timing, and validity.} \end{array} } \]

The natural next section is 4.2.24 Vision and LiDAR Fusion, where the camera and LiDAR concepts introduced in relative navigation are developed in greater depth through bearing measurements, image features, target detection, optical pose estimation, LiDAR range measurements, point-cloud geometry, camera–LiDAR calibration, relative pose fusion, and close-range navigation.

Next: 4.2.24 Vision and LiDAR Fusion

After developing general relative-navigation sensor fusion using GNSS, inter-spacecraft measurements, cameras, LiDAR, IMUs, line-of-sight, range, range rate, relative pose, observability, timing, covariance, validity, and sensor handover, the next section focuses specifically on the complementary use of vision and LiDAR for geometric relative navigation.