ANNOUNCING: navX MXP Robotics Navigation Sensor

[slibert]

Press Release - January 2, 2015
KauaiLabs, Inc. announces the navX MXP Robotics Navigation Sensor
• 9-Axis Sensor (Gyro / Accelerometer / Magnetometer)
• Intelligent Motion Processor
• RoboRIO Expansion I/O

Supercharge your robot: Field-oriented drive, auto-balancing, collision detection, motion detection, auto-rotate-to-angle, and more…

Expand your RoboRIO: 10 Digital I/Os (GPIO / PWM / Quad Encoders), 4 Analog Inputs, 2 Analog Outputs, and TTL UART / I2C / SPI ports.

Plug-n-Play: easily installed via RoboRIO’s MXP Expansion connector or USB port.

Open Source: firmware source code, board schematics/layout & bill of materials available online.

Easy-to-integrate: C++, Java and LabView libraries and sample application code simplify integration.

Backwards-compatible: existing nav6 users can upgrade easily.

********

In late 2013, Kauailabs (http://www.kauailabs.com) released the nav6 Open Source Inertial Measurement Unit (https://code.google.com/p/nav6), providing high-accuracy measures of pose (yaw/pitch/roll), with minimal yaw drift of ~1 degree per minute - performance far exceeding the analog gyro included in the FRC Kit of Parts. nav6 was used by several teams at the 2014 FIRST Championships for features including field-oriented drive.

Now, Kauailabs announces the navX MXP Robotics Navigation Sensor, which takes nav6 technology to the next level in two significant ways.

First, navX MXP was designed to use the RoboRIO MXP Expansion Connector - enabling plug-n-play installation on the National Instruments RoboRIO, and adding digital, analog I/O and UART / SPI / I2C port expansion.

Second, navX MXP features a 32-bit ARM processor, the new Invensense MPU-9250 (http://www.invensense.com/mems/gyro/mpu9250.html) sensor system-on-chip, and software algorithms which take nav6 technology to the next level, including enhanced sensor calibration and algorithms which fuse gyro, accelerometer and magnetometer data into a “9-axis heading”. The “9-axis heading” is enabled by magnetometer calibration tools (available online at no cost) and magnetometer disturbance detection and data fusion algorithms. This capability is known within the aerospace industry as an “Attitude/Heading Reference System” (AHRS) (http://en.wikipedia.org/wiki/Attitude_and_heading_reference_system). Kauailabs brings this high-tech AHRS capability to FIRST FRC teams - to use, learn and explore. navX MXP is a key component of Kauailabs’ ongoing efforts to make state-of-the-art navigation technologies used in autonomous vehicles (e.g., the Google Car) available to robotics students and enthusiasts as low-cost, open-source products.

navX MXP will be available for puchase online a few days after the 2015 FIRST FRC build season kickoff at AndyMark (http://www.andymark.com) and Kauailabs (http://www.kauailabs.com/store). MSRP is $99.

More details available in the navX MXP datasheet (http://kauailabs.com/wp-content/uploads/2014/12/navX_MXP_Datasheet.pdf) and at https://code.google.com/p/navx.

http://www.kauailabs.com/store/image/data/navx_Banner_better_robots_right_justified_width600 .png

[mman1506]

Looks great! I really love the MXP breakout too, no screw terminals or PCB breadboards just an extension of what's on the RoboRIO itself.

[Amar Shah]

This looks really cool. I wonder if I can convince my team to buy one.

[Conor Ryan]

This is the coolest Control System Add On ever. You can do so much with it, all without the danger of overloading the main CPU.

Looking in the Wiki here are the list of examples:

Field-oriented Drive (https://code.google.com/p/navx-mxp/wiki/FieldOrientedDrive)
Automatic Balancing (https://code.google.com/p/navx-mxp/wiki/AutoBalancingExample)
Rotating to a given Angle (https://code.google.com/p/navx-mxp/wiki/RotateToAngleExample)
Motion/No-Motion Detection (https://code.google.com/p/navx-mxp/wiki/MotionDetection)That is pretty impressive, I can't wait to see what some teams can do with this.


Any videos of it in action?

[slibert]

This is the coolest Control System Add On ever. You can do so much with it, all without the danger of overloading the main CPU.

Looking in the Wiki here are the list of examples:

Field-oriented Drive (https://code.google.com/p/navx-mxp/wiki/FieldOrientedDrive)
Automatic Balancing (https://code.google.com/p/navx-mxp/wiki/AutoBalancingExample)
Rotating to a given Angle (https://code.google.com/p/navx-mxp/wiki/RotateToAngleExample)
Motion/No-Motion Detection (https://code.google.com/p/navx-mxp/wiki/MotionDetection)That is pretty impressive, I can't wait to see what some teams can do with this.


Any videos of it in action?

Here's a video recently posted by the lead technical mentor of team 246, showing how they used the nav6 to implement field oriented drive. The navX is based on the same technology:

http://www.chiefdelphi.com/forums/showthread.php?t=131704&highlight=nav6

It's mentioned at about 5:30 and 10:30 into the video referenced in this post.

[Mr. Lim]

Just put in our order for one.

Team is excited to have a proper IMU on our robot this year!

Thanks, and good luck with the product!

[SpeedFreed]

I spent the large portion of my summer working with the Nav6 by Kauai Labs, and it was, by far, the easiest (and most accurate) gyro I had ever worked with. Ever. I never got around to using the other degrees (pitch, roll, linear acceleration), but it was worth it alone for just the yaw measurement, and it's easy integration into FOD. But that was just an offseason project, who knows what else tomorrow's challenge might allow us to do with it?

Needless to say, I already ordered one of the navXs, and you can be sure it will be on our robot next year.

[craigboez]

Because this is an "active" roboRIO expansion module, my understanding is that it needs explicit FRC approval before you can use it on your robot. Does the navX have this approval?

[Joe Ross]

Because this is an "active" roboRIO expansion module, my understanding is that it needs explicit FRC approval before you can use it on your robot.

It only needs approval if you plug in a motor controller or servo to it.

[craigboez]

It only needs approval if you plug in a motor controller or servo to it.

Thanks Joe. That would explain the lack of PWM outputs.

[slibert]

Thanks Joe. That would explain the lack of PWM outputs.

The navX does support PWM/Quad Encoders as well as standard GPIO. These pins are direct pass-throughs from the MXP Connector, so whatever RoboRIO drives out those pins is routed to the navx MXP Digital I/O connectors.

Any announcement regarding legality as an active device can only come from FIRST, who has indicated that all approved devices will be listed in this year's game manual, to be released tomorrow.

[craigboez]

Are there any restrictions or recommendations on how to mount the roboRIO? Is vertical ok?

[Oblarg]

This looks like it could be very useful - I know 449 has been wanting to do gyro integration for a long time but has not made much progress. This looks to be basically plug-and-play, and should allow field-oriented control to a lot of teams that couldn't before.

[Greg Needel]

Are there any restrictions or recommendations on how to mount the roboRIO? Is vertical ok?

I can't speak for the orientation requirements of this board, but you could always use a cable to relocated it off of the roborio.

http://www.andymark.com/product-p/am-2997.htm

[Ben Wolsieffer]

I can't speak for the orientation requirements of this board, but you could always use a cable to relocated it off of the roborio.

http://www.andymark.com/product-p/am-2997.htm

It also looks like it can be connected over USB, which would make it even easier to mount it away from the roboRIO.

[slibert]

Are there any restrictions or recommendations on how to mount the roboRIO? Is vertical ok?

I'd definitely recommend horizontal alignment with the chassis.

We've put a decent bit of thought, though, into alternate mounting strategies.

Please take a look at the following wiki page and hopefully it provides enough detail regarding these alternate solutions:

https://code.google.com/p/navx-mxp/wiki/AdvancedInstallOptions

You might want to consider the "One-wire connect via Floppy-disk Extension Cable" option and the "One-wire connect via USB Cable" options.

We were able to order some of the "Floppy-disk Extension Cables" on Ebay, and another poster just indicated that AndyMark is carrying them, as well.

[JesseK]

2 questions:
How much testing has this board undergone with the RoboRIO, outside of a Great like Joe Johnson?
The website shows 11 available. Is that true? Seems a bit low.

[JB987]

Our alpha and beta testing of the rRIO included vertical mounting and we had no problems with it's orientation.

[Ben Wolsieffer]

Our alpha and beta testing of the rRIO included vertical mounting and we had no problems with it's orientation.

Are you talking about the navX, or simply the roboRIO by itself.

[slibert]

2 questions:
How much testing has this board undergone with the RoboRIO, outside of a Great like Joe Johnson?
The website shows 11 available. Is that true? Seems a bit low.

First, regarding the availability. As you noted, Kauai Labs has 11 remaining, but AndyMark will initially have 100 units for sale, I expect within a week or so.

As to the Roborio Testing: Like many others, Kauai Labs has been hampered because the RoboRIO firmware has not been made available to non-beta teams. So internally we do our firmware validation by running functional and stress-test code on Arduinos (connected to MXP connector) and PCs over USB. And electrical validation was performed on a new RoboRIO.

As to the Roborio-side libraries, one extremely helpful beta team tester got the nav6 working on the RoboRio in both LabView and Java, with small modifications to the libraries on the CRio. This proves out the WPI Library Serial Port support, as well as the Kauai Labs Serial Port-based nav6 libraries for Java and Labview. Since the navX MXP is backwards compatible w/the nav6, this means the navX MXP will work on the RoboRio.

As soon as the RoboRio firmware and WPI libraries are released (Jan. 3, 2015), Kauai Labs will be working overtime to first get the RoboRio libraries fully tested w/the navX MXP on LabView, Java and C++ platforms. Based on the work by the beta tester, and the maturity of the nav6 libraries, this should proceed quickly. Once that's solid, we'll next work to add extensions to the Serial Port-based Roborio-side libraries, which will make the new navX features (9-axis heading and Magnetic Disturbance Detection) accessible, too.

We're also finishing up documentation on the I2C/SPI protocols - should be posted on the wiki any day now - and after the Serial Port-based libraries are completed, we'll be creating some Roborio-side libraries for accessing navX MXP via these protocols too.

Given the constraints, that's the best strategy we could come up with - but we're open to input as to priorities as we make navx MXP available to FIRST teams.

[slibert]

It also looks like it can be connected over USB, which would make it even easier to mount it away from the roboRIO.

Connection over USB is definitely doable; but do note that the navX MXP RoboRIO I/O expansion capability is only accessible when navX MXP is connected via the MXP connector.

One interesting side note is that navX MXP can be connected *simultaneously* by both MXP connector AND USB. So you can access the navX MXP over the MXP Connector from your robot software and simultaneously monitor the navX MXP over the USB connector. There's a PC-based application called the navXMXPUI, more info on the Wiki (https://code.google.com/p/navx-mxp/wiki/navXMXPUI).

The navXMXPUI is really helpful to understand the full breadth of what the navX MXP can do, and should also help debug as you integrate the navX MXP into your robot.

[PeterBrock]

Press Release - January 2, 2015
KauaiLabs, Inc. announces the navX MXP Robotics Navigation Sensor

The “9-axis heading” is enabled by magnetometer calibration tools (available online at no cost) and magnetometer disturbance detection and data fusion algorithms. This capability is known within the aerospace industry as an “Attitude/Heading Reference System” (AHRS) (http://en.wikipedia.org/wiki/Attitude_and_heading_reference_system). Kauailabs brings this high-tech AHRS capability to FIRST FRC teams - to use, learn and explore. navX MXP is a key component of Kauailabs’ ongoing efforts to make state-of-the-art navigation technologies used in autonomous vehicles (e.g., the Google Car) available to robotics students and enthusiasts as low-cost, open-source products.



The AHRS capability is very useful for field oriented driving.

Have you tried using the navX (or the nav6) for pose information? It would be useful to track robot position during the match.

[sanddrag]

Is it expected that more than 100 will be available? If you run out of stock, what's your lead time to get more up for sale?

[slibert]

Is it expected that more than 100 will be available? If you run out of stock, what's your lead time to get more up for sale?

Lead time is 5 weeks. We will be deciding soon when to send out the next order, based on initial sales velocity.

[slibert]

The AHRS capability is very useful for field oriented driving.

Have you tried using the navX (or the nav6) for pose information? It would be useful to track robot position during the match.

If you mean using gravity-corrected linear acceleration to estimate current x,y position, the classic response is that double-integration of acceleration to derive first motion vectors and then a track from 0,0 would work for a short period of time but errors would grow quickly. We haven't tried this, but I think determining the error rate would be a very good idea.

I'm of the opinion that navX MXP plus scanning LIDAR is an elegant approach for localization. And low cost products like the LIDAR Lite are emerging that make it affordable for FRC teams to have long-range time-of-flight ranging. Based on that thinking, fusing a IR LED-based scanning LIDAR with navX MXP's heading and linear acceleration measures is the direction we're heading.

[slibert]

Because this is an "active" roboRIO expansion module, my understanding is that it needs explicit FRC approval before you can use it on your robot. Does the navX have this approval?

Please see rule R58 of the 2015 FRC Game Manual, which indicates that the Kauai Labs navX MXP is approved as an "Active Device".

[Dunngeon]

Lead time is 5 weeks. We will be deciding soon when to send out the next order, based on initial sales velocity.

Looks like you had that initial sales velocity. To those on CD, what is a good alternative to this IMU? If any.

[slibert]

Looks like you had that initial sales velocity. To those on CD, what is a good alternative to this IMU? If any.

Here's the link to the navX MXP on Andymark's website. They'll have 100 units in about a week. We are recommending people click on the "Email when available" link to be notified when they can be purchased.

http://www.andymark.com/product-p/am-3060.htm

[slibert]

Looks like you had that initial sales velocity. To those on CD, what is a good alternative to this IMU? If any.

As to alternatives, you might consider the nav6. It's software compatible with the NavX MXP. We have some remaining stock at http://www.kauailabs.com/store. The nav6 yaw accuracy is very similar to the NavX MXP, though the NavX MXP adds roborio expansion I/O, 9-axis headings and magnetic disturbance detection.

[Dunngeon]

Here's the link to the navX MXP on Andymark's website. They'll have 100 units in about a week. We are recommending people click on the "Email when available" link to be notified when they can be purchased.

http://www.andymark.com/product-p/am-3060.htm

Oh, so they haven't sold yet. Thanks for the info!

[cjl2625]

I'm trying to get the navX set up for some basic tests.
I plugged it into the roborio, then opened up the roborio example labview project.
I replaced the ip to roboRIO-2067.local and deployed the code (which succeeds), but I can't get any readings out of it..
It just throws a bunch of errors, starting with the serial block.

Am I doing something wrong here?

[Joe Ross]

I plugged it into the roborio, then opened up the roborio example labview project.

Are you using the Nav6 project? If so, you need to add the serial port parameter to the serial open to use the MXP serial port, as it defaults to the onboard RS232 serial port. I believe there's a better library coming soon.

[slibert]

Are you using the Nav6 project? If so, you need to add the serial port parameter to the serial open to use the MXP serial port, as it defaults to the onboard RS232 serial port. I believe there's a better library coming soon.

As an example of what Joe's referring to, please see the attached image.

https://navx-mxp.googlecode.com/svn/trunk/images/labview_serial_port_selection.png

[slibert]

A good LabView library just got better.

Last year, the original LabView nav6 Serial Port-based libraries were created for the FIRST community by Joe Ross from Team 330 (Beachbots). Now, thanks to the efforts of James Parks from Team 900 (Zebracorns), these libraries have been enhanced to add SPI support and expose some navX MXP and RoboRio-specific features. Following the open-source tradition, these enhancements have generously been made available for all to use. The latest build of this LabView library, which now supports both Serial and SPI interfaces, is now available at https://code.google.com/p/navx.

The SPI Library features lower-latency communication and also lower RoboRio CPU bandwidth utilization. At the default update rate (60Hz), the Serial libraries were measured at 17% CPU utilization, whereas the SPI library was measured at 11% CPU utilization.

Note that the navX MXP also supports I2C communication, and an I2C version of the LabView library is planned; we'll send out an update on this thread when this work is completed.

Thanks to the ChiefDelphi community for continuing to support this open-source project.

[slibert]

navx MXP units have arrived at AndyMark and are now available for sale at the AndyMark online store (http://www.andymark.com/product-p/am-3060.htm).

[Dunngeon]

Just bought two, pretty excited about these.

[marshall]

For anyone using LabView with these... we are monitoring this thread along with Scott so we can help if you run into issues. Just let us know. I know James has been happy to contribute and is working on updates to the library in short order. :)

[cjl2625]

I tried running the SPI labview example tonight.
Seemed to give a nice yaw reading, although the raw magnetometer values were (0, 0, 0), and the MAG_DISTURBANCE light was on.

[marshall]

I tried running the SPI labview example tonight.
Seemed to give a nice yaw reading, although the raw magnetometer values were (0, 0, 0), and the MAG_DISTURBANCE light was on.

Have you calibrated the magnetometer?

[cjl2625]

Have you calibrated the magnetometer?

Oh, nope. I just ran whatever was in the SPI example.
I found the wiki, I'll take at the documentation in there.

[slibert]

Update: in addition to the SPI Labview Library released a few days ago, the Zebracorns have updated navX MXP Labview libraries to include support for the navX MXP's I2C interface. This updated library is now available at the navX MXP online website (https://code.google.com/p/navx).

Like the SPI interface, the I2C interface offers lower latency and lower CPU usage than the navX MXP serial libraries.

Thanks again to the Zebracorns for this contribution to the Chief Delphi community.

[pschu5]

I missed the restock on AndyMark last night, I thought they were going to restock on Friday but I guess they must have got them earlier. Any word on when they will restock?

[slibert]

I missed the restock on AndyMark last night, I thought they were going to restock on Friday but I guess they must have got them earlier. Any word on when they will restock?

AndyMark has indicated that all of their units sold out yesterday, which is the same day they became available. More units are being manufactured, and are expected to arrive at AndyMark in early February.

There still are some remaining nav6 units on sale at www.kauailabs.com/store. While I realize this isn't an ideal situation, the navx MXP is backwards compatible with the nav6 serial protocols, so should you choose to use the nav6 now, an eventual upgrade to the navX MXP should be pretty straightforward.

[Thad House]

So for the NavX, would it be a problem to both hook up to the USB port, and hook up to the MXP port?. Where would the processor draw power from, and would this cause any issues with anything else?

[slibert]

So for the NavX, would it be a problem to both hook up to the USB port, and hook up to the MXP port?. Where would the processor draw power from, and would this cause any issues with anything else?

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.

[Thad House]

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]

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]

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]

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 (https://code.google.com/p/navx-mxp/wiki/GyroAccelCalibration) 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]

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]

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]

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]

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]

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 (https://code.google.com/p/navx-mxp/wiki/SerialProtocolAdvanced), 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.

[ayeckley]

Thanks for the response. It's going to take us a while to digest that. Doing our own integration in real time does not seem like an attractive option, at least at first blush.

[slibert]

Thanks for the response. It's going to take us a while to digest that. Doing our own integration in real time does not seem like an attractive option, at least at first blush.

I may not understand why "total rotation" is needed - however my intuition is that transforming the quaternion to yaw angle is all you need. Quaternions were developed to avoid gimbal lock and can easily yield a yaw angle that is 0 to 360 rather than -180 to 180; my thinking is this completely eliminates the need for a total rotation value.

The code to do this is pretty trivial:

float q[4], yaw_radians, yaw_degrees;

// Convert navX Quaternions to a +/- 2 pi radians range
q[0] = ((float)quat_w) / 16384.0f;
q[1] = ((float)quat_x) / 16384.0f;
q[2] = ((float)quat_y) / 16384.0f;
q[3] = ((float)quat_z) / 16384.0f;

// Range-check quaternion values
for (int i = 0; i < 4; i++) if (q[i] >= 2) q[i] = -4 + q[i];

// calculate yaw angle (0-360 degrees)
yaw_radians = atan2(2*q[1]*q[2] - 2*q[0]*q[3], 2*q[0]*q[0] + 2*q[1]*q[1] - 1);
yaw_degrees = yaw_radians * (180.0/3.1415926);

[dellagd]

2607 is very excited to get working with their board when it arrives this coming week!

Question though: Given the high accuracy of the device, has anyone attempted to do distance estimation from a double integration of the accelerometer data? I'm curious how it would perform, even for small distances.

[Gdeaver]

Got ours on Friday and gave it to the programers on Sunday. They're happy with the initial testing. We have the same question on distance. Will have to test. Short distance and short period of time.

[AustinH]

2607 is very excited to get working with their board when it arrives this coming week!

Question though: Given the high accuracy of the device, has anyone attempted to do distance estimation from a double integration of the accelerometer data? I'm curious how it would perform, even for small distances.

If you guys do come up with any theories on how to do that, we would be very, very interested to help with testing...

[Trevor4004]

My team recently received our navX board and we are very excited about the possibilities it will give us. However, the power LED on the RoboRio turns a solid red when we plug it directly into the MXP area of the RoboRio as described in the Plug-n-Play section of the navx-mxp wiki (https://code.google.com/p/navx-mxp/wiki/RoboRioInstall). The RoboRio User Manual says that a solid red for the power LED means "Fault condition detected. One or more user voltage rails are in short-circuit or overcurrent condition."

Our first thought was that the short-circuit or overcurrent problems were due to some strange interaction between the naxv board connecting to the RoboRio via MXP and our daisy chain going from the RoboRio to the PDP and containing 4 talon srxs and the PCM. But this doesn't seem to make a lot of sense considering this board is supposed to be designed to work with the RoboRio for FRC and a daisy chain of 4 talons and the PCM seems like a common setup in FRC.

We can still connect to the robot with out driver station, and we get full communication and robot code when we do. We are able to drive the robot around normally, but we are worried about trying to test the navx in our code until we can determine why the RoboRio is detecting a short-circuit or overcurrent condition. Any insight into why the RoboRio is detecting these problems would be greatly appreciated. Thank you.

[AustinH]

My team recently received our navX board and we are very excited about the possibilities it will give us. However, the power LED on the RoboRio turns a solid red when we plug it directly into the MXP area of the RoboRio as described in the Plug-n-Play section of the navx-mxp wiki (https://code.google.com/p/navx-mxp/wiki/RoboRioInstall). The RoboRio User Manual says that a solid red for the power LED means "Fault condition detected. One or more user voltage rails are in short-circuit or overcurrent condition."

Our first thought was that the short-circuit or overcurrent problems were due to some strange interaction between the naxv board connecting to the RoboRio via MXP and our daisy chain going from the RoboRio to the PDP and containing 4 talon srxs and the PCM. But this doesn't seem to make a lot of sense considering this board is supposed to be designed to work with the RoboRio for FRC and a daisy chain of 4 talons and the PCM seems like a common setup in FRC.

We can still connect to the robot with out driver station, and we get full communication and robot code when we do. We are able to drive the robot around normally, but we are worried about trying to test the navx in our code until we can determine why the RoboRio is detecting a short-circuit or overcurrent condition. Any insight into why the RoboRio is detecting these problems would be greatly appreciated. Thank you.


Have you considered plugging it in via the onboard I2C/SPI ports instead of the MXP? IIRC, we're going to be attempting that due to the less than ideal mounting location of our RoboRio. You'd have to supply the board with its own power, but it could be useful for troubleshooting purposes.

[slibert]

Have you considered plugging it in via the onboard I2C/SPI ports instead of the MXP? IIRC, we're going to be attempting that due to the less than ideal mounting location of our RoboRio. You'd have to supply the board with its own power, but it could be useful for troubleshooting purposes.

AustinH, you could also consider using a MXP extension cable (http://www.andymark.com/product-p/am-2997.htm). This would allow you to continue to use the expansion ports on the navX MXP - which you won't be able to do if not connected to the MXP connector. There's more info on alternative mounting options here (https://code.google.com/p/navx-mxp/wiki/AdvancedInstallOptions).

[slibert]

My team recently received our navX board and we are very excited about the possibilities it will give us. However, the power LED on the RoboRio turns a solid red when we plug it directly into the MXP area of the RoboRio as described in the Plug-n-Play section of the navx-mxp wiki (https://code.google.com/p/navx-mxp/wiki/RoboRioInstall). The RoboRio User Manual says that a solid red for the power LED means "Fault condition detected. One or more user voltage rails are in short-circuit or overcurrent condition."

Our first thought was that the short-circuit or overcurrent problems were due to some strange interaction between the naxv board connecting to the RoboRio via MXP and our daisy chain going from the RoboRio to the PDP and containing 4 talon srxs and the PCM. But this doesn't seem to make a lot of sense considering this board is supposed to be designed to work with the RoboRio for FRC and a daisy chain of 4 talons and the PCM seems like a common setup in FRC.

We can still connect to the robot with out driver station, and we get full communication and robot code when we do. We are able to drive the robot around normally, but we are worried about trying to test the navx in our code until we can determine why the RoboRio is detecting a short-circuit or overcurrent condition. Any insight into why the RoboRio is detecting these problems would be greatly appreciated. Thank you.

This sounds like a short between one of the power (or potentially signal, if active) pins and one of the ground pins on the navX MXP's MXP Expansion connectors. This could be any of the DigitalI/O\PWM\QuadEncoder, Analog In, Analog Out, I2C, SPI or TTL UART connectors. In this case, the navX MXP's RED Power LEDs, and green S1/S2 LEDs will be all off - the navX MXP isn't getting any power from the RoboRIO in this case, because the RoboRIO is protecting itself from a short. The RoboRIO appears well-designed to deal w/this case.

Note that the RoboRIO can be powered via USB, in which case the navX MXP's sensors and microcontroller will work, even if there's a short on the MXP Expansion voltage rail. But in this case, the voltage on the navX MXP expansion connectors will be unavailable, so you won't be able to communicate w/the RoboRIO from the navX MXP via the TTL UART / I2C or SPI interfaces - and you won't be able to use the navX MXP expansion connectors. You'll be limited to using USB unless the source of the short is found and corrected.

So work on finding any shorts, I believe this is the source of the issue you are seeing.

[Tom Line]

Is it possible to download the nav6 files with a single click?

As far as I can see, the locations linked from the product webpages are SVN repositories, and most teams haven't ever used one (including us). Just looking at how to set up a SVN GUI client to get those files is fairly overwhelming, and clicking through each link individually to download the raw file is a royal pain.

If I'm missing some easy way to download these files, let me know. Goodness knows it wouldn't be the first time.

[Joe Ross]

If I'm missing some easy way to download these files, let me know. Goodness knows it wouldn't be the first time.

From the nav6 or navX main page, click the latest build link.

[Tom Line]

Thanks Joe. I read through the main page 3 times and never looked in the left pane =/.

[bmammen]

We started playing with the example code tonight, trying to use the navX to Auto-Rotate to an angle but we're having an issue where no matter what values we use for PID, the bot rotates to the angle and constantly shakes back and forth trying to reach the exact angle.

I can post our code if that helps, we're using C++ and have a 4 motor/4 transmission tank drive configuration on our test chassis. Hoping someone might have some ideas for us. Thx.

[cjl2625]

We started playing with the example code tonight, trying to use the navX to Auto-Rotate to an angle but we're having an issue where no matter what values we use for PID, the bot rotates to the angle and constantly shakes back and forth trying to reach the exact angle.

I can post our code if that helps, we're using C++ and have a 4 motor/4 transmission tank drive configuration on our test chassis. Hoping someone might have some ideas for us. Thx.

I once had a similar problem with rotating swerve modules with PID.
The problem ended up being that the loop time was really long, like 300 ms.
Since it took so long to update, it repeatedly overshot the target and shook back and forth.
In my case, it turned out that this was being caused by an error, because I didn't configure something correctly in the drive encoders. So the code seemed to be quietly throwing errors which drastically slowed down the iteration time.

[jojoguy10]

Not sure about anyone else, but the NavXMXPUI program isn't working for our team. When I try to run the .bat file, it says it can't find a file.

Is there a KNOWN working version somewhere?

Thanks!

[slibert]

Not sure about anyone else, but the NavXMXPUI program isn't working for our team. When I try to run the .bat file, it says it can't find a file.

Is there a KNOWN working version somewhere?

Thanks!

The navXMXPUI 64 bit windows version is known working, tested on Windows 7 64-bit. Please post details on the error message you are seeing. Note that Java is required to be installed, too.

[jojoguy10]

I'm using 64-bit Windows 8.1 (that might be the issue?)

Here is the command prompt window text
Catched FileNotFoundException: C:\Users\Joe\Desktop\navx-utilities\navXMXPUI\app
lication.windows64\lib\gluegen-rt-natives-windows-i586.jar (The system cannot fi
nd the file specified), while addNativeJarLibsImpl(classFromJavaJar class com.jo
gamp.common.os.Platform, classJarURI jar:file:/C:/Users/Joe/Desktop/navx-utiliti
es/navXMXPUI/application.windows64/lib/gluegen-rt.jar!/com/jogamp/common/os/Plat
form.class, nativeJarBaseName gluegen-rt-natives-windows-i586.jar): [ file:/C:/U
sers/Joe/Desktop/navx-utilities/navXMXPUI/application.windows64/lib/gluegen-rt.j
ar -> file:/C:/Users/Joe/Desktop/navx-utilities/navXMXPUI/application.windows64/
lib/ ] + gluegen-rt-natives-windows-i586.jar -> slim: jar:file:/C:/Users/Joe/Des
ktop/navx-utilities/navXMXPUI/application.windows64/lib/gluegen-rt-natives-windo
ws-i586.jar!/
Exception in thread "Animation Thread" java.lang.UnsatisfiedLinkError: Can't loa
d library: C:\Users\Joe\Desktop\navx-utilities\navXMXPUI\application.windows64\g
luegen-rt.dll
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary Internal(JNILibLoad
erBase.java:551)
at com.jogamp.common.jvm.JNILibLoaderBase.access$000( JNILibLoaderBase.ja
va:64)
at com.jogamp.common.jvm.JNILibLoaderBase$DefaultActi on.loadLibrary(JNIL
ibLoaderBase.java:96)
at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary (JNILibLoaderBase.j
ava:414)
at com.jogamp.common.os.DynamicLibraryBundle$GlueJNIL ibLoader.loadLibrar
y(DynamicLibraryBundle.java:388)
at com.jogamp.common.os.Platform$1.run(Platform.java: 203)
at java.security.AccessController.doPrivileged(Native Method)
at com.jogamp.common.os.Platform.<clinit>(Platform.java:173)
at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:82)
at processing.opengl.PJOGL.initSurface(PJOGL.java:238 )
at processing.opengl.PGraphicsOpenGL.initPrimary(PGra phicsOpenGL.java:59
88)
at processing.opengl.PGraphicsOpenGL.requestDraw(PGra phicsOpenGL.java:16
00)
at processing.core.PApplet.run(PApplet.java:2177)
at java.lang.Thread.run(Unknown Source)

If I just try to run the .exe file, it's just a blank, white window. I've tried downloading the NavX_Utilities different times and I've tried this on 3 different laptops (granted, all running 64-bit Win8.1) with no success.

Thanks!

[slibert]

I'm using 64-bit Windows 8.1 (that might be the issue?)

Here is the command prompt window text
Catched FileNotFoundException: C:\Users\Joe\Desktop\navx-utilities\navXMXPUI\app
lication.windows64\lib\gluegen-rt-natives-windows-i586.jar (The system cannot fi
nd the file specified), while addNativeJarLibsImpl(classFromJavaJar class com.jo
gamp.common.os.Platform, classJarURI jar:file:/C:/Users/Joe/Desktop/navx-utiliti
es/navXMXPUI/application.windows64/lib/gluegen-rt.jar!/com/jogamp/common/os/Plat
form.class, nativeJarBaseName gluegen-rt-natives-windows-i586.jar): [ file:/C:/U
sers/Joe/Desktop/navx-utilities/navXMXPUI/application.windows64/lib/gluegen-rt.j
ar -> file:/C:/Users/Joe/Desktop/navx-utilities/navXMXPUI/application.windows64/
lib/ ] + gluegen-rt-natives-windows-i586.jar -> slim: jar:file:/C:/Users/Joe/Des
ktop/navx-utilities/navXMXPUI/application.windows64/lib/gluegen-rt-natives-windo
ws-i586.jar!/
Exception in thread "Animation Thread" java.lang.UnsatisfiedLinkError: Can't loa
d library: C:\Users\Joe\Desktop\navx-utilities\navXMXPUI\application.windows64\g
luegen-rt.dll
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary Internal(JNILibLoad
erBase.java:551)
at com.jogamp.common.jvm.JNILibLoaderBase.access$000( JNILibLoaderBase.ja
va:64)
at com.jogamp.common.jvm.JNILibLoaderBase$DefaultActi on.loadLibrary(JNIL
ibLoaderBase.java:96)
at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary (JNILibLoaderBase.j
ava:414)
at com.jogamp.common.os.DynamicLibraryBundle$GlueJNIL ibLoader.loadLibrar
y(DynamicLibraryBundle.java:388)
at com.jogamp.common.os.Platform$1.run(Platform.java: 203)
at java.security.AccessController.doPrivileged(Native Method)
at com.jogamp.common.os.Platform.<clinit>(Platform.java:173)
at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:82)
at processing.opengl.PJOGL.initSurface(PJOGL.java:238 )
at processing.opengl.PGraphicsOpenGL.initPrimary(PGra phicsOpenGL.java:59
88)
at processing.opengl.PGraphicsOpenGL.requestDraw(PGra phicsOpenGL.java:16
00)
at processing.core.PApplet.run(PApplet.java:2177)
at java.lang.Thread.run(Unknown Source)

If I just try to run the .exe file, it's just a blank, white window. I've tried downloading the NavX_Utilities different times and I've tried this on 3 different laptops (granted, all running 64-bit Win8.1) with no success.

Thanks!

Ok, that helps. To help narrow things down, what version of Java is installed?

Also, you might try installing the processing IDE, using the instructions at the bottom of this page: https://code.google.com/p/navx-mxp/wiki/navXMXPUI

[jojoguy10]

Ok, that helps. To help narrow things down, what version of Java is installed?

Also, you might try installing the processing IDE, using the instructions at the bottom of this page: https://code.google.com/p/navx-mxp/wiki/navXMXPUI

I have Java 8 Update 31 installed on my main computer.

I have the Processing IDE installed (v2.2.1) When I try to run the navXMXPUI.pde, it says:
No library found for com.kauailabs.navx_mxp
No library found for com.kauailabs.navx_mxp
Libraries must be installed in a folder named 'libraries' inside the 'sketchbook' folder.

[slibert]

I have Java 8 Update 31 installed on my main computer.

I have the Processing IDE installed (v2.2.1) When I try to run the navXMXPUI.pde, it says:
No library found for com.kauailabs.navx_mxp
No library found for com.kauailabs.navx_mxp
Libraries must be installed in a folder named 'libraries' inside the 'sketchbook' folder.


We may have an issue with Java 8 (we tested with Java 7).

You'll need processing IDE v 2.1.

Also the sketch folder in the processing IDE needs to be set to point to the directory that has the navXMXPUI.pde file in it.

[ayeckley]

no matter what values we use for PID, the bot rotates to the angle and constantly shakes back and forth trying to reach the exact angle.

That sounds like a classic case of the Proportional gain being set too high. Keep in mind that it might require surprisingly small values, depending on your exact implementation. If you haven't already, the recommended PID tuning process starts with the I and D gains set to zero and the P gain set to a very low value. If you still get oscillation, then it is probably(*) necessary to decrease the P gain. If the robot "under-turns", then increase the gain incrementally. Generally speaking, once tuning is complete the P gain value should be just below the point at which you get oscillation. This can be very tricky with drives that have to overcome a large amount of stiction (static friction) in their drive systems (Mechanum drives are a good example) and robots that have relatively high angular moments of inertia (all of them?). It's highly unlikely that the navX unit is the source of the problem. You'll get very different behaviors if your robot is on a hard floor vs. carpet; try to use the most-FRC-realistic surface you can obtain.

* You might also get the symptoms you've described if there is some binding or other non-uniform drag in your drivetrain.

[jojoguy10]

We may have an issue with Java 8 (we tested with Java 7).

You'll need processing IDE v 2.1.

Also the sketch folder in the processing IDE needs to be set to point to the directory that has the navXMXPUI.pde file in it.

Rolling back to Java 7 worked! Thanks!

[bmammen]

That sounds like a classic case of the Proportional gain being set too high. Keep in mind that it might require surprisingly small values, depending on your exact implementation. If you haven't already, the recommended PID tuning process starts with the I and D gains set to zero and the P gain set to a very low value. If you still get oscillation, then it is probably(*) necessary to decrease the P gain. If the robot "under-turns", then increase the gain incrementally. Generally speaking, once tuning is complete the P gain value should be just below the point at which you get oscillation. This can be very tricky with drives that have to overcome a large amount of stiction (static friction) in their drive systems (Mechanum drives are a good example) and robots that have relatively high angular moments of inertia (all of them?). It's highly unlikely that the navX unit is the source of the problem. You'll get very different behaviors if your robot is on a hard floor vs. carpet; try to use the most-FRC-realistic surface you can obtain.

* You might also get the symptoms you've described if there is some binding or other non-uniform drag in your drivetrain.

We started with the P value but no matter what its set at (low or high) the turn is still at the same velocity - it does hit the angle though before gyrating back and forth trying to reach accuracy. We've also tried changing the % SetTolerance which yields no change. It must be something with the way we are handing the PID output. Thanks for the suggestions.

[slibert]

Rolling back to Java 7 worked! Thanks!

Great to hear, congratulations.

Did a little research on the error message re: the missing file; it looks like the previous Java system thought it was 32 bits, so perhaps previously the 32-bit version of Java 8 was installed. We will do some testing with Java 8 and the navXMXPUI to try to get this sorted out.

[jojoguy10]

Great to hear, congratulations.

Did a little research on the error message re: the missing file; it looks like the previous Java system thought it was 32 bits, so perhaps previously the 32-bit version of Java 8 was installed. We will do some testing with Java 8 and the navXMXPUI to try to get this sorted out.

Hmmmm...I guess that's possible.

Thanks again for the help. The NavX is VERY responsive at 60Hz! It's awesome!

[Alan Anderson]

We started with the P value but no matter what its set at (low or high) the turn is still at the same velocity - it does hit the angle though before gyrating back and forth trying to reach accuracy.

What P values were you using for "low" and "high"?

It sounds to me like you need to set the P constant lower yet. Remember that it's using the error in robot heading and turning that into a motor command. Motor values are between -1 and 1, and you probably want it to go to less than ten percent power when you're within several degrees of the target. I'd try a Kp of 0.01 to start with and go from there.

[ayeckley]

Scott,

I too am having difficulty running the UI. If I execute navXMXPUI.bat (edited as specified to point to COM4, which is where the ST VCP is connected), I get an error "Could not find or load main class NAVXMXPUI". I am able to run navXConfig (setup.exe) with no issues which leads me to believe both the PC and navX hardware are configured properly.

I'm using Win 7 (64 bit), and have Java 1.7 runtime enabled under User settings (1.8 is also installed, but I have disabled it). I've also installed Processing 2.2.1 (BTW, 2.1 is not listed as a downloadable release) and have merged the UI "processing" directory to the [user]\Documents\Processing location. I can open the Sketch successfully however when I attempt to compile it I get the same library errors as a previous poster reported (no library found for com.kauailabs etc.). When I "Show Sketch Folder", the navXMXPUI folder (and its subfolders) is displayed as one would expect.

Where have I gone wrong? I suspect it's something in my Java configuration.

[slibert]

Scott,

I too am having difficulty running the UI. If I execute (from a Command window) navXMXPUI.exe, nothing happens and no errors are generated. If I execute navXMXPUI.bat (edited as specified to point to COM4, which is where the ST VCP is connected), I get an error "Could not find or load main class NAVXMXPUI". I am able to run navXConfig (setup.exe) with no issues which leads me to believe both the PC and navX hardware are configured properly.

I'm using Win 7 (64 bit), and have Java 1.7 runtime enabled under User settings (1.8 is also installed, but I have disabled it). I've also installed Processing 2.2.1 (2.1 is not listed as a downloadable release) and have copied the "processing" directory to the specified location. I am not able to "Open the Processing IDE and then open the navXMXPUI sketch via the "File->Sketchbook menu" because there are no selections available ("Empty Sketchbook" appears, greyed-out). I can open the .pde successfully using the File/Open dialog, however when I attempt to compile it I get the same library errors as a previous poster reported (no library found for com.kauailabs etc.). When I "Show Sketch Folder", the navXMXPUI folder (and its subfolders) is displayed as one would expect.

Where have I gone wrong? I suspect it's something in my Java configuration.

Building the navXMXPUI with the Processing IDE 2.2 has an issue we haven't fixed yet, I think that's causing your issue.

The pre-built binary in the navxmxpui\application.windows64 directory should work on 64-bit windows if java 1.7 is installed, it's built with processing IDE 2.1. Looks like the link to the 2.1 IDE has been removed. :(

[slibert]

Building the navXMXPUI with the Processing IDE 2.2 has an issue we haven't fixed yet, I think that's causing your issue.

The pre-built binary in the navxmxpui\application.windows64 directory should work on 64-bit windows if java 1.7 is installed, it's built with processing IDE 2.1. Looks like the link to the 2.1 IDE has been removed. :(

Until we get the Processing IDE 2.2 and Java 8 working w/the navX MXP UI, the 2.1 installer for 64-bit windows version of processing 2.1 is temporarily available here (https://navx-mxp.googlecode.com/svn/trunk/installers/processing-2.1-windows64.zip).

[ayeckley]

Update: I've removed everything related to the UI source code (including Processing 2) and am focusing on trying to get the precompiled version to work.

I did discover that my rollback to JRE1.7 was not completely successful despite what the Configure JAVA tool was telling me. By doing the on-line JAVA verification I discovered that 1.7 was being blocked as a security threat. I was able to authorize it, and am now getting quite different (still unsuccessful) results:

Catched FileNotFoundException: C:\Users\ayeckley\Downloads\navx-utilities\navXMXPUI\application.windows64\lib\glue gen-rt-natives-windows-i586.jar (The system cannot find the file specified)<snip>

In the .zip I just downloaded there was a "gluegen-rt-natives-windows-amd64.jar" but not a "gluegen-rt-natives-windows-i586.jar". Is this the smoking gun? I've verified that I'm running Win 7 64 bit, on an Intel processor (not an AMD).

[Mockapapella]

Ok, so I know that this post is kind of old, but both websites linked said that this item was out of stock. Is there any other place where I can obtain it or the previous model?

[cad321]

Ok, so I know that this post is kind of old, but both websites linked said that this item was out of stock. Is there any other place where I can obtain it or the previous model?

I too was wondering this and asked in this (http://www.chiefdelphi.com/forums/showthread.php?threadid=133305) post earlier. According to their website, we will not be able to purchase the navX mxp board until February 7th at the earliest.

[slibert]

Update: I've removed everything related to the UI source code (including Processing 2) and am focusing on trying to get the precompiled version to work.

I did discover that my rollback to JRE1.7 was not completely successful despite what the Configure JAVA tool was telling me. By doing the on-line JAVA verification I discovered that 1.7 was being blocked as a security threat. I was able to authorize it, and am now getting quite different (still unsuccessful) results:

Catched FileNotFoundException: C:\Users\ayeckley\Downloads\navx-utilities\navXMXPUI\application.windows64\lib\glue gen-rt-natives-windows-i586.jar (The system cannot find the file specified)<snip>

In the .zip I just downloaded there was a "gluegen-rt-natives-windows-amd64.jar" but not a "gluegen-rt-natives-windows-i586.jar". Is this the smoking gun? I've verified that I'm running Win 7 64 bit, on an Intel processor (not an AMD).

Please verify that Java 7 is 64-bit, it won't work with 32-bit Java, and it sounds like Java thinks it is 32-bit.

[slibert]

Please verify that Java 7 is 64-bit, it won't work with 32-bit Java, and it sounds like Java thinks it is 32-bit.

We've performed some additional testing w/the navX MXP UI, here are the findings:

1) The pre-built 32-bit binary of navX MXP UI (processing/navXMXPUI/application.windows32) works if 32-bit Java 1.8 is installed, and is the "Active" version of java.

2) The pre-built 64-bit binary of navX MXP UI (processing/navXMXPUI/application.windows64) works if 64-bit Java 1.8 is installed, and is the "Active" version of java.

3) To tell which version of java is currently "Active", open up a command window, and type this command:

java -version

Here's what's displayed when the 32-bit version of java is "Active":

java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) Client VM (build 25.31-b07, mixed mode, sharing)


Here's what's displayed when the 64-bit version of java is "Active":

java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

4) We have not found an easy way to switch the "Active" version of java between the 32 and 64-bit versions of java - but we found online discussions about it. However, since both the 32 and 64-bit pre-built navXMXPUI binaries work w/their respective versions of java, the recommendation is to run the version of navXMXPUI that matches your version of java.

5) We recommend the 64-bit version of the navX MXP UI, since that's the version we test with most often.

[jSoft]

Is anybody here able to guide me through the process of maintaining a fixed header in labview? I'm a bit stuck and trying to follow a guide that isn't meant for this specific gyro. Thanks!

[Alan Anderson]

Is anybody here able to guide me through the process of maintaining a fixed header in labview?

If you mean a fixed heading, then it's pretty simple in concept. Read the current heading (using whatever gyro you have), subtract it from the desired heading to give an error value, and use the error value to turn the robot in the direction necessary to bring the error to zero.

An easy way to do this is to multiply (or divide) the error by a scale factor and wire it to the X axis of an Arcade Drive function. This won't be perfect; it is likely to either oscillate around the desired heading or never quite reach it. That's where a PID function comes in handy, using the Proportional term to turn the robot faster when it's farther off target, and adding in an Integral term to give the turn a little more oomph when it's been off target for too long. A Derivative term is rarely necessary, but might help reduce overshoot if the robot ever gets way off target.

[ayeckley]

Update: I've removed the 32 bit JRE and installed the 64 bit JRE 1.8. Everything seems to be working properly.

I'm still digesting the actual navX code. It's not clear to me yet which calculations are being performed in Scott's code vs. what is performed by the DMP. Definitely one of the most complex embedded projects I've encountered; most don't even do floating point math.

[slibert]

Update: I've removed the 32 bit JRE and installed the 64 bit JRE 1.8. Everything seems to be working properly.

I'm still digesting the actual navX code. It's not clear to me yet which calculations are being performed in Scott's code vs. what is performed by the DMP. Definitely one of the most complex embedded projects I've encountered; most don't even do floating point math.

The DMP is only used to read the quaternions each time a data ready interrupt occurs, calculated using proprietary Invensense algorithms. So the DMP (this is all performed on the Invensense chip) does the gyro-auto cal, and all the gyro/accel data acquisition, filtering and fusion - and puts into a FIFO the calibrated gyro data, the raw accelerometer data, and the quaternion.

Due to several issues found in the invensense "motion processing library" (MPL), the rest of the work is performed on the very capable STM32F4 processor by Kauai Labs code.

After acquiring a quaternion (line 596), this code in MPU9250/mpucontroller.cpp:

- transforms the quaternion to yaw/pitch/roll
- calculates the gravity vector from the quaternion, and subtracts that from the accelerometer data to yield linear acceleration.
- acquires periodic magnetometer samples, time-averaging to reduce noise
- applies magnetometer calibration to the raw magnetometer data to get a compass heading
- tilt-corrects the compass heading based on the pitch/roll
- calculates the "fused (9-axis) heading" from the yaw and the tilt-corrected, calibrated compass heading

Then, in the navx-mxp/navx-mxp.cpp nav10_main(), it:

- maintains statistics of linear acceleration to detect motion/no-motion
- maintains a yaw history, to detect if rotating
- if in startup calibration period, and not moving and not rotating, calculates a yaw offset, which is removed from subsequent yaw values
- sends out updates, updates registers, and processes inbound requests

You'll also come across some work-in-progress code for building and applying a temperature-compensation gyro bias which should someday completely eliminate the automatic gyro calibration after sufficient temp/bias values have been acquired and stored to flash memory.

[Mastonevich]

Any expected delivery date for the CAD files for the enclosure? Or has anyone come up with them on their own?

[slibert]

Any expected delivery date for the CAD files for the enclosure? Or has anyone come up with them on their own?

While not an enclosure, we have recently posted CAD models of the navX MXP Board (in solid works and sketch up formats) to the navX MXP Website (https://code.google.com/p/navx-mxp/source/browse/#svn%2Ftrunk%2Fenclosure). This could prove helpful in the process of designing an enclosure. These are also included in the Latest Build.zip file.

If anyone has any ideas for the enclosure design, please let us know. We've discussed so far a "lid" that rests atop the navX MXP board, is fastened to the navX MXP and the RoboRio via the two screw holes near the RoboRio USB connector, has two posts which help "grip" the navX MXP from the other end (where the two semi-circular holes are) and has top-side holes for pressing reset/cal button, holes for the LEDs to shine through, and something akin to the CRio's Digital Sidecar plastic shell to help secure PWM connectors that might be connected to the Digital/Analog I/O pins on the navX MXP....

[jojoguy10]

While not an enclosure, we have recently posted CAD models of the navX MXP Board (in solid works and sketch up formats) to the navX MXP Website (https://code.google.com/p/navx-mxp/source/browse/#svn%2Ftrunk%2Fenclosure). This could prove helpful in the process of designing an enclosure. These are also included in the Latest Build.zip file.

If anyone has any ideas for the enclosure design, please let us know. We've discussed so far a "lid" that rests atop the navX MXP board, is fastened to the navX MXP and the RoboRio via the two screw holes near the RoboRio USB connector, has two posts which help "grip" the navX MXP from the other end (where the two semi-circular holes are) and has top-side holes for pressing reset/cal button, holes for the LEDs to shine through, and something akin to the CRio's Digital Sidecar plastic shell to help secure PWM connectors that might be connected to the Digital/Analog I/O pins on the navX MXP....

I like a lid idea. I was also wondering when an enclosure would be ready as well.

[cjl2625]

I calibrated the magnetometer, but the MAG_DISTURBANCE indicator is constantly on.
Also, if I rotate the robot 180 degrees, the yaw reads 200 degrees.

[slibert]

I calibrated the magnetometer, but the MAG_DISTURBANCE indicator is constantly on.
Also, if I rotate the robot 180 degrees, the yaw reads 200 degrees.

Among other things, the navX MXP magnetometer calibration process will calculate the strength of the earth's magnetic field. Once calibrated, magnetic disturbance will be detected whenever the current magnetic measurement diverges from the calibrated earth's magnetic field strength by more than a threshold (which defaults to 19%).

So in your case either the magnetic field is truly being disturbed, or the value being used for the magnetic field strength is incorrect.

When calibrated at a high quality level, the navX MXP magnetometer is quite sensitive. Simply holding an iphone a few inches away from the navX MXPUI (when the magnetometer calibration is of high quality) is sufficient to trigger a "magnetic disturbance" detection.

More often, though, the quality of the calibration is an issue. I have yet to meet anyone who achieves quality magnetic calibration on the first try - indeed it's taken quite some practice for me personally to get quality calibration. Here are some hints to help achieve quality calibration:

- Carefully double and triple-check each step along the way - it's very easy to get the orientation of the axes wrong on one or more of the 12 steps. A single error in orientation can lead to low-quality calibration data.
- Another important factor to consider is it's very important that there are not *changing* sources of magnetic disturbance during the magnetometer calibration process. We've seen problems when calibrating the magnetometer near a PC, and another time near a USB cable that had a "choke" (a round piece of ferrous metal) on it. If there are any such sources of interference nearby that _are still_, while you _are moving_ the navX MXP to calibrate it, the fluctuations in the magnetic field measured by the navX MXP will lead to errors in the calibration.

Regarding the yaw measurement, there's a common cause for the symptom you report. It's very important to ensure that the navX MXP is held still during the startup (calibration) phase in order to get accurate yaw measurements. Please read the gyroscope/accelerometer calibration wiki page (http://code.google.com/p/navx-mxp/wiki/GyroAccelCalibration) for details on this. You can also use the navX MXP UI (http://code.google.com/p/navx-mxp/wiki/navXMXPUI) to see this clearly - when the "Calibrating..." indicator is displayed the navX MXP must be held still. Only after this indicator is removed will yaw measurements exhibit high accuracy.

[cjl2625]

Well, the mini USB I was using had a choke, I was calibrating next to a PC, I was also moving during the calibration, and I did all the calibrations by eyeballing it.
It seems reasonable to assume that my calibration sucked :P

I'll try it again against a fixed corner, attempt to scavenge for another usb, and move my PC far away.

[cjl2625]

How likely is it that a mini USB with a choke will screw up the calibration?
That's the only cord I've been able to get my hands on

[slibert]

How likely is it that a mini USB with a choke will screw up the calibration?
That's the only cord I've been able to get my hands on

The choke will only cause a problem if it moves. If it stays in the same place during the calibration and while in use, then there should not be a problem. For our calibration w/a choke, I've actually taped it in place to make sure it doesn't cause a problem (moving relative to the navX MXP during calibration).

[slibert]

Any expected delivery date for the CAD files for the enclosure? Or has anyone come up with them on their own?

A first cut of the Sketchup and STL files for a lid-style enclosure for the navX MXP when mounted on the MXP port of the RoboRio are now available (http://code.google.com/p/navx-mxp/wiki/Enclosure).

The STL file is what one would typically use to 3D-print the enclosure. If you want to modify the design, you can use Sketchup 2015 and the STL Import/Export Extension to generate the STL file from that.

We're testing this by sending out a order to Sculpteo, they are charging about 10.00 plus 6.00 shipping for a white plastic version (prices increase depending upon the materials and colors chosen). Shapeways charges a similar amount.

[mklinker]

[QUOTE=slibert;1437174]A first cut of the Sketchup and STL files for a lid-style enclosure for the navX MXP when mounted on the MXP port of the RoboRio are now available (http://code.google.com/p/navx-mxp/wiki/Enclosure).

There does not appear to be a link to the STL file. Will these be made available for download?

[Pault]

We have been having some problems with brownouts causing us to lose the NavX. Essentially, if the NavX loses power for even a fraction of a second, the roboRIO loses connection with it and isnt able to reconnect. I have tried to reinstantiate the IMU object, but it seems like FIRST does not want you doing that outside of robotInit. Do you have any solutions to this? I'm not sure how frequent brownouts will be, but 7 volts sounds like something teams will be running into often.

[slibert]

[QUOTE=slibert;1437174]A first cut of the Sketchup and STL files for a lid-style enclosure for the navX MXP when mounted on the MXP port of the RoboRio are now available (http://code.google.com/p/navx-mxp/wiki/Enclosure).

There does not appear to be a link to the STL file. Will these be made available for download?

An explicit link has been added to clarify it, if you download the latest build (https://navx-mxp.googlecode.com/svn/trunk/navx-mxp.zip) .zip file, it's in the enclosure directory.

[slibert]

We have been having some problems with brownouts causing us to lose the NavX. Essentially, if the NavX loses power for even a fraction of a second, the roboRIO loses connection with it and isnt able to reconnect. I have tried to reinstantiate the IMU object, but it seems like FIRST does not want you doing that outside of robotInit. Do you have any solutions to this? I'm not sure how frequent brownouts will be, but 7 volts sounds like something teams will be running into often.

The navX can be powered simultaneously by the MXP and the USB ports. So if your robot design allows for power to drop below the threshold required to power the RoboRio, you can do something like adding either a custom USB cable (whose 5V comes from the VRM) or a powered USB hub. The USB cable will automatically be used as a power supply if the MXP power should drop below a threshold. The navX has an onboard op-amp that monitors the voltage and an onboard fast-switching MOSFET to control the switch. Your limitation w/this design will be the minimum voltage required for the voltage regulator (which outputs 5V) to operate properly.

Another option you have is to use the "Low Level Connect via Power and Signal pins on MXP connector" (http://code.google.com/p/navx-mxp/wiki/AdvancedInstallOptions). In your case, the power could be supplied from a separate 5VDC source. I think the USB cable option indicated above would be simpler.

Finally, as to the recovery when the roborio restarts, what language and communication interface are you using?

[Joe Ross]

I have tried to reinstantiate the IMU object, but it seems like FIRST does not want you doing that outside of robotInit.

Can you explain what you mean by this?

[Pault]

Can you explain what you mean by this?

I should probably mention that I am using Java.

In disabledInit(), I called the constructor for IMU if I knew that I lost connection. This caused the RoboRIO to throw a slew of errors related to NI-VISA and HALUTIL. Unfortunately I dont have a log of these errors available to me. On second thought, there is a good chance this was being caused because I had already instantiated the IMU once, and I'm not allowed to access the port twice.

Anyways, USB should solve my problems. The 5V rail apparently is supposed to stay alive down until the RoboRIO itself experiences a brownout.

[slibert]

I should probably mention that I am using Java.

In disabledInit(), I called the constructor for IMU if I knew that I lost connection. This caused the RoboRIO to throw a slew of errors related to NI-VISA and HALUTIL. Unfortunately I dont have a log of these errors available to me. On second thought, there is a good chance this was being caused because I had already instantiated the IMU once, and I'm not allowed to access the port twice.

Anyways, USB should solve my problems. The 5V rail apparently is supposed to stay alive down until the RoboRIO itself experiences a brownout.

There should be no need to re-instantiate the IMU class when connection is lost, the IMU class will continually attempt to re-establish communications if the connection is ever lost.

If the 5V (MXP) rail stays alive until the RoboRio itself experiences a brownout, then the navX MXP should continue to receive 5V and should therefore not reset. It's theoretically possible that the RoboRio has onboard capacitors that allow it to "ride over" a dropout for a longer period of time than the nav MXP's capacitor. However, if this is the case, your RoboRio is already dangerously close to browning out. Are you confident that the navX MXP was being reset due to an undervoltage situation on the RoboRio's 5V MXP Rail?

[Gdeaver]

Problem, Our Roborio is going to be mounted vertically. What are the implications for the Navx MXP. We are using some of the break out ports and do not want to mount the board off the robo rio.

[slibert]

Problem, Our Roborio is going to be mounted vertically. What are the implications for the Navx MXP. We are using some of the break out ports and do not want to mount the board off the robo rio.

For this RoboRIO configuration, the recommendation is the "One-wire connect via 'Floppy-disk' Extension Cable" (http://code.google.com/p/navx-mxp/wiki/AdvancedInstallOptions). This approach both allows the I/O expansion to be used, and also allows the RoboRIO to be mounted in a different orientation than the navX MXP.

The navX MXP's motion processing requires the unit be mounted horizontally, parallel to the earth's surface; the implications of non-standard mounting include the invalidation of the assumption that the z-axis is perpendicular to the earths surface. This will cause the MPU-9250 accelerometer self-tests to fail. While the calibrated gyro data should still be usable (as this is unaffected by gravity), the accelerometer data and the fusion of that data with the gyros to derive a yaw angle will all be negatively impacted. It is for these reasons that this approach is discouraged.

If you do choose to embark upon this non-standard mounting experiment, please let us know your results. It's possible the navX MXP will generate useful information under these circumstances, though that would seem doubtful based upon the above discussion and some quick experiments here at Kauai Labs.

[Alan Anderson]

The navX MXP's motion processing requires the unit be mounted horizontally, parallel to the earth's surface; the implications of non-standard mounting include the invalidation of the assumption that the z-axis is perpendicular to the earths surface.

Is this a hardware limitation of the MPU-9250? If not, would it be possible in theory to change the firmware either to deduce on powerup which axis is the up/down one, or to accept a configuration instruction describing its mounting orientation?

[slibert]

Is this a hardware limitation of the MPU-9250? If not, would it be possible in theory to change the firmware either to deduce on powerup which axis is the up/down one, or to accept a configuration instruction describing its mounting orientation?

That will take some research; there are several processes that will be impacted (selftest, gyro/accel calibration, yaw offsets, magnetometer calibration), some of which occur in the MPU-9250 silicon, and some in the navX MXP firmware.

The MPU-9250 driver includes a orientation matrix that can be sent to the MPU-9250's DMP; this is intended to be used to identify the orientation of the MPU-9250 relative to the circuit board it is mounted on. This could potentially be investigated as a method for allowing alternate mounting configuration of the navX MXP itself.

It's theoretically possible to have an advanced configuration option whereby one could specify an alternate mounting configuration. If there's enough interest, we can study this further; such a change would require a non-trivial amount of work and testing.

[protoserge]

I'm looking at the printing the .stl. Can you alter the extruded text on the top of the cover to a cut? This cover is best printed with the top facing down on the bed. Thanks for providing a nice cover!

[slibert]

I'm looking at the printing the .stl. Can you alter the extruded text on the top of the cover to a cut? This cover is best printed with the top facing down on the bed. Thanks for providing a nice cover!

Hmm, you make a good point about the printing w/the top facing down on the bed. We'll get to work on your suggestion; we're also planning on thickening the edges a bit to enhance durability. This will likely take several days to complete and test, an update will be posted on this thread when the updated .stl is available.

[Thad House]

So in the next shipment that you guys get, how many will be available? We need another one to put on our practice bot, since we only ordered one originally.

[slibert]

So in the next shipment that you guys get, how many will be available? We need another one to put on our practice bot, since we only ordered one originally.

100 units are being shipped to AndyMark today, they should receive them in about 3 days from now.

Within about 2 weeks, an additional 100 more units will be shipped to AndyMark .

[marshall]

100 units are being shipped to AndyMark today, they should receive them in about 3 days from now.

Within about 2 weeks, an additional 100 more units will be shipped to AndyMark .

Not busy are you Scott?

[slibert]

Not busy are you Scott?

:) Did I mention we're working on a robot at the same time?

[rich2202]

I convinced my team to get one to play with (when they are back in stock), but now we have a need for more DIO ports, so ...

All I can find on the navX is the data sheet. Is there a pin-out diagram? The ports are labeled well. I'm sure there is a standard, but I like to know for sure, which pin is for power (usually the middle), signal, and ground.

[jojoguy10]

So in the next shipment that you guys get, how many will be available? We need another one to put on our practice bot, since we only ordered one originally.

Thad, can't you just take the one off of your competition bot before it's bagged? (In case you can't get a second one)

[Thad House]

Thad, can't you just take the one off of your competition bot before it's bagged? (In case you can't get a second one)

We will if we have to. But we'd rather not be constantly switching them around.

[slibert]

I convinced my team to get one to play with (when they are back in stock), but now we have a need for more DIO ports, so ...

All I can find on the navX is the data sheet. Is there a pin-out diagram? The ports are labeled well. I'm sure there is a standard, but I like to know for sure, which pin is for power (usually the middle), signal, and ground.

Checkout the newly-added diagram on the navX MXP IO Expansion Wiki Page (http://code.google.com/p/navx-mxp/wiki/MXPIOExpansion). This adds an image to clarify the orientation of the ground, power and signal pins for the digital and analog I/O pins.

[Thad House]

Checkout the newly-added diagram on the navX MXP IO Expansion Wiki Page (http://code.google.com/p/navx-mxp/wiki/MXPIOExpansion). This adds an image to clarify the orientation of the ground, power and signal pins for the digital and analog I/O pins.

Can I request one more thing be added to that. Would you guys add a pinout for which IO goes to which port on the MXP connector. We noticed PWMs were 0-9, but DIOs were not that. like the 8th slot was DIO 12, and the 9th slot was DIO 13. We were able to look through the schematic and figure this out, but it would be nice if you guys had an easy was to figure that out on your website.

[slibert]

Can I request one more thing be added to that. Would you guys add a pinout for which IO goes to which port on the MXP connector. We noticed PWMs were 0-9, but DIOs were not that. like the 8th slot was DIO 12, and the 9th slot was DIO 13. We were able to look through the schematic and figure this out, but it would be nice if you guys had an easy was to figure that out on your website.

Good point; the navX MXP IO Expansion Wiki Page (http://code.google.com/p/navx-mxp/wiki/MXPIOExpansion) has been updated to include the addressing of all the I/O pins.

[rich2202]

Good point; the navX MXP IO Expansion Wiki Page (http://code.google.com/p/navx-mxp/wiki/MXPIOExpansion) has been updated to include the addressing of all the I/O pins.

Thank you. I have no idea how long that would have taken us to figure out.

[rich2202]

Any comments on using the navX with Mecanum wheels?

In the wpilib, there is a gyro parameter that you can pass to the Mecanum function. Can navX provide the gryo input? Or, does the navX libraries have Mecanum drive?

[slibert]

Any comments on using the navX with Mecanum wheels?

In the wpilib, there is a gyro parameter that you can pass to the Mecanum function. Can navX provide the gryo input? Or, does the navX libraries have Mecanum drive?

Team 2465 (Kauaibots) uses navX MXP w/Mecanum, it works great.

We found the key to good mecanum was both Field-Oriented Drive (which the navX MXP provides), and traction control (implemented via speed-control PIDs on each of the wheels). Additionally, the navX MXP allows an "auto-rotate to angle" feature, which is helpful in two ways: (a) it lets drivers push a button and have the robot line itself parallel (or perpendicular) to the field, and (b) if used while strafing, it helps the robot stay aligned with the head of robot pointing to the "head" of the field, even if the load on the mecanum drive-train is uneven.

Java Source code for the drive subsystem that implements this is available here (http://code.google.com/p/kauaibotsfirst2010/source/browse/trunk/Source/2015/GizmoBot/src/org/usfirst/frc2465/GizmoBot/subsystems/Drive.java). This demonstrates the use of the nav6 or the navX MXP. Drive.java is provided a reference to the IMU object when it is constructed, and then uses it internally.

The IMU class (for C++/Java) also implements the PIDSource interface, so you can use it with other classes that use a PIDSource for gyro input.

[jojoguy10]

Our team is also planning on using the NavX to keep us aligned (especially during AUTO). We're using Labview and will hopefully be able to decipher the Java examples into Labview code. Any help or discoveries would be much appriciated!

[slibert]

100 units are being shipped to AndyMark today, they should receive them in about 3 days from now.

Within about 2 weeks, an additional 100 more units will be shipped to AndyMark .

A shipment of navX MXPs was delivered to AndyMark today; if you're waiting, please keep an eye on the navX MXP product page (http://www.andymark.com/product-p/am-3060.htm) at the Andymark site, as they should become available for purchase soon. As noted previously, Andymark recommends interested parties should register for a notification when they are available by clicking on the "Email When Available" link on this page.

[wt200999]

A shipment of navX MXPs was delivered to AndyMark today; if you're waiting, please keep an eye on the navX MXP product page (http://www.andymark.com/product-p/am-3060.htm) at the Andymark site, as they should become available for purchase soon. As noted previously, Andymark recommends interested parties should register for a notification when they are available by clicking on the "Email When Available" link on this page.

AM just sent out their availability email:

Limited supply will be available.

You are receiving this email as you have put your e-mail in to be notified when this item will become available.

Because of the higher demand than available volume of this product, we are giving you as much advance notice as possible. We plan to open the sale of the 99 available at 5:30pm ET, Monday 2/16.

The next shipment of these is due in about March 6th, 2015

We apologize for the inconvenience, with long lead time items it is difficult to forecast the demand, but will continue to improve this process.

Good luck to you at 5:30pm ET, Monday 2/16.

Jerry Budd
AndyMark Inc.
Robot Controls Engineer


I apologize for any confusion and missing this in the original email. If you have noticed, the product website shows that they will be available Tuesday, 2/17. This is the day they will be available in our warehouse, we are opening them for sale the night before so we can immediately ship these when they come in Tuesday morning.

Feel free to send any questions you may have my direction.



Jerry Budd
AndyMark Inc.
Robot Controls Engineer

[cjl2625]

I've continued to have trouble getting any kind of accurate reading.
I calibrated the gyro/accelerometer by holding down the CAL button, but readings are still off by ~10%.
I gave up on calibrating the magnetometer, I kept losing connection during calibration.
Is there anything I should try?

[rich2202]

Team 2465 (Kauaibots) uses navX MXP w/Mecanum, it works great. ...


Thanks!

[slibert]

I've continued to have trouble getting any kind of accurate reading.
I calibrated the gyro/accelerometer by holding down the CAL button, but readings are still off by ~10%.
I gave up on calibrating the magnetometer, I kept losing connection during calibration.
Is there anything I should try?

Please send us an email at support@kauailabs.com and we'll work with you on figuring out why your readings are not as accurate as expected.

[slibert]

Hmm, you make a good point about the printing w/the top facing down on the bed. We'll get to work on your suggestion; we're also planning on thickening the edges a bit to enhance durability. This will likely take several days to complete and test, an update will be posted on this thread when the updated .stl is available.

A beta version of the navX MXP "Lid" enclosure (to be used when mounting the navX MXP directly on top of the RoboRio via the MXP Connector) is now available. If you're interested in printing the enclosure yourself w/a 3D printer, please visit the "Creating an Enclosure" (http://code.google.com/p/navx-mxp/wiki/Enclosure) page on the navX MXP wiki.

Those who prefer to purchase the enclosure can order it from Shapeways (http://www.shapeways.com/product/YCWCZWCE8/navx-mxp-roborio-lid-v3-scaleddown).

**** Change Summary ****

- Thickened the walls to ensure reliability in the 3D printing process and durability during use.
- Modified text on the lid to be recessed rather than extruded, supporting printing with the lid top facing down on the 3D printer bed.

[rich2202]

In the spirit of GP, it would be nice if AM had a way to limit orders to 1 per team for the batch available Monday. Two of us are ordering one on Monday just to increase our odds of getting at least one. We could easily agree to delay one of our orders to the March 6 batch.

[Thad House]

Has anybody had issues with their NavX's freezing the SPI and I2C Busses? We have been running it for a few days, and occasionally all reports will freeze and report nothing. Resetting the board does not fix this. The only fix is to reload the code on the roborio, which returns it to working condition. Has anybody else seen this yet? We are using LabVIEW.

[slibert]

Has anybody had issues with their NavX's freezing the SPI and I2C Busses? We have been running it for a few days, and occasionally all reports will freeze and report nothing. Resetting the board does not fix this. The only fix is to reload the code on the roborio, which returns it to working condition. Has anybody else seen this yet? We are using LabVIEW.

Here at Kauailabs, we haven't heard of this issue before.

It's odd is that resetting the navX MXP doesn't clear the error, as this will reset all the navX MXP I2C/SPI circuitry. And from your description, it sounds like resetting/power-cycling the RoboRio doesn't clear the condition either, right? That's a very odd failure mode, indeed.

Here are a few questions that will hopefully lead closer to a diagnosis and solution:

Q1: When you said the only way to clear it is to "reload the code on the roborio", do you mean re-loading your robot application, or do you mean re-imaging the RoboRio?

Q2: Are you using the latest RoboRio firmware? There was apparently a I2C-related fix recently, and that the latest image v. is FRC_roboRIO_2015_v23 and the latest FPGA version is 2.1.0f3.

Q3: To help us reproduce what you're seeing, can you also please let us know more about your configuration? Specifically, are you using the I2C/SPI busses for any other communications to other devcies [we've heard of trouble communicating w/the LIDAR lite simultaneous w/other I2C devices, for instance], and which of the I2C/SPI interfaces are you currently using to communicate w/the navX MXP [did it fail on both the same way?]

[Thad House]

Powercycling the RoboRIO, or hitting the Restart Robot Code button on the DS does make it work again. Also, the DS reports that there is no valid device at the address when this happens. Resetting just the Gyro board does not change anything.

Also, we are using the newest firmware on the newest firmware on both devices. And there are no other devices on the busses. This error happens on both SPI and I2C.

[slibert]

AM just sent out their availability email:

AM just sent out the announcement that more navX MXP units are in stock now.

[rich2202]

We got one, and are excited to test it out. We are waiting until the morning to place an order for a second one. We want to give other teams the opportunity to get at least one before we took a second one for the practice bot.

[slibert]

Powercycling the RoboRIO, or hitting the Restart Robot Code button on the DS does make it work again. Also, the DS reports that there is no valid device at the address when this happens. Resetting just the Gyro board does not change anything.

Also, we are using the newest firmware on the newest firmware on both devices. And there are no other devices on the busses. This error happens on both SPI and I2C.

After doing some checking, another navX MXP customer has indicated they've seen a similar issue w/SPI, and their thinking is there's an issue in the LabView WPI Library component. This seems plausible, since the navX MXP is a slave on both buses, and resetting the navX MXP(which completely releases the busses) doesn't clear the issue. But it's a bit early in the investigation process to tell.

We've setup a LabView SPI longevity test here at Kauai Labs, and will try to reproduce the issue - and if we can reproduce it, we'll gather as much info as we can and inform National Instruments of the details - and post what we know on this thread.

Until we find out where the problem lies and how to resolve it, you might consider using the TTL UART or USB interfaces instead.

[slibert]

After doing some checking, another navX MXP customer has indicated they've seen a similar issue w/SPI, and their thinking is there's an issue in the LabView WPI Library component. This seems plausible, since the navX MXP is a slave on both buses, and resetting the navX MXP(which completely releases the busses) doesn't clear the issue. But it's a bit early in the investigation process to tell.

We've setup a LabView SPI longevity test here at Kauai Labs, and will try to reproduce the issue - and if we can reproduce it, we'll gather as much info as we can and inform National Instruments of the details - and post what we know on this thread.

Until we find out where the problem lies and how to resolve it, you might consider using the TTL UART or USB interfaces instead.

Follow-up questions: What update rate (in Hz) are you using w/the navX MXP - this'll help make sure our testing here is as close as possible to your situation. Also, what is your overall CPU % (average) when running your robot software?

[Thad House]

Follow-up questions: What update rate (in Hz) are you using w/the navX MXP - this'll help make sure our testing here is as close as possible to your situation. Also, what is your overall CPU % (average) when running your robot software?

We are using 60Hz. Also it is using about 80% of our CPU. It hasnt done it since we switched it back to SPI, which is what we were using yesterday. This morning we were using I2C It had the issue with both busses.

[TylerS]

It sounds like you guys were having the same issues we had today.

[slibert]

It sounds like you guys were having the same issues we had today.

Are you also using LabView with SPI to communicate w/the navX MXP?

[Thad House]

We were able to successfully reproduce the issue. A very fast brownout was able to. If it was longer then about 20 ms it didnt happen, but shorter then that and it did.

[jojoguy10]

Has anybody had issues with their NavX's freezing the SPI and I2C Busses? We have been running it for a few days, and occasionally all reports will freeze and report nothing. Resetting the board does not fix this. The only fix is to reload the code on the roborio, which returns it to working condition. Has anybody else seen this yet? We are using LabVIEW.

And I thought it was just us.

We are using LabView and are having the same problem every now and then. It might be because of browning out? We'll have to do some quick testing.

[TylerS]

Are you also using LabView with SPI to communicate w/the navX MXP?

Yep

[slibert]

We were able to successfully reproduce the issue. A very fast brownout was able to. If it was longer then about 20 ms it didnt happen, but shorter then that and it did.

Fascinating. Congratulations on some nice sleuthing...

Our LabView SPI longevity test has run 16 hours now w/no problems - glad there's an edge case identified we can chase down.

Using the RoboRio Brownout and Understanding Current Draw (https://wpilib.screenstepslive.com/s/4485/m/24166/l/289498-roborio-brownout-and-understanding-current-draw) article as a reference, there are three stages of RoboRio brownout. Do you know which stage was reached in the case you've reproduced? It'd be interesting to know if Stage 2 (which would remove the power from the MXP 5V rail) was hit or not.

Also, could you please post the driver station logs that document the case when this occurs? That should help clarify the details of the scenario. The goal is to try to reproduce this behavior with a benchtop power supply, so the more info on the dynamics, the better. Once reproduced, we can run through various configurations and characterize the behavior more thoroughly.

[Thad House]

Fascinating. Congratulations on some nice sleuthing...

Our LabView SPI longevity test has run 16 hours now w/no problems - glad there's an edge case identified we can chase down.

Using the RoboRio Brownout and Understanding Current Draw (https://wpilib.screenstepslive.com/s/4485/m/24166/l/289498-roborio-brownout-and-understanding-current-draw) article as a reference, there are three stages of RoboRio brownout. Do you know which stage was reached in the case you've reproduced? It'd be interesting to know if Stage 2 (which would remove the power from the MXP 5V rail) was hit or not.

Also, could you please post the driver station logs that document the case when this occurs? That should help clarify the details of the scenario. The goal is to try to reproduce this behavior with a benchtop power supply, so the more info on the dynamics, the better. Once reproduced, we can run through various configurations and characterize the behavior more thoroughly.

I will check to see how low the battery voltage was getting when this was happening. I will also get the driver station logs later today. It seems like the NaVX is rebooting, because when we do the RoboRIO code restart, if we do it within 16 seconds, the navx reports its in calibration mode, just like it does on startup.

Note that this for us was not just limited to SPI. I2C had the same issue, but it happened earlier. I would guess that when it happened on I2C, it was because the pullups were being forced high by stage 1. I don't know if SPI has that same issue, but the issue seemed to happen with a much lower battery on SPI then I2C.

[slibert]

I will check to see how low the battery voltage was getting when this was happening. I will also get the driver station logs later today. It seems like the NaVX is rebooting, because when we do the RoboRIO code restart, if we do it within 16 seconds, the navx reports its in calibration mode, just like it does on startup.

Note that this for us was not just limited to SPI. I2C had the same issue, but it happened earlier. I would guess that when it happened on I2C, it was because the pullups were being forced high by stage 1. I don't know if SPI has that same issue, but the issue seemed to happen with a much lower battery on SPI then I2C.

The RoboRio will remove power from the MXP connector if the unregulated VIN to the RoboRio drops below 6.3V. And it appears the RoboRio I2C/SPI busses are getting wedged with really short brownouts (though it's going to take some time to rig up some equipment so this can be characterized further).

If the navX MXP power input is removed during operation this will cause a yaw angle discontinuity - since the currently calculated yaw angle is based upon in-memory calibration coefficients.

Fortunately, the navx MXP has a USB input, and has on-board circuitry to automatically switch over to the USB input for power and a capacitor to ride-over the switching period. A comprehensive way to allow the navX MXP to continue to operate even in the face of a RobRio Stage 2 brownout is to modify a power-only USB connector (5VDC and ground leads only), and connect it to one of the VRM's 5VDC outputs. The VRM buck/boost regulator configuration allows it to provide 5VDC down to a VIN of 3.6V [per graphs in datasheet], by which time the RoboRio would have completely shutdown.

Using this approach, the navX MXP will continue to be powered even when the RoboRio VIN drops below the level where the RoboRio has completely shutdown (Stage 3).

It's possible this step alone will not resolve the issue that the RoboRio I2C/SPI circuitry is stuck after it enters Stage 2 and removes power from the MXP power rail for a brief instant. That needs more testing.

Here's the recommendation for moving ahead, please let me know your thoughts:

(a) connect the navX MXP USB (mini-b connector) to a 500mA 5VDC VRM output

(b) we'll work on reproducing the I2C/SPI bus hangs when the RoboRio reaches brownout Stage 2 for very short (e.g., 20 ms) periods of time, and forward that info to National Instruments.

(c) If (b) persists even after (a) and we can't get a resolution from NI in time, switching to the TTL UART interface is another feasible approach.

[rich2202]

A beta version of the navX MXP "Lid" enclosure

I suggest the following changes:

The blank part that covers the USB interface, put ground/power/signal markings like is on the roboRio

Use the roboRio style markings for the PWM port to mark the DIO/PWM port, including roboRio port numbers. Ditto for Analog ports. Maybe use letters AIN 4, AIN 5, AIN 6, AIN 7, AOUT O, AOUT 1, since there is not as much room.

[slibert]

I suggest the following changes:

The blank part that covers the USB interface, put ground/power/signal markings like is on the roboRio

Use the roboRio style markings for the PWM port to mark the DIO/PWM port, including roboRio port numbers. Ditto for Analog ports. Maybe use letters AIN 4, AIN 5, AIN 6, AIN 7, AOUT O, AOUT 1, since there is not as much room.

These are great suggestions. V4 of the beta navX MXP Lid Enclosure design files is now available.

If you're interested in printing the enclosure yourself w/a 3D printer, please visit the "Creating an Enclosure" (http://code.google.com/p/navx-mxp/wiki/Enclosure) page on the navX MXP wiki.

Those who prefer to purchase the enclosure can order it from Shapeways (https://www.shapeways.com/product/XRR8G4EC2/navx-mxp-roborio-lid-v4-scaleddown).

*** Change Summary ***

- Added GND/+/S labels to Expansion I/O pins (Digital/Analog) near the USB connector.
- Added numbering for each of the PWM/Digitial I/O and Analog pins.

[rich2202]

These are great suggestions. V4 of the beta navX MXP Lid Enclosure design files is now available.


Nice. One more refinement: it would be helpful for the #'s to correspond to RoboRio Channel Address (# for programmers to use), and not the MXP Port Number (which most people don't care about).

[rich2202]

Seems like the USB port is a good option to provide backup power to the navX board.

Can you ask Andymark to stock USB to Stranded cables so that we can wire it to the 5v 500 mA port of the VRM?

The VRM is supposed to be able to supply stable power with battery voltage down to 5V. Is the navX board protected from reverse voltage on the USB Port? If not, it would be nice if you could do that in a future release.

Thanks.

[slibert]

Seems like the USB port is a good option to provide backup power to the navX board.

Can you ask Andymark to stock USB to Stranded cables so that we can wire it to the 5v 500 mA port of the VRM?

The VRM is supposed to be able to supply stable power with battery voltage down to 5V. Is the navX board protected from reverse voltage on the USB Port? If not, it would be nice if you could do that in a future release.
::
Thanks.

Actually, this seems like a simple, inexpensive option (http://www.amazon.com/dp/B00JWKAAOA?psc=1) that also alleviates the reverse polarity concern. Here's one w/a built-in Mini-B USB connector (http://www.amazon.com/Duracell-Instant-Charger-Includes-Universal/dp/B002FU6KF2).

We'll go ahead and test the Duracell charger (or one like it) to make sure it does the trick, and post the results on this thread.

[Alan Anderson]

Actually, this seems like a simple, inexpensive option (http://www.amazon.com/dp/B00JWKAAOA?psc=1) that also alleviates the reverse polarity concern. Here's one w/a built-in Mini-B USB connector (http://www.amazon.com/Duracell-Instant-Charger-Includes-Universal/dp/B002FU6KF2).

Did you notice that those are batteries? Under <R20>, they aren't permitted on the robot.

[slibert]

Did you notice that those are batteries? Under <R20>, they aren't permitted on the robot.

Ah, good point; so sounds like a modified USB cable fed by the VRM is the best option for those wishing to ride over a Stage 2 RoboRio brownout.

[protoserge]

Ah, good point; so sounds like a modified USB cable fed by the VRM is the best option for those wishing to ride over a Stage 2 RoboRio brownout.

I don't think it would be cost-effective to inventory custom cables. Teams should be plenty capable of cutting one end off of a USB cable :)

[rich2202]

I don't think it would be cost-effective to inventory custom cables. Teams should be plenty capable of cutting one end off of a USB cable :)

A lot of USB cables are 24-28 AWG. Per R38, it would need to be 22 AWG.

Also, a lot of those type cables to not strip nicely.

Finally, regarding custom cables: I'm guessing that Andymark has sold 200 of the navX boards, and have another batch arriving soon. If half bought the cable, it might be worthwhile. I know that we would buy two for the two navX boards we have.

[Joe Ross]

A lot of USB cables are 24-28 AWG. Per R38, it would need to be 22 AWG.

You would be using the 500ma output on the VRM, which allows 28awg or larger.

[protoserge]

A lot of USB cables are 24-28 AWG. Per R38, it would need to be 22 AWG.

Also, a lot of those type cables to not strip nicely.

Finally, regarding custom cables: I'm guessing that Andymark has sold 200 of the navX boards, and have another batch arriving soon. If half bought the cable, it might be worthwhile. I know that we would buy two for the two navX boards we have.

Not necessarily. Is there a spec on the current required for the NavX? I don't see anything on the board that indicates it would require greater than 500mA, thus it would be covered by the signal level output (28 AWG).

Digikey and Mouser don't carry custom cables (at least as listed under USB cables) aside from the regular USB male plug to cable leads. Unless you want to pay $20-30 a cable, it's unlikely worthwhile for any vendor to carry the mini USB to bare wire cable.

I think one off-the-shelf solution may be this: http://www.amazon.com/USB-Female-Mini-Male-Adapter/dp/B0016RNX2I/ref=sr_1_1?ie=UTF8&qid=1424569206&sr=8-1&keywords=female+usb+to+mini and this http://www.digikey.com/product-detail/en/3021005-03/Q363-ND/1531290. I'll keep searching for a single cable.

[slibert]

Not necessarily. Is there a spec on the current required for the NavX? I don't see anything on the board that indicates it would require greater than 500mA, thus it would be covered by the signal level output (28 AWG).

Digikey and Mouser don't carry custom cables (at least as listed under USB cables) aside from the regular USB male plug to cable leads. Unless you want to pay $20-30 a cable, it's unlikely worthwhile for any vendor to carry the mini USB to bare wire cable.

I think one off-the-shelf solution may be this: http://www.amazon.com/USB-Female-Mini-Male-Adapter/dp/B0016RNX2I/ref=sr_1_1?ie=UTF8&qid=1424569206&sr=8-1&keywords=female+usb+to+mini and this http://www.digikey.com/product-detail/en/3021005-03/Q363-ND/1531290. I'll keep searching for a single cable.

NavX MXP current consumption is <= 250 mA.

[Pault]

Our practice chassis has been running off the 5V 500mA rail using USB for a while now, and we have never experienced a problem*. Literally just took a mini USB cable (buy it at RadioShack or Amazon), cut off the other end, peeled back the shielding, stripped the red and black wires, and plugged it in. It's not that hard.

[rich2202]

1) Should the Magnetometer be calibrated at each event?

2) Should we start posting questions in the Control System, Sensor sub forum, and start each title with "navX"?

[jojoguy10]

Speaking of calibrating the Magnometer,

Is there an easy way to do it? Right now, you need to turn it to every axis (+ and -), which I get. But, how do people handle the cable coming out? Do you guys just hang that part off the edge of the table?

We're probably going to re-calibrate it before our first district just to be safe.

Thanks!

[slibert]

1) Should the Magnetometer be calibrated at each event?

Magnetometer re-calibration is theoretically only necessary when changes to the structure of the robot are made which add/remove metals.

As noted on the wiki, "Initial Gyro Calibration" (press/hold the cal button) is encouraged whenever the ambient temperature changes significantly. This should likely be done when first arriving at an event, and is expected to be the only per-event calibration required unless mods like those mentioned above occur.

[Joe Ross]

Magnetometer re-calibration is theoretically only necessary when changes to the structure of the robot are made which add/remove metals.

Our robot has significant pieces of aluminum as well as a motor that move from 12 inches away from the the navx to only about 2 inches away during normal operation. However, at this time, we're only using the yaw from the navX. Do non-ferrous metals matter? If so, does it only matter for teams using the compass?

[slibert]

Our robot has significant pieces of aluminum as well as a motor that move from 12 inches away from the the navx to only about 2 inches away during normal operation. However, at this time, we're only using the yaw from the navX. Do non-ferrous metals matter? If so, does it only matter for teams using the compass?

Ferrous and non-ferrous metals can impact magnetometer readings (each type impacts in different ways).

However they should not impact the inertial sensor readings; theoretically, only compass readings could be impacted.

[slibert]

Should we start posting questions in the Control System, Sensor sub forum, and start each title with "navX"?

This thread is getting rather long, indeed. Yet, it also serves as a useful "digest" of the issues are encountering and what the solutions and options are.

We're updating the navX MXP Wiki (http://code.google.com/p/navx-mxp/wiki/TableOfContents?tm=6) (esp., the FAQ and Troubleshooting sections) w/the key issues that arise here. navX MXP is a new and unique product, and tailored specifically to the FIRST FRC community, so the best result for all will almost surely come from this type of continued interaction; often, the answers come from other people in the ChiefDelphi community.

My recommendation is to continue to post new questions to this thread (after of course reviewing this thread's current contents and the FAQ/Troubleshooting pages on the Wiki).

Any navX MXP customer who has continued trouble even after reviewing this thread and the Wiki documentation can contact us at support@kauailabs, or private message me.

Longer term (say, this summer after Nationals are over) we can work on setting up a different system. As always, your feedback is welcome, as the goal is to provide the best support possible to FIRST FRC teams.

[rich2202]

The reason I thought of posting new threads is that it makes it easier to find an answer to questions already asked. For example, if I wanted help setting up navX for field drive with Mecanum wheels, it would be hard to search through this thread (already 11 pages) for relevant posts.

[slibert]

The reason I thought of posting new threads is that it makes it easier to find an answer to questions already asked. For example, if I wanted help setting up navX for field drive with Mecanum wheels, it would be hard to search through this thread (already 11 pages) for relevant posts.

The "Search this thread" (http://www.chiefdelphi.com/forums/showthread.php?t=131859&page=12#goto_threadsearch) tool provides a simple way to search for answers on this thread.

[randantor]

What are the units for the raw gyro output in the LabVIEW Library? It looks like it could be radians/second but I'm not entirely sure.

[slibert]

What are the units for the raw gyro output in the LabVIEW Library? It looks like it could be radians/second but I'm not entirely sure.

Raw Gyro data is a 16-bit signed value, in hardware units. Conversion to a real-world value requires knowledge of the sensor Full Scale Range (FSR).

The Gyro FSR is configured for 2000 deg/sec. To convert raw gyro data to deg/sec, simply divide the raw gyro value by 2000:

float curr_deg_sec_x = (float)raw_gyro_x / 2000.0;

Note that gyro values are calibrated, so have had offsets automatically applied to them by the Digital Motion Processor (DMP) on the Invensense MPU-9250 silicon.

[Raw acceleration data is similar; in this case, in units of Gs and since the Accelerometer FSR is configured for +/- 2G, the calculation is:

float curr_accel_x = (float)raw_accel_x / 2.0;]

Most users don't access the raw gyro data directly, since to be useful it typically requires the user software to integrate the data - and for typical use cases, this work is offloaded to the navX MXP processor.

[Thad House]

We competed with our robot this weekend, and we had more of the navX issues. Probably in 5 or 6 matches, the navX would have the issue where it always returned 0. We were not able to actually figure out if it was the bus issue or an actual issue with the gyro, but have you guys been able to look more into the issue with the busses?

[Dunngeon]

We competed with our robot this weekend, and we had more of the navX issues. Probably in 5 or 6 matches, the navX would have the issue where it always returned 0. We were not able to actually figure out if it was the bus issue or an actual issue with the gyro, but have you guys been able to look more into the issue with the busses?

Was this the same issue that caused your issues in the semifinal match?

You guys are on labview right?

[Thad House]

Was this the same issue that caused your issues in the semifinal match?

You guys are on labview right?

The issue in the semi final match was caused by either a bad Ethernet cable or something with the field. The gyro issue wasn't super noticeable, as long as we ran the auto we ran all through eliminations. But we still need to get it figured out, because not being able to rotate at times in auto is a bad thing.

[Shahil_FRC]

We competed with our robot this weekend, and we had more of the navX issues. Probably in 5 or 6 matches, the navX would have the issue where it always returned 0. We were not able to actually figure out if it was the bus issue or an actual issue with the gyro, but have you guys been able to look more into the issue with the busses?

We had a similar issue this past weekend in our QF2 match in autonomous. We believe there was a spi bus or gyro error which led to a value of 0 being returned continuously. This issue caused our robot to enter an uncontrollable spin and the FTA disabling our robot for the remainder of the round. I feel bad for our alliance partners because this issue did not let us move forward to the SF. We could have returned to open loop control upon start of teleop.....

[slibert]

We competed with our robot this weekend, and we had more of the navX issues. Probably in 5 or 6 matches, the navX would have the issue where it always returned 0. We were not able to actually figure out if it was the bus issue or an actual issue with the gyro, but have you guys been able to look more into the issue with the busses?

Here's the issues we've seen so far:

(a) [LabView] an I2C bus hang when communicating w/the navX MXP using I2C (after a simulated stage 2 brownout) in a benchtop test configuration and,
(b) [Java] several I2C bus hangs on our competition robot when using the LIDAR Lite on the MXP I2C bus (in this case, we are currently suspicious of a noise issue corrupting a transmission on the I2C bus, but that hasn't been proven yet).

To get data again from these sensors in both cases required a Roborio reboot (restarting the roborio code did not resolve this issue). We've verified that a Roborio reboot does not cause the navX MXP to be rebooted (the MXP 5VDC rail stays powered across the reboot). This, combined w/the fact the issue occurs w/both LabView, and Java points to a Roborio-side problem, and perhaps at a level lower than the Roborio-side libraries. [All testing was performed w/the latest RoboRio firmware/software versions.]

Our next steps are to refine our test setup to find the simplest reproducible case that will hang the I2C bus (to identify the range of the of time during which a Stage 2 brownout can cause the I2C/SPI bus to hang, and try to get some more info on the bus line states and errors received on the RoboRio side) - and also to reproduce the SPI bus hang on the navX MXP you have mentioned. Once we've got that we'll package up the info and send it along to National Instruments.

Until a resolution is found, these are the recommendations:

- We haven't seen the MXP TTL UART communication path to the navX MXP get hung by the disconnect, so using the MXP TTL UART this is recommended for teams experiencing I2C/SPI bus hangs.

- As noted before, if keeping the navX MXP powered in the face of a Roborio Stage 2 brownout is needed, use the USB interface 5VDC/GND leads connected to a 5VDC, 500mA output from the VRM.

One question for you: have you any evidence of brownouts in your Driver Station Logs during the period of time when the I2C bus was hung? Or do you think another condition may be triggering this case?

[Thad House]

Here's the issues we've seen so far:

(a) [LabView] an I2C bus hang when communicating w/the navX MXP using I2C (after a simulated stage 2 brownout) in a benchtop test configuration and,
(b) [Java] several I2C bus hangs on our competition robot when using the LIDAR Lite on the MXP I2C bus (in this case, we are currently suspicious of a noise issue corrupting a transmission on the I2C bus, but that hasn't been proven yet).

To get data again from these sensors in both cases required a Roborio reboot (restarting the roborio code did not resolve this issue). We've verified that a Roborio reboot does not cause the navX MXP to be rebooted (the MXP 5VDC rail stays powered across the reboot). This, combined w/the fact the issue occurs w/both LabView, and Java points to a Roborio-side problem, and perhaps at a level lower than the Roborio-side libraries. [All testing was performed w/the latest RoboRio firmware/software versions.]

Our next steps are to refine our test setup to find the simplest reproducible case that will hang the I2C bus (to identify the range of the of time during which a Stage 2 brownout can cause the I2C/SPI bus to hang, and try to get some more info on the bus line states and errors received on the RoboRio side) - and also to reproduce the SPI bus hang on the navX MXP you have mentioned. Once we've got that we'll package up the info and send it along to National Instruments.

Until a resolution is found, these are the recommendations:

- We haven't seen the MXP TTL UART communication path to the navX MXP get hung by the disconnect, so using the MXP TTL UART this is recommended for teams experiencing I2C/SPI bus hangs.

- As noted before, if keeping the navX MXP powered in the face of a Roborio Stage 2 brownout is needed, use the USB interface 5VDC/GND leads connected to a 5VDC, 500mA output from the VRM.

One question for you: have you any evidence of brownouts in your Driver Station Logs during the period of time when the I2C bus was hung? Or do you think another condition may be triggering this case?

It would not report data on bootup. And there was no way to check if it was actually reporting data until the field connected, and by that point we had to be off the field. We did have the USB cord plugged into the VRM, so I highly doubt our issues were caused by a brownout. Everytime we tested in the pits it came up correctly. Just on the field it would only come up about 70% of the time.

[slibert]

It would not report data on bootup. And there was no way to check if it was actually reporting data until the field connected, and by that point we had to be off the field. We did have the USB cord plugged into the VRM, so I highly doubt our issues were caused by a brownout. Everytime we tested in the pits it came up correctly. Just on the field it would only come up about 70% of the time.

Can you please post the drive station logs for the games of interest, and any other data which might provide some insight as to what factors may be different on the field vs. in the pits?

The logs should point out any power-related issues, and may provide indications as to other factors that are coming into play in the on-field setting.

[rich2202]

We are going to try and incorporate the navX this weekend onto our practice bot. We are going to start with the sample code.

In order to avoid the I2C problem, how do we set it up for UART communications?

Thanks.

[slibert]

We are going to try and incorporate the navX this weekend onto our practice bot. We are going to start with the sample code.

In order to avoid the I2C problem, how do we set it up for UART communications?

Thanks.

The navX MXP can communicate via TTL UART, SPI and I2C; selecting the communication path is a software setting. No hardware changes are necessary as long as the "plug-n-play" installation method (http://code.google.com/p/navx-mxp/wiki/RoboRioInstall) is used.

For C++ (http://code.google.com/p/navx-mxp/wiki/CPlusPlus) / Java (http://code.google.com/p/navx-mxp/wiki/Java), currently only the TTL UART is supported in software; simply review the respective page on the navX MXP wiki for pointers on getting started.

For LabView (http://code.google.com/p/navx-mxp/wiki/Labview), in addition to I2C, both SPi and TTL UART are supported. We have done pretty extensive testing as have others on SPI, and it is the fastest way to communicate with the navX MXP. Our testing on SPI recently has focused on verifying brownout recovery, and for SPI that it is very robust, too. Our current understanding: if you have connected the navX MXP USB to the VRM, the SPI bus is reliable even if there is a RoboRio Stage 2 (or even Stage 3) brownout - and other teams are using this interface w/out problem. If the USB/VRM backup power source is not present, the navX MXP will get reset when a Roborio Stage 2 brownout occurs, but our testing has verified that the RoboRio/navX MXP SPI interface recovers in this case, too.

However, for those that experience trouble w/SPI, the Labview library also has a Serial Example, as well.

[marshall]

For LabView (http://code.google.com/p/navx-mxp/wiki/Labview), in addition to I2C, both SPi and TTL UART are supported. We have done pretty extensive testing as have others on SPI, and it is the fastest way to communicate with the navX MXP. Our testing on SPI recently has focused on verifying brownout recovery, and for SPI that it is very robust, too. Our current understanding: if you have connected the navX MXP USB to the VRM, the SPI bus is reliable even if there is a RoboRio Stage 2 (or even Stage 3) brownout - and other teams are using this interface w/out problem. If the USB/VRM backup power source is not present, the navX MXP will get reset when a Roborio Stage 2 brownout occurs, but our testing has verified that the RoboRio/navX MXP SPI interface recovers in this case, too.

However, for those that experience trouble w/SPI, the Labview library also has a Serial Example, as well.

Let us know if you have trouble with the LabView library. We're here to help.

[rich2202]

For C++ (http://code.google.com/p/navx-mxp/wiki/CPlusPlus) / Java (http://code.google.com/p/navx-mxp/wiki/Java), currently only the TTL UART is supported in software; simply review the respective page on the navX MXP wiki for pointers on getting started.


Since we use C++, I presume the default settings (TTL UART) is what we want.

[slibert]

We had a similar issue this past weekend in our QF2 match in autonomous. We believe there was a spi bus or gyro error which led to a value of 0 being returned continuously. This issue caused our robot to enter an uncontrollable spin and the FTA disabling our robot for the remainder of the round. I feel bad for our alliance partners because this issue did not let us move forward to the SF. We could have returned to open loop control upon start of teleop.....

Been thinking about what could be causing this issue.

Over the last few days extensive brownout testing w/SPI has been going on; no matter what scenario we throw at it, the LabView SPI library and the navX MXP keep recovering.

However, there was an update to the navX MXP firmware (http://code.google.com/p/navx-mxp/source/detail?r=481) back on Jan. 20 this year that fixed an issue in the navX MXP where it would hang if it encountered a UART error (which could be caused by electrical noise). Since the UART on the navX MXP is always active (as long as the UART dip switch is enabled), and if you didn't have this firmware fix, the navX MXP could lock up even if SPI is being used.

The latest version of the firmware is v. 1.0.482. You can display the firmware version number using the "Magnetometer Calibration Tool" (http://code.google.com/p/navx-mxp/wiki/Calibration).

If you do have a version earlier than v. 1.0.482, directions for upgrading the navX MXP firmware are here (http://code.google.com/p/navx-mxp/wiki/FirmwareInstallation).

[Thad House]

Been thinking about what could be causing this issue.

Over the last few days extensive brownout testing w/SPI has been going on; no matter what scenario we throw at it, the LabView SPI library and the navX MXP keep recovering.

However, there was an update to the navX MXP firmware (http://code.google.com/p/navx-mxp/source/detail?r=481) back on Jan. 20 this year that fixed an issue in the navX MXP where it would hang if it encountered a UART error (which could be caused by electrical noise). Since the UART on the navX MXP is always active (as long as the UART dip switch is enabled), and if you didn't have this firmware fix, the navX MXP could lock up even if SPI is being used.

The latest version of the firmware is v. 1.0.482. You can display the firmware version number using the "Magnetometer Calibration Tool" (http://code.google.com/p/navx-mxp/wiki/Calibration).

If you do have a version earlier than v. 1.0.482, directions for upgrading the navX MXP firmware are here (http://code.google.com/p/navx-mxp/wiki/FirmwareInstallation).

I know ours is 1.0.482, because I2C and SPI didnt work at all in the version that was preloaded, and looking at the flash drive we used to update it was 1.0.482. So at least on our end I don't think thats the issue. But I will double check.

And just to be clear, our issues over the past weekend were all seen on SPI. If it matters, we have the Update rate set to 60hz, The read is getting called once in the teleop loop, which is running every 20ms, and once in periodic tasks in a 20ms loop.

[slibert]

I know ours is 1.0.482, because I2C and SPI didnt work at all in the version that was preloaded, and looking at the flash drive we used to update it was 1.0.482. So at least on our end I don't think thats the issue. But I will double check.

And just to be clear, our issues over the past weekend were all seen on SPI. If it matters, we have the Update rate set to 60hz, The read is getting called once in the teleop loop, which is running every 20ms, and once in periodic tasks in a 20ms loop.

Thanks for clarifying, the details help; we've restarted the SPI longevity and brownout tests at 60Hz. They've been running for an hour now with no interruption, but it's a 24 hour test cycle.

Since you haven't sent any logs, I trust you've reviewed this and ruled out any other systemic issues including brownouts, Roborio CPU usage, loss of communication w/driver station, etc..

One other thing to check would be to look for any shorting between any of the pins on the navX MXP SPI connector header. These pins are electrically connected to the same MXP SPI bus pins used to communicate between the RoboRio and the navX MXP. If anything shorts the CS, SCK, MISO or MOSI pins (e.g., "swarf", or bent pins), that could cause bus communication failures. One other team encountered an issue where the Digital I/O pins on the navX MXP pin were accidentally shorted together (the pins were bent), so it's feasible this could be going on in your case.

[Thad House]

Thanks for clarifying, the details help; we've restarted the SPI longevity and brownout tests at 60Hz. They've been running for an hour now with no interruption, but it's a 24 hour test cycle.

Since you haven't sent any logs, I trust you've reviewed this and ruled out any other systemic issues including brownouts, Roborio CPU usage, loss of communication w/driver station, etc..

One other thing to check would be to look for any shorting between any of the pins on the navX MXP SPI connector header. These pins are electrically connected to the same MXP SPI bus pins used to communicate between the RoboRio and the navX MXP. If anything shorts the CS, SCK, MISO or MOSI pins (e.g., "swarf", or bent pins), that could cause bus communication failures. One other team encountered an issue where the Digital I/O pins on the navX MXP pin were accidentally shorted together (the pins were bent), so it's feasible this could be going on in your case.

I dont have the logs yet. They are still sitting in the trailer. Hopefully I'll have them tomorrow.

[IndySam]

We had to remove ours in the finals because our robot would sometimes just become impossible to drive when connected to the FMS. It would jump turn and move without driver input things it never did in practice.

I didn't see any brownout problems in the logs and until we unbag it for practice next week we do not have access to them.

At this point I doubt if we put it back on. BTW we are programming in Java.

[Kevin Sevcik]

So I'm vaguely thinking about getting one of these as an upgrade for our bot, but I'm obviously a little concerned about Thad and Sam's bugs. Might I suggest a separate thread with a poll or roll call of NavX MXP users, their programming environment, and their success/failure with the product? If problems are restricted to <5% of users, then I'd probably grab one and try my luck. If >25% of users are having problems, then I'll probably wait until things are more stable.

[slibert]

We had to remove ours in the finals because our robot would sometimes just become impossible to drive when connected to the FMS. It would jump turn and move without driver input things it never did in practice.

I didn't see any brownout problems in the logs and until we unbag it for practice next week we do not have access to them.

At this point I doubt if we put it back on. BTW we are programming in Java.

Typically, in a field-oriented drive (or auto-rotate-to-zero) application, the robot's drive train Z-axis rotation is impacted by gyro data; in other words, a gyro anomaly should impact only rotational motion. So while unexpected turning (e.g., spinning in circles) could point to a gyro issue, a robot that unexpectedly "jumps" and "moves" may be a sign of other control-path issues (Joystick->DriverStation->Network->RoboRio).

Please send along any information you can, it's not clear what's different about robots that are FMS-connected, other than the communication path between the Driver Station and the Robot software. The on-field log data for lost packets between DS and RoboRio, CPU time and communication latency might provide valuable info that might help other teams.

[Kevin Sevcik]

Typically, in a field-oriented drive (or auto-rotate-to-zero) application, the robot's drive train Z-axis rotation is impacted by gyro data; in other words, a gyro anomaly should impact only rotational motion. So while unexpected turning (e.g., spinning in circles) could point to a gyro issue, a robot that unexpectedly "jumps" and "moves" may be a sign of other control-path issues (Joystick->DriverStation->Network->RoboRio).

Please send along any information you can, it's not clear what's different about robots that are FMS-connected, other than the communication path between the Driver Station and the Robot software. The on-field log data for lost packets between DS and RoboRio, CPU time and communication latency might provide valuable info that might help other teams.This thread (http://www.chiefdelphi.com/forums/showthread.php?t=135329) is tracking an issue with Timers in Java acting differently immediately after a cold boot vs. after a warm boot. It's not directly FMS related, but it's something. The issue seems to be related to the Java Timer class depending on the RoboRIO system datetime, and the datetime initializing to 1970-something on cold start, and getting sync'd to the DS datetime on connection. The problem might just seem related to FMS connection because teams are using a different workflow during match vs. in the pit or practicing.

Also note the post in that thread about SmartDashboard logging buffering during long delays on the field and bogging things down after connection to the robot. There's definitely differences in the order and timing of control system events on the field vs. in the pits.

[Alan Anderson]

There's definitely differences in the order and timing of control system events on the field vs. in the pits.

The one obvious and mostly reliable difference is the robot being turned on and probably running user code for a while before the Driver Station is on the network. That's what brings out the timer bug, and the buffered data flood, and perhaps other things that are currently mysterious (e.g. Network Tables glitches). The workaround of restarting the robot program from the Driver Station seems to get past such problems.

[Kevin Sevcik]

The one obvious and mostly reliable difference is the robot being turned on and probably running user code for a while before the Driver Station is on the network. That's what brings out the timer bug, and the buffered data flood, and perhaps other things that are currently mysterious (e.g. Network Tables glitches). The workaround of restarting the robot program from the Driver Station seems to get past such problems.Off topic at this point, but when's the generally accepted best time to hit that reboot robot button prior to a match?

[Jared]

Off topic at this point, but when's the generally accepted best time to hit that reboot robot button prior to a match?

I hit it when our robot connects to the field and we're connected to the driver station. In case I don't have time, I also tether while in line and restart robot code.

[Thad House]

We did notice that rebooting the robot code only fixed the issue a few times. Most times it actually did not fix the issues, and the gyro still wouldn't return anything. Even resetting the gyro, then resetting the robot code did not help.

[Alan Anderson]

Off topic at this point, but when's the generally accepted best time to hit that reboot robot button prior to a match?

Restart the code as soon as possible. In general, that will mean within a couple of seconds of the Driver Station establishing communication with the Robot.

But don't reboot the robot. That takes longer than you want, and could delay the match start. Worse, though, is that it also fails to ensure that the real-time glitch won't happen again.

[slibert]

We did notice that rebooting the robot code only fixed the issue a few times. Most times it actually did not fix the issues, and the gyro still wouldn't return anything. Even resetting the gyro, then resetting the robot code did not help.

We are now able to repeatedly reproduce a condition in the lab when there's a RoboRio Stage 2 brownout for ~30ms (shorter than that, or longer than that does not cause the problem). In this condition, the Invensense chip on the navx MXP gets reset, but the navX MXP microcontroller doesn't - and at that point, the sensor no longer returns gyro values. This condition affects I2C, SPI and TTL UART. This condition doesn't occur for shorter brownout periods (since the navX MXP onboard capacitor provides enough capacity to ride it over). And it doesn't occur for longer brownout periods (since the navX MXP microcontroller gets reset). Your info about 20ms brownouts provided the clue needed to find this.

When this case occurs, the S1 and S2 LEDs on the navX MXP will not be lit, even though the red 3.3V LED will be lit. This is the tell-tale sign.

Once this happens, the navX MXP microcontroller needs to be reset - by pressing the navX MXP reset button, or rebooting the RoboRio.

This should be fixable via a navX MXP firmware update, we should have something in a week or so (the team is traveling to Central Valley Regional this weekend).

In our testing, this case does NOT occur when a secondary 5VDC power source is provided to the navX MXP via the USB connector, since in this case all circuitry onboard the navX MXP stays completely powered through the brownout event.

Based upon this, we reiterate the recommendation to provide a backup power source (via USB connection to the VRM) if Stage 2 brownouts are expected, and will also update this thread once a firmware update is available.

[Please note this does NOT appear related to the errors reported by a few teams during Week 1 events when connected to the FMS. Until we have more information the recommendation is, as previously stated by Alan Anderson, to restart the robot code immediately after first connecting to the robot on the field.]

[slibert]

Joe Hershberger of National Instruments has indicated that the USB ports on the Roborio are powered by a separate regulator with boost capability. The Roborio USB port remains powered all the way down to ~4 volts of VIN from the robot battery.

This is welcome news, as it means that to provide uninterrupted power to the NavX MXP even under brownout conditions, a standard unmodified USB cable connecting the NavX MXP to the Roborio is sufficient. In other words, it is not required to connect the NavX MXP USB port to the VRM in order to provide this backup power source.

[pluto7443]

We just got this board, and we are using it via USB. To get it to show up in the web interface, we have to unplug and replug in our usb camera. It seems that the only way to update the usb ports is a different device; this board will not cause an update to what usb devices are connected.

Also, once the roboRio refreshes and recognizes the navX the IsConnected() value we are printing to the dashboard continues to display false.

Any ideas would be helpful
thanks!

[eddie12390]

We threw ours on as soon as we got the robot out of the bag and it worked perfectly for all of our matches. We were using Java and the NavX was powered through USB.

[pluto7443]

We just got this board, and we are using it via USB. To get it to show up in the web interface, we have to unplug and replug in our usb camera. It seems that the only way to update the usb ports is a different device; this board will not cause an update to what usb devices are connected.

Also, once the roboRio refreshes and recognizes the navX the IsConnected() value we are printing to the dashboard continues to display false.

Any ideas would be helpful
thanks!

Just to clarify, we are using C++ and still no luck. Any teams running this board via usb/C++ successfully? If so, any insight for us?

[rich2202]

Joe Hershberger of National Instruments has indicated that the USB ports on the Roborio are powered by a separate regulator with boost capability. The Roborio USB port remains powered all the way down to ~4 volts of VIN from the robot battery.

This is welcome news, as it means that to provide uninterrupted power to the NavX MXP even under brownout conditions


Are you doing testing to confirm?

[rich2202]

We received the navX board from the production run that was available in mid February through Andymark. The first order of business is to use the addition DIO ports.

Per your documentation, the Digital IO Ports should map as follows:
navX -> RoboRIO channel Address
0->11
1->12
2->13
3->14
4->19
5->20
6->21
7->22
8->23
9->24

We were having trouble using them at the above addresses, so we tested them, and found our navX board to map as follows:
0->?
1->11
2->12
3->13
4->?
5->19
6->20
7->21
8->22
9->23

Note: We only checked RoboRIO ports that were in the documentation.

Question1: Does this batch of navX boards have a different mapping?
Question2: Any guess where we can find navX ports 0 and 4?

[slibert]

Are you doing testing to confirm?

We just returned from the Central Valley Regional; our robot played 4 practice matches, 10 qualifying matches and 2 playoff matches.

During the regional, the navX MXP was connected via USB cable directly to the RoboRio (as a backup power source in case of Stage 2 brownout), and also the MXP connector. No troubles were experienced (except for one, mentioned below); we got some nice kudos on our Mecanum drive system performance while we were there.

The one trouble at Central Valley Regional came because in one match the navX MXP partially popped out of the MXP slot (we forgot to add the screws to secure the navX MXP to the RoboRio). We then secured the screws and things ran well, including into the playoffs. We're putting together a best practices page on the wiki to include this.

This morning, the USB backup power was tested in the lab using our benchtop configuration. With the USB cable connecting the navX MXP to the RoboRio, the navX MXP stayed powered completely through RoboRIo Stage 2 brownouts, as expected.

Based upon this, the navX MXP USB <-> RoboRIo USB connection is a verified solution to overcoming RoboRio Stage 2 brownouts, all the way down to 4.4Volts. Once the voltage drops to 4.3 Volts, the RoboRio itself reboots, as well as the navX MXP - as expected.

[slibert]

Just to clarify, we are using C++ and still no luck. Any teams running this board via usb/C++ successfully? If so, any insight for us?

Is the code you are using selecting the SerialPort::kUSB serial port?

The sample C++ code shows how to connect via the MXP serial port:

serial_port = new SerialPort(57600,SerialPort::kMXP);

For usb, this needs to be changed to:

serial_port = new SerialPort(57600,SerialPort::kUSB);

[slibert]

A new "Best Practices" (http://code.google.com/p/navx-mxp/wiki/BestPractices) page has been added to the navX MXP Wiki. This page summarizes how to achieve high reliability and quality when using the navX MXP, and incorporates the valuable feedback provided by the ChiefDelphi community and lessons learned during the 2015 FRC season.

[slibert]

We received the navX board from the production run that was available in mid February through Andymark. The first order of business is to use the addition DIO ports.

...

Question1: Does this batch of navX boards have a different mapping?
Question2: Any guess where we can find navX ports 0 and 4?

All navX MXP boards are the same. The Expansion I/O documentation on the navX MXP Wiki has been updated, since as you noted the channel numbers start from 10 rather than 11. Thanks for helping us fix the documentation (http://code.google.com/p/navx-mxp/wiki/MXPIOExpansion) in this area.

On the navX MXP, the MXP Digital I/O Port 0 (RoboRio DigitalIO Channel 10) and Port 4 (RoboRio Digital IO Channel 18) were both tested using Java and we were able to toggle each signal using the Java DigitalOutput class, verified with an oscilloscope.

[slibert]

We just got this board, and we are using it via USB. To get it to show up in the web interface, we have to unplug and replug in our usb camera. It seems that the only way to update the usb ports is a different device; this board will not cause an update to what usb devices are connected.

When the navX MXP initializes, it drives the USB D+ line low for a second, then raises it. When this line goes high, the host (the RoboRio) re-enumerates the devices on the USB bus, at which time the navX MXP is discovered by the RoboRio, and will then show up on the web dashboard.

Here's how to verify it's working as expected (tested w/the latest RoboRio v. 23 release):

- Connect the navX MXP to the RoboRio via USB (and disconnect the camera).
- In a few seconds, the navx MXP should show up in the RoboRio Web dashboard (refresh the web dashboard page to see it update). The navX MXP should show up as ASRL3::INSTR.
- Hold the navX MXP RESET button down; the navX MXP should disappear from the list of devices in the RoboRio web dashboard (give it a second or two, and refresh the page).
- Release the RESET button; the navX MXP should reappear in the list of devices after refreshing the page again.

The above sequence was tested with another USB device (in our case, a Logitech USB webcam), and the test above worked the same when the USB webcam was connected.

If this test does not work correctly, and you have verified the USB cable you are using is working, please contact support@kauailabs.com.

[johnwiens]

Hi, A couple weeks ago our team got a NavX. So far we have been able to get good readings from the the gyroscope and we are impressed by how little the system drifts. However we have been unable to get any good values from the accelerometer. We are using C++ and the NavX example library thought we have found errors in the logic of the library, specifically errors in integrating velocity, and stopping the thread in the destructor. Has anyone else been having problems with C++ navX, and if so what might be the problem? We are getting values from the NavX however they are not accurate. Any ideas?

[forbes]

I can't seem to find the "Zero Yaw" VI in the NavX LabVIEW library.

I found it in the nav6 documentation here: http://www.kauailabs.com/onlinedocs/nav6/labview/Doc/ but can't find it in the NavX library. Am I missing something or should I be using a different VI?

[slibert]

Hi, A couple weeks ago our team got a NavX. So far we have been able to get good readings from the the gyroscope and we are impressed by how little the system drifts. However we have been unable to get any good values from the accelerometer. We are using C++ and the NavX example library thought we have found errors in the logic of the library, specifically errors in integrating velocity, and stopping the thread in the destructor. Has anyone else been having problems with C++ navX, and if so what might be the problem? We are getting values from the NavX however they are not accurate. Any ideas?

Hi John,

Glad to hear you're getting good quality gyro data.

The accelerometer-based pitch/roll measures work well for measuring tilt, and the linear acceleration data works well for motion/bump detection - however using the linear acceleration data to calculate the velocity/displacement estimates doesn't work as expected currently.

Even after correcting the velocity integration error in the C++ code, by graphing the acceleration and velocity data calculated by the Roborio-side code we can see that when the board comes to a stop after moving, the displacement unexpectedly goes negative. This appears to be due to accumulating error in the velocity estimates, but could also be due to errors in the linear acceleration data as gravity is removed from the raw acceleration data and the axes are rotated into "world frame". There's also some RoboRio-side code that discards acceleration data when motion is not detected that may need some more sophistication.

At this point, the plan is to tackle this issue in the off-season, and also publish the displacement estimation accuracy results - so teams can assess whether it's worth attempting a robot displacement estimate in autonomous mode, and if so for how long this would be reasonably accurate. Even after subtracting out acceleration due to gravity, there is pretty significant error building up over time and there will likely need to be some filtering performed in order to get usable results.

[slibert]

I can't seem to find the "Zero Yaw" VI in the NavX LabVIEW library.

I found it in the nav6 documentation here: http://www.kauailabs.com/onlinedocs/nav6/labview/Doc/ but can't find it in the NavX library. Am I missing something or should I be using a different VI?

The new navX MXP Library doesn't include the Zero Yaw VI; I'll mention that to the library author.

The implementation is pretty trivial, it's basically to record the current yaw value being reported by the navX MXP into a "offset" variable, and subtract this from subsequent yaw values. In addition, some "wraparound" handling is needed: if after subtracting the offset the value is < -180, then add 360, and if the offset is > 180, then subtract 360.

In case you'd find it helpful, the original LabView implementation of the Zero Yaw VI can be found in the roborio\labview\archived\ directory in the latest build zip file. You could even use this older library if you want (although it only supports TTL UART, unlike the new library which supports I2C and SPI).

[Caboose]

I can't seem to find the "Zero Yaw" VI in the NavX LabVIEW library.

I found it in the nav6 documentation here: http://www.kauailabs.com/onlinedocs/nav6/labview/Doc/ but can't find it in the NavX library. Am I missing something or should I be using a different VI?

The new navX MXP Library doesn't include the Zero Yaw VI; I'll mention that to the library author.

The implementation is pretty trivial, it's basically to record the current yaw value being reported by the navX MXP into a "offset" variable, and subtract this from subsequent yaw values. In addition, some "wraparound" handling is needed: if after subtracting the offset the value is < -180, then add 360, and if the offset is > 180, then subtract 360.

In case you'd find it helpful, the original LabView implementation of the Zero Yaw VI can be found in the roborio\labview\archived\ directory in the latest build zip file. You could even use this older library if you want (although it only supports TTL UART, unlike the new library which supports I2C and SPI).

Yes the original LabVIEW library had a 'zero yaw' VI. I decided against implementing it in the version I wrote as I wanted to try to keep the library as simple as to what the navX reports. If enough people would like a 'zero yaw' VI I could easily add one, but it is trivial for teams to implement this themselves as slibert has stated using a global variable for the offset.

I'll also work on writing the docs for the library, that or give it to a student to document, they like writing docs right?;)

[IndySam]

I can report that after using the USB cable for power backup and the practice of resetting the robot code after connecting to the FMS we did not have a single problem with our gyro at the Kokomo District event this weekend.

[AustinH]

Is there a Zero Yaw function in the MXP labview libraries that we're not seeing? The example code on the website is for the Nav6. Alternatively, is there any pseudo-code we can use to write our own zeroing function?

[Kevin Sevcik]

The new navX MXP Library doesn't include the Zero Yaw VI; I'll mention that to the library author.

The implementation is pretty trivial, it's basically to record the current yaw value being reported by the navX MXP into a "offset" variable, and subtract this from subsequent yaw values. In addition, some "wraparound" handling is needed: if after subtracting the offset the value is < -180, then add 360, and if the offset is > 180, then subtract 360.

In case you'd find it helpful, the original LabView implementation of the Zero Yaw VI can be found in the roborio\labview\archived\ directory in the latest build zip file. You could even use this older library if you want (although it only supports TTL UART, unlike the new library which supports I2C and SPI).Is there a Zero Yaw function in the MXP labview libraries that we're not seeing? The example code on the website is for the Nav6. Alternatively, is there any pseudo-code we can use to write our own zeroing function?I know it's a huge thread, but the answer is literally on the same page as your post. Please try a little harder next time.

[slibert]

We are now able to repeatedly reproduce a condition in the lab when there's a RoboRio Stage 2 brownout for ~30ms (shorter than that, or longer than that does not cause the problem). In this condition, the Invensense chip on the navx MXP gets reset, but the navX MXP microcontroller doesn't - and at that point, the sensor no longer returns gyro values. This condition affects I2C, SPI and TTL UART. This condition doesn't occur for shorter brownout periods (since the navX MXP onboard capacitor provides enough capacity to ride it over). And it doesn't occur for longer brownout periods (since the navX MXP microcontroller gets reset). Your info about 20ms brownouts provided the clue needed to find this.

Once this happens, the navX MXP microcontroller needs to be reset - by pressing the navX MXP reset button, or rebooting the RoboRio.

This should be fixable via a navX MXP firmware update, we should have something in a week or so (the team is traveling to Central Valley Regional this weekend).


A week of extensive brownout testing has been completed. After further investigation, it turns out the board exhibiting the previously-reported "lockup after brownout" symptom (see above) was one of our early prototype boards which, being hand soldered, had a faulty electrical connection. The "lockup after brownout" issue above has not been seen on several production boards that were tested for days straight using our "brownout torture test".

Based upon this, the navX MXP has been verified not to "lock up" during either normal operation or brownouts, and there is no need to update firmware, as long as you are running the latest production version: v. 1.0.482. If you're not sure which firmware version you have, there's info on the "Magnetometer Calibration" (http://code.google.com/p/navxmxp/wiki/Calibration) page on how to verify the version, and info on the "Firmware Installation" (http://code.google.com/p/navxmxp/wiki/FirmwareInstallation) page on how to install the latest version.

As stated previously, you can avoid brownouts altogether by connecting a USB cable between the navX MXP and the RoboRio. And pressing "restart robot code" (NOT "reboot RoboRio") after first connecting to your robot in competition is recommended to avoid issues related to the RoboRio clock being reset when the driver station connects.

[Joe Ross]

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]

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]

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

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]

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]

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]

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]

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

A process for displaying the firmware version number is on this page (http://code.google.com/p/navxmxp/wiki/Calibration); look under the "Connecting to the navX MXP" section.

[slibert]

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]

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]

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.


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

The tool reports firmware rev 1.0.482.

[randantor]

The issue seems to be happening much more often now, in our last practice match we had to restart robot code 3 times. I checked the log data, the 'Opened' indicator is false when we don't get data. I'm going to switch to I2C and see what happens.

[slibert]

The issue seems to be happening much more often now, in our last practice match we had to restart robot code 3 times. I checked the log data, the 'Opened' indicator is false when we don't get data. I'm going to switch to I2C and see what happens.

Thanks, this is a really helpful clue. This implies that the RoboRio Labview Libraries are sometimes not able to open the SPI port. There is error information that comes back from the Open VI, if you have a chance to get ahold of that error info, it could be helpful.

I'd be curious to know if the MXP TTL UART exhibits the same symptom.

[randantor]

I spent some time today messing with our NavX, and I think I've found a solution to the problem, or at least a workaround.

The SPI port open seems to be silently failing - there is no error information at the error output or in the SPI device reference. As far as I can tell, it's just outputting 255 for every read byte, and the 'opened' indicator being false seems to come from a checksum failure rather than due to an actual error code.

I tried switching to I2C, and the issue still happens with the same frequency, but there's an actual error message:
http://i.imgur.com/RBZKWMB.png

With both protocols, when communication with the NavX is working, just restarting the robot code will sometimes cause it to stop working, so it doesn't only happen on robot boot.

I then connected the SPI header on the NavX board to the roboRIO onboard SPI port, and switched to communicate through the onboard SPI rather than the MXP SPI, and it seems to work fine now. Looks like the issue is specifically related to opening the MXP ports. I spent a good 20-30 minutes repeatedly restarting the robot without issue, so it seems pretty solid to me.

TL;DR:
If you're having intermittent issues communicating with the NavX, try connecting it to the onboard SPI port.

[slibert]

I spent some time today messing with our NavX, and I think I've found a solution to the problem, or at least a workaround.

The SPI port open seems to be silently failing - there is no error information at the error output or in the SPI device reference. As far as I can tell, it's just outputting 255 for every read byte, and the 'opened' indicator being false seems to come from a checksum failure rather than due to an actual error code.

I tried switching to I2C, and the issue still happens with the same frequency, but there's an actual error message:
http://i.imgur.com/RBZKWMB.png

With both protocols, when communication with the NavX is working, just restarting the robot code will sometimes cause it to stop working, so it doesn't only happen on robot boot.

I then connected the SPI header on the NavX board to the roboRIO onboard SPI port, and switched to communicate through the onboard SPI rather than the MXP SPI, and it seems to work fine now. Looks like the issue is specifically related to opening the MXP ports. I spent a good 20-30 minutes repeatedly restarting the robot without issue, so it seems pretty solid to me.

TL;DR:
If you're having intermittent issues communicating with the NavX, try connecting it to the onboard SPI port.

Thanks for your continued research into this. At this point we've contacted National Instruments with the error info that's been gathered so far, and will also now send along your findings re: using the on-board RoboRio SPI/I2C ports vs. the MXP SPI/I2C ports. Not everyone using LabView/SPI or I2C is seeing these errors, so the more details like this, the better. As we make progress towards a final solution, we'll post that info to this thread.

[Kevin Sevcik]

I spent some time today messing with our NavX, and I think I've found a solution to the problem, or at least a workaround.

The SPI port open seems to be silently failing - there is no error information at the error output or in the SPI device reference. As far as I can tell, it's just outputting 255 for every read byte, and the 'opened' indicator being false seems to come from a checksum failure rather than due to an actual error code.

I tried switching to I2C, and the issue still happens with the same frequency, but there's an actual error message:
http://i.imgur.com/RBZKWMB.png

With both protocols, when communication with the NavX is working, just restarting the robot code will sometimes cause it to stop working, so it doesn't only happen on robot boot.

I then connected the SPI header on the NavX board to the roboRIO onboard SPI port, and switched to communicate through the onboard SPI rather than the MXP SPI, and it seems to work fine now. Looks like the issue is specifically related to opening the MXP ports. I spent a good 20-30 minutes repeatedly restarting the robot without issue, so it seems pretty solid to me.

TL;DR:
If you're having intermittent issues communicating with the NavX, try connecting it to the onboard SPI port.Are you guys running anything else through the MXP via the navX's I/O expansion? That's probably an important piece of info to track down this problem.

[randantor]

Are you guys running anything else through the MXP via the navX's I/O expansion? That's probably an important piece of info to track down this problem.

Yes, we have 2 quadrature encoders on MXP DIO 0, 1, 8, and 9, and a Banner sensor connected to MXP DIO 3.

[slibert]

I then connected the SPI header on the NavX board to the roboRIO onboard SPI port, and switched to communicate through the onboard SPI rather than the MXP SPI, and it seems to work fine now. Looks like the issue is specifically related to opening the MXP ports. I spent a good 20-30 minutes repeatedly restarting the robot without issue, so it seems pretty solid to me.[/B]

Here's another data point from National Instruments: to use the MXP SPI and I2C interfaces from the RoboRio, robot applications require access to the RoboRio FPGA in order to configure those resources. The FPGA is not required in order to configure resources for the on-board SPI/I2C, which are "fixed function". This FPGA is also not required in order to configure resources for the MXP TTL UART.

In addition to the onboard Roborio I2C/SPI interfaces indicated in randandtor's suggestion, the MXP TTL UART interface may also not be impacted by this issue.

We'll post any more relevant info as we get it.

[slibert]

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.

Hi Shahil,

Two teams have now reported success connecting the RoboRio on-board SPI connector to the navX MXP SPI Expansion connector, and changing the LabView library to specify the on-board SPI port rather than the MXP. Sounds like this has the potential to be a workaround in your case, too.

Also, as we continue to chase down this SPI issue, one detail (thanks to Kevin Sevcik for bringing it up) that could be helpful is: when you were experiencing this issue, did you have any other devices connected to the navX MXP Expansion IO ports (digital or analog I/O)?

[cjl2625]

This week, the sensor failed to initialize in 2 out of the 19 matches played.

Is there any documentation on how to connect the navX to the onboard SPI port? I'm not sure how that works.

Also: we're running a motor from the MXP DIO/PWM 0

[Thad House]

Is there any documentation on how to connect the navX to the onboard SPI port? I'm not sure how that works.

I don't think there is any direct documentation, but following the schematic helped us. https://navxmxp.googlecode.com/svn/trunk/schematics/navX_MXP_Schematic.png

Pin one is the pin closest to the MXP port on this connector. http://www.kauailabs.com/store/image/data/navx_mxp_boardphoto_top_annotated.jpg

What we did is connected SCK, MOSI, and MISO to the port on the roboRIO with a female to female pwm cable. Then you have to connect the CS pin to one of the 4 CS pins on the RoboRIO. That pin is the one you select when you select the spi port in LV.