CASTER: A Robot for Urban Search and Rescue Mohammed Waleed Kadous, Raymond Ka-Man Sheh, Claude Sammut ARC Centre of Excellence for Autonomous Systems, School of Computer Science & Engineering University of New South Wales Sydney, NSW 2052, Australia E-mail: {waleed,rsheh,claude}@cse.unsw.edu.au Abstract Designing robots for urban search and rescue (USAR) is an extremely challenging task, because it violates many of the assumptions made in the average robotics lab. Robocup Rescue [Jacoff et al., 2004] is an international competition that provides an opportunity to measure performance in such environments objectively. The competition allows for the evaluation of new and evolving sensing, hardware and software technologies in an environment that is as close to realistic as possible. This paper discusses the design and implementation of CASTER, the robot that helped Team CASualty come 3rd in the 2005 competition. The strengths of CASTER compared to other teams include high quality victim information, excellent maps and an intuitive user interface. The mapping techniques in particular are novel because they take advantage of a 3D time-offlight range imager, a technology that has only recently become widely available. The results are all the more impressive when one considers that this was the team’s first entry into the Robocup Rescue Robot League and that the robot base was delivered seven months before the competition. 1 1.1 Introduction Robocup Rescue One commonly cited example where robots can be of benefit to humanity is urban search and rescue (USAR). Robots are deployed at an earthquake site or other disaster and autonomously search the area, co-ordinate with each other, deliver assistance to those in need and assist in rescuing survivors. Whilst such dreams are obviously a long way off, much research is already being undertaken into technologies that may fulfill this ambitious goal. The RoboCup Rescue Robot League (RRL) aims Figure 1: Examples of RoboCup RRL Standard Arenas. Left is the USAR test facility at the University of Technology, Sydney and right is the competition arena at Osaka to provide both the motivation, in the form of a competition; and the testing environment, in the form of standard arenas, for research related to USAR. Doing so means that very early in the development cycle, new technologies can be practically evaluated RRL Standard Arenas are intended to be different, but comparable, real-world environments where robots may be tested, much like how various golf courses are different but comparable environments [Jacoff et al., 2004]. Examples of RRL Standard Arenas are shown in Figure 1. Whilst each is different, they are designed based on the same rules thus results of testing in the different arenas may be compared. They also intend to be practical approximations to “real world” disaster sites thus debris, loose material, low clearances, victims with varying states of consciousness, multiple levels, variable lighting and radio blackspots are replicated. For practical reasons, other factors such as water and mud are not included and unstable collapses, dust and fire are simulated by lightweight debris, curtains and “fake” heat sources. Every year, teams from around the world bring robots and support equipment to the RoboCup RRL Competition which, in 2005, was held in Osaka, Japan. Teams deploy their robots in a RRL Standard Arena and are able to compare mobility, sensing, autonomy, mapping and human-robot interface (HRI) developments with other teams. During competitive runs, operators are isolated from the arena and have no prior knowledge of the layout. The goal of these time-limited competitive runs is to find as many victims as possible, diagnose their state of consciousness and generate a map of the disaster area that a human rescuer can use to locate the victims. Secondary goals include locating landmarks and structurally interesting objects that may affect rescuer safety. 1.2 Prior Work Successful entries in the RRL have traditionally been focused on one or two of four research areas – mobility, victim identification, mapping and user interfaces. Considerable work has also been done in a fifth area – autonomy – but autonomous solutions have thus far had limited, albeit increasing, success. 2003 world champions, Robrno [Zalud, 2003] had a simple, robust four-wheeled platform that relied on high ground clearance and strong motors for its mobility. Their standout characteristic was their intuitive robot interface that included virtual reality goggles. A head tracker monitored the operator’s head, allowing the onboard camera to mirror the operator’s head movements. Their exceptional situational awareness allowed them to incur very few penalties [NIST, 2003] and resulted in their high score. In 2004, mobility and sensing came to the fore [NIST, 2004]. Toin Pelican [Koyanagi et al., 2004], winners of the international competition, fielded a highly mobile reconfigurable tracked vehicle that was able to reach further into the rescue arena than any other robot. This was combined with a raised camera that provided exceptional situational awareness, allowing them to score well. In contrast, second place winners in the international competition, Kurt3D [Surmann et al., 2004b] fielded a comparitively simple six-wheeled robot. Their distinguishing feature was their ability to generate 3D maps using a 2D laser scanner mounted on a tilting mechanism, combined with software to automatically match the resulting datasets [Surmann et al., 2004a]. Despite having significantly poorer mobility than many other teams, their exceptional mapping abilities enabled them to score highly. 1.3 Objectives of the project In order to provide a platform for a wide variety of research projects, as well as to do well in the RRL competition, it is necessary to address the main areas of USAR robotics – mobility, victim identification, mapping and user interfaces. Whilst autonomy is a growing area of USAR robotics, this project will focus on teleoperation. The ambitious goals for the project were to produce a robot system that had the ability to: Figure 2: Top-down view of CASTER (roll cages removed) Mobility Safely traverse stairs, ramps and rubble whilst carrying a full sensor payload Victim identification Detect at least four signs of life, including heat images Mapping Generate dense, textured 3D maps, merge them in an efficient manner and present them in an intuitive way HRI Provide the operator with as much information about the robots’ immediate surroundings as they would have with eyes-on control and in an intuitive way 2 Design and Implementation Figures 2 and 3 show annotated views of the robot, dubbed CASTER (Centre for Autonomous Systems Tracked Exploratory Robot), including sensors. 2.1 Locomotion CASTER is built on a Yujin Robotics Robhaz DT3 base [Yujin, 2005]. This robot base is weatherproof and extremely robust, indeed it is designed to survive the detonation of small explosives. The robot has two pairs of rubber tracks for locomotion. The front pair of tracks follow a triangular path, allowing the DT3 to climb over obstacles and stairs whilst a conventional flat rear pair provide additional traction. Two motors provide enough torque to allow the robot to carry payloads of up to 40 kilograms up inclines in excess of 45◦ . An internal battery pack provides a runtime of approximately 90 minutes. No mechanical modifications were made to the DT3 other than the addition of two Figure 3: Oblique view of CASTER 1cm thick polycarbonate plastic roll cages to protect the additional equipment. 2.2 Sensors CASTER’s sensor fitout was performed with three goals in mind: high quality 3D mapping, reliable victim identification and good situational awareness. To this end, the following sensors mounts were installed: • TracLabs Biclops pan-tilt unit with armoured camera mount • Logitech QuickCam Pro 4000 colour digital main camera plus high brightness white LEDs (on armoured camera mount) • CSEM SwissRanger 2 time-of-flight range imager (on armoured camera mount) • FLIR ThermoVision A10 thermal camera (on armoured camera mount) • Sony ECM-MS907 stereo microphone (on armoured camera mount) • IP9100A quad ethernet video capture device • 3 auxiliary cameras (connected to IP9100A video capture device) • ADXL311 accelerometer Figures 2 and 3 illustrate the placement of these sensors on the robot. The following subsections describe the sensing fitout in greater detail from the perspectives of situational awareness, victim identification and mapping. Situational awareness The DT3 robot base can move in highly unpredictable ways on unstructured terrain due to its length, articulation and the fact that it skid-steers. Given the difficulty of the environment itself and the very real prospect of becoming stuck or unstable, situational awareness is critically important. Four colour cameras provide visual feedback to the operator. A high resolution webcam on the pan-tilt unit forms the main driving camera and is able to observe the area immediately in front of the robot as well as to the sides and rear. Large sensing shadows near the robot’s left and right shoulders are covered by two auxiliary cameras mounted at the rear, which also assist in lining up the robot with openings and obstacles. A wide angle rear-view camera covers the sides and rear of the robot and assists in avoiding collisions with obstacles that may not be visible from the main camera. It is mounted on a vibration damped flexible boom to prevent damage. CASTER also carries high powered lighting, positioned so as to not shine directly into any of the cameras. Combined with the main camera’s ability to cope with highly varied lighting conditions, CASTER is able to operate in lighting conditions ranging from floodlit to complete darkness. The microphone provides the operator with feedback on the robot’s behaviour. By listening, it is possible to determine if tracks are slipping, if motors are being loaded, if the robot is high-centered or if it is brushing up against an obstacle. Finally, an accelerometer provides information on the robot’s attitude and allows the operator to make decisions as to CASTER’s stability. Victim identification and diagnosis Three groups of sensors were used for victim identification – the four colour cameras, the thermal camera and the stereo microphone. In addition, the range imager was used to accurately determine the position of victims once identified (see section 2.2). To aid victim identification, the thermal image data was superimposed on the main camera image. Occasionally, the auxiliary cameras were also used for victim identification, especially near ground level. These two groups of sensors together provide 3 signs of life – heat, form and motion. Finally, the stereo microphone was intended for use in locating victims, identifying their state and providing an additional sign of life. Unfortunately technical issues resulted in the output being mono-only, albeit with a high degree of directionality. Mapping The core of CASTER’s mapping capabilities lies in the range imager [Oggier et al., 2004], which provides 3 channels of information per pixel – distance, reflected Pan-Tilt Unit Microphone Main Camera Range Imager Thermal Camera Motor Motor Controllers Controllers Embedded PC Network switch Onboard notebook computer Accelerometer Wireless LAN access point Network switch Base Station Driving notebook Mapping notebook Video capture device Auxiliary Auxiliary Auxiliary cameras cameras cameras CASTER Robot Figure 5: Screen shot of the user interface Figure 4: Schematic diagram of CASTER’s communications system near-infrared intensity and ambient near-infrared intensity. Mounted on the pan-tilt unit along with the colour main camera and thermal imager, 7 channels of information (distance, near IR reflectance, near IR ambient, red, green, blue and temperature) are available for each pixel and allow for the construction of very informative 3D maps, as well as provide a potentially very rich data set for further image processing. The pan-tilt unit assists in this process by providing very accurate positioning of the sensors, thus allowing the accurate integration of sensor measurements taken from different directions. An accelerometer measures the robot’s pitch and roll, allowing 3D data to be pre-rotated to the horizontal. 2.3 Computing and Communications Figure 4 shows the computers and commuication systems employed on CASTER. An embedded computer in the DT3 base controls the motor interface boards and the pan-tilt unit whilst a small notebook computer mounted at the rear handles most of the sensors through firewire and USB. The exceptions are the auxiliary cameras at the side and rear which are accessed through the video capture device. These cameras have a low refresh rate of approximately 2Hz which was found to be sufficient due to the robot’s relatively low speed. An onboard fast Ethernet switch links the video capture device, embedded computer and notebook. The on-board notebook communicates with the base station over 802.11a wireless ethernet via its internal antenna. Through this link, information from all sensors is transmitted back to the base station approximately 5 times per second. The base station, embedded computer and onboard notebook run Linux and use TCP/IP as the communication protocol. In order to simplify software development, the Player robot server is used [Gerkey et al., 2001] on all three systems. The embedded PC provides a position interface for locomotion and a PTZ interface for the pan-tilt unit, both of which are mirrored through passthrough drivers on the notebook. The notebook also provides several camera interfaces including reprocessing of data from the video capture device, a position interface for the accelerometer and a wireless signal strength interface. The base station connects to the notebook as a client and can retrieve data and send commands as appropriate. 2.4 Software design In order to gain experience with the robot and sensors, this year’s entry focused on teleoperation. Elements of autonomy would then be incorporated when and where possible. As in section 2.2, the three goals of high quality 3D mapping, reliable victim identification and good situational awareness drove the design and development of this software. Figure 5 shows the teleoperation interface used to control CASTER. In order to maintain situational awareness and ensure that the robot was successfully operated, steps were taken to make the robot as easy to operate as possible. The following principles guided the design of the user interface. • Design the robot and the camera placement in order to enhance situational awareness. • Try to present the situation in a manner that reduced cognitive load. For instance, where possible information is displayed graphically rather than textually or numerically. • Reduce context switching; where the user must switch from one mode of working to another. Each context switch can introduce a delay as the user becomes reoriented with the new context. • Use metaphors and familiar controls from existing computer applications and the real world in order to maximise positive transfer. The display is designed to minimise the amount of “context switching” and take advantage of existing analogies wherever possible. The the top left hand corner is an artificial horizon that displays roll and pitch from the accelerometer in a manner familiar to anyone who has experimented with a flight simulator. On the top right hand right side is a display is a network strength indicator that is analogous to that found on a mobile phone, and a speed indicator that shows the fraction of maximum speed; similar to the bar graphs on some vehicles. All of these are rendered translucently so that the user can still see through them and thus maintain some awareness of what is behind them. A translucent 3D arrow in the middle of the screen provides feedback on the angle of the pan-tilt unit. It faces the direction CASTER is pointing, hence indicating the direction in which the robot would travel if it were driven forward. It was found to be highly intuitive. As well as the main camera, three other cameras are displayed along the edges of the screen. The rear view camera is displayed at the top of the screen but as the robot skid-steers (and so turns the same way regardless of travel direction), it is not mirrored. The side auxiliary cameras are displayed in the lower corners of the screen and roughly correspond to the lower door-windows in a minibus. To reduce sensory overload, a single command allows the user to hide all additional telemetery and view only the main camera. Images from the thermal camera may be overlaid onto the main camera image. To reduce clutter, areas of the image below a threshold temperature are unaffected whilst those above are tinted with a colour between red and yellow depending on temperature. Experimentally, it was found that tinting areas between 30◦ and 35◦ was effective. The user may also optionally observe the raw or autoexposed full-frame thermal image, which appears above the right side camera view. Intuitive control is obtained by adopting controls similar to those used in first-person-shooter computer games such as Quake, Half-Life and Unreal. The left hand operates the keyboard and controls robot movement via the keys W, A, S and D, which are arranged in an invertedT. For instance, the W key moves the robot forward as long as it is held down. The right hand operates a mouse and controls the pan-tilt unit by holding down the left mouse button and dragging. The mouse is not captured to allow the operator to, optionally, run the driving interface in a window in conjunction with other programs such as a notepad or messaging system. The scrollwheel on the mouse controls the robot’s forward, reverse and turning speeds and operates as a throttle preset. Due to control lag, moving the pan-tilt unit long distances with the mouse became excessively time consuming, thus preset positions were added. These were activated through hotkeys, rapidly moving the pan-tilt unit to pre-defined positions such as all-the-way-back or justin-front-of-left-track. The operator could then refine the position with the mouse. The number keys on top of the keyboard were chosen for the hotkeys. Other keyboard controls are available for initiating a scan macro action, hiding additional telemetry information and indicating the presence of victims and landmarks. No additional interface or context switch is used to indicate the position of a landmark or victim. Instead, from within the driving interface the operator positions the mouse cursor over the victim or landmark and, instead of dragging with the left mouse button, clicks the middle mouse button. Based on the cursor’s image position, the range imager locates the corresponding point in 3D space and automatically annotates the map. The cursor appears as a blue square to indicate the area over which the range imager’s measurement will be averaged. The interface then prompts the user for details of the landmark or victim via a text entry window. This window is small and does not obstruct the main driving interface so as to reduce the disorientating effects of the context switch. Typing text into this entry window is the only occasion that requires the operator to deviate from the left-hand-on-keyboard, right-hand-on-mouse configuration; the use of voice recognition is a possible extension for this purpose. 2.5 Mapping and recording data One purpose of CASTER’s sensors is to generate textured 3D maps of the environments and present them, along with other collected information, in an intuitive manner. This process may be broken down into the following components. • Collecting range, colour and thermal images in a particular direction, along with annotations such as landmark and victim details – a “snap” such as in figure 6 • Merging multiple “snaps” and corresponding annotations from the one location into a local map – a “scan” such as in figure 7 • Combining multiple “scans” taken in different locations into one global map such as in figure 11 Figure 6: An example of a snap. Red arrow denotes the robot’s orientation. • Postprocessing the map and including photographs and other data to generate intuitive displays and reports Figure 7: An example of a scan. Red arrow denotes the robot’s orientation. Note the annotation of the RoboCup sign. Figure 8 also shows a photograph from an elevated perspective, showing how the 3D reconstruction corresponds to the actual location. Snaps The co-location of the range imager, main camera and thermal camera allows data taken from all three devices to be merged into one image with 7 channels per pixel (see 2.2). The range imager was chosen as the reference sensor, thus the resulting composite image has a resolution of 160x124 pixels and an effective field of view of 45◦ x41◦ . By reading the location of the precision pantilt unit, the location of each pixel in 3D space relative to the robot may be determined. A major advantage of co-locating the three sensors is that the operator can perform annotations in a highly intuitive fashion (see 2.4 and automatically record location, visual and thermal data, which is stored in the “snap” data structure. By anchoring annotations to a particular set of 3D data, the highly local “map” generated by a single snap or scan may be useful even if the snap or scan itself is mislocalised. Scans While the robot is stationary, the precision pan-tilt unit allows CASTER to take many “snaps” and directly combine them into a local area map around the robot’s current location, called a “scan”. No correspondance matching is required as the relative directions of each “snap” is known to within fractions of a degree. Measurements from the accelerometer are then used to rotate this local area map relative to the horizon. This enables Figure 8: A picture (featuring UTS’ Homer robot in the same position as CASTER was for figures 6 and 7) but from an elevated position. Note the excellent resemblance. mapping to be performed even when the robot is at a steep angle. To assist in the production of scans, macro actions were developed to automate the collection of scans. These actions involve moving the pan-tilt unit around in such a way that all locations around the robot may be covered by “snaps”. Generally this involves taking 10 “snaps” at intervals of 36◦ , stopping at each location for long enough to ensure no motion blur, a process that takes approximately 20 seconds overall. If the operator desires, other “snaps” may also be recorded should objects of interest be above or below the ring of “snaps” taken by the macro action, so long as the robot base does not move. As these snaps are also located precisely relative to other snaps taken from the same position, landmark and victim annotations may be located relative to all the snaps in the scan, producing a very accurate and informative local area map. Figure 9: The user interface used for manual scan registration Global Map Each “scan” is pre-rotated based on accelerometer data so it is only necessary to move “scans” in 4 dimensions – X,Y,Z and yaw – to register them with the global map. Odometry is too poor on CASTER – especially given the uneven surface – for use in matching since the robot skid steers and often operates on surfaces that can shift. In fact, it was found that an odometric motion model would often be a poorer estimate of position than a zeromotion model, primarily due to large intermediate errors in heading. Variations on the Iterative Closest Point (ICP) [Surmann et al., 2004a] algorithm were investigated in order to register scans. This algorithm finds correspondences between points of an incoming data set and an existing model set by assuming that a given point in one set corresponds to the closest point in the other. The two sets are then transformed to minimise the least-squared error between corresponding points. The process iterates until some stopping condition, generally based on the reduction in error between iterations, is reached. Various heuristics may be applied to cull points that cannot be matched, break correspondances that can be eliminated based on distance or other factors, and weight correspondances. Unfortunately, being a gradient descent algorithm, ICP suffers from local minima. Each pair of scans involves around 400,000 to 500,000 3D points, of which around 10% correspond to depth edges and other “significant” features. Thus techniques that attempt to address local minima issues, such as simulated annealing, become very expensive. Also, there must be significant overlapping regions between scans, otherwise ICP tends to match globally consistent features, which are invariably the ring of floor pixels around each scan. Thus whilst two scans may be taken at a reasonable distance, the local (and indeed, global) minimum might in fact be the two scans on top of each other. As the operator takes scans, landmarks are highlighted. The range imager allows the system to locate the 3D position of these landmarks relative to the robot. If two or more landmarks in one scan match landmarks in the existing model, in theory it becomes possible to exactly register the new scan with the existing model (the extra degrees of freedom are accounted for since the robot’s tilt and roll are known from the accelerometer). This system was implemented and was effective as long as the operator marked landmarks accurately. Unfortunately, this process is time consuming from the operator’s perspective as they must point the pan-tilt unit and input the landmark label. It was found that it was faster for the operator to manually register the scans using a user interface than it was for the operator to specify enough landmarks for automated matching. Therefore, for competition runs, where the 10-minute time limit resulted in the operator only being able to take 3 or 4 scans per run, manual scan registration was preferred. The interface used for performing manual scan registration is shown in figure 9. Synthesis and presentation to incident commander Once the scans are registered, another software tool called RescueVis allows the operator to view the report and data on victims. It also allows the printing of a report that shows where the victims are and images of the victims. This map and victim report is then handed to the Incident Commander for scoring. The user interface for RescueVis is shown in Figure 10. Figure 11 shows a typical map generated for the Inci- Figure 10: User interface showing victim browsing in RescueVis dent Commander using the 3D capabilities of RescueVis. Subsequent screens also show pictures of the victims as well as nearby landmarks. 3 Evaluation Initial tests were conducted at the USAR Test Facility at UTS. Performance at the competition was also carefully monitored to see how the overall system design functioned and how the individual components fared. 3.1 Mechanical Platform CASTER’s powerful drivetrain played an important role in the success of the robot, allowing it to overcome very difficult obstacles and terrain. Its robustness was also a great asset as the robot was often high-centered or pushed up against obstacles. This robustness was graphically demonstrated when the robot flipped and landed heavily on the armoured camera mount – the only damage sustained was minor damage to a suspension linkage and the rearview camera boom. The CASTER’s articulated design helped to keep the robot’s center of gravity low and allowed the tracks to follow the terrain. This was especially the case when climbing stairs and step obstacles. However, the robot’s weight was a mixed blessing. The robot was less likely to slide on loose material but was more likely to become stuck when high-centered. Its weight also caused it to unintentionally push obstacles and stairs around. 3.2 Situational Awareness The four cameras placed around the robot were effective in driving the robot around but the narrow field of view of the main camera, combined with the slow speed of the pan-tilt unit, slowed down surveys of the robot’s surroundings. The inability to directly obtain a top-down Figure 11: Generated 3D map for of Round 1 of the Preliminaries of Robocup Rescue 2005 view of the robot was a limitation on the step field and other tight areas. This could be resolved using an omnidirectional or wide angle camera mounted high up. The side auxiliary cameras provided valuable perspectives for situational awareness, especially since they were close to the ground. This location left them vulnerable to damage however – one camera was almost destroyed when it became snagged on debris. 3.3 Sensor Performance Main Camera The main camera was a compromise between a high resolution, narrow angle camera for the purpose of reading victim labels and identifying victims, and a wide angle camera for situational awareness and surveying. While it was acceptable in performing both tasks, it was really good at neither. The use of a camera with optical zoom or a combination of a wide and narrow angle camera might have been more suited to this task. However, the camera’s exceptional colour rendition and ability to automatically deal with highly varied lighting conditions was quite valuable. Thermal Camera All of the victims in the arena emit heat – in fact some victims are hidden and only visible from their heat signatures. The thermal camera was vital in Team CASualty’s high map scoring as it allowed the victims’ temperatures to be determined unambiguously. The relatively simple method by which the thermal image was matched with vision – a linear shift – proved to be acceptable for the purpose of the competition. More accurate matching, either by using range information or by mounting the thermal camera closer to the main camera, would be necessary if automated victim detection were to be attempted. Range Imager The ability to gather a dense depth image in one shot was extremely valuable, both for generating maps as well as for automatically locating landmarks and victims relative to the robot. After calibration, this sensor proved to be very accurate in determining the distance to relatively smooth objects up to a distance of approximately 5 meters. It was also surprisingly robust to lighting, surface type or other objects in the scene. However, being a very new sensor, the CSEM SwissRanger 2 had some characteristics that caused major problems. The most important was the aliasing of measurements for objects at distances greater than 7.5m. Such distances could often be seen above the partitions used to construct the robot arena. Almost as severe a problem was focal blurring, which resulted in the loss of sharp discontinuities in the depth image. These two factors played a large part in the difficulties encountered with automated registration. Stereo Microphone Despite being operated in mono due to technical difficulties, the microphone was useful in detecting sounds from victims. This could well have been the difference between 3rd and 5th place. Surprisingly however, the microphone was also found to be useful for situational awareness. With practice, the operator could determine the characteristics of the surface on which the robot was moving, which tracks were under load, if the robot was pushing up against an unseen obstacle or if there was debris caught under the robot. 3.4 Mapping and Victim Scoring Due to the tight time constraints imposed during the competitive runs, it was only possible to take 2-4 scans per run. It was also impractical to take too many landmarks and therefore all the scan registration performed in scored runs was done manually. Despite this, the 3D textured and annotated maps produced were received very well and consistently scored full points. A large part of this can be attributed to the ability of the operator to locate a victim in the map by simply pointing and clicking – the presence of the range imager allows the 3D position of the victim to be determined very easily. By co-locating the thermal camera, scoring of victims based on thermal images was trivial and effectively instant, in contrast to methods involving spot non-contact thermometers where it was necessary to demonstrate an elevated temperature on a victim. The victim tags, which contribute greatly to scoring, were significantly smaller than anticipated and, for the most part, it was very difficult for the main camera to observe them due to its height and lack of optical zoom. This was the case even when run at its highest resolution. At times, it was necessary to resort to manouvering the rear of the robot close to a victim tag and using the side auxiliary cameras (which are lower to the ground) in order to read the tags. 4 Conclusions and Future Work Team CASualty came third in the finals of Robocup Rescue 2005. It came second in the preliminary round and second in the semi-finals. On average, Team CASualty scored more per victim found than most other teams. The main factors leading to this were that we were able to present the information coming back from the different sensors in an intuitive way, allowing the operator to observe victims easily and produce high quality maps that were not just top-down but also three dimensional. There are still many issues that remain to be improved and resolved. While landmark-based scan registration seemed to work some of the time, it was not sufficiently reliable nor fast enough. The characteristics of the range imager caused problems for automated scan registration, further work in this area may improve performance. While Player was a good platform for control, it was not designed for bandwidth-intensive sensors such as the high-resolution camera, thermal camera and range imager. Therefore it is our intention to separate bandwidth-intensive devices from less bandwidth intensive devices and have an additional server for highbandwidth data. A number of approaches are also being explored to address situational awareness issues; such as mounting a camera on a robotic arm that can be raised in order to better characterise the surroundings of the robot. In addition, mobility remains an issue. The DT3 appears to be one of the better platforms available (DT3based robots also took second and fifth place). Despite this, there were still a number of times when CASTER ran into difficulties – the robot flipped once and became terminally stuck in two rounds of the competition. This may in part be because our operator only had one month of practice and the video refresh rate was too slow; but it is also in part a limitation of using a single robot. Other teams with the same robot base sometimes became stuck in similar locations. One way to increase robsutness is therefore to employ multiple robots, but since the replacement cost of CASTER is approximately A$110,000, multiple CASTERs are not an option. For future competitions, multiple robots are being considered. It is likely that one will be autonomous, in co-operation with the University of Technology (also part of Team CASualty). But it may also possible to use multiple small, inexpensive yet highly mobile semiautonomous robots. 5 Acknowledgement This research was supported by the Australian Research Council Centre of Excellence for Autonomous Systems. References [Gerkey et al., 2001] B. Gerkey, R. Vaughan, K. Sty, A. Howard, G. Sukhatme, and M. Mataric. Most valuable player: A robot device server for distributed control. In Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), Wailea, Hawaii, October 2001. [Jacoff et al., 2004] Adam Jacoff, Elena Messina, and John Evans. A standard test course for urban search and rescue robots. In Proceedings of the Performance Metrics for Intelligent Systems Workshop, August 2004. [Koyanagi et al., 2004] Eiji Koyanagi, Yoshiyuki Ooba, Shuuhei Yoshida, and Yasuo Hayashibara. Toin pelican. In Proceedings of the 2004 RoboCup Symposium, 2004. [NIST, 2003] NIST. 2003 robot rescue competitions. http://robotarenas.nist.gov/2003_competitions/, 2003. Viewed 23 August 2005. [NIST, 2004] NIST. 2004 robot rescue competitions. http://robotarenas.nist.gov/2004_competitions/, 2004. Viewed 23 August 2005. [Oggier et al., 2004] T. Oggier, M. Lehmann, R. Kaufmann, M. Schweizer, M. Richter, P. Metzler, G. Lang, F. Lustenberger, and N. Blanc. An all-solid-state optical range camera for 3D real-time imaging with subcentimeter depth resolution (SwissRanger). In Optical Design and Engineering. Edited by Mazuray, Laurent; Rogers, Philip J.; Wartmann, Rolf. Proceedings of the SPIE, volume 5249, pages 534–545, February 2004. [Surmann et al., 2004a] Hartmut Surmann, Andreas Nuchter, Kai Lingemann, and Joachim Hertzberg. 6d slam – preliminary report on closing the loop in six dimensions. In Proceedings of the 5th IFAC Symposium on Intelligent Autonomous Vehicles, 2004. [Surmann et al., 2004b] Hartmut Surmann, Rainer Worst, Matthias Hennig, Kai Lingemann, Andreas Nuechter, Kai Pervoelz, Kiran Raj Tiruchinapalli, Thomas Christaller, and Joachim Hertzberg. Robocuprescue - robot league team kurt3d, germany. In Proceedings of the 2004 RoboCup Symposium, 2004. [Yujin, 2005] Yujin. Robhaz dt3 web site. http://www.robhaz.com/about_dt3_main.asp, 2005. Viewed 18 August 2005. [Zalud, 2003] Ludek Zalud. Robocup rescue robot league competition, awardee paper, robrno, czech replublic, 1st place. http://robotarenas.nist.gov/2003_competitions/, July 2003.