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
© 2012, Matthew DeVries, Matt Johnson, Paul Lyzenga, Karl Stough and Calvin College
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
i
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
ii
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
iii
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
iv
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
v
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.
May 2012
1
Calvin College, ENGR 339/340
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.
May 2012
2
Calvin College, ENGR 339/340
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.
May 2012
3
Calvin College, ENGR 339/340
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.
May 2012
4
Calvin College, ENGR 339/340
3.2
Locomotion
3.2.1 Alternatives
Table 1: Locomotion Decision Matrix
Aspects
Aspect Weight
Tracks
Legs
Wheels
Wheel on leg
Worm/Screw Wheels
Snake
Cost Versatility Complexity (mech) Complexity (prog) Durability
18
30
15
10
20
3
10
6
7
7
1
7
2
2
2
8
2
10
10
9
4
7
5
7
6
5
3
7
9
8
1
7
2
2
3
Total
93
7.0
3.4
6.8
5.9
5.8
3.6
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 snakestyle 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.
May 2012
5
Calvin College, ENGR 339/340
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 timeconsuming. 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.
May 2012
6
Calvin College, ENGR 339/340
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 onehalf 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
May 2012
7
Calvin College, ENGR 339/340
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
May 2012
8
Calvin College, ENGR 339/340
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>
May 2012
9
Calvin College, ENGR 339/340
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.
May 2012
10
Calvin College, ENGR 339/340
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.
WiFi
Router
Camera
(with speakers)
Ethernet
Ethernet
Power Regulation
7-11 V in, 5 V out
1A typ
Ethernet Shield
SPI bus
GPS
Serial
Arduino
PICAXE
Serial
Digital Out
ADC
i2c
Arm Position
Sensors
Accelerometer
Digital Out
Motor Drivers
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
May 2012
11
Calvin College, ENGR 339/340
Power regulation uses a pair of linear voltage regulators to step down DC voltage from battery levels (711 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.
May 2012
12
Calvin College, ENGR 339/340
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.
May 2012
13
Calvin College, ENGR 339/340
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.
May 2012
14
Calvin College, ENGR 339/340
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
May 2012
15
Calvin College, ENGR 339/340
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).
May 2012
16
Calvin College, ENGR 339/340
Table 2: Gearbox Test Results
Load (Newtons)
Voltage (volts)
Current Draw (amps)
0N
7.2 V
0.18 A
Tested
36 N
7.2 V
0.67 A
20 N
7.2 V
0.36 A
50 N
7.2 V
0.94 A
Extrapolated
100 N
7.2 V
1.98 A
74 N
7.2 V
1.56 A
Current Draw as a Function of Load
1.8
1.6
Current (A)
1.4
1.2
1
0.8
0.6
0.4
y = 0.0189x + 0.0631
R² = 0.966
0.2
0
0
10
20
30
40
50
60
70
80
Load (N @ 1.3 in. offset)
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
Gearbox
Driver no-load current (A)
Post-modification current (A)
Rotator current when lifing arm (A)
Post-modification current (A)
May 2012
FR
0.37
0.35
0.32
-
17
FL
0.25
0.42
0.37
RR
0.25
0.37
-
RL
0.37
0.27
0.48
0.39
Calvin College, ENGR 339/340
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
Coefficent of Friction
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
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
May 2012
18
Calvin College, ENGR 339/340
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-viewdistance 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
Front Track Position (0-90)
Rear Track Position (0-90)
Camera Height
Camera Angle
Ground View Distance (Landscape)
Ground View Distance (Portrait)
5.7
90 Degrees
90 Degrees
11.20 Inches
0.00 Degrees
39.06 Inches
27.72 Inches
+/- 2 inches
+/- 2 inches
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.
May 2012
19
Calvin College, ENGR 339/340
Figure 12: Robot Stair Climbing Test
Figure 13: Robot in Upright Position
May 2012
20
Calvin College, ENGR 339/340
Figure 14: Robot Ramp Climb Test
Figure 15: Robot Back Flip
May 2012
21
Calvin College, ENGR 339/340
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.
May 2012
22
Calvin College, ENGR 339/340
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.
May 2012
23
Calvin College, ENGR 339/340
Figure 18: Arm Position Sensor Setup
Figure 19: Drawing of Arm Position Sensors
May 2012
24
Calvin College, ENGR 339/340
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 Javabased 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,
May 2012
25
Calvin College, ENGR 339/340
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
May 2012
26
Calvin College, ENGR 339/340
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.
May 2012
27
Calvin College, ENGR 339/340
Figure 21: Work Breakdown Schedul
May 2012
28
Calvin College, ENGR 339/340
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>.
May 2012
29
Calvin College, ENGR 339/340
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
TEAM 8 RESCUE
Total Cost
Total Weight (lbs)
Mechanical
Electrical
$570.54
11.16
Component
Drive motors
Body metal
Tracks
Axles
Pivot motors
Spur gears
Pivot bearings
Aluminum tube
Screws, washers
Bushings
Shaft couplers
Part Number
276-2177
N/A
276-2168
276-1149
276-2177
276-2250
Kit8758
N/A
N/A
9440T11
276-1843
Camera
Battery
Battery
Lights
Speaker
Mic
Router
Microcontroller
Power Regulation
Motor Drivers
6-Pin Headers
8-Pin Headers
12-Pin Headers
Accelerometer
Battery Charger
FS-613B-M166
N/A
7.2V 5000 mAh Tenergy
with camera
with camera
with camera
High Power N150
N/A
N/A
NCV7702B: 1.0 A Driver
649-77311-818-06LF
649-68002-208HLF
649-68000-412HLF
SEN-10955
N/A
Cost Per Unit Shipping Quantity Weight per Unit (lbs) Total
Total (lbs) Vendor
$19.99
$2.19
4
0.200
$82.15
0.8 VEX
$0.00
$0.00
1
1.500
$0.00
1.5 Calvin
$29.99
$2.19
2
0.664
$62.17
1.328 VEX
$8.96
$2.19
1
0.192
$11.15
0.192 VEX
$19.99
$2.19
4
0.250
$82.15
1 VEX
$29.99
$2.19
2
0.384
$62.17
0.768 VEX
$4.95
$10.00
4
0.200
$29.80
0.8 VXB
$0.00
$0.00
1
0.375
$0.00
0.375 Calvin
$0.00
$0.00
1
0.250
$0.00
0.25 Calvin
$0.88
$5.00
12
0.050
$15.56
0.6 McMaster
$4.99
$2.19
1
0.020
$7.18
0.02 VEX
$62.89
$0.00
$22.99
$0.00
$0.00
$0.00
$39.82
$30.00
$10.00
$3.56
$0.19
$0.24
$0.35
$9.99
$0.00
$0.00
$0.00
$5.71
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$2.76
$0.00
$0.00
$4.00
$0.00
1
1
1
1
1
1
1
1
1
8
2
2
2
1
1
0.250
0.330
1.250
0.000
0.000
0.000
0.500
0.250
0.375
0.063
0.01
0.01
0.01
0.01
0
$62.89
$0.00
$28.70
$0.00
$0.00
$0.00
$39.82
$30.00
$10.00
$28.48
$3.14
$0.48
$0.70
$13.99
$0.00
0.25 Amazon
0.33 Generic
1.25 Amazon
0 N/A
0 N/A
0 N/A
0.5 Amazon
0.25 Generic
0.375 Generic
0.5 Mouser
0.02 Mouser
0.02 Mouser
0.02 Mouser
0.01 Sparkfun
0 Generic
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.
May 2012
30
Calvin College, ENGR 339/340
Electrical
Mechanical
Table 7: Projected Production Costs
Component
Drive motors
Tracks
Axles
Pivot motors
Spur gears
Pivot bearings
Misc. Screws, washers
Body aluminum (5052-H32)
Steel tube, plate
Camera
Potentiometer
Battery
Lights
Speaker
Mic
Router
Microcontroller
Power Regulation
Motor Drivers
Charging Station
Part Number
Vendor
Price
Quantity Total
276-2177
VEX
$ 19.99
4 $ 79.96
276-2168
VEX
$ 29.99
2 $ 59.98
276-1149
VEX
$
8.96
1 $ 8.96
276-2177
VEX
$ 19.99
4 $ 79.96
276-2250
VEX
$ 29.99
2 $ 59.98
5905K124
McMaster
$
7.93
4 $ 31.72
Generic
McMaster
$
2.00
1 $ 2.00
P314-5052
MetalsDepot $ 39.20
1 $ 39.20
T258316
MetalsDepot $
2.15
1 $ 2.15
FS-613B-M166
Amazon
$ 65.00
2 $ 130.00
Generic
Generic
$
1.00
4 $ 4.00
10H4/3A3800R2WR Powerizer
$ 39.95
2 $ 79.90
Generic
Generic
$
1.00
1 $ 1.00
Generic
Generic
$ 15.00
1 $ 15.00
Generic
Generic
$
5.00
1 $ 5.00
High Power N150 Amazon
$ 35.00
1 $ 35.00
ATMEGA2560
Digi-Key
$ 10.00
1 $ 10.00
LM7805 / LM317
Digi-Key
$ 10.00
1 $ 10.00
NCV7702B: 1.0 A Driver
Mouser
$
3.56
4 $ 14.24
CH-UN180
Powerizer
$ 30.95
1 $ 30.95
Miscelaneous
$ 20.00
Parts Cost
Shipping
Total Cost (per unit)
8.3
$ 719.01
$ 40.00
$ 759.01
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
May 2012
31
Calvin College, ENGR 339/340
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 depthrelated 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.
May 2012
32
Calvin College, ENGR 339/340
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
May 2012
33
Calvin College, ENGR 339/340
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)
May 2012
34
Calvin College, ENGR 339/340
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
May 2012
35
Calvin College, ENGR 339/340
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
May 2012
36
Calvin College, ENGR 339/340
May 2012
37
Calvin College, ENGR 339/340
May 2012
38
Calvin College, ENGR 339/340
May 2012
39
Calvin College, ENGR 339/340
May 2012
40
Calvin College, ENGR 339/340
May 2012
41
Calvin College, ENGR 339/340
May 2012
42
Calvin College, ENGR 339/340
May 2012
43
Calvin College, ENGR 339/340
May 2012
44
Calvin College, ENGR 339/340
May 2012
45
Calvin College, ENGR 339/340
May 2012
46
Calvin College, ENGR 339/340
May 2012
47
Calvin College, ENGR 339/340
May 2012
48
Calvin College, ENGR 339/340
13
Gearbox Removal Guide
Step 1: Remove four screws on outside of track arm.
Step 2: Remove axle pin and slide axle out.
May 2012
49
Calvin College, ENGR 339/340
Step 3: Slide off outside track guard and track/hubs.
Step 4: Remove four screws by drive shaft.
May 2012
50
Calvin College, ENGR 339/340
Step 5: Slide track assembly off of drive shaft.
Step 6: Remove spacer from tube axle and unscrew four holding screws.
May 2012
51
Calvin College, ENGR 339/340
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.
May 2012
52
Calvin College, ENGR 339/340
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.
May 2012
53
Calvin College, ENGR 339/340
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
May 2012
54
Calvin College, ENGR 339/340
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.
May 2012
55
Calvin College, ENGR 339/340
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.
May 2012
56
Calvin College, ENGR 339/340