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