The random drift you describe sounds like electrical noise. If the wiring from the sensor goes parallel to motor power wires, you might find the integrated value acting like that. Try shielded wire routed well away from high currents and see if it stops misbehaving.
Not sure if the WPI library was modified recently, but in 2014, when we used a regular gyro, we had similar inconsistent drifting problems. With field-centric swerve, things sometimes got really ugly.
There’s a discussion about that on this thread: http://www.chiefdelphi.com/forums/showthread.php?p=1399062#post1399062
In 2015, we got the NavX MXP, which offered further improvement, and worked great for our swerve last year. (and since the NavX comes with its own libraries, you don’t need the code modifications I mentioned)
If your team used your AndyMark First Choice points, you should have received an FRC Gyro & Accel board with your order free of charge. This sensor should provide much better performance!
I can personally vouch for the navx-mxp and WCP Spartan Board. While in my experience (which involves a sample size of exactly two of each board, and is thus in anecdotal territory) the navx has significantly less drift, neither drifts significantly anyways and thus the difference is meaningless.
The WCP Spartan board has a adxrs453 on it. The adxrs453 is an amazing chip. The drift should be 15 degrees/hour. The spec that the spartan board really wins on is the “Ultrahigh vibration rejection: 0.01°/sec/g”. On previous KOP gyros, I saw significant coupling between acceleration and angle. When I had the robot accelerate hard, it would measure that it had turned. On the adxrs453, I’ve had no issues with that. 254, 1678, 971, 973 and 1323 all ran a previous version of the board last year and will be running it again this year.
The navx has a magnetometer, so it can detect the earth’s magnetic field and use that to adjust. That will result in less drift as you noticed, if drift is the metric you want to use for heading quality.
(Full disclosure: I lead the design of the Spartan Sensor board and worked with WCP and others to make it legal this year and make it available for sale. Thanks a ton to RC for helping make this board available to everyone.)
For 50 credits, it’s a bargain. Probably one of, if not the best bargain part in the entire catalog. The ADIS16448 dev kit retails for over $800. That’s a lot of IMU for your credits.
You’re right, the ADXRS450/453 is a nice gyro core on its own! If you’re looking for high VRE (Vibration Rectification Error) take a look at the ADIS16448. It has much better VRE and lower drift vs the 450.
I went into last year a skeptic and I came out a believer: the NavMXP is going on every FIRST robot from now on until something better comes along (and I suppose that will be a long time, if ever because honestly, 1-2 degrees during a match is pretty much as good as you’ll need for almost any algorithm I’m likely to use).
I was also a skeptic of a $99 gyroscope, especially seeing as most of its features are useless to us (ie field oriented drive). Apologies to anyone standing near the field when our auton was misbehaving last year, it shouldn’t happen anymore with the navx.
The Nav6/NavX-MXP takes literal rocket science technology and makes it available for mere mortals. The underlying tech (i.e. the Invensense MPU-9250) would have been a State Secret for most of my life (I’m not kidding).
It is a great chip but it isn’t the most user friendly. $99 for a FIRST friendly wrapper is a bargain (imho), especially because some of that $99 was probably going to be spent on an MXP IO expansion board for your RoboRIO anyway.
We had a lot of inconsistent behavior (unacceptably high drift, sudden rapid changes in angle) from the one you show in the picture, and went to the ITG-3200 gyro/accel available on Andymark this year.
Programming a custom interface took some effort, but so far we have had great results. Drift is less than 1 degree during a match and we can get a reliable calibration much faster. We have it integrating the rotation rate in a separate thread, and then we query it once per driverstation cycle to get the angle.
