Got Sensor Fusion?

[Richard100]

Aaron -
Regarding your #15 / discontinuity in Yaw orientation at 0/360. These values are the native output of the sensor design, but will make feedback control difficult. I developed a code change that converts from the 'wrap' behavior of modulus math, to a 'wind' behavior of linear math. It detects and removes the discontinuity on the fly. It will likely work reliably at over 1000 deg/sec rotation rates (that's probably faster than most FRC bots, I think).

I've integrated it into the IMUOrientRead code so you can simply use either output, wrap or wind. I'll try to post it soon to make it easier for everyone, need to finish up some other improvements.

[Richard100]

Releasing an update to BNO055 IMU AHRS.

• Updated web link to latest BNO055 datasheet, document revision 1.3

• Modified IMUOrientOpen to detect when IMU is not connected and terminate with a “Fatal Result” flag. This allows code to fail gracefully should IMU fault or an IMU wiring failure occur. This prevents the FIRST LabVIEW Begin vi from hanging due to these events, which would otherwise cause the robot to not start Tele-Op.

• Updated IMUOrientDemo to show how to use the Fatal Result flag to fall back to an Analog Gyro should IMU fault, implementing a graceful failure design.

• Modified IMUOrientRead to include Wrap2Wind vi for converting IMU Yaw output from the 'wrap' behavior of modulus math, to a 'wind' behavior of linear math, allowing the Yaw indication to count above 360 degrees and below 0 degrees. The Wrap2Wind algorithm detects and removes the Yaw orientation discontinuity (at 0/360) on the fly. It will likely work reliably at over 1000 deg/sec rotation rates, when IMUOrientRead is iterated at 20ms. Both the wrap and wind outputs are now available for Yaw.

• Included detailed Read Me file.

[uutzinger]

The results with the IMU attached to CIM motor is very impressive.

Since all IMUs discussed in this thread are MEMS devices they all have same basic limitations such as drift and need for calibration.

Using a fusion algorithm that includes a compass will make the IMU stable over very long periods of time because the orientation is defined by gravity and earth's magnetic field and those two vectors are not going to change if one does not move the IMU.

Unfortunately in most buildings there are magnetic anomalies that change over the course of a basketball field. Also any motor that is about a foot from the sensor will affect the compass.

Most gyroscopes that are based on MEMS devices can not measure the earth's rotation because their noise is to high and their drift is too large.

To overcome these limits, run time calibration for the gyroscope bias and magnetic field anomaly detection is needed for the compass which is the key ingredient of the software.

Based on your report, the firmware in the BNO055 must be of very good quality.

[EthanJF123]

What size of flash drive should you use?

[Richard100]

We use an 8 Gb flash that is formatted FAT32. You can use smaller capacity drives, just watch remaining space and move files off if necessary. Since we use the same drive for data logging, 8 Gb is large enough to hold us for an entire season, I think, without being concerned with space.

We are currently evaluating the flash drive for shock/vibration failures, which may be the cause of some logging issues.

[sraque]

I'm looking for any reports of how this device has worked in competition. Does it work as expected? Is it reliable? Any problems?

[EthanJF123]

Is there any way that you can store the files directly onto the roboRIO? We have no more USB slots on our roboRIO to put a flash drive on. I tried to change save location in your code, but it did not save the calibration file for some reason.......

[jhersh]

Originally Posted by EthanJF123

Is there any way that you can store the files directly onto the roboRIO? We have no more USB slots on our roboRIO to put a flash drive on. I tried to change save location in your code, but it did not save the calibration file for some reason.......

Did you try something under /home/lvuser?

[EthanJF123]

I figured it out. It was a permissions error.

[Richard100]

Originally Posted by sraque

I'm looking for any reports of how this device has worked in competition. Does it work as expected? Is it reliable? Any problems?

Steve -

The RoboBees (FRC 836) used the BNO055 during both our Chesapeake District events and the DChamps. We used the 'IMU' mode rather than one of the 'NDOF' modes, which removes the Magnetometer. Although tests indicated the fusion algo compensated well for magnetic anomalies, there’s still an issue where it still takes a moment to decide where North is, so the zero position of Yaw will get updated early in the match (moves from relative to absolute). I wanted to avoid that issue so just went with the IMU mode as risk reduction.

The IMU was used to control our autonomous routine, and the IMU data was quite uniform. Basically we run a pattern to cross any of the non-manipulated defenses and line up on the tower goal … vision tracking takes us on final approach. The IMU Yaw data controlled our turns, and Pitch was used to know when we completed the defense crossing, and when to fire the Boulder while climbing the Batter. Our defense crossing detector would sporadically fail, but that was due to the detector logic, not the IMU performance.

One issue seemed to be the roboRIO’s USB port, which doesn’t seem to be up to the punishing field conditions in this year’s game. There were times when the IMU would not successfully go through calibration at startup, which appeared to be because the cal file wasn’t found on the Flash Drive (loosened on previous match). Once we relocated the cal file to the roboRIO the issue went away. Automatically falling back to analog gyros (Yaw and Pitch) was a useful redundancy, and saved our auto several times while we gathered necessary experience with the device.

We did have several times where the IMU would drop out during the match, but we think root cause here was loose wiring. We’re planning on running a redundant IMU, monitoring the device status and automatically switching over when SGAM all report 0. This is mostly an exercise for educating students on the value of redundancy in critical systems, but it might prove useful for us in St. Louis.

In post #6 I mention that there is an issue where Roll exceeding ~45 degrees causes an orientation error, speculating a possible BNO055 firmware issue. This appears to be confirmed by other users outside of FIRST (AdaFruit forums), see this, “Why doesn’t Euler output seem to match Quaternion output?”. Bosch essentially admits to the problem in their code. Appears this can be overcome by reading Quaternion orientations instead and converting them to Euler angles, which I’ll likely add to our LabVIEW drivers on a future release.

Finally, I continue to recommend using the MXP I2C port, and not the On-Board port to connect the BNO055 IMU. Using the On-Board I2C port causes Lo-byte / Hi-byte pairing failures – which will translate into IMU measurement glitches. For some reason the same code runs differently on the two different I2C busses.

[awinterstale33]

Hi, I've been trying to get this sensor to work with a myRio for days now and I just cannot do it. Can someone PLEASE help me and point me in the right direction on what to do?

[Richard100]

What have you tried so far? What was the result?

Which AHRS software version are you using?

[awinterstale33]

This is my first experience with electronics so forgive my ignorance. I'm a ME major that just got done with my 1st mechatronics and controls class and I'm hooked!

I've gotten the sensor working using the tutorial on adafruit with the arduino ide and visualizing a bunny on Processing. I've tried running the project file listed here but changing the roborio to a myrio. That didn't work so I went into each Vi to replace anything I thought was specific to the WPI I2c vi's with the myRio I2c vi's. For example, the BNO055 manual says the address is 28 or 29 and it seems like it's 26 in this project.
I've also tried the Express i2c vi that myrio has. I can't figure it out. I basically get no response from the sensor.
I don't even know what AHRS meant until you asked and I just looked it up. I'm not using a specific software, just trying to get the sensor to output values in labview(wirelessly if possible).

I just wanted an accelerometer I could learn/experiment with and that one seemed the best. I've first bought a myDaq, then a WPS (wireless programing stamp), then the arduino compiler for Labview package, and then after finding this project, I baught a myRio because I thought that was going to be the missing link.
So, I'm not part of any robotics team (although that would be nice) I'm spending the summer learning electronics/controls/etc because I want to develop a wireless, real time sensor network for our formula car next year. The plan was using ESP-8266 modules but Im starting to get the feeling it's not going to be ideal the more research I do.

And I believe you are the person behind this project? If so, thank you! It is a beautiful piece of work.

[Richard100]

The BNO055 I2C primary address is x28 (in hex). It has an alternate I2C address at x29 - there is nothing at x26. Did the code that you downloaded (version 3 is currently the latest) use x26 as the sensor address? The wrong address will definitely keep it from working.

Sorry I can't help with the myRIO steup, maybe one of the NI guys that monitor this forum will chime in. I would check that you're powering the sensor correctly (5v or 3.3v depending on which sensor pin you're using). One of the roboRIO's I2C ports (on MXP) has a jumper to properly select the voltage level. Another idea is to look for examples in the help files for coding with the I2C interface with your myRIO.

The myRIO, like the roboRIO, has an integrated 3-axis accelerometer built in, as another option for you. The benefit of the BNO055 is that the integrated sensor fusion algo will separate out acceleration due to gravity from the acceleration due to linear movement. The software posted here allows you to simply switch between those outputs.

This sensor is quite powerful due to the on-board fusion (it also has a three-axis rate gyro and a three-axis magnetometer). The software project I posted here was designed for FIRST FRC team use (roboRIO hardware and a special FRC software development suite), although it should be adaptable to other LabVIEW software contexts. Of course you're welcome to it and I hope you can resolve the myRIO integration issues.

If you're in California, there are a number of great FIRST FRC teams that you could join. Teams are always looking for mentors, and it's a great place to accelerate your own skill set in mechatronics!

[benny3543]

Hello!

I have successfully calibrated the gyro, and am now working to put the code into an actual robot project. Im struggling to get feedback from the sensor. What kind of loop/ delay in the loop should I use in periodic?

Thanks.