Re: separating compass heading from orientation?

> 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:23:50 UTC