ANNOUNCING: navX MXP Robotics Navigation Sensor

[slibert]

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

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]

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?

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.

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.

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=mklinker;1437227]

Originally Posted by slibert

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.

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 .zip file, it's in the enclosure directory.

[slibert]

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

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

Originally Posted by Pault

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]

Originally Posted by Joe Ross

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]

Originally Posted by Pault

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]

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

For this RoboRIO configuration, the recommendation is the "One-wire connect via 'Floppy-disk' Extension Cable". 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]

Originally Posted by slibert

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]

Originally Posted by Alan Anderson

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]

Originally Posted by stinglikeabee

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.