ANNOUNCING: navX MXP Robotics Navigation Sensor

[Thad House]

Originally Posted by slibert

You can definitely do this. In fact, it's very useful to do so, because you can use the navX MXP UI to view what's going on w/the navX MXP at the same time you can access it from the RoboRIO over the Serial Port / SPI or I2C.

The navX MXP has onboard circuitry to allow it to draw power from either the MXP or the USB. If both are connected, the navX MXP will draw power from the MXP port. I won't go into details here, but you can check out the schematics on the navX MXP wiki if you'd like.

The navX MXP has been tested w/both simultaneously connected, and the navX MXP microcontroller can keep up with both w/out impacting performance. In fact, the navX MXP can service all 4 interfaces (I2C/SPI/TTL UART/USB) simultaneously.

There's only one thing to be aware of. The navX MXP has a configurable update rate, which is global to all the interfaces. If that gets changed on one of the interfaces, the other interfaces will also see data at the new update rate. The navX MXP UI requests the maximum update rate (60 Hz) when it starts up. So, if your roborio code has configured a lower update rate on one of the other interfaces, it could change while using the navX MXP UI.

Hope you enjoy this feature, I think it's very useful.

Oh. I was hoping it would default to USB. That way we could bypass the RoboRIO brownout capability. We might have to find another way to do that, because I would not want the board rebooting.

One more thing, is there a way to make it so it does not autocalibrate. Looking through the docs, it seems like it calibrates when it sits still for 8 seconds, and then takes 8 seconds to do the calibration. What would happen if the robot was only stationary for 10 seconds then started moving again?

[slibert]

Originally Posted by Thad House

Oh. I was hoping it would default to USB. That way we could bypass the RoboRIO brownout capability. We might have to find another way to do that, because I would not want the board rebooting.

One more thing, is there a way to make it so it does not autocalibrate. Looking through the docs, it seems like it calibrates when it sits still for 8 seconds, and then takes 8 seconds to do the calibration. What would happen if the robot was only stationary for 10 seconds then started moving again?

These are some good questions.

***

If the MXP voltage falls below the USB voltage, then the USB voltage will be used to power the navX MXP - source switching is dynamic. The switch is triggered by a fast op-amp and managed by a MOSFET. Also, there's an onboard 100uF capacitor (downstream of the LDO voltage regulator) that will help provide stability during the source transition. I can say for sure that we've had both USB plugged-in while the navX MXP is in the MXP slot, and we've hot unplugged the navX MXP, and it didn't reset. Of course, you'll need to validate this under your particular test conditions.

***

Re: what happens if the robot was stationary for 10 seconds then started moving again:

There are two areas to discuss here: Gyro Calibration, and Initial Yaw Offset

- Gyro Calibration -

It depends whether the navX MXP is moving during startup gyro calibration, or afterwards.

If after gyro startup calibration, the navX MXP starts moving before the on-the-fly gyro calibration completes, then that calibration attempt is aborted, and thus the previous gyro calibration data continues to be used.

In the case where the navX MXP is moving during startup gyro calibration, the robot will fall back to the gyro calibration which is stored in flash memory. This calibration might work pretty well (if the temperature at which it was calibrated is similar to the current temperature). However, if the temperature at which the flash-stored calibration data is different that the current ambient temperature, then you will see drift that exceeds the standard (until on-the-fly gyro calibration next occurs).

Due to this, we recommend that before a day's matches the navX MXP gyro is recalibrated in the pits (or on the field). This is described in the gyro/accel calibration page. Basically, hold down the "CAL" button for 10 seconds, then reset the navX MXP. Then, hold the navX MXP still (and horizontal) while it recalibrates the gyro biases. During this period, the "CAL" button will slow flash; when complete, the newly-calibrated gyro biases are stored to flash memory. The effect will be to minimize the temperature difference between when navX MXP was calibrated and when it's used.

- Initial Yaw Offset -

This is the mechanism that ensures the yaw angle is at 0.0 after startup. Now, in the case of motion during startup gyro calibration, there is one issue here that might cause trouble. Specifically, the initial yaw offset calculation (see the calibration page for description). Here's the scenario: if the navX MXP were moving during the startup calibration, and then later on finally did sit still long enough for gyro re-calibration, at that time the yaw offset would be calculated, and from that point on, the offset would be subtracted from subsequent yaw readings - resulting in a discontinuity.

The yaw offset is communicated to the roborio, so the robot application could add it back in, if one wanted. And there's also support in the roborio-side libraries for manually re-zeroing the yaw, something a driver could trigger.

But it seems reasonable to consider this enhancement: a way to configure the navX MXP to not calculate an initial yaw offset if it can't complete startup calibration within, say, 20 seconds. This removes the chance of a discontinuity. Please consider that and let me know your thoughts, if it makes sense I'd be happy to look into it.

[marshall]

Originally Posted by Thad House

Oh. I was hoping it would default to USB. That way we could bypass the RoboRIO brownout capability. We might have to find another way to do that, because I would not want the board rebooting.

One more thing, is there a way to make it so it does not autocalibrate. Looking through the docs, it seems like it calibrates when it sits still for 8 seconds, and then takes 8 seconds to do the calibration. What would happen if the robot was only stationary for 10 seconds then started moving again?

I know one of the things that James tested with the LabView library was what would happen if the board reset for any reason. Basically, it comes back up within about 4-5 seconds... probably even less time. It's fairly quick and then it just starts spitting out readings again.

[slibert]

Originally Posted by marshall

I know one of the things that James tested with the LabView library was what would happen if the board reset for any reason. Basically, it comes back up within about 4-5 seconds... probably even less time. It's fairly quick and then it just starts spitting out readings again.

The navX MXP Gyro/Accelerometer Calibration page has been updated to clarify how this works, including a diagram that points out the key details of this process.

[Pault]

I may just be missing something, but I cant seem to find roboRIO code for the nav6/navX. The svn/trunk/roborio/jav/navx-mxp/src/com/kauailabs/navx_mxp directory on the repo is empty.

[slibert]

Originally Posted by Pault

I may just be missing something, but I cant seem to find roboRIO code for the nav6/navX. The svn/trunk/roborio/jav/navx-mxp/src/com/kauailabs/navx_mxp directory on the repo is empty.

The source code you are looking for is in the subdirectories underneath the /svn/trunk/roborio/java/navXMXPSimpleRobotExample directory.

What used to be in the navx-mxp directory is now integrated into the sample code that it's in the navXMXPSimpleRobotExample directory structure. We decided that was easier to use than making the navx mxp code into a separate java library. We'll get the now-defunct directory removed soon.

[Pault]

Originally Posted by slibert

The source code you are looking for is in the subdirectories underneath the /svn/trunk/roborio/java/navXMXPSimpleRobotExample directory.

What used to be in the navx-mxp directory is now integrated into the sample code that it's in the navXMXPSimpleRobotExample directory structure. We decided that was easier to use than making the navx mxp code into a separate java library. We'll get the now-defunct directory removed soon.

Is it IMU.java (and all of the associated classes), or is that only for the nav6?

[slibert]

Originally Posted by Pault

Is it IMU.java (and all of the associated classes), or is that only for the nav6?

IMU.java and IMUAdvanced.java work with both the navX MXP and the nav6.

We're working on a AHRS.java class which provides roborio-side access to the 9-axis heading and magnetic disturbance detection (this will be navX MXP specific since nav6 doesn't support 9-axis headings/magnetic disturbance detection), but that's likely a few weeks away from release. We'll send out a notification when AHRS.java is ready. But for what most teams need now (field-oriented drive), IMU.java will work. IMUAdvanced.java will work too, and it adds gravity-corrected linear acceleration data that can be used for motion detection, velocity estimation, etc.

[jSoft]

Hey everyone. We just got our navX MXP board, and we're trying to get it to work with labview. When we brought the open serial function into our labview project (after importing the library) we received the following errors:

http://gyazo.com/b8127479ff8b5b9509d583ea57bd775e

Does anyone here know how to fix this? Thanks!

[Tom Line]

Originally Posted by jSoft

Hey everyone. We just got our navX MXP board, and we're trying to get it to work with labview. When we brought the open serial function into our labview project (after importing the library) we received the following errors:

http://gyazo.com/b8127479ff8b5b9509d583ea57bd775e

Does anyone here know how to fix this? Thanks!

Double clicking the error will take you to the VI. Click the run arrow in the VI to see the errors, then see if they are easy to correct.

[cjl2625]

I saw the same error, it was easy to correct. If you dig down to where the error is, there's a case structure with an extra case that seems like it shouldn't be there (shown in red text).
I maybe it should be there, but when I deleted that case, it was executable again.

[Caboose]

We are currently looking in to the error.

Edit: Also you should be using SPI or I2C.

Edit 2:
Here is a link to the LabVIEW library: https://github.com/FRC900/navX-MXP-LabVIEW. Remember for support on the navX board please go to https://code.google.com/p/navx-mxp/.

[AustinH]

Hi, thanks for the help. We got it sorted and fully integrated into our drive code. Needless to say, when the field oriented drive mode started working, the room erupted in cheers. This board is an absolutely awesome IMU.

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

Edit: it appears that the modulo conversion is performed on board the navX, so there's no way to tweak the LabVIEW library to get the "true" total rotation. Even in looking at the navX source, it looks like the modulo conversion might be getting performed by the Invensense libraries.

Edit2: it also appears that the on-the-fly recalibration does some "interesting" things to the rollover point of the output. That's going to surprise some folks, I think. We too will be looking for ways to disable that feature, if that is indeed the cause of the behavior we are seeing.

[slibert]

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.

Edit: it appears that the modulo conversion is performed on board the navX, so there's no way to tweak the LabVIEW library to get the "true" total rotation. Even in looking at the navX source, it looks like the modulo conversion might be getting performed by the Invensense libraries.

Edit2: it also appears that the on-the-fly recalibration does some "interesting" things to the rollover point of the output. That's going to surprise some folks, I think. We too will be looking for ways to disable that feature, if that is indeed the cause of the behavior we are seeing.

For total rotation, I'd like to suggest two ways to approach this. Both of these approaches bypass the code (which is in the navX MXP firmware) that manage the yaw. As you suggest, the yaw angle rollover and offset calculations - which are designed for the Field-Oriented Drive / Rotate-to-Angle application and focus on "what angle are we currently pointing" and "ensure when starting our initial yaw angle is zero" - discard some information you're likely interested in.

For total rotation, the LabView library from team 900 enables access to the quaternion data. This data is the 6-axis fusion of gyro/accelerometer calculated on board the Invensense chip (I like to think of the Invensense's digital motion processor as a "quaternion engine"). From this, you can calculate a current Z-axis (yaw) angle [it's a reasonably straightforward transform] and then integrate that over time to yield the total rotation. This completely bypasses any yaw angle rollover and the yaw offset calculations. You can get this data over any of the interfaces. The SPI and I2C interfaces are very fast and since the gyro/accel integration occurs on the navX MXP, you don't have to worry about "missing" any data - in fact you could read this quaternion data at a pretty slow rate if you preferred.

The second approach is to access the raw gyro data. This is in device units so you'd have to transform it to deg/sec, then integrate it. This approach is conceptually simple, but introduces the requirement that the roborio code acquire each and every sample. With I2C/SPI (this is supported in the LabView Library), you'd have to sample more rapidly than the navX MXP's internal update rate, and compare the timestamp of each sample to detect duplicate data samples. This is where the Serial interface may be preferable, as you'll get an update message whenever the Invensense chip has new data. There are two "advanced" mode messages, one that provides a "Quaternion Data Update" and another providing a "Gyro Data Update". In this case, the "Gyro Data Update" is the one you want. Currently, the Serial protocol support in the LabView Library does not include this "Gyro Data Update" message.

Note that the quaternions and raw gyro data are subject to calibrated biases to account for manufacturing differences and temperature shifts, this part is completely managed by the Invensense chip's digital motion processor. This calibration is a separate layer from the yaw offset calculations, though, and should not obscure attempts to calculate total rotation.

So in summary, please consider using the first method based on Quaternions, I believe it'll provide you what you're looking for. I'm happy to provide more info on navX MXP internals and the quaternion->yaw angle transform, so please feel free to private message me if you have any more questions.