W3C home > Mailing lists > Public > public-geolocation@w3.org > May 2011

Re: separating compass heading from orientation?

From: Dean Jackson <dino@apple.com>
Date: Tue, 17 May 2011 04:52:43 +1000
Cc: public-geolocation@w3.org
Message-id: <70A7F259-E3BF-44CF-8635-108A0FEA5866@apple.com>
To: Steve Block <steveblock@google.com>

On 17/05/2011, at 2:06 AM, Steve Block wrote:

> Hi Dean,
> 
> Thanks for your comments. I understand the problem you describe, but
> I'm not sure that moving the absolute heading to a different property
> is the right solution.
> 
>> However, I think that we should NOT require the alpha to be a compass heading,
> So how would you define alpha? I think you're suggesting that alpha
> should only be determined from a gyroscope, but the idea of the spec
> is to be independent of the underlying source of data. The UA should
> use whatever data sources it has to provide the best possible values
> to JavaScript.

Yeah, it definitely would be nicer if there was only one value. I think the problem is that we're combining two noisy data sources (one noisier than the other with current hardware), and different applications place more value on one source over the other. By giving them both as one (even if we use whatever tricks we can to smooth the values, or use the more accurate hardware to improve the less accurate one) we're making the application worse.


> 
>> All of a sudden, the compass decides that my heading has changed (a source of interference has been removed).
>> What should the system do? If it changes the DeviceOrientation
> events, the player might jump off a cliff even
>> though I didn't move. But it can't ignore the change in heading.
> If the UA has access to both a gyroscope and a compass, I'd expect it
> to filter the two sets of the data to take advantage of the increased
> accuracy of the gyroscope while using the compass data to counter
> drift in the gyroscope data. This should avoid the value of alpha
> jumping around due to compass noise. Have you tried this? If the UA
> has only a compass, I don't think there's any way to avoid the
> problem.

Yes, I've tried it - it's still very problematic.

Suppose at the time you start playing a game your compass heading is 0 degrees (but with an accuracy of 40 degrees). You're using the device orientation alpha to control the player. Then 10 seconds into the game your compass accuracy drops to 5 degrees but your compass heading changes to 30 degrees. All of a sudden device orientation alpha has moved 30 degrees even though the player hasn't moved.

With filtering I have a choice as to what I should do. I know that the device hasn't really moved, so should I keep its alpha constant? But then I'm ignoring the increased accuracy in the compass heading? How can I know which value the user is using at the time? It might be a location-oriented application where the compass heading is more important than device movements.

The only time that the filter is definitely useful is when the user doesn't really care about compass heading. At that time your gyroscope will tell you that the device hasn't moved, so you can ignore (or smooth) any large changes in compass heading. But that's an even better argument to separate the properties - the only time you can filter is when you don't really care about alpha being a compass heading.

I guess my point is that I can use tricks to provide a smooth output, but I can't know if that's what the application wants.

The way things stand now, I think that if iOS adds compass data into DeviceOrientation it would have to be with a custom/proprietary property, otherwise some existing applications will get much worse. That's what I'm really concerned about. If we do combine them as the spec demands, I'd probably have to expose the raw data anyway - but then we're doubling the size of the event data we are spewing, putting pressure on the GC, etc).

Dean
Received on Monday, 16 May 2011 18:53:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:02 UTC