VISVESVARAYA TECHNOLOGICAL UNIVERSITY BELGAUM
PROJECT REPORT ON
Collision Avoidance for Vehicle Safety
Submitted in the partial fulfillment of the
Requirements for the award of degree of
Bachelor of Engineering
In
Telecommunication Engineering
Submitted by
Yatish.P.R N.S.Shayan Vishwas.S.Patel
1BM07TE061 1BM07TE029 1BM07TE059
Under the guidance of
Mr. Manjunath P S
Lecturer,
Dept of Telecommunication,
BMSCE, Bangalore.
Department of Telecommunication Engineering
B.M.S College of EngineeringBangalore-560019
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 2
B.M.S COLLEGE OF ENGINEERING
Bull Temple Road, Basavanagudi, Bangalore-560019
Department of Telecommunication Engineering
CERTIFICATE
Certified that the project work entitled ‖Collision Avoidance for Vehicle Safety” is a bonafide
work carried out by Yatish P R(1BM07TE061), N S Shayan(1BM07TE029), Vishwas S
Patel(1BM07TE059) in partial fulfillment for the award of degree of Bachelor of Engineering in
Telecommunication Engineering of the Visvesvaraya Technological University, Belgaum during the
year 2011. The project has been approved as it satisfies the academic requirements with respect to
the project work prescribed for Bachelor of Engineering Degree.
Signature of the Guide Signature of HOD Signature of the Principal
(Manjunath P S) (Dr.B.Kanmani) (Dr.K.Mallikarjuna Babu)
Yatish P R N S Shayan Vishwas S Patel 1BM07TE061 1BM07TE029 1BM07TE059
External Viva
Name of the examiners Signature with date
1.
2.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 3
ACKNOWLEDGEMENT
The satisfaction and euphoria that accompany the successful completion of any task would be
incomplete without mention of the people who made it possible, whose constant guidance and
encouragement crowned our efforts with success.
We consider ourselves proud to be a part of B.M.S College of Engineering family, the institution
that stood by us in all our endeavors, which provided us with an opportunity of to carry out this
project. We wish to thank out principal, Dr.K.Mallikarjuna Babu and our HOD of the
Telecommunication Department, Dr.B.Kanmani for their kind support and encouragement in
carrying out this project successfully. Most importantly, we would like to thank our internal guide
Mr. Manjunath.P.S for his guidance, inspiration and for answering all our queries satisfactorily
during the project.
Finally, we would like to thank our parents, teachers and friends for their support.
Project Team
N S Shayan
Vishwas S Patel
Yatish P R
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 4
ABSTRACT
The basic idea of the project is to improve the safety measurements of the vehicle by using the
advanced systems available in the field of electronics. There are electronic controlled units (ECU‘s)
which are programmed to handle a specific type of collision avoidance. There are three situations to
be considered, namely
1. Head on collision of the vehicle on to an obstacle in its line of site.
2. Collision avoidance at blind curves and cross roads.
3. Locating the vehicles status and to be raise alarms in case of its breakdown.
The first situation includes the use of IR sensors which transmits and receives the signals which can
be processed to conclude if an obstacle is present In Front Of the vehicle.
The collision avoidance at blind curves can be tracked down by using the GPS modules which
indicates on a display the points of blind curves and also sends a warning message to the driver
Each vehicle transmits its status to a central server. The central server receives information from
every other vehicle and keeps track of the vehicle and its status. If any breakdown is identified in the
status, the emergency services are alarmed. The transmission of the data from the vehicle to the
central server uses the Zigbee protocol.
At the vehicle side, the status, the data from the sensors and the GPS modules are processed using a
microcontroller and the server computer interfaced with LabView handles the database of the
system.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 5
Table of Contents
1. INTRODUCTION ................................................................................................................................... 6
2. AN INTRODUCTION TO LAB VIEW AND VIRTUAL INSTRUMENTATION .......................... 9
3. ZIGBEE ................................................................................................................................................. 14
4. RISC PROCESSOR ............................................................................................................................. 18
5. TYPICAL CHARACTERISTICS OF RISC ....................................................................................... 19
6. AVR-ATMEGA162 ............................................................................................................................ 20
7. MAX232 ............................................................................................................................................... 27
8. SERIAL COMMUNICATION ............................................................................................................ 29
9. GLOBAL POSITIONING SYSTEM (GPS) ...................................................................................... 36
10. GPS-634R ........................................................................................................................................ 42
11. IMPLEMENTATION FLOWCHART ........................................................................................... 46
12. PIN DIGARAM ................................................................................................................................ 54
13. IMPLEMENTATION HARDWARE/SOFTWARE ................................................................... 55
14. CONCLUSION ................................................................................................................................. 56
15. FUTURE SCOPE ............................................................................................................................. 57
16. REFERENCES .................................................................................................................................. 58
17. APPENDIX ....................................................................................................................................... 59
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 6
1. INTRODUCTION
An ECU, is the electronic circuit unit which is a part of the vehicle inbuilt system. This is the
system which is responsible for controlling the respective parameters of the vehicle. Any
activity of the vehicle can be controlled using an embedded system. This embedded system is
called the ECU.
Typically ECUs are programmed to perform a specific real time operation such as opening the
air bags of the car within microseconds of the detection of the collision.
The following block diagram will give us a better idea about the general architecture of a an
ECU
Figure 1.1 Block Diagram of a Mote
The microcontroller performs all the data processing tasks and controls the functionality of
other components in the sensor node. Sensors sense or measure physical data of the area to be
monitored. The continual analog signal sensed by the sensors is digitized by an Analog-to-
digital converter and sent to controllers for further processing. Further ECU‘s contain the CAN
module which provides communication over wired medium using transceivers. Sensor nodes
make use of ISM band which gives free radio, huge spectrum allocation and global availability.
Motes can be powered either by using batteries or capacitors. All of these parts are packaged
together in the smallest container possible.
From one part
of vehicle To other
control point
Main server
LabView
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 7
Virtual instrumentation:
Virtual Instrumentation is the use of customizable software and modular measurement hardware
to create user-defined measurement systems, called virtual instruments. The concept of a
synthetic instrument is a subset of the virtual instrument concept. A synthetic instrument is a
kind of virtual instrument that is purely software defined. A synthetic instrument performs a
specific synthesis, analysis, or measurement function on completely generic, measurement
agnostic hardware. Virtual instruments can still have measurement specific hardware, and tend to
emphasize modular hardware approaches that facilitate this specificity. Hardware supporting
synthetic instruments is by definition not specific to the measurement, nor is it necessarily (or
usually)modular.
Leveraging commercially available technologies, such as the PC and the analog to digital
converter, virtual instrumentation has grown significantly since its inception in the late 1970s.
Additionally, software packages like National Instruments' Lab VIEW and other graphical
programming languages helped grow adoption by making it easier for non-programmers to
develop systems.
Lab VIEW:
Lab VIEW (short for Laboratory Virtual Instrumentation Engineering Workbench)
is a platform and development environment for a visual programming language from National
Instruments. Originally released for the Apple Macintosh in 1986, Lab VIEW is commonly used
for data acquisition, instrument control, and industrial automation on a variety of platforms
including Microsoft Windows, various flavors of UNIX, Linux, and Mac OS. The programming
language used in Lab VIEW, is a dataflow language. Execution is determined by the structure of
a graphical block diagram. Lab VIEW (short for Laboratory Virtual Instrumentation Engineering
Workbench) is a platform and development environment for a visual programming language from
National Instruments. Since this might be the case for multiple nodes simultaneously, it is inherently
capable of parallel execution. Furthermore, Lab VIEW does not require type definition of the
variables; the wire type is defined by the data-supplying node.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 8
Experimental work:
Lab VIEW ties the creation of user interfaces (called front panels) into the development
cycle. Lab VIEW programs/subroutines are called virtual instruments (VIs). Each VI has
three components:
1. Block diagram
2. Connector pane
3. Front panel
However, the front panel can also serve as a programmatic interface. This implies each VI can
be easily tested before being embedded as a subroutine into a larger program
The graphical approach also allows non-programmers to build programs by simply dragging and
dropping virtual representations of the lab equipment with which they are already familiar. The Lab
VIEW programming environment, with the included examples and the documentation, makes it
simpler to create small applications. This is a benefit on one side but there is also a certain danger of
underestimating the expertise needed for good quality programming. Refer Appendix for figure
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 9
2. AN INTRODUCTION TO LAB VIEW AND VIRTUAL
INSTRUMENTATION
Virtual instrumentation:
Virtual Instrumentation is the use of customizable software and modular measurement hardware
to create user-defined measurement systems, called virtual instruments.
'Traditional' or 'natural' instrumentation systems are made up of pre-defined hardware components,
such as digital multimeters and oscilloscopes that are completely specific to their stimulus, analysis,
or measurement function. Because of their hard-coded function, these systems are more limited in
their versatility than virtual instrumentation systems. The primary difference between 'natural'
instrumentation and virtual instrumentation is the software component of a virtual instrument. The
software enables complex and expensive equipment to be replaced by simpler and less expensive
hardware; e.g. analog to digital converter can act as a hardware complement of a virtual
oscilloscope, a potentiostat enables frequency response acquisition and analysis in electrochemical
impedance spectroscopy with virtual instrumentation.The concept of a synthetic instrument is a
subset of the virtual instrument concept.
A syntheticinstrument is a kind of virtual instrument that is purely software defined. A synthetic
instrument performs a specific synthesis, analysis, or measurement function on completely generic,
measurement agnostic hardware. Virtual instruments can still have measurement specific hardware,
and tend to emphasize modular hardware approaches that facilitate this specificity. Hardware
supporting synthetic instruments is by definition not specific to the measurement, nor is it
necessarily (or usually) modular.
Leveraging commercially available technologies, such as the PC and the analog to digital converter,
virtual instrumentation has grown significantly since its inception in the late 1970s. Additionally,
software packages like National Instruments' LabVIEW and other graphical programming languages
helped grow adoption by making it easier for non-programmers to develop systems.
Lab VIEW:
(acronym for Laboratory Virtual Instrumentation Engineering Workbench) is a platform and
development environment for a visual programming language from National Instruments. The
graphical language is named "G". Originally released for the Apple Macintosh in 1986, LabVIEW is
commonly used for data acquisition, instrument control, and industrial automation on a variety of
platforms including Microsoft Windows, various flavors of UNIX, Linux, and Mac OS. The Latest
version of LabVIEW is version 8.20, released in honor of LabVIEW's 20th anniversary.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 10
Dataflow programming:
The programming language used in LabVIEW, called "G", is a dataflow language. Execution is
determined by the structure of a graphical block diagram (the LV-source code) on which the
programmer connects different function-nodes by drawing wires. These wires propagate variables
and any node can execute as soon as all its input data become available. Since this might be the case
for multiple nodes simultaneously, G is inherently capable of parallel execution. Multi-processing
and multi-threading hardware is automatically exploited by the built-in scheduler, which multiplexes
multiple OS threads over the nodes ready for execution.
Programmers with a background in conventional programming often show a certain reluctance to
adopt the LabVIEW dataflow scheme, claiming that LabVIEW is prone to race conditions. In
reality, this stems from a misunderstanding of the data-flow paradigm. The aforementioned dataflow
(which can be "forced", typically by linking inputs and outputs of nodes) completely defines the
execution sequence, and that can be fully controlled by the programmer. Thus, the execution
sequence of the LabVIEW graphical syntax is as well defined as with any textually coded language
such as C, Visual BASIC, and Python etc. Furthermore, LabVIEW does not require type definition
of the variables; the wire type is defined by the data-supplying node. LabVIEW supports
polymorphism in that wires automatically adjust to various types of data.
Graphical programming:
LabVIEW ties the creation of user interfaces (called front panels) into the development cycle.
LabVIEW programs/subroutines are called virtual instruments (VIs). Each VI has three
components: a block diagram, a front panel and a connector pane. The latter may represent the VI as
a sub VI in block diagrams of calling VIs. Controls and indicators on the front panel allows an
operator to input data into or extract data from a running virtual instrument. However, the front
panel can also serve as a programmatic interface. Thus a virtual instrument can either be run as a
program, with the front panel serving as a user interface, or, when dropped as a node onto the block
diagram, the front panel defines the inputs and outputs for the given node through the connector
pane. This implies each VI can be easily tested before being embedded as a subroutine into a larger
program.
The graphical approach also allows non-programmers to build programs by simply dragging and
dropping virtual representations of the lab equipment with which they are already familiar. The
LabVIEW programming environment, with the included examples and the documentation, makes it
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 11
simpler to create small applications. This is a benefit on one side but there is also a certain danger of
underestimating the expertise needed for good quality "G" programming. For complex algorithms or
large-scale code it is important that the programmer possess an extensive knowledge of the special
LabVIEW syntax and the topology of its memory management. The most advanced LabVIEW
development systems offer the possibility of building stand-alone applications. Furthermore, it is
possible to create distributed applications which communicate by a client/server scheme, and thus is
easier to implement due to the inherently parallel nature of G-code. Benefits One benefit of
LabVIEW over other development environments is the extensive support for accessing
instrumentation hardware. Drivers and abstraction layers for many different types of instruments and
buses are included or are available for inclusion. These present themselves as graphical nodes. The
abstraction layers offer standard software interfaces to communicate with hardware devices. The
provided driver interfaces save program development time. The sales pitch of National Instruments
is, therefore, that even people with limited coding experience can write programs and deploy test
solutions in a reduced time frame when compared to more conventional or competing systems. A
new hardware driver topology (DAQmxBase), which consists mainly of G coded components with
only a few register calls through NI Measurement Hardware DDK (Driver Development Kit)
functions, provides platform independent hardware access to numerous data acquisition and
instrumentation devices. The DAQmx Base driver is available for LabVIEW on Windows, Mac
OSX and Linux platforms.
In terms of performance, LabVIEW includes a compiler that produces native code for the CPU
platform. The graphical code is translated into executable machine code by interpreting the syntax
and by compilation. The LabVIEW syntax is strictly enforced during the editing process and
compiled into the executable machine code when requested to run or upon saving. In the latter case,
the executable and the source code are merged into a single file. The executable runs with the help
of the LabVIEW run-time engine, which contains some precompiled code to perform common tasks
that are defined by the G language. The run-time engine reduces compile time and also provides a
consistent interface to various operating systems, graphic systems, hardware components, etc. The
run-time environment makes the code portable across platforms. Generally, LV code can be slower
than equivalent compiled C code, although the differences often lie more with program optimization
than inherent execution speed.
Many libraries with a large number of functions for data acquisition, signal generation,
mathematics, statistics, signal conditioning, analysis, etc., along with numerous graphical interface
elements are provided in several LabVIEW package options.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 12
The LabVIEW Professional Development System allows creating stand-alone executables and the
resultant executable can be distributed an unlimited number of times. The run-time engine and its
libraries can be provided freely along with the executable.
A benefit of the LabVIEW environment is the platform independent nature of the G-code, which is
(with the exception of a few platform-specific functions) portable between the different LabVIEW
systems for different operating systems (Windows, MacOSX and Linux). National Instruments is
increasingly focusing on the capability of deploying LabVIEW code onto an increasing number of
targets including devices like Phar Lap OS based LabVIEW real-time controllers, Pocket PCs,
PDAs, Field Point modules and into FPGAs on special boards.
There is a low cost LabVIEW Student Edition aimed at educational institutions for learning
purposes. There is also an active community of LabVIEW users who communicate through several
e-mail groups and Internet forums.
Criticism:
LabVIEW is a proprietary product of National Instruments. Unlike common programming
languages such as C or FORTRAN, LabVIEW is not managed or specified by a third party
standards committee such as ANSI. Obtaining a fully compatible and up to date LabVIEW platform
requires purchasing the product. There is a movement to create user-defined extensions for the
development environment at OpenG.org but an initial purchase of LabVIEW is still required.
Currently there is no open source, free software or alternative commercial program that can
implement any portion of G-code. In addition, as of version 8, all LabVIEW installs require
customers to contact National Instruments by Internet or phone to "activate" the product. The
increasing dependence on the vendor suggests possible privacy and data security concerns. For
example, although National Instruments claims the process is "secure and anonymous" the
immediate implication is that a legal but privately installed instance of LabVIEW seems no longer
possible. However, if National Instruments were to go out of business, the LabVIEW code is
escrowed and would be released to the public, and so there would be no concerns over activation.
This would mean that, with the current system, the user would no longer be able to access their code
base as well as certain formats of archived data. Building a stand-alone application with LabVIEW
requires the Application Builder component which is included with the Professional Development
System but requires a separate purchase if using the Base Package or Full Development System.
Compiled executables produced by the Application Builder are not truly standalone in that they also
require that the LabVIEW run-time engine be installed on any target computer on which users run
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 13
the application. Although this run7time engine can be freely downloaded from National Instruments'
website, this added requirement is in contrast to other compiled languages, such as C, where a stand-
alone executable file can be created, run and distributed without the need for additional files or
installation procedures. These requirements can cause problems if an application is distributed to a
user who may be prepared to run the application but does not have the inclination or permission to
install additional files on the host system prior to running the executable. The need for a separately
installed LabVIEW run-time engine makes the development and distribution of truly portable
applications using LabVIEW difficult. There is some debate as to whether LabVIEW is really a
general-purpose programming language (or in some cases whether it is really a programming
language at all) as opposed to an application-specific development environment for measurement
and automation. Critics point to a lack of features, common in most other programming languages,
such as native recursion and, until version 8.20, object oriented features. While it is possible to write
complex applications in LabVIEW that involve no measurement or automation, it is not best suited
to the task
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 14
3. Zigbee
ZigBee is a typical wireless communication technology, based on the IEEE 802.15.4-2003
standard for wireless personal area networks (WPANs) which is widely used in Wireless
Sensor Network (WSN).
ZigBee is a low-cost, low-power, wireless mesh networking proprietary standard. The low cost
allows the technology to be widely deployed in wireless control and monitoring applications,
the low power-usage allows longer life with smaller batteries, and the mesh networking
provides high reliability and larger range. The ZigBee Alliance is the standards body that
defines ZigBee
The name "ZigBee" is derived from the erratic zigzag patterns many bees make between
flowers when collecting pollen. This is suggestive of the invisible webs of connections existing
in a fully wireless environment, similar to the way packets would move through a mesh
network.
The technology defined by the ZigBee is intended to be simpler and less expensive than other
WPANs, such as Bluetooth. ZigBee wireless sensor network has great advantages in terms of
low power consumption, high fault tolerance, flexibility, and autonomy. So it is poised to
become a very significant enabling technology in many fields, and it is widely used in
military security, environment monitoring, and home automation. As a new technology, in the
practical application the advantage of the ZigBee wireless sensor network was not very ideal,
especially in a large scale wireless ZigBee sensor network, because the coordinator processing
ability is limited. In the large scale ZigBee wireless network the coordinator should deal
with too much message, so some shortcomings come out, such as information time delay, data
packet loss, and sensor node out of control. There are some algorithms which were proposed to
improve the communication efficiency but that only aimed at the software aspects.
ZigBee operates in the industrial, scientific and medical (ISM) radio bands; 868 MHz in
Europe, 915 MHz in the USA and Australia, and 2.4 GHz in most jurisdictions worldwide. The
technology is intended to be simpler and less expensive than other WPANs such as Bluetooth.
Because ZigBee can activate (go from sleep to active mode) in 15 msec or less, the latency can
be very low and devices can be very responsive — particularly compared to Bluetooth wake-up
delays, which are typically around three seconds. Because ZigBee can sleep most of the time,
average power consumption can be very low, resulting in long battery life.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 15
For non-commercial purposes, the ZigBee specification is available free to the general public.
ZigBee Alliance provides access to the as-yet unpublished specifications and permission to
create products for market using the specifications.
ZigBee protocols are intended for use in embedded applications requiring low data rates and
low power consumption. ZigBee's current focus is to define a general-purpose, inexpensive,
self-organizing mesh network that can be used for industrial control, embedded sensing,
medical data collection, smoke and intruder warning, building automation, home automation,
etc.
Zigbee protocol layers:
Figure– Zigbee Protocol Layers
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 16
Physical and MAC Layer:
The PHY service enables the transmission and reception of PHY protocol data units (PPDU)
across the physical radio channel. It is described in IEEE 802.15.4 protocol. The features of the
IEEE 802.15.4 PHY physical layer are:
Activation and deactivation of the radio transceiver, energy detection (ED)
Link quality indication (LQI)
channel selection
The MAC is responsible for generating and synchronizing to the network beacons. The layer
provides PAN association and disassociation, and provides a reliable link between two devices.
It also offers an optional security for the MAC layer and maintains a GTS (Guaranteed Time
Slot) mechanism for devices that require a constant rate and fixed delays. The MAC layer
supports creation of two types of network topologies: star topology and peer-to-peer topology.
The peer-to-peer topology allows more complex communication scenarios. It is possible to
implement routing protocols in this topology.
Network Layer:
The main functions of the network layer are to enable the correct use of the MAC sub layer and
provide a suitable interface for use by the next upper layer, namely the application layer. Its
capabilities and structure are those typically associated to such network layers, including
routing.
The routing protocol used by the Network layer is AODV (Ad hoc on demand Distance Vector
Routing). In order to find the destination device, it broadcasts out a route request to all of its
neighbors. The neighbors then broadcast the request to their neighbors, etc until the destination
is reached. Once the destination is reached, it sends its route reply via unicast transmission
following the lowest cost path back to the source. Once the source receives the reply, it will
update its routing table for the destination address with the next hop in the path and the path
cost.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 17
Application Layer:
The application layer is the highest-level layer defined by the specification, and is the effective
interface of the ZigBee system to its end users. It comprises the majority of components added
by the ZigBee specification: both ZDO and its management procedures, together with
application objects defined by the manufacturer, are considered part of this layer.
The application support sub layer (APS) offers a well-defined interface and control services. It
works as a bridge between the network layer and the other components of the application layer:
it keeps up-to-date binding tables in the form of a database.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 18
4. RISC PROCESSOR
Reduced Instruction Set Computer (RISC) represents a processor architecture that has a relatively
small set of computer instructions that it can perform; emphasizing the instructions used most often
and optimizing them for the fastest possible execution.
RISC processors use a technique called pipelining, which allows for simultaneous execution of
parts, or stages, of instructions for efficient processing of instructions. This simplicity can be utilized
to make instructions execute very quickly. In the mid-1990s RISC processors began to be used in
personal computers.
Software for RISC processors handle more operations than the traditional CISC [Complex
Instruction Set Computer] processors, but RISC processors have advantages in applications that
benefit from faster instruction execution, such as engineering and graphics workstations and parallel
processing systems. They are also less costly to design, test, and manufacture, as compared to the
CISC processors that had been used since the introduction of the microprocessor.
Well known RISC families include Alpha, Am29k, ARC, ARM, AVR, SuperH, and SPARC. A
Samsung ARM processor is shown in the above figure, which operates at a frequency of 50MHz.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 19
5. TYPICAL CHARACTERISTICS OF RISC
For any given level of general performance, a RISC chip will typically have far fewer transistors
dedicated to the core logic which originally allowed designers to increase the size of the register set
and increase internal parallelism.
Other features which are typically found in RISC architectures are:
Uniform instruction format, using a single word with the opcode in the same bit positions in
every instruction, demanding less decoding.
Identical general purpose registers, allowing any register to be used in any context,
simplifying compiler design (although normally there are separate floating point registers).
Simple addressing modes; complex addressing performed via sequences of arithmetic
and/or load-store operations.
Few data types in hardware, some CISCs have byte string instructions, or support complex
numbers; this is so far unlikely to be found on a RISC.
RISC designs are also more likely to feature a Harvard memory model, where the instruction stream
and the data stream are conceptually separated; this means that modifying the memory where code is
held might not have any effect on the instructions executed by the processor at least until a special
synchronization instruction is issued. On the upside, this allows both caches to be accessed
simultaneously, which can often improve performance.
Many early RISC designs had a branch delay slot, which is an instruction space immediately
following a jump or branch. The instruction in this space is executed, whether or not the branch is
taken. This instruction keeps the ALU of the CPU busy for the extra time normally needed to
perform a branch. Modern RISCs consider the branch delay slot as a drawback to implement few
RISC designs and hence they do not include it in their instruction space.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 20
6. AVR-ATmega162
AVR-ATmega162 is a general purpose 8 bit microcontroller, which offers high performance and
very low power consumption. The AVR microcontroller is based on RISC principles and instruction
set and related decode mechanism are much simpler than CISC.
The ATmega162 incorporates 16 kB in system programmable flash memory system. Memory may
be used for both code and data storage. Programming of flash memory may be accomplished in
several ways. It may be programmed in system via the serial port.
Features:
Advanced RISC Architecture
o 131 Powerful Instructions – Most Single-clock Cycle Execution
o 32 x 8 General Purpose Working Registers
o Fully Static Operation
o Up to 16 MIPS Throughput at 16 MHz
o On-chip 2-cycle Multiplier
High Endurance Non-volatile Memory segments
o 16K Bytes of In-System Self-programmable Flash program memory
o 512 Bytes EEPROM
o 1K Bytes Internal SRAM
o Write/Erase cycles: 10,000 Flash/100,000 EEPROM
o Data retention: 20 years at 85°C/100 years at 25°C
o Optional Boot Code Section with Independent Lock Bits
o In-System Programming by On-chip Boot Program
True Read-While-Write Operation
o Up to 64K Bytes Optional External Memory Space
o Programming Lock for Software Security
Peripheral Features
o Two 8-bit Timer/Counters with Separate Prescalers and Compare Modes
o Two 16-bit Timer/Counters with Separate Prescalers, Compare Modes, and capture modes
o Real Time Counter with Separate Oscillator
o Six PWM Channels
o Dual Programmable Serial USARTs
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 21
o Master/Slave SPI Serial Interface
o Programmable Watchdog Timer with Separate On-chip Oscillator
o On-chip Analog Comparator
Special Microcontroller Features
o Power-on Reset and Programmable Brown-out Detection
o Internal Calibrated RC Oscillator
o External and Internal Interrupt Sources
o Five Sleep Modes: Idle, Power-save, Power-down and Standby
Operating Voltages
o 1.8 - 5.5V for ATmega162V
o 2.7 - 5.5V for ATmega162
Speed Grades
o 0 - 8 MHz for ATmega162V
o 0 - 16 MHz for ATmega162
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 24
The ATmega162 is a low-power CMOS 8-bit microcontroller based on the AVR enhanced RISC
architecture. By executing powerful instructions in a single clock cycle, the ATmega162
achieves throughputs approaching 1 MIPS per MHz allowing the system designer to optimize
power consumption versus processing speed.
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 ATmega162 provides the following features: 16K bytes of In-System Programmable Flash
with Read-While-Write capabilities, 512 bytes EEPROM, 1K bytes SRAM, an external memory
interface, 35 general purpose I/O lines, 32 general purpose working registers, a JTAG interface
for Boundary-scan, On-chip Debugging support and programming, four flexible Timer/Counters
with compare modes, internal and external interrupts, two serial programmable USARTs,
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. 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. In Extended Standby
mode, both the main Oscillator and the Asynchronous Timer continue to run.
The device is manufactured using Atmel‘s high density non-volatile memory technology. The
On-chip ISP Flash allows the program memory to 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 Self-Programmable Flash on a
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 25
monolithic chip, the Atmel ATmega162 is a powerful microcontroller that provides a highly flexible
and cost effective solution to many embedded control applications.
The ATmega162 AVR is supported with a full suite of program and system development tools
including: C compilers, macro assemblers, program debugger/simulators.
Pin Description:
VCC Digital supply voltage
GND Ground
Port A (PA7-PA0)
Port A is an 8-bit bi-directional I/O port with internal pull-up resistors (selected for each bit). The
Port A output buffers have symmetrical drive characteristics with both high sink and source
capability. When pins PA0 to PA7 are used as inputs and are externally pulled low, they will source
current if the internal pull-up resistors are activated. The Port A pins are tri-stated when a reset
condition becomes active, even if the clock is not running.
Port B (PB7-PB0)
Port B is an 8-bit bi-directional I/O port with internal pull-up resistors (selected for each bit). The
Port B output buffers have symmetrical drive characteristics with both high sink and source
capability. As inputs, Port B pins that are externally pulled low will source current if the pull-up
resistors are activated. The Port B pins are tri-stated when a reset condition becomes active, even if
the clock is not running.
Port C (PC7-PC0)
Port C is an 8-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. If the JTAG interface is enabled, the pull-up resistors on pins PC7(TDI),
PC5(TMS) and PC4(TCK) will be activated even if a Reset occurs.
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
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 26
resistors are activated. The Port D pins are tri-stated when a reset condition becomes active, even if
the clock is not running.
Port E(PE2-PE0)
Port E is a 3-bit bi-directional I/O port with internal pull-up resistors (selected for each bit). The Port
E output buffers have symmetrical drive characteristics with both high sink and source capability.
As inputs, Port E pins that are externally pulled low will source current if the pull-up resistors are
activated. The Port E pins are tri-stated when a reset condition becomes active, even if the clock is
not running.
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.
XTAL1
Input to the Inverting Oscillator amplifier and input to the internal clock operating circuit.
XTAL2
Output from the Inverting Oscillator amplifier.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 27
7. MAX232
The MAX232 is an integrated circuit that converts signals from an RS-232 serial port to signals
suitable for use in TTL compatible digital logic circuits. The MAX232 is a dual driver/receiver and
typically converts the RX, TX, CTS and RTS signals.
The drivers provide RS-232 voltage level outputs (approx. ±7.5V) from a single +5V supply via on-
chip charge pumps and external capacitors. This makes it useful for implementing RS-232 in
devices that otherwise do not need any voltages outside the 0V to +5V range. The receivers reduce
RS-232 inputs (which may be as high as ± 25V), to standard 5V TTL levels.
The above figure shows a typical MAX232 operating circuit.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 29
8. Serial Communication
USART:
The Universal Synchronous and Asynchronous serial Receiver and Transmitter (USART) is a
highly flexible serial communication device. The main features are:
Full Duplex Operation (Independent Serial Receive and Transmit Registers)
Asynchronous or Synchronous Operation
Master or Slave Clocked Synchronous Operation
High Resolution Baud Rate Generator
Supports Serial Frames with 5, 6, 7, 8, or 9 Data Bits and 1 or 2 Stop Bits
Odd or Even Parity Generation and Parity Check Supported by Hardware
Data Overrun Detection
Framing Error Detection
Noise Filtering Includes False Start Bit Detection and Digital Low Pass Filter
Three Separate Interrupts on TX Complete, TX Data Register Empty and RX Complete
Multi-processor Communication Mode
Double Speed Asynchronous Communication Mode
The ATmega162 has two USART‘s-USART0 and USART1.The GPS data received by the GPS
receiver is transferred through the serial port using the USART1 of ATmega162 microcontroller
from where the latitude and longitude co-ordinates are obtained from the received GPS packet. After
extracting the latitude and longitude co-ordinates it is sent to the central server through
USART0.The data from the central server is received from USART1 only. USART forms the
important part for the project.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 30
USART Block Diagram:
The dashed boxes in the block diagram separate the three main parts of the USART (listed from
the top): Clock Generator, Transmitter and Receiver. Control registers are shared by all units.
The Clock Generation logic consists of synchronization logic for external clock input used by
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 31
Synchronous slave operation and the baud rate generator. The XCK (Transfer Clock) pin is only
Used by synchronous transfer mode. The Transmitter consists of a single write buffer, a serial
Shift Register, parity generator and control logic for handling different serial frame formats. The
Write buffer allows a continuous transfer of data without any delay between frames. The
Receiver is the most complex part of the USART module due to its clock and data recovery
Units. The recovery units are used for asynchronous data reception. In addition to the recovery
Units, the Receiver includes a Parity Checker, Control logic, a Shift Register and a two level
Receive buffer (UDR). The receiver supports the same frame formats as the Transmitter, and can
Detect Frame Error, Data Overrun and Parity Errors.
Data Transmission– The USART Transmitter:
The USART Transmitter is enabled by setting the Transmit Enable (TXEN) bit in the UCSRB
Register. When the Transmitter is enabled, the normal port operation of the TXD pin is overridden
by the USART and given the function as the transmitter‘s serial output. The baud rate, mode of
operation and frame format must be set up once before doing any transmissions. If synchronous
operation is used, the clock on the XCK pin will be overridden and used as transmission clock.
Sending Frames with 5 to 8 Data Bit
A data transmission is initiated by loading the transmit buffer with the data to be transmitted. The
CPU can load the transmit buffer by writing to the UDR I/O location. The buffered data in the
transmit buffer will be moved to the Shift Register when the Shift Register is ready to send a new
frame. The Shift Register is loaded with new data if it is in idle state (no ongoing transmission) or
immediately after the last stop bit of the previous frame is transmitted. When the Shift Register is
loaded with new data, it will transfer one complete frame at the rate given by the Baud Register,
U2X bit or by XCK depending on mode of operation.
Sending Frames with 9 Data Bit
If 9-bit characters are used (UCSZ = 7), the ninth bit must be written to the TXB8 bit in UCSRB
before the low byte of the character is written to UDR.
Transmitter Flags and Interrupts
The USART Transmitter has two flags that indicate its state: USART Data Register Empty
(UDRE) and Transmit Complete (TXC). Both flags can be used for generating interrupts.
The Data Register Empty (UDRE) Flag indicates whether the transmit buffer is ready to receive
new data. This bit is set when the transmit buffer is empty, and cleared when the transmit buffer
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 32
contains data to be transmitted that has not yet been moved into the Shift Register. For compatibility
with future devices, always write this bit to zero when writing the UCSRA Register. When the Data
Register Empty Interrupt Enable (UDRIE) bit in UCSRB is written to one, the USART Data
Register Empty Interrupt will be executed as long as UDRE is set (provided that global interrupts
are enabled). UDRE is cleared by writing UDR. When interrupt-driven data transmission is used, the
Data Register Empty Interrupt routine must either write new data to UDR in order to clear UDRE or
disable the Data Register Empty Interrupt, otherwise a new interrupt will occur once the interrupt
routine terminates.
The Transmit Complete (TXC) Flag bit is set one when the entire frame in the Transmit Shift
Register has been shifted out and there are no new data currently present in the transmit buffer.
The TXC Flag bit is automatically cleared when a transmit complete interrupt is executed, or it
can be cleared by writing a one to its bit location. The TXC Flag is useful in half-duplex
communication interfaces (like the RS-485 standard), where a transmitting application must enter
Receive mode and free the communication bus immediately after completing the transmission.
When the Transmit Compete Interrupt Enable (TXCIE) bit in UCSRB is set, the USART Transmit
Complete Interrupt will be executed when the TXC Flag becomes set (provided that global
interrupts are enabled). When the transmit complete interrupt is used, the interrupt handling routine
does not have to clear the TXC Flag, this is done automatically when the interrupt is executed.
Parity Generator
The Parity Generator calculates the parity bit for the serial frame data. When parity bit is enabled
(UPM1 = 1), the transmitter control logic inserts the parity bit between the last data bit and the
first stop bit of the frame that is sent.
Disabling the Transmitter
The disabling of the Transmitter (setting the TXEN to zero) will not become effective until on going
and pending transmissions are completed, i.e., when the Transmit Shift Register and
Transmit Buffer Register do not contain data to be transmitted. When disabled, the Transmitter
will no longer override the TXD pin.
Data Reception – The USART Receiver:
The USART Receiver is enabled by writing the Receive Enable (RXEN) bit in the UCSRB Register
to one. When the receiver is enabled, the normal pin operation of the RXD pin is overridden by the
USART and given the function as the receiver‘s serial input. The baud rate, mode of operation and
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 33
frame format must be set up once before any serial reception can be done. If synchronous operation
is used, the clock on the XCK pin will be used as transfer clock.
Receiving Frames with5 to 8 Data Bits
The Receiver starts data reception when it detects a valid start bit. Each bit that follows the start
Bit will be sampled at the baud rate or XCK clock, and shifted into the Receive Shift Register until
the first stop bit of a frame is received. A second stop bit will be ignored by the Receiver. When the
first stop bit is received, i.e., a complete serial frame is present in the Receive Shift Register, the
contents of the Shift Register will be moved into the receive buffer. The receive buffer can then be
read by reading the UDR I/O location.
Receiving Frames with 9 Data Bits
If 9-bit characters are used (UCSZ=7) the ninth bit must be read from the RXB8 bit in UCSRB
Before reading the low bits from the UDR. This rule applies to the FE, DOR and UPE Status
Flags as well. Read status from UCSRA, then data from UDR. Reading the UDR I/O location will
change the state of the receive buffer FIFO and consequently the TXB8, FE, DOR and UPE bits,
which all are stored in the FIFO, will change.
Receive Compete Flag and Interrupt
The USART Receiver has one flag that indicates the receiver state. The Receive Complete (RXC)
Flag indicates if there are unread data present in the receive buffer, this flag is one when unread data
exist in the receive buffer, and zero when the receive buffer is empty (i.e., does not contain any
unread data). If the Receiver is disabled (RXEN = 0), the receive buffer will be flushed and
consequently the RXC bit will become zero. When the Receive Complete Interrupt Enable (RXCIE)
in UCSRB is set, the USART Receive Complete Interrupt will be executed as long as the RXC Flag
is set (provided that global interrupts are enabled). When interrupt-driven data reception is used, the
receive complete routine must read the received data from UDR in order to clear the RXC Flag,
otherwise a new interrupt will occur once the interrupt routine terminates.
Receiver Error Flags
The USART Receiver has three Error Flags: Frame Error (FE), Data Over Run (DOR) and Parity
Error (UPE). All can be accessed by reading UCSRA. Common for the Error Flags is that they
are located in the receive buffer together with the frame for which they indicate the error status.
Due to the buffering of the Error Flags, the UCSRA must be read before the receive buffer
(UDR), since reading the UDR I/O location changes the buffer read location. Equality for the Error
Flags is that they cannot be altered by software doing a write to the flag location. However, all flags
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 34
must be set to zero when the UCSRA is written for upward compatibility of future USART
implementations. None of the Error Flags can generate interrupts.
The Frame Error (FE) Flag indicates the state of the first stop bit of the next readable frame
Stored in the receive buffer. The FE Flag is zero when the stop bit was correctly read (as one),
and the FE Flag will be one when the stop bit was incorrect (zero). This flag can be used for
detecting out-of-sync conditions, detecting break conditions and protocol handling. The FE Flag
is not affected by the setting of the USBS bit in UCSRC since the receiver ignores all, except for
the first, stop bits. For compatibility with future devices, always set this bit to zero when writing to
UCSRA. The Data Over Run (DOR) Flag indicates data loss due to a receiver buffer full condition.
A Data Over Run occurs when the receive buffer is full (two characters), it is a new character
waiting in the Receive Shift Register, and a new start bit is detected. If the DOR Flag is set there
was one or more serial frame lost between the frame last read from UDR, and the next frame read
from UDR. For compatibility with future devices, always write this bit to zero when writing to
UCSRA. The DOR Flag is cleared when the frame received was successfully moved from the Shift
Register to the receive buffer. The Parity Error (UPE) Flag indicates that the next frame in the
receive buffer had a Parity Error when received. If parity check is not enabled the UPE bit will
always be read zero. For compatibility with future devices, always set this bit to zero when writing
to UCSRA Parity Checker. The Parity Checker is active when the high USART Parity mode
(UPM1) bit is set. Type of parity check to be performed (odd or even) is selected by the UPM0 bit.
When enabled, the Parity Checker calculates the parity of the data bits in incoming frames and
compares the result with the parity bit from the serial frame. The result of the check is stored in the
receive buffer together with the received data and stop bits. The Parity Error (UPE) Flag can then be
read by software to check if the frame had a Parity Error.
The UPE bit is set if the next character that can be read from the receive buffer had a parity error
when received and the parity checking was enabled at that point (UPM1 = 1). This bit is valid
until the receive buffer (UDR) is read.
Disabling the Receiver
In contrast to the Transmitter, disabling of the Receiver will be immediate. Data from ongoing
receptions will therefore be lost. When disabled (i.e., the RXEN is set to zero) the receiver will no
longer override the normal function of the RXD port pin. The receiver buffer FIFO will be flushed
when the receiver is disabled. Remaining data in the buffer will be lost.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 35
RS232:
In RS-232, user data is sent as a time series of bits. Both synchronous and asynchronous
transmissions are supported by the standard. In addition to the data circuits, the standard defines a
number of control circuits used to manage the connection between the DTE and DCE. Each data or
control circuit only operates in one direction that is, signaling from a DTE to the attached DCE or
the reverse. Since transmit data and receive data are separate circuits, the interface can operate in
a full duplex manner, supporting concurrent data flow in both directions. The standard does not
define character framing within the data stream, or character encoding.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 36
9. Global Positioning System (GPS)
The Global Positioning System (GPS) is a space-based global navigation satellite system (GNSS)
that provides location and time information in all weather, anywhere on or near the Earth, where
there is an unobstructed line of sight to four or more GPS satellites. It is maintained by the United
States government and is freely accessible by anyone with a GPS receiver.
The GPS project was developed in 1973 to overcome the limitations of previous navigation systems,
integrating ideas from several predecessors, including a number of classified engineering design
studies from the 1960s. GPS was created and realized by the U.S. Department of Defense (USDOD)
and the first satellite was launched in 1989, and the 24th satellite was launched in 1994. It became
fully operational in 1994.
In addition to GPS, other systems are in use or under development. The Russian GLObal
NAvigation Satellite System (GLONASS) was in use by only the Russian military, until it was made
fully available to civilians in 2007. There are also the planned Chinese Compass navigation
system and the European Union's Galileo positioning system.
Initially, the highest quality signal was reserved for military use, and the signal available for civilian
use was intentionally degraded ("Selective Availability", SA). This changed with United States
President Bill Clinton ordering Selective Availability turned off at midnight May 1, 2000, improving
the precision of civilian GPS from 100 meters (about 300 feet) to 20 meters (about 65 feet). The
United States military by then had the ability to deny GPS service to potential adversaries on a
regional basis.
BASIC CONCEPTS OF GPS:
A GPS receiver calculates its position by precisely timing the signals sent by GPS satellites high
above the Earth. Each satellite continually transmits messages that include
the time the message was transmitted
precise orbital information (the ephemeris)
The general system health and rough orbits of all GPS satellites (the almanac).
The receiver uses the messages it receives to determine the transit time of each message and
computes the distance to each satellite. These distances along with the satellites' locations are used
with the possible aid of trilateration, depending on which algorithm is used, to compute the position
of the receiver. This position is then displayed, perhaps with a moving map display or latitude and
longitude; elevation information may be included. Many GPS units show derived information such
as direction and speed, calculated from position changes.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 37
Three satellites might seem enough to solve for position since space has three dimensions and a
position near the Earth's surface can be assumed. However, even a very small clock error multiplied
by the very large speed of light — the speed at which satellite signals propagate — results in a large
positional error. Therefore receivers use four or more satellites to solve for the receiver's location
and time. The very accurately computed time is effectively hidden by most GPS applications, which
use only the location. A few specialized GPS applications do however use the time; these
include time transfer, traffic signal timing, and synchronization of cell phone base stations.
Although four satellites are required for normal operation, fewer apply in special cases. If one
variable is already known, a receiver can determine its position using only three satellites. For
example, a ship or aircraft may have known elevation. Some GPS receivers may use additional clues
or assumptions (such as reusing the last known altitude, dead reckoning, inertial navigation, or
including information from the vehicle computer) to give a less accurate (degraded) position when
fewer than four satellites are visible.
POSITION CALCULATION:
To provide an introductory description of how a GPS receiver works, error effects are deferred to a
later section. Using messages received from a minimum of four visible satellites, a GPS receiver is
able to determine the times sent and then the satellite positions corresponding to these times sent.
The x, y, and z components of position, and the time sent, are designated as where the
subscript i is the satellite number and has the value 1, 2, 3, or 4. Knowing the indicated time the
message was received , the GPS receiver can compute the transit time of the message as .
Assuming the message traveled at the speed of light, c, the distance traveled or pseudo range can
be computed as .
A satellite's position and pseudo range define a sphere, centered on the satellite, with radius equal to
the pseudo range. The position of the receiver is somewhere on the surface of this sphere. Thus with
four satellites, the indicated position of the GPS receiver is at or near the intersection of the surfaces
of four spheres. In the ideal case of no errors, the GPS receiver would be at a precise intersection of
the four surfaces.
If the surfaces of two spheres intersect at more than one point, they intersect in a circle. The
article trilateration shows this mathematically. A figure, Two Sphere Surfaces Intersecting in a
Circle, is shown below. Two points where the surfaces of the spheres intersect are clearly shown in
the figure. The distance between these two points is the diameter of the circle of intersection.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 38
Figure: Two sphere surfaces intersecting in a circle
The intersection of a third spherical surface with the first two will be its intersection with that circle;
in most cases of practical interest, this means they intersect at two points. Another figure, Surface of
Sphere Intersecting a Circle (not a solid disk) at Two Points, illustrates the intersection. The two
intersections are marked with dots. Again the article trilateration clearly shows this mathematically.
Figure: Surface of sphere intersecting a circle (not a solid disk) at two points
For automobiles and other near-earth vehicles, the correct position of the GPS receiver is the
intersection closest to the Earth's surface. For space vehicles, the intersection farthest from Earth
may be the correct one.
The correct position for the GPS receiver is also the intersection closest to the surface of the sphere
corresponding to the fourth satellite.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 39
APPLICATIONS:
CIVILIAN
1. Disaster relief/emergency services: Depend upon GPS for location and timing capabilities.
2. Geofencing: Vehicle tracking systems, person tracking systems, and tracking systems use
GPS to locate a vehicle, person, or pet.
3. GPS tours: Location determines what content to display; for instance, information about an
approaching point of interest.
4. Map-making: Both civilian and military cartographers use GPS extensively.
5. Navigation: Navigators value digitally precise velocity and orientation measurements.
6. Phasor measurement units: GPS enables highly accurate timestamping of power system
measurements, making it possible to compute phasors.
7. Recreation: For example, geocaching, geodashing, GPS drawing and waymarking.
8. Surveying: Surveyors use absolute locations to make maps and determine property
boundaries.
MILITARY
1. Navigation: GPS allows soldiers to find objectives, even in the dark or in unfamiliar
territory, and to coordinate troop and supply movement. In the United States armed forces,
commanders use the Commanders Digital Assistant and lower ranks use the Soldier Digital
Assistant.
2. Search and Rescue: Downed pilots can be located faster if their position is known.
3. Reconnaissance: Patrol movement can be managed more closely.
4. GPS satellites carry a set of nuclear detonation detectors consisting of an optical sensor (Y-
sensor), an X-ray sensor, a dosimeter, and an electromagnetic pulse (EMP) sensor (W-sensor), that
form a major portion of the United States Nuclear Detonation Detection System.
GPS POSITIONING: PRINCIPLE
Principle of GPS positioning:
i) Satellite 1 sends a signal at time te1
ii) Ground receiver receives it signal at time tr
iii) The range measurement ρ1to satellite 1 is
(1) ρ1= (tr-te1) xspeed of light
(2) We are therefore located on a sphere with radius ρ1 centered on satellite 1
–3 satellites ⇒intersection of 3 spheres
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 40
In simple mathematical terms:
i) GPS receivers: Measure tr,–Decode te, Compute ρrs.
ii) If the position of the satellites in an Earth-fixed frame (Xs, Ys, Zs) is known
iii) Then one can solve for (Xr, Yr, Xr)(if at least 3 simultaneous range measurements)
SATELLITE-RECEIVER TIME OFFSET
The receiver clocks are:
1. Mediocre: stability ~10-5-10-6(~ crystal wrist watch)
2. Not synchronized with the satellite clocks.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 41
There is a time difference between the satellite clock-ts and the receiver clock-tr: δt= tr–ts
1. The receivers therefore measures: τ= t + δt
2. In terms of distance: τxc = (t + δt) xc = r + δr= ρ
3. The receiver actually measures ρ= pseudo range
Practical consequences:
1. The time offset between satellite and receiver clocks is an additional unknown
2. We need 4 observations ⇒4 satellites visible at the same time
3. In order to compute a position, the receiver solves for δt => GPS receivers are very precise
clocks! (Timing is a very important application of GPS)
δt is used by the receiver to synchronize its clock with the satellite clocks. That sync is as good as δt
accuracy or ~ 0.1 μsec: we will still need to solve for δt.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 42
10. GPS-634R
GPS-634R‖ is a highly integrated smart GPS module with a ceramic GPS patch antenna. The
antenna is connected to the module via an LNA. The module is with 51 channel acquisition engine
and 14 channel track engine, which be capable of receiving signals from up to 65 GPS satellites and
transferring them into the precise position and timing information that can be read over either
UART port or RS232 serial port. Small size and high-end GPS functionality are at low power
consumption, Both of the LVTTL-level and RS232 signal interface are provided on the interface
connector, supply voltage of 3.6V~6.0V is supported. The smart GPS antenna module is available
as an off-the-shelf component, 100% tested. The smart GPS antenna module can be offered for
OEM applications with the versatile adaptation in form and connection. Additionally, the antenna
can be tuned to the final systems‘ circumstances.
FEATURES:
65 channels to acquire and track satellites simultaneously.
Industry-leading TTFF speed.
Integral LNA with low power control.
Cold start 29 sec under clear Sky.
Hot start 1 sec under clear Sky.
Accuracy 5m CEP.
Operable at 3.6V-6V.
Both of RS232 and UART interface at CMOS level.
Small form factor of 32 mm W x 32 mm Lx 8 mm H.
Mountable without solder process.
6 pins wafer connector.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 43
GENERAL SPECIFICATION:
The smart GPS antenna modules are characterized by the following parameters:
Interfacing ATMEGA162 with GPS-634R
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 44
In our module we are connecting GPS-634R to USART1 of the ATMEGA162.The GPS data is in
NMEA format NMEA contains 19 sentences. We are using GGA-GLOBAL POSITIONING
SYSTEM FIX DATA sentence.
NMEA protocol
The serial interface protocol is based on the National Marine Electronics Association‘s NMEA 0183
ASCII interface specification.
GGA-GLOBAL POSITIONING SYSTEM FIX DATA
Time, position and fix related data for a GPS receiver.
Structure:
$GPGGA,hhmmss.sss,ddmm.mmmm,a,dddmm.mmmm,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh<CR><
LF>
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 45
The data that we receive continuously in $GPGGA format, we extract only latitude and longitude
information using microcontroller, display it on LCD and continuously send the data to the central
server.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 46
11. Implementation FlowChart
Initialization of ports of
microcontroller
Microcontroller is made
ready for serial
communication
Receive interrupt pin is
enabled in USART0
Baud rate for data
transmission is set to 9600
START
LCD initialization
INT0 and INT1 interrupt
pins are enabled for rising
edge input
A
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 47
A
Define PORTA for
buzzer output
PWM initialization
and set the timer value
Receive GPS data
continuously through
USART1.
Send GPS data
continuously through
USART0 to the central
server.
B
F
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 48
No
Yes
IR Sensors
detects
collision
B
Interrupt service
routine 0
Is
emergency
key
pressed?
C D E
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 49
C
Interrupt service
routine 1
D E
If receive
interrupt
occurs in
USART1?
Receive interrupt
routine
F F
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 50
Interrupt service
routine 0
Display message on LCD
Motor control, reduce
speed
Buzzer ON
Delay 3seconds
Return
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 51
Interrupt service
routine 1
Display message on LCD
Motor control, reduce
speed
Buzzer ON
Delay 3seconds
Send continuous stream of
24 bits zeroes to central
server to indicate break
down
Return
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 52
No
Yes
Receive interrupt
routine
Is received
bit is ‗B‘?
Display message on LCD
―BLIND ZONE‖
Motor control, reduce
speed
Buzzer ON
Delay 3seconds
Display message on LCD
―ACCIDENT ZONE‖
Motor control, reduce
speed
Buzzer ON
Delay 3seconds
Is received
bit is ‗A‘?
Return Return
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 53
LCD initialization
LCDcmd(value)
value=enabling the
LCD
DELAY
LCDcmd(value)
value=clear display
screen
DELAY
LCDcmd(value)
value=increment
cursor
DELAY
LCDcmd(value)
value=display on,
cursor off
Return
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 55
13. Implementation Hardware/Software
Hardware Implementation includes the steps involved in connecting the controllers and drivers to
build the ECU. Software implementation includes the steps involved to program these IO devices.
The components used were microcontrollers, GPS module, IR sensors. Emergency switch and
Buzzer. Interfacing the Inputs to the microcontrollers require some form of drivers such as
MAX232, to convert the serial data from GPS to TTL compatible Digital Circuits.
IR sensors is connected to the INT0 of the microcontroller (PD2 pin 12).Here the interrupt occurs at
the rising edge of the clock. When interrupt occurs, the OS branches to the ISR to indicate a warning
for Head On Collision of the Vehicle to the driver.
GPS values from the received into the USART1 of the microcontroller which is then converted to
TTL using MAX232.The values in the USART are in the standard GPGGA format. These are then
processed so that only the latitude and longitude part of the format are extracted by suitable
programming. The extracted location are continuously relayed to the central sever via Zigbee.
Emergency Switch is a normal switch interface to the microcontroller which is connected to the
INT1(PD3 pin13). The OS branches to the ISR at the rising edge of the interrupt. The ISR then
relays this status as a string of 23 zeroes.
Central Server is a Backbone network which handles data from all the ECU. This is built on a
LabVIEW platform. The programming for which is done graphically and is interfaced to receive
information from the serial port of the Server.The programming at the central server is done in such
a way that when a vehicle enters a special zone, the required status messages are sent to the
concerned ECU to update the driver about this information. At Blind crossings the server compares
the location values of the current vehicle in the region with other vehicles in the same region. If the
locations are close by, the appropriate warning message is indicated
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 56
14. Conclusion
The project is mainly implemented as prototype ECU. It has advantages of many other similar
products as it uses LabVIEW as its database management system, which is a simple graphical
programming interface via the serial port of the prototype server. The components required to build
up the ECU are of low cost (73$ appx.) and the components abundantly available in the market. The
main goal of the project was to avoid lot of accident happening in the world in the present time
thereby securing human life to a certain extent. The success of this project is proved by its selection
for the All India Young Engineers’ Humanitarian Challenge 2011, IEEE. The project has been
selected at an All India level with 33124 students participating out of which 150 projects are
selected.
This low cost, low power ECU is being proposed for a large scale production to be implemented in
automobiles. This idea has been sent for a conference at the IEEE proceedings.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 57
15. FUTURE SCOPE
1. Ultra Sonic sensors can be used instead of IR sensors, as they are sensitive to ambient light.
2. Range detection can also be done using ultra sonic sensors.
3. A GUI can be built showing the position of other vehicles on the on board unit relative to the
current position.
4. Motion detection can be done using PIR sensors to differentiate between a stationary vehicle and
moving vehicle.
5. Pressure sensors can be used to indicate the Collision to the central server, so that an emergency
can be called upon.
6. Road side units can be placed to relay the information from one small region to a central database
so that hierarchal approach can be followed.
7. The system can be programmed using a RTOS for better response time.
8. Singals relayed to the server can be encoded using PN-sequences so that the are encrypted to a
higher extent, thus security is maintained
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 58
16. REFERENCES
1. Learning with LabVIEW 7TM EXPRESS- Robert H. Bishop
2. "Product Activation FAQ", National Instruments.
3. "Building a Stand-Alone Application", National Instruments.
4. "Using the Lab VIEW Run-Time Engine", National Instruments.
5. Internet references:
http://www.ni.com/events/tutorials/campus.htm
http://forums.ni.com/
http://zone.ni.com/devzone/fn/p/sn/n15:EXAMPLE
http://www.wikipedia.com/
www.google.com.
www.atmel.com
www.howstuffworks.com
http://www.gpsinformation.org/dale/nmea.htm
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 59
17. Appendix
Figure:Block diagram panel
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 61
Sensors
IR Sensor:
The IR sensors use the infrared region of the spectrum. It mainly consists of two parts namely:
The transmitter
The receiver
The transmitter is a LED whose output wavelength is in the IR region of spectrum. The receiver is
a photo detector. The various IR regions are:
Near Infrared NIR 0.78 - 3 µm
Mid Infrared MIR 3 - 50 µm
Far Infrared FIR 50 - 1000 µm
The above figure shows the principle of the IR Sensor used in the project. The LED transmits
Electromagnetic waves in infrared region. This forms the transmitter. When electromagnetic waves
are reflected by the object, leakage current flows through the photodetector if the strength of the
electromagnetic waves that falls on the photodetector is more than the threshold strength required to
generate the leakage current. This current is given as an interrupt to the microcontroller.
Collision Avoidance for Vehicle Safety 2011
Department Of TCE, BMSCE Page 62
Break Down Switch:
This is an emergency switch that is connected as an interrupt to the microcontroller. In case of
vehicle break down where the User has no other means to communicate for help, then he can take
help of this emergency switch to call help. When the User presses this switch, it acts as an interrupt
to the microcontroller. This interrupt is detected on the rising edge of the clock by the
microcontroller and it sends a string of zeroes to the central server. As soon as the central server
detects this, it notes down the location of the vehicle that had asked for help and immediately
informs the emergency services with location of the vehicle.