SparkFun officially supporting FIRST

[slibert]

Originally Posted by jojoguy10

I'm kinda curious how much better/worse this sensor is compared to the Nav6/NavX.

Thoughts?

As the person responsible for the nav6/navX, I'm kind of biased, so please take what follows with a grain of salt. Yet I think the journey we've taken to get to the navX MXP provides some valuable things to think about.

When making trade-offs like this, classic wisdom says it's good to take time, cost and features into account.

Team 2465 (Kauaibots) went on a journey, starting in 2012 (Rebound Rumble) when we first used a 9-DOF board from Pololu. It was low cost, like this board (~$40), and we interfaced to it via I2C. The pitch/roll data (X/Y axis data) was really great for the bridge balancing we did that year. We only used the accelerometers, basically and didn't get our custom 6-axis fusion software to work very well.

Next, the nav6 was created, because the yaw drift (Z-axis) from the sensor fusion algorithms was unacceptably high (in our opinion) for use in a field-oriented (mecanum) drive system. If field-oriented drive is your goal, you'll want to consider your needs and pay attention to the specifications in this area when selecting an IMU to be used for field-oriented drive. The nav6 exhibits an average of ~1 degree of yaw drift per minute. The video linked-to above showed pretty significant yaw drift, but with some software work I'm thinking it could potentially be improved.

Finally, the navX was created, in order to bring full 9-axis fusion (as discussed in the video for the 6-DOF board) into play, and to take advantage of the RoboRIO navX MXP connector, to make it a plug-n-play solution. If careful magnetic calibration is applied, this can potentially eliminate yaw drift altogether (assuming that there are periods of when the earth's magnetic field is undisturbed enough to use that as a "reference" for the yaw angle. And if you don't want to take the time to calibrate the magnetometer, you can still fall back on the yaw angle (which uses similar technology to the nav6).

All that said, there are some really great software engineers out there that can make these sensors perform really well. And if you're got team members who are like that (or mentors to help and team members who want to be) I'd highly recommend the experience of researching and developing software in this area. I think motion processing is going to join vision processing as a key skill for firmware engineers now and for the foreseeable future.

On the other hand, if you want to field-oriented drive to your robot, a plug-n-play experience with minimal yaw drift and don't want to spend the time/effort to learn the algorithms and integrate it into the RoboRIO, I'd argue the additional cost ($99) of the navX MXP is worth it - and you get the Expansion I/O capability to along with it, along w/sample code in LabView, C++ and Java - and open-source firmware and hardware for the more adventurous.

But again, I'm kind of biased. And if anyone wants to work w/the 6-DOF board and go on the "motion processing" journey, I welcome you to send me a private message - I'll try to provide some pointers based on our experiences. My strong belief is that motion processing is a key technology area to become proficient in, and doing so will be rewarding for those who wish to take the journey.