Robotics and Autonomous Systems
Project Report

---

Presented By:
Team members:
HeijkenskjOld, Hannes
Kalen, Martin
MalmesjO, Stefan

---

Abstract
This is a report of the project for the course 2D1426 Robotics and Autonomous Systems. It describes the ideas and the design of the Ad Hoc robot. It covers the main design goals, implementation and results.
The goal of the robot was to play table hockey, and above all to be able to score a goal. This was actually accomplished during the qualification round for a table hockey tournament. However, the robot never managed to score during any of the actual games. It was built of Lego bricks, and controlled by a micro controller.
The task at hand
The task of the project was to build and program a robot that could play table hockey with special rules, and that fulfilled constraints on the construction. The robot was to be built from Lego bricks and meccano, with the addition of whatever bits and pieces the constructors thought necessary. The teams were assigned two 12 V DC motors, one 6 V motor and an RC servo, which were used for locomotion and for manipulating the stick. The robot was controlled by a small 8-bit micro controller (see Appendix 1 - Parts List; PIC16F877 and [4]). To find its way on the hockey field, the robot could be equipped with a variety of sensors, such as Infra Red light sensors, reflex detectors and micro switches.
The constraints imposed on the robot were among others the following (for complete rules see [5] and [6, Part III]):
¢ Diameter of the body was to be less than 250 mm.
¢ No concave part on the body.
¢ The stick could be no wider or longer than the puck, and should not hide the latter's IR emitters.
¢ The stick could have no moving joints outside the robot's body.
Fig. 1 The hockey field
The hockey field (see Fig. 1) is a white surface, 2.4 x 1.2 m, with a black goal zone in both ends. The robot was not allowed to enter either goal zone, so some kind of sensing of the proximity to the zone was necessary. Both goals emit IR light with different pulse modulations, as does the puck. In order to be able to see each other, the competing robots also radiate IR (see Appendix 1 - Parts List; SFH485P and [3]) with modulation different from that of the puck and the goals.
To score a goal, the puck had to be put within 2 cm of the opponent's goal, without the robot entering the goal zone. Pushing or shooting the puck into the goal could accomplish this. If the robot entered the zone the goal was not counted.
Given these premises, the team designed, built and programmed the Ad Hoc robot. This report presents the design ideas, goals and implementation, and the final results and conclusions.
Design
The main goal of the overall design of the robot was to have a small, agile and fast robot, being able to outmaneuver the opponent and scoring a goal by driving the puck into goal with high speed. The team's goal for the robot was to have several behaviors, and then somehow weigh these together in order to achieve a "smart" result. To do this, vector summation was used, where each behavior contributed with one vector.
Sensing and sensory processing
Three different kinds of sensors were used in the construction; IR detectors (see Appendix 1 - Parts List; TSL261), reflex detectors (see Appendix 1 - Parts List; ITR8307) and micro switches. The input from these devices was used for decision making in navigation. The IR detectors were used to determine direction and distance to the goals, the puck and the opponent (see [2]). The reflex detectors were used to tell whether the robot were in a goal zone or not. The micro switches were used to detect if the robot had run into something. They were also used to determine whether the puck was in the possession of the robot or not. Two different code libraries were used for sensory input, bumplib and ir_servo.
IR
The robot had a separate processor, PIC16F876 (see [4]), which handled both IR signals and the R/C servo. This processor was preprogrammed so it could make out the difference between the four incoming IR signals: the puck, the opponent, the defensive goal and the offensive goal. These four targets continuously sent IR pulses, but they did so with different frequencies, so that they could be separated by the IR-PIC, and the targets distinguished.
Five IR sensors, TSL261 (see [2]), were placed on the robot. Two situated in the front (they were placed in 90° angle), twointhe rear (also 90°), and one forward facing sensor in the front. The four ones first mentioned, called "high sensors", were mainly used for estimating the direction to the target - but also the distance from it. The sole front sensor, called "low sensor", was used to measure the distance.
Fig. 4 Front IR sensors Fig. 5 Rear IR sensors and IR position beacon
Since the sensor values were sensitive to disturbances, and hence had a considerable amount of noise, mean value calculation over the two last readings was used, in order to get better values.
The exact angle to the target was never calculated. Instead, a relative measurement of the IR readings was done. First, the difference between the sum of the two rear sensors and the sum of the two front sensors was calculated. This way it was determined whether the target was in front of or behind the robot. Analogously, it was calculated whether the target was to the left or the right of the robot. The relative difference between the calculated values was used in order to calculate how much to turn each of the wheels. This worked rather well.
Whenever the need for calculating the distance to a target (for example a goal) arose, the way to figure it out was to use the strength of the IR readings. These were calibrated for each individual task, to fit accordingly. It would show that this was harder than originally thought, since the absolute value of the readings varied significantly from run to run.
IR filtering was controlled by the slave micro controller. The only thing that had to be handled in software was the interrupt generated when a complete byte had been sent on the serial line between the two processors (SPI) and to receive the IR data in correct order. This was done in the service routine in the ir_servo library ir_sevice_routine().
Reflex detectors
Under the robot, facing down toward the table, four reflex detectors were placed - one in each corner of the robot. These detectors sent out IR light, and measured how much was reflected from the surface of the hockey field (see parts list and [1]). This reflection was presented to the robot with a value between 0 (white) and 255 (black), after converting the analog signal with the PIC's built-in A/D converter. The reflex detectors were connected to the AN-ports (analog in). The function bump_poll_sensors() in bumplib was used to run the A/D converter to sample all reflex detector channels.
This information was used for estimating whether the robot was going into a goal zone or not, which was not allowed. Since the field had a black stripe for marking the middle of the field, the reflex detectors together with information from the IR sensors were used to estimate if the robot was in a goal zone or merely on the middle field stripe. So if the reflex detectors signaled black surface, and the IR sensors signaled goal proximity, then robot was positioned in a forbidden zone, and hence had to quit going in that direction.
Micro switches
The micro switches were used for tactile sensing. Attached to the micro switches the robot had antennae, which would depress the switches if it ran into something. Seven switches were used; one placed in each corner of the robot, one on the stick, and two in the front of the robot. The two in the front were used for detecting puck possession, and the others were used for obstacle detection. All bumpers and an optional emergency stop were connected to PORTB on the PIC. The function bump_poll_sensors() in bumplib was used to update bumper status, e.g. reading PORTB. As mentioned in the "Reflex detectors" section above, this function also samples reflex detectors.
Locomotion and navigation
There are different ways of moving a robot. The Ad Hoc robot was built with two wheels, which were run independently of each other using two separate 12 V motors. This made it possible for the robot to turn around on the spot if necessary, by running the wheels in opposite directions. In order for the robot to keep its balance, a small, smooth piece of Lego, placed in the front, was used for support.
For navigation the team used a behavioral approach. The idea was to program the robot with several behaviors, active at the same time. They were all to have their own will, and then some coordinator was to combine these wills, and produce some appropriate action for the robot. Each behavior should produce a "wish vector", telling the direction in which the behavior "wanted" to go. This way all the behaviors got to tell their wish, and then vector summation was used to calculate a final direction for the robot. Depending on in which state the robot was (having the puck or not) the different behaviors' wishes were assigned different weight, which were used in the vector summation.
There were five different behaviors in the robot.
¢ The find puck behavior - always wanted to go toward the puck, unless the puck already was in the robot's possession. If the robot for some reason didn't see the puck, it simply spun around, trying to locate the puck.
¢ The get puck to goal behavior - always wanted to go toward the offensive goal, as long as the robot had the puck.
¢ Avoid obstacles behavior - if the robot ran into something, this behavior tried to go in a different direction from the original one. It also stopped the robot from going into a goal zone.
¢ Avoid opponent behavior - tried to get the robot not to run into the opponent.
¢ Random behavior - produced a random (small) wish. This was to avoid that the other behaviors would sum up to a no wish, i.e. to wish the robot in exactly opposite directions. A small random vector wouldn't affect the behaviors normally, but in such a case it could add enough to get the robot out of the clash.
All different behaviors were implemented in the behavior module and the wish summation and actual motor speed settings done in the main file, function sequencer().
Manipulation
In order to be able to control the puck, the robot had a stick - seen in the figures below. The stick design was somewhat problematic, since the robot should be able to turn in different directions and still keep the puck (if the robot had it, of course). The team decided that the best way to achieve this was by swinging the stick over the puck, not just from the right to the left - which would have made us lose the puck more easily. In order to achieve this, an R/C servo was connected to the stick, to be able to steer it into the appropriate position at all times.



3
The appropriate position is dependent of the robot's current state. If in possession of the puck (which was determined by combining the information from the front bumpers and the IR readings), the robot should keep the stick on the opposite side from the direction in which the robot was turning. This would make the stick swing virtually all the time, if not suppressed by a turning rate threshold in the software. If the robot were to turn less than this threshold value, the stick swing was skipped. This proved to work rather well; the robot could turn pretty much without loosing the puck.
In the code, the check_club() function in the main program file was used to position the stick on the appropriate side of the puck. If the robot had possession of the puck and it was turning rather fast, the motors were stopped until the stick swing was complete. Otherwise, e.g. if approaching the puck from a distance, there was no need to stop the robot and move the stick all the time, so in this case the function would exit right away. This proved to be rather successful as fast movements from side to side were not carried out at all. The ir_servo lib was used for the actual servo position setting, as servo positioning was also controlled by the slave PIC and sent through the SPI interface used for IR data reception. The function servo_set_club() and the macros CLUB_LEFT and CLUB_RIGHT were used for setting the right position data to transmit on the SPI line.
Integration of the above
To put all this together, a state machine was implemented, which kept the robot in the correct state at all times. There were three states, but more could easily have been added, if needed. The three states were "Have puck", "Don't have puck", and "Score". The "Score" state was rather special, so a completely predefined movement was used for that one. The other two weighed all the behaviors' wishes together, and used vector summation to calculate a final direction vector. In both of these states, the most important behavior was to avoid obstacles (among other things because the robot was not allowed to enter the goal zones), so the weight of this behavior was greater than the sum of the weights of the rest of the behaviors. This way, the avoid obstacles behavior would always get its way. The avoid opponent behavior had a weight that was determined by switches on the motherboard (see section Electronics; DIP switches) with a value ranging from 0 to 3, setting the overall "aggressiveness" of the robot. The random behavior was set to a low weight, so it wouldn't interfere with the others too much. The only use for the random behavior was to avoid livelock, when all the other behaviors' wishes would add up to a zero vector.
¢ Don't have puck - here the find puck behavior was important, so the weight was set rather high.
¢ Have puck - now the robot's goal was to get the puck to goal, which is why the weight for that behavior was set
high.
The "statemachine" was implemented in the main program file, with behavior activation in the main() function and state control in the decice_state() function.
After the main loop had asked all the behaviors to tell their wishes, the sequencer was told to carry out the order. The sequencer then did the vector summation from all the behaviors' wishes. When it knew which way to go, it decided whether or not to swing the stick, and then it gave speed orders to the two wheels, so that the robot would move in the wanted direction.
The score state was activated whenever the robot was in possession of the puck, was facing toward the opponent's goal, and was close to it. In order for the robot to always try to score, regardless of the opponent's position, a completely separate movement scheme was programmed for this purpose. In order to accomplish this, the robot was set to the maximal speed possible (so the puck would get enough velocity to reach all the way to the goal when the robot stopped at the goal zone), and then kept an eye at the IR readings to know when enough proximity to the goal was achieved. When the robot got close enough - or when the reflex detectors signaled that the robot was in the goal zone - it would stop, and hope that the puck would get into the goal.
Software implementation
Behaviors
Each behavior described in Locomotion and navigation is implemented in a function in behavior.c (see Appendix 4 -Source Code). These functions calculate a wish vector, indicating in which direction the behavior 'wishes' to go. The behavior algorithms work as follows:
¢ behavior_get_puck() - This behavior uses the IR readings of the puck to determine if the puck is in front of or behind the robot, and if the puck is to the left or the right of the robot, as described in the section IR above. If the readings are too small on all sensors, the puck is not seen, and the wish vector is set to full right spin. If the puck is behind the robot, the y-component of the vector (forward-backward component) is set to zero, because the robot shouldn't back into the puck. When the puck is in front of the robot, the x-component (left-right component) of the wish vector is set to zero if below a certain threshold, in order to avoid an oscillating behavior when closing in on the puck. Otherwise, the largest of the x and y values is set to MAX_WISH, and the other is scaled accordingly.
¢ behavior_puck_to_goal() - This behavior uses almost the same approach as behavior_get_puck() when calculating where the target is. The main difference is that no consideration is taken as to whether the goal is behind the robot. This is because the vast amount of disturbances from other IR sources, which makes it virtually impossible to find the goal in a reasonable manner when the goal is behind the robot. Instead the behavior assumes that if the goal isn't in front of the robot, it can be found behind the robot, hence the behavior wants to stand and turn in order to try to find the target. On the other hand, if the goal is in front of the robot, the same scaling of the x and y vector components as in the behavior_get_puck() is carried out.
¢ behavior_avoid_opponent() - This behavior is the opposite of behavior_get_puck(), but when talking about the opponent, not the puck. The wish vector is calculated in the exact same manner, and then the direction is reversed in order to get a repelling conduct. One difference is that if the opponent isn't seen, the behavior doesn't want to turn around to try to find it. Instead a zero wish is produced.
¢ behavior_avoid_obstacles() - Tries to avoid running into obstacles. To accomplish this, the behavior investigates whether any of the micro switches has been depressed. If this is the case, the behavior wishes to go in the opposite direction from where the depressed switch is situated. The input from the front bumpers is suppressed when carrying the puck, since otherwise the behavior will interpret the puck as an obstacle. More important is the reflex detector inputs, used to avoid running into the goal zones. If any of the reflex detectors indicates that the surface is black, and the IR sensors give a strong goal signal reading, the behavior assumes that the robot is in a goal zone, be it offensive or defensive, and therefore gives a strong wish to go in the reverse direction.
¢ behavior_random() - produces a small random wish, in order to avoid livelocks. This wish is small enough not to disturb the other behaviors' wishes, but sufficient enough to generate a movement if all the other behaviors' wishes were to sum up to zero.

[attachment=11797]
RF Controlled SPY ROBOT
ABSTRACT
We cannot forget 9/11 when 101 people including nine foreigners and 14 policemen have lost their lives while about 300 people were injured in the worst terror attack seen in the country in which desperate men fired indiscriminately at people. Being an ex– defense person, my blood was boiling as our brave soldiers were fighting the militants to free all the hostages from Mumbai hotels. It struck an idea in my mind, why can’t we make a robot to tackle such type of situation.
Out new Combat robot is pc operated , it has got two barrel turret through bullet can be fired, pc camera in synchronization with the turret can rotate up and down ,left and right up to a safe firing limit. turret and camera mechanism has been installed on my spy robot vehicle, which has all the function like tank, Turing to any angle on its axis, moving forward and reverse turning left and right, running instantly into reverse direction.
This robot is radio operated self powered, and has all the controls like a normal car. A pair of laser gun has been installed on it, so that it can fire on enemy remotely when required this is not possible until a wireless camera is installed. Wireless camera will send real time video and audio signals which could be seen on a remote monitor and action can be taken accordingly. It can silently enter into enemy area and send us all the information through its’ tiny camera eyes. It is designed for, fighting as well as suicide attack.
Chapter 1
Introduction
RF Controlled spy robt is an exclusive project where the direction of the movement of Robot can be changed using wireless technologies. The Robot will be placed different from that of from where it is controlled. This project can also be carried out using wiring processes. But the main disadvantage when we go for wiring is that, data transmission and reception may not be perfect and the data may be lost if the wiring is not done properly. Thus, the Robot movement is controlled using wireless concept in this project. In this project, the controlling of the Robot is done from the transmitter and this information will be passed to the Robot in a wireless fashion.
There are several wireless technologies to accomplish this task. The protocol used in this project is RF Technology.
To control the direction of the Robot, predefined keys has to given as commands from the transmitter section. The data from the transmitter section is transmitted and will be received by microcontroller at the receiver section. The data, while before being transmitted, will be converted into a format suitable for transmission. i.e., data will be encoded.
At the receiving end, the receiver section receives this data. The data received will be decoded being before given to the microcontroller for further processing. Now, it is the job of the controller to read the data and perform the corresponding action i.e., move the Robot in that particular direction based on the command received from the transmitter end. The microcontroller at the receiver end continuously receives the video signal from a wireless camera which is attached to the robo and this robot is used to capture the video of the criminal and observe their position remotely in a TV or a PC and we can even attack by firing the gun attached to this robot if the target is confirmed.
1.1 Objective of the project
The project aims at making the robot to move in a particular direction, connected at the receiver side, specified by the user at the transmitter side using RF technology. The project uses the RF technology, wireless camera and Embedded Systems to design this application. The main objective of this project is to design a system that continuously checks for the data received from the transmitter section and also monitor video captured by the and transmit the same to remotely placed TV or a PC and we can even attack by firing the gun attached to this robot if the target is confirmed.
This project is a device that collects data from the transmitting section, codes the data into a format that can be understood by the controlling section. This receiving section controls the direction of the robot as per the command received from the transmitter section.
The objective of the project is to develop a microcontroller based control system. It consists of a switch control module, wireless camera, RF transmitter and receiver section, microcontroller and the robotic arrangement.
1.2 Background of the Project
The software application and the hardware implementation help the microcontroller read the data received from the transmitter section and accordingly change the direction of the robot. The performance of the design is maintained by controlling unit.
1.3 Organization of the Thesis
In view of the proposed thesis work explanation of theoretical aspects and algorithms used in this work are presented as per the sequence described below.
Chapter 1 describes a brief review of the objectives and goals of the work.
Chapter 2 discusses the existing technologies and the study of various technologies in detail.
Chapter 3 describes the Block diagram, Circuit diagram of the project and its description. The construction and description of various modules used for the application are described in detail.
Chapter 4 explains the Software tools required for the project, the Code developed for the design.
Chapter 5 presents the results, overall conclusions of the study and proposes possible improvements and directions of future research work.
Chapter 2
Overview of the technologies used
Embedded Systems:
An embedded system can be defined as a computing device that does a specific focused job. Appliances such as the air-conditioner, VCD player, DVD player, printer, fax machine, mobile phone etc. are examples of embedded systems. Each of these appliances will have a processor and special hardware to meet the specific requirement of the application along with the embedded software that is executed by the processor for meeting that specific requirement.
The embedded software is also called “firm ware”. The desktop/laptop computer is a general purpose computer. You can use it for a variety of applications such as playing games, word processing, accounting, software development and so on.
In contrast, the software in the embedded systems is always fixed listed below:
• Embedded systems do a very specific task, they cannot be programmed to do different things. Embedded systems have very limited resources, particularly the memory. Generally, they do not have secondary storage devices such as the CDROM or the floppy disk. Embedded systems have to work against some deadlines. A specific job has to be completed within a specific time. In some embedded systems, called real-time systems, the deadlines are stringent. Missing a deadline may cause a catastrophe-loss of life or damage to property. Embedded systems are constrained for power. As many embedded systems operate through a battery, the power consumption has to be very low.
• Some embedded systems have to operate in extreme environmental conditions such as very high temperatures and humidity.
Following are the advantages of Embedded Systems:
1. They are designed to do a specific task and have real time performance constraints which must be met.
2. They allow the system hardware to be simplified so costs are reduced.
3. They are usually in the form of small computerized parts in larger devices which serve a general purpose.
The program instructions for embedded systems run with limited computer hardware resources, little memory and small or even non-existent keyboard or screen.
RF Technology:
RF refers to radio frequency, the mode of communication for wireless technologies of all kinds, including cordless phones, radar, ham radio, GPS and radio and television broadcasts. RF technology is so much a part of our lives we scarcely notice it for its ubiquity. From baby monitors to cell phones, Bluetooth to remote control toys, RF waves are all around us. RF waves are electromagnetic waves which propagate at the speed of light, or 186,000 miles per second (300,000 km/s). The frequencies of RF waves, however, are slower than those of visible light, making RF waves invisible to the human eye.
The frequency of a wave is determined by its oscillations or cycles per second. One cycle is one hertz (Hz), 1,000 cycles is 1 kilohertz (KHz). A station on the AM dial at 980, for example, broadcasts using a signal that oscillates 980,000 times per second or has a frequency of 980 KHz. A station a little further down the dial at 710 broadcasts using a signal that oscillates 710,000 times a second, or has a frequency of 710 KHz. With a slice of the RF pie licensed to each broadcaster, the RF range can be neatly divided and utilized by multiple parties.
Every device in the United States that uses RF waves must conform to the Federal Communications Commission's (FCC) regulations. A baby monitor, for example, must operate using the designated frequency of 49 MHz. Cordless phones and other devices have their own designated frequencies.

[attachment=11915]
RF BASED SPY ROBOT
Introduction:
Robotics is a fascinating subject- more so, if you have to fabricate a robot yourself. The field of robotics encompasses a number of engineering disciplines such as electronics (including electrical), structural, pneumatics and mechanical.
The structural part involves use of frames, beams, linkages, axles, etc. the mechanical parts/ accessories comprise various types of gears (spurs, crowns, bevels, worms and differential gear systems), pulleys and belts, drive systems(differentials, castors, wheels and steering) etc. The pneumatics plays a vital role in generating specific pushing and pulling movements such as those simulating arms or leg movement. Pneumatic grippers are also used with advantage in robotics because of their simplicity and cost effectiveness. The electrical items include DC and Stepper motors, actuators, electrical grips, clutches and their control. The electronic parts involves remote control, sensors (touch sensors, light sensor, collision sensor, etc), there interface circuitry and a microcontroller for overall control functions.
CHAPTER -2
CIRCUIT DISCRIPTION AND WORKING
Project Overview:
What we present here is an elementary robotic land rover that can be control remotely using primarily the RF mode. The RF remote control has the advantage of adequate range (up to 200m with proper antenna) besides being omni directional. On the other hand, an IR remote would function over a limited range of about 5m and the remote transmitter has to be oriented towards the receiver module quite precisely. However, the cost involve in using RF modules is much higher than that of IR components and as such, we have included the replacement alternative of RF modules with their IR counterparts for using the IR remote control.
The proposed land rover can move in forward and reverse direction. You will also be able to steer it towards left and right directions. While being turn to left and right, the corresponding blinking LEDs would blink to indicate the direction of its turning. Similarly, during reverse movement, reversing LEDs would be lit. Front and rear bumpers are provided using long operating lever of micro switches to switch off the drive motors during any collision. The decoder being used for the project has latch outputs and as such you don’t have to keep the buttons on remote control pressed for more than a few milliseconds. This helps prolong the battery life for remote.
The entire project is split up into sections and each section is explain in the sufficient detail to enable you not only to fabricate the present design but also exploit this principles for evolving your own design with added functions.
Forward and reverse movement:
To keep your design as simple as possible, we have coupled a 30rpm geared 6v DC motor to the left front wheel and another identical motor to the right front wheel. Both these front motors are mounted side by side by facing in opposite direction. Wheel rims (5cm diameter) along with rubber wheels are directly coupled to each of the motor shafts. This arrangement does not require separate axles.
During forward (or reverse) movement of the vehicle, the two wheel shafts, as viewed from the motor ends, would move in opposite directions (one clockwise and the other anticlockwise). For reversing the direction, you simply have to reverse the DC supply polarity of the two motors driving the respective wheels.
Steering control:
There are different methods available for steering a robotic vehicle. The commonly used ones are:
1. Front wheels are used for steering, while rear wheels are used for driving eg. Tractors.
2. Front wheels are used for steering as well as driving eg, in most light vehicles. In these vehicles (such as cars), the front wheels are coupled using a differential gear arrangement. It comes into play only when one wheel needs to rotate differentially with respect to their axes.
Drive circuit for the motors:
Here is a typical circuit for driving one of the motors, in forward or reverse direction, coupled to, say the left hand front wheel. Simultaneously, the right direction for the moving the vehicle in the same direction. It means that input terminals of the motor drive circuit for the right hand motor have to be fed with reverse polarity control signals compared to those of the left hand motor drive circuit.
In the H-bridge motor drive circuit when A1 input is made high and A2 is made low, transistor T1(NPN) is forward biased and driven into saturation, while transistor T2 (PnP), being reverse biased, is cut off. This extends the battery’s positive rail to terminal1 of the motor. Simultaneously with input A2 at ground potential, transistor T3 (NPN) is cutoff, while T4 (PnP) is forward biased and driven into saturation. This results in ground being extended to terminal2 of the motor. Thus the motor rotates in one direction.
Now, if the two inputs are logically complemented, the motor will run in the opposite direction. When both the inputs are at the same logic level (gnd or vcc), the motor is at rest. Thus WI can control the movement (forward, reverse and stop) as well as the direction of rotation of the motor with the help of logic level of the two control input signals to the motor.

I need spy car circuit and details plz help me

to get information about the topic "spy robot" full report ppt and related topic refer the page link bellow

http://studentbank.in/report-mobile-cont...-spy-robot

http://studentbank.in/report-rf-based-sp...ull-report

i want to full reprt on RF based spy robot..........