RoboCupRescue 2013 - Robot League Team AriAnA (Iran)

Amir H. Soltanzadeh, Mehdi Soltanzadeh, Mahdi Emami

Robotics Laboratory Engineering School, Niayesh Campus Islamic Azad University of Central Tehran Branch Pounak Sq., Chaharbagh Ave., Tehran, 1469669191 Iran

http://robot.iauctb.ac.ir

Abstract This document describes the approach of AriAnA rescue robot team for RoboCup 2013. The team is active in RoboCup Rescue since 2006 with focus on advanced mobility tele-operated robots. At the end of 2010, our team funded for a new project to develop autonomous robots for harsh environments. This year we keep on developing robust autonomous navigation algorithms in rough terrains and will be bringing two fully autonomous robots capable of traversing yellow and orange arenas.

Introduction

AriAnA rescue robot team represents IAUCTB (Islamic Azad University of Central Tehran Branch) and develops advanced mobility rescue robots since 2006. The team had cooperation with an industrial group, AVA Strategic Alliance, in 2009-2010 timeframe to participate as a multi-national team (AriAnA & AVA) in RoboCup. The collaboration ended with first place award in Khwarizmi Robotics Competitions* in 2010. After our success, the team funded for a new research project called AMIR (Advanced Mobility Intelligent Robot) in which we develop fully autonomous mobile robots capable of traversing rough terrains (similar to the orange arena).

At the beginning, we designed and built a new tracked platform (hereafter referred to as "Diamond"). This simple skid steering robot has enough mobility to negotiate crossing ramps of the orange arena without applying any time consuming 3D navigation algorithm for cluttered areas. Despite of the huge amount of codes produced within the past 5 years, we chose ROS (Robot Operating System) [1] as the middleware of AMIR. This speeds up programming/debugging and lets us to easily utilize the outcomes of other research group in the area of autonomous mobile manipulation.

Besides Diamond, we will deploy another tracked robot (DELTA) developed during the past years. This robot won Best in Class Autonomy award of Iran-Open 2011 but, it can only explore yellow arena due to its limited mobility. Fig.1 shows the robots designed and built by AriAnA rescue robot team since 2006.

In addition to hardware modifications, we work on these improvements to our system in 2013:

• Detecting QR labels
• 2.5D perception for more accurate mapping
• Utilizing RGBD sensors for terrain classification
• Exploring the orange arena by autonomous robot
• Adding a 5 DOF manipulator to Diamond

• ALPHA, BETA, and BETA II are delivered to ISOP Co. (our former sponsor and the representative of AVA Strategic Alliance in Iran).

Team Members and Their Contributions

Faculty Members:

• Mohammad Eftekhari Advisor (Mechanics) • Kaveh Kangarloo Advisor (Electronics) • Shahrzad Hamidi Advisor (Control) • Reza Ravani Advisor (Computer)

Staff Members:

• Amir H. Soltanzadeh Team leader, Mechanics

• Mahdi Emami Electronics • Mehdi Soltanzadeh Software

Student Members:

• Mahdieh Khiabani Team manager • Behzad Peykari Mechanics • Amir R. K. Hosseinpour Mechanics • Alireza Amini Electronics • Hassan Gholami Electronics • Afshin Aryainejad Electronics • Hamed Sabti Software • Alireza M. Alizadeh 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 two laptops, gamepad, access point, ethernet switch, power system and a pair of antennas. We will carry the robots and OCU to the 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 robots 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 2 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

Control Method and Human-Robot Interface

As stated before, we will deploy two robots to perform autonomous navigation and victim detection within the yellow, orange and radio drop out zones. These robots are reasonably identical from electrical point of view. Fig.2 illustrates default hardware block diagram of our autonomous robots.

The core of this block diagram consists of a PIC based controller and a main board which is a PC/104+ compatible, ruggedized Pentium M 1.6 GHz industrial computer with 2MB L2 cache, 2GB DDRAM and 8 GB Compact Flash (CF). A light Linux (Ubuntu 11.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 complicated autonomous systems that we are dealing with in the AMIR. After a feasibility study, we decided to utilize ROS as our new middleware to perform actuated sensing and autonomous navigation in harsh environments. 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].

Fig. 3 shows default software block diagram of our autonomous robots. We slightly modify this block diagram in situations like when a module is overloading onboard computation.

Adjustable Autonomy

Our robots are 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)

This year, we have a plan to take advantage of "rviz" (provided by ROS) in our new GUI to present all sensors information (including global map) in a 3D environment.

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 result of our RBPF SLAM using outputs of an LRF and IMU carried by a person in the NIST test arena at Iran-Open 2011.

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 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 odometry 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 (RoboCup Rescue Robot League) 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 when they are available. This results in fairly accurate estimation of position even when only two sources are presented.

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.

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]. Besides the main LRF, the robots utilize a tilting short range LRF (URG-04 LX) to acquire 3D point cloud for terrain 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 DELTA 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

A set of thermopile array sensors (TPA81) from Devantech scan environment for heat sources at 2 Hz. When such a heat source is detected, robot turns to the source for accurate victim verification.

Thermal Imaging Camera

In addition to the temperature sensors, each robot is equipped with a thermal imaging camera (AXT100) from ANN ARBOR SENSOR SYSTEM. This lightweight, compact, 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 raw images to 256×248 resolution at 9 fps.

USB Camera

A pair of HD quality USB color cameras from Logitech (QuickCam Pro) are used for victim verification.

RGBD Sensor

We take advantage of Microsoft Kinect to produce depth image. After calibration and segmentation, probable holes in the walls can be detected. 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 CO$_2$ sensors.

Microphone

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

Robot Locomotion

As stated before, our robots are differentially steered tracked vehicles with different locomotion characteristics suitable for their specific tasks.

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. 8-1). Two highly efficient torque/velocity controlled 120 W brushless DC motors power 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 [15] which reduces the probability of getting stuck in debris. Fig. 8-2 depicts overall dimensions of Diamond.

Other Mechanisms

(This section header is empty in the original)

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.

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. 9).

System Cost

The following tables list approximate cost of our system.

Price list of a typical platform

Total Price 10,174 ±1% USD

Price list of sensor payload

Total Price 21,353 ±0.5% USD

Price list of OCU

Total Price 2,924 ±0.5% USD

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 organization and team working. In other words, they well know how to use their available resources in more efficient way.

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 the 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 previous RC competitions indicate that autonomous robots typically find far less victims in comparison with tele-operated ones. 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.

Importance of Administrative Tasks

In 2011, our luggage got stuck in the custom and we received them in RoboCup venue at the end of preliminaries due to an administrative mistake in Iranian custom (they had forgotten to include the packing list). Even worse, the robot's electronics had a serious damage (probably occurred within the custom clearance) and it took one extra day to fix the problem. Eventually we missed the competitions as a result of the administrative mistake. All these accentuate to the importance of the non-technical issues in the success of a RC team.

Appendix

Qualification Videos (YouTube)

http://youtu.be/6hw4qb1O0sc

http://youtu.be/9PvualS-zTQ

http://youtu.be/9PvpfVlm93Q

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. 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)