Loosing 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