Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One questions on PoseOptimization #74

Open
wds01060202 opened this issue Apr 16, 2020 · 2 comments
Open

One questions on PoseOptimization #74

wds01060202 opened this issue Apr 16, 2020 · 2 comments

Comments

@wds01060202
Copy link

wds01060202 commented Apr 16, 2020

Thank you very much for sharing the code!
I am learning your code recently, and I have one questions on PoseOptimization functions, could you give me some instructions? Thanks in advance!

I see that in PoseOptimization() fuction the parameters is normal.
for example "const float thHuberNavStatePVR = sqrt(21.666);"
but in LocalBAPRVIDP() and GlobalBundleAdjustmentNavStatePRV() fuction the parameters is changed.
for example "const float thHuberNavStatePRV = sqrt(100*21.666);".

how you determine the values for Huber?

@ferreram
Copy link

Hi @wds01060202 ,
The Huber values are taken from the chi2 table, using the number of degrees of freedom of the measurements and an inlier probability (here the 21.66 value was chosen with 9 degrees of freedom as from the 9D vector representing position, rotation, velocity, and with an inlier probability of 1%).
However, for me, it does not make sense to use a robust cost function on the IMU measurements as they indeed follow a gaussian distribution. The use of Huber is more suited for handling visual measurements as some of them might come from outliers which completely break the gaussian distribution assumption and hence would result in very bad optimization if not discarded by the use of a robust cost function.
My guess for the weird 100 factor used in GlobalBundleAdjustmentNavStatePRV() is that bad results were obtained when keeping the 21.666 value and that better results could be achieved when adding the 100 factor. However, multiplying by 100 most likely removes the effect of the Huber cost as it is unlikely that the IMU measurements error gets over the Huber threshold.

@wds01060202
Copy link
Author

wds01060202 commented Apr 27, 2020

Hi @wds01060202 ,
The Huber values are taken from the chi2 table, using the number of degrees of freedom of the measurements and an inlier probability (here the 21.66 value was chosen with 9 degrees of freedom as from the 9D vector representing position, rotation, velocity, and with an inlier probability of 1%).
However, for me, it does not make sense to use a robust cost function on the IMU measurements as they indeed follow a gaussian distribution. The use of Huber is more suited for handling visual measurements as some of them might come from outliers which completely break the gaussian distribution assumption and hence would result in very bad optimization if not discarded by the use of a robust cost function.
My guess for the weird 100 factor used in GlobalBundleAdjustmentNavStatePRV() is that bad results were obtained when keeping the 21.666 value and that better results could be achieved when adding the 100 factor. However, multiplying by 100 most likely removes the effect of the Huber cost as it is unlikely that the IMU measurements error gets over the Huber threshold.
Hi @ferreram
Thank you for your reply, I agree your point.when i cheak the information Matrix of imu graph edge,i find it is very huge compared to the graph edge of vision, it means that the measurements error can gets over the Huber threshold easily. I guess that the author @jingpang trust the imu more,so he used the weird 100 factor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants