HACKADAY PRIZE 2018

INTRODUCTION

Autonomous navigation is a trending topic, one of the main problems to solve in this field is the location and tracking of the robot in its environment.

The robot should know where it is to decide where to move, this tracking of the movements of the robot is called odometry. <- This is what the IMcoders provide

Our main focus is to design a device able to provide odometry data with a minimal integration effort, easing prototyping on almost any system without hardware modifications.

Thanks to the combination of sensors in an IMcoder, each module can provide much more information than a traditional encoder. Now we are able to detect drifting of the wheels, robot kidnapping issues and a basic auto-validation of the output data.

GOALS

The goals of the project are clear, the sensors will have the following features:

• Easy to use and integrate in a system
  • No hardware modifications of the target system needed. Attachment always external to the device.
  • Libraries and integration with ROS (Robot Operating System).
• Extend the functionalities of traditional encoders with detection of
  • Wheels drifting while
    • Accelerating
    • Braking
  • Robot kidnapping
  • Basic self-verification of the data

HOW DOES IT WORK?

IMU -> Encoders = IMcoders

The main component of an IMcoder device is an IMU (Inertial Measurement System), a device equipped with three sensors: Accelerometer, Gyroscope and Compass.

The traditional use of IMUs as source of odometry data has been deeply studied and it has been proved not to be the best option as odometry data source in the long run (with a double integration of the acceleration to obtain position the acummulated error grows really fast). All the measurements are relative to the robot’s previous position and they are not absolute to the environment where the robot is moving. The error of each measurement of the sensor is accumulated in the next measure and, at some point in time, it makes the output of the system not reliable anymore. This effect has always been the restricting factor to use this devices as an standalone odometry source.

Our approach is not to use the bare output of the IMU as the input data to generate an odometry output but to use this IMU data to infer the spatial orientation of the wheel the sensor is attached to. Then, analyzing the spatial orientation of the wheel over time we can mimic the behaviour of the traditional encoders + some extra interesting features.

This approach has several advantages:

As the measurements of the IMU are relative to the object where it is attached, the physical constraints about where to mount the system are minimal. 

The IMcoders sensors can be easily attached to any exposed part of a wheel, as the sensor works rotating WITH the wheel.

The IMcoder sensor has an internal battery and includes a bluetooth module to wirelessly communicate with the host processing the data. This wireless communication approach removes the problematic of wires and simplifies even more the attachment of the sensor to the robot.

As the IMcoders directly measures acceleration, angular velocity and magnetic field on the wheel, we can infer much more information from this data source than just the orientation, as we proceed to explain:

Drifting Detection - Acceleration:

Imagine that in a static state (robot is standing still) the IMcoder sensor measures a high value on angular speed (the wheel is spinning) but there is almost no change in the magnitude of the measured acceleration (there is no change in velocity from the static position). Then, it is highly probable that the device is trying to accelerate that fast that the wheels have not enough grip and they are drifting.

Drifting Detection - Braking

Imagine that in a dynamic position (robot is moving) the IMcoder sensor doesn’t measure angular velocity (wheels are blocked) and there is not a big deceleration measurement (there is not a fast reduction in velocity). Then it is highly probable that the device has blocked it wheels but the wheels are drifting on the ground and the robot is sliding.

Under this condition (blocked wheels) the outputs of the accelerometer and the last valid odometry based position can be used to infer how much the robot is drifting (double integration of the acceleration give us position). Thus , we are still be able to produce reliable odometry. All this scheme works under the assumption that the drift will only last no more than a few seconds (cumulative error with double integration grows extremely fast).

Robot Kidnapping

If the robot is supposed to stay still (no movement command sent to the robot) but it is changing position because the surface is slippery or someone/something is lifting the robot (even if the wheels are still and not spinning) the IMcoder sensor can notify the host about this even as it will measure a change in velocity.

Fault Detection

One of the main inputs the IMcoders is the gravity in order to estimate the spatial orientation of the wheels. This is an absolute measurement. This means that, when the wheels of the device are spinning at low speed or the robot is still, this measurement is constant and limits, if not completely removes, the effects of possible offset in the gyros. This absolute measurement allows the sensor to send an absolute orientation of the wheel and the host can verify if the previously received information correlates with the actual position of the wheel or at least how inaccurate it is. Even when it is not possible to correct previous errors (under some circumstances it is), knowing the existence of errors can tremendously increase the robustness of the system as it will not rely anymore on imprecise data and safety mechanisms can be deployed.

WHY?

Nowadays, most of the robots move using wheels and one of the most commonly used sensors to provide odometry data in robotic applications are encoders. This devices measure the rotation of an object with respect to its own frame. They can be mechanical, optical, magnetic, etc..

They need to be physically near to the object they are measuring. In most cases mechanically coupled to the spinning object and to a fixed reference frame. Adding them to a system which it is not designed to have them could be really challenging (if not impossible).

The power consumption of this devices is really low and they can measure accurately really high spin velocities.

They have been around for quite a long time and they are robust. Summarizing...

Advantages:

• Good solution for “from scratch” built robots / final products.
  • They are embedded in the system from the very beginning.
• Low power consumption.

Disadvantages: <- This is what we want to solve

• Extremely hard to add them to existing systems.
  • Complex mechanical integration.

CONCEPTS

To understand the idea behind the IMcoder project is important to know the difference between absolute and relative position estimations as we will make references to this concepts in following posts.

Sensors that provide an absolute estimation are the ones that provide information about environment positioning for each measurement, e.g. GPS.

For a GPS system, after each measurement, a set of GPS coordinates are received indicating the position of the receiver. It doesn’t matter the previous position, each measure shows the current position on the world independently of the previous one.

A relative positioning estimation means providing information related to the previous estimation. Assuming an initial position and using this relative information, it is possible to infer the current location of the robot, e.g. encoders.

Using encoders attached to the robot wheels (lets assume 1m diameter wheels), you can measure how much a wheel has spinned since the last measurement. Assuming know where you are (old_pos), you move straight and the sensor tells you that the wheel has spinned 3 whole revolutions you can easily calculate where you are now (new_pos):

If you repeat this process you can track where you are just measuring how the wheels are spinning. The problem with this approach (and with any sensors providing relative measurements) is that if there is ANY error with the output of the sensors (imagine you didn’t spinned 3 revolutions, but just 2.99 revolutions) your ‘new_position‘` will be wrong and you will base further calculations in inaccurate information. After some time this small error on the measurement is going to be quite big and unusable for navigation. Without absolute measurements you can’t know if you are where you think you are, there is no way to correct this accumulated error.

Our sensor, so called IMcoders, is a mix of absolute and relative measurements. It doesn’t give us all the advantages of an absolute measurement sensor so far, since we have drifting and several limitations with the cumulative error; still we can detect, up to a certain extent, if the output of our sensor is getting out of control.

With this on mind… Let's start!