Refactoring

[henriksod]

Regarding the structure proposed in the wiki.

These are my thoughts:

• One issue comes with separating the kalman filters from each tracker implementation. Since each tracker has the kalman filter implemented in a slightly different way, they all have different expectations on the interface. This leads to the inevitable fact that we have to:
  • Either adapt each tracker to the new common kalman filter interface...
  • ...or implement adapters.
• As for kalman filter tuning, it would have to be done via config files for now, or stubbed in the adapters (if we decide to do it that way). Evolving these parameters can probably be done, and then it makes sense to have the parameters stored in the config files, for each tracker.
• Another thought is that we could easily create an abstract TrackingMethod class that all the trackers inherit from, that has the required interfaces defined. This won't change the functionality, but allows code to be re-used if needed. (see ocsort and strongsort)

Any thoughts about this or any proposals?

[mikel-brostrom]

Adepters make sense. The config yamls can be subdivided into: tracker and kf. A trackingclass that all the other inherits from make sense as well