Applicability of NILoc to urban canyon problem
Closed this issue · 1 comments
Hi @Sachini,
First, I'd like to thank you for the effort to make your source code, models, etc. available for others to use. It doesn't seem to be the norm, but for those who can't create these tools from scratch, it's very valuable.
I'd like to present a different use case for NILoc and see if you think it (or maybe RONIN) may be applicable.
The problem I'm trying to solve is, starting from a known position (known by way of GNSS positioning), if I move to a different position where I don't have a GNSS signal (because it's obscured or for some other reason), if I'm capturing data from an IMU as I move from the known position to the second, can I deduce the second position from that IMU data? This is different from the situation in your research in that in my scenario there's no floor plan, as generally the locations in question are outdoors. I think that each point could be determined from the known origin point, rather than trying to do each sequentially (though perhaps always starting from the origin for each point would cumbersome), so maybe that would increase the odds of sucess.
I first tried to use the RONIN code, Android app, and models, but got stuck on the use of the game rotation vector (my question about this is here: Sachini/ronin#44 (comment)). I don't know if RoNIN is a better fit for the problem I'm trying to solve, though NILoc is geared toward location where RoNIN is more about navigation, so for that reason NILoc seems like the better fit.
Please let me know what thoughts you have and if you have any specific guidance on how I might proceed to use NILoc (or RoNIN) for my use case. I actually may have a working Tango phone, though I have never used it (it was procured for a different project that i didn't work on a few years ago). Sorry for the long post and thanks in advance.
NILoc relies on differences of motion imposed by the constraints from structure (building / floorplan) for localization. I believe the constraints are sparse in outdoor environments, therefore niloc is not helpful there.
If you have two distinct GNSS readings at the start, you can solve for the unknown rotation between ronin HACF and world frame, and use ronin for tracking. However, due to drift, even when the sensors are calibrated the localization accuracy is not guaranteed beyond 10 mins. If you anticipate sparse GNSS readings, a method similar to 2. IMU and WiFi Fusion by optimization can be adopted.