Purpose / Use cases
This document defines the high level architecture that the object tracker follows.
Architecture
tracking architecture
Workflow
The fundamental operation of a tracker is as follows (bold represents implementation-specific items):
- Update existing tracks to the most up-to-date coordinate frame
- Receive observations
- Associate observations to existing tracks
- Appropriately transform observations, if needed (this is unambiguous given a target frame)
- Update the tracks as needed (e.g. temporal update, depends on motion model)
- Compute the association weight/probability for each track-observation pair (depends on association model)
- Generate merge/split hypothesis (depends on merge/split model)
- Cache relevant information (this is implementation specific)
- Run the association algorithm (e.g. JVC, hungarian, GNN, PDA, depends on association algorithm)
- Get results
- Update observed tracks
- Perform the appropriate transform of observation given an associated track (unambiguous given target frame, e.g. converting message type to internal representation)
- Apply the observation update to the track (depends on state estimator and motion model)
- Potentially perform track classification (depends on track classification model)
- Resolve many-to-many matches
- Resolve merges (merges are potentially unambiguous given a decent state estimate model)
- Resolve splits (duplicate tracks, each with different single assignment)
- Initialize new tracks
- Update unassociated tracks
- Prune tracks if need be (depends on pruning rule)
- Aggregate and transform the remaining tracks into the appropriate representation (unambiguous given the message type, i.e. transform internal track type to the track message type)