GPS issue: Updates the speed field only

Bug #1570878 reported by costales on 2016-04-15
72
This bug affects 20 people
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Scott Sweeny
location-service (Ubuntu)
High
Unassigned

Bug Description

Only the speed data is updated in each new GPS position. Any other data, will be updated each 11 seconds.

Testing:
Nexus 4.
OS: Ubuntu 15.04 (r418).
WIFI Disabled.
3G Enabled.
Open Sensor Status and drive (for see how the speed changes).
Bug: There are new GPS positions each ~800ms, but they will update only the Speed field. Any other field (like altitude, latitude...) will be updated each 11 seconds.
I tested same behavior with OpenStreetMap and uNav apps.

Related branches

Uranicus (matthias.ritter) wrote :

Very similar behaviour on:

current build number: 313
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en
last update: 2016-04-14 06:07:41
version version: 313
version ubuntu: 20160414
version device: 20160329-a9bacdb
version custom: 20160324--36-54-vivid

I can not support exactly 11 seconds update frequency but at least several seconds. Speed update is very regular. I have tested this with uNav, Activity Tracker and OSM Scout.

Thomas Voß (thomas-voss) wrote :

The behavior changed with http://bazaar.launchpad.net/~phablet-team/location-service/trunk/revision/229 on purpose, addressing the common request for filtered/fusioned location updates, ensuring that only more accurate updates are delivered to the client. We do not have an estimate on the accuracy of velocity, so we hand out the specific data regardless.

Thomas Voß (thomas-voss) wrote :

I will start investigating whether we should tune the fusioning engine such that a newer update with lower accuracy could still be accepted if it is contained within the accuracy circle of the previous update. I will update this bug report going forward.

Changed in canonical-devices-system-image:
assignee: nobody → Thomas Voß (thomas-voss)
status: New → In Progress
Thomas Voß (thomas-voss) wrote :

Having done the math under the assumption of 100 km/h, the position moves ~27 m/s. Common accuracy for a position estimate provided by the GPS is ~5 m. With that, we would still reject updates. We will investigate an alternative approach accepting decreases in accuracy by a certain percentage (likely something around 25%, to account for fluctuations in estimates originating from satellite-based positioning providers).

What is happening if you're using a GPS app walking? You'll not have those
27m/s.

Thomas Voß (thomas-voss) wrote :

It would obviously work in that case, and even the current filtering would likely work for a lot of situations. We are searching for a robust addition that works for all velocities , though.

Thomas Voß (thomas-voss) wrote :

Thanks to Scott, we now have some actual data available for a highway scenario (see attached plots). Left plot shows a histogram over the quality ratio accuracy(new)/accuracy(old), with an expected peak around 0 (logarithmic scale). Right plot shows a boxplot of the values, with most of them in [0.9, 1.2]. With that, the threshold approach present before would likely work.

However, after some internal discussions we realized that we should actually assume that updates from the same source are consistent. That is, we will only filter updates that originate from different sources instead of trying to come up with a meaningful threshold that behaves robustly across a lot of different scenarios.

Thomas Voß (thomas-voss) wrote :
Uranicus (matthias.ritter) wrote :

Before this task gets forgotten, I just would like to raise my voice here again. My user feeling on this is, that Navigation with the current settings (only updates after some significant seconds) is not what I expect.

I would appreciate that this gets fixed in a sense that the GPS signals get flowing again.

Please do not forget this topic. I would assume that this gets into the stable channel with OTA11? This would cause some irritation for many users.

costales (costales) wrote :

I am agree. I can't even test uNav in RC proposed :( This will not arrive to OTA right??

Changed in unav:
importance: Undecided → Critical
status: New → Confirmed
Scott Sweeny (ssweeny) on 2016-05-23
Changed in canonical-devices-system-image:
assignee: Thomas Voß (thomas-voss) → Scott Sweeny (ssweeny)
JkB (joergberroth) wrote :

Hi,

the behavior still persists in OTA11.

Just right after OTA10 one started to play around with the location-service in rc-proposed, leading to following behavior:
While speed still was updated every second, position started to be updated most likely only every 9 seconds.
As i am working on a navigation app, I stopped using rc-proposed channel (it is not intended for every day use and it seemed not to go hand in hand with (navigation-)app development.

Ok, one wanted to use the 6 week slot to play with location-service.
But, to be honest, I am a bit disappointed about the situation, that this bug is now found in ota11 still.
This is critical to any navigation app.

In my opinion, flowing position updates are more important than in small range accuracy.

Let us know if something starts moving in rc-proposed. I am back on ota10.1 now.

Thanks, best Joerg

costales (costales) on 2016-06-05
no longer affects: unav
costales (costales) wrote :

Hi, it is a weird behavior. A new coordinate is returned each ~11 seconds, but they are returned the same coordinate 3 times at the same time. You can check it with Activity Trracker.
Best regards.

Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Changed in location-service (Ubuntu):
importance: Undecided → High
Changed in canonical-devices-system-image:
importance: Undecided → High
milestone: none → 12
Thomas Voß (thomas-voss) wrote :

For bug subscribers: The fix is staged here https://requests.ci-train.ubuntu.com/#/ticket/1534 and about to hit rc-proposed.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package location-service - 3.0.0+16.10.20160616-0ubuntu1

---------------
location-service (3.0.0+16.10.20160616-0ubuntu1) yakkety; urgency=medium

  [ Scott Sweeny ]
  * Fusion provider: Always use an update that came from the same source
    as the previous used update (fixes LP: #1570878) (LP: #1570878)

 -- Thomas Voß <email address hidden> Thu, 16 Jun 2016 06:03:16 +0000

Changed in location-service (Ubuntu):
status: New → Fix Released
Uranicus (matthias.ritter) wrote :

Well done! Thanks.

JkB (joergberroth) wrote :

Thanks a lot! It's working again.

Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments