Last week we tested auto extensively with our clone robot making 16 degree, 90 degree and 30 degree turns, all executed perfectly. Clone sat until yesterday when we resumed testing. After some very puzzling robot behavior, we discovered our NavX is reading 15 degrees below what it should be, that is a 90 degree rotation is reported by the NavX as 75 degrees. We tried resetting, reconfiguring (vertical mount) new battery all to no avail. We are stumped. Maybe the NavX has gone bad but I thought we would see if there are any other ideas.
- Check for metal shavings
- Remove the NavX from the MXP port and clean it out, along with the prongs of the NavX.
- Plug it into a PC and use the NavX software to test the NavX by itself
- Reply with results
Programmer from 4450 here.
We’ve completed your troubleshooting steps and here’s what we found:
- No metal shavings found in MXP port or in prongs of NavX.
- Plugged into a PC, yaw issues still occur. It’s short by ~15 degrees per 90 degrees of actual rotation. (So at 90 degrees of physical rotation it’s 15 degrees short, at 180 degrees it’s 30 degrees short.)
Have you guys tried retuning the PID values to see if that makes a difference? If it helps then the Navx may not be busted.
Also, the way that the degrees short changes based on how much you want to turn really does sound like a PID issue, so try increasing the value of P by a small amount and see if that helps it.
So the error a constant proportion, if so a temporary bandaid solution might be to simply multiply your gyro reading by (want/what have) ie. by 90/(90-15). If it is a constant error this should bring the values back to correct.
I don’t think it is a PID issue, because when they plugged it into the computer (completely separating it from the robot code, and the NavX doesn’t have any on-board PID loops that I am aware of), leading me to believe that it is a physical problem with the device.
That’s a good idea, but they’ll need to make sure to watch closely in case the gyro goes downhill fast (especially if you are headed full speed at the scale ) If you go this route, add some safety checks, stuff like “if the robot has rotated more than 2° in this 20ms loop, something has gone terribly wrong, stop everything”
With everything you described, alongside what I have seen from NavX boards in the past, it is most likely a electrical issue with the board itself. You could try to contact Kauai Labs and ask about this issue, but I doubt anything below board-level repair would fix this issue. For this competition, I would run with the previously mentioned “band-aid” solution and hope for the best.
Here are a few suggestions on this:
If you haven’t already, we encourage you to re-run the Factory Calibration process, while the sensor is mounted on the robot.
Vibration can definitely negatively impact the performance of the sensor fusion process which is performed in the Digital Motion Processor on the navX-MXP. The two points of guidance here (there are more, in the “Best Practices”](https://www.pdocs.kauailabs.com/navx-mxp/guidance/best-practices/) documentation) are: (a) ensure that the sensor is mounted to the RoboRIO such that it is essentially part of the main robot chassis mass [this helps ensure that shock is absorbed throughout the robot chassis before the sensor] and (b) consider an anti-vibration mount, for example four small squares of rubber or foam at each corner of the roborio, to help absorb high-frequency vibration.
It’s recommended to mount the sensor at or near the robot center of rotation. This should not account for large amounts of error, but is recommended.
Finally, I’m curious what are the sequence of motions are you attempting. We have one other report of larger-than-expected error and may be related to a 90 degree clockwise turn followed by a 90 degree counter-clockwise turn. We’re still gathering data on this, so if you’re seeing the problem in this configuration, let us know.
Oh yes, there’s one other thing. As described in the Best Practices, it’s possible that the robot underwent a Roborio brownout; in this circumstance, the RoboRIo cuts power to the 5V (and 3.3V) rail on the MXP port. This would cause the navX-MXP to reboot, and then it would enter the startup-calibration process, during which the sensor data values will fluctuate. The solution (as described in the Best Practices) is to ensure a USB cable is connected between the RoboRIO and the navX-MXP. This cable is not needed to exchange data, but ~does~ ensure that 5V is provided to the board - even during a Stage 2 brownout. Not sure if that might have happened during your tests, but it’s definitely possible, and the “backup power USB cable” will resolve that.
Yes, we recalibrated.
Yes, we mount as described.
The motion is simple. We start after initialization of robot and zeroing yaw on navx. make on 90 turn to the right and its off. Nothing complex here.
Also note there is no brownout. The error occurs with fresh battery and no load of significance on the robot.
New: we are mounting the navx at an angle from vertical and this has not been a problem. But we find if we move the navx to vertical it reads accurately. If we return it to the approx 65 degree angle of normal mounting it reads off.
Again, this mounting works fine on our comp robot and on this clone until it just quit. If something is wrong with the board I would have expected moving to vertical would still show an error. Just a bit confusing.
And we recalibrate after any change in mounting position.
Ok, I’m not surprised with yaw (Z-axis) accuracy results since it’s mounted at that angle. The reason that this will yield much less than optimal results is that the navX-MXP sensor fusion fuses accelerometer data together with gyroscope data. If the Z axis is not perpendicular to the earth, additional errors are introduced, and the results will be highly variable. Accelerometers measure the earth’s gravity as acceleration, so that has a big impact.
To get the desired results, navX-MXP needs to be mounted so that one of the axes are perpendicular to the earth’s surface (which means there are 6 possible ways to mount it). And after it’s mounted in one of those 6 orientations, it needs to be Factory Calibrated (the Factory Calibration figures out which axis is “Z, Up [with respect to earth’s surface]”. navX-MXP does not automatically switch to a new calibration whenever the new “up with respect to earth’s axis” changes (because each axis has different calibration data).
Let me know if any clarification is needed.
I understand what you are saying and am familiar with the doc. Historically we have mounted the navx vert or horiz on the roborio. This year the RR is on an angle and before building a separate mount for the RR we tested extensively with the navx on the angled RR and found it to work fine. We have competed successfully with our comp robot and our clone worked fine until it quit.
Now it is interesting that if we move the navx to vertical it works correctly but it worked on an angle for months as well. I don’t know what the problem is but something changed and the angled mount now generates the 15 degree error consistently.
We will have to move the navx or add a correction factor for the time being.
Thanks for the feedback.
> Now it is interesting that if we move the navx to vertical it works correctly but it worked on an angle for months as well. I don’t know what the problem is but something changed and the angled mount now generates the 15 degree error consistently.
This isn’t a conclusive answer, but my belief is that one of two things happened (a) the board was recently re-Factory Calibrated or (b) the angle at which it was mounted shifted somewhat.
Regarding (b), we’ve had reports of navX-MXP working acceptably when mounted at some small number of degrees (in the 10s-20s of degree range) away from vertical; but we also know there’s a point at which the angle is severe enough to begin generating inaccurate results. I’m not sure exactly what the angle is, but it’s possible that something changed and the result was the mounting angle changed sufficiently to cross into the area where accuracy is notably impacted.
Did you perhaps rotate the RIO 90 degrees around the short axis (a “flat spin”) between when it worked and when it didn’t?
The fun continues…to save time we decided we would determine a correction factor to apply to yaw values returned by the navx and get back to testing. This worked well enough to get back to auto testing. In one routine the robot drives forward from start, turns 18 degrees and then drives forward on the new heading. However, while the turn worked (with correction) the robot would jerk left on start of straight drive forward on new heading. We reset the yaw on the navx at the start of our drive straight routine as it uses the navx to monitor and correct the drive. What is happening is that after we call to reset the yaw value, on the first read of yaw from navx in the drive loop, the yaw is still reading 18 degrees, which causes the jerk (abrupt turn). We have never seen anything like this before either. We had to put a .3 sec delay in front of the reset yaw to get the first returned yaw to be zero.
This navx appears to be bonkers…but now it is time to get ready for districts so will have to put this aside and hope the robot in the bag does not develop any of these issues. After districts will try to find some time to test and see if the reset issue is affected by the navx mounting angle.
I don’t understand what you are asking. There would be no “flat” spin but there was movement around the angled (due to our mount) axis due to driving the robot. Literally, as best we can remember, it was working, we turned the robot off, it sat a week and then when we turned it back it had this problem right off or at least as soon as we tried an auto test.
Depending upon which language used, which update rate is used, and which interface used, there can be a delay of up to about 150 milliseconds upon resetting the yaw until a new reading from the sensor reflecting the update is received. Best response occurs when using Java/C++ and at high update rates and over SPI or I2C.
We are using mxp interface. To be clear, what update rate are you talking about?
The update rate is the number of samples per second genrated by the sensor. The default is 50. Other available update rates include 66, 100 and 200Hz. With higher update rates, new data is received more often, so that decreases latency of the yaw reset - and it comes with the cost of (sllightly) higher CPU usage in the navX-MXP libraries.
The below assumes you use Java and communicate over the SPI interface on the MXP Port:
// this constructur initializes comm using MXP SPI, with the default update rate (50Hz):
ahrs = new AHRS(SPI::Port::kMXP);
// this constructor initialzes comm using MXP SPI, with 100hz update rate:
byte updateRate = 100; // 100 Hz update rate
ahrs = new AHRS(SPI::Port::kMXP, updateRate);
P.S. As a note, the other things some teams do (if the reset yaw delay is a problem for them) is to implement “reset yaw” directly in their code. To do this, simply store away the current yaw angle when “reset” occurs, and then subtract it from each subsequuent yaw angle. This has the benefit that you can have control over whether the new “zeroed” angle is 0 degrees or perhaps some other angle (for instance, if your robot is initially lined off at an offset of 45 degrees relative to the field).