|
|
| Line 1: |
Line 1: |
| − | __TOC__
| + | aa |
| − | | |
| − | Recently many research groups in the area of robotics have focused on a relatively new idea call swarm robotics. This approach takes its inspiration from the system-level functionality of social insects like ants, which demonstrate three desired characteristics for multi-robot systems: robustness, flexibility and scalability. The idea of using a team of robots instead of a single robot to execute a task came from the necessity of accomplishing a task that is too difficult or too complex for a single robot as well as the higher cost of a single robot. In some situations, using a group of simple robots can be more efficient, less expensive, and more fault-tolerant than having a single powerful, highly specialized robot for each desired task. Robot swarms generally interact with each others; therefore, a constantly reliable and stable communication among the robots and between the robots and a base station is necessary and useful.<br />
| |
| − | This paper presents a procedure for creating wireless sensor network communication among swarm robots that coordinate for cooperative task identification. The experiments in this project are conducted using V-REP Evolution simulator. The Lua programming language is used for developing software to enable the robots to communicate with each other and with a base station.
| |
| − | | |
| − | [[Image:drone.png|frame|none|alt=image]]
| |
| − | | |
| − | Figure 1: AR.Drone Swarm
| |
| − | | |
| − | AR. Drone wiki.<br />
| |
| − | http://www.ardrone-flyers.com/forum/viewtopic.php?f=10&t=3963&start=0
| |
| − | | |
| − | = Purpose: =
| |
| − | | |
| − | My ultimate goal in this project is to develop a wireless communication network for robot swarm. This network will allow the robots to function as a sensor array, while searching for a a given objective.
| |
| − | | |
| − | = Background: =
| |
| − | | |
| − | Deploying large numbers of small simple robots in a decentralized swarm-like fashion is gaining recognition and popularity in many problem domains, including establishing mobile sensor network communications, distributed sensing, robotic search and rescue applications, and so on. In order to do a job, these robots must work in parallel (Liemhetcharat, 2012). The need for these robots to be able to communicate with each other has led to the development of sensor networks.
| |
| − | | |
| − | A sensor is a device that produces a measurable response to a change in a physical condition. In robot swarm a sensor network is a series of robots that contain sensors, and use the results from these sensors, and communication with each other, to achieve some shared goal (Schwager, 2006).
| |
| − | | |
| − | Many times sensor networks are distributed, meaning that all of the robots share duties. Many network communications are on a client server setup, where one side gives directives to another. "A distributed network is communication among equals" (Caro, 2009). There is no one single error that can take down the system. Any single robot can be disabled, but the network itself will continue to function even losing a link (Caro, 2009).
| |
| − | | |
| − | Many applications benefit from such sensor networks. A network of robots can cover a large area, with each robot going in a different direction. A faster solution can be found if more than one path is taken at the same time, as with a sensor network. A group of robots is also less disposed to total failure. In other words, if one robot breaks down, the rest can still complete the objective. This makes sensor networks ideal for search and retrieval missions, where their large coverage and constant communications mimic that of a human search party.
| |
| − | | |
| − | There are also some problems with using sensor networks. The largest difficulty is the requirement to be able to constantly communicate with other robots, while mobile. This makes both line of site transmission systems, like infrared, and wire based solutions unfeasible. This communication must also be set up on the fly, as robot should able to enter and exit the communication process at any time (Bayindir, 2007).
| |
| − | | |
| − | The robots must also be aware of the other robots, and at least their relative position to it, in order to be able to effectively share information about their surroundings. It is not enough to know that X robot has found the objective. In order to use this information, it must know the location of the other robot.
| |
| − | | |
| − | Communication itself poses some challenges. If the robots are not in close contact with each other, messages must be passed from one robot to another in order to route them to a specific robot. When it is assumed the fact that any one node can fail at any time, this leads to problems.
| |
| − | | |
| − | = Problem Statement =
| |
| − | | |
| − | The goal is to develop a wireless communication sensor network for robot swarm. The network will allow the robots to communicate within a restricted space and exchange information. This network, developed using the V-REP simulation wireless communication sensor functions, will form a sensor network, in order to locate a given target in this case a light source.
| |
| − | | |
| − | This will require the following:<br />
| |
| − | 1. A wireless communication software system for multiple robots.<br />
| |
| − | 2. Designing the robot<br />
| |
| − | 3. Multiple-robot software simulation that allows wireless protocol programming<br />
| |
| − | 4. And producing the final research paper based on the project<br />
| |
| − | | |
| − | | |
| − | The software produced is an essential part of this project. It includes the robots design, network protocols, and software simulation running the robot. This project does not include hardware. It will only be implemented in a simulation.
| |
| − | | |
| − | = Design Constraints: =
| |
| − | | |
| − | The “wireless networks for robot swarm communication” project consists of requirements or goals that either must be or should be followed. Constraints that must be strictly followed are listed under the “must” category. Conditions that should be at least considered but are not critical to the application of the project are listed in the “should’s”.
| |
| − | | |
| − | == This project must: ==
| |
| − | | |
| − | All the robots must be able to navigate independently of other robots. Each robot must have the ability to search independently of the others. Also, it must have some sort of navigational protocol such as random pattern, expanding circle, or straight lines until a barrier is encountered.
| |
| − | | |
| − | All the robots must be able to maneuver around obstacles. When an obstacle is encountered, the robot should be able to take action to avoid a deadlock. Solutions to this problem includes: using infrared sensors, and visual cameras.
| |
| − | | |
| − | Search for a user specified target such as a light. Each robot has to be able to search for and find some predetermined target. The robots must know when it is close enough to the target. For example, if searching for a light, must determine when the brightness of the light is satisfactory.
| |
| − | | |
| − | Signal the other robots when the target is found. The discovering robot should send out a broadcast that it discovered the target.
| |
| − | | |
| − | Search for the robot that signals it has found the target. At that point it must supply some sort of tracking mechanism for the other robots to find its current location.
| |
| − | | |
| − | == This project should: ==
| |
| − | | |
| − | Sense obstacles to avoid contact. This could possibly allow the robots to save power by preventing them from sporadically changing directions upon contact with an obstacle. Allow for robots to search and rescue robots damaged or fall off network range.
| |
| − | | |
| − | Software may be tested on real hardware
| |
| − | | |
| − | = Validity criteria: =
| |
| − | | |
| − | The following criteria can be used in order to determine the validity of various solutions to the networking robots problem addressed in this project.
| |
| − | | |
| − | == Stability: ==
| |
| − | | |
| − | One of the greatest properties of a sensor network is how functions and data are distributed over the network. Each robot only does a small part of the job, and combined, they solve the task. Any sensor network software developed must have the ability to function whether or not all the robots are working or in the network range.
| |
| − | | |
| − | == Size: ==
| |
| − | | |
| − | Since the project does not include either building actual robots, the size of the swarm is not a problem. However, the simulator world must be large enough to require multiple robots to cover the area.
| |
| − | | |
| − | = Work in This Field =
| |
| − | | |
| − | Currently, there are several projects that have focused on wireless sensor networks at various universities and private labs. Some of these have reached a prototype stage.
| |
| − | | |
| − | == The iRobot Swarm ==
| |
| − | | |
| − | The iRobot Swarm, a robot swarm of over 100 units is developed at MIT and has been used as a platform for a multitude of projects and experiments. The individual modules, one of which is pictured in Figure 4, are roughly five inch cubes and have a wide array of sensors, communications hardware and human interface devices. The swarm also includes charging stations that the modules can autonomously dock to. Most research involving this project has been performed by McLurkin and associates at MIT (Mclurkin et al. 2004).
| |
| − | | |
| − | The primary software tool used by the iRobot Swarm modules is an infrared communications system called ISIS that handles communication, localization and obstacle avoidance. Robots in close proximity are able to communicate and are able to determine the locations and bearings of each other. Messages are passed with a gradient-based multi-hop messaging protocol that disperses messages throughout the swarm. Messages follow a gradient and “flow” through the network topology, which is constantly changing (Mclurkin et al. 2004).
| |
| − | | |
| − | The features of the iRobot swarm already described provide a platform where researchers can implement swarm behaviors at a high level of abstraction. Most communication protocols and basic obstacle avoidance are handled by the underlying system so researchers can focus solely on emergent behavior.
| |
| − | | |
| − | [[Image:irobot1.jpg|frame|none|alt=image]]
| |
| − | | |
| − | Figure 4: iRobot in the MIT Lab.<br />
| |
| − | James McLurkin. Rice University. http://people.csail.mit.edu/jamesm/project-MultiRobotSystemsEngineering.php
| |
| − | | |
| − | == Defense Advanced Research Projects Agency ==
| |
| − | | |
| − | Another of the most notable examples is the DARPA (y) project for sensor networks. They envision “smart dust”: a sensor network made up of thousands of tiny robots, each communicating with each other, and relaying information about the battlefield. The objective is to make the robots small and light enough to float in the wind, scattering them, and landing on all surfaces (DARPA Virtual Robotics Challenge, 2012).
| |
| − | | |
| − | Part of the DARPA project uses an open source operating system and database known as TinyOS and TinyDB, respectively. This operating system is a runtime environment designed for embedded systems which require concurrency operations while constrained by minimal hardware resources. Many different universities are using this as a starting point for their own projects.
| |
| − | | |
| − | == Project Software: ==
| |
| − | | |
| − | I am using the V-REP (Virtual Robot Experimentation Platform) Simulator for this project. The simulator allows the user to easily modify, adjust or rewrite the example control code to fit his/her own needs. The user can also easily compose complex simulation scenes by dragging-and-dropping new models or robots into the scene from the menu.
| |
| − | | |
| − | V-REP is a 3D robot simulator based on a "distributed control architecture: control programs (or scripts) can be directly attached to scene objects and run simultaneously in a threaded or non-threaded fashion. This makes V-REP very versatile and ideal for multi-robot applications, and allows users to model robotic systems in a similar fashion as in reality - where control is most of the time also distributed" (V-REP, 2012). This Software is available Open-Source for PC, Mac and Linux platforms. A powerful mechanism is included to allow easy access to V-REP API functions from external applications (e.g. robots): the remote API. It can be bound with Python, Java, Matlab, Lua, and Urbi (K-Team, 2012).<br />
| |
| − | <br />
| |
| − | V-REP robots environment (World) are developed in Lua Programming Language. Therefore, I will use the same Programming language for developing my robots, wireless sensor network, as well as target search. V-REP is composed of several API functions Libraries. I will be using Regular API Library which allow you to access many V-REP parameters. I am also using Remote API Library that will allow me to control the simulation (or Simulator itself), as well as the Object Parameter IDs Library.
| |
| − | | |
| − | In addition I am using the Graph Library, which will enable me to record, visualize or export data from a the simulation. This is a very powerful and flexible tool of V-REP. The user can select from a multitude of data types applied to specific objects to record. Data is recorded as a data stream (sequential list of data values) that can be visualized in three different ways: Time Graph, x/y Graph, or 3D Curve (V-REP, 2012).
| |
| − | | |
| − | [[Image:ProjectTimeLine.jpg|frame|none|alt=image]]
| |
| − | | |
| − | Figure 4: This is estimated time line for the project.
| |
