My team is doing it’s first ever mecanum drive bot this year, and we are looking for a gyroscope. I’m a bit lost on what I am able to use. We have a few analog gyros and one ADIS16448, but I was wondering what some other options were.
Same as the best gyro for non-mecanum. Another thread on the topic: What gyro to use?
Other popular ones are:
- Pigeon IMU
- ADXRS450 (breakout has been in KOP) or ADXRS453 (DigiKey sells a breakout board)
- SpartanBoard (which uses the ADXRS453)
Good discussion here as well, including commentary from some of the Analog Devices folks who built and support the gyros available through FIRST Choice: Gyro and accelerometer doc trouble.
During the 2017 off season my team did a mecanum drive base and we had problems with our ADXRS450 gyro keeping up with the rate of turning of our drive base I would recommend the Pigeon IMU over all of them because the NavX uses weird angle mechanics where it only measures between 0-359 degrees where the Pigeon allows you to have both negative and positive angles infinite in both directions (I believe its infinite).
Silly question: Why do you think you have to use a gyro just because you’re using mecanum drive? A team with very strong programming/controls experience (developed during the off-season!) MAY be able to gain an 10-20% (of control/stability/whatever) using gyro feedback in a mecanum drive system. However, it’s not a necessity. We have used mecanum drive in 3-4 of our 8 seasons, and only used a gyro once - for autonomous in StrongHold. The rest were open loop, and really good drivers. I can’t understate the importance of that - good drivers (i.e. those who have have lots of stick time) can compensate for just about anything that a gyro can. We’ve wasted a TON of time tracking down stupid issues with gyros (calibration, drifting, etc.). In hindsight, it would have been better spent on driver practice.
While I can’t speak for the OP, for my team, the answer is field-oriented drive. This is completely open-loop, but frees the driver from having to mentally translate the robot reference frame to the field reference frame when deciding which way to push the joystick. In my time with my team, we’ve had one driver with an innate ability to do this translation effortlessly in his head. For everyone else, it’s been a struggle, even with practice. And even if you have an awesome driver who can do this translation with, or even without lots of practice, I propose that your driver might be even better if he or she didn’t have to devote part of his or her brain to doing this translation while driving the robot.
We are just starting experimenting with this. Our first test was literally yesterday. I was pretty unimpressed by the results. We were planning on rotating while translating, (i.e. the plan was to drive toward the rocket ship, and end up at the proper orientation when we got there, without having to make separate actions for the required rotation and translation) and when we tried it, the robot ended up going the wrong way. More experiments are necessary, but it looks like the gyro measurements from our NavX were lagging enough that it couldn’t compensate.
In theory, field oriented drive should just be adding a simple reading to the driveCartesian function of the MecanumDrive object. In practice, have you encountered real world problems that had to be dealt with to make it work?
Did it translate the wrong way (and if so in one axis, or both) or rotate the wrong way?
What port are you using to communicate with the navX? IIRC the update rate is far higher via SPI and I2C than over serial (either TTL or USB), though I don’t remember if the slower update rate over serial would be slow enough to explain your symptoms.
We never tried any autonomous driving with FOD, it was strictly for teleop. Does your robot behave strangely in teleop as well, or only when you try to automate it?
Looking at our code from last year, we did invert the yaw reading from the navX when passing the yaw value to MecanumDrive():
XAxis = Robot::GetOI()->GetDriverJoystick()->GetRawAxis(0);
YAxis = -Robot::GetOI()->GetDriverJoystick()->GetRawAxis(1);
RotAxis = Robot::GetOI()->GetDriverJoystick()->GetRawAxis(2);
Robot::driveTrain->MecanumDrive(XAxis, YAxis, RotAxis, -RobotMap::ahrs->GetYaw());
I’m not sure whether this was strictly necessary or was a side effect of other things that got inverted while troubleshooting.
navX-MXP SPI communication has very little latency, and is not noticeable by human operators; navX-MXP was designed for use with Field-Oriented Mecanum. Please feel free to log a support ticket at https://www.kauailabs.com/support/navx-mxp/login.php if you are seeing human-observable lags.
That was the biggest problem. Coding error. I’m still not sure all the signs are right, but right now, if they are wrong, they are cancelling each other out.
The other problem was that one of our wheels was running a bit stiff, and so our strafing wasn’t working well. We compensated while just strafing, but while rotating, and therefore constantly changing directions, it did not work well at all.
Now, though, it seems pretty happy.
Good to know. For testing, we are using our 2015 robot, which has the Rio mounted at an odd angle, so we have the navx connected by USB. For our competition robot, we were planning on using the mxp port, but we’ll switch to SPI if that would help. After the fixes mentioned above, it’s working fairly well. Not perfect…but more testing should show where the remaining problems are.
Always more testing…
Make sure you’re not using serial comms with your NavX. It’s slow and it uses blocking reads.
The best practices section in the navX-MXP site has a complete list. It includes: mount well (to avoid vibration); The Z axis accelerometers are lowest noise, so ideal response is with Z axis pointing up; sensor at center of rotation and mass for best results; don’t mount at odd angles; use usb as a backup power source to gracefully handle RoboRIO brownouts; use SPI for lowest latency and if you really need low latency increasing the update rate to 100Hz can help a little. And finally, add a “zero yaw” button to your driver station/joystick.
3946 did Mecanum in 2014. Not our smartest decision, but we erroneously thought that the game which would come to be known as Aerial Assault would be light on defense, focussing on those assist points; we were wrong. I don’t know exactly how, but we managed to burn up every gyro we owned before bag day. Fortunately, our prototype robot was also usable for practice after bag, and our drivers spent enough hours driving on the parking lot behind the concession stand to get the hang of robot-oriented mecanum. By the time we went to competition, the lack of a “field oriented” frame of reference was a non-issue. Heck, I learned to drive the robot in about 15 minutes well enough for a rather impressive demo to my co-workers, and I have never been any good at using video game controllers.
As another sample point, we ran an ADXRS453 on our mechanum drivetrain in 2017 and liked it quite a bit. Mechanum drives in general will have more vibration than west coast during normal operation, so picking a gyro with good noise rejection is somewhat more critical. We did not try any other options though, so I do not have much to compare against.
I’m the lead SW mentor for my team. This is our setup:
BNO055 Motion Processor - this is a great IMU. I have yet to see any drift.
Talon SRXs - using encoders on all wheels and doing velocity closed loop control
We wrote our own Mecanum class to use SRX’s more advanced features and a more interesting driver control. I would be happy to share our code if you choose the BNO055 and SRX route.
We solder the BNO055 to a MOR Board and plug it into the MXP port on the RIO. It comms over I2C. My BNO class handles everything for you. I couldn’t expect my kids to write a device driver from a 150pg datasheet and understand register addressing and bit masking.
The reason I like the BNO055, is that it does all the integration and fusion of the gyro and accelerometers in the chip and a very high frequency. This yields a very clean rotational position.
In case anyone on this thread decided to go with the ADIS16448 or the ADIS16470, there’s an important update from Team Update 15 on these boards. More info here: [IMPORTANT] Updates Involving the Functionality and Legality of Analog Devices IMUs and Gyro Boards