4.2.25 Sensor Handover and Mode-Dependent Fusion

Sensor handover and mode-dependent fusion deal with a practical reality of spacecraft navigation: one sensor combination is rarely optimal across the entire mission or across all separation ranges.

As operating conditions change, different sensors may become:

more accurate,
less accurate,
newly available,
temporarily unavailable,
geometrically weak,
saturated,
outside field of view,
unsuitable for the current range,
computationally too expensive for continuous use.

Therefore, a robust navigation architecture should not assume that one fixed fusion configuration is used from beginning to end.

Instead, the estimator should adapt its measurement set, weighting, validity logic, and operating mode to the current navigation conditions.

The central idea is

\[ \boxed{ \text{Mission Phase} + \text{Sensor Availability} + \text{Sensor Quality} + \text{Navigation Uncertainty} \rightarrow \text{Appropriate Fusion Mode} } \]

For general spacecraft rendezvous and proximity operations, this may include modes such as:

\[ \boxed{ \text{Far Range} \rightarrow \text{Mid Range} \rightarrow \text{Close Range} \rightarrow \text{Very Close / Capture-Preparation Range} } \]

The exact mission terminology and transition ranges depend on the system design.

The important principle is not the particular range boundary, but that sensor usefulness and navigation requirements change with operating condition.

Core idea

A handover is best understood as a controlled change in the information feeding one continuous state estimate. The navigation state should represent the spacecraft, while the sensor set supplying information to that state may evolve with range, geometry, quality, and health.

4.2.25.1 Why Sensor Handover Is Necessary

Different sensors have different operating envelopes.

For example:

GNSS may be effective for long-range cooperative relative navigation.
Camera bearing measurements may become useful once the target is detectable.
Detailed optical pose estimation may become available at shorter distance.
LiDAR may become increasingly valuable as reliable returns and dense geometry become available.
IMU propagation may remain useful continuously between external updates.

Therefore:

\[ \boxed{ \text{Best Sensor at One Range} \neq \text{Best Sensor at Every Range}. } \]

Sensor handover allows the navigation system to exploit whichever information sources are currently most useful.

4.2.25.2 Sensor Handover Is Not Simply Turning One Sensor Off and Another On

A naive handover would be

\[ \boxed{ \text{Sensor A OFF} \rightarrow \text{Sensor B ON}. } \]

This can be problematic.

If sensor B contains:

a different bias,
a different reference frame,
a different latency,
a different covariance,
a slightly different pose estimate,

the navigation state may jump suddenly.

A better architecture is usually:

\[ \boxed{ \text{Sensor A} \rightarrow \text{A+B Overlap} \rightarrow \text{Sensor B Dominant}. } \]

This allows the estimator to compare the sensors before the transition is completed.

4.2.25.3 Handover as an Information Transition

Sensor handover should be thought of as an information transition, not merely a hardware switch.

During handover, the estimator changes the relative amount of information contributed by each sensor.

Conceptually:

\[ \boxed{ \mathbf \Lambda_{total} = \mathbf \Lambda_A + \mathbf \Lambda_B + \cdots } \]

where

\[ \mathbf \Lambda \]

represents information contribution.

As sensor A becomes less useful and sensor B becomes more useful,

\[ \mathbf \Lambda_A \downarrow \]

while

\[ \mathbf \Lambda_B \uparrow. \]

The fused navigation state should remain physically continuous.

Why this viewpoint matters

Thinking in terms of information avoids the common mistake of treating handover as state replacement. The physical state does not change when a sensor becomes primary; only the measurement information available to estimate that state changes.

4.2.25.4 Mode-Dependent Fusion

Mode-dependent fusion means that the estimator changes behavior according to the current operational mode.

A mode can determine:

which sensors are enabled,
which measurements are accepted,
expected measurement covariance,
process-noise tuning,
measurement-update rates,
validity thresholds,
outlier gates,
state composition,
navigation requirements.

Thus the same filter architecture may behave differently in different operating conditions.

4.2.25.5 Navigation Modes

A general navigation system may contain modes such as:

\[ \boxed{ M_1=\text{Far Range} } \]

\[ \boxed{ M_2=\text{Mid Range} } \]

\[ \boxed{ M_3=\text{Close Range} } \]

\[ \boxed{ M_4=\text{Very Close / Terminal Relative Navigation}. } \]

These are conceptual categories.

Actual missions may use different names or more detailed subdivisions.

4.2.25.6 Far-Range Navigation Mode

At far range, detailed target geometry may not yet be visible.

Useful sensors may include:

absolute GNSS,
relative GNSS,
inter-spacecraft communication,
RF ranging,
coarse optical bearing.

The state estimate may focus mainly on:

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

Relative attitude may not yet be required or observable.

4.2.25.7 Mid-Range Navigation Mode

As separation decreases, the target may become clearly visible.

Camera measurements may begin contributing:

line of sight,
centroid,
silhouette,
coarse features.

LiDAR may begin producing useful range information depending on sensor capability.

The estimator may therefore use:

\[ \boxed{ \text{GNSS / Ranging} + \text{Camera Bearing} + \text{IMU}. } \]

This increases geometric observability.

4.2.25.8 Close-Range Navigation Mode

At closer range, sensors may provide detailed target geometry.

The navigation system may use:

camera features,
optical pose,
LiDAR point clouds,
direct range,
relative attitude measurements.

The state may expand to:

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

Pose estimation becomes increasingly important.

4.2.25.9 Very-Close or Terminal Navigation Mode

At very short separation, navigation requirements may become much tighter.

The estimator may rely strongly on:

precise relative pose,
low-latency sensing,
high-quality range,
close-range optical geometry.

At this stage, even small errors in:

sensor alignment,
lever arms,
timing,
target geometry

can become significant.

Therefore calibration and latency modeling become increasingly important.

4.2.25.10 Mission Phase Is Not the Same as Range Alone

Range is often used to define navigation phases, but it should not be the only condition.

Two cases with the same range may have very different:

target visibility,
illumination,
pointing,
relative velocity,
sensor quality,
covariance.

Therefore:

\[ \boxed{ \text{Mode} \neq f(\rho)\text{ only}. } \]

A more realistic mode decision may depend on

\[ \boxed{ M = f( \rho, \mathbf P, \text{sensor validity}, \text{geometry}, \text{quality} ). } \]

Range is only one variable

A reliable transition decision should combine operating geometry and estimator quality. Two encounters at the same separation can have very different visibility, covariance, sensor quality, relative rate, and observability.

4.2.25.11 Sensor Validity

Each sensor should provide a validity state.

For example:

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

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

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

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

Validity should represent whether the measurement can reasonably be used for navigation.

It should not merely indicate that hardware is powered.

4.2.25.12 Sensor Validity Criteria

Validity may depend on:

hardware health,
timestamp freshness,
field of view,
range limits,
signal quality,
feature count,
point-cloud density,
innovation statistics,
covariance,
geometry.

Thus:

\[ \boxed{ \text{Hardware Available} \neq \text{Navigation Measurement Valid}. } \]

4.2.25.13 Measurement Validity Versus Sensor Validity

These should be distinguished.

A sensor may be healthy overall while one particular measurement is invalid.

For example:

one camera frame may be blurred,
one LiDAR scan may contain insufficient points,
one GNSS update may be corrupted.

Therefore:

\[ \boxed{ \text{Sensor Valid} \not\Rightarrow \text{Every Measurement Valid}. } \]

Measurement-level validation should still be performed.

4.2.25.14 Sensor Quality

Validity is often binary:

\[ 0 \quad\text{or}\quad 1. \]

Quality is often continuous.

For example:

\[ \boxed{ 0 \le Q_s \le 1 } \]

may represent a normalized sensor-quality metric.

Two measurements can both be valid but have different uncertainty.

4.2.25.15 Quality-Dependent Covariance

Measurement covariance may depend on quality:

\[ \boxed{ \mathbf R = \mathbf R(Q_s). } \]

For poor-quality measurements:

\[ \mathbf R \uparrow \]

and therefore their Kalman gain contribution decreases.

This permits a smooth reduction in influence rather than an immediate hard rejection.

Covariance is the bridge between quality and fusion weight

In a Kalman-type estimator, changing measurement covariance changes how much information a measurement contributes. This is generally more defensible than introducing arbitrary hand-tuned sensor weights.

4.2.25.16 Hard Switching Versus Soft Switching

A hard switch is

\[ \boxed{ w_A = 1, \qquad w_B = 0 } \]

followed immediately by

\[ \boxed{ w_A = 0, \qquad w_B = 1. } \]

A soft transition allows

\[ \boxed{ 0 \le w_A,w_B \le 1. } \]

The weights change gradually according to sensor quality and uncertainty.

4.2.25.17 Why Hard Switching Can Be Dangerous

Hard switching can cause:

state discontinuity,
covariance discontinuity,
transient control response,
estimator inconsistency.

Suppose two sensors estimate position as

\[ \hat{\mathbf r}_A \]

and

\[ \hat{\mathbf r}_B. \]

If

\[ \hat{\mathbf r}_A \neq \hat{\mathbf r}_B, \]

blind replacement creates an instantaneous state jump.

The physical spacecraft did not jump; only the navigation source changed.

The state should not jump just because the source changed

A discontinuity at handover often indicates inconsistent frames, timing, bias, or covariance rather than a real physical change. A well-designed overlap region helps identify these mismatches before one sensor becomes dominant.

4.2.25.18 Fused Transition

A continuous fusion architecture instead retains one navigation state.

Sensor A and sensor B both update this common state.

Conceptually:

\[ \boxed{ \text{One State Estimate} + \text{Changing Measurement Contributions}. } \]

This generally avoids artificial state discontinuities.

4.2.25.19 Overlapping Sensor Regions

An overlap region exists where two or more sensors are simultaneously usable.

For example:

\[ \boxed{ \rho_{A,min} < \rho < \rho_{A,max} } \]

and

\[ \boxed{ \rho_{B,min} < \rho < \rho_{B,max}. } \]

If these ranges overlap, both sensors can be compared before handover.

4.2.25.20 Why Overlap Is Valuable

Overlap enables:

cross-validation,
calibration checks,
covariance comparison,
bias detection,
smoother transitions.

Therefore:

\[ \boxed{ \text{Sensor Overlap} \rightarrow \text{Reduced Handover Risk}. } \]

Without overlap, the estimator must trust the new sensor immediately when the previous one disappears.

Overlap is both a transition and a diagnostic opportunity

When two sensor families are simultaneously valid, the system can compare their innovations, detect relative bias, verify calibration, and confirm that the new source is statistically consistent before relying on it.

4.2.25.21 Cross-Sensor Innovation

Suppose sensor A and sensor B independently estimate the same quantity.

A simple discrepancy is

\[ \boxed{ \mathbf d = \hat{\mathbf x}_A - \hat{\mathbf x}_B. } \]

But raw difference alone is not enough.

The uncertainty of both estimates must also be considered.

4.2.25.22 Statistical Cross-Check

If the estimates are independent,

\[ \boxed{ \mathbf S_d = \mathbf P_A + \mathbf P_B. } \]

Then define

\[ \boxed{ D^2 = \mathbf d^T \mathbf S_d^{-1} \mathbf d. } \]

This provides a statistically meaningful agreement test.

4.2.25.23 Sensor Bias During Handover

Two sensors may both be individually stable but differ by a constant bias.

For example:

\[ \hat{\rho}_A = \rho+b_A \]

and

\[ \hat{\rho}_B = \rho+b_B. \]

Then:

\[ \boxed{ \hat{\rho}_A-\hat{\rho}_B = b_A-b_B. } \]

A handover region can reveal this difference before full reliance on sensor B.

4.2.25.24 Frame Consistency During Handover

Different sensors may report measurements in different frames.

Examples include:

inertial,
LVLH,
body,
camera,
LiDAR frame.

Before comparing measurements,

\[ \boxed{ \text{All Quantities Must Be Expressed in Consistent Frames}. } \]

Otherwise an apparent handover bias may simply be a frame transformation error.

4.2.25.25 Timestamp Consistency During Handover

Sensors may have different processing delays.

Suppose sensor A measurement is from time

\[ t_A \]

and sensor B measurement from

\[ t_B. \]

Directly comparing them without propagation can produce a false discrepancy.

Therefore:

\[ \boxed{ \text{Cross-Sensor Comparison} \rightarrow \text{Common Epoch}. } \]

4.2.25.26 Covariance Continuity

A state handover should not produce an arbitrary covariance reset.

If the estimator is already maintaining covariance

\[ \mathbf P^-, \]

a new sensor measurement should reduce uncertainty according to the normal Bayesian update.

It should not replace covariance with an unrelated value unless explicit reinitialization is intended.

State continuity is not enough

A visually smooth handover can still be wrong if covariance becomes unrealistically small or loses important correlations. State and uncertainty must remain jointly consistent.

4.2.25.27 Covariance Update Through New Sensor

For measurement matrix

\[ \mathbf H \]

and measurement covariance

\[ \mathbf R, \]

the Kalman gain is

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

Then:

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

Thus the new sensor naturally changes uncertainty through the filter equations.

4.2.25.28 Covariance Collapse During Handover

If the newly introduced sensor is assigned unrealistically small

\[ \mathbf R, \]

then

\[ \mathbf K \]

may become too large.

The filter may rapidly become overconfident.

This can produce:

\[ \boxed{ \text{Sensor Handover} \rightarrow \text{Artificial Covariance Collapse}. } \]

Therefore initial weighting of a newly activated sensor should be realistic.

4.2.25.29 Sensor Warm-Up

Some sensors should not be considered fully valid immediately after activation.

Possible reasons include:

thermal stabilization,
target acquisition,
GNSS reacquisition,
feature tracker initialization,
LiDAR registration convergence.

A sensor may therefore pass through states such as:

\[ \boxed{ \text{OFF} \rightarrow \text{INITIALIZING} \rightarrow \text{VALID}. } \]

4.2.25.30 Sensor Confidence Ramp

Instead of instantly assigning full confidence, measurement covariance may initially be inflated:

\[ \mathbf R_{start} > \mathbf R_{nominal}. \]

As consistency is demonstrated,

\[ \mathbf R \rightarrow \mathbf R_{nominal}. \]

This creates a controlled confidence ramp.

4.2.25.31 Hysteresis in Mode Switching

Suppose the switch from mode A to mode B occurs at

\[ \rho<\rho_{AB}. \]

If the spacecraft moves back and forth near that boundary, mode switching may oscillate.

To prevent this, use different entry and exit thresholds.

For example:

\[ \boxed{ \rho<\rho_{enter} \Rightarrow M_B } \]

but return only when

\[ \boxed{ \rho>\rho_{exit} } \]

with

\[ \rho_{exit}>\rho_{enter}. \]

This is hysteresis.

Hysteresis prevents chatter

Separate entry and exit thresholds keep small measurement noise near a boundary from repeatedly switching the estimator between two configurations.

4.2.25.32 Why Hysteresis Is Important

Without hysteresis, small measurement noise can produce repeated mode transitions:

\[ A\rightarrow B\rightarrow A\rightarrow B. \]

This can cause:

sensor toggling,
unstable covariance,
repeated initialization,
software complexity.

Hysteresis creates mode stability.

4.2.25.33 Dwell Time

Another way to prevent rapid switching is requiring a condition to remain true for a minimum duration.

For example:

\[ \boxed{ C(t)=1 \quad \forall t\in[t_0,t_0+T_d] } \]

before mode transition.

Here

\[ T_d \]

is dwell time.

This prevents a single noisy measurement from triggering a mode change.

4.2.25.34 Combined Hysteresis and Dwell

A robust transition can require both:

\[ \boxed{ \text{Threshold Condition} + \text{Hysteresis} + \text{Dwell Time}. } \]

This substantially reduces unwanted mode chatter.

4.2.25.35 Mode Transition Guards

A transition from mode \(M_i\) to \(M_j\) should require explicit guard conditions.

For example:

\[ \boxed{ G_{ij} = C_1 \land C_2 \land C_3. } \]

Possible conditions include:

range threshold,
covariance threshold,
sensor validity,
measurement quality,
acceptable relative rate.

Transitions should be earned, not assumed

A mode change is more robust when it requires several independent conditions such as acceptable range, valid sensor status, bounded covariance, and suitable relative rate.

4.2.25.36 Example Transition Guard

A general transition from mid-range to close-range sensing might require

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

and

\[ \boxed{ \texttt{LIDAR\_VALID}=1 } \]

and

\[ \boxed{ \sigma_r<\sigma_{r,max}. } \]

Only when all conditions are met does the mode change.

4.2.25.37 Navigation Mode State Machine

Mode management can be implemented as a state machine:

\[ \boxed{ M_1 \rightarrow M_2 \rightarrow M_3 \rightarrow M_4. } \]

Transitions depend on guards.

The estimator itself can remain continuous while the allowed measurement set changes.

4.2.25.38 Mode State Versus Estimator State

These are different concepts.

The estimator state is

\[ \boxed{ \mathbf x } \]

containing quantities such as position, velocity, attitude, and biases.

The navigation mode is

\[ \boxed{ M. } \]

It determines which algorithms or measurements are currently active.

4.2.25.39 Mode-Dependent Measurement Set

Let the complete sensor set be

\[ \mathcal S. \]

Mode \(M_i\) may enable only subset

\[ \boxed{ \mathcal S_i \subseteq \mathcal S. } \]

For example:

\[ \mathcal S_{far} = \{ GNSS, RF \} \]

while

\[ \mathcal S_{close} = \{ Camera, LiDAR, IMU \}. \]

The exact set depends on mission architecture.

4.2.25.40 Mode-Dependent Measurement Covariance

A sensor's covariance may also change with mode.

For example, camera measurement uncertainty may depend strongly on target range.

Thus:

\[ \boxed{ \mathbf R_C = \mathbf R_C(M,\rho,Q_C). } \]

The same sensor need not use one fixed covariance in all modes.

4.2.25.41 Mode-Dependent Process Noise

Process noise

\[ \mathbf Q \]

may also vary.

During quiet coast:

\[ \mathbf Q_{coast} \]

may be small.

During active maneuvering:

\[ \mathbf Q_{maneuver} > \mathbf Q_{coast} \]

for acceleration-related states.

Therefore:

\[ \boxed{ \mathbf Q = \mathbf Q(M). } \]

4.2.25.42 Why Process Noise May Change During Maneuvers

During maneuvering, uncertainty can increase due to:

thruster magnitude uncertainty,
direction error,
timing error,
unmodeled dynamics,
structural vibration.

The estimator should not necessarily use the same propagation confidence as during quiescent flight.

4.2.25.43 State Augmentation by Mode

Some advanced architectures may activate additional states only when needed.

For example, close-range mode might introduce:

camera alignment,
LiDAR bias,
relative attitude states.

However, dynamic state augmentation must be handled carefully because covariance must also be expanded consistently.

4.2.25.44 Fixed-State Alternative

An alternative is to maintain one full state vector in all modes.

Some states may simply become weakly observable when their corresponding sensors are unavailable.

This simplifies software but may increase computational load.

There is no universal choice.

4.2.25.45 Sensor Enabling Versus Measurement Acceptance

A sensor may be enabled but its measurements still rejected.

For example:

\[ \texttt{CAM\_ENABLED}=1 \]

while

\[ \texttt{CAM\_MEAS\_ACCEPTED}=0. \]

This distinction is useful because acquisition can remain active even when current data is not trustworthy.

4.2.25.46 Measurement Gating During Handover

Newly introduced sensors should still pass innovation gating.

For innovation

\[ \mathbf r \]

and covariance

\[ \mathbf S, \]

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

A sensor should not bypass statistical validation simply because the state machine expects it to become active.

4.2.25.47 Gate Tightness During Initial Acquisition

Immediately after acquisition, predicted state uncertainty may be relatively large.

Therefore the expected innovation covariance may also be large.

A gate based on

\[ \mathbf S \]

naturally accounts for this.

Fixed residual thresholds are generally less meaningful than normalized statistical thresholds.

4.2.25.48 Sensor Confirmation Before Handover

A new sensor may be required to pass

\[ N_c \]

consecutive validation checks before becoming fully trusted.

For example:

\[ \boxed{ \text{Valid}_{k-N_c+1:k} \Rightarrow \text{Enable Full Fusion}. } \]

This avoids switching based on one fortunate measurement.

4.2.25.49 Consecutive-Failure Logic

Similarly, a sensor need not be disabled after one rejected measurement.

A logic may require

\[ N_f \]

consecutive or repeated failures.

This distinguishes:

isolated outlier,
persistent sensor degradation.

4.2.25.50 Confidence Counter

One practical mechanism is a confidence score

\[ c_s. \]

For valid measurements:

\[ c_s\leftarrow c_s+1. \]

For invalid measurements:

\[ c_s\leftarrow c_s-1. \]

Sensor activation or isolation can depend on threshold values of \(c_s\).

This provides persistence without requiring a complex probabilistic health model.

4.2.25.51 Probabilistic Sensor Health

A more advanced system may maintain

\[ P(H_s|\mathcal Z) \]

where

\[ H_s \]

represents sensor health.

Then fusion weight can depend on the probability that the sensor is healthy.

This creates a probabilistic alternative to binary validity logic.

4.2.25.52 Handover and FDIR

Sensor handover interacts strongly with Fault Detection, Isolation and Recovery.

Suppose sensor A is degrading.

The system may:

detect inconsistent measurements,
reduce sensor A weight,
increase reliance on sensor B,
isolate sensor A if evidence persists.

Thus handover can form part of fault recovery.

Handover can also be a recovery mechanism

Nominal handover is planned, while fault-driven handover is reactive. The estimator should support both without confusing an expected mission transition with a sensor fault response.

4.2.25.53 Planned Versus Fault-Driven Handover

Two different situations exist.

Planned handover

Occurs because operating conditions change normally.

For example:

\[ \text{Long Range} \rightarrow \text{Close Range}. \]

Fault-driven handover

Occurs because the active sensor becomes unreliable.

These transitions should not necessarily use identical logic.

4.2.25.54 Planned Handover

A planned handover can use predictable conditions such as:

range,
mission phase,
sensor geometry.

This permits:

sensor pre-activation,
warm-up,
overlap,
cross-validation.

Therefore planned handovers can be relatively smooth.

4.2.25.55 Fault-Driven Handover

A fault-driven handover may occur suddenly.

For example:

\[ \boxed{ \text{Sensor A Fault} \rightarrow \text{Immediate Reliance on Sensor B}. } \]

There may be little or no overlap.

The estimator must therefore preserve conservative covariance and possibly enter degraded navigation.

4.2.25.56 Degraded Navigation Mode

If the preferred sensor suite is unavailable, the system may enter

\[ \boxed{ M_{degraded}. } \]

In this mode:

fewer measurements are available,
covariance grows faster,
tighter validity monitoring may be required,
guidance constraints may become more conservative.

The exact downstream response depends on mission design.

4.2.25.57 Covariance as a Mode Trigger

Navigation mode can depend directly on uncertainty.

For example:

\[ \boxed{ \sigma_r < \sigma_{req} } \]

may be required before entering a more demanding close-range mode.

Thus:

\[ \boxed{ \text{Estimated Range Alone} \neq \text{Enough for Mode Transition}. } \]

The estimator must also know the range accurately enough.

Knowing the range is not the same as knowing it well

A spacecraft may satisfy a geometric range threshold while the uncertainty in that range is still too large for the next phase. Mode readiness should therefore depend on covariance as well as the estimated state.

4.2.25.58 Position-Covariance Trigger

Suppose

\[ \mathbf P_r \]

is relative-position covariance.

A condition may be

\[ \boxed{ \lambda_{\max}(\mathbf P_r) < P_{max}. } \]

This ensures uncertainty is bounded in every principal position direction.

4.2.25.59 Velocity-Covariance Trigger

Similarly:

\[ \boxed{ \lambda_{\max}(\mathbf P_v) < V_{max}. } \]

This can prevent transition into a mode requiring precise relative-velocity knowledge when velocity remains uncertain.

4.2.25.60 Attitude-Covariance Trigger

For close-range pose operation:

\[ \boxed{ \sigma_{\theta} < \sigma_{\theta,max} } \]

may be required.

Thus relative-attitude knowledge can become part of mode-entry logic.

4.2.25.61 Sensor Geometry as a Mode Trigger

A sensor may be technically available but geometrically poor.

For example:

camera sees nearly symmetric target geometry,
LiDAR sees only a flat surface,
GNSS geometry is weak.

Therefore mode logic may include observability or geometry metrics.

4.2.25.62 Geometry Quality Metric

Suppose information matrix is

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

Small eigenvalues indicate weakly constrained directions.

A geometry metric may use

\[ \boxed{ \lambda_{\min}(\mathbf\Lambda). } \]

This can help decide whether a sensor is suitable for the next navigation phase.

4.2.25.63 Observability-Based Mode Switching

A more advanced transition may require

\[ \boxed{ \mathcal O > \mathcal O_{min} } \]

where

\[ \mathcal O \]

represents an observability metric.

This prevents switching to a measurement configuration that cannot adequately estimate required states.

Information geometry matters

A sensor can be valid and low-noise yet still provide weak information about one or more required state directions. Observability metrics help prevent switching into a configuration that cannot support the required states.

4.2.25.64 Mode-Dependent Navigation Requirements

Different modes may have different accuracy requirements.

For example:

\[ \sigma_{r,far} > \sigma_{r,mid} > \sigma_{r,close}. \]

Therefore:

\[ \boxed{ \text{Navigation Requirement} = f(M). } \]

A solution valid in far-range mode may not be valid for close-range operations.

4.2.25.65 Navigation Validity by Mode

Define

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

Its threshold may depend on mode.

For example:

\[ \boxed{ \texttt{NAV\_VALID} = 1 } \]

only if

\[ \mathbf P \]

satisfies the uncertainty limits required for the current mode.

4.2.25.66 Mode-Dependent Innovation Thresholds

Measurement statistics may also differ between modes.

For example:

camera pose uncertainty may shrink with range,
LiDAR registration quality may improve at close range.

Therefore the statistical model should reflect the current operating condition rather than use arbitrary constant limits.

4.2.25.67 Mode Transition and Navigation Reset

A mode transition should normally not reset the entire estimator.

If the state estimate is already valid, the preferred approach is usually:

\[ \boxed{ \text{Continue State} + \text{Change Measurement Configuration}. } \]

Full reinitialization should be reserved for cases where continuity cannot be maintained.

Mode change is not filter restart

Unless the current estimate is invalid, retaining the existing state and changing only the active measurement configuration usually preserves accumulated information and avoids unnecessary transients.

4.2.25.68 Why Reinitializing at Every Mode Change Is Risky

Frequent reset can cause:

loss of accumulated calibration,
covariance discontinuity,
transient errors,
loss of correlation information.

Therefore:

\[ \boxed{ \text{Mode Change} \neq \text{Estimator Restart}. } \]

4.2.25.69 Partial Reinitialization

Sometimes only part of the estimator must be initialized.

For example, when optical pose becomes available, relative attitude may be initialized while position and velocity continue from the existing filter.

This can be safer than restarting the entire state.

4.2.25.70 Sensor Handover and State Correlation

Suppose sensor B pose is derived using sensor A information.

Then the two measurements are correlated.

Fusing both as independent during overlap can double-count information.

Therefore:

\[ \boxed{ \text{Overlap} \neq \text{Automatic Independence}. } \]

Cross-correlation must be understood.

Overlap does not imply independence

If two estimates share underlying measurements or common processing, treating them as independent can double-count information and make covariance too optimistic.

4.2.25.71 Independent Sensor Cross-Validation

Cross-validation is strongest when two measurements have sufficiently independent failure modes.

For example:

camera bearing,
LiDAR range,

can provide valuable independent geometric checks.

Two outputs derived from the same camera image do not provide the same level of redundancy.

4.2.25.72 Handover and Redundancy

Sensor overlap naturally introduces redundancy.

For a period,

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

may both observe the same state.

This redundancy can support:

validation,
fault isolation,
graceful degradation.

This connects directly to the next topic on multi-sensor redundancy.

4.2.25.73 Multiple Simultaneous Sensors

A mode does not have to contain only one dominant sensor.

A close-range mode may use:

\[ \boxed{ \text{Camera} + \text{LiDAR} + \text{IMU} + \text{Other Valid Measurements}. } \]

Sensor handover can therefore mean changing the composition of the fusion set, not merely replacing one sensor with another.

4.2.25.74 Sensor Priority

Some architectures assign sensor priority.

For example:

\[ \boxed{ Priority_A > Priority_B. } \]

However, fixed priority can be inferior to uncertainty-based fusion.

A lower-priority sensor may actually be more informative under certain geometry or quality conditions.

4.2.25.75 Covariance-Based Sensor Dominance

In Kalman-type fusion, dominance emerges naturally from uncertainty.

If

\[ \mathbf R_A < \mathbf R_B \]

in relevant directions, sensor A contributes more strongly.

Therefore:

\[ \boxed{ \text{Sensor Dominance} \approx \text{Information Dominance}. } \]

This is preferable to arbitrary software priority when valid covariance models exist.

Dominance should emerge from information quality

When measurement models and covariances are realistic, the estimator naturally gives greater influence to the sensor that contributes more useful information in the currently observable directions.

4.2.25.76 Mode-Dependent Sensor Weighting

Let a measurement covariance be

\[ \mathbf R_s(M). \]

Then the same sensor can be trusted differently in different modes.

For example:

\[ \boxed{ \mathbf R_{camera,far} > \mathbf R_{camera,close} } \]

for pose-related quantities if target image resolution improves at shorter range.

4.2.25.77 Range-Dependent Weighting

A smooth covariance model may use

\[ \boxed{ \mathbf R_s = \mathbf R_s(\rho). } \]

This allows the estimator to adjust measurement weighting continuously as separation changes.

It can reduce the need for abrupt mode-specific weight changes.

4.2.25.78 Quality-Dependent Weighting

Similarly:

\[ \boxed{ \mathbf R_s = \mathbf R_s(Q_s). } \]

A valid but low-quality sensor can remain in the fusion architecture while contributing less information.

4.2.25.79 Combined Weighting Model

More generally:

\[ \boxed{ \mathbf R_s = \mathbf R_s( \rho, Q_s, M, \text{geometry} ). } \]

This allows the measurement model to reflect actual operating conditions.

However, such adaptive covariance requires careful calibration.

4.2.25.80 Avoiding Arbitrary Weighting

Measurement covariance should not be changed simply to obtain a visually smoother trajectory.

The covariance should represent expected measurement uncertainty.

Otherwise:

\[ \boxed{ \text{Smooth Output} \not\Rightarrow \text{Statistically Correct Estimator}. } \]

4.2.25.81 Handover and Innovation Monitoring

During a handover, innovation statistics should be monitored closely.

For sensor A:

\[ \mathrm{NIS}_A \]

and sensor B:

\[ \mathrm{NIS}_B. \]

If sensor B consistently disagrees while sensor A remains consistent, handover should be delayed.

4.2.25.82 Handover Readiness

A sensor can be declared ready when:

it is valid,
its measurement quality is adequate,
its innovations are statistically consistent,
geometry is acceptable,
covariance requirements are met.

Thus:

\[ \boxed{ \text{Sensor Ready} = \text{Available} + \text{Consistent} + \text{Informative}. } \]

Availability is only the first check

A sensor is truly ready for handover only when it is producing valid, informative, statistically consistent measurements with acceptable geometry and uncertainty.

4.2.25.83 Handover Completion Criteria

Transition completion may require:

\[ \boxed{ \texttt{NEW\_SENSOR\_VALID}=1 } \]

for a minimum duration, plus

\[ \boxed{ \mathrm{NIS}<\gamma } \]

and suitable covariance.

Only then may the previous sensor be removed from the active set.

4.2.25.84 Sensor Removal

A previous sensor should not necessarily be disabled immediately after the new one becomes dominant.

It may remain active for:

monitoring,
redundancy,
cross-checking.

A distinction can be made between:

\[ \boxed{ \text{Primary Measurement Source} } \]

and

\[ \boxed{ \text{Monitoring Source}. } \]

4.2.25.85 Sensor Standby Mode

A sensor may operate in standby.

For example:

\[ \boxed{ \text{OFF} \rightarrow \text{STANDBY} \rightarrow \text{ACTIVE}. } \]

Standby can reduce power while allowing faster reactivation than a complete shutdown.

This can be useful for fault recovery or mode reversal.

4.2.25.86 Reverse Handover

Mission conditions may reverse.

For example, separation may increase again.

Therefore handover logic should support:

\[ \boxed{ M_j \rightarrow M_i } \]

when appropriate.

Reverse transitions should use their own thresholds and validity checks.

4.2.25.87 Mode Hysteresis for Reverse Transitions

If transition into close-range mode occurs at

\[ \rho<\rho_{in}, \]

return to mid-range mode may occur only at

\[ \rho>\rho_{out} \]

where

\[ \rho_{out}>\rho_{in}. \]

This prevents repeated mode reversal near a boundary.

4.2.25.88 Sensor Loss During Transition

A newly introduced sensor may fail while the previous sensor is still active.

The system should be able to abort handover and remain in the previous mode.

Thus transition itself can have states such as:

\[ \boxed{ \text{PREPARE} \rightarrow \text{VALIDATE} \rightarrow \text{COMMIT}. } \]

4.2.25.89 Transaction-Like Handover

A useful conceptual model is:

prepare new sensor,
validate it,
compare against current solution,
gradually increase influence,
commit transition.

If any validation step fails, return to the previous stable mode.

This avoids incomplete handovers.

Prepare–validate–commit

This structure is useful because it gives the system a stable rollback point. If acquisition or validation fails, the previous mode remains intact instead of leaving the navigation system in a partially transitioned configuration.

4.2.25.90 Sensor Handover State Machine

A detailed handover may contain states:

\[ \boxed{ \text{INACTIVE} \rightarrow \text{ACQUIRING} \rightarrow \text{VALIDATING} \rightarrow \text{FUSING} \rightarrow \text{PRIMARY}. } \]

This is separate from the spacecraft mission-mode state machine.

4.2.25.91 Mode Management Architecture

A navigation system may therefore contain two interacting logic layers:

\[ \boxed{ \text{Mission / Navigation Mode Manager} } \]

and

\[ \boxed{ \text{Sensor Health / Handover Manager}. } \]

The first decides what capability is needed.

The second decides which sensors can safely provide it.

4.2.25.92 Estimator Configuration Manager

A configuration manager may determine:

active sensors,
covariance models,
filter gains indirectly through R,
process noise,
validity thresholds,
output requirements.

Thus:

\[ \boxed{ M \rightarrow \mathcal C_{estimator}. } \]

4.2.25.93 Configuration Consistency

Mode transition should be deterministic and traceable.

For each mode, define clearly:

enabled measurements,
measurement frames,
covariance models,
expected update rates,
thresholds,
validity criteria.

This reduces software ambiguity.

4.2.25.94 Mode-Dependent Measurement Frames

Different sensors may naturally produce different frames.

Mode configuration should explicitly define how measurements map into the estimator state frame.

For example:

\[ \boxed{ \mathbf z^{sensor} \rightarrow \mathbf z^{navigation}. } \]

Frame transformations should not be hidden inside undocumented handover logic.

4.2.25.95 Mode-Dependent Lever Arms

At close range, sensor lever arms may become more significant.

Therefore a sensor enabled only in close-range mode may require more detailed geometric modeling than sensors used at long range.

The measurement model should include the appropriate lever arm from the moment the sensor is activated.

4.2.25.96 Mode-Dependent Latency

Different navigation modes may use sensors with very different processing delays.

For example:

GNSS state update,
camera pose estimate,
LiDAR point-cloud registration.

Therefore:

\[ \boxed{ \Delta t_s = \Delta t_s(M) } \]

in practice because active sensor set changes with mode.

The estimator must still apply each measurement at its true epoch.

4.2.25.97 Delayed Measurements During Handover

A sensor may become active but deliver measurements that correspond to earlier times.

If the filter simply applies them at arrival time, the handover can appear biased.

Thus:

\[ \boxed{ \text{New Sensor Activation} \not\Rightarrow \text{Zero Latency}. } \]

Time alignment is part of handover validation.

4.2.25.98 Handover and Out-of-Sequence Updates

If a delayed measurement belongs to time

\[ t_m

the estimator may require:

historical state storage,
update at \(t_m\),
repropagation to \(t_k\).

This becomes especially relevant when newly activated vision or LiDAR processing has significant latency.

4.2.25.99 Handover and Filter Consistency

A handover should not be judged only by continuity of the state estimate.

Covariance consistency must also be maintained.

Therefore evaluate:

NIS,
NEES in simulation,
\(3\sigma\) coverage,
innovation mean.

A smooth-looking handover can still be statistically inconsistent.

Smooth does not automatically mean correct

A handover may look visually continuous while the covariance is inconsistent. Statistical checks such as NIS and NEES are therefore essential during verification.

4.2.25.100 Handover Error Metric

Define pre-handover state estimate

\[ \hat{\mathbf x}^{-} \]

and post-handover state

\[ \hat{\mathbf x}^{+}. \]

A handover jump can be measured as

\[ \boxed{ \Delta\mathbf x_{HO} = \hat{\mathbf x}^{+} - \hat{\mathbf x}^{-}. } \]

For attitude, use a multiplicative rotation error rather than direct quaternion subtraction.

4.2.25.101 Position Handover Jump

For position:

\[ \boxed{ \Delta\mathbf r_{HO} = \hat{\mathbf r}^{+} - \hat{\mathbf r}^{-}. } \]

A large jump may indicate:

sensor bias,
frame mismatch,
timing mismatch,
covariance inconsistency.

4.2.25.102 Velocity Handover Jump

Similarly:

\[ \boxed{ \Delta\mathbf v_{HO} = \hat{\mathbf v}^{+} - \hat{\mathbf v}^{-}. } \]

Velocity jumps can strongly affect guidance and control because they change predicted closing motion immediately.

4.2.25.103 Attitude Handover Jump

Define quaternion difference:

\[ \boxed{ \delta\mathbf q_{HO} = \mathbf q^{+} \otimes (\mathbf q^{-})^{-1}. } \]

Then:

\[ \boxed{ \Delta\theta_{HO} = 2\cos^{-1}(|\delta q_{0,HO}|). } \]

This measures attitude discontinuity across handover.

4.2.25.104 Covariance Jump Metric

One can also monitor

\[ \boxed{ \Delta\mathbf P = \mathbf P^{+} - \mathbf P^{-}. } \]

A sudden large decrease in uncertainty should be justified by genuine new information.

Otherwise it may indicate overconfident tuning.

4.2.25.105 Handover Transient

Even if no instantaneous jump occurs, the new sensor may produce a transient correction over several updates.

Therefore handover performance should include:

\[ \boxed{ T_{settle}. } \]

This is the time required for state error and covariance to settle after sensor transition.

4.2.25.106 Overshoot During Handover

The state estimate may temporarily move past the true state after introducing a strongly weighted sensor.

A useful metric is maximum transient error:

\[ \boxed{ e_{max,HO}. } \]

This should be tested under realistic sensor biases and initialization errors.

4.2.25.107 Handover Failure

A handover can be considered unsuccessful if:

new sensor cannot maintain lock,
innovations remain inconsistent,
state uncertainty increases excessively,
navigation validity is lost.

The system should then return to a safe supported mode if possible.

4.2.25.108 Handover Abort

A handover process may therefore include

\[ \boxed{ \texttt{HANDOVER\_ABORT}. } \]

This means the new sensor is not yet acceptable and the estimator remains with the previous valid configuration.

4.2.25.109 Fallback Navigation Mode

If both old and new sensors are unavailable, enter a fallback mode.

For example:

\[ \boxed{ \text{External Sensors Lost} \rightarrow \text{Propagation-Only / Degraded Mode}. } \]

Covariance should grow appropriately.

Fallback should be explicit

A degraded mode should deliberately represent reduced sensing capability, larger uncertainty, and tighter downstream permissions rather than pretending that nominal navigation quality still exists.

4.2.25.110 Mode-Dependent Guidance Interface

Guidance should ideally receive a consistent state interface regardless of navigation mode.

For example:

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

Guidance should not need to know whether the current measurement came from GNSS, camera, or LiDAR.

4.2.25.111 Navigation Mode Flag

The estimator may publish

\[ \boxed{ \texttt{NAV\_MODE}. } \]

Possible values might represent:

FAR,
MID,
CLOSE,
DEGRADED.

This tells downstream software how the solution is currently being generated.

4.2.25.112 Sensor Contribution Flags

The estimator may also publish

\[ \boxed{ \texttt{GNSS\_USED}, \texttt{CAM\_USED}, \texttt{LIDAR\_USED}. } \]

This distinguishes sensor availability from actual participation in the update.

4.2.25.113 Navigation Quality Output

A downstream interface may include:

\[ \boxed{ \{ \hat{\mathbf x}, \mathbf P, \texttt{NAV\_VALID}, \texttt{NAV\_MODE}, \texttt{SENSOR\_STATUS} \}. } \]

This allows guidance and autonomy logic to make uncertainty-aware decisions.

4.2.25.114 Mode Transition Logging

Every transition should be logged with:

previous mode,
new mode,
timestamp,
trigger condition,
sensor status,
covariance.

This is extremely useful for:

debugging,
verification,
post-flight analysis.

4.2.25.115 Handover Verification

Testing should verify:

state continuity,
covariance continuity,
innovation consistency,
correct sensor activation,
correct sensor deactivation,
hysteresis,
dwell time,
fallback behavior.

Mode logic should be tested independently from nominal filter equations.

4.2.25.116 Deterministic Handover Testing

Begin with deterministic simulations.

Use:

fixed initial state,
fixed sensor timing,
no random noise.

This allows checking the logic itself.

Only after the deterministic sequence is correct should random uncertainty be introduced.

4.2.25.117 Monte Carlo Handover Testing

Randomize:

sensor noise,
sensor bias,
timing delay,
activation range,
dropout,
alignment error,
initial covariance.

Then evaluate transition performance statistically.

4.2.25.118 Monte Carlo Handover Metrics

Useful metrics include:

\[ \boxed{ \Delta r_{HO}, \quad \Delta v_{HO}, \quad \Delta\theta_{HO}, \quad T_{settle}, \quad e_{max,HO}. } \]

Also record:

successful handover rate,
aborted handovers,
invalid-navigation duration.

4.2.25.119 Sensor Availability Monte Carlo

Randomize sensor availability windows.

For example:

camera acquisition delayed,
LiDAR unavailable temporarily,
GNSS lost earlier than expected.

This tests whether the mode logic depends too strongly on one nominal sequence.

4.2.25.120 Threshold Sensitivity

Transition thresholds such as

\[ \rho_{switch} \]

should be varied.

Evaluate whether small threshold changes produce large changes in estimator performance.

A very sensitive mode architecture may be difficult to operate robustly.

4.2.25.121 Dwell-Time Sensitivity

Similarly vary

\[ T_d. \]

If \(T_d\) is too small:

chatter may occur.

If too large:

useful sensor transitions may be delayed.

Therefore dwell time should be chosen based on sensor update rate and transition dynamics.

4.2.25.122 Hysteresis Sensitivity

Let hysteresis width be

\[ \boxed{ \Delta\rho_H = \rho_{exit} - \rho_{enter}. } \]

A very small width may not suppress chatter.

A very large width may delay legitimate reverse transitions.

4.2.25.123 Measurement-Quality Threshold Testing

Sensor activation may depend on quality threshold

\[ Q_s>Q_{min}. \]

Vary \(Q_{min}\) to evaluate the tradeoff between:

early sensor use,
measurement reliability.

4.2.25.124 Innovation-Gate Sensitivity

Similarly, vary gate threshold

\[ \gamma. \]

A very tight gate can reject valid new sensor measurements.

A very loose gate can allow poor measurements to influence the handover.

4.2.25.125 Mode-Transition Latency

A transition decision itself may be delayed by:

sensor processing,
software scheduling,
validity confirmation.

Define

\[ \boxed{ T_{transition}. } \]

This is the time between the physical condition becoming suitable and the new mode becoming operational.

4.2.25.126 Pre-Activation

To reduce transition latency, sensors can be activated before they are strictly required.

For example:

\[ \boxed{ \rho<\rho_{pre} \Rightarrow \text{Start Sensor Acquisition} } \]

with

\[ \rho_{pre} > \rho_{switch}. \]

This allows acquisition and validation before the actual handover point.

4.2.25.127 Pre-Activation Region

The sequence becomes:

\[ \boxed{ \text{Inactive} \rightarrow \text{Pre-Activated} \rightarrow \text{Validated} \rightarrow \text{Primary}. } \]

This is particularly useful for sensors requiring acquisition time.

4.2.25.128 Sensor Resource Constraints

Sensors consume:

power,
computation,
communication bandwidth.

Therefore all sensors may not be active continuously.

Mode-dependent activation can reduce resource use.

However, resource optimization should not compromise navigation robustness.

4.2.25.129 Computational Load by Mode

Far-range mode may require relatively simple measurements.

Close-range vision and LiDAR processing may require significantly more computation.

Thus:

\[ \boxed{ C_{compute} = C_{compute}(M). } \]

Navigation software scheduling should account for this.

4.2.25.130 Processing Deadline

A sensor measurement is useful only if processed before its latency becomes operationally unacceptable.

Therefore each sensor can have a processing deadline

\[ T_{max,s}. \]

If

\[ T_{processing}>T_{max,s}, \]

the measurement may be too stale even if numerically accurate.

4.2.25.131 Sensor Priority Under Resource Limitation

When processing resources are limited, the system may prioritize measurements based on:

expected information gain,
freshness,
mission phase,
validity.

This differs from fixed sensor priority.

4.2.25.132 Information-Gain-Based Scheduling

One advanced criterion is expected covariance reduction.

If sensor s is expected to produce posterior covariance

\[ \mathbf P_s^+, \]

one can compare

\[ \operatorname{tr}(\mathbf P^-) - \operatorname{tr}(\mathbf P_s^+). \]

Larger reduction means more expected information gain.

4.2.25.133 Mode-Dependent Sensor Scheduling

Sensor activation can therefore be interpreted as scheduling.

The system decides:

\[ \boxed{ \text{Which Measurement Is Most Useful Now?} } \]

subject to:

sensor availability,
power,
processing capacity,
geometry.

4.2.25.134 Transition and Sensor Fault

Suppose a newly activated sensor immediately fails validation.

The estimator should not force transition because a mode schedule says it should.

Therefore:

\[ \boxed{ \text{Mission Phase Request} \neq \text{Automatic Sensor Acceptance}. } \]

Sensor health must override nominal scheduling.

4.2.25.135 Mission Mode and Navigation Mode

These may differ.

A spacecraft mission mode might indicate operational intent.

Navigation mode indicates which estimator configuration is currently valid.

Therefore:

\[ \boxed{ M_{mission} \neq M_{nav} } \]

although they interact.

4.2.25.136 Navigation Mode Must Reflect Actual Capability

Suppose the mission requests close-range operation but LiDAR is unavailable.

The navigation system should not claim full close-range capability if required uncertainty cannot be achieved.

Instead:

\[ \boxed{ \text{Requested Mode} \neq \text{Achieved Navigation Capability}. } \]

This distinction is important for autonomy.

Requested capability and achieved capability are different

Mission logic can request a navigation mode, but the estimator should only declare that mode active when the actual sensor set and uncertainty satisfy its requirements.

4.2.25.137 Requested and Active Mode

Define

\[ \boxed{ M_{request} } \]

and

\[ \boxed{ M_{active}. } \]

A transition occurs only when entry conditions are satisfied.

This prevents software from declaring a navigation mode before the estimator is actually ready.

4.2.25.138 Mode Readiness Flag

A useful signal is

\[ \boxed{ \texttt{MODE\_READY}. } \]

For example:

\[ \texttt{MODE\_READY}=1 \]

only if required sensors and covariance conditions are satisfied.

4.2.25.139 Transition Permission

The navigation system may publish

\[ \boxed{ \texttt{TRANSITION\_PERMITTED}. } \]

This indicates whether downstream autonomy can proceed into the next operation phase based on navigation quality.

This is a general architecture concept and does not imply a particular mission implementation.

4.2.25.140 Sensor Handover and Safety

Sensor handover is safety relevant because poor handover can produce:

incorrect relative state,
loss of observability,
underestimated covariance.

A transition should therefore be conservative when sensor information is uncertain.

4.2.25.141 Safety Margin During Handover

Requirements may temporarily include an additional uncertainty margin.

For example:

\[ \boxed{ \sigma_{allowed,transition} < \sigma_{allowed,steady} } \]

if the system requires extra conservatism during transition.

The exact policy is mission dependent.

4.2.25.142 Handover and Relative Velocity

A sensor transition is more sensitive when relative velocity is high.

Timing error

\[ \Delta t \]

produces approximate position mismatch

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

Therefore high-speed transitions may require tighter synchronization.

4.2.25.143 Handover and Angular Rate

Similarly,

\[ \boxed{ \delta\boldsymbol\theta \approx \boldsymbol\omega_{rel}\Delta t. } \]

High angular rate increases sensitivity to delayed vision or LiDAR pose measurements.

4.2.25.144 Handover During Maneuvering

Sensor transitions during active maneuvering can be more difficult because:

state changes quickly,
process uncertainty increases,
measurement delays matter more,
vibration may affect sensors.

Therefore transition criteria may be more conservative during dynamic motion.

4.2.25.145 Handover During Quiet Motion

A sensor transition during low relative rate or coast conditions may be easier to validate.

Residuals are less contaminated by timing and dynamic-model errors.

When operationally possible, this can provide a cleaner transition.

4.2.25.146 Mode-Dependent Outlier Logic

Different sensors have different failure modes.

Therefore outlier logic may change by active sensor set.

Examples:

GNSS quality indicators,
camera reprojection errors,
LiDAR registration residuals.

There is no universal single outlier test for every measurement.

4.2.25.147 Mode-Dependent Fault Isolation

Fault isolation also depends on redundancy.

With multiple sensors active, disagreement can help isolate one sensor.

With only one sensor active, distinguishing sensor fault from model error is harder.

Thus:

\[ \boxed{ \text{Fault Isolation Capability} = f(\text{Sensor Redundancy}). } \]

4.2.25.148 Transition to Degraded Mode

If one sensor fails and no equivalent replacement is available:

\[ \boxed{ M_{nominal} \rightarrow M_{degraded}. } \]

The state estimator may still operate, but uncertainty limits and downstream permissions should reflect reduced capability.

4.2.25.149 Recovery From Degraded Mode

When a sensor returns:

\[ \boxed{ M_{degraded} \rightarrow \text{Reacquisition} \rightarrow \text{Validation} \rightarrow M_{nominal}. } \]

The system should not immediately declare nominal capability after the first recovered measurement.

4.2.25.150 Sensor Recovery Dwell

Require the sensor to remain healthy for

\[ T_{recover} \]

before restoring full confidence.

This reduces repeated degraded/nominal oscillation.

4.2.25.151 Handover and State Validity

State components may have different validity.

For example:

position may be valid,
relative attitude may not yet be valid.

Therefore a single global navigation-valid flag may sometimes be insufficient.

4.2.25.152 Component-Level Validity

Possible flags include:

\[ \boxed{ \texttt{POS\_VALID} } \]

\[ \boxed{ \texttt{VEL\_VALID} } \]

\[ \boxed{ \texttt{ATT\_VALID} } \]

\[ \boxed{ \texttt{POSE\_VALID}. } \]

Different modes may require different combinations.

4.2.25.153 Required Validity Set

Suppose close-range mode requires position and attitude.

Then entry condition may be

\[ \boxed{ \texttt{POS\_VALID} \land \texttt{ATT\_VALID}. } \]

A far-range mode may require only position and velocity validity.

4.2.25.154 Sensor Handover and Observability Loss

Removing one sensor can make some states weakly observable.

For example:

\[ \boxed{ \text{LiDAR Removed} \rightarrow \text{Reduced Range Observability} } \]

in some vision configurations.

The covariance should reflect this immediately over subsequent propagation.

4.2.25.155 Observability Before Sensor Removal

A previous sensor should ideally remain active until the new sensor set provides sufficient observability.

Thus:

\[ \boxed{ \text{Remove Old Sensor} \Rightarrow \text{Required States Observable From Remaining Set}. } \]

This is stronger than simply checking that the new sensor is producing data.

Do not remove information too early

The previous sensor should remain available until the remaining sensor set can independently support all state components required by the new mode.

4.2.25.156 Mode Transition and Bias Observability

Some sensor biases may only be observable when multiple sensors overlap.

For example, camera-LiDAR alignment or range bias may be easier to identify during simultaneous operation.

Removing one sensor too early can stop calibration convergence.

4.2.25.157 Calibration Freeze

When a calibration state becomes unobservable after handover, the estimator may:

freeze its estimate,
continue propagating it with small process noise,
remove it from active estimation.

The correct strategy depends on the calibration parameter.

4.2.25.158 Handover and Filter Architecture

Handover can be implemented within:

one EKF,
one ESKF,
one UKF,
federated filters,
multiple local filters with master fusion.

The high-level handover principles remain similar.

4.2.25.159 Single-Filter Architecture

One central estimator receives all sensor measurements.

Advantages:

shared covariance,
straightforward cross-state correction,
continuous state.

Disadvantages:

larger complexity,
possible single-point software dependence.

4.2.25.160 Federated Architecture

Separate local filters process different sensor groups.

Their outputs are combined at a master level.

Sensor handover may then mean changing:

local filter availability,
master fusion weights.

This can provide modularity and fault isolation.

4.2.25.161 Federated Handover

Suppose local filters produce

\[ \hat{\mathbf x}_1,\mathbf P_1 \]

and

\[ \hat{\mathbf x}_2,\mathbf P_2. \]

A master fusion algorithm can gradually reduce reliance on filter 1 while increasing reliance on filter 2.

Correlation must still be considered.

4.2.25.162 Covariance Intersection for Unknown Correlation

If correlation between two estimates is unknown, naive covariance fusion can be overconfident.

Covariance Intersection provides a conservative alternative.

For weight

\[ 0\le\omega\le1, \]

\[ \boxed{ \mathbf P^{-1} = \omega\mathbf P_1^{-1} + (1-\omega)\mathbf P_2^{-1}. } \]

The fused estimate is formed consistently in information space.

Why a conservative fusion method may be needed

When two estimates share unknown common information, ordinary covariance fusion can be overconfident. Covariance Intersection is useful because it does not require the unknown cross-correlation to be known explicitly.

4.2.25.163 Why Unknown Correlation Matters

If two estimates share common measurements, their errors are correlated.

Ignoring this can count the same information twice.

Thus:

\[ \boxed{ \text{Two Estimates} \neq \text{Two Independent Estimates}. } \]

This is especially important during sensor overlap and federated handover.

4.2.25.164 Smooth Switching Through Covariance Inflation

A sensor being phased out can be given gradually larger covariance:

\[ \boxed{ \mathbf R_A \uparrow. } \]

A sensor being phased in can move from conservative covariance toward nominal:

\[ \boxed{ \mathbf R_B \downarrow. } \]

This produces a smooth change in Kalman gains.

4.2.25.165 Covariance Inflation Must Be Physically Justified

Artificially inflating covariance only to force a desired switch can reduce estimator interpretability.

Prefer covariance changes based on:

range,
geometry,
measured quality,
validated sensor performance.

4.2.25.166 Smooth Weighting Function

A continuous range-dependent weight might use a sigmoid function:

\[ \boxed{ w(\rho) = \frac{1}{ 1+ e^{-k(\rho-\rho_0)} }. } \]

This creates a smooth transition around

\[ \rho_0. \]

Such weighting should still be tied to actual sensor performance.

4.2.25.167 Complementary Weighting

For two sensors:

\[ \boxed{ w_A+w_B=1. } \]

Then:

\[ w_A\rightarrow0 \]

while

\[ w_B\rightarrow1. \]

In probabilistic filtering, equivalent behavior may emerge through changing covariance rather than explicit weights.

4.2.25.168 Handover Based on Information Ratio

Define

\[ \eta = \frac{ I_B }{ I_A+I_B }. \]

When

\[ \eta \]

increases, sensor B is providing more relative information.

This can provide a more principled handover metric than range alone.

4.2.25.169 Information Metric

A simple scalar information measure could be

\[ \boxed{ I_s = \operatorname{tr} ( \mathbf H_s^T \mathbf R_s^{-1} \mathbf H_s ). } \]

Other metrics may use:

determinant,
minimum eigenvalue,
expected covariance reduction.

4.2.25.170 Mode-Dependent Sensor Geometry

Sensor geometry itself changes with spacecraft state.

Therefore the sensor considered dominant at one target orientation may not remain dominant at another orientation even at the same range.

This is another limitation of range-only handover rules.

4.2.25.171 Event-Driven Handover

Some transitions are triggered by events rather than continuous thresholds.

Examples:

target detected,
first valid LiDAR lock,
GNSS loss,
image tracker convergence.

Then:

\[ \boxed{ \text{Event} \rightarrow \text{Mode Transition Candidate}. } \]

The candidate should still pass validation.

Events can trigger readiness, not automatic commitment

Target detection or first LiDAR lock can indicate that a transition is possible, but statistical and covariance checks should still determine whether the new configuration is actually ready.

4.2.25.172 Mode Transition Priority

Several transition conditions may occur at once.

A priority hierarchy may be required.

For example:

\[ \boxed{ \text{Safety / Fault Transition} > \text{Nominal Phase Transition}. } \]

Fault responses should typically override ordinary mission progression.

4.2.25.173 Sensor Handover Race Conditions

Software must prevent inconsistent simultaneous commands such as:

enabling and disabling same sensor,
two competing mode transitions,
sensor health logic and mission logic issuing conflicting requests.

A deterministic transition manager helps prevent such race conditions.

4.2.25.174 Atomic Mode Update

A software mode transition should ideally update related parameters consistently in one logical operation:

active sensor set,
covariance model,
thresholds,
output flags.

Partial configuration changes can create transient inconsistencies.

4.2.25.175 Mode Transition Verification in SIL

Software-in-the-loop testing should verify:

all transition guards,
sensor validity handling,
hysteresis,
dwell timers,
covariance changes,
fallback logic.

The purpose is to validate logic independently of hardware effects.

4.2.25.176 Mode Transition Verification in HIL

Hardware-in-the-loop testing can additionally expose:

real sensor latency,
timestamp jitter,
communication delay,
acquisition time,
processor load.

These factors can significantly change handover behavior compared with ideal simulation.

4.2.25.177 Fault Injection Testing

Inject failures such as:

camera blackout,
LiDAR dropout,
GNSS loss,
frozen measurement,
biased measurement,
delayed packet.

Verify that handover logic detects and responds appropriately.

4.2.25.178 Timing Jitter Testing

Sensor timestamps may contain jitter.

Model:

\[ \boxed{ t_k^{meas} = t_k + \delta t_k. } \]

Vary

\[ \delta t_k \]

during transitions to test robustness.

4.2.25.179 Packet-Loss Testing

Communication or processing may lose measurement packets.

The estimator should tolerate intermittent updates without unnecessary mode switching.

One missed measurement should not normally force immediate handover.

4.2.25.180 Burst Dropout Testing

A more difficult case is a burst of missed measurements.

Define dropout duration

\[ T_{drop}. \]

Evaluate:

covariance growth,
validity,
mode transition,
recovery.

4.2.25.181 False Sensor-Recovery Testing

Inject a brief return of apparently valid data followed by another dropout.

This tests whether recovery logic has sufficient dwell and persistence.

4.2.25.182 False Mode Trigger Testing

Introduce noisy range measurements near a transition boundary.

Without hysteresis, this may generate repeated switching.

The test validates that mode logic rejects noisy threshold crossings.

4.2.25.183 Transition Boundary Monte Carlo

Randomize:

\[ \rho_0 \]

around the nominal switch region.

Also randomize measurement noise and covariance.

Evaluate:

which mode becomes active,
transition timing,
state continuity.

4.2.25.184 Bias Mismatch Testing

During overlap, inject sensor biases

\[ b_A, \qquad b_B. \]

Evaluate whether the handover creates:

state jump,
innovation inconsistency,
bias detection.

This is important because real sensors rarely agree perfectly.

4.2.25.185 Frame-Misalignment Testing

Inject small sensor alignment errors:

\[ \delta\boldsymbol\alpha_A, \qquad \delta\boldsymbol\alpha_B. \]

Then assess transition error.

Frame errors often appear most clearly during cross-sensor overlap.

4.2.25.186 Handover Performance Envelope

A useful output is a handover performance envelope showing error versus:

range,
relative velocity,
sensor noise,
sensor bias,
latency,
alignment.

This identifies the conditions under which the transition remains reliable.

4.2.25.187 Transition Success Probability

Across Monte Carlo runs:

\[ \boxed{ P_{success} = \frac{ N_{successful} }{ N_{total} }. } \]

A successful transition should have clearly defined criteria.

For example:

navigation remains valid,
transient error stays bounded,
new sensor becomes stable.

4.2.25.188 Transition Failure Categories

Failures should be categorized.

Examples:

acquisition failure,
validation failure,
excessive jump,
covariance inconsistency,
sensor dropout,
mode chatter.

This makes debugging much more useful than one global failure count.

4.2.25.189 Handover Recovery Time

Define

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

as the time from transition initiation until navigation error and covariance return to acceptable steady behavior.

This is especially useful for comparing alternative handover strategies.

4.2.25.190 Navigation Continuity Metric

Define valid-navigation fraction during transition:

\[ \boxed{ C_{nav} = \frac{ T_{valid} }{ T_{transition-window} }. } \]

A transition with good final accuracy but long invalid periods may still be undesirable.

4.2.25.191 State Continuity Metric

For state component \(x_i\),

\[ \boxed{ J_i = | x_i(t^+)-x_i(t^-) |. } \]

For vector position:

\[ \boxed{ J_r = \| \mathbf r(t^+)-\mathbf r(t^-) \|. } \]

These quantify discontinuity.

4.2.25.192 Covariance Consistency Metric

Compare actual error with \(3\sigma\) bounds during handover.

For component i,

\[ \boxed{ |e_i| \le 3\sqrt{P_{ii}} } \]

should occur with appropriate statistical frequency over many runs.

4.2.25.193 Handover NIS Monitoring

Track NIS separately before, during, and after transition.

A sudden persistent NIS increase after activating the new sensor can indicate:

bad covariance,
calibration error,
timing mismatch.

4.2.25.194 Handover NEES Monitoring

In simulation, track

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

This reveals whether covariance remains credible through the transition.

4.2.25.195 Innovation Mean During Handover

A correctly modeled sensor should have approximately zero-mean innovation.

Persistent mean:

\[ E[\mathbf r]\neq0 \]

may indicate a sensor bias or frame mismatch.

Overlap regions are particularly useful for identifying this before full handover.

4.2.25.196 Mode-Dependent Logging

Record:

mode,
active sensors,
validity flags,
measurement quality,
covariance,
NIS,
transition reason.

This allows reconstruction of exactly why each transition occurred.

4.2.25.197 Handover Debugging

When a handover performs badly, useful questions include:

Did the new sensor become valid too early?
Was its covariance too optimistic?
Were timestamps aligned?
Were frames consistent?
Was sensor bias present?
Was geometry poor?
Did covariance collapse?
Did hysteresis fail?

This systematic approach is more useful than tuning gains blindly.

4.2.25.198 Design Philosophy

A robust handover system should prefer

\[ \boxed{ \text{Measured Readiness} } \]

over

\[ \boxed{ \text{Assumed Readiness}. } \]

A mission-phase schedule may request a transition, but actual sensor and estimator quality should determine whether the transition is accepted.

4.2.25.199 Practical Sensor-Handover Workflow

A practical sequence is:

identify approaching transition condition,
pre-activate next sensor,
acquire target or measurement,
validate sensor health,
validate measurement quality,
confirm frame and timing consistency,
begin overlap,
compare innovations,
confirm covariance behavior,
gradually increase sensor influence,
confirm required observability,
declare new mode active,
retain old sensor temporarily for monitoring if useful,
disable or demote old sensor,
continue monitoring for regression.

4.2.25.200 Example General Transition Sequence

A generic sequence can be expressed as

\[ \boxed{ \begin{array}{c} \text{Current Mode}\\ \downarrow\\ \text{Transition Condition Approaches}\\ \downarrow\\ \text{Activate New Sensor}\\ \downarrow\\ \text{Validate New Sensor}\\ \downarrow\\ \text{Overlap Measurements}\\ \downarrow\\ \text{Cross-Check}\\ \downarrow\\ \text{Increase New-Sensor Weight}\\ \downarrow\\ \text{Verify Covariance and Validity}\\ \downarrow\\ \text{Commit New Mode} \end{array} } \]

This structure is applicable to many multi-sensor navigation systems.

4.2.25.201 Why Sensor Handover Is a Navigation Problem, Not Only a Software Problem

The transition depends on:

sensor physics,
measurement geometry,
covariance,
observability,
state dynamics.

Therefore handover cannot be designed only as software logic.

It must be consistent with the navigation-estimation model.

The switching logic is part of estimation design

Handover thresholds, dwell logic, covariance models, sensor geometry, and observability all affect state quality. The problem therefore spans sensor physics, estimation theory, and software architecture.

4.2.25.202 Relationship to Guidance and Autonomy

Navigation mode determines the quality of the state supplied to guidance.

Therefore:

\[ \boxed{ \text{Navigation Mode} \rightarrow \text{Available Guidance Capability}. } \]

Guidance or autonomy may need to wait until a required navigation mode is valid.

4.2.25.203 Guidance Should Use Validity, Not Sensor Identity

Guidance should ideally not contain logic such as:

Use LiDAR position directly.

Instead, it should receive the fused relative state and validity.

This maintains architectural separation between:

sensing,
estimation,
guidance.

4.2.25.204 Navigation Readiness for Phase Transition

A general readiness condition can be written

\[ \boxed{ R_{nav} = C_P \land C_V \land C_S \land C_O } \]

where:

\(C_P\): position uncertainty acceptable,
\(C_V\): velocity uncertainty acceptable,
\(C_S\): required sensors valid,
\(C_O\): observability acceptable.

Only when

\[ R_{nav}=1 \]

should the navigation system declare itself ready.

4.2.25.205 Range Is Not Enough

A spacecraft may physically reach a transition range while navigation uncertainty remains too high.

Therefore:

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

should not automatically imply

\[ \boxed{ M_{next}. } \]

Navigation quality must also satisfy requirements.

4.2.25.206 Sensor Quality Is Not Enough Either

A sensor may produce high-quality measurements while the overall state remains poorly initialized.

Thus:

\[ \boxed{ \text{Good Measurement} \neq \text{Immediately Good Navigation State}. } \]

The estimator may need several updates to converge.

4.2.25.207 Convergence Before Handover Completion

Require covariance or state change to stabilize.

For example:

\[ \boxed{ \|\mathbf P_k-\mathbf P_{k-1}\| < \epsilon_P } \]

over a suitable interval.

This can supplement measurement-validity checks.

4.2.25.208 Sensor Handover and Initialization

A newly introduced sensor may require internal initialization before its measurements are meaningful.

Examples:

pose tracker initialization,
point-cloud registration seed,
feature map initialization.

This sensor-side initialization is separate from estimator initialization.

4.2.25.209 Initial Pose Guess

Vision or LiDAR registration often requires an initial pose guess.

The current navigation filter can provide this prediction.

Thus:

\[ \boxed{ \text{Existing Navigation Estimate} \rightarrow \text{New Sensor Acquisition Aid}. } \]

This reduces handover difficulty.

4.2.25.210 Navigation-Assisted Sensor Acquisition

The estimator may predict:

target image location,
expected LiDAR range,
approximate relative orientation.

The sensor processor can use these predictions to narrow its search.

This creates a feedback interaction between estimation and sensing.

4.2.25.211 Sensor-Assisted Navigation Transition

Once the new sensor obtains a reliable solution, it improves the navigation estimate.

Thus the interaction becomes

\[ \boxed{ \text{Navigation Prediction} \rightarrow \text{Sensor Acquisition} \rightarrow \text{Better Measurement} \rightarrow \text{Improved Navigation}. } \]

4.2.25.212 Handover and Active Perception

A spacecraft may intentionally change pointing or trajectory to improve a new sensor's geometry before handover.

This is an example of active perception.

Conceptually:

\[ \boxed{ \text{Prepare Geometry} \rightarrow \text{Acquire Sensor} \rightarrow \text{Complete Handover}. } \]

4.2.25.213 Sensor Handover and Target Visibility

For optical sensors, handover may depend on whether the target is visible.

Visibility can depend on:

field of view,
target orientation,
illumination,
occlusion.

Therefore target visibility should be checked explicitly.

4.2.25.214 Sensor Handover and Range Limits

For LiDAR or other range sensors:

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

may be required.

Entering the numerical range alone does not guarantee adequate return quality, so signal quality must also be checked.

4.2.25.215 Sensor Handover and Saturation

At very close range, some sensors can saturate or fall below minimum operating distance.

Thus a sensor may be useful only over a finite interval:

\[ \boxed{ \rho_{min,s} < \rho < \rho_{max,s}. } \]

This creates the need for later handover as well as initial activation.

4.2.25.216 Multi-Stage Sensor Chain

A mission may use a sequence such as

\[ \boxed{ S_1 \rightarrow S_2 \rightarrow S_3 \rightarrow S_4. } \]

Each sensor's operating region overlaps with the next.

A well-designed chain avoids coverage gaps.

4.2.25.217 Coverage Gap

A coverage gap occurs if

\[ \rho_{min,A} > \rho_{max,B} \]

for neighboring sensors.

Then there exists a separation region where neither sensor performs adequately.

This is a system-level navigation design problem.

4.2.25.218 Coverage Overlap Margin

It is preferable to have

\[ \boxed{ \rho_{min,A} < \rho_{max,B} } \]

with sufficient overlap.

The overlap should be large enough to accommodate:

sensor uncertainty,
activation latency,
target geometry variation.

4.2.25.219 Sensor Operating Envelope

Each sensor can be characterized by an envelope:

\[ \boxed{ \mathcal E_s = \{ \rho, \text{FOV}, Q, \text{illumination}, \text{geometry} \}. } \]

Handover logic should respect this multidimensional operating envelope.

4.2.25.220 Mode Envelope

Similarly, navigation mode validity exists over a region

\[ \boxed{ \mathcal M_i } \]

of the system operating space.

A mode is valid only where its active sensor combination satisfies required navigation performance.

4.2.25.221 Mode Envelope Overlap

Good architecture may deliberately design

\[ \boxed{ \mathcal M_i \cap \mathcal M_{i+1} \neq \emptyset. } \]

This creates a region in which either mode can maintain valid navigation.

That overlap enables graceful transition.

4.2.25.222 Mode Envelope Validation

Simulation should map where each mode remains valid across:

range,
relative velocity,
lighting,
geometry,
sensor noise.

This produces a more useful design picture than one nominal transition range.

4.2.25.223 Sensor-Handover Map

A sensor-handover map can visualize:

sensor availability,
sensor quality,
active mode,
covariance,
transition boundaries.

This helps identify:

gaps,
excessive overlap,
weak regions.

4.2.25.224 Handover and Mission Robustness

A robust mission should not depend on one exact sensor transition point.

If transition is required at precisely one range with no tolerance, small uncertainty can cause failure.

Therefore handover regions should have margin.

4.2.25.225 Transition Margin

Define a transition window

\[ \boxed{ \rho_{low} < \rho < \rho_{high}. } \]

Within this window, both configurations should ideally be valid.

The exact transition can then depend on sensor quality rather than a single hard range.

4.2.25.226 Sensor-Handover Optimization

The transition point can be selected to optimize criteria such as:

minimum covariance,
maximum observability,
minimum processing cost,
maximum robustness.

One may define an objective:

\[ \boxed{ J_{HO} = w_1J_{accuracy} + w_2J_{robustness} + w_3J_{resources}. } \]

This is an advanced design approach.

4.2.25.227 Accuracy-Based Transition

One simple strategy is to compare expected sensor uncertainties.

Switch when

\[ \boxed{ \sigma_B < \sigma_A. } \]

But this ignores:

observability,
bias,
latency,
redundancy.

Therefore accuracy alone may not define the best transition.

4.2.25.228 Information-Based Transition

A better criterion may compare information:

\[ \boxed{ I_B>I_A. } \]

This includes both measurement uncertainty and state sensitivity.

Even this should be combined with sensor validity and continuity considerations.

4.2.25.229 Risk-Aware Transition

A safety-oriented system may transition only if:

\[ \boxed{ P(\text{navigation failure}|M_{next}) < P_{max}. } \]

This requires probabilistic modeling and may be too complex for many implementations, but it illustrates the principle that handover is a decision under uncertainty.

4.2.25.230 Rule-Based Transition

Many flight systems use deterministic rules because they are:

transparent,
testable,
certifiable.

A rule may be:

\[ \boxed{ \rho<\rho_0 \land Q_L>Q_{min} \land \mathrm{NIS}_L<\gamma. } \]

This is often easier to verify than complex learned switching logic.

4.2.25.231 Hybrid Transition Logic

A practical architecture may combine:

deterministic state-machine rules,
statistical measurement validation,
covariance-based weighting.

This gives

\[ \boxed{ \text{Hybrid Handover} = \text{Discrete Mode Logic} + \text{Continuous Probabilistic Fusion}. } \]

This is often a useful engineering compromise.

A practical architecture

Discrete mode logic is useful for transparent and testable behavior, while probabilistic fusion handles continuous uncertainty. Combining the two often gives a good balance between determinism and statistical consistency.

4.2.25.232 Continuous Estimator, Discrete Mode Manager

The estimator can remain continuous:

\[ \hat{\mathbf x}(t), \mathbf P(t) \]

while the mode manager changes discretely:

\[ M_i \rightarrow M_j. \]

This structure is naturally described as a hybrid dynamical system.

4.2.25.233 Hybrid-System Interpretation

The system contains:

continuous state:

``\(math \mathbf x, \)``

discrete mode:

``math M. ``

Therefore:

\[ \boxed{ \text{Navigation System} = \text{Continuous Estimation} + \text{Discrete Logic}. } \]

Mode transition errors can therefore arise even when the estimator equations are correct.

4.2.25.234 Mode Chatter as a Hybrid-System Problem

Repeated switching near a threshold is a classic hybrid-system phenomenon.

Hysteresis and dwell time are specifically introduced to avoid this.

Thus these are not merely software conveniences; they are stability features of the mode logic.

4.2.25.235 Navigation-Mode Stability

A good mode system should satisfy:

no unnecessary chatter,
deterministic transitions,
recoverable faults,
bounded transient error.

This is analogous to stability requirements in continuous estimation.

4.2.25.236 Sensor-Handover Fault Tree

A useful engineering exercise is to consider causes of handover failure:

\[ \boxed{ \text{Handover Failure} } \]

may result from:

sensor acquisition failure,
invalid measurement,
timing mismatch,
calibration error,
mode logic error,
covariance mis-modeling.

Fault-tree thinking helps ensure all failure sources are tested.

4.2.25.237 Common-Cause Failures

Two sensors may fail simultaneously due to common conditions.

Examples:

shared power,
shared processor,
common pointing loss,
common timing source.

Therefore overlap does not automatically guarantee independent redundancy.

4.2.25.238 Sensor Diversity

Redundancy is stronger when sensors use different physical principles.

For example:

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

provides greater failure-mode diversity than two identical cameras in some conditions.

This connects directly to multi-sensor redundancy.

4.2.25.239 Mode-Dependent Redundancy

Some modes may have high redundancy.

Others may rely on one critical sensor.

Therefore:

\[ \boxed{ \text{Fault Tolerance} = f(M). } \]

The navigation system should know when redundancy has decreased.

4.2.25.240 Redundancy Status

A useful quantity may be

\[ \boxed{ N_{independent} } \]

representing the number of independent valid information sources for key state components.

This can contribute to navigation-health logic.

4.2.25.241 Graceful Degradation

The objective of redundancy and handover is often graceful degradation.

Instead of

\[ \boxed{ \text{Nominal} \rightarrow \text{Complete Failure}, } \]

prefer

\[ \boxed{ \text{Nominal} \rightarrow \text{Reduced Capability} \rightarrow \text{Recovery}. } \]

This is a central design goal for robust navigation.

Robustness means preserving useful capability

The purpose of redundancy and handover is not necessarily to maintain full nominal performance after every fault, but to preserve a valid, uncertainty-aware navigation solution whenever possible.

4.2.25.242 Mode-Dependent Accuracy Reporting

Navigation output should include uncertainty rather than one fixed accuracy label.

For example:

\[ \boxed{ \sigma_r(M), \quad \sigma_v(M), \quad \sigma_\theta(M). } \]

This allows downstream systems to interpret the current mode quantitatively.

4.2.25.243 Mode-Dependent Update Rate

Different modes may also have different effective navigation rates.

For example:

IMU propagation at high rate,
camera updates at medium rate,
LiDAR pose at lower rate.

The output state can still be propagated continuously even when measurement updates are less frequent.

4.2.25.244 High-Rate Common Output

A useful architecture is:

\[ \boxed{ \text{High-Rate Propagation} + \text{Asynchronous Sensor Corrections} \rightarrow \text{Continuous Navigation Output}. } \]

This means guidance sees one consistent output rate despite sensor handovers.

4.2.25.245 Handover and Output Latency

Even if the navigation state is continuous, output latency may change with mode.

The system should track:

\[ \boxed{ T_{nav,out}. } \]

A close-range mode relying on heavy vision processing may have different latency characteristics than a GNSS-dominant mode.

4.2.25.246 Time-Tagged Navigation Output

One solution is to time-tag the navigation state:

\[ \boxed{ \hat{\mathbf x}(t_k). } \]

Downstream consumers then know the epoch to which the estimate applies.

This is especially important when measurement processing latency changes between modes.

4.2.25.247 Predicted-to-Current Output

If the best corrected state corresponds to an earlier measurement epoch, the estimator may propagate it forward to current time before publication.

Thus:

\[ \boxed{ \hat{\mathbf x}(t_m) \rightarrow \text{Propagate} \rightarrow \hat{\mathbf x}(t_{now}). } \]

This helps maintain low-latency guidance input.

4.2.25.248 Sensor Handover Documentation

Each sensor transition should have documented:

entry criteria,
exit criteria,
validity checks,
covariance model,
fallback mode,
expected transient behavior.

This is important for verification and system integration.

4.2.25.249 Mode Transition Table

A useful design artifact is a table containing:

\[ \boxed{ M_i \rightarrow M_j } \]

with:

guard conditions,
actions,
failure response.

This makes mode logic explicit.

4.2.25.250 Sensor-Use Matrix

Another useful artifact is a matrix showing active sensors by mode.

For example conceptually:

\[ \boxed{ \begin{array}{c|cccc} & GNSS & Camera & LiDAR & IMU\\ \hline Far & 1 & 0/1 & 0 & 1\\ Mid & 1 & 1 & 0/1 & 1\\ Close & 0/1 & 1 & 1 & 1 \end{array} } \]

The actual matrix is mission dependent.

4.2.25.251 Requirement Matrix

For each mode, define required limits such as:

\[ \sigma_r^{max}, \qquad \sigma_v^{max}, \qquad \sigma_\theta^{max}. \]

This allows mode readiness to be checked quantitatively.

4.2.25.252 Sensor Performance Map

Sensor characterization should provide performance as a function of:

\[ \boxed{ \text{Range}, \text{Geometry}, \text{Quality}, \text{Environment}. } \]

This data supports rational handover threshold selection.

4.2.25.253 Why Datasheet Accuracy Alone Is Not Enough

Sensor datasheets may provide one nominal accuracy number.

Handover design requires more information:

range dependence,
update rate,
latency,
geometry dependence,
dropout probability.

Therefore system-level testing remains essential.

4.2.25.254 Transition Design From Measured Data

A strong engineering process is:

\[ \boxed{ \text{Sensor Characterization} \rightarrow \text{Performance Models} \rightarrow \text{Transition Logic}. } \]

This is better than selecting switch points arbitrarily.

4.2.25.255 Sensor Handover and Adaptive Fusion

Handover logic naturally connects to adaptive fusion.

Instead of fixed

\[ \mathbf Q, \mathbf R, \]

the estimator may modify them online according to:

sensor quality,
dynamics,
environment.

This becomes the subject of the later adaptive sensor fusion section.

4.2.25.256 Difference Between Handover and Adaptive Fusion

Handover changes the active sensor configuration or mode.

Adaptive fusion changes estimator parameters continuously.

Thus:

\[ \boxed{ \text{Handover} = \text{Discrete Configuration Change} } \]

while

\[ \boxed{ \text{Adaptive Fusion} = \text{Continuous Parameter Adjustment}. } \]

They can operate together.

4.2.25.257 Robust Mode-Dependent Fusion

A robust architecture may combine:

\[ \boxed{ \text{Mode Logic} + \text{Sensor Validity} + \text{Statistical Gating} + \text{Adaptive Covariance} + \text{FDIR}. } \]

Each component addresses a different failure mechanism.

4.2.25.258 Common Implementation Mistake: Switching on Range Only

One common mistake is:

\[ \boxed{ \rho<\rho_0 \Rightarrow \text{Switch Sensor}. } \]

This ignores:

whether the new sensor is valid,
whether its geometry is good,
whether its covariance is acceptable,
whether it has converged.

Range should normally be only one part of the transition logic.

4.2.25.259 Common Implementation Mistake: Resetting State

Replacing the current state with a new sensor solution can introduce discontinuity.

Prefer:

\[ \boxed{ \text{Measurement Update} } \]

over

\[ \boxed{ \text{State Replacement} } \]

unless explicit reinitialization is required.

4.2.25.260 Common Implementation Mistake: Ignoring Covariance

A new sensor may appear numerically close to the current estimate.

But if its covariance is unknown, the estimator cannot determine how strongly to trust it.

Thus handover without uncertainty modeling is incomplete.

4.2.25.261 Common Implementation Mistake: No Overlap

Transitioning only after the previous sensor is lost creates a blind boundary.

Whenever possible:

\[ \boxed{ \text{Activate New Sensor Before Old Sensor Becomes Unusable}. } \]

This provides time for validation.

4.2.25.262 Common Implementation Mistake: No Hysteresis

Using one identical threshold for both forward and reverse transition can create mode chatter.

Always consider:

hysteresis,
persistence,
dwell.

4.2.25.263 Common Implementation Mistake: Treating Availability as Accuracy

A sensor producing data is not necessarily accurate.

Validity should include measurement-quality checks.

4.2.25.264 Common Implementation Mistake: Treating Quality as Independence

Two high-quality sensors may share the same bias source.

Their apparent agreement does not prove independence.

Cross-correlation matters.

4.2.25.265 Common Implementation Mistake: Ignoring Processing Delay

A camera or LiDAR pose can be precise but old.

The estimator should use measurement epoch, not packet-arrival time.

4.2.25.266 Common Implementation Mistake: No Recovery Logic

A robust architecture must specify what happens if the new sensor fails after handover.

Otherwise one successful nominal transition is not enough to establish reliability.

4.2.25.267 Practical Flight-Software Sequence

A representative flight-software cycle may be:

propagate state,
propagate covariance,
read current navigation mode,
check sensor-health flags,
evaluate transition guards,
pre-activate required sensors,
process available measurements,
validate quality,
form innovations,
apply statistical gates,
perform measurement updates,
update confidence counters,
update mode readiness,
commit or abort pending transition,
update navigation validity,
publish state, covariance, mode, and health.

4.2.25.268 Published Navigation Interface

A useful output may be

\[ \boxed{ \{ \hat{\mathbf x}, \mathbf P, M_{nav}, \texttt{NAV\_VALID}, \texttt{SENSOR\_HEALTH}, \texttt{MODE\_READY} \}. } \]

This communicates both estimate and operating context.

4.2.25.269 Practical Design Philosophy

A robust mode-dependent fusion system should:

define sensor operating envelopes,
define navigation modes explicitly,
avoid switching on range alone,
pre-activate new sensors,
use overlap regions,
validate new sensors statistically,
use hysteresis,
use dwell time where appropriate,
maintain one continuous navigation state where possible,
preserve covariance continuity,
model timing correctly,
maintain frame consistency,
use realistic measurement covariance,
avoid arbitrary sensor priority,
monitor observability,
support degraded modes,
include fallback logic,
test reverse transitions,
test fault-driven transitions,
validate transitions statistically.

Engineering principle

Reliable handover comes from measured readiness, explicit transition logic, overlapping coverage, correct timing and frames, realistic covariance, observability checks, and tested fallback behavior—not from a single range threshold.

4.2.25.270 Key Takeaways

1. No single sensor is usually optimal throughout an entire navigation scenario.

\[ \boxed{ \text{Operating Condition Changes} \rightarrow \text{Sensor Usefulness Changes}. } \]

2. Sensor handover should be treated as an information transition, not a simple hardware switch.

3. The preferred sequence is generally

\[ \boxed{ \text{Old Sensor} \rightarrow \text{Overlap} \rightarrow \text{New Sensor Dominant}. } \]

4. Sensor validity is different from hardware availability.

5. Measurement validity is different from sensor validity.

6. Range should not normally be the only handover criterion.

7. Covariance, geometry, and sensor quality matter.

8. Hysteresis prevents repeated switching near boundaries.

\[ \boxed{ \rho_{exit} > \rho_{enter}. } \]

9. Dwell time prevents one transient condition from triggering mode change.

10. Newly activated sensors should be validated before full trust.

11. Sensor confidence can be increased gradually.

12. Hard state replacement can create artificial jumps.

13. A continuous fused state with changing sensor weighting is usually preferable.

14. Covariance should remain physically consistent through transitions.

15. Unrealistically small measurement covariance can cause covariance collapse.

16. Frames and timestamps must be aligned before cross-sensor comparison.

17. Sensor overlap enables cross-validation.

18. Overlap also improves fault isolation and calibration checks.

19. Planned handover and fault-driven handover are different problems.

20. A degraded mode can preserve useful navigation after sensor loss.

21. Removing a sensor can change observability.

22. Navigation mode and mission mode are not necessarily identical.

23. Requested mode and active mode should be distinguished.

24. Navigation readiness should be based on actual estimator capability.

\[ \boxed{ \text{Readiness} = \text{Valid Sensors} + \text{Acceptable Covariance} + \text{Adequate Observability}. } \]

25. Transition testing should include state jumps, covariance behavior, settling time, and recovery.

26. Monte Carlo tests should vary timing, noise, bias, dropout, alignment, and transition thresholds.

27. Handover logic should include fallback and abort paths.

28. Sensor processing latency is part of the handover problem.

29. Sensor handover and redundancy are closely connected.

30. Sensor handover and adaptive fusion are related but not identical.

\[ \boxed{ \text{Handover} = \text{Discrete Configuration Change} } \]

\[ \boxed{ \text{Adaptive Fusion} = \text{Continuous Estimator Adjustment}. } \]

31. The central engineering principle is

\[ \boxed{ \begin{array}{c} \text{A navigation system should not switch sensors merely because a range boundary was crossed.}\\[4pt] \text{It should transition only when the new sensor set is valid, informative,}\\[4pt] \text{statistically consistent, and capable of supporting the required navigation state.}\\[4pt] \text{The state and covariance should remain continuous while the information sources evolve.} \end{array} } \]

The natural next section is 4.2.26 Redundancy and Multi-Sensor Fusion, where the focus shifts from transitioning between sensor sets to operating multiple redundant sensors simultaneously, including voting, weighted fusion, cross-checking, fault isolation, covariance-aware combination, and graceful degradation.

Next: 4.2.26 Redundancy and Multi-Sensor Fusion

After developing sensor handover, overlapping operating envelopes, validity logic, covariance continuity, hysteresis, dwell time, transition guards, observability, degraded modes, fault-driven switching, and verification of mode transitions, the next section focuses on how multiple redundant sensors can operate simultaneously while preserving consistency, fault tolerance, and graceful degradation.

4.2.26 Redundancy and Multi-Sensor Fusion

Multiple gyroscopes, star trackers, GNSS receivers, cameras, and redundant sensor channels; voting, weighted fusion, covariance-aware combination, fault isolation, cross-checking, sensor diversity, common-cause failures, and graceful degradation.

Continue to Redundancy and Multi-Sensor Fusion →