Introduction to Out-of-Sequence Measurement Handling
In a multi-sensor tracking system, time lag can result in the time at which a sensor generates a measurement differing from the time at which the tracker or filter receives the measurement for processing. If, before receiving a measurement, the filter or tracker is updated by another measurement with a later timestamp, the delayed measurement is known as a out-of-sequence measurement (OOSM). For example, assume a measurement is taken at time τ, but is not available until time step k, where τ < k, then the measurement taken at time τ is an OOSM at the processing time k.
Regular sequential filters and object trackers do not have the ability to process
OOSMs correctly, because they only maintain the current state estimates and covariances.
At the filter level, neglecting OOSMs can increase the state estimate error covariances
and thus increase the uncertainty of the state estimate. On the other hand, directly
applying an OOSM without considering the measurement time can destabilize the state
estimates. At the tracker level, incorrect or insufficient use of OOSMs can additionally
result in false associations and false tracks, while valuable information, such as
object classification, can be missed entirely. To simulate out-of-sequence detections,
Sensor Fusion and Tracking Toolbox™ provides these options to handle OOSMs.
Report an Error for OOSM
In Sensor Fusion and Tracking Toolbox, as the default behavior, these multi-object trackers and tracker blocks report an error when encountering an OOSM:
Reporting an error for an OOSM stops the execution of a tracker. Use this option when you do not expect OOSMs, and consider them to be errors in your tracking system.
You can specify for the tracker to neglect OOSMs by specifying the
OOSMHandling property of these multi-object trackers to
With this setting, the tracker neglects any OOSM it encounters and continues to run.
Similarly, you can set the Out-of-sequence measurement handling
parameter in these tracker blocks to
In most cases, neglecting an OOSM is a good choice when the tracking system is updated with high frequency, such that the loss of a measurement is not very costly. Also, this option does not require extra processing operations and storage. For tracking systems with low update rates, however, this option can affect the state estimate quality, and may result in incorrect detection-track association.
Process OOSM Using Retrodiction
Retrodiction is an effective and efficient approach for handling OOSMs. For details on the algorithm, see Retrodiction and Retro-Correction, , and . This diagram illustrates the retrodiction and retro-correction steps.
Assume that, at time k, the filter obtains the posteriori state estimate x(k|k) and state estimate error covariance P(k|k), based on all the measurements that have arrived at the filter up to that time. Also, assume an OOSM taken at time τ, where τ < k, is now available at time k. To process the OOSM using retrodiction, the filter first retrodicts (predicts backward in time) the state and state covariance to obtain the retrodicted state x(τ|k) and state covariance P(τ|k). Then, using the OOSM z(τ) and its covariance R(τ), the filter corrects the state estimate and obtains the retro-corrected state x(k|τ) and state covariance P(k|τ) for the current time step k, including the OOSM. Note that, to successfully apply the algorithm, the filter needs to store the state estimate covariance matrices from timestamps prior to the OOSM time τ to time k.
Compared with a linear or extended Kalman filter, an interactive multiple model (IMM)
trackingIMM) needs to maintain the probability of each member-filter in the
retrodiction steps. See  for more details.
Retrodiction in Tracking Filters
Sensor Fusion and Tracking Toolbox currently provides retrodiction capability for
trackingIMM filter objects. To enable retrodiction in a filter,
MaxNumOOSMSteps property as a positive integer,
which represents the number of previous state covariances preserved in the filter.
Then, use the
retrodict object function to retrodict the state to the OOSM time,
and use the
retroCorrectJPDA object function to update the current state using
Retrodiction in Multi-Object Trackers
Sensor Fusion and Tracking Toolbox currently provides retrodiction capability for these tracker objects and blocks:
Joint Probabilistic Data Association Multi Object Tracker block
To enable retrodiction in
trackerJPDA, specify its
'Retrodiction', and specify the
MaxNumOOSMSteps property as a positive integer. Similarly,
you can enable retrodiction in the Global Nearest Neighbor Multi Object
Tracker block or the Joint Probabilistic Data Association Multi
Object Tracker block via the Out-of-sequence measurements
handling and the Maximum number of OOSM steps
parameters. In the tracker object or the tracker block, you must specify a filter
initialization function that returns a
The tracker follows these steps to handle the OOSM:
If the OOSM timestamp is beyond the track history maintained by the tracker, the tracker neglects the OOSM.
If the OOSM timestamp is within the track history maintained by the tracker, the tracker first retrodicts all the existing tracks to the time of the OOSM. Then, the tracker tries to associate the OOSM to any of the retrodicted tracks.
If the tracker successfully associates the OOSM to a retrodicted track, the tracker updates the retrodicted tracks using the OOSM by applying the retro-correction algorithm to obtain current, corrected tracks.
If the tracker cannot associate the OOSM to any retrodicted track, the tracker creates a new track based on the OOSM and predicts the track to the current time.
trackerTOMHT | Global
Nearest Neighbor Multi Object Tracker | Joint Probabilistic Data Association Multi Object Tracker | Track-Oriented
 Bar-Shalom, Y., Huimin Chen, and M. Mallick. “One-Step Solution for the Multistep out-of-Sequence-Measurement Problem in Tracking.” IEEE Transactions on Aerospace and Electronic Systems 40, no. 1 (January 2004): 27–37.
 Bar-shalom, Y. and Huimin Chen. “IMM Estimator with Out-of-Sequence Measurements.” IEEE Transactions on Aerospace and Electronic Systems, vol. 41, no. 1, Jan. 2005, pp. 90–98.