RoboCupRescue 2013 - Robot League Team Red Knight RoboRescue Squad (USA)

Timothy E. Jump

Benilde-St. Margaret's School Advanced Competitive Science Program

http://www.bsmschool.org/acs

Abstract Team RKRS is the enrichment component the Benilde-St. Margaret's high school engineering program (Advanced Competitive Science). The goal of the ACS program is to give students conceptual understanding in four engineering foundations (mechanical, electrical/electro-mechanical, design and control). Students that show extreme promise during their development of small scale rescue robots are invited to contribute to, and operate the team RKRS RoboCupMajor Rescue Robot. Ultimately, our participation at the RoboCupMajor level is an opportunity to demonstrate and integrate advanced engineering concepts and learning, both to and from the BSM-ACS students and to participate and expose students to a true research project preparing them to be competitive applicants for research positions as they enter their university studies. We also hope to produce functional products that can be implemented in higher level research projects and be commercially viable.

Introduction

Our focus is on developing an advanced mobility, intuitively controlled, significantly cost effective robot transport system. Our latest platform continues in the line of our robot platforms from the 2011 and 2012 RoboCup entries, incorporating targeted improvements documented from robot performance at the Istanbul and Mexico City events. We continue our dedication to fixed climbing arms. Fixed arms increase control simplicity for the driver/operator compared to the complexity presented by arms that require driver managed control. We also continue our commitment to abdominal belts, giving our robot a significant force transmitting surface area and a minimum amount of static lower structure. This minimizes the potential for chassis hang on undulating surfaces. Our motor change from Istanbul to Mexico City offered significant improvement so we have retained our Mexico City power train. The radio upgrade we debuted in Mexico City proved extremely effective so we will retain this system for our 2013 robot. Our big addition for 2013 will be integration of autonomous mapping. We have adopted the Hector-SLAM mapping process with preliminary tests proving successful.

1. Team Members and Their Contributions

Engineering 3 Students/Seniors in the Benilde-St. Margaret's ACS Program participate across all of the following areas.

• Robot Locomotion (Mechanical and Electro-Mechanical)
• Robot Locomotion (Control)
• Navigation and Localization
• Victim Identification
• Map Generation
• Robotic Arm
• Operations

Students comprising the 2013 Benilde-St. Margaret's Rescue Major travel team:

TBD

Advisor: Timothy Jump

2. Operator Station Set-up and Break-Down (3 minutes)

With the addition of an independent power source, setting up the team RKRS operator station should be as simple as flipping a switch. The control console has an integrated WiFi router, antenna, control computer and monitor(s) as well as control devices (joystick, mouse, etc.) so it is an all-in-one control console solution.

Communication and application programs should start automatically upon boot saving time over computer boots where applications must be launched manually.

Operator station break-down is simply shutting down the control console.

3. Communications

The integrated multi-frequency radio (802.11 a/b/g/n) allows for expanded flexibility to meet the requirements of different locations. The radio maximizes performance on congested frequencies. We use the same components at both the robot and operator station.

Table 1. Communication protocols under testing and available for use.

4. Control Method and Human-Robot Interface

We control the team RKRS robot through both teleoperation and autonomous functions. Teleoperation is currently managed by our custom LabVIEW control interface MainController.vi but we are investigating a move to a ROS based control interface .

From our MainController.vi we simply input the robot IP address and connect. We can then drive motors, monitor sensors, monitor video and access video analysis protocols including horizon, edge, obstacle and motion (differencing) detection.

We switch the robot into autonomous mode via our LabVIEW MainController.vi by loading and executing picoC code.

We have a semi-functional interactive mode in our firmware that allows for simultaneous running of autonomous functions and teleoperative controls, but it still needs more work.

We also have the potential to run autonomously with Roborealm machine vision software running remotely on the control console computer but we have not yet implemented this functionality.

5. Map Generation

Following the 2012 RoboCup in Mexico City we began investigating the ROS based mapping of Team Hector-Darmstadt. This process looks to be an excellent format for our robot so we have been working to get Hector-SLAM operational in our lab. Currently, we can generate real-time maps with sensors connected directly to a PC. Our next step is to get data streaming wirelessly from our robot to the ROS mapping PC, the result being full SLAM mapping for our robot.

6. Sensors for Navigation and Localization

Teleoperative navigation is managed through visual data streamed through the OmniVision OV7725 camera and our LabVIEW vision interface. From the camera we can get edge, horizon and obstacle detection data as well as images.

We are also investigating autonomous navigation through the inclusion of a perimeter detection system that will set off warnings at the control console if an unseen obstacle penetrates our Clearance Zone. The Clearance Zone represents the area around the robot that must be clear in order for the robot to make clean turns and navigate through doorways, paths, etc. We are experimenting with Sharp digital and analog IR sensors and short range Maxbotix ultrasonic sensors as detection devices.

Once we have the perimeter detection system working we will begin to integrate code to get the robot to move through the arena based solely on the data received through the perimeter detection sensors. Elements of difficulty will include interpreting skewed data from when the robot is on uneven terrain.

7. Sensors for Victim Identification

Victim identification incorporates five primary data groups (motion, thermal, CO2, form, sound). We get motion and form direct from the OV7725 color CMOS camera and the SRV-1 camera/control board.

Thermal comes from our custom designed thermal sensor that uses a Perkin Elmer A2TPMI334-L5.5 OAA060 single pixel thermopile sensing element.

CO2 detection comes from our custom designed CO2 sensor using a Heimann CO2 Gas Sensor element.

Auditory is also under development. We have used an Audio-Technica ATR35s Lavalier Microphone with some success, but we are pursuing a much smaller device for easier inclusion in our arm head used to insert into smaller access cracks.

8. Robot Locomotion

Our fixed climbing arm continues to be well received. We feel we have equal mobility to a managed climbing arm system but with a significant reduction in user complexity. Our fixed arm system only requires basic differential drive control awareness so the user only needs to know forward, reverse, spin left, spin right, turn left, turn right maneuvers.

Going to fixed climbing arms also significantly reduces the cost of the robot base. With fixed arms there is no longer any need for arm motors, speed controllers, position encoders, etc. Fewer high-torque demands such as comes with climbing arms also means extended operation time of the robot as there are now fewer demands on the battery system.

We have retained abdominal drive with our new mobility base. Abdominal drive makes almost every bit of the lower surface of the robot a force delivery mechanism, minimizing opportunity to get stuck on a ledge or rubble that can hold robot wheels/treads off the ground.

Although we've retained abdominal drive we have abandoned rubber belts and adopted a 'chain-belt' system from Intralox (Intralox manufactures plastic conveyor chain). We found certain benefits with our original friction drive of belts using Linatex rubber drive wheels (belts can remain loose to allow for molding to surface irregularities) but under strain the contact surface between the wheels and belts failed resulting in slippage. We tried a timing belt application, but with timing belts we had to give up our loose belt fit and we experienced jamming of our belts tooth on tooth at the drive wheels effectively stalling the robot. The timing belts also placed a significant load on the motors causing them to pull high current (16A per motor) and trigger the protection circuitry within the motors completely stalling the robot. High current draw also reduced our overall runtime. With the change over to the Intralox chain-belt we retain positive drive (no slippage), we can run our belts loose as the chain-belt is driven by a sprocket system that guides sprocket teeth into the chain drive, and the flexibility of the Intralox components has dropped our current draw to roughly 3A per motor. The Intralox components have also dropped the overall cost of the robot significantly.

9. Other Mechanisms

We currently retain our arm and sensor head fitted with a set of the victim ID sensors and a high power LED spot light to illuminate dark areas. We have a new arm design that includes a multi-axis manipulator for grasping objects and an extension component to improve reach, but we have yet to begin fabrication of the new arm.

10. Team Training for Operation (Human Factors)

We constructed a RoboCupRescue test arena in our lab. Students take what time they need on the course to test design concepts and evaluate ease of use and control accuracy of our robots and data systems.

11. Possibility for Practical Application to Real Disaster Site

It seems that many of the developers of rescue and other robot systems have price points that make them impractical for mass market distribution. Our primary goal is to generate a cost effective, highly functional mobility base that gives greater access to rescue robots to all institutions.

We are also targeting ease of use. Many existing mobility platforms are difficult to control without hours of practice. Our hope is for our system to be so intuitive that only minutes of training is needed to accomplish successful operator control.

12. System Costs

Section content follows with cost tables below.

Cost Table - Operator Station