Drm

Robotics for Disaster Management

Yasser Nihal Siddiqui, Yawar Jung and Ankit Gureja

9/11/2010

Acknowledgement

We would like to thank the IEEE HTN and IEEE Bangalore section for pro-viding us with this oppurtunity and giving us the financial support requiredfor making this project a success. We would also like to thank our projectsupervisor Dr. M.T. Beg for giving us an opputunity to work under him andfor guiding us in our endeavours. His constant motivation has been a drivingforce in the completion of our work.

Yawar Jung(Team leader,Membership Number-90885704)Md. Yasser Nihal SiddiquiDate: 11/09/2010

1

Contents

1 Introduction 41.1 Challenges of Disaster Response . . . . . . . . . . . . . . . . . 41.2 Robotics in Disaster Management . . . . . . . . . . . . . . . 51.3 Objective of the Project . . . . . . . . . . . . . . . . . . . . . 6

2 Preliminaries 72.1 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Top 10 Natural Disasters Reported Affected . . . . . . 82.1.2 Statistics per Event . . . . . . . . . . . . . . . . . . . 92.1.3 Statistics By Disasters Type . . . . . . . . . . . . . . 11

2.2 Contemporary Solutions . . . . . . . . . . . . . . . . . . . . . 12

3 The Prototype 133.1 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Driving Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Communication Module . . . . . . . . . . . . . . . . . . . . . 153.4 The Camera Module . . . . . . . . . . . . . . . . . . . . . . . 173.5 The Image Processing System . . . . . . . . . . . . . . . . . . 183.6 Gas Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.7 Robot Controller . . . . . . . . . . . . . . . . . . . . . . . . . 193.8 Power Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

A Appendix 21A.1 Software used . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

A.1.1 Main File of AVRCAM on ATmega8 Microcontroller . 22A.1.2 PCB design . . . . . . . . . . . . . . . . . . . . . . . . 23

2

List of Figures

2.1 (a)Percentage of Reported people killed by disaster type (b)Percentageof Reported people affected by disaster type . . . . . . . . . . 11

2.2 Economic Damage . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 L298 IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Encoder Decoder Pair . . . . . . . . . . . . . . . . . . . . . . 163.3 C3088 Camera Module . . . . . . . . . . . . . . . . . . . . . . 173.4 Sunrom’s Combustible gas sensor . . . . . . . . . . . . . . . . 183.5 Voltage Regulator . . . . . . . . . . . . . . . . . . . . . . . . . 19

A.1 PCB for AVRcam . . . . . . . . . . . . . . . . . . . . . . . . . 23

3

Chapter 1

Introduction

Disaster may strike any time, any place and can also end up in many casual-ties. Disaster can be natural (floods, earthquake, storms etc) or man made(terrorist attack, sabotage, minefields blowing up, chemical or nuclear leaksetc.). Since 1980, the World Bank has approved more than 500 operationsrelated to disaster management, amounting to more than US$40 billion [1].Disaster management primarily comprises of but is not limited to [2]:

• Preparing for disaster before it occurs

• Disaster response (emergency evacuation, quarantine, mass decontam-ination, etc.)

• Supporting, and rebuilding society after disasters have occurred.

The disaster struck places are often not easily accessible and hazardous evento the disaster relief forces. In the process of disaster response the responseforce personnel themselves are exposed to many dangers. Analysis shows thatrobotics technology can provide an economically & technically viable solutionfor disaster management in disaster response. The proposed solution is inthe form of a robot or an unmanned ground vehicle which can relieve thedisaster relief forces of the tasks of surveillance and reconnaissance of thedisaster afflicted area.

1.1 Challenges of Disaster ResponseListing the challenges of disaster response is virtually an impossible task. Afew of them are listed below:

4

CHAPTER 1. INTRODUCTION 5

• The occurrence of a disaster whether natural or man made cannot besatisfactorily predicted

• The disaster afflicted areas are not easily accessible and hazardous forboth the rescuer and rescued

• Disaster response cannot always be timely implemented

• The disaster relief equipment is not affordable by every country andthus donated by somebody else or is procured at an emergency only,thus causing a delay

• Only a few relief equipments are available that can be reused again andagain, even in multifaceted situations

1.2 Robotics in Disaster ManagementOne of the first steps in disaster response is the collection of informationfrom the disaster afflicted areas to further act upon. Surveillance and recon-naissance is the area of focus in this project. Thus the robot is primarilyexpected to provide surveillance and reconnaissance support to disaster re-sponse teams. The robot is expected to have the following features:

• Ability to traverse rough terrain (a combination of four wheel drive andbelt drive mechanism)

• The robot should have the capability to be remotely operated andcontrolled by an operator

• Ability to provide live video transmission to the remote operator

• Detection of hazardous gases in the afflicted area

• Ability to operate in nuclear contaminated areas and detection of anydangerous levels of nuclear radiation present in the environment

• The robot should be able to transmit the collected data to the remoteoperator

• The robot should have the capability to operate independently (in otherwords the robot should have on-board image processing capabilities)

CHAPTER 1. INTRODUCTION 6

• It should be easy to repair the robot and replace parts in case of abreakdown

• Lastly it should be a low cost solution to the problem

A particular challenge concerning the project is that the use of robotics indisaster management is a relatively new concept and thus no previous modelsare available to further build on. A prototype withate reduced capabilitieshas been developed. The developed prototype aims to show the feasibility ofa low cost robot with the afore mentioned capabilities.

1.3 Objective of the ProjectThe objective of this project is to create a surveillance and reconnisscancerobot for disaster management. The proposed robot is designed to providethe disaster relief forces with the primary information of ground zero at adisaster struck place. After a disaster, be it an earthquake, oil spill, fire,nuclear or gas leakage the disaster relief forces themselves are exposed haz-ardeous environment in the process of disaster response. In this process weexpect the robot to perform with speed, precision and above all prevent theexposure of the disaster relief force to danger. The robot can with little orno modification be used for low intensity securty patroling requirements.

Chapter 2

Preliminaries

Since 1980, the World Bank has approved more than 500 operations relatedto disaster management, amounting to more than US$40 billion [1]. Hugeamount of money is spent by the Government of India in many rescue opera-tions which usually involve the deployment of army for the rescue work. Theobvious advantage of our solution lies in the fact that robots can go wherehumans cannot. India - Disaster Statistics.

Data related to human and economic losses from disasters that have oc-curred between 1980 and 2008.

No of events: 395No of people killed: 139,393

Average killed per year: 4,807No of people affected: 1,506,794,740

Average affected per year: 51,958,439Economic Damage (US$ X 1,000): 45,184,830

Economic Damage per year (US$ X 1,000): 1,558,098

Table 2.1: Overview

7

CHAPTER 2. PRELIMINARIES 8

Natural Disaster Occurrence Reported

2.1 Statistics

2.1.1 Top 10 Natural Disasters Reported Affected

People Disaster Date Affected

Drought 1987 300,000,000Drought 2002 300,000,000Flood 1993 128,000,000

Drought 1982 100,000,000Drought 2000 50,000,000Flood 2002 42,000,000Flood 1982 33,500,000Flood 2004 33,000,000Flood 1995 32,704,000Flood 1980 30,000,023


Killed People Disaster Date Killed

Earthquake* 2001 20,005Earthquake* 2004 16,389

Storm 1999 9,843Earthquake* 1993 9,748Epidemic 1984 3,290Epidemic 1988 3,000Storm 1998 2,871

Extreme temp. 1998 2,541Flood 1994 2,001Flood 1998 1,811

Economic Damages

Flood 1993 7,000,000Flood 2006 3,390,000Flood 2005 3,330,000

Earthquake* 2001 2,623,000Storm 1999 2,500,000Flood 2004 2,500,000Flood 2005 2,300,000Storm 1990 2,200,000Storm 1996 1,500,300

Earthquake* 2004 1,022,800

2.1.2 Statistics per Event

Killed People

Drought: 53.33Earthquake*: 3,108.19Epidemic: 274.78

Extreme temp: 320.56Flood: 225.01

Insect infestation: ...Mass mov. dry: 45.00Mass mov. wet: 90.26

Storm: 279.99Wildfire: 3.00


Affected People

Drought: 125,195,833.33Earthquake*: 1,741,700.25Epidemic: 7,205.18

Extreme temp: 6.62Flood: 4,005,617.70

Insect infestation: ...Mass mov. dry: ...Mass mov. wet: 123,677.55

Volcano: ...Storm: 624,422.81

Economic Damages

Drought: 340,187.00Earthquake*: 318,893.75Epidemic: ...

Extreme temp: 16,000.00Flood: 164,938.27

Insect infestation: ...Mass mov. dry: ...Mass mov. wet: 1,758.06

Volcano: ...Storm: 120,139.25Wildfire: 1,000.00


2.1.3 Statistics By Disasters Type

Figure 2.1: (a)Percentage of Reported people killed by disaster type(b)Percentage of Reported people affected by disaster type

Figure 2.2: Economic Damage

*: Including tsunamiThe above statistics tell us how serious the problem of natural disasters

in India let alone the man made ones. It has been observed that during suchcalamitous times only manpower is not enough, this is where robots come in.


2.2 Contemporary SolutionsAs far as this solution is concerned, it has no contemporary in the past. Thedisaster management forces have always relied heavily on the manpower.The only instance of use of machines in a disaster response is the use of JCBmachines which entirely defeats the purpose of safe rescue.

Solution proposed and its advantages One of the first steps in disasterresponse is the collection of information from the disaster afflicted areas tofurther act upon. Surveillance and reconnaissance is the area of focus in thisproject. Thus the robot is primarily expected to provide surveillance andreconnaissance support to disaster response teams. The robot is expected tohave the following features:

• Ability to traverse rough terrain (a combination of four wheel drive andbelt drive mechanism)

• The robot should have the capability to be remotely operated andcontrolled by an operator

• Ability to provide live video transmission to the remote operator

• Detection of hazardous gases in the afflicted area

• Ability to operate in nuclear contaminated areas and detection of anydangerous levels of nuclear radiation present in the environment

• The robot should be able to transmit the collected data to the remoteoperator

• The robot should have the capability to operate independently (in otherwords the robot should have on-board image processing capabilities)

• It should be easy to repair the robot and replace parts in case of abreakdown

• Lastly it should be a low cost solution to the problem

Chapter 3

The Prototype

The prototype has reduced capabilities that can be enhanced to achieve therobot with capabilities that has been previously listed. In this report therobot has been divided and described module by module. The Robot’s hard-ware can be divided into the following section/categories:

1. Chassis2. Drive mechanism3. Communication Platform4. Camera Module5. Image Processing system (AVRcam)6. Sensors Used7. Robot Controller8. Power Circuit

3.1 ChassisAluminium was chosen to design the chassis as it is light weight and easilyworkable for this purpose. The body is thus resistant to rust and otheratmospheric corrosions. The chassis is in the form of a skeleton made fromL-shaped aluminium angles. The dimensions of the angle are 19mmX38mm.The chassis itself has rectangular shape with dimensions of 420mmX300mm.The holes are for fixing the motors and are kept at a distance of 337mm.

13

CHAPTER 3. THE PROTOTYPE 14

3.2 Driving MechanismA combination of four wheel drive and a drive belt mechanism has beenused. The robot can use either of the two mechanisms of locomotion inter-changeably depending on the operational requirements. To change from onemechanism of locomotion to another human intervention is required.

Figure 3.1: L298 IC

The robot utilizes geared DC motors on each wheel for improved perfor-mance and horsepower requirements of various operations. Big radii tiresand tracks can make the robot work in various terrains. The motors of therobot are driven by L298 Dual Full-Bridge driver. The L298 is an integratedmonolithic circuit in a 15- lead Multiwatt and PowerSO20 packages. It is ahigh voltage, high current dual full-bridge driver designed to accept standardTTL logic levels and drive inductive loads such as relays, solenoids, DC andsteppingmotors. Two enable inputs are provided to enable or disable thedevice independentlyof the input signals. The emitters of the lower transis-tors of each bridge are connected together and the corresponding externalterminal can be used for the connection of an external sensing resistor. Anadditional supply input is provided so that the logic works at a lower volt-age.This IC is capable of driving with currents up to 2A per channel and


a maximum of 46 volts[3]. The IC is shown in the figure 2.1. The motordriver consists of 4 bridges of which two are needed to drive the motor. Thefunctioning of a single bridge is shown in the Table 2.1.

The L298 circuit uses another bridge consisting of 8 diodes (1N4007)which are used here to prevent the back emf of the motors from damagingthe motor driver. The current output is controlled through the resistorsbetween the current_sense pin and the ground.

Inputs FunctionVen=H C=H,D=L Forward

C=L,D=H ReverseC=D Fast motor stop

Ven=L C=X,D=L Free Running motor stop

Table 3.1: Function of a single the L298

3.3 Communication ModuleThe robot is wirelessly remote controlled. Since the transmission of imagesrequires high data rate, therefore this robot establishing communication withother systems using a CC2500 based transceiver modules produced by TexasInstruments. The camera module has a baud rate of 115.2Kbps, which isnot achievable by using standard 434/315 MHz ASK modulated transmitter-receiver modules having maximum data rate of 9600bps.

The CC2500 is a low-cost 2.4 GHz transceiver designed for very low-power wireless applications. The circuit is intended for the 2400- 2483.5MHz ISM (Industrial, Scientific and Medical) and SRD (Short Range Device)frequency band. The RF transceiver is integrated with a highly configurablebaseband modem. The modem supports various modulation formats andhas a configurable data rate up to 500 kBaud. CC2500 provides extensivehardware support for packet handling, data buffering, burst transmissions,clear channel assessment, link quality indication, and wake-on-radio. It’sdata stream can be Manchester coded by the modulator and decoded by thedemodulator . It has a high performance and easily to design your product.The main operating parameters and the 64-byte transmit/receive FIFOs ofCC2500 can be controlled via an SPI interface. In a typical system, the


CC2500 will be used together with a microcontroller and a few additionalpassive components.

Since digital data is transmitted serially, encoder and decoder is requiredfor the transmission of the individual bits. A minimum number of four chan-nels is required to run the robot only, one more is required for the sensor datatraffic and another for the transmission of images from the camera. Two en-coder decoder pairs are required since we have two transmitter/receivers areused. The encoder-decoder pairs used are the HT12E/D, which are four chan-nel encoders. These are capable of addressing 8-12 address bits and 4 databits. The circuit connections of HT12D/E are shown below: Fig. TypicalHT12D circuit Fig. Typical HT12E circuit

Figure 3.2: Encoder Decoder Pair

The encoder begins a 4-word transmission cycle upon receipt of a trans-mission enable (TE for the HT12E, active low). This cycle will repeat itselfas long as the transmission enable (TE) is held low. Once the transmissionenable returns high the encoder output completes its final cycle and thenstops.

The decoders receive data that are transmitted by an encoder and inter-pret the first N bits of code period as addresses and the last 12_N bits asdata, where N is the address code number. Signal on the DIN pin activatesthe oscillator which in turn decodes the incoming address and data. The


decoders will then check the received address three times continuously. Ifthe received address codes all match the contents of the decoder’ local ad-dress, the 12_N bits of data are decoded to activate the output pins and theVT pin is set high to indicate a valid transmission. This will last unless theaddress code is incorrect or no signal is received. The output of the VT pinis high only when the transmission is valid. Otherwise it is always low.

3.4 The Camera ModuleThe camera module used in our machine is known as the C3088 cameramodule. It uses Omnivision’s OV6620 CMOS sensor. The camera moduleworks at a native clock of 17.72 MHz. It is able to produce an image of 144 X82 pixels which is just quite enough to be handled by an 8 bit microcontroller,hence the module is apt for low cost applications. The camera module isreported to provide 30 frames per second, when the complete camera controlsystem is connected to a computer using a serial port. However the efficiencyof the camera is yet to be tested on wireless platform. The camera modulehas 32 pins and the communication to the sensor can made through the I2Cinterface.

I2C interface was developed by Philips for communication between differ-ent IC’s in a system. The I2C allows for multi master-slave configurations.The I2C utilises a Two Wire Interface (TWI) and utilises the SCL (serialclock) and the SDA (serial data) pins of an IC. Through the use of I2C theregisters of the camera module can be accessed and the module can be di-rected to perform specific actions. Thus this module can also be used forobject tracking.

Figure 3.3: C3088 Camera Module


3.5 The Image Processing SystemThe image processing system consists of two microcontrollers and the cameramodule. Besides these a RS-232 level shifter is used which converts thedata from the microcontroller TTL levels to that of RS-232 levels so thatcommunication to a pc ca be established.

The first microcontroller is an ATtiny12. Its sole purpose in this system isto establish initial communication between the camera module and the mainmicrocontroller. First, sends instructions to the camera module to route itsclock to the ATmega8 for a synchronised operation, then tells the I2C tomake mega8 as the master and C3088 as the slave. Due to pin limitations onAtmega8 the programming pins are being shared by the UV bus of C3088,thus another function of the tiny12 is to give instruction to the camera moduleto tri-state its UV bus on the start-up of system, this allows the programmingof the mega8 to be changed during this time. After this the microcontrollerwaits forever in an infinite loop.

The heart of the system is a mega8 microcontroller. The mega8 is usedhere to convert the data so that it can be read in a computer system, therebyacting as a signal processor. The microcontroller directs the OV6620 tooutput the image as QCIF format thereby reducing the image resolution.The reduced image can now be processed by the mega8.

The image processing system used is called AVRcam.

3.6 Gas Sensor

Figure 3.4: Sunrom’s Combustible gas sensor


Although many sensors can be used but just to show the feasibility ofour project we have put only a combustible gas sensor. The Gas Sensor todemonstrate the communication and the detection purpose of this robot, acombustible gas sensor has been selected. The gas sensor used is manufac-tured by Sunrom Technologies, can detect combustible gases in the atmo-sphere from 100ppm to 10000ppm. The simple analog output of the gassensor can be connected to either a microcontroller an analog to digital con-verter or an alarm system. The implementation here is for demonstrationpurpose only, where the gas sensor sends the signal back to the receiver whereit can be manipulated to obtain the concentration of combustible gas in air.The sensor is not sensitive to alcoholin air.

3.7 Robot ControllerThe robot is controlled by the use of a self designed controller board. Thecontroller board is used to control the movement of the robot. Besides themovement control, the data is received from the robot by the use of a micro-controller which displays the sensor readings.

The remote navigation of the robot can be done through the use of aPersonal Computer. The images captured by the robot are sent to a com-puter via a CC2500 module connected to the computer’s serial port. Theapplication software ’AVRcamView’ is used to interface the microcontrollerand the computer.

3.8 Power Circuit

Figure 3.5: Voltage Regulator


Power source that can be used are Ni-Cad batteries/SLA or 9V dry cells.Since the circuits run on a 5V supply we use a votage regulator circuit toobtain a constant supply.

7805 voltage regulator is used to get +5 V output out of a higher voltagesupply (7.5V-20V).We use adapter’s supply to generate +5V here. Connectthe gnd and +12V of adapter to the pins as shown and get +5V directly asan output out of the 3rd pin. Current up to 0.5 A can be obtained from thisregulator without any significant fall in voltage level.The regulator circuit isshown in figure 2.5, we use two capacitors of .1uF and 1uF to filter noise inthe input and output of regulator’s supply.

Appendix A

Appendix

A.1 Software usedThe camera hardware and the computer can be interfaced by the AVR-camVIEW software (version 1.2). This unique application was developedby John Royce Orlando. AVRcamVIEW provides the following capabilities:

• Take full-colour snapshots (176 x 144 pixels) with the system and displaythe images (both raw Bayer data and interpolated colour data).

• Easily create a Colour Map of colours to track based on a snapshot(Just click on the colours of interest and add them to the Colour Map).

• Adjust the precision of each tracked colour (i.e. provide a range ofacceptable R-G-B values for each colour), allowing the user to adjust theColour Map to the surrounding environment.

• Display the real-time tracking results of each tracked object (Withcolour and bounding box information).

• Record a tracking session for playback at a later time.• Test the system out in multiple OS platforms that are supported by

Java 1.5 (both Windows and Linux are currently supported).The other software used were ’WinAVR’ to compile the source code and

burn the hex files onto the microcontroller and ’DipTrace’ for designing thePrinted Circuit Board to mount the C088 camera module.

21

APPENDIX A. APPENDIX 22

A.1.1 Main File of AVRCAM on ATmega8 Microcon-troller

/*Module Name: Main.c Module Date: 24/8/2010 Description: This moduleis responsible for providing the entry point to the code through the "main"function. */

/* Includes */#include <avr/io.h>#include <stdlib.h>#include <string.h>#include "UIMgr.h"#include "UartInterface.h"#include "I2CInterface.h"#include "CamInterface.h"#include "DebugInterface.h"#include "FrameMgr.h"#include "CommonDefs.h"#include "CamConfig.h"#include "Executive.h"#include "Utility.h"/* Local Structures and Typedefs *//* Extern Variables *//* Definitions *//* Function Name: main Function Description: This function provides

the entry point into AVRcam application. Inputs: none Outputs: int */int main(void) { /* initialize all of the interface modules */DebugInt_init();UartInt_init();I2CInt_init();CamInt_init(); /* initialize the remaining modules that will process data...interrupts

need to be on for these */ENABLE_INTS();CamConfig_init();UIMgr_init();FrameMgr_init(); /* provide a short delay for the camera to stabilize

before we let the executive start up */Utility_delay(1000); /* the rest of the application will be under the con-

trol of the Executive. */

APPENDIX A. APPENDIX 23

Exec_run(); /* this should never be reached */return(0);}Due to size limitation of the page we are attaching the other source code

files. This main file has been derived from the original developed by John R.Orlando in 2004.

A.1.2 PCB design

Figure A.1: PCB for AVRcam

Bibliography

[1] http://web.worldbank.org/

[2] Datasheets- L298N, L298HN, FS100A,HT12E, HT12D, CC2500, C3088OV 6620, USBASP AVR programmer, ATmega8, ATmega16, ATmega32,LM7805 and ATtiny12.

[2] Saurabh Sankule, “Beginers Guide to Embedded Systems”, IIT KanpurRobotics Club.

[3] Joe Pardue, “ Programming and Customizing AVR with Butterfly”, Smi-ley Macros, TN, USA.

[4] www.winavr.scienceprog.com/example-avr-projects.

[5] www.jrobot.net.

24

Drm

Documents

Transcript of Drm