Copyright 2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
2004 IEEE International Conference on Systems, Man and Cybernetics
GroundScouts: Architecture for a Modular Micro Robotic Platform for Swarm Intelligence and Cooperative Robotics* Ferat Sahin Electrical Engineering Department Rochester Institute of Technology Rochester, NY USA
[email protected] cost limitation. Even though electronic components have gotten smaller significantly, mechanical parts and battery sizes are still reasonably large. Size limitation on a micro robot is imposed by mostly mechanical parts and batteries. The fundamental problem with reducing the size of the mechanical devices is that they either become inefficient or not fully functional when their size is shrunken. For example, when the size of a DC motor or a gear gets smaller, their power and their durability reduce significantly. These limitations have determined our design which is detailed in the following sections.
-
Abstract Thispapergresents architecture for a modular micro robotic platform for swarm intelligence and cooperative robotics research and applications. In a swarm the value of an individual is negligible since the goal of the swarm is essential. Thus, the ogenfs (robots) need to be small, low cost, and cooperative. GroundScouts are designed based on these conditions. The proposed architecture slices a robot into abstract modules such as locomotion. control, sensors, communication, and actuation. Any mobile robot con be constructed by combining these abstract modules for a specijk application. A modular embedded micro-OS with dynamic task uploading and multi-tasking abilities is developed in order to create better interface between robots and the command center and among the robots. The dynamic task uploading allows the robots change their behaviors in runtime. Thus, the robots con work in swam, master-slave. or hybrid mode and possibly be used in other applications such as mobile sensor networks. remote sensing, andplant monitoring.
There have been many definitions of a robot io the literature since the beginning of the robotics field in the 1940s. After having been introduced in factories, robots became mobile and smaller with advances made io mechanical and electrical engineering fields. After the mobility of the robots was developed, the artificial intelligence field made its contribution to robotics by making them autonomous and smarter. Thus, the autonomy of a robot required good communications and sensing skills. One of the latest definitions of a robot, given by Siegel, is: “Robots are machines that sense, think, act, and (more recently) communicate” [13]. His definition is based on a definition given by Allen Newell, called the thee-component definition: a robot is a machine that senses, thinks, and acts [9].
Keywords: Swarm intelligence, autonomous robots, modular hardware, and cooperative robotics.
1 Introduction The main goal of this work is to develop a modular micro robotic platform to be used io implementation of swarm intelligence and cooperative robotics algorithms. The nature of the swarm intelligence and cooperative robotics brings some limitations and conditions to the design of a reliable platform. Size, cost, and cooperative abilities via specific tools are some of the limitations and conditions. Size and cost limitations are closely related since smaller size means less material thus less cost. With the advances in microelectronics fabrication technologies, the size and cost of the ICs used in the systems went down significantly, which allows the designers to meet the
Robots need sensors mainly for t h e e reasons. First, sensing is the purpose of the mission: e.g. to gather chemical analyses of rocks on a mars mission. Second, sensing is necessary for survival in the robot’s environment: to determine an obstacle on the planned path to the target. Finally, sensing is needed to enable the robots to sense their own configurations and their relationships with the environment. Along with sensing, a robot needs to make decisions (think) to be able to adapt to the environment and to change the environment
’ 0-780343566-7/04/$20.00 0 2004 IEEE 929
Authorized licensed use limited to: Rochester Institute of Technology. Downloaded on January 12, 2009 at 11:10 from IEEE Xplore. Restrictions apply.
according to the mission. No machine can s w i v e in an environment without proper feedback from it. Mechanical and sensor errors can easily accumulate and put the robot in a dangerous situation. Thus, cognition is essential for robots’ survival. Acting is another essential requirement for the evolution of intelligence [13]. Acting is an ability to act on the environment to survive and accomplish the mission. Manipulation and mobility are key components of action even though they may not be necessary at the same time for small robots. Most of the time, mobility is enough for small robots to accomplish the mission. This changes the current image of a robot from “one-anned iron-laborer” to “a mobile creature’’ mostly moved by wheels, In recent years, special attention has been given to swarms of robots mostly inspired from the nature of insects. Cooperation between the insects lets them accomplish a complex mission with their rather limited intelligence. This type of behavior brings the communication component to the picture because robots can cooperate with each other only with effective communication between them [l].
model has both hardware and software modularity. Figure 1 presents the proposed MRS hardware modularity. In the model, each abstract module can he implemented by the corresponding hardware. For example, a sensor module may be an ultrasound sensory board or a proximity sensory board, or perhaps both. The sub-modules are designed such that they have a unique signature and a standard pin connection. The sub-modules can be added at any level and the position does not effect its module’s operation. Since modules can he combined in any order, an application specific robot can be quickly constructed. For example, if a new problem domain requires legs rather than wheels, the wheeled sub-module can he instantly swapped with the legged sub-module. This is essential for swarm intelligence applications since agents might he equipped with complementary abilities instead of having the same ahilities. For example, in ant colonies, there are different kinds of ants handling distinct tasks using their snecial ahilities.
In the next section, the proposed modular design architecture is discussed in both software and hardware aspects. Section 3 presents an implementation of the proposed architecture, called GroundScouts. Finally, Section 4 presents conclusion and future work.
!
2 Modular Design Architecture 2.1
Modular Hardware Architecture
Figure 1. Modular Hardware Architecture.
There has been a significant amount of research in reconfigurable and modular robotics in recent years [7,8, 131. Most of the research has been on multiple identical modules that construct a single robot. The proposed architecture has a vertical modularity in which the modules are not identical to one another. It slices a robot into functional abstract modules such as locomotion, control, sensors, communication, and actuation. Any mobile robot can be constructed by combining the above abstract modules for a specific application. A sub-module is a piece of hardware, which accomplishes the functionality of an abstract module, i.e. a wireless communication suhmodule for a communication module. An analogy can be made with object oriented programming if the abstract modules are considered to he abstract classes and suhmodules are concrete subclass instances. A similar modular robotics approach is explored in [4]. Fryer et al. focus on sensor-oriented modular robotics systems (MRS) where modules contain a mobile base, a camera mount, and a camera [4]. In OUT architecture, the same robot can he constructed by combining a locomotion module, sensory module, and an actuator module. In [4], the software modularity bas not been intensively explored. Our MRS
2.2
Modular Software Architechre
Programming robotic applications is far from standardized. The primary reason is that each robot is composed of very special hardware designed for a specific goal. The result is that the software also becomes specific. Thus, systems currently available are not capable of providing modules that are easily maintained and reusable [3]. Denneherg and Fromm attempted to develop open software for autonomous mobile robots [3]. Their approach, Open Software Concept for Autonomous Robots (OSCAR), is based on a layered model with four software levels: command layer, execution layer, image layer, and hardware layer. Each layer acts as an interface between the upper layer and the lower layer. Therefore the upper layer does not require knowledge of the lower layer [3]. Our approach employs software modularity that matches the hardware mdularity presented in section 2.1. In OSCAR, only the hardware layer deals with the hardware components whereas in OUI model, each hardware module corresponds to a software module. Modular software development methodologies are directly related to the object-oriented programming 930
Authorized licensed use limited to: Rochester Institute of Technology. Downloaded on January 12, 2009 at 11:10 from IEEE Xplore. Restrictions apply.
paradigm. The proposed software architecture consists of abstract classes and their concrete subclasses. The abstract classes are robot, locomotion, control, communication, sensor, and actuators. The concrete classes are derived from these abstract classes. For example, a wireless class may be instantiated from the communication class. The wireless class represents the robot's communication module. The concrete classes inherit functionality from the abstract classes, in addition to their hardware specific functionality. Even though the modules contain their own software modules, the central controller (or operating system) identifies newly inserted modules and instantiates the corresponding objects and interfaces to the hardware module. These objects are going to be the tasks dynamically loaded and executed in the operating system. Figure 2shows the class structure for the software architecture. The modular operating system is developed and tested on an evaluation board. The initial tests on the robots are also successful.
altemative locomotion to be used in different applications. The battery selected for the robot is an AA form factor NiMH rechargeable cell. Four of these cells connected in series are used in the system. Two are placed in the front of the robot and two are in back. The cells are nominally 1.2 volts each for a system voltage of 4.8 volts. The locomotion, first electronic level shown in Figure 4, is the most critical level in the operation of the robot. It contains the circuitry for the €€Bridge, which provides direction control for the motors and supplies the high current they require. It also includes the power system, which consists of a DC-DC converter and some passive components. The power system provides +5 volts for the entire robot, and will accept from 1.5 - 15 volts on its input. This provides plenty of flexibility f a different battery system is put in place. This level also contains the charge circuitry, which allows the battery to remain in the robot while its being recharged. Finally, this layer contains three proximity sensors, one centered at the front and two facing 45 degrees off center on either side of the front sensor. These sensors allow the detection of objects in close oroximin to the robot which i t mav need to avoid. This level attaches to the base with f o k screws and houses connectors for the batterysystem and the motors.
.-
! ! !
jl 'I
Figure 2. Modular software architecture.
3 GroundScouts: Modular Mobile Micro Robots
Figure 3. Robot base with four wheels and legged.
GraundScouts are modular micro robots, which take advantage of a layered design approach described in Section 2. Even though there are five levels in the hardware and software architectures, the implementations (sub-modules) of the levels (modules) can be more than one. In addition, each level may also involve multiple closely related functionalities. The sub-modules are designed at RIT but the layouts are sent out for professional fabrication. The following sections presents (snh)modules in the GroundSconts: Locomotion, Control, Sensor, Communication, and Actuation.
3.1
..
.
',
D
Figure 4. Locomotion sub-module top (left) and bottom (right) view
3.2
Control
Housed on this layer, seen in Figures 5, is the main controller, an 8051-based microcontroller running at 11.0592MHz. A 64k x 8 flash memory IC, a 32k x 8 SRAM IC, and an 8bit latch are the rest of the components on this level. The flash memory is in a dip package and is attached via an IC socket, so it can he removed to be reprogrammed. All other components are soldered directly to the hoard. With improved memory architecture, GronndScouts are able to run a modular embedded operating system explained in the next section. The
Locomotion
Locomotion module has a mechanical base, and locomotion module hardware (sub-module). The base of the robot consists of an aluminum frame, two DC motors, some gearing, four wheels and associated ball bearings, and the batteries. The base is designed by CAD tools and machined with high precision CNC machines. Figure 3 (left) shows the base with wheels, gears and motors. A legged version of the base is also designed as an 931
Authorized licensed use limited to: Rochester Institute of Technology. Downloaded on January 12, 2009 at 11:10 from IEEE Xplore. Restrictions apply.
microcontroller currently in place is a Philips 8OC552-5, which has no internal ROM and vectors directly to the external flash for its program. As for VO, it has five %bit registers, two of which are used to access external program and data memory. One of those registers houses an 8-bit analog-todigital converter. In addition to the five registers, the microcontroller has two PWM lines and some program and data memory access lines. Because of the microcontroller's built-in address space, the only external address decoding required was a single FET to enable/disahle the SRAM and the flash ROM.
Figure 7. Ultrasonic Sub-module top (left) and bottom (right) view.
3.4
The communication sub-module, shown in Figure 8, is comprised of a PIC microcontroller that controls a LWX wireless transceiver. The modulation scheme for the transceiver is Frequency Shift Keying (FSK) centered at 913 with a 20 MHz bandwidth. A PIC microcontroller is used to form packets and to do addresii decoding. The PIC communicates serially with the main controller. When multiple users are present, a Medium Access Control (MAC) protocol must be applied in order for data to be successfully transmitted. Time Division Multiple Access (TDMA) was selected as main protocol because it is easier to design, simple, and fairly well-known. This MAC protocol separates the users in time, allotting a time slot for each userto transmit data.
Figure 5: Microcontroller Board Top (left) and bottom (right)view.
3.3
Communication
Sensor
There are two sensor suh-modules in GroundScouts. The infiared sub-module, shown in Figure 6, consists solely of five infrared sensor pairs. Each pair consists of an emitter and a detector. The IR emitters of all five pairs of sensors are enabled simultaneously via a logic-level E T , and are turned on by the microcontroller. The detectors require that the emitters he driven at 38 "adulated on 833 Hz, which is done by the microcontroller. The detectors have built-in filters and provide a digital output to the microcontroller informing it if an object is present. The IR layer uses a total of six microcontroller YO lines: one to drive the emitters, and five to read each of the detectors.
Figure 8. Comnunication sub-module for GroundScouts Since there are many individuals in the swarm and they may not seekommunicate with each other, a better protocol needs to be designed for swarm intelligence applications. Conventional TDMA is reliable but has some in-efficiencies that exist when the maximum amount of users are not present. Unused time slots are present which could be used to increase the transfer rate of the users who are present. An Adaptive TDMA (ATDMA) protocol was developed to utilize these unused time slots. As users enter and leave the network, the number of time slots will change accordingly creating a TDMA network with no unused time slots. The cost of this protocol is one time slot per frame. This time slot is designated for users to enter the network. The data link layer incorporates error detection with the use of a checksum, packet numbering to ensure reliable transmissions, and a transmit / acknowledge procedure to allow the errclneous packets to be retransmitted. The ATDMA protocol has been successfully tested with two swarm intelligence based applications [2, 101.
Figure 6. Infrared Sub-module The ultrasonic sensor sub-module, shown in Figure 7, is designed to accommodate three ultrasonic receiver and transmitter pairs. These sensors allow the robot to determine its distance to an object in the range of 2 300cm. In order for the object to be detected, it must have at least one section which is normal.to the sensors as well as be of a material which will reflect a majority of the ultrasonic energy. The three sensors can be in one of two possible configurations: 1) one front and centered, and two on either side at 45' fiom center, or 2) one ffont and centered and two facing rearward at 45' from center.
932
Authorized licensed use limited to: Rochester Institute of Technology. Downloaded on January 12, 2009 at 11:10 from IEEE Xplore. Restrictions apply.
3.5
Actuation
A GPS sub-module, shown in Figure 9, is designed as the actuation level for the GroundScouts. A CCD camera and a gripper are also considered as possible actuator submodules. The chosen GPS receiver was the Lassen SQ GPS receiver. It operates on the standard L1 carrier frequency of 1575.42 MHz and has the capability to automatically get GPS satellites and track up to 8 of them. It can also compute location, speed, heading and time.
section presents an implementation of the modular software architecture.
3.6
Software
Controlling many cooperative robots is not an easy task. The software needed is complex and must allow multi-tasking. To mitigate the complexity, many developers have begun using real time operating systems (RTOSs). In addition to providing the ability to precisely synchronize multiple events, RTOSs give the application programmer predefined system services and varying degrees of hardware abstraction, both of which are aimed at making software development easier and more organized. Thus, a micro real time operating system is developed with the GroundScouts’ software architecture.
3.6.1 Operating System Figure 9. GPS sub-module top (left) and bottom (right) view.
The operating system is designed using a modular architecture so that the basic operating system (OS) is significantly small in size and tasks are dynamically loadable over a serial port (via wireless transceiver). Each robotic sub-module has an associated task (driver). Each task corresponds to an object of the corresponding concrete class defined in Section 22. These drivers are separate from the OS in order to reduce the OS size. This separation makes the dynamic task loading and execution a crucial component of the operating systems.
Data is sent to and from the GPS receiver via serial communications. The protocol of these communications is dependant on the standard chosen, either Trimble Standard Interface Protocol (TSIP) or National Marine Electronics Association (NMEA). TSIP was chosen for this application, having an input and output baud rate of 9600, 8 data bits, odd parity, 1 stop bit and no flow control. TSIP automatically sends information on GPS time, position, velocity, receiver healthhtatus and satellites in view. GPS time and receiver healthhtatus are sent every 5 seconds, and all others are sent every 1 second. Position and velocity measurements are capable of being sent as singles or doubles depending on the desired precision. In this application, single was chosen to save space and calculation time. GPS information is received and stored by a PIC16F73 using its onboard UART configured at the aforementioned settings. 12C is used to communicate between the 80552 and the PIC when GPS information is desired by the 80552. When an I2C message is received by the PIC, it finishes the current GPS message in its entirety, and then services I2C to guarantee complete uptodate information is delivered.
The current operating system is a real time operating system capable of accommodating the modular nature of the robots [5, 1I]. The hardware platform is developed around the Philips 80C552 microcontroller, a derivative of the 8051 microcontroller originally designed by Intel. This 8-hit microcontroller may support up to 64k of external program memory, and an additional 64k of data memory. The primary properties of the operating system are:
I. An operating system that is generic and promotes portability. 2. Programmed in C except for processor specific assembly. 3. Provides modular s o m e code. 4. A multitasking operating system that supports dynamic loading and task execution.
3.6.2 Dynamic Task Uploading The challenge when implementing DLE using a RTOS stems from the fact that there are fundamental operating system limitations. A RTOS such as the $/OS-I1 is preemptive, meaning that the highest priority task waiting for execution will be executed unless it is suspended, delayed, or waiting for an event. The pC/OS-Il Operating System, written by Jean J. Labrosse [q,was specifically designed for embedded systems. The pC/OS-II runs on
Figure 10 A Groundscout with all sub-modules This completes the modular hardware building blocks, The complete robot can be seen in Figure IO. The next
933
Authorized licensed use limited to: Rochester Institute of Technology. Downloaded on January 12, 2009 at 11:10 from IEEE Xplore. Restrictions apply.
[2] E Chapman and F. Sahin, “Application of Swarm Intelligence to the Mine Detection Problem”, to be presented at the IEEE SMC 2004, the Hauge, Netherlands, October 2004.
most 8, 16, 32 and even 64 bit microprocessors including the 805 1. The easiest solution is to use pC/OS-I1 to create a shell task as part of the OS-application image, into which the dynamically loaded task can be loaded at a later time. This shell task remains dormant, that is not executed, until a dynamic task is loaded into the shell. A generic shell task contains a reserved memory location that holds the dynamically loaded task program code and the necessary operating system services code. If an independent task is loaded into the reserved memory location and the shell task is dynamically activated and executed by the CPU. Figure 11 presents the dynamic load and execute feature. The human supervisor via the software interface and wireless communication link sends a task The operating system receives the task and forwards it to a reserved memory space. Finally, the task is executed when needed.
[3] V. Denneberg and P. Fromm, “OXAR. An open software concept for autonomous robots,” in Proceedings of the 24th Annual Conference of the IEEE Industrial Electronics Society, pp 1192 -1 197, September 1998. [4] J.A. Fryer and G.T. McKee, ‘Resource modeling and combination in modular robotics systems,’’ in Proceedings of the I998 IEEE International Confertmce on Robotics andAutomation,pp3167-3172,May 199,5. [5] B. Kauler, Flow Design for Embedded Systems, R&D Books, Lawrence Kansas, 1999. J. J. Labrosse, MicroUOS-II: The Real Time Kernel, CMF’ Books, Lawrence Kansas, 1999.
[q
[7] W.H. Lee and A.C. Sanderson, “Dynamics and distributed control of modular robotic systems,” in Proceedings of the 26th Annual Conference of the IEEE Industrial Electronics Society, pp 2479-2484,2000.
[8] S. Murata, E. Yoshida, K. Tomita, H. Kurokawa, A. Kamimura, S. Kokaji, ‘Rardware design of modular robotic system,” in Proceedings of the 1999 IEEE/RSJ International Conference on Intelligsnt Robots and Systems,pp 1579-1585, Korea, October 1999.
Figure 11. The high level view of pUOS-E with dynamic load and execute functionality.
4
[9] S, Noser, seminar “Naturliche and Kunstliche Intelligenz”, lecture ”Foundations of C!lassical AI and Cognitive Science”, March 2001, Institut hr Informatik der Universitat Zurich. See htpp://www.ifi.unizh.chi groups/ailab/teachingisemi2OOO/semi. htm
Conclusion and Future Work
This paper presented architecture for modular micro robotic platforms to be used in swarm intelligence and cooperative robotics applications. Hardware and software modularity of the architecture have been presented in detail. Successful implementations of two swarm based algorithm have been performed using the proposed robot architecture (Groundsouts) [2, lo]. These successful applications show that the GroundScouts can be used in other applications such mobile sensor networks, remote sensing, and plant monitoring. Even though hardware for the proposed architecture has been completed, the software architecture has not been fully tested on the GroundScouts. Next generation real-time micm OS is being developed for in order to have bug-free operation.
[lo] W. J. Opp and F. Sahin, “An Mificial immune
System approach to Mobile Sensor Networks and Mine Detection”, to be presented at the IEEE SMC 2004, the Hauge, Netherlands, October 2004. [Ill B. Santo, “Embedded Battle Royale,” IEEE Spectrum, pp. 3641,December 2001. [I21 M Seigel, “Smart Sensors and Small Robots”, in the IEEE Instrumentation and Measurement Technology Conference, pp. 303-308, Budapest: Hungary, May 21-23 2001.
References [I31 E. Yoshida, S. Kokaji, S. Murata, H.’Kurokawa, andK. Tomita, “Miniaturized self-reconfigurable system using shape memory alloy,” in Proceedings of the 1999 IEEE/RSJ International Conference on Intelligent Robots ands’stems, pp 1579-1585, October 1999.
K. Capek,, (translated by PSelver, N.R. Playfair), R.U.R (Rosum’s universal robots): a fantastic melodrama in three acts and an epilogue, New York: S. French, 1923. [l]
934
Authorized licensed use limited to: Rochester Institute of Technology. Downloaded on January 12, 2009 at 11:10 from IEEE Xplore. Restrictions apply.
