Tracking Object Merger

Purpose

This package try to merge two tracking objects from different sensor.

Inner-workings / Algorithms

Merging tracking objects from different sensor is a combination of data association and state fusion algorithms.

Detailed process depends on the merger policy.

decorative_tracker_merger

In decorative_tracker_merger, we assume there are dominant tracking objects and sub tracking objects. The name decorative means that sub tracking objects are used to complement the main objects.

Usually the dominant tracking objects are from LiDAR and sub tracking objects are from Radar or Camera.

Here show the processing pipeline.

time sync

Sub object(Radar or Camera) often has higher frequency than dominant object(LiDAR). So we need to sync the time of sub object to dominant object.

data association

In the data association, we use the following rules to determine whether two tracking objects are the same object.

• gating
  • distance gate: distance between two tracking objects
  • angle gate: angle between two tracking objects
  • mahalanobis_distance_gate: Mahalanobis distance between two tracking objects
  • min_iou_gate: minimum IoU between two tracking objects
  • max_velocity_gate: maximum velocity difference between two tracking objects
• score
  • score used in matching is equivalent to the distance between two tracking objects

tracklet update

Sub tracking objects are merged into dominant tracking objects.

Depends on the tracklet input sensor state, we update the tracklet state with different rules.

tracklet management

We use the existence_probability to manage tracklet.

• When we create a new tracklet, we set the existence_probability to $p_{sensor}$ value.
• In each update with specific sensor, we set the existence_probability to $p_{sensor}$ value.
• When tracklet does not have update with specific sensor, we reduce the existence_probability by decay_rate
• Object can be published if existence_probability is larger than publish_probability_threshold
• Object will be removed if existence_probability is smaller than remove_probability_threshold

These parameter can be set in config/decorative_tracker_merger.param.yaml.

tracker_state_parameter:
  remove_probability_threshold: 0.3
  publish_probability_threshold: 0.6
  default_lidar_existence_probability: 0.7
  default_radar_existence_probability: 0.6
  default_camera_existence_probability: 0.6
  decay_rate: 0.1
  max_dt: 1.0

input/parameters

Default parameters are set in config/decorative_tracker_merger.param.yaml.

• the detail of tracker_state_parameter is described in tracklet management

tuning

As explained in tracklet management, this tracker merger tend to maintain the both input tracking objects.

If there are many false positive tracking objects,

• decrease default_<sensor>_existence_probability of that sensor
• increase decay_rate
• increase publish_probability_threshold to publish only reliable tracking objects

equivalent_tracker_merger

This is future work.