Any automated machine needs to have a strong understanding of where it is in order to complete its task. A robot arm needs to be able to weld one section of a car to another, a 3D printer needs to print fine details with precision layer by layer, and consumer robots need to navigate an everchanging space to clean.

Today, we want to focus on the last case – consumer robots moving along relatively flat surfaces to clean. These robots determine location using a technique called SLAM (Simultaneous Localization and Mapping). Data from the wheel encoders and inertial measurement unit (IMU) - and optionally optical flow/camera/LIDAR - all contribute to determining the movement of the robot. This is the localization part. Mapping is what keeps the robot on an efficient path that avoids obstacles and avoids repeating areas.

Within this set of robots, we’re going to focus on precise localization using a price conscious set of sensors and the process of optimizing performance. Data from the wheel encoder, optical flow sensor, and IMU can be combined for odometry (the change in location over time). When these calculations are computed without the aid of wireless beacons or LIDAR to get an exact location, this is also known as Robot Dead Reckoning. This paper will go over in detail the comparison and analysis of dead reckoning algorithms. Whereas a previous white paper focused on the basics
of robotics sensors and touched on testing, this one will focus in depth on the testing process. We will discuss how our data was collected, what we are comparing against, and how we analyzed the comparison data along with the presenting the data itself.

Robotic systems are a complex beast, requiring the combination of carefully picked mechanical, electrical, and programmed parts.
Before a line of code is written, you have to pore over spec sheets to determine which mechanical components stand a chance of achieving your end goal. Every robot also requires sensors to understand the world around them, then rely on mapping algorithms to move where we want them to, not just where the code tells them (old programming joke).
After you have something that proves your concept, you need to test more to fine tune the idea over time. Testing is another sophisticated and arduous process, to measure and analyze what the robot is seeing relative to what you see and want.
If you're tired of reading this already, that's understandable. Even with this high-level summary of the process, there are still so many combinations of places where choices need to be made and things can go wrong.