INTRODUCTION

The objective of this project is to build a Pick and place Robot that can be controlled by
gesture wirelessly. User is able to control motions of the tank by wearing the controller glove
and performing predefined gestures. This tank can detect block objects and stop
automatically; in addition, feedback messages are sent to the controller and warn the user by
a vibration motor. This project provides a basic platform for many potential applications such
as wireless controlled car racing games, gesture human-machine interfacing, and etc.
For this project, NXP 89V51RD2 microcontroller and gyro scope are employed for the
controller; NXP 89V51RD2, H-bridge are employed for the controlled tank. A pair of
wireless UART module, Wi.232, is used to communicate between the controller and tank.
However, the hardware is also ready for Bluetooth wireless protocol.
As the name implies “Wireless Gesture controlled Pick and Place Robot ” we
use a simple Android Cell phone as controller for Device. We, here use a low cost 8-bit
microcontroller and a pre-defined key which is burnt in the microcontroller. In the receiver
section we use an Bluetooth Receiver attached to the controller. The controller checks the
output of Bluetooth receiver and compares it with pre stored key. If it matches, the controller
switches on the relay and in turn controls the robot movement through a motor connected to
it. Here we just use a display unit to find the values returned by the Android Mobile for each
Movement.

As we rotate the mobile the accelerometer inside it will return different values which
will be passed to the Receiver section through Bluetooth Transceivers. For each different
movement a different action will be initiated at the receiver’s side.

HARDWARE:
 Power Supply : 5v DC
 Micro controller : AT89S52
 LCD : 16x2 characters
 RS 232 converter : MAX 232
 Temperature sensor
 Keil C m-vision.
 Motors

SOFTWARE:
  Embedded C

 Keil m-vision

 Android

 Flash Magic Burner Software

Applications:

1. Military and aerospace embedded software applications

2. Communication Applications

3. Industrial automation and process control software.

4. Home Automation

5. Medical & Industry Applications

Advantages:

1. Android is free OS

2. Platform independent

3. Low Cost

4. High end Security Can be achieved

BLOCK DIAGRAM
 Receiver:

Micro
Bluetooth Controller
(Transceiv
er) Relay Motor
Circuit

Power
Receiver
Supply Unit Relay Motor
Circuit

Relay Motor
Circuit

Relay Motor
Circuit
 AT89S52

Features
• Compatible with MCS-51® Products
• 8K Bytes of In-System Programmable (ISP) Flash Memory
– Endurance: 1000 Write/Erase Cycles
• 4.0V to 5.5V Operating Range
• Fully Static Operation: 0 Hz to 33 MHz
• Three-level Program Memory Lock
• 256 x 8-bit Internal RAM
• 32 Programmable I/O Lines
• Three 16-bit Timer/Counters
• Eight Interrupt Sources
• Full Duplex UART Serial Channel
• Low-power Idle and Power-down Modes
• Interrupt Recovery from Power-down Mode
• Watchdog Timer
• Dual Data Pointer
• Power-off Flag

Description

The AT89S52 is a low-power, high-performance CMOS 8-bit microcontroller with 8K bytes

of in-system programmable Flash memory. The device is manufactured using Atmel’s high-
density nonvolatile memory technology and is compatible with the indus-try-standard 80C51
instruction set and pinout. The on-chip Flash allows the program memory to be
reprogrammed in-system or by a conventional nonvolatile memory pro-grammer. By
combining a versatile 8-bit CPU with in-system programmable Flash on a monolithic chip,
the Atmel AT89S52 is a powerful microcontroller which provides a highly-flexible and cost-
effective solution to many embedded control applications.
The AT89S52 provides the following standard features: 8K bytes of Flash, 256 bytes of
RAM, 32 I/O lines, Watchdog timer, two data pointers, three 16-bit timer/counters, a six-
vector two-level interrupt architecture, a full duplex serial port, on-chip oscillator, and clock
circuitry. In addition, the AT89S52 is designed with static logic for operation down to zero
frequency and supports two software selectable power saving modes. The Idle Mode stops
the CPU while allowing the RAM, timer/counters, serial port, and interrupt system to
continue functioning. The Power-down mode saves the RAM con-tents but freezes the
oscillator, disabling all other chip functions until the next interrupt or hardware reset.
PIN CONFIGURATION
BLOCK DIAGRAM
Pin Description

VCC
Supply voltage.
GND
Ground.
Port 0
Port 0 is an 8-bit open drain bidirectional I/O port. As an output port, each pin can sink eight
TTL inputs. When 1s are written to port 0 pins, the pins can be used as high-impedance
inputs.
Port 0 can also be configured to be the multiplexed low-order address/data bus during
accesses to external program and data memory. In this mode, P0 has internal pullups.
Port 0 also receives the code bytes during Flash program-ming and outputs the code bytes
during program verification. External pull-ups are required during program verification.
Port 1
Port 1 is an 8-bit bidirectional I/O port with internal pullups. The Port 1 output buffers can
sink/source four TTL inputs. When 1s are written to Port 1 pins, they are pulled high by the
internal pullups and can be used as inputs. As inputs, Port 1 pins that are externally being
pulled low will source current (IIL) because of the internal pullups.
In addition, P1.0 and P1.1 can be configured to be the timer/counter 2 external count input
(P1.0/T2) and the timer/counter 2 trigger input (P1.1/T2EX), respectively, as shown in the
following table.
Port 1 also receives the low-order address bytes during Flash programming and verification.

Port Pin Alternate Functions

P1.0 T2 (external count input to Timer/Counter 2),
clock-out
P1.1 T2EX (Timer/Counter 2 capture/reload trigger
and direction control)
P1.5 MOSI (used for In-System Programming)
P1.6 MISO (used for In-System Programming)
P1.7 SCK (used for In-System Programming)

Port 2
Port 2 is an 8-bit bidirectional I/O port with internal pullups. The Port 2 output buffers can
sink/source four TTL inputs. When 1s are written to Port 2 pins, they are pulled high by the
internal pullups and can be used as inputs. As inputs, Port 2 pins that are externally being
pulled low will source current (IIL) because of the internal pullups.
Port 2 emits the high-order address byte during fetches from external program memory and
during accesses to external data memory that use 16-bit addresses (MOVX @ DPTR). In this
application, Port 2 uses strong internal pul-lups when emitting 1s. During accesses to external
data memory that use 8-bit addresses (MOVX @ RI), Port 2 emits the contents of the P2
Special Function Register.
Port 2 also receives the high-order address bits and some control signals during Flash
programming and verification.
Port 3
Port 3 is an 8-bit bidirectional I/O port with internal pullups. The Port 3 output buffers can
sink/source four TTL inputs. When 1s are written to Port 3 pins, they are pulled high by the
internal pullups and can be used as inputs. As inputs, Port 3 pins that are externally being
pulled low will source current (IIL) because of the pullups.
Port 3 also serves the functions of various special features of the AT89S52, as shown in the
following table.
Port 3 also receives some control signals for Flash pro-gramming and verification.

Port Pin Alternate Functions

P3.0 RXD (serial input port)

P3.1 TXD (serial output port)

P3.2 INT0 (external interrupt 0)

P3.3 INT1 (external interrupt 1)

P3.4 T0 (timer 0 external input)

P3.5 T1 (timer 1 external input)

P3.6 WR (external data memory write strobe)

P3.7 RD (external data memory read strobe)

RST
Reset input. A high on this pin for two machine cycles while the oscillator is running resets
the device. This pin drives High for 96 oscillator periods after the Watchdog times out. The
DISRTO bit in SFR AUXR (address 8EH) can be used to disable this feature. In the default
state of bit DISRTO, the RESET HIGH out feature is enabled

ALE/PROG
Address Latch Enable (ALE) is an output pulse for latching the low byte of the address
during accesses to external memory. This pin is also the program pulse input (PROG) during
Flash programming.
In normal operation, ALE is emitted at a constant rate of 1/6 the oscillator frequency and may
be used for external timing or clocking purposes. Note, however, that one ALE pulse is
skipped during each access to external data memory.
If desired, ALE operation can be disabled by setting bit 0 of SFR location 8EH. With the bit
set, ALE is active only dur-ing a MOVX or MOVC instruction. Otherwise, the pin is weakly
pulled high. Setting the ALE-disable bit has no effect if the microcontroller is in external
execution mode.
PSEN
Program Store Enable (PSEN) is the read strobe to exter-nal program memory.
When the AT89S52 is executing code from external pro-
gram memory, PSEN is activated twice each machine cycle, except that two PSEN
activations are skipped during each access to external data memory.
EA/VPP
External Access Enable. EA must be strapped to GND in order to enable the device to fetch
code from external pro-gram memory locations starting at 0000H up to FFFFH. Note,
however, that if lock bit 1 is programmed, EA will be internally latched on reset.
EA should be strapped to VCC for internal program execu-tions.
This pin also receives the 12-volt programming enable volt-age (V PP) during Flash
programming.

XTAL1
Input to the inverting oscillator amplifier and input to the internal clock operating circuit.
XTAL2
Output from the inverting oscillator amplifier

0F8H 0FFH

B
0F0H 0F7H
00000000

0E8H 0EFH

ACC
0E0H 0E7H
00000000

0D8H 0DFH

PSW
0D0H 0D7H
00000000
T2CON T2MOD RCAP2L RCAP2H TL2 TH2
0C8H 0CFH
00000000 XXXXXX00 00000000 00000000 00000000 00000000

0C0H 0C7H

IP
0B8H 0BFH
XX000000
P3
0B0H 0B7H
11111111
IE
0A8H 0AFH
0X000000

P2 AUXR1 WDTRST
0A0H 0A7H
11111111 XXXXXXX0 XXXXXXXX
SCON SBUF
98H 9FH
00000000 XXXXXXXX
P1
90H 97H
11111111
 TCON TMOD TL0 TL1 TH0 TH1 AUXR
88H 8FH
00000000 00000000 00000000 00000000 00000000 00000000 XXX00XX0
P0 SP DP0L DP0H DP1L DP1H PCON
80H 87H
11111111 00000111 00000000 00000000 00000000 00000000 0XXX0000

Special Function Registers

A map of the on-chip memory area called the Special Func-tion Register (SFR) space is
shown in Table 1.
Note that not all of the addresses are occupied, and unoc-cupied addresses may not be
implemented on the chip. Read accesses to these addresses will in general return random
data, and write accesses will have an indetermi-nate effect.
User software should not write 1s to these unlisted loca-tions, since they may be used in
future products to invoke new features. In that case, the reset or inactive values of the new
bits will always be 0.

Timer 2 Registers:

Control and status bits are contained in registers T2CON (shown in Table 2) and T2MOD
(shown in Table 3) for Timer 2. The register pair (RCAP2H, RCAP2L) are the
Capture/Reload registers for Timer 2 in 16-bit cap-ture mode or 16-bit auto-reload mode.

Interrupt Registers:

The individual interrupt enable bits are in the IE register. Two priorities can be set for each
of the six interrupt sources in the IP register.

Memory Organization

MCS-51 devices have a separate address space for Pro-gram and Data Memory. Up to 64K
bytes each of external Program and Data Memory can be addressed.

Program Memory

If the EA pin is connected to GND, all program fetches are directed to external memory.
On the AT89S52, if EA is connected to V CC, program fetches to addresses 0000H through
1FFFH are directed to internal memory and fetches to addresses 2000H through FFFFH are
to external memory.

Data Memory

The AT89S52 implements 256 bytes of on-chip RAM. The upper 128 bytes occupy a parallel
address space to the Special Function Registers. This means that the upper 128 bytes have the
same addresses as the SFR space but are physically separate from SFR space.

When an instruction accesses an internal location above address 7FH, the address mode used
in the instruction specifies whether the CPU accesses the upper 128 bytes of RAM or the SFR
space. Instructions which use direct addressing access of the SFR space.
For example, the following direct addressing instruction accesses the SFR at location 0A0H
(which is P2).
MOV 0A0H, #data
Instructions that use indirect addressing access the upper 128 bytes of RAM. For example,
the following indirect addressing instruction, where R0 contains 0A0H, accesses the data byte
at address 0A0H, rather than P2 (whose address is 0A0H).
MOV @R0, #data
Note that stack operations are examples of indirect addressing, so the upper 128 bytes of data
RAM are avail-able as stack space.

Watchdog Timer
(One-time Enabled with Reset-out)

The WDT is intended as a recovery method in situations where the CPU may be subjected to
software upsets. The WDT consists of a 13-bit counter and the Watchdog Timer Reset
(WDTRST) SFR. The WDT is defaulted to disable from exiting reset. To enable the WDT, a
user must write 01EH and 0E1H in sequence to the WDTRST register (SFR location 0A6H).
When the WDT is enabled, it will increment every machine cycle while the oscillator is run-
ning. The WDT timeout period is dependent on the external clock frequency. There is no way
to disable the WDT except through reset (either hardware reset or WDT over-flow reset).
When WDT overflows, it will drive an output RESET HIGH pulse at the RST pin.

Using the WDT

To enable the WDT, a user must write 01EH and 0E1H in sequence to the WDTRST register
(SFR location 0A6H). When the WDT is enabled, the user needs to service it by writing
01EH and 0E1H to WDTRST to avoid a WDT over-flow. The 13-bit counter overflows when
it reaches 8191 (1FFFH), and this will reset the device. When the WDT is enabled, it will
increment every machine cycle while the oscillator is running. This means the user must reset
the WDT at least every 8191 machine cycles. To reset the WDT the user must write 01EH
and 0E1H to WDTRST. WDTRST is a write-only register. The WDT counter cannot be read
or written. When WDT overflows, it will generate an output RESET pulse at the RST pin.
The RESET pulse duration is 96xTOSC, where TOSC=1/FOSC. To make the best use of the
WDT, it should be serviced in those sec-tions of code that will periodically be executed
within the time required to prevent a WDT reset.

WDT During Power-down and Idle

In Power-down mode the oscillator stops, which means the WDT also stops. While in Power-
down mode, the user does not need to service the WDT. There are two methods of exiting
Power-down mode: by a hardware reset or via a level-activated external interrupt which is
enabled prior to entering Power-down mode. When Power-down is exited with hardware
reset, servicing the WDT should occur as it normally does whenever the AT89S52 is reset.
Exiting Power-down with an interrupt is significantly different. The interrupt is held low long
enough for the oscillator to stabi-lize. When the interrupt is brought high, the interrupt is
serviced. To prevent the WDT from resetting the device while the interrupt pin is held low,
the WDT is not started until the interrupt is pulled high. It is suggested that the WDT be reset
during the interrupt service for the interrupt used to exit Power-down mode.

To ensure that the WDT does not overflow within a few states of exiting Power-down, it is
best to reset the WDT just before entering Power-down mode.
Before going into the IDLE mode, the WDIDLE bit in SFR AUXR is used to determine
whether the WDT continues to count if enabled. The WDT keeps counting during IDLE
(WDIDLE bit = 0) as the default state. To prevent the WDT from resetting the AT89S52
while in IDLE mode, the user should always set up a timer that will periodically exit IDLE,
service the WDT, and reenter IDLE mode.
With WDIDLE bit enabled, the WDT will stop to count in IDLE mode and resumes the
count upon exit from IDLE.

UART

The UART in the AT89S52 operates the same way as the UART in the AT89C51 and
AT89C52. For further informa-tion on the UART operation, refer to the ATMEL Web site
(http://www.atmel.com). From the home page, select ‘Prod-ucts’, then ‘8051-Architecture
Flash Microcontroller’, then ‘Product Overview’.

Timer 0 and 1

Timer 0 and Timer 1 in the AT89S52 operate the same way as Timer 0 and Timer 1 in the
AT89C51 and AT89C52. For further information on the timers’ operation, refer to the
ATMEL Web site (http://www.atmel.com). From the home page, select ‘Products’, then
‘8051-Architecture Flash Microcontroller’, then ‘Product Overview’.

Timer 2

Timer 2 is a 16-bit Timer/Counter that can operate as either a timer or an event counter. The
type of operation is selected by bit C/T2 in the SFR T2CON (shown in Table 2). Timer 2 has
three operating modes: capture, auto-reload (up or down counting), and baud rate generator.
The modes are selected by bits in T2CON, as shown in Table 3. Timer 2 consists of two 8-bit
registers, TH2 and TL2. In the Timer function, the TL2 register is incremented every
machine cycle. Since a machine cycle consists of 12 oscil-lator periods, the count rate is 1/12
of the oscillator frequency.

RCLK
+TCLK CP/RL2 TR2 MODE
0 0 1 16-bit Auto-reload
0 1 1 16-bit Capture
1 X 1 Baud Rate Generator
X X 0 (Off)

In the Counter function, the register is incremented in response to a 1-to-0 transition at its
corresponding external input pin, T2. In this function, the external input is sampled during
S5P2 of every machine cycle. When the samples show a high in one cycle and a low in the
next cycle, the count is incremented. The new count value appears in the register during S3P1
of the cycle following the one in which the transition was detected. Since two machine cycles
(24 oscillator periods) are required to recognize a 1-to-0 transi-tion, the maximum count rate
is 1/24 of the oscillator fre-quency. To ensure that a given level is sampled at least once
before it changes, the level should be held for at least one full machine cycle.

Capture Mode

In the capture mode, two options are selected by bit EXEN2 in T2CON. If EXEN2 = 0,
Timer 2 is a 16-bit timer or counter which upon overflow sets bit TF2 in T2CON.

This bit can then be used to generate an interrupt. If EXEN2 = 1, Timer 2 performs the same
operation, but a 1-to-0 transition at external input T2EX also causes the current value in TH2
and TL2 to be captured into RCAP2H and RCAP2L, respectively. In addition, the transition
at T2EX causes bit EXF2 in T2CON to be set. The EXF2 bit, like TF2, can generate an
interrupt.

Auto-reload (Up or Down Counter)

Timer 2 can be programmed to count up or down when configured in its 16-bit auto-reload
mode. This feature is invoked by the DCEN (Down Counter Enable) bit located in the SFR
T2MOD (see Table 4). Upon reset, the DCEN bit is set to 0 so that timer 2 will default to
count up. When DCEN is set, Timer 2 can count up or down, depending on the value of the
T2EX pin.

Baud Rate Generator

Timer 2 is selected as the baud rate generator by setting TCLK and/or RCLK in T2CON
(Table 2). Note that the baud rates for transmit and receive can be different if Timer 2 is used
for the receiver or transmitter and Timer 1 is used for the other function. Setting RCLK
and/or TCLK puts Timer 2 into its baud rate generator mode, as shown in Fig-ure 8.
The baud rate generator mode is similar to the auto-reload mode, in that a rollover in TH2
causes the Timer 2 registers to be reloaded with the 16-bit value in registers RCAP2H and
RCAP2L, which are preset by software.
The baud rates in Modes 1 and 3 are determined by Timer 2’s overflow rate according to the
following equation.

Timer 2 Overflow Rate

Modes 1 and 3 Baud Rates = -----------------------------------------------------------
 16

The Timer can be configured for either timer or counter operation. In most applications, it is
configured for timer operation (CP/T2 = 0). The timer operation is different for Timer 2 when
it is used as a baud rate generator. Normally, as a timer, it increments every machine cycle (at
1/12 the oscillator frequency). As a baud rate generator, however, it increments every state
time (at 1/2 the oscillator frequency). The baud rate formula is given below.

Modes
---------------------- --------------------------------------------------
----------------1and3- = -----------------------------------OscillatorFrequency
32 x [65536-
Baud Rate RCAP2H,RCAP2L)]

where (RCAP2H, RCAP2L) is the content of RCAP2H and RCAP2L taken as a 16-bit
unsigned integer.
Timer 2 as a baud rate generator is shown in Figure 8. This figure is valid only if RCLK or
TCLK = 1 in T2CON. Note that a rollover in TH2 does not set TF2 and will not gener-ate an
interrupt. Note too, that if EXEN2 is set, a 1-to-0 transition in T2EX will set EXF2 but will
not cause a reload from (RCAP2H, RCAP2L) to (TH2, TL2). Thus, when Timer 2 is in use
as a baud rate generator, T2EX can be used as an extra external interrupt.
Note that when Timer 2 is running (TR2 = 1) as a timer in the baud rate generator mode, TH2
or TL2 should not be read from or written to. Under these conditions, the Timer is
incremented every state time, and the results of a read or write may not be accurate. The
RCAP2 registers may be read but should not be written to, because a write might overlap a
reload and cause write and/or reload errors. The timer should be turned off (clear TR2)
before accessing the Timer 2 or RCAP2 registers.

Interrupts

The AT89S52 has a total of six interrupt vectors: two exter-nal interrupts (INT0 and INT1),
three timer interrupts (Tim-ers 0, 1, and 2), and the serial port interrupt. These interrupts are
all shown in Figure 10.
Each of these interrupt sources can be individually enabled or disabled by setting or clearing
a bit in Special Function Register IE. IE also contains a global disable bit, EA, which disables
all interrupts at once.
Note that Table 5 shows that bit position IE.6 is unimple-mented. In the AT89S52, bit
position IE.5 is also unimple-mented. User software should not write 1s to these bit positions,
since they may be used in future AT89 products.
Timer 2 interrupt is generated by the logical OR of bits TF2 and EXF2 in register T2CON.
Neither of these flags is cleared by hardware when the service routine is vectored to. In fact,
the service routine may have to determine whether it was TF2 or EXF2 that generated the
interrupt, and that bit will have to be cleared in software.
The Timer 0 and Timer 1 flags, TF0 and TF1, are set at S5P2 of the cycle in which the timers
overflow. The values are then polled by the circuitry in the next cycle. However, the Timer 2
flag, TF2, is set at S2P2 and is polled in the same cycle in which the timer overflows.
Oscillator Characteristics

XTAL1 and XTAL2 are the input and output, respectively, of an inverting amplifier that can
be configured for use as an on-chip oscillator, as shown in Figure 11. Either a quartz crystal
or ceramic resonator may be used. To drive the device from an external clock source, XTAL2
should be left unconnected while XTAL1 is driven, as shown in Figure 12. There are no
requirements on the duty cycle of the external clock signal, since the input to the internal
clocking circuitry is through a divide-by-two flip-flop, but minimum and maxi-mum voltage
high and low time specifications must be observed.

Idle Mode

In idle mode, the CPU puts itself to sleep while all the on-chip peripherals remain active. The
mode is invoked by software. The content of the on-chip RAM and all the spe-cial functions
registers remain unchanged during this mode. The idle mode can be terminated by any
enabled interrupt or by a hardware reset.
Note that when idle mode is terminated by a hardware reset, the device normally resumes
program execution from where it left off, up to two machine cycles before the internal reset
algorithm takes control. On-chip hardware inhibits access to internal RAM in this event, but
access to the port pins is not inhibited. To eliminate the possibility of an unexpected write to
a port pin when idle mode is termi-nated by a reset, the instruction following the one that
invokes idle mode should not write to a port pin or to exter-nal memory.

Power-down Mode

In the Power-down mode, the oscillator is stopped, and the instruction that invokes Power-
down is the last instruction executed. The on-chip RAM and Special Function Regis-ters
retain their values until the Power-down mode is termi-nated. Exit from Power-down mode
can be initiated either by a hardware reset or by an enabled external interrupt. Reset redefines
the SFRs but does not change the on-chip RAM. The reset should not be activated before V CC
is restored to its normal operating level and must be held active long enough to allow the
oscillator to restart and stabilize.

BLUETOOTH

Bluetooth is a wireless technology standard for exchanging data over short distances (using
short-wavelength radio transmissions in the ISM band from 2400–2480 MHz) from fixed and
mobile devices, creating personal area networks (PANs) with high levels of security. Created
by telecom vendor Ericsson in 1994, it was originally conceived as a wireless alternative to
RS-232 data cables. It can connect several devices, overcoming problems of synchronization.

Bluetooth is managed by the Bluetooth Special Interest Group, which has more than 18,000
member companies in the areas of telecommunication, computing, networking, and consumer
electronics.Bluetooth was standardized as IEEE 802.15.1, but the standard is no longer
maintained. The SIG oversees the development of the specification, manages the
qualification program, and protects the trademarks must be qualified.
Name and logo

The word "Bluetooth" is an anglicized version of the Scandinavian Blåtand/Blåtann, the

epithet of the tenth-century king Harald I of Denmark and parts of Norway who united
dissonant Danish tribes into a single kingdom. The idea of this name was proposed by Jim
Kardach who developed a system that would allow mobile phones to communicate with
computers (at the time he was reading Frans Gunnar Bengtsson's historical novel The Long
Ships about Vikings and king Harald Bluetooth).The implication is that Bluetooth does the
same with communications protocols, uniting them into one universal standard.

The Bluetooth logo is a bind rune merging the Younger Futhark runes (Hagall) (ᚼ) and
(Bjarkan) (ᛒ), Harald's initials.

Implementation

Bluetooth operates in the range of 2400–2483.5 MHz (including guard bands). This is in the
globally unlicensed Industrial, Scientific and Medical (ISM) 2.4 GHz short-range radio
frequency band. Bluetooth uses a radio technology called frequency-hopping spread
spectrum. The transmitted data is divided into packets and each packet is transmitted on one
of the 79 designated Bluetooth channels. Each channel has a bandwidth of 1 MHz. The first
channel starts at 2402 MHz and continues up to 2480 MHz in 1 MHz steps. It usually
performs 1600 hops per second, with Adaptive Frequency-Hopping (AFH) enabled.

Originally Gaussian frequency-shift keying (GFSK) modulation was the only modulation
scheme available; subsequently, since the introduction of Bluetooth 2.0+EDR, π/4-DQPSK
and 8DPSK modulation may also be used between compatible devices. Devices functioning
with GFSK are said to be operating in basic rate (BR) mode where an instantaneous data rate
of 1 Mbit/s is possible. The term Enhanced Data Rate (EDR) is used to describe π/4-DPSK
and 8DPSK schemes, each giving 2 and 3 Mbit/s respectively. The combination of these (BR
and EDR) modes in Bluetooth radio technology is classified as a "BR/EDR radio".

Bluetooth is a packet-based protocol with a master-slave structure. One master may

communicate with up to 7 slaves in a piconet; all devices share the master's clock. Packet
exchange is based on the basic clock, defined by the master, which ticks at 312.5 µs intervals.
Two clock ticks make up a slot of 625 µs; two slots make up a slot pair of 1250 µs. In the
simple case of single-slot packets the master transmits in even slots and receives in odd slots;
the slave, conversely, receives in even slots and transmits in odd slots. Packets may be 1, 3 or
5 slots long but in all cases the master transmit will begin in even slots and the slave transmit
in odd slots.

Bluetooth provides a secure way to connect and exchange information between devices such
as faxes, mobile phones, telephones, laptops, personal computers, printers, Global Positioning
System (GPS) receivers, digital cameras, and video game consoles. It was principally
designed as a low-bandwidth technology.

Communication and connection

A master Bluetooth device can communicate with a maximum of seven devices in a piconet
(an ad-hoc computer network using Bluetooth technology), though not all devices reach this
maximum. The devices can switch roles, by agreement, and the slave can become the master
(for example, a headset initiating a connection to a phone will necessarily begin as master, as
initiator of the connection; but may subsequently prefer to be slave).

The Bluetooth Core Specification provides for the connection of two or more piconets to
form a scatternet, in which certain devices simultaneously play the master role in one piconet
and the slave role in another.

At any given time, data can be transferred between the master and one other device (except
for the little-used broadcast mode. The master chooses which slave device to address;
typically, it switches rapidly from one device to another in a round-robin fashion. Since it is
the master that chooses which slave to address, whereas a slave is (in theory) supposed to
listen in each receive slot, being a master is a lighter burden than being a slave. Being a
master of seven slaves is possible; being a slave of more than one master is difficult. The
specification is vague as to required behavior in scatternets.

Many USB Bluetooth adapters or "dongles" are available, some of which also include an
IrDA adapter. Older (pre-2003) Bluetooth dongles, however, have limited capabilities,
offering only the Bluetooth Enumerator and a less-powerful Bluetooth Radio incarnation.
Such devices can link computers with Bluetooth with a distance of 100 meters, but they do
not offer as many services as modern adapters do.

Uses

Bluetooth is a standard wire-replacement communications protocol primarily designed for

low power consumption, with a short range (power-class-dependent, but effective ranges vary
in practice; see table below) based on low-cost transceiver microchips in each device.Because
the devices use a radio (broadcast) communications system, they do not have to be in visual
line of sight of each other, however a quasi optical wireless path must be viable.

The effective range varies due to propagation conditions, material coverage, production
sample variations, antenna configurations and battery conditions. In most cases the effective
range of Class 2 devices is extended if they connect to a Class 1 transceiver, compared to a
pure Class 2 network. This is accomplished by the higher sensitivity and transmission power
of Class 1 devices.

While the Bluetooth Core Specification does mandate minima for range, the range of the
technology is application specific and is not limited. Manufacturers may tune their
implementations to the range needed for individual use cases.

Bluetooth profiles
Main article: Bluetooth profile

To use Bluetooth wireless technology, a device has to be able to interpret certain Bluetooth
profiles, which are definitions of possible applications and specify general behaviors that
Bluetooth enabled devices use to communicate with other Bluetooth devices. These profiles
include settings to parametrize and to control the communication from start. Adherence to
profiles saves the time for transmitting the parameters anew before the bi-directional link
becomes effective. There are a wide range of Bluetooth profiles that describe many different
types of applications or use cases for devices.

A typical Bluetooth mobile phone headset.

 Wireless control of and communication between a mobile phone and a handsfree

headset. This was one of the earliest applications to become popular.
 Wireless control of and communication between a mobile phone and a Bluetooth
compatible car stereo system
 Wireless Bluetooth headset and Intercom.
 Wireless networking between PCs in a confined space and where little bandwidth is
required.
 Wireless communication with PC input and output devices, the most common being
the mouse, keyboard and printer.
 Transfer of files, contact details, calendar appointments, and reminders between
devices with OBEX.
 Replacement of previous wired RS-232 serial communications in test equipment, GPS
receivers, medical equipment, bar code scanners, and traffic control devices.
 For controls where infrared was often used.
 For low bandwidth applications where higher USB bandwidth is not required and
cable-free connection desired.
 Sending small advertisements from Bluetooth-enabled advertising hoardings to other,
discoverable, Bluetooth devices.
 Wireless bridge between two Industrial Ethernet (e.g., PROFINET) networks.
  Three seventh and eighth generation game consoles, Nintendo's Wii and Sony's
PlayStation 3, PSP Go and PS Vita, use Bluetooth for their respective wireless
controllers.
 Dial-up internet access on personal computers or PDAs using a data-capable mobile
phone as a wireless modem.
 Short range transmission of health sensor data from medical devices to mobile phone,
set-top box or dedicated telehealth devices.
 Allowing a DECT phone to ring and answer calls on behalf of a nearby mobile phone
 Real-time location systems (RTLS), are used to track and identify the location of
objects in real-time using “Nodes” or “tags” attached to, or embedded in the objects
tracked, and “Readers” that receive and process the wireless signals from these tags to
determine their locations
 Personal security application on mobile phones for prevention of theft or loss of
items. The protected item has a Bluetooth marker (e.g. a tag) that is in constant
communication with the phone. If the connection is broken (the marker is out of range
of the phone) then an alarm is raised. This can also be used as a man overboard alarm.
A product using this technology has been available since 2009.
 Calgary, Alberta, Canada's Roads Traffic division uses data collected from travelers'
Bluetooth devices to predict travel times and road congestion for motorists.

Bluetooth vs. Wi-Fi (IEEE 802.11)

Bluetooth and Wi-Fi (the brand name for products using IEEE 802.11 standards) have some
similar applications: setting up networks, printing, or transferring files. Wi-Fi is intended as a
replacement for cabling for general local area network access in work areas. This category of
applications is sometimes called wireless local area networks (WLAN). Bluetooth was
intended for portable equipment and its applications. The category of applications is outlined
as the wireless personal area network (WPAN). Bluetooth is a replacement for cabling in a
variety of personally carried applications in any setting and also works for fixed location
applications such as smart energy functionality in the home (thermostats, etc.).

Wi-Fi is a wireless version of a common wired Ethernet network, and requires configuration
to set up shared resources, transmit files, and to set up audio links (for example, headsets and
hands-free devices). Wi-Fi uses the same radio frequencies as Bluetooth, but with higher
power, resulting in higher bit rates and better range from the base station.

Devices
A Bluetooth USB dongle with a 100 m range.

Bluetooth exists in many products, such as telephones, tablets, media players, Lego
Mindstorms NXT, PlayStation 3, PS Vita, the Nintendo Wii, and some high definition
headsets, modems, and watches. The technology is useful when transferring information
between two or more devices that are near each other in low-bandwidth situations. Bluetooth
is commonly used to transfer sound data with telephones (i.e., with a Bluetooth headset) or
byte data with hand-held computers (transferring files).

Bluetooth protocols simplify the discovery and setup of services between devices.Bluetooth
devices can advertise all of the services they provide. [21] This makes using services easier
because more of the security, network address and permission configuration can be
automated than with many other network types.[20]

Computer requirements

A typical Bluetooth USB dongle.

An internal notebook Bluetooth card (14×36×4 mm).

A personal computer that does not have embedded Bluetooth can be used with a Bluetooth
adapter that will enable the PC to communicate with other Bluetooth devices (such as mobile
phones, mice and keyboards). While some desktop computers and most recent laptops come
with a built-in Bluetooth radio, others will require an external one in the form of a dongle.

Unlike its predecessor, IrDA, which requires a separate adapter for each device, Bluetooth
allows multiple devices to communicate with a computer over a single adapter.

Operating system implementation

For more details on this topic, see Bluetooth stack.

Apple products have worked with Bluetooth since Mac OS X v10.2 which was released in
2002.

For Microsoft platforms, Windows XP Service Pack 2 and SP3 releases work natively with
Bluetooth 1.1, 2.0 and 2.0+EDR.[23] Previous versions required users to install their Bluetooth
adapter's own drivers, which were not directly supported by Microsoft. [24] Microsoft's own
Bluetooth dongles (packaged with their Bluetooth computer devices) have no external drivers
and thus require at least Windows XP Service Pack 2. Windows Vista RTM/SP1 with the
Feature Pack for Wireless or Windows Vista SP2 work with Bluetooth 2.1+EDR. Windows 7
works with Bluetooth 2.1+EDR and Extended Inquiry Response (EIR).

The Windows XP and Windows Vista/Windows 7 Bluetooth stacks support the following
Bluetooth profiles natively: PAN, SPP, DUN, HID, HCRP. The Windows XP stack can be
replaced by a third party stack which may support more profiles or newer versions of
Bluetooth. The Windows Vista/Windows 7 Bluetooth stack supports vendor-supplied
additional profiles without requiring the Microsoft stack to be replaced.

Linux has two popular Bluetooth stacks, BlueZ and Affix. The BlueZ stack is included with
most Linux kernels and was originally developed by Qualcomm. The Affix stack was
developed by Nokia. FreeBSD features Bluetooth since its 5.0 release. NetBSD features
Bluetooth since its 4.0 release. Its Bluetooth stack has been ported to OpenBSD as well.

Mobile phone requirements

A Bluetooth-enabled mobile phone is able to pair with many devices. To ensure the broadest
feature functionality together with compatibility with legacy devices, the Open Mobile
Terminal Platform (OMTP) forum has published a recommendations paper, entitled
"Bluetooth Local Connectivity".

Specifications and features

The Bluetooth specification was developed as a cable replacement in 1994 by Jaap Haartsen
and Sven Mattisson, who were working for Ericsson in Lund, Sweden. The specification is
based on frequency-hopping spread spectrum technology.

The specifications were formalized by the Bluetooth Special Interest Group (SIG). The SIG
was formally announced on 20 May 1998. Today it has a membership of over 17,000
companies worldwide. It was established by Ericsson, IBM, Intel, Toshiba and Nokia, and
later joined by many other companies.

All versions of the Bluetooth standards are designed for downward compatibility. That lets
the latest standard cover all older versions.

Bluetooth v1.0 and v1.0B

Versions 1.0 and 1.0B had many problems, and manufacturers had difficulty making their
products interoperable. Versions 1.0 and 1.0B also included mandatory Bluetooth hardware
device address (BD_ADDR) transmission in the Connecting process (rendering anonymity
impossible at the protocol level), which was a major setback for certain services planned for
use in Bluetooth environments.

Bluetooth v1.1

 Ratified as IEEE Standard 802.15.1–2002

 Many errors found in the 1.0B specifications were fixed.
 Added possibility of non-encrypted channels.
 Received Signal Strength Indicator (RSSI).

Bluetooth v1.2

This version is backward compatible with 1.1 and the major enhancements include the
following:

 Faster Connection and Discovery

 Adaptive frequency-hopping spread spectrum (AFH), which improves resistance to
radio frequency interference by avoiding the use of crowded frequencies in the
hopping sequence.
 Higher transmission speeds in practice, up to 721 kbit/s, than in v1.1.
 Extended Synchronous Connections (eSCO), which improve voice quality of audio
links by allowing retransmissions of corrupted packets, and may optionally increase
audio latency to provide better concurrent data transfer.
 Host Controller Interface (HCI) operation with three-wire UART.
 Ratified as IEEE Standard 802.15.1–2005
 Introduced Flow Control and Retransmission Modes for L2CAP.
Bluetooth v2.0 + EDR

This version of the Bluetooth Core Specification was released in 2004 and is backward
compatible with the previous version 1.2. The main difference is the introduction of an
Enhanced Data Rate (EDR) for faster data transfer. The nominal rate of EDR is about 3
Mbit/s, although the practical data transfer rate is 2.1 Mbit/s. EDR uses a combination of
GFSK and Phase Shift Keying modulation (PSK) with two variants, π/4-DQPSK and
8DPSK. EDR can provide a lower power consumption through a reduced duty cycle.

The specification is published as "Bluetooth v2.0 + EDR" which implies that EDR is an
optional feature. Aside from EDR, there are other minor improvements to the 2.0
specification, and products may claim compliance to "Bluetooth v2.0" without supporting the
higher data rate. At least one commercial device states "Bluetooth v2.0 without EDR" on its
data sheet.

Bluetooth v2.1 + EDR

Bluetooth Core Specification Version 2.1 + EDR is fully backward compatible with 1.2, and
was adopted by the Bluetooth SIG on 26 July 2007.

The headline feature of 2.1 is secure simple pairing (SSP): this improves the pairing
experience for Bluetooth devices, while increasing the use and strength of security. See the
section on Pairing below for more details.

2.1 allows various other improvements, including "Extended inquiry response" (EIR), which
provides more information during the inquiry procedure to allow better filtering of devices
before connection; and sniff subrating, which reduces the power consumption in low-power
mode.

Bluetooth v3.0 + HS

Version 3.0 + HS of the Bluetooth Core Specification was adopted by the Bluetooth SIG on
21 April 2009. Bluetooth 3.0+HS provides theoretical data transfer speeds of up to 24 Mbit/s,
though not over the Bluetooth link itself. Instead, the Bluetooth link is used for negotiation
and establishment, and the high data rate traffic is carried over a collocated 802.11 link.

The main new feature is AMP (Alternate MAC/PHY), the addition of 802.11 as a high speed
transport. The High-Speed part of the specification is not mandatory, and hence only devices
sporting the "+HS" will actually support the Bluetooth over 802.11 high-speed data transfer.
A Bluetooth 3.0 device without the "+HS" suffix will not support High Speed, and needs to
only support a feature introduced in Core Specification Version 3.0 or earlier Core
Specification Addendum 1.

L2CAP Enhanced modes

Enhanced Retransmission Mode (ERTM) implements reliable L2CAP channel, while
Streaming Mode (SM) implements unreliable channel with no retransmission or flow control.
Introduced in Core Specification Addendum 1.

Alternate MAC/PHY

Enables the use of alternative MAC and PHYs for transporting Bluetooth profile data. The
Bluetooth radio is still used for device discovery, initial connection and profile configuration,
however when large quantities of data need to be sent, the high speed alternate MAC PHY
802.11 (typically associated with Wi-Fi) will be used to transport the data. This means that
the proven low power connection models of Bluetooth are used when the system is idle, and
the faster radio is used when large quantities of data need to be sent. AMP links require
enhanced L2CAP modes.

Unicast Connectionless Data

Permits service data to be sent without establishing an explicit L2CAP channel. It is intended
for use by applications that require low latency between user action and
reconnection/transmission of data. This is only appropriate for small amounts of data.

Enhanced Power Control

Updates the power control feature to remove the open loop power control, and also to clarify
ambiguities in power control introduced by the new modulation schemes added for EDR.
Enhanced power control removes the ambiguities by specifying the behaviour that is
expected. The feature also adds closed loop power control, meaning RSSI filtering can start
as the response is received. Additionally, a "go straight to maximum power" request has been
introduced. This is expected to deal with the headset link loss issue typically observed when a
user puts their phone into a pocket on the opposite side to the headset.

Ultra-wideband

The high speed (AMP) feature of Bluetooth v3.0 was originally intended for UWB, but the
WiMedia Alliance, the body responsible for the flavor of UWB intended for Bluetooth,
announced in March 2009 that it was disbanding, and ultimately UWB was omitted from the
Core v3.0 specification.

On 16 March 2009, the WiMedia Alliance announced it was entering into technology transfer
agreements for the WiMedia Ultra-wideband (UWB) specifications. WiMedia has transferred
all current and future specifications, including work on future high speed and power
optimized implementations, to the Bluetooth Special Interest Group (SIG), Wireless USB
Promoter Group and the USB Implementers Forum. After the successful completion of the
technology transfer, marketing and related administrative items, the WiMedia Alliance will
cease operations.

In October 2009 the Bluetooth Special Interest Group suspended development of UWB as
part of the alternative MAC/PHY, Bluetooth v3.0 + HS solution. A small, but significant,
number of former WiMedia members had not and would not sign up to the necessary
agreements for the IP transfer. The Bluetooth SIG is now in the process of evaluating other
options for its longer term roadmap.

Bluetooth v4.0

The Bluetooth SIG completed the Bluetooth Core Specification version 4.0 and has been
adopted as of 30 June 2010. It includes Classic Bluetooth, Bluetooth high speed and
Bluetooth low energy protocols. Bluetooth high speed is based on Wi-Fi, and Classic
Bluetooth consists of legacy Bluetooth protocols.

Bluetooth low energy (BLE), previously known as WiBree, is a subset to Bluetooth v4.0 with
an entirely new protocol stack for rapid build-up of simple links. As an alternative to the
Bluetooth standard protocols that were introduced in Bluetooth v1.0 to v3.0, it is aimed at
very low power applications running off a coin cell. Chip designs allow for two types of
implementation, dual-mode, single-mode and enhanced past versions. The provisional names
Wibree and Bluetooth ULP (Ultra Low Power) were abandoned and the BLE name was used
for a while. In late 2011, new logos “Bluetooth Smart Ready” for hosts and “Bluetooth
Smart” for sensors were introduced as the general-public face of BLE.

 In a single mode implementation the low energy protocol stack is implemented solely.
CSR, Nordic Semiconductor and Texas Instruments have released single mode
Bluetooth low energy solutions.
 In a dual-mode implementation, Bluetooth low energy functionality is integrated into
an existing Classic Bluetooth controller. Currently (2011-03) the following
semiconductor companies have announced the availability of chips meeting the
standard: Qualcomm-Atheros, CSR, Broadcom and Texas Instruments. The compliant
architecture shares all of Classic Bluetooth’s existing radio and functionality resulting
in a negligible cost increase compared to Classic Bluetooth.

Cost-reduced single-mode chips, which enable highly integrated and compact devices, feature
a lightweight Link Layer providing ultra-low power idle mode operation, simple device
discovery, and reliable point-to-multipoint data transfer with advanced power-save and
secure encrypted connections at the lowest possible cost.
Embedded code
//---------------------------------------------------------------------------------------------------------------
-----

// ROBOT_Main.c

//---------------------------------------------------------------------------------------------------------------
-----

// MODIFIED BY:

// MODIFIED DATE:

// 105_ROBOT

// Target: PROJECT BOARD of PHILIPS P89V51RD2 ( PES-01-0809 )

// Tool chain: KEIL IDE

//---------------------------------------------------------------------------------------------------------------
-----

// Includes

//---------------------------------------------------------------------------------------------------------------
-----

#pragma OR // order all variables in memory according to

their order of definition

#pragma small // by default all variables are stored in data

memory type

#include<P89V51RD2.H> // header file of RD2 microcontroller

#include<ROBOT_UART.c>

#define SYSCLK 11059200 // crystal frequency

//---------------------------------------------------------------------------------------------------------------
-----

// 16-bit SFR Definitions for "P89V51RD2"

//---------------------------------------------------------------------------------------------------------------
-----

sbit Jaw_Forward = P2^0;

sbit Jaw_Reverse = P2^1;

sbit Neck_Forward = P2^2;

sbit Neck_Reverse = P2^3;

sbit L_Motor_Data1 = P2^4;

sbit L_Motor_Data2 = P2^5;

sbit R_Motor_Data1 = P2^6;

sbit R_Motor_Data2 = P2^7;

sbit Front_IR = P1^3;

sbit TOGGLE_SW = P1^0;

//---------------------------------------------------------------------------------------------------------------
-----

// Global VARIABLES

//---------------------------------------------------------------------------------------------------------------
-----
//---------------------------------------------------------------------------------------------------------------
-----

// Global CONSTANTS

//---------------------------------------------------------------------------------------------------------------
-----

//---------------------------------------------------------------------------------------------------------------
-----

// Function PROTOTYPES

//---------------------------------------------------------------------------------------------------------------
-----

void Device_Init( void );

void Robot_OFF( );

void Forward_L_R( void );

void Rotate_L( void );

void Rotate_R( void );

void Reverse_L_R( void );

void Rotate_Pick_Arm_L( void );

void Rotate_Pick_Arm_R( void );

void Rotate_Pick_Arm_F( void );

void Rotate_Pick_Arm_B( void );

void MSDelay( unsigned int Milli_Sec );

//---------------------------------------------------------------------------------------------------------------
-----

// void main (void)

//---------------------------------------------------------------------------------------------------------------
-----

void main( void )

// unsigned char i;

Device_Init( );

MSDelay(100);

UART_ST( "UART TESTED" );

// ******* Testing Robot *********

Forward_L_R( );

Rotate_L( );

Rotate_R( );

Reverse_L_R( );

Rotate_Pick_Arm_L( );

Rotate_Pick_Arm_R( );

Rotate_Pick_Arm_F( );

Rotate_Pick_Arm_B( );

// *******************************

while(1)

if(TOGGLE_SW==1)

Rx_count = 0;
// Take UART Receiver array to zeroth location
 Rx_ST_Flag = 0;
// Indicates UART receive of first byte

while( Rx_ST_Flag == 0 )

if(TOGGLE_SW==0)

break;

if( Rx_ST_Flag == 1 )

Rx_ST_Flag = 0;
// Indicates UART receive of first byte

switch( Rx_data_arr[0] )

case '1':

Forward_L_R( );

break;

case '2':

Rotate_L( );

break;

case '3':

Rotate_R( );

break;

}
 case '4':

Reverse_L_R( );

break;

case '5':

Rotate_Pick_Arm_L( );

break;

case '6':

Rotate_Pick_Arm_R( );

break;

case '7':

Rotate_Pick_Arm_F( );

break;

case '8':

Rotate_Pick_Arm_B( );

break;

}
 }

else if(TOGGLE_SW==0)

Rotate_Pick_Arm_L( );

Rotate_Pick_Arm_F( );

Rotate_Pick_Arm_R( );

Rotate_L( );

Forward_L_R( );

Rotate_R( );

Forward_L_R( );

Rotate_Pick_Arm_L( );

Rotate_Pick_Arm_B( );

Rotate_Pick_Arm_R( );

Reverse_L_R( );

Rotate_R( );

Forward_L_R( );

Rotate_L( );

Rotate_Pick_Arm_L( );

Rotate_Pick_Arm_F( );

Rotate_Pick_Arm_R( );

Forward_L_R( );
 Rotate_Pick_Arm_L( );

Rotate_Pick_Arm_B( );

Rotate_Pick_Arm_R( );

Reverse_L_R( );

Rotate_Pick_Arm_L( );

Rotate_Pick_Arm_F( );

Rotate_Pick_Arm_R( );

Rotate_R( );

Forward_L_R( );

Rotate_L( );

Forward_L_R( );

Rotate_Pick_Arm_L( );

Rotate_Pick_Arm_B( );

Rotate_Pick_Arm_R( );

Reverse_L_R( );

Rotate_L( );

Forward_L_R( );

Rotate_R( );

}
 }

while(1) //
spin over

void Device_Init( void )

xdata unsigned char UC_count = 0xFD; // For 9600 Buad Rate

EA = 0;

// P0 = 0xFF;

// P1 = 0xF8;

// P2 = 0x00;

// P3 = 0x00;

UART0M1_Tx_Init( ); // UART0 mode 1

Transmit initialization

Timer1M2_Init( UC_count ); // Timer 1 mode 2

initialization

EA = 1; // Enable
Global Interrupts

TR1 = 1; // Start Timer 1

L_Motor_Data1 = 0;

L_Motor_Data2 = 0;
 R_Motor_Data1 = 0;

R_Motor_Data2 = 0;

Jaw_Forward = 0;

Jaw_Reverse = 0;

Neck_Forward = 0;

Neck_Reverse = 0;

void Robot_OFF( )

L_Motor_Data1 = 0;

L_Motor_Data2 = 0;

R_Motor_Data1 = 0;

R_Motor_Data2 = 0;

void Forward_L_R( void )

L_Motor_Data1 = 1;

L_Motor_Data2 = 0;

R_Motor_Data1 = 1;

R_Motor_Data2 = 0;
 MSDelay(1000);

L_Motor_Data1 = 0;

L_Motor_Data2 = 0;

R_Motor_Data1 = 0;

R_Motor_Data2 = 0;

MSDelay(100);

void Rotate_L( void )

L_Motor_Data1 = 0;

L_Motor_Data2 = 1;

R_Motor_Data1 = 1;

R_Motor_Data2 = 0;

MSDelay(700);

L_Motor_Data1 = 0;

L_Motor_Data2 = 0;

R_Motor_Data1 = 0;

R_Motor_Data2 = 0;

MSDelay(100);

}
void Rotate_R( void )

L_Motor_Data1 = 1;

L_Motor_Data2 = 0;

R_Motor_Data1 = 0;

R_Motor_Data2 = 1;

MSDelay(700);

L_Motor_Data1 = 0;

L_Motor_Data2 = 0;

R_Motor_Data1 = 0;

R_Motor_Data2 = 0;

MSDelay(100);

void Reverse_L_R( void )

L_Motor_Data1 = 0;

L_Motor_Data2 = 1;

R_Motor_Data1 = 0;

R_Motor_Data2 = 1;

MSDelay(1000);

L_Motor_Data1 = 0;

L_Motor_Data2 = 0;

R_Motor_Data1 = 0;

R_Motor_Data2 = 0;
 MSDelay(100);

void Rotate_Pick_Arm_L( void )

Jaw_Forward = 0;

Jaw_Reverse = 1;

MSDelay(700);

Jaw_Forward = 0;

Jaw_Reverse = 0;

MSDelay(100);

void Rotate_Pick_Arm_R( void )

Jaw_Forward = 1;

Jaw_Reverse = 0;

MSDelay(700);

Jaw_Forward = 0;

Jaw_Reverse = 0;

MSDelay(100);

void Rotate_Pick_Arm_F( void )

Neck_Forward = 0;

Neck_Reverse = 1;

MSDelay(700);

Neck_Forward = 0;
 Neck_Reverse = 0;

MSDelay(100);

void Rotate_Pick_Arm_B( void )

Neck_Forward = 1;

Neck_Reverse = 0;

MSDelay(700);

Neck_Forward = 0;

Neck_Reverse = 0;

MSDelay(100);

//---------------------------------------------------------------------------------------------------------------
-----

// void MSDelay( unsigned int Milli_Sec )

//---------------------------------------------------------------------------------------------------------------
-----

// Function Name: void MSDelay( unsigned int Milli_Sec )

// Arguments : 1 argument used

// Milli_Sec -> value in this variable will give that msec

// Return Value : No return value

// Description : This function will generate the required milli second delay based
on the Milli_Sec variable.

// This function is tested on P89V51RD2 controller

void MSDelay( unsigned int Milli_Sec )

data unsigned int x,y;

 for(x=0;x<Milli_Sec;x++)

for(y=0;y<180;y++)

if(Front_IR == 1)

L_Motor_Data1 = 0;

L_Motor_Data2 = 0;

R_Motor_Data1 = 0;

R_Motor_Data2 = 0;

UART_ST( "OBSTACLE DETECTED" );

while(1);

}
 ANDROID

Android is a Linux-based operating system designed primarily for touch screen

mobile devices such as Smartphone’s and tablet computers. Initially developed by Android,
Inc., which Google backed financially and later bought in 2005,Android was unveiled in
2007 along with the founding of the Open Handset Alliance: a consortium of hardware,
software, and telecommunication companies devoted to advancing open standards for mobile
devices. The first Android-powered phone was sold in October 2008.
Android is open source and Google releases the code under the Apache License. This open
source code and permissive licensing allows the software to be freely modified and
distributed by device manufacturers, wireless carriers and enthusiast developers.
Additionally, Android has a large community of developers writing applications ("apps") that
extend the functionality of devices, written primarily in a customized version of the Java
programming language. In October 2012, there were approximately 700,000 apps available
for Android, and the estimated number of applications downloaded from Google Play,
Android's primary app store, was 25 billion.

These factors have allowed Android to become the world's most widely used smart phone
platform,[19] overtaking Symbian in the fourth quarter of 2010, and the software of choice for
technology companies who require a low-cost, customizable, lightweight operating system
for high tech devices without developing one from scratch. As a result, despite being
primarily designed for phones and tablets, it has seen additional applications on televisions,
games consoles, digital cameras and other electronics. Android's open nature has further
encouraged a large community of developers and enthusiasts to use the open source code as a
foundation for community-driven projects, which add new features for advanced users or
bring Android to devices which were officially released running other operating systems.

Android had a worldwide smart phone market share of 75% during the third quarter of 2012,
with 750 million devices activated in total and 1.5 million activations per day. The operating
system's success has made it a target for patent litigation as part of the so-called "smart
phone" between technology companies.

History

Android, Inc. was founded in Palo Alto, California in October 2003 by Andy Rubin (co-
founder of Danger),Rich Miner (co-founder of Wildfire Communications, Inc.), Nick Sears
(once VP at T-Mobile), and Chris White (headed design and interface development at
WebTV) to develop, in Rubin's words "smarter mobile devices that are more aware of its
owner's location and preferences". The early intentions of the company were to develop an
advanced operating system for digital cameras, when it was realised that the market for the
devices was not large enough, and diverted their efforts to producing a smartphone operating
system to rival those of Symbian and Windows Mobile (Apple's iPhone had not been released
at the time). Despite the past accomplishments of the founders and early employees, Android
Inc. operated secretly, revealing only that it was working on software for mobile phones. That
same year, Rubin ran out of money. Steve Perlman, a close friend of Rubin, brought him
$10,000 in cash in an envelope and refused a stake in the company.

Google acquired Android Inc. on August 17, 2005, making it a wholly owned subsidiary of
Google. Key employees of Android Inc., including Rubin, Miner and White, stayed at the
company after the acquisition. Not much was known about Android Inc. at the time, but
many assumed that Google was planning to enter the mobile phone market with this move. At
Google, the team led by Rubin developed a mobile device platform powered by the Linux
kernel. Google marketed the platform to handset makers and carriers on the promise of
providing a flexible, upgradable system. Google had lined up a series of hardware component
and software partners and signaled to carriers that it was open to various degrees of
cooperation on their part.
Speculation about Google's intention to enter the mobile communications market continued
to build through December 2006. Reports from the BBC and the Wall Street Journal noted
that Google wanted its search and applications on mobile phones and it was working hard to
deliver that. Print and online media outlets soon reported rumors that Google was developing
a Google-branded handset. Some speculated that as Google was defining technical
specifications, it was showing prototypes to cell phone manufacturers and network operators.
In September 2007, InformationWeek covered an Evalueserve study reporting that Google
had filed several patent applications in the area of mobile telephony.

On November 5, 2007, the Open Handset Alliance, a consortium of technology companies

including Google, device manufacturers such as HTC and Samsung, wireless carriers such as
Sprint Nextel and T-Mobile, and chipset makers such as Qualcomm and Texas Instruments,
unveiled itself, with a goal to develop open standards for mobile devices. That day, Android
was unveiled as its first product, a mobile device platform built on the Linux kernel version
2.6. The first commercially available phone to run Android was the HTC Dream, released on
October 22, 2008.

Since 2008, Android has seen numerous updates which have incrementally improved the
operating system, adding new features and fixing bugs in previous releases. Each major
release is named in alphabetical order after a dessert or sugary treat; for example, version 1.5
Cupcake was followed by 1.6 Donut. The latest release is 4.2 Jelly Bean. In 2010, Google
launched its Nexus series of devices—a line of smartphones and tablets running the Android
operating system, and built by a manufacturer partner. HTC collaborated with Google to
release the first Nexus smartphone, the Nexus One. The series has since been updated with
newer devices, such as the Nexus 4 phone and Nexus 10 tablet, made by LG and Samsung,
respectively. Google releases the Nexus phones and tablets to act as their flagship Android
devices, demonstrating Android's latest software and hardware features.

On 13 March 2013, it was announced by Larry Page in a blog post that Andy Rubin had
moved from the Android division to take on new projects at Google. He was replaced by
Sundar Pichai, who also continues his role as the head of Google's Chrome division, which
develops Chrome OS.

Interface

Android's user interface is based on direct manipulation using touch inputs that loosely
correspond to real-world actions, like swiping, tapping, pinching and reverse pinching to
manipulate on-screen objects. The response to user input is designed to be immediate and
provides a fluid touch interface, often using the vibration capabilities of the device to provide
haptic feedback to the user. Internal hardware such as accelerometers, gyroscopes and
proximity sensors are used by some applications to respond to additional user actions, for
example adjusting the screen from portrait to landscape depending on how the device is
oriented, or allowing the user to steer a vehicle in a racing game by rotating the device,
simulating control of a steering wheel.

Android devices boot to the homescreen, the primary navigation and information point on the
device, which is similar to the desktop found on PCs. Android homescreens are typically
made up of app icons and widgets; app icons launch the associated app, whereas widgets
display live, auto-updating content such as the weather forecast, the user's email inbox, or a
news ticker directly on the homescreen. A homescreen may be made up of several pages that
the user can swipe back and forth between, though Android's homescreen interface is heavily
customisable, allowing the user to adjust the look and feel of the device to their tastes. Third
party apps available on Google Play and other app stores can extensively re-theme the
homescreen, and even mimic the look of other operating systems, such as Windows Phone.
Most manufacturers, and some wireless carriers, customise the look and feel of their Android
devices to differentiate themselves from the competition.

Present along the top of the screen is a status bar, showing information about the device and
its connectivity. This status bar can be "pulled" down to reveal a notification screen where
apps display important information or updates, such as a newly received email or SMS text,
in a way that does not immediately interrupt or inconvenience the user. [46] In early versions of
Android these notifications could be tapped to open the relevant app, but recent updates have
provided enhanced functionality, such as the ability to call a number back directly from the
missed call notification without having to open the dialer app first. Notifications are
persistent until read or dismissed by the user.

Applications

Android has a growing selection of third party applications, which can be acquired by users
either through an app store such as Google Play or the Amazon Appstore, or by downloading
and installing the application's APK file from a third-party site. The Play Store application
allows users to browse, download and update apps published by Google and third-party
developers, and is pre-installed on devices that comply with Google's compatibility
requirements. The app filters the list of available applications to those that are compatible
with the user's device, and developers may restrict their applications to particular carriers or
countries for business reasons. Purchases of unwanted applications can be refunded within 15
minutes of the time of download,[51] and some carriers offer direct carrier billing for Google
Play application purchases, where the cost of the application is added to the user's monthly
bill.[52] As of September 2012, there were more than 675,000 apps available for Android, and
the estimated number of applications downloaded from the Play Store was 25 billion.

Applications are developed in the Java language using the Android software development kit
(SDK). The SDK includes a comprehensive set of development tools, [54] including a
debugger, software libraries, a handset emulator based on QEMU, documentation, sample
code, and tutorials. The officially supported integrated development environment (IDE) is
Eclipse using the Android Development Tools (ADT) plugin. Other development tools are
available, including a Native Development Kit for applications or extensions in C or C++,
Google App Inventor, a visual environment for novice programmers, and various cross
platform mobile web applications frameworks.

In order to work around limitations on reaching Google services due to Internet censorship in
the People's Republic of China, Android devices sold in the PRC are generally customized to
use state approved services instead.

Development

Android is developed in private by Google until the latest changes and updates are ready to
be released, at which point the source code is made available publicly. This source code will
only run without Architecture diagram modification on select devices, usually the Nexus
series of devices.

Architecture diagram

Android consists of a kernel based on Linux kernel version 2.6 and, from Android 4.0 Ice
Cream Sandwich onwards, version 3.x, with middleware, libraries and APIs written in C, and
application software running on an application framework which includes Java-compatible
libraries based on Apache Harmony. Android uses the Dalvik virtual machine with just-in-
time compilation to run Dalvik 'dex-code' (Dalvik Executable), which is usually translated
from Java bytecode. The main hardware platform for Android is the ARM architecture. There
is support for x86 from the Android x86 project, and Google TV uses a special x86 version of
Android. In 2013, Freescale announced Android on its i.MX processor, i.MX5X and i.MX6X
series.

Android's Linux kernel has further architecture changes by Google outside the typical Linux
kernel development cycle. Android does not have a native X Window System by default nor
does it support the full set of standard GNU libraries, and this makes it difficult to port
existing Linux applications or libraries to Android. Support for simple C and SDL
applications is possible by injection of a small Java shim and usage of the JNI like, for
example, in the Jagged Alliance 2 port for Android.
Certain features that Google contributed back to the Linux kernel, notably a power
management feature called "wakelocks", were rejected by mainline kernel developers partly
because they felt that Google did not show any intent to maintain its own code. Google
announced in April 2010 that they would hire two employees to work with the Linux kernel
community, but Greg Kroah-Hartman, the current Linux kernel maintainer for the stable
branch, said in December 2010 that he was concerned that Google was no longer trying to get
their code changes included in mainstream Linux. Some Google Android developers hinted
that "the Android team was getting fed up with the process," because they were a small team
and had more urgent work to do on Android.

In August 2011, Linus Torvalds said that "eventually Android and Linux would come back to
a common kernel, but it will probably not be for four to five years". In December 2011, Greg
Kroah-Hartman announced the start of the Android Mainlining Project, which aims to put
some Android drivers, patches and features back into the Linux kernel, starting in Linux 3.3.
Linux included the autosleep and wakelocks capabilities in the 3.5 kernel, after many
previous attempts at merger. The interfaces are the same but the upstream Linux
implementation allows for two different suspend modes: to memory (the traditional suspend
that Android uses), and to disk (hibernate, as it is known on the desktop). The merge will be
complete starting with Kernel 3.8, Google has opened a public code repository that contains
their experimental work to re-base Android off Kernel 3.8.

The flash storage on Android devices is split into several partitions, such as "/system" for the
operating system itself and "/data" for user data and app installations. In contrast to desktop
Linux distributions, Android device owners are not given root access to the operating system
and sensitive partitions such as /system are read-only. However, root access can be obtained
by exploiting security flaws in Android, which is used frequently by the open source
community to enhance the capabilities of their devices, but also by malicious parties to install
viruses and malware.

Whether or not Android counts as a Linux distribution is a widely debated topic, with the
Linux Foundation and Chris DiBona, Google's open source chief, in favour. Others, such as
Google engineer Patrick Brady disagree, noting the lack of support for many GNU tools,
including glibc, in Android.

Proprietary binary dependencies

With many devices, there are proprietary binaries which have to be provided by the
manufacturer, in order for Android to work.

Memory management

Since Android devices are usually battery-powered, Android is designed to manage memory
(RAM) to keep power consumption at a minimum, in contrast to desktop operating systems
which generally assume they are connected to unlimited mains electricity. When an Android
app is no longer in use, the system will automatically suspend it in memory - while the app is
still technically "open," suspended apps consume no resources (e.g. battery power or
processing power) and sit idly in the background until needed again. This has the dual benefit
of increasing the general responsiveness of Android devices, since apps don't need to be
closed and reopened from scratch each time, but also ensuring background apps don't waste
power needlessly.
Android manages the apps stored in memory automatically: when memory is low, the system
will begin killing apps and processes that have been inactive for a while, in reverse order
since they were last used (i.e. oldest first). This process is designed to be invisible to the user,
such that users do not need to manage memory or the killing of apps themselves. However,
confusion over Android memory management has resulted in third-party task killers
becoming popular on the Google Play store; these third-party task killers are generally
regarded as doing more harm than good.

Update schedule

Google provides major updates, incremental in nature, to Android every six to nine months,
which most devices are capable of receiving over the air. The latest major update is Android
4.2 Jelly Bean.

Compared to its chief rival mobile operating system, namely iOS, Android updates are
typically slow to reach actual devices. For devices not under the Nexus brand, updates often
arrive months from the time the given version is officially released. This is caused partly due
to the extensive variation in hardware of Android devices, to which each update must be
specifically tailored, as the official Google source code only runs on their flagship Nexus
devices. Porting Android to specific hardware is a time- and resource-consuming process for
device manufacturers, who prioritize their newest devices and often leave older ones behind.
[84]
Hence, older smartphones are frequently not updated if the manufacturer decides it is not
worth their time, regardless of whether the phone is capable of running the update. This
problem is compounded when manufacturers customize Android with their own interface and
apps, which must be reapplied to each new release. Additional delays can be introduced by
wireless carriers who, after receiving updates from manufacturers, further customize and
brand Android to their needs and conduct extensive testing on their networks before sending
the update out to users.[84]

The lack of after-sale support from manufacturers and carriers has been widely criticised by
consumer groups and the technology media Some commentators have noted that the industry
has a financial incentive not to update their devices, as the lack of updates for existing
devices fuels the purchase of newer ones, an attitude described as "insulting". The Guardian
has complained that the complicated method of distribution for updates is only complicated
because manufacturers and carriers have designed it that way. [86] In 2011, Google partnered
with a number of industry players to announce an "Android Update Alliance", pledging to
deliver timely updates for every device for 18 months after its release. As of 2013, this
alliance has never been mentioned since.
Open source community

Android has an active community of developers and enthusiasts who use the Android source
code to develop and distribute their own modified versions of the operating system. These
community-developed releases often bring new features and updates to devices faster than
through the official manufacturer/carrier channels, albeit without as extensive testing or
quality assurance; provide continued support for older devices that no longer receive official
updates; or bring Android to devices that were officially released running other operating
systems, such as the HP Touchpad. Community releases often come pre-rooted and contain
modifications unsuitable for non-technical users, such as the ability to overclock or
over/undervolt the device's processor. CyanogenMod is the most widely used community
firmware, and acts as a foundation for numerous others.

Historically, device manufacturers and mobile carriers have typically been unsupportive of
third-party firmware development. Manufacturers express concern about improper
functioning of devices running unofficial software and the support costs resulting from this.
Moreover, modified firmwares such as CyanogenMod sometimes offer features, such as
tethering, for which carriers would otherwise charge a premium. As a result, technical
obstacles including locked bootloaders and restricted access to root permissions are common
in many devices. However, as community-developed software has grown more popular, and
following a statement by the Librarian of Congress in the United States that permits the
"jailbreaking" of mobile devices, manufacturers and carriers have softened their position
regarding third party development, with some, including HTC, Motorola, Samsung and Sony,
providing support and encouraging development. As a result of this, over time the need to
circumvent hardware restrictions to install unofficial firmware has lessened as an increasing
number of devices are shipped with unlocked or unlockable bootloaders, similar to the Nexus
series of phones, although usually requiring that users waive their devices' warranties to do
so.[92] However, despite manufacturer acceptance, some carriers in the US still require that
phones are locked down.

The unlocking and "hackability" of smartphones and tablets remains a source of tension
between the community and industry, with the community arguing that unofficial
development is increasingly important given the failure of industry to provide timely updates
and/or continued support to their devices.
Security and privacy

Android applications run in a sandbox, an isolated area of the system that does not have
access to the rest of the system's resources, unless access permissions are explicitly granted
by the user when the application is installed. Before installing an application, the Play Store
displays all required permissions: a game may need to enable vibration or save data to an SD
card, for example, but should not need to read SMS messages or access the phonebook. After
reviewing these permissions, the user can choose to accept or refuse them, installing the
application only if they accept.

The sandboxing and permissions system lessens the impact of vulnerabilities and bugs in
applications, but developer confusion and limited documentation has resulted in applications
routinely requesting unnecessary permissions, reducing its effectiveness. Several security
firms, such as Lookout Mobile Security, AVG Technologies, and McAfee, have released
antivirus software for Android devices. This software is ineffective as sandboxing also
applies to such applications, limiting their ability to scan the deeper system for threats.

Research from security company Trend Micro lists premium service abuse as the most
common type of Android malware, where text messages are sent from infected phones to
premium-rate telephone numbers without the consent or even knowledge of the user. Other
malware displays unwanted and intrusive adverts on the device, or sends personal
information to unauthorised third parties. Security threats on Android are reportedly growing
exponentially; however, Google engineers have argued that the malware and virus threat on
Android is being exaggerated by security companies for commercial reasons, and have
accused the security industry of playing on fears to sell virus protection software to users.
Google maintains that dangerous malware is actually extremely rare, [107] and a survey
conducted by F-Secure showed that only 0.5% of Android malware reported had come from
the Google Play store.

Google currently uses their Google Bouncer malware scanner to watch over and scan the
Google Play store apps. It is intended to flag up suspicious apps and warn users of any
potential issues with an application before they download it. Android version 4.2 Jelly Bean
was released in 2012 with enhanced security features, including a malware scanner built into
the system, which works in combination with Google Play but can scan apps installed from
third party sources as well, and an alert system which notifies the user when an app tries to
send a premium-rate text message, blocking the message unless the user explicitly authorises
it.

Android smartphones have the ability to report the location of Wi-Fi access points,
encountered as phone users move around, to build databases containing the physical locations
of hundreds of millions of such access points. These databases form electronic maps to locate
smartphones, allowing them to run apps like Foursquare, Google Latitude, Facebook Places,
and to deliver location-based ads. Third party monitoring software such as TaintDroid, an
academic research-funded project, can, in some cases, detect when personal information is
being sent from applications to remote servers.

The open source nature of Android allows security contractors to take existing devices and
adapt them for highly secure uses. For example Samsung has worked with General Dynamics
through their Open Kernel Labs acquisition to rebuild Jelly Bean on top of their hardened
microvisor for the "Knox" project.

Licensing

The source code for Android is available under free and open source software licenses.
Google publishes most of the code (including network and telephony stacks) under the
Apache License version 2.0, and the rest, Linux kernel changes, under the GNU General
Public License version 2. The Open Handset Alliance develops the changes to the Linux
kernel, in public, with source code publicly available at all times. The rest of Android is
developed in private by Google, with source code released publicly when a new version is
released. Typically Google collaborates with a hardware manufacturer to produce a 'flagship'
device (part of the Google Nexus series) featuring the new version of Android, then makes
the source code available after that device has been released.

In early 2011, Google chose to temporarily withhold the Android source code to the tablet-
only 3.0 Honeycomb release. The reason, according to Andy Rubin in an official Android
blog post, was because Honeycomb was rushed for production of the Motorola Xoom, and
they did not want third parties creating a "really bad user experience" by attempting to put
onto smartphones a version of Android intended for tablets. [122] The source code was once
again made available in November 2011 with the release of Android 4.0.

Non-free software

Even though the software is open-source, device manufacturers cannot use Google's Android
trademark unless Google certifies that the device complies with their Compatibility
Definition Document (CDD). Devices must also meet this definition to be eligible to license
Google's closed-source applications, including Google Play. As Android is not completely
released under a GPL compatible license, e.g. Google's code is under the Apache license,[11]
and also because Google Play allows proprietary software, Richard Stallman and the Free
Software Foundation have been critical of Android and have recommended the usage of
alternatives such as Replicant.
Reception

Android received a lukewarm reaction when it was unveiled in 2007. Although analysts were
impressed with the respected technology companies that had partnered with Google to form
the Open Handset Alliance, it was unclear whether mobile phone manufacturers would be
willing to replace their existing operating systems with Android. The idea of an open source,
Linux-based development platform sparked interest, but there were additional worries about
Android facing strong competition from established players in the smartphone market, such
as Nokia and Microsoft, and rival Linux mobile operating systems that were in development.
These established players were skeptical: Nokia was quoted as saying "we don't see this as a
threat," and a member of Microsoft's Windows Mobile team stated "I don't understand the
impact that they are going to have."

Since then Android has grown to become the most widely used smartphone operating system
and "one of the fastest mobile experiences available." Reviewers have highlighted the open
source nature of the operating system as one of its defining strengths, allowing companies
such as Amazon (Kindle Fire), Barnes & Noble (Nook), Ouya, Baidu, and others to fork the
software and release hardware running their own customised version of Android. As a result,
it has been described by technology website Ars Technica as "practically the default
operating system for launching new hardware" for companies without their own mobile
platforms. This openness and flexibility is also present at the level of the end user: Android
allows extensive customisation of devices by their owners and apps are freely available from
non-Google app stores and third party websites. These have been cited as among the main
advantages of Android phones over others.

Despite Android's popularity, including an activation rate three times that of iOS, there have
been reports that Google has not been able to leverage their other products and web services
successfully to turn Android into the money maker that analysts had expected. The Verge
suggested that Google is losing control of Android due to the extensive customization and
proliferation of non-Google apps and services - for instance the Amazon Kindle Fire points
users to the Amazon app store that competes directly with the Google Play store. Google SVP
Andy Rubin, who was replaced as head of the Android division in March 2013, has been
blamed for failing to establish a lucrative partnership with cell phone makers. The chief
beneficiary of Android has been Samsung, whose Galaxy brand has surpassed that of
Android in terms of brand recognition since 2011. Meanwhile other Android manufacturers
have struggled since 2011, such as LG, HTC, and Google's own Motorola Mobility (whose
partnership with Verizon Wireless to push the "DROID" brand has faded since 2010).
Ironically, while Google directly earns nothing from the sale of each Android device,
Microsoft and Apple have successfully sued to extract patent royalty payments from Android
handset manufacturers.
AmarinoDbAdapter.java
/*

Amarino - A prototyping software toolkit for Android and Arduino

Copyright (c) 2010 Bonifaz Kaufmann. All right reserved.

This application and its library is free software; you can redistribute

it and/or modify it under the terms of the GNU Lesser General Public

License as published by the Free Software Foundation; either

version 3 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

GNU

Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public

License along with this library; if not, write to the Free Software

Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

*/

package at.abraxas.amarino;

import java.util.ArrayList;

import android.content.ContentValues;

import android.content.Context;

import android.database.Cursor;

import android.database.SQLException;
import android.database.sqlite.SQLiteDatabase;

import android.database.sqlite.SQLiteOpenHelper;

import android.util.Log;

import at.abraxas.amarino.log.Logger;

/**

* $Id: AmarinoDbAdapter.java 444 2010-06-10 13:11:59Z abraxas $

*/

public class AmarinoDbAdapter {

public static final String

KEY_DEVICE_ID = "_id";

public static final String

KEY_DEVICE_NAME = "name";

public static final String

KEY_DEVICE_ADDRESS = "device_address";

public static final String

KEY_EVENT_ID = "_id";

public static final String

KEY_EVENT_NAME = "event_name";

public static final String

KEY_EVENT_DESC = "desc";

public static final String

KEY_EVENT_VISUALIZER = "visualizer";

public static final String

KEY_EVENT_VISUALIZER_MIN = "minVal";

public static final String

KEY_EVENT_VISUALIZER_MAX = "maxVal";

public static final String

KEY_EVENT_FLAG = "flag";
 public static final String
KEY_EVENT_PACKAGE_NAME = "package";

public static final String

KEY_EVENT_EDIT_CLASS_NAME = "edit_class";

public static final String

KEY_EVENT_SERVICE_CLASS_NAME = "service_class";

public static final String

KEY_EVENT_PLUGIN_ID = "plugin_id";

public static final String

KEY_EVENT_DEVICE_ID = "device_id";

private static final boolean

DEBUG = true;

private static final String TAG =

"AmarinoDbAdapter";

private static final int

DATABASE_VERSION = 2;

private static final String

DATABASE_NAME = "amarino_2.db";

private static final String

DEVICE_TABLE_NAME = "devices_tbl";

private static final String

EVENT_TABLE_NAME = "events_tbl";

private DatabaseHelper
mDbHelper;

private SQLiteDatabase mDb;

private final Context mCtx;

 private static class
DatabaseHelper extends SQLiteOpenHelper {

DatabaseHelper(Context context) {

super(context, DATABASE_NAME, null, DATABASE_VERSION);

@Override

public void onCreate(SQLiteDatabase db) {

Log.d(TAG, "create database

tables");

/* Create Devices Table */

db.execSQL("CREATE TABLE
" + DEVICE_TABLE_NAME + " ("

+ KEY_DEVICE_ID + " INTEGER PRIMARY KEY,"

+ KEY_DEVICE_ADDRESS + " TEXT UNIQUE,"

+ KEY_DEVICE_NAME + " TEXT"

+ ");");

db.execSQL("CREATE TABLE
" + EVENT_TABLE_NAME + " ("

+ KEY_EVENT_ID + "
INTEGER PRIMARY KEY,"

+ KEY_EVENT_NAME + " TEXT NOT NULL,"

+ KEY_EVENT_DESC + " TEXT,"

+ KEY_EVENT_VISUALIZER + " INTEGER,"

+ KEY_EVENT_VISUALIZER_MIN + " NUMBER,"

+ KEY_EVENT_VISUALIZER_MAX + " NUMBER,"

+ KEY_EVENT_FLAG + " INTEGER NOT NULL,"

 + KEY_EVENT_PACKAGE_NAME + " TEXT NOT NULL,"

+ KEY_EVENT_EDIT_CLASS_NAME + " TEXT NOT NULL,"

+ KEY_EVENT_SERVICE_CLASS_NAME + " TEXT NOT NULL,"

+ KEY_EVENT_PLUGIN_ID + " INTEGER NOT NULL,"

+ KEY_EVENT_DEVICE_ID + " INTEGER REFERENCES " +

DEVICE_TABLE_NAME + "(_id) "

+ ");");

@Override

public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {

Log.w(TAG, "Upgrading database from version " + oldVersion + " to "

+ newVersion + ", which will destroy all old data");

db.execSQL("DROP TABLE IF EXISTS " + DEVICE_TABLE_NAME);

db.execSQL("DROP TABLE IF EXISTS " + EVENT_TABLE_NAME);

onCreate(db);

Log.d(TAG, "upgrade db");

/**

* Constructor - takes the context to allow the database to be

* opened/created

*
* @param ctx the Context within which to work

*/

public AmarinoDbAdapter(Context ctx) {

this.mCtx = ctx;

/**

* Open the database. If it cannot be opened, try to create a new

* instance of the database. If it cannot be created, throw an exception to

* signal the failure

* @return this (self reference, allowing this to be chained in an

* initialization call)

* @throws SQLException if the database could be neither opened or created

*/

public AmarinoDbAdapter open() throws SQLException {

mDbHelper = new DatabaseHelper(mCtx);

mDb = mDbHelper.getWritableDatabase();

return this;

public void close() {

mDbHelper.close();

/**
 * Create a new device using the address and name provided. If the device is

* successfully created return the new rowId for that device, otherwise return

* a -1 to indicate failure.

* @param address the address of the device

* @param name the name of the device

* @return rowId or -1 if failed

*/

public long createDevice(BTDevice device) {

ContentValues initialValues = new ContentValues();

initialValues.put(KEY_DEVICE_ADDRESS, device.address);

initialValues.put(KEY_DEVICE_NAME, (device.name == null) ? "NONAME" :

device.name);

return mDb.insert(DEVICE_TABLE_NAME, null, initialValues);

/**

* Delete the device with the given rowId

* @param rowId id of device to delete

* @return true if deleted, false otherwise

*/

public boolean deleteDevice(long deviceId) {

int numEvents =
deleteEvents(deviceId);

if (DEBUG) Logger.d(TAG,
"delete device with id " + deviceId + ": " + numEvents + " associated events
removed");
 return mDb.delete(DEVICE_TABLE_NAME, KEY_DEVICE_ID + "=" +
deviceId, null) > 0;

public BTDevice getDevice(String address){

BTDevice device = null;

Cursor c =
mDb.query(DEVICE_TABLE_NAME, null, KEY_DEVICE_ADDRESS + " like ?",
new String[]{address}, null, null, null);

if (c == null){

return null;

if (c.moveToFirst()){

String name =
c.getString(c.getColumnIndex(KEY_DEVICE_NAME));

long id =
c.getLong(c.getColumnIndex(KEY_DEVICE_ID));

device = new BTDevice(id,

address, name);

c.close();

return device;

/**

* Return a list of all devices in the database

*
 * @return ArrayList over all devices

*/

public ArrayList<BTDevice> fetchAllDevices() {

ArrayList<BTDevice> devices =
new ArrayList<BTDevice>();

Cursor c = mDb.query(DEVICE_TABLE_NAME, null, null, null, null, null, null);

if (c == null){

return devices;

if (c.moveToFirst()){

do {

String address =
c.getString(c.getColumnIndex(KEY_DEVICE_ADDRESS));

String name =
c.getString(c.getColumnIndex(KEY_DEVICE_NAME));

long id =
c.getLong(c.getColumnIndex(KEY_DEVICE_ID));

devices.add(new BTDevice(id,
address, name));

while(c.moveToNext());

c.close();

return devices;

}
 /**

* Create a new event associated with a specific device. If the event is

* successfully created return the new rowId for that event, otherwise return

* a -1 to indicate failure.

* @param address the address of the device

* @param name the name of the device

* @return rowId or -1 if failed

*/

public long createEvent(Event event) {

ContentValues initialValues = new ContentValues();

initialValues.put(KEY_EVENT_NAME, event.name);

initialValues.put(KEY_EVENT_DESC, event.desc);

initialValues.put(KEY_EVENT_VISUALIZER, event.visualizer);

initialValues.put(KEY_EVENT_VISUALIZER_MIN, event.visualizerMinValue);

initialValues.put(KEY_EVENT_VISUALIZER_MAX, event.visualizerMaxValue);

initialValues.put(KEY_EVENT_FLAG, (int)event.flag);

initialValues.put(KEY_EVENT_PACKAGE_NAME, event.packageName);

initialValues.put(KEY_EVENT_EDIT_CLASS_NAME, event.editClassName);

initialValues.put(KEY_EVENT_SERVICE_CLASS_NAME,
event.serviceClassName);

initialValues.put(KEY_EVENT_PLUGIN_ID, event.pluginId);

initialValues.put(KEY_EVENT_DEVICE_ID, event.deviceId);

return mDb.insert(EVENT_TABLE_NAME, null, initialValues);

}
 /**

* Delete the event with the given rowId

* @param rowId id of event to delete

* @return true if deleted, false otherwise

*/

public boolean deleteEvent(long rowId) {

return mDb.delete(EVENT_TABLE_NAME, KEY_EVENT_ID + "=" + rowId,

null) > 0;

/**

* Delete all events associated to the given device

* @param deviceId

* @return

*/

public int deleteEvents(long deviceId){

return
mDb.delete(EVENT_TABLE_NAME, KEY_EVENT_DEVICE_ID + "=" + deviceId,
null);

public Event getEvent(long deviceId, int pluginId){

Event e = null;

Cursor c =
mDb.query(EVENT_TABLE_NAME, null,
 KEY_EVENT_DEVICE_ID +
"=? AND " + KEY_EVENT_PLUGIN_ID + "=?",

new String[]
{String.valueOf(deviceId), String.valueOf(pluginId)}, null, null, null);

if (c == null){

if (DEBUG) Logger.d(TAG, "no

event found for device with id: " + deviceId + " and pluginId:" + pluginId);

return null;

if (c.moveToFirst()){

long id =
c.getLong(c.getColumnIndex(KEY_EVENT_ID));

String name =
c.getString(c.getColumnIndex(KEY_EVENT_NAME));

String desc =
c.getString(c.getColumnIndex(KEY_EVENT_DESC));

int visualizer =
c.getInt(c.getColumnIndex(KEY_EVENT_VISUALIZER));

float minVal =
c.getFloat(c.getColumnIndex(KEY_EVENT_VISUALIZER_MIN));

float maxVal =
c.getFloat(c.getColumnIndex(KEY_EVENT_VISUALIZER_MAX));

char flag = (char)

c.getInt(c.getColumnIndex(KEY_EVENT_FLAG));

String packageName=
c.getString(c.getColumnIndex(KEY_EVENT_PACKAGE_NAME));

String editClassName=
c.getString(c.getColumnIndex(KEY_EVENT_EDIT_CLASS_NAME));

String
serviceClassName=
c.getString(c.getColumnIndex(KEY_EVENT_SERVICE_CLASS_NAME));
 e = new Event(id, name,
desc, visualizer, flag, packageName, editClassName,

serviceClassName, pluginId,
deviceId);

e.visualizerMinValue =
minVal;

e.visualizerMaxValue =
maxVal;

c.close();

return e;

/**

* Return a list of all events for a given device

* @return ArrayList of all events for the given device

*/

public ArrayList<Event> fetchEvents(long deviceId) {

ArrayList<Event> events = new

ArrayList<Event>();

Cursor c = mDb.query(EVENT_TABLE_NAME, null,

KEY_EVENT_DEVICE_ID + "=" + deviceId ,

null, null, null, null);

if (c == null){
 if (DEBUG) Logger.d(TAG, "no
events found for device with id: " + deviceId);

return events;

if (c.moveToFirst()){

do {

long id =
c.getLong(c.getColumnIndex(KEY_EVENT_ID));

String name =
c.getString(c.getColumnIndex(KEY_EVENT_NAME));

String desc =
c.getString(c.getColumnIndex(KEY_EVENT_DESC));

int visualizer =
c.getInt(c.getColumnIndex(KEY_EVENT_VISUALIZER));

float minVal =
c.getFloat(c.getColumnIndex(KEY_EVENT_VISUALIZER_MIN));

float maxVal =
c.getFloat(c.getColumnIndex(KEY_EVENT_VISUALIZER_MAX));

char flag = (char)

c.getInt(c.getColumnIndex(KEY_EVENT_FLAG));

String packageName=
c.getString(c.getColumnIndex(KEY_EVENT_PACKAGE_NAME));

String editClassName=
c.getString(c.getColumnIndex(KEY_EVENT_EDIT_CLASS_NAME));

String serviceClassName=
c.getString(c.getColumnIndex(KEY_EVENT_SERVICE_CLASS_NAME));

int pluginId =
c.getInt(c.getColumnIndex(KEY_EVENT_PLUGIN_ID));

Event e = new Event(id, name,

desc, visualizer, flag, packageName, editClassName,
 serviceClassName, pluginId,
deviceId);

e.visualizerMinValue =
minVal;

e.visualizerMaxValue =
maxVal;

events.add(e);

if (DEBUG) Logger.d(TAG,
"event found: " + e.name + " - id=" + e.pluginId);

while(c.moveToNext());

else {

if (DEBUG) Logger.d(TAG, "no

events found for device with id: " + deviceId);

c.close();

return events;

public int updateEvent(Event event){

ContentValues values = new

ContentValues();

values.put(KEY_EVENT_VISUALIZER, event.visualizer);
values.put(KEY_EVENT_VISUALIZER_MIN, event.visualizerMinValue);

values.put(KEY_EVENT_VISUALIZER_MAX, event.visualizerMaxValue);

return
mDb.update(EVENT_TABLE_NAME, values, KEY_EVENT_ID + "=" + event.id,
null);

Monitoring.java

/*

Amarino - A prototyping software toolkit for Android and Arduino

Copyright (c) 2010 Bonifaz Kaufmann. All right reserved.

This application and its library is free software; you can redistribute

it and/or modify it under the terms of the GNU Lesser General Public

License as published by the Free Software Foundation; either

version 3 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

GNU
 Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public

License along with this library; if not, write to the Free Software

Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

*/

package at.abraxas.amarino;

import android.app.Activity;

import android.app.AlertDialog;

import android.app.Dialog;

import android.content.BroadcastReceiver;

import android.content.Context;

import android.content.DialogInterface;

import android.content.Intent;

import android.content.IntentFilter;

import android.hardware.SensorListener;

import android.hardware.SensorManager;

import android.os.Bundle;

import android.os.Handler;

import android.preference.PreferenceManager;

import android.view.MotionEvent;

import android.view.View;

import android.view.View.OnTouchListener;

import android.widget.Button;

import android.widget.EditText;

import android.widget.ScrollView;
import android.widget.TextView;

import android.widget.Toast;

import at.abraxas.amarino.log.LogListener;

import at.abraxas.amarino.log.Logger;

public class Monitoring extends Activity implements LogListener,

View.OnClickListener,SensorListener {

private static final int

DIALOG_FLAGS = 1;

private static final int

DIALOG_DEVICES = 2;

private static final String

KEY_FLAG_PREF = "flag_pref";

private static final int

MAX_ENTRIES = 400;

private Button monitoringBtn;

private Button flagBtn;

private EditText
dataToSendET;

private ScrollView
logScrollView;

private TextView logTV;

private Handler handler;

private int logEntries = 0;

private boolean monitoring;

 private boolean userTouch =
false;

String[] addresses; // connected

devices

String[] flags;

char selectedFlag;

SensorManager sm = null;

@Override

protected void onCreate(Bundle

savedInstanceState) {

super.onCreate(savedInstanceState);

setTitle(R.string.monitoring_title);

setContentView(R.layout.monitoring);

handler = new Handler();

sm = (SensorManager)
getSystemService(SENSOR_SERVICE);

monitoringBtn =
(Button)findViewById(R.id.monitoring_btn);

flagBtn =
(Button)findViewById(R.id.flag_btn);
 dataToSendET =
(EditText)findViewById(R.id.data_to_send);

logScrollView =
(ScrollView)findViewById(R.id.log_scroll);

logTV =
(TextView)findViewById(R.id.log);

logTV.setText("==========
Logging Window ==========\n");

monitoring =
PreferenceManager.getDefaultSharedPreferences(Monitoring.this)

.getBoolean(Logger.KE
Y_IS_LOG_ENABLED, true);

updateMonitoringState();

findViewById(R.id.send_btn).setOnClickListener(this);

findViewById(R.id.clear_btn).setOnClickListener(this);

monitoringBtn.setOnClickListener(this);

flagBtn.setOnClickListener(this);
logScrollView.setOnTouchListener(new View.OnTouchListener() {

public boolean
onTouch(View v, MotionEvent event) {

if (!userTouch
&& event.getAction() == MotionEvent.ACTION_DOWN){

userTouch
= true;

else if (userTouch
&& event.getAction() == MotionEvent.ACTION_UP){

userTouch
= false;

return false;

});

setupFlagsArray();

selectedFlag =
(char)PreferenceManager.getDefaultSharedPreferences(this).getInt(KEY_FLAG_PRE
F, 65); // default 'A'

flagBtn.setText(getString(R.string.flag_btn, selectedFlag));

IntentFilter intentFilter = new

IntentFilter(AmarinoIntent.ACTION_CONNECTED_DEVICES);

registerReceiver(receiver,
intentFilter);
 Intent intent = new
Intent(Monitoring.this, AmarinoService.class);

intent.setAction(AmarinoIntent.ACTION_GET_CONNECTED_DEVICES);

Monitoring.this.startService(intent);

private void setupFlagsArray() {

flags = new String[52];

for (int i=0;i<52;i++){

char flag;

if (i<26)

flag = (char) ('A'

+ i);

else

flag = (char) ('a'

+ i-26);

flags[i] =
String.valueOf(flag);

@Override

protected void onStart() {

super.onStart();

logScrollView.fullScroll(View.FOCUS_DOWN);
 }

@Override

protected void onStop() {

super.onStop();

// remember last selected flag

PreferenceManager.getDefaultSharedPreferences(this).edit()

.putInt(KEY_FLAG_PR
EF, selectedFlag).commit();

Logger.unregisterLogListener(this);

unregisterReceiver(receiver);

sm.unregisterListener(this);

private void
clearLogClickHandler(View target){

logTV.setText("==========
Logging Window ==========\n");

Logger.clear();

updateMonitoringState();

}
 private void
updateMonitoringState(){

if (monitoring) {

monitoringBtn.setText("Disable
Monitoring");

logTV.append("Monitoring
enabled!\n");

logTV.append(Logger.getLog());

logScrollView.smoothScrollBy(0,
logTV.getHeight());

Logger.registerLogListener(this);

Logger.enabled = true;

else {

monitoringBtn.setText("Enable
Monitoring");

Logger.enabled = false;

Logger.unregisterLogListener(this);

logTV.append("Monitoring
disabled!\n");

}
 private void sendData(String
address, String msg){

Intent intent = new

Intent(Monitoring.this, AmarinoService.class);

intent.setAction(AmarinoIntent.ACTION_SEND);

intent.putExtra(AmarinoIntent.EXTRA_DEVICE_ADDRESS, address);

intent.putExtra(AmarinoIntent.EXTRA_FLAG, selectedFlag);

intent.putExtra(AmarinoIntent.EXTRA_DATA_TYPE,
AmarinoIntent.STRING_EXTRA);

intent.putExtra(AmarinoIntent.EXTRA_DATA, msg);

Monitoring.this.startService(intent);

public void logChanged(final

String lastAddedMsg) {

logEntries++;

handler.post(new Runnable() {
 public void run() {

if (logEntries >
MAX_ENTRIES){

int size =
logTV.getText().length();

logTV.setText(logTV.getText().subSequence(size/2, size));

logEntries
/= 2;

logTV.append(lastAddedMsg +
"\n");

if (!userTouch){

logScrollView.post(new
Runnable() {

public void run() {

logScrollView.smoothScrollBy(0,
60);

});

});

}
 @Override

protected Dialog onCreateDialog(int id) {

switch (id) {

case DIALOG_FLAGS:

return new
AlertDialog.Builder(Monitoring.this)

.setTitle("Choose
your flag")

.setItems(flags,
new DialogInterface.OnClickListener() {

public void
onClick(DialogInterface dialog, int which) {

String flag = flags[which];

flagBtn.setText(Monitoring.this.getString(R.string.flag_btn, flag));

selectedFlag = flag.charAt(0);

})

.create();

case DIALOG_DEVICES:

return new
AlertDialog.Builder(Monitoring.this)

.setTitle("Send data to:")

.setItems(addresses, new
DialogInterface.OnClickListener() {
 public
void onClick(DialogInterface dialog, int which) {

sendData(addresses[which],
dataToSendET.getText().toString());

})

.create();

return null;

@Override

public boolean
onTouchEvent(MotionEvent event) {

Toast.makeText(this,
"touch events from screen",60000).show();

//sendData(addresses[0],
"4");

return true;

public void
onSensorChanged(int sensor, float[] values) {

synchronized (this) {

Toast.makeText(this,
"sensorvalue changing",60000).show();

if (sensor ==
SensorManager.SENSOR_ORIENTATION) {
 if(values[2]>4.5){

sendData(addresses[0], "4");

else
if(values[2]<4.5){

sendData(addresses[0], "3");

else{

sendData(addresses[0], "1");

public void onClick(View v) {

switch (v.getId()){

case R.id.monitoring_btn:

sm.registerListener(Monitoring.this,

SensorManager.SENSOR_ORIENTATION |

SensorManager.SENSOR_ACCELEROMETER,

SensorManager.SENSOR_DELAY_NORMAL);
 /*monitoring = !
monitoring;

PreferenceManager.getDefaultSharedPreferences(Monitoring.this)

.edit()

.putBoolean(Log
ger.KEY_IS_LOG_ENABLED, monitoring)

.commit();

updateMonitoringState();*/

break;

case R.id.flag_btn:

//showDialog(DIALOG_FLAGS);

sm.unregisterListener(this);

sendData(addresses[0],
"2");

break;

case R.id.send_btn:

if (addresses == null){

Toast.makeText(Monitoring.this, "No connected device found!\n\nData not sent.",

Toast.LENGTH_SHORT).show();
 }

else if (addresses.length
== 1){

sm.unregisterListener(this);

sendData(addresses[0], "5");

else {

// several
connected devices, we need to show a dialog and ask where to send the data

showDialog(DIALOG_DEVICES);

break;

case R.id.clear_btn:

//clearLogClickHandler(v);

sm.unregisterListener(this);

sendData(addresses[0],
"1"); break;

}}

BroadcastReceiver receiver =
new BroadcastReceiver() {

@Override
 public void onReceive(Context
context, Intent intent) {

String action =
intent.getAction();

if (action == null)
return;

If

(AmarinoIntent.ACTION_CONNECTED_DEVICES.equals(action)){

addresses =
intent.getStringArrayExtra(AmarinoIntent.EXTRA_CONNECTED_DEVICE_ADDR
ESSES);

};

Public void
onAccuracyChanged(int arg0, int arg1) {

// TODO Auto-generated
method stub

}
 Conclusion and Future Developments

 Speed : automating processes speeds up the production in industries.

 Precision: Pick and place systems are almost 100% accurate in their operations,
much more than a human being can ever be.
 Reliability : This enables a manufacturing unit to churn out products in almost no
time at all. This in turn, leads to considerable revenues.

 Flexibility :A slight tweak in the programming controls or a few twists and turns of
the tools are all that is needed to equip a pick and place system with the capability to
deal with multiple applications.

 Cost-Effectiveness : these systems ultimately bring in riches for a business.

Robot can be programmed to move within specific limits.

 If a business owner desires to change how the robot moves, he might consider
purchasing extensions for the robot's arms or changing its orientation.

 It can be advanced to use in crucial environments like Underground Coal mining,

Hazardous utility company operations.

REFERENCES

BOOKS

 PIC MICROCONTROLLER BOOK By : NEBOJSA MATIC

 The 8051 Microcontroller and Embedded Systems
By: Muhammad Ali Mazidi, Janice Gillispie Mazidi, Rolin D. McKinlay
 Automobile Engineering vol-1 and vol-2 by Kirpal Singh

WEBSITES

http://howstuffworks.com

http://ehow.com

http://whynot.com

http://britanica.com

http://wikipedia.com

http://national.com

http://google.com

http://gaadiwala.com