Got Sensor Fusion?

The RoboBees release a sophisticated Inertial Measurement Unit (IMU) based Attitude and Heading Reference System (AHRS), written in LabVIEW.

Based on interest regarding a simple IMU based AHRS released last year, see http://www.chiefdelphi.com/forums/showthread.php?t=131823 … this year we are making code available designed around the new Bosch BNO055 Intelligent 9-Axis Absolute Orientation Sensor, which is available on a breakout board by AdaFruit.com. The product ID is 2472, and runs about $35 (no affiliation). It is powered by 5 VDC (or 3.3 VDC) and interfaced over the I2C bus (roboRIO compatible). Mentioned elsewhereon CD, the board should be available via virtual KoP Product Voucher through Digi-Key, for free.

A key difference distinguishing this IMU is that the BNO055 contains an integrated microcontroller, (high speed Cortex-M0 based processor) running a sensor fusion algorithm, which is designed to constantly self-calibrate in real-time, after an initial manual calibration process has occurred. The on-board fusion algorithm, although unspecified, is likely a Kalman filter variant. The filter fuse’s the three sensors into a single composite sensor which provides accurate and stable orientation indications in all 3 dimensions (Roll, Pitch, and Yaw). This LabVIEW code runs on the roboRIO with last year’s version of LabVIEW, and should easily port once FIRST releases this season’s LabVIEW version.

The IMU is calibrated by simply moving it in a prescribed manner. Once this is done the fusion algorithm will continue to update the calibration as a background process. The LabVIEW code simplifies the calibration process by providing guidance and real-time status feedback, as well as functionality to save and restore previous calibrations, allowing the sensor to become ready for use upon power-up. A flash drive is required to be installed in one of the roboRIO’s USB ports.

The IMU code modules are patterned after the familiar WPI sensor VIs. Once again, there’s no coprocessor to integrate or assembly required, beyond soldering some pins. The concept behind the released demonstration project is to have you up and running by simply plugging in the IMU and supplying your FRC Team number to the LabVIEW Project file.

The files have a bunch of comments for how the code works to understand this unique sensor. As always, bug reports are welcome!

Good luck to all FRC teams this season, the RoboBees will see you at STRONGHOLD!

The RoboBees FRC Team 836

AdaIMUOrient.zip (949 KB)


AdaIMUOrient.zip (949 KB)

Additional detail for those interested …

Description:
Reads Bosch BNO055 Inertial Measurement Unit (IMU) sensors: Rate Gyro, Accelerometer, and Magnetometer. Numerically
integrates Gyro rates to accumulate degree displacement. Reads data fusion outputs.

These IMU subVIs are designed to be used with the AdaFruit 9-DoF Absolute Orientation IMU Breakout - containing a high
speed ARM Cortex-M0 based 32-bit processor running a Bosch sensor fusion algorithm to blend the integrated 3-axis
Accelerometer, Rate Gyroscope, and Magnetometer readings (Product ID: 2472). The fusion algorithm, although
unspecified, is likely a Kalman filter variant.

The RoboBees IMU ORIENT Series subVIs are:

OPEN - Performs IMU initialization, setup, and calibration of each axis of Rate Gyroscope, Accelerometer, and Magnetometer.
The device can be configured to a number of different fusion or non-fusion operating modes.
IMU RefNum Registry Set / Get - These are standard WPI-type functional globals used to pass IMU configuration data.
READ - Reads IMU sensors. Gyro output provides XYZ rotation rates as well as integrating these rates for degree displacements.
Accelerometer output provides XYZ raw acceleration, as well as separating acceleration due to movement (linear)
from acceleration due to gravity. Magnetometer output provides XYZ magnetic field strength and anomaly detection.
Orientation outputs available in both Roll / Pitch / Yaw (Euler degrees) and in quaternions (WXYZ).

Design:
Calibration of each sensor is performed, or re-established, by the IMU Open vi. The essential design of this vi is to provide
read operations for a set of indication functions. Each function can also be selectively enabled/disabled by settings passed
in the Read Enable cluster, to allow the user to optimize read cycle times (enabling only what is used). These functions
provide real-time calibration status, orientation in Euler angles and quaternions, rotation rate and angular displacement,
multiple modes of acceleration, and magnetic field strength. The various read functions access the appropriate IMU data
registers over the I2C bus, then data bytes are assembled, and finally scaled by specification sheet sensitivities to put the
values into the correct units. Gyro rates are numerically integrated for rotation displacement, with an available
reset-to-zero function.

The on-board fusion algorithm will continue to update the calibration as the sensor is read. If enabled, the Cal Status is updated
in real-time, providing Gyro, Accel, Mag, and System status. One can observe the status change as the sensor is exposed to
movement or non-Earth magnetic fields. Calibration status is provided in a color-coded Boolean Cal Status cluster, where red
indicates a status level of 0 (uncalibrated) and green indicates status level 3 (fully calibrated).

Each sensor (G/A/M) shares the basic design of storing their measurements across two one-byte registers, and the native data
register sequence for each sensor is Little Endian - review this term and its relationship to Gulliver’s Travels by Jonathan Swift
for insight on reference (software engineers have a great sense of humor). Orientation in degrees for Yaw, Roll, and Pitch is
provided in an Orient Y/R/P output cluster. Rotation rates and Degrees displacements are provided in a Gyro X,Y,Z output cluster.

Three modes of acceleration can be alternately indicated, selectable via the Read Enable, Accel Mode input control. Selecting
Raw Data yields 3-axis acceleration measurements that combine acceleration due to movement with reacting forces due to
gravity. (Review Einstein’s Principle of Equivalence, which asserts there is “complete physical equivalence of a gravitational
field and a corresponding acceleration of the reference system”, which is why an accelerometer will always report a composite
of both ‘accelerations’). Selecting Linear as the control value modifies the indication to reflect only acceleration due to
movement, as separated by the fusion algorithm. Similarly, selecting Gravity modifies the indication to reflect the fusion
algorithm’s estimate of only the reacting forces due to gravity. Acceleration values are provided in a Acc X,Y,Z output cluster.

Orientation expressed in quaternions is provided in the Quaternions output cluster for values in W, X, Y, and Z. Not to be
confused with axis-angle representations, the quaternion is an extension of complex numbers, from one of the less mainstream
branches of mathematics. (The quaternion represents a point on the surface of a four-dimensional hypersphere.) These are
unit quaternions, where the root-sum-square of all parameters is one. Quaternions are useful in avoiding gimbal lock and for
smoothly interpolating rotations. The algorithm reportedly performs all internal sensor fusion calculations in quaternions.

Magnetic field strength measurements in all three axes is provided in a Mag Field X,Y,Z cluster. The vector magnitude is
calculated and compared to the expected Earth field for magnetic anomaly detection. One can use the average value displayed
on this vi’s Front Panel (magnitude), which should be consistent with data available at the National Geophysical Data Center :

                                       http://www.ngdc.noaa.gov/geomag-web/?useFullSite=true#igrfwmm

… input USA zip code or city/country, select Get Lat/Long then Calculate, and note “Total Field” value, expressing this in
microTeslas (not nanoTeslas as NOAA displays). A Mag Field Tolerance value is used as tolerance for the comparison.

Inputs:
I2CDEVREF - Device Reference containing IMU configuration data.
READ ENABLE - Cluster containing switches for each read function, and a control to choose the mode of acceleration data.
GYRO (DISPLACEMENT) RESET - Boolean control to reset gyro 3-axis displacement values to zero. Reset occurs on Rising-Edge.
EARTH FIELD (uT) - Cluster for expected total 3D Earth magnetic field vector magnitude, and tolerance used for anomaly detect.

Outputs:
CAL STATUS - Cluster indicating cal status of accel, rate gyro, mag and system. Status is a ‘real-time’ report of the fusion
algorithm’s belief of the degree of IMU calibration. Level 0 indicates uncalibrated, level 3 indicates fully calibrated.
ORIENT Y, R, P - Cluster containing rotation orientation for Yaw, Roll, and Pitch, in degrees.
GYRO X,Y,Z - Cluster containing rotation rate and displacements for each axis, in degrees/sec and degrees.
ACC X,Y,Z - Cluster containing, for each axis, calibrated acceleration measurements in the selected mode, in mGs.
QUATERNIONS - Cluster containing quaternion parameterization (W,X,Y,Z) of orientation, unitless.
MAG FIELD X,Y,Z - Cluster containing, for each axis, calibrated magnetic field strength, in microTeslas, and an anomaly indicator.

VI Properties:
Execution Reentrancy is set to Non-Reentrant Execution

Implementation:
While either of the two roboRIO I2C interfaces can be designated, it is recommended that this software be used only with the
MXP I2C interface (the Rev Robotics ‘More Board’ provides a convenient expansion of the MXP interface). Although the software
is and runs the same for either I2C port, the On-Board I2C interface performs differently, and can cause frequent Lo-byte / Hi-Byte
measurement pairing failures during read operations.

Despite the sensor calibration in IMU Open, neither the Mag cal status, nor the Mag anomaly detection, nor the correspondence
of 0 degrees of Yaw to magnetic North, has been observed to be highly trustworthy during an initial operating period, until the
background calibration process has been allowed to experience some 3-D movement. This does not appear to greatly affect the
quality of the relative orientation readings (Euler Yaw/Roll/Pitch or quaternion).

This design performs numerical integration off-FPGA for the Digital Gyro (unlike the Analog Gyro subVIs, which typically utilize
the FPGA to perform accumulation for superior speed resulting in less integration error). Testing indicates this off-FPGA
approach may be adequate for FRC application, however, it is important to ensure the code runs without any timing issues.
This is why a Timed Loop is recommended for the IMU Read within Periodic Tasks (executes at a higher priority). Non-uniformity
in read iteration is mitigated by design, as each dt is uniquely calculated by time stamping each read event. This means that while
some variation in timing can be tolerated (the occasional late iteration), excessively long durations (periods) between successive
reads will fail to capture the actual rate profile as it changes resulting in integration error.

In short, use a Timed Loop structure to iterate IMU READs, and set the loop period for a relatively fast iteration (<75 ms). Shorter
periods provide improved accuracy of degree displacements, however setting this too short can impact the execution of your
remaining code (especially when using Timed Loops). One way of determining an optimized period is to set it while monitoring
the “Finished Late?” Loop parameter, ensuring this value stays False. It helps if the CPU Utilization remains low (<75%), which
can be monitored with the RT Get CPU Loads subVI (Real Time menu). Study LabVIEW determinism for additional insight.

IMU Orientation Read benchmarks, with roboRIO.
Time to execute IMU Orient Read in milliseconds (ms):

Device … Read (ms)
Cal Status 1
Orientation 1-2
Gyro 1-2
Accel 1-2
Quaternion 1-3
C + O 1-3
O + G 1-3
C + O + G 2-5
ALL 3-7

Ensure loop time calling this subVI is significantly above listed read execution time (say, >*10) to minimize load on CPU utilization.

----- The RoboBees FRC Team 836! ----- You too can conquer inertia!! … orient on a career in STEM!

FYI, theres also a breakout board for this sensor from Atmel, also sold on DigiKey, but it’s cheaper! (~$25 shipped)

http://www.digikey.com/product-detail/en/ATBNO055-XPRO/ATBNO055-XPRO-ND/5230918

I’ve tested this breakout board with my Java class and it works fine. I see no reason why it wouldn’t also work with your LabVIEW implementation.
Wiring info against the Adafruit board is here: https://github.com/jcorcoran/BNO055_FRC

The RoboBees LabVIEW code for the BNO055 Absolute Orientation IMU sensor has been ported to the 2016 FRC version of LabVIEW.

There is a Visualization vi which runs on the My Computer Target, providing a 3-D scene for tracking the sensor movement. This can help with understanding the performance of the sensor.

AdaIMUOrient v2.zip (383 KB)


AdaIMUOrient v2.zip (383 KB)

So I’ve got my sensor hooked up, and I’ve double checked the connections, but I don’t see anything happening on the various graphs when I move the sensor around. I have deployed the code successfully. Is there some sort of readme for this example?

Thanks,

Benjamin

I would speculate that your IMU is not yet calibrated. What does the “Current Cal Status” indicator say? If all values are red you probably haven’t gone through the calibration process. Advise if this isn’t the problem and I’ll help troubleshoot. For now, I’ll assume cal is the problem …

IMU’s require calibration for their measurements to become useful. This BNO055 IMU is advanced to the point that the sensor will self-calibrate if you simply physically move it as described by section 3.10 of the datasheet(and then it will continue to update its calibration as it’s used in operation).

There’s a short version of this guidance in a comment on the back panel diagram of IMUOrientOpen, but here’s the procedure in a bit more detail:

The code is designed to first help you calibrate the IMU by letting you put it into a calibrate mode. This is where you make the physical sensor movements for calibration. As this mode completes, a calibration dataset is stored on the flash drive that you previously installed in either one of the roboRIO’s USB ports. The next time you run the code, you put it in normal mode and tell it the name of the stored calibration file. This lets the IMU to be ready at startup.

Let’s try this … once you have the IMUOrientDemo2016 vi open, select the “Calibrate?” control on the front panel, and open the IMUOrientOpen vi so you can see its front panel (you’ll need this in a moment). Do a Run-button deploy (not a Compile-and-deploy). TheIMUOrientOpen vi will run first, and since Calibrate? is set to True, you will be prompted via a dialog box with instructions on the physical motion required to achieve calibration. With Demo running, switch to the IMUOrientOpen front panel so you can observe the “Manual Calibration Status” indicator – this provides immediate feedback as you move the sensor around per the instruction. Once all four status indicators are green, another dialog box will congratulate you on your perseverance and personal intelligence, but most importantly, it will identify the filename where the calibration constants have been stored. Write this down and stop the code.

Go back to the IMUOrientDemo2016 vi, deselect the Calibration? control, and enter the cal filename into the “Stored Cal File” control on the front panel of IMUOrientDemo2016. Run the vi again (it can be a Run-button deploy or a Compile-and-deploy, doesn’t matter now). You should now see data updates on the front panel graphs and other indicators.

The calibration process needs to be executed at least once so there’s a cal file for the code to reference. Try this first with the sensor on a table-top to get used to what motion it takes to achieve full (all green) calibration. The accelerometer generally takes the most finesse to calibrate - keep trying, it’s worth it. Once you install the sensor on the robot, you’ll have to move the entire robot around as a unit to create a new calibration file. This is because the robot can disturb the local magnetic field, and you want the cal to compensate for this. It’s not too difficult.

Explore the different sensor operating modes using the “Op Mode” control on the Demo vi, which are described in section 3.3 of the datasheet. Some are fusion modes and some are not. The code defaults to the “NDOF_FMC_OFF” operating mode, which translates to Nine Degrees Of Freedom / Fast Magnetic Calibration Off. The “IMU” operating mode avoids the use of the sensor’s magnetometer, which could be useful should you find issues with robot magnetic interference affecting sensor performance (one tradeoff is that you won’t know North). The Op Mode must be designated prior to running the code.

Explore the different sensor read functions with the “Read Enable” control on the Demo vi. These can be selected / deselected ‘live’. The accelerometer read function has three different modes so you can explore Einstein’s Principle of Equivalence with the power of sensor fusion. You can turn on all the read functions so you can see what’s available. You might want to leave on only the functions you use to optimize the execution speed of your code.

There are two separate I2C interface buses on the roboRIO. I recommend staying with the default “MXP” interface, as there still appears to be difference in how they work, and the On-Board I2C port is apparently causing issues with the BNO055 bus traffic (best I can tell). Get a Rev Robotics More Board to get easy access to the MXP I2C interface, if you like.

Don’t forget to run the Visualization vi to observe in real-time the orientation change as the sensor is moved. The vi runs on the My Computer Target, (not the roboRIO Target), which means it can only be accessed in debug mode. There is an issue where Roll exceeding ~45 degrees causes an orientation error (possible BNO055 firmware issue). Most FIRST robots don’t roll that far so perhaps it’s not a major issue.

That’s about it … you might read through the datasheet to get a better idea of everything the sensor can do. Our software abstracts the details to make it quick/easy to use in competition. There a bunch of comments in the code that discusses the code design and implementation considerations.

Let us know if this helped!

Okay, I’m in the shop this morning and I’m going to try what you said. Just to confirm, I need to have a flash drive in the Robo Rio when running this IMU? It’ll have to remain in the entire time?

Actually just got the calibration process working. I see the part about the flash drive. Thanks! I’ll keep posting here with updates.

Yes … you need to leave a flash drive installed. Would have been nice if the BNO055 had some EEPROM but it doesn’t. We use a low profile flash and just leave it for data logging, so we’re used to it / no issues.

By working I mean the code is running properly. But I’m not seeing any calibration occurring as I move the sensor around. I’m currently plugged into the singular I2C port. I’ll try plugging into the MXP I2C soon, but I don’t currently have the pin connectors to do that.

My apologies about the flash drive thing. I didn’t read carefully enough.

Attached is a screenshot. It says “bad result”?

EDIT: Connected through the MXP I2C now. We put it in IMU mode instead of CONFIG. Successful calibration of Accelerometer and Gyroscope.

Thanks,

Benjamin





When you were plugged into the ‘singular’ (On-Board) I2C interface, you likely needed to set the I2C port to “On-Board” in the front panel control of the Demo vi. The I2C Read/Write vi’s need to know where to look for your sensor.

When you switched to the MXP I2C port, it was likely connected but you had selected “Config Mode” (reference your screen shot) which may explain why you received a “Bad Result”.

Now it sounds like you’re configured correctly … since you’re seeing cal status updates. Yes keep trying … if you’re having trouble with the magnetometer calibration move the sensor in all three axes and the mag cal will improve to green. Bosch suggests moving the sensor in a figure-8 pattern. I found that orbiting the sensor in a polar axis followed by an equatorial axis calibrates the Mag quickly.

The ‘S’ element represents the status of the “System”. There’s not much explanation from Bosch on this but it appears that the internal Kalman filter needs to build up some agreement between the accel, gyro, and mag for it to reach cal status level 3 (green in our software).

Keep going, you’re almost there … this sensor is unlike many others you come across in FRC - it is highly advanced but takes some initial effort to set it up. The performance is staggering, especially since it’s effectively free via the virtual KoP. It’s a sweet piece of tech and worth the effort.

I want to reiterate publicly what I said earlier to Richard in a PM.

Thank You!

Team Titanium got this sensor running today thanks to Richard answering a few questions. It does still seem a little mysterious how much tilting and shaking the robot needs before the calibration cycle goes all green, but we love the results once it does. Here is what we did.

  1. Wired the sensor to the I2C portion of the MXP expansion slot on the roboRIO. (We had some poorer results with the onboard I2C slot.) Secured the sensor to the robot (with tape).
  2. Put a flash drive in the top-most USB port. (We failed to read the calibration settings when we used the other port.)
  3. Downloaded the AdaIMUOrient v2.zip from post 4 of this thread.
  4. Extracted the files and opened up the IMU Orient Demo 2016.lvproj
  5. In the project explorer changed the “836” in the target to our team number.
  6. Opened the IMU Orient Demo 2016.vi and changed the Earth Field to 52.5 to match our local zip-codes information on the front panel.
  7. Also on the front panel we turned on the Calibrate? button. We left the I2C Bus and Op Mode in their initial settings. (I2C MXP and NDOF_FMC_OFF)
  8. Hit the run arrow while connected to the robot wirelessly to deploy in de-bug mode.
  9. Calibration instruction came up and we hit the “OK” button to proceed.
  10. Turned the robot, laid it on it’s side and back, and towards the end of the calibration cycle we pushed it really fast across the floor.
  11. While watching the front panel of the IMUOrientOpen.vi we saw the Gyro light (G) go green immediately, followed by the accelerometer (A). The M and S lights took a bit longer to get to lit-up.
  12. Once all the lights went green a pop-up message appeared with the file-name of the calibration constants which were then saved to the USB drive. (We did check the USB drive to make sure the files were there. They were.)
  13. We stopped the code, turned the Calibrate? button off on the front panel, and typed in the name of the file into the “Stored Cal File” text box. (We actually mistyped it the first time. Of course it cares.)
  14. We re-ran the code in debug mode. All lights on the Current Cal Status went green. The Cal Status @ Open was Red, Green, Green, Green.
  15. We did get readings on yaw, pitch and roll that seemed accurate (and steady for a stationary robot!). For Yaw 0/360 seemed to be due east. Not sure if this is always true, or a function of where the robot was when we calibrated it. It also does not include angles outside of 0 to 360. No negative angles. Code will have to interpret that jump between 0 and 360.

So far we are very encouraged by the results. Yaw seems to be very robust against robot jarring. We look forward to more robust testing of this sensor.

Thank you both very much! I’ll get to try again tomorrow afternoon. I’ll follow these steps exactly.

Benjamin

I would be interested in the performance of these self made units.
In particular I would like to know what the magnitude is of the following measurements when the sensor is not moving.

Gyration in radians/sec
Acceleration repeatability in g (turn off / turn on again after a few days)
Magnetometer variation in % at run time

I am working with RTIMU2-teensy and have ported code on my github account (uutzinger). I am using the MPU 9250 which is the same as the navx mxp unit. The RTIMU library supports many other IMUs including the Bosh unit. RTIMU worked for me because I could expand the code to make an underwater pressure sensor work with it.

With the MPU 9250 i get
Gyration 0.002 rad/sec when sensor does not move.
Acceleration is within 10mg after a few turn on/off cycles.
Magnetometer varies usually about 10-20% depending on orientation even after calibration. The magnetomter is the main source of fluctuations in the pose.

I believe the key ingredients for IMU to work well on an FRC robot is that you can turn off the magnetometer when motors are engaged and that you can accurately measure the gyroscope bias when you know the robot is not moving.

The navx unit has an magnetic field anomaly detection but I have not yet seen that working correctly and I think its better for teams to turn off the compass when their autonomous period starts (and navigate with gyroscope and accelerometer).

RTIMU computes the gyro bias during runtime which has its own issues because detecting that the IMU is not moving is tricky.

Even with best calibration the gravity removed acceleration I get is about 0.02 m/s2 when the robot does not move.

Uutzinger -
Informal testing of BNO055 performance:

Rotational drift … well … 0 radians per second
Clamping it to the table resulted in no change in rotation after 10 minutes. By ‘no’ I mean zero. This is the sensor fusion output (roll, pitch, and yaw, each), not the raw gyro. Gyro itself is about 0.5 deg / min on worst axis, and that’s with me doing the rate integration (trapezoidal rule with 20 ms sample period).

Accelerometer repeatability …
Short term measurement std dev (separating out gravity) is ~ 1 mG for X,Y axes; ~ 4 mG for Z (exposed to Earth G field)
Short term measurement std dev (gravity alone, i.e. separating out linear acceleration) is zero, all axes.
Running sample size of 30.

  Log term repeatability (change in mean value after successive power resets)  is &lt;&lt; Short term SD / doesn't change / not discernible from short term noise.

Magnetometer repeatability …
I can offer the results of a simple test I conducted with the IMU in full sensor fusion mode (specifically the “NDOF_FMC_OFF” mode, which incorporates the mag with accel and gyro). Strapped the IMU to robot about 12 inches away from CIM drive motors. To generate high current draw, spun robot in place (~500 deg/sec). Resulting Yaw orientation graphed out as flat repeating ramp signal from 0 to 360 deg (0 and 360 are congruent). Implication, if I’m thinking right, is that any robot magnetic field disturbance would cause ramp signal to deviate from flat. The fusion algo appears to automatically discount magnetic disturbance and perhaps fall back to a degraded performance (which I cannot detect).

Strapped IMU directly to CIM motor and repeated test. No change / flat Yaw ramp during spin.

We might be able to come up with a more sophisticated test.

It’s entirely possible that the fusion algorithm embedded in the BNO055 outperforms some other algos, don’t know. It’s a factory’s secret sauce in the IMU world. It appears to be very high performing.

At the moment, I’m satisfied with it.

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.

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.

Read Me.docx (25.8 KB)
AdaIMUOrient v3.zip (435 KB)


Read Me.docx (25.8 KB)
AdaIMUOrient v3.zip (435 KB)

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.

What size of flash drive should you use?

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.