Discontinuities in IMU heading

[IronReignRobotics]

First thanks for sharing your whole codebase and approach to extending ftc_app. We tried it out a few weeks ago, but since the imu code was broken we set it aside for a while. Now we are trying your recent updates and getting actual heading values. But we are seeing discontinuities in the Euler angle outputs. I'm not talking about gimbal lock.

For example, if the heading is nearing 320 degrees (normalization turned off) as we are rotating counter clockwise, the instant we go below 320 degrees we start getting small negative angles for the next 8 degrees of rotation. So at 316 degrees of rotation it will actually be reporting -4 degrees and at 313 degrees, -7. It returns to the absolute range when we cross over to 312 degrees.

There are multiple such discontinuities, in fact the pattern seems to be that for every multiple n of 16 degrees, the highest 8 degrees in the range are reported as x = n*16 - actual heading, while you get the actual heading in the lower half of the range.

Have you seen this? Or is this more likely evidence of a faulty sensor?

Also looking forward to your next version integrating the national teams latest changes. I see you've made headway on the merge in your mentors branch.

Thanks.

[rgatkinson]

Thanks for trying out our code.

We have seen something similar, yes; I don’t think it’s a faulty sensor. It sounds like you might have characterized the symptoms of what appears to be a bug on our part better than we have. You mention a characterization of the symptoms below, thanks for that; might you also have handy any of the raw data you could share? It might help us get to the bottom of things more quickly if that’s convenient to send our way.

We should have the integration with the latest release from FTC HQ completed tomorrow or Sunday by the latest.

            Thanks again,
            Bob Atkinson
            Mentor, Swerve Robotics

From: IronReignRobotics [mailto:notifications@github.com] Sent: Friday, September 25, 2015 4:27 PM To: SwerveRobotics/ftc_app ftc_app@noreply.github.com Subject: [ftc_app] Discontinuities in IMU heading (#19)

First thanks for sharing your whole codebase and approach to extending ftc_app. We tried it out a few weeks ago, but since the imu code was broken we set it aside for a while. Now we are trying your recent updates and getting actual heading values. But we are seeing discontinuities in the Euler angle outputs. I'm not talking about gimbal lock.

For example, if the heading is nearing 320 degrees (normalization turned off) as we are rotating counter clockwise, the instant we go below 320 degrees we start getting small negative angles for the next 8 degrees of rotation. So at 316 degrees of rotation it will actually be reporting -4 degrees and at 313 degrees, -7. It returns to the absolute range when we cross over to 312 degrees.

There are multiple such discontinuities, in fact the pattern seems to be that for every multiple n of 16 degrees, the highest 8 degrees in the range are reported as x = n*16 - actual heading, while you get the actual heading in the lower half of the range.

Have you seen this? Or is this more likely evidence of a faulty sensor?

Also looking forward to your next version integrating the national teams latest changes. I see you've made headway on the merge in your mentors branch.

Thanks.

— Reply to this email directly or view it on GitHubhttps://github.com/SwerveRobotics/ftc_app/issues/19.

[rgatkinson]

This now seems to be fixed. The core issue was problems with the math that assembled two bytes into an int (unaccounted-for sign extension was occurring).

Fix is in fe163d120ec0537eb9ce67e871362dd83002f86c.

[rgatkinson]

Thanks for the bug report!

[IronReignRobotics]

Thanks Bob, looks rock solid now. Really enjoying all the other goodies and refactoring you've put into this project. And we are also using your BotBug tool. So much easier when switching around between multiple computers and phones!