First Place of Rescue Robot League at AUTCup 2010

Last week we took part in AUTCup 2010, a national robotic event; but this time with some quests from countries like USA, Germany etc. Generally, the competitions consisted of two categories: RoboCup Leagues (all the simulation leagues with most robot leagues) and Non-RoboCup Leagues (e.g. Mars Rovers, Deminers etc.).

The Rescue Robot League was very similar to Iran-Open competitions. Although the team MRL was absent, all other famous Iranian teams made it a very challenging league. The arena was a smaller copy of RoboCup 2010 rescue robot arena with several steep roll ramps and more difficult red arena step field.

Since our managing team had decided to participate with minimums; we registered only 5 members (usually 3 of them were ready on-site) and utilized BETAII, one of our tele-operated robots which had several minor modifications after coming back from Singapore. We also had another change; our former operator, Mehdi (my older brother) was not able to attend at AUTCup and I had to control the robot myself. I was well familiar with controlling BETA using Xbox 360 joystick but, now we were using Logitech freedom and I needed to test this new controller. Thanks to my teammates, I had several test & practice runs in setup and preliminary days. Now I was ready to do almost everything with robot at final rounds.

As our competitors said, we had two dramatic final rounds in which we scored all the victims on elevated floor and inside the car. In the second final round we all knew that we won’t win the first place unless I open the door of a bucket using manipulator and identify its victim. We practiced and I found a trick to open the door using our 2DOF manipulator. Fortunately everything went fine at the final round and I could do what I practiced!

Thanks to all my existing and former teammates who made it to become true!

Man-packable rescue robots rather than Superman-packable!

Obviously rescue robots should be light enough to be carried by rescue personnel to the disaster zones. US Center for Robot Assisted Search And Rescue (CRASAR) emphasizes on the usage of man-packable and more specifically “shoe box size” robots in Urban Search And Rescue (USAR) missions.
However the existing rules of RoboCup Rescue Robot League (RC RRL) do not encourage participants to develop small size and light weight robots. If you take a close look at the participating teams of RC RLL, you will hardly find man-packable robots. In my opinion, this is only due to the lack of “reward/penalty” mechanism for such a crucial parameter.
Certainly the size and weight of a robot can only be decreased at a cost of decreasing its electromechanical capabilities (i.e. mobility, manipulation and victim detection) or increasing its final price but why we should pay this high price?! Unfortunately I haven’t found the answer in the RC RRL rules yet; even worse, heavier robots sometimes have potentially better performance in RC RRL (note that the robots of iRap-Pro – the first place award winning team of RC09 and RC10 – are definitely heavier than 30 Kg.).
If we accept that the performance of a mobile robot is proportional to its weight, it cannot be right to evaluate a 30 Kg robot with an over 50 Kg. one. Considering the very tight schedule of RoboCup competitions, it won’t be possible to have several weight-class based (e.g. light weight, heavy weight etc.) evaluations. On the other hand having weight-classified evaluations may not encourage participating teams to work on reducing the weight of their robots.

My suggestion is to utilize “dynamic elements” in the arena so that the difficulty of traversing them changes based on the passing weight. An example of such an element is shown in the top of this post. This element is just like a simple 45 deg slope but it is connected to the elevated floor using a pair of sprung joints instead of hinges. Now, the distance between top end of this ramp and the elevated floor will change based on the amount of mass on it. As it’s shown in the picture, the robot with mass “M” will face a gap with length “D” which is larger than the distance “d” caused by the robot with mass “m”. This means that a robot should have greater mobility if it is heavier!

New Scoring Method for RoboCup Rescue

“Time” is the most important limiting factor in an Urban Search And Rescue (USAR) mission. Actually the chance of surviving victims drastically decreases 24 hours after a disaster. In this critical situation, rescue personnel should avoid any risky tasks. Published texts indicate that surviving a trapped rescuer takes about 4 hours for a team of 10 rescuers and it’ll take almost 10 hours if the rescuer is injured or entombed!

Rescue teams can reduce the risk of surviving victims by means of robotics. Robots can provide accurate information about the collapsing walls, hazard materials etc. what rescue dogs cannot do. One may want to put a camera on a rescue dog to inspect collapsed buildings but, these video streams certainly won’t provide the environmental awareness that a smoothly controlled tele-operated robot can. In other words the “accuracy and quality” of environmental awareness (identification of victims can also be considered as a part of environmental awareness) provided by robots is the most significant advantage of these instruments in comparison with rescue dogs. We can also use these two parameters to have a rough estimation about the success of rescue phase in a USAR mission: “the more accurate and usable information one gets in a search phase, the more victims are expected to be survived in rescue time.”

In RoboCup Rescue scenario that is a standardized simulation of real disasters, rescue teams very well know how many people are injured, who they are and where they are located (rescuers may get this information from a survived person in real situations). The task is “to explore the arena by a team of robots with different levels of autonomy in a limited time to gather accurate and reusable information about the surroundings and victims.”
Like in a real USAR mission, here we can expect that a victim will be survived if a safe path to his/her location is discovered. Therefore, a victim should first be detected then his/her exact location be marked on the currently generated map of the environment to start rescuing. If the team cannot find a safe path to the location of detected victim, the rescuers should probably put their own life in a serious danger to survive that victim. This means that a “search phase” is not accomplished unless rescuers can prepare a map of the environment having accurate location of victims with a path for following. If we suppose that the chance of rescuing an identified victim linearly increases with the quality and accuracy of generated map, the following formulas can be used for evaluating general performance of a rescue team:

(1) Score of a detected victim = (mapping score at the point / maximum mapping score) x (victim identification score / maximum score of victim identification)

(2) Final score of a mission = (100 / QTY of all victims) x (sum of victim’s scores)

As an instance, assume that a team could find 5 victims out of 12 in a mission and they could identify all the signs of life (victim identification score = 30) while they could generate a half accurate map (mapping score = 10). Their final score is calculated as the followings:

Score of each detected victim = (10 / 20) x (30 / 30) = 0.5
Final score = (100 / 12) x (5 x 0.5) = 20.8%
This shows that the mission was 20.8% successful!

How would it be if they could find 3 victims with a completely accurate map?
Score of each detected victim = (20 / 20) x (30 / 30) = 1.0
Final score = (100 / 12) x (3 x 1.0) = 25.0%
It seems that they really need to improve their mapping for the next year!

Now let’s take a closer look at this scoring method:
Since final result of each team is calculated by adding all identified victims’ score which itself is the product of mapping and victim identification results, the final score highly depends on efficiency of applied algorithms (Computer Science) and robustness of utilized electro-mechanical systems (Mechatronics). Obviously a team should be very well prepared in terms of mechatronics, computer science and human resources if it wants to be successful in the competitions. Unlike the existing formula, a team will not be able to completely cover its weakness in one of the aforementioned areas by concentrating on its capabilities in the other fields. This can also be considered as a step towards eliminating operator’s skill in success of rescue teams (the end users of rescue robots won’t necessarily have all the capabilities of a well trained operator in RC RRL).

Advantages of proposed method:

• More accurate and still fair: As it was discussed, a team should be the best one in mechatronics, computer science and human resources if it wants to win the place award because these three factors have less effect on each other comparing to the existing formula.

• Easy to understand scoring result: Everyone (competitors and audiences) can easily understand how the performance of a team is even without comparing it with other teams’ scores when it is presented in percentage.

• Flexibility: Since the final score is a fraction of maximum available score, it does not depend on how many victims are placed in the arena. Therefore, the committee can freely add or remove some victims in an event while the performance of participants will be easily evaluated with previous events.

• Encouraging development of accurate real-time SLAM algorithms: Generally accuracy and quality of mapping algorithms reduce when the speed of a mobile platform increases. So, teams need to develop their mapping algorithms to have more accurate maps when they drive their robots faster to find more victims.

• Necessity of search strategy: One may want to find more victims to have grater score while another one may decide to get complete score of each victim. So, having a search strategy based on technical capabilities besides compromising between finding more victims and having more accurate maps will be inevitable.

• Shortening the score gap between auto-based and tele-based teams: Most auto-based teams produce very high quality maps. So, their mapping coefficient will be greater than tele-based teams. As a result, they can probably get more score if they find a victim.

Disadvantages:

• Map scoring: The presented scoring formula highly depends on mapping score. Since the automatic map scoring system is still under development by the RC RRL committee, final results will rely on human factor till a reliable automatic map scoring system becomes available.

However, there may be several teams that are not interested in AI problems or mechatronics. Those teams can always try their chance at best in class challenges.
At the end I think the proposed scoring formula can help to improve the quality of our highly valuable RoboCup Rescue Robot League.

A brief history of robotic mapping in RoboCup Rescue

At the very beginning of RoboCup Rescue, teams usually provided a hand-drawn map of the explored area to indicate the location of detected victims after their missions. Although these hand-drawn maps may be quite enough for rescuers to find the victims but, it didn’t have any technical challenge for academic side. In 2006 the RoboCup Rescue committee decided to restrict acceptable mapping methods to the automatically generated grid mappings. Although several teams (mostly European ones) were developing SLAM algorithms even before 2006, they didn’t have a similar method to represent their mapping results. Therefore the committee standardized the mapping format to be able to quantify the accuracy and quality of these maps. With these standardized mapping formats, now the committee members are working to develop an automatic map scoring system.

How can team leaders help RobCup Rescue?

Every year after coming back from RoboCup competitions, I send my ideas to the mailing list of RoboCup Rescue Robot League hopefully to improve the quality of our league. Unfortunately I have been one of the few people (if not the only one) who shares his/her ideas in the mailing list during these years. In fact the Rescue Robot community of RoboCup competitions is not that much active and we need more collaboration from team leaders in this area.
As far as I know, it has always been a big challenge for the organizing committee (especially Adam) to make the league closer and closer to the real scenarios while it is standard and of course interesting for the audience. In this way, they should consider several diverse issues (i.g. First Responders’ technical requirements, the existing technologies, standard test methods and technical level of participating teams). Obviously the Executive and Technical Committees will reach to a better conclusion if they know the ideas of participating teams (at least about technical issues).

RoboCup 2010 Rescue Robot League

Two weeks after coming back from RoboCup 2010, finally I could have enough time to write about the competitions.
First of all I should say that RoboCup 2010 was the best organized RoboCup event that I’d ever taken part. Thanks to the local committee, everything was in its perfect state (i.e. the competition venue, information desks, internet connectivity and of course the arena of Rescue Robot League was really ready in the first setup day!).
This year, three well known rescue robot teams (Jacobs from Jacobs University of Bremen, resko from Uni Koblenz and Resquake from K.N. Toosi University) were absent though their team leaders attended there as the committee members of the league. I’m sure they would increase the quality of the league if their teams could also take part!
Generally the arena didn’t have any significant change in comparison with last year but, its size seemed to be much bigger than previous and victims were distributed farther from each other. Also a three-pipe high elevated floor in one side and a steep ramp coated with two different materials in the other side made the arena A and B dissimilar.
It’s supposed to have some big changes in the rules this year (i.e. automatic victim locating on the map, multi-robot mapping …) but, some of them were ignored (hopefully only for this year) because most teams couldn’t adapt their systems with new rules. Also the committee decided to make an important on-site change in the rules after a close looking at the performance of multi-robot teams (last year I explained the problem in the mailing list of the league). As I wrote in my previous post, they limited rests to the TEAM RESET. That is why most multi-robot teams were less successful in Autonomy this year.
At the end of this event three teams from Thailand won top three Place Awards and the Australian team, CASualty won two Best in Class (in Mobility and Autonomy) awards while the famous Japanese Pelican United could only repeat their previous success in Best in Class Manipulation. Here you can find some photos of participants of RoboCup Rescue 2010 and its winners.

Third Preliminary Mission, something beyond Murphy’s law

Today at 9:30 am we had the third team leader meeting in which Adam talked about the results of his last session (at last night) with executive and technical committees of Rescue Robot League. The most important one is that “The teams are allowed to only request TEAM RESET NOT ROBOT RESET”! This means if ONE of a group of your robots needs reset, you should return ALL the robots to the start point! So the multi-robot teams (almost all teams) won’t be able to request reset if their autonomous robot(s) doesn’t go where they supposed to go – this technique is widely used by multi-robot teams like us. Anyway, our third mission was a very disappointing end to our preliminaries. Since we didn’t score any victim in our previous missions, we had to find around 4 victims. So we decided to climb up a very steep staircase having two victims (most teams refused to go there). BETA climbed up it perfectly but at the final step, Mehdi a little bit turned the flippers which led to flipping over from a 1.5m height!!! Mehdi intelligently could flip back the robot using its flippers but Alireza (Amini) informed me about the smell of smoke around the robot. I asked reset and we understood the powering system of our robot is badly damaged! As a result we missed the general competitions and we should only concentrate on the best of class missions. Hopefully we’ll have a better chance in remaining days!

Second Preliminary Mission

I’m awfully sorry to say that our second mission was a big loss due to my mistake as the team leader!!! After the problem we faced in the previous mission I asked the electronics guys to change our currently installed video server (from Planet Co.) with the other one that we were using since last year (from MOXA Co.). We had only three hours and I accepted the risk of changing the system in a short time. As I predicted the guys could change the device properly but unfortunately we realized that our video server badly blurs the video streams. Honestly I still don’t know how our operator could drive the robot to the first victim location using these noisy videos. Unfortunately the referee didn’t accept any found victim due to very noisy pictures! I’m awfully sorry for my wrong decision :’-(

First Preliminary Mission

As we scheduled last night, all the members woke up at 6 am to reach to the competition venue early after the opening time (7 am). After a 10 min walk to the Suntec we started to test the problem of servos. Unluckily not only we couldn’t fix the problem but also we lost the video stream sent from BETA. When I was deciding to cancel our first mission, Mehdi (Soltanzadeh) found out what the problem is – our usb interfaced relay module that switches the videos had decided to use another serial port!!!
Finally we started our mission but we couldn’t score any victim due to the considerable delay in video streaming :-(

Second Setup Day

Today we tested BETA and fixed some electromechanical problems that unexpectedly occurred during the tests. At 12 pm the first team leader meeting was held (with about 2 hours delay). Adam Jacof and Ann Virst as representatives of organizing committee talked about the new rules and answered the questions. As I predicted, some of the previously proposed rules won’t be completely applied this year (as an instance it’s allowed to merge individual maps manually). The committee also informed about assigning an extra 25 points (half of a victim’s complete score) to each mission in which one of the team members explains to the audience what their robots do (or supposed to do); this wasn’t announced before! During this meeting the schedule of Rescue Robot League (which is listed hereunder) was also given:
- Preliminary: Monday and Tuesday (2 missions per day each one should be done in 15 min.)
- Semi-final: Wednesday (2 missions and 25 min. for each mission)
- Final: Thursday (only one 25 min. mission)
- Best in class: Thursday
At the end of the session team leaders randomly selected when their missions will be on tomorrow. I guess we had a good chance since one of our missions will be at 10 am (in arena A) and the other one at 3 pm (in arena B). At the time of writing, we noticed that the servos located on BETA moves strangely but we have no more time to stay at the competition venue (it’s 11 pm and the lights will go off in a minute). I hope we’ll be able to fix the bug before starting our first mission!

DELTA is fixed

After unpacking our luggage, the team is divided to two subgroups: the first group inspecting BETA (the tele-operated robot) and the second one fixing the aforementioned mechanical problem of DELTA (the autonomous robot). Not surprisingly, nothing was damaged inside our custom made aluminum boxes and we just checked the electronics. At the time of writing this post GAMMA is fixed though we haven’t check it’s performance in the arena.

Unpacking

I got the ID cards of our Iranian sub-group but I couldn’t do it for the Malaysian ones due to a problem with registration process. So, I came to the Rescue field (located at 4th floor of Suntec Exhibition Center) and Sharifah Azizah is following up the problem. Here the airport custom agent delivered our robots and toolboxes at 11 am and now we’re unpacking our luggage to see if everything is OK.

Receiving a new motherboard

This morning I met Sharifah Azizah, the team manager of our Malaysian sub-group that received to Singapore last night. She brought us another military/industry grade motherboard that we use in our robots (we experienced some strange problems with the motherboard of BETA before leaving Iran and I thought we should have a reserve). After the breakfast we will go to the competition venue to get our ID cards and the robots.

Waiting till tomorrow!

The members who went to the airport at 7 am just came back to the hotel (it’s 6 pm now). They successfully handled all the administrative tasks in the airport custom but the luggage (including BETA and GAMMA) should be delivered at the competition venue (Suntec Exhibition Center) tomorrow!
This means no one is able to work except Mehdi who still is working on automatic victim marking. As a result I told my team members to take a walk in the city and find Islamic food shops.

Why to use Aluminum suitcase!

As I wrote in my previous post, the Emirates didn’t permit us to ship our autonomous robot (DELTA) in its aluminum suitcase and we had to accept the risk of shipping the robot in a carton box though it was clear that the carton box won’t be suitable to protect the robot in a long areal trip. After a visual checking at the hotel, we noticed that the driven pulley of left tracks is badly pushed and its shaft should be adjusted. I guess it’ll take about an hour to fix if we have our mechanical tool boxes sent by cargo shipping to Singapore. Since the administrative tasks of delivering our cargos may take a while, I asked Mehdi to keep on his previous task (automated victim marking) while a group of our team members try to bring our cargos from airport as soon as possible.

Hello Singapore!

After a 12-hour trip, finally I could manage to write a new post in my hotel room at Singapore. Thanks to Emirates airline, our both flights (Tehran-Dubai and Dubai-Singapore) were comfortable and we could rest after a number of sleepless nights.
I’m so happy to see a very good atmosphere exists in our team due to the great support of our university heads especially after attendance of Dr. Eftekhari (the dean of Engineering School) and Dr. Mahbadi (the head of Mechanical Engineering Department as well as Robotics Lab) at the airport to personally say goodbye to the team.
At the airport, the Emirates didn’t accept our autonomous robot (the only robot which we didn’t post it using cargo shipping) in its custom made Aluminum suitcase. Finally we had to bring the robot out of its box to put it in a taped carton box!!!
At the airport of Singapore I realized that we are one of the first RoboCuppers coming via that airport because they didn’t well prepared to host RoboCup teams. Actually we couldn’t do what was instructed by RoboCup organization for hand carried robot luggage. We met one of our Malaysian partners there and he helped us to handle everything there.
Now we’re checking if everything is brought safely while Mehdi is working on automatic victim marking on the map.
Hopping nothing is damaged!

Starting RoboCup logs

Another RoboCup event is going to begin and our team is preparing. Unlike previous I'll give my daily reports not only to my professor - Dr. Mahbadi but also to public. So, if you are interested to know the latest news about AriAnA & AVA rescue robot team in RoboCup 2010 Singapore, please check my weblog frequently!

Beyond Murphy's Law

If you're working in robotics, I'm pretty sure that you have experienced a variation of Murphy's law even if you don't know what it is! Murphy's law simply states that "Anything that can go wrong will go wrong". For example imagine that you're going to demonstrate your robot and you still have a technical problem; be sure you'll face that problem but in almost all cases not during the demonstrating your robot but only half an hour before it -- That is why I named it "Beyond Murphy's Law" quite similar to Prof. Robin R. Murphy's "Beyond Asimov's Law" ;-) Having a technical problem is very common in complex systems like robots (honestly I usually become worry if everything goes fine with my robots in my first attempts) but, your reaction after facing a problem shows if you are an experienced person or not! I have seen numerous people that cannot do very simple things (e.g. checking the wiring) when they become stressed.
As a person who designs and builds robots for several years I suggest taking these points in your account if you want to demonstrate your robot:

1. Be sure your robot is not perfect and it is not the first system in the world that is not perfect!
2. Nobody can guarantee that everything will go fine!
3. Don't be angry or embarrassed if you noticed your robot don't work at all before demonstration, just calm down!
4. Check obvious things at first (e.g. if your robot has battery or not)!
5. Don't think about "philosophy of life" if you couldn't fix the problem!

Research is done by money!

Few weeks ago I was at Iran-Open 2010 RoboCup competitions which again was held in Tehran International Fair. Our team, AriAnA&AVA, was participated as previous but, this time without its staff members (except me only for evaluating performance of new members to be selected for future collaborations). Although it didn't go that much well for us and we stopped at semi-final round but, I had enough time to talk to participants and spectators.
One of disappointing facts that I usually notice in Iran-Open competitions is that most Iranian universities poorly support their RoboCup teams if they do it. It's one of reasons that I never expect to see an advanced research in the biggest annual robotics event in Iran.
This problem could never exist in my opinion if our universities (professors and students) knew how to demonstrate their capabilities to get found from industry and our industry believed that paying for research is not a waste at all.
Anyway, I'm so happy that I'm working in a team that its university side (our staff members) know how to get budget from industry and its industry side believe in what we're paid for.

Kicking off my blog!

Since a while, I was thinking about having a web-log to publish what we (AriAnA rescue robot team) are doing. Finally I found out that it won't take place if I wait for other team members or the university staffs.
So I decided to have my own blog to post personal news about what I'm doing in our robotics team, at university or in office. I'll also post my ideas about robotics events that I participate or robots that I see.
Who knows, maybe I'm not the only person that check this blog! ;-)