I’m using the Gyro.getAngle() method and displaying this value on Smart Dashboard. When I make our robot turn clockwise and then counterclockwise for a few seconds, the numbers the gyro are returning are consistently increasing small numbers (it won’t go into the negatives even if I just turn the robot counterclockwise). It takes about ten to twenty seconds for the angle to reach 1 degree. We’re using the NavX gyro and I’m not sure what the issue could be. Any help would be appreciated thank you!
We had a similar issue with the PigeonIMU. It would increase and decrease as expected so if we turned 90 deg clockwise it would read 90, but it would drift fairly quickly, maybe a degree every 3 seconds. We found a small metal shaving under the PCB (between PCB and the electrical board that it was bolted to). When we removed that shaving the issue went away. Might be something to look for.
One thing to check would be the sensor calibration. What you describe sounds similar to what can happen if the sensor is not calibrated correctly for its current orientation.
By default, the sensor is calibrated at the factory with the top of the board pointed up (away from the earth’s surface). However, when teams mount the board in a different configuration, it’s important to re-calibrate the sensor. The reason this is so critical is because it’s important for the sensor to use the correct axis for the “yaw” (Z-axis) angle - it’s needs to know “which direction is up”.
You can read more about the “Omnimount” feature, and the related Factory Calibration, at this link. I encourage you to review it, and consider going through the Factory Calibration process.
It’s not obvious to me what you could have shorted that would cause a drift of 3 deg per second.
What could happen is that …
[1] the Pigeon was resetting due to a power short.
[2] You were losing communication due to bad cabling or metal shaving.
If using the Talon-ribbon-cable strategy, you should have self-tested the Talon to see if it disconnected/reconnect the Pigeon. That would test [1]. (See self-test details in Pigeon IMU User’s guide). Additionally the Pigeon LEDs would have signaled that it was boot-calibrating. Additionally the status would have reported this event assuming you are polling it in your code (which our manual recommends strongly).
Driver messages would confirm [2] or red LED bliping on Pigeon LEDs.
[3] Pigeon User’s guide also has procedures for testing the typical sources for IMU error, follow them then apply the corrective steps if need be.
We were using a ribbon cable to a Talon. I am not 100% sure what the issue was, as it was only an issue three times.
The first time I got to test motion profiles and rotate to angles with the pigeon was in week 6 of build season. When I tried to make the robot rotate to +35 degrees it did, and then I forgot to disable it before making a change in the auto routine (needed to drive further forward before turning and run the intake in the other direction). By the time I made the change the robot had turned quite a bit more. That was the first time the issue happened.
The second time I reset the robot to the autonomous starting configuration and ran the routine again, and let stay enabled while I watched. It rotated to the desired angle and then after 10-15 seconds it rotated again. I was using a simple Proportional controller to hold a heading so presumably it needed some time for the error to become large enough to overcome mechanical resistance.
The third time I just made the robot print the Pigeon angle to the SmartDashboard, and I noticed the pretty severe drift. Even when the robot was disabled (and thus not moving at all) it was approx 1 degree every 3 seconds.
At that point we had to go put everything away as it was pretty late at night. At the next meeting, the electronics board came off as we needed to add two more Talons. To make space for the Talons the Pigeon got moved and that is when we found the metal shaving underneath.
I am not sure if that was necessarily the root cause of the problem, but since removing that shaving, and moving the Pigeon maybe 2 inches from its previous position, we haven’t had an issue with it.
It sounds like your NavX might not be plugged in/recognized by your RoboRIO.
How are you connected to the NavX? Is it plugged directly onto the surface of the rio, like the KOP gyro, or are you cabled to it with USB (or one of the other connection methods)?
When you start up your robot, do you see a print statement in your driver station console indicating that a connection has been opened between the gyro and the rio?
Are the green status lights on the NavX lit when plugged in?
EDIT: What library are you using to work with the gyro? The one provided by Kauai Labs or a different one?
Does this happen a lot, or did it happen once, or once in a great while?
This probably isn’t the problem, but I’ll share my experience with the NavX. Great sensor. Love it. Reasonably priced, very easy to use for FIRST, all that jazz. One thing I have found, though, is that it really, really, wants 12 volts.
Last night, trying out yet another autonomous variation. (Lots more variations this year than usual) Drive backwards for a bit. Turn. Drive backwards again. So far so good. Turn one more time. Uh. oh. Robot starts spinning, and doesn’t stop. What’s up with that. Check logs. Unreasonable values for NavX.
Oh, yeah. That problem. Change robot battery. Problem solved.
I’ve seen several occasions when the first thing to fail on the robot due to a weakening battery is our NavX. It doesn’t fail completely, but it gives wrong answers intermittently. If the robot starts driving funny when testing code that has run a lot of times before, I check the voltage now, and check logs, if any, of NavX sensor. Something in there wants 12 real volts, or it starts acting up. The behavior described in the OP is one of the failure modes I have seen.
A couple general gyro things to keep in mind:
Gyros measure rotational velocity. To get robot angle, you have to integrate this measurement.
While standing still, there will be noise in the signal. Ideally this is mean-zero noise, so it won’t impact your reading over time. In the real world, the noise tends to be non-zero. Integrating a slightly non-zero value over time will cause the integrated value to slowly increase or decrease. This is commonly referred to as “gyro drift”.
When a robot powers on, it’s always a good idea to “calibrate” a gyro. Many libraries or hardware have this built in. If not, you may have to do it yourself. The basic function should be the same though: measure the rotational velocity for some period of time while standing still (aka, measuring only noise), then calculate the average value of the noise. For all future readings, subtract this average from the reading. This theoretically makes the noise mean-zero.
You have to be very careful not to bump the robot during this calibration procedure. We instruct our drive team in this every year.
Though very small, MEMS Gyros do in fact have moving parts. Slight deflections in suspended components are how the velocity is measured. In theory, a large mechanical disturbance to the system could cause this part to become “re-aligned”, causing a different zero-offset, and driving the need for re-calibration. The effect of this could be better or worse based on the quality of the gyro.
I wouldn’t expect a simple few seconds of rotation to drive a re-cal need. We’ve been using an ADXRS453 (~$75 for one axis gyro-only) for a few years now and never had the re-cal need from something like that. So I doubt this is the only thing at play here.
Another thing to consider is the maximum measurement limit of the gyro. Ours for example is limited at 300 deg/s (if memory serves properly). Any time you exceed (or really come near) that rate, expect the angle measurement to acquire some error, and hang on to it until you reset the robto.
However, having never used the NavX, I have little specific advice I can provide, unfortunately.
NavX-MXP is powered by the RoboRIO 5V “user” rail on the MXP port.
RoboRIO cuts power to the MXP “user” rail whenever it detects a Stage 2 brownout.
The navX-MXP best practices discuss this important issue, and how to use a USB cable to provide power even when this occurs. After following this recommendation, NavX-MXP will not lose power even during stage 2brownout. All users are encouraged to review the best practices.
+1. I had this exact issue. We solved it by removing the board and clearing it of metal shavings on and under the board. Worked like a charm.
Lesson we learned: Always cover your electronics when drilling/sawing/etc.
1 Like