Unmanned Ground Vehicle Project Report

In the name of Allah, the Most Beneficent, the Most Merciful
Final Year Project Report 2008

FYPR IIEE 16b 459 2008
UGV
Unmanned Ground Vehicle
KASHIF IQBAL (1631)
SHAHBAZ ALI (1627)
SYED ADIL MUDASSIR AHSAN (1628)
SYED MUHAMMAD AAFAQ ASHRAF (1631)
Submitted to In-charge
Final Year Project
Ashab Mirza
Associate Professor IIEE
SUPERVISORS OF THE PROJECT
External Project Supervisor
Mr. Riaz-un-Nabi
Visiting Lecturer at IIEE

BE (Industrial Electronics) NEDUET, Karachi
Project Work Incharge
Mr. Ashab Mirza
Associate Professor at IIEE

MS (Aerospace Engg.) ENSAE, Toulouse, France
BE (Electronics) NEDUET, Karachi
Email: [email protected]
edication
This project is dedicated to our sweet, precious and beloved parents and family members,
who gave us courage and who have been the reason behind our success and prayed for the
completion of this project successfully on time. They are the ones who supported us
financially, morally and spiritually. We are nothing without them. Thanks for everything.
This project is also dedicated to the respected Faculty Members of Institute of Industrial
Electronics Engineering, who helped us all the way through to complete our project.
KASHIF IQBAL
SHAHBAZ ALI
SYED ADIL MUDASSIR AHSAN
SYED MUHAMMAD AAFAQ ASHRAF
Preface
In 1990, in response to Congressional concerns, a number of Department of Defense (DoD)
advanced development projects related to ground vehicle robotics were consolidated under the
Joint Robotics Program (JRP) directed by the Office of the Secretary of Defense (OSD). The
Joint Robotics Program Master Plan (JRPMP) is prepared annually and provided to Congress.
The plan provides a single, integrated DoD document that lays out the strategies for acquiring
first-generation UGVs and for developing technologies critical to follow- on systems.
Robotics industry leaders point out that advances in military, transportation, medical, and other
non-manufacturing robotics applications, where research and development investments are
justified by dramatic potential benefits, will provide the technologies to advance future
generations of robots for application in manufacturing. Industrial robots will trail in technology
development, adopting advanced technology as it is proven to be reliable and cost effective;
autonomous mobile systems for military applications represent the forefront of robotics research.
Thus we got the insight of applications on both positive and negative aspects. When we came in
final year we started searching for ideas to make the final year project. The idea of UGV was
developed in fact from the idea of unmanned solar car which I thought, could revolutionize the
industrial standards with the mobility of hazardous chemicals without human involvement and in
the midst of energy savings focal point. But the other fact beneath the base of idea was that we
wanted to do some work which never had been successful in our country before. Reading THE
DAWN newspaper I found that research work have been started by Pak army for the
development of UGVs, which invoked us to at least achieve success in prototype implementation
of idea, of course we cannot afford the budget as well as time for the big one.
This document completely elucidate the combined implementation of the two modes of UGV on
a designed vehicular body and communicate with it via remote PC as well as to test its artificial
intelligence algorithm via pre defined map loaded in the vehicles controller
The inside chapters enclose the Block Diagram of the operation, Flowcharts of system,
background , hardware, firmware and software, explanations of all program codes of both PC
side as well as the embedded side, all sort of source codes. Finally, all the links and references
we went through are enfolded in this document.
To finish, I wish good luck for the reader to gain some from this little piece of art.
ACKNOWLEDGEMENT
We want to fully acknowledge the efforts of our
concerned teachers specially Professor Ashab
Mirza, Sir Farhan Khan and Sir Riaz
Nabi for depicting their keen interest in our project
and for guiding us about major fraction of the project,
so that we are successful to end the project in a more
better way than it was aimed.
OPERATION MANUAL
UNMANNED GROUND VEHICLE
Page - 1
LIST OF FIGURES
Figure 1.1: Block Diagram of the Project
Figure 1.2: A Snapshot of UGV
Figure 2.1: Sketch of UGV
Figure 2.2: Speed motor control circuit
Figure 2.3: Position Motor Control Circuit
Figure 2.4: Optocoupler IC
Figure 3.1: Vehicle Side Schematic
Figure 3.2: LM317 Adjustable Positive Voltage Regulator
Figure 3.3: Transistor level circuitry modeling for single H-bridge package driving speed motor
Figure 3.4: Transistor level circuitry modeling for single H-bridge package driving direction motor
Figure 3.5: Optocoupler modeling using LED and phototransistor
Figure 3.6: Battery Discharge Curve
Figure 4.1: Xbee Pro
Figure 4.2: Data packet sent by the PC to the microcontroller
Figure 5.1: Linear velocity and angular velocity are related by equation of rolling
Figure 5.2: C & Direction Keys
Figure 5.3: Pre-Defined Maps
Figure 5.4: Segmented Map
Figure 5.5: Main GUI window
Figure 5.6: UGV Navigation Mode GUI window
Figure 5.7: UGV Autonomous Mode GUI window
Figure 6.1: Non inverting & Inverting PWM Concept
Figure 6.2: Illustration of inverting and non inverting PWM
Figure 6.3: Position Actuation Concept
Figure 7.1: Analog to Digital Image Conversion
Figure 7.2: Example of Single Frame Acquisition (filling in glass mug starts)
Figure 7.3: Example of Multiple Frame acquisition (Glass Mug filled)
Figure 8.1: An RGB image, along with its separate R, G and B components
Figure 8.2: A representation of additive color mixing
Figure 8.3: RGB Cube
Figure 8.4: Example of imfilter
Figure 8.5: Vehicles and persons tracked throughout the scene
Figure 8.6: Implementation effects of Frame Comparison Algorithm
Figure 9.1: Speedometer
Figure 9.2: Block diagram of video image
Figure 10.1: Predefined map divided into segments
Figure 10.2: Motion Planning Workspace
_________________________________________________________________
PCSIR - Institute of Industrial Electronics Engineering,
IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi 75300
Pg- 6
Pg-10
Pg-13
Pg-14
Pg-15
Pg-16
Pg-20
Pg-20
Pg-22
Pg-23
Pg-25
Pg-28
Pg-34
Pg-35
Pg-39
Pg-40
Pg-44
Pg-44
Pg-46
Pg-47
Pg-48
Pg-53
Pg-53
Pg-54
Pg-59
Pg-65
Pg-67
Pg-71
Pg-72
Pg-74
Pg-75
Pg-79
Pg-79
Pg-84
Pg-85
Pg-89
Pg-94
Page - 2
LIST OF TABLES
Table 3-1: Possible conditions of states existing for H-bridge and their consequences
Pg-22
Table 3-2: Possible conditions of states existing for H-bridge and their consequences
Pg-24
Table 4-1: Comparison of various available protocols
Pg-33
Table 5-1: Some Properties of MSCOMM
Pg-39
Table 5-2: VB Key Codes of corresponding used keys of keyboard
Pg-43
_________________________________________________________________
Page - 3
Abstract
Unmanned ground vehicle is a robotic platform that is used as an extension of human

capability. This type of robot is generally capable of operating outdoors and over wide
variety of terrain, functioning in place of humans. There are two general classes of
unmanned ground vehicles: Teleoperated and Autonomous. Our solution is to
establish a UGV prototype which has two modes of operation, i.e. both as teleoperated
and as autonomous robots. A teleoperated UGV is a vehicle that is controlled by a
human operator at a remote location via a communications link. All cognitive
processes are provided by the operator based upon sensory feedback from either lineof-sight visual observation or remote sensory input such as video cameras. An
autonomous UGV is essentially an autonomous robot but is specifically a vehicle that
operates on the surface of the ground.
_________________________________________________________________
Page - 4
SYNOPSIS
The Unmanned Ground Vehicle (UGV) program is our final year robotic research
project that began in March 2008. The goal of the UGV project is to develop, by
November 2008, the technologies critical for minimally supervised, autonomous,
cooperative UGVs capable of military missions (typically scout reconnaissance). The
required capabilities under development were for:
(1) Teleoperation Mode (on-road and off-road)
(2) Image Capture
(3) Autonomous navigation (on-road and off-road),
(4) Automatic target recognition (ATR), and
(5) Minimum supervisory control.
The benefits of UGVs to the various fields are obvious:

(1) Reduction in loss of life,
(2) Near-continuous operation without fatigue &
(3) Force multiplier.
In addition, many of the technologies developed for the UGVs are useful for
autonomous driving by civilian vehicles, and, thus, ties were established, early on,
with the Department of Transportation.
_________________________________________________________________
Page - 5
UGV is a robotic platform that is used as an extension of human capability. This type
of robot is generally capable of operating outdoors and over a wide variety of terrain,
functioning without presence of human for the operation.
There are two kinds of UGVs:
1) Teleoperated UGV
2) Autonomous UGV
IMPLEMENTATION
Our UGV may be operated in either mode. The project may be divided categorically
into the following four sections:
Mechanical Assembly
Electronic Circuitry
Teleoperation
Autonomous operation
Their details are as follows:
i.
Mechanical Assembly:
The mechanical assembly of UGV is composed of a plastic toy car as the vehicle
body, PMDC motors for speed and direction controlling of the motor, camera mounted
on the front of the vehicle, on-board battery to meet the energy requirements,
electronic PCB, optocoupler/disc assembly.
_________________________________________________________________
ii.
Page - 6
Electronic Circuitry:
The electronic circuitry on the PC side consists of Xbee transceiver interfaced with the
serial port of the PC through a max 232 IC. On the vehicle side, the PCB consists of
the following;
Voltage regulators for motor, microcontroller and Xbee transceiver.
H-bridge based controller interfaced motor driver circuitry for bidirectional

controlling of both, speed and direction motors.
Xbee transceiver for communicating with the PC.
Disc, optocoupler (phototransistor + led) assembly for speed feedback.
iii.
Teleoperation:
In the teleoperation mode, the UGV navigation takes place through the PCs keyboard.
Live video sensory input from the UGV is available to the user through the on-board
video camera. The user may make a decision based on this video feed or take
snapshots of interesting objects/events. The UGV may move forward and backward or
turn leftward and rightward.
iv.
Autonomous Operation:
In its autonomous mode, a map is defined with dimensions in the PC and a snapshot
of the final destination is provided. The UGV starts navigating with instructions being
received by the PC while the PC estimates the current position of the UGV on the map
based on the feedback attained from the vehicle. Upon transversing through the map,
the vehicle compares the current image with the one saved for the target. If the two
images match by a certain percent, then the vehicle signals its arrival in the correct
destination, else it generates an error.
_________________________________________________________________
Page - 7
CHAPTER 1
INTRODUCTION
This chapter contains a description of the engineering problems associated with an
UNMANNED GROUND VEHICLE aka UGV. It goes on to present the research
efforts of other universities, the research efforts of students from previous batches of
IIEE and then finally, our own solution.
CONTENTS:
a.
b.
c.
d.
Problem Description
Block Diagram
Early Research Efforts
Our Solution
_________________________________________________________________
1.1
Page - 8
PROBLEM DESCRIPTION
In the broadest "dictionary" sense, an unmanned ground vehicle (UGV) is any piece of
mechanized equipment that moves across the surface of the ground and serves as a
means of carrying or transporting something, but explicitly does NOT carry a human
being. With the advancement of time as a next generation ground forces, and for
radiation monitor, airport security, nuclear waste control and casualty recovery, the
importance of UGVs cannot be ignored. UGV or Unmanned Ground Vehicle is a
robotic platform that is used as an extension of human capability. This type of robot is
generally capable of operating outdoors and over a wide variety of terrain, functioning
without presence of human for the operation. UGVs are basically classified into two
types with respect to their functionality:
1. Self controlled and transportable vehicle, on users command.
2. Remotely operated and controlled vehicle (ROVs).
The basic idea of our project is to combine both functionalities and tasks of UGV on
one platform to meet the complete task oriented features of UGV. Various other works
have also been done on UGV but majority of these works were focused on any one
single task of the two mentioned above, amongst which some are elaborated in
section1.3. Thus for achieving this goal we have decided to accomplish following four
objectives in our project.
Operation of the vehicle on pre-defined path.
Real time remote monitoring and control.
Obstacle detection.
Feedback Control System.
_________________________________________________________________
Page - 9
The next section consists of complete block diagram and its introductory description
of each block within the figure.
1.2
EARLY RESEARCH EFFORTS
The academic community usually refers to UGVs (especially UGVs possessing

significant autonomous capabilities) as mobile robots. There is a certain irony in this
terminology, since many of the key research issues (e.g., "inverse kinematics")
addressed in "traditional" robotics (oriented to the control of industrial manipulators)
are completely irrelevant to mobile robots. There is some commonality in issues
relating to path planning, obstacle avoidance, and sensor-based control, but results
have tended to flow more from mobile robots to manipulators, rather than in the other
direction. The focus of mobile robotic research has in fact evolved from the discipline
of artificial intelligence (AI). Surveys of early mobile robots and autonomous vehicle
research include [Flynn, 1985], [Harmon, 1986], [Klafter, 1988], [Meystel, 1991],
[Everett, 1995].
The first major mobile robot development effort was Shakey, developed in the late
1960s to serve as a testbed for DARPA-funded AI work at Stanford Research Institute
(SRI) [Nilsson, 1969]. Shakey was a wheeled platform equipped with steerable TV
camera, ultrasonic range finder, and touch sensors, connected via an RF link to its
SDS-940 mainframe computer that performed navigation and exploration tasks. As
befit an AI testbed, the Shakey system could accept English sentence commands from
the terminal operator, directing the robot to push large wooden blocks around in its lab
environment "world". While Shakey was considered a failure in its day because it
never achieved autonomous operation, the project established functional and
performance baselines for mobile robots, identified technological deficiencies, and
helped to define the AI research agenda in such areas as planning, vision, and natural
language processing [Flynn, 1985].
_________________________________________________________________
Page - 10
From 1973 to 1981, Hans Moravec led the Stanford Cart project at the Stanford
University AI Lab, exploring navigation and obstacle avoidance issues using a
sophisticated stereo vision system [Moravec, 1983] The Cart's single TV camera was
moved to each of 9 different positions atop its simple mobility base, and the resulting
images were processed by the offboard KL-10 mainframe. Feature extraction and
correlation between images allowed reconstruction of a model of the 3-D scene, which
3 was used to plan an obstacle-free path to the destination. The system was incredibly
slow, taking up to 15 minutes to make each one-meter move. Moravec moved to
Carnegie Mellon University (CMU) in 1981 and continued his work on the smaller
CMU Rover [Moravec, 1983] indoor platform. CMU became a major leader in mobile
robot research during the 1980s, with its Navlab vehicle as the focus for much of the
work [Thorpe, 1990].
A number of other research-oriented mobile robot development efforts (e.g., the
French HILARE project [Giralt, 1983]) that were undertaken in the late 1970s and
early 1980s are described in [Klafter, 1988].
The task of creating a UGV has previously been undertaken by two groups of our
institute:
1)
Group 455, 7th Batch
2)
Group 455, 10th Batch
GROUP 455, 7TH BATCH
This group created an UNMANNED INTELLIGENT NAVIGATION CAR (UINC)

with a microprocessor board mounted on-board. The main program was loaded into
their UINC through a floppy disk. User was able to give new coordinates to the car to
transverse to using a monitor and a keyboard. The car would then reach the desired
_________________________________________________________________
Page - 11
destination. Obstacle detection was implemented using IR sensor with a range of 2.5
meters.
GROUP 455, 10TH BATCH
This group built on the previous batchs work. They removed the microprocessor
board and made the vehicle microcontroller based. They also discarded the use of
heavy monitor for display with a liquid crystal display and used a keypad instead of a
keyboard to input data to the vehicle. Hence it was no longer necessary to use the
monitor and keyboard every time new coordinates were to be entered.
1.3
OUR SOLUTION
Our solution is different from other two solutions stated above in terms of both
hardware and software. In our project the desktop PC will serve as the master
controller of the system and will display the GUI as well as the live video of front
view path for optimum user convenience, through which the user will monitor the
vehicle. Our vehicle will have two modes of operation.
a) Standalone Mode
b) Remotely operated Vehicle (ROVs) Mode
In this mode UGV will auto-drive on a pre-defined path with the help of preprogrammed map and target detection capability induced through image processing.
During this mode operator will be able to track the UGV on PC monitor.
In the remote controlled operation mode UGV will be operated by a remote user
controlling the car on remote PC. The transmission of data to UGV via wireless means
will be achieved by using ZIGBEE communication protocol because primarily the
operational frequency range of this protocol access ISM frequency band which is free
to access (license free) in our country and secondly because of its excellent interface
_________________________________________________________________
Page - 12
capability on embedded side. This frequency range is sufficient to have coverage of

approximately 250 square foot, which is enough to demonstrate the operation.
Figure 1.1: System Diagram of the Project
The prime modifications in our project as compared to other university level UGV
solutions include:
I.
II.
User-friendly Graphical User Interface on PC side.

Combining both purposes of UGV (standalone and remotely controlled).
III.
Real time monitoring and control..
IV.
Embedded solution.
V.
VI.
Feedback Control system (speed).

Overhead camera for real time front view vision.
_________________________________________________________________
Page - 13
SECTION A
HARDWARE OF UGV
This sections contains description of the hardware related issues

associated with the UGV
a. Mechanical Assembly
b. Electronic Hardware
_________________________________________________________________
Page - 14
CHAPTER 2
MECHANICAL
ASSEMBLY
This chapter contains details about the mechanical assembly of our UGV.
CONTENTS:
a. Speed Feedback Mechanism
b. Protection mechanisms
_________________________________________________________________
2.1
Page - 15
SALIENT FEATURES
The mechanical assembly of the vehicle includes;
A front PMDC motor for direction control.
Rear motor PMDC for speed control.
Opto-coupler/disc assembly for speed sensing, mounted on the vehicles axel.
Tires for motion with traction.
Gears for coupling motor torque to wheels.
On-board video camera relaying live feed to PC.
Battery-holding assembly.
Bumper at the front
Figure 2.1: Sketch of UGV
_________________________________________________________________
2.1.1
Page - 16
UGV SPEED CONTROL
For UGV speed control, a PMDC motor has been used. Its speed is adjusted through
PWM, with H-bridge driver circuitry for bidirectional control. It is a light motor used
to ensure light weight of overall UGV. The weight of this motor is about 160 grams.
This motor is capable of supporting loads of up to 1.5 kg.
Figure 2.2: Speed motor control circuit
2.1.2
UGV DIRECTION CONTROL
For UGV direction control, a PMDC motor has been used. Tri-State position
controlling has been implemented.
The possible states are mean position (0 w.r.t vehicle body), maximum left (45 w.r.t
vehicle body) and maximum right (-45 w.r.t vehicle body).
_________________________________________________________________
Page - 17
Figure 2.3: Position Motor Control Circuit
2.1.3
SPEED SENSOR
Speed sensing accomplished through optocoupler/disc assembly.

As can be seen in figure 2.2, an optocoupler consists of LED photo-transistor pair. If
there is no hindrance between them, then the light radiated by the LED reaches the
phototransistor, driving it into saturation, level adjusted by adjusting resistor values. In
this case, the transistor is switched on and the voltage across it is approximately 0.6,
which is read low by the microcontroller. When there is a hindrance between them,
then the path for radiation is broken, the phototransistor is turned off, and voltage
appears across its terminals.
To create hindrance, a disc with 2 holes was created. When the hole is between the
sender and receiver, then the voltage is low. When hole is not there, then the
obstruction causes the voltage across its terminals to be pulled to 4.4 V and read high
by the controller.
_________________________________________________________________
Page - 18
The disc has been mounted on the axel. Optocoupler was preferred over
Tachogenerator and Hall Effect generator due to
Ease of installation
Ease of implementation with digital controller
Figure 2.2: Optocoupler IC
The encoder disc used is highly symmetric with 2 holes at 180 with respect to one
another.
2.1.4
POWER SUPPLY
The power supply (AA CELLS) have been mounted on the rear side of the vehicle
attached by use of strong adhesive. The weight of the cells was approximately 300
grams.
A separated 9 V battery was also required for the video camera.
_________________________________________________________________
2.1.5
Page - 19
VIDEO CAMERA
The video camera for video sensory input to the PC has been mounted firmly at the
front end of the vehicle so that it may provide live video feed to the PC of the objects
in front.
2.1.6
BUMPER
A bumper has been installed in the front to provide stability to the vehicle and balance
its weight as its rear end was considerably heavier than its front owing to its power
supply being in the back. This bumper also prevents the vehicle from incurring any
damage to the circuitry, vehicle body, motor and camera as the impact of the collision
is sustained by the bumper. The bumper was tested at full speed of unity duty cycle
(2.6 m/s). No damage was incurred on the vehicle.
2.1.7
CAR CASING
For more protection and safety, the upper shielding hard plastic body casing was used
and allowed us to fix camera at a very suitable location, i.e. top front position of car.
Like Bumper the upper shield Casing was also tied with screws to provide balance,
stability and uniform weight across the body of vehicle.
_________________________________________________________________
Page - 20
CHAPTER 3
ELECTRONIC
HARDWARE
This chapter contains details about the electronics involved in our project.
The topics include
CONTENTS:
a.
b.
c.
d.
e.
PC side electronics
Vehicle side electronics
PC side power supply
Vehicle side power supply
Power supply considerations
_________________________________________________________________
3.1
Page - 21
PC SIDE ELECTRONICS
The electronic circuitry on the PC side is solely that of a transmitter. The PC

communicates with the vehicle microcontroller serially through Xbee transceiver in
the air interface. As the Xbee is based on Zigbee protocol which is based on TTL logic
levels, hence it cannot be directly connected to the PCs serial port. This is because in
RS-232 standard, a logic 1 is represented by -3 to -25 V while a 0 bit is +3 to +25 V
with -3 to +3 V undefined. Max 232 IC is used to consist of Xbee transceiver
interfaced with the serial port of the PC through a max 232 IC. The MAX232 converts
from RS232 voltage levels to TTL voltage levels and vice versa. One advantage of the
MAX232 chip is that it uses a +5 V power source. The MAX232 has two sets of line
drivers for transferring and receiving data.
3.2
VEHICLE SIDE ELECTRONICS
3.2.1
OVERVIEW
The UGV electronics may be categorically divided into
Voltage regulators
Transceiver Circuitry
Front Motor Driver Circuitry
Rear Motor Driver Circuitry
Feedback sensor interfacing
The schematic diagram of the vehicle side electronics is shown below:
_________________________________________________________________
Page - 22
Figure 3.1: Vehicle Side Schematic
3.2.2
VOLTAGE REGULATORS
First off, the 12-15 V from the vehicle batteries have to be regulated and stepped down
to useable levels. The 2 useable levels are 8V for motors and 3.3 V for the UGV
circuitry,
Figure 3.2: LM317 Adjustable Positive Voltage Regulator
_________________________________________________________________
Page - 23
Hence for this purpose, two LM317; adjustable positive voltage regulator ICs have
been used. The output of the LM317 is;
(3.1)
Values of R2 and R1 are selected to generate 3.3 V from one and 8 V from the other
regulator.
TRANSCEIVER CIRCUITRY:
3.2.3
On the vehicle side, the vehicle receives serial transmission from the PC side Xbee
through a complementary vehicle side Xbee transceiver. This transceiver is interfaced
directly with the vehicle side AVR microcontroller which receives this data serially,
and takes action based on this data.
3.2.4
MOTOR DRIVER CIRCUITRY:
The AVR microcontroller in turn, is connected to L239D, a quad H-bridge motor

driver circuitry, two of which are used. First is for UGV speed controlling motor while
the second is for vehicle direction controlling motor. Both the driving circuits are Hbridge. An H-bridge driver circuitry provides for bidirectional control through a
unidirectional supply.
3.2.4.1
REAR MOTOR DRIVER CIRCUITRY:
The controlling of speed is through PWM that is set by the user through data
transmitted from the PC. The speed control motor is an 8 V PMDC motor. PB3 and
PB4 of the AVR microcontroller are dedicated for controlling the speed of the vehicle
by providing the actuating signals to the rear motor driver circuitry.
The IC L293D has 4 H-bridges. The H-bridge principle is illustrated below;
_________________________________________________________________
Page - 24
Figure 3.3: Transistor level circuitry modeling for single H-bridge package driving speed motor
There are 4 possible cases as shown in the following table;

POSSIBLE
OUTCOME
STATES
PB3
PB4
Low
Low
As both PB3 and PB4 are low, hence all 4 transistors are in cut-off,
and motor remains inactive, consequently, vehicle remains inactive
High
Low
High PB3 drives Q1 and Q3 into saturation, thereby actuating the

motor and the vehicle moves in forward direction. Q2 and Q4
remain cutoff due to low PB3
Low
High
High PB4 drives Q2 and Q4 into saturation, reversal of motor supply

takes place and the vehicle moves in reverse direction. Q1 and Q3
remain cutoff due to low PB3
High
High
All four transistors are driven into saturation. Hence 8V supply is

shorted to ground. This state must be prevented
Table 3.1: Possible conditions of states existing for H-bridge and their consequences
_________________________________________________________________
Page - 25
Now using the logic defined above, the microcontroller, upon receiving command to
move vehicle in forward direction, sends continuous pulses to PB3. Hence the vehicle
starts moving in forward direction. The duty cycle of these pulses controls the vehicle
speed. This may also be set by the user.
On receiving command to move vehicle in reverse direction, the microcontroller sends
continuous pulses to PB4. Hence the vehicle starts to move in reverse direction.
On receiving command to stop the vehicle, the microcontroller set both PB3 and PB4
low. Hence the vehicle stops moving.
Note that maximum speed in either direction is attained through unity duty cycle.
Also, the condition where both PB3 and PB4 become active is avoided to prevent
damage to the circuitry.
3.2.4.2
FRONT MOTOR DRIVER CIRCUITRY:
The motor for UGV direction control is also an 8 V PMDC motor interfaced to the
controller through the above said H-bridge. The circuitry is an exact replica and is
shown below:
Figure 3.4:
Transistor level circuitry modeling for single H-bridge package driving direction motor
_________________________________________________________________

Page - 26
Logically, 4 conditions are possible;

POSSIBLE
OUTCOME
STATES
PB1
PB2
Low
Low
As both PB1 and PB2 are low, hence all 4 transistors are in cut-off,
and motor remains inactive, consequently, tires maintain 0
orientation
High
Low
High PB1 drives Q1 and Q3 into saturation, thereby actuating the

motor and the wheels turn in left direction. Q2 and Q4 remain cutoff
due to low PB2
Low
High
High PB2 drives Q2 and Q4 into saturation, reversal of motor supply

takes place and the wheels turn in right direction. Q1 and Q3 remain
cutoff due to low PB1
High
High
All four transistors are driven into saturation. Hence 8V supply is

shorted to ground. This state must be prevented
Table 3.2: Possible conditions of states existing for H-bridge and their consequences
On receiving command from PC to maintain 0 orientation of the wheels, the

microcontroller sets both PB1 and PB2 low. The motor becomes inactive and the
vehicle orientation remains at 0 with respect to the vehicle body.
On receiving command from PC to turn left, the microcontroller resets RB2 and sets
the port pin PB1. This causes the motor to be actuated in one direction; the wheels
start to turn left until limited by the vehicle body. At this point, the wheels make an
angle of about 45 with respect to the vehicle body.
On receiving command from PC to turn right, the microcontroller resets RB1 and sets
RB2. This causes the motor to be actuated in reverse direction; the wheels start to turn
right until limited by the vehicle body. At this point, the wheels make an angle of
about -45 with respect to the vehicle body.
_________________________________________________________________
3.2.4.3
Page - 27
FEEDBACK SENSOR INTERFACE:
Vehicle speed estimation is done through a sensor mounted on the UGVs axel. The
sensor is based on optocoupler/disc assembly. There are 2 holes in the disc. Hence on
one complete rotation of the wheels, 2 pulses are obtained. This information is fed
back directly to the microcontroller which transmits this information serially to the PC
through which the PC calculates the vehicles speed and estimates the vehicles
position, thereby providing for effective tracking.
The circuit for sensor interfacing is shown below;
Figure 3.5: Optocoupler modeling using LED and phototransistor
The optocoupler assembly is based on a phototransistor-LED pair. The LED is

transmitting continuously to the phototransistor. If this light were to pass to the
phototransistor, then it would drive the phototransistor into saturation. This would
cause PD2 to become low. If there were a hindrance between them, then it would
block the path of light thereby keeping the phototransistor in cutoff. This causes PD2
pin of AVR to become high.
Hence the rotating disc with two holes generates pulses at the PD2 pin which may be
used to estimate the vehicle speed and when coupled with vehicle direction
_________________________________________________________________
Page - 28
information, this may be used for tracking the vehicle and imparting the intelligence of
localization to it whereby it is aware of its location.
3.3
PC SIDE POWER SUPPLY
The PCs circuit is supplied energy through a power supply. The voltages required are
+12V DC for the analog video receiver, which is supplied by its adapter from AC line.
The voltages required for the circuit are about 5 V and any supply from 5V to 12V
can be used.
3.4
VEHICLE SIDE POWER SUPPLY
The vehicles circuit is supplied energy through on-board power supply constructed
through 10 1.5 V AA cells connected in series to get voltages of about 13.8 Vmax. As
the voltages required are:
8 V for motors.
3.3 V for controller and Xbee transceiver.
Hence, two LM317 ICs were used. They are adjustable positive voltage regulators.
Their output is adjusted according to requirement.
3.5
ELECTRICAL SPECIFICATIONS
The electrical specifications required for the UGV are as follows

3.5.1
CAMERA:
The analog camera mounted on the vehicle operates between 8 and 9 volts while
consuming 0.4 amp.
_________________________________________________________________
3.5.2
Page - 29
MOTORS:
Both front and rear motors require operation at 8 V for reliable and consistent
performance. The front motor consumes 0 power while the vehicle is moving straight
but requires current of approx 0.3-0.4 amperes at the rated voltage when turning.
The rear motor consumes 0 power at stand-still but draws current of approx 0.2-0.3
amperes at the rated voltage when vehicle is moving at full speed.
3.5.3
MICROCONTROLLER:
The AVR microcontroller implementing the decisions relayed by the PC to the UGV
requires about 0.1 ampere when operating at 3.3V.
3.5.4
TRANSCEIVER:
The Xbee transceiver doing the bulk of the communication between the vehicle and
the remote PC requires a well-regulated supply of 3.3 V at 0.3 A.
OVERALL UGV REQUIREMENT:
The overall current required by the UGV circuitry besides the camera is 1.1A. Hence
cells were selected with unit cell capacity of 2A. A separate 9-V battery was attached
to fulfill the power requirements of the camera.
3.6
3.6.1
POWER SUPPLY CONSIDERATIONS

WEIGHT
The weight of the power source was a prime concern in our UGV. All mobile robots
should be as light as possible to avoid expending unnecessary energy. A larger weight
would lead to increased load on the motor and consequently greater energy
expenditure. Hence lightest economically feasible solution was implemented and 10
AA 1.5 V batteries were connected in series.
_________________________________________________________________
3.6.2
Page - 30
CAPACITY
Source capacity is a measure of its energy storing capability. A large capacity would
be required to entail longer running of UGV. The rechargeable batteries used provide
the UGV a running of approximately 20 minutes.
Figure 3.3: Battery Discharge Curve
From the figure 3.3, it is evident by graph that discharging of rechargeable cells takes
place in timely manner. Initially the excessive voltage stored drops quickly with
respect to time up to the rated level, after which the discharge rate is comparatively
much slower. But at a certain level of voltage when chemical ionization is weakened
quite enough, the cell starts to discharge rapidly. At this level the cell should be
recharged otherwise continual in this way would cause reversing of polarities or
negative charging and consequently damaging the cell. Thus, more the capacity of
cell, larger would be the region of low discharge rate.
3.6.3
LIFETIME
Lifetime is a measure of useful life of a power source. Our batteries are rechargeable
hence they may be used for extensive periods although proper care must be ensured.
Overcharging, and charging without completely draining reduces the battery life.
3.6.4
RECHARGING
Reusability of a power source is a prime concern in UGVs. Else a new power source
would have to be purchased after every running. Hence rechargeable cells were
selected to make the running economically feasible.
_________________________________________________________________
3.6.5
Page - 31
COST
Cost of power source is also a prime concern. In case replacement is eminent, its
replacement has to be economically feasible. The rechargeable cells were Rs.140 a
piece. Considering life and rechargeability, this was a very viable solution.
3.6.6
SAFETY
Voltage spikes and short-circuiting of the power source can easily damage the ICs
and their associated circuitry. Their protection was implemented through voltage
regulators. They have large current handling capability and incase of spikes, maintain
output constant. In case of short-circuiting, only the regulators would be damaged
while the rest of the circuitry would remain intact.
3.6.7
WARM-UP
Some voltage sources have a warm-up time, a certain period after turning on when the
power supply becomes useable. Our power source has no warm-up time.
3.6.8
AVAILABILITY:
Availability of power source is a prime concern. If worse comes to worst, the power
source may have to be replaced and if that were the case, then their ready availability
is an issue of uttermost importance. These rechargeable cells are available at most
electronic goods items while non-rechargeable ones are available at almost all
convenient stores.
3.6.9
SOURCING CAPABILITY:
The power supply should be capable of generating the desired current. The desired
current is about 1.1 A, and the unit cell sourcing capability of the selected battery is
2A.
_________________________________________________________________
Page - 32
SECTION B
SOFTWARE OF UGV
Next comes, the software of the UGV. Once the hardware was finished,
the basis of modes of operation of UGV were defined, structured and
programmed through software. Visual Basic 6 and MATLAB have been
used on the PC side whereas the microcontroller programming has been
done in AVRSTUDIO4 Assembly Language.
a.
b.
c.
d.
Communication
Key Press Handling
Image acquisition toolbox and Image Acquisition
Image Processing Toolbox and Image Processing
_________________________________________________________________
Page - 33
CHAPTER 4
COMMUNICATION
PROTOCOL
This chapter contains details about the manner in which the PC and the
AVR microcontroller communicate with one another.
CONTENTS:
a. Comparison between various protocols standards
b. Packet Transfer Protocol
_________________________________________________________________
4.1
Page - 34
DEFINITION
Wireless communication is the transfer of information over a distance without the use
of electrical conductors or "wires". The distances involved may be short (a few meters
as in television remote control) or very long (thousands or even millions of kilometers
for radio communications). Wireless operations permits services, such as long range
communications, that are impossible or impractical to implement with the use of
wires.. The communication protocol is the set of defined rules by which the two
devices (PC and UGV) communicate with one another.
4.2
COMPARISON BETWEEN VARIOUS STANDARDS
Following is a comparison between some of the available protocols.
Table 4-1: Comparison of various available protocols
processing
Of all of these, the only feasible alternatives were

1. Zigbee
2. Bluetooth
_________________________________________________________________
Page - 35
This is because the rest require commercial licensing.

Zigbee was preferred due to
1. Longer range
2. Easy embedded system implementation
3. Advanced technology
4.3
ZIGBEE PROTOCOL IMPLEMENTATION
Zigbee protocol was implemented using Xbee PRO transceiver. It is a full duplexed
transceiver operating at 2.4 GHz frequency with a 300 ft range. The baud rate set is
9600 bps. The power consumption in this device is about 0.66 W with a rated current
of 0.2 A flowing at 3.3 V.
Figure 4-1: XBee Pro
processing
This is a serial transceiver with communication being implemented in a point-to-point

manner as there are only two transceivers.
The IC has an antenna attached to it.
_________________________________________________________________
4.4
Page - 36
COMMUNICATION ALGORITHM
Electronic communications devices that operate in environments with a high level of

electromagnetic noise require special consideration and testing to ensure the
continuous delivery of uncorrupted data. Communication devices are susceptible to
data interruption and corruption in industrial, automotive, telecommunication, medical
and test lab environments, to name just a few. Demonstrating compliance with
international immunity testing standards helps to ensure robust communications in
noisy electromagnetic environments.
This protocol provides key recommendations for implementing serial communication
for wireless transfer in the form of packets. The data packet sent by the remote PC to
the vehicle microcontroller is given below and that from the controller to the PC,
follow the same algorithm given below;
Figure 4-2: Data packet sent by the PC to the microcontroller
rprocessing
4.4.1
START BYTE
Communication is initiated with start byte transmission. XX was selected as the start
byte. This is used to identify start of packet transmission.
4.4.2
COMMAND BYTE
The second byte transmitted is the command byte. It indicates the target parameter.
The target parameter may be direction motor left turning, direction motor right
turning, and setting speed for speed motor, forward motion, and reverse motion.
_________________________________________________________________
4.4.3
Page - 37
VALUE BYTE
The third byte to be transmitted is the value byte. This is the value to be set for the
above parameter. For example, set PWM speed etc. This indicates how much the
magnitude is, for selected command.
4.4.4
END BYTE
The End Byte is the final byte to be transmitted. It is to signal end of transmission. In
case the start and stop bytes dont match, then the entire packet is retransmitted. This
is a measure to ensure synchronization in communication.
4.4.5
CHECKSUM BYTE
The sum of the aforementioned 4 bytes is transmitted as the 4th byte to ensure errorfree communication with utter disregard to carry flag. The controller then sums these 4
bytes. In case the two are unequal, then an error has occurred in the transmission.
There are many advantages for sending serial data in the form of packets. The reason
for which we used packet transfer protocol was to avoid any sort of distortion that
would come during communication which could be either because of voltage level
fluctuations sor noise. Thus after organizing the packet the computer first checks the
packet to assure correct arrival of packet in serial buffer of PC by checking the
CHECKSUM byte. After transmitting the packet to microcontroller (AVR) in car, the
AVR checks the values of bytes received and compare it with CHECKSUM byte
value. If the value will not match with the one sent by PC, then AVR will discard the
packet and will not perform any action corresponding any byte. AVR will send the
received byte value and error code to request the PC for resending of same packet. In
that case computer will send the packet again to AVR. With this packet transfer
protocol we terminated communication distortion and losses to 100%.
_________________________________________________________________
Page - 38
CHAPTER 5
PC SIDE SOFTWARE
This chapter contains details about the algorithm of PC side software which sends
signal corresponding to the key pressed and applicable logic. Through keypad control,
the user may define direction of motion. Beside this the calculation of feedback and
programming of autonomous mode of UGV are also its elements.
CONTENTS:
a.
b.
c.
d.
e.
f.
Communication with MSCOMM

Speed Calculation
Key Press Handling
Building of Pre-Defined Map
Calling MATLAB from VB6
Graphical User Interface (GUI)
_________________________________________________________________
Page - 39
COMMUNICATION WITH MSCOMM
5.1
The MSComm control provides serial communications for your application by

allowing the transmission and reception of data through a serial port.
The
MSComm
control
provides
the
following
two
ways
for
handling
communications:
Event-driven communications is a very powerful method for handling serial
port interactions. In many situations you want to be notified the moment an
event takes place, such as when a character arrives or a change occurs in the
Carrier Detect (CD) or Request To Send (RTS) lines. In such cases, use the
MSComm control's OnComm event to trap and handle these communications
events. The OnComm event also detects and handles communications errors.
For a list of all possible events and communications errors, see the
CommEvent property.
You can also poll for events and errors by checking the value of the
CommEvent property after each critical function of your program. This may
be preferable if your application is small and self-contained. For example, if
you are writing a simple phone dialer, it may not make sense to generate an
event after receiving every character, because the only characters you plan to
receive are the OK response from the modem.
Each MSComm control you use corresponds to one serial port. If you need to access
more than one serial port in your application, you must use more than one MSComm
control. The port address and interrupt address can be changed from the Windows
Control Panel.
Although the MSComm control has many important properties, there are a few that
one should be familiar with first, which are as follows:
_________________________________________________________________
Page - 40
Table 5.1: Some Properties of MSCOMM
PROPERTIES
DESCRIPTION
CommPort
Sets and returns the communications port number.
Settings
Sets and returns the baud rate, parity, data bits, and stop bits as a
string.
PortOpen
Sets & returns state of a communications port. Also opens and

closes a port.
Input
Returns and removes characters from the receive buffer.
Output
Writes a string of characters to the transmit buffer.
Using MSCOMM.ocx ActiveX control, we used the default settings of COMM Port1,
i.e. 9600 Baud rate, No Parity, 8 data bits and 1 Stop bit. Then finally, we
implemented our communication algorithm explained in Section4.4, in Visual Basic 6
for PC side using various properties of MSCOMM ActiveX component.
5.2
SPEED CALCULATION
Figure 5.1: Linear velocity and angular velocity are related by equation of rolling.
If friction is neglected as in case of our project, for rolling with sliding, the distance
covered in translation is equal to the distance covered by a point on the rim of the
body in rotation. This means that:
(5.1)
_________________________________________________________________
Page - 41
RPM of the vehicle is 60 times the RPS of the vehicle. RPS is inverse of time taken by
wheels to complete one revolution.
As two pulses are attained in one revolution, hence the time elapsed between two
consecutive high-to-low transitions of feedback pulses multiplied by two is equal to
inverse of RPS.
The count of the timer multiplied by time of each count gives elapsed time. Scaling
has been done so the 1 count of the timer represents 8.68 msec. The interrupt is
enabled every 100 msec and then disabled for next 100 msec. Hence the sampling time
has been set to 100 msec and the sample rate is 10 Hz.
Hence the formula for speed calculation of UGV becomes:
(5.2)
5.3
KEY PRESS HANDLING
Key scanning software was needed to operate UGV in teleoperated mode for which
first we found the key codes of Direction keys and C button key.
Figure 5.2: C & Direction Keys
_________________________________________________________________
Page - 42
UP KEY: Rear motor will actuate in forward direction. Direction motor is dependent
on LEFT and RIGHT keys. If the latter two have not been pressed or have been
released, then the motor remains unactuated and the wheels have a straight orientation
with respect to the vehicle body.
DOWN KEY: Rear motor will actuate in reverse direction. Direction motor is
dependent on LEFT and RIGHT keys. If the latter two have not been pressed or
have been released, then the motor remains unactuated and the wheels have a straight
orientation with respect to the vehicle body.
LEFT KEY: Direction motor will actuate in left direction. Speed motor dependent on
UP and DOWN keys. If the latter two have not been pressed or have been released,
then the speed motor remains unactuated and the wheels have a +45 orientation with
respect to the vehicle body.
RIGHT KEY: Direction motor will actuate in right direction. Speed motor dependent
on UP and DOWN keys. If the latter two have not been pressed or have been
released, then the speed motor remains unactuated and the wheels have a -45
Code:
Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
Label2 = KeyCode
Select Case KeyCode
Case vbKeyUp:
Down_Disabled = False
Up_Disabled = False
5.3.1
SIMULATNEOUS KEY PRESS LOGIC:
During key scanning code development, it was kept considered to take decisions on
the consequences of simultaneous multiple keys press. Thus finally in the code
developed, following logical decisions were used for possible multiple direction keys
press:
_________________________________________________________________
Page - 43
UP key = Forward Throttle
DOWN key = Reverse
LEFT key = Left Turn
RIGHT key = Right Turn
UP key + DOWN key = Preference to first key pressed

LEFT key + RIGHT key = Preference to first key pressed
UP key + LEFT key = North West Curved motion (Left accelerate)
UP key + RIGHT key = North East Curved motion (Right Accelerate)
DOWN key + LEFT key = South West Curved motion (Left Reverse)
DOWN key + RIGHT key = South East Curved motion (Right Reverse)
UP key + LEFT key + DOWN key = Left turn + first key pressed from rest of two
UP key + RIGHT key + DOWN key = Right turn + first key pressed from rest of two
UP key + LEFT key + RIGHT key = Forward + first key pressed from rest of two
DOWN key + LEFT key + RIGHT key = Reverse + first key pressed from rest of two
If all four direction keys pressed then:

Preference to first key pressed from (LEFT key/RIGHT key) & (UP key/DOWN key)
In this way we wrote the algorithm which was continuously scanning the key press by
respective key code and taking decision on behalf of above explained logic. The
Visual Basic 6 Key codes for the used keys are:
The following table, table 5.2 shows the VB6 key codes of corresponding keys used in
the key scanning software of UGV,
_________________________________________________________________
Page - 44
Table 5.2: VB Key Codes of corresponding used keys of keyboard
KEYS
CODE
Key C
67
Key Left
37
Key Up
38
Key Right
39
Key Down
40
Key Plus
107
Key Minus
109
Plus Key was used to increase the Speed.

Minus key was used to decrease the speed.
C key for capturing screenshots.
5.4
BUILDING OF PRE-DEFINED MAP
The predefined map building was the foundation of Autonomous mode. For coding the
pre-defined map, we first designed our map according to the criteria of destinations.
We chose two targets for our pre-defined map.
1. Red target
2. Green target
_________________________________________________________________
Page - 45
Instead of making different maps for both targets we constructed one map for red
target and reserved its half part as the map for green target, as can be seen from
figure.5.3. The distance from green mark to red mark is considered as one map for red
flag destination, whiles the complete track distance starting from green flag as well as
ending at it, is considered as the map for green destination.
Figure 5.3: Pre-Defined Maps
For the definition of map in terms of coding the map was divided into 10 segments. As
shown in figure segments 1, 5, 6, 10 are equal, bending segments 2,4,7,9 are equal and
similarly segments 3, 8 are equal. Length of segments 3,8 is half of length of segments
1,5,6,10.
Figure 5.4: Segmented Map
On curved paths, the vehicles speed is reduced by sending decimal 175. This is to
minimize the radius of curvature of the vehicle on turns. The radius at this speed has
_________________________________________________________________
Page - 46
been found to be 85 cm. The vehicle may only take sharp right and left turns in
autonomous mode. Thus, finally by speed calculation, we gave length value to all
straight segments of map and as per requirement of map we put (radius/4) value for
curved paths i.e. for 90 rotations. In this way both maps were designed.
5.5
CALLING MATLAB FROM VB6
For implementing the Artificial Intelligence as verification for the arrival of

destination we used image processing and wrote a colour segmentation algorithm in
Matlab. But as an application we found it odd to run two different programs for our
project, so we made meta file or M-file of that function from Matlab and ran it from
VB6. We executed our M-file function from a Visual Basic client application through
a COM interface. Following is the code for running M-file from VB6.
Code:
Private Sub init_Matlab()
Set Matlab = CreateObject("MatLab.Application")
MatlabCommand = "cd '" & CurDir & "'"
MatlabResult = Matlab.Execute(MatlabCommand)
In this way we made VB6 as one platform for our project application through
execution of one VB6 exe file.
5.6
GRAPHICAL USER INTERFACE (GUI)
The Graphical User Interface of UGV is developed in Visual Basic 6 IDE because of
ease of application development. The main GUI of application is shown in figure5.5 in
which user can select the mode of operation. On selection of either mode the
corresponding window will open showing the particular interface of that mode.
_________________________________________________________________
Page - 47
Figure 5.5: Main GUI window
From figure you can see the main GUI window, in which two command buttons are
visible by which user can select the mode of operation for UGV. The Enable Car
Vision button will allow the user to watch live video streaming from the camera
mounted on UGV. The white textbox in main window shows the number of bytes in
stack to be transferred first before sending the new byte. For proper communication,
this value should be Zero. The grey strip visible in main window is actually the
message label which will inform user the status of operation in autonomous mode.
5.6.1
NAVIGATION MODE WINDOW
In figure 5.6, you can see the left box in which the snapshot taken by user by pressing
C button of keyboard, from live video will be displayed as well as stored. The
_________________________________________________________________
Page - 48
speedometer on screen will show the speed of UGV. The screen itself explains the
operation guide for user, how to drive in Navigation mode.
Figure 5.6: UGV Navigation Mode GUI window
5.6.2
AUTONOMOUS MODE WINDOW
The autonomous mode GUI window is shown in figure 5.7. In this window user can
select either of the available map by selecting through the option button, e.g. Red
target or green target. For the ease of use, with the map, screenshot of destination
point is also displayed above the map, to aid user in the selection of map.
Once the user selects the map, there is a start button for user to start the operation of
UGV in its autonomous mode and auto drive itself until the arrival destination point.
Since, as it is mentioned earlier that the maps are divided into segments, the
information of UGV about current status will be displayed on grey label.
_________________________________________________________________
Page - 49
Figure 5.7: UGV Autonomous Mode GUI window
The rest of the available labels shown in above figure are following purposes.
label displaying label4 in figure 5.5 for : Threshold Value
label displaying label5 in figure 5.5 for : Hard code Red value
label displaying label6 in figure 5.5 for : Hard code Green value
label displaying label7 in figure 5.5 for : Hard code Blue value
label high-lightened by orange oval for: Showing calculated speed
label high-lightened by yellow oval for: Showing feedback speed
At the moment the values shown in figure 5.7 are garbage and not the operating value.
_________________________________________________________________
Page - 50
CHAPTER 6
EMBEDDED SIDE
SOFTWARE
a) PWM generation
b) Speed Motor Actuation
c) Position motor Actuation
d) Speed Feedback
_________________________________________________________________
6.1
Page - 51
INTRODUCTION TO ATMEGA8
The AVR core combines a rich instruction set with 32 general purpose working
registers. All the 32 registers are directly connected to the Arithmetic Logic Unit
(ALU), allowing two independent registers to be accessed in one single instruction
executed in one clock cycle. The resulting architecture is more code efficient while
achieving throughputs up to ten times faster than conventional CISC microcontrollers.
The member of this family which we used in our project is Atmega8.
The ATmega8 is a low-power CMOS 8-bit microcontroller based on the AVR RISC
architecture. By executing powerful instructions in a single clock cycle, the ATmega8
achieves throughputs approaching 1 MIPS per MHz, allowing the system designer to
optimize power consumption versus processing speed.
The ATmega8 provides the following features: 8K bytes of In-System Programmable

Flash with Read-While-Write capabilities, 512 bytes of EEPROM, 1K byte of SRAM,
23 general purpose I/O lines, 32 general purpose working registers, three flexible
Timer/Counters with compare modes, internal and external interrupts, a serial
programmable USART, a byte oriented Two- wire Serial Interface, a 6-channel ADC
(eight channels in TQFP and QFN/MLF packages) with 10-bit accuracy, a
programmable Watchdog Timer with Internal Oscillator, an SPI serial port, and five
software selectable power saving modes. The Idle mode stops the CPU while allowing
the SRAM, Timer/Counters, SPI port, and interrupt system to continue functioning.
The Power- down mode saves the register contents but freezes the Oscillator, disabling
all other chip functions until the next Interrupt or Hardware Reset. In Power-save
mode, the asynchronous timer continues to run, allowing the user to maintain a timer
base while the rest of the device is sleeping. The ADC Noise Reduction mode stops
the CPU and all I/O modules except asynchronous timer and ADC, to minimize
switching noise during ADC conversions. In Standby mode, the crystal/resonator
_________________________________________________________________
Page - 52
Oscillator is running while the rest of the device is sleeping. This allows very fast
start-up combined with low-power consumption.
The device is manufactured using Atmels high density non-volatile memory
technology. The Flash Program memory can be reprogrammed In-System through an
SPI serial interface, by a conventional non-volatile memory programmer, or by an Onchip boot program running on the AVR core. The boot program can use any interface
to download the application program in the Application Flash memory. Software in
the Boot Flash Section will continue to run while the Application Flash Section is
updated, providing true Read-While-Write operation. By combining an 8-bit RISC
CPU with In-System Self-Programmable Flash on a monolithic chip, the Atmel
ATmega8 is a powerful microcontroller that provides a highly-flexible and costeffective solution to many embedded control applications.
The ATmega8 AVR is supported with a full suite of program and system development
tools, including C compilers, macro assemblers, program debugger/simulators, InCircuit Emulators, and evaluation kits.
6.2 PWM GENERATION

The speed of the vehicle may be set through pulse width modulation. The driving
waveform generated by the controller is controlled through an 8-bit register. Decimal
value of 255 generates maximum speed because of waveform of unity duty cycle
while 0 generates minimum speed with 0 duty cycle.
In atmege8, there is 8 bit timer, which also functions in Fast PWM mode by
configuring some bits of its TCCR2 register (Timer/Counter Control Register). In fast
PWM mode, the counter is incremented until the counter value matches the MAX
value. The counter is then cleared at the following timer clock cycle.
_________________________________________________________________
Page - 53
The fast Pulse Width Modulation or fast PWM mode provides a high frequency PWM
waveform generation option. The fast PWM differs from the other PWM option by its
single slope operation. The counter counts from BOTTOM to MAX then restarts from
BOTTOM. In non-inverting Compare Output mode, the Output Compare (OC2) is
cleared on the Compare Match between TCNT2 and OCR2, and set at BOTTOM. In
inverting Compare Output mode, the output is set on Compare Match and cleared at
BOTTOM. Due to the single-slope operation, the operating frequency of the fast
PWM mode can be twice as high as the phase correct PWM mode that uses dual-slope
operation. This high frequency makes the fast PWM mode well suited for motor
control. High frequency allows physically small sized external components (coils,
capacitors), and therefore reduces total system cost. In fast PWM mode, the counter is
incremented until the counter value matches the MAX value. The counter is then
cleared at the following timer clock cycle. The PWM frequency for the output can be
calculated by the following equation:
(6.1)
The N variable represents the prescale factor (1, 8, 32, 64, 128, 256, or 1024). The
value of prescale factor using in our project is 8.
6.3 SPEED MOTOR ACTUATION

The fast PWM mode of controller is used for controlling motor speed. By using the
fast PWM mode rear motor can be rotated in clock wise direction and anticlockwise
direction by using two bits from which motor terminals are connected to the
controller. Now suppose, bit A is connected to one terminal of motor and bit B is
connected to other terminal motor then for rotating motor we have following
sequence.
_________________________________________________________________
Page - 54
Figure 6.1: Non inverting & Inverting PWM Concept
For rotating motor in anti clock wise direction we will send 0 to bit B and will apply
non-inverting compare output mode on pin A which will result in the generation of
positive direction PWM because at rising of clocks sawtooth wave, the PWM will
have high logic level, as shown in figure 6.1.
Figure 6.2: Illustration of inverting and non inverting PWM
For rotating motor in clock wise direction we will send 1 to bit B and will apply
inverting compare output mode on pin A which will result in the generation of
negative direction PWM because at rising of clocks sawtooth wave, the PWM will
have low logic level, as shown in figure 6.1.
_________________________________________________________________
Page - 55
6.4 POSITION MOTOR ACTUATION

For position motor the task was relatively simple. The vehicles wheels may have 3
possible orientations with respect to vehicle body: Straight, +45 and -45. Through
keypad control, the user may define direction of motion.
Figure 6.3: Position Actuation Concept
With reference to figure 6.3, for the position motor to be at center we will simply put
0 on both bits 1 & 2, i.e. at its default position. In order to move motor for +45 we
will send 1 on bit1 and 0 on bit2. Similarly for moving motor through -45 we will
send 0 on bit1 and 1 on bit2.
6.5 SPEED FEEDBACK

The encoder disc used is highly symmetric with 2 holes at 180 with respect to one
another. The output of optocoupler is connected to external interrupt pin of AVR.
Each time the hole appears there is rising edge pulse appearance at interrupt pin. With
every interrupt, counter increases and speed is calculated by observing the number of
counts in sample time. The speed in RPM was calculated by formula:
_________________________________________________________________
Page - 56
CHAPTER 7
IMAGE
ACQUISITION
TOOLBOX AND
IMAGE
ACQUISITION
_________________________________________________________________
Page - 57
7.1 INTRODUCTION
Image Acquisition Toolbox lets you acquire images and video directly into
MATLAB and Simulink from PC-compatible imaging hardware. You can detect
hardware automatically, configure hardware properties, preview an acquisition, and
acquire images and video. With support for multiple hardware vendors, you can use a
range of imaging devices, from inexpensive Web cameras or industrial frame grabbers
to high-end scientific cameras that meet low-light, high-speed, and other challenging
requirements.
7.2 KEY FEATURES

Manages device configurations
Provides live video previewing
Acquires static images and continuous video
Enables in-the-loop image processing and analysis
Provides graphical user interface for working with devices
Supports devices for use with MATLAB and Simulink
Supports multiple hardware vendors
7.3 WORKING WITH IMAGE ACQUISITION TOOLBOX

Image Acquisition Toolbox helps you connect to and configure your hardware,
preview the acquisition, and acquire and visualize image data. You can use the toolbox
from the Image Acquisition Tool, the MATLAB command line, or the From Video
Device block within Simulink. This lets you control your image acquisition
parameters and incorporate them into M-scripts, applications built within MATLAB,
or Simulink models.
_________________________________________________________________
7.3.1
Page - 58
CONNECTING TO HARDWARE
Image Acquisition Toolbox automatically detects compatible image and video

acquisition devices. The connection to your devices is encapsulated as an object,
providing an interface for configuration and acquisition. You can create multiple
connection objects for simultaneous acquisition from as many devices as your PC and
imaging hardware support.
7.3.2
CONFIGURING HARDWARE
The toolbox provides a consistent interface across multiple hardware devices and
vendors, simplifying the configuration process. You configure your hardware by using
the Image Acquisition Tool or by modifying the properties of the object associated
with the hardware on the MATLAB command line. The toolbox also supports camera
files from hardware vendors.
You can set base properties that are common to all supported hardware. These
properties can include video format, resolution, region of interest (ROI), and returned
color space. You can also set device-specific properties, such as hue, saturation,
brightness, frame rate, contrast, and video sync, if your device supports these
properties.
7.3.3
PREVIEWING THE ACQUISITION
The Image Acquisition Toolbox video preview window helps you verify and optimize
your acquisition parameters. It instantly reflects any adjustments that you make to
acquisition properties. The Image Acquisition Tool has a built-in preview window,
and you can add one to any application built with MATLAB.
7.3.4
ACQUIRING IMAGE DATA
Image Acquisition Toolbox can continuously acquire image data while you are
processing the acquired data in MATLAB or Simulink. The toolbox automatically
_________________________________________________________________
Page - 59
buffers acquired data into memory, handles memory and buffer management, and
enables acquisition from an ROI. Data can be acquired in a wide range of data types,
including signed or unsigned 8-, 16-, and 32-bit integers and single- or doubleprecision floating point. The toolbox supports any color space provided by the image
acquisition device, such as RGB, YUV, or grayscale. Raw sensor data in a Bayer
pattern can be automatically converted into RGB data. The toolbox supports any frame
rate and video resolution supported by your PC and imaging hardware.
7.4 ADVANCED ACQUISITION FEATURES

Image Acquisition Toolbox supports three trigger types: immediate, manual, and
hardware. Hardware triggers, which are device-specific, let you synchronize your
acquisition to an external signal.
You can log data to disk, memory, or both simultaneously. Image Acquisition
Toolbox lets you:
Log each image frame or log frames at specified intervals
Log data to disk as compressed or uncompressed AVI streams
Extract single images from a video stream and store them in standard formats,
including BMP, JPEG, and TIFF
For advanced sequencing of your acquisition application, you can create callback
functions that are automatically executed whenever events occur, such as acquisition
started or stopped, trigger occurred, and a set number of frames acquired.
_________________________________________________________________
Page - 60
7.5 ANALOG TO DIGITAL IMAGE CONVERSION

Because of the unavailability of wireless digital camera or wireless webcam, we had to
use wireless analog camera to achieve live video feed feature and implement
Autonomous mode and Artificial Intelligence. But the problem was that computers
dont have Analog Video input. Thus, we convert the analog output image into digital
image by feeding the analog output to TV tuner card which served as Frame Grabber
Card. The reason for not using Analog to Digital Video converters was its high cost,
which is why we selected TV tuner card.
Figure 7.1: Analog to Digital Image Conversion
As can be seen in figure 7.1, the wireless camera mounted on the vehicle transmits
video information to the analog receiver. The analog receiver is interfaced with the PC
through the frame grabber card, which converts the analog input to a digital output.
The Image acquisition toolbox of MATLAB also supports the PCI interface therefore
using TV tuner Card was the best economical option. The TV tuner card we used is
PIXEL VIEW BT878P. Following are its features:
Conexant Bt878 chipset.

Video Resolution: 640x480
Video capture Rate: up to 30 frame/second
Single-Chip video capture/TV tuner/FM radio multimedia adapter.
Fully PCI Rev 2.1 compliant and zero wait state PCI burst write.
PCI bus master interface.
Supports NTSC/PAL/SECAM video input.
_________________________________________________________________
Page - 61
Composite / S-Video input and audio input.

Supports Windows 98SE/Me/2000/XP.
Multiple composite, S-Video and 8 pin mini-Din connector
Full TV frequency range for CATV/VHF/UHF.
RGB pixel formats supported on output.
Video capture rate maximum 30 frames/ second.
Video conferencing ready.
Remote control
Important features for us, includes Video capture Rate and Video Resolution. For
good Video processing 30 frames per second is a good choice. The more the frames of
second the less distorted and less blurred image. The importance of resolution was
because the filter we were going to use (imfilter) had the same output array as that of
the original image, thus, at this resolution CPU speed was not affected too much for
the extent of video processing we used.
Suitable adaptors are necessary to convert this digital information into a form (RGB
format) compatible with MATLAB. Matlab video adapter for importing AV digitized
video is winvideo adapter. This adapter converts the video into Matlab usable format,
i.e. in its own colour space model depending upon the hardware support.
7.6
7.6.1
ACCESSING VIDEO SOURCE

ACCESSING AN IMAGE ACQUISITION DEVICE
A video input object represents the connection between MATLAB and an image
acquisition device. To create a video input object, use the VIDEOINPUT function and
indicate what device the object is to be associated with.
% Access an image acquisition device.
vidobj = videoinput('dt', 1, 'RS170')
Acquisition Source(s): VID0, VID1, and VID2 are available.
_________________________________________________________________
Acquisition Parameters:
Status:
7.6.2
Page - 62
'VID0' is the current selected source.

10 frames per trigger using the selected
Waiting for START.
0 frames acquired since starting.
0 frames available for GETDATA.
IDENTIFYING A DEVICE'S VIDEO SOURCE OBJECT
A video source object represents a collection of one or more physical data sources that
are treated as a single entity. For example, one video source object could represent the
three physical connections of an RGB source (red, green, and blue).
The Source property of a video input object provides an array of the device's available
video source objects.
% Access the device's video sources that can be used for acquisition.
sources = vidobj.Source
Display Summary for Video Source Object Array:
Index:
1
2
3
whos sources
Name
sources
SourceName:
'VID0'
'VID1'
'VID2'
Selected:
'on'
'off'
'off'
Size
Bytes
1x3
872
Class
videosource object
Grand total is 47 elements using 872 bytes
7.6.3
SELECTING A VIDEO SOURCE OBJECT FOR ACQUISITION
A video source object can be selected for acquisition by specifying its name.
set(vidobj, 'SelectedSourceName', 'VID2')
% Notice that the corresponding video source has been selected.
sources
Display Summary for Video Source Object Array:
Index:
1
2
3
SourceName:
'VID0'
'VID1'
'VID2'
Selected:
'off'
'off'
'on'
_________________________________________________________________
Page - 63
To obtain the video source object that is currently selected, use the
GETSELECTEDSOURCE function.
selectedsrc = getselectedsource(vidobj)
Display Summary for Video Source Object:
Index:
1
7.7
SourceName:
'VID2'
Selected:
'on'
ACCESSING VIDEO SOURCE OBJECT'S PROPERTIES
Each video source object provides a list of general and device specific properties.
To access a complete list of an object's properties and their current values, use the
GET function with the object.
% Create a video input object.
vidobj = videoinput('winvideo', 1);
% List the video input object's properties and their current values.
get(vidobj)
General Settings:
DeviceID = 1
DiskLogger = []
DiskLoggerFrameCount = 0
EventLog = [1x0 struct]
FrameGrabInterval = 1
FramesAcquired = 0
FramesAvailable = 0
FramesPerTrigger = 10
Logging = off
LoggingMode = memory
Name = RGB24_320x240-winvideo-1
NumberOfBands = 3
Previewing = off
ReturnedColorSpace = rgb
ROIPosition = [0 0 320 240]
Running = off
Tag =
Timeout = 10
Type = videoinput
_________________________________________________________________
Page - 64
UserData = []
VideoFormat = RGB24_320x240
VideoResolution = [320 240]
Callback Function Settings:
ErrorFcn = @imaqcallback
FramesAcquiredFcn = []
FramesAcquiredFcnCount = 0
StartFcn = []
StopFcn = []
TimerFcn = []
TimerPeriod = 1
TriggerFcn = []
Trigger Settings:
InitialTriggerTime = [0 0 0 0 0 0]
TriggerCondition = none
TriggerFrameDelay = 0
TriggerRepeat = 0
TriggersExecuted = 0
TriggerSource = none
TriggerType = immediate
Acquisition Sources:
SelectedSourceName = input1
Source = [1x1 videosource]
% List the video source object's properties and their current values.
get(selectedsrc)
General Settings:
Parent = [1x1 videoinput]
Selected = on
SourceName = VID2
Tag =
Type = videosource
UserData = []
Device Specific Properties:
FirstActiveLine = 21
FirstActivePixel = 140
FrameType = interlacedEvenFieldFirst
StrobeOutput = off
StrobeOutputDuration = 3.3ms
StrobeOutputPolarity = activeHigh
StrobeOutputType = afterFrame
SyncInput = composite
TriggerTimeout = 0
_________________________________________________________________
Page - 65
Note: Each video source object maintains its own property configuration. Modifying
the selected video source is equivalent to selecting a new video source configuration.
% once the video input object is no longer needed, delete
% it and clear it from the workspace.
delete(vidobj)
clear vidobj
7.8
LOGGING DATA TO MEMORY
7.8.1
PREVIEWING DATA
Before logging data, images from an image acquisition device can be previewed live
using the PREVIEW function. Calling the PREVIEW function, will open a preview
window. To close the preview window, use the CLOSEPREVIEW function.
% Access an image acquisition device.
vidobj = videoinput('winvideo', 1);
% Open the preview window.
preview(vidobj)
7.8.2
SINGLE FRAME ACQUISITION
To acquire a single frame, use the GETSNAPSHOT function.

snapshot = getsnapshot(vidobj);
% Display the frame in a figure window.
imagesc(snapshot)
_________________________________________________________________
Page - 66
Figure 7.2: Example of Single Frame Acquisition (filling in glass mug starts)
7.8.3
MULTI-FRAME ACQUISITION
To specify the number of frames to log upon triggering, configure the video input
object's FramesPerTrigger property.
% Configure the number of frames to log upon triggering.
set(vidobj, 'FramesPerTrigger', 50);
An image acquisition object must be running before data can be logged. To initiate an
acquisition, use the START function.
start(vidobj)
% Notice that the number of frames being logged to memory ...
numAvail = vidobj.FramesAvailable
numAvail = 7
% ... is increasing ...
numAvail = 14
% ... over time.
_________________________________________________________________
Page - 67
numAvail = 21
To retrieve logged data from memory, we will use the GETDATA function with the
video input object and the number of frames to retrieve.
% Retrieve some of the logged frames.
imageData = getdata(vidobj, 30);
% Notice the number of frames remaining in memory.
numAvail = 13
% Display the last frame extracted from memory.
imagesc(imageData(:,:,:,30))
To acquire data continuously, configure the FramesPerTrigger property to infinity.

Upon triggering, data will be logged until the video input object stops running. To stop
an object from running, use the STOP function.
set(vidobj, 'FramesPerTrigger', inf)
% Initiate the acquisition.
start(vidobj)
% Notice the number of frames in memory.
numAvail = 6
% Stop the acquisition.
stop(vidobj)
% View the total number of frames that were logged before stopping.
numAcquired = get(vidobj, 'FramesAcquired')
numAcquired = 13
% Retrieve all logged data.
imageData = getdata(vidobj, numAcquired);
% Display one of the logged frames.
imagesc(imageData(:,:,:,10))
_________________________________________________________________
Page - 68
Figure 7.3: Example of Multiple Frame acquisition (Glass Mug filled)
7.8.4
VIEWING LOGGED DATA
To view the most recently logged image data without extracting it from memory, use
the PEEKDATA function with the video input object and the number of frames to
view. Viewing logged data using PEEKDATA will not remove any logged data from
memory.
% Configure the number of frames to log upon triggering.
vidobj.FramesPerTrigger = 35;
% Initiate the acquisition.
start(vidobj)
% Wait for the acquisition to finish.
wait(vidobj, 3);
% Verify the number of frames logged to memory.
numAvail = 35
% Access the logged data without extracting them from memory.
imageData = peekdata(vidobj, numAvail);
% Verify that all logged frames are still available in memory.
numFramesAvailable = vidobj.FramesAvailable
numFramesAvailable = 35
_________________________________________________________________
Page - 69
CHAPTER 8
IMAGE
PROCESSING
TOOLBOX AND
IMAGE
PROCESSING
_________________________________________________________________
Page - 70
INTRODUCTION
8.1
Image Processing Toolbox provides a comprehensive set of reference-standard

algorithms and graphical tools for image processing, analysis, visualization, and
algorithm development. You can restore noisy or degraded images, enhance images
for improved intelligibility, extract features, analyze shapes and textures, and register
two images. Most toolbox functions are written in the open MATLAB language,
giving you the ability to inspect the algorithms, modify the source code, and create
your own custom functions.
Image Processing Toolbox supports engineers and scientists in areas such as

biometrics, remote sensing, surveillance, gene expression, microscopy, semiconductor
testing, image sensor design, color science, and materials science. It also facilitates the
learning and teaching of image processing techniques.
8.2
WORKING WITH IMAGE PROCESSING TOOLBOX
Image Processing Toolbox supports images generated by a wide range of devices,

including digital cameras, frame grabbers, satellite and airborne sensors, medical
imaging devices, microscopes, telescopes, and other scientific instruments. You can
visualize, analyze, and process these images in many data types, including single and
double precision floating-point and signed or unsigned 8-, 16-, and 32-bit integers.
8.2.1.
IMPORTING AND EXPORTING IMAGES
There are several ways to import or export images into and out of the MATLAB
environment for processing. You can use Image Acquisition Toolbox (available
separately) to acquire live images from Web cameras, frame grabbers, DCAMcompatible cameras, and other devices. Using Database Toolbox (also available
separately), you can access images stored in ODBC/JDBC-compliant databases
_________________________________________________________________
Page - 71
MATLAB supports standard data and image formats, including JPEG, TIFF, PNG,
HDF, HDF-EOS, FITS, Microsoft Excel, ASCII, and binary files. It also supports
multiband image formats, such as LANDSAT. Low-level I/O functions enable you to
develop custom routines for working with any data format. Image Processing Toolbox
supports a number of specialized image file formats.
8.2.2.
ENHANCING IMAGES
Image enhancement techniques in Image Processing Toolbox enable you to increase

the signal-to-noise ratio and accentuate image features by modifying the colors or
intensities of an image. You can:
Perform histogram equalization

Perform de-correlation stretching
Remap the dynamic range
Adjust the gamma value
Perform linear, median, or adaptive filtering
The toolbox includes specialized filtering routines and a generalized multidimensional

filtering function that handles integer image types, multiple boundary padding options,
and convolution and correlation. Predefined filters and functions for designing and
implementing your own linear filters are also provided.
8.3 RGB COLOUR MODEL

The RGB color model is an additive color model in which red, green, and blue light
are added together in various ways to reproduce a broad array of colors. The name of
the model comes from the initials of the three additive primary colors, red, green, and
blue.
_________________________________________________________________
Page - 72
RGB is a device-dependent color space: different devices detect or reproduce a given

RGB value differently, since the color elements (such as phosphors or dyes) and their
response to the individual R, G, and B levels vary from manufacturer to manufacturer,
or even in the same device over time. Thus an RGB value does not define the same
color across devices without some kind of color management.
Typical RGB input devices are color TV and video cameras, image scanners, and
digital cameras. Typical RGB output devices are TV sets of various technologies
(CRT, LCD, plasma, etc.), computer and mobile phone displays, video projectors,
multicolor LED displays, and large screens as JumboTron, etc. Color printers, on the
other hand, are usually not RGB devices, but subtractive color devices (typically
CMYK color model).
Figure 8.1: An RGB image, along with its separate R, G and B components
Note that the white snow consists of strong red, green, and blue; the brown barn is
composed of strong red and green with little blue; the dark green grass consists of
strong green with little red or blue; and the light blue sky is composed of strong blue
and moderately strong red and green.
8.3.1
ADDITIVE PRIMARY COLORS
To form a color with RGB, three colored light beams (one red, one green, and one
blue) must be superimposed (for example by emission from a black screen, or by
reflection from a white screen). Each of the three beams is called a component of that
_________________________________________________________________
Page - 73
color, and each of them can have an arbitrary intensity, from fully off to fully on, in
the mixture.
Figure 8.2: A representation of additive color mixing.
The main purpose of the RGB color model is for the sensing, representation, and
display of images in electronic systems, such as televisions and computers, though it
has also been used in conventional photography. Before the electronic age, the RGB
color model already had a solid theory behind it, based in human perception of colors.
The RGB color model is additive in the sense that the three light beams are added
together, and their light spectra add, wavelength for wavelength, to make the final
color's spectrum.
Zero intensity for each component gives the darkest color (no light, considered the
black), and full intensity of each gives a white; the quality of this white depends on the
nature of the primary light sources, but if they are properly balanced, the result is a
neutral white matching the system's white point. When the intensities for all the
components are the same, the result is a shade of gray, darker or lighter depending on
the intensity. When the intensities are different, the result is a colorized hue, more or
less saturated depending on the difference of the strongest and weakest of the
intensities of the primary colors employed.
_________________________________________________________________
Page - 74
When one of the components has the strongest intensity, the color is a hue near this
primary color (reddish, greenish, or bluish), and when two components have the same
strongest intensity, then the color is a hue of a secondary color (a shade of cyan,
magenta or yellow). A secondary color is formed by the sum of two primary colors of
equal intensity: cyan is green + blue, magenta is red + blue, and yellow is red + green.
Every secondary color is the complement of one primary color; when a primary and its
complementary secondary color are added together, the result is white: cyan
complements red, magenta complements green, and yellow complements blue.
The RGB color model itself does not define what is meant by red, green, and blue
colorimetrically, and so the results of mixing them are not specified as absolute, but
relative to the primary colors. When the exact chromaticities of the red, green, and
blue primaries are defined, the color model then becomes an absolute color space,
such as sRGB.
8.4 RGB COLOUR SPACE

An RGB color space is any additive color space based on the RGB color model. A
particular RGB color space is defined by the three chromaticities of the red, green, and
blue additive primaries, and can produce any chromaticity that is the triangle defined
by those primary colors. The complete specification of an RGB color space also
requires a white point chromaticity and a gamma correction curve.
An RGB color space can be easily understood by thinking of it as "all possible colors"
that can be made from three colors of red, green and blue. Imagine, for example,
shining three lights together onto a white wall: one red light, one green light, and one
blue light, each with dimmer switches. If only the red light is on, the wall will look
red. If only the green light is on, the wall will look green. If the red and green lights
are on together, the wall will look yellow. Dim the red light some and the wall will
become more of a yellow-green. Dim the green light instead, and the wall will become
_________________________________________________________________
Page - 75
more orange. Bringing up the blue light a bit will cause the orange to become less
saturated and more white-ish. In all, each setting of the three dimmer switches will
produce a different result, either in color or in brightness or both. The set of all
possible results is the gamut defined by those particular color light bulbs. Swap out the
red light bulb for one of a different brand that is slightly more orange, and there will
be slightly different gamut, since the set of all colors that can be produced with the
three lights will be changed.
Figure 7.3: RGB Cube
An LCD display can be thought of as a grid of thousands of little red, green, and blue
light bulbs, each with their own dimmer switch. The gamut of the display will depend
on the three colors used for the red, green and blue lights. A wide-gamut display will
have very saturated, "pure" light colors, and thus be able to display very saturated,
deep colors.
8.5 PIXEL
In digital imaging, a pixel (picture element) is the smallest piece of information in an
image. Pixels are normally arranged in a regular 2-dimensional grid, and are often
represented using dots, squares, or rectangles. Each pixel is a sample of an original
image, where more samples typically provide a more accurate representation of the
original. The intensity of each pixel is variable; in color systems, each pixel has
_________________________________________________________________
Page - 76
typically three or four components such as red, green, and blue, or cyan, magenta,
yellow, and black.
8.6 imfilter
imfilter
filters an image im with filter F. When im is a multichannel image, each
channel can be filtered with F separately. Input image pixel values outside the bounds
of the image are assumed to equal the nearest array border value.
The only difference of filter2 with imfilter is the output of filter2 is double
matrix, and the output of imfilter has the same type as input and the elements in the
output matrix that exceed the range of the integer type will be truncated.
B = imfilter(A, H)
filters the multidimensional array A with the multidimensional
filter H. The array A can be logical or a nonsparse numeric array of any class and
dimension. The result B has the same size and class as A.
Figure 7.4: Example of imfilter
_________________________________________________________________
Page - 77
Each element of the output B is computed using double-precision floating point. If A is

an integer or logical array, then output elements that exceed the range of the integer
type are truncated, and fractional values are rounded.
B = imfilter(A, H, option1, option2,...)
performs multidimensional filtering
according to the specified options. Option arguments can have the following values.
imfilter
is more memory efficient than some other filtering operations in that it
outputs an array of the same data type as the input image array.
By default, imfilter assumes that image pixels "outside" the image are zero.
Mathematically this is kind of reasonable, but it tends to produce a dark strip along the
edge of the output image.
8.7
AI IMPLEMENTATION
After getting the filtered image, we used two algorithms to implement Artificial
Intelligence in UGV, namely:
1) Colour Segmentation
2) Image Comparison
Two algorithms were necessary because image comparison algorithm could not be run
at every instant in combination with Visual Basic 6 exe file as it was using much CPU
resources. Hence a much lighter Colour Segmentation algorithm was used, as a
primary condition to be satisfied, to avoid CPU hanging. Similarly, we could not use
Colour segmentation algorithm only because any colored object could also come in
front of car which could have that RGB colour, which could be inside threshold
tolerance range, thus causing a malfunction.
_________________________________________________________________
Page - 78
8.8 COLOUR SEGMENTATION

For UGV to identify its target, we wrote a colour segmentation algorithm of a function
getcolor which was checking the intensity of red, green and blue intensities in the
pixels of a stored video frame or simply a filtered image. Each frame was filtered by
imfilter. We took snapshots of destination and obtained the hard code RGB values of
the destination colour with the help of data cursor
function [my_ans, my_percent] = getcolor(image,tr,colors)
This function finds a color of an Image A and returns IMAGE, the original image with
the pixels with the specified color set to zero, and IND, an index to the pixels that are
were equal to the selected color. TR is the threshold tolerance for the color range,
COLOR VECTOR is an additional argument that takes in the hard-coded values for
the color.
The return type of this function getcolor is no. of pixels matched and matching
percentage.
[my_ans, my_percent]= getcolor(image,colors,tr);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function [my_ans, my_percent] = getcolor(image,color,tr)

[i j k]=size(image);
R=color(1,1);
G=color(1,2);
B=color(1,3);
I=double(image);
my_ans=0;
for (a=1:i)
for (b=1:j)
if ((abs(I(a,b,1)-R) <tr ) && ( abs(I(a,b,2)-G) <tr ) && (
abs(I(a,b,3)-B) <tr ))
my_ans=my_ans+1;
end
_________________________________________________________________
Page - 79
end
end
my_percent=(my_ans/(i*j))*100;
Where,
my_ans
is no. of pixels matched and
my_percent
is matching percentage.
We could not use Colour segmentation algorithm only because any colored object
could also come in front of car which could have that RGB colour, which could be
inside threshold tolerance range, thus causing a malfunction. Thus we need another
software for secondary target verification.
8.9 IMAGE COMPARISON

Object tracking can be described as a correspondence problem, and involves finding
which object in a video frame relates to which object in the next frame. Tracking
methods can be classified into four major categories:
Model based tracking
Active contour based tracking
Feature based tracking
Region based tracking.
_________________________________________________________________
Page - 80
Figure 7.5: Vehicles and persons tracked throughout the scene
The category we selected for our target detection is Region based tracking. This
algorithm was secondary verification of destination as well as turning point. Images of
turning points and destination were taken and stored in PC. In this algorithm we were
subtracting the pixels of current filtered frame from video (an image) from the
corresponding stored frame at the calculated time. On subtraction the matching pixels
are replaced by black pixels, absence of color (matching percentage) for us. This
matching percentage was useful for us and we used it later in our final Visual Basic
code with threshold range to decide arrival of destination and turning points.
Figure 7.7: Implementation effects of Frame Comparison Algorithm
_________________________________________________________________
Page - 81
SECTION C
MODES OF UGV
After the Hardware and Software Structure Development, we were ready to achieve
our final goals and that is to achieve the combination of booth modes that is:
Teleoperated Mode
Autonomous mode
The final Steps remained in the development were the combination of all codes, their
inter linkage and development of GUI.
_________________________________________________________________
Page - 82
CHAPTER 9
TELEOPERATION
This chapter contains details about the electronics involved in our project. The topics
include
CONTENTS:
a.
b.
c.
d.
Overview
Vehicle Motion
Speed View
Picture Capture
_________________________________________________________________
9.1
Page - 83
OVERVIEW
In teleoperation mode, the vehicles navigation is controlled by the user at the remote
PC station. The user sends commands through the keyboard to the vehicle
microcontroller through the Xbee interface. The vehicle microcontroller, on receiving
the command, generates the corresponding signal for the direction and speed motor
drives. A speed sensor is mounted on the axel of the vehicle which is directly
interfaced with the microcontroller. The microcontroller sends back the pulses to the
PC through which the PC estimates the speed of the vehicle. This is displayed on the
speedometer. Speed is determined through an algorithm defined later on. On the basis
of this feedback, the vehicles position may be estimated.
The vehicle also relays live video feed to the PC through the on-board analog video
camera. The user makes the decision based on this video sensor feedback.
The user may also capture any image he finds interesting through this camera.
The PC controls transmit reference speed and direction to the vehicle.
The vehicle moves accordingly.
Vehicle tracking is accomplished through the data fed back by the microcontroller.
9.2
Vehicle Motion
9.2.1
SPEED
The speed of the vehicle may be set through pulse width modulation. The driving
waveform generated by the controller is controlled through an 8-bit register. Decimal
value of 255 generates maximum speed because of waveform of unity duty cycle
while 0 generates minimum speed with 0 duty cycle.
_________________________________________________________________
9.2.2
Page - 84
DIRECTION
The vehicles wheels may have 3 possible orientations with respect to vehicle body:
Straight, +45 and -45. Through keypad control, the user may define direction of
motion. UP and DOWN keys keep the direction motor unactuated, LEFT key
cause motor to turn in one direction whereas RIGHT key causes motor direction to
reverse.
9.2.3
COMMANDS
UP KEY: Rear motor will actuate in forward direction. Direction motor is dependent
on LEFT and RIGHT keys. If the latter two have not been pressed or have been
released, then the motor remains unactuated and the wheels have a straight orientation
with respect to the vehicle body.
DOWN KEY: Rear motor will actuate in reverse direction. Direction motor is
dependent on LEFT and RIGHT keys. If the latter two have not been pressed or
have been released, then the motor remains unactuated and the wheels have a straight
LEFT KEY: Direction motor will actuate in left direction. Speed motor dependent on
UP and DOWN keys. If the latter two have not been pressed or have been released,
then the speed motor remains unactuated and the wheels have a +45 orientation with
respect to the vehicle body.
RIGHT KEY: Direction motor will actuate in right direction. Speed motor dependent
on UP and DOWN keys. If the latter two have not been pressed or have been
released, then the speed motor remains unactuated and the wheels have a -45
_________________________________________________________________
9.3
Page - 85
SPEEDOMETER
A speedometer has been placed which indicates speed of the vehicle. The value of
speed is obtained from the formula of equation 9.1. Maximum speed at unity duty
cycle is about 3.5 mps.
Figure 9.1: Speedometer
9.4
VEHICLE SPEED CALCULATION
As the feedback mechanism is such that only 2 pulses are obtained in one complete
revolution of the vehicles wheel, hence a large sampling time of the order of 2 to 10
seconds would be required for reasonable precision. Hence a compensatory measure
had to be taken for speed determination. An unconventional method was developed
which is the fastest possible and whose accuracy is dependent on two factors,
Resolution of microcontrollers timer
Symmetry of holes spacing.
_________________________________________________________________
Page - 86
inverse of RPS.
The time taken between two consecutive high-to-low transitions is determined by
starting a timer when 1st transition occurs and stopping it when the second one occurs.
The count of the timer multiplied by time of each count gives elapsed time.
Scaling has been done so the 1 count of the timer represents 8.68 msec.
The interrupt is enabled every 100 msec and then disabled for next 100 msec. Hence
the sampling time has been set to 100 msec and the sample rate is 10 Hz.
Hence the formula for speed calculation of UGV becomes
9.5
LIVE VIDEO FEED
Live video feed from the vehicles video sensory input is available to the operator
through MATLAB.
The user makes decisions based on this input.
Figure 9.2: Block diagram of video image
processing
_________________________________________________________________
Page - 87
As can be seen, the wireless camera mounted on the vehicle transmits video
information to the analog receiver. The analog receiver is interfaced with the PC
through the frame grabber card, which converts the analog input to a digital output.
Suitable adaptors are necessary to convert this digital information into a form
compatible with MATLAB. The live video feed is displayed on MATLAB.
9.6
IMAGE CAPTURING
The user has the option to capture images that he finds to be important by pressing
button C of keyboard. These images are stored in the hard disk in *.bmp format.
There is no limit of image capture and user can take as much snap shots as much space
is available on that partition of hard disk drive. The capture picture feature is achieved
by getsnapshot command of MATLAB.
Getsnapshot - Immediately return single image frame

Syntax
frame = getsnapshot(obj)
Description
frame = getsnapshot(obj) immediately returns
from the video input object obj. The frame of data
video input object F
one single image frame, frame,

returned is independent of the
The object obj must be a 1-by-1 video input object.
_________________________________________________________________
Page - 88
CHAPTER 10
AUTONOMOUS
NAVIGATION
This chapter contains details about the electronics involved in our project. The topics
include
CONTENTS:
a.
b.
c.
d.
e.
PC side electronics
Vehicle side electronics
PC side power supply
Vehicle side power supply
Power supply considerations
_________________________________________________________________
10.1
Page - 89
OVERVIEW
In autonomous navigation mode, the track on which the navigation is to take place is
broken down into segments and then defined in the PC through VB interface. An
image of the final destination is also fed to the PC. A segment may be a straight
forward, straight reverse, left or right turn.
When the vehicle is ready for navigation, then the START button is pressed, on which
the vehicle receives instruction from the PC to start moving. From the pulses fed back
by the vehicle, the PC estimates the vehicle current position. As soon as the PC
estimates that the vehicle has covered the distance as necessitated by the track, the PC
issues command for the next segment, which may be a turn, or reversing. In this
manner, the vehicles position is continuously tracked by the PC, thereby imparting it
the intelligence of localization.
On reaching the final destination, the vehicle takes a snapshot and compares the RGB
content of current frame with that of the frame provided to it of the destination. If they
match by a certain percentage, then it is considered a match. If they donot match, then
an alarm is generated in the PC to alert the operator that the vehicle has arrived at an
incorrect location and to take control of the vehicle, and take the corrective measures
through teleoperated navigation mode.
10.2
M AP DEFINITION
The map shown in fig 5-1 has three destinations. If the destination were to not match
given a certain error leeway, then a malfunctioning error would be generated.
A SEGMENT MAY BE A STRAIGHT PATH OR A CURVED ONE. A CURVED PATH MAY BE
A LEFT OR RIGHT TURN .
A map may be defined as follows;

_________________________________________________________________
Page - 90
Figure 10.1: PREDEFINED MAP DIVIDED INTO SEGMENTS
processing
AS CAN BE SEEN, THERE MAY BE MULTIPLE DESTINATIONS IN A S INGLE PATH,

WITH MALFUNCTION ERROR RESOUNDING IF ANY DESTINATION WERE TO BE A
MISMATCH. A TARGET IMAGE HAS TO BE ASSOCIATED W ITH EACH DESTINATION .
10.2.1 SEGMENT
Before a map can be fed into the PC for autonomous navigation, it has to be broken
down into segments.
Segments are the paths into which the vehicles path is divided. A segment may be
straight or curved.
_________________________________________________________________
10.3
Page - 91
VEHICLE MOTION
A vehicle may move in two manners on the basis of type of segment encountered.
Straight Segment
Curved Segment
10.3.1
STRAIGHT SEGMENT
On straight segments, the vehicles direction motor remains unactuated where as the
speed motor turns at maximum speed.
10.3.2
CURVED SEGMENT
On curved paths, the vehicles speed is reduced by sending decimal 175. This is to
minimize the radius of curvature of the vehicle on turns. The radius at this speed has
been found to be 75 cm. The vehicle may only take sharp right and left turns in
autonomous mode. On encountering a curved segment, the direction motor is actuated
in the corresponding direction for an estimated time after which the motor is again,
deactivated, thereby realigning the wheels in parallel with the vehicles body.
10.4
VEHICLE TRACKING
Artificial intelligence necessitates that in order to make a decision to issue command

for new segment, the vehicle must be tracked to estimate its current location on the
predefined map or path. On the basis of the feedback speed and the time elapsed, the
PC estimates the distance transverse by the vehicle on its current segment. Once this
distance matches the distance that vehicle was supposed to transverse, the PC issues
command for next segment. In this manner, the UGV has intelligence of localization,
the most primary of all for autonomous navigation algorithms.
_________________________________________________________________
10.5
Page - 92
VEHICLE SPEED CALCULATION
As the feedback mechanism is such that only 2 pulses are obtained in one complete
revolution of the vehicles wheel, hence a large sampling time of the order of 2-10
seconds would be required for reasonable precision. Hence a compensatory measure
had to be taken for speed determination. An unconventional method was developed
which is the fastest possible and whose accuracy is dependent on two factors,
Resolution of microcontrollers timer
Symmetry of holes spacing.
inverse of RPS.
The time taken between two consecutive high-to-low transitions is determined by
starting a timer when 1st transition occurs and stopping it when the second one occurs.
The count of the timer multiplied by time of each count gives elapsed time.
Scaling has been done so the 1 count of the timer represents 8.68 msec.
The interrupt is enabled every 100 msec and then disabled for next 100 msec. Hence
the sampling time has been set to 100 msec and the sample rate is 10 Hz.
Hence the formula for speed calculation of UGV becomes
_________________________________________________________________
10.6
Page - 93
ARTIFICIAL INTELLIGENCE
The ability of a computer program to evaluate information and make decisions

according to pre-established criteria
Three sub classes of artificial intelligence are required for autonomous mode
navigation
Localization (Knowing Where You Are): This is done through tracking mechanism
explained previously.
Mapping (Knowing What Is Around You): This is done through image processing,
though on a limited scale due to 2-D image.
Motion Planning (Knowing How To Get To Destination): This has to be defined in the
map, & by current position information.
10.6.1
LOCALIZATION
The robot localization problem is a key problem in making truly autonomous robots. If
a robot does not know where it is, it can be difficult to determine what to do next. In
order to localize itself, a robot has access to relative and absolute measurements giving
the robot feedback about its driving actions and the situation of the environment
around the robot. Given this information, the robot has to determine its location as
accurately as possible. What make this difficult are the existence of uncertainty in both
the driving and the sensing of the robot. The uncertain information needs to be
combined in an optimal way.
For UGV to know where it is at a particular instant, we used heuristic basis. Since we
knew the whole path distance, and have feedback of speed from Car, therefore we
were storing the value of current distance covered with respect to our reference or
starting point at every millisecond. Thus in case of accidental power failure, the last
_________________________________________________________________
Page - 94
value stored in the text file would be its next starting point on power resumption,
however frame of reference would still be the starting point.
10.6.2
MAPPING
Data mapping is the process of creating data element mappings between two distinct
data models. Data mapping is used as a first step for a wide variety of data integration
tasks including:
Data transformation or data mediation between a data source and a destination
Identification of data relationships as part of data lineage analysis
This is the newest approach in data mapping and involves simultaneously evaluating
actual data values in two data sources using heuristics and statistics to automatically
discover complex mappings between two data sets. This approach is used to find
transformations between two data sets and will discover substrings, concatenations,
arithmetic, case statements as well as other kinds of transformation logic. This
approach also discovers data exceptions that do not follow the discovered
transformation logic. Therefore by image recognition algorithm we were simply
subtracting the current frame for original frame and were checking the number of
black pixels percentage (which shows matching) and comparing it with certain
threshold value depending on light available in the surrounding, to make UGV sense
what is around it.
10.6.3
MOTION PLANNING
Motion planning (a.k.a., the "navigation problem", the "piano mover's problem") is a
term used in robotics for the process of detailing a task into atomic motions.
For example, consider navigating a mobile robot inside a building to a distant
waypoint. It should execute this task while avoiding walls and not falling down stairs.
A motion planning algorithm would take a description of these tasks as input, and
produce the speed and turning commands sent to the robot's wheels. Motion planning
_________________________________________________________________
Page - 95
algorithms might address robots with a larger number of joints (e.g., industrial
manipulators), more complex tasks (e.g. manipulation of objects), different constraints
(e.g., a car that can only drive forward), and uncertainty (e.g. imperfect models of the
environment or robot).
Motion planning has several robotics applications, such as autonomy, automation, and
robot design in CAD software, as well as applications in other fields, such as
animating digital characters, architectural design, robotic surgery, and the study of
biological molecules.
A basic motion planning problem is to produce a continuous motion that connects a
start configuration S and a goal configuration G, while avoiding collision with known
obstacles. The robot and obstacle geometry is described in a 2D or 3D workspace,
while the motion is represented as a path in (possibly higher-dimensional)
configuration space.
Figure 10.2 Motion Planning Workspace
In our case, we achieved motion planning by image processing algorithms of image

recognition and colour segmentation. At every destination and turning point, we took
the snaps for comparing it in real time when UGV would be approaching either
destination or turns respectively. Since this algorithm uses a lot of resources therefore
instead of using it for all time we used colour segmentation algorithm as a preliminary
_________________________________________________________________
Page - 96
condition to be satisfied. Then Image recognition as a secondary condition to be

verified.
10.6.4
AVAILABLE DATA
Following is the data available to the PC for implementing navigational A.I.

1. Map
2.
Speed
3.
Time
4.
Live video feed
5.
Destination Image
6.
Color Flags at Destination
7.
Round about Image
FEATURES:
1. Online Video Feed
2.
Target Detection
3.
Image Recognition
4.
Map Designing
5.
Artificial Intelligence
_________________________________________________________________
Page - 97
REFERENCES
[Everett, 1995] H.R. Everett. Sensors for Mobile Robot Systems: Theory and Application,
A.K. Peters, Wellesley MA, 1995.
[Fredrick J. Keller, 1993], Physics: Classical & Modern, 2nd Edition, McGraw-Hill, Inc.
Singapore.
[Flynn, 1985] Flynn, A.M. "Redundant Sensors for Mobile Robot Navigation", MIT AI Lab
Technical Report 859, 1985.
[Francis H. Raven, 1995]. Automatic Control Engineering, 5th Edition, McGraw-Hill, Inc.
Singapore.
[Giralt, 1983] Giralt, G, Chatila, R. and Vaisset M. "An Integrated Navigation and Motion
Control System for Autononous Multisensory Mobile Robots", Proceedings of the
First International Symposium of Robotics Research, 1983.
[Harmon, 1986] Harmon, S.Y. "Autonomous Vehicles", Encyclopedia of Artificial
Intelligence, Wiley and Sons, NY, 1986, pp 39-45.
[Klafter, 1988] Klafter, R.D. "Mobile Robots, Research and Development", International
Encyclopedia of Robotics: Applications and Automation, Wiley and Sons, NY,
1988, pp 920-943.
[Martin Marietta, 1986] Martin Marietta Denver Aerospace, The Autonomous Land Vehicle
Program, handout at June 1986 ALV demonstration, Denver CO.
[Meystel, 1991] Meystel, A. Autonomous Mobile Robots -- Vehicles with Cognitive
Control, World Scientific Publishing Co, Singapore, 1991, chapter 2. [Moravec,
1983] Moravec, H.P. The Stanford Cart and CMU Rover. Technical Report,
Robotics Institute, Carnegie-Mellon University, February 1983.
_________________________________________________________________
Page - 98
[Moravec, 1985] Moravec, H.P. and Elfes, A. "High Resolution Maps from Wide Angle
Sonar", Proceedings of 1985 IEEE International Conference on Robotics and
Automation, St Louis MO, 25-28 March 1985, pp 116-121.
[Nilsson, 1969] Nilsson, N.J. "A Mobile Automaton: An Application of Artificial Intelligence
Techniques", Proceedings of the First International Joint Conference on Artificial
Intelligence, Washington DC, May 1969, pp 509-520.
[Paul E. Sandin, 2003] Robot Mechanisms & Mechanical Devices Illustrated, 1st Edition,
McGraw-Hill, Inc. Singapore.
[Robert Resnick, 1992] Physics, 4th Edition, Volume 1, John Wiley & Sons, Inc.
[R.S. Khurmi, 1997] A Textbook of Applied Mechanics,13th Edition, S. Chand & Company
Ltd., New-Dehli, Ind
[Thorpe, 1990] Thorpe, C.E., ed. Vision and Navigation: The Carnegie Mellon Navlab,
Kluwer, Boston MA, 1990.
[George Luger, 2004] George Luger. Artificial Intelligence: Structures and Strategies for
Complex Problem Solving, 5th Edition, The Benjamin/Cummings Publishing Company,
Inc.
[Nils Nilsson, 1998] Nils Nilsson. Artificial Intelligence: A New Synthesis, Morgan
Kaufmann Publishers.
[Stuart J. Russel, 2003] Stuart J. Russel. Artificial Intelligence: A Modern Approach, 2nd
Edition, Upper Saddle River, NJ: Prentice Hall.
[David Poole, 1998] Alan Mackworth. Computational Intelligence: A Logical Approach,

Oxford University Press.
_________________________________________________________________
Page - 99
APPENDIX A
SCHEMATIC OF
EMBEDDED
CIRCUIT
_________________________________________________________________
Page - 100
_________________________________________________________________
Page - 101
APPENDIX B
LAYOUT OF PCB
_________________________________________________________________
Page - 102
_________________________________________________________________
Page - 103
APPENDIX C
AVR ASSEMBLY
SOURCE CODES
_________________________________________________________________
Page - 104
MAIN
.INCLUDE
.INCLUDE
.INCLUDE
.INCLUDE
.INCLUDE
.INCLUDE
"m8def.inc"
"UGV_Variables.inc"
"UGV_Macros.inc"
"SerialHandler.asm"
"TimerHandler.asm"
"Debug_n_Testing.asm"
.ORG 0x000
RJMP Reset
.ORG 0x001
RJMP INT0Handler
.ORG 0x008
RJMP T1OVHandler
.ORG UGV_Start_Addr
Reset:
; Stack initializing
LDI R16, HIGH(RAMEND)
OUT SPH,R16
LDI R16, LOW(RAMEND)
OUT SPL,R16
; Upper
;
; Lower
;
byte
to stack pointer
byte
to stack pointer
;iNitiAl_IXI_
;MOVI 0x90, 0b11001100
;SET_BIT 0x90, (1<<PORTB7)|(1<<PORTB5)|(1<<PORTB0)
;CLR_BIT 0x90, (1<<PORTB7)|(1<<PORTB2)|(1<<PORTB0)
LDI R16, 0xFF
OUT DDRC, R16
OUT DDRB, R16
; Make PortB (Motor) output.
LDI R16, 0b10101100

OUT PORTC, R16
Main:
SEI
; Enable Global Interrupt
RCALL Motor_INIT
RCALL Timer_INIT
RCALL UART_Init
_________________________________________________________________
Page - 105
LOOP:
; Do some work here
RCALL DeBug_Serial_Runtime
; Do some work here

RJMP LOOP
Motor_INIT:
LDI Temp0, 0
OUT Motor_Spd_PWM, Temp0
; Set PWM=0
CBI Motor_Port, Motor_Spd_Bit1

direction
;
SBI Motor_Port, Motor_Spd_Bit2OC
; Set for forward
CBI Motor_Port, Motor_Pos_Bit1

Positions bits
CBI Motor_Port, Motor_Pos_Bit2
position
; Clear both
; to have reset
; Motor feedback initialization

LDI Temp0, (1<<ISC01)|(1<<ISC00)
OUT MCUCR, Temp0 ; Make INT0 active on rising Edge
LDI Temp0, (1<<INT0)
OUT GICR, Temp0
; Enable External INT0
RET
; Used to get motor speed feedback
INT0Handler:
LDS Temp0, DeBug_INTcnt
INC Temp0
of
STS DeBug_INTcnt, Temp0
; Increase counter which is

; used to track the number
; times interrupt had occured.
;
IN Temp0, TCNT1L
;
IN Temp1, TCNT1H ; Save time taken between interrupt (HB only)
in FB_Val
;
STS Motor_Feedback_Val_LB, Temp0
;
STS Motor_Feedback_Val_HB, Temp1
; Take new value, and average it with old value.
_________________________________________________________________
;
;
;
Page - 106
IN Temp0, TCNT1L
LDS Temp0, Motor_Feedback_Val_HB
IN Temp1, TCNT1H
ADD Temp1, Temp0
ROR Temp1
LDI Temp0, 0
OUT TCNT1H, Temp0
OUT TCNT1L, Temp0
RETI
; Reset timer value
T1OVHandler:
LDI Temp0, 0xFF
STS Motor_Feedback_Val_LB, Temp0
RETI
SERIAL HANDLER
.ORG 0x00B
RJMP UART_RECV
.ORG UGV_Serial_Addr
UART_Init:
SBI UCSRA, U2X
;CBI UCSRA, U2X
; Set U2X (double baud rate)

; Clear U2X (normal baud rate)
; Enable receiver and transmitter, and enable receiver interrupt

LDI Temp0, (1<<RXCIE)|(1<<RXEN)|(1<<TXEN)
OUT UCSRB, Temp0
; Set frame format: 8data, 1stop bit
LDI Temp0, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
OUT UCSRC, Temp0
; Set baud rate
LDI Temp1, 0x0
LDI Temp0, 0x5F
;LDI Temp0, 0x2F
;LDI Temp0, 0x17
; 9600 Baudrate
; 19200 Baudrate
; 38400 Baudrate
_________________________________________________________________
;LDI Temp0, 0x0F

;LDI Temp0, 0x7
Page - 107
; 57600 Baudrate
; 115200 Baudrate
OUT UBRRH, Temp1

OUT UBRRL, Temp0
; Initiate UGV serial variables
MOVI UART_RECV_NO, 0
MOVI UART_Flag, 0x00
MOVI UART_TO_Counter, 0x00
Disable_TO
RET
UART_RECV:
PUSH_ALL
IN Temp3, UDR
Disable_TO
; Save incoming data
LDS Temp0, UART_RECV_NO

CPI Temp0, 0
; If UART_RECV_NO is 0
BREQ UART_RECV_New
; then jump.
; Else the incoming data is VAL.
;
MOVM UART_RECV_CMD, UART_RECV_CMDtemp
STS UART_RECV_VAL, Temp3
SET_BIT UART_Flag, (1<<Cmd_Received)
RJMP UART_RECV_END
UART_RECV_New:
STS UART_RECV_CMD, Temp3
UART_RECV_END:
POP_ALL
RETI
; Arguments: Temp1=CMD, Temp2=VAL

UART_SEND:
CLR_BIT UART_Flag, (1<<Cmd_Received)
Enable_TO
STS UART_SEND_CMD, Temp1
STS UART_SEND_VAL, Temp2
MOV Temp0, Temp1
RCALL OUT_UDR
_________________________________________________________________
Page - 108
MOV Temp0, Temp2

RCALL OUT_UDR
RET
TO_OV:
MOVI UART_TO_Counter, 0
LDS Temp0, UART_SEND_CMD
RCALL OUT_UDR
LDS Temp0, UART_SEND_VAL
RCALL OUT_UDR
RET
OUT_UDR:
SBIS UCSRA, UDRE
RJMP OUT_UDR
OUT UDR, Temp0
RET
; Skip if transmit buffer (UDR) is Empty
TIMERHANDLER
.ORG 0x009
RJMP T0OV
.ORG UGV_Timer_Addr
Timer_INIT:
RCALL T0INIT
RCALL T1INIT
RCALL T2INIT
LDI Temp0, (1<<TOIE0)|(1<<TOIE1)
OUT TIMSK, Temp0
; Enable Timer0/1 Interrupt
RET
T0INIT:
; 1024 prescale, 72 counts (256-72=0xB8) = 10 ms
; 64 prescale, 115.2 counts (256-115=0x8D) = 1 ms
LDI Temp0, T0_Prescale
OUT TCCR0, Temp0
; Enable Timer0, Prescale = 1024
LDI Temp0, T0_Preset
OUT TCNT0, Temp0
RET
T1INIT:
LDI Temp0, 0
; Timer 1, Normal operation mode.
_________________________________________________________________
Page - 109
OUT TCCR1A, Temp0

;
;
LDI
LDI
LDI
OUT
RET
Temp0, 0b00000011
Temp0, 0b00000100
Temp0, 0b00000101
TCCR1B, Temp0

T2INIT:
; Initialize Timer2 for FastPWM, non-inverted with prescale of
32 (Making PWM freq=976 Hz)
LDI R16,
(1<<COM21)|(0<<COM20)|(1<<WGM21)|(1<<WGM20)|(0<<CS22)|(1<<CS21)|(0<<C
S20)
OUT TCCR2, Temp0
RET
T0OV:
PUSH_ALL
LDI Temp0, T0_Preset
OUT TCNT0, Temp0
; TO Section
SBMS UART_Flag, TO_Enable
TO_Enable
RJMP Skip_TO_Section
LDS Temp0, UART_TO_Counter
INC Temp0
; Reload Preset value
; Skip the RJMP if

; Else skip the TO_Section
; INC TO_Counter
STS UART_TO_Counter, Temp0

LDS Temp0, UART_TO_Counter
CPI Temp0, TO_n_Multiple
BRLO Skip_TO_Section
RCALL TO_OV
Skip_TO_Section:
; Check if TO OV
; If yes then go down
; else jump to Skip
T0OV_END:
POP_ALL
RETI
_________________________________________________________________
Page - 110
APPENDIX D
VB6 SOURCE
CODES
_________________________________________________________________
Page - 111
-: frm_MSComm :Option Explicit

' ********* Variables to determine the speed of UART communication
*********
Dim PSPS_Cnt As Integer
' Packets Sent Per Second
Dim PRPS_Cnt As Integer
' Packets Received Per Second
' ********* Serial Interface to other Program areas (Variables
Declaration) *********
Dim Current_Packet_No As Integer
Private Type SEND_Packet
CMD As Byte
VAL As Byte
End Type
Dim SSSPacket(1 To MAX_Packet_Count) As SEND_Packet
' SSS =
Serial SEND Stack
' ********* UART Handler (Variables Declaration) *********

Dim UART_RECV_NO As Byte
Dim FLAG_CMD_Received As Boolean
Dim UART_SEND_CMD As Byte
Dim UART_SEND_VAL As Byte
Dim UART_RECV_CMD As Byte
Dim UART_RECV_VAL As Byte
Dim UART_RECV_CMD_temp As Byte
' Variables to handle Serial IN/OUT
Dim s_Ob(1) As Byte
Dim s_OFb(0) As Byte
Dim s_Ib() As Byte
Dim s_I
Dim Serial_Input As Integer
Dim Serial_Input_Buffer(200) As Integer
' INIT Serial IN/OUT and UGV_Ser_Variables

Private Sub Form_Load()
MSComm1.Settings = UGV_Baud & ",n,8,1"
MSComm1.RThreshold = 1
' Take action for even single byte
received
MSComm1.SThreshold = 0
' Send immediately whenever the buffer is
not empty
_________________________________________________________________
Page - 112
'MSComm1.InputLen = 0
' Read all bytes from input buffer at a
time.
MSComm1.InputLen = 10000
MSComm1.InputMode = comInputModeBinary
'MSComm1.InBufferCount = 0
'MSComm1.InBufferSize = 0
'MSComm1.OutBufferCount = 0
'MSComm1.OutBufferSize = 0
MSComm1.PortOpen = True
' UART Variables Initialization.
TO_Timer.Enabled = False
UART_RECV_NO = 0
FLAG_CMD_Received = True
' False for MCU
TO_Timer.Interval = UGV_TO_Time_Interval
End Sub
Private Sub Form_Unload(Cancel As Integer)

MSComm1.PortOpen = False
End Sub
' Packets Per Second Timer: Used to update the UART Speed Display
Private Sub PPS_Timer_Timer()
If DeBug_Mode Then frm_DeBugMain.lbl_PSPS = PSPS_Cnt
If DeBug_Mode Then frm_DeBugMain.lbl_PRPS = PRPS_Cnt
PSPS_Cnt = 0
PRPS_Cnt = 0
End Sub
Public Sub UART_SEND_Poll()
'initial_IXI_
'Do
'If frm_HS_Test.Check1.Value = 1 Then 'initial_IXI_
If FLAG_CMD_Received = True And Current_Packet_No > 0 Then Call
SendCMD(SSSPacket(1).CMD, SSSPacket(1).VAL)
'initial_IXI_
'DoEvents
'initial_IXI_
_________________________________________________________________
Page - 113
'frm_HS_Test.Check1.Value = 0
'End If
'initial_IXI_
'Loop
End Sub
Public Sub SendCMD(CMD2SEND As Byte, VAL2SEND As Byte)

UART_SEND_CMD = CMD2SEND
UART_SEND_VAL = VAL2SEND
TO_Timer.Enabled = True
FLAG_CMD_Received = False
If DeBug_Mode And frm_DeBugMain.chk_UART_Display.Value = 1 Then
frm_DeBugMain.txt_UART = frm_DeBugMain.txt_UART & "SEND: " &
Format(UART_SEND_CMD, "000 ") & Format(UART_SEND_VAL, "000
")
'If DeBug_Mode And frm_DeBugMain.chk_UART_Display.Value = 1 Then
UART_SEND_CMD & " " & UART_SEND_VAL & "
"
s_Ob(0) = UART_SEND_CMD
s_Ob(1) = UART_SEND_VAL
MSComm1.Output = s_Ob
PSPS_Cnt = PSPS_Cnt + 1
End Sub
Public Sub SendFIXByte()
Format(UART_SEND_CMD, "010 ")
"
s_OFb(0) = UART_SEND_CMD
MSComm1.Output = s_OFb
End Sub
Public Sub RecvFIXByte()
frm_DeBugMain.txt_UART = frm_DeBugMain.txt_UART & "RECV: 1 fixbyte "
"
s_Ib = MSComm1.Input
s_OFb(0) = UART_SEND_CMD
MSComm1.Output = s_OFb
End Sub
_________________________________________________________________
Page - 114
Private Sub TO_Timer_Timer()

Format(UART_SEND_CMD, "000 ") & Format(UART_SEND_VAL, "000
")
"
s_Ob(0) = UART_SEND_CMD
s_Ob(1) = UART_SEND_VAL
MSComm1.Output = s_Ob
End Sub
Private Sub MSComm1_OnComm()

Select Case MSComm1.CommEvent
'
Case comEventBreak
' A Break was received.
'
Case comEventFrame
' Framing Error
'
Case comEventOverrun
' Data Lost.
'
Case comEventRxOver
' Receive buffer overflow.
'
MSComm1.InBufferCount = 0
'
Case comEventRxParity
' Parity Error.
'
Case comEventTxFull
' Transmit buffer full.
'
Case comEventDCB
' Unexpected error retrieving DCB]
'
'
Case comEvCD
' Change in the CD line.
'
Case comEvCTS
' Change in the CTS line.
'
Case comEvDSR
' Change in the DSR line.
'
Case comEvRing
' Change in the Ring Indicator.
Case comEvReceive
' Received RThreshold # of chars
s_Ib = MSComm1.Input
Dim i As Integer
If UBound(s_Ib) >= 1 Then
For i = 0 To 1
Serial_Input = s_Ib(i)
'SEND: 012 010
'
If DeBug_Mode And
frm_DeBugMain.chk_UART_Display.Value = 1 Then frm_DeBugMain.txt_UART
= frm_DeBugMain.txt_UART & "SEND: " & Format(UART_SEND_CMD, "000 ")
& Format(UART_SEND_VAL, "000
")
If DeBug_Mode And
= frm_DeBugMain.txt_UART & "RECV:
" & Format(Serial_Input, "000
")
_________________________________________________________________
Page - 115
'
If DeBug_Mode And
= frm_DeBugMain.txt_UART & "RECV: " & Serial_Input & " "
Call Serial_RECV_Int
Next i
Else
'
Serial_Input = s_Ib(i)
'SEND: 012 010
'
If DeBug_Mode And
= frm_DeBugMain.txt_UART & "SEND: " & Format(UART_SEND_CMD, "000 ")
& Format(UART_SEND_VAL, "000
")
'
If DeBug_Mode And
= frm_DeBugMain.txt_UART & "RECV:
" & Format(Serial_Input, "000
")
'
If DeBug_Mode And
= frm_DeBugMain.txt_UART & "RECV: " & Serial_Input & " "
'
Call Serial_RECV_Int
End If
'
DoEvents
'
'
Case comEvSend
' There are SThreshold number of characters
in the transmit buffer.
'
Case comEvEOF
' An EOF charater was found in the input
stream
'
'
Case Else
'
Print
End Select
End Sub
Private Sub Serial_RECV_Int()
TO_Timer.Enabled = False
If UART_RECV_NO = 0 Then
UART_RECV_CMD_temp = Serial_Input
UART_RECV_NO = 1
Else
UART_RECV_CMD = UART_RECV_CMD_temp
UART_RECV_VAL = Serial_Input
Call Save_in_RECV_Array
UART_RECV_NO = 0
Call SSS_Handler_on_RECV
' SSS = Serial Send Stack
PRPS_Cnt = PRPS_Cnt + 1
End If
End Sub
Private Sub Save_in_RECV_Array()
If UART_RECV_CMD <> 0 Then
_________________________________________________________________
Page - 116
SRAPacket(UART_RECV_CMD).Is_New = True
SRAPacket(UART_RECV_CMD).VAL = UART_RECV_VAL
End If
End Sub
Private Sub SSS_Handler_on_RECV()
Select Case SSSPacket(1).CMD
Case 13:
' Right
frm_NFS.Label4.Caption = "Right"
Case 14:
' Left
frm_NFS.Label4.Caption = "Left"
Case 15:
' Center
frm_NFS.Label4.Caption = "Center"
Case 5:
' Feedback
FBcnt = FBcnt + 1
Total_FB = Total_FB + UART_RECV_VAL
frm_UserMain.Label8.Caption = Total_FB
'frm_NFS.Label4.Caption = "Center"
' _iNitiAl_IXI_
Case 8:
' Echo streams
SRAPacket(7).Is_New = False
If SRAPacket(7).VAL + 1 <= 255 Then
Call Push2SSS(8, SRAPacket(7).VAL + 1)
Else
Call Push2SSS(8, 0)
End If
' Act a/c to CMD (if feasible) like informing to main program
that LEFT dir is SENT
End Select
'
If UART_RECV_CMD <= 30 Then ' initial_IXI_

If FLAG_CMD_Received = False Then
FLAG_CMD_Received = True
Current_Packet_No = Current_Packet_No - 1
If Current_Packet_No <> 0 Then
Dim i As Integer
For i = 1 To MAX_Packet_Count - 1
SSSPacket(i).CMD = SSSPacket(i + 1).CMD
SSSPacket(i).VAL = SSSPacket(i + 1).VAL
Next i
End If
End If
'
End If
End Sub
_________________________________________________________________
Page - 117
Public Sub Push2SSS(Command As Byte, Value As Byte)

'
SSS=Serial Send Stack
If Current_Packet_No = MAX_Packet_Count Then
'MsgBox "Program went on partial forbidden location, SSS is full.
(Code: SSSF)"
'frm_SSSF.Show
'initial_IXI_
Debug.Print "SSS Full"
Else
Current_Packet_No = Current_Packet_No + 1
SSSPacket(Current_Packet_No).CMD = Command
SSSPacket(Current_Packet_No).VAL = Value
End If
End Sub
Private Sub Timer_UpdSSSList_Timer()
Timer_UpdSSSList.Interval = VAL(frm_DeBugMain.txt_SSS_Upd_Time)
Dim i As Integer
For i = 1 To MAX_Packet_Count
frm_DeBugMain.lst_SSS_CMD.List(i) = SSSPacket(i).CMD
frm_DeBugMain.lst_SSS_VAL.List(i) = SSSPacket(i).VAL
Next i
frm_DeBugMain.lbl_Current_Packet_No.Caption = Current_Packet_No
End Sub
' _iNitial_IXI_:
Public Sub Update_Number()
frm_UserMain.lbl_COMM.Caption = Current_Packet_No
End Sub
-: frm_NFS :Option Explicit

Dim obj_Speedometer As New SpeedometerGauge
Dim
Dim
Dim
Dim
Dim
Up_Disabled As Boolean
Down_Disabled As Boolean
Right_Disabled As Boolean
Left_Disabled As Boolean
PWM_Speed As Byte
Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)

Label1 = KeyCode
Select Case KeyCode
Case vbKeyAdd:
If PWM_Speed < 255 Then
PWM_Speed = PWM_Speed + 1
_________________________________________________________________
Page - 118
Label3.Caption = PWM_Speed
'
Call frm_MSComm.Push2SSS(12, PWM_Speed)
End If
Case vbKeySubtract
If PWM_Speed > 0 Then
PWM_Speed = PWM_Speed - 1
'
End If
Case vbKeyUp:
If Up_Disabled = True Then Exit Sub
Down_Disabled = True
Up_Disabled = True
Call frm_MSComm.Push2SSS(10, 1)
Case vbKeyDown:
If Down_Disabled = True Then Exit Sub
Up_Disabled = True
Case vbKeyLeft:
If Left_Disabled = True Then Exit Sub
Right_Disabled = True
Left_Disabled = True
Case vbKeyRight:
If Right_Disabled = True Then Exit Sub
End Select
End Sub

Label2 = KeyCode
Select Case KeyCode
Case vbKeyUp:
Up_Disabled = False
_________________________________________________________________
Page - 119
Case vbKeyDown:
Up_Disabled = False
Case vbKeyLeft:
Right_Disabled = False
Left_Disabled = False
Case vbKeyRight:
Case vbKeyC:
Call CaptureSS
End Select
End Sub
'frm_MSComm.MSComm1.Settings = UGV_Baud & ",n,8,1"
PWM_Speed = CAR_MAX_SPEED
obj_Speedometer.Setup picSpeedometer, 0, 150
obj_Speedometer.Value = 0
'OutFile To_MATLAB_File, Terminate_Application_Code
'OutFile To_MATLAB_File, Preview_Vid_Code
End Sub

'OutFile To_MATLAB_File, Close_Vid_Code
End Sub
Public Sub Update_RPM()
obj_Speedometer.Value = Actual_Feedback * 100000 / 100
End Sub
Private Sub CaptureSS()
Call TakeSS
' Wait (intentionally) to let matlab get SS.
Dim TempStr As String
Dim FNum As Integer
FNum = FreeFile
SS_REPEAT:
On Error GoTo ErrH_SS
Open To_MATLAB_File For Input As #FNum
_________________________________________________________________
Page - 120
Line Input #FNum, TempStr

Close #FNum
On Error GoTo 0
If TempStr = Command_Received_Code Then
img_SS.Picture = LoadPicture(Snapshot_Folder & "SS" &
Format(SSn, "#") & ".bmp")
Exit Sub
Else
DoEvents
GoTo SS_REPEAT
End If
ErrH_SS:
Close #FNum
DoEvents
DoEvents
DoEvents
DoEvents
DoEvents
DoEvents
DoEvents
Open To_MATLAB_File For Input As #FNum
Resume
End Sub
Private Sub picSpeedometer_KeyDown(KeyCode As Integer, Shift As
Integer)
Call Form_KeyDown(KeyCode, Shift)
End Sub
Private Sub picSpeedometer_KeyUp(KeyCode As Integer, Shift As
Integer)
Call Form_KeyUp(KeyCode, Shift)
End Sub
-: frm_UGVMain :Option Explicit

Load frm_MSComm
'frm_MSComm.Hide
'frm_MSComm.Show
Me.Hide
Timer_GetFB.Interval = TIME_Get_FB
Timer_AvgFB.Interval = TIME_Avg_FB
End Sub
Private Sub Poll_Timer()
'initial_IXI_
'SEND_Poll_Timer.Enabled = False
_________________________________________________________________
Page - 121
Call frm_MSComm.UART_SEND_Poll
' _iNitiAl_IXI_:
Call frm_MSComm.Update_Number
End Sub
' ********** UGV Main Feedback Handler **********

Private Sub Timer_GetFB_Timer()
If DeBug_Mode Then Timer_GetFB.Interval =
VAL(frm_DeBugMain.txt_Get_FB_Time)
End Sub
Private Sub Timer_AvgFB_Timer()
If DeBug_Mode Then Timer_AvgFB.Interval =
VAL(frm_DeBugMain.txt_Avg_FB_Time)
If FBcnt <> 0 Then
Dim d As Double
d = FBcnt
FeedBack = Total_FB / d
Else
FeedBack = old_Feedback
End If
'FeedBack = SRAPacket(6).VAL
If DeBug_Mode Then frm_DeBugMain.lbl_FBcnt.Caption = FBcnt
FBcnt = 0: Total_FB = 0
old_Feedback = FeedBack
' Get delta time for to be used in different areas of project.
Current_Time = Get_Sys_Time() * 1000
Actual_Feedback = Calc_FB(FeedBack)
frm_UserMain.Label9.Caption = Current_Time
frm_UserMain.Label10.Caption = Actual_Feedback
_iNitiAl_IXI_
' _iNitiAl_IXI_
'
If DeBug_Mode Then Call frm_DeBugMain.UpdateGrapher

If DeBug_Mode And DeBug_PDP Then Call frm_PreDefPath.Runtime
If Not DeBug_Mode Then Call frm_UserMain.Runtime
' Reset time for next delta time approach
Call Reset_Sys_Time
End Sub
_________________________________________________________________
Page - 122
-: frm_UserMain :Option Explicit

Dim UGV_Mode As Integer
Const UGV_Navigation = 1
Const UGV_Auto_Drive = 2
'Dim obj_Speedometer As New SpeedometerGauge
' Navigation Mode variables
Dim Up_Disabled As Boolean
Dim Down_Disabled As Boolean
Dim Right_Disabled As Boolean
Dim Left_Disabled As Boolean
Dim PWM_Speed As Byte
' Autonomous Mode variables
Dim Target_Red As Integer
Dim Target_Green As Integer
Dim Target_Blue As Integer
Dim Target_Th As Integer
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
Const
Const
Const
Const
Const
Const
Const
Const
Const
Const
Const
Const
cSTOP = 0
cSTEP1 = 1
cSTEP2 = 2
cSTEP3 = 3
cSTEP4 = 4
cSTEP5 = 5
cSTEP6 = 6
cSTEP7 = 7
cSTEP8 = 8
cSTEP9 = 9
cSTEP10 = 10
cSTEP11 = 11
Dim Final_STEP As Integer

Dim Local_Task As Integer
Dim Total_Distance As Double
Dim Covered_Distance As Double
Dim Result As Boolean
Public Sub Runtime()

If UGV_Mode = UGV_Navigation Then
' Display meters/sec. But Actual_Feedback is in cms/ms
' obj_Speedometer.Value = Actual_Feedback
_________________________________________________________________
'
Page - 123
Call frm_NFS.Update_RPM
Label4.Caption = Actual_Feedback * 100000 / 100
End If
If UGV_Mode = UGV_Auto_Drive Then
Select Case Local_Task
Case cSTOP:
Case cSTEP1:
' Go straight
Result = Go_Straight(Actual_Feedback, Current_Time,
Covered_Distance, Total_Distance)
If Result Then
Covered_Distance = 0
lbl_Error.Caption = "Turning on Segment 2."
Local_Task = cSTEP2
Call frm_MSComm.Push2SSS(CMD_Motor_RIGHT, 1)
End If
Case cSTEP2:
' Go right, angled for 90 degrees
Result = Go_Right(Actual_Feedback, Current_Time,
Covered_Distance)
If Result Then
lbl_Error.Caption = "Straight on Segment 3."
Total_Distance = cSegment3Dist
Local_Task = cSTEP3
Call frm_MSComm.Push2SSS(CMD_Motor_CENTER, 1)
Call frm_MSComm.Push2SSS(CMD_Motor_PWM,
CAR_MAX_SPEED)
End If
Case cSTEP3:
' Go straight
If Result Then
Local_Task = cSTEP4
End If
Case cSTEP4:
' Turn
Covered_Distance)
If Result Then
Local_Task = cSTEP5
CAR_MAX_SPEED)
End If
_________________________________________________________________
Page - 124
Case cSTEP5:
' Go straight
If Result Then
Local_Task = cSTEP6
CAR_MAX_SPEED)
End If
Case cSTEP6:
' straight
If Result Then
Local_Task = cSTEP7
End If
Case cSTEP7:
' Turn
Covered_Distance)
If Result Then
Local_Task = cSTEP8
CAR_MAX_SPEED)
End If
Case cSTEP8:
' Straight
If Result Then
Local_Task = cSTEP9
End If
Case cSTEP9:
' Turn
Covered_Distance)
If Result Then
Local_Task = cSTEP10
_________________________________________________________________
Page - 125
CAR_MAX_SPEED)
End If
Case cSTEP10:
'Straight
If Result Then
lbl_Error.Caption = "Stopping on Segment 11."
Call frm_MSComm.Push2SSS(CMD_Motor_PWM, 0)
End If
Case cSTEP11:
' Stop
'
'
If Result Then
lbl_Error.Caption = "Stopping on Segment 11."
'
End If
End Select
If (Local_Task >= Final_STEP) And (Local_Task <> 0) Then Call
Check_Destination
End If
End Sub
Private Sub Check_Destination()
' After target is achieved, reset all parameters used.
Local_Task = cSTOP
cmd_Start_Auto.Enabled = True
opt_1.Enabled = True
DoEvents
' Wait 1000 ms
Call Reset_Sys_Time
Do
DoEvents
Loop Until (Current_Time > 1000)
_________________________________________________________________
Page - 126
' Load illogical value (eg 101) in output (observed for image
percent match)
OutFile To_UGV_File, Str(101)
' Initiate command to process image with TARGET variables
Dim FNum As Integer
FNum = FreeFile
Open To_MATLAB_File For Output As #FNum
Print #FNum, Process_Image_Code
Print #FNum, Str(Target_Th)
Print #FNum, Str(Target_Red)
Print #FNum, Str(Target_Green)
Print #FNum, Str(Target_Blue)
Close #FNum
Label4.Caption
Label5.Caption
Label6.Caption
Label7.Caption
=
=
=
=
Target_Red
Target_Green
Target_Blue
Target_Th
Call Reset_Sys_Time
'
' Loop "forever" until result <> 101. (or if systime > 1000ms)
Dim Int_Result As Integer
Dim Str_Result As String
Do
DoEvents
InFile To_UGV_File, Str_Result
Int_Result = VAL(Str_Result)
Loop Until ((Int_Result <> 101) And (Current_Time > 1000))
Loop Until (Int_Result <> 101)
If Current_Time > 1000 Then lbl_Error.Caption = "Malfunction

Error!. Time Elapsed.": Exit Sub
'MsgBox Int_Result
If Int_Result < Target_Match_Percent Then
lbl_Error.Caption = "Malfunction Error!. Destination not
reached. Match Percentage is: " & Str(Int_Result)
' _iNitiAl_IXI_
'
Call cmd_NavMode_Click
Else
lbl_Error.Caption = "Target Reached. Percent Match: " &
Str(Int_Result)
End If
End Sub
' ******* UGV Automated Mode Coding (START) *******

Private Sub cmd_AutoMode_Click()
UGV_Mode = UGV_Auto_Drive
cmd_AutoMode.Enabled = False
_________________________________________________________________
Page - 127
frame_CAM.Visible = True
frame_CNM.Visible = False
lbl_Error.Caption = "Click Start."
End Sub
Private Sub cmd_Start_Auto_Click()
frm_NFS.Hide
cmd_Start_Auto.Enabled = False
opt_1.Enabled = False
' Drive UGV on 1st segment
lbl_Error.Caption = "Going straight on Segment 1."
Local_Task = cSTEP1
Call frm_MSComm.Push2SSS(CMD_Motor_FWD, 0)
Call frm_MSComm.Push2SSS(CMD_Motor_PWM, CAR_MAX_SPEED)
If opt_1.Value Then
Target_Red = Target1_Red
Target_Green = Target1_Green
Target_Blue = Target1_Blue
Target_Th = Target1_Th
Final_STEP = cSTEP11
End If
If opt_2.Value Then
Final_STEP = cSTEP6
End If
If opt_3.Value Then
Final_STEP = cSTEP1
End If
End Sub
' ******* UGV Automated Mode Coding (END) *******
' ******* _iNitiAl_IXI_: COMMENTED IS FINE. *******

' Use only for forced debug
'Private Sub cmd_DebugMode_Click()
'
UGV_Mode = UGV_Navigation
'
frame_CAM.Visible = False
'
frame_CNM.Visible = True
_________________________________________________________________
Page - 128
'
frm_DeBugMain.Show
'
DeBug_Mode = True
'End Sub
' ******* UGV Navigation Mode Coding (START) *******

Private Sub cmd_NavMode_Click()
UGV_Mode = UGV_Navigation
frame_CAM.Visible = False
'
frame_CNM.Visible = True
Local_Task = cSTOP
cmd_Start_Auto.Enabled = True
cmd_AutoMode.Enabled = True
DoEvents
frm_NFS.Show
End Sub
Private Sub scrl_Percent_Speed_Change()

PWM_Speed = scrl_Percent_Speed.Value * 2.55
End Sub
Private Sub KeyDown(KeyCode As Integer)
If UGV_Mode <> UGV_Navigation Then Exit Sub
Select Case KeyCode
Case vbKeyUp:
If Up_Disabled = True Then Exit Sub
Up_Disabled = True
Case vbKeyDown:
If Down_Disabled = True Then Exit Sub
Up_Disabled = True
Case vbKeyLeft:
_________________________________________________________________
Page - 129
If Left_Disabled = True Then Exit Sub

Case vbKeyRight:
If Right_Disabled = True Then Exit Sub
End Select
End Sub
Private Sub KeyUp(KeyCode As Integer)
If UGV_Mode <> UGV_Navigation Then Exit Sub
Select Case KeyCode
Case vbKeyUp:
Up_Disabled = False
Case vbKeyDown:
Up_Disabled = False
Case vbKeyLeft:
Case vbKeyRight:
End Select
End Sub
Private Sub scrl_Percent_Speed_KeyUp(KeyCode As Integer, Shift As
Integer)
Call KeyUp(KeyCode)
End Sub
Private Sub cmd_NavMode_KeyDown(KeyCode As Integer, Shift As Integer)
Call KeyDown(KeyCode)
End Sub
Private Sub cmd_NavMode_KeyUp(KeyCode As Integer, Shift As Integer)
Call KeyUp(KeyCode)
End Sub
Private Sub cmd_AutoMode_KeyDown(KeyCode As Integer, Shift As
Integer)
End Sub
Private Sub cmd_AutoMode_KeyUp(KeyCode As Integer, Shift As Integer)
_________________________________________________________________
Page - 130
Call KeyUp(KeyCode)
End Sub
Private Sub cmd_DebugMode_KeyDown(KeyCode As Integer, Shift As
Integer)
End Sub
Private Sub cmd_DebugMode_KeyUp(KeyCode As Integer, Shift As Integer)
Call KeyUp(KeyCode)
End Sub
Private Sub cmd_CaptureSS_KeyDown(KeyCode As Integer, Shift As
Integer)
End Sub
Private Sub cmd_CaptureSS_KeyUp(KeyCode As Integer, Shift As Integer)
Call KeyUp(KeyCode)
End Sub
Private Sub cmd_EN_Vision_KeyDown(KeyCode As Integer, Shift As
Integer)
End Sub
Private Sub cmd_EN_Vision_KeyUp(KeyCode As Integer, Shift As Integer)
Call KeyUp(KeyCode)
End Sub
Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
End Sub
Call KeyUp(KeyCode)
End Sub
Private Sub cmd_EN_Vision_Click()
If cmd_EN_Vision.Caption = "Enable Car Vision" Then
OutFile To_MATLAB_File, Preview_Vid_Code
cmd_EN_Vision.Caption = "Disable Car Vision"
Else
OutFile To_MATLAB_File, Close_Vid_Code
cmd_EN_Vision.Caption = "Enable Car Vision"
End If
End Sub
' ******** UGV Navigation Mode Coding (END) *********
'
obj_Speedometer.Setup picSpeedometer, 0, Max_UGV_RPM
End Sub
OutFile To_MATLAB_File, Terminate_Application_Code
End
End Sub
_________________________________________________________________
Page - 131
APPENDIX E
MATLAB
SOURCE CODES
_________________________________________________________________
Page - 132
%function [image,index]=find_color(image,map,tr,colors)
function [my_ans, my_percent]=find_color(image,map,tr,colors)
%[IMAGE,IND]=FIND_COLOR(A,MAP,THRESHOLD,COLOR VECTOR)
%Finds a color of an Image A and returns IMAGE, the
%original image with the pixels with the specified color set
%to zero, and IND, an index to the pixels that are were
%equal to the selected color.
%
%MAP is the input if the image is indexed, if the image is not
indexed
%enter empty brackerts ( [] ), TR is the threshold tolerance for the
%color range, COLOR VECTOR is an additional argument that takes
%in the hard-coded values for the color, use empty brackects ( [] )
%if you wish to select the color from the origimal image using the
mouse.
[my_ans, my_percent]= getcolor(image,colors,tr);

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function [my_ans, my_percent]=getcolor(image,color,tr)

[i j k]=size(image);
R=color(1,1);
G=color(1,2);
B=color(1,3);
I=double(image);
my_ans=0;
for (a=1:i)
for (b=1:j)
%for (a=1:2:i)
for (b=1:2:j)
if ((abs(I(a,b,1)-R) <tr ) && ( abs(I(a,b,2)-G) <tr ) && (
abs(I(a,b,3)-B) <tr ))
tic;
if ((abs(image(a,b,1)-R) <tr ) && ( abs(image(a,b,2)-G) <tr )
&& ( abs(image(a,b,3)-B) <tr ))
my_ans=my_ans+1;
end
toc
end
end
my_percent=(my_ans/(i*j))*100;
_________________________________________________________________
Page - 133
CALLING MATLAB COM LIBRARY FROM VB6

Option Explicit
Private Sub Timer_FileCHK_Timer()
Dim UGV_Command As String
InFile From_UGV_File, UGV_Command
Select Case UGV_Command
Case Preview_Vid_Code: Call Preview_Vidobj
Case Close_Vid_Code: Call Stop_Vidobj
Case Process_Image_Code: Call Prcss_IMG
Case Take_Snapshot_Code: Call Take_SS
Case Command_Received_Code: Exit Sub
Case Terminate_Application_Code:
OutFile From_UGV_File, Command_Received_Code
OutFile From_MATLAB_File, " "
End
Case Else: Exit Sub
End Select
OutFile From_UGV_File, Command_Received_Code
End Sub
MODULE:
Option Explicit
Public Const To_MATLAB_File = "MFile.txt"
Public Const From_UGV_File = "MFile.txt"
Public Const To_UGV_File = "UGVFile.txt"
Public Const From_MATLAB_File = "UGVFile.txt"
Public
Public
Public
Public
Public
Public
Public
Const
Const
Const
Const
Const
Const
Const
MATLAB_init_code = "MATLAB Initialized"

Preview_Vid_Code = "Preview Video"
Close_Vid_Code = "Close Video"
Process_Image_Code = "Process Image"
Take_Snapshot_Code = "Take Snapshot"
Command_Received_Code = "Command Received"
Terminate_Application_Code = "END"
Private Matlab As Object

Private MatlabCommand As String
Private MatlabResult As String
Sub Main()
Call init_Matlab
OutFile To_UGV_File, MATLAB_init_code
Load frm_Main
End Sub
_________________________________________________________________
Page - 134
Private Sub init_Matlab()

'
frm_Splash.lbl_LoadStatus.Caption = "Starting Matlab...."
Set Matlab = CreateObject("MatLab.Application")
'
Matlab.Visible = False ' Hide the matlab window
'
frm_Splash.lbl_LoadStatus.Caption = "Initializing frame grabber
device...."
MatlabCommand = "cd '" & CurDir & "'"
Debug.Print MatlabResult
MatlabCommand = "vidobj = videoinput('winvideo', 1,
'RGB555_768x576')"
MatlabCommand = "selectedsrc = getselectedsource(vidobj)"
MatlabCommand = "selectedsrc.AnalogVideoFormat='pal_b'"
MatlabCommand = "selectedsrc.Contrast=9000"
MatlabCommand = "selectedsrc.Brightness=6500"
MatlabCommand = "selectedsrc.Saturation=9000"
MatlabCommand = "triggerconfig(vidobj, 'manual')"
MatlabCommand = "start(vidobj)"
OutFile To_UGV_File, MATLAB_init_code
End Sub
Public Sub Preview_Vidobj()
MatlabCommand = "vidRes = get(vidobj, 'VideoResolution');"
_________________________________________________________________
Page - 135
MatlabCommand = "nBands = get(vidobj, 'NumberOfBands');"

MatlabCommand = "hImage = image( zeros(vidRes(2), vidRes(1),
nBands) );"
MatlabCommand = "preview(vidobj, hImage);"
End Sub
Public Sub Stop_Vidobj()
MatlabCommand = "close;"
End Sub
Public Sub Prcss_IMG()
Dim Tr As Byte
Dim TargetRED As Byte
Dim TargetGREEN As Byte
Dim TargetBLUE As Byte
Dim Color_Perc As Double
Dim MReal() As Double
Dim MImag() As Double
Dim Temp As String
Dim FNum As Integer
FNum = FreeFile
Open From_UGV_File For Input As #FNum
Line Input #FNum, Temp
Line Input #FNum, Temp: Tr = Val(Temp)
Line Input #FNum, Temp: TargetRED = Val(Temp)
Line Input #FNum, Temp: TargetGREEN = Val(Temp)
Line Input #FNum, Temp: TargetBLUE = Val(Temp)
Close #FNum
MatlabCommand = "snapshot = getsnapshot(vidobj);"
'Debug.Print Result
MatlabCommand = "[Mat_Ans Mat_Perc] = our_color_test (snapshot,
[], " & Str(Tr) _
& ", [" & Str(TargetRED) & Chr(vbKeySpace) &
Str(TargetGREEN) & Chr(vbKeySpace) & Str(TargetBLUE) & "])"
'Debug.Print Result
MatlabResult = Matlab.GetFullMatrix("Mat_Perc", "base", MReal,
MImag)
Color_Perc = MReal(0, 0)
_________________________________________________________________
Page - 136
OutFile To_UGV_File, Str(Color_Perc)

End Sub
Public Sub Take_SS()
Dim SSFile As String
Dim FNum As Integer
FNum = FreeFile
Open From_UGV_File For Input As #FNum
Line Input #FNum, SSFile
Line Input #FNum, SSFile
Close #FNum
MatlabCommand = "snapshot = getsnapshot(vidobj);"
MatlabCommand = "imwrite (snapshot,'" & SSFile & "', 'bmp');"
End Sub
Public Sub OutFile(FName As String, FStr As String)
Dim FNum As Integer
FNum = FreeFile
On Error GoTo Err_H1
Open FName For Output As #FNum
Print #FNum, FStr
Close #FNum
On Error GoTo 0
Exit Sub
'
Close #10
DoEvents
Beep
Resume
End Sub
Public Sub InFile(FName As String, ByRef FStr As String)
Dim FNum As Integer
FNum = FreeFile
Open FName For Input As #FNum
Line Input #FNum, FStr
Close #FNum
On Error GoTo 0
Exit Sub
End Sub
_________________________________________________________________
Page - 137
APPENDIX F
DATASHEETS
_________________________________________________________________
www.fairchildsemi.com
LM317
3-Terminal Positive Adjustable Regulator

Features
Description
This monolithic integrated circuit is an adjustable 3-terminal

positive voltage regulator designed to supply more than 1.5A
of load current with an output voltage adjustable over a 1.2
to 37V. It employs internal current limiting, thermal
shut-down and safe area compensation.
Output Current In Excess of 1. 5A

Output Adjustable Between 1. 2V and 37V
Internal Thermal Overload Protection
Internal Short Circuit Current Limiting
Output Transistor Safe Operating Area Compensation
TO-220 Package
TO-220
1. Adj 2. Output 3. Input
Internal Block Diagram

Vin 3
Input
+
-
Voltage
Reference
Protection
Circuitry
Rlimit
2 Vo
Output
1
Adj
Vadj
Rev. 1.0.0
2001 Fairchild Semiconductor Corporation
LM317
Absolute Maximum Ratings

Parameter
Symbol
Value
Unit
Input-Output Voltage Differential
V I - VO
40
Lead Temperature
TLEAD
230
Power Dissipation
PD
Internally limited
Operating Junction Temperature Range
Tj
0 ~ +125
TSTG
-65 ~+125
Vo/T
0.02
%/C
Storage Temperature Range

Temperature Coefficient of Output Voltage
Electrical Characteristics
(VI-VO=5V, IO= 0.5A, 0C TJ + 125C, IMAX = 1.5A, PDMAX = 20W, unless otherwise specified)
Parameter
Line Regulation (Note1)
Load Regulation (Note1)
Symbol
Rline
Rload
Conditions
Min
Typ.
Max.
Unit
TA = +25C
3V VI - VO 40V
0.01
0.04
%/V
3V VI - VO 40V
0.02
0.07
%/V
TA = +25C, 10mA IO IMAX

VO< 5V
VO 5V
18
0.4
25
0.5
mV% / VO
10mA IO IMAX
VO < 5V
VO 5V
40
0.8
70
1.5
mV% / VO
IADJ
46
100
Adjustable Pin Current Change
IADJ
3V VI - VO 40V
10mA IO IMAX PD PMAX
2.0
Reference Voltage
VREF
3V VIN - VO 40V
10mA IO IMAX
PD PMAX
1.20
1.25
1.30
0.7
% / VO
3.5
12
mA
1.0
2.2
0.3
0.003
0.01
% / VO
66
60
75
dB
0.3
C / W
Adjustable Pin Current
Temperature Stability
STT
Minimum Load Current to Maintain

Regulation
IL(MIN)
VI - VO = 40V
Maximum Output Current
IO(MAX)
VI - VO 15V, PD PMAX
VI - VO 40V, PD PMAX
TA=25C
RMS Noise, % of VOUT
eN
TA= +25C, 10Hz f 10KHz
Ripple Rejection
RR
VO = 10V, f = 120Hz
without CADJ
CADJ = 10F (Note2)
ST
TA = +25C for end point

measurements, 1000HR
Long-Term Stability, TJ = THIGH

Thermal Resistance Junction to
Case
RJC
Note:
1. Load and line regulation are specified at constant junction temperature. Change in VD due to heating effects must be taken
into account separately. Pulse testing with low duty is used. (PMAX = 20W)
2. CADJ, when used, is connected between the adjustment pin and ground.
LM317
ADJUSTMENT CURRENT(uA)
OUTPUT VOLTAGE DEVIATION(%)
Typical Perfomance Characteristics
TEMPERATURE (C)
TEMPERATURE (C)
Figure 2. Adjustment Current
REFERENCE VOLTAGE(V)
INPUT-OUTPUT DIFFERENTIAL(V)
Figure 1. Load Regulation
TEMPERATURE (C)
Figure 3. Dropout Voltage
TEMPERATURE (C)
Figure 4. Reference Voltage
LM317
Typical Application
VI
Input
Ci
0. 1
F
VI
LM317
KA317
Output
Vo
Vadj
R1
I adj
Co
1
F
R2 I adj
VO = 1.25V (1+ R 2/ R1)+Iadj R2
Figure 5. Programmable Regulator
Ci is required when regulator is located an appreciable distance from power supply filter.
Co is not needed for stability, however, it does improve transient response.
Since IADJ is controlled to less than 100A, the error associated with this term is negligible in most applications.
LM317
Mechanical Dimensions
Package
TO-220
4.50 0.20
2.80 0.10
(3.00)
+0.10
1.30 0.05
18.95MAX.
(3.70)
3.60 0.10
15.90 0.20
1.30 0.10
(8.70)
(1.46)
9.20 0.20
(1.70)
9.90 0.20
(45
1.52 0.10
0.80 0.10
2.54TYP
[2.54 0.20]
10.08 0.30
(1.00)
13.08 0.20
1.27 0.10
+0.10
0.50 0.05
2.40 0.20
2.54TYP
[2.54 0.20]
10.00 0.20
LM317
Ordering Information
Product Number
Package
Operating Temperature
LM317T
TO-220
0C to + 125C
LM317
DISCLAIMER
FAIRCHILD SEMICONDUCTOR RESERVES THE RIGHT TO MAKE CHANGES WITHOUT FURTHER NOTICE TO ANY
PRODUCTS HEREIN TO IMPROVE RELIABILITY, FUNCTION OR DESIGN. FAIRCHILD DOES NOT ASSUME ANY
LIABILITY ARISING OUT OF THE APPLICATION OR USE OF ANY PRODUCT OR CIRCUIT DESCRIBED HEREIN; NEITHER
DOES IT CONVEY ANY LICENSE UNDER ITS PATENT RIGHTS, NOR THE RIGHTS OF OTHERS.
LIFE SUPPORT POLICY
FAIRCHILDS PRODUCTS ARE NOT AUTHORIZED FOR USE AS CRITICAL COMPONENTS IN LIFE SUPPORT DEVICES
OR SYSTEMS WITHOUT THE EXPRESS WRITTEN APPROVAL OF THE PRESIDENT OF FAIRCHILD SEMICONDUCTOR
CORPORATION. As used herein:
1. Life support devices or systems are devices or systems
which, (a) are intended for surgical implant into the body,
or (b) support or sustain life, and (c) whose failure to
perform when properly used in accordance with
instructions for use provided in the labeling, can be
reasonably expected to result in a significant injury of the
user.
2. A critical component in any component of a life support

device or system whose failure to perform can be
reasonably expected to cause the failure of the life support
device or system, or to affect its safety or effectiveness.
www.fairchildsemi.com
6/1/01 0.0m 001
Stock#DSxxxxxxxx
2001 Fairchild Semiconductor Corporation
L293D
L293DD
PUSH-PULL FOUR CHANNEL DRIVER WITH DIODES
600mA OUTPUT CURRENT CAPABILITY
PER CHANNEL
1.2A PEAK OUTPUT CURRENT (non repetitive) PER CHANNEL
ENABLE FACILITY
OVERTEMPERATURE PROTECTION
LOGICAL 0 INPUT VOLTAGE UP TO 1.5 V
(HIGH NOISE IMMUNITY)
INTERNAL CLAMP DIODES
DESCRIPTION
The Device is a monolithic integrated high voltage, high current four channel driver designed to
accept standard DTL or TTL logic levels and drive
inductive loads (such as relays solenoides, DC
and stepping motors) and switching power transistors.
To simplify use as two bridges each pair of channels is equipped with an enable input. A separate
supply input is provided for the logic, allowing operation at a lower voltage and internal clamp diodes are included.
This device is suitable for use in switching applications at frequencies up to 5 kHz.
SO(12+4+4)
Powerdip (12+2+2)
ORDERING NUMBERS:
L293DD
L293D
The L293D is assembled in a 16 lead plastic

packaage which has 4 center pins connected together and used for heatsinking
The L293DD is assembled in a 20 lead surface
mount which has 8 center pins connected together and used for heatsinking.
BLOCK DIAGRAM
June 1996
1/7
L293D - L293DD
ABSOLUTE MAXIMUM RATINGS
Symbol
Parameter
Value
Unit
VS
Supply Voltage
36
V SS
Logic Supply Voltage
36
Input Voltage
Enable Voltage
Vi
V en
Io
P tot
Tstg, Tj
Peak Output Current (100 s non repetitive)
1.2
40 to 150
Total Power Dissipation at Tpins = 90 C

Storage and Junction Temperature
PIN CONNECTIONS (Top view)
Powerdip(12+2+2)
SO(12+4+4)
THERMAL DATA
Symbol
DIP
SO
Unit
Rth j-pins
Thermal Resistance Junction-pins
Decription
max.
14
C/W
Rth j-amb
Thermal Resistance junction-ambient
max.
80
50 (*)
C/W
Rth j-case
Thermal Resistance Junction-case
max.
14
(*) With 6sq. cm on board heatsink.
2/7
L293D - L293DD
ELECTRICAL CHARACTERISTICS (for each channel, VS = 24 V, VSS = 5 V, Tamb = 25 C, unless
otherwise specified)
Symbol
Parameter
Test Conditions
Min.
Typ.
Max.
Unit
VS
Supply Voltage (pin 10)
VSS
36
V SS
Logic Supply Voltage (pin 20)
4.5
36
IS
Total Quiescent Supply Current

(pin 10)
Vi = L ; IO = 0 ; Ven = H
mA
Vi = H ; IO = 0 ; Ven = H
16
24
mA
Ven = L
ISS
Total Quiescent Logic Supply

Current (pin 20)
Vi = L ; IO = 0 ; Ven = H
44
mA
60
mA
Vi = H ; IO = 0 ; Ven = H
16
22
mA
Ven = L
16
24
mA
0.3
1.5
2.3
VSS
2.3
10
100
0.3
1.5
VSS 7 V
2.3
VSS
VSS > 7 V
2.3
V IL
Input Low Voltage (pin 2, 9, 12,

19)
VIH
Input High Voltage (pin 2, 9,

12, 19)
VSS 7 V
VSS > 7 V
IIL
Low Voltage Input Current (pin

2, 9, 12, 19)
VIL = 1.5 V
IIH
High Voltage Input Current (pin

2, 9, 12, 19)
2.3 V VIH VSS 0.6 V
Ven L
Enable Low Voltage

(pin 1, 11)
Ven H
Enable High Voltage

(pin 1, 11)
Ien L
Low Voltage Enable Current

(pin 1, 11)
Ven L = 1.5 V
Ien H
High Voltage Enable Current

(pin 1, 11)
2.3 V Ven H VSS 0.6 V
VCE(sat)H
Source Output Saturation

Voltage (pins 3, 8, 13, 18)
IO = 0.6 A
VCE(sat)L
Sink Output Saturation Voltage

(pins 3, 8, 13, 18)
VF
30
100
10
1.4
1.8
IO = + 0.6 A
1.2
1.8
Clamp Diode Forward Voltage
IO = 600nA
1.3
tr
Rise Time (*)
0.1 to 0.9 VO
250
ns
tf
Fall Time (*)
0.9 to 0.1 VO
250
ns
ton
Turn-on Delay (*)
0.5 Vi to 0.5 VO
750
ns
toff
Turn-off Delay (*)
0.5 Vi to 0.5 VO
200
ns
30
(*) See fig. 1.
3/7
L293D - L293DD
Figure 1: Switching Times
TRUTH TABLE (one channel)

Inpu t
Enable (*)
Output
H
L
H
L
H
H
L
L
H
L
Z
Z
Z = High output impedance

(*) Relative to the considered channel
Figure 2: Junction to ambient thermal resistance vs. area on board heatsink (SO12+4+4 package)
4/7
L293D - L293DD
POWERDIP16 PACKAGE MECHANICAL DATA
mm
DIM.
MIN.
a1
0.51
0.85
b
b1
TYP.
inch
MAX.
MIN.
TYP.
MAX.
0.020
1.40
0.033
0.50
0.38
0.020
0.50
0.055
0.015
0.020
20.0
0.787
8.80
0.346
2.54
0.100
e3
17.78
0.700
7.10
0.280
5.10
0.201
L
Z
3.30
0.130
1.27
0.050
5/7
L293D - L293DD
SO20 PACKAGE MECHANICAL DATA
mm
DIM.
MIN.
TYP.
A
a1
MIN.
TYP.
2.65
0.1
MAX.
0.104
0.2
a2
0.004
0.008
2.45
0.096
0.35
0.49
0.014
0.019
b1
0.23
0.32
0.009
0.013
0.5
0.020
c1
45
1.772
10
12.6
0.039
10.65
0.394
1.27
0.050
e3
11.43
0.450
7.4
0.496
0.419
0.039
0.291
8.8
9.15
0.346
0.360
0.5
1.27
0.020
0.050
M
S
6/7
inch
MAX.
0.75
0.030
8 (max.)
L293D - L293DD
Information furnished is believed to be accurate and reliable. However, SGS-THOMSON Microelectronics assumes no responsibility for the
consequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. No
license is granted by implication or otherwise under any patent or patent rights of SGS-THOMSON Microelectronics. Specification mentioned
in this publication are subject to change without notice. This publication supersedes and replaces all information previously supplied.
SGS-THOMSON Microelectronics products are not authorized for use as criticalcomponents in life support devices or systems without express
written approval of SGS-THOMSON Microelectronics.
1996 SGS-THOMSON Microelectronics Printed in Italy All Rights Reserved
SGS-THOMSON Microelectronics GROUP OF COMPANIES
Australia - Brazil - Canada - China - France - Germany - Hong Kong - Italy - Japan - Korea - Malaysia - Malta - Morocco - The Netherlands Singapore - Spain - Sweden - Switzerland - Taiwan - Thailand - United Kingdom - U.S.A.
7/7
Features
High-performance, Low-power AVR 8-bit Microcontroller
Advanced RISC Architecture
130 Powerful Instructions Most Single-clock Cycle Execution

32 x 8 General Purpose Working Registers
Fully Static Operation
Up to 16 MIPS Throughput at 16 MHz
On-chip 2-cycle Multiplier
Nonvolatile Program and Data Memories
8K Bytes of In-System Self-Programmable Flash
Endurance: 10,000 Write/Erase Cycles
Optional Boot Code Section with Independent Lock Bits
In-System Programming by On-chip Boot Program
True Read-While-Write Operation
512 Bytes EEPROM
Endurance: 100,000 Write/Erase Cycles
1K Byte Internal SRAM
Programming Lock for Software Security
Peripheral Features
Two 8-bit Timer/Counters with Separate Prescaler, one Compare Mode
One 16-bit Timer/Counter with Separate Prescaler, Compare Mode, and Capture
Mode
Real Time Counter with Separate Oscillator
Three PWM Channels
8-channel ADC in TQFP and MLF package
Six Channels 10-bit Accuracy
Two Channels 8-bit Accuracy
6-channel ADC in PDIP package
Four Channels 10-bit Accuracy
Two Channels 8-bit Accuracy
Byte-oriented Two-wire Serial Interface
Programmable Serial USART
Master/Slave SPI Serial Interface
Programmable Watchdog Timer with Separate On-chip Oscillator
On-chip Analog Comparator
Special Microcontroller Features
Power-on Reset and Programmable Brown-out Detection
Internal Calibrated RC Oscillator
External and Internal Interrupt Sources
Five Sleep Modes: Idle, ADC Noise Reduction, Power-save, Power-down, and
Standby
I/O and Packages
23 Programmable I/O Lines
28-lead PDIP, 32-lead TQFP, and 32-pad MLF
Operating Voltages
2.7 - 5.5V (ATmega8L)
4.5 - 5.5V (ATmega8)
Speed Grades
0 - 8 MHz (ATmega8L)
0 - 16 MHz (ATmega8)
Power Consumption at 4 Mhz, 3V, 25C
Active: 3.6 mA
Idle Mode: 1.0 mA
Power-down Mode: 0.5 A
8-bit
with 8K Bytes
In-System
Programmable
Flash
ATmega8
ATmega8L
Summary
Rev. 2486MSAVR12/03
Note: This is a summary document. A complete document

is available on our Web site at www.atmel.com.
Pin Configurations
PDIP
(RESET) PC6
(RXD) PD0
(TXD) PD1
(INT0) PD2
(INT1) PD3
(XCK/T0) PD4
VCC
GND
(XTAL1/TOSC1) PB6
(XTAL2/TOSC2) PB7
(T1) PD5
(AIN0) PD6
(AIN1) PD7
(ICP1) PB0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
28
27
26
25
24
23
22
21
20
19
18
17
16
15
PC5 (ADC5/SCL)
PC4 (ADC4/SDA)
PC3 (ADC3)
PC2 (ADC2)
PC1 (ADC1)
PC0 (ADC0)
GND
AREF
AVCC
PB5 (SCK)
PB4 (MISO)
PB3 (MOSI/OC2)
PB2 (SS/OC1B)
PB1 (OC1A)
32
31
30
29
28
27
26
25
PD2 (INT0)
PD1 (TXD)
PD0 (RXD)
PC6 (RESET)
PC5 (ADC5/SCL)
PC4 (ADC4/SDA)
PC3 (ADC3)
PC2 (ADC2)
TQFP Top View
1
2
3
4
5
6
7
8
24
23
22
21
20
19
18
17
PC1 (ADC1)
PC0 (ADC0)
ADC7
GND
AREF
ADC6
AVCC
PB5 (SCK)
24
23
22
21
20
19
18
17
PC1 (ADC1)
PC0 (ADC0)
ADC7
GND
AREF
ADC6
AVCC
PB5 (SCK)
(T1) PD5
(AIN0) PD6
(AIN1) PD7
(ICP1) PB0
(OC1A) PB1
(SS/OC1B) PB2
(MOSI/OC2) PB3
(MISO) PB4
9
10
11
12
13
14
15
16
(INT1) PD3
(XCK/T0) PD4
GND
VCC
GND
VCC
(XTAL1/TOSC1) PB6
(XTAL2/TOSC2) PB7
32
31
30
29
28
27
26
25
PD2 (INT0)
PD1 (TXD)
PD0 (RXD)
PC6 (RESET)
PC5 (ADC5/SCL)
PC4 (ADC4/SDA)
PC3 (ADC3)
PC2 (ADC2)
MLF Top View
1
2
3
4
5
6
7
8
(T1) PD5
(AIN0) PD6
(AIN1) PD7
(ICP1) PB0
(OC1A) PB1
(SS/OC1B) PB2
(MOSI/OC2) PB3
(MISO) PB4
9
10
11
12
13
14
15
16
(INT1) PD3
(XCK/T0) PD4
GND
VCC
GND
VCC
(XTAL1/TOSC1) PB6
(XTAL2/TOSC2) PB7
ATmega8(L)
2486MSAVR12/03
ATmega8(L)
Overview
The ATmega8 is a low-power CMOS 8-bit microcontroller based on the AVR RISC
architecture. By executing powerful instructions in a single clock cycle, the ATmega8
achieves throughputs approaching 1 MIPS per MHz, allowing the system designer to
optimize power consumption versus processing speed.
Block Diagram
Figure 1. Block Diagram

XTAL1
RESET
PC0 - PC6
PB0 - PB7
VCC
XTAL2
GND
PORTC DRIVERS/BUFFERS
PORTB DRIVERS/BUFFERS
PORTC DIGITAL INTERFACE
PORTB DIGITAL INTERFACE
MUX &
ADC
ADC
INTERFACE
PROGRAM
COUNTER
STACK
POINTER
PROGRAM
FLASH
SRAM
TWI
AGND
AREF
INSTRUCTION
REGISTER
GENERAL
PURPOSE
REGISTERS
TIMERS/
COUNTERS
OSCILLATOR
INTERNAL
OSCILLATOR
WATCHDOG
TIMER
OSCILLATOR
X
INSTRUCTION
DECODER
MCU CTRL.
& TIMING
CONTROL
LINES
ALU
INTERRUPT
UNIT
AVR CPU
STATUS
REGISTER
EEPROM
PROGRAMMING
LOGIC
SPI
USART
+
-
COMP.
INTERFACE
PORTD DIGITAL INTERFACE
PORTD DRIVERS/BUFFERS
PD0 - PD7
3
2486MSAVR12/03
The AVR core combines a rich instruction set with 32 general purpose working registers.
All the 32 registers are directly connected to the Arithmetic Logic Unit (ALU), allowing
two independent registers to be accessed in one single instruction executed in one clock
cycle. The resulting architecture is more code efficient while achieving throughputs up to
ten times faster than conventional CISC microcontrollers.
The ATmega8 provides the following features: 8K bytes of In-System Programmable
Flash with Read-While-Write capabilities, 512 bytes of EEPROM, 1K byte of SRAM, 23
general purpose I/O lines, 32 general purpose working registers, three flexible
Timer/Counters with compare modes, internal and external interrupts, a serial programmable USART, a byte oriented Two-wire Serial Interface, a 6-channel ADC (eight
channels in TQFP and MLF packages) where four (six) channels have 10-bit accuracy
and two channels have 8-bit accuracy, a programmable Watchdog Timer with Internal
Oscillator, an SPI serial port, and five software selectable power saving modes. The Idle
mode stops the CPU while allowing the SRAM, Timer/Counters, SPI port, and interrupt
system to continue functioning. The Power-down mode saves the register contents but
freezes the Oscillator, disabling all other chip functions until the next Interrupt or Hardware Reset. In Power-save mode, the asynchronous timer continues to run, allowing the
user to maintain a timer base while the rest of the device is sleeping. The ADC Noise
Reduction mode stops the CPU and all I/O modules except asynchronous timer and
ADC, to minimize switching noise during ADC conversions. In Standby mode, the crystal/resonator Oscillator is running while the rest of the device is sleeping. This allows
very fast start-up combined with low-power consumption.
The device is manufactured using Atmels high density non-volatile memory technology.
The Flash Program memory can be reprogrammed In-System through an SPI serial
interface, by a conventional non-volatile memory programmer, or by an On-chip boot
program running on the AVR core. The boot program can use any interface to download
the application program in the Application Flash memory. Software in the Boot Flash
Section will continue to run while the Application Flash Section is updated, providing
true Read-While-Write operation. By combining an 8-bit RISC CPU with In-System SelfProgrammable Flash on a monolithic chip, the Atmel ATmega8 is a powerful microcontroller that provides a highly-flexible and cost-effective solution to many embedded
control applications.
The ATmega8 AVR is supported with a full suite of program and system development
tools, including C compilers, macro assemblers, program debugger/simulators, In-Circuit Emulators, and evaluation kits.
Disclaimer
Typical values contained in this datasheet are based on simulations and characterization of other AVR microcontrollers manufactured on the same process technology. Min
and Max values will be available after the device is characterized.
ATmega8(L)
2486MSAVR12/03
ATmega8(L)
Pin Descriptions
VCC
Digital supply voltage.
GND
Ground.
Port B (PB7..PB0) XTAL1/

XTAL2/TOSC1/TOSC2
Port B is an 8-bit bi-directional I/O port with internal pull-up resistors (selected for each
bit). The Port B output buffers have symmetrical drive characteristics with both high sink
and source capability. As inputs, Port B pins that are externally pulled low will source
current if the pull-up resistors are activated. The Port B pins are tri-stated when a reset
condition becomes active, even if the clock is not running.
Depending on the clock selection fuse settings, PB6 can be used as input to the inverting Oscillator amplifier and input to the internal clock operating circuit.
Depending on the clock selection fuse settings, PB7 can be used as output from the
inverting Oscillator amplifier.
If the Internal Calibrated RC Oscillator is used as chip clock source, PB7..6 is used as
TOSC2..1 input for the Asynchronous Timer/Counter2 if the AS2 bit in ASSR is set.
The various special features of Port B are elaborated in Alternate Functions of Port B
on page 56 and System Clock and Clock Options on page 23.
Port C (PC5..PC0)
Port C is an 7-bit bi-directional I/O port with internal pull-up resistors (selected for each
bit). The Port C output buffers have symmetrical drive characteristics with both high sink
and source capability. As inputs, Port C pins that are externally pulled low will source
current if the pull-up resistors are activated. The Port C pins are tri-stated when a reset
PC6/RESET
If the RSTDISBL Fuse is programmed, PC6 is used as an I/O pin. Note that the electrical characteristics of PC6 differ from those of the other pins of Port C.
If the RSTDISBL Fuse is unprogrammed, PC6 is used as a Reset input. A low level on
this pin for longer than the minimum pulse length will generate a Reset, even if the clock
is not running. The minimum pulse length is given in Table 15 on page 36. Shorter
pulses are not guaranteed to generate a Reset.
The various special features of Port C are elaborated on page 59.
Port D (PD7..PD0)
Port D is an 8-bit bi-directional I/O port with internal pull-up resistors (selected for each
bit). The Port D output buffers have symmetrical drive characteristics with both high sink
and source capability. As inputs, Port D pins that are externally pulled low will source
current if the pull-up resistors are activated. The Port D pins are tri-stated when a reset
Port D also serves the functions of various special features of the ATmega8 as listed on
page 61.
RESET
Reset input. A low level on this pin for longer than the minimum pulse length will generate a reset, even if the clock is not running. The minimum pulse length is given in Table
15 on page 36. Shorter pulses are not guaranteed to generate a reset.
5
2486MSAVR12/03
AVCC
AVCC is the supply voltage pin for the A/D Converter, Port C (3..0), and ADC (7..6). It
should be externally connected to VCC, even if the ADC is not used. If the ADC is used,
it should be connected to VCC through a low-pass filter. Note that Port C (5..4) use digital
supply voltage, VCC.
AREF
AREF is the analog reference pin for the A/D Converter.
ADC7..6 (TQFP and MLF

Package Only)
In the TQFP and MLF package, ADC7..6 serve as analog inputs to the A/D converter.
These pins are powered from the analog supply and serve as 10-bit ADC channels.
ATmega8(L)
2486MSAVR12/03
ATmega8(L)
Register Summary
Address
Name
Bit 7
Bit 6
Bit 5
Bit 4
Bit 3
Bit 2
Bit 1
Bit 0
0x3F (0x5F)
SREG
Page
9
0x3E (0x5E)
SPH
SP10
SP9
SP8
11
0x3D (0x5D)
SPL
SP7
SP6
SP5
SP4
SP3
SP2
SP1
SP0
11
0x3C (0x5C)
Reserved
47, 65
0x3B (0x5B)
GICR
INT1
INT0
IVSEL
IVCE
0x3A (0x5A)
GIFR
INTF1
INTF0
66
0x39 (0x59)
TIMSK
OCIE2
TOIE2
TICIE1
OCIE1A
OCIE1B
TOIE1
TOIE0
70, 100, 120
0x38 (0x58)
TIFR
OCF2
TOV2
ICF1
OCF1A
OCF1B
TOV1
TOV0
71, 101, 120
0x37 (0x57)
SPMCR
SPMIE
RWWSB
RWWSRE
BLBSET
PGWRT
PGERS
SPMEN
210
0x36 (0x56)
TWCR
TWINT
TWEA
TWSTA
TWSTO
TWWC
TWEN
TWIE
168
0x35 (0x55)
MCUCR
SE
SM2
SM1
SM0
ISC11
ISC10
ISC01
ISC00
31, 64
0x34 (0x54)
MCUCSR
WDRF
BORF
EXTRF
PORF
39
0x33 (0x53)
TCCR0
CS02
CS01
CS00
70
0x32 (0x52)
TCNT0
Timer/Counter0 (8 Bits)
0x31 (0x51)
OSCCAL
Oscillator Calibration Register
0x30 (0x50)
SFIOR
70
29
ACME
PUD
PSR2
PSR10
56, 73, 121, 190

95
0x2F (0x4F)
TCCR1A
COM1A1
COM1A0
COM1B1
COM1B0
FOC1A
FOC1B
WGM11
WGM10
0x2E (0x4E)
TCCR1B
ICNC1
ICES1
WGM13
WGM12
CS12
CS11
CS10
0x2D (0x4D)
TCNT1H
Timer/Counter1 Counter Register High byte
98
99
0x2C (0x4C)
TCNT1L
Timer/Counter1 Counter Register Low byte
99
0x2B (0x4B)
OCR1AH
Timer/Counter1 Output Compare Register A High byte
99
0x2A (0x4A)
OCR1AL
Timer/Counter1 Output Compare Register A Low byte
99
0x29 (0x49)
OCR1BH
Timer/Counter1 Output Compare Register B High byte
99
0x28 (0x48)
OCR1BL
Timer/Counter1 Output Compare Register B Low byte
99
0x27 (0x47)
ICR1H
Timer/Counter1 Input Capture Register High byte
100
0x26 (0x46)
ICR1L
0x25 (0x45)
TCCR2
Timer/Counter1 Input Capture Register Low byte
0x24 (0x44)
TCNT2
Timer/Counter2 (8 Bits)
117
0x23 (0x43)
OCR2
Timer/Counter2 Output Compare Register
117
FOC2
WGM20
COM21
COM20
WGM21
100
CS22
CS21
CS20
0x22 (0x42)
ASSR
AS2
TCN2UB
OCR2UB
TCR2UB
0x21 (0x41)
WDTCR
WDCE
WDE
WDP2
WDP1
WDP0
UBRRH
URSEL
0x20(1) (0x40)(1)
UBRR[11:8]
115
117
41
155
UCSRC
URSEL
UMSEL
UPM1
UPM0
USBS
UCSZ1
UCSZ0
UCPOL
153
0x1F (0x3F)
EEARH
EEAR8
18
0x1E (0x3E)
EEARL
EEAR7
EEAR6
EEAR5
EEAR4
EEAR3
EEAR2
EEAR1
EEAR0
0x1D (0x3D)
EEDR
EEPROM Data Register
18
18
EERIE
EEMWE
EEWE
EERE
PORTB
PORTB7
PORTB6
PORTB5
PORTB4
PORTB3
PORTB2
PORTB1
PORTB0
63
DDRB
DDB7
DDB6
DDB5
DDB4
DDB3
DDB2
DDB1
DDB0
63
0x16 (0x36)
PINB
PINB7
PINB6
PINB5
PINB4
PINB3
PINB2
PINB1
PINB0
63
0x15 (0x35)
PORTC
PORTC6
PORTC5
PORTC4
PORTC3
PORTC2
PORTC1
PORTC0
63
0x14 (0x34)
DDRC
DDC6
DDC5
DDC4
DDC3
DDC2
DDC1
DDC0
63
0x1C (0x3C)
EECR
0x1B (0x3B)
Reserved
0x1A (0x3A)
Reserved
0x19 (0x39)
Reserved
0x18 (0x38)
0x17 (0x37)
18
0x13 (0x33)
PINC
PINC6
PINC5
PINC4
PINC3
PINC2
PINC1
PINC0
63
0x12 (0x32)
PORTD
PORTD7
PORTD6
PORTD5
PORTD4
PORTD3
PORTD2
PORTD1
PORTD0
63
0x11 (0x31)
DDRD
DDD7
DDD6
DDD5
DDD4
DDD3
DDD2
DDD1
DDD0
63
0x10 (0x30)
PIND
PIND7
PIND6
PIND5
PIND4
PIND3
PIND2
PIND1
PIND0
0x0F (0x2F)
SPDR
SPI Data Register
63
128
0x0E (0x2E)
SPSR
SPIF
WCOL
SPI2X
0x0D (0x2D)
SPCR
SPIE
SPE
DORD
MSTR
CPOL
CPHA
SPR1
SPR0
0x0C (0x2C)
UDR
0x0B (0x2B)
UCSRA
RXC
TXC
UDRE
FE
DOR
PE
U2X
MPCM
151
0x0A (0x2A)
UCSRB
RXCIE
TXCIE
UDRIE
RXEN
TXEN
UCSZ2
RXB8
TXB8
152
0x09 (0x29)
UBRRL
0x08 (0x28)
ACSR
ACD
ACBG
ACO
ACI
ACIE
ACIC
ACIS1
ACIS0
191
0x07 (0x27)
ADMUX
REFS1
REFS0
ADLAR
MUX3
MUX2
MUX1
MUX0
202
0x06 (0x26)
ADCSRA
ADEN
ADSC
ADFR
ADIF
ADIE
ADPS2
ADPS1
ADPS0
204
0x05 (0x25)
ADCH
ADC Data Register High byte
205
0x04 (0x24)
ADCL
ADC Data Register Low byte
205
0x03 (0x23)
TWDR
0x02 (0x22)
TWAR
USART I/O Data Register
155
Two-wire Serial Interface Data Register

TWA5
TWA4
TWA3
TWA2
126
150
USART Baud Rate Register Low byte
TWA6
128
170
TWA1
TWA0
TWGCE
170
7
2486MSAVR12/03
Register Summary (Continued)

Address
Name
Bit 7
Bit 6
Bit 5
Bit 4
Bit 3
Bit 2
Bit 1
Bit 0
Page
0x01 (0x21)
TWSR
TWS7
TWS6
TWS5
TWS4
TWS3
TWPS1
TWPS0
170
0x00 (0x20)
TWBR
Notes:
Two-wire Serial Interface Bit Rate Register
168
1. Refer to the USART description for details on how to access UBRRH and UCSRC.
2. For compatibility with future devices, reserved bits should be written to zero if accessed. Reserved I/O memory addresses
should never be written.
3. Some of the Status Flags are cleared by writing a logical one to them. Note that the CBI and SBI instructions will operate on
all bits in the I/O Register, writing a one back into any flag read as set, thus clearing the flag. The CBI and SBI instructions
work with registers 0x00 to 0x1F only.
ATmega8(L)
2486MSAVR12/03
ATmega8(L)
Instruction Set Summary
Mnemonics
Operands
Description
Operation
Flags
#Clocks
ARITHMETIC AND LOGIC INSTRUCTIONS

ADD
Rd, Rr
Add two Registers
Rd Rd + Rr
Z,C,N,V,H
ADC
Rd, Rr
Add with Carry two Registers
Rd Rd + Rr + C
Z,C,N,V,H
ADIW
Rdl,K
Add Immediate to Word
Rdh:Rdl Rdh:Rdl + K
Z,C,N,V,S
SUB
Rd, Rr
Subtract two Registers
Rd Rd - Rr
Z,C,N,V,H
SUBI
Rd, K
Subtract Constant from Register
Rd Rd - K
Z,C,N,V,H
SBC
Rd, Rr
Subtract with Carry two Registers
Rd Rd - Rr - C
Z,C,N,V,H
SBCI
Rd, K
Subtract with Carry Constant from Reg.
Rd Rd - K - C
Z,C,N,V,H
SBIW
Rdl,K
Subtract Immediate from Word
Rdh:Rdl Rdh:Rdl - K
Z,C,N,V,S
AND
Rd, Rr
Logical AND Registers
Rd Rd Rr
Z,N,V
ANDI
Rd, K
Logical AND Register and Constant
Rd Rd K
Z,N,V
OR
Rd, Rr
Logical OR Registers
Rd Rd v Rr
Z,N,V
ORI
Rd, K
Logical OR Register and Constant
Rd Rd v K
Z,N,V
EOR
Rd, Rr
Exclusive OR Registers
Rd Rd Rr
Z,N,V
COM
Rd
Ones Complement
Rd 0xFF Rd
Z,C,N,V
NEG
Rd
Twos Complement
Rd 0x00 Rd
Z,C,N,V,H
SBR
Rd,K
Set Bit(s) in Register
Rd Rd v K
Z,N,V
CBR
Rd,K
Clear Bit(s) in Register
Rd Rd (0xFF - K)
Z,N,V
1
1
INC
Rd
Increment
Rd Rd + 1
Z,N,V
DEC
Rd
Decrement
Rd Rd 1
Z,N,V
TST
Rd
Test for Zero or Minus
Rd Rd Rd
Z,N,V
CLR
Rd
Clear Register
Rd Rd Rd
Z,N,V
SER
Rd
Set Register
Rd 0xFF
None
MUL
Rd, Rr
Multiply Unsigned
R1:R0 Rd x Rr
Z,C
MULS
Rd, Rr
Multiply Signed
R1:R0 Rd x Rr
Z,C
MULSU
Rd, Rr
Multiply Signed with Unsigned
R1:R0 Rd x Rr
Z,C
FMUL
Rd, Rr
Fractional Multiply Unsigned
R1:R0 (Rd x Rr) <<
Z,C
FMULS
Rd, Rr
Fractional Multiply Signed
Z,C
FMULSU
Rd, Rr
Fractional Multiply Signed with Unsigned
1
R1:R0 (Rd x Rr) << 1
R1:R0 (Rd x Rr) << 1
Z,C
Relative Jump
PC PC + k + 1
None
Indirect Jump to (Z)
PC Z
None
Relative Subroutine Call
PC PC + k + 1
None
ICALL
Indirect Call to (Z)
PC Z
None
RET
Subroutine Return
PC STACK
None
RETI
Interrupt Return
PC STACK
I
None
BRANCH INSTRUCTIONS
RJMP
IJMP
RCALL
CPSE
Rd,Rr
Compare, Skip if Equal
if (Rd = Rr) PC PC + 2 or 3
CP
Rd,Rr
Compare
Rd Rr
Z, N,V,C,H
CPC
Rd,Rr
Compare with Carry
Rd Rr C
Z, N,V,C,H
CPI
Rd,K
Compare Register with Immediate
Rd K
Z, N,V,C,H
SBRC
Rr, b
Skip if Bit in Register Cleared
if (Rr(b)=0) PC PC + 2 or 3
None
1/2/3
1
1/2/3
SBRS
Rr, b
Skip if Bit in Register is Set
if (Rr(b)=1) PC PC + 2 or 3
None
1/2/3
SBIC
P, b
Skip if Bit in I/O Register Cleared
if (P(b)=0) PC PC + 2 or 3
None
1/2/3
SBIS
P, b
Skip if Bit in I/O Register is Set
if (P(b)=1) PC PC + 2 or 3
None
1/2/3
BRBS
s, k
Branch if Status Flag Set
if (SREG(s) = 1) then PCPC+k + 1
None
1/2
BRBC
s, k
Branch if Status Flag Cleared
if (SREG(s) = 0) then PCPC+k + 1
None
1/2
BREQ
Branch if Equal
if (Z = 1) then PC PC + k + 1
None
1/2
BRNE
Branch if Not Equal
if (Z = 0) then PC PC + k + 1
None
1/2
BRCS
Branch if Carry Set
if (C = 1) then PC PC + k + 1
None
1/2
BRCC
Branch if Carry Cleared
None
1/2
BRSH
Branch if Same or Higher
None
1/2
BRLO
Branch if Lower
None
1/2
BRMI
Branch if Minus
if (N = 1) then PC PC + k + 1
None
1/2
BRPL
Branch if Plus
if (N = 0) then PC PC + k + 1
None
1/2
BRGE
Branch if Greater or Equal, Signed
if (N V= 0) then PC PC + k + 1
None
1/2
BRLT
Branch if Less Than Zero, Signed
if (N V= 1) then PC PC + k + 1
None
1/2
BRHS
Branch if Half Carry Flag Set
if (H = 1) then PC PC + k + 1
None
1/2
BRHC
Branch if Half Carry Flag Cleared
if (H = 0) then PC PC + k + 1
None
1/2
BRTS
Branch if T Flag Set
if (T = 1) then PC PC + k + 1
None
1/2
BRTC
Branch if T Flag Cleared
if (T = 0) then PC PC + k + 1
None
1/2
BRVS
Branch if Overflow Flag is Set
if (V = 1) then PC PC + k + 1
None
1/2
BRVC
Branch if Overflow Flag is Cleared
if (V = 0) then PC PC + k + 1
None
Mnemonics
Operands
Description
Operation
Flags
1/2
#Clocks
9
2486MSAVR12/03
Instruction Set Summary (Continued)

BRIE
Branch if Interrupt Enabled
if ( I = 1) then PC PC + k + 1
None
1/2
BRID
Branch if Interrupt Disabled
if ( I = 0) then PC PC + k + 1
None
1/2
DATA TRANSFER INSTRUCTIONS

MOV
Rd, Rr
Move Between Registers
Rd Rr
None
MOVW
Rd, Rr
Copy Register Word
Rd+1:Rd Rr+1:Rr
None
LDI
Rd, K
Load Immediate
Rd K
None
LD
Rd, X
Load Indirect
Rd (X)
None
LD
Rd, X+
Load Indirect and Post-Inc.
Rd (X), X X + 1
None
LD
Rd, - X
Load Indirect and Pre-Dec.
X X - 1, Rd (X)
None
LD
Rd, Y
Load Indirect
Rd (Y)
None
LD
Rd, Y+
Rd (Y), Y Y + 1
None
LD
Rd, - Y
Y Y - 1, Rd (Y)
None
LDD
Rd,Y+q
Load Indirect with Displacement
Rd (Y + q)
None
LD
Rd, Z
Load Indirect
Rd (Z)
None
LD
Rd, Z+
Rd (Z), Z Z+1
None
LD
Rd, -Z
Z Z - 1, Rd (Z)
None
LDD
Rd, Z+q
Load Indirect with Displacement
Rd (Z + q)
None
LDS
Rd, k
Load Direct from SRAM
Rd (k)
None
ST
X, Rr
Store Indirect
(X) Rr
None
ST
X+, Rr
Store Indirect and Post-Inc.
(X) Rr, X X + 1
None
ST
- X, Rr
Store Indirect and Pre-Dec.
X X - 1, (X) Rr
None
ST
Y, Rr
Store Indirect
(Y) Rr
None
ST
Y+, Rr
(Y) Rr, Y Y + 1
None
2
2
ST
- Y, Rr
Y Y - 1, (Y) Rr
None
STD
Y+q,Rr
Store Indirect with Displacement
(Y + q) Rr
None
ST
Z, Rr
Store Indirect
(Z) Rr
None
ST
Z+, Rr
(Z) Rr, Z Z + 1
None
ST
-Z, Rr
Z Z - 1, (Z) Rr
None
STD
Z+q,Rr
Store Indirect with Displacement
(Z + q) Rr
None
STS
k, Rr
Store Direct to SRAM
(k) Rr
None
Load Program Memory
R0 (Z)
None
LPM
Rd, Z
Load Program Memory
Rd (Z)
None
LPM
Rd, Z+
Load Program Memory and Post-Inc
Rd (Z), Z Z+1
None
Store Program Memory
(Z) R1:R0
None
In Port
Rd P
None
LPM
SPM
IN
Rd, P
OUT
P, Rr
Out Port
P Rr
None
PUSH
Rr
Push Register on Stack
STACK Rr
None
POP
Rd
Pop Register from Stack
Rd STACK
None
BIT AND BIT-TEST INSTRUCTIONS

SBI
P,b
Set Bit in I/O Register
I/O(P,b) 1
None
CBI
P,b
Clear Bit in I/O Register
I/O(P,b) 0
None
LSL
Rd
Logical Shift Left
Rd(n+1) Rd(n), Rd(0) 0
Z,C,N,V
LSR
Rd
Logical Shift Right
Rd(n) Rd(n+1), Rd(7) 0
Z,C,N,V
ROL
Rd
Rotate Left Through Carry
Rd(0)C,Rd(n+1) Rd(n),CRd(7)
Z,C,N,V
ROR
Rd
Rotate Right Through Carry
Rd(7)C,Rd(n) Rd(n+1),CRd(0)
Z,C,N,V
ASR
Rd
Arithmetic Shift Right
Rd(n) Rd(n+1), n=0..6
Z,C,N,V
SWAP
Rd
Swap Nibbles
Rd(3..0)Rd(7..4),Rd(7..4)Rd(3..0)
None
BSET
Flag Set
SREG(s) 1
SREG(s)
BCLR
Flag Clear
SREG(s) 0
SREG(s)
BST
Rr, b
Bit Store from Register to T
T Rr(b)
BLD
Rd, b
Bit load from T to Register
Rd(b) T
None
SEC
Set Carry
C1
CLC
Clear Carry
C0
SEN
Set Negative Flag
N1
CLN
Clear Negative Flag
N0
SEZ
Set Zero Flag
Z1
CLZ
Clear Zero Flag
Z0
SEI
Global Interrupt Enable
I1
CLI
Global Interrupt Disable
I 0
SES
Set Signed Test Flag
S1
CLS
Clear Signed Test Flag
S0
SEV
Set Twos Complement Overflow.
V1
CLV
Clear Twos Complement Overflow
V0
SET
Set T in SREG
T1
Mnemonics
10
Operands
Description
Operation
Flags
#Clocks
ATmega8(L)
2486MSAVR12/03
ATmega8(L)
Instruction Set Summary (Continued)
CLT
Clear T in SREG
T0
SEH
Set Half Carry Flag in SREG
H1
CLH
Clear Half Carry Flag in SREG
H0
MCU CONTROL INSTRUCTIONS

NOP
SLEEP
WDR
No Operation
Sleep
Watchdog Reset
(see specific descr. for Sleep function)

(see specific descr. for WDR/timer)
None
None
None
1
1
1
11
2486MSAVR12/03
Ordering Information
Speed (MHz)
Power Supply
Ordering Code
Package
Operation Range
2.7 - 5.5
ATmega8L-8AC
ATmega8L-8PC
ATmega8L-8MC
32A
28P3
32M1-A
Commercial
(0C to 70C)
ATmega8L-8AI
ATmega8L-8PI
ATmega8L-8MI
32A
28P3
32M1-A
Industrial
(-40C to 85C)
ATmega8-16AC
ATmega8-16PC
ATmega8-16MC
32A
28P3
32M1-A
Commercial
(0C to 70C)
ATmega8-16AI
ATmega8-16PI
ATmega8-16MI
32A
28P3
32M1-A
Industrial
(-40C to 85C)
16
Note:
4.5 - 5.5
This device can also be supplied in wafer form. Please contact your local Atmel sales office for detailed ordering information and
minimum quantities.
Package Type
32A
32-lead, Thin (1.0 mm) Plastic Quad Flat Package (TQFP)
28P3
28-lead, 0.300 Wide, Plastic Dual Inline Package (PDIP)
32M1-A
32-pad, 5 x 5 x 1.0 body, Lead Pitch 0.50 mm Micro Lead Frame Package (MLF)
12
ATmega8(L)
2486MSAVR12/03
ATmega8(L)
Packaging Information
32A
PIN 1
B
PIN 1 IDENTIFIER
E1
D1
D
C
0~7
A1
A2
L
COMMON DIMENSIONS
(Unit of Measure = mm)
Notes:
1. This package conforms to JEDEC reference MS-026, Variation ABA.

2. Dimensions D1 and E1 do not include mold protrusion. Allowable
protrusion is 0.25 mm per side. Dimensions D1 and E1 are maximum
plastic body size dimensions including mold mismatch.
3. Lead coplanarity is 0.10 mm maximum.
SYMBOL
MIN
NOM
MAX
1.20
A1
0.05
0.15
A2
0.95
1.00
1.05
8.75
9.00
9.25
D1
6.90
7.00
7.10
8.75
9.00
9.25
E1
6.90
7.00
7.10
0.30
0.45
0.09
0.20
0.45
0.75
NOTE
Note 2
Note 2
0.80 TYP
10/5/2001
2325 Orchard Parkway

San Jose, CA 95131
TITLE
32A, 32-lead, 7 x 7 mm Body Size, 1.0 mm Body Thickness,
0.8 mm Lead Pitch, Thin Profile Plastic Quad Flat Package (TQFP)
DRAWING NO.
REV.
32A
13
2486MSAVR12/03
28P3
PIN
1
E1
SEATING PLANE
B2
B1
A1
(4 PLACES)
0 ~ 15
REF
e
E
COMMON DIMENSIONS
eB
Note:
1. Dimensions D and E1 do not include mold Flash or Protrusion.

Mold Flash or Protrusion shall not exceed 0.25 mm (0.010").
MIN
NOM
MAX
4.5724
A1
0.508
34.544
34.798
7.620
8.255
E1
7.112
7.493
0.381
0.533
B1
1.143
1.397
B2
0.762
1.143
3.175
3.429
0.203
0.356
eB
10.160
SYMBOL
A
NOTE
Note 1
Note 1
2.540 TYP
09/28/01
14

San Jose, CA 95131
TITLE
28P3, 28-lead (0.300"/7.62 mm Wide) Plastic Dual
Inline Package (PDIP)
DRAWING NO.
28P3
REV.
B
ATmega8(L)
2486MSAVR12/03
ATmega8(L)
32M1-A
D
D1
1
2
3
Pin 1 ID
E1
SIDE VIEW
TOP VIEW
A3
A2
A1
A
0.08 C
P
COMMON DIMENSIONS
D2
Pin 1 ID
1
2
3
E2
SYMBOL
MIN
NOM
MAX
0.80
0.90
1.00
A1
0.02
0.05
A2
0.65
1.00
A3
b
0.20 REF
0.18
D2
3.25
4.75BSC
2.95
Notes: 1. JEDEC Standard MO-220, Fig. 2 (Anvil Singulation), VHHD-2.
3.10
5.00 BSC
E1
E2
0.30
4.75 BSC
2.95
BOTTOM VIEW
0.23
5.00 BSC
D1
e
NOTE
3.10
3.25
0.50 BSC
0.30
0.40
0.50
0.60
12o
01/15/03

San Jose, CA 95131
TITLE
32M1-A, 32-pad, 5 x 5 x 1.0 mm Body, Lead Pitch 0.50 mm
Micro Lead Frame Package (MLF)
DRAWING NO.
32M1-A
REV.
C
15
2486MSAVR12/03
Erratas
The revision letter in this section refers to the revision of the ATmega8 device.
ATmega8
Rev. D, E, F, and G
CKOPT Does not Enable Internal Capacitors on XTALn/TOSCn Pins when 32 KHz
Oscillator is Used to Clock the Asynchronous Timer/Counter2
1. CKOPT Does not Enable Internal Capacitors on XTALn/TOSCn Pins when
32 KHz Oscillator is Used to Clock the Asynchronous Timer/Counter2
When the internal RC Oscillator is used as the main clock source, it is possible to
run the Timer/Counter2 asynchronously by connecting a 32 KHz Oscillator between
XTAL1/TOSC1 and XTAL2/TOSC2. But when the internal RC Oscillator is selected
as the main clock source, the CKOPT Fuse does not control the internal capacitors
on XTAL1/TOSC1 and XTAL2/TOSC2. As long as there are no capacitors connected to XTAL1/TOSC1 and XTAL2/TOSC2, safe operation of the Oscillator is not
guaranteed.
Problem fix/Workaround
Use external capacitors in the range of 20 - 36 pF on XTAL1/TOSC1 and
XTAL2/TOSC2. This will be fixed in ATmega8 Rev. G where the CKOPT Fuse will
control internal capacitors also when internal RC Oscillator is selected as main clock
source. For ATmega8 Rev. G, CKOPT = 0 (programmed) will enable the internal
capacitors on XTAL1 and XTAL2. Customers who want compatibility between Rev.
G and older revisions, must ensure that CKOPT is unprogrammed (CKOPT = 1).
16
ATmega8(L)
2486MSAVR12/03
ATmega8(L)
Datasheet Change
Log for ATmega8
This document contains a log on the changes made to the datasheet for ATmega8.
Changes from Rev.

2486K-08/03 to Rev.
2486L-10/03
All page numbers refers to this document.
Changes from Rev.

2486K-08/03 to Rev.
2486L-10/03
1. Updated Calibrated Internal RC Oscillator on page 28.
1. Removed Preliminary and TBDs from the datasheet.

2. Renamed ICP to ICP1 in the datasheet.
3. Removed instructions CALL and JMP from the datasheet.
4. Updated tRST in Table 15 on page 36, VBG in Table 16 on page 40, Table 100 on
page 239 and Table 102 on page 241.
5. Replaced text XTAL1 and XTAL2 should be left unconnected (NC) after
Table 9 in Calibrated Internal RC Oscillator on page 28. Added text regarding XTAL1/XTAL2 and CKOPT Fuse in Timer/Counter Oscillator on page 30.
6. Updated Watchdog Timer code examples in Timed Sequences for Changing
the Configuration of the Watchdog Timer on page 43.
7. Removed bit 4, ADHSM, from Special Function IO Register SFIOR on page
56.
8. Added note 2 to Figure 103 on page 212.
9. Updated item 4 in the Serial Programming Algorithm on page 233.
10. Added tWD_FUSE to Table 97 on page 234 and updated Read Calibration Byte,
Byte 3, in Table 98 on page 235.
11. Updated Absolute Maximum Ratings* and DC Characteristics in Electrical
Characteristics on page 237.
Changes from Rev.

2486J-02/03 to Rev.
2486K-08/03

1. Updated VBOT values in Table 15 on page 36.
2. Updated ADC Characteristics on page 243.
3. Updated ATmega8 Typical Characteristics on page 244.
4. Updated Erratas on page 16.
Changes from Rev.

2486I-12/02 to Rev.
2486J-02/03
17
2486MSAVR12/03
1. Improved the description of Asynchronous Timer Clock clkASY on page

24.
2. Removed reference to the Multipurpose Oscillator application note and the
32 kHz Crystal Oscillator application note, which do not exist.
3. Corrected OCn waveforms in Figure 38 on page 88.
4. Various minor Timer 1 corrections.
5. Various minor TWI corrections.
6. Added note under Filling the Temporary Buffer (Page Loading) on page 213
about writing to the EEPROM during an SPM Page load.
7. Removed ADHSM completely.
8. Added section EEPROM Write during Power-down Sleep Mode on page 21.
9. Removed XTAL1 and XTAL2 description on page 5 because they were already
described as part of Port B (PB7..PB0) XTAL1/ XTAL2/TOSC1/TOSC2 on
page 5.
10. Improved the table under SPI Timing Characteristics on page 241 and
removed the table under SPI Serial Programming Characteristics on page
236.
11. Corrected PC6 in Alternate Functions of Port C on page 59.
12. Corrected PB6 and PB7 in Alternate Functions of Port B on page 56.
13. Corrected 230.4 Mbps to 230.4 kbps under Examples of Baud Rate Setting
on page 156.
14. Added information about PWM symmetry for Timer 2 in Phase Correct PWM
Mode on page 111.
15. Added thick lines around accessible registers in Figure 76 on page 166.
16. Changed will be ignored to must be written to zero for unused Z-pointer
bits under Performing a Page Write on page 213.
17. Added note for RSTDISBL Fuse in Table 87 on page 220.
18.Updated drawings in Packaging Information on page 13.
Changes from Rev.

2486H-09/02 to Rev.
2486I-12/02
1.Added errata for Rev D, E, and F on page 16.
Changes from Rev.

2486G-09/02 to Rev.
2486H-09/02
1.Changed the Endurance on the Flash to 10,000 Write/Erase Cycles.
18
ATmega8(L)
2486MSAVR12/03
ATmega8(L)
Changes from Rev.
2486F-07/02 to Rev.
2486G-09/02
Changes from Rev.

2486E-06/02 to Rev.
2486F-07/02
1 Updated Table 103, ADC Characteristics, on page 243.
Changes in Digital Input Enable and Sleep Modes on page 53.
Addition of OCS2 in MOSI/OC2 Port B, Bit 3 on page 57.
The following tables has been updated:

Table 51, CPOL and CPHA Functionality, on page 129, Table 59, UCPOL Bit Settings, on page 155, Table 72, Analog Comparator Multiplexed Input(1), on
page 192, Table 73, ADC Conversion Time, on page 197, Table 75, Input Channel Selections, on page 203, and Table 84, Explanation of Different Variables
used in Figure 103 and the Mapping to the Z-pointer, on page 218.
Changes in Reading the Calibration Byte on page 230.
6 Corrected Errors in Cross References.
Changes from Rev.

2486D-03/02 to Rev.
2486E-06/02

1
Updated Some Preliminary Test Limits and Characterization Data

The following tables have been updated:
Table 15, Reset Characteristics, on page 36, Table 16, Internal Voltage Reference Characteristics, on page 40, DC Characteristics on page 237, Table , ADC
Characteristics, on page 243.
Changes in External Clock Frequency

Added the description at the end of External Clock on page 30.
Added period changing data in Table 99, External Clock Drive, on page 239.
Updated TWI Chapter

More details regarding use of the TWI bit rate prescaler and a Table 65, TWI Bit
Rate Prescaler, on page 170.
Changes from Rev.

2486C-03/02 to Rev.
2486D-03/02

1
Updated Typical Start-up Times.

The following tables has been updated:
Table 5, Start-up Times for the Crystal Oscillator Clock Selection, on page 26,
Table 6, Start-up Times for the Low-frequency Crystal Oscillator Clock Selection,
on page 26, Table 8, Start-up Times for the External RC Oscillator Clock Selection, on page 27, and Table 12, Start-up Times for the External Clock Selection,
on page 30.
2 Added ATmega8 Typical Characteristics on page 244.
19
2486MSAVR12/03
Changes from Rev.

2486B-12/01 to Rev.
2486C-03/02

1
Updated TWI Chapter.

More details regarding use of the TWI Power-down operation and using the TWI as
Master with low TWBRR values are added into the datasheet.
Added the note at the end of the Bit Rate Generator Unit on page 167.
Added the description at the end of Address Match Unit on page 167.
Updated Description of OSCCAL Calibration Byte.

In the datasheet, it was not explained how to take advantage of the calibration bytes
for 2, 4, and 8 MHz Oscillator selections. This is now added in the following
sections:
Improved description of Oscillator Calibration Register OSCCAL on page 29 and
Calibration Byte on page 221.
Added Some Preliminary Test Limits and Characterization Data.

Removed some of the TBDs in the following tables and pages:
Table 3 on page 24, Table 15 on page 36, Table 16 on page 40, Table 17 on page
42, TA = -40C to 85C, VCC = 2.7V to 5.5V (unless otherwise noted) on page
237, Table 99 on page 239, and Table 102 on page 241.
Updated Programming Figures.

Figure 104 on page 222 and Figure 112 on page 232 are updated to also reflect that
AVCC must be connected during Programming mode.
Added a Description on how to Enter Parallel Programming Mode if RESET

Pin is Disabled or if External Oscillators are Selected.
Added a note in section Enter Programming Mode on page 224.
20
ATmega8(L)
2486MSAVR12/03
Atmel Corporation
San Jose, CA 95131, USA
Tel: 1(408) 441-0311
Fax: 1(408) 487-2600
Regional Headquarters
Europe
Atmel Sarl
Route des Arsenaux 41
Case Postale 80
CH-1705 Fribourg
Switzerland
Tel: (41) 26-426-5555
Fax: (41) 26-426-5500
Asia
Room 1219
Chinachem Golden Plaza
77 Mody Road Tsimshatsui
East Kowloon
Hong Kong
Tel: (852) 2721-9778
Fax: (852) 2722-1369
Japan
9F, Tonetsu Shinkawa Bldg.
1-24-8 Shinkawa
Chuo-ku, Tokyo 104-0033
Japan
Tel: (81) 3-3523-3551
Fax: (81) 3-3523-7581
Atmel Operations
Memory
Tel: 1(408) 441-0311
Fax: 1(408) 436-4314
RF/Automotive
Theresienstrasse 2
Postfach 3535
74025 Heilbronn, Germany
Tel: (49) 71-31-67-0
Fax: (49) 71-31-67-2340
Microcontrollers
Tel: 1(408) 441-0311
Fax: 1(408) 436-4314
La Chantrerie
BP 70602
44306 Nantes Cedex 3, France
Tel: (33) 2-40-18-18-18
Fax: (33) 2-40-18-19-60
ASIC/ASSP/Smart Cards
1150 East Cheyenne Mtn. Blvd.

Colorado Springs, CO 80906, USA
Tel: 1(719) 576-3300
Fax: 1(719) 540-1759
Biometrics/Imaging/Hi-Rel MPU/
High Speed Converters/RF Datacom
Avenue de Rochepleine
BP 123
38521 Saint-Egreve Cedex, France
Tel: (33) 4-76-58-30-00
Fax: (33) 4-76-58-34-80
Zone Industrielle
13106 Rousset Cedex, France
Tel: (33) 4-42-53-60-00
Fax: (33) 4-42-53-60-01
1150 East Cheyenne Mtn. Blvd.
Colorado Springs, CO 80906, USA
Tel: 1(719) 576-3300
Fax: 1(719) 540-1759
Scottish Enterprise Technology Park
Maxwell Building
East Kilbride G75 0QR, Scotland
Tel: (44) 1355-803-000
Fax: (44) 1355-242-743
Literature Requests
www.atmel.com/literature
Disclaimer: Atmel Corporation makes no warranty for the use of its products, other than those expressly contained in the Companys standard
warranty which is detailed in Atmels Terms and Conditions located on the Companys web site. The Company assumes no responsibility for any
errors which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice, and
does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property of Atmel are
granted by the Company in connection with the sale of Atmel products, expressly or by implication. Atmels products are not authorized for use
as critical components in life support devices or systems.
Atmel Corporation 2003. All rights reserved. Atmel and combinations thereof, AVR, and AVR Studio are the registered trademarks of
Atmel Corporation or its subsidiaries. Microsoft , Windows, Windows NT, and Windows XP are the registered trademarks of Microsoft Corporation. Other terms and product names may be the trademarks of others
Printed on recycled paper.

2486MSAVR12/03
Product Datasheet
XBee ZigBee/802.15.4 Modules

2.4 GHz OEM RF Modules
Part of Digis Drop-in Networking product family,
XBee OEM RF modules provide reliable, wireless data
communication over ZigBee/802.15.4 networks.
Available in Series 1 or Series 2 models for point-tomultipoint or mesh topologies, they enable OEMs
with excellent wireless performance in a cost-effective,
small form factor solution.
Ethernet
Central Facilities
Management
Internet/
Frame Relay/
VPN
Wireless
Telco Network
ConnectPort X
Ga
ate
tewa
w y
wa
Gateway
9-30VDC
MAX
1A
ARY
SECOND A
ANTENN
Warehouse
POWER
RESET
TH
STRENG
STATUS
SIGNAL
ACT
Con
nec
rt X4
tPo
Y
PRIMAR A
ANTENN
LINK
PR
PR
Meter
Meter
ZigBee/802.15.4
Wireless Mesh Network
XBee
Module
PR
Meter
Features/Benefits
ZigBee/802.15.4 compatible RF
modules
2.4 GHz ISM band for use
worldwide
Fully interoperable with other
Digi Drop-in Networking
products, including gateways,
device adapters and extenders
Available in Series 1 or Series 2
models for point-to-multipoint
or mesh topologies
Pin-swappable regular and
long-range PRO versions
Low cost
Common footprint for a variety
of Digi RF modules
Low-power sleep modes
Multiple antenna options
Industrial temperature
(-40 C to 85 C)
www.digi.com
Overview
The XBee family of ZigBee/802.15.4 RF modules is the premiere choice for OEMs looking for
excellent wireless performance in a cost-effective, small form factor solution. Each XBee module
comes in either a regular or long-range PRO version*. All XBee modules are pin-for-pin
compatible with the exception of a few varying I/O features, which provides a standard
footprint for OEMs with multiple applications.
XBee Series 1 is based on ZigBee/802.15.4 silicon from Freescale. Its 802.15.4 firmware feature
set makes it ideal for point-to-point, peer-to-peer, and point-to-multipoint (star) topologies. The
XBee Series 1 gives the user maximum control over network nodes and minimum latency.
XBee Series 2 is based on ZigBee/802.15.4 silicon from Ember. It features ZigBee firmware
for creating ad-hoc mesh networks. The XBee Series 2 performs automatic route discoveries to
create a self-healing network of full-function routers and low-power end devices. XBee Series 1
and Series 2 modules do not communicate with one another.
Known for ease of use, the XBee modules are ready to operate out of the box and offer simple
AT commands or an API for advanced, user-settable configurations. XBee modules are
recognized worldwide for reliable wireless data communication in the license-free 2.4 GHz ISM
band. Visit our website for a complete listing of countries that have approved the XBee as a
certified, license-free RF module with no need for further testing.
XBee modules are a part of Digis full line of Drop-in Networking products. ConnectPort X
gateways and XBee device adapters, modules and extenders provide end-to-end wireless
connectivity to commercial-grade electronic devices in locations where wired infrastructure does
not exist or satisfy customer needs. To learn more about Drop-in Networking, visit
www.digi.com/products/wirelessdropinnetworking.
Features/Specifications
Product Selection Guide
Series 1
Series 2
Silicon
Freescale
Ember
Firmware
802.15.4
ZigBee
Point-to-point, peer-to-peer,
point-to-multipoint (star)
Mesh
Network Topologies
POWER
REQUIREMENTS
XBee
(Series 1)
XBee-PRO
(Series 1)
XBee
(Series 2)
XBee-PRO
(Series 2)*
Indoor/Urban range
100 ft (30 m)
300 ft (90 m)
133 ft (40 m)
n/a
Outdoor/RF Line-of-Sight Range
300 ft (90 m)
1 mi (1.6 km)
400 ft (120 m)
n/a
802.15.4 Star
Series 1 (XBee / XBee-PRO)

Supply voltage: 2.8 3.4 VDC /
2.8 3.4 VDC
Transmit current (@ 3.3 V):
45 mA / 215 mA
Receive current (@ 3.3 V):
50 mA / 55 mA
Power-down current:
<10 uA / <10 uA
Series 2 (XBee)
Supply voltage: 2.1 3.6 VDC
Transmit current (@ 3.3 V): 35 mA
(40 mA boost mode)
Receive current (@ 3.3 V): 38 mA
(40 mA boost mode)
Power-down current: <1 uA (@ 25 C)
ZigBee Mesh
ANTENNA
OPTIONS
* XBee-PRO Series 2 coming soon.
PERFORMANCE
FEATURES
General
RF data rate: 250 Kbps
Operating temperature:
-40 C to 85 C (-40 F to 185 F)
Indoor/Urban range: 100 ft
(30 m) / 300 ft (90 m)
Outdoor/RF line-of-sight range:
300 ft (90 m) / 1 mi (1.6 km)
Transmit power output: 1 mW
(0 dBm) / 60 mW (+18 dBm) -
General
Serial data interface:
3.3V CMOS UART
Configuration method: API or AT
commands, local or over-the-air
Frequency band: 2.4 GHz
Interference immunity: DSSS
(Direct Sequence Spread
Spectrum) channels
Series 1
Serial data rate:
1200 - 250000 bps
(6) 10-bit ADC inputs,
(8) Digital I/O
Series 2
Serial data rate: 1200 1 Mbps
(4) 10-bit ADC inputs,
(10) Digital I/O
Note: In Europe XBeePRO

modules must be set to 10 mW
(10 dBm). In Japan XBP modules
are calibrated to 10 mW
(10 dBm).
Receiver sensitivity (1% PER):
-92 dBm / -100 dBm
Series 2 (XBee)
Indoor/Urban range: 133 ft
(40 m)
Outdoor/RF line-of-sight range:
400 ft (120 m)
Transmit power output:
1.25 mW (+1 dBm) (2 mW
(+3 dBm) boost mode)
Receiver sensitivity (1% PER):
-97 dBm (-98 dBm boost mode)
REGULATORY
APPROVALS
U.S. (FCC Part 15.247): OUR-XBEE /
OUR-XBEEPRO
Canada (IC): 4214A-XBEE /
4214A-XBEEPRO
Europe (CE): ETSI / ETSI
(max. tx power output: 10 mW)
Australia
Japan
Series 2 (XBee)
U.S. (FCC Part 15.247): OUR-XBEE2
Canada (IC): 4214A-XBEE2
Europe (CE): ETSI
Japan
NETWORKING
AND SECURITY
XBee-PRO
Encryption: AES 128-bit

Reliable packet delivery:
Retries/Acknowledgments
PAN ID, 64-bit IEEE MAC
address, 16 channels
(12 channels XBee-PRO Series 1)
XBee
0.32
(0.82)
1.087
(2.761)
DIGI SERVICE AND SUPPORT - You can purchase with confidence knowing that Digi is here
11001 Bren Road E.

Minnetonka, MN 55343
U.S.A.
PH: 877-912-3444
952-912-3444
FX: 952-912-4952
email: [email protected]
Digi International
KK
Digi International
(HK) Limited
31 rue des Poissonniers

92200 Neuilly sur Seine
PH: +33-1-55-61-98-98
FX: +33-1-55-61-98-99
www.digi.fr
NES Building South 8F

22-14 Sakuragaoka-cho,
Shibuya-ku
Tokyo 150-0031, Japan
PH: +81-3-5428-0261
FX: +81-3-5428-0262
www.digi-intl.co.jp
Suite 1703-05, 17/F.,

K Wah Centre
191 Java Road
North Point, Hong Kong
PH: +852-2833-1008
FX: +852-2572-9989
www.digi.cn
0.960
(2.438)
WHEN
to support you with expert technical support and a one-year warranty. www.digi.com/support
Digi International
France
0.32
(0.82)
1.297
(3.294)
0.960
(2.438)
Please visit www.digi.com for part numbers.
Digi International
Wire whip antenna

Chip antenna
U.Fl RF connector
RPSMA female RF connector
MATTERS
Digi International, the leader in device networking for business, develops reliable
products and technologies to connect and securely manage local or remote electronic
devices over the network or via the web. With over 20 million ports shipped worldwide
since 1985, Digi offers the highest levels of performance, flexibility and quality.
www.digi.com
2006-2007 Digi International Inc.

All rights reserved. Digi, Digi International, the Digi logo, the When Reliability Matters logo, ConnectPort, XBee, XBee-PRO and XStream are either
trademarks or registered trademarks of Digi International Inc. in the United States and other countries worldwide. All other trademarks are the property
of their respective holders.
91001412
A1/1007
UGV
Unmanned Ground Vehicle
OPERATION MANUAL
Hardware:
1.
2.
3.
4.
5.
Attach the PC side Communication module board to COMM port of PC.

Attach the 5V supply to power input terminals of PC side Communication module
board.
Attach the 9V battery to power input terminals of analog camera mounted at the vehicle.
Attach the 12V adapter to power input terminals of receiver of analog camera mounted
at the vehicle.
Attach 10 AA batteries (1800 mAH Current rating for good operation) power input
terminals of UGV. 4 Batteries at top rear side of UGV and 6 underdown side of UGV.
Software:
B.
Put the attached disk into the CD-ROM. Open and click UGV.exe file.
You will see the following screen. Click next
C.
D.
Select the desired mode of operation from UGV by clicking the either of two buttons.
For Navigation Mode, following window will appear:
A.
E.
F.
Use arrow direction keys to operate UGV and C key for Capturing Snapshots.
For Autonomous operation close Navigation Mode window and press Autonomous
mode button & vice versa for Navigation mode toggling.
G.
H.
I.
J.
K.
First put the UGV on its starting point of pre-defined map.

Press Enable Car Vision Button to watch live video (Front Scenes).
Select the desired destination point for UGV.
Press Start button to initiate Autonomous Operation of UGV
To repeat process go to Step I.
email: [email protected], kashif [email protected], [email protected],

[email protected]
Thanks for reading the report. The video of working of this project can be watched and
downloaded from Youtube. The link of webpage is:
http://www.youtube.com/watch?v=8UGGUdpqNLE

Unmanned Ground Vehicle Project Report

Uploaded by

Copyright:

Available Formats

Unmanned Ground Vehicle Project Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unmanned Ground Vehicle Project Report

Uploaded by

Copyright:

Available Formats

In the name of Allah, the Most Beneficent, the Most Merciful

Final Year Project Report 2008

SUPERVISORS OF THE PROJECT

External Project Supervisor

Visiting Lecturer at IIEE

Project Work Incharge

Mr. Ashab Mirza

Associate Professor at IIEE

UNMANNED GROUND VEHICLE

UNMANNED GROUND VEHICLE

Table 4-1: Comparison of various available protocols

Table 5-1: Some Properties of MSCOMM

Table 5-2: VB Key Codes of corresponding used keys of keyboard

UNMANNED GROUND VEHICLE

Unmanned ground vehicle is a robotic platform that is used as an extension of human

UNMANNED GROUND VEHICLE

The benefits of UGVs to the various fields are obvious:

UNMANNED GROUND VEHICLE

Their details are as follows:

UNMANNED GROUND VEHICLE

Voltage regulators for motor, microcontroller and Xbee transceiver.

H-bridge based controller interfaced motor driver circuitry for bidirectional

Xbee transceiver for communicating with the PC.

Disc, optocoupler (phototransistor + led) assembly for speed feedback.

UNMANNED GROUND VEHICLE

UNMANNED GROUND VEHICLE

Operation of the vehicle on pre-defined path.

Real time remote monitoring and control.

Feedback Control System.

UNMANNED GROUND VEHICLE

EARLY RESEARCH EFFORTS

The academic community usually refers to UGVs (especially UGVs possessing

UNMANNED GROUND VEHICLE

Group 455, 7th Batch

Group 455, 10th Batch

GROUP 455, 7TH BATCH

This group created an UNMANNED INTELLIGENT NAVIGATION CAR (UINC)

UNMANNED GROUND VEHICLE

UNMANNED GROUND VEHICLE

capability on embedded side. This frequency range is sufficient to have coverage of

Figure 1.1: System Diagram of the Project

User-friendly Graphical User Interface on PC side.

Real time monitoring and control..

Feedback Control system (speed).

UNMANNED GROUND VEHICLE

This sections contains description of the hardware related issues

UNMANNED GROUND VEHICLE

UNMANNED GROUND VEHICLE

The mechanical assembly of the vehicle includes;

A front PMDC motor for direction control.

Rear motor PMDC for speed control.

Opto-coupler/disc assembly for speed sensing, mounted on the vehicles axel.

Tires for motion with traction.

Gears for coupling motor torque to wheels.

On-board video camera relaying live feed to PC.

Bumper at the front

Figure 2.1: Sketch of UGV

UNMANNED GROUND VEHICLE

UGV SPEED CONTROL

Figure 2.2: Speed motor control circuit