Delay in yaw, pitch, and roller values
I am developing an application on Windows Phone 7.1 that needs the current degree of rotation of the phone along the x and y axis. I've tried using the motion API and using the appropriate values from the yaw and roll step it provides. But the values it provides linger in the sense that if I move my phone too quickly and rotate it 90 degrees, the corresponding value takes a little time to reach there, which damages my target.
I have done the same in Android where I can use something similar to calculate the immediate rotation of the phone.
This thing can be done using a gyroscope on wp7, but I want to use an accelerometer so that I can serve more devices.
Any help reaching the goal would be appreciated
source to share
I have similar issues with WP8 Motion API. Latency is not the only problem. It looks like the Motion API is also very sensitive to compass (or magnetometer) errors of all kinds. Even worse, they don't only affect yaw. The motion class AHRS algorithm seems to combine feed and roll with yaw. As a result, when the compass lingers or goes on other paths crazy, so take a step and throw.
I doubt you can do without a gyroscope. In theory, you can get the Euler angles (yaw, pitch and roll) only from the accelerometer, but ONLY if the phone is stationary. The slightest movement causes linear / centripetal accelerations that will ruin your attitude calculations. I would say that any attempt to do this with a hand held device like a telephone is doomed to fail. In addition, the Motion API itself requires both a compass and a gyroscope in addition to an accelerometer.
In any case, all is not lost. I got rid of the Motion class entirely and implemented "my own" IMU a la Sebastian Madgwick IMU algorithm. IMU / AHRS report with C-code here:
http://www.x-io.co.uk/res/doc/madgwick_internal_report.pdf
The C source code can be found here:
http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/
With the right beta win, the Madgwick IMU works like a charm on Windows Phone. The IMU does not provide yaw, just step and throw. And it only uses gyroscope and accelerometer hardware. If you need a dash too, you can implement the full AHRS algorithm included in both of the above sources. This, of course, needs a compass too.
Madgwick's algorithms do not include Euler angle calculations (only a quaternion describing rotation between Earth and touch frames), but you will find equations from Madgwick's report.
I have no experience with full AHRS (or MARG, as Magwick calls it). However, the algorithm separates the yaw compass from the bumps and rolls, so it can be expected to have normal stride / roll readings even there magnetic disturbances.
Please note that the coordinate systems are different. In WP, X = pitch axis, Y = roll axis and Z = yaw axis. In the above algorithms, Y = pitch, X = shaft, and Z = yaw. So you need to swap X and Y and also invert the direction of Z acceleration. You also need to change the gyro speed (and change the X and Y speeds).
Hope it helps :)
source to share