RoboCupRescue 2011 - Robot League Team AriAnA (Iran)

Amir H. Soltanzadeh, Amir H. Rajabi, Arash Alizadeh, Golnaz Eftekhari, Mehdi Soltanzadeh

Robotics Laboratory Engineering School, Niayesh Campus Islamic Azad University of Central Tehran Branch

http://robot.iauctb.ac.ir

Abstract This document describes the approach of AriAnA rescue robot team for RoboCup 2011. The team is active in RoboCup Rescue since 2006 and has participated in the last two years as a part of a multi-national team. This year we have focused on autonomous navigation in rough terrains and will be bringing only one fully autonomous mobile robot capable of traversing yellow and orange arenas.

Introduction

AriAnA rescue robot team represents IAUCTB (Islamic Azad University of Central Tehran Branch) and develops mechatronical layers of high mobility rescue robots (i.e. hybrid locomotion, semi-active controlling and power management) since 2006. The team began cooperating with an industrial group (AVA Strategic Alliance) in 2009 which led to participating as a joined multi-national team in RoboCup 2009 and 2010. We continued the collaboration up to the end of 2010 and won first place award of Khwarizmi National Robotics Competitions within this year.

After the competitions, our team was funded for a new research project called AMIR (Advanced Mobility Intelligent Robot) in which we will develop a fully autonomous mobile robot capable of traversing rough terrains (similar to the orange arena).

To reduce the time of low level programming/debugging, we decided to use ROS (Robot Operating System) [1] which is becoming very popular in robotics communities. At the time being, ROS is implemented on our existing autonomous robot (DELTA) which doesn't have enough mobility to pass the orange arena. To solve this problem, we have designed a new platform (hereafter referred to as "Diamond") and we will use it in RoboCup 2011. Fig.1 shows the robots built by AriAnA rescue robot team since 2006.

Team Members and Their Contributions

• Dr. Hossein Mahbadi Advisor • Dr. Mohammad Eftekhari Advisor • Dr. Armen Adamian Advisor • Amir H. Soltanzadeh Team leader, Technical manager • Arash Alizadeh Mechanics • Amir Hossein Rajabi Mechanics • Golnaz Eftekhari Electronics • Mehdi Soltanzadeh Software • Hedieh Vahabi Ahooie Software • Further student members may join to the team.

And many appreciations to all former members of AriAnA rescue robot team.

Operator Station Set-up and Break-Down (10 minutes)

As in previous years, we use a custom designed OCU (Operator Control Unit) for fast set-up and break-down. This OCU currently consists of a laptop, gamepad, access point, ethernet switch, power system and a pair of antennas. We will carry the OCU and Diamond to warm zone (next to the arena) using a trolley five minutes before each mission. Then we will turn the entire system on to perform automatic system check up. The system will remain powered up on "hot stand-by" until our mission starts. This set-up strategy is similar to what had been applied in 9/11 USAR (Urban Search And Rescue) missions [2].

When a mission starts, two team members put the robot in start point and other two members carry the OCU to operator control station. Once whole devices are placed in their right places, the operator starts controlling. This is done in less than 2 minutes. At the end of each mission, the operator has two specific tasks: stopping the system and delivering mission data while two members are taking the robot out of the arena. The break-down procedure takes about 5 minutes.

Communications

All our robots have a 5 GHz IEEE802.11a Access Point/Bridge with a pair of external antennas to exchange data (e.g. high level control commands, sensor data and digital audio/video) with another one in OCU.

We use channel 36 as our default setting (Table 1) but it can easily be changed to any possible channel if it is needed.

Used communication frequencies

| Rescue Robot League | AriAnA (IRAN) | | Frequency Channel/Band | 5.0 GHz - 802.11a | | Power (mW) | 36-64 (selectable) | | | 50 |

Control Method and Human-Robot Interface

As stated before, we will deploy only one robot to perform autonomous navigation and victim detection within the yellow, orange and radio drop out zones. This robot is very similar to DELTA from electrical viewpoint. Fig.2 illustrates hardware block diagram of Diamond.

The core of this block diagram consists of an FPGA based controller and a main board which is a PC/104+ compatible, ruggedized Pentium M 2.0 GHz industrial computer with 2MB L2 cache, 2GB DDRAM and 8 GB Compact Flash (CF). A light Linux (Ubuntu 10.4 Server Edition) is installed on the CF to run robot control software.

Robot Operating System

Although we have been using the Player framework [3] in our robots since 2007, it is not designed for complex intelligent systems that we are dealing with in the AMIR. After a feasibility study, we decided to utilize ROS (C Turtle) to perform actuated sensing and autonomous mobile manipulation in Diamond which its software block diagram is illustrated in Fig. 3.

ROS is an open source, meta-operating system for robots. It provides the services one would expect from an operating system (e.g. hardware abstraction, low level device control and package management) [4].

Adjustable Autonomy

Diamond is supposed to navigate in a variety of environments with different levels of traversal difficulty. We have implemented an adjustable autonomy approach to permit the operator to enter to the robot controlling loop when it is needed. The presented autonomy modes are:

• Teleoperation: no sensors are used to keep the robot from bumping into objects
• Safe: teleoperation with obstacle avoidance provided by the system
• Shared: semi-autonomous navigation with obstacle avoidance in which user marks his/her desired target point on the map and robot plans a safe path to reach to the target
• Full autonomous: robot chooses a target point (based on Frontier Exploration algorithm [5]) then safely navigates

HRI

Obviously, design of HRI (Human Robot Interaction) directly affects the ability of operator to understand the current situation, make decisions and provide high level commands to the robotic system. Therefore the operator's requirements and the way of presenting them to him/her should be emphasized [6].

Our GUI (Graphical User Interface) is developed since 2009 to support adjustable autonomy. It allows the operator to use identical GUI's to control robots with different levels of autonomy. As it is shown in Fig. 4, the GUI has 4 different panels:

• Drive: a video centric GUI[7] for tele-operation
• Report: to record victims' information
• Map: a map centric GUI for autonomous controlling with selectable autonomy
• Log: shows recorded logs of mission (i.e. sensor data and control commands)

Map generation/printing

Our mapping system comprises of two main components: Occupancy Grid (OG) SLAM (Simultaneous Localization And Mapping) and accurate pose estimation.

Occupancy Grid SLAM

The 2D mapping module is based on recently well known open source GMapping codes [8]. It uses grid-based SLAM algorithm with RBPF (Rao-Blackwellized Particle Filters) by adaptive proposals and selective resampling [9]. Empirical studies have proved robustness of this algorithm especially in large environments with several loop closing [10]. However, we have modified this algorithm to make it real-time even with tens of particles each of which represents a hypothesis of robot pose besides a map. This results in fairly accurate maps even in very noisy conditions. As an instance, Fig. 5 shows the outcome of our RBPF SLAM using the logs of an LRF and IMU carried by a person (Dr. Johannes Pellenz, TC) in the NIST test arena at RC10 RRL (RoboCup 2010 Rescue Robot League).

Accurate Pose Estimation

Generally, the registration process of most SLAM algorithms needs an estimation of robot pose when the recent scan is taken relative to the pose of the previous or some other earlier scans. The more accurate pose estimation, the need to fewer particles. Therefore, a variety of techniques are applied to have more accurate pose estimation in 6 DOF (the (x,y,θ)T form is used in the RBPF). Fig. 6 illustrates the output of our entire mapping system (RBPF OG SLAM with accurate pose estimation) using LRF and IMU logs of the team Resko (University of Koblenz, Germany) in German-Open 2010 Rescue Robot League.

Slip Compensated Odometry by Gyro

Wheel encoder based odometry is known as the most commonly used technique of robot pose estimation. On the other hand, odometry data of tracked vehicles is very error prone due to the huge slippage while steering. A novel approach is implemented to eliminate the slippage in odometery calculations taking IMU data and mechanical characteristics into account. This method is called SCOG (Slip Compensated Odometry by Gyro sensor) and is described in [11].

Laser Odometry

A fast ICP (Iterative Closest Point) scan matching method [12] is used to estimate the position and orientation of robot in horizontal world plane by aligning consecutive scans from the laser rangefinder.

Visual Odometry

To have more accurate pose estimation within currently non-static RC RRL arena, we have implemented an open source visual odomtery using stereo vision. It finds suitable image features for tracking and matches them frame by frame. By having depth of these points, we can compute a likely 6 DOF pose for each frame.

EKF Data Fusion

After obtaining pose estimations by several individual methods, these estimates are used in a sensor-independent manner for accurate state estimation. An open source Extended Kalman Filter (EKF) fuses the relative position estimates of encoder, IMU, laser and stereo odometries.

Sensors for Navigation and Localization

As stated before, DELTA and Diamond are very similar to each other in terms of hardware and sensor arrangement. Their navigation sensors are (Fig. 7):

Camera

Two identical wide angle 1/3" high resolution Sony CCD color cameras provide a fine environmental awareness for tele-operation. Videos of these cameras are converted to MPEG-4 format and streamed over Ethernet with Real Time Streaming Protocol (RTSP) by means of a MOXA V351 video server. We have a plan to replace this system with a pair of HD quality USB color camera from Logitech.

Optical Shaft Encoder

All our locomotion platforms are powered by Maxon Gearhead DC motors coupled to HEDL 5540 optical shaft encoders. The motor controllers (Maxon EPOS) connected to these encoders send motors' data (i.e. position, velocity and acceleration) to the motherboard via CAN interface.

LRF

Our robots are equipped with Hokoyo UTM-30 LX scanning LRF. This long range (up to 30 m), wide angle (270°) and fast (40 Hz) LRF is mounted on a gyro controlled gimbal-type servo mechanism to stay horizontal (in world frame) while scanning [13]. The autonomous robots utilize a tilting short range LRF (URG-04 LX) besides the main LRF to acquire 3D point cloud for train classification.

IMU

Each robot has an IMU (Xsens MTi) to measure its 3 DOF orientation and 6 DOF accelerations.

Ultrasonic Ranger

Twelve Devantech SRF08 ultrasonic sensors are placed around the autonomous robots for more reliable collision avoidance.

Stereo Vision Module

DELTA has a Stereo-On-Chip (STOC) module from Videre Design for visual odometry. This device has an embedded processor which runs a version of the SRI Small Vision System (SVS) [14] stereo algorithm. It is connected to an industrial computer with IEEE 1394 (Firewire) interface and produces 30 frames per second 3D point cloud at a resolution of 640×480 pixels.

Sensors for Victim Identification

The autonomous victim detection is mainly based on thermal scanning to find heat sources at the temperature of human body. The victim detector module also keeps an eye on the other victim identification sensors. For example, when the robot enters to a place with large amount of CO2 or noise level, it moves slowly and changes exploration strategy to increase the chance of finding victims (knowing that victims are mostly placed in corners that are not points of interest for navigation module). We are also developing a hole-detection algorithm using depth images provided by a low cost 3D Imager.

Temperature Sensor

Two 8×1 pixels thermopile array sensors from Devantech mounted on a precise servo are used in DELTA to scan environment in 42v×180h deg. field of view for heat sources having 37±5 degrees Celsius at 1 Hz. When such a heat source is detected, robot turns to the source for accurate verification by thermal camera. We will replace this servo controlled thermal scanner with 32 fixed thermopile array sensors mounted on a 1 DOF manipulator in Diamond to have real-time panoramic thermal image. This new combination increases the chance of finding victims located in very high or very low heights even from close distances.

Thermal Imaging Camera

Once a heat source is detected, the robot turns to the source and verifies it by means of a thermal imaging camera (AXT100) from ANN ARBOR SENSOR SYSTEM. This compact, lightweight and low cost thermal camera has a 32×31 uncooled FPA (Focal Plane Array) to provide temperature information in a range of -20ºC to 600ºC with 2ºC resolution. Its on-board image processing smoothes the 32×31 raw images to 256×248 resolution at 9 fps.

3D Imager

We take advantage of recently hacked Microsoft Kinect to produce depth image. After calibration and segmentation, probable holes in the walls can be detected (Fig. 8). Once such a hole is detected, its location will be verified by thermal sensors.

CO2 Sensor

Each robot is equipped with a Vaisala GMM CO2 sensor to sense exhaled CO2 from victims. They have a response time of about 20 sec. which is common in most CO2 sensors.

Microphone

A sensitive microphone is used to measure sound level around the robot.

Robot Locomotion

As mentioned, all our robots are differentially steered tracked vehicles. They have different locomotion characteristics to make them suitable for their specific tasks [15].

DELTA

DELTA is a fully autonomous mobile robot which operates only in yellow arena. It has simple Two-Tracked drivetrain with rather small footprint (Fig. 9-1). Two highly efficient torque/velocity controlled 120 W brushless DC motors powers it to steer in maximum speed of 1.2 m/s.

Diamond

In contrast with DELTA, Diamond is designed to have rather high mobility while it should be easy to control. It benefits the concept of full body crawler locomotion [16] which reduces the probability of getting stuck in debris or turning over on steep ramps. Fig. 9-2 shows overall dimensions of Diamond.

Other Mechanisms

Our robots utilize a custom designed power management system for remote supervisory control (e.g. switching devices on/off, voltage-current monitoring and limiting). The power manager is the only device that a user can directly turn it on/off. When it booted up, it follows a step by step procedure to turn on and test the required devices to be wirelessly connected to the OCU (i.e. Ethernet switch and Access Point) and if anything goes wrong, it begins blinking an LED and alarming.

Once the wireless connection is established, the power management system waits for operator's commands to turn on/off any requested onboard device even the industrial computer via web interface. This is a useful capability especially when there is no direct access to a robot that may happen in real USAR missions.

In the RoboCup competitions, this provides us an extra option of resetting robots without touching them which results in resetting a robot without losing time and score.

Power Management System

Our robots utilize a custom designed power management system for remote supervisory control (e.g. switching devices on/off, voltage-current monitoring and limiting). The power manager is the only device that a user can directly turn it on/off. When it booted up, it follows a step by step procedure to turn on and test the required devices to be wirelessly connected to the OCU (i.e. Ethernet switch and Access Point) and if anything goes wrong, it begins blinking an LED and alarming.

Once the wireless connection is established, the power management system waits for operator's commands to turn on/off any requested onboard device even the industrial computer via web interface. This is a useful capability especially when there is no direct access to a robot that may happen in real USAR missions.

In the RoboCup competitions, this provides us an extra option of resetting robots without touching them which results in resetting a robot without losing time and score.

Team Training for Operation (Human Factors)

Our new robot works in different levels of autonomy ranging from pure tele-operation to full autonomy. A typical computer user without any background of robotics can control it after half an hour of familiarization.

Additionally, the simulation environments of the Player project (Stage and Gazebo) are integrated to the ROS. This lets us to train people and develop software without damaging real robots. Fig. 10 shows a screenshot of a simulated environment in which we are testing navigation algorithm of DELTA.

Possibility for Practical Application to Real Disaster Site

Having a real working rescue robot is a highly motivating goal and we are taking our first steps towards this high goal of rescuing human lives.

Among aforementioned platforms, ALPHA and BETA has been evaluated in several real urban and suburban rough terrains by our former sponsor (Fig. 11).

System Cost

The following tables list approximate cost of our system.

Price list of a typical platform

Price list of sensor payload

Price list of OCU

Lessons Learned

Award winning teams of RC RRL may (or may not) apply the most cutting edge technologies and innovative ideas but, they certainly are the best prepared teams in terms of device and team working. In other words, they well know how to use their available resources in more efficient way. This cannot be achieved without having team strategy and permanent practices.

Team Strategy

The team CASualty (Australia) in RC09 is a good example of a team with successful strategy. They managed to win three best in class awards using two robots.

Since the outcomes of preliminary round have major effect on the results of best in class evaluations, teams should decide on which category they are going to focus on. Furthermore, an exact instruction of what each member should do within a mission (especially in emergencies), will be helpful.

Autonomy with Mobility

From a quantitative point of view, results of two previous RC competitions indicate that nearly no team was successful in the yellow arena. Apart from efficiency and robustness of applied algorithms, almost all autonomous robots suffer from inefficient mobility and placement of victim detection sensors.

Considering the new rules, a number of improvements in mobility of autonomous robots are inevitable.

References

1. ROS: http://www.ros.org/wiki/
2. Murphy, R.R.: Activities of the Rescue Robots at the World Trade Center from 11–21 September 2001. IEEE Robotics & Automation Magazine (2004) 50–61
3. Gerkey, B. P., Vaughan, R. T., Howard A.: The Player/Stage Project: Tools for Multi-Robot and Distributed Sensor Systems. International Conference on Advanced Robotics (ICAR 2003), Coimbra Portugal (2003) 317–323
4. Quigley, M., Gerkey, B., Conley, K., Faust, J., Foote, T., Leibsz, J., Bergery, E., Wheelery, R., Ng, A.: ROS: an open-source Robot Operating System. ICRA09 (2009)
5. Yamauchi, B.: A frontier-based approach for autonomous exploration. IEEE International Symposium on Computational Intelligence in Robotics and Automation (1997)
6. Adams, J. A.: Critical Considerations for Human-Robot Interface Development, AAAI Fall Symposium, Human Robot Interaction Technical Report (2002)
7. Keyes, B.: EVOLUTION OF A TELEPRESENCE ROBOT INTERFACE. Final thesis for M.Sc. degree. Department of Computer Science. University of Massachusetts Lowell (2007)
8. GMapping: http://www.openslam.org/gmapping.html
9. Grisetti, G., Stachniss, C., Burgard, W.: Improving grid-based SLAM with rao-blackwellized particle filters by adaptive proposals and selective resampling, ICRA05 (2005)
10. Balaguer, B., Carpin, S., Balakirsky, S.: Towards Quantitative Comparisons of Robot Algorithms: Experiences with SLAM in Simulation and Real World Systems. IROS workshop (2007)
11. Nagatani, K., Tokunaga, T., Okada, Y., and Yoshida, K.: Continuous Acquisition of Three dimensional Environment Information for Tracked Vehicles on Uneven Terrain. In Proceedings of the 2008 IEEE International Workshop on Safety, Security and Rescue Robotics, pages 25–30 (2008)
12. Censi, A.: An ICP variant using a point-to-line metric. ICRA08 (2008)
13. Pellenz, J.: Rescue robot sensor design: An active sensing approach. Fourth International Workshop on Synthetic Simulation and Robotics to Mitigate Earthquake Disaster (2007)
14. Konolige, K.: The Small Vision System. http://www.ai.sri.com/~konolige (2006)
15. Soltanzadeh, A. H., Chitsazan, A., Ghazali, S. A. S.: TDP of AriAnA & AVA (Iran & Malaysia). RoboCup Rescue Robot League (2010)
16. Yoshida, T., Koyanagi, E., Tadokoro, S., Yoshida, K., Nagatani, K., Ohno, K., Tsubouchi, T., Maeyama, S., Noda, I., Takizawa, O., Hada, Y.: A High Mobility 6-Crawler Mobile Robot 'Kenaf', Proc. 4th International Workshop on Synthetic Simulation and Robotics to Mitigate Earthquake Disaster. SRMED2007, pp.38 (2007)