Presented By
ABSTRACT
If knowledge can create problems, it is not through ignorance that we can solve them. - ISAAC ASIMOV In recent years there has been an increasing interest in distributed robotic systems. In such a system, a task is not completed by a single robot but instead by a team of collaborating robots. Team members may exchange sensor information, may help each other to scale obstacles, or may collaborate to manipulate heavy objects. This paper describes the design of a team of centimeter scale robots that collaborate to map and explore unknown environments. The robots, called "CMU Millibots", are configured from modular components that include sonar and IR sensors, camera, communication, computation, and mobility modules. Although these small robots have limited capabilities as individuals, as a collaborative team they can be used for Mapping and surveillance applications. In this context we are going to present the Technology involved in this project of Millibots.
Second Law
A robot must obey the orders given to it by human beings. Except where such orders would conflict with the first law.
Third Law
A robot must protect its own existence as long as such protection does not conflict with the first or second law.
- ISAAC ASIMOV
1. INTRODUCTION
3
A team of robots has distinct advantages over single rbots with respect to actuation as well as sensing. When manipulating or carrying large objects, the load can be distributed over several robots so that each robot can be built much smaller, lighter, and less expensive. As for sensing, a team of robots can perceive its environment from multiple disparate viewpoints. Even though a single robot may be equipped with different sensing modes, it can only observe the environment from a single viewpoint. For tasks such as mapping and exploration, this increased utility equates to increased coverage and speed. Exploration and mapping can occur at multiple fronts simultaneously precluding the necessity for a single robot to travel to multiple waypoints. By coordinating as a team, a group of physically distinct entities can act as a single logical entity. Small robots have a distinct advantage over their larger counterparts in the exploration and surveillance arenas. In addition to being highly suitable for covert operations they have the unique ability to access areas unreachable to larger robots
2. SYSTEM DESIGN
4
To explore the utility of distributed sensor collaboration, we have developed a team of small robots, called Millibots (Figure 1) [3]. These robots are constructed at the 5-10 cm scale allowing them increased accessibility to tight or cluttered spaces. Distributed robotic systems require a new design philosophy. Traditional robots are designed with a broad array of capabilities (sensing, actuation, communication and computation), but redundant subsystems must be added toavoid single point failure. This results in a robot that is larger, more complex and more expensive. Millibots are able to distribute processing and sensing over a collection of robots by exploiting the nature of modularity and specialization. By equipping a Millibot with only those sensors needed for the particular set of sub-tasks, the robot is able to optimize on resources such as size, computational complexity and power. This optimization results in less expensive robots that are easier to maintain and debug. Reducing the cost of individual units allows more robots to be built with the same resources. Adding multiple robots with the same abilities increases the effectiveness of the group while adding a degree of redundancy and consequently increasing fault tolerance. If a single robot fails, only limited capabilities are lost and the team can still continue the task with remaining robots.
Figure 2 is an example of some of the modules currently available for the construction of a Millibot. A mobility module is selected according to the task. One mobility module may be well suited for operation on coarse terrain while another is more effective on a flat, smooth surface. A processing module is then selected based on the computation necessary for operation (center). Powerful processors consume significantly more power than smaller processors and may be more than the robot requires for a given task. By selecting the minimum processing necessary for operation, the robot can support a greater sensor load or extend the operating time of the robot. On the other hand, a different robot may be built with greater processing capability but at the expense of sensing. A team design is able to exploit the features of both. Finally a sensing module(s) is selected based on the particular mission. For example, some robots may use sonar sensors allowing them to build sensor maps, while others are support object identification with a camera. By supporting modularity, any sensor module that conforms to the proper interface can be integrated into a given Millibot. These platforms may include a variety of sensors including sound recorders, ranging sensors, proximity detectors, chemical sniffers, magnetic field detectors, or radiation monitors.
This Camera Module provides a video camera and transmitter to the team. The camera is switched on for short periods of time when needed to identify objects or clearings around the robot.
4. CLASSIFICATION OF MILLIBOTS
Millibots are classified according to the task to be performed. Mainly they are classified into seven types as follows. 4.1 The Long Range Sonar Robot 4.2 The Short Range Sonar Robot 4.3 The Dirrs Robot 4.4 The Pyro Robot 4.5 The BW Camera Robot 4.6 The Color Camera Robot 4.7 The Laser Robot
10
robots to perform robot to robot ranging. This feature is key in allowing the team to maintian knowledge of robot positions as the team moves.
11
12
5. ARCHITECTURE
The architecture of this environment is set up to support multiple-team, multiple-robot operations. The teams may or may not be aware of each other. Each team shares the same environment. Its architecture Mainly consists of TEAM MANAGER, TEAM LEADER, ROBOT.
13
Figure 16: Architecture of Millibots Team Manager - The primary purpose of this class is to hold references to the entities that have interaction with the environment.This includes a reference to each of the team leaders, all of the robots and all of the global objects. There are two purposes for holding independent references to all the entities. The first is to allow the team manager a handle to draw all the appropriate images on the world map. The second is to privide the simulator with references to all the potential objects that could produce a collision or reflection. The team leader and robot classes do not have access to this class. Team Leader - This is a virtual class that represents an individual team of robots. Each team leader contains references to the robots of its group. Each team is threaded and can be treated as an independent process. Robot - Like the team leader, each robot class is threaded as well and acts as an independent process. The robot can run independently or tasked via messages from the team leader.
14