UF Eliminator

2002 International Ground Vehicle Competition Sponsored by auvsi

University of Florida Department of Mechanical and Aerospace Engineering

Center for Intelligent Machines and Robotics

Team Members: Faculty Advisers: Carl Evans Dr. Carl Crane Donald MacArthur Dr. Michael Nechyba David Novick Arfath Pasha Erica Zawodny

2

1.0 INTRODUCTION

The Center for Intelligent Machines and Robotics, which is a part of the Mechanical and

Aerospace Engineering Department at the University of Florida, is submitting the “UF Eliminator” for

participation in the 2002 International Ground Vehicle Competition sponsored by AUVSI. This is the

University of Florida’s first time participating in the ground vehicle competition. This paper will discuss

various aspects of the vehicle’s overall development. The project was divided into four phases that

encompass elements such as platform design, sensor integration, and software architecture. The team

consisted of five Mechanical Engineering graduate students and was advised by faculty from the

Mechanical and Aerospace Engineering and Electrical Engineering departments. The final product was a

robust ground vehicle with extended capabilities in the areas of obstacle detection and avoidance,

computer vision, navigation, and path planning. This paper will present the thought process and effort

required to complete the task.

2.0 BACKGROUND INFORMATION

Personnel at the Center for Intelligent Machines and Robotics have been developing autonomous

ground vehicle systems for several years. Most of this work focused on position based navigation. For

example, road following would be accomplished by first determining the global coordinates of points on

the center line of the road and the vehicle would then be controlled to follow this path. The edges of the

road would not have to be detected during navigation (although the road surface would be monitored for

obstacles, either positive or negative). As such, additional developments had to be made specifically to

address the problem statement defined for the current ground vehicle competition.

Much research at the University of Florida is focused on the development of a generic

architecture for ground vehicle systems. UF personnel are members of the Department of Defense Joint

Architecture for Unmanned Ground Systems (JAUGS) Working Group and are developing an architecture

that is vehicle independent and technology independent. The architecture used on the vehicle entered in

this competition is modeled on the JAUGS philosophy and the modular nature of the architecture has

significantly accelerated this development effort.

3

3.0 PROJECT EVOLUTION

This section will address the different phases of the design process and overall project evolution.

The project was broken up into four phases, each of which enhanced the vehicle’s capabilities. The first

and second phases focused on establishing a stable platform with a robust electrical and power system.

The third and fourth phases focused on addressing the system specific requirements of the competition.

System architecture and software were developed during the course of these two phases.

The design process was conducted using an iterative approach with an emphasis on field-testing

and experimentation. During each phase different capabilities were established and field-tested

extensively before progressing to the next phase. This ensured that lower level functions were solid

before entering the next phase. Consequently, work on higher-level functionality could proceed without

complications from lower level systems.

The team was organized into two sub-teams that were responsible for the navigation and

autonomous challenge, respectively. Each sub-team was organized such that there was a balance of

expertise and workload. There was interaction between the sub-teams to establish commonality between

the software structure and vehicle functionality. Figure 1 shows a timeline of the project and the dates of

each phase.

3.1 Phase I: Platform Development

The first objective in this phase of the project was to develop a

robust vehicle capable of being operated via tele-operation. With the

consideration of the requirement of having a robust platform design and

a fast turn around it was decided to create a platform using a store

bought electric vehicle. A Fisher Price Power Wheels vehicle was

purchased for this project to provide the chassis, wheels, steering mechanism, electric motors, and basic

9/1/2001 10/1/2001 11/1/2001 12/1/2001 1/1/2002 2/1/2002 3/1/2002 4/1/2002 5/1/2002 6/1/2002

8/1/2001 7/1/2002

Phase I:Platform

Development

Phase IV:Software

Development

ProjectCompletion

Phase III:Task Specific

System Requirements

Phase II:Sensor and

Processing Capabilities

Fig. 1: Project Timeline

Fig. 2: Platform as Purchased

4

wiring (see Figure 2). The vehicle specifications allowed for a 60-70 lb payload with a top speed of five

miles per hour. This provided a baseline for the maximum weight of associated electronics, sensors,

batteries, and other necessary equipment.

3.1.1 Power System: The vehicle contains two 12 V, 15 Ah, sealed lead acid batteries. One battery was

designated for the motors and steering actuator. The other battery was used for providing power to all

vehicle electronics. This power arrangement allowed for approximately three hours of continuous

operation of the system. Isolation of the motor power system and the electronics power system

prevented problems associated with large transients during extreme motor operations.

3.1.2 Micro-Controller: A Motorola 68HC11 micro-controller was used to perform low-level motor and

actuator controls (see Figure 3). The micro-controller

generated signals that controlled motor power and steering

position. The low-level software was all written in assembly

allowing for natural and efficient integration of the on-chip

peripherals. The software was designed to be interrupt driven

to allow for quick vehicle response.

3.1.3 Motor Control: Each rear wheel was powered

independently by a 12 V DC motor. Each motor utilized a 12 V RC style speed controller as shown in

Figure 4. The power applied by the speed controllers was regulated by a signal from the HC11 micro-

controller in the form of a pulse width modulated signal.

3.1.4 Steering System: The vehicle used an Ackerman style steering system. Other steering styles were

investigated but the Ackerman style was found during testing to provide adequate turning radius and

Fig. 3: Micro-Controller

Fig. 4: Drive Motors and Speed Controllers

Drive Motor

Speed Controller

5

mobility for the vehicle configuration. Steering control was achieved using a 30 lbf linear actuator and

linkage on the front wheels as shown in Figure 5.

3.1.5 Communications: During this phase the emphasis was on establishing low-level controls with

remote operation capability. This was accomplished by providing a serial communications link directly to

the micro-controller. At this point higher-level electronics could control the vehicle via the serial link. A

one-byte command protocol was developed to allow for ease of communication and inter-operability. The

single byte contained the commanded steering and speed information.

3.1.6 Phase I Testing: Figure 6 shows the Eliminator vehicle at the conclusion of Phase I. A series of

mobility tests were conducted to evaluate the speed and maneuverability of the vehicle on varied terrains

and to evaluate system reliability. The system was judged to be acceptable for the AUVSI competition.

Fig. 5: Steering Actuator

Fig. 6: Phase I System

Steering Actuator

6

3.2 Phase II: Establishing Multiple Sensor Integration and Processing Capability

The purpose of this phase was to increase the capability of the vehicle through addition of a

single board computer and a removable electronics rack that contained all computing hardware. The rack

system was essential to development and testing because it allowed for all high-level electronics to be

removed from the vehicle and powered at a workstation. This provided the ability to analyze test data

and program the vehicle offline.

3.2.1 Power Distribution: Due to the varying voltage requirements of different hardware, regulated 5 V,

12 V, and 24 V busses were built. These busses were contained on the electronics rack to allow for

future hardware integration.

3.2.2 Single Board Computer: A WinSystems AMD K6 II

333 MHz industrial single board computer (see Figure 7)

was incorporated on the vehicle to perform the high-level

navigation and control processing. The board was chosen

because of the large number of on-board peripherals such

as the video card, network card, multiple serial ports, and

USB port. The single board operated off of a 5 V power

supply with low power consumption.

3.2.3 Multiple Sensor Capability: The computer that was selected allowed for multiple sensors to be

integrated using various types of connections. The bulk of the sensor communication was performed via

the four serial ports on the single board computer.

3.3 Phase III: Task Specific System Requirements

This phase focused primarily on the details of the competition and how to tailor the vehicle for

success in both the navigation and autonomous challenges. During this phase the necessary sensors

were procured and tested individually. Low-cost sensors were incorporated into our design when

possible. Innovative techniques were required to integrate these sensors for the competition.

Fig. 7: Single Board Computer

7

3.3.1 USB Camera: A USB Philips ToUCam, shown in Figure 8, was used for all vision applications. This

camera was chosen due to low-cost, functionality, and support across

multiple operating systems to provide visual information during the

autonomous challenge. During testing it was found that the field-of-view

was inadequate to navigate the course using only one camera. There

were two options to overcome the inadequacy of the initial camera

configuration. Either multiple cameras could be used or the camera lens

could be modified. Due to USB bandwidth limitations and extra

processing required when using multiple cameras, the decision was

made to change the camera lens. The new lens increased the field-of-view by a factor of three, which

allowed a large view of the field without using multiple cameras. Passive optical filters were incorporated

to compensate for the camera’s inherent infrared sensitivity.

3.3.2 Laser Range Finder: A Sick LMS 200 laser range finder, shown in Figure 9, was used to detect

spatial obstacles in the vehicle’s path during the

autonomous and navigation challenges. The laser scans

180? at 0.5? increments and produces range values for

every increment. The laser requires a 24 V power supply,

which is provided by the electronics rack. Extensive

software was required to interface this piece of hardware.

This sensor communicates via binary messages across a serial port connection. Input and output

messages required decoding and encoding of data in order to communicate with the laser.

3.3.3 Digital Compass: A Precision Navigation TCM2 electronic compass module,

shown in Figure 10, provided high frequency updated roll and pitch information as

well as bearing information used for general navigation. The compass was

interfaced via serial port and communicated using ASCII messages. The message

style allowed for ease of implementation when incorporated into the system.

3.3.4 GPS: A Garmin GPS 16 OEM module, shown in Figure 11, provided latitude and longitude

information required by the navigation challenge. This module accepts Wide Area Augmentation System

Fig. 8: USB Camera

Fig. 9: Laser Range Finder

Fig. 10: Digital Compass

8

(WAAS) correction signals, which allows position accuracy of less than

three meters. This sensor was chosen due to its low-cost and compact

packaging. This GPS system was extremely rugged and weather

resistant. Another benefit of this GPS is that its antenna is contained

within the GPS casing. The GPS was interfaced serially and required a 5 V power supply. Associated

code was written to parse the NMEA message received from the GPS and convert the data.

3.4 Phase IV: Task Specific Software Development

During this phase the task specific software was developed to successfully achieve the goals of

the navigation and autonomous challenges. During this time all previous efforts were linked to form a

final deliverable. A software architecture was implemented to smoothly integrate all sensor data with

high-level, intelligent software. The software was designed to be modular such that different programs

could easily be included into the overall project software suite. In addition, the architecture is structured

so that different programs run independently but efficiently communicate with other programs.

3.4.1 Software Architecture: The operating system on the single board computer was Red Hat Linux 7.1.

This operating system was chosen because of its many benefits. This operating system is open source,

which allows for innovative implementation of hardware and software. It is very well documented on the

Internet and was found to run very efficiently on robotic platforms.

The software architecture was organized through “shared memory”. The functions of the robot

were broken into processes. Each process was an independent program that can transfer data to and

Fig. 11: GPS

Process Manager

Shared Memory

Process Process Process Process

Sensor Sensor

SensorProcesses

High-LevelOverheadProcesses

Fig. 12: Software Architecture

9

from shared memory. The architecture was organized such that multiple processes may run

simultaneously and interact via shared memory. Each sensor had an associated process that

communicated with the sensor and transferred the data to shared memory. A process manager oversaw

the shared memory data structure and regulated all processes. A schematic of the software architecture

is shown in Figure 12.

This method was beneficial for cases when processes are delayed due to the update rate of a

sensor. The architecture allowed the other processes to proceed even if another process is waiting for

sensor data. This provided a medium for innovative approaches for integrating sensors having different

update rates.

3.4.2 Vehicle Control Unit (VCU): This process communicated with the low-level vehicle control system

(HC11). The VCU operated by maintaining a commanded compass bearing. This process established a

higher level of vehicle control that other processes could collaborate with. The VCU was composed of a

tunable PID controller. During testing the PID controller was tuned to have an optimal response.

The VCU achieved fast vehicle response by utilizing the high frequency compass update rate (30

Hz maximum). This allowed for the desired heading to be maintained in between updates from other

sensors.

3.4.3 Navigation Challenge: This part of the competition required the use of three mission specific

processes that ran along with the standard processes for controlling the vehicle and reading information

from the system sensors. These processes were the waypoint, driver, and arbiter.

Waypoint Process: This process was responsible for reading in a list of waypoints, reading the

vehicle’s current global location, and then calculating the true course (compass heading) and distance to

the desired waypoints. This was a continuous process. When the vehicle received updated global

position information every second, new true course and distance values were calculated to correct for any

deviations from the straightest path to the desired waypoint. Once the vehicle was determined to be

within a given distance threshold to the desired waypoint, the vehicle proceeded to the next waypoint.

This process was repeated until the vehicle had reached each waypoint.

Driver Process: This process was solely responsible for obstacle avoidance during the

Navigation Challenge. It used the VFH+ method developed by Ulrich and Borenstein at the University of

10

Michigan’s Advanced Technologies Laboratory. This method builds a polar histogram around the front of

the vehicle based on data from the vehicle’s laser range measurement system. Obstacles are extracted

from the polar histogram, and the obstacles are then expanded to take into account the vehicle width and

a factor of safety to prevent the vehicle from getting close to a detected obstacle. The VFH+ method

showed that because the vehicle width is considered in the expansions, the vehicle could be treated as a

particle moving through space. The next step in the process generated a binary histogram based on the

width and safety factor adjusted histogram. It then took into account the turning radius of the vehicle to

prevent it from trying to reach a heading that was clear, but would cause the vehicle to collide with an

obstacle that fell within its turning radius. Once these obstacles were expanded based on all of the

aforementioned parameters, any openings in the binary histogram would correspond to directions that the

vehicle could safely pass through. These directions were then used to determine a number of candidate

headings. A cost function, based on a number of vehicle factors, was applied to the candidate headings

and the lowest cost heading was returned as the driver’s desired heading. If the current vehicle heading

was free from obstructions, then the driver returned that it had no desired heading. The driver also sets a

blocked flag when it has no clear path.

Arbiter Process: This process had the responsibility of pulling everything together by looking at

information from the waypoint and driver processes and making the decisions for the ultimate control of

heading and speed of the vehicle. When the vehicle was in autonomous mode, the arbiter commanded

the vehicle to follow the recommended heading from the waypoint process. The arbiter would slow the

vehicle as it approached an obstacle and also as it approached the desired waypoint. Slowing the vehicle

allowed more accurate control, which was crucial during these two conditions. A safety feature of this

process was that it immediately stopped the vehicle if the driver

process set its blocked flag. The vehicle would no longer be able

to drive forward until there was a clear path. It would, however,

be able to be driven in reverse to clear the completely blocked

path.

Waypoint Navigation Algorithm: A genetic algorithm was

used to compute a feasible sequence of waypoints that the vehicle

Fig. 13: Waypoint Navigation Path

11

must seek in the given time. The objective function of the genetic algorithm was similar to that of the

traveling salesman problem. A sequence of waypoints beginning and ending with the start point, and

having a smaller cumulative distance than the total distance the vehicle was capable of traveling in the

given time limit was computed. A sample of a path planned between several waypoints is shown in

Figure 13.

3.4.4 Autonomous Challenge: This part of the competition was broken into four sections, these of which

are depicted in Figure 14. This

application involved visual and spatial

obstacles and visual boundaries. To

successfully navigate the course it was

proposed to use image processing,

obstacle detection, sensor fusion, and

path planning. The core of the

navigation method through the obstacle

course relied heavily on the path planner.

Image Processing/Camera Process: Once a raw camera image was obtained there were several

steps necessary to extract the desired information from the image. The image processing software

successfully extracted line and pothole information from the raw image.

?? Statistical Color Model Technique: In this step a statistical color model was created to

characterize the lines and potholes. The image was processed by comparing the RGB

values of each pixel in an image with that of the color model. This allows for the pixels

that fit the color model to be identified from the rest of the image.

?? Coordinate Transformation: Once the pixels were identified that fit the color model; the

pixel location was transferred from image coordinate space to local vehicle coordinate

space. The transformation was performed using a camera model that was determined

during camera calibration. The camera calibration procedure determined the intrinsic and

extrinsic camera properties used during the transformation procedure. By transforming

the pixel location to the local vehicle coordinate system, the spatial properties of the lines

Fig. 14: Image Processing, Obstacle Detection, and Path Planner Process

Processed Image Path Planner

Obstacles Raw Image

12

and potholes were in a more natural form. This allowed for easier fusion with data from

other sensors and implementation into the path planner.

?? Adaptive Line Extraction: Once the pixels were identified and translated, it was

necessary to distinguish between points on the left and right lines. In order to separate

the data, an adaptive separator algorithm was implemented to establish a distinction

between the right and left lines. After the points were separated, a polynomial was fit to

each set of data. Best-fit algorithms provided indices of the condition of the line fit. This

allowed for data to be rejected or accepted based on the line fit. This algorithm

performed robust processing and lane determination at a low computational cost.

?? Pothole Detection Algorithm: To address the special case of when potholes existed, a

pothole detection algorithm was implemented. This method used blob detection and the

known spatial characteristics of the potholes. Using this information the algorithm could

determine if a pothole was in the image and calculate the location of the centroid.

Obstacle Detection/Laser Process: The laser range finder was used to detect spatial obstacles.

When an obstacle entered the scan area of the laser, the range data contained the polar range

information of the obstacle with respect to the vehicle. The raw laser data was filtered to eliminate noise

and spurious readings.

Sensor Fusion: Extracted data from the image processing and obstacle detection was formatted

into a structure that the path planner could accept. Therefore line and obstacle data was fused into a

single data set.

?? Line data: The polynomial line fits from the image processing algorithms were discretized

to form line segments and ultimately a boundary for the vehicle to navigate through.

?? Obstacle data: Polygons were created around the points that were obtained from the

obstacle detection algorithms. The size and offset of the polygons were tunable

parameters, which compensated for vehicle width and configuration. The obstacle data

included data from the obstacle detection algorithm and pothole detection algorithm.

13

Path Planner Process: The path planner was a software

module that implemented a set of algorithms to compute the shortest

path from a start point to a goal point in a given map. The map could

consist of non-convex and self-intersecting polygonal obstacles and

a boundary. This software module was used as an online path

planner on board the Eliminator. The data that was received from the

sensors is filtered with the help of a set of image processing

algorithms and converted into polygonal obstacle and boundary data.

The path planner took this polygonal data as input and computed the

shortest path from the vehicle’s current position to a goal position

that lied within the sensor range and in free space.

Figure 15 illustrates the steps involved in computing the shortest

path. The ovals represent the input and output stages that involve

reading from and writing to shared memory. The input was first

checked for erroneous data that may hamper further computation.

Once validated, this data was used to compute a visibility graph. The

visibility graph was represented as a two dimensional square matrix

that contained visibility information of every vertex with respect to

every other vertex in the map. A radial sweep line method was used to efficiently compute the visibility

graph. Finally, Dijkstra’s shortest path algorithm used the visibility graph to compute the shortest path

between the start and the goal points. The shortest path was represented as a list of points, beginning

with the start and ending with the goal point.

The overall complexity of the algorithm was O(n2lgn)

where n was the number of vertices in the input map. Figure

16 shows a simulation of the path planner. The map contains a

set of obstacles, a boundary, and a start and goal points. The

start and goal points also contain vehicle-heading information.

Pseudo obstacles were drawn around the start and the goal

validate input data

compute visibility

graph

find shortest path

filtered data from

sensors

path data

Fig. 16: Path Planner

Fig. 15: Path Planner Algorithm

14

points in order to compute a path that the vehicle can steer into with its current heading and end with the

final heading. The obstacles were expanded and the boundary was shrunk in relation to the vehicle’s

dimensions and turning radius. By doing this, the vehicle was shrunk down to a point and the shortest

path was then computed for this point in free space.

4.0 COST ESTIMATE

An itemized list of the vehicle components and their associated costs is listed in the figure below.

Component Quantity Unit Price Price

Base Vehicle 1 $220 $220

ERC Linear Actuator 1 $500 $500

Victor 883 Speed Controllers 2 $130 $260

Sealed Lead Acid Batteries 2 $75 $150

Sick LMS 200 1 $5,500 $5,500 WinSystems Single Board Computer 1 $1,500 $1,500

PNI Digital Compass TCM2 1 $700 $700

Garmin GPS 16 1 $170 $170

Phillips ToUCam 1 $65 $65

RF Remote Relay System 1 $35 $35

HC11 single chip board 1 $25 $25

Wide Angle Camera Lens 1 $50 $50

DC/DC converters 1 $250 $250

Acrylic Sheeting 1 $100 $100

Misc. Electronics 1 $200 $200

Misc. Mechanical Parts 1 $100 $100

TOTAL $9,825

5.0 SAFETY

Several measures were taken to ensure safe operation

of the vehicle at all times. The safety precautions prevent

damage to the vehicle body, electronics, and operators. Due to

the extreme currents that the batteries could produce when

shorted, several layers of safety were installed. Fuses were

used at the major power connections of the electronics rack and

linear actuator. These prevent damage to the electronics when the current draw exceeds a specified

value.

Fig. 17: RF Remote Relay System

Fig. 18: Itemized Costs

15

A mechanical and wireless RF switch enabled E-stop operations. In order for the vehicle to be

placed in the brake mode, the power could not simply be disconnected from the motors. While on an

incline, the vehicle weight would cause the motors to back drive. The speed controllers have a braking

option, which prevented the back driving of the motor while in neutral. Initiating the mechanical or RF E-

stop switch would place the motors in a neutral state. For improved safety, mechanical and RF kill

switches were installed in the vehicle to completely disconnect the motor power.

6.0 CONCLUSION

This paper has described the process by which the “UF Eliminator” was constructed and

developed. The project evolution was described, providing an in-depth look into the various phases of the

design and development process. The “UF Eliminator” vehicle is an agile and robust platform that

encompasses aspects of Mechanical Engineering, Electrical Engineering, and Computer Science

Engineering. With a maximum speed of five miles per hour, the vehicle can perform image processing,

obstacle detection and avoidance, sensor fusion, waypoint navigation, and path planning.

7.0 ACKNOWLEDGEMENTS

The development team would like to gratefully acknowledge the support provided by the Air Force

Research Laboratory at Tyndall Air Force Base, Applied Research Associates, Inc., Wintec Inc., and

Precision Navigation Inc.