IMU-based encoders. IMcoders provides odometry data to robots with a minimal integration effort, easing prototyping on almost any system.

Similar projects worth following
The IMcoders project is meant to offer to the robotic community an easy to mount, cheap and reliable device capable of substitute the wheel encoders in an already existing system, or to produce accurate odometry data for wheeled robots without previous odometry support.


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.


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


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

Read more »

Kicad files, modify them as you please!

x-zip-compressed - 639.92 kB - 06/20/2018 at 20:40



Do you want to build you own IMcoder? Here are the gerbers for the PCB! This is the version v0.2, some errors are present on the board and the component placement is far from optimal, but as you can see in the logs... It Works!

Zip Archive - 22.97 kB - 06/03/2018 at 08:08


  • 1 × IMcoder PCB Self-developed PCB to integrate the 3 main components of the system together.
  • 1 × Arduino Pro Mini Brain of the sensor, it will read the data from the IMU and send the values to the host computer
  • 1 × MPU9250 Core sensor of the IMcoder. IMU module with integrated Accelerometer, Gyro and Compass
  • 1 × HC-05 Bluetooth Module Wireless link with the host computer. It creates the connection between the Arduino module and the software stack.
  • 1 × LiPo Battery It is not a must, but somehow we should power the device, don't we?


    Alfonso Troya05/31/2018 at 00:24 0 comments

    Hi again!

    We have some very good news, our Robot is moving!

    The simulation environment is up and running. The calculations for the odometry and hardware integrations are done! There is still a lot to be developed, tested and integrated but we can say the first development milestone is complete and the Alfa version of the IMcoders closed.

    Read more »


    Alfonso Troya05/30/2018 at 23:24 0 comments

    In the previous log we checked that we are able to simulate the IMcoders for getting an ideal output (we will need it for making the algorithm development much easier and for verifying the output of the hardware).

    Let's check in Rviz (ROS visualizer) that the movement of our sensors corresponds with the data they output. The procedure is quite easy (pssst! It is also described in the github repo in case you already have one IMcoder). 

    Then, we activate the link with the computer, start reading the sensor output, opening the visualizer and...

    Voilà! The visualization looks great. Now we are ready to check the sensor in a real wheel. Let's start with that broken bike there...

    Read more »


    Alfonso Troya05/30/2018 at 22:52 0 comments

    Ok, so now the hardware is working and we have a lot to do, but in order to have a reference for comparing the output of the real sensors, we want to simulate them for getting the ideal output.  In order to ease the use of the sensors and making the rest of the people to use it, we created a github repository where you can find all the instructions for running the simulation with the sensors (and with the real hardware too!). As we want to integrate them in ROS, it makes sense to also use for integrating all the simulation. Probably most of you already now it if you already worked with robots, but for those who don't here you can find an introduction to it. So let's begin!

    Our first approximation: a simple cube

    As our sensors are providing an absolute orientation, the easiest way to see the rotation, is using a simple cube. Inside of it, one of ours sensors is inside, so we are able to move the cube in the simulated world and see the output of our sensor:

    Let's tell the cube to move and let's see what happens...

    Read more »


    Pablo Leyva05/26/2018 at 16:18 0 comments


    The days pass quickly and the project is moving forward. Before the development on the algorithmic part is finished we are working on an enclosure we can attach to our tests platforms. 

    A case is not only an attachment help for the final device, it will also help us to use the sensor without fear of shorting something out or breaking a connector. The design is extremely simple, two plastic covers with the PCB in the middle. An extra piece will hold the battery in place.

    The design was done on Onshape and is already available. We are planning to improve the case and get rid off the screws, but will work on that once everything is up and running. Right now we have other priorities to focus on. 

    Read more »


    Pablo Leyva05/21/2018 at 20:51 0 comments

    Will they blink?

    The boards are with us! Time to solder the components and check if everything works.

    To make SMD prototyping boards from through-hole ones you just need some sandpaper and patience, the results are incredibly good!

    Read more »


    Pablo Leyva05/21/2018 at 20:45 0 comments

    Time to Design!

    The design of the boards is painfully simple. As all the components of our boards are small development boards with their own power regulators and level shifters, all we need to do is just connect the dots.

    The design has some flaws we plan to correct in the following versions, but we didn’t want to miss the submit date for the HackaDay 2018 price and we order them without double checking a few things.

    Working with Kicad was an experience itself, I personally expected it to be a little bit more user friendly, but once you get how to work with it is no so complex. Looking at the schematic and PCB layout you can see there is no need for any special feature. It is just really basic stuff.

    Read more »


    Pablo Leyva05/21/2018 at 20:39 0 comments

    The Firstborn

    To test the viability of the idea a first prototype was developed and tested (with success!). The aesthetic was no priority and the soldering skills at the moment unavailable or nonexistent.

    After some prototyping in the protoboard and making sure that the tool chains were correctly installed, devices reachable and git repositories clean and commited a more reliable development platform was needed, and so the hardware V0.1 was borned.

    Read more »

View all 7 project logs

  • 1
    Build the IMcoder Hardware

    With the available gerbers for the PCB and the components list, you can easily solder your own IMcoder module. You just need a soldering iron and some time to put all the components together.

  • 2
    Program the IMcoder Firmware

    With the Arduino IDE and the code in our GIT you just need to program the sketch RTArduLinkIMU.ino. 

    By default it is configure to use MPU-9250 IMU with SPI, so you are ready to go :)

    To establish a connection with the host PC, the HC-05 Bluetooth module should be configured with a baud-rate of 115200.

  • 3
    Visualizing the data with RTIMULib2

    If you want to test the connection with the PC opening a serial console with the COM port binded to the bluetooth module should be enough. You should see characters being printed to the console.

    If you want to see the orientation of the sensor and something a little bit more graphic you can follow the instructions in our GIT to compile the visualization software.

    Thanks again to richardstechnotes as he did the heavy lifting with his RTIMULib infrastructure.

View all 5 instructions

Enjoy this project?



rasyoung wrote 06/20/2018 at 11:20 point

Great Project!

Wondering if KiCad design files are available? I would like to add some additional connectors, and blinky bling.

  Are you sure? yes | no

Pablo Leyva wrote 06/20/2018 at 20:47 point

Sure! They are now available under "Files".  

I highly recommend a pull-down in the trace from EN (HC-05) and Arduino, The bluetooth module interfere with the UART while new software is being downloaded and without it, you cant turn it off... I realized that too late.

  Are you sure? yes | no

Mesbah Uddin Mohammed Arif wrote 06/20/2018 at 08:23 point

does the module need to rotate to get the odometry data ... can it provide odometry info whenit is in a stationary position on top of the robot platform but the robot is moving ?

  Are you sure? yes | no

Pablo Leyva wrote 06/20/2018 at 20:53 point

Yes, and No. the module just sends the values of the sensor (accelerometer, gyro, and compass) to the computer. In our case, a ROS node reads the data and perform the sensor fusion under the assumption that is attached to a wheel. Knowing the radius of the wheel we send the odometry data.

You can use the module on top of the robot, but the fusion of the sensor data to generate the odometry is going to be different.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates