ANNOUNCING: navX MXP Robotics Navigation Sensor

[Joe Ross]

Originally Posted by ayeckley

Can anyone recommend a good tactic (that doesn't involve modifying the navX source code) to convert the yaw output from a range of -180 to 180 (i.e. modulo 360) to an accumulated total rotation? All of the approaches we can think of require an assumption of what a maximum realistic turn rate is, and we'd like to avoid that if possible. I'm confident that we're not the only team encountering this challenge.

We had this issue. However, as we were already reading the angle at 50hz, finding a reasonable assumption of turn rate wasn't hard, we used a threshold of 180 degrees, which means we'd have to be spinning at faster then 9000 degrees/sec to have a problem.

[Joe Johnson]

Originally Posted by Joe Ross

We had this issue. However, as we were already reading the angle at 50hz, finding a reasonable assumption of turn rate wasn't hard, we used a threshold of 180 degrees, which means we'd have to be spinning at faster then 9000 degrees/sec to have a problem.

I think you also have the angular rate data from the navX. It gives you the angle estimate but it also gives you the rate that it things you have changed. You can use this to provide a check on your accumulation calcs. There are an infinite number of angular rates that can get you from one NavX position to another (due to the Mod 360 problem) but you should choose the one that is closest to the angular rate measured by the NavX.

My 2 Cents.

Dr. Joe J.

[dougwilliams]

Scott and All,
I was wondering if there's a good layman's comparison of the nav features comparing the Nav6 vs the NavX? We had the misfortune of buying the Nav6 right before the NavX announcement and have to financially consider buying a batch of NavX's now. With that said, the Nav6 provided flawless performance during our season, we implemented FOD on Mecanum, with a bunch of special alignment "rotate-to-angle" type features. Your support was also stellar (thank you!).

Your best practices page explains a lot - and there are some pros and cons to the various connection methods as compared to the Nav6. I understand all that, but need help with the Navigation features.

What benefit is the NavX providing over the Nav6? Practically speaking for an FRC robot? Does the 9-axis benefit most users? Are there other nav features I may not be considering, or future products worth waiting for? We typically were just using yaw readings for FOD - but may expand that to some of the accel features in the off season and next year.

Thanks for the help -

[cjl2625]

I've had a weird issue with the navX sometimes refusing to give readings. Like for most matches, it works fine, but sometimes it doesn't read and generally leads to catastrophic results for the match.
Has anyone else seen this?
(I have it plugged in with both MXP and USB and read with SPI)

Also, if we were to place our robot half way on the scoring platform, would this screw up the calibration due to being at an angle?

[dougwilliams]

Originally Posted by cjl2625

...if we were to place our robot half way on the scoring platform, would this screw up the calibration due to being at an angle?

Anecdote only (and based on the Nav6), we set up many competition matches with one set of wheels on the platform and one set on the floor when we turned on the robot. This seemed to have no impact at all on our yaw measurements.

[randantor]

We are also having issues with reading the NavX at times. We are using LabVIEW with the SPI bus. Sometimes the data is all 0 with the 'Data Valid' output false. In every case, restarting the robot code from the driver station gets it working again. Before, I had only seen it on our comepetition robot while connected to the FMS, and I thought it was related to the clock issue mentioned earlier, but yesterday it happened twice on the practice bot, which has a diffferent roborio and NavX board. I would say it happens about 1 in every 10-12 robot starts.

I haven't tried I2C or UART, but we may switch protocols for Lone Star and see what happens.

[marshall]

Originally Posted by randantor

We are also having issues with reading the NavX at times. We are using LabVIEW with the SPI bus. Sometimes the data is all 0 with the 'Data Valid' output false. In every case, restarting the robot code from the driver station gets it working again. Before, I had only seen it on our comepetition robot while connected to the FMS, and I thought it was related to the clock issue mentioned earlier, but yesterday it happened twice on the practice bot, which has a diffferent roborio and NavX board. I would say it happens about 1 in every 10-12 robot starts.

I haven't tried I2C or UART, but we may switch protocols for Lone Star and see what happens.

Check your battery voltage levels. This sounds like a brownout related issue. What version of the firmware are you running on the NavX?

[cjl2625]

Originally Posted by randantor

We are also having issues with reading the NavX at times. We are using LabVIEW with the SPI bus. Sometimes the data is all 0 with the 'Data Valid' output false. In every case, restarting the robot code from the driver station gets it working again. Before, I had only seen it on our comepetition robot while connected to the FMS, and I thought it was related to the clock issue mentioned earlier, but yesterday it happened twice on the practice bot, which has a diffferent roborio and NavX board. I would say it happens about 1 in every 10-12 robot starts.

I haven't tried I2C or UART, but we may switch protocols for Lone Star and see what happens.

This is precisely what happens for us.
I don't think it's a brownout issue, because it happens with a fresh battery upon booting up.

[Shahil_FRC]

Originally Posted by cjl2625

This is precisely what happens for us.
I don't think it's a brownout issue, because it happens with a fresh battery upon booting up.

This exact issue has happened to us as well, in autonomous mode with a fresh battery at the Waterbury District. We are running labview with the navx configured for SPI communications.

[marshall]

Originally Posted by Shahil_FRC

This exact issue has happened to us as well, in autonomous mode with a fresh battery at the Waterbury District. We are running labview with the navx configured for SPI communications.

Can you guys confirm firmware versions? We can look at testing this.

[cjl2625]

Is there a way to check what firmware version is being used?

[slibert]

Originally Posted by cjl2625

Is there a way to check what firmware version is being used?

A process for displaying the firmware version number is on this page; look under the "Connecting to the navX MXP" section.

[slibert]

Originally Posted by randantor

We are also having issues with reading the NavX at times. We are using LabVIEW with the SPI bus. Sometimes the data is all 0 with the 'Data Valid' output false. In every case, restarting the robot code from the driver station gets it working again. Before, I had only seen it on our comepetition robot while connected to the FMS, and I thought it was related to the clock issue mentioned earlier, but yesterday it happened twice on the practice bot, which has a diffferent roborio and NavX board. I would say it happens about 1 in every 10-12 robot starts.

I haven't tried I2C or UART, but we may switch protocols for Lone Star and see what happens.

In the case where the 'Data Valid" output is false, do you know if the "Opened" indicator is also false?

[slibert]

Originally Posted by dougwilliams

Scott and All,
I was wondering if there's a good layman's comparison of the nav features comparing the Nav6 vs the NavX?

...

What benefit is the NavX providing over the Nav6? Practically speaking for an FRC robot? Does the 9-axis benefit most users? Are there other nav features I may not be considering, or future products worth waiting for? We typically were just using yaw readings for FOD - but may expand that to some of the accel features in the off season and next year.

Thanks for the help -

The nav6 is fine for FOD (Field-Centric Drive), rotate to angle and "Straight Strafing". The navX MXP provides a simplified mounting solution, and integrated I/O Expansion.

The navX MXP also provides I2C/SPI interfaces and a USB interface - which are faster than the RS-232 interface of the nav6. But many teams use the serial interface successfully.

As you note, the navX MXP also provides 9-axis features, but these are not required for FOD; and indeed, they require more effort to calibrate and are sensitive to magnetic disturbances. The 9-axis heading does give an "absolute" heading, but the 6-axis yaw is simpler to use. There are certain applications where measuring the compass heading at the beginning of a match (before the motors are turned on) can allow the robot software to figure out where "zero degrees" on the field is at the beginning of a match, but it's an individual decision as to whether this is worth the effort to perform magnetometer calibration.

The navX MXP will be where future firmware development efforts are focused, since the navX MXP has a much more capable processor. Moving ahead, we plan to develop a features that only the navX MXP will have: (a) vertical mounting for the navX MXP, and (b) improving the navX MXP Linear Acceleration measures to be more useful for velocity/displacement calculations. Existing navX MXP customers will be able to upgrade to these at no charge w/a firmware upgrade.

[randantor]

Originally Posted by slibert

In the case where the 'Data Valid" output is false, do you know if the "Opened" indicator is also false?

I didn't check. I'll start logging that value for Lone Star. Chances are we'll see the issue happen at least once.

Originally Posted by marshall

Can you guys confirm firmware versions? We can look at testing this.

The tool reports firmware rev 1.0.482.