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

Re: separating compass heading from orientation?

From: Dean Jackson <dino@apple.com>
Date: Fri, 08 Jul 2011 00:41:19 +1000
Cc: public-geolocation@w3.org
Message-id: <24B4265F-5D5C-4A66-AF02-3C09B689A71C@apple.com>
To: Steve Block <steveblock@google.com>
Hi Steve,

Apple unfortunately didn't have time to wait for a resolution here, so for iOS 5.0 we exposed two new (custom) properties for the DeviceOrientation event:

webkitCompassHeading - which is the alpha as described in the spec right now
webkitCompassAccuracy - in degrees

The alpha, beta and gamma properties have not changed since iOS 4.0 so they are still not world accurate. Rather they are based on a (possibly arbitrary) reference orientation. We (Apple) may look again at combining the compass into the alpha value, but not in the immediate future. Our main problem now is not breaking existing content. The good news is that we have the property to set indicating real world orientation, and our compass properties are prefixed.

Thanks for the feedback though! :)

Dean

On 08/07/2011, at 12:23 AM, Steve Block wrote:

>> different applications place more value on one source over the other.
> This is true, but I'm still not convinced that we can't reach a
> reasonable solution by leaving it to the UA to combine the signals.
> 
>> 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.
> The gyroscope has a good high-frequency response, but is subject to
> drift due to integration errors. The compass is noisy, but has a good
> low-frequency response. So I'd expect a filter to combine the
> low-frequency component of the compass signal and the high-frequency
> component of the gyroscope signal. In the example you describe, if the
> compass signal suddenly jumped 30 degrees, I'd expect the combined
> signal to slowly swing towards the new compass value. What kind of
> filter algorithm did you try, and with what parameters?
> 
>> 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.
> I don't think that's true. The gyroscope signal will drift, so in
> order to report a constant value when the device is stationary, you
> need to make use of use the compass signal to compensate for this
> drift. I think you'd need this even in the gaming application you
> describe.
> 
> 
> Steve
> 
> -- 
> Google UK Limited
> Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
> Registered in England Number: 3977902
Received on Thursday, 7 July 2011 14:42:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:56 GMT