Ins velocity estimate

[knmcguire]

For now, just a pull request to the ins_velocity_estimate branch. Tomorrow I'll have another test flight, and then I'll send a pull request to master

[knmcguire]

I figured out the scaling problem. There was an error in the calculation of the velocity estimate, which used image width and height in combination with the focal length in pixels, which is incorrect. I also added an alternative velocity estimate as a comment.

[knmcguire]

how is it looking now, is it sufficient enough for a merge?

[knmcguire]

I also see that most of the changes that I've made is mostly inside the optical flow module (which was not necessary the purpose of this branch). If this is not yet sufficient for merge, could at least the current status of ins_velocity_estimate on the paparazzi repository be merged with the master? I would like to proceed with not changing the existing optical flow module itself any more, but with a velocity estimate from an external camera module.

[flixr]

Still TODO: actually calculate a realistic noise value (unit: m/s^2) in the opticflow module. Also we should decide if this should be the standard variation or already the variance (and rename that field as appropriate)...
Also do we want one value for this, or one per axis?
One per axis would be the best solution I think (not having a full covariance matrix, but just the diagonal).
Then you could also set the variance one one axis to Inf (or NaN) to indicate that that axis was not measured.

[knmcguire]

Yes, that is still something to be determined. I think that some quality values need to be logged together with the velocity estimate error with an optitrack system, and see if there is a correlation between them. Then an adaptive noise value can be made. This will take some time though to get it right, so I will ask somebody in the Lab who will work specifically on the optical flow module as it is. If a realistic noise model can be fitted for this, then the guidance control can be very robust.

From: Felix Ruess [mailto:notifications@github.com]
Sent: woensdag 11 november 2015 13:34
To: paparazzi/paparazzi
Cc: Kimberly Mcguire - LR
Subject: Re: [paparazzi] Ins velocity estimate (#1412)

Still TODO: actually calculate a realistic noise value (unit: m/s^2) in the opticflow module. Also we should decide if this should be the standard variation or already the variance (and rename that field as appropriate)...
Also do we want one value for this, or one per axis?
One per axis would be the best solution I think (not having a full covariance matrix, but just the diagonal).
Then you could also set the variance one one axis to Inf (or NaN) to indicate that that axis was not measured.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1412#issuecomment-155765223.