Magnetic Field Impact on the NavX

Technical Sensors
1

Realistically how far away does the NavX have to be from the Motors and any other magnets on the robot? We really don’t want to field test this one with by hovering the magnet close to the NavX. Will enclosures protect it?

http://www.pdocs.kauailabs.com/navx-mxp/intro/frequently-asked-questions/

"Aren’t the magnetometer (compass heading) readings unreliable when the navX-MXP is used on a Robot with powerful motors?

Yes, this is correct. If navX-MXP is mounted nearby any energized motors, the magnetometer’s ability to measure the (weak) earth’s magnetic field is severely diminished.

However, at the beginning of each FIRST FRC match, the robot is turned on for about a minute before the match begins. During this time period, the motors are not energized and thus do not add magnetic interference that would disturb the magnetometer readings. Once the magnetometer is calibrated, navX-MXP will return either an accurate magnetometer reading, or an indication that its measurement of the earth’s magnetic field has been disturbed.

Magnetometer readings taken at the beginning of a match, when combined with the navX-MXP yaw measurements, enable a robot’s pose and absolute heading to be maintained throughout the match. This feature of the navX-MXP is referred to as a “9-axis” heading."

2

Depends upon the motors, likely 3 feet or so at a minimum. A well-calibrated navX-MXP will display magnetic disturbance indications when it is too close, so that can be used to get feedback.

This is an advanced feature and could take a lot of effort to get working well. Our robot this year is too short to use the magnetometer. The magnetometer update rate is very low and it can only take a reading when still for a second as well as not magnetically disturbed. So for those reasons most teams stick with the six-axis yaw angle for orientation tracking, rather than the compass heading.

3

Thank you for replying

I see getFusedHeading() which supports the 9-axis. I did not see any methods that discussed the 6-axis. Can you please elaborate on how the 6-axis works?

Thanks

4

Sure, the 6-axis headings fuse the 3-axis gyroscope and 3-axis accelerometer data (a total of 6 input sensing axes) into a single set of data which forms a 3-axis coordinate system, and provides measures of Yaw, Pitch and Roll.

So this data (sometimes referred to as 6-axis data, my apologies for introducing a confusing term) can be retrieved via:

getYaw()
getPitch()
getRoll()

There is more discussion of the 3-axis coordinate system and Yaw, Pitch and Roll on the navX-MXP terminology page.

5

So if I understand correctly

Mecanum_cartesian(getPitch(), getRoll(), PID, getYaw())
Arcadedrive(getRoll(), getYaw()) // exclude getPitch because cannot strafe in arcade

Thank you

6

First of all, Pitch and Roll angles are not used w/the drive subsystems to control driving unless you are trying to have the robot auto-balance(not tip over). And that’s an advanced feature. They’re also useful for determining this year when the robot is on one of the ramps (like the defense platform, or the batter) - but that’s not directly related to controlling the drive system. So let’s take pitch/roll angles off of the table for the rest of this discussion.

The Yaw angle is typically used for:

  • Field-centric drive
  • Rotate to Angle (for instance, rotate to point to the “head” of the field)
  • Help the robot drive straight (since most robots don’t drive in a perfectly straight line)

For Mecanum (and more generally, Holonomic Drive systems):

  • Field-centric drive is a 4th parameter to the Mecanum drive function that helps the software know how much to “twist” the X/Y coordinates from the joysticks. The other inputs would be the X, Y and Z (rotation) velocities from the driver joystick.

  • Rotate-to-Angle: in this case, the rotation amount from the joystick is ignored, and the output from the PID controller [which uses the yaw angle as input] is used as the amount for the drive system to rotate. If spinning in place, the X/Y axis values are 0.

  • Drive Straight: in this case, the rotation amount from the joystick is ignored just as in Rotate-to-Angle, but this time the robot is being driven in the X or Y axis directions as well, and once again the output from the PID controller [using the yaw angle as input] is fed as the rotation parameter to the drive system.

[The code for these is shown in the navX-MXP Examples]

Tank (Arcade) Drive systems:

Fundamentally, this is more limited than a holonomic drive system (e.g., mecanum), since:

  • It cannot strafe
  • It cannot rotate around it’s center and move in a linear direction simultaneously.

So, in this case, one axis (the Y axis) of the driver joystick is used to indicate the amount of forward motion, and a second joystick axis is used to indicate the amount of rotation (some drivers use two joysticks, which is “tank” drive style). These joystick axes are the “forward” and “rotate” rate amounts the ArcadeDrive() function.

Now back to our use cases:

  • Field-centric drive: no can do on a tank drive system
  • Rotate-to-angle: In this case, the “forward” rate would be some value (zero if you wanted to rotate in place, more if an arc was acceptable), and the PID controller output (using the yaw angle as input) would be used for the rotation amount.
  • Drive Straight: The “drive forward” rate would be a non-zero value, and the PID controller output (using yaw angle as input) would be used for the rotation amount - which would have the effect of correcting the robot so that it would drive in a straight line.

So the Arcade Drive code would look something like:

Rotate-to-Angle Use Case:

ArcadeDrive(0, YawAnglePIDControllerOutput)

Drive-Straight Use Case:

ArcadeDrive(JoystickYAxis, YawAnglePIDControllerOutput)

7

Thank you very much for the detailed reply it is greatly appreciated.