Velocity tracking

[Dmytro-Shvetsov]

Hello, I was woundering if there's a way of extending existing functionality by adding velocity parameter to the track outputs. If it is possible, could you guide me how I should change motpy/motpy/model.Model or maybe add a new preset to motpy/motpy/model.ModelPreset . I assume the speed of my objects to track is constant

Thank you in advance!

[wmuron]

Hi Dmytro. Please note that for order >= 1, the velocity (horizontal and vertical) is a part of the object state. I've prepared an example presenting the velocity here https://github.com/wmuron/motpy/compare/development...test-velocity (run examples/2d_multi_object_tracking.py example)

[Dmytro-Shvetsov]

@wmuron Excellent example! I dug into Kalman filters a bit more since I've posted the question and I tried to modify some parameters to measure a real km/h velocity of a vehicle. Am I understanding this correctly that your example evaluates pixel velocity and to solve my problem I would have to: 1) project bounding boxes on the ground 2) feed obtained boxes to the tracker and get the pixel velocity 3) multiply the velocity by meters per pixel constant given the real environment distance

[wmuron]

@Dmytro-Shvetsov One possible solution to project boxes on the ground is to calculate and use homography matrix to project the scene (along with each detection or track) to bird-eye view. Obviously, you'll still need to get obtain some kind of calibration data (e.g. width of the lane, lane marking length or some other known distances etc.) to calculate a relation of pixels (in bird eye view) to meters. You can apply bird-eye transform on detections and track the transformed detections in bird-eye space or track in image space and transform active tracks to bird eye view. A couple of notes:

• The problem with the second solution is that it might be non-trivial to convert image-space pixel velocities to mph values.
• The problem with the first solution is that if your detections are unstable or quite distant from the ego camera, you might have trouble with the default matching function (because often transformed boxes won't overlap, especially in Y axis). Also the boxes after homography transform are not going to be rectangles (current IOU calculation relies on rectangular bounding boxes)
• In both cases, you could consider transforming the detection boxes to their bottom parts (e.g. the bottom 10% of the vehicle close to the ground), which will help limit errors when applying using homography to transform to bird-eye view
• Maybe you could try a hybrid approach, with tracking the bottom-box in image space and then "manual" velocity calculation for each vehicle in bird-eye space (since you know their IDs, it's easy).

[Dmytro-Shvetsov]

@wmuron Got it. Thanks a lot!