SurveyBot

Chris Johnson

Jeremy Coffeen

Miguel Lopez

ECE 4006 – Senior Design Project Prof. James Hamblen Summer Term 2003

July 17th, 2003

Georgia Institute of Technology School of Electrical and Computer Engineering Table of Contents

Executive Summary………………………………………………………………1

Introduction……………………………………………………………………….2

Overview…………………………………………………………………………..2

The AmigoBot Platform………………………………………………….………3

Differential GPS System………………………………………………………….4

Communications…………………………………………………………………..6

SurveyBot Behavior Control……………………………………………………..7

Mapping Algorithm……………………………………………………………….8

Testing and Results……………………………………………………………….10

Project Timeline and Organization……..………………………………………11

Economic Analysis……………………………………………………………….13

Conclusion………………………………………………………………………..13

Appendix A: Photos and Schematics…………………………………………..A-1

Appendix B: Software Information……………………………………………B-1

Appendix C: Source Code……………………………………………………...C-1

Appendix D: References………………………………………………………..D-1 Executive Summary

The SurveyBot project’s objective was to design and build an autonomous robot capable of traversing and mapping an unknown landscape. The robot navigates towards given goals determined by Differential GPS (DGPS) coordinates. Obstacles encountered on or near the path of the SurveyBot are stored and mapped graphically. The SurveyBot is based upon the AmigoBot platform, and is controlled via an onboard laptop PC communicating serially with the AmigoBot.

The majority of the project consisted of software development for the PC. The hardware side of the project involved building the Differential GPS receiver from scratch, and hardwiring all of the external components together. The software was developed in phases; the first being a multi-threaded communications system with the AmigoBot, capable of sending commands and constantly reading data from the AmigoBot. This proved to be time consuming due to inaccuracies in the AmigoBot documentation. After a communication link was established with the robot, software to control general movement was developed. Finally, obstacle avoidance, navigation, and mapping were added to the control program.

The final design consisted of a robot capable of navigating a rectangular area, delimited by GPS coordinates, mapping obstacles in one-foot increments as it ‘zig- zagged’ across the area. Further progress could be made with the SurveyBot by implementing a digital compass to improve navigation accuracy by correcting internal odometry error, as well as adding a more detailed mapping algorithm. Introduction

The SurveyBot project was conceived as an attempt to develop a mobile robot capable of mapping an unknown territory, and guiding itself using Differential GPS technology. The uses for this type of robot are abundant, particularly in situations too hazardous or areas too confined for human exploration.

The SurveyBot consists of an AmigoBot robot platform (Fig A-1), with an onboard laptop PC for control via a serial link. The PC can also be interfaced to a

Differential GPS system for navigation purposes. The SurveyBot is capable of navigating across a rectangular area, incorporating obstacle avoidance behavior, while seeking a goal position and mapping obstacles along the way with one-foot precision.

Overview

The heart of the SurveyBot is an onboard laptop PC, which communicates serially with the AmigoBot. The AmigoBot sends Server Information Packets (SIP’s) approximately 10 times a second. These packets consist of robot position data in the X-Y plane calculated by a running count of wheel rotations onboard the AmigoBot, as well as distance readings from the onboard sonar sensors and the status of different systems. The

PC, running a control program built with C++, uses a thread to capture the SIP’s, and then decodes the incoming data and parses it into global variables for use by the control program. The control program uses this data to make navigation, obstacle avoidance, and mapping decisions.

The PC can also receive position data from a Differential GPS (DGPS) system via another serial link. This position data is used to create goals for the robot to navigate towards. It was found that the position data was not reliable enough to be used for real- time navigation and mapping, especially indoors. Instead, GPS coordinates are used to designate the perimeter of the landscape, and also possibly add GPS coordinates to mapped obstacles.

The DGPS system consisted of a Garmin eTrex handheld GPS unit, connected to a homebuilt DGPS receiver board to receive the differential corrections. The receiver board was built from plans for “Rich Heineck’s DGPS Receiver Board” at [1]. The PC utilizes a DLL library called ‘MGC4C’ which allows position data to be obtained from the GPS with a single DLL call.

The AmigoBot Platform

The AmigoBot (Fig A-1) is a mobile robot platform from ActivMedia Inc., with a variety of uses. The robot has an onboard processor to control movement and communications, as well as an array of 8 sonar range sensors, capable of providing accurate ranges up to a few meters away. The robot provides a great amount of feedback on its status, which allows remote control. In addition, it has its own navigation system that keeps track of its movement from the starting position. Velocity and angle can be set very accurately via remote control.

Communicating with the AmigoBot proved to be the first major challenge. The link is a 9600 bps serial link, and the robot has a very specific format for sending and receiving data packets from the PC, and the documentation was not extremely helpful.

Command packets were smaller and fairly simple to create, as long as the checksum was correctly calculated. If the checksum is incorrect, the AmigoBot ignores the command. Each command packet consists of a simple command, such as set velocity, or turn a specified number of degrees. Once the sign convention and byte order for these data packets were determined, creating them was very simple.

Decoding incoming SIP’s proved more difficult. The sonar readings are unsigned

2-byte integers, which were easy to extract and decode. However each packet only contains 2 of the 8 sonar readings, so in order for all sonar readings to be updated, 4 packets must be received. Position data is given in millimeters from the origin, and although the documentation claimed that they were unsigned, they were actually sent as signed integers in 2’s complement form. In addition, SIP’s contain an angle reading, which was assumed to be relative to the original heading of the robot. After trying to use this angle data for navigation, however, it was determined that this data only contains information about the last turn made. This meant that the control program had to keep track of the robot’s heading by assuming that when it is told to turn a certain amount of degrees, it does so with reasonable accuracy. This could affect accuracy over a large distance.

Differential GPS System

The GPS navigation system consists of a handheld Garmin eTrex GPS, connected to the PC and also to the differential receiver board (Fig A-2). The receiver board is based on a low-frequency receiver to receive DGPS corrections from land-based stations, as well a PIC microcontroller to communicate these corrections to the GPS via a 4800 bps serial link. The schematic is included in Figure A-4. The receiver was built on a pre-fabricated PC board, and also includes and external board carrying a 5 volt power supply regulator, as well as an active loop antenna circuit (see schematic). The unit is essentially a low-frequency (approximately 300 kHz) radio receiver, which is controlled via PIC microcontroller. The microcontroller receives commands from the GPS unit in NMEA (National Marine Electronics Association) format, which specify which station to tune to, based upon current location. If the receiver is able to ‘lock’ onto a signal at that frequency, the microcontroller decodes the data, which is sent at 50, 100, or 200 bps, and sends correction data to the GPS unit in

RTCM format. The GPS uses these corrections to obtain more accurate position fixes.

For more information on DGPS, there is an excellent tutorial at http://www.trimble.com/gps/dgps.html. The block diagram of the DGPS system can be seen in Figure A-3.

After the DGPS unit was assembled, it was tuned to specifications using a frequency generator and oscilloscope as described in the assembly instructions. The

DGPS was able to successfully lock onto DGPS stations and communicate correction data, however testing indicated that, especially indoors, results were still not accurate enough to enable direct use of position data onboard the robot. The SurveyBot navigates in units of millimeters, and so even very small position errors could throw the SurveyBot off course. Instead, the robot uses ‘dead reckoning’ to keep track of position by keeping track of movement from the start position. After an area has been mapped in this way, assuming the starting position was known, object locations could be translated into GPS position coordinates. Communications

Because the SurveyBot behavior is controlled via an off-board processor (the laptop PC), instructions must be sent to the AmigoBot, which uses the AmigoOS system, and information from the AmigoBot must be read into the control program. The

AmigoBot includes multiple onboard serial ports, and comes with a tether for connection to a PC serial port. Communications with the robot are handled in the control program using a windows thread that runs in the background, continuously updating a set of variables obtaining robot odometry and sensor data. This thread reads the 33-byte data packets in serially, parses them into data segments, using the parseSensor() function, and finally decodes these data segments and stores them appropriately. Using this method, robot odometry and sensor data can be accessed with a simple variable reference from anywhere in the control program.

Because the SurveyBot was originally designed to make use of real-time GPS position data, the control program is designed to read data from the GPS, connected to a second serial port. The eTrex GPS sends bursts of data serially at 9600 bps once per second. These are transmitted in NMEA format, which in addition to DGPS tuning commands, includes information on latitude, longitude, velocity, and elevation, as well as estimated current accuracy.

Rather than use a second thread to handle GPS communicates, a DLL library, called MGC4C was used. This is a freely distributed library from www.marshallsoft.com. This library handles all GPS communications and data processing, enabling position data to be obtained with two simple C++ calls, mgcLatitude and mgcLongitude, after proper initialization. Using this library, position data would be very easy to incorporate into further projects with the SurveyBot.

SurveyBot Behavior Control

Autonomous navigation of the robot is done through a combination of a go-to- goal behavior and an obstacle avoidance behavior. The go-to-goal behavior uses the

AmigoBot’s odometry, its current orientation, and goal coordinates (x,y) to determine the differential angle between the goal and the robot as well as the distance to the goal. With this data a vector is created with an angle towards the goal and a constant magnitude of

0.5. The obstacle avoidance behavior is called within the go-to-goal behavior and provides a correction to the vector created by go-to-goal. Using the sonar sensor data, the obstacle avoidance behavior creates a vector that points away from the direction where an obstacle was detected with a variable magnitude dependant on the distance from the obstacle. The magnitude follows a 1/x2 relationship and is modulated by two threshold values. It has a max sensor distance value where all readings are ignored and a minimum sensor distance where the magnitude is very large. An overall vector, which constitutes the sum of the vectors created by each sensor, is then outputted and added to the go-to- goal vector to give a final direction for the robot. Due to the 1/x2 relationship of the obstacle avoidance vector magnitude, the go-to-goal vector is hardly influenced at large distances from an obstacle and heavily influenced when very close to an obstacle. The final angle of direction is modulated by multiplying by a constant 0.415, creating smaller turns which minimize oscillations and create a smoother path. The velocity of the robot is also determined by a combination of both behaviors.

In the goal behavior the velocity remains constant until the robot comes within a certain distance from the goal. As soon as this threshold is reached the robot’s velocity decreases linearly as a function of distance from the goal in order to accurately reach the goal and avoiding overshooting it. In the obstacle avoidance behavior the velocity follows a similar relationship except that there is a minimum velocity at the inner threshold. The robot follows a constant velocity at distances above the outer threshold, then decreases linearly as it gets closer to an obstacle to avoid the obstacle more carefully, and maintains a minimum velocity if closer than the inner threshold. The reason for this minimum velocity is that you don’t want the robot to come to a stop if it is really close to an obstacle but rather, move away from it slowly. After both behaviors have calculated their optimal velocity, the smaller of the two is outputted to the robot move command.

The calculation of the robots path to traverse is done in creategoals() and is dependant on the distances between corners of the area outlined by the GPS coordinates.

The coordinates of these goals are saved onto an array that is accessed in the traverse function. The traverse function calls go-to-goal and updates the goals after there are reached. Between goals, the robot turns in place in the direction of the new goal to avoid major disruptions in the odometry, which are caused by large turns while moving forward.

Mapping Algorithm

The mapping part of the project is designed to read the sonar data and current position from the AmigoBOT and visually map out where obstacles were encountered. The file format we use is a PGM (Portable Grayscale Map) for the actual map. The map consists of a 62,500 element static array. Each element of the array represents 1 pixel in the map. We chose to use a 250 x 250 pixel map, which corresponds to a 10ft x 10ft area. We decided to use a 1 foot resolution so there are 100 different squares on our map.

The AmigoBOT is about 1 sq foot so we thought this would be accurate.

As the robot is traversing through the area to its calculated goals, it is continuously polling the sonar sensors for obstacles. Every 8 tenths of a second the all of the sonar’s are updated twice. We get data from each sonar two times to make sure we aren’t getting erratic data. We have the sonar sensors ignoring values over 304mm, which is equivalent to 1 foot. This allows us to only use the values when the obstacle is near the robot. When we do the mapping, the distance used is anything less than 250mm.

Also the obstacle has to be detected at least twice within 1.6 seconds (2 polling cycles).

This compensates for random errors.

After an obstacle has been detected, the program calculates where on the map it is based on the current angle, the current position, and which sonar sensor detected the obstacle. We are only using the left (90) sensor and the right (-90) sensor for the mapping.

When calculating the location of the obstacle, we take the current angle and either add

90 if the left sensor detected it or subtract 90 if the right sensor detected it. We then take the distance from the obstacle detected by the sensor and add 75% of its value to compensate for sonar error. This number is multiplied by the cosine of the new angle for the x direction and sin of the new angle for the y direction. This number is then added or subtracted to the current position of the robot to accurately place the obstacle on the map. The ColorArea() function takes in the calculated values of the obstacle in mm.

The function converts these numbers into pixels for the map. The next challenge was the fact that the AmigoBOT’s coordinate system was totally different than what we are used to. (Fig. A-5) We had to convert the data into the new coordinate system to put the obstacle in the correct place on the map. If an obstacle is detected anywhere inside a square the entire 25 x 25 pixel square which is equivalent to a 1ft square is colored black.

This alters the respective elements in the array and changes the color from white to black.

The CreateMap() function takes the 62,500 element array and writes it to the actual map file.

Testing and Results

Testing of the SurveyBot was an ongoing process that began as soon as communications were established with the AmigoBot. Once implemented, the obstacle avoidance was tested by placing the robot in a variety of situations and making sure it would avoid obstacles encountered. Large, flat obstacles were used mainly for testing, such as cardboard boxes, because they provided a good sonar reflection and were simple to visualize. Smaller objects such as table legs and humans tended to confuse things and were not always detected accurately.

To test the final SurveyBot design, a 10’ by 5’ area was set up with one or two large obstacles (cardboard boxes) randomly placed in the area. The perimeter was kept clear of other obstacles or obstructions. Intermediate goals were created that would cause the robot to traverse the area in a zig-zag pattern while mapping the area. During first tests of the complete SurveyBot design, the robot was able to traverse the given area effectively in the proper pattern, and avoid all obstacles along the way.

The first problem encountered was that after making several large turns, the internal heading data became less accurate due to compounded errors. The robot would turn a little too far and not realize it. This problem was largely solved by implementing smaller, and more gradual turns, rather than abrupt “stop, turn, go,” commands.

Mapping required the most extensive testing and revision. During early tests, the

SurveyBot would properly map the first obstacle encountered, but then would incorrectly map it as it passed by a second time on the way back across the area. Many small refinements were made to the code, and the entire mapping algorithm was eventually re- written in a simpler form, which proved to be more effective. Figure A-7 shows a sample output map created by the SurveyBot.

Project Timeline and Organization

After deciding on an initial project plan, and securing the needed components, the

SurveyBot project was divided into many different tasks, some of which were ongoing at the same time. Obtaining the AmigoBot took longer than expected, and this delay was certainly a bottleneck for the rest of the design process. Building, testing, and tuning the

DGPS system was one of the lengthiest tasks, and fell mainly to Jeremy. The process ended up taking many weeks while group members worked on other parts of the project.

Fortunately, the DGPS was not essential for implementation of the remainder of the project. The first major hurdle was establishing successful communications with the

AmigoBot, which ended up taking more than a week because of poor documentation.

Miguel did most of the thread programming, while Chris designed the parseSensor() routine to decode the incoming packets into variables. Decoding SIP packets correctly proved to be the biggest trouble spot. No other behavior control code could be tested until the computer was talking to the AmigoBot. At the same time, Chris tested different means of communicating with the GPS were tested, and the MGC4C DLL was finally chosen as the simplest means of obtaining position data.

Once reliable communication had been established, behavior control software could be implemented. Because of prior experience in this area, Miguel designed the obstacle avoidance and goal seeking algorithms. The first step was simple obstacle avoidance, followed by obstacle avoidance while seeking a specified goal. This process involved many weeks of tweaks and refinements, and some problems encountered were inaccurate sonar readings at very close distances, as well as imprecise position data received from the robot. All group members were involved with weeks of testing a refinements of the behavior control algorithm.

While testing the behavior software, the mapping software was also being designed, mainly by Jeremy. After deciding on a file format to use for the map data, the mapping algorithm was added and tested along with the behavioral control. Because the two systems are independent, they could be modified independently. The mapping proved to be the most challenging part of the project, with the testing and refinement process continuing right up to the deadline. In the end, the mapping process works effectively yet with low resolution. The project documentation was divided into areas of specialty, with Chris formatting the basic report and the communications and DGPS sections, while Miguel and Jeremy contributed write-ups on their areas of specialty for the project. Overall, the work load was evenly distributed among all members of the team. A complete project gantt chart can be found in figure A-6.

Economic Analysis

The SurveyBot is a valuable platform for the testing of future mapping robot implantations, and such a platform could be of great value to companies pursuing research in this area. The SurveyBot could be a prototype or test bed for much larger scale implantations, saving valuable testing time and money.

Our group averaged about 15 hours per person per week over 12 weeks of work; totaling approximately 540 total hours of work on the project. Using an estimated cost of

$60 per hour for salary and overhead costs, the design process cost about $32,400. The cost of the AmigoBot, GPS, DGPS, and various other parts add about $3000 to this number, in addition to the cost of the required laptop, about $1500. Therefore the total project cost totals $36,900. Should the SurveyBot ever be marketed (most likely to companies pursing research in the area), a selling price of approximately $4000 would ensure that costs would be recovered after the sale of 10 units, leaving a good deal of room for future profits.

Conclusion

The SurveyBot project proved to be successful in creating a mapping mobile robot. Although the current map output is rudimentary, we are confident that more detail and accuracy would be obtainable by implementing more sonar sensors as well as increasing the resolution of the map used. The current project would be an excellent starting point and leaves plenty of room for further expansion of the project.

One of the goals of the project at the outset was to use DGPS, at least partially, for navigation or mapping purposes. Because of the small area being mapped and the relative inaccuracy of the GPS in such a small area, it was not feasible to use the GPS directly for navigation. However, the SurveyBot is set up to accept GPS input, and one approach could be to post-process the map data given a starting GPS coordinate, and add

GPS coordinates to mapped obstacles. Should a project like the SurveyBot ever be implemented on a larger scale, perhaps on an outdoor robot, satellite guided navigation might become more feasible. SurveyBot provides a platform for this.

The idea of a mapping robot has a great amount of potential, and there are numerous uses for such a tool, particularly in hazardous or unreachable areas. The

SurveyBot demonstrates the feasibility of this idea, and provides a platform for future experimentation, especially because code for a larger, more expensive version could be tested first aboard a smaller platform such as the AmigoBot. Appendix A: Photos and Schematics

Figure A-1. AmigoBot with tether.

Figure A-2. DGPS board and complete assembly.

Figure A-3. DGPS block diagram. Figure A-4. Differential GPS receiver schematic. From http://home1.gte.net/clseng/dgps_index.htm.

Normal coordinate AmigoBOT coordinate system  system   Y X

X   Y

Figure A-5. Normal coordinate system Vs. AmigoBOT coordinate system AmigoBot Project Gantt Chart

Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 19-May 26-May 2-Jun 9-Jun 16-Jun 23-Jun 30-Jun 7-Jul 14-Jul 21-Jul Formulate Basic Design Requirements List and Order Required Parts Write GPS Interface Software Write AmigoBot Communications Software Build DGPS Receiver Board Write Navigation and Control Software Write Mapping Software Test DGPS Accuracy Test Navigation Test Mapping Interface DGPS System to laptop Interface Laptop to AmigoBot Test and Refine Entire System Final Report /Presentation / Webpage

Expected Duration Actual Duration Figure A-6. SurveyBot Project Gantt Chart.

Figure A-7. Sample Output Map Appendix B – Software Information

The SurveyBot control program, mycom.exe, will run on Windows 98, 2000, XP, or NT. In addition to the executable file, the MGC4C DLL must be installed on the PC.

This software is for Windows 98 and above and is available free from www.marshallsoft.com. To view output maps created by the program, a viewer capable of opening PGM files is required. For this project we used a free program called

IrfanView, available at www.irfanview.com. The blank input map, inputmap.pgm, must also be in the directory with the executable in order for an output map to be generated.

All required programs are included on the SurveyBot project web page as well as the included CD-ROM. Appendix C: Source Code Appendix D: References

[1] Heineck, Rich. “Build Your Own DGPS Receiver.”

http://home1.gte.net/clseng/dgps_index.htm.

[2] ActivMedia Robotics, Inc. AmigoBOT Technical Manual. Version 1.0

August, 2000.

[3] Trimble Navigation, Ltd. “Differential GPS.”

http://www.trimble.com/gps/dgps.html.