Initializing user-defined a-priori covariance for tracker objects (trackerTOMHT).

Hello all,

I am currently in the process of implementing a multi-target tracker for processing space-based observations of asteroids (from the WISE spacecraft). Currently, I am using the trackerTOMHT tracker, but I believe this question would extend to the other multi-target tracking algorithms that MATLAB has in its sensor fusion and tracking toolbox as it mainly has to do with the filtering aspect of multi-target tracking (MTT).

I am currently feeding the tracker Right-Ascension and Declination (RADec) angles as measurements , with the associated measurement noise covariance matrix as objectDetection objects for each measurement on each scan, and all is working well for my test case with scaled data (angles in the range ). The issue arises when I try to un-scale my test data (RADec angles in the range ) as well as run the tracker on the real data (same order of magnitude difference in measurements over the course of the data).

I initially made this decision to scale the data as I was noticing that upon processing the first scan, trackerTOMHT (using @initcvkf as the tracker filter) initializes the position (angle) covariances as the matrix diagonals, but initializes the velocity (angle rate) covariances as 100. When operating on the unscaled test (and real) data with relatively small differences in angles throughout the scenario, this covariance is drastically too large and causes far too many measurements to be considered in the gating process. This essentially stalls the tracker as it never makes it through the first scan due to all measurements being considered for all tracks (an intractable problem).

This leads me to my main question:

• I am wondering if there is a way to define an initial covariance that is used upon the initialization of any track within trackerTOMHT. This seems to me like a functionality that should be there somewhere, as a-priori knowledge of the tracking scenario seems like it would be helpful in obtaining the best MTT results. This is the main issue that I am facing, and the alternative is to just scale the real data such that an a-priori velocity covariance of 100 is realistic, but I would like to avoid that. I have scoured the documentation to no avail.

Other questions that would be nice to have answered but are not necessary:

• Is there a way to assign each measurement an associated probability of detection ? Upon tracker initialization, a blanket is declared which covers all measurements. I am using a matched filter with binary hypothesis testing to extract positional measurements from images, so each measurement has an associated based on the statistical significance of the detection.
• Is there a way to declare the dimensionality of the tracking problem? I am currently using the 'StateParameters' argument to trackerTOMHT as follows to try and force the problem to be 2D, but when I try a filter other than @initcvkf, it does not accept the 2-dimensional state vector.

% State of sensor
stateParams.Frame = 'Rectangular';
stateParams.Position = [0 0];
stateParams.Velocity = [0 0];

tracker = trackerTOMHT( ...
    'FilterInitializationFcn', @initcvkf,...
    'StateParameters', stateParams,...
    );

Of course there are more arguments to the trackerTOMHT() call for tuning purposes, but I omitted them for clarity.

• Some of the built-in track viewer functions such as trackPlotter, or alternatively error quantifying tools such as trackErrorMetrics do not accept my 2D state vectors (4 element state vectors as opposed to the typical 6). Is there a way of altering the dimensionality of these tools as well?

If any part of my questions are unclear, please respond and I can clarify with more code/data to better flesh out the problem. Thank you everyone!

Answer 1

[Elad Kivelevitch]

Hi Anthony,

Thanks for the question. It's a very interesting and probably challenging problem for the TOMHT tracker.

To answer your questions, here are a few suggestions:

Is there a way to define an initial covariance ?

Yes, there is an easy way to do that. You should create your own filter initialization function and it's not as daunting as it might sound.

Copy the initcvkf (or any other init function) into your work directory and rename it. Suppose you call it initRADecFilter to indicate that it is initialization a filter using to track the RADec parameters.

In the new function:

Initialize the StateCovariance property to any values you would like.

Can the dimensionality of the problem be 2D for filters that are not created by initcvkf?

Yes, they can be. For clarity, let's assume you being with initcvekf. In your copied and renamed function, define the State size to be 4-by-1 instead of 6-by-1. This will allow you to have a 2-D problem. You will also need to create a new constant velocity measurement model to replace cvmeas that always returns a 3-D measurement. It's very easy to do. Create a function cvmeas2D like this:

function [measurement, bounds] = cvmeas2D(state, varargin)
[measurement3, bounds3] = cvmeas(state, varargin)
measurement = measurement3(1:2,:);
bounds = bounds3(1:2,:);
end

Similarly, create a function based on cvmeasjac to return a 2-D measurement Jacobian.

Can you define a PD per each measurement?

There are a couple of way of handling that, but it would require a little more work.

• If you want to use the PD in computing the measurement: When you pack your measurements into the objectDetection format, you can use the MeasurementParameters property to specify PD. The MeasurementParameters are used by the measurement function that you define to calculate association distance, measurement likelihood, and filter correction. So, you can use them to update the measurement.
• If you just want to pass the PD through the tracker, you can add the PD to the ObjectAttributes property. The trakcer attaches them to the associated track and then to the track output.

You can also define PD for each track. To do that, see the HasDetectableBranchIDsInput property of the tracker and how to use it in the step. You will essentially call the step method with an additional matrix input with BranchID as the first column and PD as the second column. This is useful if your sensor doesn't cover all tracks all the time. Use the getBranches method to get all the branches (track hypotheses) maintained by the tracker in the previous step.

How to limit association/gating

You mentioned performance issues. To limit some of the association possibilities, use the 4th element of the AssociationThreshold value to a finite value. This limits which tracks are considered for association with each detection and if you set a strict gate, you can eliminate many association options.

[Anthony Zara]

Elad,

Thanks for the incredibly detailed answers to all my questions! This is incredibly helpful and will no doubt help me solve the problem at hand.