Design of Reconfigurable Heterogeneous Modular Architecture for Service Robots

Transcription

1 2008 IEEE/RSJ International Conference on Intelligent Robots and Systems Acropolis Convention Center Nice, France, Sept, 22-26, 2008 Design of Reconfigurable Heterogeneous Modular Architecture for Service Robots Ho Seok Ahn 1, Young Min Beak 2, In-Kyu Sa 3, Woo Sung Kang 2, Jin Hee Na 2, Jin Young Choi 2 Abstract This paper presents the design and implementation of a reconfigurable heterogeneous modular architecture for service robots. The proposed architecture has five key concepts which are different from conventional reconfigurable modular service robots; 1) easy and multiple assembly according to requirements of users, 2) hardware resource sharing system with other heterogeneous modules, 3) communication ability among all heterogeneous modules which have different operating systems, 4) automatic connection management system when a new module is attached, 5) automatic software upgrading system for new module software. We explain the three parts of the system architecture which meet the five concepts; mechanical architecture, software architecture, and connection architecture. To verify our architecture, we developed and evaluated a reconfigurable heterogeneous modular service robot by applying the proposed design. I. INTRODUCTION Intelligent service robots consist of numerous components such as actuators, manipulators, visual recognition system, and many sensors that should be integrated organically in one robot to perform specific missions. Developing these systems requires a lot of time and effort of researchers since integration of these systems is a difficult task. In addition, some functions may not be needed for a specific task, although these functions are essential for other tasks. Considering these problems, many reconfigurable modular robot systems have been proposed [1-11]. Reconfigurable modules for service robots are classified as homogeneous modules and heterogeneous modules depending on whether their modules are identical or not [1]. As homogeneous modules are focused on processing some specific tasks such as manipulating or actuating, they are not suited for service robots. On the contrary, as heterogeneous modules have different functions each, they can process many functions at once which are essential for service robots. The goal of this paper is to present a design and implementation of reconfigurable heterogeneous modular service robot architecture. We consider five key concepts which are different from conventional reconfigurable 1 Ho Seok Ahn is with School of Electrical Engineering and Computer Science, PIRC, ASRI, Seoul National University, Seoul, Korea (corresponding author to provide phone: ; fax: ; hsahn@neuro.snu.ac.kr). 2 Authors are with School of Electrical Engineering and Computer Science, PIRC, ASRI, Seoul National University, Seoul, Korea ( {ymbeak, wskang, jhna, jychoi}@neuro.snu.ac.kr). 3 In-Kyu Sa is with Telecommunication R&D Center, Telecommunication Network Business Operations, Samsung Electronics., Suwon, Korea ( inkyu.sa@samsung.com). Fig. 1. The reconfigurable heterogeneous modular service robot Mom s Friend which is assembled with seven heterogeneous modules; SLAM module, power module, main module, vision module, home appliance control module, manipulator module, and head module. Speech module operates separately using wireless communication at this time. modular service robots. We have designed the reconfigurable heterogeneous module(rhm) architecture which satisfies these five concepts. The proposed architecture consists of three parts; mechanical architecture, software architecture, and connection architecture. Using the RHM architecture, we have developed a reconfigurable heterogeneous modular service robot Mom s Friend as shown in Fig. 1. Each RHM can operate independently, as well as cohesively, in combination with other RHMs. An RHM can be assembled easily and can share hardware resources. It also communicates seamlessly although its operating system is different from other RHMs. When a user attaches new RHMs, the main module detects and reunites them as one robot. Mom s Friend connects to the web site of each RHM, and upgrades the software automatically. This paper is organized as follows. In Section 2, we explain the problems of conventional modular robots and the five key concepts of the RHM architecture. In Section 3, we describe the RHM architecture which meets the five key concepts in Section 2. In Section 4, we introduce the reconfigurable heterogeneous modular service robot Mom s Friend based on the RHM architecture. In Section 5, we present our experimental results and evaluations. Finally, we conclude this paper in Section 6. II. KEY CONCEPTS OF RECONFIGURABLE HETEROGENEOUS MODULAR ARCHITECTURE FOR SERVICE ROBOT A. Problems of Conventional Modular Robots In homogeneous modules, as the shape or functions of each module is identical before assembling into one robot, it is /08/$ IEEE. 1313

2 suitable for simple functional robots such as manipulators or actuators. The Conro Robot [1] carries its own processor, power supply, communication system, sensors, and actuator. Although it is useful to make a snake robot or a quadruped robot, it is impossible to make service robot which requires various functions. The M-TRAN [2] robots have demonstrated various locomotion modes, including rolling track, H-walker, snake, and caterpillar. The Superbot module [3] is self-reconfigurable robot which is focused on the details of realized in a large number of different ways. The ATRON module [4] is a lattice-based modular self-reconfigurable robot system. The basic module design is based on two hemispheres connected by a rotational joint. In heterogeneous modules, as the shape or functions of a module is different before assembling into one robot, it is suitable for various functional robots such as mobile service robots or humanoid robots. Tetsuya Taira, et al. [5] have developed reconfigurable modular humanoid robot with different functional modules such as arm module, mobile module, and head module. While each functional module works independently, it monopolizes own hardware resource and it is impossible to cooperate with other modules. The architecture of GroundScouts [6] is to slice a robot into several modules such as control, sensors, communication, and actuation. It is impossible to communicate among all modules if they have different operating systems. The Spiking Neural Building Block Robot [7] has simple functional module for line tracing robot. Cube Modular Robot [8] and GRASP Modular Robot [9] are only for actuator robots. Although these robots are heterogeneous modular robots, they are just simple functional robots. Kohsei Matsumoto [10] has proposed a mono-functional modular robot which is dividing an intelligent robot into robotic elements. As each module has one sensor or actuator, each module does not perform individually. HERMES [11] is focused on expandability and all actuators are designed as modules. A CAN bus connects them with a main computer and the whole-body motion is controlled by it. Although it is a distributed robot system, each module cannot operate autonomously without the main computer. B. The Key Concepts We suggest the key concepts of the RHM architecture as follows to solve the problems which are present in conventional modular robots. Easy and multiple assembly according to requirements of users. Hardware resources sharing system with other heterogeneous modules. Communication ability among all heterogeneous modules which have various operating systems. Automatic connection management system when a new module is attached. Automatic software upgrading system for new module software. The suitable shape, processors, and operating systems are different for the functions of each RHM. Easy assembling mechanism is needed for users to make various functional robots. Because hardware resources such as cameras and navigating sensors are expensive, each RHM should share all hardware resources in the robot. It is important to manage all RHMs and communicate seamlessly in real-time although their OSs are not same. It should connect new RHMs automatically without any help of users. If new RHM is attached or new software is needed, it should update the software automatically. Although there is no main system, each RHM should be operated independently, as well as cohesively, in combination with other RHMs. III. RECONFIGURABLE HETEROGENEOUS MODULAR ARCHITECTURE FOR SERVICE ROBOTS We have designed RHM architecture based on the five key concepts described in Section 2. The RHM architecture consists of three parts; 1) mechanical architecture, 2) software architecture, 3) connection architecture. A. Mechanical Architecture Each RHM should have common mechanical structure to be assembled in random order on all sides. As shown in Fig. 2, the common mechanical structure consists of four parts; power hub, data hub, connector, and functional system. The power hub and the data hub consist of several power boards and data boards each and connect all the functional systems in the whole robot using bypass lines. The power hub supplies power to the functional system by various voltage levels, because the required voltage level is different for the functional system. For this, power boards have the circuit for converting various voltage levels. The data hub supports various kinds of data formats such as LAN, USB, serial, and audio, because the required data format is different depending on the functional system. For this, the data format of all data boards should be prearranged to avoid data collision and it is Fig. 2. The common mechanical structure of the RHM architecture. It has four parts; power hub, data hub, connector, and functional system. The power hub and the data hub connect all the functional systems in the whole robot using bypass lines. While this method is similar with CAN communication, it supports various kinds of data formats. 1314

3 managed by the connection managing system which is based on the connection architecture. For connecting with other RHMs on all sides as occasion demands, every connector is able to be placed anywhere if it is connected with the power hub and the data hub. The functional system, which has various operating systems and programs, sends the result data to other RHMs or receives the required data from other RHMs by the data hub. In this case, the correlated RHMs should have the same numbered data board to communicate with each other. Fig. 3 shows the connection of the power hub and the data hub. Every RHM should have at least one power board and data board for assembling. Using the mechanical architecture, each RHM is able to share hardware resources in the robot when it has the data board which is connected with the required hardware resources. In the case of the power hub, main voltage level is supplied to all modules through the power hubs, and each power board converts to the required voltage level. B. Software Architecture We have designed the software architecture for RHMs to communicate between RHMs, which have various operating systems and functions because the suitable OS and processors may be different depending on the functions of RHMs. As shown in Fig. 4, we use TCP/IP communication for the processed result data and RS485 communication for sharing hardware resources. Each RHM converts the processed result data to a defined markup language format using the data parser for communicating among all RHMs. If there is request for the result data from other RHM, the processed result data is sent directly if they are connected by data hub. If they are not connected, the processed result data is sent to other RHM via the main system which is connected with all RHMs. When RHM needs to use some hardware resources in other RHMs, it gets the information of the hardware resources from the connection managing system, and requests the data or the authority to the RHM which has the hardware resources. The main system is decided by the connection managing system according to the purpose of the robot. The main system plans the schedule of the whole robot and manages the version of all RHMs using the connection managing system. When a new RHM is attached, the connection managing system informs the main system the status and it gets the information of the new RHM. If the version of the new RHM is different from the information in the main module, it connects the website which has the suitable software of the new RHM by getting the URL from the connection managing system. Then the main system updates software autonomously and schedules cooperating functions. Each RHM can operate independently without the main system, as well as cohesively, in combination with other RHMs. C. Connection Architecture We have designed the connection architecture for managing all RHMs in the robot. In reconfigurable modular robots, the requirements are not only expansibility, but also the stability of operating the system when users assemble RHMs randomly. For satisfying these conditions, it is required that new RHMs should be detected quickly and the information about new RHMs is acquired. We have defined the five standard information of the connection architecture for RHM as follows. Fig. 3. The connection of the power hub and the data hub. When there are four RHMs which have the common mechanical structure. Each RHM has at least one power board and data board for connecting. Each RHM is able to communicate and share hardware resources using suitable data board. If there is a camera system, which is connected with the data board 2 in the arm module, the main module can use the camera system through the data board 2. Fig. 4. The software system architecture of the RHM architecture. It connects all RHMs using TCP/IP communication for the processed result data. It also makes possible to share hardware resources in all modules. As the main system is decided by the connection managing system, which is based on the connection architecture, it can be changed according to the purpose of the robot. 1315

4 ID: National Code (3 digits) + Company Code (6digits) + Product Code (3 digits) - It uses the number code which is predefined. Version: Year (4 digits) + Month (2 digits) + Day (2 digits) + Time (2 digits) - It uses only number. Data Hub: (Board Number + Port Number + Data Format) + (Board Number + Port Number + Data Format) + - Data Format: U (USB), L (LAN), S (Serial), A (Audio), etc. - The digit of Data Hub packet is the number of using port x 3. IP Address: IP address of each module - IPv4: 4 digits (32 bits). - IPv6: 6 digits (128 bits). URL: URL of the website for downloading the information of the module - It uses as string value. Fig. 5 shows the connection managing system which is hardware system using micro processor. Each RHM has the connection managing circuit board with one MCU for storing the five standard information of the RHM and an eight digits array switch for setting IP address. Especially the first bit of the eight digits array switch is for setting the host and the client according to the purpose of the robot. For the host, the first bit of the eight digits array switch should be set to low, for the client, the first bit of the eight digits array switch should be set to high. If there is no RHM which is set to low, the RHM which has the lowest IP address is decided to host automatically. If there are more than two RHMs which are set to low, the RHM which has the lowest IP address among them is decided to be the host automatically. The RHM with the connection managing circuit board which is set to the host becomes the main system. When a new RHM is attached, the connection managing system in the new RHM sends the signal to the host connection managing system. Then the host connection managing system gets the standard information from the new connection managing system. It checks which RHM is attached and whether there is collision of data hub or not, automatically. If there are some problems, new RHM stops working and notifies the problem to users. If there is no problem, it sends the five standard information of the new RHM to the main system. IV. IMPLEMENTATION OF SERVICE ROBOT BASED ON THE RHM ARCHITECTURE We have implemented the reconfigurable heterogeneous modular robot named as Mom s Friend by applying the RHM architecture which is described in Section 3. There are eight kinds of RHMs and each RHM has common mechanical structure and different shape, functions, processors, and operating systems. A. Reconfigurable Heterogeneous Modules We have developed eight RHMs; SLAM module, power module, main module, vision module, home appliance control module, manipulator module, head module, and speech module as shown in Fig. 1. Table I briefly shows the purpose and operating system of each developed RHM and the details are given as follows. TABLE I THE MAIN PURPOSE AND OPERATING SYSTEM OF EACH RECONFIGURABLE HETEROGENEOUS MODULE Module Main Purpose Operating System SLAM Movement of Robot Embedded Linux Power Supplying Power none Main Scheduling Windows XP Vision Image Processing Windows XP Home Appliance Control Home Control Appliances Tiny OS Manipulator Grabbing Something ucos Head Emotion Expression Embedded Linux Speech Speech Recognition Windows XP Fig. 5. The structure of the connection managing system. There is the connection managing circuit board include one MCU for storing the five standard information of each RHM and an eight digit array switch for setting IP address. It checks the connection of all RHMs and collision of data hub. B. Various Combinations of Mom s Friend As shown in Fig. 6, we assembled various combinations using Mom s Friend. The top left robot uses seven RHMs except the speech module. Each combination operates independently and communicates together. Its specification is shown in Table II. The top right robot is the chair robot that 1316

5 user can sit on the robot and control it using SONY PSP (PlayStation Portable) controller. It can be substituted as wheelchair for the aged or the disabled. Fig. 7 shows the connection managing system in each RHM. The top left is the connection managing circuit board with power board. It has the information of the RHM and sends it to the host connection managing system when it is connected with other RHMs. The top right is the data board for sharing hardware resources and data with other RHMs. Each data board has five ports and each of them supports various types of data format. The two bottom pictures are connectors of a RHM which is a part of the common mechanical structure. The socket and the connecting method TABLE II THE SPECIFICATION OF THE MAIN COMBINATION ROBOT OF MOM S FRIEND can be changed according to the system. V. EXPERIMENTS AND EVALUATIONS We have executed two experiments of the Mom s Friend. The first experiment is focused on the operation of each RHM independently. The second experiment is the scenario based operation of the service robot Mom s Friend. A. Experimental Result of Assembling Each Module Fig. 8 shows the procedure of assembling RHMs to the service robot Mom s Friend. At first, there was the robot which had some RHMs; the SLAM module, the power module, and the head module. Users could attach some RHMs to add some functions easily. In this case, as the Specification Size 500 x 500 x 1400 mm (w x d x h) Weight 70kg Operating System Windows XP, Embedded Linux, ucos, Tiny OS Camera Logitech QuickCam Pro 4000 x 4 Sensor Ultra Sonic x 12, IR Scanner x 2, Pressure Sensors x 8, Flexible Sensor x 8 Power Lead Battery (18Ah, 12V) x 4 Body Aluminium, Acryl Communication Wireless LAN, Bluetooth, ZigBee Fig. 8. The procedure of assembling RHMs to the service robot Mom s Friend. Users can select the RHM which they want and easily assemble the robot. Fig. 6. Various combinations of Mom s Friend. Using the RHM architecture, we have developed eight RHMs and it is assembled randomly. Especially, the top left robot is the service robot which can go on an errand. It uses seven RHMs except the speech module which is operated independently at this time. The top right robot is the chair robot which is controlled SONY PSP controller by user on the robot. Fig. 7. The connection managing system (top) and the connector part (bottom) of the common mechanical structure. The top left is the connection managing circuit board with power board and the top right is the data board. The bottom is the connector of a RHM. Fig. 9. The diagram of the internal signal flow. This experiment was done by five steps and we verified the RHM architecture. 1317

6 connectors were placed on the top and bottom of the RHM, users just heaped them up to attach without any screw and turning off the robot. When users commanded the robot to execute the functions which required additional RHM, the connection managing system announced it. And then users attached the RHM for the functions, and the robot connected it autonomously and performed the job. B. Experiment result based on Service Scenario We have taken the experiment based on scenario. In this experiment, we checked the seamless transfer of internal messages and operation of overall robot system without communication lag. The service scenario is as follows. Fig. 9 shows the diagram of the internal signal flow. 1) Request Hardware Resource Sharing: The speech module requested for sharing MICs and speakers and the vision module requested for sharing cameras to the head module. The connection managing system checked whether there were some data collisions. We verified the performance of the hardware resources sharing system. 2) Greeting & Emotion Expression Mode: The robot found the users by face recognition engine in the vision module and greeted by speech and facial emotion expression. We verified the seamless communication among all RHMs which had different OS and functions. 3) Home Appliance Module Attached: The robot checked whether it controlled home appliances or not and it notified the result to users. Users attached the home appliance control module and the connection managing system connected it automatically. In this step, users did not need to stop or shut down the robot for assembling. We verified the performance of the easy assembly, the automatic connection managing system, and the automatic software upgrading system. 4) Errand Mode: The robot listened to users order and it went to grab the bottle of water. It got the camera image from the arm module and sent it to the vision module to recognize object. During errand, users ordered the robot to control home appliances and the robot processed multiple jobs at the same time. We verified the seamless transfer of internal messages and operation of overall robot system without any communication lag. VI. CONCLUSIONS In this paper, we have considered the five key concepts for the RHM architecture to solve the problems of the conventional reconfigurable modular robots. We have designed the RHM architecture considering the five key concepts. The RHM architecture consists of three parts; mechanical architecture, software architecture, and connection architecture. Using the RHM architecture, the RHMs which have different OS and shape can be joined as one robot. Each RHM not only processes all functions by distributed computing in any combination, but also operates independently without the main module. It shares all hardware resources in the robot and manages all RHMs autonomously using the connection managing system. If the RHM architecture is applied to conventional modular robots, they can be easier for researchers and better performance system for users. We have implemented the reconfigurable heterogeneous modular robot Mom s Friend by applying the RHM architecture. In some experiments, we verified that the RHM architecture solved the five key concepts which were problems in conventional modular robots. In the future, we will focus on a multi robot system by applying the RHM architecture. ACKNOWLEDGMENT This research was performed for the Brain Korea 21 program supported by the Korean Ministry of Education and the Korean Ministry of Science and Technology and for the Visual Surveillance project by Samsung Techwin. REFERENCES [1] A. Castano, A. Behar, and P. Will, The Conro Modules for Reconfigurable Robots, IEEE/ASME Transactions on Mechatronics, vol.7, no.4, pp , Dec [2] Kamimura, A., H. Kurokawa, E. Yoshida, K. Tomita, S. Murata, and S. Kokaji, Automatic Locomotion Pattern Generation for Modular Robots, In Proceedings of the 2003 IEEE International Conference on Robotics & Automation (ICRA 2003), pp , [3] Jacob Everist, Feili Hou, and Wei-Min Shen, Transformation of Control in Congruent Self-Reconfigurable Robot Topologies, In Proceedings of the 2006 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2006), pp , Oct [4] David Brandt, and David Johan Christensen, A New Meta-Module for Controlling Large Sheets of ATRON Modules, In Proceedings of the 2007 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2007), pp , Oct [5] T. Taira, N. Kamata, and N. Yamasaki, Design and Implementation of Reconfigurable Modular Humanoid Robot Architecture, In Proceedings of the 2005 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2005), pp , Aug [6] Ferat Sahin, GroundScouts: Architecture for a Modular Micro Robotic Platform for Swarm Intelligence and Cooperative Robotics, In Proceedings of the 2004 IEEE International Conference on Systems, Man and Cybernetics, pp , Oct [7] J. Nielsen, and H.H. Lund, Spiking neural building block robot with Hebbian learning, In Proceedings of the 2003 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2003), vol.2, pp , Oct [8] T. Tohge, K. Shimada, and H. Iba, Evolutionary Morphology for Real Cubic Modular Robots, In Proceedings of the 2006 IEEE Congress on Evolutionary Computation, pp , Jul [9] S. Chitta, and J.P. Ostrowki, Motion Planning for Heterogeneous Modular Mobile Systems, In Proceedings of the 2002 IEEE International Conference on Robotics & Automation (ICRA 2002), vol.4, pp , May [10] K. Matsumoto, H. Chen, K. Shimada, J. Ota, and T. Arai, Automatic parameter identification for distributedly placed modular robots, In Proceedings of the 2002 IEEE International Conference on Robotics & Automation (ICRA 2002), vol.4, pp , May [11] R. Bischoff, and V. Graefe, Integrating vision, touch and natural language in the control of a situation-oriented behavior-based humanoid robot, In Proceedings of the 1999 IEEE International Conference on Systems, Man and Cybernetics, vol.2, pp , Oct