4 ms·

I'm skeptical of this approach because it seems to me that they have not defined-well the expectation of what the GPS radio hides from them. A lot of informatio

I'm skeptical of this approach because it seems to me that they have not defined-well the expectation of what the GPS radio hides from them. A lot of information can get lost depending on what simplifications are taken in firmware. What I mean by this is that I would be surprised if GPS radios prioritized accurate signal reports per transponder (and/or refresh-rate of reporting that signal) over battery life when a sufficient level of accuracy is reached, which means Uber could be working with bad data. If it was a professional GNSS receiver, that's one thing, but for a GNSS chip in a cell phone, power consumption really matters the most. Doing something latency-sensitive in software better than the firmware, over a cellular network, seems like a very lofty goal.

ocdtrekkie 9y ago
I would guess people internally were skeptical about it too, but as they demonstrated, they have an app that lets their employees see the difference due to this change: Presumably they wouldn't have deployed it (at likely significant resource costs for processing) if it didn't average vastly better.
- nickysielicki 9y ago
  Upon rereading, it seems to me that they're mostly looking to do this type of increased accuracy when an Uber is parked somewhere waiting for their rider, and you want to be able to show the rider exactly where he is parked, rather than something that is meant to be used while in motion or anything like that. When you limit the scope like that, I think most of my concerns go away. Very cool work here.
  - woolvalley 9y ago
    Also applies in figuring out the spot to pick up the rider, most people don't move much when requesting a car.
  - adrianmonk 9y ago
    Your concerns about bad data from dodgy hardware seem real, but it seems like their system is meant to be used while in motion. From the article: "We therefore use past measurements and constrain the location evolution over time using a motion model adapted to the application (e.g., pedestrian vs. vehicular motion)." … "Over time, the probability weights and particle locations evolve based on the measurements and the motion model." Presumably this means something along the lines of throwing out hypothesized locations based on impossible movements. If they were very sure that a car was at a particular location 5 seconds ago and now it is at another location 100 meters away, then that's believable because cars can travel at that speed (~40 mph or ~65 km/h). But if dealing with a pedestrian, it indicates low probability of the latest measurement being correct. I'm just guessing on the specifics of what the motion model does. But it seems like they're trying to use history in more cases than just when someone is sitting still.
Ajedi32 9y ago
This isn't just some theoretical approach to solving the problem that's never been tried in the real world. The article suggests this is something they already built, tested, and deployed at scale. What's left to be skeptical of?
- jsjohnst 9y ago
  > The article suggests this is something they already built, tested, and deployed at scale. Because nothing has ever been built by a company that had marginal, if any, improvements over what was there before? Not saying that’s the case here, but I’m skeptical of your argument why OP shouldn’t be skeptical, to put it nicely.
jhayward 9y ago
SNR in a processing gain system (i.e., the GPS signal) is somewhat of a manufactured value and may be taken or defined in different ways, but it is known each time you take an observation for each satellite. In fact you may have more than one signal for a given satellite due to multipath. SNR is one way to decide which of those signals to report.
jrockway 9y ago
I don't really see the problem. The position fix is done in firmware as per normal, and then the server-side just looks at the SNR for each PRN and decides whether or not to adjust that position. The SRNs will probably not match across two different GPS chips, but multipath vs. shadow vs. clear sky should have enough relative difference for the server to tell the cases apart.

ocdtrekkie 9y ago

I would guess people internally were skeptical about it too, but as they demonstrated, they have an app that lets their employees see the difference due to this change: Presumably they wouldn't have deployed it (at likely significant resource costs for processing) if it didn't average vastly better.

nickysielicki 9y ago
Upon rereading, it seems to me that they're mostly looking to do this type of increased accuracy when an Uber is parked somewhere waiting for their rider, and you want to be able to show the rider exactly where he is parked, rather than something that is meant to be used while in motion or anything like that. When you limit the scope like that, I think most of my concerns go away. Very cool work here.
- woolvalley 9y ago
  Also applies in figuring out the spot to pick up the rider, most people don't move much when requesting a car.
- adrianmonk 9y ago
  Your concerns about bad data from dodgy hardware seem real, but it seems like their system is meant to be used while in motion. From the article: "We therefore use past measurements and constrain the location evolution over time using a motion model adapted to the application (e.g., pedestrian vs. vehicular motion)." … "Over time, the probability weights and particle locations evolve based on the measurements and the motion model." Presumably this means something along the lines of throwing out hypothesized locations based on impossible movements. If they were very sure that a car was at a particular location 5 seconds ago and now it is at another location 100 meters away, then that's believable because cars can travel at that speed (~40 mph or ~65 km/h). But if dealing with a pedestrian, it indicates low probability of the latest measurement being correct. I'm just guessing on the specifics of what the motion model does. But it seems like they're trying to use history in more cases than just when someone is sitting still.

Ajedi32 9y ago

This isn't just some theoretical approach to solving the problem that's never been tried in the real world. The article suggests this is something they already built, tested, and deployed at scale. What's left to be skeptical of?

jsjohnst 9y ago
> The article suggests this is something they already built, tested, and deployed at scale. Because nothing has ever been built by a company that had marginal, if any, improvements over what was there before? Not saying that’s the case here, but I’m skeptical of your argument why OP shouldn’t be skeptical, to put it nicely.

jhayward 9y ago

SNR in a processing gain system (i.e., the GPS signal) is somewhat of a manufactured value and may be taken or defined in different ways, but it is known each time you take an observation for each satellite. In fact you may have more than one signal for a given satellite due to multipath. SNR is one way to decide which of those signals to report.

jrockway 9y ago

I don't really see the problem. The position fix is done in firmware as per normal, and then the server-side just looks at the SNR for each PRN and decides whether or not to adjust that position. The SRNs will probably not match across two different GPS chips, but multipath vs. shadow vs. clear sky should have enough relative difference for the server to tell the cases apart.