Chukyo Rescue A Team Description Paper for Robocup 2017 Virtual Robot League

Kazuma Ito, Kazuki Yokochi, Yuuki Tanaka

Chukyo University, Aichi, Japan

https://sites.google.com/site/chukyorescuervrl/chukyo-rescue-a

Abstract In this team description paper, we describe our team's work recently and agenda by the competition. Our Goal is an integration of maps that are got by multi-robot. We tried to make a map by a monorobot or multi-robot with ROS, as a result we found the problem which mapping with multi-robot was inaccurate. We are challenging to solve the problem by developing a method of integrating maps.

1 Introduction

We will use some quadrotor robots. We are challenging to develop a method to integrate a map of a multi robot working in a remote place. In rescue activities, it is very important to earn an integrated map of all disaster sites. After that, in order to earn a map in a short time, you need to create a map using a multi robot. At the moment it is easy if there is a program to integrate the map, but posting the SLAM does not have the function of integrating the map[5][6]. In this rescue virtual robot league[1] team description paper, we describe our method to build an integration map in a simple way, indicating that there are some conditions in the integration method. Section 2, we show our goal. Section 3 shows the system overview of our software. Section 4 describes the reason of using the quadrotor robot. Some results of SLAM are shown in Section 5. Our method of map integration is shown in Section 6. Section 7 describes our exercising. Section 8 describes our future works. And Section 9 shows the release schedule of our software.

2 Our Goal

We have two challenges. One is developing a software to integrate data of among robots. The other is introducing a map integration software into our system. As a method of integrating maps, we are investigating the strategy to read the QR code attached to the robot, recognize the vector direction of the map, unify the direction of the map and integrate it. Even within an unstable environment, by integrating the maps among robots, it is possible to reliably achieve integration of maps. Also, by adding information of fire origin and blood streaks, design a system that introduces elements useful for on-site activities of the rescue team. Now, we can do only 2D Mapping by mono-robot. On the next step, we want to get the map available as real time and 3-Dimension from some robots. The first issue is a problem to occur when robots are trying SLAM. The second issue is another problem in the case of coordinates that have equal x and y, but unequal z, for example in the building. In the building, the coordinate z is different by oor, and moreover on oor or desk in case of the same oor. We are challenging integration of map from robots with considering the coordinate z. We will use some quad rotor robots. By floating in the air, the quad rotor can do the search without being affected by the terrain. Using that function, you can generate a map of a place where the terrestrial robot can not search. Furthermore, it executes 3D search from the atmosphere and enables generation of 3D map. To achieve, we need a SLAM to output 3D map or way to generate a map similar to 3D by use of 2D SLAM. At first we tried to make a map by two robots with Hector slam (these are ROS[7] default packages). The results were depending on the situation. We plan to achieve the method of mapping and high accurately integration by the time the competition start.

3 System Overview

Our system consist from ROS as Fig. 1. Gazebo[4] is used for a virtual environment. We use ROS for a robot controller, SLAM and so on. Human Operator get information of camera view and whole map, and command robots ROS runs on Ubuntu, receive information of a range-sensor and so on from a robot in Gazebo, and output a map data published by SLAM algorithm. Also, ROS directs a robot by human operator 's command. One Ubuntu and ROS system is allocated to one robot. Each map data outputted by ROS are integrated, and the result, as a whole map, is shown an operator. Similarly, the image of the camera attached to each robot is shown to a human operator. Basing on information of the whole map data and these images, the operator commands robots through the command translation program hatched rectangle. Ubuntu version is 16.04, Gazebo version is 7.5 and ROS version is Kinetic. Fig. 1 is our system architecture. Hatching rectangles are developing now.

4 SLAM

Fig. 2 (a) (b) (c) are mapping results of a simple rectangle room. Fig. 2 (a) is a map of gmapping[5] by mono-robot. Fig. 2 (b) (c) are 2D map of gmapping by two robots. Fig. 2 (b) shows the mapping was the success in early time. But Fig. 2 (c) shows the mapping became the fault at last. Through this experiment we realized that depending on the situation, the simple SLAM mapping is possible.

In actuality, there is a case of sharing each Point Cloud Data(PCD) because each robot works separately. Thus we have a problem to be solved, is to develop a method to integrate maps without the sharing each PCD by changing the SLAM algorithm or use situation.

(a) Mapping by 1 robot (b) Mapping by 2 robots in early (c) Mapping by 2 robots at last. Fig. 2. Mapping in a simple situation

5 Using Quad Rotor Robot

The reason of our using some quad rotor robots is that the quadrotor can move without being influenced by the terrain. Now we can create only 2D mapping, but we want to create a 3D map by using quad rotor robots that can move up and down in the air.

6 Map Integration

We will use the OHM TSD SLAM to create a map by using multi-robot[3, 2]. The OHM TSD SLAM has following characters.

The OHM TSD SLAM can create a map by using PCD from multi-robot simultaneously.
Integration phase is needless after a mission.
The OHM TSD SLAM has some optimized parameters for using HOKUYO LIDARs or same type LIDARs which are equipped on rescue robots in ordinary rescue missions.

Currently, we could not finish introducing the OHM TSD SLAM into our robot controlling system.

7 Exercising

Since the SLAM is weak against a sudden turn and/or fast moving of a robot, it is necessary to turn slowly and/or move slowly. Then we are exercising that controlling a quad rotor robot slowly. If a quad rotor robot go near the wall too close, it will cause collision between the robot and the wall and the robot become unstable. So we are exercising how to operate the robot not to get too close to the wall.

8 Future Works

This is the first time that we used quad rotor robot, and we could not reach to build our own user interface. Therefore, we would like to make quad rotor robot interface more easy to use it. When we integrate maps which have some levels, stairs or grade separated crossing, we should consider both plane and vertical direction. Also, at the time of map generation, we have to create an algorithm that outputs the degree of bleeding volume of the victim and extracted the fire source from the image data, as well as including the position of the rescuer.

9 Release Schedule

We can release our system on a github repository linked from our site by the end of June 2017.

References

H. L. Akin, N. Ito, A. Jacoff, A. Kleiner, J. Pellenz, and A. Visser. Robocup rescue robot and simulation leagues. The AI Magazine, 34(1), 2013.
P. Koch, S. May, M. Schmidpeter, M. Kühn, C. Pfitzner, C. Merkl, R. Koch, M. Fees, J. Martin, D. Ammon, et al. Multi-robot localization and mapping based on signed distance functions. volume 83, pages 409–428. Springer, 2016.
S. May, P. Koch, R. Koch, C. Merkl, C. Pfitzner, and A. Nüchter. A generalized 2d and 3d multi-sensor data integration approach based on signed distance functions for multi-modal robotic mapping. In VMV, pages 95–102, 2014.
Open Source Robotics Foundation. http://gazebosim.org/, date:15.May.2017.
ROS.org. gmapping. http://www.ros.org/wiki/gmapping.
ROS.org. Hector SLAM. http://www.ros.org/wiki/hector_slam.
ROS.org. ROS. http://www.ros.org/wiki/.