ANNOUNCING: navX MXP Robotics Navigation Sensor

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

Originally Posted by 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.

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:


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]

Originally Posted by 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:


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]

Originally Posted by 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:


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]

Originally Posted by Kevin Sevcik

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]

Originally Posted by randantor

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]

Originally Posted by Shahil_FRC

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

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]

Originally Posted by cjl2625

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/t..._Schematic.png

Pin one is the pin closest to the MXP port on this connector. http://www.kauailabs.com/store/image..._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.

[slibert]

Originally Posted by 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

Thanks for the input that you're controlling a motor via PWM 0, it's very helpful.

In addition to Thad's post on this topic, you may find the following helpful.

You will need to connect a total of 4 wires between two sets of connectors which are shown in the navX MXP RoboRio installation photo. The RoboRio SPI connector is at the top left of the photo. The navX MXP SPI connector is the middle row of 6 pins, just above the white arrowhead indicating the Y (Roll) axis.

First, carefully connect the following pins between the RoboRio SPI Connector and the navX MXP SPI Connector:

RoboRio <--->  navX MXP

CS0     <--->  CS
MISO    <--->  MOSI  [Note that the pin names are different on each side]
MOSI    <--->  MISO  [Note that the pin names are different on each side]
SCLK    <--->  SCLK

(Note: Don't connect the RoboRio SPI Connector's CS1, CS2, CS3, GND, 3.3V and 5.V pins)

Look closely at the silkscreen on the navX MXP, and you'll see the pin names labelled directly underneath each of the SPI pins.

Second, in your code, select the correct SPI port. In LabView, you'll need to modify the "navX Open.vi" and change the SPI Bus constant (this is an input parameter to the WPI Library SPI Open vi) to "SPI Onboard, CS0". By default, this constant is "SPI MXP".

[taichichuan]

Originally Posted by 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 released the nav6 Open Source Inertial Measurement Unit, 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 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). 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 and Kauailabs. MSRP is $99.

More details available in the navX MXP datasheet and at https://code.google.com/p/navx.

Unfortunately, the examples fail to build in the 2016 control system betas. The compiler complains about:

"invalid new expression of abstract class type 'AHRS'" and dies a horrible death.

[slibert]

Originally Posted by taichichuan

Unfortunately, the examples fail to build in the 2016 control system betas. The compiler complains about:

"invalid new expression of abstract class type 'AHRS'" and dies a horrible death.

Yes, the current NavX-MXP libraries are compatible with the 2015 WPI Libraries. A breaking change was introduced in the beta 2016 WPI libraries.

Work is underway to update the NavX-MXP C++ and Java libraries and sample code to work with the as-yet-unreleased 2016 WPI Libraries.

A post on this forum will announce when that 2016 WPI Library-compatibility is available, and will occur sometime before kickoff.

[taichichuan]

Thanks! We're looking forward to seeing the updates!

[taichichuan]

If you need someone to help test the updates with the 2016 Beta libraries, we'd be happy to help.

Mike A.
FRC #116