PROJECT TRAINING In

EMBEDDED SYSTEM & ROBOTICS

WITH “C”
at
ROBOSAPIENSINDIA
Submitted for partial fulfillment of award of

BACHELOR OF TECHNOLOGY degree 
 In
ELECTRONICS AND COMMUNICATION
ENGINEERING
Submitted By

ANUJ CHOUDHARY (0708210017)

MORADABAD INSTITUTE OF TECHNOLOGY,

MORADABAD, INDIA
 JULY, 2010

ACKNOWLEDGEMENT
This project is the outcome of the efforts of several people, apart from the team members, and it
is important that their help be acknowledgement here.

First of all I want to present my sincere gratitude and deep appreciations to MR.PRADEEP
SHARMA, GENERAL MANAGER to allow me to undertake the industrial training in
RBOSAPIENSINDIA ,NOIDA one of the leading organization amongst the Electronics industries in
India.

Without motivation, a person is literally unable to make his best effort. I am highly grateful to
him for his guidance as he played an important role in preparing me for industrial culture and making
me aware of actual scenario and work culture in organization.

I would like to devote my special thanks to Mr.UJJAWAL SARKAR for teaching

EMBEDDED SYSTEM AND ROBOTICS in a very easy and interesting manner.

I would like to thanks Ms. MAHIMA RAINA (PROGRAM CO-ORDINATOR) and rest all
faculty member of centre and all the employee of ROBOSAPIENSINDIA IN NOIDA, who devoted
their valuable time to render me information about the complexities of industries and technical know-
how.

The Organization has a beautiful and well organized work environment which made a great
pleasure and an easy task to learn and understand the principles and theories.

ANUJ CHOUDHARY
ELECTRONICS AND COMMUNICATION
7th Sem ,E- Sec
0708210017
 ABSTRACT
Although embedded systems are generally defined as special-purpose computer-
systems designed to perform one or more dedicated functions, usually with real-time
constraints, and have computer hardware and software embedded as parts of a complete
device or system, they range from simple portable devices to sophisticated multi-board
stationary systems.

We are living in the Embedded World. You are surrounded with many embedded
products and your daily life largely depends on the proper functioning of these gadgets.
Television, Radio, CD player of your living room, Washing Machine or Microwave Oven
in your kitchen, Card readers, Access Controllers, Palm devices of your work space
enable you to do many of your tasks very effectively. Apart from all these, many
controllers embedded in your car take care of car operations between the bumpers and
most of the times you tend to ignore all these controllers.

In recent days, you are showered with variety of information about these embedded
controllers in many places. All kinds of magazines and journals regularly dish out details
about latest technologies, new devices, fast applications which make you believe that
your basic survival is controlled by these embedded products. Now you can agree to the
fact that these embedded products have successfully invaded into our world. You must be
wondering about these embedded controllers or systems. What is this Embedded System?
The computer you use to compose your mails, or create a document or analyze the
database is known as the standard desktop computer. These desktop computers are
manufactured to serve many purposes and applications.
 TABLE OF CONTENTS
INTRODUCTION ABOUT ROBOSAPIENSINDIA

ROBOSAPIENS AND ROBOTRYSTS’ 2010

Part I: Embedded Systems

A. OVERVIEW

A.I Examples of embedded systems

A.II Embedded systems span all aspects of modern life and there are
many examples of their use
B. HISTORY
C. CHARACTERISTICS
D. USER INTERFACES
D.I Simple systems
D.II In more complex systems
D.III CPU platforms
D.IV Ready made computer boards
D.V ASIC and FPGA solutions

E. PERIPHERALS
F. TOOLS
G. DEBUGGING
H. RELIABILITY
I. EMBEDDED SOFTWARE ARCHITECTURES

I.I Simple control loop

I.II Interrupt controlled system

I.III Cooperative multitasking

I.IV Preemptive multitasking or multi-threading

I.V Microkernels and exokernels

I.VI Monolithic kernels

I.VII Exotic custom operating systems

I.VIII Additional software components

Part II: Robotics

A. HISTORY

B. COMPONENT OF ROBOT

C. ROBOT –HUMAN INTERFACE

D. WALKING ROBOTS

Part III: AVR Microcontroller

A. HISTORY
B. DEVICE OVERVIEW
 B. I BASIC FAMILIES

C. DEVICE ARCHITECHTURE

D. PROGRAM MEMORY

D.I EEPROM

E. PROGRAM EXECUTION

E.I Instruction Sets

F. MCU SPEED

G. DEVELOPMENT

H. FEATURES

Part IV: PROJECTS

A. MOBILE PHONE OPERATED ROBOT

A.I Overview
A.II Circuit Description
A.III Working
A.IV Programing

B. LINE FOLLOWER USING L293D H-BRIDGE IC

B.I Introduction
B.II Dc Gear Motor
B.III IR Sensors
B.IV IR LED
B.V Photodiode
 B.VI OP-amp
B.VII Working
B.VIII Sensitivity of IR Sensors
B.IX Motor Driver IC (L293D)
B.X Working Model
B.XI Programing

INTORDUCTION ABOUT ROBOSAPIENS INDIA

Mission:
The basic objective of the organization is to generate a need for robotics education among
engineering Students and schools in India and become a name synonymous with robotics
education and related events in the country by providing the most comprehensive and
fulfilling services and by creating an ambience of creativity and an approach towards
seeking logical solutions to everyday problems. The vision of the founders’ mantra is

‘INVENT THE TECHNOLOGY YOU DESIRE’

Achievements:
Robosapiens-India team has been granted the Patent on 'SSBMC' by Government of
India. This achievement entails a long story involving dedicated efforts and hard work.
The team Robosapiens-India has faced many obstacles and roadblocks on its journey to
success but it’s never ending zeal for success and excellence has made them the best
team. What lessons can be learnt from this extraordinary feat? What special did the team
Robosapiens-India do? How did we cope up with the challenging business environment?
What has been their mantra of success?

This cover story aims at answering the above and many more questions. The idea is to
learn as much as possible from the team and to reapply the proven expertise to repeat the
success. Let’s begin with the tale of extraordinary events.
 ROBOSAPIENS AND ROBOTRYSTS’2010

Robotrysts'2010 is an initiative by Robosapien India & Emanagineer India in

association with Radiance '10, IIT Bombay towards Robotics. It’s a National level
Robotics Championship. The prelims Rounds will be organized at different Zonal
centers all across India.

Radiance An enlightenment... An awakening A beginning.. Well certainly a most apt

name for a festival that even in its most elementary form applauds the power of
knowledge. An event where different sectors of industry and academia are brought
together to facilitate a pleasant and yet vibrant exchange of knowledge. Radiance, is the
Annual Research & Technological Festival of Mechanical Engineering Department, IIT
Bombay , organized by Mechanical Engineering Association . Conceptualized in 2007,
Radiance over the years has proved its mettle by bridging the gap between an
academicians theoretical knowledge and an industry professionals solutions to real life
technical problems. And with v4.0 all geared up for 13-14 March 2010, Radiance is
coming back and it is bigger than ever. Spanning from mind-crunching treasure hunts to
research paper presentations, from never-seen-before workshops to inspiring lectures to
designing competitions, we bring you an arsenal of events that endeavors to explore
every dimension and aspect of the science that we call "Mechanical Engineering.

RoboTrysts 2010 organised Successfully

 PART I
EMBEDDED SYSTEM

Picture of the internals

of a Netgear ADSL
modem/router.

Microprocessor (4),
RAM (6), and flash
memory (7).

A. OVERVIEW

An EMBEDDED SYSTEM is a special-purpose computer system designed to

perform one or a few dedicated functions often with real-time computing constraints. It is
usually embedded as part of a complete device including hardware and mechanical parts.
In contrast, a general-purpose computer, such as a personal computer, can do many
different tasks depending on programming. Embedded systems control many of the
common devices in use today.

Since the embedded system is dedicated to specific tasks, design engineers can optimize
it, reducing the size and cost of the product, or increasing the reliability and performance.
Some embedded systems are mass-produced, benefiting from economies of scale.

Physically, embedded systems range from portable devices such as digital watches and
MP4 players, to large stationary installations like traffic lights, factory controllers, or the
systems controlling nuclear power plants. Complexity varies from low, with a single
microcontroller chip, to very high with multiple units, peripherals and networks mounted
inside a large chassis or enclosure.

In general, "EMBEDDED SYSTEM" is not an exactly defined term, as many systems

have some element of programmability. For example, Handheld computers share some
elements with embedded systems — such as the operating systems and microprocessors
which power them — but are not truly embedded systems, because they allow different
applications to be loaded and peripherals to be connected.

A.IEXAMPLES OF EMBEDDED SYSTEMS :

PC Engines' ALIX.1C Mini-ITX embedded

board with an x86 AMD Geode LX 800
together with Compact Flash, miniPCI
and PCI slots, 22-pin IDE interface, audio,
USB and 256MB RAM
 An embedded Router Board 112 with U.FL-
RSMA pigtail and R52 miniPCI Wi-Fi card
widely used by wireless Internet service
providers (WISPs) in the Czech Republic

A.II Embedded systems span all aspects of modern

life and there are many examples of their use:-
Telecommunications systems employ numerous embedded systems from telephone
switches for the network to mobile phones at the end-user. Computer networking
uses dedicated routers and network bridges to route data.

Consumer electronics include personal digital assistants (PDAs), mp3 players,

mobile phones, videogame consoles, digital cameras, DVD players, GPS receivers,
and printers. Many household appliances, such as microwave ovens, washing
machines and dishwashers, are including embedded systems to provide flexibility,
efficiency and features. Advanced HVAC systems use networked thermostats to
more accurately and efficiently control temperature that can change by time of day
and season. Home automation uses wired- and wireless-networking that can be
used to control lights, climate, security, audio/visual, surveillance, etc., all of
which use embedded devices for sensing and controlling.

Transportation systems from flight to automobiles increasingly use embedded

systems. New airplanes contain advanced avionics such as inertial guidance
systems and GPS receivers that also have considerable safety requirements.
Various electric motors — brushless DC motors, induction motors and DC motors
— are using electric/electronic motor controllers. Automobiles, electric vehicles,
and hybrid vehicles are increasingly using embedded systems to maximize
efficiency and reduce pollution. Other automotive safety systems such as anti-lock
braking system (ABS), Electronic Stability Control (ESC/ESP), traction control
(TCS) and automatic four-wheel drive.

Medical equipment is continuing to advance with more embedded systems for vital
signs monitoring, electronic stethoscopes for amplifying sounds, and various
medical imaging (PET, SPECT, CT, MRI) for non-invasive internal inspections.
 In addition to commonly described embedded systems based on small computers, a
new class of miniature wireless devices called motes are quickly gaining popularity
as the field of wireless sensor networking rises. Wireless sensor networking, WSN,
makes use of miniaturization made possible by advanced IC design to couple full
wireless subsystems to sophisticated sensor, enabling people and companies to
measure a myriad of things in the physical world and act on this information
through IT monitoring and control systems. These motes are completely self
contained, and will typically run off a battery source for many years before the
batteries need to be changed or charged.

B. HISTORY:
In the earliest years of computers in the 1930–40s, computers were sometimes dedicated
to a single task, but were far too large and expensive for most kinds of tasks performed
by embedded computers of today. Over time however, the concept of programmable
controllers evolved from traditional electromechanical sequencers, via solid state devices,
to the use of computer technology.

One of the first recognizably modern embedded systems was the Apollo Guidance
Computer, developed by Charles Stark Draper at the MIT Instrumentation Laboratory. At
the project's inception, the Apollo guidance computer was considered the riskiest item in
the Apollo project as it employed the then newly developed monolithic integrated circuits
to reduce the size and weight. An early mass-produced embedded system was the
Autonetics D-17 guidance computer for the Minuteman missile, released in 1961. It was
built from transistor logic and had a hard disk for main memory. When the Minuteman II
went into production in 1966, the D-17 was replaced with a new computer that was the
first high-volume use of integrated circuits. This program alone reduced prices on quad
nand gate ICs from $1000/each to $3/each, permitting their use in commercial products.

Since these early applications in the 1960s, embedded systems have come down in price
and there has been a dramatic rise in processing power and functionality. The first
microprocessor for example, the Intel 4004, was designed for calculators and other small
systems but still required many external memory and support chips. In 1978 National
Engineering Manufacturers Association released a "standard" for programmable
microcontrollers, including almost any computer-based controllers, such as single board
computers, numerical, and event-based controllers.

As the cost of microprocessors and microcontrollers fell it became feasible to replace

expensive knob-based analog components such as potentiometers and variable capacitors
with up/down buttons or knobs read out by a microprocessor even in some consumer
products. By the mid-1980s, most of the common previously external system components
had been integrated into the same chip as the processor and this modern form of the
microcontroller allowed an even more widespread use, which by the end of the decade
were the norm rather than the exception for almost all electronics devices.

The integration of microcontrollers has further increased the applications for which
embedded systems are used into areas where traditionally a computer would not have
been considered. A general purpose and comparatively low-cost microcontroller may
often be programmed to fulfill the same role as a large number of separate components.
Although in this context an embedded system is usually more complex than a traditional
solution, most of the complexity is contained within the microcontroller itself. Very few
additional components may be needed and most of the design effort is in the software.
The intangible nature of software makes it much easier to prototype and test new
revisions compared with the design and construction of a new circuit not using an
embedded processor.

C. CHARACTERISTICS:

Soekris net4801, an embedded system

targeted at network applications.

A. Embedded systems are designed to do some specific task, rather than be a

general-purpose computer for multiple tasks. Some also have real-time
performance constraints that must be met, for reasons such as safety and
usability; others may have low or no performance requirements, allowing the
system hardware to be simplified to reduce costs.
B. Embedded systems are not always standalone devices. Many embedded systems
consist of small, computerized parts within a larger device that serves a more
general purpose. For example, the Gibson Robot Guitar features an embedded
system for tuning the strings, but the overall purpose of the Robot Guitar is, of
course, to play music.[2] Similarly, an embedded system in an automobile provides
a specific function as a subsystem of the car itself.
C. The program instructions written for embedded systems are referred to as
firmware, and are stored in read-only memory or Flash memory chips. They run
with limited computer hardware resources: little memory, small or non-existent
keyboard and/or screen.

D. USER INTERFACES:

Embedded system text user

interface using Micro VGA
Embedded systems range from no user interface at all — dedicated only to one task — to
complex graphical user interfaces that resemble modern computer desktop operating
systems.

D.I Simple systems

Simple embedded devices use buttons, LEDs, and small character- or digit-only displays,
often with a simple menu system.

D.II In more complex systems

A full graphical screen, with touch sensing or screen-edge buttons provides flexibility
while minimizing space used: the meaning of the buttons can change with the screen, and
selection involves the natural behavior of pointing at what's desired.

Handheld systems often have a screen with a "joystick button" for a pointing device.

Many systems have "maintenance" or "test" interfaces that provide a menu or command
system via an RS-232 interface. This avoids the cost of a display, but gives a lot of
control. Most consumers cannot assemble the required cables, however.

The rise of the World Wide Web has given embedded designers another quite different
option: providing a web page interface over a network connection. This avoids the cost of
a sophisticated display, yet provides complex input and display capabilities when needed,
on another computer. This is successful for remote, permanently installed equipment such
as Pan-Tilt-Zoom cameras and network routers.

D.III CPU platforms

Embedded processors can be broken into two broad categories: ordinary microprocessors
(μP) and microcontrollers (μC), which have many more peripherals on chip, reducing
cost and size. Contrasting to the personal computer and server markets, a fairly large
number of basic CPU architectures are used; there are Von Neumann as well as various
degrees of Harvard architectures, RISC as well as non-RISC and VLIW; word lengths
vary from 4-bit to 64-bits and beyond (mainly in DSP processors) although the most
typical remain 8/16-bit. Most architecture comes in a large number of different variants
and shapes, many of which are also manufactured by several different companies.

D.IV Ready made computer boards

PC/104 and PC/104+ are examples of available ready made computer boards intended for
small, low-volume embedded and ruggedized systems. These often use DOS, Linux,
NetBSD, or an embedded real-time operating system such as MicroC/OS-II, QNX or
VxWorks.

In certain applications, where small size is not a primary concern, the components used
may be compatible with those used in general purpose computers. Boards such as the
VIA EPIA range help to bridge the gap by being PC-compatible but highly integrated,
physically smaller or have other attributes making them attractive to embedded engineers.
The advantage of this approach is that low-cost commodity components may be used
along with the same software development tools used for general software development.
Systems built in this way are still regarded as embedded since they are integrated into
larger devices and fulfill a single role. Examples of devices that may adopt this approach
are ATMs and machines. And which contain code specific to the application.

D.V ASIC and FPGA solutions

A common configuration for very-high-volume embedded systems is the system on a
chip (SoC) which contains a complete system consisting of multiple processors,
multipliers, caches and interfaces on a single chip. SoCs can be implemented as an
application-specific integrated circuit (ASIC) or using a field-programmable gate array
(FPGA).

E. Peripherals
Embedded Systems talk with the outside world via peripherals, such as:

 Serial Communication Interfaces (SCI): RS-232, RS-422, RS-485 etc

 Synchronous Serial Communication Interface: I2C, SPI, SSC and ESSI (Enhanced
Synchronous Serial Interface)
 Universal Serial Bus (USB)
 Multi Media Cards (SD Cards, Compact Flash etc)
 Networks: Ethernet, Controller Area Network, LonWorks, etc
 Timers: PLL(s), Capture/Compare and Time Processing Units
 Discrete IO: aka General Purpose Input/Output (GPIO)
 Analog to Digital/Digital to Analog (ADC/DAC)
 Debugging: JTAG, ISP, ICSP, BDM Port, ...

F. Tools
As for other software, embedded system designers use compilers, assemblers, and
debuggers to develop embedded system software. However, they may also use some
more specific tools:

 In circuit debuggers or emulators (see next section).

 Utilities to add a checksum or CRC to a program, so the embedded system can
check if the program is valid.
 For systems using digital signal processing, developers may use a math workbench
such as Scilab / Scicos, MATLAB / Simulink, EICASLAB, MathCad, or
Mathematica to simulate the mathematics. They might also use libraries for both
the host and target which eliminates developing DSP routines as done in DSPnano
RTOS and Unison Operating System.
 Custom compilers and linkers may be used to improve optimisation for the
particular hardware.
 An embedded system may have its own special language or design tool, or add
enhancements to an existing language such as Forth or Basic.
 Another alternative is to add a Real-time operating system or Embedded operating
system, which may have DSP capabilities like DSPnano RTOS.

Software tools can come from several sources:

 Software companies that specialize in the embedded market

 Ported from the GNU software development tools
 Sometimes, development tools for a personal computer can be used if the
embedded processor is a close relative to a common PC processor

As the complexity of embedded systems grows, higher level tools and operating systems
are migrating into machinery where it makes sense. For example, cellphones, personal
digital assistants and other consumer computers often need significant software that is
purchased or provided by a person other than the manufacturer of the electronics. In these
systems, an open programming environment such as Linux, NetBSD, OSGi or Embedded
Java is required so that the third-party software provider can sell to a large market.

G. Debugging
Embedded Debugging may be performed at different levels, depending on the facilities
available. From simplest to most sophisticate they can be roughly grouped into the
following areas:
  Interactive resident debugging, using the simple shell provided by the embedded
operating system (e.g. Forth and Basic)
 External debugging using logging or serial port output to trace operation using
either a monitor in flash or using a debug server like the Remedy Debugger which
even works for heterogeneous multicore systems.
 An in-circuit debugger (ICD), a hardware device that connects to the
microprocessor via a JTAG or NEXUS interface. This allows the operation of the
microprocessor to be controlled externally, but is typically restricted to specific
debugging capabilities in the processor.
 An in-circuit emulator replaces the microprocessor with a simulated equivalent,
providing full control over all aspects of the microprocessor.
 A complete emulator provides a simulation of all aspects of the hardware, allowing
all of it to be controlled and modified and allowing debugging on a normal PC.

Unless restricted to external debugging, the programmer can typically load and run
software through the tools, view the code running in the processor, and start or stop its
operation. The view of the code may be as assembly code or source-code.

Because an embedded system is often composed of a wide variety of elements, the

debugging strategy may vary. For instance, debugging a software- (and microprocessor-)
centric embedded system is different from debugging an embedded system where most of
the processing is performed by peripherals (DSP, FPGA, and co-processor). An
increasing number of embedded systems today use more than one single processor core.
A common problem with multi-core development is the proper synchronization of
software execution. In such a case, the embedded system design may wish to check the
data traffic on the busses between the processor cores, which requires very low-level
debugging, at signal/bus level, with a logic analyzer, for instance.

H. Reliability
Embedded systems often reside in machines that are expected to run continuously for
years without errors and in some cases recover by themselves if an error occurs.
Therefore the software is usually developed and tested more carefully than that for
personal computers, and unreliable mechanical moving parts such as disk drives,
switches or buttons are avoided.

Specific reliability issues may include:

H.I The system cannot safely be shut down for repair, or it is too inaccessible to repair.
Examples include space systems, undersea cables, navigational beacons, bore-hole
systems, and automobiles.
H.II The system must be kept running for safety reasons. "Limp modes" are less
tolerable. Often backups are selected by an operator. Examples include aircraft
navigation, reactor control systems, safety-critical chemical factory controls, train
signals, engines on single-engine aircraft.
H.III The system will lose large amounts of money when shut down: Telephone
switches, factory controls, bridge and elevator controls, funds transfer and market
making, automated sales and service.

A variety of techniques are used, sometimes in combination, to recover from errors—

both software bugs such as memory leaks, and also soft errors in the hardware:

 watchdog timer that resets the computer unless the software periodically notifies
the watchdog
 subsystems with redundant spares that can be switched over to
 software "limp modes" that provide partial function
 Designing with a Trusted Computing Base (TCB) architecture[3] ensures a highly
secure & reliable system environment
 An Embedded Hypervisor is able to provide secure encapsulation for any
subsystem component, so that a compromised software component cannot interfere
with other subsystems, or privileged-level system software. This encapsulation
keeps faults from propagating from one subsystem to another, improving
reliability. This may also allow a subsystem to be automatically shut down and
restarted on fault detection.
 Immunity Aware Programming

I. Embedded software architectures

There are several different types of software architecture in common use.

I.I Simple control loop

In this design, the software simply has a loop. The loop calls subroutines, each of which
manages a part of the hardware or software.

I.II Interrupt controlled system

Some embedded systems are predominantly interrupt controlled. This means that tasks
performed by the system are triggered by different kinds of events. An interrupt could be
generated for example by a timer in a predefined frequency, or by a serial port controller
receiving a byte.

These kinds of systems are used if event handlers need low latency and the event
handlers are short and simple.

Usually these kinds of systems run a simple task in a main loop also, but this task is not
very sensitive to unexpected delays.

Sometimes the interrupt handler will add longer tasks to a queue structure. Later, after the
interrupt handler has finished, these tasks are executed by the main loop. This method
brings the system close to a multitasking kernel with discrete processes.

I.III Cooperative multitasking

A nonpreemptive multitasking system is very similar to the simple control loop scheme,
except that the loop is hidden in an API. The programmer defines a series of tasks, and
each task gets its own environment to “run” in. When a task is idle, it calls an idle
routine, usually called “pause”, “wait”, “yield”, “nop” (stands for no operation), etc.

The advantages and disadvantages are very similar to the control loop, except that adding
new software is easier, by simply writing a new task, or adding to the queue-interpreter.

I.IV Preemptive multitasking or multi-threading

In this type of system, a low-level piece of code switches between tasks or threads based
on a timer (connected to an interrupt). This is the level at which the system is generally
considered to have an "operating system" kernel. Depending on how much functionality
is required, it introduces more or less of the complexities of managing multiple tasks
running conceptually in parallel.

As any code can potentially damage the data of another task (except in larger systems
using an MMU) programs must be carefully designed and tested, and access to shared
data must be controlled by some synchronization strategy, such as message queues,
semaphores or a non-blocking synchronization scheme.
Because of these complexities, it is common for organizations to buy a real-time
operating system, allowing the application programmers to concentrate on device
functionality rather than operating system services, at least for large systems; smaller
systems often cannot afford the overhead associated with a generic real time system, due
to limitations regarding memory size, performance, and/or battery life.

I.V Microkernels and exokernels

A microkernel is a logical step up from a real-time OS. The usual arrangement is that the
operating system kernel allocates memory and switches the CPU to different threads of
execution. User mode processes implement major functions such as file systems, network
interfaces, etc.

In general, microkernels succeed when the task switching and intertask communication is
fast, and fail when they are slow.

Exokernels communicate efficiently by normal subroutine calls. The hardware, and all
the software in the system are available to, and extensible by application programmers.

I.VI Monolithic kernels

In this case, a relatively large kernel with sophisticated capabilities is adapted to suit an
embedded environment. This gives programmers an environment similar to a desktop
operating system like Linux or Microsoft Windows, and is therefore very productive for
development; on the downside, it requires considerably more hardware resources, is often
more expensive, and because of the complexity of these kernels can be less predictable
and reliable. Common examples of embedded monolithic kernels are Embedded Linux
and Windows CE.

Despite the increased cost in hardware, this type of embedded system is increasing in
popularity, especially on the more powerful embedded devices such as Wireless Routers
and GPS Navigation Systems. Here are some of the reasons:

 Ports to common embedded chip sets are available.

 They permit re-use of publicly available code for Device Drivers, Web Servers,
Firewalls, and other code.

 Development systems can start out with broad feature-sets, and then the
distribution can be configured to exclude unneeded functionality, and save the
expense of the memory that it would consume.
  Many engineers believe that running application code in user mode is more
reliable, easier to debug and that therefore the development process is easier and
the code more portable.

 Many embedded systems lack the tight real time requirements of a control system.
A system such as Embedded Linux has fast enough response for many
applications.

 Features requiring faster response than can be guaranteed can often be placed in
hardware.

 Many RTOS systems have a per-unit cost. When used on a product that is or will
become a commodity, that cost is significant.

I.VII Exotic custom operating systems

A small fraction of embedded systems require safe, timely, reliable or efficient behavior
unobtainable with the one of the above architectures. In this case an organization builds a
system to suit. In some cases, the system may be partitioned into a "mechanism
controller" using special techniques, and a "display controller" with a conventional
operating system. A communication system passes data between the two.

I.VIII Additional software components

In addition to the core operating system, many embedded systems have additional upper-
layer software components. These components consist of networking protocol stacks like
CAN, TCP/IP, FTP, HTTP, and HTTPS, and also included storage capabilities like FAT
and Flash memory management systems. If the embedded devices have audio and video
capabilities, then the appropriate drivers and codecs will be present in the system. In the
case of the monolithic kernels, many of these software layers are included. In the RTOS
category, the availability of the additional software components depends upon the
commercial offering
 PART II
ROBOTICS

History:
Stories of artificial helpers and companions and attempts to create them have a long
. history

In 1837- the story of the Golem of Prague an humanoid artificial intelligence activated
by inscribing Hebrew letters on its forehead which was based on Jewish folklore that
was created by Jewish German writer Berthold Auerbach for his novel Spinoza.

In 1921- Czech writer Karel Capek introduced the word "robot" in his play R.U.R.
(Rossum's Universal Robots). The word "robot" comes from the word "robota" which
meaning in Czech Is "forced labour drudgery".

In 1927- the Maschinenmensch (“machine-human”) which was a gynoid humanoid

robot also called "Parody", "Futura", "Robotrix", or the "Maria impersonator" (played
by German actress Brigitte Helm), the first and perhaps the most memorable depiction of
a robot ever to appear on film, was depicted in Fritz Lang's film Metropolis.

In 1942- Isaac Asimov formulated the Three Laws of Robotics, and in the process of
doing so, coined the word "robotics" (see details in "Etymology" section below).
In 1948- Norbert Weiner formulated the principles of cybernetics, the basis of practical
robotics.

Fully autonomous robots only appeared in the second half of the 20th century. The first
digitally operated and programmable robot, the Unimate, was installed in 1961 to lift hot
pieces of metal from a die casting machine and stack them. Today, commercial and
industrial robots are in widespread use performing jobs more cheaply or more
accurately and reliably than humans. They are also employed in jobs which are too dirty,
dangerous, or dull to be suitable for humans. Robots are widely used in manufacturing,
assembly, and packing; transport; earth and space exploration; surgery; weaponry;
laboratory research; safety; and mass production of consumer and industrial goods.

Components of robot
 Sructure

 Power Source: At present; mostly(Lead-Acid) batteries are used.

 Actuation

 Sensing : Touch, Vission

 Manipulation

 Locomotion

Robot-Human Interaction
If robots are to work effectively in homes and other non-industrial environments, the
way they are instructed to perform their jobs, and especially how they will be told to stop
will be of critical importance. The people who interact with them may have little or no
training in robotics, and so any interface will need to be extremely intuitive. Science
fiction authors also typically assume that robots will eventually be capable of
communicating with humans through speech, gestures, and facial expression, rather than
a command-line interface. Although speech would be the most natural way for the human
to communicate, it is quite unnatural for the robot. It will be quite a while before robots
interact as naturally as the fictional C-3PO.
 Speech recognition: Interpreting the continuous flow of sounds coming from a
human (speech recognition), in real time, is a difficult task for a computer, mostly
because of the great variability of speech. The same word, spoken by the same
person may sound different depending on local acoustics, volume, the previous
word, whether or not the speaker has a cold, etc.. It becomes even harder when the
speaker has a different accent. Nevertheless, great strides have been made in the
field since Davis, Biddulph, and Balashek designed the first "voice input system"
which recognized "ten digits spoken by a single user with 100% accuracy" in
1952Currently, the best systems can recognize continuous, natural speech, up to
160 words per minute, with an accuracy of 95%

 Gestures: One can imagine, in the future, explaining to a robot chef how to make a
pastry, or asking directions from a robot police officer. On both of these occasions,
making hand gestures would aid the verbal descriptions. In the first case, the robot
would be recognizing gestures made by the human, and perhaps repeating them for
confirmation. In the second case, the robot police officer would gesture to indicate
"down the road, then turn right". It is quite likely that gestures will make up a part
of the interaction between humans and robots A great many systems have been
developed to recognize human hand gestures

 Facial expression: Facial expressions can provide rapid feedback on the progress
of a dialog between two humans, and soon it may be able to do the same for
humans and robots. Robotic faces have been constructed by Hanson Robotics
using their elastic polymer called Frubber, allowing a great amount of facial
expressions due to the elasticity of the rubber facial coating and imbedded
subsurface motors (servos) to produce the facial expressions. The coating and
servos are built on a metal skull. A robot should know how to approach a human,
judging by their facial expression and body language. Whether the person is happy,
frightened, or crazy-looking affects the type of interaction expected of the robot.
Likewise, robots like Kismet and the more recent addition, Nexi can produce a
range of facial expressions, allowing it to have meaningful social exchanges with
humans.
 KISMET can produce a range of
facial expression.

 Artificial emotions Artificial emotions can also be imbedded and are composed of
a sequence of facial expressions and/or gestures. As can be seen from the movie
Final Fantasy: The Spirits Within, the programming of these artificial emotions is
quite complex and requires a great amount of human observation. To simplify this
programming in the movie, presets were created together with a special software
program. This decreased the amount of time needed to make the film. These
presets could possibly be transferred for use in real-life robots.

 Personality: Many of the robots of science fiction have a personality, something

which may or may not be desirable in the commercial robots of the future.
Nevertheless, researchers are trying to create robots which appear to have a
personality: i.e. they use sounds, facial expressions, and body language to try to
convey an internal state, which may be joy, sadness, or fear. One commercial
example is Pleo, a toy robot dinosaur, which can exhibit several apparent emotions

Walking robots
 ASIMO: The World most advanced
humanoid robot (By HONDA’s)

 Walking is a difficult and dynamic problem to solve. Several robots have been
made which can walk reliably on two legs, however none have yet been made
which are as robust as a human. Many other robots have been built that walk on
more than two legs, due to these robots being significantly easier to construct.
Hybrids too have been proposed in movies such as I, Robot, where they walk on 2
legs and switch to 4 (arms+legs) when going to a sprint. Typically, robots on 2 legs
can walk well on flat floors, and can occasionally walk up stairs. None can walk
over rocky, uneven terrain. Some of the methods which have been tried are.

 ZMP Technique: The Zero Moment Point (ZMP) is the algorithm used by robots
such as Honda's ASIMO. The robot's onboard computer tries to keep the total
inertial forces (the combination of earth's gravity and the acceleration and
deceleration of walking), exactly opposed by the floor reaction force (the force of
the floor pushing back on the robot's foot). In this way, the two forces cancel out,
leaving no moment (force causing the robot to rotate and fall over). However, this
is not exactly how a human walks, and the difference is quite apparent to human
observers, some of whom have pointed out that ASIMO walks as if it needs the
lavatory. ASIMO's walking algorithm is not static, and some dynamic balancing is
used (See below). However, it still requires a smooth surface to walk on.

 Hopping: Several robots, built in the 1980s by Marc Raibert at the MIT Leg
Laboratory, successfully demonstrated very dynamic walking. Initially, a robot
with only one leg, and a very small foot, could stay upright simply by hopping.
The movement is the same as that of a person on a pogo stick. As the robot falls to
one side, it would jump slightly in that direction, in order to catch itself. Soon, the
algorithm was generalised to two and four legs. A bipedal robot was demonstrated
 running and even performing somersaults. A quadruped was also demonstrated
which could trot, run, pace, and bound. For a full list of these robots.

 Dynamic Balancing or controlled falling: A more advanced way for a robot to

walk is by using a dynamic balancing algorithm, which is potentially more robust
than the Zero Moment Point technique, as it constantly monitors the robot's
motion, and places the feet in order to maintain stabilityThis technique was
recently demonstrated by Anybots' Dexter Robot, which is so stable, it can even
jump. Another example is the TU Delft Flame
.
 Passive Dynamics: Perhaps the most promising approach utilizes passive
dynamics where the momentum of swinging limbs is used for greater efficiency. It
has been shown that totally unpowered humanoid mechanisms can walk down a
gentle slope, using only gravity to propel themselves. Using this technique, a robot
need only supply a small amount of motor power to walk along a flat surface or a
little more to walk up a hill. This technique promises to make walking robots at
least ten times more efficient than ZMP walkers, like ASIMO

PART III
AVR Microcontroller
The AVR is a modified Harvard architecture 8-bit RISC single chip microcontroller
which was developed by Atmel in 1996. The AVR was one of the first microcontroller
families to use on-chip flash memory for program storage, as opposed to One-Time
Programmable ROM, EPROM, or EEPROM used by other microcontrollers at the
time.

Atmel AVR ATmega8 PDIP.

History
The AVR architecture was conceived by two students at the Norwegian Institute of
Technology (NTH) Alf-Egil Bogen and Vegard Wollan

The original AVR MCU was developed at a local ASIC house in Trondheim, Norway,
where the two founders of Atmel Norway were working as students. It was known as a
μRISC (Micro RISC) When the technology was sold to Atmel, the internal architecture
was further developed by Alf and Vegard at Atmel Norway, a subsidiary of Atmel
founded by the two architects. The designers worked closely with compiler writers at
IAR Systems to ensure that the instruction set provided for more efficient compilation of
high-level languages. Atmel says that the name AVR is not an acronym and does not
stand for anything in particular. The creators of the AVR give no definitive answer as to
what the term "AVR" stands for. .

Among the first of the AVR line was the AT90S8515, which in a 40-pin DIP package has
the same pinout as an 8051 microcontroller, including the external multiplexed address
and data bus. The polarity of the RESET line was opposite (8051's having an active-high
RESET, while the AVR has an active-low RESET), but other than that, the pinout was
identical.
Device overview
The AVR is a Modified Harvard architecture machine with program and data stored in
separate physical memory systems that appear in different address spaces, but having the
ability to read data items from program memory using special instructions.

Basic families
AVRs are generally classified into five broad groups:

 tinyAVR — the ATtiny series

o 0.5–8 kB program memory
o 6–32-pin package
o Limited peripheral set

 megaAVR — the ATmega series

o 4–256 kB program memory
o 28–100-pin package
o Extended instruction set (Multiply instructions and instructions for handling
larger program memories)
o Extensive peripheral set

 XMEGA — the ATxmega series

o 16–384 kB program memory
o 44–64–100-pin package (A4, A3, A1)
o Extended performance features, such as DMA, "Event System", and
cryptography support.
o Extensive peripheral set with DACs

 Application specific AVR

o megaAVRs with special features not found on the other members of the
AVR family, such as LCD controller, USB controller, advanced PWM,
CAN etc.

 Atmel At94k FPSLIC (Field Programmable System Level Integrated Circuit), an

AVR core on-die with an FPGA. The FPSLIC uses SRAM for the AVR program
code, unlike all other AVRs. Partly due to the relative speed difference between
SRAM and flash, the AVR core in the FPSLIC can run at up to 50 MHz.
Device architecture
Flash, EEPROM, and SRAM are all integrated onto a single chip, removing the need for
external memory in most applications. Some devices have a parallel external bus option
to allow adding additional data memory or memory-mapped devices. Almost all devices
(except the smallest TinyAVR chips) have serial interfaces, which can be used to connect
larger serial EEPROMs or flash chips.

Program memory
Program instructions are stored in non-volatile flash memory. Although they are 8-bit
MCUs, each instruction takes one or two 16-bit words.

The size of the program memory is usually indicated in the naming of the device itself
(e.g., the ATmega64x line has 64 kB of flash, however the ATmega32x has only 32 kB).

There is no provision for off-chip program memory; all code executed by the AVR core
must reside in the on-chip flash. However, this limitation does not apply to the AT94
FPSLIC AVR/FPGA chips.

Internal data memory

The data address space consists of the register file, I/O registers, and SRAM.

Internal registers

The AVRs have 32 single-byte registers and are classified as 8-bit RISC devices.

In most variants of the AVR architecture, the working registers are mapped in as the first
32 memory addresses (000016-001F16) followed by the 64 I/O registers (002016-005F16).

Actual SRAM starts after these register sections (address 006016). (Note that the I/O
register space may be larger on some more extensive devices, in which case the memory
mapped I/O registers will occupy a portion of the SRAM address space.)

Even though there are separate addressing schemes and optimized opcodes for register
file and I/O register access, all can still be addressed and manipulated as if they were in
SRAM.
In the XMEGA variant, the working register file is not mapped into the data address
space; as such, it is not possible to treat any of the XMEGA's working registers as though
they were SRAM. Instead, the I/O registers are mapped into the data address space
starting at the very beginning of the address space. Additionally, the amount of data
address space dedicated to I/O registers has grown substantially to 4096 bytes (0000 16-
0FFF16). As with previous generations, however, the fast I/O manipulation instructions
can only reach the first 64 I/O register locations (the first 32 locations for bitwise
instructions). Following the I/O registers, the XMEGA series sets aside a 4096 byte range
of the data address space which can be used optionally for mapping the internal
EEPROM to the data address space (1000 16-1FFF16). The actual SRAM is located after
these ranges, starting at 200016.

EEPROM

Almost all AVR microcontrollers have internal EEPROM for semi-permanent data
storage. Like flash memory, EEPROM can maintain its contents when electrical power is
removed.

In most variants of the AVR architecture, this internal EEPROM memory is not mapped
into the MCU's addressable memory space. It can only be accessed the same way an
external peripheral device is, using special pointer registers and read/write instructions
which makes EEPROM access much slower than other internal RAM.

However, some devices in the SecureAVR (AT90SC) family use a special EEPROM
mapping to the data or program memory depending on the configuration. The XMEGA
family also allows the EEPROM to be mapped into the data address space.

Since the number of writes to EEPROM is not unlimited — Atmel specifies 100,000
write cycles in their datasheets — a well designed EEPROM write routine should
compare the contents of an EEPROM address with desired contents and only perform an
actual write if contents need to be changed.

Program execution
Atmel's AVRs have a two stage, single level pipeline design. This means the next
machine instruction is fetched as the current one is executing. Most instructions take just
one or two clock cycles, making AVRs relatively fast among the eight-bit
microcontrollers.
The AVR family of processors were designed with the efficient execution of compiled C
code in mind and has several built-in pointers for the task.

Instruction set
Atmel AVR instruction set

The AVR Instruction Set is more orthogonal than those of most eight-bit
microcontrollers, in particular the 8051 clones and PIC microcontrollers with which AVR
competes today. However, it is not completely regular:

Pointer registers X, Y, and Z have addressing capabilities that are different from each
other.

Register locations R0 to R15 have different addressing capabilities than register locations
R16 to R31.

I/O ports 0 to 31 have different addressing capabilities than I/O ports 32 to 63.

CLR affects flags, while SER does not, even though they are complementary instructions.
CLR set all bits to zero and SER sets them to one. (Note that CLR is pseudo-op for EOR
R, R; and SER is short for LDI R,$FF. Math operations such as EOR modify flags while
moves/loads/stores/branches such as LDI do not.)

Accessing read-only data stored in the program memory (flash) requires special LPM
instructions; the flash bus is otherwise reserved for instruction memory.

Additionally, some chip-specific differences affect code generation. Code pointers

(including return addresses on the stack) are two bytes long on chips with up to 128
kBytes of flash memory, but three bytes long on larger chips; not all chips have hardware
multipliers; chips with over 8 kBytes of flash have branch and call instructions with
longer ranges; and so forth.

The mostly-regular instruction set makes programming it using C (or even Ada)
compilers fairly straightforward. GCC has included AVR support for quite some time,
and that support is widely used. In fact, Atmel solicited input from major developers of
compilers for small microcontrollers, to determine the instruction set features that were
most useful in a compiler for high-level languages.

MCU speed
The AVR line can normally support clock speeds from 0-20 MHz, with some devices
reaching 32 MHz. Lower powered operation usually requires a reduced clock speed. All
recent (Tiny and Mega, but not 90S) AVRs feature an on-chip oscillator, removing the
need for external clocks or resonator circuitry. Some AVRs also have a system clock
prescaler that can divide down the system clock by up to 1024. This prescaler can be
reconfigured by software during run-time, allowing the clock speed to be optimized.

Since all operations (excluding literals) on registers R0 - R31 are single cycle, the AVR
can achieve up to 1 MIPS per MHz, i.e. an 8 MHz processor can achieve up to 8 MIPS.
Loads and stores to/from memory take 2 cycles, branching takes 3 cycles. Branches in the
latest "3-byte PC" parts such as ATmega2560 are one cycle slower than on previous
devices.

Development
AVRs have a large following due to the free and inexpensive development tools
available, including reasonably priced development boards and free development
software. The AVRs are sold under various names that share the same basic core but with
different peripheral and memory combinations. Compatibility between chips in each
family is fairly good, although I/O controller features may vary.

See external links for sites relating to AVR development.

Features
 Current AVRs offer a wide range of features:
 Multifunction, bi-directional general purpose I/O ports with configurable, built-in
pull-up resistors
 Multiple internal oscillators, including RC oscillator without external parts
 Internal, self-programmable instruction flash memory up to 256 kB (384 kB on
XMega)
 In-system programmable using serial/parallel low-voltage proprietary interfaces or
JTAG
 Optional boot code section with independent lock bits for protection
 On chip debugging (OCD) support through JTAG or debugWIRE on most devices
 The JTAG signals (TMS, TDI, TDO, and TCK) are multiplexed on GPIOs. These
pins can be configured to function as JTAG or GPIO depending on the setting of a
fuse bit, which can be programmed via ISP or HVSP. By default, AVRs with
JTAG come with the JTAG interface enabled.
 debugWIRE uses the /RESET pin as a bi-directional communication channel to
access on-chip debug circuitry. It is present on devices with lower pin counts, as it
only requires one pin.
 Internal data EEPROM up to 4 kB
 Internal SRAM up to 8 kB (32 kB on XMega)
 External 64 kB little endian data space on certain models, including the Mega8515
and Mega162.
 The external data space is overlaid with the internal data space, such that the full
64 kB address space does not appear on the external bus. An accesses to e.g.
address 010016 will access internal RAM, not the external bus.
 In certain members of the XMEGA series, the external data space has been
enhanced to support both SRAM and SDRAM. As well, the data addressing modes
have been expanded to allow up to 16 MB of data memory to be directly
addressed.
 AVR's generally do not support executing code from external memory. Some
ASSP's using the AVR code do support external program memory.
 8-Bit and 16-Bit timers
 PWM output (Dead time generator on some devices)
 Input capture
 Analog comparator
 10 or 12-Bit A/D converters, with multiplex of up to 16 channels
 12-bit D/A converters
 A variety of serial interfaces, including
 I²C compatible Two-Wire Interface (TWI)
 Synchronous/asynchronous serial peripherals (UART/USART) (used with RS-232,
RS-485, and more)
 Serial Peripheral Interface Bus (SPI)
 Universal Serial Interface (USI) for two or three-wire synchronous data transfer
 Brownout detection
 Watchdog timer (WDT)
 Multiple Power-Saving Sleep Modes
 Lighting and motor control (PWM specific) controller models
 CAN controller support
 USB controller support
 Proper full-speed (12 Mbit/s) hardware & Hub controller with embedded AVR.
 Also freely available low-speed (1.5 Mbit/s) (HID) bitbanging software emulations
 Ethernet controller support
 LCD controller support
  Low-voltage devices operating down to 1.8 V (to 0.7 V for parts with built-in DC-
DC upconverter)
 picoPower devices
 DMA controllers and "event system" peripheral communication.
 Fast cryptography support for AES and DES

PART IV
PROJECTS

MOBILE PHONE OPERATED BOT

OVERVIEW:
Today as the mobile phones are become very essential for everyone and has a vital use so to
think about a mobile phone operated robot is an innovative idea. We can operate our robot
from any distant or remote area. It is a wireless robot but instead of using a separate wireless
module (transmitter and receiver) we are using the cell phones for this purpose. This robot
has advantages over simple wireless bot as it overcomes the limitations of wireless like
limited range, frequency interference etc. Mobile operated bot is having a wide range (service
provider range), less fear of interference as every call is having a unique frequency and
moreover it has more control keys (12 keys).The principle used for mobile controlled robot is
the decoding of the DTMF tone. DTMF tone stands for dual-tone multi-frequency tone.
During any call if a button is pressed, a tone corresponding to that button is generated and
heard at the other end of the call. This tone is basically known as DTMF tone and these tones
are standard one, fixed by IEEE, ISO, EIA, ITU etc

CIRCUIT DISCRIPTION
.

WORKING:

The mobile operated robot is having basically five main phases:

1. Make a call to mobile on robot.
2.Sending the signal generated by DTMF encoder in transmitter.
3.Receiving the signal by receiver.
4.Decode the signal with HT9170 decoder IC.
5.Process the decoded signal with on board processor ATmega16.
Firstly make a call from the remote phone to the phone attached to the robot and connect
the receiving mobile phone with headset in auto answer mode. As the call is received, the
connection is established between two. Now if you press a button then the DTMF tone
 generates a signal by adding the frequency corresponding to that button and sends to the
receiver. Receiver detects it and sends it to HT9170 decoder IC which decodes the DTMF
tone and fed the decoded signal to the microcontroller ATmega16 i.e. on board processor.
According to the program in the microcontroller the robot starts moving.

In DTMF the tones and assignments are as follows:

The keys A,B,C,D are not available in the mobile phones as these keys are used to transmit
some secret or confidential data. These keys are basically used in govt. and defense sector.

All type of HT9170 series use digital counting techniques to detect and decode all the 16
DTMF tone pair into 4-bit code output.
 VP and VN are the dual i/p of the op-amp, GS is the output of op-amp. When input signals
given at pin1 and pin2 found to be effective then DV(pin15) becomes high, the correct 4- bit
code of tone is transferred to the output pins D0-D3. The decoded digital data is then negated
using 4 NOR gates of 7404 HEX INVERTER. This inverted input will be given to Port A of
microcontroller. The microcontroller is programmed to give output at Port D,to control the
motor driver. As the microcontroller is not able to drive the motor so a motor driver IC
L293D is used for this purpose.
 PROGRAMING
#define F_CPU 1000000UL // define cpu frequency for delay
function
#include <avr/io.h> // includes input/output header file
#include <util/delay.h> // includes delay header file

int main(void)
{
int DTMF=0; //DTMF variable for mean while checking
DDRC=0xFF; //PORTC as output Port connected to motors
DDRA=0b00000000;//PORTA Input port connected to DTMF decoder
IC
PORTD=0xF0;

while(1) // infinite loop

{
DTMF=PINA;
DTMF=DTMF&0b00001111; //Mask low order 4 bits

if(DTMF==2) //if Key 2 of cell phone pressed

{
PORTC=0b00001001; // move straight
}

if(DTMF==4) // if Key 4 of cell phone pressed

{
PORTC=0b00000001; // turn left
}

if(DTMF==6) // if Key 6 of cell phone pressed

{
PORTC=0b00001000; // turn right
}

if(DTMF==8) // if Key 8 of cell phone pressed

{
PORTC=0b00000110; // move back
}

if(DTMF==5) // if Key * of cell phone pressed

{
PORTC=0b00000000; //stop
}

}//while closed
}//main closed
 LINE FOLLOWER USING L293D
H-BRIDGE IC

INTRODUCTION:
The name line follower itself clear it’s meaning that it is a robot
which traces or follows a specific path .The principle of the line follower is based on
sensing the background surface making use of IR sensor. Basically IR sensor takes
input by detecting the reflection of the IR rays from the surface and accordingly gives
its output to the motors. The output of the sensors are not directly fed to the motors
instead a L293D IC is used in between the sensors output and motors input. The
sensors output is given to the input pin of L293D and the output pin of IC is
connected to the motors. The L293D IC is having two H-bridges which is capable to
rotate motor in bidirectional.

DC GEAR MOTOR:

In our line follower dc gear motors are used.

 WHY DC MOTOR?

 Easy to control
 Require only two signals
 For change the direction of rotation just reverse the polarity
 Speed can be controlled by the voltage

 USE OF GEARS

 To provide enough torque.

 Increases the torque on the expense of speed.
IR SENSORS:
Sensors are basically electronic devices which are used to sense the changes
that occur in their surroundings. The change may be in color, temperature, moisture, sound,
heat etc. They sense the change and work accordingly. In IR sensor the there is emitter and
detector. Emitter emits the IR rays and detector detects it.

The IR sensor basically consists of three components:

 IR LED (emitter)
 Photodiode (detector)
 Op-Amp

IR LED:

Fig. 1

IR LED is a light emitting diode which emits the IR radiations. The basic function of
the emitter is to convert electricity into light. It works on the principle of recombination
of the electron-hole pair. As in the conduction band of a diode, electrons are the
majority carrier and in the valence band, holes are majority carrier. So when an
electron from a conduction band recombines with a hole of valance band, some
amount of energy is released and this energy is in the form of light. The amount of
energy released is depends upon the forbidden energy gap. The IR Led has two
legs, the leg which is longer is positive and other leg is negative.
PHOTODIODE:

Photodiode
PIN Photodiode

Fig. 2

The photodiode is a p-n junction diode which is connected in reverse bias direction.
The basic function of the detector is to convert light into electricity. As its name
implies that it works effectively only when the certain number of photon or certain
amount of light falls on it. When there is no fall of light on the photodiode it has an
infinite resistance and act as a open switch but as the light starts falling on the
photodiode, the resistance become low and when the full intensity of light fall in the
photodiode then its resistance becomes zero and it starts act like a closed switch.

Basically two type of photodiodes:

o PIN type – P stand for p-type semiconductor

 I stand for intrinsic semiconductor.
 N stand for n-type semiconductor.
o Avalanche type

OPAMP:

Op-Amp stands for operational amplifier. It is a DC-coupled high gain amplifier with
differential inputs and single output. Typically the output of the op-amp is controlled by
either negative feedback or positive feedback. Due to the fact that it performs several
operations like addition, subtraction, multiplication, integration etc, it is named as operational
amplifier. It has two inputs, inverted (Pin 2) and non-inverted input (Pin3). The signal which
is applied to the inverted input gives output 180 degree out of phase with input whereas in the
non-inverted input gives output in phase with that of input. Op-amp has a variety of uses in
different electronics devices. In the line follower it is used in the comparator mode. The op-
amp IC which is used here is LM358, which is an 8-pin IC having two inbuilt op-amps. In the
comparator mode, the reference voltage is set at the inverted input pin and then it is compared
with the input at non inverted pin. As the voltages at two input pins of op-amp is compared,
as the voltage at Pin 3 exceeds the reference voltage at Pin 2 the output of the comparator
becomes high (5 V) otherwise it becomes low (0 V). The reference voltage at Pin 2 is set with
the help of variable resistor.

Types of Op-amp:

1) General purpose op-amp.

2) Special purpose op-amp.

Fig 3. Internal block diagram of LM358 IC

Working:

Fig 4. Circuit diagram of IR sensor

We know that the white surface reflects all the radiations falls on it whereas the black color
absorbs them. When the supply is given to IR sensor, LED starts emitting light radiations. If
the surface is of white color then it reflects all the radiations. As these radiations starts falling
on the photodiode which is connected in reverse bias, the resistance of the photodiode starts
decreasing rapidly and the voltage drop across the diode also decreases. The voltage at Pin 3
starts increases, as it reaches just beyond the voltage of Pin 2 the comparator gives high
output. In case of the black surface, LED emits light but it is not reflected by the surface, so
the photodiode detects nothing and its resistance remains infinite. Hence the comparator
gives low output.

 White surface – Comparator output is high.

 Black surface – Comparator output is low

Sensitivity of IR sensor:

The sensitivity of sensor means that how much effectively the sensor senses the change that
is occurring in its surrounding. The sensitivity of the IR sensor is controlled by reference
voltage at pin 2 using variable resistor.

 Large value of reference voltage – less sensitive.

 Small value of reference voltage – more sensitive.

MOTOR DRIVER IC (L293D)

L293D IC is a dual H-bridge motor driver IC. One H-bridge is capable to drive a dc motor in
bidirectional. L293D IC is a current enhancing IC as the output from the sensor is not able to
drive motors itself so L293D is used for this purpose. L293D is a 16 pin IC having two
enables pins which should always be remain high to enable both the H-bridges. L293B is
another IC of L293 series having two main differences with L293D.

Difference between L293D and L293B:

1. L293D can run a motor up to 600 mA whereas L293B can run up to 1 A.

2. L293D has protection diode whereas L293B doesn’t have any such protection diode.
Need to add the protection diode manually.

NOT gates are usually used as buffers in the H-bridge to strengthen the signal and also used
as repeaters.
 Fig 5. Pin diagram of L293D

WORKING MODEL:

PROGRAMING
#define F_CPU 12000000UL // define cpu frequency for delay function

#include <avr/io.h> // includes input/output header file

#include <util/delay.h> // includes delay header file

int main(void)

DDRC=0b11111111; //PORTC as output Port connected to motors

DDRA=0b00000000;//PORTA Input port connected to Sensors

DDRD=0b11111111;//PORTD as output Port connected to motor enable pins

PORTD=0b11110000;

int left_sensor=0, right_sensor=0;

while(1) // infinite loop

left_sensor=PINA&0b00010000; // mask PA4 bit of Port A

right_sensor=PINA&0b00100000;// mask PA5 bit of Port A

if((left_sensor==0b00000000) & (right_sensor==0b00000000)) //if both sensors "off

PORTC=0b00000000; // stop

left_sensor=0; // mask PA4 bit of Port A

right_sensor=0;// mask PA5 bit of Port A

if((left_sensor==0b00010000) & (right_sensor==0b00100000)) //if both sensors "on"

{
 PORTC=0b00001001; // move straight

left_sensor=0; // mask PA4 bit of Port A

right_sensor=0;// mask PA5 bit of Port A

if((left_sensor==0b00000000)&(right_sensor==0b00100000))

PORTC=0b00000001; // turn left

left_sensor=0; // mask PA4 bit of Port A

right_sensor=0;// mask PA5 bit of Port A

if((left_sensor==0b00010000)&(right_sensor==0b00000000))

PORTC=0b00001000; // turn right

left_sensor=0; // mask PA4 bit of Port A

right_sensor=0;// mask PA5 bit of Port A

} right_sensor=0;// mask PA5 bit of Port A

}}//while closed

} //main close