ANNOUNCING: navX MXP Robotics Navigation Sensor

[rich2202]

Originally Posted by stinglikeabee

I don't think it would be cost-effective to inventory custom cables. Teams should be plenty capable of cutting one end off of a USB cable

A lot of USB cables are 24-28 AWG. Per R38, it would need to be 22 AWG.

Also, a lot of those type cables to not strip nicely.

Finally, regarding custom cables: I'm guessing that Andymark has sold 200 of the navX boards, and have another batch arriving soon. If half bought the cable, it might be worthwhile. I know that we would buy two for the two navX boards we have.

[Joe Ross]

Originally Posted by rich2202

A lot of USB cables are 24-28 AWG. Per R38, it would need to be 22 AWG.

You would be using the 500ma output on the VRM, which allows 28awg or larger.

[protoserge]

Originally Posted by rich2202

A lot of USB cables are 24-28 AWG. Per R38, it would need to be 22 AWG.

Also, a lot of those type cables to not strip nicely.

Finally, regarding custom cables: I'm guessing that Andymark has sold 200 of the navX boards, and have another batch arriving soon. If half bought the cable, it might be worthwhile. I know that we would buy two for the two navX boards we have.

Not necessarily. Is there a spec on the current required for the NavX? I don't see anything on the board that indicates it would require greater than 500mA, thus it would be covered by the signal level output (28 AWG).

Digikey and Mouser don't carry custom cables (at least as listed under USB cables) aside from the regular USB male plug to cable leads. Unless you want to pay $20-30 a cable, it's unlikely worthwhile for any vendor to carry the mini USB to bare wire cable.

I think one off-the-shelf solution may be this: http://www.amazon.com/USB-Female-Min...le+usb+to+mini and this http://www.digikey.com/product-detai...363-ND/1531290. I'll keep searching for a single cable.

[slibert]

Originally Posted by stinglikeabee

Not necessarily. Is there a spec on the current required for the NavX? I don't see anything on the board that indicates it would require greater than 500mA, thus it would be covered by the signal level output (28 AWG).

Digikey and Mouser don't carry custom cables (at least as listed under USB cables) aside from the regular USB male plug to cable leads. Unless you want to pay $20-30 a cable, it's unlikely worthwhile for any vendor to carry the mini USB to bare wire cable.

I think one off-the-shelf solution may be this: http://www.amazon.com/USB-Female-Min...le+usb+to+mini and this http://www.digikey.com/product-detai...363-ND/1531290. I'll keep searching for a single cable.

NavX MXP current consumption is <= 250 mA.

[Pault]

Our practice chassis has been running off the 5V 500mA rail using USB for a while now, and we have never experienced a problem*. Literally just took a mini USB cable (buy it at RadioShack or Amazon), cut off the other end, peeled back the shielding, stripped the red and black wires, and plugged it in. It's not that hard.

[rich2202]

1) Should the Magnetometer be calibrated at each event?

2) Should we start posting questions in the Control System, Sensor sub forum, and start each title with "navX"?

[jojoguy10]

Speaking of calibrating the Magnometer,

Is there an easy way to do it? Right now, you need to turn it to every axis (+ and -), which I get. But, how do people handle the cable coming out? Do you guys just hang that part off the edge of the table?

We're probably going to re-calibrate it before our first district just to be safe.

Thanks!

[slibert]

Originally Posted by rich2202

1) Should the Magnetometer be calibrated at each event?

Magnetometer re-calibration is theoretically only necessary when changes to the structure of the robot are made which add/remove metals.

As noted on the wiki, "Initial Gyro Calibration" (press/hold the cal button) is encouraged whenever the ambient temperature changes significantly. This should likely be done when first arriving at an event, and is expected to be the only per-event calibration required unless mods like those mentioned above occur.

[Joe Ross]

Originally Posted by slibert

Magnetometer re-calibration is theoretically only necessary when changes to the structure of the robot are made which add/remove metals.

Our robot has significant pieces of aluminum as well as a motor that move from 12 inches away from the the navx to only about 2 inches away during normal operation. However, at this time, we're only using the yaw from the navX. Do non-ferrous metals matter? If so, does it only matter for teams using the compass?

[slibert]

Originally Posted by Joe Ross

Our robot has significant pieces of aluminum as well as a motor that move from 12 inches away from the the navx to only about 2 inches away during normal operation. However, at this time, we're only using the yaw from the navX. Do non-ferrous metals matter? If so, does it only matter for teams using the compass?

Ferrous and non-ferrous metals can impact magnetometer readings (each type impacts in different ways).

However they should not impact the inertial sensor readings; theoretically, only compass readings could be impacted.

[slibert]

Originally Posted by rich2202

Should we start posting questions in the Control System, Sensor sub forum, and start each title with "navX"?

This thread is getting rather long, indeed. Yet, it also serves as a useful "digest" of the issues are encountering and what the solutions and options are.

We're updating the navX MXP Wiki (esp., the FAQ and Troubleshooting sections) w/the key issues that arise here. navX MXP is a new and unique product, and tailored specifically to the FIRST FRC community, so the best result for all will almost surely come from this type of continued interaction; often, the answers come from other people in the ChiefDelphi community.

My recommendation is to continue to post new questions to this thread (after of course reviewing this thread's current contents and the FAQ/Troubleshooting pages on the Wiki).

Any navX MXP customer who has continued trouble even after reviewing this thread and the Wiki documentation can contact us at support@kauailabs, or private message me.

Longer term (say, this summer after Nationals are over) we can work on setting up a different system. As always, your feedback is welcome, as the goal is to provide the best support possible to FIRST FRC teams.

[rich2202]

The reason I thought of posting new threads is that it makes it easier to find an answer to questions already asked. For example, if I wanted help setting up navX for field drive with Mecanum wheels, it would be hard to search through this thread (already 11 pages) for relevant posts.

[slibert]

Originally Posted by rich2202

The reason I thought of posting new threads is that it makes it easier to find an answer to questions already asked. For example, if I wanted help setting up navX for field drive with Mecanum wheels, it would be hard to search through this thread (already 11 pages) for relevant posts.

The "Search this thread" tool provides a simple way to search for answers on this thread.

[randantor]

What are the units for the raw gyro output in the LabVIEW Library? It looks like it could be radians/second but I'm not entirely sure.

[slibert]

Originally Posted by randantor

What are the units for the raw gyro output in the LabVIEW Library? It looks like it could be radians/second but I'm not entirely sure.

Raw Gyro data is a 16-bit signed value, in hardware units. Conversion to a real-world value requires knowledge of the sensor Full Scale Range (FSR).

The Gyro FSR is configured for 2000 deg/sec. To convert raw gyro data to deg/sec, simply divide the raw gyro value by 2000:

float curr_deg_sec_x = (float)raw_gyro_x / 2000.0;

Note that gyro values are calibrated, so have had offsets automatically applied to them by the Digital Motion Processor (DMP) on the Invensense MPU-9250 silicon.

[Raw acceleration data is similar; in this case, in units of Gs and since the Accelerometer FSR is configured for +/- 2G, the calculation is:

float curr_accel_x = (float)raw_accel_x / 2.0;]

Most users don't access the raw gyro data directly, since to be useful it typically requires the user software to integrate the data - and for typical use cases, this work is offloaded to the navX MXP processor.