Hacker News Reader

Comment by leot | Hacker News Reader

Do you have a citation on phones using inertial navigation?

The technical term is usually sensor fusion and route prediction, this is how your phone knows that if it gets a weird echo from the GPS signal that you haven't jumped 150 meters forward under 1 second or help you navigate in doors etc.

It is also used for indoor navigation, Google had quite a few talks about this this one is from Google I/O 2013 https://www.youtube.com/watch?v=oLOUXNEcAJk (click to https://youtu.be/oLOUXNEcAJk?t=1985 if you want to see the break down).

There were a few better/more technical talks from 2010 and a few more recent ones that I'm trying to find again.

On android this is exposed through the Fused Sensor Location provider https://developers.google.com/android/reference/com/google/a....

"Fused Location Provider: Get highly accurate location information (latitude and longitude) based on combined signals from the device GPS and sensors."

I found the 2010 technical talk https://www.youtube.com/watch?v=C7JQ7Rpwn2k

And the 2nd 2013 talk https://youtu.be/Bte_GHuxUGc?t=400

I'd also be curious to see a reference for

Orientation/heading from a phone's gyroscope/compass can be pretty reasonable, but most mems accelerometers are pretty much crap for dead reckoning use when loosely attached to a person. I could definitely see some interesting ideas with cell tower position data + heading + pedometer estimation getting merged, but I have a hard time believing that works in practice.

This isn't using a "pedometer" this is fusing the input from multiple sensors like gyro, accelerometer, magnetometer, barometer etc. as well as other location data (wifi/gps/cellular/beacons etc.) and extrapolating the location using a path prediction algorithm.

Given a known starting point, or a known point in general this increases both the speed and accuracy of identifying your location considerably even outdoors.

I think we're starting from the same assumptions - my reference to pedometer meant the software-fused data from whatever on-board inertial/nav sensing was available, 6DOF IMU, compass, etc... In practice in consumer products I most often see this provided as "estimated distance" based on a learned or hard-coded model of what a single step looks like from the IMU (the pedometer part) + the output of GPS/cell/wifi localization.

I'm specifically curious about evidence for a commercial smartphone that can track you to room-level accuracy using only IMU + GPS. (Add in wifi or other RF triangulation and it's clearly a solved problem.) In practice with a cell-phone GPS receiver and IMU only, attached to a person it is a hard problem to track a path to within a few meters. Trying to use accelerometer data to get position information over more than fractions of a second in that situation is... tricky.

This is what Google does, the GPS updates are actually pretty infrequent, especially if you specify low power mode, or they detect a slow activity and or you are indoors. Google's location API fuses all the sensors, they rely heavily on sensor data for indoor tracking and it's been getting pretty darn good since they've introduced it 2-3 years ago. I've linked a few google talks in this thread already, and you can read about the Fused Location API.

Research has been done before on using the gyro + accelerometer on a smartphone as an IMU (inertial measurement unit) to augment positioning; see for example: http://gpsworld.com/showing-smartphones-the-way-inside/

However the last I heard, powering the gyro + accelerometer constantly was a prohibitive drain on the battery and the relatively low grade sensors used in smartphones made the positional drift rate high enough to be problematic, so I'm pretty sure that the original poster above is misinformed. I'm not aware of any smartphones that use inertial dead reckoning to augment their positioning.

Google has been supporting this since API version 10, this is the default (and only) location provider if you are using the Google Play Services API. https://youtu.be/Bte_GHuxUGc?t=400

Then skip https://youtu.be/Bte_GHuxUGc?t=700 to for the deep dive :)

You can still do location "manually" by either using GPS or sensor data using the Android framework.

Thanks for those links - I think they frame the progress on localization really nicely. They also make clear the improvements are based on fusion of GPS + wifi + IMU/sensors. Adding IMu data to the existing mix is a clear win, but there's a major difference between that and using the IMU for dead reckoning alone. I think that's worth clarifying since the thread started out talking about localization with wifi disabled (although disabled clearly doesn't quite mean what you think it might in this context.)

Oh no they don't use that alone, the amount of data they receive from the sensors and how it factors into everything also varies, if you got that impression it's my bad, I thought I was clear that when you enable the "location services" in Android it works all the time in the background regardless of what you have explicitly enabled or not they even state that when you turn it on. Pretty much the IMU data is used to prevent jumps, enable them to use better path predicting algorithms and to provide coverage in doors, if you don't want them tracking you disable the background location services, or well sadly don't take the phone with you.

P.S.

I'm pretty sure that iOS has the same thing, I also know that there are a few startups that want to push their own location provider service including sensor based tracking, I've played around with pathsense their location API was faster and considerably* more accurate than Google's https://pathsense.com

*As far as jitter goes, if you are talking about accuracy only to the point of "is jim at the juicebar on the corner of Main St. and 8th.?" they both work pretty much the same.

Reply on news.ycombinator.com