Joint Probabilistic Data Association Multi Object Tracker

Joint probabilistic data association tracker

Library:
Sensor Fusion and Tracking Toolbox

Description

The Joint Probabilistic Data Association Multi Object Tracker block is capable of processing detections of multiple targets from multiple sensors. The tracker uses joint probabilistic data association to assign detections to each track. The tracker applies a soft assignment, in which multiple detections can contribute to each track. The tracker initializes, confirms, corrects, predicts (performs coasting), and deletes tracks. The tracker estimates the state vector and state estimate error covariance matrix for each track. Each detection is assigned to at least one track. If the detection cannot be assigned to any existing track, the tracker creates a new track.

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 corresponding track is confirmed immediately. When a track is confirmed, the 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.

Ports

Input

expand all

`Detections` — Detection list
Simulink^® bus containing MATLAB^® structure

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

Field	Description	Type
`NumDetections`	Number of detections	Integer
`Detections`	Object detections	Array of `objectDetection` structures. The first `NumDetections` of these detections are actual detections.

The fields of detections are:

Field	Description	Type
`Time`	Measurement time	`Single` or `Double`
`Measurement`	Object measurements	`Single` or `Double`
`MeasurementNoise`	Measurement noise covariance matrix	`Single` or `Double`
`SensorIndex`	Unique ID of the sensor	`Single` or `Double`
`ObjectClassID`	Object classification ID	`Single` or `Double`
`MeasurementParameters`	Parameters used by initialization functions of tracking filters	Simulink Bus
`ObjectAttributes`	Additional information passed to tracker	Simulink Bus

See objectDetection for 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 of 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.

`Prediction Time` — Track update time
real scalar

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` — Cost matrix
real-valued N_t-by-N_d matrix

Cost matrix, specified as a real-valued N_t-by-N_d matrix, where N_t is the number of existing tracks and N_d is the number of current detections.

The rows of the cost matrix correspond to the existing tracks. The columns correspond to the detections. Tracks are ordered as they appear in the list of tracks from the All Tracks output port on the previous invocation of the block.

In the first update to the tracker, or if the tracker has no previous tracks, assign the cost matrix a size of [0, N_d]. 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 TrackIDs` — Detectable track IDs
real-valued M-by-1 vector | real-valued M-by-2 matrix

Detectable track IDs, specified as a real-valued M-by-1 vector or M-by-2 matrix. Detectable tracks are tracks that the sensors expect to detect. The first column of the matrix contains a list of track IDs that the sensors report as detectable. The optional second column enables you to add the detection probability for each track.

Tracks whose identifiers are not included in Detectable TrackIDs 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 track IDs Input.

Output

expand all

`Confirmed Tracks` — Confirmed tracks
Simulink bus containing MATLAB structure

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

Field	Description
`NumTracks`	Number of tracks
`Tracks`	Array 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.

Depending on the track logic, a track is confirmed if:

History – A track receives at least M detections in the last N updates. M and N are specified in Confirmation threshold for the History logic.
Integrated – The integrated probability of track existence is higher than the confirmation threshold specified in Confirmation threshold for the Integrated logic.

`Tentative Tracks` — Tentative tracks
Simulink bus containing MATLAB structure

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.

`All Tracks` — Confirmed and tentative tracks
Simulink bus containing MATLAB structure

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.

`Info` — Additional information for analyzing track updates
Simulink bus containing MATLAB structure

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

This table shows the fields of the info structure:

Field	Description
`TrackIDsAtStepBeginning`	Track IDs when step began.
`CostMatrix`	Cost matrix for assignment.
`Clusters`	Cell array of cluster reports. See Feasible Joint Events for more details.
`InitiatedTrackIDs`	IDs of tracks initiated during the step.
`DeletedTrackIDs`	IDs of tracks deleted during the step.
`TrackIDsAtStepEnd`	Track IDs when the step ended.

The Clusters field can include multiple cluster reports. Each cluster report is a structure containing:

Field	Description
`DetectionIndices`	Indices of clustered detections.
`TrackIDs`	Track IDs of clustered tracks.
`ValidationMatrix`	Validation matrix of the cluster. See Feasible Joint Events for more details.
`SensorIndex`	Index of the originating sensor of the clustered detections.
`TimeStamp`	Mean time stamp of clustered detections.
`MarginalProbabilities`	Matrix of marginal posterior joint association probabilities.

Dependencies

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

Parameters

expand all

Tracker Management

`Filter initialization function` — Filter initialization function
`@initcvekf` (default) | function handle | character vector

Filter initialization function, specified as a function handle or as a character vector containing the name of a valid filter initialization function. The tracker uses the filter initialization function when creating new tracks.

Sensor Fusion and Tracking Toolbox™ supplies many initialization functions:

Initialization Function	Function Definition
`initcvkf`	Initialize constant-velocity linear Kalman filter.
`initcakf`	Initialize constant-acceleration linear Kalman filter.
`initcvabf`	Initialize constant-velocity alpha-beta filter
`initcaabf`	Initialize constant-acceleration alpha-beta filter
`initcvekf`	Initialize constant-velocity extended Kalman filter.
`initcaekf`	Initialize constant-acceleration extended Kalman filter.
`initrpekf`	Initialize constant-velocity range-parametrized extended Kalman filter.
`initapekf`	Initialize constant-velocity angle-parametrized extended Kalman filter.
`initctekf`	Initialize constant-turn-rate extended Kalman filter.
`initcackf`	Initialize constant-acceleration cubature filter.
`initctckf`	Initialize constant-turn-rate cubature filter.
`initcvckf`	Initialize constant-velocity cubature filter.
`initcvukf`	Initialize constant-velocity unscented Kalman filter.
`initcaukf`	Initialize constant-acceleration unscented Kalman filter.
`initctukf`	Initialize constant-turn-rate unscented Kalman filter.
`initcvmscekf`	Initialize constant-velocity extended Kalman filter in modified spherical coordinates.
`initekfimm`	Initialize tracking IMM filter.

You can also write your own initialization function using this syntax:

filter = filterInitializationFcn(detection)

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

For guidance in writing this function, use the type command to examine the details of built-in MATLAB functions. For example:

type initcvekf

Note

trackerJPDA does not accept all filter initialization functions in Sensor Fusion and Tracking Toolbox. The full list of filter initialization functions available in Sensor Fusion and Tracking Toolbox are given in the Initialization section of Estimation Filters.

`Feasible joint events generation function name` — Feasible joint events generation function name
`@jpdaEvents` (default) | function handle | character vector

Feasible joint events generation function name, specified as a function handle or as a character vector containing the name of a feasible joint events generation function. This function generates feasible joint event matrices from admissible events (usually given by a validation matrix) of a tracking scenario. A validation matrix is a binary matrix listing all possible detections-to-track associations. For details, see jpadEvents.

You can also write your own generation function. The function must have this syntax:

FJE = myfunction(ValidationMatrix)

The input and output of this function must exactly follow the formats used in jpdaEvents. For guidance in writing this function, use the type command to examine the details of jpdaEvents:

type jpdaEvents

`Maximum number of tracks` — Maximum number of tracks
`100` (default) | positive integer

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

`Maximum number of sensors` — Maximum number of sensors
`20` (default) | positive integer

Maximum number of sensors that the block can process, specified as a positive integer. This value should be greater than or equal to the highest SensorIndex value input at the Detections input port.

`Absolute tolerance between time stamps of detections` — Absolute tolerance between time stamps of detections
`20` (default) | positive integer

Absolute time tolerance between detections for the same sensor, specified as a positive scalar. The block expects detections from a sensor to have identical time stamps. However, if the time stamp differences between detections of a sensor are within the margin specified by this parameter, these detections will be used to update the track estimate based on the average time of these detections.

`Simulate using` — Type of simulation to run
`Interpreted Execution` (default) | `Code Generation`

Interpreted execution — Simulate the model using the MATLAB interpreter. This option shortens startup time. In 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.

Assignment

`Threshold for assigning detections to tracks` — Threshold for assigning detections to tracks
`30*[1 Inf]` (default) | positive scalar | 1-by-2 vector of positive values

Threshold for assigning detections to tracks (or gating threshold), specified as a positive scalar or 1-by-2 vector of [C₁,C₂], where C₁ ≤ C₂. If specified as a scalar, the specified value, val, is expanded to [val, Inf].

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 C₂. Also, the tracker can only assign a detection to a track if the accurate normalized distance between them is less than C₁. See the distance function used with tracking filters (such as trackingCKF and trackingEKF) for explanation of the distance calculation.

Tips:

Increase the value of C₂ if there are track and detection combinations that should be calculated for assignment but are not. Decrease this value if the cost calculation takes too much time.
Increase the value of C₁ if there are detections that should be assigned to tracks but are not. Decrease this value if there are detections that are assigned to tracks they should not be assigned to (too far away).

`Threshold to initialize a track` — Threshold to initialize a track
`0` (default) | scalar in the range [0, 1]

The probability threshold to initialize a new track, specified as a scalar in the range [0, 1]. If the probabilities of associating a detection with any of the existing tracks are all smaller than InitializationThreshold, the detection is used to initialize a new track. This allows detections that are within the validation gate of a track but have an association probability lower than the initialization threshold to spawn a new track.

Example: 0.1

`Probability of detection` — Probability of detection
`0.9` (default) | scalar in the range [0, 1]

Probability of detection, specified as a scalar in the range [0, 1]. This property is used in calculations of the marginal posterior probabilities of association and the probability of track existence when initializing and updating a track.

`Spatial density of clutter measurements` — Spatial density of clutter measurements
`1e-5` (default) | positive scalar

Spatial density of clutter measurements, specified as a positive scalar. The clutter density describes the expected number of false positive detections per unit volume. It is used as the parameter of a Poisson clutter model. When Type of track confirmation and deletion logic is set to 'Integrated', this parameter is also used in calculating the initial probability of track existence.

Track Logic

`Type of track confirmation and deletion logic` — Confirmation and deletion logic type
`History` (default) | `Integrated`

Confirmation and deletion logic type, selected as:

History – Track confirmation and deletion is based on the number of times the track has been assigned to a detection in the latest tracker updates.
Integrated – Track confirmation and deletion is based on the probability of track existence, which is integrated in the assignment function.

`Confirmation threshold [M N]` — Track confirmation threshold for history logic
`[2, 3]` (default) | real-valued 1-by-2 vector of positive integers

Track confirmation threshold for history logic, specified as a real-valued 1-by-2 vector of positive integers [M N]. A track is confirmed if it receives at least M detections in the last N updates.

Dependencies

To enable this parameter, set Type of track confirmation and deletion logic to 'History'.

`Deletion threshold [P Q]` — Track deletion threshold for history logic
`[5, 5]` (default) | real-valued 1-by-2 vector of positive integers

Track deletion threshold for history logic, specified as a real-valued 1-by-2 vector of positive integers, [P Q]. If, in P of the last Q tracker updates, a confirmed track is not assigned to any detection that has a likelihood greater than the Threshold for registering 'hit' or 'miss' parameter, then that track is deleted.

Dependencies

To enable this parameter, set Type of track confirmation and deletion logic to 'History'.

`Threshold for registering 'hit' or 'miss'` — Threshold for registering a 'Hit' or a 'Miss'
`0.2` (default) | scalar in the range [0, 1]

Threshold for registering a 'hit' or 'miss', specified as a scalar in the range [0, 1]. The track history logic registers a 'miss' and the track will be coasted if the sum of the marginal probabilities of assignments is below this threshold. Otherwise, the track history logic registers a 'hit'.

Dependencies

To enable this parameter, set Type of track confirmation and deletion logic to 'History'.

`Confirmation threshold [Probability]` — Track confirmation threshold for integrated logic
`0.95` (default) | positive scalar

Track confirmation threshold for integrated logic, specified as a real-valued positive scalar. A track is confirmed if its probability of existence is greater than or equal to the confirmation threshold.

Dependencies

To enable this parameter, set Type of track confirmation and deletion logic to 'Integrated'.

`Deletion threshold [Probability]` — Track deletion threshold for integrated logic
`0.1` (default) | positive scalar

Track deletion threshold for integrated logic, specified as a positive scalar. A track is deleted if its probability of existence drops below this threshold.

Dependencies

To enable this parameter, set Type of track confirmation and deletion logic to 'Integrated'.

`Spatial density of new targets` — Spatial density of new targets
`1e-5` (default) | positive scalar

Spatial density of new targets, specified as a positive scalar. The new target density describes the expected number of new tracks per unit volume in the measurement space. It is used in calculating the probability of track existence during track initialization.

Dependencies

To enable this parameter, set Type of track confirmation and deletion logic to 'Integrated'.

`Time rate of true target deaths` — Time rate of true target deaths
`0.01` (default) | scalar in the range [0, 1]

Time rate of true target deaths, specified as a scalar in the range [0, 1]. This parameter describes the probability with which true targets disappear. It is related to the propagation of the probability of track existence (PTE) :

$P T E (t + δ t) = {(1 - D e a t h R a t e)}^{δ t} P T E (t)$

where DeathRate is the time rate of true target deaths, and δt is the time interval since the previous update time t.

Dependencies

To enable this parameter, set Type of track confirmation and deletion logic to 'Integrated'.

Port Setting

`Prediction time source` — Source of prediction time
`Auto` (default) | `Input port`

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.

`Enable cost matrix input` — Enable input port for cost matrix
off (default) | on

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

`Enable detectable track IDs input` — Enable detectable track IDs input
off (default) | on

Select this check box to enable the Detectable track IDs input port.

`Enable tentative tracks output` — Enable output port for tentative tracks
off (default) | on

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

`Enable all tracks output` — Enable output port for all tracks
off (default) | on

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

`Enable information output` — Enable output port for analysis information
off (default) | on

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

`Source of output bus name` — Source of output track bus name
`Auto` (default) | `Property`

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 output info bus name` — Source of output info bus name
`Auto` (default) | `Property`

Source of the output info bus name, specified as one of these options:

Auto — The block automatically creates an output info bus name.
Property — Specify the output info bus name by using the Specify an output bus name parameter.

Model Examples

Track Vehicles Using Lidar Data in Simulink

Track vehicles using measurements from a lidar sensor mounted on top of an ego vehicle. Due to high resolution capabilities of the lidar sensor, each scan from the sensor contains a large number of points, commonly known as a point cloud. The example illustrates the workflow in Simulink for processing the point cloud and tracking the objects. The lidar data used in this example is recorded from a highway driving scenario. You use the recorded data to track vehicles with a joint probabilistic data association (JPDA) tracker and an interacting multiple model (IMM) approach. The example closely follows the Track Vehicles Using Lidar: From Point Cloud to Track List MATLAB® example.

Track Closely Spaced Targets Under Ambiguity in Simulink

Track objects in Simulink® with Sensor Fusion and Tracking Toolbox™ when the association of sensor detections to tracks is ambiguous. It closely follows the Tracking Closely Spaced Targets Under Ambiguity MATLAB® example.

Algorithms

expand all

Tracker Logic Flow

When a joint probabilistic data association (JPDA) tracker processes detections, track creation and management follow these steps:

The tracker divides detections into multiple groups by originating sensor.
For each sensor:
1. The tracker calculates the distances from detections to existing tracks and forms a costMatrix.
2. The tracker creates a validation matrix based on the assignment threshold (or gate threshold) of the existing tracks. A validation matrix is a binary matrix listing all possible detections-to-track associations. For details, see Feasible Joint Events.
3. Tracks and detections are then separated into clusters. A cluster can contain one track or multiple tracks if these tracks share common detections within their validation gates. A validation gate is a spatial boundary, in which the predicted detection of the track has a high likelihood to fall. For details, see Feasible Joint Events.
Update all clusters following the order of the mean detection time stamp within the cluster. For each cluster, the tracker:
1. Generates all feasible joint events. For details, see jpdaEvents.
2. Calculates the posterior probability of each joint event.
3. Calculates the marginal probability of each individual detection-track pair in the cluster.
4. Reports weak detections. Weak detections are the detections that are within the validation gate of at least one track, but have probability association to all tracks less than the IntitializationThreshold.
5. Updates tracks in the cluster using correctjpda.
Unassigned detections (detections not in any cluster) and weak detections spawn new tracks.
The tracker checks all tracks for deletion. Tracks are deleted based on the number of scans without association using 'History' logic or based on their probability of existence using'Integrated' track logic.
All tracks are predicted to the latest time value (either the time input if provided, or the latest mean cluster time stamp).

Feasible Joint Events

In the typical workflow for a tracking system, the tracker needs to determine if a detection can be associated with any of the existing tracks. If the tracker only maintains one track, the assignment can be done by evaluating the validation gate around the predicted measurement and deciding if the measurement falls within the validation gate. In the measurement space, the validation gate is a spatial boundary, such as a 2-D ellipse or a 3-D ellipsoid, centered at the predicted measurement. The validation gate is defined using the probability information (state estimation and covariance, for example) of the existing track, such that the correct or ideal detections have high likelihood (97% probability, for example) of falling within this validation gate.

However, if a tracker maintains multiple tracks, the data association process becomes more complicated, because one detection can fall within the validation gates of multiple tracks. For example, in the following figure, tracks T₁ and T₂ are actively maintained in the tracker, and each of them has its own validation gate. Since the detection D₂ is in the intersection of the validation gates of both T₁ and T₂, the two tracks (T₁ and T₂) are connected and form a cluster. A cluster is a set of connected tracks and their associated detections.

To represent the association relationship in a cluster, the validation matrix is commonly used. Each row of the validation matrix corresponds to a detection while each column corresponds to a track. To account for the eventuality of each detection being clutter, a first column is added and usually referred to as "Track 0" or T₀. If detection D_i is inside the validation gate of track D_j, then the (j, i+1) entry of the validation matrix is 1. Otherwise, it is zero. For the cluster shown in the figure, the validation matrix Ω is

$Ω = [\begin{matrix} 1 & 1 & 0 \\ 1 & 1 & 1 \\ 1 & 0 & 1 \end{matrix}]$

Note that all the elements in the first column of Ω are 1, because any detection can be clutter or false alarm. One important step in the logic of joint probabilistic data association (JPDA) is to obtain all the feasible independent joint events in a cluster. Two assumptions for the feasible joint events are:

A detection cannot be emitted by more than one track.
A track cannot be detected more than once by the sensor during a single scan.

Based on these two assumptions, feasible joint events (FJEs) can be formulated. Each FJE is mapped to an FJE matrix Ω_p from the initial validation matrix Ω. For example, with the validation matrix Ω, eight FJE matrices can be obtained:

$\begin{array}{l} Ω_{1} = [\begin{matrix} 1 & 0 & 0 \\ 1 & 0 & 0 \\ 1 & 0 & 0 \end{matrix}], Ω_{2} = [\begin{matrix} 0 & 1 & 0 \\ 1 & 0 & 0 \\ 1 & 0 & 0 \end{matrix}], Ω_{3} = [\begin{matrix} 1 & 0 & 0 \\ 0 & 1 & 0 \\ 1 & 0 & 0 \end{matrix}], Ω_{4} = [\begin{matrix} 1 & 0 & 0 \\ 0 & 0 & 1 \\ 1 & 0 & 0 \end{matrix}] \\ Ω_{5} = [\begin{matrix} 0 & 1 & 0 \\ 0 & 0 & 1 \\ 1 & 0 & 0 \end{matrix}], Ω_{6} = [\begin{matrix} 1 & 0 & 0 \\ 1 & 0 & 0 \\ 0 & 0 & 1 \end{matrix}], Ω_{7} = [\begin{matrix} 0 & 1 & 0 \\ 1 & 0 & 0 \\ 0 & 0 & 1 \end{matrix}], Ω_{8} = [\begin{matrix} 1 & 0 & 0 \\ 0 & 1 & 0 \\ 0 & 0 & 1 \end{matrix}] \end{array}$

As a direct consequence of the two assumptions, the Ω_p matrices have exactly one "1" value per row. Also, except for the first column which maps to clutter, there can be at most one "1" per column. When the number of connected tracks grows in a cluster, the number of FJE increases rapidly. The jpdaEvents function uses an efficient depth-first search algorithm to generate all the feasible joint event matrices.

Track Structure

The fields of a track structure are:

Field	Definition
`SourceIndex`	Unique source index used to distinguish tracking sources in a multiple tracker environment.
`TrackID`	Unique track identifier used to distinguish multiple tracks.
`BranchID`	Unique track branch identifier used to distinguish multiple track branches.
`UpdateTime`	Time at which the track is updated. Units are in seconds.
`Age`	Number of times the track survived.
`State`	Value of state vector at the update time.
`StateCovariance`	Uncertainty covariance matrix.
`TrackLogic`	Confirmation and deletion logic type, returned as `'History'` or `'Integrated'`.
`TrackLogicState`	The current state of the track logic type. Based on the logic type `TrackLogic`, the logic state is returned as: `'History'` – A 1-by-K logical array, where K is the number of latest track logical states recorded. In the array, 1 denotes hit and 0 denote miss. `'Integrated'` – A nonnegative scalar. The scalar represents the integrated probability of existence of the track. The default value is 0.5.
`IsConfirmed`	Confirmation status. This field is `true` if the track is confirmed to be a real target.
`IsCoasted`	Coasting status. This field is `true` if the track is updated without a new detection.
`IsSelfReported`	Indicate if the track is reported by the tracker. This field is used in a track fusion environment. It is returned as `true` by default.
`ObjectClassID`	Integer value representing the object classification. The value `0` represents an unknown classification. Nonzero classifications apply only to confirmed tracks.
`ObjectAttributes`	Additional information of the track.

Documentation

Joint Probabilistic Data Association Multi Object Tracker

Description

Ports

Input

Detections — Detection list Simulink® bus containing MATLAB® structure

Prediction Time — Track update time real scalar

Dependencies

Cost Matrix — Cost matrix real-valued Nt-by-Nd matrix

Dependencies

Detectable TrackIDs — Detectable track IDs real-valued M-by-1 vector | real-valued M-by-2 matrix

Dependencies

Output

Confirmed Tracks — Confirmed tracks Simulink bus containing MATLAB structure

Tentative Tracks — Tentative tracks Simulink bus containing MATLAB structure

Dependencies

All Tracks — Confirmed and tentative tracks Simulink bus containing MATLAB structure

Dependencies

Info — Additional information for analyzing track updates Simulink bus containing MATLAB structure

Dependencies

Parameters

Filter initialization function — Filter initialization function @initcvekf (default) | function handle | character vector

Feasible joint events generation function name — Feasible joint events generation function name @jpdaEvents (default) | function handle | character vector

Maximum number of tracks — Maximum number of tracks 100 (default) | positive integer

Maximum number of sensors — Maximum number of sensors 20 (default) | positive integer

Absolute tolerance between time stamps of detections — Absolute tolerance between time stamps of detections 20 (default) | positive integer

Simulate using — Type of simulation to run Interpreted Execution (default) | Code Generation

Threshold for assigning detections to tracks — Threshold for assigning detections to tracks 30*[1 Inf] (default) | positive scalar | 1-by-2 vector of positive values

Threshold to initialize a track — Threshold to initialize a track 0 (default) | scalar in the range [0, 1]

Probability of detection — Probability of detection 0.9 (default) | scalar in the range [0, 1]

Spatial density of clutter measurements — Spatial density of clutter measurements 1e-5 (default) | positive scalar

Type of track confirmation and deletion logic — Confirmation and deletion logic type History (default) | Integrated

Confirmation threshold [M N] — Track confirmation threshold for history logic [2, 3] (default) | real-valued 1-by-2 vector of positive integers

Dependencies

Deletion threshold [P Q] — Track deletion threshold for history logic [5, 5] (default) | real-valued 1-by-2 vector of positive integers

Dependencies

Threshold for registering 'hit' or 'miss' — Threshold for registering a 'Hit' or a 'Miss' 0.2 (default) | scalar in the range [0, 1]

Dependencies

Confirmation threshold [Probability] — Track confirmation threshold for integrated logic 0.95 (default) | positive scalar

Dependencies

Deletion threshold [Probability] — Track deletion threshold for integrated logic 0.1 (default) | positive scalar

Dependencies

Spatial density of new targets — Spatial density of new targets 1e-5 (default) | positive scalar

Dependencies

Time rate of true target deaths — Time rate of true target deaths 0.01 (default) | scalar in the range [0, 1]

Dependencies

Prediction time source — Source of prediction time Auto (default) | Input port

Enable cost matrix input — Enable input port for cost matrix off (default) | on

Enable detectable track IDs input — Enable detectable track IDs input off (default) | on

Enable tentative tracks output — Enable output port for tentative tracks off (default) | on

Enable all tracks output — Enable output port for all tracks off (default) | on

Enable information output — Enable output port for analysis information off (default) | on

Source of output bus name — Source of output track bus name Auto (default) | Property

Source of output info bus name — Source of output info bus name Auto (default) | Property

Model Examples

Track Vehicles Using Lidar Data in Simulink

Track Closely Spaced Targets Under Ambiguity in Simulink

Algorithms

Tracker Logic Flow

Feasible Joint Events

Track Structure

Extended Capabilities

C/C++ Code Generation Generate C and C++ code using Simulink® Coder™.

See Also

Blocks

Functions

Objects

System Objects

Topics

Sensor Fusion and Tracking Toolbox Documentation

Support

`Detections` — Detection list
Simulink^® bus containing MATLAB^® structure

`Prediction Time` — Track update time
real scalar

`Cost Matrix` — Cost matrix
real-valued N_t-by-N_d matrix

`Detectable TrackIDs` — Detectable track IDs
real-valued M-by-1 vector | real-valued M-by-2 matrix

`Confirmed Tracks` — Confirmed tracks
Simulink bus containing MATLAB structure

`Tentative Tracks` — Tentative tracks
Simulink bus containing MATLAB structure

`All Tracks` — Confirmed and tentative tracks
Simulink bus containing MATLAB structure

`Info` — Additional information for analyzing track updates
Simulink bus containing MATLAB structure

`Filter initialization function` — Filter initialization function
`@initcvekf` (default) | function handle | character vector

`Feasible joint events generation function name` — Feasible joint events generation function name
`@jpdaEvents` (default) | function handle | character vector

`Maximum number of tracks` — Maximum number of tracks
`100` (default) | positive integer

`Maximum number of sensors` — Maximum number of sensors
`20` (default) | positive integer

`Absolute tolerance between time stamps of detections` — Absolute tolerance between time stamps of detections
`20` (default) | positive integer

`Simulate using` — Type of simulation to run
`Interpreted Execution` (default) | `Code Generation`

`Threshold for assigning detections to tracks` — Threshold for assigning detections to tracks
`30*[1 Inf]` (default) | positive scalar | 1-by-2 vector of positive values

`Threshold to initialize a track` — Threshold to initialize a track
`0` (default) | scalar in the range [0, 1]

`Probability of detection` — Probability of detection
`0.9` (default) | scalar in the range [0, 1]

`Spatial density of clutter measurements` — Spatial density of clutter measurements
`1e-5` (default) | positive scalar

`Type of track confirmation and deletion logic` — Confirmation and deletion logic type
`History` (default) | `Integrated`

`Confirmation threshold [M N]` — Track confirmation threshold for history logic
`[2, 3]` (default) | real-valued 1-by-2 vector of positive integers

`Deletion threshold [P Q]` — Track deletion threshold for history logic
`[5, 5]` (default) | real-valued 1-by-2 vector of positive integers

`Threshold for registering 'hit' or 'miss'` — Threshold for registering a 'Hit' or a 'Miss'
`0.2` (default) | scalar in the range [0, 1]

`Confirmation threshold [Probability]` — Track confirmation threshold for integrated logic
`0.95` (default) | positive scalar

`Deletion threshold [Probability]` — Track deletion threshold for integrated logic
`0.1` (default) | positive scalar

`Spatial density of new targets` — Spatial density of new targets
`1e-5` (default) | positive scalar

`Time rate of true target deaths` — Time rate of true target deaths
`0.01` (default) | scalar in the range [0, 1]

`Prediction time source` — Source of prediction time
`Auto` (default) | `Input port`

`Enable cost matrix input` — Enable input port for cost matrix
off (default) | on

`Enable detectable track IDs input` — Enable detectable track IDs input
off (default) | on

`Enable tentative tracks output` — Enable output port for tentative tracks
off (default) | on

`Enable all tracks output` — Enable output port for all tracks
off (default) | on

`Enable information output` — Enable output port for analysis information
off (default) | on

`Source of output bus name` — Source of output track bus name
`Auto` (default) | `Property`

`Source of output info bus name` — Source of output info bus name
`Auto` (default) | `Property`

C/C++ Code Generation
Generate C and C++ code using Simulink® Coder™.