Multi-Rate and Asynchronous Sensor Fusion

4.2.13 Multi-Rate and Asynchronous Sensor Fusion

Real spacecraft navigation systems almost never receive all sensor measurements at the same rate, at the same time, or from the same clock.

An IMU may generate measurements at

\[ \boxed{ 100\text{–}1000~\mathrm{Hz} } \]

while GNSS may update at only

\[ \boxed{ 1\text{–}20~\mathrm{Hz}. } \]

A star tracker may provide attitude at

\[ \boxed{ 1\text{–}20~\mathrm{Hz}, } \]

while a camera or LiDAR may produce measurements irregularly depending on

• image exposure,
• image-processing time,
• target visibility,
• feature detection,
• communication delay,
• processor scheduling.

Therefore, a practical navigation system cannot assume

\[ \boxed{ \text{All Sensors Update Simultaneously}. } \]

Instead, it must support

\[ \boxed{ \text{Continuous or High-Rate State Propagation} + \text{Asynchronous Measurement Corrections}. } \]

This is the central idea of multi-rate and asynchronous sensor fusion.

A typical spacecraft estimator may operate conceptually as

\[ \boxed{ \text{High-Rate IMU / Gyro Propagation} } \]

\[ \downarrow \]

\[ \boxed{ \text{GNSS Update Whenever Available} } \]

\[ \downarrow \]

\[ \boxed{ \text{Star-Tracker Update Whenever Available} } \]

\[ \downarrow \]

\[ \boxed{ \text{Camera / LiDAR Update Whenever Available}. } \]

The estimator therefore evolves according to the time of each measurement, rather than according to one artificial common sensor sampling rate.

4.2.13.1 Why Multi-Rate Sensor Fusion Is Necessary

Different spacecraft sensors are designed for different physical purposes.

For example:

Gyroscope

Provides high-rate angular-rate information:

\[ \boxed{ \boldsymbol\omega_m } \]

but suffers from

• bias,
• drift,
• noise.

Accelerometer

Provides high-rate specific force:

\[ \boxed{ \mathbf f_m } \]

but also suffers from

• bias,
• scale-factor error,
• noise,
• misalignment.

GNSS

Provides relatively low-rate absolute position and velocity:

\[ \boxed{ \mathbf r, \mathbf v } \]

but often with much lower frequency than IMU data.

Star Tracker

Provides precise absolute attitude:

\[ \boxed{ \mathbf q } \]

but typically at a lower rate than gyroscopes.

Camera

May provide

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

or

\[ \boxed{ \text{Relative Pose} } \]

only when image processing is complete.

LiDAR

May provide

\[ \boxed{ \text{Range / Bearing / Pose} } \]

at another independent rate.

Therefore:

\[ \boxed{ f_{\text{gyro}} \neq f_{\text{GNSS}} \neq f_{\text{camera}} \neq f_{\text{LiDAR}}. } \]

4.2.13.2 Typical Spacecraft Sensor Rates

A representative sensor-rate hierarchy may look like

\[ \boxed{ f_{\text{IMU}} > f_{\text{gyro}} > f_{\text{GNSS}} > f_{\text{camera}} > f_{\text{star tracker}} } \]

although actual values depend on the mission.

For example:

These are only illustrative values.

The important concept is that the rates are different.

4.2.13.3 High-Rate Propagation and Low-Rate Correction

The most common navigation architecture is

\[ \boxed{ \text{High-Rate Sensor} \rightarrow \text{State Propagation} } \]

combined with

\[ \boxed{ \text{Low-Rate Absolute Sensor} \rightarrow \text{State Correction}. } \]

For example:

\[ \boxed{ \text{Gyro} \rightarrow \text{Attitude Propagation} } \]

and

\[ \boxed{ \text{Star Tracker} \rightarrow \text{Attitude Correction}. } \]

Similarly:

\[ \boxed{ \text{IMU} \rightarrow \text{Position / Velocity Propagation} } \]

while

\[ \boxed{ \text{GNSS} \rightarrow \text{Position / Velocity Correction}. } \]

4.2.13.4 Why High-Rate Sensors Are Useful

High-rate inertial sensors capture fast spacecraft motion.

For example, a gyroscope may detect a rapid slew long before a low-rate star tracker provides its next attitude measurement.

Therefore inertial propagation provides

\[ \boxed{ \text{High Temporal Resolution}. } \]

But because inertial sensors integrate noise and bias, their error accumulates.

Thus high-rate propagation alone is not sufficient.

4.2.13.5 Why Low-Rate Absolute Sensors Are Useful

Absolute sensors provide information that limits accumulated inertial drift.

For example,

\[ \boxed{ \text{Gyro Bias} \rightarrow \text{Attitude Drift} } \]

but a star tracker periodically provides an absolute attitude reference.

Similarly,

\[ \boxed{ \text{Accelerometer Bias} \rightarrow \text{Velocity / Position Drift} } \]

while GNSS periodically corrects those errors.

Therefore:

\[ \boxed{ \text{High-Rate Relative Information} + \text{Low-Rate Absolute Information} = \text{Robust Navigation}. } \]

4.2.13.6 Synchronous Fusion vs Asynchronous Fusion

In a synchronous system, all measurements are assumed to arrive at the same discrete time:

\[ \boxed{ t_k. } \]

One might construct a combined measurement vector

\[ \mathbf z_k = \begin{bmatrix} \mathbf z_{GNSS}\\ \mathbf z_{camera}\\ \mathbf z_{LiDAR} \end{bmatrix}. \]

But this is often unrealistic.

In an asynchronous system, measurements arrive at

\[ t_{GNSS}, \qquad t_{camera}, \qquad t_{LiDAR} \]

independently.

The estimator should therefore process each measurement at its own valid timestamp.

4.2.13.7 Event-Driven Measurement Updates

A practical architecture is event driven.

State propagation runs continuously or at a fixed high rate.

Whenever a measurement arrives:

\[ \boxed{ \text{Measurement Event} \rightarrow \text{Perform Measurement Update}. } \]

Thus:

\[ \boxed{ \text{No New Measurement} \rightarrow \text{Prediction Only} } \]

while

\[ \boxed{ \text{Measurement Available} \rightarrow \text{Prediction + Correction}. } \]

4.2.13.8 Generic Multi-Rate Filter Structure

The estimator may maintain

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

and

\[ \mathbf P(t). \]

At every propagation interval:

\[ \boxed{ \hat{\mathbf x}_{k+1}^{-} = f( \hat{\mathbf x}_k^{+}, \mathbf u_k ) } \]

and

\[ \boxed{ \mathbf P_{k+1}^{-} = \mathbf\Phi_k \mathbf P_k^{+} \mathbf\Phi_k^T + \mathbf Q_k. } \]

If no measurement exists:

\[ \boxed{ \hat{\mathbf x}_{k+1}^{+} = \hat{\mathbf x}_{k+1}^{-}. } \]

If a measurement exists, perform the appropriate update.

4.2.13.9 Variable Propagation Interval

In asynchronous processing, the time step is not always constant.

Instead,

\[ \boxed{ \Delta t_k = t_k-t_{k-1}. } \]

The propagation equations must use the actual elapsed time.

Therefore:

\[ \boxed{ \mathbf\Phi = \mathbf\Phi(\Delta t_k) } \]

and

\[ \boxed{ \mathbf Q_d = \mathbf Q_d(\Delta t_k). } \]

Using a fixed \Delta t when actual timing varies introduces state and covariance errors.

4.2.13.10 Process-Noise Scaling with Time

For simple models, discrete process noise may scale approximately as

\[ \boxed{ Q_d \propto \Delta t. } \]

For integrated states, higher-order terms may appear:

\[ \Delta t^2, \qquad \Delta t^3, \qquad \Delta t^4. \]

Therefore asynchronous estimators must recompute or appropriately scale

\[ Q_d \]

whenever

\[ \Delta t \]

changes.

4.2.13.11 Multi-Rate Gyro and Star-Tracker Fusion

Consider

\[ f_g = 100~\mathrm{Hz} \]

and

\[ f_{ST} = 5~\mathrm{Hz}. \]

The gyro propagation occurs every

\[ \boxed{ 0.01~\mathrm{s}. } \]

The star tracker updates every

\[ \boxed{ 0.2~\mathrm{s}. } \]

Thus approximately 20 gyro propagation steps occur between star-tracker updates.

Conceptually:

\[ \boxed{ G\,G\,G\,G\,G\,G\,G\,G\,G\,G } \]

\[ \boxed{ G\,G\,G\,G\,G\,G\,G\,G\,G\,G } \]

\[ \boxed{ ST~Update. } \]

4.2.13.12 Multi-Rate IMU and GNSS Fusion

Suppose

\[ f_{\text{IMU}} = 200~\mathrm{Hz} \]

and

\[ f_{\text{GNSS}} = 10~\mathrm{Hz}. \]

Then IMU propagation occurs every

\[ 5~\mathrm{ms} \]

while GNSS correction occurs every

\[ 100~\mathrm{ms}. \]

There are approximately

\[ \boxed{ 20 } \]

IMU updates between GNSS measurements.

This is a classic strapdown-navigation architecture.

4.2.13.13 Propagation State

For inertial navigation, the nominal state may contain

\[ \boxed{ \mathbf x = \begin{bmatrix} \mathbf r\\ \mathbf v\\ \mathbf q\\ \mathbf b_g\\ \mathbf b_a \end{bmatrix}. } \]

High-rate IMU data propagates

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

Lower-rate measurements correct the accumulated navigation errors and biases.

4.2.13.14 Attitude Propagation with Gyro

The bias-corrected angular rate is

\[ \boxed{ \hat{\boldsymbol\omega} = \boldsymbol\omega_m - \hat{\mathbf b}_g. } \]

Then the quaternion is propagated using

\[ \boxed{ \dot{\hat{\mathbf q}} = \frac12 \Omega( \hat{\boldsymbol\omega} ) \hat{\mathbf q}. } \]

This propagation occurs at the gyroscope rate.

4.2.13.15 Translational Propagation with Accelerometer

A simplified inertial navigation relation is

\[ \boxed{ \dot{\mathbf v} = \mathbf C_{IB}( \mathbf f_m-\hat{\mathbf b}_a ) + \mathbf g. } \]

Then

\[ \boxed{ \dot{\mathbf r} = \mathbf v. } \]

These equations can be integrated at the accelerometer update rate.

4.2.13.16 Measurement Update Does Not Need to Match Propagation Rate

Suppose the filter propagates at

\[ 200~\mathrm{Hz}. \]

GNSS may update at

\[ 10~\mathrm{Hz}. \]

Camera may update at

\[ 7.3~\mathrm{Hz} \]

and LiDAR at

\[ 12~\mathrm{Hz}. \]

There is no requirement that these rates be integer multiples of each other.

The filter should use timestamps, not assumed integer scheduling relationships.

4.2.13.17 Independent Sensor Clocks

Each sensor may maintain its own internal clock.

Therefore:

\[ \boxed{ t_{\text{IMU}} \neq t_{\text{camera}} \neq t_{\text{LiDAR}} \neq t_{\text{computer}}. } \]

Differences can arise from

• clock offset,
• clock drift,
• oscillator error,
• transport delay,
• software buffering.

These timing differences must eventually be reconciled.

4.2.13.18 Measurement Timestamp

Every sensor measurement should ideally include

\[ \boxed{ t_{\text{measurement}}. } \]

This is the time at which the physical phenomenon was measured.

It is not necessarily equal to

\[ \boxed{ t_{\text{arrival}}. } \]

The distinction is fundamental.

4.2.13.19 Measurement Time vs Arrival Time

Suppose a camera captures an image at

\[ t=10.000~\mathrm{s}. \]

Image processing takes

\[ 80~\mathrm{ms}. \]

The pose estimate may therefore reach the estimator at

\[ t=10.080~\mathrm{s}. \]

But the measurement belongs to

\[ \boxed{ 10.000~\mathrm{s}, } \]

not

\[ 10.080~\mathrm{s}. \]

Using arrival time instead of measurement time introduces temporal inconsistency.

4.2.13.20 Exposure Time

For cameras, even the phrase “measurement time” may require definition.

An image may have exposure interval

\[ [t_s,t_e]. \]

A common convention is to timestamp at the exposure midpoint:

\[ \boxed{ t_m = \frac{t_s+t_e}{2}. } \]

For rapidly rotating spacecraft, exposure duration itself can affect the measurement.

4.2.13.21 LiDAR Timestamping

A LiDAR measurement may also be generated over a finite scan interval.

A complete scan may contain points corresponding to different times.

Therefore a point cloud is not always one instantaneous measurement.

This is particularly important for

• scanning LiDAR,
• rapidly moving spacecraft,
• close-range RPO.

4.2.13.22 Event-Driven Filter Timeline

A realistic timeline might be

\[ t_0: \text{IMU} \]

\[ t_1: \text{IMU} \]

\[ t_2: \text{IMU + GNSS} \]

\[ t_3: \text{IMU} \]

\[ t_4: \text{IMU + Camera} \]

\[ t_5: \text{IMU + LiDAR}. \]

The estimator processes whichever measurements are valid at each time.

4.2.13.23 Sequential Measurement Updates

If multiple independent measurements arrive at approximately the same time, they can be processed sequentially.

For example:

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

followed by

\[ \boxed{ \text{Star-Tracker Update} } \]

followed by

\[ \boxed{ \text{LiDAR Update}. } \]

For a linear Gaussian filter with independent measurements, sequential updates are mathematically equivalent to a batch update under ideal assumptions.

4.2.13.24 Batch Measurement Update

Alternatively, measurements may be stacked:

\[ \boxed{ \mathbf z = \begin{bmatrix} \mathbf z_1\\ \mathbf z_2\\ \mathbf z_3 \end{bmatrix}. } \]

The measurement matrix becomes

\[ \boxed{ \mathbf H = \begin{bmatrix} \mathbf H_1\\ \mathbf H_2\\ \mathbf H_3 \end{bmatrix}. } \]

For independent noise:

\[ \boxed{ \mathbf R = \operatorname{blkdiag} ( R_1,R_2,R_3 ). } \]

But asynchronous measurements should not be artificially batched if their timestamps differ significantly.

4.2.13.25 Sequential vs Batch Fusion

Sequential fusion is often preferable in practical asynchronous systems because

• each sensor can update independently,
• different rates are easy to support,
• sensor dropout is simple,
• software architecture is modular.

Batch updates may be useful when measurements are truly synchronized.

4.2.13.26 Sensor-Specific Measurement Models

Each sensor has its own measurement model.

GNSS:

\[ \boxed{ z_G = h_G(x)+v_G. } \]

Camera:

\[ \boxed{ z_C = h_C(x)+v_C. } \]

LiDAR:

\[ \boxed{ z_L = h_L(x)+v_L. } \]

Star tracker:

\[ \boxed{ z_{ST} = h_{ST}(x)+v_{ST}. } \]

The estimator selects the appropriate

\[ h_j, H_j,R_j \]

when sensor j produces a measurement.

4.2.13.27 Sensor-Specific Measurement Dimensions

GNSS may provide six values:

\[ \boxed{ r_x,r_y,r_z,v_x,v_y,v_z. } \]

A monocular camera may provide only two image coordinates:

\[ \boxed{ u,v. } \]

LiDAR may provide range:

\[ \boxed{ \rho. } \]

Therefore the measurement dimension changes dynamically depending on which sensor updates.

The estimator must support this naturally.

4.2.13.28 Event-Driven EKF Update

Suppose sensor j produces

\[ z_j. \]

Compute

\[ \boxed{ r_j = z_j - h_j( \hat x^- ). } \]

Then

\[ \boxed{ S_j = H_jP^-H_j^T+R_j. } \]

Then

\[ \boxed{ K_j = P^-H_j^TS_j^{-1}. } \]

Update:

\[ \boxed{ \hat x^+ = \hat x^- + K_jr_j. } \]

Thus no common sensor rate is required.

4.2.13.29 Event-Driven ESKF Update

For an ESKF, nominal-state propagation may occur continuously at IMU rate.

When a measurement arrives:

\[ \boxed{ r_j \rightarrow \delta\hat x } \]

then

\[ \boxed{ x_{\text{nominal}} \leftarrow x_{\text{nominal}} \oplus \delta\hat x. } \]

The error state is then reset.

Again, the correction occurs only when the measurement is available.

4.2.13.30 Event-Driven MEKF Update

For an MEKF:

\[ \boxed{ \text{Gyro} \rightarrow \text{High-Rate Quaternion Propagation} } \]

while star tracker or vector sensors trigger measurement updates.

Thus:

\[ \boxed{ q^- \rightarrow \delta\theta \rightarrow q^+. } \]

This is inherently a multi-rate architecture.

4.2.13.31 Event-Driven UKF Update

The UKF can also operate asynchronously.

Propagation occurs whenever required.

When sensor j arrives:

\[ \boxed{ \chi_i^- \rightarrow h_j( \chi_i^- ) } \]

and the corresponding predicted measurement distribution is calculated.

Only the active sensor model is evaluated.

4.2.13.32 Event-Driven Particle Filter

Particle propagation can occur at the process-model rate.

When a new sensor measurement arrives:

\[ \boxed{ w_i \leftarrow w_i p( z_j|x_i ). } \]

Thus particle filters also naturally support multi-rate measurement likelihoods.

4.2.13.33 Different Update Frequencies Do Not Require Different Filters

A common misconception is that each sensor rate requires a separate estimator.

This is not necessary.

A single estimator may maintain one state and covariance while accepting different sensors asynchronously.

Thus:

\[ \boxed{ \text{Different Sensor Rates} \neq \text{Different Navigation States}. } \]

4.2.13.34 Propagation Frequency

The propagation rate should be high enough to represent vehicle dynamics accurately.

Potential considerations include

• angular rate,
• acceleration,
• orbital dynamics,
• control bandwidth,
• sensor sampling rate.

A filter propagating too slowly may introduce discretization error.

4.2.13.35 Estimator Rate vs Sensor Rate

The estimator itself may run at a fixed loop rate

\[ f_{\text{filter}} \]

while sensor arrivals are asynchronous.

For example:

\[ f_{\text{filter}} = 200~\mathrm{Hz}. \]

At each estimator tick:

1. process IMU data,
2. propagate state,
3. inspect measurement queue,
4. process all valid measurements.

This is one practical implementation.

4.2.13.36 Fully Event-Driven Estimator

Another implementation does not use one fixed estimator loop.

Instead:

\[ \boxed{ \text{Sensor Event} \rightarrow \text{Estimator Event}. } \]

Every timestamped measurement is inserted into a time-ordered event queue.

The estimator processes events chronologically.

This architecture can handle irregular sensors elegantly.

4.2.13.37 Sensor Buffer

A practical system may use separate buffers:

\[ \boxed{ \text{IMU Buffer} } \]

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

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

\[ \boxed{ \text{LiDAR Buffer}. } \]

Each stored item should ideally contain

• measurement value,
• timestamp,
• validity flag,
• sensor ID,
• covariance,
• sequence number.

4.2.13.38 Measurement Queue

Measurements can be combined into a time-ordered queue:

\[ \boxed{ (t_1,z_1), (t_2,z_2), \dots } \]

with

\[ t_1

The estimator processes measurements according to timestamp rather than arrival order when possible.

4.2.13.39 Data Association with Time

Correct timestamping is also important for data association.

A camera detection observed at

\[ t_1 \]

must be compared with the predicted target position at

\[ t_1, \]

not at the current processor time

\[ t_2. \]

Otherwise association gates can be wrong.

4.2.13.40 Multi-Sensor Fusion Example

Consider an RPO estimator using:

• IMU at 200 Hz,
• relative GNSS at 10 Hz,
• camera at 15 Hz,
• LiDAR at 5 Hz,
• star tracker at 5 Hz.

A possible sequence is:

\[ \boxed{ \text{IMU Propagation} } \]

repeated continuously.

Then, whenever available:

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

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

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

\[ \boxed{ \text{Star-Tracker Update}. } \]

4.2.13.41 RPO Far-Range Fusion

At far range:

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

may provide the primary navigation measurement.

Camera bearing information may be intermittent.

Thus:

\[ \boxed{ \text{IMU Propagation} + \text{GNSS Correction} + \text{Occasional Optical Update}. } \]

4.2.13.42 RPO Mid-Range Fusion

At mid range:

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

may both provide useful information.

The estimator should process whichever measurement arrives first.

There is no need to delay a valid camera measurement until the next GNSS epoch.

4.2.13.43 RPO Close-Range Fusion

At close range:

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

may dominate.

Relative GNSS may become less important.

LiDAR and camera updates can occur independently.

Thus the filter becomes strongly event-driven.

4.2.13.44 Capture-Phase Fusion

During capture, navigation updates may include

\[ \boxed{ r_{rel} } \]

\[ \boxed{ v_{rel} } \]

\[ \boxed{ q_{rel} } \]

\[ \boxed{ \omega_{rel}. } \]

These quantities may arrive from different sensors at different times.

The capture-readiness logic must use a state estimate propagated to a common current epoch.

4.2.13.45 Common Fusion Epoch

Before guidance or control uses the navigation solution, all estimates should correspond to the same time:

\[ \boxed{ t_{\text{nav}}. } \]

A camera measurement from

\[ t_c \]

and LiDAR measurement from

\[ t_L \]

may have been fused earlier, but the output state should be propagated to

\[ t_{\text{nav}}. \]

4.2.13.46 Asynchronous Sensor Availability

Some sensors may become unavailable temporarily.

For example:

\[ \boxed{ \text{Camera} \rightarrow \text{Unavailable During Poor Illumination}. } \]

LiDAR may remain available.

GNSS may experience blockage.

The filter should not require all sensors to be simultaneously healthy.

4.2.13.47 Sensor Dropout

If sensor j becomes unavailable:

\[ \boxed{ \text{Do Not Perform Its Measurement Update}. } \]

Continue using

\[ \boxed{ \text{Propagation + Remaining Sensors}. } \]

Covariance should naturally increase in state directions that lose observability.

4.2.13.48 Sensor Reacquisition

When a sensor returns, its measurement can be processed again.

However, after a long dropout, residuals may be large.

Therefore reacquisition may require

• validity checking,
• larger gates,
• covariance-aware acceptance,
• staged reintroduction.

4.2.13.49 Measurement Age

A useful quantity is

\[ \boxed{ \Delta t_{\text{age}} = t_{\text{current}} - t_{\text{measurement}}. } \]

The estimator should know whether a measurement is

• current,
• slightly delayed,
• excessively stale.

A stale measurement should not be treated as current.

4.2.13.50 Maximum Accepted Measurement Age

A system may define

\[ \boxed{ \Delta t_{\max}. } \]

If

\[ \Delta t_{\text{age}} > \Delta t_{\max}, \]

the measurement may be

• rejected,
• handled using delayed-update logic,
• processed through repropagation.

The correct response depends on mission requirements.

4.2.13.51 Independent Sensor Processing Time

Measurement generation latency may differ by sensor.

For example:

\[ \boxed{ \tau_{\text{IMU}} \approx 1~\mathrm{ms} } \]

while image-based pose estimation may require

\[ \boxed{ \tau_{\text{camera}} = 50\text{–}200~\mathrm{ms}. } \]

Therefore asynchronous fusion and latency management are closely related.

This leads directly to the next section on time synchronization and delayed measurements.

4.2.13.52 State Interpolation

Suppose a sensor measurement time falls between two stored navigation states:

\[ t_k < t_m < t_{k+1}. \]

One strategy is to interpolate the state.

For linear quantities:

\[ \boxed{ x(t_m) \approx (1-\alpha)x_k + \alpha x_{k+1} } \]

where

\[ \boxed{ \alpha = \frac{t_m-t_k} {t_{k+1}-t_k}. } \]

4.2.13.53 Quaternion Interpolation

Quaternion attitude should not generally be interpolated linearly.

A better approach is spherical linear interpolation:

\[ \boxed{ q(t_m) = \operatorname{SLERP} ( q_k, q_{k+1}, \alpha ). } \]

This preserves unit quaternion geometry.

4.2.13.54 State Propagation to Measurement Time

Instead of interpolation, the estimator can propagate the previous state directly to the measurement timestamp:

\[ \boxed{ x(t_m) = f( x(t_k), t_m-t_k ). } \]

Then perform the measurement update.

This is often preferable when a reliable process model is available.

4.2.13.55 Propagate-Update-Propagate Architecture

A delayed but still manageable measurement can be processed as:

\[ \boxed{ x(t_k) } \]

\[ \downarrow \]

\[ \boxed{ \text{Propagate to }t_m } \]

\[ \downarrow \]

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

\[ \downarrow \]

\[ \boxed{ \text{Propagate to Current Time}. } \]

This concept becomes central to delayed-measurement handling.

4.2.13.56 Multi-Rate Covariance Propagation

Covariance must be propagated whenever state is propagated.

Thus:

\[ \boxed{ P(t_m) = \Phi P(t_k) \Phi^T + Q_d. } \]

A multi-rate implementation must not update only the nominal state while leaving covariance at an old timestamp.

4.2.13.57 Sensor-Specific Measurement Covariance

Each sensor has its own covariance:

\[ \boxed{ R_{GNSS} } \]

\[ \boxed{ R_{camera} } \]

\[ \boxed{ R_{LiDAR} } \]

\[ \boxed{ R_{ST}. } \]

The correct matrix must be selected dynamically during each update.

4.2.13.58 Dynamic Measurement Covariance

Measurement uncertainty itself may vary with operating conditions.

For a camera,

\[ R_C \]

may depend on

• target range,
• number of detected features,
• image blur,
• illumination,
• pose-estimation confidence.

For GNSS,

\[ R_G \]

may depend on satellite geometry or signal quality.

Thus asynchronous fusion may also be quality adaptive.

4.2.13.59 Sensor Health Flag

Each measurement packet should ideally include a health or validity indication:

\[ \boxed{ \text{valid}_j. } \]

If

\[ \text{valid}_j=0, \]

the measurement should not be used.

Measurement arrival alone does not imply measurement validity.

4.2.13.60 Measurement Sequence Numbers

A sequence number helps detect

• dropped packets,
• duplicated measurements,
• reordered packets.

For example:

\[ \boxed{ N_k, N_{k+1}, N_{k+3} } \]

indicates a missing packet.

This information is useful in real-time distributed systems.

4.2.13.61 Duplicate Measurements

If the same measurement is accidentally processed twice, information is counted twice.

For a Kalman filter this can lead to

\[ \boxed{ P \text{ becoming artificially small}. } \]

Therefore duplicate detection is important.

4.2.13.62 Message Reordering

Communication networks may deliver packets out of order.

For example:

\[ t_1 \]

measurement may arrive after

\[ t_2 \]

measurement.

The estimator therefore needs either

• ordered buffering,
• out-of-sequence handling,
• rejection of stale measurements.

4.2.13.63 Asynchronous Sensor Fusion Is Not the Same as Delayed Fusion

A measurement may be asynchronous but not delayed.

Example:

camera produces measurements at irregular times, but each arrives immediately.

That is asynchronous.

A measurement becomes delayed when

\[ \boxed{ t_{\text{arrival}} > t_{\text{measurement}} } \]

by a non-negligible interval.

These are related but distinct problems.

4.2.13.64 Clock Offset

Suppose sensor clock time is

\[ t_s. \]

Navigation computer time is

\[ t_n. \]

There may be constant offset

\[ \boxed{ \Delta t_o = t_s-t_n. } \]

Without calibration, measurements may be systematically fused at the wrong epoch.

4.2.13.65 Clock Drift

Sensor clocks may also drift.

A simple model is

\[ \boxed{ t_s = a\,t_n+b. } \]

Here,

• b is clock offset,
• a represents clock-rate error.

Long-duration missions may require continuous clock synchronization.

4.2.13.66 Time Synchronization Sources

Possible spacecraft synchronization sources include

• GNSS time,
• onboard master clock,
• PPS signals,
• hardware trigger lines,
• time-distribution buses,
• PTP-like protocols,
• spacecraft time correlation.

The architecture depends on mission hardware.

4.2.13.67 PPS Synchronization

GNSS receivers may provide a pulse-per-second signal:

\[ \boxed{ \text{PPS}. } \]

This can synchronize sensor or processor clocks to a common epoch.

Accurate PPS synchronization is especially useful when multiple sensors require sub-millisecond alignment.

4.2.13.68 Hardware Triggering

Some sensors can be triggered simultaneously using a hardware line.

For example:

\[ \boxed{ \text{Common Trigger} \rightarrow \text{Camera Exposure + LiDAR Measurement}. } \]

This can greatly simplify sensor-fusion timing.

But processing latencies may still differ after acquisition.

4.2.13.69 Software Synchronization

When hardware triggering is unavailable, timestamps must be aligned in software.

This requires

• clock calibration,
• latency characterization,
• buffering,
• interpolation,
• synchronization logic.

Software-only synchronization is generally less precise than hardware synchronization.

4.2.13.70 Timing Error as Navigation Error

Suppose relative velocity is

\[ v_{rel}. \]

If a position measurement is applied with timestamp error

\[ \Delta t, \]

the induced position mismatch is approximately

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

Thus even small timing errors can matter when relative motion is fast.

4.2.13.71 Attitude Timing Error

If spacecraft angular rate is

\[ \omega, \]

and attitude timestamp error is

\[ \Delta t, \]

the angular error is approximately

\[ \boxed{ \Delta\theta \approx \omega\Delta t. } \]

During fast slews, millisecond timing errors can become important.

4.2.13.72 Camera Timing Error During RPO

Suppose camera line-of-sight is measured at

\[ t_c \]

but compared against predicted target state at

\[ t_c+\Delta t. \]

The residual then contains both

• actual navigation error,
• timing-induced geometric error.

The filter may mistakenly interpret timing error as state error.

4.2.13.73 Latency Can Mimic Bias

Persistent sensor latency can create residual patterns that resemble

• position bias,
• velocity bias,
• attitude bias.

Therefore some apparent calibration errors may actually be timing errors.

This is why sensor timing should be verified before aggressively tuning bias states.

4.2.13.74 Multi-Rate Observability

Different sensor rates affect observability over time.

For example, high-rate gyro measurements alone do not make absolute attitude observable.

Absolute attitude information arrives only when

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

updates.

Therefore uncertainty may grow between absolute updates.

4.2.13.75 Covariance Sawtooth Behaviour

A multi-rate estimator often shows covariance that

\[ \boxed{ \text{Grows During Prediction} } \]

and then

\[ \boxed{ \text{Drops During Measurement Update}. } \]

This produces a characteristic sawtooth pattern.

That behavior can be completely normal.

4.2.13.76 Example of Covariance Evolution

Between GNSS updates:

\[ P_r \uparrow \]

and

\[ P_v \uparrow. \]

When GNSS arrives:

\[ P_r \downarrow \]

and

\[ P_v \downarrow. \]

The magnitude of growth depends on

• process noise,
• IMU quality,
• time between measurements.

4.2.13.77 Sensor Rate and Estimation Accuracy

Increasing an absolute measurement rate can improve performance because uncertainty has less time to grow between updates.

However, more frequent measurements also increase

• processor load,
• bus traffic,
• power consumption.

Thus sensor rate is a system-level design trade.

4.2.13.78 Measurement Rate vs Measurement Quality

A high-rate noisy sensor is not always more useful than a lower-rate accurate sensor.

The filter naturally balances this through covariance.

For example:

\[ \boxed{ \text{High Rate + Large }R } \]

may contribute similar information to

\[ \boxed{ \text{Low Rate + Small }R. } \]

4.2.13.79 Information Rate

A useful conceptual quantity is information gained per unit time.

If a sensor provides covariance

\[ R \]

at rate

\[ f, \]

then roughly speaking its information contribution scales with

\[ \boxed{ fR^{-1} } \]

for simple independent measurements.

This is only a conceptual approximation but helps compare sensor architectures.

4.2.13.80 High-Rate Noise Correlation

Successive high-rate measurements may not be statistically independent.

Examples include

• filtered IMU outputs,
• correlated camera tracking errors,
• colored sensor noise.

If correlations are ignored, the filter may become overconfident.

4.2.13.81 Colored Noise

If measurement noise is temporally correlated,

\[ E[ v_kv_{k-1}^T ] \neq0. \]

Standard Kalman assumptions are violated.

Possible approaches include

• augmenting bias/noise states,
• whitening filters,
• more realistic stochastic models.

4.2.13.82 IMU Preintegration

In systems where IMU runs much faster than the main estimator, many IMU samples can be summarized using preintegration.

Conceptually:

\[ \boxed{ \text{Many IMU Samples} \rightarrow \Delta R,\Delta v,\Delta r. } \]

This is especially common in factor-graph and visual-inertial navigation architectures.

4.2.13.83 Why Preintegration Helps

Suppose an IMU runs at

\[ 1000~\mathrm{Hz} \]

but camera updates at

\[ 10~\mathrm{Hz}. \]

There are

\[ 100 \]

IMU samples between images.

Preintegration summarizes their cumulative motion while preserving appropriate uncertainty.

4.2.13.84 Zero-Order Hold

One simple multi-rate implementation holds the latest measurement constant until the next measurement.

For control signals, this may be represented as a zero-order hold.

However, for navigation measurements, the estimator should not repeatedly treat a held value as a new independent measurement.

Otherwise information is counted multiple times.

4.2.13.85 Critical Warning About Reusing Old Measurements

Suppose GNSS updates at

\[ 1~\mathrm{Hz} \]

but the filter runs at

\[ 100~\mathrm{Hz}. \]

If the same GNSS measurement is applied at every filter step, it is effectively used 100 times.

That produces severe overconfidence.

Therefore:

\[ \boxed{ \text{Each Measurement Must Normally Be Applied Once}. } \]

4.2.13.86 Measurement “New Data” Flag

A practical implementation should use a flag such as

\[ \boxed{ \text{newGNSS} } \]

or

\[ \boxed{ \text{measurementAvailable}. } \]

Only when

\[ \text{newGNSS}=1 \]

should the GNSS measurement update be executed.

4.2.13.87 Sample-and-Hold Display vs Estimator Update

It is acceptable to display the latest GNSS value continuously.

But display behavior is different from estimator behavior.

Thus:

\[ \boxed{ \text{Held Measurement for Display} \neq \text{Repeated Measurement Update}. } \]

4.2.13.88 Simulink Multi-Rate Implementation

A Simulink architecture may contain

• high-rate propagation subsystem,
• GNSS update subsystem,
• camera update subsystem,
• LiDAR update subsystem,
• star-tracker update subsystem.

Each subsystem can be triggered by its own valid-data event.

4.2.13.89 Simulink Rate Transitions

When signals cross between different sample rates, Rate Transition blocks may be required.

These help maintain deterministic data transfer between tasks.

However, the navigation meaning of the timestamp must still be preserved.

A rate-transition block alone does not solve sensor latency.

4.2.13.90 Simulink Function-Call Subsystems

An event-driven architecture can use function-call subsystems:

\[ \boxed{ \text{GNSS Event} \rightarrow \text{GNSS Update Subsystem} } \]

\[ \boxed{ \text{Camera Event} \rightarrow \text{Camera Update Subsystem}. } \]

This closely matches real asynchronous measurement processing.

4.2.13.91 MATLAB Implementation Pattern

A simplified software loop might conceptually be:

1. obtain next event,
2. read event timestamp,
3. propagate state to event timestamp,
4. identify sensor type,
5. build h,H,R,
6. validate measurement,
7. perform update,
8. continue.

Thus the estimator operates on a chronological stream of events.

4.2.13.92 Sensor Event Structure

A useful software structure is

\[ \boxed{ \text{MeasurementEvent} = \{ t, \text{sensorID}, z, R, \text{valid} \}. } \]

This standardizes asynchronous sensor handling.

4.2.13.93 Sensor-Specific Calibration

Before fusion, each sensor may require calibration for

• scale factor,
• bias,
• misalignment,
• lever arm,
• boresight,
• clock offset.

Multi-rate fusion does not eliminate calibration requirements.

4.2.13.94 Lever-Arm Correction

Suppose GNSS antenna and IMU are not located at the same point.

The measured position must be transformed using the lever arm.

During rotation, antenna velocity also includes rotational contribution:

\[ \boxed{ \mathbf v_A = \mathbf v_{CG} + \boldsymbol\omega \times \mathbf r_{A/CG}. } \]

At high rates, timing and lever-arm errors can interact.

4.2.13.95 Boresight Alignment

Camera or LiDAR frame may not align perfectly with body frame.

A constant rotation

\[ \boxed{ C_{BC} } \]

or

\[ \boxed{ C_{BL} } \]

must be included.

Without correct boresight calibration, asynchronous optical residuals may appear biased.

4.2.13.96 Multi-Rate Bias Estimation

Bias states may be propagated continuously:

\[ \dot b_g = n_{bg}. \]

But they are corrected only when informative absolute measurements arrive.

Thus gyro bias uncertainty may grow between star-tracker updates and decrease afterward.

4.2.13.97 Sensor Dropout and Bias Observability

During a long absolute-attitude sensor outage, gyro bias may become weakly observable.

Therefore:

\[ \boxed{ P_{b_g} \uparrow. } \]

When star-tracker measurements return, bias estimation improves again.

4.2.13.98 Multi-Rate Navigation Output

Although measurements arrive irregularly, guidance and control often require a fixed-rate navigation output.

For example:

\[ \boxed{ f_{\text{GNC}} = 50~\mathrm{Hz}. } \]

The estimator can output the latest state propagated to each control epoch.

4.2.13.99 Fixed-Rate GNC Output from Asynchronous Estimator

At control time

\[ t_c, \]

the navigation system provides

\[ \boxed{ \hat x(t_c), P(t_c). } \]

Measurements may have been fused at earlier irregular times.

The state is simply propagated to the control time before output.

4.2.13.100 Guidance Should Use State Age

A useful navigation output is

\[ \boxed{ t_{\text{last absolute update}}. } \]

Guidance can then know how long the estimator has been operating without external correction.

This may influence

• approach speed,
• hold decisions,
• abort logic.

4.2.13.101 Navigation Health Flag

A navigation solution should include a health indicator based on

• covariance,
• sensor availability,
• innovation consistency,
• update age,
• filter status.

Thus guidance should not receive only

\[ \hat x. \]

It should also know whether that estimate is trustworthy.

4.2.13.102 Capture Readiness and Sensor Timing

Suppose capture requires

\[ \boxed{ \|r_{rel}\|

and

\[ \boxed{ \|v_{rel}\|

These quantities must correspond to the same timestamp.

Using position from one epoch and velocity from another can produce incorrect capture readiness.

4.2.13.103 Multi-Rate Attitude and Translation Fusion

Attitude may update using star tracker at one rate.

Translation may update using GNSS or LiDAR at another.

But force and measurement transformations often depend on attitude.

Therefore a translational measurement at

\[ t_m \]

must use attitude corresponding to

\[ \boxed{ t_m. } \]

4.2.13.104 Frame Transformation at Measurement Time

Suppose camera measurement requires

\[ C_{HC}(t_m). \]

Using

\[ C_{HC}(t_{\text{current}}) \]

instead can introduce a false residual.

Thus time consistency applies not just to state values but also to coordinate transformations.

4.2.13.105 Thruster Events and Navigation Timing

During RPO, thruster firings may occur between measurements.

The state propagation must include the maneuver at the correct time.

If a thruster event occurs at

\[ t_b, \]

then propagation across that interval must account for the applied impulse or force.

4.2.13.106 Impulsive Maneuver Example

For impulsive velocity change

\[ \Delta v, \]

the state update at

\[ t_b \]

is

\[ \boxed{ v(t_b^+) = v(t_b^-) + \Delta v. } \]

All later sensor predictions must include this maneuver.

4.2.13.107 Continuous Thruster Firing

For finite-duration thrust,

\[ \boxed{ \dot v = \frac{F(t)}{m(t)} + a_{\text{external}}. } \]

Propagation through the burn interval should use the actual actuation timeline.

Multi-rate sensor measurements during the burn must be compared with that propagated state.

4.2.13.108 Control Command Timestamp

Navigation timing is also linked to control-command timing.

The filter should know when a command was actually applied, not merely when it was computed.

Possible delays include

• command generation,
• bus transmission,
• valve actuation,
• actuator dynamics.

4.2.13.109 Asynchronous Actuator Information

Actuator telemetry may itself arrive asynchronously.

For accurate propagation, the estimator may need

\[ \boxed{ \text{Actual Actuator State} } \]

rather than only commanded actuator state.

This is especially relevant when actuation delays are significant.

4.2.13.110 Multi-Rate Sensor Fusion and RPO Safety

During close RPO, a stale navigation estimate can be dangerous.

Therefore the system may define

\[ \boxed{ \Delta t_{\text{nav,max}}. } \]

If navigation information becomes too old:

\[ \boxed{ \text{Continue Approach} \rightarrow \text{Not Allowed}. } \]

The spacecraft may instead

• hold,
• retreat,
• abort.

4.2.13.111 Sensor Update Age by Mission Phase

Far from the target, longer update intervals may be acceptable.

Near capture, tighter timing requirements may apply.

Thus:

\[ \boxed{ \Delta t_{\max} = \Delta t_{\max}( \text{mission phase} ). } \]

4.2.13.112 Multi-Rate Fusion and Observability During RPO

At different ranges, different sensors provide observability.

Far range:

\boxed{ \text{GNSS}

may dominate.

Mid range:

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

Close range:

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

The estimator remains continuous while sensor information rates change.

4.2.13.113 Sensor Handover

During handover from sensor A to sensor B:

\[ \boxed{ A \rightarrow A+B \rightarrow B. } \]

An overlap period is often useful.

It allows

• consistency comparison,
• alignment verification,
• smoother transition.

4.2.13.114 Hard vs Soft Sensor Handover

Hard Handover

Immediately stop sensor A and start sensor B.

Soft Handover

Use both sensors during an overlap interval.

Soft handover generally provides better continuity and fault detection.

4.2.13.115 Covariance During Sensor Handover

The filter should not manually force covariance lower simply because a new sensor becomes active.

The covariance should change according to the actual information in the measurement update.

Thus:

\[ \boxed{ \text{New Sensor} \neq \text{Automatic Confidence}. } \]

4.2.13.116 Measurement Rejection in Multi-Rate Fusion

Every asynchronous measurement should still pass validation.

Possible checks include

• range limits,
• innovation magnitude,
• timestamp validity,
• sensor health,
• frame validity.

A fast sensor should not be trusted merely because it updates frequently.

4.2.13.117 Outlier Frequency Matters

Suppose a sensor has a low per-measurement outlier probability.

At a very high update rate, outliers may still occur frequently in time.

Therefore robust gating becomes even more important for high-rate sensors.

4.2.13.118 Innovation Sequence

For each sensor, maintain a separate innovation history:

\[ r_{GNSS}, \]

\[ r_{camera}, \]

\[ r_{LiDAR}. \]

This makes it easier to detect sensor-specific inconsistencies.

4.2.13.119 Sensor-Specific NIS

For each sensor j:

\[ \boxed{ NIS_j = r_j^TS_j^{-1}r_j. } \]

Different sensor dimensions require different chi-square thresholds.

Thus validation should be sensor specific.

4.2.13.120 Multi-Rate Logging

A good logging system should record:

• estimator time,
• sensor timestamp,
• arrival time,
• sensor ID,
• measurement,
• innovation,
• innovation covariance,
• update accepted/rejected,
• state before update,
• state after update.

This is invaluable for diagnosing timing problems.

4.2.13.121 Timing Diagnostics

Useful derived quantities include

\[ \boxed{ \text{latency} = t_{\text{arrival}} - t_{\text{measurement}} } \]

and

\[ \boxed{ \text{update interval} = t_{k} - t_{k-1}. } \]

Plotting these values often reveals synchronization issues that are invisible in ordinary state plots.

4.2.13.122 Sensor Jitter

Even nominally periodic sensors exhibit timing jitter.

For nominal sample period

\[ T, \]

actual period may be

\[ \boxed{ T_k = T+\delta T_k. } \]

A robust estimator should use actual timestamps rather than assuming perfect periodicity.

4.2.13.123 Dropped Sample Detection

If sensor timestamps normally satisfy

\[ t_{k+1}-t_k \approx T, \]

but suddenly

\[ t_{k+1}-t_k \approx 2T, \]

one sample may have been dropped.

The filter can continue, but covariance should propagate through the longer interval.

4.2.13.124 Multi-Rate Simulation

Simulation should represent the actual sensor rates rather than producing all sensors every solver step.

For example:

\[ f_{IMU}=200~\mathrm{Hz} \]

\[ f_{GNSS}=10~\mathrm{Hz} \]

\[ f_{camera}=5~\mathrm{Hz}. \]

Each sensor should generate measurements according to its own schedule.

4.2.13.125 Sensor-Clock Simulation

A higher-fidelity simulation may include

• clock offset,
• clock drift,
• jitter,
• packet delay.

Then

\[ t_{\text{sensor}} \]

and

\[ t_{\text{truth}} \]

are not assumed identical.

This is important before HIL testing.

4.2.13.126 Communication-Delay Simulation

Measurements may be delayed by

\[ \boxed{ \tau_{\text{comm}}. } \]

For each sensor:

\[ \boxed{ t_{\text{arrival}} = t_{\text{measurement}} + \tau_{\text{processing}} + \tau_{\text{communication}}. } \]

This provides realistic asynchronous behavior.

4.2.13.127 Monte Carlo Timing Errors

Timing uncertainty should be included in Monte Carlo analysis.

Randomize:

• clock offset,
• drift,
• jitter,
• processing latency,
• packet delay,
• dropout.

Evaluate sensitivity of navigation accuracy and consistency.

4.2.13.128 Verification Strategy

A multi-rate estimator should be verified incrementally.

4.2.13.128.1 Equal-Rate Test

Run all sensors at the same rate.

Verify baseline filter performance.

4.2.13.128.2 Two-Rate Test

Use high-rate IMU and low-rate GNSS.

Verify correct propagation between GNSS updates.

4.2.13.128.3 Irregular Measurement Test

Generate camera measurements at nonuniform intervals.

Verify each is processed at its own timestamp.

4.2.13.128.4 Dropout Test

Disable one sensor temporarily.

Verify covariance growth and continued propagation.

4.2.13.128.5 Reacquisition Test

Restore the sensor and verify stable convergence.

4.2.13.128.6 Duplicate-Measurement Test

Send the same packet twice.

Verify it is not processed twice.

4.2.13.128.7 Reordered-Packet Test

Deliver measurements out of order.

Verify buffering or delayed-update logic.

4.2.13.128.8 Timestamp-Jitter Test

Introduce timing jitter.

Verify variable-\Delta t propagation.

4.2.13.128.9 High-Dynamics Test

Perform fast slew or translation.

Verify timing sensitivity.

4.2.13.128.10 Sensor-Handover Test

Transition from GNSS to camera to LiDAR.

Verify estimator continuity.

4.2.13.129 Common Implementation Errors

Common errors include:

• applying a low-rate measurement repeatedly at every high-rate filter step,
• using arrival time instead of measurement time,
• assuming fixed \Delta t despite timing jitter,
• forgetting to scale Q_d with time,
• processing measurements out of chronological order without correction,
• mixing sensor clocks without synchronization,
• fusing stale measurements as current,
• using current attitude for an old camera measurement,
• failing to propagate covariance with the state,
• incorrect sensor-rate transitions,
• duplicate packet processing,
• ignoring packet loss,
• using one R for sensors with different quality,
• not updating health status after dropout,
• inconsistent coordinate frames at different timestamps,
• not logging timing information.

4.2.13.130 Real-Time Software Architecture

A robust architecture may contain:

\[ \boxed{ \text{Sensor Drivers} } \]

\[ \downarrow \]

\[ \boxed{ \text{Timestamping} } \]

\[ \downarrow \]

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

\[ \downarrow \]

\[ \boxed{ \text{Chronological Event Queue} } \]

\[ \downarrow \]

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

\[ \downarrow \]

\[ \boxed{ \text{Sensor-Specific Update} } \]

\[ \downarrow \]

\[ \boxed{ \text{Navigation Output}. } \]

4.2.13.131 Multi-Rate Fusion in One Diagram

The complete concept can be summarized as

\[ \boxed{ \text{High-Rate IMU / Gyro} } \]

\[ \downarrow \]

\[ \boxed{ \text{Continuous State + Covariance Propagation} } \]

while independent sensors provide:

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

\[ \boxed{ \text{Star Tracker at }t_{ST} } \]

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

\[ \boxed{ \text{LiDAR at }t_L. } \]

Each measurement triggers:

\[ \boxed{ \text{Propagate to Measurement Time} } \]

\[ \downarrow \]

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

\[ \downarrow \]

\[ \boxed{ \text{Perform Sensor-Specific Correction} } \]

\[ \downarrow \]

\[ \boxed{ \text{Continue Propagation}. } \]

Thus the estimator is driven by

\[ \boxed{ \text{Time} + \text{Measurement Events}, } \]

not by the assumption that every sensor shares one sample clock.

4.2.13.132 Key Equations at a Glance

Actual Propagation Interval

\[ \boxed{ \Delta t_k = t_k-t_{k-1}. } \]

State Prediction

\[ \boxed{ \hat x_k^- = f( \hat x_{k-1}^+, u_{k-1}, \Delta t_k ). } \]

Covariance Prediction

\[ \boxed{ P_k^- = \Phi_k P_{k-1}^+ \Phi_k^T + Q_d( \Delta t_k ). } \]

Sensor-Specific Innovation

\[ \boxed{ r_j = z_j - h_j( \hat x^- ). } \]

Innovation Covariance

\[ \boxed{ S_j = H_jP^-H_j^T+R_j. } \]

Kalman Gain

\[ \boxed{ K_j = P^-H_j^TS_j^{-1}. } \]

Measurement Update

\[ \boxed{ \hat x^+ = \hat x^- + K_jr_j. } \]

Measurement Age

\[ \boxed{ \Delta t_{\text{age}} = t_{\text{current}} - t_{\text{measurement}}. } \]

Timing-Induced Position Error Approximation

\[ \boxed{ \Delta r \approx v\Delta t. } \]

Timing-Induced Attitude Error Approximation

\[ \boxed{ \Delta\theta \approx \omega\Delta t. } \]

4.2.13.133 Key Takeaways

The most important concepts of multi-rate and asynchronous sensor fusion are:

• Real spacecraft sensors operate at different rates.
• They may also use independent clocks.
• High-rate IMU and gyroscope data are typically used for state propagation.
• Lower-rate GNSS, star tracker, camera, and LiDAR measurements provide corrections.
• The estimator should normally process measurements according to their measurement timestamps.
• Measurement time and arrival time are not necessarily the same.
• The propagation interval should use the actual

\[ \Delta t. \]

• Process covariance

\[ Q_d \]

must be consistent with the actual propagation duration.

• A low-rate measurement must not be repeatedly reused at every high-rate filter step.
• Each independent measurement should normally be incorporated once.
• Measurement updates can be event driven.
• Sequential sensor updates are convenient for asynchronous systems.
• Different sensors may use different

\[ h_j,\;H_j,\;R_j. \]

• Measurement dimensions may change dynamically.
• Multi-rate fusion works naturally with KF, EKF, ESKF, MEKF, UKF, and Particle Filters.
• Sensor dropout should result in prediction-only operation for the missing measurement source.
• Covariance generally grows during propagation and drops when measurements arrive.
• Sensor reacquisition should be validated before full trust is restored.
• State and covariance must refer to the same timestamp.
• Attitude used in camera or LiDAR transformations must correspond to the measurement epoch.
• Independent sensor clocks require synchronization or time correlation.
• Packet duplication, loss, and reordering must be detected.
• High-rate measurements may have correlated noise and should not automatically be treated as independent.
• Sensor handover is best handled with overlap when possible.
• Guidance and control should receive a state propagated to a common current epoch.
• Navigation outputs should include covariance, sensor health, and measurement-age information.
• Timing errors can appear as navigation biases.
• During RPO, timing requirements become increasingly strict near final approach and capture.
• Simulation and Monte Carlo testing should reproduce real sensor rates, latency, jitter, dropout, and asynchronous events.

The central implementation principle is

\[ \boxed{ \text{Propagate Continuously} + \text{Update Only When New Valid Measurements Arrive}. } \]

The central timing principle is

\[ \boxed{ \text{Fuse a Measurement With the State at the Time the Measurement Was Taken}. } \]

And the central warning is

\[ \boxed{ \text{A Measurement With the Correct Value but the Wrong Timestamp Is Still a Wrong Measurement for the Estimator}. } \]

Next: 4.2.14 Time Synchronization, Latency and Delayed Measurements

Multi-rate fusion establishes that sensors operate at different frequencies and measurement updates may occur asynchronously.

The next problem is more subtle.

A measurement may correspond to time

\[ \boxed{ t_m } \]

but reach the navigation computer only at

\[ \boxed{ t_a=t_m+\tau. } \]

The delay

\[ \boxed{ \tau } \]

may contain

\[ \boxed{ \tau = \tau_{\text{sensor}} + \tau_{\text{processing}} + \tau_{\text{communication}} + \tau_{\text{buffering}}. } \]

Therefore the next section should develop 4.2.14 Time Synchronization, Latency and Delayed Measurements, including:

• sensor timestamps,
• measurement time versus arrival time,
• clock offset,
• clock drift,
• PPS synchronization,
• master spacecraft time,
• camera exposure timing,
• LiDAR scan timing,
• communication latency,
• processing latency,
• buffering delay,
• state history buffers,
• propagation to measurement time,
• delayed measurement correction,
• repropagation,
• out-of-sequence measurements,
• fixed-lag smoothing,
• timestamp uncertainty,
• timing calibration,
• timing-error observability,
• latency estimation,
• software and hardware synchronization,
• RPO timing requirements,
• Monte Carlo timing-error analysis,
• and verification of delayed-measurement navigation systems.