Alternatives to an Expansion Hub with the old IMU could be an off-the-shel IMU board. I haven’t tested this but it’s possible that the Adafruit BNO055 board could be connected to I2C port 1 on the Control Hub, added to the robot configuration as a BNO055 IMU and used in Blocks/Java using the built-in driver.
I’ll give that a try and report back.
Yep, we have one on the way as well. I don’t see an ESD suppressor on the AdaFruit schematic though. If the ESD issue is with the Control Hub I2C bus itself (is it the new Control Hub design that is resetting the bus?) then adding an external cable without ESD suppression seems like it might not make the issue better.
If it’s really the new IMU version that has ESD issues, then substituting the external BNO055 device would make sense. I’m not sure from the REV blog if the issue is the IMU itself, or the Control Hub I2C bus/interface.
We’ll give it a try and also report back. ESD is so hard to debug… I need a static gun, and a pile of sacrificial Control Hubs. 
From what we know at this point, this would not likely help the IMU issue; it appears to reproduce when EMI from an ESD event interferes with an internal circuit. Nothing plugged into the I2C port would have any effect.
We’ll keep the community informed as we get more information from REV.
-Danny
Similar issue happens here, drives us crazy. Any workaround now? Will external IMU solve the issue? or where can we get an old version expansion hub?
REV has not yet provided any solutions. I understand that they are testing multiple possible solutions, but they do not have anything that has yet shown enough merit for external testing by users.
An external IMU will avoid using the internal Control Hub IMU, but the biggest question is whether or not external IMUs will be affected by ESD similar to the internal IMU. None of the external IMUs that I am aware of have specific ESD protection circuitry - it’s important to understand that there’s two levels of “protection”, the first level is “ESD will not physically harm the device” which the IMU on the Control Hub has, and the second level is “ESD will not cause the device to behave incorrectly” which very few devices actually have. Most external IMUs that I am aware of have neither specifically in their circuitry, though in their design they have features that help them be more resistant.
With that said, I have never heard reports of the Adafruit IMU featuring the BNO055 (like this one) having ESD problems. It also has software support already built in to the FTC SDK.
You can only purchase one if someone is willing to sell it to you. I wouldn’t hold my breath.
-Danny
No guarantees that an external IMU will fix the issue for your particular robot, but if you’d like to try, here are some detailed steps.
We mounted an external one and it has the same problem. We monitored all three IMUs and the only one that didn’t fail was the one in the old expansion hub. My test consisted of just pushing the bot around by hand on the field and then after a bit, pushing it into the structure. All the angles came back as 0.
Is there a way to poll the IMU directly to find out if it is in a bad state? If it is then we can switch to the expansion hub one or something like that.
In the mean time, what is being done to resolve this issue? Should we reach out to REV directly?
938
01-04 15:50:24.958
Warning
BNO055IMU
(new): getRobotOrientationAsQuaternion(): Failed to retrieve valid quaternion from IMU. Returning the identity quaternion.
939
01-04 15:50:24.972
Warning
BHI260IMU
getRobotOrientationAsQuaternion(): Failed to retrieve valid quaternion from IMU. Returning the identity quaternion.
We’ve had our IMU fail only once (that I’m aware of or observed), but when it failed I seem to recall that orientation.getAcquisitionTime() was returning zero values instead of valid timestamps. That might be a useful way to determine that an IMU has entered a bad state.
Fortunately our IMUs don’t seem to fail often, so I haven’t had adequate time to repeat this test (and tbh, I don’t want to try to force our IMUs to fail). But if others could confirm that acquisition time is a useful surrogate for this, that would be really helpful.
Code snippet:
YawPitchRollAngles orientation = imu.getRobotYawPitchRollAngles();
long imuTime = orientation.getAcquisitionTime();
if (imuTime == 0) {
// imu has perhaps failed...?
}
Pm
Well that’s disappointing. Can I ask which I2C bus you added the AdaFruit sensor to?
Quick update from our experimentation. We ran the evening with the garage door open. 55F @ 60% humidity.
Grounding strap on.
Ferrite chokes on the USB cables.
Electronics are isolated on a wooden board.
External IMU is added to Control Hub I2C port 3.
We experienced an ESD event on the Control Hub 10/10 runs (then stopped counting).
We sample the IMUs on the Control Hub, Expansion Hub (old), and external IMU through our entire auto.
The Control Hub IMU returned garbage about 500ms into the auto. Both the Expansion Hub and External IMU reported valid data (even when the CH IMU failed.) This was repeatable 5/5 attempts (until we stopped trying.)
We can confirm that the Orientation class Acquisition Time does start to read ‘0’ with or very near the ESD event.
This is incredibly useful information, our thanks to your team for conducting the experiments and reporting on them.
We’ve ordered an Adafruit external IMU. Our internal CH IMU has seemed to work so far, but we at least want to have something ready as a backup, if not switch to the external sensor outright. (Competition day is not when we want to discover it starts failing.)
Again, thank you for sharing this.
Pm
We implemented a class that has two IMUs in it: a primary that could be the one in the control hub and a secondary from the expansion hub. It essentially uses orientation.getAcquistionTime() returning 0 (thanks pmichaud) to determine if the primary one has failed. If it determines that such a thing happened, it remembers it and then on returns the orientation etc from the secondary imu.
Don’t know how useful this might be or if it does solve the problem or not but haven’t had any issues after this implementation. There have been cases where the primary IMU does seem to have failed but the robot run was not affected, at least not noticeably.
Here’s a link to our Class. SilverTitansIMU.java - Google Drive
Here’s how we use it in our MecanumDrive Class:
/**
* Create the primary IMU, initialize it and set the Expansion Hub IMU as its secondary IMU
*/
IMU controlHubIMU = hardwareMap.get(IMU.class, "imu");
IMU.Parameters controlHubParameters = new IMU.Parameters(new RevHubOrientationOnRobot(
RevHubOrientationOnRobot.LogoFacingDirection.LEFT, RevHubOrientationOnRobot.UsbFacingDirection.UP
));
controlHubIMU.initialize(controlHubParameters);
/**
* Create a secondary IMU, the one from the expansion hub. Initialize it.
*/
IMU expansionHubIMU = hardwareMap.get(IMU.class, "imu2");
IMU.Parameters expansionHubParameters = new IMU.Parameters(new RevHubOrientationOnRobot(
RevHubOrientationOnRobot.LogoFacingDirection.RIGHT, RevHubOrientationOnRobot.UsbFacingDirection.UP
));
expansionHubIMU.initialize(expansionHubParameters);
silverTitansIMU = new SilverTitansIMU(controlHubIMU, expansionHubIMU);
/**
* Reset the yaw on the IMU
*/
resetYaw();
Coach, FTC #4327 “Silver Titans”
Sorry for the delay. Had a tournament to prep for.
We have it plugged into the i2c bus 2 on the CHUB. What we haven’t tried is to plug it into the Expansion Hub.
We have done a similar thing where we use our externalIMU until it goes bad and then switch to the expansion hub. Both the external and expansion are the old BNO IMUs.
Any news on this? Our control hub began showing exactly this behavior in the past few weeks. after working perfectly for months.
There’s definitely an environmental factor to all of this. Our Control Hub IMU fails rarely when in our normal practice space (a room in my house), but when we go to another team’s practice facility the Control Hub IMU fails 7 of 10 times or more. When we’re back to our normal space it works more reliably again.
To me, a Control Hub IMU that works for months and then starts failing may simply be reacting to the environment, such as changes in the weather and HVAC operation. Since September I’ve watched the humidity in my house go from averaging 50%-60% to being regularly 35% or lower (we keep a temp/humidity sensor in our practice space for precisely this reason).
Similarly, some of the events in our area are noticing increased ESD issues as we get into colder weather – venues that were “just fine” back in October and November are now seeing increased disconnects as things have gotten colder and heating systems are running more constantly.
We’ve switched to an external IMU for the time being, and so far it seems to run well in both environments that we regularly practice, as well as at our League Meet last Saturday. I think that’s really the best bet for now, as well as getting event hosts to treat fields for static.
could well be. Our practice field is in a school that was closed from mid December until mid January when temps were below zero for a week or so. so we had very low humidity in that room
all the ESD best practices are already implemented so I am going to use the IMU in our expansion as an alternate and check for a zero time from the primary control hub imu.
tnx
Russ
are you related to Phillippe Michaud by any chance? Army officer stationed in Germany in 1979
Our team is experiencing EXACTLY the same issue (same repro steps, same symptoms) as you describe here, with both our robots (both are Rev Control Hub that we bought in 2023).
We observed the exact same thing on the two Control Hubs we have! Maybe the weather got colder and dryer and it caused these ESD events to happen a lot more often. We never got issues like this one during the summer.