Losing IMU while driving

Software Control System
1

Our team has been using a recently received newer control to try and implement field-centric driving on the bot. We are only collecting the yaw angle. It appeared that there was an issue reading IMU data too slowly; however, after a lot of testing and debugging, we have definitively isolated the problem.

We loosing (communication, etc., don’t really know) the IMU all together after the bot has a mishap such as banging into the wall, getting caught by a signal pole, or running over a ground junction. Of course, these things happen in competition and when the students are driving in general. At first the data read will just be 0, and it remains 0, but I suspect no new data is coming from the IMU. On the first restart of the opmode, it will read NaN (java not-a-number). Maybe there is corrupted data still in the IMU registers. Another restart or two of the opmode will return it to normal function.

This is not much of an issue for auton, but it makes field-centric programming/driving impossible. Is anyone else seeing this behavior?

I would love to hear any insights, as I am at a dead-end being able to help the team fix this issue.

2

First, I’d love for you to answer the following questions:

(1) Which Control Hub do you have? Do you have a legacy one with a BNO055 IMU or a newer Control Hub with a BHI260AP IMU?
(2) If it’s a BNO055 IMU, which API are you using (Legacy or new IMU API)?
(3) Can you give us an example of how you’re reading the IMU? Or better yet, can you provide the actual source code of you reading the IMU yaw value?

Thanks!
-Danny

3

It’s the newer control hub with the BHI260AP IMU, so we are using the new universal IMU class.

Here is the initialization where we also take the initial heading:

imu = hardwareMap.get(IMU.class, “imu”);

    RevHubOrientationOnRobot.LogoFacingDirection logoDirection = RevHubOrientationOnRobot.LogoFacingDirection.UP;
    RevHubOrientationOnRobot.UsbFacingDirection  usbDirection  = RevHubOrientationOnRobot.UsbFacingDirection.FORWARD;
    RevHubOrientationOnRobot orientationOnRobot = new RevHubOrientationOnRobot(logoDirection, usbDirection);
    
    // Initialize IMU using Parameters
    imu.initialize(new IMU.Parameters(orientationOnRobot));
    imu.resetYaw();
    
    angularVelocity = imu.getRobotAngularVelocity(AngleUnit.RADIANS);
    orientation = imu.getRobotYawPitchRollAngles();
    setHeading = orientation.getYaw(AngleUnit.RADIANS);

We collect the bot headings for correction using the simple statements:

        orientation = imu.getRobotYawPitchRollAngles();
        botHeading = orientation.getYaw(AngleUnit.RADIANS);

When things go wrong, the botHeading just reads 0.0000 in our telemetry. We have a short method that collects the yaw upon a gamepad button press that we used for debugging. This does not yield any new reading when the problem happens.

4

I believe this hub/IMU is defective. I cannot remember it ever working since we received it a little more than a week ago. We just thought there were code bugs until recently. Now we know that the code is fine, as everything runs well until the IMU fails.

After careful testing tonight, we saw that it happens even without impact with careful driving. In fact, some of the bumps were caused by loss of heading. It still fails 100% of the time when bumped, but it also fails 100% of the time with normal non-contact driving. We set up a manual direct drive from the sticks to the wheel with a simple yaw read and report to telemetry in the opmode while loop, and it fails with an absolutely repeatable sequence. It reads 0 to 15 decimal places. When we stop the opmode and re-init, it reads NaN on the initial heading reading. If we stop the opmode and re-init a second time, it reads properly until the next failure.

Has anyone seen anything like this?

5

I ran IMU tests with my BHI260AP Control Hub (though I used the Blocks interface for quick testing) and gave it several firm “thunks” and quite a few “shakes” trying to replicate your issue - mine is from the same manufacturing batch as the ones teams received this last pass. I have seen no issues continuously reading from the device.

Your issue quite honestly seems less likely a bad device or a bad connection (especially since it “comes back” after a reboot) - it sounds/seems a lot more like an ESD issue. I highly recommend that you get your hands on some Staticide and treat your field components before use, especially if you are in an area where static electricity is prominent. Also:

Surely I don’t know if you’ve actually got an internal issue to your Control Hub, but I can at least be sure that there’s not a widespread problem with the IMUs. Because of the limited number of Control Hubs available, though, it would benefit you sooner to try treating your field/practice area with Staticide and follow the other best practices I’ve mentioned and in the ESD guide.

-Danny

6

I had already ordered staticide which should arrive this week, and we will do some more testing and some ESD mitigations. I recently began thinking it could be ESD, but it did not appear to be so at first because the rest of the bot runs just fine. Also, the problem is perfectly repeatable, which is not how random ESD usually behaves. Also, there have been no disconnects or other odd behaviors. Everything else runs fine. Finally, a second but different bot running field-centric driving with a legacy hub never has this issue. We will give these all these things a try. We are also probably going to pull the hub today or tomorrow and test it bare, which would rule out ESD.

Thanks for the help!

7

Also, the problem is perfectly repeatable

Can you provide me the java file you’re using to repeat it? If you prefer, you can email it to the FTC Technical Account ftctech@firstinspires.org instead.

-Danny

8

Did you find a final solution for this? We have 2 new control hubs and are having the exact issue you are describing with both control hubs. Originally it would happen within a few seconds. But, once we installed a grounding strap, it takes a little more to make it happen. But, it will still start reading 0 after a minor collision with the wall or truss.

9

The poster never provided code to reproduce the issue. If you have a simple program that reproduces this, please send it to our tech support email address (ftctech@firstinspires.org) along with reproduction steps and we will investigate further.

-Danny

10

I took the issue to Rev who then decided that it was a faulty IMU and replaced the control hub. They said that the readings in the log could only be caused by a faulty IMU.

11

Wow, thanks for the update!

-Danny

12

We’ve come to believe that it was static discharge that appears to affect the new gyro more than the old gyros. We saw significant improvement when we installed our grounding straps. Then after treating the field with staticide the day before our last meeting, we didn’t see any issues at that meeting. I’ll provide updates if we have any more issues. If we do, we will also make sure to capture some logs and open a case with Rev.

1 Like
13

My team is also seeing the same issue. We have tried 2 different control hubs, both delivered in 2023. We have added the group strap and also covered most of the exposed metal to prevent the ESD event. It would be great to hear if there was a resolution.
As a workaround the team is using IMUs from old expansion hubs.

14

We have not had issues since coating the field with Staticide several weeks ago.

15

Both our FTC teams are experiencing this on their robots.
They are driving field orientation and at some point, the IMU just starts reading zero no matter which way they turn so they end up in a robot orientated tank drive style movement.

While not 100% confirmed, it was said that it seemed to happen mostly when they were multitasking – driving and running the input program, or driving while turning with the other joy stick.

We are looking for potential solutions or code fix for this.
If there is any other information please let us know.

FYI, while staticide might be a solution for team field, it isn’t a given that a competition field will be treated with staticide.

16

While it’s true that FIRST cannot regulate all fields, the guidance to all tournament partners is to use Heavy Duty Staticide on fields in areas where there is a high risk of ESD buildup. I highly recommend reaching out to your tournament organizers in advance of your event and discuss with them the need to use Heavy Duty Staticide on their fields.

-Danny

17

We are experiencing the exact same thing: randomly the imu yaw returns only zero. Resetting the imu does not fix the issue. We have to restart the op, then the imu starts working again for a short random while.
We have two robots with newer rev robotics control hubs and mecanum wheels. The issue happens with both robots. We added grounding straps, and the problem still happens. We are ordering some staticide to see if that eliminates the issue. We are looking into ordering an external BNO055 card too. Very frustrating.

1 Like
18

Hello,

Our team was trying field centric drive using the IMU and we’re running into issues with the IMU returning zero after a while.

The behavior is that the IMU works for 5 to 20 seconds of driving the robot around with the code below, then yaw starts to return 0 until the IMU is initialized again. The error message in the logs is BHI260IMU: getRobotOrientationAsQuaternion(): Failed to retrieve valid quaternion from IMU. Returning the identity quaternion.

Minimum Block program to reproduce the issue and logs are here

The battery was charged all night and showed 14.1 V at rest and 13.9 V with the robot driving at max speed. No other motor or servo was powered during the test. The gyro crashes when driving at low speeds too so it doesn’t appear to be a brown out due to low battery. This happens without bumping into any field elements or walls, just driving around on foam tiles.

This is with a Control Hub from June 2023 so it has the BHI260IMU IMU. It’s upgraded to SDK 9.0.1.

This seems like the same issue other teams are reporting. Any hints on what we can try? Thanks.

19

We just had this happen to us yesterday in the middle of autonomous testing. The robot kept spinning out of control and we stopped it. Otherwise it would have hit/taken out other robots.

getRobotOrientationAsQuaternion(): Failed to retrieve valid quaternion from IMU. Returning the identity quaternion.```

Is there anyway this can we wrapped in a try catch or anything like that or are we dead at this point?

And yes this is a new hub that was just purchased over the summer. We never saw this with our hold CHUB from about 18 months ago.
1 Like
20

For what it’s worth, I plugged in an old expansion hub with the BNO055 IMU (circa 2019) into the 2023 control hub, configured the expansion hub I2C 0 as imu2, and it has been running the minimum field-centric drive Block program from above using the exapansion hub IMU rock solid. Drive fast down to 11.9V volts, bang into walls and field elements, and no issues with the BNO055 IMU tracking yaw. The BHI260IMU from the control hub failed by returning 0 yaw within 5 seconds every time while the BNO055 hasn’t failed a single 2 minute run.

Danny, I can provide any data that would help root-cause this issue. I have a scope, logic analyzer, and I’ve got all the Android development tools. Let me know.

2 Likes