We have one of the ADXRS450 from FIRST Choice, and it works pretty well overall. Works out of the box, drifts a little but not terribly. The issue is we’d like to code a few “automagic” buttons to go to specific angles to face certain field elements (we already have the math worked out, and rotating the robot very slowly works), but the ADXRS450 is limited to 300 degrees/second before it can’t keep up with how fast you’re turning. What gyros does your team have / recommend? Is this a pipe dream? We could turn slower of course, but could still get hit while turning and end up losing the gyro again… thoughts, CD?
https://www.sparkfun.com/products/10612 is one we’ve used in the past with some success. We did have occasional issues with it dropping out, and i’m not sure if it was the gyro itself, or the I2C libraries/hardware on the RIO… But, for a fast robot, this might work decently for you!
Pigeon IMU from CTRE. 2000 degrees/s and it has integration of an accelerometer and gyro so you get a drift similar to what you’d find on other top-of-the-line IMU’s like the Nav-X. Even better is that you can connect it over the can bus with 2 wires rather than mucking about with I2C or any other wiring scheme. You can also wire it in through a ribbon cable to one of your motor controllers if you are using Talon SRX’s.
http://www.ctr-electronics.com/gadgeteer-imu-module-pigeon.html
We used the analog kit-op-parts gyros up through 2014. In 2015 we went to the same one that 971 uses. Did it again in 2016. The Pigeon took a lot of the headache out though.
How fast does your robot rotate?
Depends on how fast we tell it to… 
Honestly though, pretty fast if we spin at full power.
Really though, even if we slow it down to cap at 300 degrees / second, there’s the possibility of getting pushed around a bit by someone playing defense or something and losing track of where you’re facing that way. I’d like the drivers to be able to turn quickly in teleop, but still have quick and easy “go to this angle” buttons for quick alignment.
Your robot does probably turn pretty fast at full power, but you never need to turn more than 180degrees to snap to a location - can your robot really accelerate to 300 deg/s AND decellerate back to zero in 180degrees of motion?
I don’t think I’ve ever seen a FRC robot that can do that.
Do you have data that shows that you are hitting that limit?
The issue here isn’t going to be the rate then. The issue of drift over the course of a match can’t just be overcome with a “better” gyro. You are always going to have noise in a gyro system. A gyro is very good at measuring rotational acceleration, however things like vibrations, linear accelerations, and electrical noise can be read from the sensor as rotational acceleration, causing drift.
An IMU will help with this issue, it will take inputs from other sensors (accelerometers, other gyros, magnetometer) on the same chip, and use them to filter the gyro signal to help minimize the drift. The NAV-X, Pigeon IMU, and ADIS16448 are all used by FRC teams successfully, and are pretty well documented. I think you will have a lot more luck with one of these IMUs than you would trying to find a better quality gyro. Even with an IMU there will be some drift over the course of a match. Inertial sensors in general do much better at tracking short term relative movements than they do at tracking position or orientation over a period of time.
This is true. However, with good calibration, you can get the drift down to ~2-3 degrees over the course of a match.
That’s likely enough to snap to a rough position - and if you want to use that for shooting, you’ll need either vision or manual alignment anyways, so not being exactly exact isn’t a problem.
You have gotten drift to only a couple of degrees with just a gyro? Or with an IMU?
We’re just using a gyro (the one on the WCP Spartan board, the ADXRS453), running onboard the RoboRIO at 200hz. After our fairly long calibration sequence (~45 seconds, to the dismay of our autonomous programmers 
) we’ve been getting around 2 degrees per match of drift.
Yep, the 453 is an excellent gyro. Though I don’t think you really need 45 seconds to calibrate it.
It’s rare that the actual rotation rate of the robot by itself will saturate the gyro. What’s more likely is that collisions will. A short period of saturation can throw a gyro off by a substantial amount.
That can usually be solved by giving the drivers the ability to rezero, or by making your calculations relative to something else, like a camera angle.
Oh yeah, it’s definitely overkill. We got that value last year, when our calibration logic was a little touchy, and just haven’t changed it since then. I’ve been meaning to tweak it to see if I can get it to a lower value without sacrificing accuracy, so thanks for the reminder :D.
We use a navX-MXP from Kauai Labs. It works pretty well I think, though we didn’t use it last year so it hasn’t gotten a whole lot of competition use.
Agreed. Nothing will come close to comparing with the navX for FRC use.
It’s increadibly easy to set up, small, and has accuracy beyond belief. Gyros we have used in previous years all had some slight drift and we’re some what complicated to use.
First use out of the box we were able to drive around blind for a little and go back to where the gyro thought was 0 to within an inch or 2.
Would highly recommend the navX, only slight con is that it takes up a USB port.
I’m curious what data and performance testing you’ve done on competitive products to make that statement. There are a number of IMU’s on the market other than that navX. Have you tested them?
I am in no way disparaging the NavX. We’ve played with it and it works very well. However, I’m an engineer and I try not to make statements that product A is better than product B unless I have seen a marked difference in some measurable.
We’ve been using the ADXRS453 since the 2015 season. I’m not sure how our code lines up against the WPILib code for this family of Gyros, but ours has multiple years of execution time on it… bug free. https://github.com/Team2168/2016_Main_Robot/tree/master/src/org/team2168. In our implementation, comms with the sensor runs in a separate thread from the main robot. So timed events, like calibrating, don’t block main program execution.
We have code kicked off from Robot.java which automatically detects drift while the robot is disabled (prior to match start) so if you’ve got a bad calibration (robot powered on and then moved onto the field - not stationary during initial calibration) it will get a new zero. This code is orig. stolen/inspired from 245’s 2013? code, and we’ve improved upon it over the years.
Last year we also spent some time with the BNO055. This is an IMU that’s in the $30 price range. https://github.com/jcorcoran/BNO055_FRC Definitely a favorite of mine.
Both of these have more than acceptable performance over the duration of an FRC match.
Well, I’m biased a bit, but wanted to share my thoughts:
Pigeon specs are similar to navX-MXP/navX-Micro for 6-axis performance from a yaw drift rate, make sense as they use the same chipset which performs the 6-axis fusion onboard. The navX-MXP/navX-Micro firmware for calibration has improved over the two years, but it’s likely safe to assume the Pigeon orientation angle accuracy after calibration is similar (sounds like it, according to published specs).
Pigeon update rate is 100hz, navX-MXP/navX-Micro are 200hz, so if you want faster update rate the latter is superior. 200Hz is great if you want to drive rapid PID loops that manage the orientation of multiple wheels on the robot.
We will have to see if there’s any CAN bus contention limits the Pigeon IMU from consistently achieving update rate at 100hz, CTRE should be able to say on that. At 1mbps w/the PDP, 4 talons and a PCM all chatting on the CAN bus, and 100hz Pigeon updates there may be some contention starting to arise - that remains to be seen. However, in the configuration to connect directly a Pigeon to a Talon this would likely not be a concern.
From a software perspective, the Pigeon docs indicate it provides yaw, pitch and roll - however the navX-MXP/navX-Micro also (perhaps because it’s not limited to the 8-byte CAN bus data payload sizes) provide synchronized quaternions and a sensor timestamp as well. Timestamped Quaternions (and the fact that navX-MXP/navX-Micro have multiple simultaneous communcation interfaces) are being used effectively in the Sensor Fusion Framework (SF2) to correct for video processing latency, and create timestamped orientation histories. As a contributor to SF2, I can say that more features along this line are coming. Software is key to enabling more autonomous features.
For newer teams the number of examples, the training materials and the large community that support navX-MXP/navX-Micro and help each other too are awesome.
So in addition to orientation accuracy specs which I believe are very similar, there are several system and software level capabilities to also consider.
There we go :D. That’s great info. Thank you.
I believe the Talon srx update rate is at a default of 10 ms. So a matching update rate of the Pigeon at 10 ms means you’ll be receiving 1 new sample per loop. I’m curious though how much the law of diminishing returns comes into effect when trying to run things at an update rate of 10 ms versus 5 ms. It’s well beyond the scope of what I know how to do to measure the effect of that. You probably have more experience with that than I do since we rarely worry about update rates (except on shooters…).
I suspect based on the maximum number of devices allowed on the Can Bus that the update rate will not become bottlenecked, but like you said we should know pretty shortly. We haven’t seen a problem on ours with 13 srx’s.
We could probably do 5ms. In all honesty when I started with the Invensense example, it was set to 10ms, and I just never tried changing it.
Originally I was planning on using a different IMU chip entirely but then we couldn’t source it in time, I had to switch. In so doing I just left all the timing the same as the previous IMU.
If you guys think that’s an important improvement, we’ll add it to the list.
In my testing the update rate seemed adequate so I didn’t dig further.
This is not a problem. Pigeon only adds ~6% CAN bus util whether it be CAN or gadgeteer.(Section 11.4).
If you guys think that’s important, we’ll add it to the list.
In my research none of teams seemed to care about time-synchronization.
Maybe most teams just “aren’t there yet”. But if a bunch of teams start asking for it, we’ll probably implement. Synchronizing signals across CAN frames is something we know how to do.
All in all there are many options for good nav, including NavX [and Pigeon :)].
Inertial navigation has been a hole in our product line for a while, so I was eager to fill it. I think what makes Pigeon unique is the on-the-fly temperature compensation, multiple connection strategies, robustness against power-dips, fast boot-cal, price, and future features where our CAN devices work together.