NavBot – Initial Software Design

The NavBot

Now that the WallBot has functioning wheel encoders I’m eager to evolve it from a simple wall-avoiding robot to one that can autonomously navigate its environment.

I already managed to code up some crude dead-reckoning navigation that lets the bot execute sequences of “move, turn” commands.

However, creating a robust and fully featured NavBot is going to demand a lot more software engineering than has been required up till now. My initial research suggests that navigation on the small scale, like moving about inside a building, has a lot of technical challenges to overcome. The key one being “Localization”, i.e. the process of figuring out and tracking your current position. Most techniques used for calculating position have inherent errors that accumulate over time, resulting in localization that becomes increasingly inaccurate.

Of course, it all depends on what you are trying to do. For now I don’t have any practical application for NavBot. I’m interest in learning about navigation in general and its related issues. With that in mind I want to keep the code base as modular as possible so I can play with all the different navigation techniques without having to change too much code.

Design Overview

From what little I’ve read so far most systems are centered about a “localizer”. This is a piece of software whose job it is to calculate and maintain the current location and orientation of the bot.

I’ve designed my system around a localizer I call the Navigator, and another piece of software responsible for driving the bot, called the Pilot.

Screen Shot 2014-02-19 at 8.04.15 PM

The Navigator provides the position (x, y), heading (h) and velocity (v) of the bot about its center point. In the current setup the Navigator relies solely on the encoder ticks to “dead reckon” changes in position. This is not an ideal approach as inevitable errors will accumulate and eventually the dead-reckoning will get to be too far off to be of any use.

However, the Navigator can also be expanded to use other internal and external sources of telemetry to provide more accurate and reliable localization, such as GPS, accelerometers, compasses, distancing sensors, imaging sensors and beacons. The reality is that an accurate and reliable system will require a mixture of different techniques in order to compliment each others’ inherent shortcomings.

The important point to note is that regardless of how the Navigator works – however simple it is or sophisticated it gets – the interface to the rest of the system, such as the Pilot, does not change.

The Pilot, in turn, uses the Navigator to control the movement of the bot. The main robot logic can tell the Pilot to move to a new location (x, y) or simply set a heading (h) and distance to travel. It can also set the speed (v) to move at.

The Pilot’s job then is to control the motors (l-motor, r-motor) in such a way that they move the bot to the desired location. The Pilot continually uses feedback from the Navigator and employes two PID controllers – one for maintaining or adjusting the bot’s heading, and one to regulate speed – to generate the correct l-motor and r-motor values over time.

Like the Navigator, the Pilot also provides a fixed interface to the rest of the code. If we were to alter or change the drive/steering system of the bot then we just need to implement a new Pilot and not have to change any other code. [This is not entirely true but close enough.]

The “Logic” box in the diagram above is a catch-all for every other system that might be needed, like collision detection, obstacle avoidance, waypoints, mapping and so on. For the first version of NavBot I only plan to create code for testing and calibrating the Navigator and Pilot using a simple waypoint sequencer.

I’m in the process of implementing the code and I’m sure the design will change somewhat as issues arise. Unfortunately not a whole lot of time available for coding at present so hopefully it does not take too long to complete. I’m very curious as to how this all works out.

As I go along I’ll document the sub-systems in greater detail.

References

It might be useful to list the articles and papers I’ve referenced so far for my basic research:

  1. A Tutorial and Elementary Trajectory Model for the Differential Steering System of Robot Wheel Actuators by G.W. Lucas
  2. Enabling Your Robot to Keep Track of its Position by RidgeSoft
  3. Path Tracking and Obstacle Avoidance for a Miniature Robot by Martin Lundgren
  4. Where am I? Sensors and Methods for Mobile Robot Positioning by J. Borenstein, H. R. Everett, and L. Feng
Advertisements

Comments welcome

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s