Using IMUs For Odometry

The future is autonomous robots. Whether that means electric cars with rebranded adaptive cruise control, or delivery robots that are actually just remote control cars, the robots of the future will need to decide how to move, where to move, and be capable of tracking their own movement. This is the problem of odometry, or how far a robot has traveled. There are many ways to solve this problem, but GPS isn’t really accurate enough and putting encoders on wheels doesn’t account for slipping. What’s really needed for robotic odometry is multiple sensors, and for that we have [Pablo] and [Alfonso]’s entry to the Hackaday Prize, the IMcorder.

The IMcorder is a simple device loaded up with an MPU9250 IMU module that has an integrated accelerometer, gyro, and compass. This is attached to an Arduino Pro Mini and a Bluetooth module that allows the IMcorder to communicate with a robot’s main computer to provide information about a robot’s orientation and acceleration. All of this is put together on a fantastically tiny PCB with a lithium battery, allowing this project to be integrated into any robotics project without much, if any, modification.

One interesting aspect of the IMcorders is that they can be used for robot kidnapping issues. This, apparently, is an issue when it comes to robots and other electronic detritus littering the sidewalks. Those electric scooters abandoned on the sidewalk in several cities contain some amazing components that are ripe for some great hardware hacking. Eventually, we’re going to see some news stories about people stealing scooters and delivery robots for their own personal use. Yes, it’s a cyberpunk’s dream, but the IMcorder can be used for a tiny bit of theft prevention. Pity that.

32 thoughts on “Using IMUs For Odometry

  1. Imu odometry is accurate for about 3 milliseconds if very well calibrated. Accelerometers are horrible for odometry because calculus. You’re taking an estimate calculated from an estimate calculated from a noisy sensor reading. You get error piled on every step of the way. There’s a reason neither Oculus, Vive, nor cardboard or daydream use accelerometers for position, and vr doesn’t even need much precision. It just does not work. Now if you paired the data with other types of sensors, that’s a totally different and possibly workable story. GPS and wifi positioning are ubiquitous because they are much more reliable. You may only have accuracy to a city block, but you can be sure it’s in that block. Imu will give you dubious estimates of what planet you’re on. It’s a nice thought, but accelerometers just aren’t accurate or precise enough yet. They may be some day.
    Those modules would be great for tattling on couriers mishandling packages, through.

    1. The project page goes into more detail, but he’s not using an IMU the way you’re talking about. He’s using it to measure the rotation of a wheel. So it acts like an encoder.

    2. > and vr doesn’t even need much precision

      VR does need a very high precision else the world feels jittery and you feel uncomfortable or dizzy. The Oculus DK2 had 0.05 mm precision at 1.5 m with a VGA sensor, the Rift is probably much better than that with its 720p sensor.

  2. I’m sure the pilots of airplanes from the U-2 to the SR-71 to the B-2 to the Boeing 787 would be a little surprised to hear that the IMUs they navigated with every day were next to worthless. Funny, I thought we managed to make them work pretty well. If a B-52, say, can take off in North Dakota, fly to the Middle East, drop bombs, return and land without additional updates, I’d call that pretty good.

    Granted, any IMU needs to be “trimmed” to correct for systematic errors. Nowadays the nav systems depend on GPS, but at least in the beginning, we always assumed that our GPS satellites would be the first things to go in a shooting war.

    I have no idea what IMUs are in the B-52s being used today, but back in the 80’s it was the most accurate IMU ever built. The gyro drift rate was lower than the proper motion of some stars. In practice, the crews would spin the gyros up, align the platforms, then shut down the drives. The gyros would continue to spin through the duration of the mission, with no additional updates or re-alignments.

    I think maybe Joe is thinking of the MEMS gyros and accels you can get these days, For sure, they are pretty crude and drift rates are high. But even now, there are affordable IMUs with very good performance.

    I’m also puzzled by the statement that GPS is NG for odometry. The military version of GPS is accurate to about 1 cm. That’s not GOOD enough?

    I suspect that any problems folks are having relate more to the performance of their Kalman filter than the hardware.

    What’s that you say? You don’t _HAVE_ a Kalman filter?

    That’s what I thought.

    1. “The gyros would continue to spin through the duration of the mission, with no additional updates or re-alignments.”

      Supercooled and spin can go for long time shielded from external effects.

      1. Ok, so we’re talking about navigating a 100-lb robot in a house or warehouse? Then there are many other methods available to trim the IMU. Laser or ultrasound ranging, for starters. Most robots like Roomba take fixes on walls or furniture, I think, and built an internal map of the room(s) they’re in.

        Like others, I think I was put off by the term “odometry” in this context. Maybe it’s time to ask, what’s the application?

        If a Roomba-sized robot goes 10 cm forward, then 10 cm backward, does the odometer read 20 cm, or zero? What about if it goes 10 cm North, then 10 cm SW?

        Unless you’re trying to calculate the wear on the machine, I don’t think odometry has much value for navigating inside a house.

        A warehouse, that’s another matter. Lots of companies have delivery robots that carry goods or parts from one part of the factory floor to another. Even mail robots.

        Is that what we’re talking about? Time to nail down the requirements a little more, huh?

    2. If you’re blitzing across Europe in a convoy GPS is fine but for a 100lb robot that needs cm scale fixes it leaves a lot to be desired. Even dGPS has limitations that would make it only slightly helpful for small robots.

    3. Even if you have a Kalman filter, you can’t extract information where there is none. MEMS based IMU are crap for long time positionning, and what they claim on the product brief is only true when the part is leaving the manufacturer’s factory. The reproducibility of the measure is close to none because of mems’s aging, sensibility to temperature, non-iso-orientation, magnetic perturbation etc…, none of which you can fix with a Kalman filter since you can’t model those.
      So, as Joe says, cheap IMU are good for milliseconds tracking, but for anything more serious you need some absolute reference, either a GPS, a Bespoon’s UWB tracker, a Wifi mesh…

      1. @sweethack: “MEMS based IMU are crap for long time positionning …you need some absolute reference, either a GPS, a Bespoon’s UWB tracker, a Wifi mesh…”

        I think we’re saying the same thing. You can integrate acceleration to get position & velocity, but errors build up. So you need some other method to correct the errors. That’s the central function of a Kalman filter.

        I do think you guys are selling MEMS packages short, though. Granted, you can’t navigate for an hour, using a MEMS IMU. But milliseconds? C’mon! How far is your Roomba/factory robot/unmanned delivery truck/swinging door going to move in a millisecond?

        I’m guessing more like 1-5 MINUTES before errors get too large. Unless you’re storing your position in long double.

  3. The best of imus haven’t changed specs in 50 years and kalman filters have been in place for that long. For several million dollars and the size of a toaster oven you could get 1.2 miles of position error (1 sigma) in 1 hour….mems with good characteristics is 1.2 miles in much less than 10 minutes. It turns out that angle can sound reasonable (1 deg drift per hour on good gyros) but acceleration is a big problem with no magical work around. Gps is by far the best solution for things moving more than a few CM per sec

    1. The use of “text-transform: uppercase;” styling is problematic for pluralized initialisms.
      Hackaday should consider removing it, or replacing it with “font-variant: small-caps;”.
      Either would remove the confusion between IMUS and IMUs.

  4. AFAIK roombas are dumb. They drove until they hit something them pivot a random magnitude & drive off. They have a homing beacon for the base station but no real mapping ability.
    Factory robots are generally line followers but amazon use some fancy indoor gps-like system.
    As for odometry you’re confusing the gauge on your car with the most literal definition. The IMUs are tracking displacement. A vector. Try walking through your house blindfolded to understand the use of odometry. Self driving cars (on roads) are cool but they’re a different problem from Simultaneous location and mapping. I guess you could argue collision avoidance is similar to SLAM but it’s ephemeral so the map is useless after a brief window.

    1. Modern room as have a camera, they can create a map of the flat as they go, return to the base to recharge and then continue where they left, know which parts of the flat they have still not visited…

    2. I believe Roomba makes/made money off the back of selling room-mapping data on to other interested parties. I suppose marketers might have an interest in knowing the approximate layout/size of a house?

      1. Really? That’s OUTRAGEOUS!!! Next thing, you’ll be telling me that Alexa is watching me take a dump. Maybe she’s scanning the brand of TP or toothpaste that I use.

    3. I have two problems. First, the use of the word “odometry.” IMUs are used for NAVIGATION, and that’s what most of the folks commenting here seem to be thinking. I assumed that “odometry” must mean something different. If it doesn’t, can we please drop the term entirely?

      Second, we need to define the problem space. Brians original post talked about “electric cars with rebranded adaptive cruise control, or delivery robots that are actually just remote control cars.” For applications like that, you clearly don’t need to limit yourself to MEMS IMUs. And GPS is also the PERFECT way to trim the nav system.

      OTOH, when I mentioned GPS, Robert said, “GPS is useless in doors,” and Gregg wants to measure the angle of a door.

      Clearly, these are different problems. Solutions exist for all of them, and as Pat b says, they haven’t changed much in 50 years (though the available hardware HAS changed, immensely).. But I don’t see how we can find a solution that works for both a self-driving delivery truck and a bathroom door.

      1. >> IMUs are used for NAVIGATION, and that’s what most of the folks commenting here seem to be thinking. I assumed that “odometry” must mean something different.

        Odometry from the Greek roots is literally measuring your route. It’s true that IMUs are used in navigation but you can’t navigate a map if you don’t know where you are on it after you start moving. You either need a real time (how ‘real’ is real depends on movement speed) view of the outside world to build a map as you go (SLAM) or an accurate map with accurate vectors of your movement. Again compare walking through a building with your eyes open vs closed. If your map of the space is off you can’t use IMUs alone without collisions. In the self driving car example you need both (assuming you’re not just driving laps) since the state of the road is constantly changing.

        >>And GPS is also the PERFECT way to trim the nav system.

        I think we’re fuzzing the problem space boundaries.
        Navigating a space with GPS alone works fine as long as the obstacles are larger than the error of the measurement. With state of the art dGPS you’re looking at around 10cm / 4in, your average consumer GPS is around 4m / 13ft. Both of these are too large to use on populated streets. If you want to get to a specific area on a map GPS is just fine, but self driving cars also have to deal with collision avoidance from other objects on the road. You seem to be approaching the problem strictly from a map navigation view, which isn’t necessarily invalid, but once you factor in collision avoidance you wouldn’t be using GPS to trim your location fix, you’d be using lidar/radar, IMUs, terrain matching, or some other sensor to trim the GPS fix to avoid collisions.

  5. What is the main reason for drift in MEMS accelerometers and gyros?

    Could it be reduced by e.g. putting the chip in hermetically sealed, temperature stabilized box, like oven controlled crystal oscillators?

    1. The inherent noise in the system is what causes the drift. You have to integrate to get position from acceleration. Without any noise, provided that the device was perfectly calibrated, you would get accurate position. Now assume that you get just one reading with a bit of noise. That acceleration turns into a small fixed amount of velocity, which over time adds up. You can do things to reduce noise but because IMUs are inherently analog at their core, you will never entirely eliminate it.

      1. Sorry, Jack, I think you’ve got that wrong. Noise is what filters are for, and the art of filtering noisy signals is pretty well advanced. I do agree that there are going to be errors in any measurement — quantization errors, for starters. If your ADC has only 8-bit resolution, you’re going to get a lot of error. 16- or even 24-bit, not so much.

        Even so, you have to filter the inputs, smoothing out the noise from all sources.

        Where I used to work, we used triple-precision (thus 48-bit) accumulation of gyro inputs, and a third-order polynomial of MATRICES to estimate the most likely attitude, This is sophisticated stuff, and the results were phenomenal.

    2. Temperature-related errors can indeed be controlled by holding the temp constant. However, an even better way is to just measure the performance at different temperatures,, and store the sensitivities in a table. Then you don’t need to control the temp, just add a sensor to measure it.

      Other errors are simply variations from perfection. They can range from simple mounting errors to manufacturing tolerances to imperfections in the materials (for MEMS) or wheel imbalances (for wheeled gyros).

      There’s one aspect of this that hasn’t been mentioned: CALIBRATION. At Honeywell where I used to work, we used a computer-programmed sequence of tests to calibrate the instrument. On the highest-rated systems, calibration can last for a couple of DAYS or more.

      Also, the calibration usually involves rotating the system into various attitudes, so the accels see gravity from different directions, and gyros sense the rotations along different axes.

      The ring-laser gyros that Honeywell builds have their own error sources, which arises from the nature of the interaction of the counter-rotating laser beams. This produces a random-walk error that can’t be avoided, though it CAN be made very small.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.