PROJECT TRAINING In

EMBEDDED SYSTEM & ROBOTICS WITH “C ”

at

ROBOSAPIENSINDIA

Submitted for partial fulfillment of award of

BACHELOR OF TECHNOLOGY degree 

 InELECTRONICS AND COMMUNICATION

ENGINEERING

Submitted By

ANUJ CHOUDHARY (0708210017)

MORADABAD INSTITUTE OF TECHNOLOGY, MORADABAD, INDIA

JULY, 2010

ACKNOWLEDGEMENTThis 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 systemsA.II Embedded systems span all aspects of modern life and there are

many examples of their useB. HISTORYC. CHARACTERISTICSD. USER INTERFACES

D.I Simple systemsD.II In more complex systemsD.III CPU platformsD.IV Ready made computer boardsD.V ASIC and FPGA solutions

E. PERIPHERALSF. TOOLSG. DEBUGGING

H. RELIABILITYI. EMBEDDED SOFTWARE ARCHITECTURES

I.I Simple control loopI.II Interrupt controlled systemI.III Cooperative multitaskingI.IV Preemptive multitasking or multi-threadingI.V Microkernels and exokernelsI.VI Monolithic kernels

I.VII Exotic custom operating systemsI.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 OverviewA.II Circuit DescriptionA.III WorkingA.IV Programing

B. LINE FOLLOWER USING L293D H-BRIDGE ICB.I IntroductionB.II Dc Gear Motor B.III IR SensorsB.IV IR LEDB.V PhotodiodeB.VI OP-ampB.VII WorkingB.VIII Sensitivity of IR SensorsB.IX Motor Driver IC (L293D)

B.X Working ModelB.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

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

Picture of the internals of a Netgear ADSL modem/router.

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

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.I EXAMPLES 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

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.

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

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 :

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

Soekris net4801, an embedded system targeted at network applications.

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.IIIThe 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

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

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

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 MicrocontrollerThe 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 memoryo 6–32-pin packageo Limited peripheral set

megaAVR — the ATmega series o 4–256 kB program memoryo 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 memoryo 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 (000016-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 (100016-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

ICPORTD=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