ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

• Automatic Balancing

• Rotating to a given Angle

• Motion/No-Motion Detection

That is pretty impressive, I can't wait to see what some teams can do with this.


Any videos of it in action?

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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/sh...highlight=nav6

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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!

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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?

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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/w...InstallOptions

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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?

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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?

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

navx MXP units have arrived at AndyMark and are now available for sale at the AndyMark online store.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

Just bought two, pretty excited about these.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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. :)

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

Have you calibrated the magnetometer?

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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?

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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?

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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?

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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!

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

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

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

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

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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);

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

AustinH, you could also consider using a MXP extension cable. 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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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!

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Here is the command prompt window text
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!

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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:

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

Rolling back to Java 7 worked! Thanks!

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

Hmmmm...I guess that's possible.

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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. :(

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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?

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

I too was wondering this and asked in this post earlier. According to their website, we will not be able to purchase the navX mxp board until February 7th at the earliest.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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!

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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.

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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

Re: ANNOUNCING: navX MXP Robotics Navigation Sensor
 

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