ANNOUNCING: navX MXP Robotics Navigation Sensor

[bmammen]

Originally Posted by ayeckley

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.

[Alan Anderson]

Originally Posted by bmammen

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]

Originally Posted by ayeckley

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]

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

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

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

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.

[slibert]

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

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]

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

Originally Posted by jSoft

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]

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

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.