GPS Navigation – Part 2

In part 2 of this article I have built a small robot to test and prove the theories discussed in part 1. One thing we could not account for was the specifics of the robot, since it had not yet been built. We also wanted to be able to use this concept and even the code elements on just about any platform we use. The first thing to do in this case is define several key elements of the design before we begin. How large is the robot going to be? How fast will it move? What type of terrain will it traverse? How will it steer?

For purposes of this article my answers were about the size of a shoe box, no faster than 3 feet per second, asphalt and / or concrete and skid-steering. An old Lexan chassis I had lying around would be perfect for this task (See Figure 1). This robot has 4 spur-gear motors and a two level platform for mounting the microcontroller and sensors. It also has a lower deck, perfect for storing the batteries.

Additional Components

I opted to use a BASIC Stamp 2p Module for this system because it is more than capable of reading the raw NMEA data from the GPS receiver, parsing the data, reading the compass and calculating headings from that data. It can then control the drive system to steer the robot where it needs to go, plus it simplifies the code design for those using a different platform for their robot and controller. The BS2p will mount on a Super Carrier Board which will provide connections to the remaining hardware.

The chosen compass module for this application is the HM55B due to its easy integration and existing compatible source code. A serial LCD display, some ultrasonic sensors and a heat array sensor (Devantech TPA81) have been installed on this robot. However, for this example they will not be used and are option for this part of the project. These items will be used in Part 3. To drive the four gearhead motors I chose to use two HB-25 Motor Controllers due to their servo-like control and ability to not only handle these motors in pairs, but also to scale up should a larger robot chassis be used.

Construction

This first thing I did was assembled the chassis which was being repurposed from a previous robot project. The HB-25 motor controllers were installed in the belly of the chassis in between the motors. As you can see from Figure 2, it is somewhat of a tight fit. However, with proper cable routing, you could almost say it fits like a glove. The only thing I had to be cautious about was clearance for the fans on each motor controller.

Figure 3 shows the lower section of the robot assembled with one ultrasonic sensor installed and a power switch for the motors.

Batteries were added and then then the lower plate was installed along with some padding to hold the batteries in place (See Figure 4). Two batteries are used in this design. One is dedicated to the motors and is switched independently using the power switch shown in Figure 3. The other battery powers the Super Carrier Board which in turn powers the GPS and LCD which both consume a lot of power. The batteries are standard 7.2V R/C battery packs from a hobby store. They are Nickel Metal Hydride (NiMH) and are rated at 2600mAh each.

A separate switch controls power to the Super Carrier Board. As you can see in Figure 5, several 3-pin headers have been mounted for connecting the various sensors and motors. The lower pins provide a provision for a push button which is used to set waypoints for the GPS navigation.

Figure 6 shows how the LCD and GPS mount to the top plate as well as the additional ultrasonic sensors and the thermal array sensor. This plate is then installed on top of the lower section of the robot using standoffs (See Figure 7).

Programming

Once the robot construction was completed it was time to download the program code onto it (See Figure 8). Notice the old-school serial cable connected to a DB-9 serial port.

The program has a main loop that does the following tasks until the last waypoint has been reached.

• Obtain current GPS coordinates (Latitude / Longitude)
• Calculate the desired heading (in degrees) based on target position vs current position
• Obtain current heading (in degrees) from compass module
• Calculate course correction based on desired heading vs current heading
• Determine if waypoint has been reached (and is last)
• Adjust course and speed of motor drive as needed to reach goal

This loop will continue until the robot reaches its goal or the batteries die. As mentioned before, eventually other sensor data (such as from the sonar) will be factored into the equations to avoid obstacles as well. For this article let’s assume it’s a clear path as my test area is (for the most part).

Code Details

The first task is to obtain the coordinates of the current position. These coordinates are used along with the target coordinates to calculate the desired heading. In part 1 of the article this was done using Pythagorean Theorem. You can also get distance to target in this section using one more calculation. Next we want to obtain the current heading from the compass module and compare it to our desired heading and any course corrections are applied. At this point the specifics of the motor drive system determine how best to handle the minor and major adjustments in course correction. On this robot the skid steering makes any angle corrections easy since the robot can easily turn in place.

Taking the Robot for a Stroll

The initial results were quite promising from the first few runs. The only real issues were related to the weather which did somewhat impair GPS reception at a few points. If and when the GPS signal becomes invalid the robot is programmed to stop in place and await a valid fix. These types of behaviors can be adjusted via minor code changes I will cover in the next part, however in the test phase (and lacking sensors) I thought stopping was the safer way to go. Also the corrections are somewhat jittery…fortunately with the skid-steering it is not very noticeable however the previous platform I tested the code on showed this effect much more. This will require some filtering in the code.

The LCD and pushbutton functions are very rudimentary and will also be enhanced upon. Right now the push button serves only one purpose and the LCD only displays current Latitude and Longitude. A larger display could show more, but a menu system allowing you to select different display modes would be easy enough to implement.

Final Thoughts

The size of the robot can be a help or a hindrance depending on your terrain. Remember, when testing GPS code like this, fast is not necessarily better. Wait until your code is adjusted and fine-tuned before throwing the throttle wide open. I was very conservative with my speed settings while still allowing for a reasonable speed to travel the distances within a parking lot, which is where my waypoints were set.

Obviously, since GPS requires outdoor reception you won’t be using a BoE-BOT for this purpose. The reason being that the speed at which a small desktop robot travels means it will take a while to traverse any reasonable distance, including the GPS margin for error, which can be several feet or more depending on reception and number of locked satellites.

On the other hand, something as large as a lawn mower might pose a threat to people or property if something should go wrong. The robot chassis I chose was a great compromise of speed versus size and had sufficient computing power to handle all the functions including those not yet implemented. The code is well documented and even describes the connections to the motors.

In Part 3, we will build on the existing code and enhance it to handle the extra sensors. Until next time, take care and have fun!

Resources

GPS Navigation – Part 1

GPS Navigation – Part 3

Discuss this project on Savage///Chats

This project was published in the April 2010 issue of Servo Magazine