Live data from Hacker News

GPS

ciechanow.ski

231–240 of 296 posts

Re: GPS

#232
post #214

Earlier quoted context omitted.

There are certain streets in downtown SF where Android (and iOS) location always suddenly jumps to a block away. Navigation apps then direct drivers to make incorrect turns or even dangerous turns like turning the wrong way onto a one-way street. It seems to me that your software could prevent this error.

Yup! This issue, which is commonly described as the "wrong-side-of-the-street" or "wrong-city-block" error, is one of the biggest ones, and is where a lot of the innovation I mentioned is happening today. This occurs because in "urban canyons", meaning streets with tall high-rises or sky scrapers, there is little or no line of sight to GNSS satellites (GNSS being the generic term for all satellite positioning systems…

I wonder how the inventors of GPS would have responded if back in the early nineties you had suggested to just add a map of all the worlds high buildings to the GPS receiver.

Re: GPS

#233
post #41

This is very nice. Very clear, and the 3D interactives are excellent at guiding the explanation. One thing that I thought was a little confusing was right at the beginning, when we were estimating the position of the figurine and there was an area of uncertainty shown by the yellow circle. It isn't clear how you're estimating position, and why we have an area of uncertainty. At first I figured it was going to explain…

I actually stopped reading the guide when I got to this point, and I have a lot of experience working with GPS. My thought was, "If the simple parts are this unclear, I don't want to spend time getting to the more complex portions".

You should consider reading the rest of it, it's excellent after this.

Re: GPS

#234
post #214

Earlier quoted context omitted.

Yup! This issue, which is commonly described as the "wrong-side-of-the-street" or "wrong-city-block" error, is one of the biggest ones, and is where a lot of the innovation I mentioned is happening today. This occurs because in "urban canyons", meaning streets with tall high-rises or sky scrapers, there is little or no line of sight to GNSS satellites (GNSS being the generic term for all satellite positioning systems…

Trying to predict reflections by processing building geometry sounds very complicated and error-prone. Wouldn't it be easier to query Google Maps & Waze telemetry for impossible position jumps? Then you could make geofences where Google Play Services ignores position jumps and falls back to Wifi-based location and integrating the accelerometer.

We consider and integrate all kinds of solutions, accounting for building geometry is just one of them, and we do thorough validation to ensure it's actually helping. There's always various tradeoffs being made.

Ideally, clients will be using our Fused Location Provider API [0] which fuses any (or all) of GNSS, WiFi, accel, gyro, mag... with smoothing + filtering to provide the best location possible at any time while automatically managing power compromises; in effect, using WiFi + accel, as you described, along with more signals and filtering. However, some clients still choose to use pure GPS/GNSS, for various reasons.

Part of providing the best location experience possible (while simultaneously minimizing power drain...) is providing high accuracy at every percentile. Some techniques that may improve the average or median percentile error may cause higher errors at the 90% percentile. For example, let's say we check for "impossible" GNSS position jumps, and just ignore those. What if 10% of the time, the position it's jumping to is actually closer to the true position - since suddenly we might have better line of sight - and previously we were stuck at a worse estimate? What might help in one situation might hurt more in another. It's hard to build robust systems to handle every possible scenario and condition (on all sorts of different kinds of hardware from tons of vendors, since anyone can launch an Android device). It's even harder because, as you can image, smartphone grade sensors are magnitudes worse than those you find in survey or military grade hardware.

Also, WiFi-based localization can only be as good as the estimate of WiFi access point location, which isn't always great (and it's usually worse so since WiFi signal strength localization isn't that great), so GNSS is generally higher accuracy under good conditions (and hence rectifying GNSS error wherever we can is one of our goals), and the error of accel/gyro based dead-reckoning grows quadratically/cubically (due to double integration errors), so it doesn't get you very far.

[0] https://developers.google.com/location-context/fused-locatio...

Re: GPS

#235
post #232
post #214

Earlier quoted context omitted.

Yup! This issue, which is commonly described as the "wrong-side-of-the-street" or "wrong-city-block" error, is one of the biggest ones, and is where a lot of the innovation I mentioned is happening today. This occurs because in "urban canyons", meaning streets with tall high-rises or sky scrapers, there is little or no line of sight to GNSS satellites (GNSS being the generic term for all satellite positioning systems…

I wonder how the inventors of GPS would have responded if back in the early nineties you had suggested to just add a map of all the worlds high buildings to the GPS receiver.

I think we're doing all sorts of things now that people decades ago thought were simply impossible!

Re: GPS

#236
post #171

Amazing work. I work on the Android location team at Google, and I sent this article out to my team. GPS/GNSS is critical for accurate location/context, and there's still plenty of innovations happening in this field. One of our directors is Frank Van Diggelen - none other than the professor who taught the Stanford GPS MOOC referenced by the article :) I'm sure he is going to appreciate seeing the course called out t…

How many satelites are tracked by a typical android phone? 4? Or more? Can it track both GPS and other systems like glonass at the same time?

Re: GPS

#237
post #236
post #171

Amazing work. I work on the Android location team at Google, and I sent this article out to my team. GPS/GNSS is critical for accurate location/context, and there's still plenty of innovations happening in this field. One of our directors is Frank Van Diggelen - none other than the professor who taught the Stanford GPS MOOC referenced by the article :) I'm sure he is going to appreciate seeing the course called out t…

How many satelites are tracked by a typical android phone? 4? Or more? Can it track both GPS and other systems like glonass at the same time?

It depends on the GNSS chipset in the phone, but usually it'll be all the GNSS satellites visible in the sky, from all major constellations. The current Android platform supports GPS, SBAS, GLONASS, QZSS, BEIDOU, GALILEO, and IRNSS[0].

Each satellite adds another constraint, which helps, and with more satellites to choose from, you can drop the weakest or worst measurements.

[0] https://developer.android.com/reference/android/location/Gns...()

Re: GPS

#238
post #225
post #214

Earlier quoted context omitted.

Yup! This issue, which is commonly described as the "wrong-side-of-the-street" or "wrong-city-block" error, is one of the biggest ones, and is where a lot of the innovation I mentioned is happening today. This occurs because in "urban canyons", meaning streets with tall high-rises or sky scrapers, there is little or no line of sight to GNSS satellites (GNSS being the generic term for all satellite positioning systems…

Fun fact: when I was looking into patenting this concept in c. 2007, the prior art search revealed that it had already been patented by someone in Japan in c. 1997. Amazing to think that ideas people had back when Selective Availability was on for the foreseeable future are just now becoming available to consumers. Congrats on getting it done!

Cool! Were you involved in GPS/localization R&D back then?

Re: GPS

#239
post #187
post #163

Earlier quoted context omitted.

Again, that's not necessarily how that's intended. The observation on its own is just an observation, it doesn't indicate anything about how interview performance was evaluated. For example when I interview, I have a question related to chess, which requires a basic understanding of how the pieces move. I was amazed that even engineers don't understand the basic movement rules of chess. However as far as the intervie…

As an interviewer, where there's a huge power imbalance, why even stray into the territory where candidate can easily perceive a disadvantage for not having totally unrelated knowledge? A candidate will feel like their lack of chess knowledge, or GPS knowledge, hurt them if they didn't perform well. Why not just ask questions that are relevant to the work they will be doing? Maybe you don't realize just how stressful…

It's very clear in the interview that knowledge of chess isn't being tested. The chess-related exchange is literally about 30s and it's clearly part of the segment where the problem is explained, not the part where the candidate needs to demonstrate their abilities.

As for why, by relating the question to something in the real world (like chess or GPS) a few things are accomplished:

- It gives the candidate an ambiguous situation that they have to navigate away from (e.g. by asking clarifying questions).

- It requires the candidate to map a real-world situation to an algorithmic solution, rather than just being told "implement a graph traversal" or "use dynamic programming to solve this".

- It makes the problem more interesting.

I know exactly what it's like to be on the other side because I was there too not so long ago, solving interviews just like this. I found questions like this much nicer than more obscure questions like Gray code.

I think you're just fixated on this idea that the interview is there to test what you know and not knowing something is a fail but that's not really how it works. What a candidate knows is next to nothing to me, what's most important is how they go about solving the problem. Do they ask questions? Do they consider alternative solutions before digging in? Is their code somewhat readable?

Aside from the basics of CS, I really don't care what they know and that's made reasonably clear before the interview (as it was to me when I was interviewed).

Re: GPS

#240

> Naturally, large range uncertainty increases the ambiguity of position, but the relative position of the satellites also matters. If they aren’t well spread, the exactness of calculated location also suffers. (see the excellent example in OP) Fun tidbit, the resulting error is known for the system in closed form as Geometric Dilution of Precision, and is a 3x3 (edit: or 4+x4+ if you are estimating bias or quantitie…

Do you know a good source to learn about the FIM?

(Postgraduate level stats/maths, mostly applied, tiny bit pure.)

Post reply on HN