![]() |
IMUs
Hello! My team is fairly new to sensor-based driving, and we would like to consider using an IMU to help us out with positioning during autonomous. I'd like the robot to traverse a defense and correct its position and angle for a clear shot based on IMU or other sensor data.
At first I had hoped to use the new Analog Devices ADIS16448, but we used all of our FIRST Choice credits. So I'm looking for something else. I've found a whole bunch on SparkFun, but I have absolutely no experience with wiring such things, and even after reading through some datasheets I'm not sure if they are compatible with the RoboRio. Does anyone know if the FRC Gyro & Accelerometer Board that is coming free with every order is capable of delivering what I need? Here's the link the SparkFun ones. Any of these compatible and/or recommended? The navX is one more that I found which seems to be compatible, but it's $100. Anybody have experience with this model in particular? Thanks, Benjamin |
Re: IMUs
The NavX really is your best bet. It was developed specifically for FRC and has great documentation and code examples. Many teams used them successfully last year.
|
Re: IMUs
Yeah, it was looking to me like the best option. This post makes me doubt that a little though...it talks about ~1 meter drift per 15 seconds. I just wonder if that's too much. I'll still look into it. Thanks for your response. I'd appreciate any input from anyone else with experience!
|
Re: IMUs
Quote:
|
Re: IMUs
Okay. So I can do what I want without displacement? I can correct the robot's angle and its position after it crosses to the courtyard?
|
Re: IMUs
We used the NavX last year just as a gyro, and it worked fairly well. The firmware has been updated significantly since then, so we're liking it MUCH more now!
|
Re: IMUs
It really depends on what you want your sensor data to be telling you. You say you want to correct for angle and position. From that I take it you mean you want to drive over the defenses and have the robot head to a specific coordinate location on the field, with the right heading (presumably facing the tower). The problem with this plan of attack is that there aren't many sensors which can provide you an field-centric position (what you were asking for).
Sensors which can give you this information typically accumulate error over time, so you end up losing track of your coordinate position pretty quickly. If you can remove the need for the sensor to provide you an absolute (field-centric) coordinate position, the door opens wide for sensors that can give you accurate data over the duration of the match. Sensors that can provide you heading:
For reference, the way we approach this problem on our team is through a combination of a camera and gyro.
In short, we use the visual targets on the goal to localize our robot, instead of requiring a sensor to keep track of our absolute field position over the duration of the match. Don't forget you have a bunch of PDVs in your kit of parts that can be used to buy sensors. The one from digikey is good for $35 |
Re: IMUs
Not only does the Bosch BNO055 look like a great option, but your methodology for autonomous is very helpful! Thank you so much for the great response!
|
Re: IMUs
Concur Bosch BNO055 Absolute Orientation IMU is a good choice for Roll, Pitch, and Yaw (what is called an Attitude and Heading Reference System, or AHRS). It is cheap (well, actually free) and high performing (advanced fusion algorithm is already integrated).
If you use LabVIEW, see this post, the RoboBees released code for this sensor before kickoff. It gives guidance on calibrating it and will store the calibration for you so you can use it in a competition. As with any advanced sensor, sufficient time and experimentation is required to integrate into both the robot design and control system. You'll want to ensure that magnetic fields generated by the robot don't overly degrade the performance of any IMU. |
Re: IMUs
Quote:
Quote:
|
Re: IMUs
Quote:
Quote:
So if you just need heading (not yaw or tilt), this looks like a great option. Especially because its free! The Java code I linked to above should work with the 450 as well. It was used all last season without error. I obviously haven't tested it yet with the 450, since nobody has these sensors in hand yet. Also, I wouldn't be surprised if a future WPIlib update included a class for this sensor, since all teams are receiving them. |
Re: IMUs
Quote:
|
Re: IMUs
So, to poll the opinions of all of you who've responded (thanks very much btw!), I propose this question:
Should I use the BNO055 or the ADXRS450? This is the situation as I see it: They are both available to me for free (by voucher the BNO055 won't cost me anything). They both have Labview examples available. They are both probably above my learning curve so I'll be posting here for help (I'm a second year programmer, and my team has never touched sensors). I'd like to use one of them to help me build an autonomous that can traverse a defense and score a high goal. I want the sensor to help me get to an approximated shooting location in the courtyard. Vision code will identify our location relative to the goal, and then the sensor will correct the angular displacement and square us to the goal. So, with the above in mind, and the goal that I have, BNO055 or ADXRS450? Thank you all again so much for your help! |
Re: IMUs
Hello!
Robotics engineer specializing in inertial nav here. Pretty much all inexpensive chipscale MEMs IMUs are going to perform fairly similarly in terms of noise and stability over time, which is to say, fairly terribly when trying to do positioning. There are many barriers that make this difficult, but the way to think about it is that you're integrating acceleration twice to find position, and the sensor rarely if ever is calibrated such that motionless reads exactly zero acceleration - something called a sensor bias. In practice, what this means is that if you just sit there integrating, you'll slowly drift off into outer space, and with these sensors the drift will be meters per minute (and it's exponential). Some sensors and software packages are capable of detecting zero-motion conditions (literally, when the acceleration looks like it's so small that the robot assumes there is no motion), and takes that opportunity to get a better estimate of its biases (known in the lingo as a zero-velocity update, or ZUPT), but with how often a FIRST robot is stationary I doubt it's going to get a solid estimate during the game. The answer to many of life's difficulties to finding position with an IMU is to have an external aid of some sort - usually an encoder is preferred - and then fuse the IMU data and encoder data (encoders can be used as velocities or incremental position estimates, we've had better luck in incremental position mode, simply because differentiation is usually noisy). That allows you to take different measurements, even ones that seem to disagree slightly, and put them together in a way that trusts particular sensors in different scenarios. The typical way to do that is a kalman filter, but that may be beyond the scope of all but the most dedicated FIRST teams. Instead, what is usually done when you must have displacement but don't have the time and/or resources to do a full inertial nav system is to use an IMU in AHRS mode and then use the encoders to get incremental position. Use the AHRS to find the direction of your motion, and the encoders to get the magnitude of the motion, and hey presto, a not-terrible position estimate. Note that it will degrade pretty rapidly, and spinning your wheels without moving (like getting in a shoving match) will destroy the position estimate, but it circumvents a lot of the typical issues of an inertial-only estimate - error is linear with time instead of exponential, and guaranteed to stop drifting when motionless. Using external aids like the vision system and field markers is the hands-down best way to ensure good field position estimates, but is often difficult and/or computationally expensive. FIRST does a great job of making some of the more advanced sensors easy to use, but it still takes an awful lot of finagling to get everything working right. In short, if you're going to do something clever like that, leave plenty of time for tweaking. Sparks |
Re: IMUs
Quote:
Quote:
Quote:
Quote:
|
| All times are GMT -5. The time now is 03:01. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi