-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
yaw calculation is faulty #409
Comments
my current code:
|
PS: |
Likely duplicate of #375 |
and which is the solution to this issue? |
Other than the calculation change mentioned in #375, the behavior that you describe is inherent in the IMU's output. It does not keep track of the last known yaw/heading value between resets, and since it's a 6-axis device, it has no reference point for north internally available. Further, the v2.0 DMP microcode (and possibly other versions) always perform an initial accel/gyro calibration on start-up, and during this time the heading typically drifts--sometimes considerably--until the gyros zero themselves. Concerning the range of [-180, +180] instead of [0, 360], this is arbitrary and easily adjusted at an application level. Again, since there's no true north reference point, any given heading being "0" is relative only to another heading of your choice. |
just to clarify: But unfortunately yaw is calculated unstable after that, either which initial value has been taken, As stated: e.g. when initially -120° is shown, after 180° counter-clockwise and then 180° clockwise to the initial position, t does not show -120° like at start but -32.4 which is complete nonsense. |
update 1: it take extremely long until yaw setlles to a stabile value, but after perhaps 1 min it's stable then: Initializing I2C devices... ! +/- stabile now ! |
Update 2: after stabilization, and after ROUGHLY turning 180° back and forth, it now shows ROUGHLY a similar value like before turning ( -144° vs. -149°): ypr -149.89 -3.42 -0.48 I'll keep on checking and will report! |
Update 3:
Can this yaw start value (after having setlled) be arbitrarily set to 0° at either time in the program or is that value produced by the IMU chip autonomously? |
In my (ancient) experience with the v2.0 DMP microcode, the calibration process usually takes about 8 seconds as long as the IMU is sitting still, e.g. flat on a table. It will always take longer if it is in motion. There's no way I know of to reset the DMP-provided yaw value back to 0, although this capability may exist internally. The simplest way is to have the application code monitor the reported yaw for changes during what you know or expect to be the calibration phase, and then once the drift stops, calculate an "offset" heading value and just subtract it from every yaw value the sensor provides. Or, even more simply, provide a "reset heading" mechanism via button press or serial input value so that you can just zero it on demand whenever you want to. |
yes, thank you for your advices. I'll try to fix the -179.9/+179.9 shifting by a |
Actually, it is just |
yaw calculation is faulty.
correctly it would be expected:
always start at 0°/360° at programm start (initialized arbitrarily).
Then for turning:
360/0...90°...180°...270°...360/0° for 1 complete turn clockwise , at 360° switch to 0°,
0/360...270...180...90...0/360 for counter-clockwise
So always positive values are expected to be retrieved -
that is identical to what a compass would show if alligned to Magnetic North at start of program.
Instead, your program behaves as follows:
Yaw starts randomly, e.g. at -120 instead of 0/360°
and after turning 180° counter-clockwise it ends randomly e.g., (150°... -160°) instead of exactly 180 degrees less than start value (i.e. when starting at -120° then it should show 60°, but it doesn't).
It does not detect 180° turns correctly. Around 180° it jerks to -180° and back.
ypr 179.90 -2.81 10.37
ypr 179.96 -2.76 10.37
ypr -179.98 -2.71 10.37
ypr -179.94 -2.68 10.38
ypr -179.90 -2.66 10.38
and then after 180° turned back clockwise it ends at -32
instead of the same like at start (i.e., -120 in that case)
ypr -32.43 -2.21 17.85
ypr -32.46 -2.20 17.74
ypr -32.50 -2.22 17.64
ypr -63.09 41.71 -53.83
FIFO overflow!
ypr -32.89 -2.17 13.40
so the calculation of turning several degrees is faulty!
The text was updated successfully, but these errors were encountered: