OCV YOLO Tracking can generate zero-sized detections

[jrobble]

From @fpertl :

the DFT assignment seems to make an error (assigning wrong object to track, white car I think). That also makes the residual error of the Kalman Filter pretty large. The I think the the filter tries to estimate/predict motion based on a large "jump" in object location resulting in large velocities and size changes. The next prediction is way off and probably put the prediction outside the frame, which leads to 0 size after intersection with the frame. At least in this instance that seems to be what is happening. If we wanted to tune things a little to the scenario, one could slightly lower the KF_MAX_ASSIGNMENT_RESIDUAL (defaults to 2.5)

Changing detection parameters to suit the specific case is always a little dicey though

As a fix, at least a quick one, we could throw out the non-sense detections prior to returning them regardless the cause. This would make sense to me, at least for production, so things don't get messed up down the line.

The more proper way it to somehow constrain the KF to not wander out of the frame, but that is a little more involved and would require some reasonably good testing to make sure it works properly everywhere else in the component code. The best place to probably do that in the code is in Track::kalmanCorrect

I think we could edit the Track::kalmanCorrect function to not "correct" coordinates to zero of off-screen despite what the dynamics of the detections might indicate (correctly or in error). I'm just slightly weary of how it will change the behavior of the KF. So we should test it with a couple of cases if that is what we want to do.

I think either way the tracking will still make mistakes in some instances. So I'd be good with the "brute-force" approach of just tossing the 0 sized detections at the end. Which ever way we want to go.

[fpertl]

The scenario where YOLO detection size is set "too small" to reliably detect objects will exasperate the issue: e.g. if there are two similar looking objects and their detections are unreliable, i.e. the pop in an out in subsequent frames, then the odds of them being assigned to the same track (incorrectly) increase. This then feeds "bad" position data to the filter which causes it to wrongly estimate velocity and future position. To address the zero size detections in OCV Yolo (probably only) caused by Kalman Filter correction step, we could just skip the correction when it results in zero size. I this changing the Track::kalmanCorrect as follows would accomplish that:

void Track::kalmanCorrect(const float edgeSnap){
  if(_kfPtr){                                                               
    LOG_TRACE("kf meas:" << locations.back().getRect());
    _kfPtr->correct(locations.back().getRect());

    cv::Rect2i corrected =  snapToEdges(locations.back().getRect(),
                                        _kfPtr->correctedBBox(),
                                        locations.back().frame.bgr.size(),
                                        edgeSnap);

    if(   corrected.width  == 0 || corrected.height == 0){
      // corrected bbox is zero area, use original instead.
     _kfPtr->setStatePostFromBBox( snapToEdges(locations.back().getRect(),
                                               locations.back().getRect(),
                                               locations.back().frame.bgr.size(),
                                               edgeSnap));
    }else{
      _kfPtr->setStatePostFromBBox(corrected);
       locations.back().setRect(corrected);
    }
    LOG_TRACE("kf corr:" << locations.back().getRect());
  }
}

If we still get zero sized detections then there are additional bugs. Another potential improvement that I think might help prevent detections being assigned to the incorrect track would be to make the residual check flag a relative increase (once it is above a reasonable minimum value), rather than a hard limit here.