Building the SunRover navigation system

Why no Encoders on the Wheels?

A common robotic practice is to stick encoders on the wheels so you can track how many times the wheels have turned. An encoder [7] is a sensor that is attached to a rotating object (e.g., a wheel or track) to measure rotation. Basically, the encoder allows you to track how far your robot has moved – assuming zero slippage, that is.

The two main ways of encoding are using a rotary sensor (on the shaft of the wheel being measured) or using an optical encoder that works from reflections from a encoder disk.

I really don't have access to the shafts of the driving motors in the T'Rex tank motor bay to put on a shaft encoder, so I'm left with two possibilities for using an optical encoder. The first option is to bounce IR off the gears that are visible in the motor bay or bounce IR off the tracks themselves. After looking at the space inside the motor bay and the space outside the front of the robot, I have decided to put the sensors off of the front of the robot pointing at the tracks. Then, I can calculate an estimate of distance.

I'm using the inexpensive IR encoders from SparkFun [8] and a 3D printed shield.

Navigation Systems and Track builder

The current communication architecture between the Raspberry Pi 2 and the Arduino Mega (a serial connection), causes a lag between sending the command and the execution and response back to the Raspberry Pi 2. I'm really not happy with this delay in general (it can be about 1-2 seconds) and don't really want to execute complex motions with this delay between each motion. That is the rational behind the track builder software discussed in the next section.

The way this works is you stack up a set of commands in the database (a "path") on the Pi. Each element in the command stack is a command telling the Robot where to go, how to turn, or what sensor to check to continue. The stack is meant to be a planning tool for moving the robot. The selection of plans are held in the MySQL database on the Raspberry Pi and then a single set of commands is sent down to the Arduino for execution. This approach leads to very snappy responses and turns from SunRover without the command sequence delay. See the box titled "ROS" for more on future updates to the SunRover software architecture.


The SunRover software architecture on the Pi is very similar to what I used on Project Curacao [9]. It is basically a task-based scheduling program written in Python using apScheduler. This approach works well for Project Curacao (it doesn't move!), but I'm just finding it too limited for SunRover operations. I'm currently looking at using the Raspberry Pi version of the ROS (Robotic Operating System) [10], an open source operating system that runs on top of Linux in the Raspberry Pi.

A ROS system consists of nodes that communicate with other nodes via a publish/subscribe messaging model. The ROS nodes do not have to be on the same computer or even of the same hardware architecture, which provides lots of flexibility to do robotic applications, but it is a bit overwhelming.

Buy this article as PDF

Express-Checkout as PDF

Pages: 8

Price $2.95
(incl. VAT)

Buy Raspberry Pi Geek

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content