View/Open - University of Khartoum Dspace
Transcription
View/Open - University of Khartoum Dspace
Design and Implementation of a Navigation System A Report submitted in partial fulfillment of the requirements for the degree of B.Sc. In Electrical and Electronic Engineering Under Supervision of Dr. Iman Abuel Maaly By Omer Hassan Omer Abdelrahman To The Department of Electrical and Electronic Engineering University of Khartoum July 2005 Acknowledgement I would like to express my profound gratitude to Almighty God for all the physical and mental strength He bestowed on me during the preparation of this thesis. I am indebted to Dr. Iman Abuel Maaly who supervised my project with patience and dedication. Finally, I would like to thank my family for their encouragement and support in all my endeavors. I owe all my success to them. II Abstract This project is a feat of engineering that utilizes emerging technologies in conjunction with autonomous control to create a smart vehicle that is capable of navigating to a sequence of global coordinates without physical human intervention. Creation of the project is based on the need for an autonomous vehicle to accomplish tasks that otherwise may be time consuming or hazardous for human beings. In order to do this the global positioning system (GPS) was implemented as the means by which the vehicle knows its position on the earth. Orientation from a digital compass is used in conjunction with position information from the GPS receiver to steer the vehicle. A tracking system based on RF communication is also incorporated into the design. The project is built around a complex microcontroller system, integrating hardware and software, and interfacing the microcontroller with the components to quickly process data, control the motors and provide feedback information on board the vehicle. The vehicle was tested by giving it multiple waypoints; it navigated successfully to within the accuracy of the GPS receiver. III ﻣﺴﺘﺨﻠﺺ ﺩﺍﺭ ﻫﺫﺍ ﺍﻟﺒﺤﺙ ﺤﻭل ﺘﺼﻤﻴﻡ ﻭ ﺘﻨﻔﻴﺫ ﻨﻅﺎﻡ ﺘﺤﻜﻡ ﺫﺍﺘﻲ ﻴﻘﻭﻡ ﺒﺘﻭﺠﻴﻪ ﻭﻗﻴﺎﺩﺓ ﻋﺭﺒﺔ ﺩﻭﻥ ﺍﻟﺘﺩﺨل ﺍﻟﺒﺸﺭﻱ .ﺘﻅﻬﺭ ﺍﻟﺤﺎﺠﺔ ﺇﻟﻰ ﻫﺫﺍ ﺍﻟﻨﻅﺎﻡ ﻓﻲ ﺍﻟﺘﻁﺒﻴﻘﺎﺕ ﺫﺍﺕ ﺍﻟﻁﺒﻴﻌﺔ ﺍﻟﺭﺘﻴﺒﺔ ﺃﻭ ﺍﻟﻤﻬﺩﺩﺓ ﻟﺤﻴﺎﺓ ﺍﻹﻨﺴﺎﻥ .ﻟﺘﺤﻘﻴﻕ ﻫﺫﺍ ﺍﻟﻨﻅﺎﻡ ﺇﺴﺘﺨﺩﻤﺕ ﺘﻘﻨﻴﺔ ﺘﺤﺩﻴﺩ ﺍﻟﻤﻭﻗﻊ ﺒﻭﺍﺴﻁﺔ ﺍﻷﻗﻤﺎﺭ ﺍﻟﺼﻨﺎﻋﻴﺔ ﺒﺎﻹﻀﺎﻓﺔ ﺇﻟﻰ ﺒﻭﺼﻠﺔ ﺇﻟﻜﺘﺭﻭﻨﻴﺔ ﻟﺘﺤﺩﻴﺩ ﺍﻹﺘﺠﺎﻩ ،ﺘﺘﻡ ﻤﻌﺎﻟﺠﺔ ﻫﺫﻩ ﺍﻟﻤﻌﻁﻴﺎﺕ ﺒﻭﺍﺴﻁﺔ ﺩﺍﺭﺓ ﺘﺤﻜﻡ ﺘﻘﻭﻡ ﺒﺈﺼﺩﺍﺭ ﺍﻹﺸﺎﺭﺍﺕ ﺍﻟﻼﺯﻤﺔ ﻟﺘﻭﺠﻴﻪ ﺍﻟﻌﺭﺒﺔ ﺒﻭﺍﺴﻁﺔ ﻤﺤﺭﻜﺎﺕ ﻜﻬﺭﺒﺎﺌﻴﺔ .ﺘﻡ ﺇﺨﺘﺒﺎﺭ ﻫﺫﺍ ﺍﻟﻨﻅﺎﻡ ﻋﻤﻠﻴﺎ ﻭﻗﺩ ﻋﻤل ﺒﻨﺠﺎﺡ، ﺤﻴﺙ ﺘﻌﻁﻰ ﺍﻟﻌﺭﺒﺔ ﻤﺴﺎﺭﺍ ﻤﻌﻴﻨﺎ ﻋﺒﺎﺭﺓ ﻋﻥ ﻤﺠﻤﻭﻋﺔ ﻤﻥ ﺍﻹﺤﺩﺍﺜﻴﺎﺕ ﻓﺘﻘﻭﻡ ﺫﺍﺘﻴﺎ ﺒﺎﻟﺘﺤﺭﻙ ﻓﻲ ﻫﺫﺍ ﺍﻟﻤﺴﺎﺭ ﻭﺘﺯﻭﺩ ﺍﻟﻤﺴﺘﺨﺩﻡ ﺒﻤﻌﻠﻭﻤﺎﺕ ﻤﻼﺤﻴﺔ ﺒﻭﺍﺴﻁﺔ ﺸﺎﺸﺔ ﻋﺭﺽ ﻤﻭﺠﻭﺩﺓ ﻋﻠﻰ ﺴﻁﺤﻬﺎ ،ﻜﻤﺎ ﺘﺭﺴل ﺇﺸﺎﺭﺍﺕ ﻻﺴﻠﻜﻴﺔ ﺘﻤﻜﻥ ﺃﻱ ﻤﺴﺘﺨﺩﻡ ﻤﻥ ﺘﺘﺒﻌﻬﺎ ﻋﻥ ﺒﻌﺩ .ﺃﺩﺍﺀ ﻫﺫﺍ ﺍﻟﻨﻅﺎﻡ ﻤﺤﺩﻭﺩ ﺒﺩﻗﺔ ﺠﻬﺎﺯ ﺇﺴﺘﻘﺒﺎل ﻨﻅﺎﻡ ﺍﻷﻗﻤﺎﺭ ﺍﻟﺼﻨﺎﻋﻴﺔ ﻟﺘﺤﺩﻴﺩ ﺍﻟﻤﻭﺍﻗﻊ ﺍﻟﺠﻐﺭﺍﻓﻴﺔ ﺍﻟﻤﻭﺠﻪ ﻟﻠﻌﺭﺒﺔ. IV Table of Contents Acknowledgement ..............................................................................................................II Abstract ............................................................................................................................. III ﻣﺴﺘﺨﻠﺺ.............................................................................................................................. IV Table of Contents............................................................................................................... V Table of Figures ...............................................................................................................VII 1 Introduction................................................................................................................. 1 1.1 Background: Global Navigation ......................................................................... 1 1.2 Statement of the Problem.................................................................................... 1 1.3 Project Goal ........................................................................................................ 2 1.4 The Scope of the Project ..................................................................................... 2 1.5 Organization of the Thesis .................................................................................. 3 2 Literature Review........................................................................................................ 4 2.1 Introduction......................................................................................................... 4 2.2 Justification ......................................................................................................... 4 2.3 Plan of Work ....................................................................................................... 5 2.3.1 Research...................................................................................................... 6 2.3.2 Simulation ................................................................................................... 6 2.3.3 Implementation ........................................................................................... 6 2.3.4 Testing......................................................................................................... 6 2.4 Methods and Materials........................................................................................ 6 2.4.1 The Model................................................................................................... 6 2.4.2 Processing ................................................................................................... 7 2.4.3 Navigation Sensors ..................................................................................... 8 2.4.4 Motion Control............................................................................................ 9 2.4.5 User Interface............................................................................................ 10 2.4.6 Tracking .................................................................................................... 10 2.4.7 Power supply............................................................................................. 11 3 Theoretical Aspects of the Navigation System......................................................... 12 3.1 Positioning Module........................................................................................... 12 3.1.1 Satellite-Based Positioning Technique ..................................................... 12 3.1.2 GPS Segments........................................................................................... 12 3.1.3 How does GPS work? ............................................................................... 15 3.1.4 GPS Error................................................................................................ 18 3.2 Electronic Compass Module ............................................................................. 19 3.2.1 Earth’s Magnetic Field.............................................................................. 19 3.2.2 Building Blocks of an Electronic Compass .............................................. 20 3.3 OOPic Microcontroller ..................................................................................... 21 3.3.1 OOPic Application.................................................................................... 21 3.4 DC Motor Theory ............................................................................................. 22 3.5 Motor Controller ............................................................................................... 23 3.5.1 H-Bridge Theory....................................................................................... 23 V 4 Modeling and Solution Algorithm ............................................................................ 25 4.1 Simulation ......................................................................................................... 25 4.1.1 Simulation Flowchart................................................................................ 25 4.2 Modeling of the Control System....................................................................... 26 4.2.1 Description of the Algorithm .................................................................... 28 4.2.2 Algorithm Flowchart................................................................................. 29 4.2.3 Implementation of the Algorithm ............................................................. 30 5 Hardware Implementation ........................................................................................ 35 5.1 Hardware Interface............................................................................................ 35 5.1.1 OOPic Hardware Objects.......................................................................... 35 5.1.2 Motor Control and Drive System.............................................................. 35 5.1.3 LCD Module ............................................................................................. 38 5.1.4 RF transmitter ........................................................................................... 38 5.1.5 GPS and Compass Modules...................................................................... 39 5.2 Physical Placement of Components.................................................................. 40 5.3 Power Management .......................................................................................... 40 6 Implementation of the Navigation System ............................................................... 41 6.1 Development stages .......................................................................................... 41 6.2 Results............................................................................................................... 42 6.3 Performance ...................................................................................................... 42 6.4 Evaluation of Alternative Solutions.................................................................. 43 7 Conclusion and Future Work .................................................................................... 44 7.1 Conclusion ........................................................................................................ 44 7.2 Future Work ...................................................................................................... 44 Appendix A: Hardware Specifications ............................................................................. 46 Appendix B: Schematic Diagram ..................................................................................... 53 Appendix C: OOPic Code................................................................................................. 54 Appendix D: Simulation Code.......................................................................................... 60 Appendix E: Programming & Using the OOPic............................................................... 69 Appendix F: User Manual................................................................................................. 73 Appendix G: Schedule of Tasks ....................................................................................... 74 References......................................................................................................................... 75 VI Table of Figures Fig 2.1 Fig 2.2 Fig 2.3 Fig 2.4 Fig 2.5 Fig 2.6 Fig 3.1 Fig 3.2 Fig 3.3 Fig 3.4 Fig 3.5 Fig 3.6 Fig 3.7 Fig 3.8 Fig 3.9 Fig 3.10 Fig 3.11 Fig 3.12 Fig 3.13 Fig 3.14 Fig 3.15 Fig 3.16 Fig 4.1 Fig 4.2 Fig 4.3 Fig 4.4 Fig 4.5 Fig 4.6 Fig 4.7 Fig 4.8 Fig 4.9 Fig 4.10 Fig 4.11 Fig 4.12 Fig 4.13 Fig 5.1 Fig 5.2 Fig 5.3 Fig 6.1 OOPic-R robot controller board ......................................................................... 8 GPS Receiver....................................................................................................... 8 Electronic Compass ............................................................................................. 9 DC Motor............................................................................................................. 9 Dual H-Bridge Motor Driver............................................................................. 10 LCD Module...................................................................................................... 10 GPS segments .................................................................................................... 12 GPS constellation .............................................................................................. 13 Simplified Representation of Nominal GPS Constellation ............................... 13 GPS Satellite Signals ......................................................................................... 14 GPS Master Control and Monitor Station Network .......................................... 15 GPS Control....................................................................................................... 15 GPS timing and ranging .................................................................................... 16 Estimated range to 1 satellite............................................................................. 17 Estimated range to 2 satellites ........................................................................... 17 Estimated range to 3 satellites ........................................................................... 18 Earth’s Magnetic Field ...................................................................................... 19 Earth Field Vector ............................................................................................. 20 Functional block diagram of an electronic compass ......................................... 21 DC Motor Operation.......................................................................................... 23 Using H-bridge to control DC Motor ................................................................ 23 H-bridge Sample Control Circuit ...................................................................... 24 Simulation Flowchart ........................................................................................ 25 Screen capture of the program in the simulation mode ..................................... 26 Navigation System Breakdown ......................................................................... 27 Navigation Algorithm Flowchart....................................................................... 29 Abstract Navigation System Design.................................................................. 30 Destination in 1st quadrant in relation to current position ................................ 31 Destination in 2nd quadrant in relation to current position ............................... 31 Destination in 3rd quadrant in relation to current position................................ 31 Destination in 4th quadrant in relation to current position................................ 32 Polynomial Approximation of arctan (x)........................................................... 33 Turn Direction Algorithm.................................................................................. 33 Vehicle Tracking ............................................................................................... 34 Screen capture of the program in the tracking mode......................................... 34 System Block Diagram...................................................................................... 35 Pulse Width Modulation of a 12V, 4000 rpm DC Motor.................................. 37 I2C Bus Configuration....................................................................................... 39 The Final Product .............................................................................................. 42 VII CHAPTER ONE 1 INTRODUCTION 1.1 BACKGROUND: GLOBAL NAVIGATION The basis of global navigation for an autonomous guided vehicle is reliably gaining a coordinate of vector describing where the vehicle is in relation to a fixed point on the globe. This point is generally taken to be the intersection of the Greenwich meridian and the equator line of latitude, at sea level - in accordance with standard geographical practice. Using this position information, with reference to a map or otherwise, a list of way-points can be generated and followed to allow the vehicle to navigate between end points of a journey. Navigation can be described as a combination of the following fundamental elements: 1. Self localization : to establish its own position within a frame of reference 2. Path planning : freedom of movement 3. Map building and map interpretation: the map is an internal representation of the outside environment that the robot will reference for navigation. The robot will constantly monitor its sensors and bearings to check its position against this reference. This frame of reference, or “map”, can be embedded into the robot’s internal memory and enhanced by the robot internal sensors. An autonomous vehicle is a self-piloted vehicle that does not require an operator to navigate and accomplish its tasks. Autonomous vehicles are a recently developed subset of robotics and can come in three general forms; air, ground and submarine. Many companies and organizations are spending a lot of time and money developing autonomous vehicles for numerous applications. Navigation of Mobile Robots is a broad topic, covering a large spectrum of different technologies and applications. It draws on some very ancient techniques, as well as some of the most advanced space science and engineering. 1.2 STATEMENT OF THE PROBLEM Robot vehicles will allow the execution of high risk civilian, military, and space operations (e.g. reconnaissance, search and rescue, observation and de-mining) without danger for the operator, even if the device is damaged or destroyed. One approach to this problem is teleoperation. Factors complicating teleoperation are: Time delay between the command and the resulting feedback (space operations) Limited bandwidth or unreliable communication between the operator and the vehicle. 1 Introduction Poor situational awareness of the vehicle's environment (e.g. lack of visual feedback). The classic teleoperation scheme, where the operator directly commands the vehicle on the basis of real-time TV images, is not feasible in many situations; however, autonomous vehicles may provide a solution here. One of the many challenging problems facing designers of autonomous vehicles is that of navigation. A robot vehicle must generally have a reasonably good idea of where it is and where it is going in order to complete its intended mission. Navigation and positioning are crucial to mobile robot and yet the process has always been quite cumbersome. The quest for greater and greater navigation accuracy has spawned the idea of employing Global Positioning System (GPS) technology to improve the robot navigation functionality. 1.3 PROJECT GOAL The goal of this project is to design and implement a control system that is capable of navigating to a sequence of pre-defined global coordinates. The control system will be integrated on a self-propelled vehicle utilizing GPS. The objectives of the project consist of the following: Develop a system that will be sturdy enough to cover mostly flat terrain while carrying a payload of what components are necessary for it to accomplish its function. Develop a system that will be able to establish its own location on earth and use information from the global positioning system to navigate to a user defined GPS coordinates. The vehicle will be able to follow a path of points provided by a user Provide a wireless communication between the vehicle and a computer at some base location. This would allow a remote user to track the vehicle location. 1.4 THE SCOPE OF THE PROJECT The scope of this project is limited to fairly simple navigation. The vehicle will not be able to navigate complex areas with obstructions. The reason for this is the time limitation. The vehicle may be able to handle simple obstructions, but this isn’t a core requirement. 2 Introduction 1.5 ORGANIZATION OF THE THESIS This thesis is organized as follows: CHAPTER (1) is an introduction and gives the research goals, objectives and organization of the thesis. CHAPTER (2) lights the literature review, justification, plan of work and methods used to solve the problem. CHAPTER (3) describes the theoretical aspects of the navigation subsystems. CHAPTER (4) describes the simulation program used to model the navigation system, and gives a detailed description of the navigation algorithm implemented in this project. CHAPTER (5) describes the hardware implementation of the navigation system. CHAPTER (6) describes development stages, results, and performance of the system CHAPTER (7) presents the thesis conclusion and provides directions for future research. APPENDIX A specifications of the hardware components used in this project APPENDIX B is a detailed schematic diagram of the system. APPENDIX C contains the microcontroller code for the navigation system. APPENDIX D contains the simulation code. APPENDIX E describes how to program and use the OOPic microcontroller APPENDIX F is a user manual for the autonomous vehicle. APPENDIX G contains a Gantt chart showing how tasks were scheduled during the year. 3 CHAPTER TWO 2 LITERATURE REVIEW 2.1 INTRODUCTION Unmanned robotic vehicle systems have evolved rapidly in the past two decades, with new technologies and applications being discovered at an ever increasing pace. Vehicle control and sensor systems have become more advanced and reliable with the increasing availability of smaller and more powerful computers. There has been a great amount of researches devoted to the global positioning system based navigation for mobile robot platforms and intelligent vehicles. Any mobile robot that must reliably operate in an unknown or dynamic environment must be able to perform intelligent navigation. A recent competition was held by Defense Advanced Research Projects Agency DARPA -a unit of the US Department of Defense (DOD) – and it is intended to accelerate the development of autonomous vehicle technologies for both military and civilian use. DARPA, and other US agencies, are already funding numerous robotic vehicle development programs. Perhaps the most important result from surveying the literature on mobile robots navigation is that, to date, there is no truly elegant solution for the problem 2.2 JUSTIFICATION This project seeks to provide a proof of concept for autonomous vehicular navigation, which is a technology being sought for use in applications that are either hazardous in nature, or require an exacting level of precision or repeatability. Autonomous vehicles are equipped with a variety of instrumentation and controls depending upon the mission of the target vehicle. The advantages offered by unmanned vehicle systems make them well suited for many applications such as: Information gathering and remote presence. Environmental surveying. Security surveillance robots. Search and rescue missions: by attaching a camera, it can be sent to find victims, by given GPS coordinates as waypoints and told to search for people in that area. Monotonous work Agricultural tractors Industrial, mining and drilling vehicle. 4 Literature Review Military logistics (transportation of materials) Investigate environments contaminated with radiation, biological warfare, or chemical spills. It is better to send in a replaceable machine than it is to send in a non-replaceable human. With the addition of a wireless camera the army could use such a robot for urban warfare. Commanders could scout a potentially hostile area before risking the lives of infantry. The robot is a small target and can easily be sent into small spaces to explore enemy positions. Along the same lines the robot could be an advance scout for troops in the field. Finding enemy positions before troops run into the enemy. Another application for the military would be as a mine detector. The robot equipped with a mine detecting device, something as simple as a metal detector, could be sent ahead of the infantry or tank unit and identify where mines are. This would allow commanders to plot a clear and safe path for the troops to move through. It can also be used as a mobile radar platform. This can be accomplished by attaching a radar system. Because of its size and the fact that it is land based it can operate in enemy territory without being detected. This makes it superior to aerial radar platforms. Space exploration: Due to the communications time delay and the hostile environment, it is highly undesirable for the ground controllers on Earth to regularly intervene to correct the rover navigation. These delays can eat up much of a rover's useful life and jeopardize the success of its mission. There are currently no plans by NASA to place a full GPS system around Mars. It is possible to use GPS in a local area using small ground-based GPS transmitters called pseudolites (pseudo-satellites). GPS guided systems are just the beginning of a larger initiative to automate transportation. 2.3 PLAN OF WORK To be able to reach the project goal, it is necessary to plan the activities carefully. Project development will involve four stages for completion. These stages are needed for most engineering development team. The stages in order are: 5 Literature Review 2.3.1 RESEARCH Research will be conducted into a variety of previous and current designs and implementations of autonomous vehicles in order to determine the most feasible course for this design, with the primary goals of developing a low-cost, easy-to-use, effective, and reliable system. Before any kind of action is done in a project, extensive information gathering should be performed. Learning more about the product you buy can really save your budget. Hardware selection is determined by the component’s ability to interface with the selected microcontroller. 2.3.2 SIMULATION To assist in developing the navigation system and to understand the interactions of vehicle and the control system, a simulation program will be developed initially for this project. 2.3.3 IMPLEMENTATION Moving from simulation model to the real world requires a simple robot that can be easily programmed and controlled in the same way in which a simulated robot is controlled. This model is situated between simulations and real-world applications. If on the one hand it keeps a level of simplicity and operation modality similar to simulation tools, on the other hand it cannot reach the complexity of real-world applications. However, being a physical robot, it introduces most of the characteristics of robots used for real-world applications. 2.3.4 TESTING This will be the final stage of the project development. After constructing the car a series of tests need to be done. 2.4 METHODS AND MATERIALS In order to fulfill the requirements of this project, several technologies must be incorporated into the design. The following discusses the components necessary to fulfill the project requirements and the alternative technologies that were researched. 2.4.1 THE MODEL A model car is the easiest platform to start with, because it can be acquired easily and operated nearly anywhere. The navigation system is not limited to model cars; actually, any stable platform may be used including boat, hovercraft, or even aircraft. A pre-assembled remote control truck was chosen to navigate globally. The truck is large enough to provide adequate space for the electronic parts and components needed to navigate this truck. 6 Literature Review 2.4.2 PROCESSING The core of any navigation system is its ability to process data from its sensors and control its outputs in an efficient manner. The complexity of the processor is directly related to the amount of data being processed and the time the processor has to complete the task. With large, expensive systems, the computation power of a high-performance computer may be necessary. However, for a smaller, less expensive system, low-performance microcontrollers may be suitable depending upon the processing and speed requirements. MICROCONTROLLERS A microcontroller is a microprocessor with built-in memory and communication interfaces; it performs all the computations and serves as the master controller for the vehicle components, it is the brain of the navigation system. Microcontrollers are capable of storing and running the program that was written, complied and downloaded into it. The main parts of a microcontroller generally consist of the Central Processing Unit (CPU), Random Access Memory (RAM), Read Only Memory (ROM), input/output lines (I/O lines), serial and parallel ports, timers and other peripherals such as analog to digital (A/D) converter and digital to analog (D/A) converter. WHY TO USE A MICROCONTROLLER Microcontrollers are inexpensive microcomputers. The microcontroller's ability to store and run unique programs makes it very flexible. For example, one can program a microcontroller to perform functions based on predetermined situations (1/O-line logic) and selections. The microcontroller's capability to carry out mathematical and logic functions allows it to imitate complicated logic and electronic circuits. Microcontroller selection requires sufficient input/output control lines, sufficient processor speed to complete all processing in the required time, and adequate memory to run all programs. In addition, on-board computer resources such as serial ports, timers, counters, pulse width modulators (PWM) and, in some cases, analog to digital converters simplify designs and improve reliability. Based on these criteria for this project, the OOPic-R microcontroller was chosen for the central processing unit (CPU). This was done after a long search and readings and comparison between it and other potential microcontrollers that can be used in this project. 7 Literature Review FIG2.1 OOPIC-R ROBOT CONTROLLER BOARD 2.4.3 NAVIGATION SENSORS To navigate a vehicle autonomously, the control system must have the ability to determine its present location and direction of travel. Location can be determined either from an outside source with technology such as the Global Positioning System (GPS), or by calculating a traveled path from a known starting point. While neither option is perfect, GPS offers the benefit of retrieving location information that has no bearing upon previous results. This prevents calculation errors from accumulating throughout the path. For this reason, low cost, and ease of use, GPS was selected as the method of location retrieval for this autonomous vehicle project. The GPS receiver provides the robot car navigation software with its current location to allow the software to determine steps to get the car from this position to its destination. The GPS receiver used in this project is shown in Fig (2.2) below: FIG 2.2 GPS RECEIVER While a GPS can be used to give a direction of travel, it is only useful when traveling at a high rate of speed. It is important for the robot to know what direction it is pointing at all times, whether moving or not. In order to have the robot know which direction it is facing, some kind of compass must be implemented in the design. The compass that is used is an electronic device that provides the orientation of north relative to itself. Using this information the robot car has the ability to determine its orientation relative to its destination. The navigation software programmed onto the microcontroller uses this information to formulate the commands to the robot car necessary to get to its destination. 8 Literature Review The CMPS03 electronic compass module was selected for this project. This compass is designed specifically to aid in the navigation of robots; it is affordable, easy to use, and extremely accurate. FIG 2.3 ELECTRONIC COMPASS 2.4.4 MOTION CONTROL Two DC motors are used to drive the vehicle. By manipulating the relative speed each motor operates at the direction that the vehicle is moving in can be controlled. The vehicle uses differential or “tank” steering, which is accomplished by making one motor move in the opposite direction as the other. For example, to turn right, the left side motor is moved forward and the right side motor is moved backward. The vehicle uses two 7.2V, 175 RPM gear motors, pictured in Fig (2.4). They include a 50:1 ratio gearbox and have a stall torque of 99.04 oz-in (7.13 kg-cm). Coupled with 3” diameter wheels, the motors should travel at a maximum speed of (175 RPM) (Pi*3”) = 1650 in/min = 137 ft/min = 2.3 ft/sec which meets our specifications. The force generated by one motor with a 2.25” wide wheel is (99.04 oz-in)/(2.25 in) * (lb/16 oz) = 2.75 lbs With a total of 2 motors the force created is 5.5 lbs. This is enough power to carry the electronic components. The motors are actually supplied by 9 V battery, increasing the voltage generally increases the power. This process also means an increase in heat, so care must be taken not to run the motors at high voltage for too long or they could be damaged. This can be prevented by running the motors at short intervals using the motor controller. FIG 2.4 DC MOTOR 9 Literature Review A circuit called H-Bridge is used to interface the motors to the microcontroller. The Hbridge is software controlled; it converts digital output from the microcontroller in the form of a pulse-width-modulated signal into the driving current needed to control the motors. In the design of this project a dual H-Bridge motor driver is used, the driver is pictured in Fig (2.5). FIG 2.5 DUAL H-BRIDGE MOTOR DRIVER 2.4.5 USER INTERFACE The heart of the user interface is an LCD module. The LCD is mounted on the surface of the robot car body for easy access and it is used to provide feedback to the user. The LCD provides the user with information about the performance of the navigation software including the current position, heading and speed of the robot car. The LCD is also used to confirm information given by the users including destination coordinates. The user interface allows the user check functionality of sensors and motors on the vehicle. In the development stages, the user interface was employed to debug the software by outputting sensor values and internal software states, and it was very useful in testing and troubleshooting the navigation system. The LCD used for this project is pictured in Fig (2.6). It is 2 line x 16 characters and uses serial interfacing with the microcontroller. It has low power consumption and it is able to print all standard alphanumeric characters easily. The major feature of the LCD module is its ease of interfacing. FIG 2.6 LCD MODULE 2.4.6 TRACKING The development of the tracking system is not a primary goal. Therefore, the tracking system should be simple and it should just be able to detect the vehicle location when it reaches a destination. 10 Literature Review Vehicle tracking requires wireless communication between the robot and a computer at some base location. RF technology is a typical solution for this application due to its reasonable range (up to 100m) and reasonable cost. 2.4.7 POWER SUPPLY The vehicle should be completely autonomous and therefore have its own power supply. The power supply should be able to drive the DC motors and the other electronic equipments. Batteries were chosen for the vehicle, because it is the easiest to install and should be able to deliver power for 2- 4 hours of testing, without getting to heavy. 11 CHAPTER THREE 3 THEORETICAL ASPECTS OF THE NAVIGATION SYSTEM 3.1 POSITIONING MODULE The positioning module is a vital component of any navigation system to provide the system with proper maneuver instructions, the vehicle location must be determined precisely, therefore accurate and reliable vehicle positioning is essential prerequisite for any good navigation system. 3.1.1 SATELLITE-BASED POSITIONING TECHNIQUE The Global Positioning System (GPS) is a satellite-based system that can be used to locate positions anywhere on the earth. Operated by the U.S. Department of Defense (DOD), NAVSTAR (NAVigation Satellite Timing and Ranging) GPS provides continuous (24 hours/day), real-time, 3-dimensional positioning, navigation and timing worldwide. Any person with a GPS receiver can access the system, and it can be used for any application that requires location coordinates (i.e. Navigation, surveying, and geological studies). GPS user can also find velocity and time among other services that may be provided. 3.1.2 GPS SEGMENTS The GPS system consists of three segments: a) The space segment: the GPS satellites themselves. b) The control system: operated by the U.S. military. c) The user segment: includes both military and civilian users and their GPS equipment. FIG 3.1 GPS SEGMENTS 12 Theoretical Aspects of the Navigation System a) SPACE SEGMENT The first GPS satellite was launched by the U.S. Air Force in early 1978. There are now at least 24 satellites orbiting the earth at an altitude of about 22,200 km. The high altitude insures that the satellite orbits are stable, precise and predictable, and that the satellite's motion through space is not affected by atmospheric drag. These 24 satellites make up a full GPS constellation. On board each GPS satellite are four atomic clocks, only one of which is in use at a time. These highly accurate atomic clocks enable GPS to provide the most accurate timing system that exists. Satellite Orbits There are four satellites in each of 6 orbital planes equally spaced (60 degrees apart). Each plane is inclined 55 degrees relative to the equator, which means that satellites cross the equator tilted at a 55 degree angle. The system is designed to maintain full operational capability even if two of the 24 satellites fail. FIG 3.2 GPS CONSTELLATION GPS satellites complete an orbit in approximately 12 hours, which means that they pass over any point on the earth about twice a day. FIG 3.3 SIMPLIFIED REPRESENTATION OF NOMINAL GPS CONSTELLATION 13 Theoretical Aspects of the Navigation System Satellite Signals GPS satellites continuously broadcast satellite position and timing data via radio signals on two frequencies (L1 and L2). The L1 frequency (1575.42 MHz) carries the navigation message and the SPS code signals. The L2 frequency (1227.60 MHz) is used to measure the ionospheric delay by PPS equipped receivers. The radio signals travel at the speed of light (300,000 km/s). Three binary codes shift the L1 and/or L2 carrier phase: 1. The C/A Code (Coarse Acquisition) modulates the L1 carrier phase. The C/A code is a repeating 1 MHz Pseudo Random Noise (PRN) Code. This noise-like code modulates the L1 carrier signal, "spreading" the spectrum over a 1 MHz bandwidth. The C/A code repeats every 1023 bits (one millisecond). There is a different C/A code PRN for each SV. GPS satellites are often identified by their PRN number, the unique identifier for each pseudorandom-noise code. The C/A code that modulates the L1 carrier is the basis for the civil SPS (Standard Positioning Service). The SPS accuracy was intentionally degraded by the DOD, by the use of selective availability. 2. The P-Code (Precise) modulates both the L1 and L2 carrier phases. In the Anti-Spoofing (AS) mode of operation, the P-Code is encrypted into the Y-Code. The encrypted Y-Code requires a classified AS module for each receiver channel and is for use only by authorized users with cryptographic keys. The P (Y)-Code is the basis for the PPS (Precise Positioning Service) which is available only to the US military and authorized users with cryptographic equipment and keys and specially equipped receivers. Using P code on both frequencies, a military receiver can achieve better accuracy than civilian receivers. Additional techniques can increase the accuracy of both C/A code and P code GPS receivers. 3. The Navigation Message also modulates the L1-C/A code signal. The Navigation Message is a 50 Hz signal consisting of data bits that describe the GPS satellite orbits, clock corrections, and other system parameters. FIG 3.4 GPS SATELLITE SIGNALS 14 Theoretical Aspects of the Navigation System b) CONTROL SEGMENT The Control Segment consists of a system of tracking stations located around the world. FIG 3.5 GPS MASTER CONTROL AND MONITOR STATION NETWORK The Master Control facility is located at Falcon Air Force Base in Colorado. These monitor stations measure signals from the satellites which are incorporated into orbital models for each satellites. The models compute precise orbital data (ephemeris) and satellites clock corrections for each satellite. The Master Control station uploads ephemeris and clock data to the Satellites which then send subsets of the orbital ephemeris data to GPS receivers over radio signals. FIG 3.6 GPS CONTROL c) USER SEGMENT The GPS User Segment consists of the GPS receivers and the user community. GPS receivers convert SV signals into position, velocity, and time estimates. Four satellites are required to compute the four dimensions of X, Y, Z (position) and Time. 3.1.3 HOW DOES GPS WORK? CALCULATING A POSITION A GPS receiver calculates its position by a technique called satellite ranging, which involves measuring the distance between the GPS receiver and the GPS satellites it is tracking. The range (the range a receiver calculates is actually a pseudo range, or an estimate of range 15 Theoretical Aspects of the Navigation System rather than a true range) or distance, is measured as elapsed transit time. The position of each satellite is known, and the satellites transmit their positions as part of the "messages" they send via radio waves. The GPS receiver on the ground is the unknown point, and must compute its position based on the information it receives from the satellites. MEASURING DISTANCE TO SATELLITES The first step in measuring the distance between the GPS receiver and a satellite requires measuring the time it takes for the signal to travel from the satellite to the receiver. Once the receiver knows how much time has elapsed, it multiplies the travel time of the signal times the speed of light (because the satellite signals travel at the speed of light to compute the distance. Distance measurements to four satellites are required to compute a 3-dimensional (latitude, longitude and altitude) position. In order to measure the travel time of the satellite signal, the receiver has to know when the signal left the satellite and when the signal reached the receiver. Knowing when the signal reaches the receiver is easy; the GPS receiver just "checks" its internal clock when the signal arrives to see what time it is. But how does it "know" when the signal left the satellite? All GPS receivers are synchronized with the satellites so they generate the same digital code at the same time. When the GPS receiver receives a code from a satellite, it can look back in its memory bank and "remember" when it emitted the same code. This little "trick" allows the GPS receiver to determine when the signal left the satellite. FIG 3.7 GPS TIMING AND RANGING USING THE DISTANCE MEASUREMENTS TO CALCULATE A POSITION Once the receiver has the distance measurements, it's basically a problem of geometry. If it "knows" where each satellite is, and how far it is from each satellite, it can compute its location through trilateration. Here's an illustration of how it works. 1. The GPS receiver "locks on" to one satellite and calculates the range. This fact helps narrow the receiver location down, but it only tells us that we are somewhere on a sphere 16 Theoretical Aspects of the Navigation System which is centered on the satellite. Many of the locations on that sphere are not on earth, but out in space. FIG 3.8 ESTIMATED RANGE TO 1 SATELLITE 2. Now, consider that the receiver picks up a signal from a second satellite and calculates the range between the receiver and the satellite. That means we are also somewhere on a sphere with a known radius and the second satellite at the center. We must, therefore, be somewhere where these two spheres intersect. When the two spheres intersect, a circle is formed, so we must be somewhere on that circle. FIG 3.9 ESTIMATED RANGE TO 2 SATELLITES 3. If the receiver picks up another satellite, another sphere is formed, and there are only two points where the three spheres intersect. Usually the receiver can discard one of the last two points because it is nowhere near the earth. So, we're left with one point which is the location of the GPS receiver. 17 Theoretical Aspects of the Navigation System FIG 3.10 ESTIMATED RANGE TO 3 SATELLITES 4. In practice, a fourth measurement is needed to correct for clock error and have correct altitude estimation. 3.1.4 GPS ERROR There are many sources of possible errors that will degrade the accuracy of positions computed by a GPS receiver. The travel time of GPS satellite signals can be altered by atmospheric effects; when a GPS signal passes through the ionosphere and troposphere it is refracted, causing the speed of the signal to be different from the speed of a GPS signal in space. Sunspot activity causes interference with GPS signals. Another source of error is measurement noise, or distortion of the signal caused by electrical interference or errors inherent in the GPS receiver itself. Errors in the ephemeris data (the information about satellite orbits) will also cause errors in computed positions, because the satellites weren't really where the GPS receiver "thought" they were (based on the information it received) when it computed the positions. Small variations in the atomic clocks (clock drift) on board the satellites can translate to large position errors; a clock error of 1 nanosecond translates to 1 foot or .3 meters user error on the ground. Satellite geometry can also affect the accuracy of GPS positioning. This effect is called Geometric Dilution of Precision (GDOP). GDOP refers to where the satellites are in relation to one another, and is a measure of the quality of the satellite configuration. It can magnify or lessen other GPS errors. In general, the wider the angle between satellites, the better the measurement Selective Availability (SA) occurred when the DOD intentionally degraded the accuracy of GPS signals – for civilian users - by introducing artificial clock and ephemeris (orbital information) errors. When SA was implemented, it was the largest component of GPS 18 Theoretical Aspects of the Navigation System error. SA is a component of the Standard Positioning Service (SPS), which was formally implemented on March 25, 1990, and was intended to protect national defense. SA was turned off on May 1, 2000 and is replaced by regional denial capabilities (denying civil services of GPS on regional basis). 3.2 ELECTRONIC COMPASS MODULE The magnetic compass is a crucial navigation tool in many areas, even in times of the global positioning system (GPS). Replacing the “old” magnetic needle compass or the gyrocompass by an electronic solution offers advantages like having a solid-state component without moving parts and the ease of interfacing with other electronic systems. 3.2.1 EARTH’S MAGNETIC FIELD The magnetic field of the earth is the physical quantity to be evaluated by a compass, figure (3.11) gives an illustration of the field shape. FIG 3.11 EARTH’S MAGNETIC FIELD We can assume that the earth’s field is generated by a bar magnet within the earth, as pointed out in Figure (3.11). The magnetic field lines point from the earth’s South Pole to its north pole, this is opposite to the physical convention for the poles of a bar magnet. The magnetic poles of the earth do not coincide with the geographical poles, which are defined by the earth’s axis of rotation. The angle between the magnetic and the rotation axis is about 11.5°. As a consequence, the magnetic field lines do not exactly point to geographic or “true” north. Figure (3.12) gives a 3-D representation of the earth field vector (He) at some point on the earth, this illustration allows defining the quantities, which are of importance for a compass. 19 Theoretical Aspects of the Navigation System Here, the x- and y-coordinates are parallel to the earth’s surface, whereas the z-coordinate points vertically downwards. FIG 3.12 EARTH FIELD VECTOR THE AZIMUTH (α) is the angle between magnetic north and the heading direction. Magnetic north is the direction of the horizontal component of the earth’s field (Heh). The azimuth is the reading quantity of the compass. Hey Hex α = tan −1 ………………………………… (3.1) THE DECLINATION (λ) is the angle between geographic or true north and magnetic north. Declination is dependent on the actual position on earth. The azimuth measured by a compass has to be corrected by the declination in order to find the heading direction with respect to geographic north. THE INCLINATION (δ) is the angle between the earth’s field vector and the horizontal plane, it varies with the actual location on earth, being zero at the equator and approaching ±90° near the poles. 3.2.2 BUILDING BLOCKS OF AN ELECTRONIC COMPASS The compass uses a magnetic field sensor that can detect Earth’s magnetic field. The output from two of these sensors mounted at 90 degrees to each other is used to compute the direction of the horizontal component of Earth’s magnetic field. Besides the sensor elements, a signal conditioning unit and a direction determination unit are required to build up an electronic compass. The main functions of the signal conditioning unit are amplification of the sensor signals and offset compensation. In the direction determination 20 Theoretical Aspects of the Navigation System unit, the azimuth is derived as the desired compass output quantity from the measured field strengths Hey and Hex. Figure (3.13) shows a functional block diagram of an electronic compass. FIG 3.13 FUNCTIONAL BLOCK DIAGRAM OF AN ELECTRONIC COMPASS 3.3 OOPIC MICROCONTROLLER OOPic is an acronym for: Object-Oriented Programmable Integrate Circuit. OOPic provides the programmer with an object-oriented language model designed to interact with the electrical hardware components that are attached to the OOPic. The programmer can design hardware interface in software by creating objects and setting their properties to define their behavior and interaction with hardware. These objects can also be interconnected to form a Virtual Circuit. The programmer then utilize this hardware interface and it’s associated virtual circuits by writing a program that controls and responds to hardware events that occur. 3.3.1 OOPIC APPLICATION An OOPic application is a computer program written for the purpose of controlling electronic equipment connected to an OOPic microcontroller. The program itself is written and stored on a P.C. style computer where it is "compiled" into OOPic instructions and downloaded into the OOPic's EEPROM. The OOPic will start running the new program as soon as the PC is finished downloading and each time the power is turned on. The objects in the OOPic environment encapsulate the functionality of the hardware found in the PIC16C74 IC; an application can interact with the hardware quickly. This is in contrast to the alternative, which would be working with a long list of memory locations that represent scattered bits and pieces of the same hardware. 21 Theoretical Aspects of the Navigation System The concept behind OOPic is straight forward. Use preprogrammed multitasking objects from a library of highly optimized objects to do all the work of interacting with the hardware. Then write small scripts in Basic, C, or Java syntax styles to control the objects. During operation, the objects run continuously and simultaneously in the background while the scripts run in the foreground telling the objects what to do. Every aspect of the objects can be controlled by the scripts as the objects do their work with the hardware. Another unique feature of OOPic is the Virtual Circuits capability. A virtual circuit is a circuit in an OOPic that appears to be a physical discrete electronic circuit but is actually the objects within the OOPic emulating the functionality of the circuit. Virtual circuits are created by logically linking together a set of objects in the same methodology as one would physically link together a set of electronic components. Once created, each individual part of the virtual circuit can be manipulated or evaluated by the program providing total computerized control of the entire circuit. Virtual circuits are used to perform functions that provide continuous processes. In an OOPic application, things that need to be continuously updated or monitored can be done by using a virtual circuit. Other reasons and key features for selecting the OOPic were: • No additional expensive programming hardware to buy. • No additional EPROM eraser to buy. The OOPic's EEPROMs erase automatically when you download a new program. • No new language syntax to learn. The OOPic scripting languages are based on industry standard languages. In this project C language was used since. 3.4 DC MOTOR THEORY Briefly, when a current passes through a wire, which is subjected to a magnetic field, the wire will move (see the figure below). The direction of movement is determined by the direction of the field and the direction of the current. The speed of movement is determined by the strength of the field and the amplitude of the current. This principle is used in the electric motor to produce rotation. 22 Theoretical Aspects of the Navigation System FIG 3.14 DC MOTOR OPERATION Since the electric field is produced by the voltage difference, it can be controlled by controlling the applied voltage to the motor. Note that the electric field is proportional to the electrical voltage difference. 3.5 MOTOR CONTROLLER Controlling a DC motor needs a circuit that can control the applied voltage to the motor terminals. Since a microcontroller is used in this project, a motor controller that can interface to it is needed. After long search, it was found that the H-bridge is the best circuit to control the motor voltage. 3.5.1 H-BRIDGE THEORY The H-bridge is so named because it has four switching elements at the "corners" of the H and the motor forms the cross bar. The basic bridge is shown in the Fig (3.15). FIG 3.15 USING H-BRIDGE TO CONTROL DC MOTOR The "high side drivers" are the switches that control the positive voltage to the motor. The "low side drivers" are the switches that control the negative voltage to sink current to the motor. The switches are turned on in pairs, either high left and lower right, or lower left and high right, but never both switches on the same "side" of the bridge. If both switches on one side of a bridge are turned on it creates a short circuit between the battery plus and battery minus 23 Theoretical Aspects of the Navigation System terminals. If the bridge is sufficiently powerful it will absorb that load and your batteries will simply drain quickly. Usually however the switches in question melt. To power the motor, you turn on two switches that are diagonally opposed. In Fig (3.16), if the high side left and low side right switches are turned on, the current will flow through the motor forward. FIG 3.16 H-BRIDGE SAMPLE CONTROL CIRCUIT If the high side right and low side left switches are turned on, current will flow the other direction through the motor and the motor turns in the opposite direction. As each switch has one of two states, and there are four switches, there are 16 possible states. However, since any state that turns both switches on one side on is avoided, there are in fact only four useful states (the four quadrants) where the transistors are turned on. TABLE (3.1): H-BRIDGE TRUTH TABLE High Side High Side Left Right On Off Lower Left Off Lower Right On Quadrant Description Motor goes Clockwise Off On On Off Motor goes Counter-clockwise On On Off Off Motor "brakes" and decelerates Off Off On On Motor "brakes" and decelerates The last two rows describe a maneuver where you "short circuit" the motor which causes the motors generator effect to work against itself. The turning motor generates a voltage which tries to force the motor to turn the opposite direction. This causes the motor to rapidly stop spinning and is called "braking". Of course there is also the state where all the transistors are turned off. In this case the motor coasts if it was spinning and does nothing if it was doing nothing. 24 CHAPTER FOUR 4 MODELING AND SOLUTION ALGORITHM 4.1 SIMULATION Simulation studies have for long time been considered a valid investigation methodology to develop autonomous mobile robots, both for research purposes and industrial applications. Real mobile robots are not yet always employed during the initial research stage. To assist in developing the navigation system a simulation program was initially developed for this project. The program simulates the sensory inputs (i.e. GPS coordinates, compass) and the vehicle movement in order to test the results before transferring it to the robot. 4.1.1 SIMULATION FLOWCHART FIG 4.1 SIMULATION FLOWCHART 25 Modeling and Solution Algorithm The program can be used in two modes of operations, simulation or tracking. In the simulation mode the user can start the vehicle at any location in the world. The latitude, longitude, and initial heading are user determined. Also the user can enter the destination coordinates to setup the rout for the vehicle. A new position is calculated based on the speed, current position and current heading. A screen capture of the program in the simulation mode is shown in Fig (4.2) below: FIG 4.2 SCREEN CAPTURE OF THE PROGRAM IN THE SIMULATION MODE 4.2 MODELING OF THE CONTROL SYSTEM The classical closed feedback control loop was utilized in the modeling of the navigational problem, with an input command, feedback signal, error signal, and output transfer function characteristics. The target waypoint destinations are specified as the input command and the feedback signal is provided by the compass and GPS. Now, using the present position coordinates, it plots bearing from the target waypoint to determine the error. Correction signals are generated to reduce the error to a certain tolerance based on the bearing angle error signal generated. The corrective signals are sent to the robot motion control system, which translates the commands into motor control voltages that steer and propel (right, left or stop) the robot on the course. Once the bearing angle error and target range have been reduced to the required tolerance, the robot reaches its target destination waypoint. Now, the process continues until all target waypoints are navigated. 26 Modeling and Solution Algorithm NAVIGATION SYSTEM INPUTS Destination coordinates Current GPS coordinates Compass heading. NAVIGATION SYSTEM OUTPUTS Steering and speed control commands. User feedback information FIG 4.3 NAVIGATION SYSTEM BREAKDOWN 27 Modeling and Solution Algorithm 4.2.1 DESCRIPTION OF THE ALGORITHM The purpose of the navigation system is to control the movement of the robot along a path from one destination to another. In order to do so, the navigation system needs the appropriate inputs from the GPS, compass, and the operator (destination coordinates). Based on the combination of these inputs, the robot uses the algorithm programmed into the OOPic microcontroller to determine the appropriate movements for steering and speed control. After the user inputs the desired GPS waypoints (the latitude and longitude of each point), the current position of the robot is then taken through the GPS receiver. Next the destination coordinates are subtracted from the current coordinate latitude and longitude, in this way the ‘x’ and ‘y’ distances from the current location to the destination coordinate are acquired . The angle of rotation is then calculated dividing the ‘x’ distance by the ‘y’ distance and taking the arctangent of this value. The vehicle compares this angle with its orientation with respect to north, according to the digital compass, and turns the correct distance to face the destination. Now that the platform is facing toward the correct heading, it then moves forward for a period of time determined by the user. This process is repeated until the desired destination is reached. Once a destination has been reached, the navigation system sends a feedback (status) signal indicating the current vehicle location. After that the vehicle moves on to the next destination in the destination list. To determine the angle that the robot has to turn, it first must get its orientation from north; this is done by taking a reading from the electronic compass (heading), and then calculates the difference between the direction that the vehicle is currently facing and the direction that it needs to be facing. Depending on these calculations, the vehicle will turn at varying degrees to correct its path. 28 Modeling and Solution Algorithm 4.2.2 ALGORITHM FLOWCHART FIG 4.4 NAVIGATION ALGORITHM FLOWCHART 29 Modeling and Solution Algorithm 4.2.3 IMPLEMENTATION OF THE ALGORITHM To understand the navigation code, it is best to start with a high level approach and work downwards. A copy of the code is located in Appendix C and may be useful with the following discussion. The abstract design of the navigation system is represented in the following diagram. FIG 4.5 ABSTRACT NAVIGATION SYSTEM DESIGN The navigation system at the top takes the inputs from the path navigator, processes them and passes commands to the other subsystems. This is primarily represented in the main subroutine of our code. (I) PATH NAVIGATOR The path navigator portion of the code is primarily contained within the getgps subroutine. It has access to the GPS receiver and digital compass hardware. The navigation code uses the current GPS coordinates along with the destination coordinates and the compass reading to determine the direction to steer the vehicle. This is represented as a combination of the getafn, and turndir subroutines. The getafn subroutine determines the difference between the current latitude and longitude and the destination latitude and longitude, then uses this information to determine the angle of the destination from the current position relative to north. Once the angle of the destination relative to north is calculated, the turndir uses this value along with the current heading of the vehicle to determine the turn direction for the robot. Current latitude = lat, current longitude = lng Destination Latitude = detlat, destination Longitude = destlng ∆x = | destlng - lng | ∆y = | destlat – lat | Ө = tan-1 (∆y/∆x) To calculate the destination angle relative to north (afn): 30 Modeling and Solution Algorithm If the destination is in the 1st quadrant in relation to the current position (destlat > lat & destlng >lng) afn = 90 - Ө FIG 4.6 DESTINATION IN 1ST QUADRANT IN RELATION TO CURRENT POSITION If the destination is in the 2nd quadrant in relation to the current position: (destlat > lat & destlng < lng) afn = 270 + Ө FIG 4.7 DESTINATION IN 2ND QUADRANT IN RELATION TO CURRENT POSITION If the destination is in the 3rd quadrant in relation to the current position: (destlat < lat & destlng < lng) afn = 270 - Ө FIG 4.8 DESTINATION IN 3RD QUADRANT IN RELATION TO CURRENT POSITION 31 Modeling and Solution Algorithm If the destination is in the 4th quadrant in relation to the current position: (destlat < lat & destlng > lng) afn = 90 + Ө FIG 4.9 DESTINATION IN 4TH QUADRANT IN RELATION TO CURRENT POSITION ARCTAN(X) USING OOPIC The above calculation uses an approximation to arctangent since the OOPic does not support inverse trigonometric functions. This is challenging because the OOPic only works with small integer variables within the limits of -32768 and 32767. The arctan function has to cover the range of 0 – 45o (values of x between 0 and 1); first to avoid overflow errors or a division by zero problem at angles around 90 degrees. If the arctan has to be found for an angle α between 45 and 90 degrees (values of x above 1), you'll search for the arctan (1/x) and extract α = 90-arctan (1/x). For approximation of the arctan function, an acceptable result was given by polynomial approximation which is given by the formula: y = -0.30097 + 0.61955x - 0.001659 x2 x: a number from 0 - 1 y: an angle from 0 - 45° as approximation of the arctan function. This formula has to be simplified to always stay in the small-integer limits: y ={ [-150 + 310 x - (x2 DIV 2) - (x2 DIV 3) ] DIV 50 + 5 } DIV 10 This polynomial approximation gathers all the advantages: high speed, low memory, and good accuracy 32 Modeling and Solution Algorithm FIG 4.10 POLYNOMIAL APPROXIMATION OF ARCTAN (X) (II)MOTION CONTROL After the destination angle relative to north is calculated, the turndir subroutine subtracts this value from the heading in order to determine the turn direction for the robot. To choose which direction the platform will rotate the following criteria is used: FIG 4.11 TURN DIRECTION ALGORITHM To control the vehicle movement, the H-bridge is used to control the speed of the two DC motors. By varying the pulse widths inputted to the H-bridge, the motor can go from full speed reverse to full speed forward. To rotate the platform each motor is turned in opposing directions, this pivots the robot about its center. Now that the platform is facing toward the correct heading (heading = afn), the two motors are controlled to rotate in the same direction in order to move forward. (III) USER INTERFACE When the vehicle is activated, The LCD displays an initial introduction screen, and when a destination is reached a message is displayed on the screen. During operation the LCD moves 33 Modeling and Solution Algorithm through screens displaying the current position (latitude, longitude), speed and direction of the vehicle. The user interface is implemented in the updatelcd subroutine. (IV) TRACKING Tracking is achieved in a simple manner. Whenever the vehicle reaches a destination, it sends back a status signal to a computer at some base station. A software program integrated into the simulation receives this signal via the parallel port, and the current destination reached by the vehicle is displayed. In this way the remote user can know when the vehicle reaches a destination point, while inter-destination positions are unknown. FIG 4.12 VEHICLE TRACKING A screen shot of the program while running in the tracking mode is shown in Fig (4.13), it shows that the vehicle reached destination 2 successfully. FIG 4.13 SCREEN CAPTURE OF THE PROGRAM IN THE TRACKING MODE 34 CHAPTER FIVE 5 HARDWARE IMPLEMENTATION 5.1 HARDWARE INTERFACE This section describes the basics of interfacing the included components to the OOPic-R microcontroller. 5.1.1 OOPIC HARDWARE OBJECTS A hardware object is an object that represents and encapsulates a physically implemented piece of hardware in the OOPic. In an application, multiple instances of these objects can be declared, but only one per piece of hardware present in the OOPic can be operational at any given time. Object’s characteristics can be changed by changing its properties which are the attributes you set to or retrieve from the object. FIG 5.1 SYSTEM BLOCK DIAGRAM 5.1.2 MOTOR CONTROL AND DRIVE SYSTEM The vehicle is propelled by two bi-directional dc motors. The two motors are controlled by the dual H-bridge DC motor driver which is controlled by the OOPic-R. The OOPic-R microcontroller has a built in hardware object that is designed to work with H-bridge circuits. This object, called oDCMotor2, utilizes three digital I/O lines to control speed, 35 Hardware Implementation direction and braking of a dc motor. The H-bridge uses two drive inputs for direction and braking and a Pulse-Width-Modulated (PWM) input to vary speed. ODCMOTOR2 OBJECT The oDCMotor2 object is capable of driving a DC Motor at 255 different speeds, in forward or reverse plus free spinning, active braking, and friction braking (not used in this design) modes. The speed at which the motor spins is determined by varying the duty ratio of the PWM input. It is specified by a single value which can be configured to have a range of 0 to 255 or -128 to +127. This design uses the latter. By configuring the speed value with a range of -128 to +127, the direction of the motor is also specified. When the value is a positive number from 1 to 127, the motor turns forward at the speed indicated by the value. The higher the value, the faster the motor turns. When the value is a negative number from -1 to -128, the motor turns backwards at the speed indicated by the value. The lower the number, the faster the motor turns in reverse. When this value is 0, the motor is at free-spinning rest. A brake value is used to apply brakes and when this value is set to 1, the speed value is ignored and the motor will quickly stop. The method used to stop the motor is active braking. The oDCMotor2 object monitors the Value and the Brake properties, and based on their numeric values controls the direction, speed, and braking of a DC Motor by outputting control signals to the H-Bridge motor driver circuit . To control the speed of the motor, a PulseWidth-Modulated (PWM) clock cycle is outputted on the I/O line specified by the IOLineP property. The direction that the motor spins is controlled by setting one of the control lines specified by IOLine1 and IOLine2 properties to 1 while setting the other to 0. Whether or not the brakes are applied is controlled by outputting the same value to both of the control lines specified by IOLine1 and IOLine2 properties. The H-Bridge monitors the state of all three of these control lines and controls the DC motor accordingly. In normal operation, a 0 in the Value property will cause the PWM line to output 0 Volts, causing the motor to be at a full stop. If the Value property is greater than 0, then the Pulse-width of the PWM output is set to correspond to the Value property, the I/O line specified by the IOLine1 property is set to 5 Volts and the I/O line specified by the IOLine2 property is set to 0 Volts. This will cause the DC motor to go forward at a speed specified by the Value property. The higher the number (up to 127), the faster the motor will turn. If the Value property is less than 0, then the Pulse-Width of the PWM output is set to correspond to the absolute value of the Value property, the I/O line specified by the IOLine1 property is set to 0 Volts and the I/O line specified by the IOLine2 property is set to 5. This will cause the DC motor to go backwards 36 Hardware Implementation at a speed specified by the Value property. The lower the number (down to negative 128), the faster the motor will turn in reverse. When the Brake property is set to 1, both of the control lines specified by the IOLine1 and IOLine2 properties are set to 5 V and the PWM output is set to 5 V. Setting both the control lines to the same value will cause the Motor to generate power back into itself, effectively driving the motor back the other way which causes the motor to come to an abrupt stop. The combination of the Period and the PreScale properties specify the PWM clock cycle's frequency. The PreScale property specifies how many times a 5-Mhz clock is divided. This scaled down 5-Mhz clock is used to increment a Period-Duration Counter. A full PWM clock cycle has been reached when the Period-Duration Counter reaches the value specified by the Period property. The PreScale property can be set to divide the 5-Mhz clock by 1, 4, or 16, giving frequencies of 5-Mhz, 1.25-Mhz, and 312.5-Khz. The Period property can be set to any value from 1 to 255. This results in 765 possible frequencies. The Speed of the DC Motor is controlled by the Pulse-Width of the logic-high portion of the cycle determined by the Value property. At the beginning of each PWM clock cycle, the I/O Line specified by the IOLineP property is set to 5 Volts. Each time the Period-Duration Counter is incremented it is compared to the value specified by the Value property. When the PeriodDuration Counter reaches the value specified by the Value property the I/O Line is set to 0-Volts. The Period property also dictates the resolution of the PWM pulse. If the Period property is set to 255 then the Value property's range is 0 - 255. Likewise, if the Period property is set to 10, then the Value property's effective range is 0 - 10, because any value above 10 will never be reached by the Period-Duration Counter. The picture below shows a good example of how PWM works. PWM allowed the OOPic to represent any voltage between 0 and 5 volts with one IO line. FIG 5.2 PULSE WIDTH MODULATION OF A 12V, 4000 RPM DC MOTOR 37 Hardware Implementation ONAVCON OBJECT The oNavCon Object provides differential steering calculations that can be used to control two oDCMotor2 objects. It takes a speed value and a turn value and produces two values, one for each of the two motors, in a dual drive robotic base. The oNavCon object takes the value of the object linked to by the Input1 property (speed value) and both add and subtract the value of the object linked to by the Input2 property (turn value). The resulting two numbers (the two motor's speed values) are then stored in the objects linked to by the Output1 and Output2 properties where Output1 = (Input1 + Input2) and Output2 = (Input1 - Input2). If the Input2 value is 0, then both of the outputs will be set to the Input1 value. For example, if the Input1 value (speed) is 97 and the Input2 value (turn) is 0, then both of the Output values (right speed and left speed) will be set to 97. If the Input1 value is 0, then the Output values will be set to the positive and negative forms of the Input2 value. For example, if the Input2 value (turn) is 32 and the Input1 value (speed) is 0 then the Output1 value (right) will be 32 and the Output2 value (left) will be -32. If both the Input1 and Input2 values are 0 then both the Output values will be set to 0. A Limit property is provided for the cases where either of the output object's value properties cannot exceed the 8-Bits limitation (-128 to +127). For example: if the Input1 value (speed) is 120 and the Input2 value (turn) is 10 then the Output1 value (right) will be 130 and the Output2 values (left) will be 110. The output object will use the 8th bit of the number as a sign bit which results in the value of 130 being seen erroneously as a negative 126. By setting the Limit property to 1, the value of 130 is limited to +127 which will be seen correctly by the output object. 5.1.3 LCD MODULE The LCD is represented inside the OOPic code as an oLCDSE object that sends data serially on one data line. When the oLCDSE object's Value property is set to the ASCII value of a character, that character is sent out the I/O Line specified by the IOLine property. Setting the String property to a string of characters will sequentially send each character in the string to the LCD. 5.1.4 RF TRANSMITTER The RF transmitter is represented inside the OOPic as oDio1 object that sends data via one of the OOPic’s parallel I/O lines. The IOLine property of the oDio1 object specifies the physical I/O line to use. The Value property represents the electrical state of the I/O line and it 38 Hardware Implementation is set to 1 when transmitting. The Direction property specifies if the I/O Line is an input or an output (in this case it’s an output). 5.1.5 GPS AND COMPASS MODULES Each one of the GPS receiver and the electronic compass has I2C communication interface. Multiple devices can be connected to the I2C bus of the OOPic-R as long as they have different addresses. That is a major difference between I2C and RS232 serial communications. Serial port cannot transmit to multiple devices on the same line, while I2C can. THE I2C BUS CONCEPT The I2C-bus has two wires, serial data (SDA) and serial clock (SCL), carry information between the devices connected to the bus. Each device is recognized by a unique address and can operate as either a transmitter or receiver, depending on the function of the device. In addition devices can also be considered as masters or slaves when performing data transfers. A master is the device which initiates a data transfer on the bus and generates the clock signals to permit that transfer (OOPic), at that time, any device addressed is considered a slave (compass or GPS). FIG 5.3 I2C BUS CONFIGURATION The GPS and the compass modules are represented internally as I2C objects and communicate on the OOPic’s I2C communication bus. The oI2C object reads a byte from the I2C device connected to the Local I2C Bus. The Node property specifies the 7-Bit address of the I2C device with which to communicate. The 7Bit address is the I2C address that is assigned by the device's manufacturer and is 'hard-wired' into the I2C device. The Width property specifies how many bytes get transferred. If the Width property is set to 0, then 1 byte is transferred. If the Width property is set to 1, then 2 bytes are transferred. The Location property specifies the I2C device's register location. The NoInc property specifies if the Location property is increased each time the I2C device is read from or written to. 39 Hardware Implementation 5.2 PHYSICAL PLACEMENT OF COMPONENTS Each component is mounted on the car according to where it is needed. The compass reading is affected by anything that affects the local magnetic field; motors in particular contain strong magnets. The compass must be mounted as far away from magnetic and ferrous objects as is practicable. To minimize the possibility of interference, the compass is mounted as far rear as possible in the car, since the motors are at the front. To gain the best reception of GPS signal, the GPS module is mounted above a metal base on the top of the car in order to have a good view of the sky. 5.3 POWER MANAGEMENT Power management can be one of the biggest challenges in portable applications. The vehicle power system is designed to provide the required voltage levels for all of the components. The majority of the power consumption on the vehicle occurs in the drive motors. The large current draw of the drive motor causes large voltage distortions that severely affected other electronic components on the vehicle. To prevent this from happening, the DC motors were connected to their own 9V battery. The microcontroller comes with an onboard 5V DC regulator, which supplies the current required by the microcontroller (1A) and additional current (5A) for powering devices from its ports. The electronic compass, LCD and H-bridge were configured to draw current from the microcontroller based on their minimal current requirements. Two separate 9V batteries were provided to power the GPS receiver and the RF transmitter. 40 CHAPTER SIX 6 IMPLEMENTATION OF THE NAVIGATION SYSTEM 6.1 DEVELOPMENT STAGES Designing the system was a complicated process so it was tested in stages. After each system was completed, it was tested to see if it met the specifications. The first system to be completed was the user interface to help with debugging of the other subsystems. The next system to be developed was the mobile platform. To test this system, a desired route was preprogrammed into the microcontroller. By doing so the ability of the platform to move and turn properly was confirmed. The next component to be interfaced was the electronic compass. Using the LCD module, the output of the compass was read, and by comparing it with a handheld compass the two readings were identical. After that a demo was developed to test the vehicle’s ability to steer and ascertain its bearing. The demo that was decided upon was to have the car begin from arbitrary orientation and it must drive itself and turn in such a way as to reorient itself to a north facing position. This demo was a test of the integration of the compass and steering control. The most important sensor for this project, and the most challenging to get working, was the GPS receiver. Initially a GPS receiver was used. This receiver can communicate with other devices using the NMEA 0183 format. NMEA 0183 is an interface specification and protocol standard provided by the National Marine Electronics Association. NMEA 0183 is loosely based on RS-232 at 4800 Baud. In testing, the computer serial port’s RS-232 converter was able to process the data, but the one on the OOPic-R was not. The serial data from the GPS was likely to be too fast and the strings too long. The OOPic-R processes a byte at a time and so couldn’t stream serial data in for processing. After long trials this receiver was changed and the replacement was interfaced with the OOPic-R through the I2C bus. Next was the path navigation subsystem. This part was tested completely independently of the others. This was done by interfacing the microcontroller with the compass and the GPS receiver and outputting the results to the LCD display. Lastly, all of the components were integrated together and the path planning software was written. After applying the above test plan all of the key features were functional. However, additional features were added, the remote control circuit of the vehicle was reverse-engineered. The transmitter was interfaced with the microcontroller, and the receiver with a computer through 41 Implementation of the Navigation System the parallel port. Then the tracking software was written and integrated with the simulation program and finally the whole navigation system was tested. 6.2 RESULTS The final product was tested on a large patch. First one GPS coordinate was measured and programmed into the vehicle. Then the vehicle was placed approximately 30 meters from the target and facing away from the target. After sufficiently testing one coordinate, another coordinate was programmed into the car and same procedure was repeated except two coordinates were used instead of one. The vehicle achieves the goal of navigating to predefined GPS coordinates. Fig (6.1) shows a picture of the car. FIG 6.1 THE FINAL PRODUCT 6.3 PERFORMANCE Several generalizations and observations of the performance of the vehicle can be made. With the accuracy of the GPS, the vehicle doesn’t reach the exact destination point, since the accuracy is off by 3-5 meters in radius. This means that the vehicle may stop somewhere within the 3-5 meter radius. Also during testing the vehicle didn't go directly to the waypoint and this is also due to the GPS accuracy. In large patches, the vehicle navigates precisely enough for a variety of interesting paths and missions. However, it is just barely possible to run the vehicle in a suburban street without hitting the curb. A GPS route created down the middle of the street one day may be down the far edge of the street the next day due to different satellite configurations and the baseline GPS error. The tracking system is only limited to 100 meters; this distance was enough regarding the testing area. 42 Implementation of the Navigation System 6.4 EVALUATION OF ALTERNATIVE SOLUTIONS Throughout the initial design process, several alternative solutions have come up to various aspects of the project. One solution that was considered is not using a compass for the navigation of the RC car, by implementing a navigation algorithm that would not require the use of a compass. This navigation algorithm is based on comparing the vehicle’s current location with its previous location. From that data the direction that the car needs to turn in order to get closer to its destination can be determined. This process would be repeated every second or so until the destination is reached. Although this solution may require less hardware, it may not be as accurate as using a compass to determine which direction the car should turn. Each time the vehicle goes to a desired set of GPS coordinates, those coordinates must be programmed into the system. One possible method of doing this is having everything needed to program a new coordinate set located on the car. This would require an LCD screen to ask the user what coordinates to enter, as well as a keypad to allow the user to input the coordinates. However this solution was too difficult to implement given our time and budget constraints. An alternative solution to programming the new coordinates would be the use of a laptop. For example, whenever a new coordinate set is desired, the laptop could be hooked up to the system and reprogrammed via a serial link. Although this solution was not as desirable, it was more feasible given the scope of this project. One of the most important aspects of the project is the ability to control the RC car accurately. One possible solution was to directly tap into the servos of the steering and the drive motors of the car and completely bypassing the RC car’s controls. However, there is not a large amount of documentation publicly available for RC cars. Another proposed solution was to use the remote control of the RC car to move the car in the desired direction. This would require us to have extensive knowledge of how the remote control circuit works and would likely be too difficult to implement. After long search, it was found that the H-bridge was the best circuit to control the robot movement. 43 CHAPTER SEVEN 7 CONCLUSION AND FUTURE WORK 7.1 CONCLUSION The description of this project was to design, implement and test a navigation system. The project description was completed and the robot met all the specifications. After comparing the original goals with those accomplished, we see that the main goals have been met. The vehicle is capable of establishing its global location using the GPS unit. It is also able to determine its orientation using the digital compass. The vehicle outputs information to an LCD to make operation easier, and sends feedback signal to allow a remote user to track the vehicle location. Applying all of this information to the algorithm that was designed, the vehicle is able to navigate itself to all of its user-defined waypoints. The modular design of this navigation system enables it to quickly be migrated to a variety of vehicle platforms. In this project, modularity is present for both the hardware and software systems. For instance, a more accurate GPS device could quickly be introduced to the navigation system, with only minimal parsing changes to the navigation software. The physical scale of a device's navigation requirements can be measured by the accuracy to which the robot needs to navigate - this is the resolution of navigation. GPS on its own does not currently offer a sufficient navigation resolution to allow it to be used as a standalone global navigation method for mobile robots. However, there are several enhancements to GPS, both current and future, which may allow it to be more accurate for civilian use. Although this project was done on a small budget and a small scale, the same concepts and ideas can be applied to a larger scale application, given a larger budget. 7.2 FUTURE WORK For future work on this research, the following points are recommended: Currently the accuracy is about 3 -5 meters. This accuracy can be improved with the implementation of a differential global positioning system (DGPS) which could increase the accuracy to about 1.5 meters of a desired waypoint. Add a keypad to allow the user to enter the desired GPS coordinates. Implement sensors for obstacle avoidance such as IR, sonar or ultrasonic range finder. Interface the robot with image processing system (Vision based obstacle avoidance). 44 Conclusion and Future Work Wireless communication for remote operation. The user can send the destination coordinates from a host-PC and receive statistical data from the vehicle For safety purposes a wireless kill switch can be added. An independent system that can bring the reset port on the microcontroller low is all that is needed to. A camera can be added which would make it more viable for reconnaissance applications. Also a transmitter should be added so that this video can be analyzed back at the base station. Improve the tracking subsystem by using GSM/GIS technology. Complete operation from a cellular phone device This navigation system can be transferred into other complex vehicles such as autonomous boats which could map the bottom of rivers, lakes, harbors or other bodies of water or even into a small airplane for use to gather pictures of large tracts of land. The possibilities are endless and only limited to time and imagination. Future work is centered on finding practical work for the autonomous vehicles to do, as remote sensing platforms or transportation and delivery vehicles. 45 APPENDIX A: HARDWARE SPECIFICATIONS OOPIC-R ROBOT CONTROLLER BOARD http://www.oopic.com POWER AND VOLTAGE REGULATORS The OOPic-R's 3 voltage regulators are configured so that the logic side of the board has a private one-Amp power supply, while the I/O has a full five Amps of regulated power, plus an optional voltage regulator that can be specified and installed. A set of power selection jumpers allows different sections of the main I/O lines to be connected to the various power supplies. PROGRAMMING CONNECTOR In addition to being able to program the OOPic via the serial port, the Local I2C port has a programming connector on it. The following table shows the pin assignments for the 5-pin programming connector: Pin Name 1 LSDL 2 GND 3 LSCA 4 +5 5 RESET Description Local I2C Serial Data Ground Function I2C Serial Data generated by OOPic programmer when reading / writing the EEPROM. 0 Volt reference Local I2C Serial Clock I2C Serial Clock generated by OOPic programmer when reading / writing the EEPROM. +5 Volt Power Reset (Active Low) +5 Volt reference Pulled low to reset the OOPic when programming the Program EEPROM. MAIN I/O The Main I/O of the OOPic-R board is split up into four groups of four I/O connections. Each I/O connection has three pins: Signal, Power, and Ground. Each group of four I/O lines has a power selection jumper by the voltage regulator that allows the individual groups to be connected 46 Appendix A to power as needed. Power and ground pins are also found in four more places along the Main I/O which allows various connections to be made for a wide variety of devices. DUAL DC MOTOR I/O Provides the following connections: 2 PWM Lines 4 Digital I/O Lines +5 Volt Power & Ground. LCD I/O Pin Name Description Function 1 +5 +5 Volt power. +5 Volt reference 2 GND Ground 0 Volt reference 3 Data I/O Line 16 Provides the serial data for the LCD. I2C NETWORK CONNECTOR The I2C Network connectors provide the following connections. I2C Network. +5 Volt Power & Ground. Can be optionally used for a non-network connection to I/O lines 19 and 20. MEMORY MAP The memory of the OOPic2+ is arranged so that the application program has 96 bytes of Object space, 72 bytes of variable space and 256 bytes of Fast-Access EEPROM. 47 Appendix A OOPIC-R BOARD SCHEMATIC LYNXMOTION DUAL H-BRIDGE MOTOR DRIVER http://www.lynxmotion.com/Product.aspx?productID=92&CategoryID=10 The board incorporates diode protection of the output stages, and there is a LED indicator that the logic voltage is present. The microcontroller connection is 4 wires for the speed and direction control, and an optional enable line for each motor. SPECIFICATIONS 4.8v - 12vdc 4 amp Peak 2 amp Continuous Dual Channel, TTL Input Driver type = L298 IC Chip rated voltage = 46 vdc max Chip rated current = 2 amps max DHB Motor voltage = 20 vdc max DHB Motor current = 1 amp max I/O required = Four TTL level lines (outputs) 48 Appendix A Supply capacitance = 330uF 20v Logic voltage = 5vdc regulated Onboard regulator = None Current requirements (5v) = 36mA PC board size = 2.3" x 3.0" SCHEMATIC DIAGRAM DEVANTECH CMPS03 DIGITAL COMPASS http://www.robot-electronics.co.uk/shop/Compass_CMPS032004.htm The compass uses two Philips KMZ10A magnetic field sensors that are sensitive enough to detect the Earths magnetic field. The module generates a number that indicates the bearing of the robot in relation to the local magnetic field. 49 Appendix A SPECIFICATIONS Voltage Current Resolution Accuracy Output 1 Output 2 Size 5V only Required 20 mA Typical 0.1 Degree 3-4 degrees approx. after calibration Timing Pulse 1mS to 37mS in 0.1mS increments I2C Interface, 0-255 and 0-3599SCL speed up to 1MHz 1.26 x 1.38 in.32 x 35 mm The compass has a 16 byte array of registers, some of which double up as 16 bit registers as follows: Register 0 1 2,3 4,5 6,7 8,9 10,11 12 13 14 15 Function Software Revision Number Compass Bearing as a byte, i.e. 0-255 for a full circle Compass Bearing as a word, i.e. 0-3599 for a full circle, representing 0-359.9 degrees. Internal Test - Sensor1 difference signal - 16 bit signed word Internal Test - Sensor2 difference signal - 16 bit signed word Internal Test - Calibration value 1 - 16 bit signed word Internal Test - Calibration value 2 - 16 bit signed word Unused - Read as Zero Unused - Read as Zero Unused - Read as Undefined Calibrate Command - Write 255 to perform calibration step I2C communication protocol with the compass module is as follows: First send a start bit, the module address (0XC0) with the read/write bit low, then the register number you wish to read (registers 2 and 3 contain the 16 bit bearing). This is followed by a repeated start and the module address again with the read/write bit high (0XC1). You now read one or two bytes for 8bit or 16bit registers respectively. 16bit registers are read high byte first. 50 Appendix A GLOBAL POSITIONING SYSTEM MODULE http://www.acroname.com/robotics/parts/R217-TR-GPM.pdf The DS-GPM is a highly integrated Global Positioning System. The DS-GPM provides latitude, longitude, heading, altitude, speed, time, date and satellite position in easy to access registers via I2C and RS232 communications. Additionally the DS-GPM has a four-line, onboard fully configurable TTL IO port and a four-line analogue input port with automatic measurement. SPECIFICATIONS Parameter Supply Voltage (Vcc) (+5V) Supply Voltage (6-16V) Supply Current RS232 TX data output level RS232 RX data input level RS232 speed GPS port TX data output level GPS port RX data input level GPS port speed I2C speed I2C pull-up resistance ADC input voltage ADC measurement cycle IO line output voltage IO line output current IO line input voltage GPS positional accuracy GPS frequency band GPS channels Minimum 4.5 6 50 0.3 -15 0.1 0 0 0.3 0 2.5 - Maximum 5.5 16 60 Vcc – 0.8V +15 9600 3.3 3.3 9600 400 4.7 Vcc 100 Vcc-0.8V 20 Vcc+0.3V 5 1575.42 8 Unit V V mA V V bps V V bps KHz KΩ V ms V mA V Meters MHz - To read individual data and status registers from the GPS, a device write then read must be undertaken by the I2C Master. The write consists of a start condition, device address, register to start read and a stop bit. This is followed by a read, which consists of a start bit, device address, followed by data from the register specified and terminated with a stop bit. The GPS also auto 51 Appendix A increments the register specified for every additional read requested by the Master I2C device, which allows more than one register to be read in one transaction. LCD MODULE http://totalrobots.com/pdfs/DS-LCDDn_totalrobots_V1.03.pdf The SLCD216 module comprises a DS-LCDD1 serial interface module and a 2 line x 16 character alphanumeric LCD display with a back light option. The modules can be connected to any device capable of RS232 or inverted CMOS TTL, at 2400 or 9600 baud. Optional jumpers enable the selection of baud rate (2400 / 9600), back light and 1 or 2 line display and the LCD contrast can be adjusted with an on-board potentiometer. Connection to the module is through a four (4) pin vertical header, pinned as follows: Header Pin 1 2 3 4 Connection designation SO (Serial output GND (Signal ground) SI (Serial input) +5V (Supply) DC GEAR HEAD MOTOR http://www.lynxmotion.com/Product. aspx?productID=96&CategoryID=11 SPECIFICATIONS 7.2vdc 175rpm, Gear Head Motor Weight = 4.22 oz (119.63 g) Reduction = 50:1 metal gear Stall Torque = 99.04 oz-in (7.13 kg-cm) Length (motor and gear) = 1.72" (4.37 cm) Length (shaft only) = 0.89" (2.26 cm) Diameter (motor and gear) = 1.45" (3.68 cm) Diameter (shaft) = 6mm Current (at 7.2v no load) = 200mA Current (at 7.2v locked shaft) = 3.80A 52 Appendix B: Schematic Diagram 53 APPENDIX C: OOPIC CODE //--------- LCD Variables ----------------------oLCDSE LCD = new oLCDSE; //--------- GPS Variables ----------------------oi2c GPM = New oi2c; oWord Lat = New oWord ; oWord Lng = New oWord; Const GPMAdr = &h68; // Latitude storage register (1 degree accuracy) // Longitude storage register (1 degree accuracy) // GPM address, A0 &A1 jumpers ON //-------- Compass Variables -----------------oI2C Compass = new oI2C; oWord heading=new oWord; // create the compass object // 16 bit to store the reading //---------H-Bridge variables ------------------oDCMotor2 RightMotor= New oDCMotor2; oDCMotor2 LeftMotor = New oDCMotor2; oWord Turn=New oWord; using the object Navcon through VC oWord Speed=New oWord; // Right motor bank // Left motor bank // One number used to turn both left and right // One number used to command both forward // and reverse using the object Navcon through VC oNavCon Nav=New oNavCon; //-----------Destination Variables---------------Byte cd; Word destLat; Word destLng; //----------- Tx variables -------------------------oDio1 Tx=New ODio1; // Object used to command the vehicle around // using one speed value and one turn value //Current Dest number // destination latitude // destination longitude //----------- State Variables ----------------------oword afn=new oword; word ig; /*----------------------------------------------------*/ /* main program */ /*----------------------------------------------------*/ Sub void main(void) { destlat=38755; destlng=31901; Setup; lcd.string="Welcome"; oopic.delay=500; getgps; // get data from gps updatelcd; ig=1; do 54 Appendix C { if(((destlat==lat) |(destlat==(lat+1)) |(destlat==(lat - 1))) & (destlng==lng) | (destlng==(lng+1)) | (destlng==(lng - 1))) // if this is the final destination break; // exit the loop if(ig==1) { getafn; // calculate destination direction do { speed=0; turndir; // turn the vehicle towards destination lcd.clear; // clear screen lcd.string="Head="+str$(heading); // display current heading LCD.Value=254 ; LCD.Value=192 ; lcd.string="Dest="+str$(afn); // display destination direction } while(turn!=0); // repeat until turn =0 } speed=127; // move towards destination updatelcd; // update LCD screen (position, speed, and heading) getgps; // update vehicle position ig++; ig=ig%4; } speed=0; // stop when destination is reached lcd.clear; // clear LCD display lcd.string="Final destination"; Tx.value=1; // output status signal to the transmitter oopic.delay=100; Tx.value=0; oopic.delay=200; } //------------- Hardware initialization -------------------------Sub void Setup(void) { /*--------------------- gps setup --------------------------------- */ /* subroutine to setup I2C communication to DS-GPM */ /*-------------------------------------------------------------------*/ GPM.Node = GPMAdr; // Setup I2C address for GPM GPM.Width = cv8bit; //Control Info is 1-byte GPM.Mode = cv10bit; //I2C mode is 10-Bit Addressing GPM.NoInc = cvFalse; //Increment on every read/write //------------ lcd setup --------------------------------LCD.IOLine = 16; LCD.Clear ; 55 Appendix C /*--------------------------------- compass setup ---------------------------------------*/ /* this reads compass register 2, a 16 bit value representing the heading */ /*------------------------------------------------------------------------------------------*/ Compass.Node = 96; Compass.Mode = cv10bit; Compass.NoInc = 1; Compass.Location = 2; Compass.Width = cv16bit; // decimal of Hex address 0xC0 shifted right by 1 // I2C mode is 10-Bit Addressing. // don’t increment // Address of single byte bearing // Compass Data is 2-byte wide. //------------------------------- Tx setup -------------------------------------------Tx.IOline=1; Tx.direction=cvoutput; /*-------------------------- Motor setup ------------------------------------------- */ /* Speed is a value between 127 and -128 with 0 being neutral Or Stop.*/ /* When speed is set from 1 to 127 the vehicle will move forward and */ /* faster As the value /*goes up When speed is set from -1 to -128 the */ /* vehicle will move backward and faster As the value goes down */ /* Turn is a value between 127 and -128 with 0 being no turn at all. */ /* When turn is set from 1 to 127 the vehicle will move to the left. */ /* As the value goes up the vehicle turns harder. When turn is set */ /* from -1 to -127 the vehicle will move to the right. */ /*--------------------------------------------------------------------------------------*/ LeftMotor.IOLineP = 17; leftMotor.InvertoutD=cvTrue; leftMotor.prescale=2; leftMotor.period=255; LeftMotor.IOLine1 = 24; LeftMotor.IOLine2 = 25; LeftMotor.Operate = 1; LeftMotor.Brake = cvOff; LeftMotor.value = cvOff; // Enable line of motor control PWM is used IOLINE P // Changes direction moves when commanded forward // Used to step down the frequ. of PWM // Used to set resolution of PWM (# of steps for value) // First control line for an L293 H-Bridge IOLINE 1 // Second control line for an L293 H-Bridge IOLINE 2 // Used to make this object active in the list loop // brake is set to off // motor value set to 0 RightMotor.IOLineP = 18; RightMotor.InvertoutD=cvTrue; RightMotor.prescale=2; RightMotor.period=255; RightMotor.IOLine1 = 26; RightMotor.IOLine2 = 27; RightMotor.Operate = 1; RightMotor.Brake = cvOff; RightMotor.value = cvOff; Speed.signed = 1; // Enable line of motor control PWM is used IOLINE P // Changes direction moves when commanded forward // Used to step down the frequ. of PWM // Used to set resolution of PWM (# of steps for value) // First control line for an L293 H-Bridge IOLINE 1 // Second control line for an L293 H-Bridge IOLINE 2 // Used to make this object active in the list loop // brake is set to off // motor value set to 0 // Sets up the value property to use positive and negative // numbers 127 to -128 // Sets up the value property to use positive and negative // numbers 127 to -128 // Links the speed variable to the Navcon object // Links the turn variable to the Navcon object turn.signed = 1; Nav.Input1.Link(Speed); Nav.Input2.Link(Turn); 56 Appendix C Nav.Output1.Link(LeftMotor); Nav.Output2.LInk(RightMotor); // Links the first output of Navcon to LeftMotor value // using VC // Links the second output of Navcon to RightMotor // value using VC // Limits the left and right motor values from 127 to -128 // Used to make this object active in the list loop Nav.Limit = cvTrue; Nav.Operate = 1; } /*--------------------------------------------------------------------------- */ /* Subroutine to store speed, latitude and longitude as values */ /* -------------------------------------------------------------------------- */ Sub void getgps(void) { word lat1; word lng1; GPM.Location = 16; // start at register 16 Lat1 = (GPM*10000)+(GPM*1000)+(GPM*100)+(GPM*10)+GPM; // Store latitude in degrees GPM.location = 25; // start at register 25 Lng1 = (GPM*10000)+(GPM*1000)+(GPM*100)+(GPM*10)+GPM; // Store longitude in degrees if(lat1!=0) // if gps signal is not lost lat=lat1; // update latitude if(lng1!=0) // if gps signal is present lng=lng1; // update longitude } /*---------------------------------------------- */ /* Update LCD */ /*---------------------------------------------- */ Sub void updateLCD(void) { heading=compass/10; // get data from compass lcd.clear; LCD.string="Heading="+str$(heading); // display current heading LCD.Value=254 ; LCD.Value=192 ; GPM.location=50; // start at R50 LCD.String="Speed="+chr$(GPM+48)+chr$(GPM+48)+chr$(GPM+48)+"."+chr$(GPM+48)+"k mh"; // display speed oopic.delay=30; lcd.clear; GPM.Location = 14; // Point to R14 LCD.String="Lat="+chr$(GPM+48)+chr$(GPM+48)+chr$(GPM+48)+"."+chr$(GPM+48)+chr$( GPM+48)+chr$(GPM+48)+chr$(GPM+48); // display latitude LCD.Value = 254; LCD.Value = 192; GPM.location = 22; // point to R22 LCD.String="Lng="+chr$(GPM+48)+chr$(GPM+48)+chr$(GPM+48)+"."+chr$(GPM+ 48)+chr$(GPM+48)+chr$(GPM+48)+chr$(GPM+48)+chr$(GPM+48); // display longitude } 57 Appendix C /* ----------------------------------------------*/ /* calculate arctan */ /*---------------------------------------------- */ function word arctan(word xa,word ya) { word i; word i2; word a; word div; if (xa == 0) arctan = 90; else if (ya == 0) arctan = 0; else { if (ya >= xa) { i=Xa*100; i=i/Ya; } else { i=ya*100; i=i/xa; } i2= i * i; div= 310 * i; a = div - 150; div= i2 / 2; a = a - div; div= i2 / 3; a = a - div; a = a / 50; a = a + 5; a = a / 10; if (ya >= xa) arctan = 90 - a; else arctan = a; } } /*------------------------------------------------------------------*/ /* Determine destination Angle */ /*------------------------------------------------------------------ */ sub void getafn(void) { word dx; word dy; if((destlat>=lat) & (destlng>=lng)) { dy=destlat - lat; 58 Appendix C dx=destlng - lng; afn=90 - arctan(dx,dy); } else if((destlat>=lat) & (destlng<=lng)) { dy=destlat - lat; dx=lng - destlng; afn=270 + arctan(dx,dy); } else if((destlat<=lat) & (destlng<=lng)) { dy=lat - destlat; dx=lng - destlng; afn=270 - arctan(dx,dy); } else { dy=lat - destlat; dx=destlng - lng; afn=90 + arctan(dx,dy); } } /*-----------------------------------------------*/ /* Determine turn direction */ /*-----------------------------------------------*/ sub void turndir(void) { word sbt; heading=compass.value/10; if(afn>(heading+1)) { sbt=afn - heading; if(sbt>180) turn= 127; else turn= -127; } else if((heading - 1)>afn) { sbt=heading - afn; if(sbt>180) turn= -127; else turn= 127; } else turn=0; } 59 APPENDIX D: SIMULATION CODE //********** initialization code ****************************** #include <stdio.h> #include <graphics.h> #include <conio.h> #include <math.h> #include <dos.h> //******* programmed destination coordinates********************* //*** [destination number, longitude, latitude] ********************* float dest_list[5][3] = {1,20255,37087, 2,20234,37098, 3,20222,37088, 4,20241,37076,5,20250,37083}; //******* initial gps reading *********************************** float gps_pos[2] = {20270,37077}; // ******* initial compass reading (radians where North = 0)********** float pi=3.1415, heading = pi/4; //********* tolerance range for destination and timeout************** int tolerance = 1; const timeout = 100; //************* robot initialization ***************************** int speed = 0; int turn_dir = 0; //************ simulation initialization ************************** int i = 1; float path_history[timeout][2] = {gps_pos[0],gps_pos[1]}; float nav_info[3] = {0,0,0}; float dT = 0.5; int num_dests = 5; int cur_dest_num = 1; float start_pos[2] = {gps_pos[0],gps_pos[1]}; float getDistInfo(float[],float[]); void getNavInfo1 (float[2],float[3],int); float getAngleFromHeading2(float[],float[]); void track(int); void plot(); 60 Appendix D void nav(); void initmouse(); void showmouse(); void hidemouse(); void mouseclick(int*,int*,int*); //****************** simulation code ********************** void main() { int c=0; long x,y,r; int gdriver = DETECT, gmode; initgraph(&gdriver, &gmode, "C:\\TC\\BGI"); setbkcolor(BLACK); initmouse(); showmouse(); //***************** plotting code**************************** //* get the distance that is considered close enough to target //* plot destination circles //* plot green circle at starting point //********************************************************* setcolor(GREEN); x=10*(start_pos[0]-20220); y=10*(start_pos[1]-37075); r=10; circle(x,y,r); delay(200); outtextxy(x,(y+10),"THE START"); delay(200); int j=0; while( j < num_dests) { setcolor(BLUE); x=10*(dest_list[j][1]-20220); y=10*(dest_list[j][2]-37075); 61 Appendix D r=10*tolerance; circle(x,y,r); delay(200); switch(j) { case 0: outtextxy(x,y,"1"); break; case 1: outtextxy(x,y,"2"); break; case 2: outtextxy(x,y,"3"); break; case 3: outtextxy(x,y,"4"); break; case 4: outtextxy(x,y,"5"); break; } sound(900); delay(500); nosound(); j = j + 1; } int mx,my,mb; setfillstyle(SOLID_FILL,WHITE); bar(30,400,100,430); setcolor(BLUE); outtextxy(35,410,"SIMULATE"); setfillstyle(SOLID_FILL,WHITE); bar(200,400,250,430); setcolor(BLUE); outtextxy(205,410,"TRACK"); setfillstyle(SOLID_FILL,WHITE); bar(400,400,450,430); setcolor(BLUE); outtextxy(410,410,"EXIT"); do { mouseclick(&mb,&mx,&my); if((mb==1) && (mx>30) && (mx<100) && (my>400) && (my<430)) { 62 Appendix D nav(); //% plot red circle at stopping point setcolor(RED); x=10*(gps_pos[0]-20220); y=10*(gps_pos[1]-37075); r=10; circle(x,y,r); continue; } if((mb==1) && (mx>200) && (mx<250) && (my>400) && (my<430)) { int result,port=0x379; do { do { result=inport(port); } while(result != -13193); track(c); c++; } while(c<5); continue; } if((mb==1) && (mx>400) && (mx<450) && (my>400) && (my<430)) break; } while(mb!=6); closegraph(); } void getNavInfo1(float gps_pos[2],float dest[3],int num_dests) { 63 Appendix D int cur_dest_num = dest[0]; float dest_pts[2] = {dest[1],dest[2]}; //***************** get path control information ******************** float turn_dir=0; float speed = 2; // ********** get the distance away from the destination ****************** float distance = getDistInfo(gps_pos, dest_pts); // ********* determine if the robot has reached its destination. if it has, set **** //******* the current destination to the next destination or else finish ********* int next_dest = cur_dest_num; if(distance < tolerance) { speed = 0; if(cur_dest_num < num_dests) next_dest = cur_dest_num + 1; else next_dest = 0;// % finished course } nav_info[0]=turn_dir; nav_info[1]=speed; nav_info[2]=next_dest; } float getDistInfo(float gps_pos[2],float dest[2]) { //******** this function calculates the distance to the next destination coordinate**** //********* distance = (deltaX^2 + deltaY^2)^(1/2)*************************** float deltaX = gps_pos[0] - dest[0]; float deltaY = gps_pos[1] - dest[1]; float calc_distance = pow((pow(deltaX,2) + pow(deltaY,2)),0.5); return calc_distance; } float getAngleFromHeading2(float gps_pos[2],float dest[2]) 64 Appendix D { float dx = dest[0] - gps_pos[0]; float dy = dest[1] - gps_pos[1]; float invtan,afr; if( dx == 0) invtan = 0; else invtan = atan(dy/dx); if( invtan >= 0) if( dx == 0) if( dy >= 0) afr = pi/2; else afr = 3*pi/2; else if( dx > 0) afr = invtan; else afr = pi + invtan; else if( dy >= 0) afr = pi + invtan; else afr = 2*pi + invtan; return afr; } void track(int tr) { int x,y; x=10*(dest_list[tr][1]-20220); y=10*(dest_list[tr][2]-37075); delay(1000); sound(765); delay(200); setfillstyle(1,RED); 65 Appendix D bar(x-3,y-3,x+3,y+3); sound(379); delay(200); setfillstyle(1,WHITE); bar(x-3,y-3,x+3,y+3); sound(999); delay(200); nosound(); setfillstyle(1,RED); bar(x-3,y-3,x+3,y+3); sound(379); delay(200); setfillstyle(1,WHITE); bar(x-3,y-3,x+3,y+3); sound(999); delay(200); nosound(); setfillstyle(1,RED); bar(x-3,y-3,x+3,y+3); } //% plot path void plot() { int x,y,r; setcolor(WHITE); x=10*(path_history[i][0]-20220); y=10*(path_history[i][1]-37075); r=5; circle(x,y,r); //sound(600); delay(100); nosound(); delay(100); } 66 Appendix D void nav() { while( (cur_dest_num != 0) && (i < timeout)) { float cur_dest[3] = {dest_list[(cur_dest_num-1)][0],dest_list[(cur_dest_num1)][1],dest_list[(cur_dest_num-1)][2]}; //******************** get inputs from Navigator ******************** getNavInfo1(gps_pos, cur_dest, num_dests); turn_dir = nav_info[0]; speed = nav_info[1]; cur_dest_num = nav_info[2]; float dest_pts[2] = {cur_dest[1],cur_dest[2]}; heading=getAngleFromHeading2(gps_pos,dest_pts); //********** calculate new position and heading and add to path history****** i = i + 1; gps_pos[0] = gps_pos[0] + speed * dT * cos(heading); gps_pos[1] = gps_pos[1] + speed * dT * sin(heading); path_history[i][0] = gps_pos[0]; path_history[i][1] = gps_pos[1]; setfillstyle(0,WHITE); bar(100,430,500,480); plot(); setcolor(RED); char msg[20]; sprintf(msg,"LATITUDE= %f",gps_pos[0]); outtextxy(100,430,msg); sprintf(msg,"LONGITUDE= %f",gps_pos[1]); outtextxy(100,450,msg); sprintf(msg,"SPEED= %d",speed); outtextxy(300,430,msg); sprintf(msg,"ANGLE= %f",(heading*180/pi)); outtextxy(300,450,msg); delay(600); } 67 Appendix D } void initmouse() { _AX=0; geninterrupt(0x33); } void showmouse() { _AX=1; geninterrupt(0x33); } void hidemouse() { _AX=2; geninterrupt(0x33); } void mouseclick(int *bottom,int *x,int *y) { _AX=3; geninterrupt(0x33); *bottom=_BX; *x=_CX; *y=_DX; } 68 APPENDIX E: PROGRAMMING & USING THE OOPIC Before the OOPic can be used it must be programmed. A great deal of the project development involved writing programs for the OOPic to interface with hardware. To program the OOPic, one should go the OOPic website (www.oopic.com) and download the latest version of the OOPic Multi-Language Compiler, which at the time of our project was in version 5, then install the compiler. PREPARING THE OOPIC FOR PROGRAMMING Start the OOPic Multi-Language Compiler open. To prepare the OOPic for download of a program attach the serial cable to the interface at the back of the computer but do not attach it to the OOPic programming connector, yet. In the compiler software go to Tools Æ Cable Æ Configuration and a dialog window will appear. Press the Find Serial Cable. 69 Appendix E Then, go to ToolsÆ Language and select the language syntax that you would like to use (C, Java, or Basic). All of the developed code for our project was written in C syntax because of our previous experience and familiarity. Now, you may attach the OOPic RS232 serial connector to the serial programming cable. You may now program the OOPic. 70 Appendix E PROGRAMMING THE OOPIC FROM A FILE Start with the OOPic Multi-Language Software open, then go to FileÆ Open and the following dialog will open. Navigate the dialog window to the location of your source file. It will have the extension *.osc. When you have found the desired file, click on it. Its file name will appear in the File name text box and you may press the Open button. The dialog window will close and the program will open to a window in the OOPic Mult-Language Compiler environment. To program the OOPic, you may either use the button with triangle pointing to the Right or press F5. The code will compile and download to the EEPROM on the control board 71 Appendix E USING THE NETWORK CONNECTORS TO DEBUG CODE To use this function, in the main body of the program insert the line: OOPic.Node = #, where # is a number between 1 and 127. Next program the OOPic as described before. Then in the OOPic Multi-Language Compiler environment click on the icon labeled NETWORK NODE() in the right pane and the following dialog will appear. In the field labeled Node enter the same number you entered for # in the line of code you inserted in your code on the previous step. Press the Set button and the dialog will close. Next, reset the OOPic by pressing the reset button on the OOPic-R control board. Now, while the program is running you may double-click on any of the icons in the right pane of the OOPic Multi-Language Compiler environment as shown. These icons represent objects you have declared in your program and when you double-click on them a dialog similar to the following will appear. These dialog windows will vary with the objects they are associated with them. In these dialog windows you can view the current values of the attributes associated with that object. However, they do not update automatically. In order to view the value of an attribute at any given time the user must press Refresh button to update the values. . 72 APPENDIX F: USER MANUAL I. Preparing the Course Before any modifications can be made to the robot car the course that it will run must be investigated and prepared. First go out to the site where the course will be and investigate the site for suitability. Take special care with regard to wet ground due prevent damage to electronics. Next, select points on the site to create a course or path. Finally, record your path coordinates for programming the robot car. II. Modifying Source Code To modify the source code of the vehicle to navigate to desired coordinates, look in the source code add the coordinates of the destinations into the list. III. Programming the OOPic To program the robot control board after modifying and saving the source code file, follow the instructions at www.oopic.com or Appendix E for Programming the OOPic from a file. IV. Activating the systems 1. Connect the RF receiver to the parallel port and run the simulation program. Press the Track button. The computer now ready to track the vehicle. 2. Place the vehicle out onto the field of operation. Make sure that the vehicle has a clear view of the sky. 3. Plug in power for the GPS and wait until positional information acquired. This can take several minutes depending on how long the GPS has been blocked form viewing the sky. Once a valid GPS signal is acquired the status indicator changes from steady ON to flashing. 4. Plug in power for the motors and for the microcontroller which supplies the other electronic components. 5. The LCD should now display a welcome message. 6. Move away from the vehicle and wait for operation to begin. 7. The vehicle will travel to all the way points and will send tracking signals back to the computer into which the simulation program is running. Information pertaining to its progress will be displayed on the LCD. The LCD shows current coordinates, heading, speed and direction it needs to turn. The time it takes to finish traversing all the waypoints depends on how far away the waypoints are. 8. When the vehicle finishes going through the course it will stop and the LCD should display a message. You may now disconnect the power. 73 Appendix G: Schedule of Tasks 74 REFERENCES Dennis Clark; Programming and Customizing the OOPic Microcontroller, McGrawHill, 2003. Savage Innovations; OOPic Programmer's Guide, http://www.oopic.com/tech.htm Imperial College, Jonathan Dixon, Global Reference Navigation for Mobile Robots: Issues in Practical Implementation,1997, http://www.doc.ic.ac.uk/~nd/surprise_97/journal/vol2/jmd/#ab ENSCO Inc., Autonomous Vehicle Technology: Qualifications , 2002, http://www.ensco.com/news/darpa/qua_exp.htm Peter H. Dana, Global Positioning System Overview, 1999, http://www.colorado.edu/geography/gcraft/notes/gps/ Federal Radio navigation Plan (FRP), USNO NAVSTAR Global Positioning System, 1994, http://tycho.usno.navy.mil/gpsinfo.html#sig Marshall Brain & Tom Harris, How GPS Receivers Work, 1999, http://electronics.howstuffworks.com/ 75