-
Notifications
You must be signed in to change notification settings - Fork 13
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
Explore robust pose estimation #269
Comments
I dived into this a couple weeks ago. Didn't get as far as to write code, but I did came up with some notes and a plan of action:
So, an OGK estimator and qselect medians would be a good start IMO. |
For further reference, section 6.8 of Robust Statistics: Theory and Methods (with R) book, also co-authored by Ricardo Maronna, covers several competing methods. I only skimmed through it though. |
This is ok by me, but we should first test the hyphotesis about what the problem is before looking for performant solutions for it. I would definitely not want spend a couple months implementing an unproven way to solve a problem we are not sure we have.
I would still start with this before trying anything else. This is already far better than what we have and it's been extensively tested in the use cases we are mainly interested in. Afterwards, let's keep in mind that "real-time" is in the eyes of the beholder. It's the users that strike the balance between their application and the resources they throw into it. Most likely a "slow" solution will not be the default for
I'm afraid not. Looks like he works at Ciencias Exactas. |
Absolutely. That is why this is an exploration. I stared down the rabbit hole only to make sure this isn't a dead-end (as it would have been if we implement something like MCD only to realize it takes seconds to yield an estimation).
I'm on the fence about this. Doing exactly what Nav2 AMCL does is the low hanging fruit and it ensures we won't do worse. It also means we won't do any better (in terms of localization performance, we can still marginally improve in terms of computational performance).
That's technically true, but if your solution is an order of magnitude slower for typical operation rates (1-10 Hz?) on modern CPUs (i5, i7, i9, Ryzen 5, Ryzen 7) then it is highly likely that it will be useless in most cases. |
Feature description
Recent benchmarks have shown that, while Beluga AMCL and Nav2 AMCL are on par on average, Beluga's worst case performance (i.e.$sup \mathrm{APE}$ ) is subpar compared to good ol' AMCL.
One possible cause for this discrepancy, and the one I entertain the most, are outliers. Outliers would skew Beluga's pose estimation, which relies on sample statistics only, whereas Nav2 AMCL's clustering algorithms may naturally exhibit some resistance to them.
While we could simply work our way forward with #258, I think there is value in exploring methods purposely designed for outlier rejection, and in particular, those from the robust statistics domain.
Implementation considerations
Beluga's design is advantageous for this: robust pose estimation support amounts to adding a new estimator mixin.
The text was updated successfully, but these errors were encountered: