ANNOUNCING: navX MXP Robotics Navigation Sensor

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

[Mastonevich]

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

[slibert]

Originally Posted by Mastonevich

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

Originally Posted by slibert

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

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]

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

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 for details on this. You can also use the navX MXP UI 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

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