|
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
|