SparkFun officially supporting FIRST

[Thad House]

I went onto SparkFun today, and saw this.

https://www.sparkfun.com/news/1708

Better gyros in FIRST Choice is always nice, and a discount code for teams to use it really good as well. Also the publicity from a big company like SparkFun always helps.

[jojoguy10]

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

Thoughts?

[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.

[jojoguy10]

Great thoughts!

Our team is planning on going with field-oriented driving for some and robot-oriented for others. Right now, we are using the KOP gyro/accelerometer, but the drift on it is unacceptable and it's obvious while driving.

With that said, we were originally planning to buy the NavX, but we saw it was out of stock (I heard it's coming to AndyMark and back in stock at Kauai Labs soon). With it out of stock, we're just waiting right now.

That's why I was wondering about this SparkFun sensor. Is it worth getting that just so we can start improving our mecanum or do we risk not getting a NavX when it comes in stock?

So, as we stand right now, we're just going to wait for the NavX to become available.

Thanks!

[Thad House]

Originally Posted by slibert

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.

I want to believe in the Nav6, but I just don't think we will actually be able to get one. With you guys saying AM is only going to be getting 100 of them, and it has a 5 week lead time, there are not going to be alot of teams getting them, which means we need other options. If it was going to be more available, I would say for sure it would be a better option.

[slibert]

Originally Posted by Thad House

I want to believe in the Nav6, but I just don't think we will actually be able to get one. With you guys saying AM is only going to be getting 100 of them, and it has a 5 week lead time, there are not going to be alot of teams getting them, which means we need other options. If it was going to be more available, I would say for sure it would be a better option.

As to the navX, your description of the situation is correct. I'm not even sure our team is going to be able to get them from AndyMark, based upon the demand, the navX MXP's sold out at the Kauai Labs store before team 2465's order was placed.

So we are using the nav6 for our team's robot development.

As to the nav6, we still have about 30 left for sale at KauaiLabs in the online store. We've got them working w/the RoboRio either w/the RS-232 port, or with a USB-serial adapter. Note that not every USB-serial adapter is detected by the RoboRIO Linux OS, so if you go that route, you'd want a more common USB-serial adapter that uses the FTDI Chipset. If you have any more questions on that, please feel free to send me a private message and we can discuss that further.

[Joe Ross]

Originally Posted by jojoguy10

That's why I was wondering about this SparkFun sensor. Is it worth getting that just so we can start improving our mecanum or do we risk not getting a NavX when it comes in stock?

Assuming you want to use it just for yaw, it should be better then the ADW22307 gyro, however the specs are worse then the ADXRS453 single axis gyro discussed in this thread: http://www.chiefdelphi.com/forums/sh...d.php?t=130538

In either case (ITG-3200 or ADXRS453), you'd have to write your own driver and integration.

Like Scott said, fusion algorithms are not easy, so taking advantage of the 6 axes is probably not something a normal team would get working this year, which would be the advantage of the 6 axis board.

[Dale]

The CH Robotics sensor is the closest we've found to the navx. It doesn't plug in as nicely to the top of the RoboRIO but, at least on paper, seems to address the same problem of knowing what direction you are facing. Has anyone tried it?