Main Content

Track-Oriented Multi-Hypothesis Tracker

Track-Oriented Multi-Hypothesis Tracker

  • Library:
  • Sensor Fusion and Tracking Toolbox / Multi-Object Tracking Algorithms

  • Track-Oriented Multi-Hypothesis Tracker block

Description

The Track-Oriented Multi-Hypothesis Tracker block processes detections of multi targets from multiple sensors. The tracker block initializes, confirms, predicts, corrects, and deletes tracks. Inputs to the tracker block are detection reports generated by objectDetection, fusionRadarSensor, irSensor, or sonarSensor objects. The tracker block estimates the state vector and state vector covariance matrix for each track. The tracker assigns detections based on a track-oriented, multi-hypothesis approach.

Any new track starts in a tentative state. If enough detections are assigned to a tentative track, its status changes to confirmed. If the detection already has a known classification (the ObjectClassID field of the returned track is nonzero), that track is confirmed immediately. When a track is confirmed, the multi-object tracker considers the track to represent a physical object. If detections are not assigned to the track within a specifiable number of updates, the track is deleted. For an overview of how the tracker functions, see Algorithms.

Ports

Input

expand all

Detection list, specified as a Simulink bus containing a MATLAB structure. The structure has the form:

FieldDescriptionType
NumDetectionsNumber of detectionsInteger
DetectionsObject detectionsArray of objectDetection structures. The first NumDetections of these detections are actual detections.

The fields of the detections structure are:

FieldDescriptionType
TimeMeasurement timeSingle or Double
MeasurementObject measurementsSingle or Double
MeasurementNoiseMeasurement noise covariance matrixSingle or Double
SensorIndexUnique ID of the sensorSingle or Double
ObjectClassIDObject classification IDSingle or Double
MeasurementParametersParameters used by initialization functions of tracking filtersSimulink Bus
ObjectAttributesAdditional information passed to trackerSimulink Bus

See objectDetection for a more detailed explanation of these fields.

Note

The object detection structure contains a Time field. The time tag of each object detection must be less than or equal to the time at the current invocation of the block. The time tag must also be greater than the update time specified in the previous invocation of the block.

Track update time, specified as a real scalar in seconds. The tracker updates all tracks to this time. The update time must always increase with each invocation of the block. The update time must be at least as large as the largest Time specified in the Detections input port.

If the port is not enabled, the simulation clock managed by Simulink determines the update time.

Dependencies

To enable this port, on the Port Setting tab, set Prediction time source to Input port.

Cost matrix, specified as a real-valued N-by-M matrix, where N is the number of branches and M is the number of current detections.

The rows of the cost matrix must be in the same order as the list of branches. Branches are ordered as they appear in the list of branches from the All Branches output port on the previous invocation of the block. The columns correspond to the detections.

In the first update to the tracker, or if the tracker has no previous tracks, assign the cost matrix a size of [0, N]. The cost must be calculated so that lower costs indicate a higher likelihood that the tracker assigns a detection to a track. To prevent certain detections from being assigned to certain tracks, use Inf.

If this port is not enabled, the filter initialized by the Filter initialization function calculates the cost matrix using the distance method.

Dependencies

To enable this port, on the Port Setting tab, select Enable cost matrix input.

Detectable branch IDs, specified as a real-valued M-by-1 vector or M-by-2 matrix. Detectable branches are branches that the sensors expect to detect. The first column of the matrix contains a list of branch IDs that the sensors report as detectable. The optional second column enables you to add the detection probability for each branch. Branches are listed in the All Branches output from the previous invocation of the block.

Tracks whose identifiers are not included in Detectable BranchIDs are considered undetectable. The track deletion logic does not count the lack of detection as a "missed detection" for track deletion purposes.

If this port is not enabled, the tracker assumes all tracks to be detectable at each invocation of the block.

Dependencies

To enable this port, on the Port Setting tab, select Enable detectable branch IDs input.

Track state parameters, specified as a Simulink bus containing a MATLAB structure. The structure has the form:

FieldDescription
NumParametersNumber of non-default state parameters, specified as a nonnegative integer
ParametersArray of state parameter structures

The block uses the value of the Parameters field for the StateParameters field of the generated tracks. You can use these parameters to define the reference frame in which the track is reported or other desirable attributes of the generated tracks.

For example, you can use the following structure to define a rectangular reference frame whose origin position is at [10 10 0] meters and whose origin velocity is [2 -2 0] meters per second with respect to the scenario frame.

Field NameValue
Frame"Rectangular"
Position[10 10 0]
Velocity[2 -2 0]

Dependencies

To enable this port, in the Tracker Configuration tab, select the Update track state parameters with time parameter.

Output

expand all

Confirmed tracks, returned as a Simulink bus containing a MATLAB structure. The structure has the form:

FieldDescription
NumTracksNumber of tracks
TracksArray of track structures of a length set by the Maximum number of tracks parameter. Only the first NumTracks of these are actual tracks.

The fields of the track structure are shown in Track Structure.

A track is confirmed if it satisfies the threshold specified in the Confirmation threshold parameter under the Track Logic tab.

Tentative tracks, returned as a Simulink bus containing a MATLAB structure. A track is tentative before it is confirmed.

The fields of the track structure are shown in Track Structure.

Dependencies

To enable this port, on the Port Setting tab, select Enable tentative tracks output.

Combined list of confirmed and tentative tracks, returned as a Simulink bus containing a MATLAB structure.

The fields of the track structure are shown in Track Structure.

Dependencies

To enable this port, on the Port Setting tab, select Enable all tracks output.

Additional information for analyzing track updates, returned as a Simulink bus containing a MATLAB structure.

This table shows the fields of the info structure:

FieldDescription
OOSMDetectionIndices

Indices of out-of-sequence measurements

BranchIDsAtStepBeginning

Branch IDs when the update began.

CostMatrix

Cost of assignment matrix.

Assignments

Assignments returned from the assignTOMHT function.

UnassignedTracks

IDs of unassigned branches returned from the tracker.

UnassignedDetections

IDs of unassigned detections returned from the tracker.

InitialBranchHistory

Branch history after branching and before pruning.

InitialBranchScores

Branch scores before pruning.

KeptBranchHistory

Branch history after initial pruning.

KeptBranchScores

Branch scores after initial pruning.

Clusters

Logical array mapping branches to clusters. Branches belong in the same cluster if they share detections in their history or belong to the same track either directly or through other branches.

TrackIncompatibility

Branch incompatibility matrix. The (i,j) element is true if the i-th and j-th branches have shared detections in their history or belong to the same track.

GlobalHypotheses

Logical matrix mapping branches to global hypotheses. Compatible branches can belong in the same hypotheses.

GlobalHypScoresTotal score of global hypotheses.
PrunedBranches

Logical array of branches that the pruneTrackBranches function determines to prune.

GlobalBranchProbabilities

Global probability of each branch existing in the global hypotheses.

BranchesDeletedByPruning

Branches deleted by the tracker.

BranchIDsAtStepEnd

Branch IDs when the update ended.

Dependencies

To enable this port, on the Port Setting tab, select Enable information output.

All branches, returned as a Simulink bus containing a MATLAB structure.

The fields of the branch structure are the same as the Track Structure.

Dependencies

To enable this port, on the Port Setting tab, select Enable all branches output.

Parameters

expand all

Tracker Management

Unique tracker identifier, specified as a nonnegative integer. This parameter is passed as the SourceIndex in the tracker outputs, and distinguishes tracks that come from different trackers in a multiple-tracker system. You must specify this property as a positive integer to use the track outputs as inputs to a trackFuser object.

Example: 1

Filter initialization function, specified as the name of a filter initialization function. The tracker uses a filter initialization function when creating new tracks.

Sensor Fusion and Tracking Toolbox™ provides many initialization functions that are compatible with this block.

Initialization FunctionFunction Definition
initcvabfInitialize constant-velocity alpha-beta filter
initcaabfInitialize constant-acceleration alpha-beta filter
initcvekfInitialize constant-velocity extended Kalman filter.
initcackfInitialize constant-acceleration cubature filter.
initctckfInitialize constant-turn-rate cubature filter.
initcvckfInitialize constant-velocity cubature filter.
initcapfInitialize constant-acceleration particle filter.
initctpfInitialize constant-turn-rate particle filter.
initcvpfInitialize constant-velocity particle filter.
initcvkfInitialize constant-velocity linear Kalman filter.
initcvukfInitialize constant-velocity unscented Kalman filter.
initcaekfInitialize constant-acceleration extended Kalman filter.
initcakfInitialize constant-acceleration linear Kalman filter.
initcaukf Initialize constant-acceleration unscented Kalman filter.
initctekf Initialize constant-turn-rate extended Kalman filter.
initctukfInitialize constant-turn-rate unscented Kalman filter.
initcvmscekfInitialize constant-velocity modified spherical coordinates extended Kalman filter.
initrpekfInitialize constant-velocity range-parametrized extended Kalman filter.
initapekfInitialize constant-velocity angle-parametrized extended Kalman filter.
initekfimmInitialize tracking IMM filter.

You can also write your own initialization function. The function must have the following syntax:

filter = filterInitializationFcn(detection)
The input to this function is a detection report like those created by the objectDetection object. The output of this function must be a filter object: trackingKF, trackingEKF, trackingUKF, trackingCKF, trackingPF, trackingMSCEKF, trackingGSF, trackingIMM, or trackingABF.

To guide you in writing this function, you can examine the details of the supported functions from within MATLAB. For example:

type initcvekf

Threshold for assigning detections to tracks, specified as a positive scalar, a 1-by-3 vector of non-decreasing positive values, [C1,C2,C3], or a1-by-4 vector of non-decreasing positive values, [C1,C2,C3,C4]. If specified as a scalar, the specified value, val, will be expanded to [0.3,0.7,1,Inf]*val. If specified as [C1,C2,C3], it will be expanded as [C1,C2,C3,Inf].

The thresholds control (1) the assignment of a detection to a track, (2) the creation of a new branch from a detection, and (3) the creation of a new branch from an unassigned track. The threshold values must satisfy: C1 <= C2 <= C3<=C4.

  • C1 defines a distance such that if a track has an assigned detection with lower distance than C1, the track is no longer considered unassigned and does not create an unassigned track branch.

  • C2 defines a distance such that if a detection has been assigned to a track with lower distance than C2, the detection is no longer considered unassigned and does not create a new track branch.

  • C3 defines the maximum distance for assigning a detection to a track.

  • C4 defines combinations of track and detection for which an accurate normalized cost calculation is performed. Initially, the tracker executes a coarse estimation for the normalized distance between all the tracks and detections. The tracker only calculates the accurate normalized distance for the combinations whose coarse normalized distance is less than C4.

Tips:

  • Increase the value of C3 if there are detections that should be assigned to tracks but are not. Decrease the value if there are detections that are assigned to tracks they should not be assigned to (too far away).

  • Increasing the values C1 and C2 helps control the number of track branches that are created. However, doing so reduces the number of branches (hypotheses) each track has.

  • Increase the value of C4 if there are combinations of track and detection that should be calculated for assignment but are not. Decrease it if cost calculation takes too long.

Data Types: single | double

Maximum number of tracks that the block can maintain, specified as a positive integer.

Maximum number of sensors that can be connected to the tracker, specified as a positive integer. MaxNumSensors must be greater than or equal to the largest value of SensorIndex found in all the detections used to update the tracker. SensorIndex is one of the properties of an objectDetection object. The block's MaxNumSensors property determines how many sets of ObjectAttributes fields each output track can have.

Out-of-sequence measurements handling, specified as Terminate or neglect. Each detection has a timestamp associated with it, td, and the tracker block has it own timestamp, tt, which is updated in each invocation. The tracker block considers a measurement as an OOSM if td < tt.

When the parameter is specified as:

  • Terminate — The block stops running when it encounters any out-of-sequence measurements.

  • Neglect — The block neglects any out-of-sequence measurements and continue to run.

Specify the parameters of the track state reference frame as a structure or a structure array. The block passes the value of this parameter to the StateParameters field of the generated tracks. You can use these parameters to define the reference frame in which the track is reported or other desirable attributes of the generated tracks.

For example, you can use the following structure to define a rectangular reference frame whose origin position is at [10 10 0] meters and whose origin velocity is [2 -2 0] meters per second with respect to the scenario frame.

Field NameValue
Frame"Rectangular"
Position[10 10 0]
Velocity[2 -2 0]

You can update the track state parameters through the State Parameters input port by selecting the Update track state parameters with time parameter.

Data Types: struct

Select this parameter to enable the input port for track state parameters through the State Parameters input port.

Track output method, specified as 'Tracks', 'Hypothesis', or 'Clusters'.

  • 'Tracks' – Output the centroid of each track based on its track branches.

  • 'Hypothesis' – Output branches that are in certain hypotheses. If you choose this option, list the hypotheses to output using the HypothesesToOutput property.

  • 'Clusters' – Output the centroid of each cluster. Similar to the 'Tracks' output, but includes all tracks within a cluster.

Data Types: char

  • Interpreted execution — Simulate the model using the MATLAB interpreter. This option shortens startup time. In the Interpreted execution mode, you can debug the source code of the block.

  • Code generation — Simulate the model using generated C code. The first time you run a simulation, Simulink generates C code for the block. The C code is reused for subsequent simulations as long as the model does not change. This option requires additional startup time.

Hypotheses Management

Maximum number of hypotheses maintained by the tracks in cases of ambiguity, specified as a positive integer. Larger values increase the computational load.

Example: 10

Data Types: single | double

Maximum number of track branches (hypotheses) allowed for each track, specified as a positive integer. Larger values increase the computational load.

Data Types: single | double

Maximum number of scans maintained in the branch history, specified as a positive integer. The number of track history scans is typically from 2 through 6. Larger values increase the computational load.

Data Types: single | double

Minimum probability required to keep a track branch, specified as a positive scalar less than one. Any track with probability lower than the specified probability is pruned. Typical values are 0.001 to 0.005.

Example: .003

Data Types: single | double

N-scan pruning method, specified as 'None' or 'Hypothesis'. In N-scan pruning, branches that belong to the same track are pruned (deleted) if, in the N-scans history, they contradict the most likely branch for the same track. The most-likely branch is defined in one of two ways:

  • 'None' – No N-scan pruning is performed.

  • 'Hypothesis' – The chosen branch is in the most likely hypothesis.

Example: 'Hypothesis'

Track Logic

Minimum score required to confirm a track, specified as a positive scalar. Any track with a score higher than this threshold is confirmed.

Example: 12

Data Types: single | double

The maximum score drop before a track is deleted, specified as a scalar. Any track with a score that falls by more than this parameter from the maximum score is deleted. Deletion threshold is affected by the probability of a false alarm.

Example: -1

Data Types: single | double

Probability of detection, specified as a positive scalar between 0 and 1. This property is used to compute track score.

Example: 0.5

Data Types: single | double

The probability of false alarm, specified as a scalar. This property is used to compute track score.

Example: 1e-5

Data Types: single | double

The volume of a sensor measurement bin, specified as a positive scalar. For example, if a radar produces a 4-D measurement, which includes azimuth, elevation, range, and range rate, the 4-D volume is defined by the radar angular beam width, the range bin width, and the range-rate bin width. Volume is used in calculating the track score when initializing and updating a track.

Example: 1.5

Data Types: single | double

The rate of new tracks per unit volume, specified as a positive scalar. The parameter is used in calculating the track score during track initialization.

Example: 2.5

Data Types: single | double

Port Setting

Source for prediction time, specified as Input port or Auto. Select Input port to input an update time by using the Prediction Time input port. Otherwise, the simulation clock managed by Simulink determines the update time.

Select this parameter to enable the input of a cost matrix by using the Cost Matrix input port.

Select this parameter to enable the Detectable branch IDs input port.

Select this parameter to enable the output of tentative tracks through the Tentative Tracks output port.

Select this parameter to enable the output of all the tracks through the All Tracks output port.

Select this parameter to enable the output port for analysis information through the Info output port.

Select this parameter to enable the output of all the branches through the All Branches output port.

Source of the output track bus name, specified as:

  • Auto — The block automatically creates an output track bus name.

  • Property — Specify the output track bus name by using the Specify an output bus name parameter.

Source of the output info bus name, specified as:

  • Auto — The block automatically creates an output info bus name.

  • Property — Specify the output info bus name by using the Specify an output info bus name parameter.

Dependencies

To enable this parameter, on the Port Setting tab, select Enable information output.

Algorithms

expand all

References

[1] Werthmann, J. R. "Step-by-Step Description of a Computationally Efficient Version of Multiple Hypothesis Tracking." In International Society for Optics and Photonics, Vol. 1698, pp. 228-301, 1992.

[2] Blackman, S., and R. Popoli. Design and Analysis of Modern Tracking Systems. Artech House Radar Library, Boston, 1999.

Extended Capabilities

Introduced in R2020a