Unmanned Ground Vehicle Project Report

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

Final Final Year Year Proje Project ct Report Report 2008 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 Submitted to In-charge In-charge Final Year Project

Ashab Mirza Associate Professor IIEE

SUPERVISORS OF THE PROJECT

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

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 vehicle’s 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

UNM ANNED GROUND VEH I CLE

Page - 1

LIST OF FIGURES Figure 1.1: Block Diagram of the Project

Pg- 6

Figure 1.2: A Snapshot of UGV

Pg-10

Figure 2.1: Sketch of UGV

Pg-13

Figure 2.2: Speed motor control circuit

Pg-14

Figure 2.3: Position Motor Control Circuit

Pg-15

Figure 2.4: Optocoupler IC

Pg-16

Figure 3.1: Vehicle Side Schematic

Pg-20

Figure 3.2: LM317 Adjustable Positive Voltage Regulator

Pg-20

Figure 3.3: Transistor level circuitry modeling for single H-bridge package driving speed motor

Pg-22

Figure 3.4: Transistor level circuitry modeling for single H-bridge package driving direction motor

Pg-23

Figure 3.5: Optocoupler modeling using LED and phototransistor

Pg-25

Figure 3.6: Battery Discharge Curve

Pg-28

Figure 4.1: Xbee Pro

Pg-34

Figure 4.2: Data packet sent by the PC to the microcontroller

Pg-35

Figure 5.1: Linear velocity and angular velocity are related by equation of rolling

Pg-39

Figure 5.2: „C‟ & Direction Keys

Pg-40

Figure 5.3: Pre-Defined Maps

Pg-44

Figure 5.4: Segmented Map

Pg-44

Figure 5.5: Main GUI window

Pg-46

Figure 5.6: UGV Navigation Mode GUI window

Pg-47

Figure 5.7: UGV Autonomous Mode GUI window

Pg-48

Figure 6.1: Non inverting & Inverting PWM Concept

Pg-53

Figure 6.2: Illustration of inverting and non inverting PWM

Pg-53

Figure 6.3: Position Actuation Concept

Pg-54

Figure 7.1: Analog to Digital Image Conversion

Pg-59

Figure 7.2: Example of Single Frame Acquisition (filling in glass mug starts)

Pg-65

Figure 7.3: Example of Multiple Frame acquisition (Glass Mug filled)

Pg-67

Figure 8.1: An RGB image, along with its separate R, G and B components

Pg-71

Figure 8.2: A representation of additive color mixing

Pg-72

Figure 8.3: RGB Cube

Pg-74

Figure 8.4: Example of „imfilter‟

Pg-75

Figure 8.5: Vehicles and persons tracked throughout the scene

Pg-79

Figure 8.6: Implementation effects of Frame Comparison Algorithm

Pg-79

Figure 9.1: Speedometer

Pg-84

Figure 9.2: Block diagram of video image

Pg-85

Figure 10.1: Predefined map divided into segments

Pg-89

Figure 10.2: Motion Planning Workspace

Pg-94

_________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 ob vious: (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 UGV‟s: 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 PC‟s 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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


Page - 7

CHAPTER 1

I NTRODUCTION 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 user‟s 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: th

1)

Group 455, 7 Batch

2)

Group 455, 10 Batch

th

TH

GROUP 455, 7 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. TH

GROUP 455, 10 BATCH

This group built on the previous batch‟s 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 pre programmed 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 vehicle‟s 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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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.

PC side electronics Vehicle side electronics PC side power supply Vehicle side power supply e. 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 dir ectly connected to the PC‟s 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 IC‟s have been used. The output of the LM317 is; (3.1)

Values of R 2 and R 1 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 H bridge. 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;


UNM ANNED GR GROUND OUND VEH I CLE

Page Pa ge - 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

_____________________________________ ________________________ __________________________ __________________________ _______________ __ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300 75300


Page Pa ge - 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

PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300 75300


Page Pa ge - 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 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˚ -45˚ with respect to the vehicle body. _____________________________________ ________________________ __________________________ __________________________ _______________ __ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300 75300


3.2.4.3

Page - 27

FEEDBACK SENSOR INTERFACE:

Vehicle speed estimation is done through a sensor mounted on the UGV‟s 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 vehicle‟s speed and estimates the vehicle‟s position, thereby providing for effective tracking. The circuit for sensor interf acing 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 _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 PC‟s 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 vehicle‟s 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 IC‟s 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 R EQUIREMENT : 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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


3.6.2

Page - 30

C APACITY

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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 IC‟s 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

Of all of these, the only feasible alternatives were 1. Zigbee 2. Bluetooth _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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

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

4.4.1

START B YTE

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 B YTE

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 B YTE

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 B YTE

The End Byte is the final byte to be transmitted. It is to signal end of transmission. In case the start and stop bytes don‟t match, then the entire packet is ret ransmitted. This is a measure to ensure synchronization in communication.

4.4.5

CHECKSUM B YTE th

The sum of the aforementioned 4 bytes is transmitted as the 4 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)

’



5.1

Page - 39

COMMUNICATION WITH ‘MSCOMM’

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: _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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) _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 k eys 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 d ependent 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° orientation with respect to the vehicle body. 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: _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 ke y/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 vehicle‟s 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 _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 p articular 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 Atmel‟s 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 c ycle. 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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 clock‟s 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 clock‟s sawtooth wave, the PWM will have low logic level, as shown in figure 6.1. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


Page - 55

6.4 POSITION MOTOR ACTUATION For position motor the task was relatively simple. The vehicle‟s 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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 double precision 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 num ber of frames acquired.



Page - 60

7.5 ANALOG TO DIGITAL IMAGE CONVERSION Because of the unavailability of wireless digital ca mera 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 don‟t 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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 o ne 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 = vidobj.FramesAvailable numAvail = 14 % ... over time.



Page - 67

numAvail = vidobj.FramesAvailable 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 = vidobj.FramesAvailable 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 = vidobj.FramesAvailable 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 = vidobj.FramesAvailable 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 _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 mana gement.

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 _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


Page Pa ge - 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. _____________________________________ ________________________ __________________________ __________________________ _______________ __ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300 75300


Page Pa ge - 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 d efined 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 g reen light instead, and the wall will become _____________________________________ ________________________ __________________________ __________________________ _______________ __ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300 75300


Page Pa ge - 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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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)


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 t hroughout 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 vehicle‟s 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 vehicle‟s 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 c ycle.



9.2.2

Page - 84

DIRECTION

The vehicle‟s 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‟ k ey 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 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° orientation with respect to the vehicle body.



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

V EHICLE SPEED CALCULATION

As the feedback mechanism is such that only 2 pulses are obtained in one complete revolution of the vehicle‟s 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 de pendent on two factors, Resolution of microcontroller‟s timer Symmetry of holes‟ spacing. RPM of the vehicle is 60 times the RPS of the vehicle. RPS is inverse of time taken by wheels to complete one revolution. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


Page - 86

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 time taken between two consecutive high-to-low transitions is determined by st

starting a timer when 1 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 vehicle‟s 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



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 d isplayed 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 one single image frame, frame, from the video input object obj. The frame of data returned is independent of the

video input object F

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 vehicle‟s position is continuously track ed 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 STR AIGHT PATH OR A CURVED ONE . A CURVED PATH MAY BE A LEFT OR RIGHT TURN .

A map may be defined as follows; _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


Figure 10.1: PREDEFINED

Page - 90

MAP DIVIDED INTO SEGMENTS

AS C AN BE SEEN , THERE MAY BE MULTIPLE DESTINATIONS I N A S INGLE PATH , WITH MALFUNCTION E RROR R ESOUNDING IF A NY D ESTINATION WERE TO BE A MISMATCH. A TARGET IMAGE HAS TO BE ASSOCIATED WITH E ACH DESTINATION.

10.2.1 S EGMENT

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 vehicle‟s 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 vehicle‟s direction motor remains unactuated where as the speed motor turns at maximum speed.

10.3.2

CURVED SEGMENT

On curved paths, the vehicle‟s 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 vehicle‟s 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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


10.5

Page - 92

VEHICLE SPEED C ALCULATION

As the feedback mechanism is such that only 2 pulses are obtained in one complete revolution of the vehicle‟s 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 de pendent on two factors, Resolution of microcontroller‟s timer Symmetry of hole‟s spacing. 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 time taken between two consecutive high-to-low transitions is determined by st

starting a timer when 1 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 ex istence 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 po int.

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 _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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 _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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

R EFERENCES

[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, 2 nd 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, 5 th 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. _________________________________________________________________ PCSIR - Institute of Industrial Electronics Engineering, IIEE ST-22/C, Block-6 Gulshan-e-Iqbal, Karachi – 75300


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, 1 st Edition, McGraw-Hill, Inc. Singapore.

[Robert Resnick, 1992] Physics, 4 th Edition, Volume 1, John Wiley & Sons, Inc. [R.S. Khurmi, 1997] A Textbook of Applied Mechanics,13 th 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 Pa ge - 10 101 1

APPENDIX B

LAYOUT OF PCB



Page Pa ge - 10 102 2



Page Pa ge - 10 103 3

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<
; 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<
; 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 STS Motor_Feedback_Val_HB, Temp1

LDI Temp0, 0 OUT TCNT1H, Temp0 OUT TCNT1L, Temp0 RETI

; Reset timer value

T1OVHandler: LDI Temp0, 0xFF STS Motor_Feedback_Val_LB, Temp0 STS Motor_Feedback_Val_HB, 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<
; Set frame format: 8data, 1stop bit LDI Temp0, (1<
; 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<
; Arguments: Temp1=CMD, Temp2=VAL UART_SEND: CLR_BIT UART_Flag, (1<


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<
; 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

; Enable Timer1, Prescale = 64 ; Enable Timer1, Prescale = 256 ; Enable Timer1, Prescale = 1024

T2INIT: ; Initialize Timer2 for FastPWM, non-inverted with prescale of 32 (Making PWM freq=976 Hz) LDI R16, (1<
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 frm_DeBugMain.txt_UART = frm_DeBugMain.txt_UART & "SEND: " & 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() 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, "010 ") 'If DeBug_Mode And frm_DeBugMain.chk_UART_Display.Value = 1 Then frm_DeBugMain.txt_UART = frm_DeBugMain.txt_UART & "SEND: " & UART_SEND_CMD & " " & UART_SEND_VAL & " " s_OFb(0) = UART_SEND_CMD MSComm1.Output = s_OFb End Sub Public Sub RecvFIXByte() If DeBug_Mode And frm_DeBugMain.chk_UART_Display.Value = 1 Then frm_DeBugMain.txt_UART = frm_DeBugMain.txt_UART & "RECV: 1 fixbyte " 'If DeBug_Mode And frm_DeBugMain.chk_UART_Display.Value = 1 Then frm_DeBugMain.txt_UART = frm_DeBugMain.txt_UART & "SEND: " & UART_SEND_CMD & " " & UART_SEND_VAL & " " s_Ib = MSComm1.Input s_OFb(0) = UART_SEND_CMD MSComm1.Output = s_OFb End Sub



Page - 114

Private Sub TO_Timer_Timer() 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 frm_DeBugMain.txt_UART = frm_DeBugMain.txt_UART & "SEND: " & UART_SEND_CMD & " " & UART_SEND_VAL & " " 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.chk_UART_Display.Value = 1 Then frm_DeBugMain.txt_UART = frm_DeBugMain.txt_UART & "RECV: " & Format(Serial_Input, "000 ")



Page - 115

' If DeBug_Mode And frm_DeBugMain.chk_UART_Display.Value = 1 Then frm_DeBugMain.txt_UART = 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.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 frm_DeBugMain.txt_UART = frm_DeBugMain.txt_UART & "RECV: " & Format(Serial_Input, "000 ") ' If DeBug_Mode And frm_DeBugMain.chk_UART_Display.Value = 1 Then frm_DeBugMain.txt_UART = 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.Capt ion = 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 Label3.Caption = PWM_Speed ' Call frm_MSComm.Push2SSS(12, PWM_Speed) End If

Case vbKeyUp: If Up_Disabled = True Then Exit Sub Down_Disabled = True Up_Disabled = True Call frm_MSComm.Push2SSS(10, 1) Call frm_MSComm.Push2SSS(12, PWM_Speed) Case vbKeyDown: If Down_Disabled = True Then Exit Sub Up_Disabled = True Down_Disabled = True Call frm_MSComm.Push2SSS(11, 1) Call frm_MSComm.Push2SSS(12, PWM_Speed) Case vbKeyLeft: If Left_Disabled = True Then Exit Sub Right_Disabled = True Left_Disabled = True Call frm_MSComm.Push2SSS(14, 1) Case vbKeyRight: If Right_Disabled = True Then Exit Sub Left_Disabled = True Right_Disabled = True Call frm_MSComm.Push2SSS(13, 1) End Select End Sub

Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer) Label2 = KeyCode Select Case KeyCode Case vbKeyUp: Down_Disabled = False Up_Disabled = False Call frm_MSComm.Push2SSS(12, 0)



Page - 119

Case vbKeyDown: Up_Disabled = False Down_Disabled = False Call frm_MSComm.Push2SSS(12, 0) Case vbKeyLeft: Right_Disabled = False Left_Disabled = False Call frm_MSComm.Push2SSS(15, 1) Case vbKeyRight: Left_Disabled = False Right_Disabled = False Call frm_MSComm.Push2SSS(15, 1) Case vbKeyC: Call CaptureSS End Select End Sub Private Sub Form_Load() 'frm_MSComm.MSComm1.Settings = UGV_Baud & ",n,8,1" PWM_Speed = CAR_MAX_SPEED Label3.Caption = PWM_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

Private Sub Form_Unload(Cancel As Integer) '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 Private Sub Form_Load() 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) Call frm_MSComm.Push2SSS(5, 1) 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.Capt ion = Current_Time frm_UserMain.Label10.Cap tion = 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 Covered_Distance = 0 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 Result = Go_Straight(Actual_Feedback, Current_Time, Covered_Distance, Total_Distance) If Result Then Covered_Distance = 0 lbl_Error.Caption = "Turning on Segment 4." Local_Task = cSTEP4 Call frm_MSComm.Push2SSS(CMD_Motor_RIGHT, 1) End If Case cSTEP4: ' Turn Result = Go_Right(Actual_Feedback, Current_Time, Covered_Distance) If Result Then lbl_Error.Caption = "Straight on Segment 5." Local_Task = cSTEP5 Covered_Distance = 0 Total_Distance = cSegment5Dist Call frm_MSComm.Push2SSS(CMD_Motor_CENTER, 1) Call frm_MSComm.Push2SSS(CMD_Motor_PWM, CAR_MAX_SPEED) End If



Page - 124

Case cSTEP5: ' Go straight Result = Go_Straight(Actual_Feedback, Current_Time, Covered_Distance, Total_Distance) If Result Then lbl_Error.Caption = "Straight on Segment 6." Local_Task = cSTEP6 Covered_Distance = 0 Total_Distance = cSegment6Dist Call frm_MSComm.Push2SSS(CMD_Motor_CENTER, 1) Call frm_MSComm.Push2SSS(CMD_Motor_PWM, CAR_MAX_SPEED) End If Case cSTEP6: ' straight Result = Go_Straight(Actual_Feedback, Current_Time, Covered_Distance, Total_Distance) If Result Then Covered_Distance = 0 lbl_Error.Caption = "Turning on Segment 7." Local_Task = cSTEP7 Call frm_MSComm.Push2SSS(CMD_Motor_RIGHT, 1) End If Case cSTEP7: ' Turn Result = Go_Right(Actual_Feedback, Current_Time, Covered_Distance) If Result Then lbl_Error.Caption = "Straight on Segment 8." Local_Task = cSTEP8 Covered_Distance = 0 Total_Distance = cSegment8Dist Call frm_MSComm.Push2SSS(CMD_Motor_CENTER, 1) Call frm_MSComm.Push2SSS(CMD_Motor_PWM, CAR_MAX_SPEED) End If Case cSTEP8: ' Straight Result = Go_Straight(Actual_Feedback, Current_Time, Covered_Distance, Total_Distance) If Result Then Covered_Distance = 0 lbl_Error.Caption = "Turning on Segment 9." Local_Task = cSTEP9 Call frm_MSComm.Push2SSS(CMD_Motor_RIGHT, 1) End If Case cSTEP9: ' Turn Result = Go_Right(Actual_Feedback, Current_Time, Covered_Distance) If Result Then lbl_Error.Caption = "Straight on Segment 10." Local_Task = cSTEP10 Covered_Distance = 0 Total_Distance = cSegment10Dist



Page - 125

Call frm_MSComm.Push2SSS(CMD_Motor_CENTER, 1) Call frm_MSComm.Push2SSS(CMD_Motor_PWM, CAR_MAX_SPEED) End If Case cSTEP10: 'Straight Result = Go_Straight(Actual_Feedback, Current_Time, Covered_Distance, Total_Distance) If Result Then Covered_Distance = 0 lbl_Error.Caption = "Stopping on Segment 11." Local_Task = cSTEP11 Call frm_MSComm.Push2SSS(CMD_Motor_CENTER, 1) Call frm_MSComm.Push2SSS(CMD_Motor_PWM, 0) End If Case cSTEP11: ' Stop ' Result = Go_Straight(Actual_Feedba ck, Current_Time, Covered_Distance, Total_Distance) ' If Result Then Covered_Distance = 0 lbl_Error.Caption = "Stopping on Segment 11." Local_Task = cSTEP11 Call frm_MSComm.Push2SSS(CMD_Motor_CENTER, 1) Call frm_MSComm.Push2SSS(CMD_Motor_PWM, 0) ' 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. Call frm_MSComm.Push2SSS(CMD_Motor_PWM, 0) Call frm_MSComm.Push2SSS(CMD_Motor_CENTER, 0) Local_Task = cSTOP cmd_Start_Auto.Enabled = True opt_1.Enabled = True opt_2.Enabled = True opt_3.Enabled = True DoEvents ' Wait 1000 ms Call Reset_Sys_Time Do DoEvents Current_Time = Get_Sys_Time() * 1000 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) Current_Time = Get_Sys_Time() * 1000 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 opt_2.Enabled = False opt_3.Enabled = False ' Drive UGV on 1st segment lbl_Error.Caption = "Going straight on Segment 1." Local_Task = cSTEP1 Covered_Distance = 0 Total_Distance = cSegment1Dist 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 Target_Red = Target2_Red Target_Green = Target2_Green Target_Blue = Target2_Blue Target_Th = Target2_Th Final_STEP = cSTEP6 End If If opt_3.Value Then Target_Red = Target2_Red Target_Green = Target2_Green Target_Blue = Target2_Blue Target_Th = Target2_Th 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 Call frm_MSComm.Push2SSS(CMD_Motor_PWM, 0) Local_Task = cSTOP cmd_Start_Auto.Enabled = True opt_1.Enabled = True opt_2.Enabled = True opt_3.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 Down_Disabled = True Up_Disabled = True Call frm_MSComm.Push2SSS(10, 1) Call frm_MSComm.Push2SSS(12, PWM_Speed) Case vbKeyDown: If Down_Disabled = True Then Exit Sub Up_Disabled = True Down_Disabled = True Call frm_MSComm.Push2SSS(11, 1) Call frm_MSComm.Push2SSS(12, PWM_Speed) Case vbKeyLeft:



Page - 129

If Left_Disabled = True Then Exit Sub Right_Disabled = True Left_Disabled = True Call frm_MSComm.Push2SSS(14, 1) Case vbKeyRight: If Right_Disabled = True Then Exit Sub Left_Disabled = True Right_Disabled = True Call frm_MSComm.Push2SSS(13, 1) End Select End Sub Private Sub KeyUp(KeyCode As Integer) If UGV_Mode <> UGV_Navigation Then Exit Sub Select Case KeyCode Case vbKeyUp: Down_Disabled = False Up_Disabled = False Call frm_MSComm.Push2SSS(12, 0) Case vbKeyDown: Up_Disabled = False Down_Disabled = False Call frm_MSComm.Push2SSS(12, 0) Case vbKeyLeft: Right_Disabled = False Left_Disabled = False Call frm_MSComm.Push2SSS(15, 1) Case vbKeyRight: Left_Disabled = False Right_Disabled = False Call frm_MSComm.Push2SSS(15, 1) 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) Call KeyDown(KeyCode) 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) Call KeyDown(KeyCode) 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) Call KeyDown(KeyCode) 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) Call KeyDown(KeyCode) 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) Call KeyDown(KeyCode) End Sub Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer) 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) *********

Private Sub Form_Load() ' obj_Speedometer.Setup picSpeedometer, 0, Max_UGV_RPM End Sub

Private Sub Form_Unload(Cancel As Integer) OutFile To_MATLAB_File, Terminate_Application_Code End End Sub



Page - 131

APPENDIX E

MATLAB SOURCE CODES



Page Pa ge - 13 132 2

%function [image,index]=find_color(image,map,tr,colors) function [my_ans, 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, 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 (a=1:i) for (b=1:j) for (b=1:j) %for (a=1:2:i) for (b=1:2:j) if ((abs(I(a,b,1)-R) if ((abs(I(a,b,1)-R)


Page Pa ge - 13 133 3

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 Pa ge - 13 134 4

Private Sub init_Matlab() ' frm_Splash.lbl_LoadStatus.Ca ption = "Starting Matlab...." Set Matlab = CreateObject("MatLab.Application") ' Matlab.Visible = False ' Hide the matlab window ' frm_Splash.lbl_LoadStatus.Ca ption = "Initializing frame grabber device...." MatlabCommand = "cd '" & CurDir & "'" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult MatlabCommand = "vidobj = videoinput('winvideo', 1, 'RGB555_768x576')" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult MatlabCommand = "selectedsrc = getselectedsource(vidobj)" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult MatlabCommand = "selectedsrc.AnalogVideoFormat='pal_b'" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult MatlabCommand = "selectedsrc.Contrast=9000" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult MatlabCommand = "selectedsrc.Brightness=6500" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult MatlabCommand = "selectedsrc.Saturation=9000" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult MatlabCommand = "triggerconfig(vidobj, 'manual')" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult MatlabCommand = "start(vidobj)" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult OutFile To_UGV_File, MATLAB_init_code End Sub

Public Sub Preview_Vidobj() MatlabCommand = "vidRes = get(vidobj, 'VideoResolution');" MatlabResult = Matlab.Execute(MatlabCommand)



Page - 135

MatlabCommand = "nBands = get(vidobj, 'NumberOfBands');" MatlabResult = Matlab.Execute(MatlabCommand) MatlabCommand = "hImage = image( zeros(vidRes(2), vidRes(1), nBands) );" MatlabResult = Matlab.Execute(MatlabCommand) MatlabCommand = "preview(vidobj, hImage);" MatlabResult = Matlab.Execute(MatlabCommand) End Sub Public Sub Stop_Vidobj() MatlabCommand = "close;" MatlabResult = Matlab.Execute(MatlabCommand) Debug.Print MatlabResult 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);" MatlabResult = Matlab.Execute(MatlabCommand) 'Debug.Print Result MatlabCommand = "[Mat_Ans Mat_Perc] = our_color_test (snapshot, [], " & Str(Tr) _ & ", [" & Str(TargetRED) & Chr(vbKeySpace) & Str(TargetGREEN) & Chr(vbKeySpace) & Str(TargetBLUE) & "])" MatlabResult = Matlab.Execute(MatlabCommand) '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);" MatlabResult = Matlab.Execute(MatlabCommand) MatlabCommand = "imwrite (snapshot,'" & SSFile & "', 'bmp');" MatlabResult = Matlab.Execute(MatlabCommand) 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

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

VI - VO

40

V

Lead Temperature

TLEAD

230

°C

Power Dissipation

PD

Internally limited

W

T j

0 ~ +125

°C

TSTG

-65 ~+125

°C

∆Vo/∆T

±0.02

%/°C

Operating Junction Temperature Range Storage Temperature Range Temperature Coefficient of Output Voltage

Electrical Characteristics (VI-VO=5V, IO= 0.5A, 0°C ≤ TJ ≤ + 125°C, IMAX = 1.5A, PDMAX = 20W, unless otherwise specified) Parameter Line Regulation (Note1)

Load Regulation (Note1)

Adjustable Pin Current

Symbol Rline

Rload

Conditions

Min

Typ.

Max.

Unit

T A = +25°C 3V ≤ VI - VO ≤ 40V

-

0.01

0.04

%/V

3V ≤ VI - VO ≤ 40V

-

0.02

0.07

%/V

T A = +25°C, 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

I ADJ

-

-

46

100

µ A

Adjustable Pin Current Change

∆I ADJ

3V ≤ VI - VO ≤ 40V 10mA ≤ IO ≤ IMAX PD ≤ PMAX

-

2.0

5

µ A

Reference Voltage

VREF

3V ≤ VIN - VO ≤ 40V 10mA ≤ IO ≤ IMAX PD ≤ PMAX

1.20

1.25

1.30

V

-

0.7

-

% / VO

-

3.5

12

mA

1.0

2.2 0.3

-

A

-

0.003

0.01

% / VO

66

60 75

-

dB

-

0.3

1

%

-

5

-

°C / W

Temperature Stability Minimum Load Current to Maintain Regulation Maximum Output Current RMS Noise, % of VOUT Ripple Rejection Long-Term Stability, TJ = THIGH Thermal Resistance Junction to Case

STT

-

IL(MIN)

VI - VO = 40V

IO(MAX)

VI - VO ≤ 15V, PD ≤ PMAX VI - VO ≤ 40V, PD ≤ PMAX T A=25°C

eN

T A= +25°C, 10Hz ≤ f ≤ 10KHz

RR

VO = 10V, f = 120Hz without C ADJ C ADJ = 10µF (Note2)

ST

T A = +25°C for end point measurements, 1000HR

RθJC

-

Note: 1. Load and line regulation are specified at constant junction temperature. Change in V D due to heating effects must be taken into account separately. Pulse testing with low duty is used. (PMAX = 20W) 2. C ADJ, when used, is connected between the adjustment pin and ground.

2

LM317

Typical Perfomance Characteristics

) % ( N O I T A I V E D E G A T L O V T U P T U O

) A u ( T N E R R U C T N E M T S U J D A

TEMPERATURE (°C)

TEMPERATURE (°C)

Figure 1. Load Regulation

) V ( L A I T N E R E F F I D T U P T U O T U P N I

Figure 2. Adjustment Current

) V ( E G A T L O V E C N E R E F E R

TEMPERATURE (°C)

Figure 3. Dropout Voltage

TEMPERATURE (°C)

Figure 4. Reference Voltage

3

LM317

Typical Application VI Input Ci 0. 1µF

VI

LM317 KA317

Output

Vo

Vadj

R1 I adj R2

Co 1µF

I adj

VO = 1.25V (1+ R 2 / R1)+Iadj R2

Figure 5. Programmable Regulator

Ci is required when r egulator is located an appreciable distance from power supply filter. Co is not needed f or stability, however, it does improve transient r esponse. Since IADJ is controlled to less than 100µA, the error associated with this term is negligible in most applications.

4

LM317

Mechanical Dimensions Package

TO-220 4.50 ±0.20

9.90 ±0.20 ) 0 7 . 1 (

0 1 . 0

(8.70)

±

0 3 . 1

ø3.60

+0.10

±

±0.10

1.30 –0.05

0 8 . 2

. X A M ± 5 0 9 . 9 . 8 1 ) 5 0 1 0 . 3 ( ) 0 7 . 3 (

0 2 . 0

±

0 2 . 9

0 1 . 0

) 6 4 . 1 (

0 2 . 0

( 4 5 ° ) 0 2 . 0

±

8 0 . 3 1

) 0 0 . 1 (

0 3 . 0

1.27 ±0.10

1.52 ±0.10

0.80 ±0.10 2.54TYP [2.54 ±0.20]

±

8 0 . 0 1

+0.10

0.50 –0.05

2.40 ±0.20

2.54TYP [2.54 ±0.20]

10.00 ±0.20

5

LM317

Ordering Information

6

Product Number

Package

Operating Temperature

LM317T

TO-220

0°C to + 125°C

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 FAIRCHILD’S 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

V SS

Logic Supply Voltage

36

V

Input Voltage

7

V

Enable Voltage

7

V

1.2

A

4

W

– 40 to 150

°C

Vi V en Io P tot Tstg, T j

Peak Output Current (100 µ s non repetitive) Total Power Dissipation at Tpins = 90 ° C Storage and Junction Temperature

PIN CONNECTIONS (Top view)

SO(12+4+4)

Powerdip(12+2+2)

THERMAL DATA Symbol

Decription

SO

Unit

Rth j-pins

Thermal Resistance Junction-pins

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

DIP

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

V SS

Logic Supply Voltage (pin 20)

4.5

36

V

IS

Total Quiescent Supply Current (pin 10)

Vi = L ; IO = 0 ; Ven = H

2

6

mA

Vi = H ; I O = 0 ; Ven = H

16

24

mA

4

mA

Ven = L ISS

Total Quiescent Logic Supply Current (pin 20)

Vi = L ; IO = 0 ; Ven = H

44

60

mA

Vi = H ; I O = 0 ; Ven = H

16

22

mA

Ven = L

16

24

mA

– 0.3

1.5

V

V IL

Input Low Voltage (pin 2, 9, 12, 19)

VIH

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

VSS ≤ 7 V

2.3

VSS

V

VSS > 7 V

2.3

7

V

IIL

Low Voltage Input Current(pin 2, 9, 12, 19)

VIL = 1.5 V

– 10

µA

IIH

High Voltage Input Current (pin 2, 9, 12, 19)

2.3 V ≤ V IH ≤ V SS – 0.6 V

100

µA

– 0.3

1.5

V

30

Ven L

Enable Low Voltage (pin 1, 11)

Ven H

Enable High Voltage (pin 1, 11)

VSS ≤ 7 V

2.3

VSS

V

VSS > 7 V

2.3

7

V

Ien L

Low Voltage Enable Current (pin 1, 11)

Ven L = 1.5 V

– 100

µA

Ien H

High Voltage Enable Current (pin 1, 11)

2.3 V ≤ V en H ≤ VSS – 0.6 V

± 10

µA

VCE(sat)H

Source Output Saturation Voltage (pins 3, 8, 13, 18)

IO = – 0.6 A

1.4

1.8

V

VCE(sat)L

Sink Output Saturation Voltage (pins 3, 8, 13, 18)

IO = + 0.6 A

1.2

1.8

V

VF

Clamp Diode Forward Voltage

IO = 600nA

1.3

V

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) Input

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: Junctionto 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

B

0.85

b b1

TYP.

inch MAX.

MIN.

TYP.

MAX.

0.020 1.40

0.033

0.50 0.38

0.020 0.50

D

0.055

0.015

0.020

20.0

0.787

E

8.80

0.346

e

2.54

0.100

e3

17.78

0.700

F

7.10

0.280

I

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

MAX.

MIN.

TYP.

2.65 0.1

MAX. 0.104

0.2

a2

0.004

0.008

2.45

0.096

b

0.35

0.49

0.014

0.019

b1

0.23

0.32

0.009

0.013

C

0.5

0.020

c1

45

1.772

D

1

E

10

12.6

0.039

10.65

0.394

1.27

0.050

e3

11.43

0.450

F

1

7.4

0.496 0.419

e

0.039

0.291

G

8.8

9.15

0.346

0.360

L

0.5

1.27

0.020

0.050

M S

6/7

inch

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 t hird 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. T his publication supersedes and replaces a ll information previously supplied. SGS-THOMSON Microelectronics products are not authorized for use as criticalc omponents in life support devices or systems without express written approval of SGS-THOMSON Microelectronics. � 1996 SGS-THOMSON

Microelectronics – Printedi n 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 - S witzerland - 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, 25°C – 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. 2486MS–AVR–12/03 2486MS–AVR–12/03

Note: This is a summary document. A complete document is available on our Web site at www.atmel.com.

Pin Configurations PDIP (RESET) (RXD) (TXD) (INT0) (INT1) (XCK/T0)

PC6 PD0 PD1 PD2 PD3 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)

TQFP Top View ) ) L A D ) C T S / S / ) ) ) ) ) E 5 4 3 2 0 D D S C C C C T X X E D D D D N I ( T ( R ( R ( A ( A ( A ( A ( 2 1 0 6 5 4 3 2 D D D C C C C C P P P P P P P P 2 1 0 9 8 7 6 5 3 3 3 2 2 2 2 2

(INT1) PD3 (XCK/T0) PD4 GND VCC GND VCC (XTAL1/TOSC1) PB6 (XTAL2/TOSC2) PB7

1 2 3 4 5 6 7 8 9

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)

0 1 2 3 4 5 6 1 1 1 1 1 1 1

5 6 7 0 1 2 3 4 D D D B B B B B P P P P P P P P ) ) ) ) ) ) ) ) 1 0 1 1 A B 2 O T N I N P 1 1 C I S ( I C C C / O A ( O O I ( M ( A ( I ( / S S O S ( M (

MLF Top View ) ) L A D ) C S / S ) ) T / ) ) ) E 5 4 3 2 0 D D S C C C C T X X E D D D D N T R R A A A A I ( ( ( ( ( ( ( ( 2 1 0 6 5 4 3 2 D D D C C C C C P P P P P P P P 2 1 0 9 8 7 6 5 3 3 3 2 2 2 2 2

(INT1) PD3 (XCK/T0) PD4 GND VCC GND VCC (XTAL1/TOSC1) PB6 (XTAL2/TOSC2) PB7

1 2 3 4 5 6 7 8 9

0 1 2 3 4 5 6 1 1 1 1 1 1 1

5 6 7 0 1 2 3 4 D D D B B B B B P P P P P P P P ) ) ) ) ) ) ) ) 1 0 1 1 A B 2 O T I N I N P 1 1 C S ( I I C C O A ( A C / M ( ( O ( / I ( O S S O S ( M (

2

ATmega8(L) 2486MS–AVR–12/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

STACK

COUNTER

POINTER

TWI

AGND AREF TIMERS/

PROGRAM FLASH

SRAM

COUNTERS

OSCILLATOR

INTERNAL OSCILLATOR

INSTRUCTION

GENERAL

WATCHDOG

REGISTER

PURPOSE

TIMER

OSCILLATOR

REGISTERS X INSTRUCTION DECODER

Y

MCU CTRL. & TIMING

Z

CONTROL LINES

ALU

AVR CPU

REGISTER

PROGRAMMING LOGIC

+ -

INTERRUPT

STATUS

SPI

UNIT

EEPROM

USART

COMP. INTERFACE

PORTD DIGITAL INTERFACE

PORTD DRIVERS/BUFFERS

PD0 - PD7

3 2486MS–AVR–12/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 whi le 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, allowi ng 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 Atmel’s 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

4

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) 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 b oth 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 condition becomes active, even if the clock is not running.

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 condition becomes active, even if the clock is not running. 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 2486MS–AVR–12/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 V CC, even if the ADC is not used. If the ADC is used, it should be connected to V CC through a low-pass filter. Note that Port C (5..4) use digital supply voltage, V CC.

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.

6


ATmega8(L) Register Summary Address

Name

Bit 7

Bit 6

Bit 5

Bit 4

0x3F (0x5F)

SREG

0x3E (0x5E)

SPH

0x3D (0x5D)

SPL

SP7

0x3C (0x5C)

Reserved

0x3B (0x5B)

GICR

0x3A (0x5A)

GIFR

0x39 (0x59)

TIMSK

OCIE2

Bit 3

Bit 2

Bit 1

Bit 0

Page

I

T

H

S

V

N

Z

C

9

–

–

–

–

–

SP10

SP9

SP8

11

SP6

SP5

SP4

SP3

SP2

SP1

SP0

11

INT1

INT0

–

–

–

–

IVSEL

IVCE

47, 65

INTF1

INTF0

–

–

–

–

–

–

66

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)

70

0x31 (0x51)

OSCCAL

Oscillator Calibration Register

29

0x30 (0x50)

SFIOR

–

–

–

–

ACME

PUD

PSR2

PSR10

56, 73, 121, 190

0x2F (0x4F)

TCCR1A

COM1A1

COM1A0

COM1B1

COM1B0

FOC1A

FOC1B

WGM11

WGM10

95

0x2E (0x4E)

TCCR1B

ICNC1

ICES1

–

WGM13

WGM12

CS12

CS11

CS10

98

0x2D (0x4D)

TCNT1H

Timer/Counter1 – Counter Register High byte

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

0x1F (0x3F)

EEARH

–

–

–

–

–

–

–

EEAR8

18

0x1E (0x3E)

EEARL

EEAR7

EEAR6

EEAR5

EEAR4

EEAR3

EEAR2

EEAR1

EEAR0

18

0x1D (0x3D)

EEDR

0x1C (0x3C)

EECR

–

–

–

–

EERIE

EEMWE

EEWE

EERE

18

0x1B (0x3B)

Reserved

0x1A (0x3A)

Reserved

0x19 (0x39)

Reserved

0x18 (0x38)

PORTB

PORTB7

PORTB6

PORTB5

PORTB4

PORTB3

PORTB2

PORTB1

PORTB0

63

0x17 (0x37)

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

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

63

EEPROM Data Register

153

18

0x0F (0x2F)

SPDR

0x0E (0x2E)

SPSR

SPIF

WCOL

–

–

SPI Data Register –

–

–

SPI2X

128

128

0x0D (0x2D)

SPCR

SPIE

SPE

DORD

MSTR

CPOL

CPHA

SPR1

SPR0

126

0x0C (0x2C)

UDR

0x0B (0x2B)

UCSRA

RXC

TXC

UDRE

0x0A (0x2A)

UCSRB

RXCIE

TXCIE

UDRIE

0x09 (0x29)

UBRRL

0x08 (0x28)

ACSR

ACD

ACBG

ACO

0x07 (0x27)

ADMUX

REFS1

REFS0

0x06 (0x26)

ADCSRA

ADEN

ADSC

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

150

FE

DOR

PE

U2X

MPCM

151

RXEN

TXEN

UCSZ2

RXB8

TXB8

152

ACIC

ACIS1

ACIS0

191

USART Baud Rate Register Low byte

155

ACI

ACIE

ADLAR

–

MUX3

MUX2

MUX1

MUX0

202

ADFR

ADIF

ADIE

ADPS2

ADPS1

ADPS0

204

Two-wire Serial Interface Data Register TWA6

TWA5

TWA4

TWA3

TWA2

170 TWA1

TWA0

TWGCE

170

7 2486MS–AVR–12/03

Register Summary (Continued) Address

Name

Bit 7

Bit 6

Bit 5

0x01 (0x21)

TWSR

TWS7

TWS6

TWS5

0x00 (0x20)

TWBR

Notes:

8

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0

Page

TWS4

TWS3

–

TWPS1

TWPS0

170

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) 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

1 1

ADIW

Rdl,K

Add Immediate to Word

Rdh:Rdl ← Rdh:Rdl + K

Z,C,N,V,S

2

SUB

Rd, Rr

Subtract two Registers

Rd ← Rd - Rr

Z,C,N,V,H

1

SUBI

Rd, K

Subtract Constant from Register

Rd ← Rd - K

Z,C,N,V,H

1

SBC

Rd, Rr

Subtract with Carry two Registers

Rd ← Rd - Rr - C

Z,C,N,V,H

1

SBCI

Rd, K

Subtract with Carry Constant from Reg.

Rd ← Rd - K - C

Z,C,N,V,H

1

SBIW

Rdl,K

Subtract Immediate from Word

Rdh:Rdl ← Rdh:Rdl - K

Z,C,N,V,S

2

AND

Rd, Rr

Logical AND Registers

Rd ← Rd • Rr

Z,N,V

1 1

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

1

ORI

Rd, K

Logical OR Register and Constant

Rd ← Rd v K

Z,N,V

1

EOR

Rd, Rr

Exclusive OR Registers

Rd ← Rd ⊕ Rr

Z,N,V

1

COM

Rd

One’s Complement

Rd ← 0xFF − Rd

Z,C,N,V

1

NEG

Rd

Two’s Complement

Rd ← 0x00 − Rd

Z,C,N,V,H

1

SBR

Rd,K

Set Bit(s) in Register

Rd ← Rd v K

Z,N,V

1

CBR

Rd,K

Clear Bit(s) in Register

Rd ← Rd • (0xFF - K)

Z,N,V

1

INC

Rd

Increment

Rd ← Rd + 1

Z,N,V

1

DEC

Rd

Decrement

Rd ← Rd − 1

Z,N,V

1

TST

Rd

Test for Zero or Minus

Rd ← Rd • Rd

Z,N,V

1

CLR

Rd

Clear Register

Rd

Z,N,V

1

SER

Rd

Set Register

Rd ← 0xFF

None

1

MUL

Rd, Rr

Multiply Unsigned

R1:R0 ← Rd x Rr

Z,C

2

MULS

Rd, Rr

Multiply Signed

R1:R0 ← Rd x Rr

Z,C

2

MULSU

Rd, Rr

Multiply Signed with Unsigned

R1:R0 ← Rd x Rr

Z,C

2

FMUL

Rd, Rr

Fractional Multiply Unsigned

R1:R0 ← (Rd x Rr) <<

Z,C

2

FMULS

Rd, Rr

Fractional Multiply Signed

Z,C

2

FMULSU

Rd, Rr

Fractional Multiply Signed with Unsigned

1 R1:R0 ← (Rd x Rr) << 1 R1:R0 ← (Rd x Rr) << 1

Z,C

2

← Rd ⊕ Rd

BRANCH INSTRUCTIONS RJMP

k

IJMP RCALL

k

Relative Jump

PC ← PC + k + 1

None

2

Indirect Jump to (Z)

PC ← Z

None

2

Relative Subroutine Call

PC ← PC + k + 1

None

3

ICALL

Indirect Call to (Z)

PC ← Z

None

3

RET

Subroutine Return

PC ← STACK

None

4

RETI

Interrupt Return

PC ← STACK

I

4

CPSE

Rd,Rr

Compare, Skip if Equal

if (Rd = Rr) PC ← PC + 2 or 3

None

1/ 2/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

1

CPI

Rd,K

Compare Register with Immediate

Rd − K

Z, N,V,C,H

1

1

SBRC

Rr, b

Skip if Bit in Register Cleared

if (Rr(b)=0) PC ← PC + 2 or 3

None

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 PC←PC+k + 1

None

1/2

BRBC

s, k

Branch if Status Flag Cleared

if (SREG(s) = 0) then PC←PC+k + 1

None

1/2

BREQ

k

Branch if Equal

if (Z = 1) then PC ← PC + k + 1

None

1/2

BRNE

k

Branch if Not Equal

if (Z = 0) then PC ← PC + k + 1

None

1/2

BRCS

k

Branch if Carry Set

if (C = 1) then PC ← PC + k + 1

None

1/2

BRCC

k

Branch if Carry Cleared

if (C = 0) then PC ← PC + k + 1

None

1/2

BRSH

k

Branch if Same or Higher

if (C = 0) then PC ← PC + k + 1

None

1/2

BRLO

k

Branch if Lower

if (C = 1) then PC ← PC + k + 1

None

1/2

BRMI

k

Branch if Minus

if (N = 1) then PC ← PC + k + 1

None

1/2

BRPL

k

Branch if Plus

if (N = 0) then PC ← PC + k + 1

None

1/2

BRGE

k

Branch if Greater or Equal, Signed

if (N ⊕ V= 0) then PC

← PC

+k+1

None

1/2

BRLT

k

Branch if Less Than Zero, Signed

if (N ⊕ V= 1) then PC

← PC

+k+1

None

1/2

BRHS

k

Branch if Half Carry Flag Set

if (H = 1) then PC ← PC + k + 1

None

1/2

BRHC

k

Branch if Half Carry Flag Cleared

if (H = 0) then PC ← PC + k + 1

None

1/2

BRTS

k

Branch if T Flag Set

if (T = 1) then PC ← PC + k + 1

None

1/2

BRTC

k

Branch if T Flag Cleared

if (T = 0) then PC ← PC + k + 1

None

1/2

BRVS

k

Branch if Overflow Flag is Set

if (V = 1) then PC ← PC + k + 1

None

1/2

BRVC

k

Branch if Overflow Flag is Cleared

if (V = 0) then PC ← PC + k + 1

None

1/2

Mnemonics

Operands

Description

Operation

Flags

#Clocks

9 2486MS–AVR–12/03

Instruction Set Summary (Continued) BRIE

k

Branch if Interrupt Enabled

if ( I = 1) then PC ← PC + k + 1

None

1/2

BRID

k

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

1

MOVW

Rd, Rr

Copy Register Word

Rd+1:Rd ← Rr+1:Rr

None

1

LDI

Rd, K

Load Immediate

Rd

LD

Rd, X

Load Indirect

Rd ← (X)

← K

None

1

None

2

LD

Rd, X+

Load Indirect and Post-Inc.

Rd ← (X), X ← X + 1

None

2

LD

Rd, - X

Load Indirect and Pre-Dec.

X ← X - 1, Rd ← (X)

None

2

LD

Rd, Y

Load Indirect

Rd ← (Y)

None

2

LD

Rd, Y+


Rd ← (Y), Y ← Y + 1

None

2

LD

Rd, - Y


Y ← Y - 1, Rd ← (Y)

None

2

LDD

Rd,Y+q

Load Indirect with Displacement

Rd ← (Y + q)

None

2

LD

Rd, Z

Load Indirect

Rd ← (Z)

None

2

LD

Rd, Z+


Rd ← (Z), Z ← Z+1

None

2

LD

Rd, -Z


Z ← Z - 1, Rd ← (Z)

None

2

LDD

Rd, Z+q

Load Indirect with Displacement

Rd ← (Z + q)

None

2

LDS

Rd, k

Load Direct from SRAM

Rd

None

2

ST

X, Rr

Store Indirect

(X) ← Rr

None

2

ST

X+, Rr

Store Indirect and Post-Inc.

(X) ← Rr, X ← X + 1

None

2

ST

- X, Rr

Store Indirect and Pre-Dec.

X ← X - 1, (X) ← Rr

None

2

ST

Y, Rr

Store Indirect

(Y) ← Rr

None

2

ST

Y+, Rr


(Y) ← Rr, Y ← Y + 1

None

2

ST

- Y, Rr


Y ← Y - 1, (Y) ← Rr

None

2

STD

Y+q,Rr

Store Indirect with Displacement

(Y + q) ← Rr

None

2

ST

Z, Rr

Store Indirect

(Z) ← Rr

None

2

ST

Z+, Rr


(Z) ← Rr, Z ← Z + 1

None

2

ST

-Z, Rr


Z ← Z - 1, (Z) ← Rr

None

2

STD

Z+q,Rr

Store Indirect with Displacement

(Z + q) ← Rr

None

2

STS

k, Rr

Store Direct to SRAM

(k) ← Rr

None

2

Load Program Memory

R0 ← (Z)

None

3

LPM

← (k)

LPM

Rd, Z

Load Program Memory

Rd ← (Z)

None

3

LPM

Rd, Z+

Load Program Memory and Post-Inc

Rd ← (Z), Z ← Z+1

None

3

Store Program Memory

(Z) ← R1:R0

None

-

In Port

Rd ← P

None

1 1

SPM IN

Rd, P

OUT

P, Rr

Out Port

P ← Rr

None

PUSH

Rr

Push Register on Stack

STACK ← Rr

None

2

POP

Rd

Pop Register from Stack

Rd ← STACK

None

2

BIT AND BIT-TEST INSTRUCTIONS SBI

P,b

Set Bit in I/O Register

I/O(P,b) ← 1

None

2

CBI

P,b

Clear Bit in I/O Register

I/O(P,b) ← 0

None

2

LSL

Rd

Logical Shift Left

Rd(n+1) ← Rd(n), Rd(0) ← 0

Z,C,N,V

1

LSR

Rd

Logical Shift Right

Rd(n) ← Rd(n+1), Rd(7) ← 0

Z,C,N,V

1

ROL

Rd

Rotate Left Through Carry

Rd(0)←C,Rd(n+1)← Rd(n),C←Rd(7)

Z,C,N,V

1 1

ROR

Rd

Rotate Right Through Carry

Rd(7)←C,Rd(n)← Rd(n+1),C←Rd(0)

Z,C,N,V

ASR

Rd

Arithmetic Shift Right

Rd(n) ← Rd(n+1), n=0..6

Z,C,N,V

1

SWAP

Rd

Swap Nibbles

Rd(3..0)←Rd(7..4),Rd(7..4)←Rd(3..0)

None

1

BSET

s

Flag Set

SREG(s) ← 1

SREG(s)

1

BCLR

s

Flag Clear

SREG(s) ← 0

SREG(s)

1

BST

Rr, b

Bit Store from Register to T

T ← Rr(b)

T

1

BLD

Rd, b

Bit load from T to Register

Rd(b) ← T

None

1

Set Carry

C ← 1

C

1

CLC

Clear Carry

C ← 0

C

1

SEN

Set Negative Flag

N ← 1

N

1

SEC

CLN

Clear Negative Flag

N ← 0

N

1

SEZ

Set Zero Flag

Z ← 1

Z

1

CLZ

Clear Zero Flag

Z ← 0

Z

1

SEI

Global Interrupt Enable

I

I

1

← 1

CLI

Global Interrupt Disable

I ← 0

I

1

SES

Set Signed Test Flag

S ← 1

S

1

CLS

Clear Signed Test Flag

S ← 0

S

1

SEV

Set Twos Complement Overflow.

V ← 1

V

1

CLV

Clear Twos Complement Overflow

V ← 0

V

1

SET

Set T in SREG

T ← 1

T

Mnemonics

10

Operands

Description

Operation

1

Flags

#Clocks


ATmega8(L) Instruction Set Summary (Continued) CLT

Clear T in SREG

T ← 0

T

1

SEH

Set Half Carry Flag in SREG

H ← 1

H

1

CLH

Clear Half Carry Flag in SREG

H ← 0

H

1

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 2486MS–AVR–12/03

Ordering Information Speed (MHz)

Power Supply

Ordering Code

Package

8

2.7 - 5.5

ATmega8L-8AC

32A

Commercial

ATmega8L-8PC ATmega8L-8MC

28P3 32M1-A

(0°C to 70°C)

ATmega8L-8AI

32A

ATmega8L-8PI ATmega8L-8MI

28P3 32M1-A

ATmega8-16AC ATmega8-16PC

32A 28P3

ATmega8-16MC

32M1-A

ATmega8-16AI

32A

ATmega8-16PI ATmega8-16MI

28P3 32M1-A

16

Note:

4.5 - 5.5

Operation Range

Industrial (-40°C to 85 °C) Commercial (0°C to 70°C) Industrial (-40°C to 85 °C)

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) Packaging Information 32A

PIN 1 B PIN 1 IDENTIFIER

E1

e

E

D1 D C

0˚~7˚ A1

A2

A

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

A

–

–

1.20

A1

0.05

–

0.15

A2

0.95

1.00

1.05

D

8.75

9.00

9.25

D1

6.90

7.00

7.10

E

8.75

9.00

9.25

E1

6.90

7.00

7.10

B

0.30

–

0.45

C

0.09

–

0.20

L

0.45

–

0.75

e

NOTE

Note 2

Note 2

0.80 TYP

10/5/2001

R

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. 32A

REV.

B

13 2486MS–AVR–12/03

28P3

D

PIN 1

E1

A

SEATING PLANE

L

B2 B1

A1

B

(4 PLACES)

0º ~ 15º

REF

e E COMMON DIMENSIONS

C

(Unit of Measure = mm) SYMBOL

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

NOTE

A

–

–

4.5724

A1

0.508

–

–

D

34.544

–

34.798

E

7.620

–

8.255

E1

7.112

–

7.493

B

0.381

–

0.533

B1

1.143

–

1.397

B2

0.762

–

1.143

L

3.175

–

3.429

C

0.203

–

0.356

eB

–

–

10.160

e

Note 1

Note 1

2.540 TYP

09/28/01

R

14


TITLE 28P3, 28-lead (0.300"/7.62 mm Wide) Plastic Dual

Inline Package (PDIP)

DRAWING NO.

28P3

REV.

B


ATmega8(L) 32M1-A

D D1

1

0

2

Pin 1 ID

3

E1

SIDE VIEW

E

TOP VIEW

A3 A2 A1 A 0.08 C

P

COMMON DIMENSIONS (Unit of Measure = mm)

D2 Pin 1 ID 1

P

2 3

E2

SYMBOL

MIN

NOM

MAX

A

0.80

0.90

1.00

A1

–

0.02

0.05

A2

–

0.65

1.00

A3 b

e

b

L

BOTTOM VIEW

0.20 REF 0.18

0.30

5.00 BSC

D1

4.75 BSC 2.95

3.10

3.25

E

5.00 BSC

E1

4.75BSC

E2

2.95

e

Notes: 1. JEDEC Standard MO-220, Fig. 2 (Anvil Singulation), VHHD-2.

0.23

D

D2

NOTE

3.10

3.25

0.50 BSC

L

0.30

0.40

0.50

P

–

–

0

–

–

0.60 o 12

01/15/03

R


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 2486MS–AVR–12/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) 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

All page numbers refers to this document. 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.

Changes from Rev. 2486I-12/02 to Rev. 2486J-02/03

Updated “Erratas” on page 16.


17 2486MS–AVR–12/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) 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.

1

Changes in “Digital Input Enable and Sleep Modes” on page 53.

2

Addition of OCS2 in “MOSI/OC2 – Port B, Bit 3” on page 57.

3

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.

5

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

All page numbers refers to this document. 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.

2

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.

3

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


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 2486MS–AVR–12/03

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


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.

2

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 – OSCC AL” on page 29 and “Calibration Byte” on page 221.

3

Added Some Preliminary Test Limits and Characterization Data. Removed some of the TBD’s 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 = -40×C to 85×C, VCC = 2.7V to 5.5V (unless otherwise noted)” on page 237, Table 99 on page 239, and Table 102 on page 241.

4

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.

5

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


Atmel Corporation 2325 Orchard Parkway 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 2325 Orchard Parkway San Jose, CA 95131, USA 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 2325 Orchard Parkway San Jose, CA 95131, USA 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 t han those expressly contained in the Company’s standard warranty which is detailed in Atmel’s Terms and Conditions located on the Company’s 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. Atmel’s products are not authorized for use as critical components in life support devices or systems.

© Atmel Cor pora tio n 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. 2486MS–AVR–12/03

Product Datasheet

XBee™ ZigBee® /802.15.4 Modules 2.4 GHz OEM RF Modules

Part of Digi’s 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 G Gateway ay C 9-30VDX 1A MA DARY SECONENNA A NT

Warehouse

POWER

RESET

NA LSTRE S IG

rt X4 tPo nec Con

NGTH

STATUS

ACT ARY PRIMNNA ANTE

LINK

O P R

O P R

Meter

ZigBee/802.15.4 Wireless Mesh Network

Meter

XBee™ Module

O P R

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 Digi’s 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

Indoor/Urban range

POWER REQUIRE MENTS Series 1 (XBee / XBee-PRO)

XBee™ (Series 1)

XBee-PRO™ (Series 1)

XBee™ (Series 2)

XBee-PRO™ (Series 2)*

100 ft (30 m)

300 ft (90 m)

133 ft (40 m)

n/a

• 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)

Outdoor/RF Line-of-Sight Range

300 ft (90 m)

1 mi (1.6 km)

400 ft (120 m)

802.15.4 – Star

• 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)

n/a

ZigBee – Mesh

ANTENNA

* XBee-PRO Series 2 coming soon.

OPTIONS

P E R F O R M A N C E

FEATURES

General

General

• RF data rate: 250 Kbps • Operating temperature: -40º C to 85° C (-40º F to 185° F)

• 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 (XBee / XBee-PRO)

• 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) 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

• • • •

R E G U L A T O R Y APPROVALS Series 1 (XBee / XBee-PRO)

• 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 1

• Serial data rate: 1200 - 250000 bps • (6) 10-bit ADC inputs, (8) Digital I/O Series 2

Series 2 (XBee)

• Serial data rate: 1200 – 1 Mbps • (4) 10-bit ADC inputs, (10) Digital I/O

• • • •

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)

NETWORK ING

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 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)

W HEN

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)

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]

U.S. (FCC Part 15.247): OUR-XBEE2 Canada (IC): 4214A-XBEE2 Europe (CE): ETSI Japan

A N D S E C U R I T Y

Please visit www.digi.com for part numbers.

Digi International

Wire whip antenna Chip antenna U.Fl RF connector RPSMA female RF connector

M ATTERS ™ 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.di gi.c om

© 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

Unmanned Ground Vehicle OPERATION MANUAL

1. 2. 3. 4. 5.

A.

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.

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:

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 vi deo (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 iqbal9k [email protected], [email protected], [email protected]

Unmanned Ground Vehicle Project Report

Recommend Documents