new FTC-compatible navX-Micro IMU / AHRS Sensor Announced

[FTC10386]

This was just announced on www.kauailabs.com, and should be of interest to FTC teams who are looking for a plug-n-play IMU that's designed to be easy-to-use for FTC robotics. This same technology is now in use by hundreds of FRC teams, and is completely open-source.

Available for purchase mid-November. More information is available at http://navx-micro.kauailabs.com

navX-Micro Feature Summary:

Sophisticated Motion Processing

•High Accuracy, Low-latency Yaw, Pitch and Roll Angles
•Automatic Accelerometer/Gyroscope Calibration
•Quaternions and Gravity-corrected Linear Acceleration
•High-sensitivity Motion Detection
•Tilt-compensated Compass Heading
•9-Axis absolute heading w/Magnetic disturbance detection

Inertial/Magnetic Measurement Unit

•Configurable Update Rate from 4 to 60Hz
•Access to Raw Data from Gyroscopes, Accelerometers and Magnetometers

Easy to Use

•Plug-n-Play connection on FTC and FRC robots via I2C interface
•Connection to Windows PC via USB Cable
•FTC and FRC Software libraries and sample code
•Support for Mounting in horizontal, vertical and even upside-down configurations via Omnimount
•Tools for Magnetometer Calibration
•Onboard Calibration data storage (in EEPROM) for rapid startup

Protective Enclosure

•A custom navX-Micro enclosure can be created with a 3D printer using provided Enclosure design files
•Alternatively, the navX-Micro enclosure can be purchased separately online.

Open-Source

•board schematics (developed in Eagle 6.5.0, freely available at http://www.cadsoftusa.com/) and bill of materials.
•The Eclipse IDE and a free version of an ARM compiler can be downloaded for those wishing to customize the firmware.
•Firmware updates can be easily downloaded to the navX-Micro circuit board via the USB port.

[AlanG]

Does it come with any sort of Java API with which one could set up a separate IMU thread in the FTC SDK execution environment?

Is there any available information about how much (or how little) "crosstalk" there is among the pitch, yaw, and roll angles? Specific example: Does the yaw (heading) angle remain steady when a robot drives straight up a ramp, thereby pitching upward toward "gimbal lock"?

[FTC10386]

Here's the link to the online help for the current Java library: http://www.kauailabs.com/public_file...pidocs/android

And here's the link to the sources: https://github.com/kauailabs/navxmxp.../ftc/AHRS.java

The MPU-9250 and the navX-Micro microcontroller calculate all the interesting data on-chip, so typically application code doesn't need to manage things on a separate thread. The onboard calculations include the quaternions, the Tait-Bryan Angles (yaw, pitch, roll), world-frame Linear Acceleration, motion/rotation detection and also velocity and displacement integration. All of these values, except the velocity/displacement integration values, are made visible in the navx-Micro Java API.

I'm responsible for the library and the sample code, and there's one example (collision detection) that's being ported from FRC code to FTC that could use just such a callback. So work is underway to add a callback to the Java API that will notify anyone that registers whenever new data has been retrieved from the navX-Micro, triggered whenever there's a change in the timestamp that is included with each update from the sensor.

To help ensure that any requirements you envision may be included in this new callback mechanism, can you please let me know what kind of processing you are envisioning to take place when new data is received?

[dmssargent]

FTC10386, why are you using lines like "return (((curr_data.sensor_status & AHRSProtocol.NAVX_SENSOR_STATUS_MOVING) != 0) ? true : false);"
when to me it should just be "return (curr_data.sensor_status & AHRSProtocol.NAVX_SENSOR_STATUS_MOVING) != 0;"?

[FTC10386]

> Is there any available information about how much (or how little) "crosstalk" there is among the pitch, yaw, and roll angles?
Specific example: Does the yaw (heading) angle remain steady when a robot drives straight up a ramp, thereby pitching upward toward "gimbal lock"?

Cross-axis sensitivity (from the MPU-9250 datasheet) for the gyros and for the accelerometers is +/- 2%. The modern 9-axis MEMs sensors from Invensense, STM, Bosch and Fairchild have similar specs in this area.

At the algorithm level, pitch and yaw accuracy is not significantly impacted by cross-axis effects and should remain accurate independent of motion in other axes.

The yaw axis drift is not significantly impacted if motion in one axis occurs (e.g., as when driving straight up a ramp), even up to a near vertical ascent - so it's steady in that case.

A more interesting case to discuss is the impact on yaw accuracy when the robot chassis is driving over bumps as it drives upwards. This type of motion
(high-amplitude simultaneous motion in both x and y accelerometer axes) presents a challenge to 6-axis sensor fusion algorithms. The impact on yaw accuracy is related to the amplitude/frequency of the x/y axis motion and also the mass of the robot and the quality of the sensor mounting.

So based on the results seen with FRC, here's how it pencils out in my mind: Assuming the sensor is well-mounted on a 15-pound, four-wheeled robot, I'd estimate going over all the churros on the low-mid zones could introduce on the order of +/- 1 degree of yaw error. For robots that continue on to climb up the high and cliff zones, the yaw error introduced would depend upon how smoothly (from the sensor's point of view) the motion occurred. A grappling hook-style lifter might have little error introduced unless the robot were to bang against the churros/rails as it climbed, but a two-handed climber could experience more degrees of yaw error, say +/- 2 degrees of error. So that totals up to an estimate of +/- 3 degrees of yaw error when climbing from bottom to top.

[FTC10386]

FTC10386, why are you using lines like "return (((curr_data.sensor_status & AHRSProtocol.NAVX_SENSOR_STATUS_MOVING) != 0) ? true : false);"
when to me it should just be "return (curr_data.sensor_status & AHRSProtocol.NAVX_SENSOR_STATUS_MOVING) != 0;"?

Thanks for the code review, that's a good point - appreciate the feedback!

[matrixguy]

This was just announced on www.kauailabs.com, and should be of interest to FTC teams who are looking for a plug-n-play IMU that's designed to be easy-to-use for FTC robotics....

Easy to Use

•Plug-n-Play connection on FTC and FRC robots via I2C interface
•Connection to Windows PC via USB Cable
•FTC and FRC Software libraries and sample code
•Support for Mounting in horizontal, vertical and even upside-down configurations via Omnimount
•Tools for Magnetometer Calibration
•Onboard Calibration data storage (in EEPROM) for rapid startup

Hi,

I saw this thread and I checked out the navX-Micro IMU. It looks really nice and has a lot of features. I check out their Java software for FTC and it looked easy to use. There are a lot of features though that I probably wouldn't use and some I don't even know what they are. I was looking at one of their example programs for motion detection and there was a warning about thread synchronization.

I'm just starting to learn to program with Android Studio and wasn't sure if this would be as easy to use as I first thought. Also, there isn't an I2C cable attached or a header. I've never tried soldering on anything like this before and would hate to "fry" the board.

I was just going to order the new Integrating Gyro from Modern Robotics, but I was thinking about getting this one instead. Any advice or recommendation would be greatly appreciated.

Thanks

[FTC10386]

The final production units (available mid-November) will have a 4-pin I2C header pre-installed, and will come out of the box with a 4-wire I2C cable. No soldering required, and it's literally plug it into one of the DIM i2C ports, modify the port number in the opmode sample code, and then in the loop() function access the sensor data.

The thread synchronization is only an issue for advanced users who would like a callback whenever new data is available, so you shouldn't need to worry about that.

Check out this sample opmode code, it should give you a good understanding of what the opmode code will look like for typical usage.

[Varun Singh]

Do you know how this compares with the Adafruit IMU that others have been using in terms of accuracy with yaw angles and accelerometer data?

[FTC10386]

Haven't done a side-by-side comparison, they're likely to be very similar - they're both using similar MEMS technology (Bosch BNO055 vs. Invensense MPU-9250). The yaw drift when not moving is less on the BNO055, but I haven't yet heard what really counts which is the yaw drift under various dynamic situations. In practice, the navX-Micro yaw drifts an average of +/1 degree/minute, and under extreme circumstances (e.g., lots of bouncing up and down, left and right as if driving over a set of churros) can get up to +/3 degrees/minute. Absent any hard data on the BNO055, my believe is they are likely very similar in this area. Hopefully we'll get some side-by-side data.

At the feature level, the differences between the BNO055 and navX-Micro are in cost and ease-of-use. The Adafruit BNO055 IMU costs less, and requires a small bit of soldering to install an I2C header. The Swerve Robotics library includes calibration data get/set functions, so you should be able to store magnetometer calibration data for later use by writing some code in the robot application. That library also timestamps each data sample w/the Android system timestamp.

The navX-Micro has an on-board microcontroller that manages storage of calibration data to ensure quick startup, connects also to a PC via USB (for demo UI, magnetometer calibration, firmware update), supports easy-to-configure mounting in various different configurations (vertical, horizontal, upside-down), and 3D-printable enclosure design files are online or can be ordered from Shapeways. The navX-Micro timestamps that data at the microcontroller level, so it's more accurate which might make a difference if using the yaw, pitch or roll angles in a PID controller.

As to accuracy of accelerometer data, what kind of accuracy are you looking for? Do note that neither of these has accelerometer data that's high enough quality (low-noise) to integrate and get displacement data, so if you're wanting to use the acceleration data to track the location of the robot as it moves, you'll find that the accuracy is not going to be sufficient. The BNO055 has slightly better accelerometer noise (in micro-g/square-root hertz) specs than the navX-Micro's MPU-9250, but the navX-Micro double-integrates the accelerometer data onboard, whereas it has to be done on the Robot Controller w/the BNO055 (which is problematic because the timestamps from the Swerve Robotics library - since they use the Android system clock - aren't very accurate which makes a huge difference when integrating). But either way, you won't really get sufficiently accurate displacement data from either.