FOV optical flow measurement model does not match datasheet

[knmcguire]

So we were brought to the attention that the flowdeck's FOV in the code does not match the datasheet that we still have on the wiki (this should be moved to the right product page actually as well). The code says 4.2 degrees but the data sheet says 42 degrees, which indeed seem more realistic

The original implementation has been part of an Masterthesis work of @mgreiff and the documentation about the measurement model can be found on the website (which should also be updated). According to the text in the code it appears it was estimated at the time, so then I assume that the information on the datasheet wasn't available by then. @mgreiff, I know it has been a while ago but do you remember that part still from your master thesis?

So, the strange thing is, I've done some measurements ago as part of #608, where I also did ground truth measurements (converted lighthouse position (seperated from EKF) to flow with the same measurement), but that was using the exact same measurement model so I guess that doesnt count. It has been flying pretty good so far, so it might be somehow compensated for later in the code, but I can not find that so far.

The result of this could be, that the velocity has been underestimated by the measurement model and there was quite a difference between the measured pixel flow and the predicted one. So let's check that one out first.

[knmcguire]

Here is a nice plot of the predicted flow (based on the measurement model) and the actual measured flow, and there is no factor 10 off.

Also if it was off, we should have noticed this with the estimation, there is no way that the kalman filter would have converged if that was the case.

It would be good to have the code to reflect the datasheet better, so the search continues to find the element that compensates this 😄

[jonasdn]

We need more investigation, suggested next thing to check:

• Try to set it to 42.0f in the code and check the impact
• Check if we have "compensated" for this erronous value in some other tuning constant

We want to answer the question: Why does this work?