Was this page helpful?

Multiframe correspondence tracker model

From $1

    NOTES: (2009 Mar 06)

    • as of radR 276, the parameter minimum gain for a blip to join a track is now specified and displayed in "log units".  You can convert between old and new values for this parameter using new functions:

    gain.log.units <- TRACKER$gain.to.log.units(gain.old.units)
    gain.old.units <- TRACKER$log.units.to.gain(gain.log.units)

    The old gain units were treated as a probability. (i.e. a number in the range [0, 1])
    The new log units can be thought of as the log odds ratio; i.e. log(p / (1-p))
    The effective range of this parameter is now roughly [-150, 150].
    The reason for the new units is that most of the observable change in behaviour for this parameter occurred when changing its value between, e.g. 0.9998 and 0.9999   Suggestions for other ways to treat this are welcome.

    • the multiframecorr parameter small penalty for blips missing from tracks  has in fact never been used in the tracker code!  This parameter is specified in the literature reference, but I inadvertently omitted it.  It will rarely have any effect on real data, but I will fix this anyway.  My apologies for any confusion and wasted time this may have caused you!

    • when a track is selected in the plot window, you can see the coordinates and details of its blips by entering tr in the console window.  You can still get the details of the track object itself (including the motion model state and the gain) by entering to in the console window.

    The multiframe correspondence (MFC) model works by considering the most recent k scans at a time.  As each new scan is examined, corrections to active tracks can be made by breaking the track at a point up to k-1 scans back, and joining the earlier portion of the track to one of the blips in the new scan.  The later portion of the broken track is removed, and blips left over this way are reassembled into tracks using nearest neighbour. [Fixed as of radR595: FIXME:  we should be using maxmatching rather than maxpathcover on leftover blips to exactly implement the algorithm as published].

    MFC starts with two scans, matching blips between them using nearest neighbour.  Having done that, it can assign a velocity to the set of matched blips in the 2nd scan (it knows how far the blip moved, and how long it took).  Then, when the third scan comes in, it considers all possible "connections" between blips in the first two scans, and those in the third.

    Suppose blips X, Y, and Z are from scans 1, 2, and 3:

    Scan 1      Scan 2       Scan 3


     \                         /

      \                       /


    The algorithm considers possible new track segments (labelled with ">>"), i.e. either "extending" the track to be X->Y->Z, or "correcting"
    the X->Y track to be X->Z instead.  But now, it's no longer using just distance information, it's predicting where the target
    would be in scan 3 if it actually was at X in scan 1, and Y in scan 2, assuming a constant velocity.  If that predicted location is reasonably
    close to point Z, then it chooses to "extend".  If the predicted location is far from Z, but Z is actually pretty close to X, then it chooses to
    "correct", on the assumption that Y was noise and the target just wasn't showing up in scan 2.  It also considers how similar the directions
    X->Y and Y->Z are.  The closer they are, the more favourable for extending X->Y to X->Y->Z.

    When the 4th scan comes in, the same thing happens.  All possible track segments connecting the existing points and the ones in the new scan are considered, making the set of choices that match up best overall.  What is meant by best overall is described in the next section.

    The gain functions

    The tradeoffs between various possible assignments of blips to tracks are made by computing a gain function for each combination of track and blip, (or each pair of blips for when considering only 2 scans).  You can think of this as "how good is the match between track and blip" (or "how good is the match between two blips"). For convenience, gain functions return a number between 0.0 (terrible match) and 1.0 (best possible match).

    The gain function used for evaluating the matching between a blip in one scan and a blip in the next is:

        gain(blip1, blip2) = 1 - (distance(blip1, blip2) / max_interblip_distance)

    and this is called nearest neighbour because it results in blips typically being matched to their nearest neighbours.
    (Don't confuse this with the nearest neighbour tracker model, which is a separate model that uses the same general idea.)

    The gain function used for evaluating the matching between a track with blips track[1]...track[n] and a blip in the next scan is:

       gain(track, blip) =     alpha     * proximity_to_prediction(track, blip)

                           + (1 - alpha) * directional_consistency(track, blip)

    There are two components, weighted by the parameter alpha, which is between 0.0 and 1.0:

       proximity_to_prediction(track, blip) =

            |blip - track[n] + track.velocity[n] * (blip.t - track[n].t)| / max_interblip_distance

    which predicts the target location based on the velocity at the track endpoint and the time elapsed between the
    track endpoint and the blip, then takes the distance between the blip location and this prediction, divided by the
    maximum interblip distance; and:

       directional_consistency(track, blip) = abs(angle(track.velocity[n], blip - track[n]) / 180)

    which is the scaled angle between the velocity at the track endpoint, and the displacement between the track
    endpoint and the blip.

    Watching the gain function in action

    [2009/03/09: there is a bug in the gain display; it often shows +/-Inf at all cursor positions.]

    To improve the quality of tracks, we need to improve the gain functions.  This can be facilitated by a feature that allows you to examine the value of the gain function at various points in a track's history. To do this, enable the tracker, bliptrails, and pointerinfo plugins, and make sure you have selected the multiframe correspondence model.

    If you pause play and examine an active track (i.e. one which might still be extended with more blips, and which is coloured brightly on the plot), clicking on the track will surround its points with circles.  This is best seen zoomed in. By clicking on a circle, you select that point in the track as the anchor from which gain to various points is calculated as you move the cursor around the plot window.  The x, y, and z locations of the cursor correspond to locations on the axis of the radar antenna.  The t value corresponds to the time for the range and pulse you are hovering over, but shifted to the scan after the anchor point on the track.  If you have not selected an anchor point, the last point on the track is used implicitly, and the time at the cursor position is shifted forward one scan:


    By zooming in sufficiently, you should be able to sequentially compute the gains that were used in building a track: selecting the first point and move the cursor to the second point (i.e. the centre of the second circle); select the second point and move the cursor to the third point, and so on:


    To see the actual values of the gains that were saved, enter "to" in the console window after selecting the track.  This variable contains the gains and the velocities for all but the first point in the track.  (The variable "tr" works similarly, but holds a table of x, y, z, and t locations for the track.)


    Was this page helpful?
    Tags: (Edit tags)
    • No tags
    FileSizeDateAttached by 
    Examining the gain function for the selected track when no point is chosen as anchor.
    66.89 kB20:17, 12 Sep 2007JohnActions
    Examining the gain when a point is chosen as the anchor.
    70.15 kB20:17, 12 Sep 2007JohnActions
    The saved gain and state data for the selected track. Only available for active tracks.
    23.85 kB20:02, 12 Sep 2007JohnActions
    Comments (0)

    Powered by MindTouch Core