GPS Navigation for Field Mobile Robotscourses.cs.tamu.edu/rgutier/cpsc483_s04/reports/gps-cdr.pdf · GPS Navigation for Field Mobile Robots – Critical Design Review Page 2 of 41

GPS Navigation for Field Mobile Robots – Critical Design Review

Page 1 of 41

GPS Navigation for Field Mobile RobotsCritical Design Review

Chris FoleyKris Horn

Richard Neil PittmanMichael Willis

CPSC 483March 8, 2004


Page 2 of 41

Table of Contents

I. Review of Project 4A. Problem Background 4B. Needs Statement 4C. Goals and Objectives 4D. Literature and Technical Survey 4E. Design Constraints and Feasibility 6F. Evaluation of Alternative Solutions 6

II. Final Design with Component Descriptions 8A. System Block Diagram 8B. Alternative Designs 9C. Component Descriptions and Interfaces 10

i. Mark III Control Board with OOPic 10 ii. Steering Servo 12 iii. Throttle Control Servo 12 iv. Shaft Optical Encoder 12 v. Front Sonar Left 13 vi. Front Sonar Center 13 vii. Front Sonar Right 13 viii. Rear Sonar 13 ix. GPS Receiver 14 x. Compass 14 xi. LCD 15 xii. Keypad 15 xiii. Serial Interface 15 xiv. Battery 16 xv. Voltage Regulation 16

III. Subsystems 17A. Collision Avoidance System 17

i. Circuit 17 ii. Interfaces and Pin-Outs 17 iii. Timing Diagrams and Waveforms 18 iv. Software Processes (in C) 18 v. Parts List 19

B. Speed Control System 19 i. Circuit 19 ii. Interfaces and Pin-Outs 20 iii. Timing Diagrams and Waveforms 21 iv. Software 21 v. Parts List 23

C. Navigation System 23 i. Inputs 23


Page 3 of 41

ii. Outputs 23 iii. Function 23 iv. Parts List 24

IV. Validation and Testing Procedures 24

V. Schedule 25

VI. Division of Labor and Responsibilities 26

VII. Review of Engineering Standards 27A. Economic Analysis 27

i. Economic Viability 27 ii. Sustainability 27 iii. Manufacturability 27

B. Societal, Safety, and Environmental Analysis 28

VIII. Appendices 29A. OOPic Test Code 30B. Sample MATLAB Code 39C. Product datasheets 41


Page 4 of 41

Review of Project

Problem Background

Today many electronic devices are automated, and unmanned. There are manyapplications in which having an unmanned robot is safe and can save humanlives. An example is a robot that travels into a mine field to detonate a dangerousmine. This robot could use GPS coordinates to navigate to a specific location toperform the necessary tasks. In addition there must be some form of obstacleavoidance. One example would be the use of sonar devices to avoid obstacles.

Needs Statement

With so many dangers arising today and because of the advancement oftechnology, there is a need for automated and unmanned devices. The militaryhas a need for GPS guided systems to protect the lives of soldiers. Civilians alsocould benefit from GPS guided systems by making everyday navigation easierand safer.

Goals and Objectives

Our goal is to develop a GPS guided system that will successfully navigate to aseries of pre-defined coordinates.Our objectives consist of the following:

• Develop a system that will be sturdy enough to cover mostly flat terrainwhile carrying a payload of electronic equipment including the globalpositioning system

• Develop a system that will be able to establish its own location on earthand use information from the global positioning system to navigate to auser defined GPS coordinate

• Vehicle will be able to follow a path of points provided by a user• Vehicle will be able to avoid obstacles along the way, and still navigate to

the user defined coordinates

Literature and Technical Survey

Our team has utilized several resources to familiarize ourselves with thecomponents that will make up our final project. We researched general GPSrelated articles as well as specific data sheets of GPS units. In addition we havelearned about radio controlled cars, and how to modify them. The proposeddesign for the GPS unit will incorporate a compass system that has already beenused by a CPSC 483 group from last semester. Our group will need to be familiar


Page 5 of 41

with the literature provided by the compass group from last semester. Below isthe list of resources that we have used so far:

www.navtechgps.com• This site allowed us to learn about several GPS units and compare prices

www.howstuffworks.com• Contains general information about how GPS units work.

www.junun.org/MarkIII• Contains documentation of the Mark III board that we are using.

www.qkits.com• Another site that sells electronic kits such as GPS kits.

www.epemag.wimborne.co.uk/lcd1.pdf• An article titled “How to use Intelligent Lcds”

www.doc.ic.ac.uk/~ih/doc/lcd/operatio.html• Contains documentation on the HD44780 lcd standards.

http://studentweb.tulane.edu/~jreasor• This site is the homepage of a Tulane graduate student who is doing a

similar project.

www.oopic.com• Contains documentation of the OOPIC which is the microprocessor that

we are using.

http://www.superdroidrobots.com/sensors_compass.htm• Contains information about the electronic compass.

http://www.digitalnemesis.com/catalogue/RLC1/RLC1.htm• Contains information about an rs232 to TTL converter.

The Devantech SRF04 Ultrasonic Range Finder• This is the data sheet for the Sonar devices that we are using

Optical EC Encoder Kit Documentation from US Digital• This is the data sheet for the optical encoder that we are using


Page 6 of 41

Design Constraints and Feasibility

Through the design process we will be limited by several different types ofconstraints. The first of these constraints is budget. We do not have a fixed limiton how much we can spend for this project. However we must justify eachpurchase by making sure that it is the most cost effective part and that it isnecessary to reach the final goal. We have been asked to keep the project to anapproximate cost of five hundred dollars.

Another constraint of this project is time. We only have one semester to completethe final product. Therefore we have to be careful in how far we plan to take theproject. Our team must find a medium between a project that is feasible tocomplete, and a project that is challenging. A major effect of our time constraintis ordering parts. It will be imperative that parts are ordered as soon as possibleso that we are not waiting on parts to begin construction. It will also be importantthat we hold the vendors responsible for shipping our ordered parts in a timelymanner.

The technical scope of our project is yet another possible constraint. This ispartially related to the time constraint. Since we are on a limited schedule, aproject that is too difficult and too technically challenging may not be possiblegiven the teams experience with this subject. However, our project needs to bechallenging enough so that we are generating the best possible product withinthe given time period.

Evaluation of Alternative Solutions

Throughout the initial design process we have come up with several alternativesolutions to various aspects of our project. One solution that we have consideredis not using a compass for the navigation of the RC car. We have consideredusing a navigation algorithm that would not require the use of a compass. Thisnavigation algorithm is based on comparing the RC car’s current location with itsprevious location. From that data we can determine which direction the car needsto turn in order to get closer to its destination. This process would be repeatedevery second or so until the destination is reached. Although this solution mayrequire less hardware, it may not be as accurate as using a compass todetermine which direction the car should turn. In addition, compass navigationhas already been used in a previous project. So, it would be relatively simple toimplement the compass into our system. The compass hardware is already builtand we have access to the software and the documentation of the compassdesign as well.

Each time the RC car goes to a desired set of GPS coordinates, thosecoordinates must be programmed into the system. One possible method of doingthis is having everything needed to program a new coordinate set located on the


Page 7 of 41

car. This would require an LCD screen to ask the user what coordinates to enter,as well as a keypad of that would allow the user to input the coordinates.However this solution may be too difficult to implement given our timeconstraints. An alternative solution to programming the new coordinates wouldbe the use of a PDA or a laptop. For example, whenever a new coordinate set isdesired the laptop or PDA could be hooked up to the system and reprogrammedvia a serial link. Although this solution is not as desirable, it is more feasible giventhe scope of this project.

One of our concerns at this point in the project is being able to control the RC caraccurately. There is not a large amount of documentation publicly available forRC cars. One possible solution would be to directly tap into the servos of thesteering and the drive motors of the car and completely bypassing the RC car’scontrols. This may be the simplest solution since most servo motors are verysimilar to each other, so it would not be very difficult to learn how to control them.However another proposed solution is to use the remote control of the RC car tomove the car in the desired direction. This would require us to have extensiveknowledge of how the remote control circuit works and would likely be too difficultto implement. Although, we may be able to contact the manufacturer of the RCcar and get a copy of the technical documentation which would help us to knowhow the remote control functions. Having the documentation would allow us tomake a more informed decision regarding which method of controlling the carwould be best.

Throughout the design process we will be faced with possible alternativesolutions to various problems. With each new alternative solution it is imperativethat we evaluate each proposed solution based on budget, time constraints, andfeasibility.


Page 8 of 41

Final Design with Component Descriptions

System Block Diagram

Figure 1: System block diagram of robot’s final design

The final design for the robot car is a combination of all the best featuresresearched by the design team. The design incorporates a versatile sonarconfiguration for detecting obstacles in front and from behind. The design alsoincludes an optical encoder to monitor speed controlled by the throttle servo.This configuration utilizes a compass and GPS in the navigation system todetermine course to destination. The robot will communicate with the user usinga serial interface to a computer. The overall control of the robot car’s system willbe operated by the Mark III control board with OOPic microcontroller.


Page 9 of 41

Alternative Designs

Figure 2: System block diagram of alternative design 1



Page 10 of 41


Above are three alternative designs for the robot car that the design team hasconsidered and at this time rejected. The reasons for rejecting these designsinclude differences in the design of the collision avoidance system with regard tosonar configuration. Two of the rejected designs incorporate a sonarconfiguration that only looks ahead and offers no data on what is behind therobot car. While it offers superior monitoring from the front this lack of sensingability in the rear was determined to be unacceptable especially in the case ofallowing movement in reverse. The difference in these designs compared to thefinal design is that two of these designs use an alternative means of interfacingwith the user. Alternative designs 1 and 2 utilize a keypad to accept destinationcoordinates from the user instead of the serial interface. This was rejected onthe basis that setting up a keypad interface would be too complicated and timeconsuming in comparison to the serial interface in order to complete the projectgoals.

Component Descriptions and Interfaces

Mark III Control Board with OOPicPin IN/OUT DeviceV+ IN Voltage Regulation (Power)Vin IN Battery (Power)GND IN Battery (GND), Voltage Regulation (GND)IC2 Serial Bus IN Compass (Serial Data), Compass (Serial

Clock)IO LINE 1-2 NA not used


Page 11 of 41

IO LINE 3 IN Serial Interface (Toggle)IO LINE 4-5 IN Shaft Optical Encoder (IO 1-2)IO LINE 6 OUT Rear Sonar (Ping) (only on Final Design & Alt.

Design 2)IO LINE 7 IN Rear Sonar (Echo) (only on Final Design & Alt.

Design 2)IO LINE 8 OUT LCD (Data Strobe)IO LINE 9 OUT Throttle Servo (Data)IO LINE 10 OUT Steering Servo (Data)IO LINE 11 OUT LCD (Register Select)IO LINE 12-15 OUT LCD (Data 1-4)IO LINE 16 OUT Front Sonar Left (Ping)IO LINE 17 IN Front Sonar Left (Echo)IO LINE 18 OUT Front Sonar Center (Ping) (only on Alt. Design

1 & 3)IO LINE 19 IN Front Sonar Center (Echo) (only on Alt. Design

1 & 3)IO LINE 20 OUT Front Sonar Right (Ping)IO LINE 21 IN Front Sonar Right (Echo)IO LINE 22 OUT GPS Receiver (Serial In), Serial Interface

(Serial In) (only on Final Design & Alt. Design 3)

IO LINE 23 IN GPS Receiver (Serial Out), Serial Interface(Serial Out) (only on Final Design & Alt. Design 3)

IO LINE 24-31 IN Keypad (Data 1-8) (only on Alt. Design 1 & 2)5V Source OUT Compass (Power), Shaft Optical Encoder

(Power), LCD (Power), Keypad (Power), Throttle Servo (Power), Steering Servo (Power), Rear Sonar (Power), Front Sonar Left (Power), Front Sonar Center (Power), Front Sonar Right (Power), GPS Receiver (Power)

Gnd IN Compass (GND), Shaft Optical Encoder(GND), LCD (GND), Keypad (GND), ThrottleServo (GND), Steering Servo (GND), RearSonar (GND), Front Sonar Left (GND), FrontSonar Center (GND), Front Sonar Right(GND), GPS Receiver (GND)

The Mark III control board is the control center of the robot car. It will accept datafrom the sensors including sonar, compass, and GPS. Then, using this data, itwill run the navigation software that will be programmed into the OOPic microcontroller. This navigation software will make the necessary commands tocontrol the throttle and steering of the robot car to arrive at the desired


Page 12 of 41

destination. The OOPic has a regulated 5V source that will supply power for theexternal components.

Steering ServoPin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)DATA IN Mark III (IO LINE 10)

The steering servo is servo used to control the orientation of the front wheels ofthe robot car. By rotating the servo the front wheels of the robot car turn allowingthe robot car to maneuver. A ServoSP1 object in the OOPic software, thatcontrols the robot car, represents the steering servo internally. When the valueof this object is set, a pulse modulation is sent to the servo on IO LINE 10 of theMark III control board and the servo responds by rotating to the desired angleindicated by the set value.

Throttle Control ServoPin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)DATA IN Mark III (IO LINE 9)

The throttle servo is servo used to control the voltage output to the robot carmotor. By rotating the servo the voltage is adjusted so that the motor will propelthe car forwards or backwards. A ServoSP1 object in the OOPic software, thatcontrols the robot car, represents the throttle servo internally. When the value ofthis object is set, a pulse modulation is sent to the servo on IO LINE 9 of theMark III control board and the servo responds by rotating to the desired angleindicated by the set value.

Shaft Optical EncoderPin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)IO 1 OUT Mark III (IO LINE 4)IO 2 OUT Mark III (IO LINE 5)

The shaft optical encoder is an optical encoder mounted to the drive shaft of therobot car in order to monitor the speed at which the wheels of the robot car arerotating. Using this information as feedback the software on the OOPic will beable to adjust the value of the throttle servo to regulate the speed of the robot


Page 13 of 41

car. The shaft optical encoder is represented inside the OOPic software as aQencode object.

Front Sonar LeftPin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)Ping IN Mark III (IO LINE 16)Echo OUT Mark III (IO LINE 17)

Front Sonar Center (only on Alt. Design 1 & 3)Pin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)Ping IN Mark III (IO LINE 18)Echo OUT Mark III (IO LINE 19)

Front Sonar RightPin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)Ping IN Mark III (IO LINE 20)Echo OUT Mark III (IO LINE 21)

Rear Sonar (only on Final Design & Alt. Design 2)Pin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)Ping IN Mark III (IO LINE 6)Echo OUT Mark III (IO LINE 7)

The sonar modules are part of the robot car’s collision avoidance system todetect obstacles in the path. The robot car will have three sonar modules in aconfiguration to allow the robot car to detect objects ahead, determine the extentof obstacles to the right and left, and if obstacles are behind the robot (see Figure5). Inside the OOPic software the sonar modules are connected to a clockobject. The sonar modules check for obstacles when their operate field goesfrom high to low. The clock is set up to send a clock signal to the sonar that willresult the robot car checking for obstacles twice a second. If an obstacle isdetected an interrupt inside the OOPic software will execute a collision avoidancealgorithm.


Page 14 of 41

Figure 5: Sonar configuration for collision avoidance system

GPS ReceiverPin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)Serial In IN Mark III (IO LINE 22)Serial Out OUT Mark III (IO LINE 23)

The GPS Receiver is a Garmin 15L GPS receiver that constitutes the center ofthe robot car navigation system. The GPS receiver communicates using a serialinterface and is represented as a serial port object in the OOPic software. TheGPS receiver will provide the robot car navigation software with its currentlocation to allow the software to determine steps to get the car from this positionto its destination. The GPS receiver is connected to the Mark III control board onits dedicated serial lines, IO LINE 22 and IO LINE 23.

CompassPin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)Serial Data OUT Mark III (IC2 Serial Bus)Serial Clock IN Mark III (IC2 Serial Bus)

The compass is an electronic device that provides the orientation of north relativeto itself. Using this information the robot car has the ability to determine its


Page 15 of 41

orientation relative to its destination. The navigation software programmed ontothe OOPic will use this information to formulate the commands to the robot carnecessary to get to its destination. The compass is represented internally as anIC2 object and communicates on the OOPic’s IC2 communication bus.

LCDPin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)DATA IN Mark III (IO Line 12-15)Data Strobe IN Mark III (IO Line 8)Data Register Select IN Mark III (IO Line 11)

The LCD will be mounted on the surface of the robot car body and will be used toprovide feedback to the user. The LCD will provide information to the user aboutthe performance of the navigation software including the coordinates the robotcar believes it to be located. The LCD is represented inside the OOPic code asan LCD object that sends data on four data lines and updates using a data strobeand register select. The LCD will also be used to confirm information given bythe users including destination coordinates.

Keypad (only on Alt. Design 1 & 2)Pin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)DATA IN Mark III (IO LINE 24-31)

The keypad is a simple sixteen-button pad in a configuration similar to a touch-tone phone. The keypad is an alternative interface to the serial interface forinputting destination coordinates into the robot car. The keypad interfaces withthe Mark III board using eight pins, including IO LINES 24 through 31. Half of thepins are used to indicate the row and the other indicate the column. A keypadobject represents the keypad internally.

Serial Interface (only on Final Design & Alt. Design 3)Pin IN/OUT DeviceVCC IN Mark III (5V Source)GND OUT Mark III (Gnd)Toggle OUT Mark III (IO LINE 3)Serial In 1 IN Mark III (IO LINE 22), GPS Receiver (SerialOut)Serial Out 1 OUT Mark III (IO LINE 23), GPS Receiver (Serial In)Serial In 2 IN Computer


Page 16 of 41

Serial Out 2 OUT Computer

The serial interface is a combination of smaller components still to be designedinto a whole. The components of this interface include a switch between theserial interfaces between the GPS and the Mark III and the Mark III and acomputer, and a RS232 converter chip to convert the voltage levels from TTL onthe Mark III side and RS232 on the computer side. The software on the OOPicwill be able to know whether it is communicating with the GPS or the computerusing a toggle signal on IO LINE 3.

BatteryPin IN/OUT DeviceVoltage Source OUT Mark III (Vin), Voltage Regulation (Vin)GND IN Mark III (GND) Voltage Regulation (GNDin)

The battery is a 7.2 V battery that was provided to power the remote control carbefore it was modified into the robot car. The power distribution scheme for therobot car will be set up to run on this battery alone. Since this battery provides avoltage that is too high for the servos, a voltage regulation component will benecessary to lower the voltage to be safe for the servos.

Voltage RegulationPin IN/OUT DeviceVin IN Battery (Voltage Source)GNDin OUT Battery (GND)Vout OUT Mark III (V+)GNDout IN Mark III (GND)

The voltage regulation component is going to contribute to the power distributionscheme. The servos that control the steering and throttle have a lower voltagerange than that of the Mark III board. Therefore the voltage provided by thebattery must be reduced before it is given to the servos. A proposed solution isto connect the power and ground to the servos that were used to power thembefore the car was modified.


Page 17 of 41

Subsystems

Collision Avoidance System

Circuit

We decided to use sonar rather than infrared to detect obstacles obstructing thepath of our truck. Using sonar, we are able to detect obstacles at a greater rangethan infrared. Sonar is also immune to distortion from the ambient lighting of thesun. The sonar we used for this project is the ultrasonic ranger DevantechSRF04. It has a range from 3 inches to 10 feet.

Figure 6: Devantech SRF04

Figure 7: Sonar Range

Interfaces and Pin-Outs

The Devantech SRF04 provides an easy to use controller interface. The sonaruses 4 pins to configure: power, ground, echo pulse output, and trigger pulseinput. When a positive edge (0 to 1) is sent to the TRIGGER input a ping isemitted from the sonar, which brings the ECHO line high. This is where you startyour timer. When the ping is bounced off an obstacle the sound reflects back tothe sonar. When the sonar detects the return of the ping the ECHO line isimmediately brought low.


Page 18 of 41

Timing Diagrams and Waveforms

Figure 8: Sonar Timing Diagram

To calculate distance you take the time measured from the ECHO line andmultiply it by the speed sound. At ground level sound takes approximately 1.8milliseconds to travel one foot out and back, in other words two feet.

Distance object is from sonar (feet) = (time in milliseconds)/1.8

Software Processes (in C)

The software that comes with the OOPic microcontroller already has a controllerinterface for the sonar. The counter (tics) is incremented 64 times for a ping totravel two feet.

Distance object is from sonar (feet) = (tics)/64

// SONAR example; Sends data to LCD.

oSonarDV Frtsonar = New oSonarDV;

Sub void main(void){

Frtsonar.IOLineP = 12; //trigger to SRF04 Frtsonar.IOLineE = 13; //echo to SRF04 Frtsonar.Operate = cvFalse;

While(1){Frtsonar.Operate = 0;Frtsonar.Operate = 1; //Trigger one reading

While (Frtsonar.Received = cvFalse){ //wait for echo}


Page 19 of 41

if (!Frtsonar.Timeout) {printdata(Frtsonar / 64); //distance calculated in feet. Sent to an LCD.

}OOPic.delay = 50; // give _ second for LCD to display characters

}}

Parts List

• Three Devantech SRF04 ultrasonic rangers.• Hardware to mount sonar to RC truck.

Speed Control System

Circuit

To change velocity of the robot we decided to use the stock manual speedcontroller. This simply means that a servo is used to control the throttle. Thevelocity of the car is measured using an optical kit encoder from US DigitalCorporation. The encoder updates the OOPic of its current velocity. The OOPicthen decides whether the car is going too fast or slow. If the OOPic needs toupdate the cars velocity it sends a signal to the throttle servo, which adjusts thevoltage to the motor.

Figure 9: Optical Kit Encoder


Page 20 of 41

Figure 10: Manual Speed Control Schematic

Interfaces and Pin-Outs

The standard servo has three pins for configuration: Power, Ground, and inputpulse data line. The data line is used to turn the servo a certain number ofdegrees. Our servo rotates 180 degrees, -90 to 90 degrees. The Mark III boardprovides two convenient 3 pin-outs for controlling two servos, one for the throttleand one for the steering.

The optical encoder kit has five pins: Power, ground, channel A, channel B, andindex. Channel A and B are outputs that are used to detect the angular speed.The channels are used to read a quadrature track.


Page 21 of 41

Figure 11: Optical Kit Encoder Details

Timing Diagrams and Waveforms

Channel A and Channel B are used to tell which way the encoder’s shaft isrotating and how fast. When Channel A leads Channel B the shaft is rotatingclockwise, if Channel B leads Channel A the shaft rotates counterclockwise. Theindex is pulsed once every revolution.

Figure 12: Encoder Timing Diagram

Software

The OOPic II+ provides easy to use software for controlling hobby servos and theoptical encoder. The servo object we use in the software has a data range from -128 to 127. This is the number range used to turn the servo. The encoder objecthas a 16 bit number that is incremented or decremented when shaft has rotated.This makes it easy to detect the rotational speed using a simple timer.

To control the throttle we needed to detect the data range for neutral. We foundout that neutral ranged from 22 to 35. This means that if the servo has a datavalue between 22 and 35 the RC truck motor will not be powered. Anythingabove 35 will turn the trucks motor.


Page 22 of 41

Below is a simple program in C that controls the speed to an average of 2 feetper second using the wheel encoder.

oWord temp = new oWord; // used in the encoder eventoByte start_value = new oByte; // the value for the servo when the car begins to moveoByte throttle_value = new oByte; // Servo throttle valueoQEncode encoder = new oQencode; // wheel encoder objectoTimer timer = new oTimer; // 16 bit timeroEvent Throttle = new oEvent; // Computes the servo throttle (like a class)oServoSP1 Thrservo = New oServoSP1; // Servo object that controlls throttle

Sub Void Main(void){

encoder.IOLine1 = 1; // (pin #7) Channel B on encoderencoder.IOLine2 = 14; // (pin #8) Channel A on encoderencoder.Signed = 0; // value ranges from 0 - 65,535encoder.Operate = cvTrue;

timer.ExtClock = 0; // Use programmed 5 MHz internal clocktimer.Prescale = 3; // Divide Clock by 4 (5 MHz/ 4 = 1.25 MHz)timer.Operate = cvFalse; // Turned offtimer = 0; // Clear 16-bit counter

Thrservo.IOLine = 9; Thrservo.Center = 0; Thrservo.Operate = cvTrue;

Thrservo.value = 33; // puts truck in neutral, careful when changing

OOPic.delay = 700; // Wait 7 seconds before take off

while(encoder.Moved == 0){Thrservo.Value = Thrservo.Value +1;OOPic.Delay= 10; // wait 100 milliseconds

}

while(1) // this while loop is the center of the trucks programming.{ // events are activated when their "Operate" value goes from cvFalse to a cvTrue (0 to 1)

Throttle.Operate = cvFalse;Throttle.Operate = cvTrue; // Execute encode_CODE once

}

}//main//**********************************************************************************************************************************// We want the truck to travel 2 wheel revolutions / second// There are 2.75 encoder shaft revolutions / 1 wheel revolution// The 16 bit encoder value is updated 128 times / 1 encoder shaft revolution// Taking the above information yields, (2)*(2.75) = 5.5 encoder shaft revolutions / second// (5.5) * (128) = 704 updated encoder value / second//// In 1/64 of a second (a random value chosen) the encoder should have been updated 11 times.// A speed between 9 and 14 should be adequate.

Sub Void Throttle_CODE(void){ // encoder code

do{

Thrservo.Value = throttle_value;

if(encoder.Value > 64000 ){encoder.Value=0;

}

timer.Value=0;temp = encoder.Value;timer.Operate = cvTrue;

while(timer < 9766){}

timer.Operate = cvFalse;temp = encoder.Value - temp;

if( (temp >= 14) ){throttle_value--;

}else if( temp <= 9 ){


Page 23 of 41

throttle_value++;}

}while( (temp < 9) | (temp > 14) ); // loop until the speed is correct

}//encode_CODE

Parts List• Battery (6 – 18 volts)• Mark III board (OOPic Microcontroller)• Hobby Servo• Manual Speed Controller• DC Motor• E3 Optical Encoder from US Digital

Navigation System

Inputs

destination coordinates, current GPS coordinates, compass heading, steeringcommands (from collision avoidance system)

Outputs

steering control commands, speed control commands, coordinate reading

Function

The purpose of the navigation subsystem is to control the movement of the robotalong a path from one destination to another. In order to do so, the navigationsystem needs the appropriate inputs from the GPS, compass, collision avoidancesystem, and the operator (destination coordinates). Based on the combination ofthese inputs, the robot will use an algorithm programmed into the OOPicmicrocontroller to determine the appropriate movements for steering and speedcontrol.

This algorithm, while still in its early phases of development, calculates thedistance between the destination coordinates and the current location as well asthe difference between the direction that the robot is currently facing and thedirection that it needs to be facing. Depending on these calculations, the robotwill turn at varying degrees to correct its path. If an obstacle is detected by thecollision avoidance system, the robot will attempt to steer around the obstacleuntil the obstacle no longer hinders the path to the destination. Since the


Page 24 of 41

originally planned, direct path to the destination may have obstacles, the robotwill always attempt to calculate the best possible path from its current location. Ifan obstacle forces it to deviate from this path, it will attempt the best possiblepath from its new location.

Parts List

The navigational subsystem is composed of the following parts:• GPS receiver and antenna• Wired serial connection• OOPic• Mark III board• Electronic compass

Validation and Testing Procedures

There are several different aspects of our project that will need to undergo testingin order to validate our design. As an overall test, once the project is finished, wewill test that the robot is able to navigate from one set of coordinates to the next.We will try this with various different coordinates and paths to ensure that therobot can handle them properly. However, to get to this point in our project, wewill have to do several tests on smaller components that make up the wholeproject.

To determine how well the OOPic is able to control the throttle, we have testedthe car on both grass and concrete surfaces. At the current time, the car doesnot perform equally on different surfaces so we are adjusting the design to meetthis need.

Once the motor control has been successfully accomplished, we will move on totesting the steering control. We will test the car, on multiple surfaces again, toverify that it is able to turn at specified amounts.

Other tests include verifying the accuracy of the sonar sensors by placing therobot in different environments. Currently we have the sonar measurementsoutput to the LCD so that we can confirm the sonar reading.

We will take the GPS to various locations and record the readings we find todetermine the reliability of its outputs. Once this has been done we will integratethe GPS with the OOPic and make sure that we successfully read from the GPS.

When all the smaller components have been tested, we plan to integrate thecomponents, one at a time, and verify that they work correctly together.


Page 25 of 41

We are writing the navigation algorithm in MATLAB first so that we can simulatethe path that the robot will take. Once in proves successful in MATLAB, we willconvert it to C and program it into the Mark III board. We will then have the taskof making sure that the other subsystems interact correctly with the algorithm andthat the robot as a whole can navigate its course successfully.

Schedule

The following Gantt chart in Figure 13 shows our updated schedule that we planto follow.

Figure 13: Gantt Chart of our projected schedule


Page 26 of 41

Division of Labor and Responsibilities

We have divided the tasks into two main groups,1. The GPS unit and Navigation Algorithm2. Compass, Sonar and Servos GPS unit and Navigation Algorithm: Chris and Michael

o Chris’s responsibilities Develop a simulator using Matlab to test various navigation

algorithms Determine the best method for regulating the current on the

GPS to ensure that the current stays close to the required 85mA.

o Michael’s responsibilities Survey various testing sites using the GPS unit and a laptop

to determine which testing site will give the most accuratedata

Determine the accuracy of the GPS based on testing acertain location multiple times.

o Chris and Michael Determine which navigation algorithm will be most

successful Develop the code for the desired navigation algorithm in C

Compass, Sonar, Servos and Optical Encoder: Kris and Neilo Kris’s responsibilities

Interface the steering servo and speed control servo with theOOPic on the Mark III board

Mount the sonar, compass, Mark III board, and opticalencoder securely onto the RC car

o Neil’s responsibilities Interface the compass with the OOPic Write the code to communicate with the Sonar devices and

the optical encodero Kris and Neil

Ensure that the Sonar, Compass, and optical encoder are allable to send data to the OOPic

Control the speed of the RC car based on the data from theoptical encoder


Page 27 of 41

Review of Engineering Standards

Economic Analysis

Economical Viability

This system could potentially be very marketable given the need for automatednavigation. It is difficult to predict the cost of mass producing a device such asours. We estimate that we could save approximately 25% on our material costs,bringing the total equipment cost per unit to $315. It will take an estimated 2hours to assemble the product, and approximately 30 minutes to effectively testthe device before shipping. If it costs $15 dollars per hour for the labor ofassembly and testing, then the total cost per unit would be $352.50.

Sustainability

All of the parts on our system are available from more than one vendor. So, ifone of our vendors were to go out of business, then we would still be able tomanufacture our product. If the product is assembled correctly, then the onlymaintenance that the product would need would be replacing the componentsthat malfunction during use. This would only need to be done if one of thecomponents wears out or is damaged. The product will ship with clear andconcise instructions; however it may be necessary to provide technical support toour customers.

Manufacturability

Our production yield would be directly related to the number of assemblers wehad working for our company. It is expected that each assembly worker couldassemble and test one unit in 2.5 hours time. The GPS unit requires a fairlyspecific voltage and current. However if the same components are used for eachunit, then this should not be a problem.

Once manufactured, there are some variables that can affect systemsperformance. The primary concern here would be the accuracy of the GPSreadings. Worst case, the GPS readings could have an error of 15 to 20 meterswhich could be unacceptable for some applications. On average, the GPS isexpected to be accurate to within 5 to 10 meters, and the best case would bewithin 3 meters. Much of this accuracy will depend on the environmentalconditions in which the robot is. If the area has many large obstacles (buildings,trees, etc.) or if the weather is below par, the inputs from the GPS will probablynot be as accurate. While we have had some complications thus far with ourGPS, our next step is to test the GPS in multiple environments to determine anaverage accuracy. Another variable that can affect system performance is the


Page 28 of 41

surface on which the robot is moving. We are attempting to control the speed sothat the texture of the surface will have a minimal impact on the motion of therobot. However, at the present time, the robot will travel faster on smoothsurfaces than on textured surfaces such as grass.

The only compliances and regulations that would concern this product are thoseof the FCC. Since we are using a GPS unit from Garmin, which is FCCcompliant, our product is also FCC compliant.

Societal, Safety, and Environmental Analysis

A GPS guided mobile robot presents many benefits and changes to society. Oneof the largest impacts may be in warfare. A GPS guided robot will have theability to travel to places where it may be dangerous for humans to travel. Whiletraveling, features and sensors could be added to the robot for various detectionneeds. For example, a GPS guided robot could be sent into a mine field to tryand find the locations of mines. If a mine triggers during the process, it is betterto loose the robot than a human life. This robot’s application could be extendedto various other situations in warfare and in everyday life. The main idea behindit is that we can send a robot to places that are unsafe for humans or thathumans would have difficulty getting to. This could definitely change warfare andscientific research at the least.

The safety concerns associated with this robot are minimal. Normal care shouldbe taken when operating electrical equipment and caution should be placedwhen setting the coordinates for the robot’s path. It will be important to makesure that the robot will not take a path that could lead to undesirable damage.

Finally, the GPS guided mobile robot should not have much of an effect on theenvironment. If the batteries ever need replacing, it is necessary to properlydispose of the used batteries. Also, it will be important to make sure that therobot does not traverse any ground on which it may have a negative effect on thesurroundings. Unless it is intentional, coordinates should be plotted to avoidsensitive areas.


Page 29 of 41

Appendices

• OOPic Test Code

• Sample MATLAB Code

• Product datasheets


Page 30 of 41

//complete throttle and sonar

oServoSP1 Thrservo = New oServoSP1;oClock Sonarchk = New oClock;oEvent Sonarrec = New oEvent;oWire SonarInt = New oWire;oSonarDV Frtsonar = New oSonarDV;oQencode Shaftenc = New oQencode;oDio1 red = New oDio1;

Sub void main(void){ Thrservo.IOLine = 9; Thrservo.Center = 0; Thrservo.Operate= cvTrue;

Frtsonar.IOLineP = 12; Frtsonar.IOLineE = 13; Frtsonar.Operate = cvFalse;

red.IOLine=15; red.Direction=cvOutput; red.Value=0;

SonarInt.Input.Link(Frtsonar.Received); SonarInt.Output.Link(Sonarrec.Operate); SonarInt.Operate = cvTrue;

Sonarchk.Rate = 110; Sonarchk.Output.Link(Frtsonar.Operate); Sonarchk.Operate = cvTrue;

Shaftenc.IOLine1 = 11; Shaftenc.IOLine2 = 10; Shaftenc.Operate = cvTrue;

Neu; OOPic.delay = 500; while(1) { red.Value=0; Go; }}

Sub void Sonarrec_Code(void){ if ( ~ Frtsonar.TimeOut & (Frtsonar.Value/64 <= 10)) { red.Value=1; Stop; } else { red.Value=0; Go; }


Page 31 of 41

}

Sub void Neu(void){ if (Thrservo.Value != 22) { Thrservo.Value=22; }}

Sub void Go(void){ OOPic.delay=50; if ((Thrservo.Value < 38) & ~ Shaftenc.Moved) { Thrservo.Value=Thrservo.Value+1; }}

Sub void Stop(void){ if (Thrservo.Value > 30) { Thrservo.Value=30; } OOPic.delay=1000; Neu;}


Page 32 of 41

//complete throttle and sonar

oServoSP1 Thrservo = New oServoSP1;oClock Systemchk = New oClock;oEvent Sonarrec = New oEvent;oWire SonarInt = New oWire;oSonarDV Frtsonar = New oSonarDV;oQencode Shaftenc = New oQencode;oTimer TimeInt = New oTimer;oCompareC Timechk = New oCompareC;oEvent Speedchk = New oEvent;oWire TimerInt = New oWire;oDio1 red = New oDio1;

oWord Interval = New oWord;oWord MaxDis = New oWord;oWord ShaftPos = New oWord;oByte Thrstart = New oByte;oBit DetectObs = New oBit;

Sub void main(void){ Thrservo.IOLine = 9; //servo controls throttle speed Thrservo.Center = 0; Thrservo.Operate= cvTrue;

Frtsonar.IOLineP = 12; //sonar to detect obstacles ahead Frtsonar.IOLineE = 13; Frtsonar.Operate = cvFalse;

Systemchk.Rate = 110; //clock signal to coordiante sensors Systemchk.Output.Link(Frtsonar.Operate); Systemchk.Operate = cvTrue;

red.IOLine=15; //LED lights up when obstacle detected red.Direction=cvOutput; red.Value=0;

SonarInt.Input.Link(Frtsonar.Received); //wire connects sonar recieved to event trigger SonarInt.Output.Link(Sonarrec.Operate); SonarInt.Operate = cvTrue;

Shaftenc.IOLine1 = 11; //shaft encoder to moniter speed Shaftenc.IOLine2 = 10; Shaftenc.Operate = cvTrue;

MaxDis.Value = 14; //max change in encoder over time interval

TimeInt.ExtClock = 0; //timer to check speed TimeInt.Prescale = 3; TimeInt.Operate = cvFalse; TimeInt.Value = 0;

Interval.Value = 9766; //time to check speed

Timechk.Input.Link(TimeInt); //compares timer to determine if time to check speed Timechk.Fuzziness = 0; Timechk.ReferenceIn.Link(Interval);


Page 33 of 41

Timechk.ClockIn = Systemchk.Output; //compare on clock signal Timechk.Operate = cvTrue;

TimerInt.Input.Link(Timechk.Above); //wire connects comparison above to event trigger TimerInt.Output.Link(Speedchk.Operate); TimerInt.Operate = cvTrue;

DetectObs = 0; TimeInt.Operate = cvTrue;

Neu; OOPic.delay = 500; while(1) { red.Value = 0; DetectObs = 0; //Go; }}

Sub void Sonarrec_Code(void){ if ( ~ Frtsonar.TimeOut & (Frtsonar.Value/64 <= 10)) { red.Value = 1; DetectObs = 1; Stop; } else { red.Value = 0; DetectObs = 0; //Go; }}

Sub void Speedchk_Code(void){ TimeInt.Operate = cvFalse; TimeInt.Value = 0; if ((Shaftenc.Value >= MaxDis.Value) & (Thrservo.Value >= Thrstart.Value-14)) { Thrservo.Value--; } else if (Shaftenc.Value <= 9) { Thrservo.Value++; }}



Page 34 of 41

Sub void Go(void){ OOPic.delay=50; if ((Thrservo.Value < 38) & ~ Shaftenc.Moved) { Thrservo.Value=Thrservo.Value+1; }}



Page 35 of 41

//servo & sonar fusion

oServoSP1 Thrservo = New oServoSP1;oSonarDV Frtsonar = New oSonarDV;oDio1 red = New oDio1;




Neu;

do { Frtsonar.Operate = cvFalse; Frtsonar.Operate = cvTrue;

while (Frtsonar.Transmitting == cvTrue) { }

if ( ~ Frtsonar.TimeOut & (Frtsonar/64 <= 10)) {

red.Value=1; Stop; } else {

red.Value=0; Go; } } while(1);}


Sub void Go(void){ OOPic.delay=50; if (Thrservo.Value < 38)


Page 36 of 41

{ Thrservo.Value=Thrservo.Value+1; }}



Page 37 of 41

//servo & sonar fusion

oServoSP1 Thrservo = New oServoSP1;oSonarDV Frtsonar = New oSonarDV;oDio1 red = New oDio1;




Goto NEU;

while(1) { LOOK: Frtsonar.Operate = cvFalse; Frtsonar.Operate = cvTrue;

while (Frtsonar.Received == cvFalse) { // wait for echo }

if ( ~ Frtsonar.TimeOut & (Frtsonar/64 <= 10)) {

red.Value=1; Goto STOP; } else {

red.Value=0; Goto GO; } OOPic.delay = 50; }

NEU: OOPic.delay=50; // wait 1/2 sec Thrservo.Value=22; // neutral point for throttle servo OOPic.delay=500; Goto LOOK;

GO: OOPic.delay=50; // wait 1/2 sec Thrservo.Value=40; // at 38 the throttle is on Goto LOOK;

STOP:


Page 38 of 41

OOPic.delay=50; // wait 1/2 sec Thrservo.Value=35; // at 35 the throttle is off, OOPic.delay=100; Goto NEU;}


Page 39 of 41

Sample MATLAB Code

alg00.m

heading = pi/2;pos = [0, 3];dest = [0, 0];maxturn =

dy = dest(2) - pos(2);dx = dest(1) - pos(1);

afh = getanglefromH(heading, dx, dy);

afh = converttodegrees(afh);

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% new code

distance = sqrt(dx*dx + dy*dy);

distance

converttodegrees.m

function d = converttodegrees(rad)

d = rad*180/pi;

getanglefromH.m

function afh = getanglefromH(heading, dx, dy)

if dx == 0invtan = 0;

elseinvtan = atan(dy/dx);

end

if invtan >= 0if dx >= 0

anglefromN = pi/2 - invtan;else

anglefromN = ((3*pi)/2) - invtan;end


Page 40 of 41

elseif dy >= 0

anglefromN = (2*pi) - invtan;else

anglefromN = pi - invtan;end

end

afh = anglefromN - heading;

test.m

heading = pi/2;speed = 1;angVel = 0.5;posX = 0;posY = 0;dT = .1;

history = [posX, posY];

for i = 1:5 posX = posX + speed * dT * cos(heading); posY = posY + speed * dT * sin(heading); heading = heading + angVel * dT; history(i+1,:) = [posX, posY];end

plot(history(:,1),history(:,2),'.');


Page 41 of 41

Product Datasheets (attached)

Documents

GPS Navigation for Field Mobile Robotscourses.cs.tamu.edu/rgutier/cpsc483_s04/reports/gps-cdr.pdf · GPS Navigation for Field Mobile Robots – Critical Design Review Page 2 of 41