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
December 2011 i Calvin College, ENGR 339/340
Abstract
In this study, Team RESCUE examines 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 will have independently rotating tracked arms and communicate wirelessly with a controlling laptop. The robot will also have 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 $590 a functioning prototype robot can be constructed. Full-scale production of 1,000 units annually would result in variable production costs of around $760 per unit, to be sold at $2,500 to rescue organizations.
December 2011 ii Calvin College, ENGR 339/340
Table of Contents
1 Introduction to Project and Team ......................................................................................... 2
2 Project Description ................................................................................................................. 2 2.1 Observation of a Need ..............................................................................................................2 2.2 Chosen Design and Reasoning ..................................................................................................2 2.3 Budget/Funding Options ..........................................................................................................3
3.2.2 Chosen Design and Reasoning ..........................................................................................4
3.3 Communication, Control and Power ........................................................................................5 3.3.1 Communication................................................................................................................5
3.3.2 Control ............................................................................................................................6
3.3.3 Power ..............................................................................................................................7
3.4 Additional Features ..................................................................................................................7 3.5 Programming ...........................................................................................................................7
4 Project Management............................................................................................................... 9 4.1 Team Organization ..................................................................................................................9 4.2 Schedule and Tasks ..................................................................................................................9
4.3 Testing and Results ................................................................................................................10
5 Business Plan ......................................................................................................................... 11 5.1 Marketing Study ....................................................................................................................11
5.2 Development and Production Costs ........................................................................................11 5.2.1 Prototype Budget............................................................................................................11
5.2.2 Production Budget ..........................................................................................................12
5.3 Possible Future Improvements ...............................................................................................14
The team is focusing 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 their budget. 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.
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 will be 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.) will be 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.
December 2011 2 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.
Bruce and Matt 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.
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, rugged and easy to operate.
2.2 Chosen Design and Reasoning
The team discussed several possibilities for the main robot design. Initially a snake or worm-style robot was considered for maximum maneuverability in tight spaces. However, this idea was discarded upon discussion with potential users in the police department, since a snake-style robot would be very difficult to control and expensive. In addition, the maneuverability would likely be unnecessary as most buildings
only partially collapse, meaning that there are relatively large gaps through which a robot can pass.2
The decision matrix below in Table 1 shows the breakdown of the team’s selection of track-based locomotion. The “Aspect Weight” row at the top reflects how important the team considered each category, with versatility being most important. Each option was then rated in each category; higher numbers meant that that locomotion was better in the associated category. While each of the other options was viable, none stood up to the decision matrix as well as tracks. A detailed synopsis of each design and its merits can be found in section 3.2(Locomotion). Since tracks achieved the highest score, they were chosen for the final design.
1 Siciliano, Bruno, and Oussama Khatib, eds. Springer Handbook of Robotics. New York: Springer, 2008. 1156-57. Web. 2 Nov.
2011. 2 Maycroft, Michael, and Patrick Merrill. Personal Interview. 7 Oct. 2011.
December 2011 3 Calvin College, ENGR 339/340
Table 1: Locomotion Decision Matrix
2.3 Budget/Funding Options
Calvin College supplied the team with an initial budget of $500 USD. This funding will be used to purchase materials for the prototype (Table 2, page 12). In addition, a laptop was provided by the college which will provide 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 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 be available before project completion.
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. The most common obstacle is stairs, so it must be as small and light as possible but 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 must be able to go under fallen obstacles as well as above them if needed. On a flat surface it should be able to move at approximately 1 mile per hour.
Along with mobility and size constraints , the robot must be water and dust resistant. In any recently collapsed building there will be dust and fine particles. 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 must be able to withstand rinsing. Because of these factors, the robot must 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 must have a port for configurable attachments. One key attachment is a quick release latch that can be used to transport water or other important commodities. Other key attachments include environmental sensing equipment or additional cameras.
In the event that a part is damaged, the robot must be easily dismantled and fixed. None of the components should be so complex that a replacement part is overly expensive or hard to find. Because of this, minimal welding will be used in the construction.
The robot shall be controlled remotely and have a two way audio communication system. The wireless range shall be 150 feet. The robot will have a camera and microphone for detection of persons trapped or injured, as well as a speaker so that the controller 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.
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
December 2011 4 Calvin College, ENGR 339/340
It is vital that once a person is discovered the robot can be located. To this end, a global positioning system (GPS) unit will be included on the robot. For control purposes, as the operator is maneuvering the robot the orientation and status of the robot shall be displayed on the control screen.
3.2 Locomotion
3.2.1 Alternatives
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, page 3) 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 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. This design would allow the robot greater mobility than simple wheels and more traction than a wheel on an arm.
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.
3 The chosen style of tracks was the most cost-effective style available.
3 Siciliano, Bruno, and Oussama Khatib, eds. Springer Handbook of Robotics. New York: Springer, 2008. 1158. Web. 2 Nov. 2011.
December 2011 5 Calvin College, ENGR 339/340
Figure 1: Gearing and Drive Assembly for Track Arm
Each track is driven directly by an electric motor, producing a final ground speed of approximately one foot per second. Each track arm is controlled by a separate electric motor coupled with a gear reduction train of Rd = 9:1 (Figure 1), to deliver an arm rotation rate of eleven revolutions per minute and a torque (T) of 5.4 foot-pounds under normal operating conditions (A = 1.2 amps) with a 20% loss due to friction (ε). The motors used 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 collectively lift the entire robot, which will weigh approximately ten pounds. The chosen motors have the necessary torque (with the gear train) at 7.2 volts when drawing 1.2 amps under a worst-case scenario. 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 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 for the initial prototype. 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 battery life would not be an issue. Communication between controller and robot would be more reliable and less susceptible to interference. The tether could
December 2011 6 Calvin College, ENGR 339/340
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. Us ing 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), 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 is to 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 means that video communications can bypass the microcontroller 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 will be used to keep costs down. The specific router used, “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 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.
4 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 should, 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.
5 In
addition, the development cycle could be delayed by the additional complexity of designing a processor using this FPGA.
A third option is 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 are 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 will then receive all information from different devices and display it to the operator. Using a WiFi router allows for future improvements as discussed in section 5.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 simultaneously. A tethered cable can provide continuous power for extended runtimes; the disadvantages to using a tether are discussed in 3.3. Another option is to use a rechargeable battery, which allows for freedom of movement but restricts runtime.
For this design, it was decided that a wireless system was more important than longer runtime. In addition, this design permits the option to switch over to tethered mode without heavy modification. This is discussed in section 5.3 (Possible Future Improvements). Because the project requires at least 1 hour of runtime an appropriately sized battery was chosen. The capacity of the battery is approximately 4000 milliamp-hours at 12 volts, which is expected to handle all expected current draws.
3.4 Additional Features
The robot will have 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 will be used to save space and money through component consolidation. In addit ion, a quick release hook will be designed and implemented to allow different attachments for various needs. The robot will also have an attachment point for environmental measurement sensors to detect hazards such as oxygen and other hazardous materials.
For location and position determination, the robot will be fitted with GPS to show the position of the robot a well as the orientation of the arms. In the event that the robot is flipped upside down, the operator will be able to correct camera view and control orientation to compensate.
3.5 Programming
The programming aspect of this project will be divided between two primary elements: the microcontrollers inside the robot, and the laptop used by the operator. Each has a primary purpose
December 2011 8 Calvin College, ENGR 339/340
reflected by its programming: the laptop displays to the user the current camera video images and robot status and handles its side of audio input and output, while the microcontroller communicates the laptop commands to the motors and sends the output of the sensors back to the laptop.
The robot will contain an Arduino connected to a slave microcontroller to boost its number of output pins. This is an arrangement of convenience, since the team already had the necessary parts available; a production model of this robot would s imply have a microcontroller with more pins to control. The microcontroller will take input from the position sensors on the robot and preprocess the readings, converting them to American Standard Code for Information Interchange (ASCII) values. This will allow for easier debugging in case of software problems. The microcontroller will also 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 will be communicated to the laptop as well via the WiFi router on the robot.
The laptop itself will run a Java user interface. The team chose the Java programming language because of its cross-platform nature; it works on all major operating systems. The user interface itself will simply display 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 will be shown using a small wireframe model of the robot with the arms in the current positions. The arms will flash a different color when they confirm contact with an obstacle. For audio input and output, the program will use the controlling laptop’s default speakers and microphone. A rudimentary mockup of the interface is shown below in Figure 2.
Figure 2: Interface Mockup Displayed on Laptop to User
December 2011 9 Calvin College, ENGR 339/340
4 Project Management
4.1 Team Organization
The team divided first according to concentration: the mechanical engineers (Bruce and Matt) would take care of the mechanical aspects of the design – shape, locomotion, etc. – while the electrical engineers would take 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, handles CAD modeling and robot construction. Matt likewise manages calculations and is the primary researcher for the team. The two collaborate to ensure that they have the same vision for the mechanical design. On the electrical side, Karl, who has spent a great deal of time working with microcontrollers, performs the hardware design and the microcontroller programming. Paul similarly designs the software for the controller and the user interface. The two together handle the communication between the robot and computer and the overall electrical design of the project. The team as a whole regularly discusses the interaction between mechanical and electrical systems, particularly any needs regarding space and sensors.
4.2 Schedule and Tasks
4.2.1 Anticipated Tasks
The team anticipates creating a finalized prototype by the end of April 2012. To meet this goal, it is imperative that the team strictly follow a fixed schedule to eliminate setbacks. To finish the prototype the team will have to complete construction, testing and modification in a timely manner.
Before the end of January 2012 the team will have completed the design of the robot and have started construction. Construction of the robot is expected to take approximately one month. After the robot has been constructed it will have to be programmed. This will begin before the end of February 2012. During the programming stage the robot will also be tested.
Programming and testing is expected to last more than one month, after which the team will assess the design, note areas of improvement and add additional features. If time and budget permit, a second prototype will be constructed at this time. Additional features to be fully explored and possibly implemented are detailed in section 5.3 (Possible Future Improvements).
One of the final tasks of the project is to compile a final report. Generation of this report will begin after the prototype is working and will coincide with the addition of features.
4.2.2 Scheduling
A finalized design is scheduled to be completed no later than January 21. At this time the team will have a completed CAD model as well as a working electrical diagram. From these plans the team will begin construction of the robot before the end of January. Construction will include the physical assembly of the housing, tracks, drive system and mounts, and the fabrication and population of circuit boards. Construction and assembly of the robot is expected to last approximately one month. Final assembly will be completed before mid-February.
After the construction of the design is finished, the electrical team will complete development of software for the robot as well as the user interface which will be used on the laptop. Software development is expected to last more than one month but can occur concurrently with construction of the prototype.
The testing stage will begin as soon as the robot is fully functional. Testing will include both a hardware analysis as well as a software functionality analysis. The details of testing are covered in the next section. Testing is scheduled to last less than one month and will lead straight into prototype modification.
December 2011 10 Calvin College, ENGR 339/340
The prototype should be fully functional, but may be lacking some features. Beginning in the middle of March, the prototype will be modified and additional features will be implemented. If time and budget permit, a second prototype will be constructed during this stage. In addition, the prototype may have some flaws that will be addressed and fixed during this stage. Modification and addition of features is expected to last less than one month and will be completed before April 10.
Once the prototype has been modified accordingly, the team will finalize the design and fix any remaining performance issues. The graphical user interface (GUI) may be polished to make it aesthetically pleasing and the robot itself will be cleaned up. The team should be able to finalize the design in less than 1 month, but the additional time will serve as a buffer in case other stages are delayed. The design will be ready for exhibition before April 30.
4.3 Testing and Results
Testing will comprise both electrical and physical tests to ensure the robot performs as desired. The team shall perform tests to verify the design goals regarding battery runt ime, wireless range, physical mobility and environmental resistance.
To test runtime, the robot shall drive across a level surface at full speed until the battery is depleted. The robot should be able to perform this task for at least forty-five minutes. Another test to assess battery performance will be a stationary test. In this test the robot shall be powered on with all electronic systems active. The robot will remain stationary until the battery is depleted. It is expected that the electronics will remain powered for more than 2 hours during this test. It is assumed that under normal operating conditions the robot will be performing a combination of mobile and stationary operation for a total mission time of approximately 1 hour.
Wireless range will be tested by driving the robot until the operator can no longer effectively control the robot. The test shall consist of both a line of sight test in an open area and an interference range test. Final range shall be the distance from the operator to the robot when the video stream becomes unusable and/or movement becomes unpredictable. The robot is expected to have a range of at least 150 feet in the line of sight test. The actual range with interference from walls and other obstacles is unknown but should be at least 100 feet.
The robot is also designed to climb stairs and traverse other rubble. To test this, the team shall attempt to drive the robot up a flight of stairs. Ideally, the robot will align itself with the stairs and drive straight up without additional repositioning. To be a successful test, the robot will have both climbed and descended the stairs under its own power.
Environmental resistance shall be tested by spraying the robot with water. For the test to be successful the robot must not only operate after contact but must also be completely dry inside the housing. Any moisture inside the housing signifies a leak that may become a major problem if the robot is to be used in an environment with hazardous materials.
December 2011 11 Calvin College, ENGR 339/340
5 Business Plan
5.1 Marketing Study
5.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.
5.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
5.2 Development and Production Costs
5.2.1 Prototype Budget
The cost of a single prototype is expected to be about $590. Table 2 shows the cost, quantity, weight and vendor of each component, as well as shipping costs.
The production cost estimates for production of 1,000 units per year are laid out in Table 3. Also included are a basic financial analysis for the first three years of operation. The projected selling price of each robot is approximately $2,500. 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 $588.35 Already Spent $0.00
Total Weight (lbs) 9.59
Component Part Number Cost Per Unit Shipping Quantity Weight per Unit (lbs) Total Total (lbs) Vendor
Marketing General Annual 10,000$ Website/publications
Sales Repairs/Maintenance† Variable 20,000$ Support, Grant Assistance
Production Yearly Part Cost Variable 759,005$ Machining, Assembly, Shipping
Maintenance 25,000$
Building Initial Machinery One-time 1,000,000$
Rent Annual 150,000$
Utilities Annual 10,000$
December 2011 14 Calvin College, ENGR 339/340
5.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.
††Labor Costs
Type Salary Quantity Sector Cost *Sales includes commission
Engineering 70,000$ 1 70,000$ Unit invoice cost 2,500$
Other Expense 25,000$ 950,030$ 25,000$ 1,035,720$ 25,000$ 1,004,065$
Operating Income (50,030)$ 44,280$ 195,935$
Interest Expense (10%) 63,640$ 29,838$ 25,201$
Profit Before Tax (113,670)$ 14,442$ 170,734$
Income Tax (40%) -$ 5,777$ 30,900$
Net Income (113,670)$ 8,665$ 139,834$
December 2011 15 Calvin College, ENGR 339/340
Better yet, the team also had the idea to add a second camera to the front and 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 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 nontrivial additions to the control logic.
Further viewing 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.
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.
One of the weaknesses of the current robot design is orientation: the user does not have any way to determine which way is down with respect to the robot. This could be solved with the addition of an accelerometer, preferably located in the center of the vehicle. This would allow the user interface to display the robot model tilted appropriately.
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 current robot design requires the robot to be using power directly from the battery whenever it is active. However, with the addition of an Ethernet port, the robot could be connected directly to a power source using power over Ethernet. This would allow 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. This could be implemented in the current design without major modifications.
9 Maycroft, Michael, and Patrick Merrill. Personal Interview. 7 Oct. 2011.
December 2011 16 Calvin College, ENGR 339/340
6 Conclusion The goal of this project is to design a low cost robot for first response reconnaissance in structurally unsound or collapsed buildings and hazardous materials situations. Given the budget and time constraint Team RESCUE has successfully shown the feasibility of the RESCUE robot and is working diligently and on schedule toward final design and prototype production.
December 2011 17 Calvin College, ENGR 339/340
7 List of Abbreviations 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)
Printed Circuit Board (PCB)
Radio Frequency (RF)
Robot for Extraction of Survivors Confined in Unreachable Environments (RESCUE)
Unmanned Ground Vehicle (UGV)
December 2011 18 Calvin College, ENGR 339/340
8 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 Security
Matt Weeda at Innotec Group
Ren Tubergen at Gumbo Product Development, Inc.
Ned Nielsen, Professor and Advisor, at Calvin College
