Project Final Report Team 8: R.E.S.C.U - Calvin College Final Report Team 8: R.E.S.C.U.E Robot for Extraction of Survivors Confined in Unreachable Environments ... 1 Introduction to

May 2012 Calvin College, ENGR 339/340 © 2012, Matthew DeVries, Matt Johnson, Paul Lyzenga, Karl Stough and Calvin College

Project Final Report

Team 8: R.E.S.C.U.E Robot for Extraction of Survivors Confined in Unreachable Environments

Matthew DeVries (Mechanical Engineer)

Matt Johnson (Mechanical Engineer)

Paul Lyzenga (Electrical and Computer Engineer)

Karl Stough (Electrical and Computer Engineer)

ENGR 339/340 Senior Design Project

May 2012 i Calvin College, ENGR 339/340

Abstract

In this document, Team RESCUE demonstrates the feasibility of designing and prototyping a small

search and rescue robot which can also be used in hazardous materials situations. Based on the need for a

man-portable robot capable of traversing challenging and dangerous terrain, the robot has independently

rotating tracked arms and communicates wirelessly with a controlling laptop. The robot also has a small

port on the back where additional features such as sensors or mechanical components may be attached.

The team has determined that with a budget of approximately $570 a functioning prototype robot can be

constructed. Full-scale production of 1,000 units annually would result in variable production costs of

approximately $760 per unit, to be sold at $2,750 to rescue organizations.

May 2012 ii Calvin College, ENGR 339/340

Table of Contents

1 Introduction to Project and Team ......................................................................................... 2

2 Project Description ................................................................................................................. 3

2.1 Observation of a Need ....................................................................................................................... 3

3 Design Description .................................................................................................................. 4

3.1 Requirements and Criteria ............................................................................................................... 4

3.2 Locomotion ......................................................................................................................................... 5

3.2.1 Alternatives ............................................................................................................................... 5

3.2.2 Chosen Design and Reasoning .................................................................................................. 6

3.3 Communication, Control and Power ............................................................................................... 7

3.3.1 Communication ......................................................................................................................... 7

3.3.2 Control ...................................................................................................................................... 8

3.3.3 Power ........................................................................................................................................ 9

3.4 Additional Features ......................................................................................................................... 10

4 System Overview ................................................................................................................... 10

4.1 Mechanical Architecture ................................................................................................................. 10

4.2 Electrical Architecture .................................................................................................................... 11

5 Testing .................................................................................................................................... 15

5.1 Initial Wireless Range Test ............................................................................................................. 15

5.2 Gearbox Test .................................................................................................................................... 16

5.3 Motor Current Test ......................................................................................................................... 17

5.4 Track Friction Test .......................................................................................................................... 18

5.5 Battery Test ...................................................................................................................................... 18

5.6 Field of View Test ............................................................................................................................ 19

5.7 Runtime Test .................................................................................................................................... 19

5.8 Second Wireless Range Test ........................................................................................................... 19

5.9 Versatility Tests................................................................................................................................ 19

6 Construction and Design Modifications ............................................................................. 22

6.1 Mechanical Design Modifications ................................................................................................... 22

6.1.1 Bearing Support ...................................................................................................................... 22

6.1.2 Bushings .................................................................................................................................. 23

6.2 Electrical Design Modifications ...................................................................................................... 23

6.2.1 Batteries .................................................................................................................................. 23

6.2.2 Arm Position Sensors .............................................................................................................. 23

6.2.3 Motor Braking and Holding .................................................................................................... 25

6.2.4 Arm Contact Sensing .............................................................................................................. 25

May 2012 iii Calvin College, ENGR 339/340

6.2.5 User Interface .......................................................................................................................... 25

6.3 Robot Component Layout ............................................................................................................... 25

7 Project Management ............................................................................................................. 27

7.1 Team Organization .......................................................................................................................... 27

7.2 Schedule 27

7.3 Budget/Funding Options ................................................................................................................. 27

8 Business Plan ......................................................................................................................... 29

8.1 Marketing Study .............................................................................................................................. 29

8.1.1 Target Market .......................................................................................................................... 29

8.1.2 Competition ............................................................................................................................. 29

8.2 Development and Production Costs ............................................................................................... 30

8.2.1 Prototype Budget..................................................................................................................... 30

8.2.2 Production Budget................................................................................................................... 30

8.3 Possible Future Improvements ....................................................................................................... 31

9 Conclusion ............................................................................................................................. 33

10 List of Abbreviations ............................................................................................................ 34

11 Acknowledgements ............................................................................................................... 35

12 Team Design CAD Drawings ............................................................................................... 36

13 Gearbox Removal Guide ...................................................................................................... 49

14 User’s Guide to Controlling the RESCUE Robot .............................................................. 54

May 2012 iv Calvin College, ENGR 339/340

Table of Figures, Tables and Equations

Figure 1: Team RESCUE - Matthew DeVries, Matt Johnson, Paul Lyzenga, Karl Stough ........... 3

Figure 2: Gearing and Drive Assembly for Track Arm .................................................................. 6

Figure 3: VEX Motor Power Curve ................................................................................................ 7

Figure 4: Electrical System Overview .......................................................................................... 11

Figure 5: Main Controller Board Layout ...................................................................................... 12

Figure 6: Software Block Diagram ............................................................................................... 13

Figure 7: Interface Displayed on Laptop to User.......................................................................... 14

Figure 8: Wireless Range Test Setup ............................................................................................ 15

Figure 9: Gearbox Test Setup ....................................................................................................... 16

Figure 10: Graphical Gearbox Test Results .................................................................................. 17

Figure 11: Voltage Drop from Motor Switching .......................................................................... 18

Figure 12: Robot Stair Climbing Test ........................................................................................... 20

Figure 13: Robot in Upright Position ........................................................................................... 20

Figure 14: Robot Ramp Climb Test .............................................................................................. 21

Figure 15: Robot Back Flip........................................................................................................... 21

Figure 16: Initial Design for Bearing Support .............................................................................. 22

Figure 17: Final Design for Bearing Support ............................................................................... 22

Figure 18: Arm Position Sensor Setup.......................................................................................... 24

May 2012 v Calvin College, ENGR 339/340

Figure 19: Drawing of Arm Position Sensors ............................................................................... 24

Figure 20: Component Layout Inside Robot ................................................................................ 26

Figure 21: Work Breakdown Schedule ......................................................................................... 28

Figure 22: Finished Robot with Cover Removed ......................................................................... 33

Table 1: Locomotion Decision Matrix ............................................................................................ 5

Table 2: Gearbox Test Results ...................................................................................................... 17

Table 3: Current Draw Test Results.............................................................................................. 17

Table 4: Friction Test Results ....................................................................................................... 18

Table 5: Field of View Spreadsheet .............................................................................................. 19

Table 6: Prototype Bill of Materials ............................................................................................. 30

Table 7: Projected Production Costs ............................................................................................. 31

Equation 1.1: ...................................................................................................................................7

May 2012 1 Calvin College, ENGR 339/340

Design Norms

The team is focused on 3 engineering design norms throughout this project: stewardship, trust and

transparency. Stewardship of taxpayers' money was a primary focus as the team attempted to reduce the

overall cost of the robot. Due to the current economic conditions, first responders have very limited

funds, and those funds are provided by taxpayers, corporations and individuals through municipal budgets

and grants. By reducing the cost of the robot, the team hopes to allow even the most resource-challenged

departments to purchase a robot which can reduce risk to human life while helping to save others.

Because of the time-sensitive and life-or-death situations in which the robot will be used, the team has

designed the vehicle to be trustworthy. As such, it is reliable enough that its effectiveness will not be

questioned and durable enough to assist in a broad spectrum of situations.

In the interests of transparency, all text-based communication (sensor information, voltage levels, etc.) are

transmitted using American Standard Code for Information Interchange (ASCII) values, the standard

encoding type for character transmission. While ASCII characters are less compact and therefore take up

more bandwidth, they allow more transparency since the numbers are transmitted in a well-documented,

human-readable form. In addition, the construction of the robot allows for users to easily troubleshoot

issues that may arise, while the software is designed for reasonable ease of use. Finally, the team provides

this report which includes design decisions, technical calculations and drawings documenting the

procedure the team followed.


1 Introduction to Project and Team

Team 8 consists of two mechanical engineers, Matthew “Bruce” DeVries and Matt Johnson, and two

electrical engineers, Paul Lyzenga and Karl Stough, who chose as a group to design and build a robot for

locating survivors from partially collapsed buildings. This team, Team RESCUE – Robot for Extraction

of Survivors Confined in Unreachable Environments – chose the project in light of the recent ten-year

anniversary of the September 11 terrorist attacks, recognizing that robotic search and rescue units are

invaluable in situations like those or natural disasters. The project grew in scope as the group met with

police and fire departments to determine what needs could be met by a robot of this type.

Matt is a senior engineering student concentrating in mechanical engineering. Matt grew up in nearby

Hudsonville, MI and enjoys tennis, cycling, building with Legos and occasionally some programming as

well. Matt has worked with laser cutting and etching as an intern for Innotec Group in Zeeland, MI and

with automated guided vehicles as a field technician for Egemin Automation (based in Holland, MI but

stationed in North Carolina). Matt will be joining the Koops Factory Automation team as a Mechanical

Design Engineer following graduation.

Matthew DeVries is the second mechanical engineer of Team RESCUE. Hailing from Andover,

MN, he has always enjoyed the physical stuff that makes everything work, from toasters to

VCRs; nothing was thrown out without having been thoroughly dismantled. With increasingly

complex mechanical hobbies, engineering was a natural choice. Matthew has accepted an

engineering position at Honda R&D Americas in Marysville, OH and will be designing wiring

harnesses for new Honda automobiles.

Born in Grand Rapids but raised further south, Paul is an electrical engineering student, inspired by the

example of his older brother. His interests within the field tend toward the digital realm and software

development. He has accepted an offer for a position in which he can practice those skills from the

company where he has interned for the past year and a half: Apex Controls, in Hudsonville, MI.

Karl’s interest in electronics started a few years before Calvin with microcontrollers and simple electronic

circuits. He enjoys working on digital logic circuits as well as computer science programming projects.

Karl is from the Aurora area in Illinois and plans to return to Illinois after graduation. He will continue to

work at Alcatel-Lucent following the internship that started summer of 2011.

Matt and Bruce share a fascination with robots, which was a significant factor in the team’s choice of

project. Likewise, Paul and Karl have a common interest in digital systems. This project allows all four

team members to pursue their passions while creating a product with practical applications, which makes

this project a good choice for senior design.


Figure 1: Team RESCUE - Matthew DeVries, Matt Johnson, Paul Lyzenga, Karl Stough

2 Project Description

2.1 Observation of a Need

The need for a widely available, cost-effective search and rescue robot became increasingly evident

following the terrorist attacks in the United States on September 11, 2001. This was the first true

deployment of robots for search and rescue operations. Since that time, robots have been used in various

disaster and hazardous materials situations with varying degrees of success; however, the number of first

responders with access to a basic search and rescue or reconnaissance robot (excluding bomb squad

robots) is minimal at best. Currently, the Center for Robot-Assisted Search and Rescue (CRASAR) is the

main source of such robots, and precious time is used in simply transporting the machines to the disaster

site.1 Thus, the team decided to design and prototype a man-portable unmanned ground vehicle (UGV)

which would be low-cost, reliable and easy to operate.

1 Siciliano, Bruno, and Oussama Khatib, eds. Springer Handbook of Robotics. New York: Springer, 2008. 1156-57. Web. 2 Nov.

2011.


3 Design Description

3.1 Requirements and Criteria

For the RESCUE robot, size is one of the main constraints. The robot needs to be small and light enough

to get into places inaccessible by humans. However, the robot must be able to surmount obstacles

commonly found in disaster areas. The most common obstacle is stairs, so it shall be as small and light as

possible to remain portable, but shall also be large enough to climb stairs. Length is a key factor in stair

climbing because, for speed and stability, the robot must contact at least two stair edges at all times. The

robot shall be able to go under fallen obstacles as well as above them if needed. On a flat surface it shall

be able to move at approximately 1 mile per hour.

Along with mobility and size constraints, the robot shall be water and dust resistant. In any recently

collapsed building there will be dust and fine particles that could interfere with the operation of the robot.

There may also be broken pipes and puddles of water. It is important that this environment does not

cause the robot to fail. In the event of a hazmat situation the robot will need to be cleaned after use and

shall be able to withstand rinsing. Because of these factors, the robot shall be sealed with all of its

electronics and gear boxes located inside the body to ensure protection from the elements.

Because of the many situations in which the robot may be used, it shall have a port for configurable

attachments. One key attachment would be a quick release latch that can be used to transport water or

other important commodities. Other potential attachments include environmental sensing equipment or

additional cameras.

The robot shall be controlled remotely and have a two way audio communication system. The wireless

range shall be 75 feet through a 1 foot thick concrete wall. The robot will have a camera and microphone

for detection of persons trapped or injured, as well as a speaker so that the operator will be able to

communicate directly with the person in danger. Since the robot will rely solely on battery power, it shall

have a minimum run time of one hour.

It is vital that once a person is discovered the robot can be located. The orientation and status of the robot

shall be displayed on the control screen – that is, the pitch and yaw of the robot will be shown, as well as

the relative pitch of each arm.


3.2 Locomotion

3.2.1 Alternatives

Table 1: Locomotion Decision Matrix

The most basic problem facing UGVs is mobility, and the choice of locomotion affects the structure of

the entire robot. To meet the stated requirements, the vehicle must have a flexible drive system which can

adapt to the myriad of conditions and obstacles possible in collapse scenarios, while remaining simple and

reliable enough for search and rescue work.

The team considered many options (Table 1) when designing the robot, the first of which was a snake-

style motion using joints which would expand and retract. This option would provide exceptional

maneuverability in a relatively small package. The addition of modular sensors and payloads would lead

to increased mission flexibility. However, the speed of a snake-style robot is quite limited, and the

mechanical complexities would mean a cost far greater than the allotted budget.

A second locomotion option was a hexapod design with insect-like legs. Legs are most easily adapted to

the uneven terrain found in building collapses. However, each leg would require at least 2 joints and 3

degrees of freedom, which greatly increases complexity, both physical and programmatic, as well as cost.

This increased complexity also decreases reliability and durability, which were two factors the team

considered very important. With a minimum of four legs required for stability, the team decided that

insect-like locomotion would be too complex, too costly and too fragile.

A more novel third option involved rotating screws placed on the outside of the robot. When spinning in

opposite directions, they would propel the vehicle forward through almost any terrain. These screws

(similar to a back-driven worm) provide lots of traction and would work in water. Unfortunately, the

screw system cannot climb stairs, thus failing one of the team's key design criteria.

Large wheels were briefly considered as a fourth type of locomotion. Wheels would be the simplest,

cheapest and most reliable option, as they require fewer motors and fewer moving parts. However, the

mobility of a simple wheeled vehicle is severely limited, and a small wheeled robot would not be able to

climb stairs. Placing a wheel at the end of a freely rotating arm would solve the stair-climbing problem,

but there would be no traction along the length of the arm.

Using tracks on the arm instead of a wheel was the final option. Tracks supply traction along the entire

arm without an increase in complexity over wheels on the end of rotating arms. This design would allow

the robot greater mobility than simple wheels and more traction than a wheel on an arm.

Aspects Cost Versatility Complexity (mech) Complexity (prog) Durability Total

Aspect Weight 18 30 15 10 20 93

Tracks 3 10 6 7 7 7.0

Legs 1 7 2 2 2 3.4

Wheels 8 2 10 10 9 6.8

Wheel on leg 4 7 5 7 6 5.9

Worm/Screw Wheels 5 3 7 9 8 5.8

Snake 1 7 2 2 3 3.6


3.2.2 Chosen Design and Reasoning

The tracked system utilizing four tracks on independent, rotating arms was chosen for this project. With

this design, the vehicle can climb stairs, lift itself off the ground to clear obstacles, and travel through

muddy terrain. The arms can be used to pull the vehicle forward should it become stuck, yet it will still

be operable even if flipped over. Each track assembly is 1.5 inches wide and 10 inches long axle-to-axle.

The height of each track is 2.375 inches while the body of the robot is only 2 inches thick, so the robot

can run on just the track hubs over flat surfaces. Each track has a side shield to minimize the risk of

becoming de-tracked, a crippling problem that has been an issue for tracked vehicles in previous

applications.2 The team looked into building its own tracks, but this proved too expensive and time-

consuming. Thus, a couple of tread kits were purchased and implemented instead. The diameter of the

track hubs provided a target overall height for the robot body of two inches.

Figure 2: Gearing and Drive Assembly for Track Arm

Each track is driven directly by an electric motor, producing a final ground speed of approximately ten

inches per second with a fully charged battery. A myriad of motors were considered in the design

process. Motors with enough torque (usually through an attached gearbox) were too large, while smaller

motors with higher revolutions per minute (RPM) would require custom gear reductions (Figure 2). The

final choice involved using eight VEX 7.2 volt, 100 RPM motors: four driving the tracks themselves, and

four rotating the arms.

2 Siciliano, Bruno, and Oussama Khatib, eds. Springer Handbook of Robotics. New York: Springer, 2008. 1158. Web. 2 Nov.

2011.


Figure 3: VEX Motor Power Curve

These motors fit the size (~1 inch thick) and power (13.5 inch-pounds of torque) constraints relatively

well. To achieve the desired torque, however, a gear reduction was necessary. A gearbox with overall

reduction of 9:1 was required; however, the size constraint made a single-stage reduction impossible, so

the team designed the gearbox with two 3:1 reduction stages. The axle driving the tracks passes through a

hollowed out, thick-walled tube. This tube is connected to the final gear in the gear train, which allows

the arm to rotate independently of the track movement. Each arm is controlled by its own electric motor

coupled with the gear reduction of Rd = 9:1, to deliver an arm rotation rate of ten revolutions per minute

and a torque (T) of 3.3 foot-pounds under normal operating conditions (A = 1.6 amps out of 3.6 max,

Figure 3) with a 40% loss due to friction (ε). The motors have a rated speed of ω = 100 revolutions per

minute running at V = 7.2 volts (Equation 1.1).

(

) ( )

(1.1)

This allows two arms to easily lift their half of the robot body, which weighs approximately eleven

pounds (the entire robot with arms weighs 14.5 pounds). The chosen motors have the necessary torque

(with the gear train) at 7.2 volts when drawing 1.6 amps. The gears used in the reduction train are one-

half inch wide to reduce stress on the individual teeth and have holes allowing connection of the rotation

axle tube to the larger gear. Also, all electronic components remain inside the vehicle, making this design

very water and dust resistant.

3.3 Communication, Control and Power

3.3.1 Communication

3.3.1.1. Alternatives

The robot will be used in disaster areas inside collapsed buildings and around debris. It will likely be

used in collapsed basements or in other radio frequency (RF) shielded environments. It is assumed that


there will be no external coverage, such as cellular networks, in the case of natural disasters. The goal is

to have a range of up to 150 feet line of sight for the initial prototype, less in confined areas with

structural interference. Communication with the robot could be achieved in one of three ways:

The first option was to use a cable tethered to the robot at all times to provide power, communication and

other functions such as a fresh water supply. Using a tethering cable from the base station to the robot

meant that a battery would not be needed and operating time would not be an issue. Communication

between controller and robot would be more reliable and less susceptible to interference. The tether could

potentially create problems by snagging on corners of objects or tangling in steel debris. A tether would

also have to be stored either on the robot or near the operator. The friction from pulling the cable could

prove overwhelming for a robot of this size.

A second option was to utilize a WiFi router to handle all communications between the robot and base

station. The popularity of this technology with consumers means that the cost is kept lower than other

possible wireless solutions. Using a WiFi router in conjunction with a laptop computer eliminates the

need for a dedicated transceiver pair. WiFi will also provide sufficient bandwidth for video streams from

the robot provided the signal is free of interference. Disadvantages of using a WiFi router would include

the limited wireless range that it may provide (approximately 150 feet line of sight), especially through

solid walls.

The final option would be to use a dedicated RF transceiver pair for all communications. This method

could be designed to provide sufficient bandwidth at very long ranges (up to 1 mile). It could be designed

with more transmission power than a typical WiFi router to maintain the signal to the robot through

interference such as walls and debris. The disadvantage to using such a system is that it can be expensive.

3.3.1.2. Chosen Design and Reasoning

Of these three options it was decided that a simple WiFi router would be used in the prototype. This was

done primarily because of its low cost, wireless capability and ease of implementation with other systems.

Using a router as the primary path of communication also meant that video communications could bypass

the motor controller entirely. In a production design, the robot could have a more powerful and dedicated

RF transceiver pair or a more powerful WiFi router. For this prototype, however, a simple commercial

router was used to keep costs down. The specific router, a Buffalo Technology High Power N150, was

chosen for its greater signal strength and low price. Also see section 3.3.2 (Control) for more justification

for using a WiFi router.

3.3.2 Control

3.3.2.1. Alternatives

Control of the robot would be done via one of several methods which could include a dedicated

microcontroller or a processor programmed onto a field programmable gate array (FPGA). Another

alternative is to construct a simple computer running an operating system, such as Linux.

A microcontroller can be purchased cheaply and is powerful enough for most functions. Positioning and

most sensing could be done with the microcontroller, leaving video streams to another device. This

approach would be very simple to design and implement quickly. In addition, the cost of a


microcontroller for final production would be less than $10.3 The disadvantage of a microcontroller is

that cheaper processors may not be able to transmit video streams and audio to and from the operator. It

would, however, be able to handle all other sensors and motors including accelerometers, GPS and

temperature sensors.

An FPGA such as the Cyclone II would be more flexible to work with and could be designed to handle all

the needed functions, but is often more expensive than a microcontroller. The Altera DE2 development

board possesses a video input, network capability and audio connections on a single board. The main

problem with a dedicated FPGA is the high cost per chip. The cost of the FPGA used in the DE2 board

(Cyclone II EP2C35F672C6N) is $150 per unit, not including the external memory or other parts.4 In

addition, the development cycle could be delayed by the additional complexity of designing a processor

using this FPGA.

A third option was to construct a miniature computer capable of running a Linux operating system to

handle all peripherals attached to the robot. An advantage of using an operating system is that drivers are

available for hardware such as cameras, speakers, microphones and network adapters, making

development easier. The computer could be made powerful enough to process all sensor information

including cameras and voice communication. Much like the FPGA, this approach would be expensive.

Interface between this computer and the motors and low level sensors may require an additional

microcontroller which would add to the cost. This complicated system also has the potential to draw

much more power than alternative designs, an undesirable attribute for a battery powered system.

3.3.2.2. Chosen Design and Reasoning

For the preliminary prototype an Arduino microcontroller was chosen. This was done because of the

availability of the microcontroller (Arduino Uno with Ethernet connection already owned) and for its

simplicity of use. A more refined prototype would contain a more powerful microprocessor, such as an

AVR or ARM based microcontroller, on a custom printed circuit board. Other alternatives are far more

expensive and more complex.

This choice of controller also influenced the choice of communication device. If a WiFi router is used,

camera images can be sent directly through the router to the operator's laptop without involving the

microcontroller. This removes a large responsibility from the microcontroller and allows the use of a

much cheaper device. The software on the laptop then receives all information from different devices and

displays it to the operator. Using a WiFi router allows for future improvements as discussed in section

8.3 (Possible Future Improvements).

3.3.3 Power

To be useful for search and rescue applications, the robot shall have at least 1 hour of runtime. It is

assumed that only some of the motors will be run at any time, but power must be provided to all the

electronic components continuously. A tethered cable could provide continuous power for extended

3 ATMEGA2560, $10.032 per unit at 100 units,

<http://search.digikey.com/us/en/products/ATMEGA2560-16AU/ATMEGA2560-16AU-ND/735455> 4 <http://search.digikey.com/us/en/products/EP2C35F672C6N/544-1694-ND/1084608>


runtimes; the disadvantages to using a tether are discussed in 3.3.1 (Communication). Another option

was to use a rechargeable battery, which allows for freedom of movement but restricts runtime.

For this design, it was decided that the versatility of a wireless system was more important than longer

runtime. In addition, this design permitted the option to switch over to tethered mode without heavy

modification. This is discussed in section 8.3 (Possible Future Improvements). As explained in section

6.2.1 (Batteries), two appropriately-sized batteries were chosen due to current draw constraints.

3.4 Additional Features

The robot has additional features to assist in search and rescue applications, including cameras, audio

systems and sensors. A single optical camera containing both a speaker and microphone was used to save

space and money through component consolidation. In addition, the robot has an attachment point for

custom sensors to detect hazards such as oxygen and other hazardous materials.

For location and position determination, the robot was fitted with an accelerometer, arm orientation

sensors and a GPS to show the position and orientation of the robot as well as the orientation of the arms.

In the event that the robot is flipped upside down, the software on the laptop automatically correct camera

view and control orientation so that the operator may continue to operate the robot normally.

4 System Overview

4.1 Mechanical Architecture

The majority of the structure of the RESCUE Robot is made out of machined aluminum. One of the

design goals was that the robot be light for ease of transportation and so that the arms would be able to lift

the body. The estimated weight of the body at the beginning of the design process was ten pounds. This

weight included all internal mechanical components and circuitry but not the arms themselves. This

estimated weight was then used in calculating the torque that the motor would need to produce. After

searching for and finding a suitable motor for the arm rotation, a gear box was designed to ensure the final

torque was sufficient. The robot has four gearboxes, each of which controls one arm. Each gearbox has

two motors, one for arm rotation and one for track motion, for a total of eight motors inside the robot.

Autodesk Inventor was the primary program used for designing and modeling the prototype. This

allowed for a complete visualization of the robot and could be used to demonstrate its functionality to

others not involved directly in the project. Through this process the team was able to foresee potential

assembly problems and allowed for the mechanical team members to give the electrical members an

accurate idea of the space that they would have to work with inside the body for electrical components.

The first component to be machined and assembled was a gear box. Ensuring that the motor would be

able to produce the proper amount of torque was critical. The test can be read about in 5.2 (Gearbox

Test). After having passed the test, the rest of the aluminum components were laser cut and the body was

cut and folded by the team’s industrial consultant. Once the parts were received the final geometries were

machined in, holes were cleaned up and true assembly began. All other parts needed were either

purchased or made in the metal shop using a mill, lathe or drill press or any combination thereof.


4.2 Electrical Architecture

The electrical system is designed to provide the interface between the operator and the robot. It provides

the means to stream video and sensor data from the robot back to the operator as well as provide a means

to relay instructions from the user to the locomotion system. The system is centered around a WiFi router

which provides the wireless connection between the robot and laptop. An EasyN FS-613B-M166 Ethernet

camera is attached to a Buffalo Technology WHR-HP-GN router to provide both a video stream to the

operator as well as a two-way audio stream between the robot and the operator.

The Arduino microcontroller is attached to an Ethernet shield to interface with the router. Connected to

the Arduino is the accelerometer, GPS and a PICAXE microcontroller. The PICAXE is used solely for

additional output pins as the Arduino used by the team does not have sufficient outputs to control all

devices and motors. It should be noted that in a production design, there would be a single AVR

microcontroller. The choice to use two microcontrollers was made because of budget restrictions and

availability of parts from team members. An overview of the electrical system is shown in Figure 4.

RouterCamera

(with speakers)

ArduinoPICAXE

Motor Drivers

Ethernet Shield

Ethernet

Ethernet

SPI bus

Serial

Digital Out

WiFi

GPSSerial

Accelerometer

i2c

Power Regulation7-11 V in, 5 V out

1A typ

Digital Out

Arm Position Sensors

ADC

Figure 4: Electrical System Overview

As shown in Figure 4, the Arduino communicates to the Ethernet shield via the SPI bus. It uses two pairs

of serial lines to communicate with the PICAXE and GPS. The accelerometer is interfaced with an i2c

bus according to the example code provided by SparkFun Electronics5. Arm position sensors are read

with the Analog to Digital Converter (ADC) on the Arduino.

5 Example code found at http://www.sparkfun.com/products/10955

http://www.sparkfun.com/products/10955


Power regulation uses a pair of linear voltage regulators to step down DC voltage from battery levels (7-

11 volts) and outputs a steady 5 volts for the router and camera. Current draw for the router and camera

are approximately 0.5 amps each. The Arduino has a built-in voltage regulator that regulates power for

itself and the PICAXE microcontroller, which combined draw 0.5 amps as well.

The Printed Circuit Board (PCB) used in the robot was designed using dedicated CAD software and all

traces were routed by hand. This board provides the interface between the Arduino, arm position sensors,

accelerometer, PICAXE, GPS and all eight motor drivers. The final board layout is shown in Figure 5.

The team manufactured the board in Calvin’s electronics lab, populated it and then tested the connections.

A single trace was found to be missing in the final board and was fixed with a small jumper.

Figure 5: Main Controller Board Layout

The Java user interface and control program, running on the laptop, is used primarily to accept input from

and present information to the end user. A block diagram of the program can be seen below in Figure 6.

The central control of the program communicates with the Native Swing web browser to present the

camera feed to the user, as well as the camera controls (record, talk, listen, snapshot). As well, at regular

intervals the program sends messages to the microcontroller via the PrintWriter; each message which

either requests data, such as the current GPS location or device orientation, or sends a command to

activate or deactivate motors. The responses of these commands are then received by the

BufferedReader. The reader passes along the message to a function which forwards relevant information

to the appropriate parser. The parser then updates the rest of the program as appropriate. The final

important component is the Java3D canvas which contains a wireframe model of the robot. This model is

updated whenever new information on the orientation of the robot or the positions of the arms is received.


Figure 6: Software Block Diagram

The team chose the Java programming language because of its cross-platform nature - it works on all

major operating systems. The user interface itself simply displays the output from the robot’s camera, as

well as information on the location of the robot and the status of the arms. To facilitate an intuitive

interface, the status of the arms is shown using a small wireframe model of the robot with the arms in the

current positions. For audio input and output, the program will use the controlling laptop’s default

speakers and microphone. The finalized interface is shown below in Figure 7. Note that the buttons in

the bottom right hand corner are only accessible to Windows users. This is a necessary sacrifice due to

the camera chosen by the team, which did not list this requirement in its specifications.


Figure 7: Interface Displayed on Laptop to User

As mentioned above, the Native Swing and Java3D modules were used to add utility to the default Java

classes. The Native Swing library was selected from among several options for web browser support (the

Java Browser project, Lobo, Flying Saucer, etc.) because it was designed to be compatible with the Swing

architecture included as a part of Java and which was already in use for the rest of the project. This

library required the use of the Standard Widget Toolkit, which is freely available. For the robot

wireframe, Java3D was selected as a simple addition. Java3D is a project from the same group that

develops the Java language and is only packaged separately to lessen the size of the base Java

development environment. Thus it was a natural extension to use when programming three dimensional

models in Java.

Communication between the two devices (computer and microcontroller) is accomplished via a TCP/IP

connection. The microcontroller’s IP address is static, and the Java interface connects directly to the

microcontroller. Messages are passed along this connection. Formatting for these messages is based on

the NMEA (National Marine Electronics Association) 0183 protocol. Early versions of the message

construction used the NMEA protocol directly, creating comma-separated messages with four-letter

headers and a two-digit checksum at the end, like so: $ACMS,18,18,18,18,00,28,00,28*1C. Since these

commands were very lengthy and took significant amounts of memory in the microcontroller, it was

decided to alter the message style, removing all superfluous characters, like so: m11110202*6D. This

allowed faster and more efficient message parsing by the microcontroller.


5 Testing

5.1 Initial Wireless Range Test

The first major test the team performed was a wireless range test. For this test, a wireless router was

hooked up to a portable power supply and a microcontroller. That microcontroller controlled power to a

light bulb. When a command was sent from the laptop to the router, the light bulb would be illuminated.

Repeating the command would turn the light off. To test wireless range, a team member carried the router

and power supply away from the laptop and down an apartment hallway. When the light bulb stopped

blinking, the router had effectively reached the end of its range. This test showed an approximate range

of 150 feet with minimal obstructions. When carried downstairs, placing two floors between the router

and computer to simulate obstructions, the range dropped to approximately 80 feet. Figure 8 shows the

setup used for this experiment.

Figure 8: Wireless Range Test Setup


5.2 Gearbox Test

As soon as the necessary components arrived, the team built a prototype gearbox to test the torque output.

The test setup consisted of a 1.5 amp power supply powering a VEX motor. An output shaft from the

final gear was attached to a 2.6 inch gear, to which a string was attached. The motor would spin the large

gear, winding the string and raising a 20 pound weight resting on the floor.

Figure 9: Gearbox Test Setup

In the event that the weight could not be raised, two 50 Newton scales were hung in parallel between the

weight and the gear. This would allow the team to see how much tension the gearbox would put in the

string. If the 20 pound weight was successfully lifted, it would mean that the motor and gearbox

combination was capable of producing at least 2.2 foot-pounds of torque. While this is less than the

gearbox was designed to produce, the power supply was also limited to 1.5 amps, which is less than half

of what the motors were capable of drawing (3.6 amps). Thus, if the weight could be lifted at 1.5 amps,

then the necessary torque would likely be achievable under full current draw. Figure 9 shows the gearbox

test setup. Two multimeters were used to measure motor voltage and current throughout the test. The

results of the test, seen in Table 2 and Figure 10, show that current draw increased in an approximately

linear fashion with load. One result of this test not shown in the data is the fact that the square shafts used

to support the gears tended to dig into the aluminum gearbox plates, necessitating the inclusion of some

sort of bearing system. The team decided to use shaft couplers, which connect to the square shaft and

create a round surface to insert into a bushing. Bronze bushings impregnated with graphite were chosen

to reduce friction and wear on the aluminum supports; see 6.1.2 (Bushings).


Table 2: Gearbox Test Results

Figure 10: Graphical Gearbox Test Results

5.3 Motor Current Test

Once the redesigned gearboxes were assembled, a current draw test was performed, with the objective of

determining which gearboxes had excessive friction. Those with excess friction would be adjusted to

ensure that there would be as little loss to friction as possible. The test was performed by powering each

motor (drive motors and rotator motors) with no load and while lifting an arm, respectively. The results,

displayed in Table 3, showed that the front right and rear left gearboxes had more friction than the others

in the direct track drive. These were drilled out to ensure that the driveshaft was not rubbing on the arm

tube axle. The front and rear left gearboxes had excessive friction in the gear train for rotating the arms.

It was discovered that these had shafts that were rubbing against the body of the robot. Once the shafts

were shortened, the friction was reduced. Numbers in italics represent gearboxes targeted for having

excessive friction.

Table 3: Current Draw Test Results

Load (Newtons) 0 N 20 N 36 N 50 N 74 N 100 N

Voltage (volts) 7.2 V 7.2 V 7.2 V 7.2 V 7.2 V 7.2 V

Current Draw (amps) 0.18 A 0.36 A 0.67 A 0.94 A 1.56 A 1.98 A

Tested Extrapolated

y = 0.0189x + 0.0631 R² = 0.966

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

0 10 20 30 40 50 60 70 80

Cu

rre

nt

(A)

Load (N @ 1.3 in. offset)

Current Draw as a Function of Load

Gearbox FR FL RR RL

Driver no-load current (A) 0.37 0.25 0.25 0.37

Post-modification current (A) 0.35 - - 0.27

Rotator current when lifing arm (A) 0.32 0.42 0.37 0.48

Post-modification current (A) - 0.37 - 0.39


5.4 Track Friction Test

The prefabricated treads installed on the robot are made of Delrin plastic and have a low coefficient of

friction. Because of this, climbing stairs with smooth edges would present a problem because the tracks

would not grip. To determine the best method for enhancing grip, a test was performed using different

materials affixed to a five-link section of track. Each variation was tested on three different surfaces:

wooden bench top, concrete floor and vinyl stairs. Five different materials were used: 220 grit sandpaper,

600 grit sandpaper, double sided tape with sandblasting grit, sandblasting grit attached with epoxy, and

coarse sand also attached with epoxy. A control set with no material attached was tested as well.

Table 4: Friction Test Results

For the experiment each sample was loaded with 1.85 pounds and a spring force gauge was hooked onto

an open link. The opposite end of the gage was pulled until the sample began moving and a reading could

be obtained. The results can be seen in Table 4 (higher coefficient is better). The 220 grit sandpaper

achieved a marginally higher coefficient of friction over the epoxied sandblasting grit. However, because

of more robust means of attachment, the epoxied sandblasting grit was chosen as the best option and was

applied to the tracks of the robot.

5.5 Battery Test

Shortly after receiving the purchased battery, a test was performed to determine whether that single

battery could run both the motors and the electronics. It was discovered that the battery was overtaxed

when the motors were started; its output voltage dipped so low that it could no longer run the router,

camera, and microcontroller (see Figure 11). As such, all three would reset and control would be lost. At

this point the team determined that a second battery would be necessary to run the electronics separately

from the motors.

Figure 11: Voltage Drop from Motor Switching

600 grit sandpaper 220 grit sandpaper Taped blasting grit Epoxied blasting grit Epoxied coarse grit Control

Wood (workbench) 0.49 0.73 0.38 0.61 0.49 0.30

Concrete (floor) 0.39 0.49 0.43 0.46 0.33 0.36

Vinyl (stairs) 0.58 0.85 0.55 0.85 0.73 0.46

Coefficent of Friction


5.6 Field of View Test

The orientation of the camera inside the robot affects the field of view for the operator. The longest side

of the circuit board that the camera lens was mounted to was 1.875 inches, which was too large to fit

inside the body without slotting the body and lid. The team performed a field of view test to determine

how far ahead of the robot the operator would be able to first see the ground. In portrait-style orientation,

the operator can see the ground closer to the robot but not as much side-to-side. Conversely, in

landscape-style orientation, the operator has a wider field of view to the sides but cannot see the ground

as close. Ultimately, the size of the circuit board determined the mounting of the camera inside the robot,

and thus the field of view (portrait). However, the team did some calculations to determine ground-view-

distance for either mode, depending on the angle of the tracks (and thus the robot body). Table 5 shows

the results of the analysis - in portrait mode, with the robot lifted up on all four arms, the operator can first

see the ground about 28 inches ahead of the robot.

Table 5: Field of View Spreadsheet

5.7 Runtime Test

To test runtime, the robot was turned on and a timer displayed in front of the camera. When the

electronics battery (the bottleneck battery) died, the last updated camera image showed how long the

battery lasted. This turned out to be approximately 45 minutes, which is more than sufficient for the

anticipated 20 minute average rescue mission length.

5.8 Second Wireless Range Test

Final wireless range was tested by driving the robot until the camera feed frame rate dropped below 2

frames per second, which would hamper control of the robot. The test consisted of both a line of sight

test in an open area and an interference range test. The robot has a range of 150 feet line of sight and a

range of 50 feet under heavy interference, which included an 8 inch cinderblock wall, a steel door, and

some aluminum ductwork.

5.9 Versatility Tests

The robot is designed to climb stairs and traverse other rubble. To test this, the team drove the robot up a

custom-built flight of three stairs, each 7 inches high and 9.5 inches deep. The robot was able to

successfully climb up and down the stairs many times under its own power (Figure 12). However,

considerable practice was necessary for the driver to climb stairs efficiently. In addition, the robot was

able to lift itself upright (Figure 12), easily cross a 10 inch gap, and climb and descend a 21 inch tall ramp

at an angle of 49 degrees from horizontal (Figure 14). Even back flips are possible (Figure 15)! Note that

in the following three pictures, the robot is tethered. This is because the wireless battery was charging

during testing.

Front Track Position (0-90) 90 Degrees

Rear Track Position (0-90) 90 Degrees

Camera Height 11.20 Inches

Camera Angle 0.00 Degrees

Ground View Distance (Landscape) 39.06 Inches +/- 2 inches

Ground View Distance (Portrait) 27.72 Inches +/- 2 inches


Figure 12: Robot Stair Climbing Test

Figure 13: Robot in Upright Position


Figure 14: Robot Ramp Climb Test

Figure 15: Robot Back Flip


6 Construction and Design Modifications

6.1 Mechanical Design Modifications

6.1.1 Bearing Support

Throughout the final design and construction process, there were many modifications made to the original

design. The first major modification was a change in the bearing design. Initially, the team planned to

use a needle bearing which would support the arm axle tube. However, constraining this bearing proved

to be a complicated endeavor, requiring the part shown in Figure 16.

Figure 16: Initial Design for Bearing Support

This part would take many hours of machining to fabricate, and considering the design calls for four of

them, the design change saved an estimated 20 man-hours of machining.

Figure 17: Final Design for Bearing Support

The final two-piece design, shown in Figure 17, consists of a separate flanged bearing and support piece.

With this design, the bearing (left) rests inside the groove on the support piece (right), and is effectively

sandwiched between the support piece and wall of the robot body. Bearing replacement is easier and the

load on the bearing is distributed more evenly between the body and the support piece.


6.1.2 Bushings

The second major modification was the addition of bushings in the gearboxes. Initial tests of the gearbox

(Figure 9, Page 16) showed that the square axles would dig into the aluminum support pieces, generating

friction, increasing wear and introducing slop into the gear train. A proposed solution was to attach shaft

couplers to the shafts. These couplers had square inserts for the shafts and round exteriors, making them

a good candidate for bushings. This solution proved ideal, so several couplers were cut in half to ensure

that they would fit in the gearbox, while the rest were installed unmodified. These couplers fit inside

bronze bushings; the bushings come impregnated with graphite to provide lubrication. The team found

that the new design both decreased mechanical slop and wear in the system and reduced friction in the

gear train.

6.2 Electrical Design Modifications

6.2.1 Batteries

As detailed in section 5.5 (Battery Test), the team determined that a second battery would be necessary to

provide proper power to every component even while the motors were running. Fortunately, the team

already owned a battery which could be used for the task. Space within the robot was found for the

battery and the CAD model was updated accordingly. The battery assigned to the motors is rated at 5

amp-hours at 7.2 volts, and the electronics battery is rated at 1.6 amp-hours at 9.6 volts. Since the router,

camera, and microcontroller draw approximately 1.5 amps, this gives more than an hour of runtime to the

electronics (under ideal conditions). The motor current draw is more varied, but the team discovered that

5 amp-hours is enough for at least a full hour of runtime.

6.2.2 Arm Position Sensors

The arm position sensors (Figure 18) were designed after construction of the bearing housings connecting

the tracks to the rotation motors and gearboxes. The team used a thin PCB and some C-shaped pieces of

resistive paper to construct four potentiometer-like position sensors. The design is shown below in Figure

19. When the arm rotates in one direction, a wiper on the tube axle moves along the resistive paper and

makes contact with the copper inner ring. A constant voltage of 5 volts is applied between ends of the

resistive ring. Depending on the position of the arm, the voltage measured on the inner ring will vary from

+5 volts to 0 volts. This value is measured with the Arduino microcontroller and sent to the laptop. It

should be noted that there is a “dead zone” with this design that returns a meaningless result when the

wiper doesn’t contact the outer resistive ring. The wiper is placed on the arm so that this happens when

the arms are folded in next to the body of the robot. Figure 19 shows the electrical equivalent of the

circuit shown on the left and the actual implementation on the right.


Figure 18: Arm Position Sensor Setup

Figure 19: Drawing of Arm Position Sensors


6.2.3 Motor Braking and Holding

After construction of the robot, the team noticed that the arm rotation motors would not hold the arms in

position when the robot was partially lifted off the ground. This was primarily due to the lack of motor

braking on the motor drivers used. The team brainstormed three ways to hold the rotation motors in place

when the robot is partially elevated:

Attach solenoids to the gearboxes that would engage when the motors are off to lock

position

Connect relays in parallel with the arm rotation motors and close the relays when the

motors are off to brake the motors

Utilize a feedback system to read the arm positions and automatically rotate the arms

back to the desired position.

Of the three choices, it was decided that the team would use the feedback system as this would only

require a change in software. Using a solenoid would require extensive mechanical modifications and the

use of a relay could potentially cause problems with the motor control system shorting out. A production

model would incorporate a mechanical means of motor braking.

6.2.4 Arm Contact Sensing

In order to detect contact between the arms and any obstacles, the controller would have to monitor

voltage differences across the arm rotation motors. When the arms encountered resistance (obstacles), a

large voltage difference would be measured and would be reported to the operator. In order to measure

these voltages, no fewer than eight ADC’s would be needed (two ADC’s per each of the four rotation

motors). The Arduino microcontroller being used does not have enough ADC’s to measure all the

voltages at the motors. In a production design, a larger microcontroller would have sufficient analog

inputs to measure the desired voltages.

6.2.5 User Interface

The user interface underwent several different versions as the capabilities of various Java modules were

explored. In the end, rather than take the feed directly from the camera, it was necessary to use a Java-

based web browser utilizing the Native Swing project. In addition, a combination of two factors

decreased the performance of the camera by requiring the team to open browser feeds to the camera. In

the early stages of construction, due to space constraints, the camera was mounted so that its feed would

be shown sideways on the monitoring web page. Because of this and the fact that the camera only

supports transmitting and receiving audio on a single web page whose individual components cannot be

rotated, the team was forced to isolate the camera feed on a different page in order to present it to the user

right side up; audio capabilities had to be loaded separately, requiring the camera to transmit two video

streams to the application.

6.3 Robot Component Layout

Figure 20 shows an approximate top-down view of the robot without the lid on. The numbers correlate to

the descriptions below; the front of the robot is facing the left side of the page. Each of the individual

components designed and machined by the team can be seen in section 12,


Team Design CAD Drawings.

Figure 20: Component Layout Inside Robot

1. Rectangular Body - Made out of folded 1/8” sheet aluminum, measures 17” L x 10” W x 2” H

2. Bearing Support Plate – Plate on gear box that attaches to the body and holds the arm bearing in

place

3. Gears – Used with the motor for the rotation of the arm to ensure sufficient torque

4. Interior Support Plate – Primary connection for motors

5. Arm Rotation Motor – Motor attached to gears for turning the arm

6. Track Drive Motor – Motor that directly drives the tracks

7. Camera and Communications Cover – Machined transparent fixture that protects the camera and

holds the microphone and speaker for two way communication

8. Camera – Security camera with infrared LEDs for night vision

9. Microphone – Allows operator to hear ambient noise around robot or listen to survivors

10. Speaker – Allows the operator to talk to survivors

11. Motor Battery – Powers all motors

12. Electronics Battery – Powers all electronics aside from motors

13. Motor Driver Board – Houses motor driving circuitry, microcontrollers, accelerometer and GPS

14. Wireless Router/Camera Circuit Board – Router on bottom for communication with computer and

camera circuitry on top


7 Project Management

7.1 Team Organization

The team divided first according to concentration: the mechanical engineers (Bruce and Matt) assume

responsibility for the mechanical aspects of the design – shape, locomotion, etc. – while the electrical

engineers (Paul and Karl) took care of the electrical aspects – wiring, programming, sensors, etc. Tasks

were subdivided between each member according to strengths and experience. Bruce, who has

considerable computer aided design (CAD) experience, handled much of the CAD modeling and robot

construction. Matt likewise managed calculations, research, administrative duties and assisted Bruce with

robot construction. The two collaborated to ensure that they had the same vision for the mechanical

design. On the electrical side, Karl, who has spent a great deal of time working with microcontrollers,

performed the hardware design and the microcontroller programming. Paul similarly designed the

software for the controller and the user interface. The two together handled the communication between

the robot and computer and the overall electrical design of the project. The team as a whole regularly

discussed the interaction between mechanical and electrical systems, particularly any needs regarding

space and sensors.

7.2 Schedule

Mechanical design and electrical/software design occurred simultaneously, with each realm influencing

the other. For example, the mechanical design was modified to allow for a second battery, while the

electrical design was constrained by the physical space within the robot itself.

Overall conceptual design was completed in early November. General robot mechanical design was

completed in mid-January. However, the design details were quite dynamic, as problems arose that had

to be resolved and as improvement ideas were implemented. Software design began in January and

evolved continually as the prototype was built and tested. The assembled prototype was first fully tested

on April 13. More software debugging and hardware modifications followed this initial test, and a

plethora of performance tests were performed in late April and early May. The robot performed

admirably on Senior Design Night, running both tethered and wirelessly for about an hour and a half. An

approximate schedule of completed events is shown in Figure 21.

7.3 Budget/Funding Options

Calvin College supplied the team with an initial budget of $500 USD. This funding was used to purchase

materials for the prototype (Table 6). In addition, a laptop was provided by the college which served as a

platform for software development and operation of the robot. In searching for additional funds, the team

considered applying for federal and foundational grants. However, after some research into these options,

including a meeting with a grant writer for the Grand Rapids Fire Department, the team decided that

grants would require too large a time investment compared to the likelihood of return. In addition, the

timeline for grant funding would mean that funds would not likely have been available before project

completion.


Figure 21: Work Breakdown Schedul


8 Business Plan

8.1 Marketing Study

8.1.1 Target Market

As mentioned previously, the team developed the idea for this robot based on a need in the first responder

community. Our target market, were this design put into production, would be first responders, including

firefighters, hazardous materials teams, police departments and other rescue organizations. Such

organizations are generally taxpayer-funded, so by providing access to a low-cost alternative, the team

can promote stewardship of the often-limited resources provided to first responders. Because

government-funded rescue organizations often use grant money to purchase equipment, a company

selling rescue equipment would be even more marketable by having several people to assist first

responders in the grant-writing process. Currently, federal grants cannot be used to purchase robots, but

state grants and other grants may still be used.

8.1.2 Competition

There are a number of search and rescue robots available on the market today; a few of those are similar

to the team's chosen design. The first such vehicle is iRobot's 110 FirstLook. This UGV is designed to

be small, portable and rugged - it can be thrown through windows, survive large drops and be fully

submerged. It also contains 4 cameras for 360° vision and can run for 6 hours.6 However, no cost data

were available at the time of this writing, and it is designed more for reconnaissance than search and

rescue as it has no GPS location abilities.

Another robot currently available is the Inuktun VGTV, a tracked surveillance robot capable of changing

the orientation of its body by moving the hubs inside the tracks. This robot is available in two sizes, is

waterproofed up to 100 feet and includes an intuitive joystick control system. Approximate pricing is in

the $35,000 to $45,000 range. The VGTV does not have wireless capabilities - it must be tethered (up to

300 feet).7

The Chaos robot by Autonomous Solutions, discovered after a design had been chosen, is most similar to

the team's design. This robot has 4 independent tracked arms, a camera and wireless operation. In

addition, Chaos is able to carry upwards of 100 pounds of cargo and drive at speeds over 9 feet per

second. This functionality comes at the cost of size, however, as Chaos weighs over 130 pounds, is 9

inches tall, 26 inches wide and 51 inches long with tracks extended.8

6 "110 FirstLook." iRobot. iRobot, 2011. Web. 13 Nov. 2011.

<http://www.irobot.com/gi/filelibrary/pdfs/robots/iRobot_110_FirstLook.pdf>. 7 VGTV. Inuktun Services Ltd, 2011. Web. 13 Nov. 2011. <http://www.inuktun.com/crawler-vehicles/vgtv.html>. 8 "Autonomous Solutions." Chaos. N.p., 2009. Web. 13 Nov. 2011. <http://autonomoussolutions.com/brochure/Chaos.pdf>.


8.2 Development and Production Costs

8.2.1 Prototype Budget

The cost of a single prototype was approximately $570. Table 6 shows the cost, quantity, weight and

vendor of each component, as well as shipping costs.

Table 6: Prototype Bill of Materials

8.2.2 Production Budget

The production cost estimates for production of 1,000 units per year are laid out in Table 7. Also

included is a basic financial analysis for the first three years of operation. The projected selling price of

each robot is approximately $2,750. This is a very low price compared to the other robots the team

encountered. For example, the previously mentioned IGTV robot offered by Inuktun costs between

$35,000 and $45,000. More advanced robots, such as the robot used by the Grand Rapids Police

Department bomb squad, can cost upwards of $250,000.

TEAM 8 RESCUE

Total Cost $570.54

Total Weight (lbs) 11.16

Component Part Number Cost Per Unit Shipping Quantity Weight per Unit (lbs) Total Total (lbs) Vendor

Mechanical Drive motors 276-2177 $19.99 $2.19 4 0.200 $82.15 0.8 VEX

Body metal N/A $0.00 $0.00 1 1.500 $0.00 1.5 Calvin

Tracks 276-2168 $29.99 $2.19 2 0.664 $62.17 1.328 VEX

Axles 276-1149 $8.96 $2.19 1 0.192 $11.15 0.192 VEX

Pivot motors 276-2177 $19.99 $2.19 4 0.250 $82.15 1 VEX

Spur gears 276-2250 $29.99 $2.19 2 0.384 $62.17 0.768 VEX

Pivot bearings Kit8758 $4.95 $10.00 4 0.200 $29.80 0.8 VXB

Aluminum tube N/A $0.00 $0.00 1 0.375 $0.00 0.375 Calvin

Screws, washers N/A $0.00 $0.00 1 0.250 $0.00 0.25 Calvin

Bushings 9440T11 $0.88 $5.00 12 0.050 $15.56 0.6 McMaster

Shaft couplers 276-1843 $4.99 $2.19 1 0.020 $7.18 0.02 VEX

Electrical Camera FS-613B-M166 $62.89 $0.00 1 0.250 $62.89 0.25 Amazon

Battery N/A $0.00 $0.00 1 0.330 $0.00 0.33 Generic

Battery 7.2V 5000 mAh Tenergy $22.99 $5.71 1 1.250 $28.70 1.25 Amazon

Lights with camera $0.00 $0.00 1 0.000 $0.00 0 N/A

Speaker with camera $0.00 $0.00 1 0.000 $0.00 0 N/A

Mic with camera $0.00 $0.00 1 0.000 $0.00 0 N/A

Router High Power N150 $39.82 $0.00 1 0.500 $39.82 0.5 Amazon

Microcontroller N/A $30.00 $0.00 1 0.250 $30.00 0.25 Generic

Power Regulation N/A $10.00 $0.00 1 0.375 $10.00 0.375 Generic

Motor Drivers NCV7702B: 1.0 A Driver $3.56 $0.00 8 0.063 $28.48 0.5 Mouser

6-Pin Headers 649-77311-818-06LF $0.19 $2.76 2 0.01 $3.14 0.02 Mouser

8-Pin Headers 649-68002-208HLF $0.24 $0.00 2 0.01 $0.48 0.02 Mouser

12-Pin Headers 649-68000-412HLF $0.35 $0.00 2 0.01 $0.70 0.02 Mouser

Accelerometer SEN-10955 $9.99 $4.00 1 0.01 $13.99 0.01 Sparkfun

Battery Charger N/A $0.00 $0.00 1 0 $0.00 0 Generic


Table 7: Projected Production Costs

8.3 Possible Future Improvements

While budget was a limiting factor for the features included in the robot, it did not limit the imagination

of the team. As a result, there were a number of ambitious ideas that could not be taken to fruition.

Among these ideas were several improvements to the existing equipment as well as quite a few new

features.

The prototype designed by the team has only one camera, placed at the front of the vehicle. This presents

a problem if the robot gets stuck in a dead end and has to back out. To nullify this, the team originally

planned to have a second camera in the “rear” of the robot to allow reversing direction without driving

blind.

Better yet, the team also had the idea to add a second camera to the front and a pair of cameras to the

back of the vehicle to allow three dimensional viewing by the operator, whether traveling forward or

backward. When the team conferred with representatives of the Grand Rapids Police Department

Component Part Number Vendor Price Quantity Total

Drive motors 276-2177 VEX 19.99$ 4 79.96$

Tracks 276-2168 VEX 29.99$ 2 59.98$

Axles 276-1149 VEX 8.96$ 1 8.96$

Pivot motors 276-2177 VEX 19.99$ 4 79.96$

Spur gears 276-2250 VEX 29.99$ 2 59.98$

Pivot bearings 5905K124 McMaster 7.93$ 4 31.72$

Misc. Screws, washers Generic McMaster 2.00$ 1 2.00$

Body aluminum (5052-H32) P314-5052 MetalsDepot 39.20$ 1 39.20$

Steel tube, plate T258316 MetalsDepot 2.15$ 1 2.15$

Camera FS-613B-M166 Amazon 65.00$ 2 130.00$

Potentiometer Generic Generic 1.00$ 4 4.00$

Battery 10H4/3A3800R2WR Powerizer 39.95$ 2 79.90$

Lights Generic Generic 1.00$ 1 1.00$

Speaker Generic Generic 15.00$ 1 15.00$

Mic Generic Generic 5.00$ 1 5.00$

Router High Power N150 Amazon 35.00$ 1 35.00$

Microcontroller ATMEGA2560 Digi-Key 10.00$ 1 10.00$

Power Regulation LM7805 / LM317 Digi-Key 10.00$ 1 10.00$

Motor Drivers NCV7702B: 1.0 A DriverMouser 3.56$ 4 14.24$

Charging Station CH-UN180 Powerizer 30.95$ 1 30.95$

20.00$

719.01$

40.00$

759.01$

Parts Cost

Shipping

Miscelaneous

Total Cost (per unit)

Mec

han

ical

Elec

tric

al


concerning their current robots’ shortcomings, the officers specifically mentioned this feature, as it is very

difficult for the user to get a sense of distance when operating the robot. As such, even simple depth-

related tasks require several attempts.9

A third improvement for the cameras would be to position them so that they could be panned and tilted.

To this end, the lights on the front of the robot would also have to pan and tilt to provide light wherever

the user looked. This would require both better cameras and additions to the control logic. Cameras

could also be added to the sides, top and bottom of the vehicle (bearing in mind that the top and bottom of

the robot are interchangeable) to convey more information regarding the robot’s surroundings to the user.

The feeds from these cameras would not always be shown but instead would be toggled by the user, to

avoid disorientation from the different views.

Further improvements would involve adding more sensors. The primary candidate for addition would be

a thermal imaging camera, allowing the robot to see surface heat on obstacles to precisely locate a

survivor. In the same vein, a directional microphone could allow the robot to determine the most direct

path to a conscious survivor. To allow more utility in hazardous materials situations, the robot would

have additional sensors for air purity, temperature, pH, radiation, etc. It would be fully water-sealed to

further resist contamination, as well.

The microcontroller could also be modified to monitor the voltage across each arm rotation motor to

determine when the motor has stalled (and by extension, when the arm has made contact with the ground

or an obstacle). These contacts would be communicated to the laptop via the WiFi router on the robot.

The arms would flash a different color when they confirm contact with an obstacle. In addition, the two

processors used by the team would be replaced by a single, more powerful processor with more input and

output pins, which would eliminate the communication delays experienced by the prototype.

Currently all switches and batteries are internal and the cover must be removed to access them. This is

time consuming. In future prototypes there would be shielded switches located on the outside of the body

and ports for removing the battery or hooking the robot itself up for charging.

The original robot design required the robot to be using power directly from the battery whenever it was

active. However, with the addition of an Ethernet port, the robot can be connected directly to a power

source using power over Ethernet. This allows the robot to function tethered without draining the battery,

which would be useful particularly when traveling to or from the launching point so that the battery could

be fully charged when the robot began investigating. The implementation used by the team allows

powering of all electronic components except the camera entirely from an outside power source. The

motors, however, are still battery-powered.

Allowing for the tracks to be tightened to remove slack would be another major change. On the current

prototype the treads bow out a bit which could allow for larger debris to enter into the internal arm. In

addition, having all components machined offsite would significantly decrease the time it would take to

construct the model.

Another obstacle for the current prototype was traction on the treads. The team purchased the current

treads due to lack of time for individual construction. In future prototypes the tracks would be fabricated

9 Maycroft, Michael, and Patrick Merrill. Personal Interview. 7 Oct. 2011.


out of metal instead of plastic to increase the melting temperature and durability. Designing and

fabricating a new track would also allow for the addition of studs to increase the gripping ability.

Motor breaking is a bit of an issue for the current model. If the arms are not straight the weight of the

body causes it to drop back down. Instead of using the current gear system, a worm gear would be

applied. This would eliminate the need for electrical or software solutions.

9 Conclusion

The goal of this project was to design and prototype a low cost robot for first response reconnaissance in

structurally unsound or collapsed buildings and hazardous materials situations. The prototype produced

has a ground speed of 10 inches per second, battery life of approximately 45 minutes, wireless range of

between 50 and 150 feet (depending on conditions), weighs 14.5 pounds and has a high level of mobility.

Based on the tests and performance of the final prototype, and given the budget and time constraint, Team

RESCUE has demonstrated the plausibility of a future RESCUE robot (Figure 22).

Figure 22: Finished Robot with Cover Removed


10 List of Abbreviations

Analog to Digital Converter (ADC)

American Society of Testing and Materials (ASTM)

American Standard Code for Information Interchange (ASCII)

Center for Robot-Assisted Search and Rescue (CRASAR)

Computer Aided Design (CAD)

Field Programmable Gate Array (FPGA)

Global Positioning System (GPS)

Graphical User Interface (GUI)

National Marine Electronics Association (NMEA)

Printed Circuit Board (PCB)

Radio Frequency (RF)

Robot for Extraction of Survivors Confined in Unreachable Environments (RESCUE)

Unmanned Ground Vehicle (UGV)

United States Dollar (USD)


11 Acknowledgements

The team would like to thank the following persons for their assistance with the project:

Bill Fabiano, Andy Nowack and Gary Veldhouse at Grand Rapids Fire Department

Station 6

Ryan Sparks with the Grand Rapids Fire Department

Michael Maycroft and Patrick Merrill of the Grand Rapids Police Department Bomb

Squad

Ron Venneman with Calvin College Campus Safety

Ren Tubergen, Industrial Consultant, at Gumbo Product Development, Inc.

Ned Nielsen, Professor and Advisor, at Calvin College

Phil Jasperse, Metal and Wood Shop Technician, at Calvin College

Bob DeKraker, Technological Assistance, at Calvin College

Friends and family of all members of Team RESCUE for their support


12 Team Design CAD Drawings

RESCUE .........................................................................................................................................37

Gear Box Assembly .......................................................................................................................... 38

Gear Box Front................................................................................................................................. 39

Camera Inner Mount .........................................................................................................................40

Front Camera Cover ......................................................................................................................... 41

Gear Box Side .................................................................................................................................. 42

Lid .................................................................................................................................................. 43

Second Plate Motor Holder ............................................................................................................... 44

Body ................................................................................................................................................ 45

Track Guard Inside ........................................................................................................................... 46

Track Guard Support ........................................................................................................................ 47

Arm Drive Axle (Tube Axle) ............................................................................................................. 48














13 Gearbox Removal Guide

Step 1: Remove four screws on outside of track arm.

Step 2: Remove axle pin and slide axle out.


Step 3: Slide off outside track guard and track/hubs.

Step 4: Remove four screws by drive shaft.


Step 5: Slide track assembly off of drive shaft.

Step 6: Remove spacer from tube axle and unscrew four holding screws.


Step 7: Remove drive shaft pin and pull drive shaft out of gearbox.

Step 8: Push in on bearing to clear the body, then tilt gearbox up and out. Stop at this step if simply

removing gearbox; remember to unplug motors and rotation sensor.


Step 9: Remove gearbox holding screw.

Step 10: Carefully remove gearbox side plate. Note that bushings are free to slide along shafts and wires

are attached to side plate. You may now access any part of the gearbox. When reassembling, complete

steps in reverse order. Remember to include the bronze spacers on gearbox holding screws (3) and drive

shaft.


14 User’s Guide to Controlling the RESCUE Robot

Before you begin, if you wish to customize the controls of the robot, simply edit the appropriate

line in the config.txt file (e.g. moveForwardKey=w to moveForwardKey=j if you wish j to move

the robot forward). While the RESCUE program does support modifier keys (input as, for

example, control shift space), this is not recommended. If any modifier key is released before

the modified key, the key release action will not be performed and the robot will continue to act

as if the key were held.

For purposes of this document, the default keys will be used, as shown below.

Note that all commands are relative to the camera view; that is, the raise and lower commands

will move the arms in the opposite direction when the robot is turned upside down. This means

that the operator does not need to change approaches when the robot is flipped; the button which


moves the camera “up” still moves it “up” relative to the view shown. Before starting the

RESCUE program, ensure that the robot is fully powered and turned on. After a short time, the

“RESCUE Bot” wireless network should be available. Connect to this network using the

password T8RESCUE.

To begin, simply click on the RESCUE.jar file. The program will start up on its own. (If you

wish to see motor messages as they are shown and accelerometer messages as they are received,

start the jar using the command line.)

You will see a screen much like this:

The left half of the screen is used for the view from the camera. This view will automatically

flip upside down if the accelerometer on the robot detects that it is oriented upside down. (If the

camera requests a user and password, enter admin as the user and click OK.)

The upper right section of the screen is used for a display of the robot. This display can be

rotated left and right by the user to obtain a better understanding of the robot’s current

orientation. Other rotations are automatically done by the program and represent the current

orientation of the robot. As well, the legs (shown in green) rotate individually to show their

orientations relative to the robot.


The bottom right corner is reserved for sensor data (in this case, GPS data) and interaction with

the camera. The four buttons shown each have their own uses; hovering over a button displays

its purpose below. From the top left, proceeding clockwise, these buttons are: record stream,

take snapshot of stream, activate speaker to talk through robot, and activate microphone to

receive audio from robot.

Documents

Project Final Report Team 8: R.E.S.C.U - Calvin College Final Report Team 8: R.E.S.C.U.E Robot for Extraction of Survivors Confined in Unreachable Environments ... 1 Introduction to