Sunteți pe pagina 1din 62

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

and Computer Engineer) ENGR 339/340 Senior Design Project May 2012 © 2012, Matthew DeVries, Matt Johnson,

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.

Table of Contents

1 Introduction to Project and Team

2

2 Project Description

3

2.1Observation of a Need

3

3 Design Description

4

3.1Requirements and Criteria

4

3.2Locomotion

5

3.2.1 Alternatives

5

3.2.2 Chosen Design and Reasoning

6

3.3Communication, Control and Power

7

3.3.1 Communication

7

3.3.2 Control

8

3.3.3 Power

9

3.4Additional Features

10

4 System Overview

10

4.1Mechanical Architecture

10

4.2Electrical Architecture

11

5 Testing

15

5.1Initial Wireless Range Test

15

5.2Gearbox Test

16

5.3Motor Current Test

17

5.4Track Friction Test

18

5.5Battery Test

18

5.6Field of View Test

19

5.7Runtime Test

19

5.8Second Wireless Range Test

19

5.9Versatility Tests

19

6 Construction and Design Modifications

22

6.1Mechanical Design Modifications

22

6.1.1 Bearing Support

22

6.1.2 Bushings

23

6.2Electrical 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

6.2.5

User Interface

25

6.3Robot Component Layout

7 Project Management

25

27

7.1Team Organization

27

7.2Schedule

27

7.3Budget/Funding Options

27

8 Business Plan

29

8.1Marketing Study

29

8.1.1 Target Market

29

8.1.2 Competition

29

8.2Development and Production Costs

30

8.2.1 Prototype Budget

30

8.2.2 Production Budget

30

8.3Possible 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

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

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

Design Norms

The team is focused on 3 engineering design norms throughout this project: stewardship, trust and transparency. Stewardship of taxpayers' money was a primary focus as the team attempted to reduce the overall cost of the robot. Due to the current economic conditions, first responders have very limited funds, and those funds are provided by taxpayers, corporations and individuals through municipal budgets and grants. By reducing the cost of the robot, the team hopes to allow even the most resource-challenged departments to purchase a robot which can reduce risk to human life while helping to save others.

Because of the time-sensitive and life-or-death situations in which the robot will be used, the team has designed the vehicle to be trustworthy. As such, it is reliable enough that its effectiveness will not be questioned and durable enough to assist in a broad spectrum of situations.

In the interests of transparency, all text-based communication (sensor information, voltage levels, etc.) are transmitted using American Standard Code for Information Interchange (ASCII) values, the standard encoding type for character transmission. While ASCII characters are less compact and therefore take up more bandwidth, they allow more transparency since the numbers are transmitted in a well-documented, human-readable form. In addition, the construction of the robot allows for users to easily troubleshoot issues that may arise, while the software is designed for reasonable ease of use. Finally, the team provides this report which includes design decisions, technical calculations and drawings documenting the procedure the team followed.

1

Introduction to Project and Team

Team 8 consists of two mechanical engineers, Matthew “Bruce” DeVries and Matt Johnson, and two electrical engineers, Paul Lyzenga and Karl Stough, who chose as a group to design and build a robot for locating survivors from partially collapsed buildings. This team, Team RESCUE Robot for Extraction of Survivors Confined in Unreachable Environments chose the project in light of the recent ten-year anniversary of the September 11 terrorist attacks, recognizing that robotic search and rescue units are invaluable in situations like those or natural disasters. The project grew in scope as the group met with police and fire departments to determine what needs could be met by a robot of this type.

Matt is a senior engineering student concentrating in mechanical engineering. Matt grew up in nearby Hudsonville, MI and enjoys tennis, cycling, building with Legos and occasionally some programming as well. Matt has worked with laser cutting and etching as an intern for Innotec Group in Zeeland, MI and with automated guided vehicles as a field technician for Egemin Automation (based in Holland, MI but stationed in North Carolina). Matt will be joining the Koops Factory Automation team as a Mechanical Design Engineer following graduation.

Matthew DeVries is the second mechanical engineer of Team RESCUE. Hailing from Andover, MN, he has always enjoyed the physical stuff that makes everything work, from toasters to VCRs; nothing was thrown out without having been thoroughly dismantled. With increasingly complex mechanical hobbies, engineering was a natural choice. Matthew has accepted an engineering position at Honda R&D Americas in Marysville, OH and will be designing wiring harnesses for new Honda automobiles.

Born in Grand Rapids but raised further south, Paul is an electrical engineering student, inspired by the example of his older brother. His interests within the field tend toward the digital realm and software development. He has accepted an offer for a position in which he can practice those skills from the company where he has interned for the past year and a half: Apex Controls, in Hudsonville, MI.

Karl’s interest in electronics started a few years before Calvin with microcontrollers and simple electronic circuits. He enjoys working on digital logic circuits as well as computer science programming projects. Karl is from the Aurora area in Illinois and plans to return to Illinois after graduation. He will continue to work at Alcatel-Lucent following the internship that started summer of 2011.

Matt and Bruce share a fascination with robots, which was a significant factor in the team’s choice of project. Likewise, Paul and Karl have a common interest in digital systems. This project allows all four team members to pursue their passions while creating a product with practical applications, which makes this project a good choice for senior design.

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

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

2 Project Description

2.1 Observation of a Need

The need for a widely available, cost-effective search and rescue robot became increasingly evident following the terrorist attacks in the United States on September 11, 2001. This was the first true deployment of robots for search and rescue operations. Since that time, robots have been used in various disaster and hazardous materials situations with varying degrees of success; however, the number of first responders with access to a basic search and rescue or reconnaissance robot (excluding bomb squad robots) is minimal at best. Currently, the Center for Robot-Assisted Search and Rescue (CRASAR) is the main source of such robots, and precious time is used in simply transporting the machines to the disaster site. 1 Thus, the team decided to design and prototype a man-portable unmanned ground vehicle (UGV) which would be low-cost, reliable and easy to operate.

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

2011.

3

Design Description

3.1 Requirements and Criteria

For the RESCUE robot, size is one of the main constraints. The robot needs to be small and light enough to get into places inaccessible by humans. However, the robot must be able to surmount obstacles commonly found in disaster areas. The most common obstacle is stairs, so it shall be as small and light as possible to remain portable, but shall also be large enough to climb stairs. Length is a key factor in stair climbing because, for speed and stability, the robot must contact at least two stair edges at all times. The robot shall be able to go under fallen obstacles as well as above them if needed. On a flat surface it shall be able to move at approximately 1 mile per hour.

Along with mobility and size constraints, the robot shall be water and dust resistant. In any recently collapsed building there will be dust and fine particles that could interfere with the operation of the robot. There may also be broken pipes and puddles of water. It is important that this environment does not cause the robot to fail. In the event of a hazmat situation the robot will need to be cleaned after use and shall be able to withstand rinsing. Because of these factors, the robot shall be sealed with all of its electronics and gear boxes located inside the body to ensure protection from the elements.

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

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

other important commodities. 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.

Other potential attachments include environmental sensing equipment or

attachments.

It is vital that once a person is discovered the robot can be located. The orientation and status of the robot shall be displayed on the control screen that is, the pitch and yaw of the robot will be shown, as well as the relative pitch of each arm.

3.2

Locomotion

3.2.1 Alternatives

Table 1: Locomotion Decision Matrix

Aspects Aspect Weight Tracks Legs Wheels Worm/Screw Wheels Snake Cost 18 Versatility 30 10 7

Aspects

Aspect Weight

Tracks

Legs

Wheels

Worm/Screw Wheels

Snake

Cost

18

Versatility

30

10

7

3

7

Complexity (mech)

15

Complexity (prog)

10

Durability

20

Total

93

3

2

10

10

9

6.8

7

5

7

6

5.9

2 10 10 9 6.8 7 5 7 6 5.9

6

2

7

2

7

2

9

2

7

7.0

1

5

1

2

8

3

3.4

5.8

3.6

 

8

Wheel on leg

4

6 2 7 2 7 2 9 2 7 7.0 1 5 1 2 8 3
6 2 7 2 7 2 9 2 7 7.0 1 5 1 2 8 3
6 2 7 2 7 2 9 2 7 7.0 1 5 1 2 8 3

The most basic problem facing UGVs is mobility, and the choice of locomotion affects the structure of the entire robot. To meet the stated requirements, the vehicle must have a flexible drive system which can adapt to the myriad of conditions and obstacles possible in collapse scenarios, while remaining simple and reliable enough for search and rescue work.

The team considered many options (Table 1) when designing the robot, the first of which was a snake- style motion using joints which would expand and retract. This option would provide exceptional maneuverability in a relatively small package. The addition of modular sensors and payloads would lead to increased mission flexibility. However, the speed of a snake-style robot is quite limited, and the mechanical complexities would mean a cost far greater than the allotted budget.

A second locomotion option was a hexapod design with insect-like legs. Legs are most easily adapted to the uneven terrain found in building collapses. However, each leg would require at least 2 joints and 3 degrees of freedom, which greatly increases complexity, both physical and programmatic, as well as cost. This increased complexity also decreases reliability and durability, which were two factors the team considered very important. With a minimum of four legs required for stability, the team decided that insect-like locomotion would be too complex, too costly and too fragile.

A more novel third option involved rotating screws placed on the outside of the robot. When spinning in opposite directions, they would propel the vehicle forward through almost any terrain. These screws (similar to a back-driven worm) provide lots of traction and would work in water. Unfortunately, the screw system cannot climb stairs, thus failing one of the team's key design criteria.

Large wheels were briefly considered as a fourth type of locomotion. Wheels would be the simplest, cheapest and most reliable option, as they require fewer motors and fewer moving parts. However, the mobility of a simple wheeled vehicle is severely limited, and a small wheeled robot would not be able to climb stairs. Placing a wheel at the end of a freely rotating arm would solve the stair-climbing problem, but there would be no traction along the length of the arm.

Using tracks on the arm instead of a wheel was the final option. Tracks supply traction along the entire arm without an increase in complexity over wheels on the end of rotating arms. This design would allow the robot greater mobility than simple wheels and more traction than a wheel on an arm.

3.2.2 Chosen Design and Reasoning

The tracked system utilizing four tracks on independent, rotating arms was chosen for this project. With this design, the vehicle can climb stairs, lift itself off the ground to clear obstacles, and travel through muddy terrain. The arms can be used to pull the vehicle forward should it become stuck, yet it will still be operable even if flipped over. Each track assembly is 1.5 inches wide and 10 inches long axle-to-axle. The height of each track is 2.375 inches while the body of the robot is only 2 inches thick, so the robot can run on just the track hubs over flat surfaces. Each track has a side shield to minimize the risk of becoming de-tracked, a crippling problem that has been an issue for tracked vehicles in previous applications. 2 The team looked into building its own tracks, but this proved too expensive and time- consuming. Thus, a couple of tread kits were purchased and implemented instead. The diameter of the track hubs provided a target overall height for the robot body of two inches.

a target overall height for the robot body of two inches. Figure 2: Gearing and Drive

Figure 2: Gearing and Drive Assembly for Track Arm

Each track is driven directly by an electric motor, producing a final ground speed of approximately ten inches per second with a fully charged battery. A myriad of motors were considered in the design process. Motors with enough torque (usually through an attached gearbox) were too large, while smaller motors with higher revolutions per minute (RPM) would require custom gear reductions (Figure 2). The final choice involved using eight VEX 7.2 volt, 100 RPM motors: four driving the tracks themselves, and four rotating the arms.

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

2011.

Figure 3: VEX Motor Power Curve These motors fit the size (~1 inch thick) and

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 R d = 9:1, to deliver an arm rotation rate of ten revolutions per minute and a torque (T) of 3.3 foot-pounds under normal operating conditions (A = 1.6 amps out of 3.6 max, Figure 3) with a 40% loss due to friction (ε). The motors have a rated speed of ω = 100 revolutions per minute running at V = 7.2 volts (Equation 1.1).

(

)

(

)

(1.1)

This allows two arms to easily lift their half of the robot body, which weighs approximately eleven pounds (the entire robot with arms weighs 14.5 pounds). The chosen motors have the necessary torque (with the gear train) at 7.2 volts when drawing 1.6 amps. The gears used in the reduction train are one- half inch wide to reduce stress on the individual teeth and have holes allowing connection of the rotation axle tube to the larger gear. Also, all electronic components remain inside the vehicle, making this design very water and dust resistant.

3.3 Communication, Control and Power

3.3.1 Communication

3.3.1.1. Alternatives

It will likely be

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

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

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

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

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

The first option was to use a cable tethered to the robot at all times to provide power, communication and other functions such as a fresh water supply. Using a tethering cable from the base station to the robot meant that a battery would not be needed and operating time would not be an issue. Communication between controller and robot would be more reliable and less susceptible to interference. The tether could potentially create problems by snagging on corners of objects or tangling in steel debris. A tether would also have to be stored either on the robot or near the operator. The friction from pulling the cable could prove overwhelming for a robot of this size.

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

station. The popularity of this technology with consumers means that the cost is kept lower than other possible wireless solutions. Using a WiFi router in conjunction with a laptop computer eliminates the need for a dedicated transceiver pair. WiFi will also provide sufficient bandwidth for video streams from the robot provided the signal is free of interference. Disadvantages of using a WiFi router would include the limited wireless range that it may provide (approximately 150 feet line of sight), especially through solid walls.

The final option would be to use a dedicated RF transceiver pair for all communications. This method could be designed to provide sufficient bandwidth at very long ranges (up to 1 mile). It could be designed with more transmission power than a typical WiFi router to maintain the signal to the robot through interference such as walls and debris. The disadvantage to using such a system is that it can be expensive.

3.3.1.2. Chosen Design and Reasoning

Of these three options it was decided that a simple WiFi router would be used in the prototype. This was done primarily because of its low cost, wireless capability and ease of implementation with other systems. Using a router as the primary path of communication also meant that video communications could bypass the motor controller entirely. In a production design, the robot could have a more powerful and dedicated RF transceiver pair or a more powerful WiFi router. For this prototype, however, a simple commercial router was used to keep costs down. The specific router, a Buffalo Technology High Power N150, was chosen for its greater signal strength and low price. Also see section 3.3.2 (Control) for more justification for using a WiFi router.

3.3.2 Control

3.3.2.1. Alternatives

Control of the robot would be done via one of several methods which could include a dedicated microcontroller or a processor programmed onto a field programmable gate array (FPGA). Another alternative is to construct a simple computer running an operating system, such as Linux.

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

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

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

microcontroller for final production would be less than $10. 3 The disadvantage of a microcontroller is that cheaper processors may not be able to transmit video streams and audio to and from the operator. It would, however, be able to handle all other sensors and motors including accelerometers, GPS and temperature sensors.

An FPGA such as the Cyclone II would be more flexible to work with and could be designed to handle all the needed functions, but is often more expensive than a microcontroller. The Altera DE2 development board possesses a video input, network capability and audio connections on a single board. The main problem with a dedicated FPGA is the high cost per chip. The cost of the FPGA used in the DE2 board (Cyclone II EP2C35F672C6N) is $150 per unit, not including the external memory or other parts. 4 In addition, the development cycle could be delayed by the additional complexity of designing a processor using this FPGA.

A third option was to construct a miniature computer capable of running a Linux operating system to handle all peripherals attached to the robot. An advantage of using an operating system is that drivers are available for hardware such as cameras, speakers, microphones and network adapters, making development easier. The computer could be made powerful enough to process all sensor information including cameras and voice communication. Much like the FPGA, this approach would be expensive. Interface between this computer and the motors and low level sensors may require an additional microcontroller which would add to the cost. This complicated system also has the potential to draw much more power than alternative designs, an undesirable attribute for a battery powered system.

3.3.2.2. Chosen Design and Reasoning

For the preliminary prototype an Arduino microcontroller was chosen. This was done because of the availability of the microcontroller (Arduino Uno with Ethernet connection already owned) and for its simplicity of use. A more refined prototype would contain a more powerful microprocessor, such as an AVR or ARM based microcontroller, on a custom printed circuit board. Other alternatives are far more expensive and more complex.

This choice of controller also influenced the choice of communication device. If a WiFi router is used, camera images can be sent directly through the router to the operator's laptop without involving the microcontroller. This removes a large responsibility from the microcontroller and allows the use of a much cheaper device. The software on the laptop then receives all information from different devices and displays it to the operator. Using a WiFi router allows for future improvements as discussed in section

8.3 (Possible Future Improvements).

3.3.3 Power

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

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

3 ATMEGA2560, $10.032 per unit at 100 units,

<http://search.digikey.com/us/en/products/ATMEGA2560-16AU/ATMEGA2560-16AU-ND/735455>

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

runtimes; the disadvantages to using a tether are discussed in 3.3.1 (Communication). Another option was to use a rechargeable battery, which allows for freedom of movement but restricts runtime.

For this design, it was decided that the versatility of a wireless system was more important than longer runtime. In addition, this design permitted the option to switch over to tethered mode without heavy modification. This is discussed in section 8.3 (Possible Future Improvements). As explained in section 6.2.1 (Batteries), two appropriately-sized batteries were chosen due to current draw constraints.

3.4 Additional Features

The robot has additional features to assist in search and rescue applications, including cameras, audio systems and sensors. A single optical camera containing both a speaker and microphone was used to save space and money through component consolidation. In addition, the robot has an attachment point for custom sensors to detect hazards such as oxygen and other hazardous materials.

For location and position determination, the robot was fitted with an accelerometer, arm orientation sensors and a GPS to show the position and orientation of the robot as well as the orientation of the arms. In the event that the robot is flipped upside down, the software on the laptop automatically correct camera view and control orientation so that the operator may continue to operate the robot normally.

4 System Overview

4.1 Mechanical Architecture

The majority of the structure of the RESCUE Robot is made out of machined aluminum. One of the design goals was that the robot be light for ease of transportation and so that the arms would be able to lift the body. The estimated weight of the body at the beginning of the design process was ten pounds. This weight included all internal mechanical components and circuitry but not the arms themselves. This estimated weight was then used in calculating the torque that the motor would need to produce. After searching for and finding a suitable motor for the arm rotation, a gear box was designed to ensure the final torque was sufficient. The robot has four gearboxes, each of which controls one arm. Each gearbox has two motors, one for arm rotation and one for track motion, for a total of eight motors inside the robot.

Autodesk Inventor was the primary program used for designing and modeling the prototype. This allowed for a complete visualization of the robot and could be used to demonstrate its functionality to others not involved directly in the project. Through this process the team was able to foresee potential assembly problems and allowed for the mechanical team members to give the electrical members an accurate idea of the space that they would have to work with inside the body for electrical components.

The first component to be machined and assembled was a gear box. Ensuring that the motor would be able to produce the proper amount of torque was critical. The test can be read about in 5.2 (Gearbox Test). After having passed the test, the rest of the aluminum components were laser cut and the body was cut and folded by the team’s industrial consultant. Once the parts were received the final geometries were machined in, holes were cleaned up and true assembly began. All other parts needed were either purchased or made in the metal shop using a mill, lathe or drill press or any combination thereof.

4.2

Electrical Architecture

The electrical system is designed to provide the interface between the operator and the robot. It provides the means to stream video and sensor data from the robot back to the operator as well as provide a means to relay instructions from the user to the locomotion system. The system is centered around a WiFi router which provides the wireless connection between the robot and laptop. An EasyN FS-613B-M166 Ethernet camera is attached to a Buffalo Technology WHR-HP-GN router to provide both a video stream to the operator as well as a two-way audio stream between the robot and the operator.

The Arduino microcontroller is attached to an Ethernet shield to interface with the router. Connected to the Arduino is the accelerometer, GPS and a PICAXE microcontroller. The PICAXE is used solely for additional output pins as the Arduino used by the team does not have sufficient outputs to control all devices and motors. It should be noted that in a production design, there would be a single AVR microcontroller. The choice to use two microcontrollers was made because of budget restrictions and availability of parts from team members. An overview of the electrical system is shown in Figure 4.

W iFi Camera Router Ethernet (with speakers) Ethernet Power Regulation Ethernet Shield 7-11 V in,
W iFi
Camera
Router
Ethernet
(with speakers)
Ethernet
Power Regulation
Ethernet Shield
7-11 V in, 5 V out
1A typ
SPI
bus
Serial
GPS
Arduino
Serial
PICAXE
Digital Out
Digital Out
ADC
i2c
Motor Drivers
Arm Position
Accelerometer
Sensors
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 Electronics 5 . 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

Power regulation uses a pair of linear voltage regulators to step down DC voltage from battery levels (7- 11 volts) and outputs a steady 5 volts for the router and camera. Current draw for the router and camera are approximately 0.5 amps each. The Arduino has a built-in voltage regulator that regulates power for itself and the PICAXE microcontroller, which combined draw 0.5 amps as well.

The Printed Circuit Board (PCB) used in the robot was designed using dedicated CAD software and all traces were routed by hand. This board provides the interface between the Arduino, arm position sensors, accelerometer, PICAXE, GPS and all eight motor drivers. The final board layout is shown in Figure 5. The team manufactured the board in Calvin’s electronics lab, populated it and then tested the connections. A single trace was found to be missing in the final board and was fixed with a small jumper.

in the final board and was fixed with a small jumper. Figure 5: Main Controller Board

Figure 5: Main Controller Board Layout

The Java user interface and control program, running on the laptop, is used primarily to accept input from and present information to the end user. A block diagram of the program can be seen below in Figure 6. The central control of the program communicates with the Native Swing web browser to present the camera feed to the user, as well as the camera controls (record, talk, listen, snapshot). As well, at regular intervals the program sends messages to the microcontroller via the PrintWriter; each message which either requests data, such as the current GPS location or device orientation, or sends a command to activate or deactivate motors. The responses of these commands are then received by the BufferedReader. The reader passes along the message to a function which forwards relevant information to the appropriate parser. The parser then updates the rest of the program as appropriate. The final important component is the Java3D canvas which contains a wireframe model of the robot. This model is updated whenever new information on the orientation of the robot or the positions of the arms is received.

Figure 6: Software Block Diagram The team chose the Java programming language because of its

Figure 6: Software Block Diagram

The team chose the Java programming language because of its cross-platform nature - it works on all major operating systems. The user interface itself simply displays the output from the robot’s camera, as well as information on the location of the robot and the status of the arms. To facilitate an intuitive interface, the status of the arms is shown using a small wireframe model of the robot with the arms in the current positions. For audio input and output, the program will use the controlling laptop’s default speakers and microphone. The finalized interface is shown below in Figure 7. Note that the buttons in the bottom right hand corner are only accessible to Windows users. This is a necessary sacrifice due to the camera chosen by the team, which did not list this requirement in its specifications.

Figure 7: Interface Displayed on Laptop to User As mentioned above, the Native Swing and

Figure 7: Interface Displayed on Laptop to User

As mentioned above, the Native Swing and Java3D modules were used to add utility to the default Java classes. The Native Swing library was selected from among several options for web browser support (the Java Browser project, Lobo, Flying Saucer, etc.) because it was designed to be compatible with the Swing architecture included as a part of Java and which was already in use for the rest of the project. This library required the use of the Standard Widget Toolkit, which is freely available. For the robot wireframe, Java3D was selected as a simple addition. Java3D is a project from the same group that develops the Java language and is only packaged separately to lessen the size of the base Java development environment. Thus it was a natural extension to use when programming three dimensional models in Java.

Communication between the two devices (computer and microcontroller) is accomplished via a TCP/IP connection. The microcontroller’s IP address is static, and the Java interface connects directly to the microcontroller. Messages are passed along this connection. Formatting for these messages is based on the NMEA (National Marine Electronics Association) 0183 protocol. Early versions of the message construction used the NMEA protocol directly, creating comma-separated messages with four-letter headers and a two-digit checksum at the end, like so: $ACMS,18,18,18,18,00,28,00,28*1C. Since these commands were very lengthy and took significant amounts of memory in the microcontroller, it was decided to alter the message style, removing all superfluous characters, like so: m11110202*6D. This allowed faster and more efficient message parsing by the microcontroller.

5

Testing

5.1 Initial Wireless Range Test

The first major test the team performed was a wireless range test. For this test, a wireless router was hooked up to a portable power supply and a microcontroller. That microcontroller controlled power to a light bulb. When a command was sent from the laptop to the router, the light bulb would be illuminated. Repeating the command would turn the light off. To test wireless range, a team member carried the router and power supply away from the laptop and down an apartment hallway. When the light bulb stopped blinking, the router had effectively reached the end of its range. This test showed an approximate range of 150 feet with minimal obstructions. When carried downstairs, placing two floors between the router and computer to simulate obstructions, the range dropped to approximately 80 feet. Figure 8 shows the setup used for this experiment.

80 feet. Figure 8 shows the setup used for this experiment. Figure 8: Wireless Range Test

Figure 8: Wireless Range Test Setup

5.2

Gearbox Test

As soon as the necessary components arrived, the team built a prototype gearbox to test the torque output. The test setup consisted of a 1.5 amp power supply powering a VEX motor. An output shaft from the final gear was attached to a 2.6 inch gear, to which a string was attached. The motor would spin the large gear, winding the string and raising a 20 pound weight resting on the floor.

string and raising a 20 pound weight resting on the floor. Figure 9: Gearbox Test Setup

Figure 9: Gearbox Test Setup

In the event that the weight could not be raised, two 50 Newton scales were hung in parallel between the weight and the gear. This would allow the team to see how much tension the gearbox would put in the string. If the 20 pound weight was successfully lifted, it would mean that the motor and gearbox combination was capable of producing at least 2.2 foot-pounds of torque. While this is less than the gearbox was designed to produce, the power supply was also limited to 1.5 amps, which is less than half of what the motors were capable of drawing (3.6 amps). Thus, if the weight could be lifted at 1.5 amps, then the necessary torque would likely be achievable under full current draw. Figure 9 shows the gearbox test setup. Two multimeters were used to measure motor voltage and current throughout the test. The results of the test, seen in Table 2 and Figure 10, show that current draw increased in an approximately linear fashion with load. One result of this test not shown in the data is the fact that the square shafts used to support the gears tended to dig into the aluminum gearbox plates, necessitating the inclusion of some sort of bearing system. The team decided to use shaft couplers, which connect to the square shaft and create a round surface to insert into a bushing. Bronze bushings impregnated with graphite were chosen to reduce friction and wear on the aluminum supports; see 6.1.2 (Bushings).

Table 2: Gearbox Test Results

Load (Newtons) Voltage (volts) Current Draw (amps) Tested Extrapolated 0 N 20 N 36 N

Load (Newtons) Voltage (volts) Current Draw (amps)

Tested

Extrapolated

0 N

20 N

36 N

50 N

74 N

100 N

7.2 V

7.2 V

7.2 V

7.2 V

7.2 V

7.2 V

0.18 A

0.36 A

0.67 A

0.94 A

1.56 A

1.98 A

Current Draw as a Function of Load

1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 y = 0.0189x + 0.0631 R²
1.8
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
y = 0.0189x + 0.0631
R² = 0.966
0
0
10
20
30
40
50
60
70
80
Current (A)

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

FR

FL

RR

RL

Driver no-load current (A) Post-modification current (A)

0.37

0.25

0.25

0.37

0.35

-

-

0.27

Rotator current when lifing arm (A)

0.32

0.42

0.37

0.48

Post-modification current (A)

-

0.37

-

0.39

Post-modification current (A) - 0.37 - 0.39

5.4

Track Friction Test

The prefabricated treads installed on the robot are made of Delrin plastic and have a low coefficient of friction. Because of this, climbing stairs with smooth edges would present a problem because the tracks would not grip. To determine the best method for enhancing grip, a test was performed using different materials affixed to a five-link section of track. Each variation was tested on three different surfaces:

wooden bench top, concrete floor and vinyl stairs. Five different materials were used: 220 grit sandpaper, 600 grit sandpaper, double sided tape with sandblasting grit, sandblasting grit attached with epoxy, and coarse sand also attached with epoxy. A control set with no material attached was tested as well.

Table 4: Friction Test Results

Wood (workbench)

Concrete (floor)

Vinyl (stairs)

Coefficent of Friction 600 grit sandpaper 0.49 0.39 0.58 220 grit sandpaper Taped blasting grit

Coefficent of Friction

600 grit sandpaper 0.49 0.39 0.58 220 grit sandpaper Taped blasting grit Epoxied blasting grit
600 grit sandpaper 0.49 0.39 0.58 220 grit sandpaper Taped blasting grit Epoxied blasting grit

600 grit sandpaper

0.49

0.39

0.58

220 grit sandpaper

Taped blasting grit

Epoxied blasting grit

Epoxied coarse grit

Control

0.73

0.38

0.61

0.49

0.30

0.49

0.43

0.46

0.33

0.36

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.

necessary to run the electronics separately from the motors. Figure 11: Voltage Drop from Motor Switching

Figure 11: Voltage Drop from Motor Switching

5.6

Field of View Test

The orientation of the camera inside the robot affects the field of view for the operator. The longest side of the circuit board that the camera lens was mounted to was 1.875 inches, which was too large to fit inside the body without slotting the body and lid. The team performed a field of view test to determine how far ahead of the robot the operator would be able to first see the ground. In portrait-style orientation, the operator can see the ground closer to the robot but not as much side-to-side. Conversely, in landscape-style orientation, the operator has a wider field of view to the sides but cannot see the ground as close. Ultimately, the size of the circuit board determined the mounting of the camera inside the robot, and thus the field of view (portrait). However, the team did some calculations to determine ground-view- distance for either mode, depending on the angle of the tracks (and thus the robot body). Table 5 shows the results of the analysis - in portrait mode, with the robot lifted up on all four arms, the operator can first see the ground about 28 inches ahead of the robot.

Table 5: Field of View Spreadsheet

Front Track Position (0-90)

90

Degrees

5.7 Runtime Test

To test runtime, the robot was turned on and a timer displayed in front of the camera. When the electronics battery (the bottleneck battery) died, the last updated camera image showed how long the battery lasted. This turned out to be approximately 45 minutes, which is more than sufficient for the anticipated 20 minute average rescue mission length.

5.8 Second Wireless Range Test

Final wireless range was tested by driving the robot until the camera feed frame rate dropped below 2 frames per second, which would hamper control of the robot. The test consisted of both a line of sight test in an open area and an interference range test. The robot has a range of 150 feet line of sight and a range of 50 feet under heavy interference, which included an 8 inch cinderblock wall, a steel door, and some aluminum ductwork.

5.9 Versatility Tests

The robot is designed to climb stairs and traverse other rubble. To test this, the team drove the robot up a custom-built flight of three stairs, each 7 inches high and 9.5 inches deep. The robot was able to successfully climb up and down the stairs many times under its own power (Figure 12). However, considerable practice was necessary for the driver to climb stairs efficiently. In addition, the robot was able to lift itself upright (Figure 12), easily cross a 10 inch gap, and climb and descend a 21 inch tall ramp at an angle of 49 degrees from horizontal (Figure 14). Even back flips are possible (Figure 15)! Note that in the following three pictures, the robot is tethered. This is because the wireless battery was charging during testing.

Figure 12: Robot Stair Climbing Test Figure 13: Robot in Upright Position May 2012 20

Figure 12: Robot Stair Climbing Test

Figure 12: Robot Stair Climbing Test Figure 13: Robot in Upright Position May 2012 20 Calvin

Figure 13: Robot in Upright Position

Figure 14: Robot Ramp Climb Test Figure 15: Robot Back Flip May 2012 21 Calvin

Figure 14: Robot Ramp Climb Test

Figure 14: Robot Ramp Climb Test Figure 15: Robot Back Flip May 2012 21 Calvin College,

Figure 15: Robot Back Flip

6

Construction and Design Modifications

6.1 Mechanical Design Modifications

6.1.1 Bearing Support

Throughout the final design and construction process, there were many modifications made to the original design. The first major modification was a change in the bearing design. Initially, the team planned to use a needle bearing which would support the arm axle tube. However, constraining this bearing proved to be a complicated endeavor, requiring the part shown in Figure 16.

complicated endeavor, requiring the part shown in Figure 16. Figure 16: Initial Design for Bearing Support

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.

design change saved an estimated 20 man-hours of machining. Figure 17: Final Design for Bearing Support

Figure 17: Final Design for Bearing Support

The final two-piece design, shown in Figure 17, consists of a separate flanged bearing and support piece. With this design, the bearing (left) rests inside the groove on the support piece (right), and is effectively sandwiched between the support piece and wall of the robot body. Bearing replacement is easier and the load on the bearing is distributed more evenly between the body and the support piece.

6.1.2

Bushings

The second major modification was the addition of bushings in the gearboxes. Initial tests of the gearbox (Figure 9, Page 16) showed that the square axles would dig into the aluminum support pieces, generating friction, increasing wear and introducing slop into the gear train. A proposed solution was to attach shaft couplers to the shafts. These couplers had square inserts for the shafts and round exteriors, making them a good candidate for bushings. This solution proved ideal, so several couplers were cut in half to ensure that they would fit in the gearbox, while the rest were installed unmodified. These couplers fit inside bronze bushings; the bushings come impregnated with graphite to provide lubrication. The team found that the new design both decreased mechanical slop and wear in the system and reduced friction in the gear train.

6.2

Electrical Design Modifications

6.2.1

Batteries

As detailed in section 5.5 (Battery Test), the team determined that a second battery would be necessary to provide proper power to every component even while the motors were running. Fortunately, the team already owned a battery which could be used for the task. Space within the robot was found for the battery and the CAD model was updated accordingly. The battery assigned to the motors is rated at 5 amp-hours at 7.2 volts, and the electronics battery is rated at 1.6 amp-hours at 9.6 volts. Since the router, camera, and microcontroller draw approximately 1.5 amps, this gives more than an hour of runtime to the electronics (under ideal conditions). The motor current draw is more varied, but the team discovered that 5 amp-hours is enough for at least a full hour of runtime.

6.2.2 Arm Position Sensors

The arm position sensors (Figure 18) were designed after construction of the bearing housings connecting the tracks to the rotation motors and gearboxes. The team used a thin PCB and some C-shaped pieces of resistive paper to construct four potentiometer-like position sensors. The design is shown below in Figure 19. When the arm rotates in one direction, a wiper on the tube axle moves along the resistive paper and makes contact with the copper inner ring. A constant voltage of 5 volts is applied between ends of the resistive ring. Depending on the position of the arm, the voltage measured on the inner ring will vary from +5 volts to 0 volts. This value is measured with the Arduino microcontroller and sent to the laptop. It should be noted that there is a “dead zone” with this design that returns a meaningless result when the wiper doesn’t contact the outer resistive ring. The wiper is placed on the arm so that this happens when the arms are folded in next to the body of the robot. Figure 19 shows the electrical equivalent of the circuit shown on the left and the actual implementation on the right.

Figure 18: Arm Position Sensor Setup Figure 19: Drawing of Arm Position Sensors May 2012

Figure 18: Arm Position Sensor Setup

Figure 18: Arm Position Sensor Setup Figure 19: Drawing of Arm Position Sensors May 2012 24

Figure 19: Drawing of Arm Position Sensors

6.2.3

Motor Braking and Holding

After construction of the robot, the team noticed that the arm rotation motors would not hold the arms in position when the robot was partially lifted off the ground. This was primarily due to the lack of motor braking on the motor drivers used. The team brainstormed three ways to hold the rotation motors in place when the robot is partially elevated:

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

Connect relays in parallel with the arm rotation motors and close the relays when the motors are off to brake the motors

Utilize a feedback system to read the arm positions and automatically rotate the arms back to the desired position.

Of the three choices, it was decided that the team would use the feedback system as this would only require a change in software. Using a solenoid would require extensive mechanical modifications and the use of a relay could potentially cause problems with the motor control system shorting out. A production model would incorporate a mechanical means of motor braking.

6.2.4 Arm Contact Sensing

In order to detect contact between the arms and any obstacles, the controller would have to monitor voltage differences across the arm rotation motors. When the arms encountered resistance (obstacles), a large voltage difference would be measured and would be reported to the operator. In order to measure these voltages, no fewer than eight ADC’s would be needed (two ADC’s per each of the four rotation motors). The Arduino microcontroller being used does not have enough ADC’s to measure all the voltages at the motors. In a production design, a larger microcontroller would have sufficient analog inputs to measure the desired voltages.

6.2.5 User Interface

The user interface underwent several different versions as the capabilities of various Java modules were explored. In the end, rather than take the feed directly from the camera, it was necessary to use a Java- based web browser utilizing the Native Swing project. In addition, a combination of two factors decreased the performance of the camera by requiring the team to open browser feeds to the camera. In the early stages of construction, due to space constraints, the camera was mounted so that its feed would be shown sideways on the monitoring web page. Because of this and the fact that the camera only supports transmitting and receiving audio on a single web page whose individual components cannot be rotated, the team was forced to isolate the camera feed on a different page in order to present it to the user right side up; audio capabilities had to be loaded separately, requiring the camera to transmit two video streams to the application.

6.3 Robot Component Layout

Figure 20 shows an approximate top-down view of the robot without the lid on. The numbers correlate to the descriptions below; the front of the robot is facing the left side of the page. Each of the individual components designed and machined by the team can be seen in section 12,

Team Design CAD Drawings.

Team Design CAD Drawings. Figure 20: Component Layout Inside Robot 1. Rectangular Body - Made out

Figure 20: Component Layout Inside Robot

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

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

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

4. Interior Support Plate Primary connection for motors

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

6. Track Drive Motor Motor that directly drives the tracks

7. Camera and Communications Cover Machined transparent fixture that protects the camera and holds the microphone and speaker for two way communication

8. Camera Security camera with infrared LEDs for night vision

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

10. Speaker Allows the operator to talk to survivors

11. Motor Battery Powers all motors

12. Electronics Battery Powers all electronics aside from motors

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

14. Wireless Router/Camera Circuit Board Router on bottom for communication with computer and camera circuitry on top

7

Project Management

7.1 Team Organization

The team divided first according to concentration: the mechanical engineers (Bruce and Matt) assume responsibility for the mechanical aspects of the design shape, locomotion, etc. while the electrical engineers (Paul and Karl) took care of the electrical aspects wiring, programming, sensors, etc. Tasks were subdivided between each member according to strengths and experience. Bruce, who has considerable computer aided design (CAD) experience, handled much of the CAD modeling and robot construction. Matt likewise managed calculations, research, administrative duties and assisted Bruce with robot construction. The two collaborated to ensure that they had the same vision for the mechanical design. On the electrical side, Karl, who has spent a great deal of time working with microcontrollers, performed the hardware design and the microcontroller programming. Paul similarly designed the software for the controller and the user interface. The two together handled the communication between the robot and computer and the overall electrical design of the project. The team as a whole regularly discussed the interaction between mechanical and electrical systems, particularly any needs regarding space and sensors.

7.2 Schedule

Mechanical design and electrical/software design occurred simultaneously, with each realm influencing the other. For example, the mechanical design was modified to allow for a second battery, while the electrical design was constrained by the physical space within the robot itself.

Overall conceptual design was completed in early November. General robot mechanical design was completed in mid-January. However, the design details were quite dynamic, as problems arose that had to be resolved and as improvement ideas were implemented. Software design began in January and evolved continually as the prototype was built and tested. The assembled prototype was first fully tested on April 13. More software debugging and hardware modifications followed this initial test, and a plethora of performance tests were performed in late April and early May. The robot performed admirably on Senior Design Night, running both tethered and wirelessly for about an hour and a half. An approximate schedule of completed events is shown in Figure 21.

7.3 Budget/Funding Options

Calvin College supplied the team with an initial budget of $500 USD. This funding was used to purchase materials for the prototype (Table 6). In addition, a laptop was provided by the college which served as a platform for software development and operation of the robot. In searching for additional funds, the team considered applying for federal and foundational grants. However, after some research into these options, including a meeting with a grant writer for the Grand Rapids Fire Department, the team decided that grants would require too large a time investment compared to the likelihood of return. In addition, the timeline for grant funding would mean that funds would not likely have been available before project completion.

May 2012 Figure 21: Work Breakdown Schedul 28 Calvin College, ENGR 339/340

May 2012

Figure 21: Work Breakdown Schedul

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>.

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

 

Component

Part Number

Cost Per Unit

Shipping

Quantity

Weight per Unit (lbs)

Total

Total (lbs)

Vendor

Mechanical

Drive motors

276-2177

$19.99

$2.19

4

0.200

$82.15

0.8

VEX

 

Body metal

N/A

$0.00

$0.00

1

1.500

$0.00

1.5

Calvin

 

Tracks

276-2168

$29.99

$2.19

2

0.664

$62.17

1.328

VEX

 

Axles

276-1149

$8.96

$2.19

1

0.192

$11.15

0.192

VEX

 

Pivot motors

276-2177

$19.99

$2.19

4

0.250

$82.15

1

VEX

 

Spur gears

276-2250

$29.99

$2.19

2

0.384

$62.17

0.768

VEX

 

Pivot bearings

Kit8758

$4.95

$10.00

4

0.200

$29.80

0.8

VXB

 

Aluminum tube

N/A

$0.00

$0.00

1

0.375

$0.00

0.375

Calvin

 

Screws, washers

N/A

$0.00

$0.00

1

0.250

$0.00

0.25

Calvin

 

Bushings

9440T11

$0.88

$5.00

12

0.050

$15.56

0.6

McMaster

 

Shaft couplers

276-1843

$4.99

$2.19

1

0.020

$7.18

0.02

VEX

Electrical

Camera

FS-613B-M166

$62.89

$0.00

1

0.250

$62.89

0.25

Amazon

 

Battery

N/A

$0.00

$0.00

1

0.330

$0.00

0.33

Generic

 

Battery

7.2V 5000 mAh Tenergy

$22.99

$5.71

1

1.250

$28.70

1.25

Amazon

 

Lights

with camera

$0.00

$0.00

1

0.000

$0.00

0

N/A

 

Speaker

with camera

$0.00

$0.00

1

0.000

$0.00

0

N/A

 

Mic

with camera

$0.00

$0.00

1

0.000

$0.00

0

N/A

 

Router

High Power N150

$39.82

$0.00

1

0.500

$39.82

0.5

Amazon

 

Microcontroller

N/A

$30.00

$0.00

1

0.250

$30.00

0.25

Generic

 

Power Regulation

N/A

$10.00

$0.00

1

0.375

$10.00

0.375

Generic

 

Motor Drivers

NCV7702B: 1.0 A Driver

$3.56

$0.00

8

0.063

$28.48

0.5

Mouser

 

6-Pin Headers

649-77311-818-06LF

$0.19

$2.76

2

0.01

$3.14

0.02

Mouser

 

8-Pin Headers

649-68002-208HLF

$0.24

$0.00

2

0.01

$0.48

0.02

Mouser

 

12-Pin Headers

649-68000-412HLF

$0.35

$0.00

2

0.01

$0.70

0.02

Mouser

 

Accelerometer

SEN-10955

$9.99

$4.00

1

0.01

$13.99

0.01

Sparkfun

 

Battery Charger

N/A

$0.00

$0.00

1

0

$0.00

0

Generic

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.

Table 7: Projected Production Costs

 

Component

Part Number

Vendor

Price

Quantity

Total

Drive motors 276-2177 VEX $ 19.99 4 $ 79.96

Drive motors

276-2177

VEX

$

19.99

4

$ 79.96

Tracks 276-2168 VEX $ 29.99 2 $ 59.98

Tracks

276-2168

VEX

$

29.99

2

$ 59.98

Axles 276-1149 VEX $ 8.96 1 $ 8.96

Axles

276-1149

VEX

$

8.96

1

$ 8.96

Pivot motors 276-2177 VEX $ 19.99 4 $ 79.96

Pivot motors

276-2177

VEX

$

19.99

4

$ 79.96

Spur gears 276-2250 VEX $ 29.99 2 $ 59.98

Spur gears

276-2250

VEX

$

29.99

2

$ 59.98

Pivot bearings 5905K124 McMaster $ 7.93 4 $ 31.72

Pivot bearings

5905K124

McMaster

$

7.93

4

$ 31.72

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

Misc. Screws, washers

Generic

McMaster

$

2.00

1

$ 2.00

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

Body aluminum (5052-H32)

P314-5052

MetalsDepot

$

39.20

1

$ 39.20

Steel tube, plate

T258316

MetalsDepot

$

2.15

1

$ 2.15

MechanicalElectrical

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

Camera

FS-613B-M166

Amazon

$ 65.00

2

$

130.00

Potentiometer Generic Generic $ 1.00 4 $ 4.00

Potentiometer

Generic

Generic

$ 1.00

4

$ 4.00

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

Battery

10H4/3A3800R2WR

Powerizer

$ 39.95

2

$ 79.90

Lights Generic Generic $ 1.00 1 $ 1.00

Lights

Generic

Generic

$ 1.00

1

$ 1.00

Speaker Generic Generic $ 15.00 1 $ 15.00

Speaker

Generic

Generic

$ 15.00

1

$ 15.00

Mic Generic Generic $ 5.00 1 $ 5.00

Mic

Generic

Generic

$ 5.00

1

$ 5.00

Router High Power N150 Amazon $ 35.00 1 $ 35.00

Router

High Power N150

Amazon

$ 35.00

1

$ 35.00

Microcontroller ATMEGA2560 Digi-Key $ 10.00 1 $ 10.00

Microcontroller

ATMEGA2560

Digi-Key

$ 10.00

1

$ 10.00

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

Power Regulation

LM7805 / LM317

Digi-Key

$ 10.00

1

$ 10.00

Motor Drivers NCV7702B: 1.0 A Dri Mouser $ 3.56 4 $ 14.24

Motor Drivers

NCV7702B: 1.0 A Dri

Mouser

$ 3.56

4

$ 14.24

Charging Station

CH-UN180

Powerizer

$ 30.95

1

$ 30.95

Miscelaneous

$ 20.00

Parts Cost

$ 719.01

Shipping

$ 40.00

Total Cost (per unit)

$ 759.01

8.3 Possible Future Improvements

While budget was a limiting factor for the features included in the robot, it did not limit the imagination of the team. As a result, there were a number of ambitious ideas that could not be taken to fruition. Among these ideas were several improvements to the existing equipment as well as quite a few new features.

The prototype designed by the team has only one camera, placed at the front of the vehicle. This presents a problem if the robot gets stuck in a dead end and has to back out. To nullify this, the team originally planned to have a second camera in the “rear” of the robot to allow reversing direction without driving blind.

Better yet, the team also had the idea to add a second camera to the front and a pair of cameras to the back of the vehicle to allow three dimensional viewing by the operator, whether traveling forward or backward. When the team conferred with representatives of the Grand Rapids Police Department

concerning their current robots’ shortcomings, the officers specifically mentioned this feature, as it is very difficult for the user to get a sense of distance when operating the robot. As such, even simple depth- related tasks require several attempts. 9

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

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

the user looked. This would require both better cameras and additions to the control logic. Cameras could also be added to the sides, top and bottom of the vehicle (bearing in mind that the top and bottom of the robot are interchangeable) to convey more information regarding the robot’s surroundings to the user. The feeds from these cameras would not always be shown but instead would be toggled by the user, to avoid disorientation from the different views.

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

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

survivor. In the same vein, a directional microphone could allow the robot to determine the most direct path to a conscious survivor. To allow more utility in hazardous materials situations, the robot would have additional sensors for air purity, temperature, pH, radiation, etc. It would be fully water-sealed to further resist contamination, as well.

The microcontroller could also be modified to monitor the voltage across each arm rotation motor to determine when the motor has stalled (and by extension, when the arm has made contact with the ground

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

The arms would flash a different color when they confirm contact with an obstacle. In addition, the two processors used by the team would be replaced by a single, more powerful processor with more input and

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

Currently all switches and batteries are internal and the cover must be removed to access them. This is time consuming. In future prototypes there would be shielded switches located on the outside of the body and ports for removing the battery or hooking the robot itself up for charging.

The original robot design required the robot to be using power directly from the battery whenever it was active. However, with the addition of an Ethernet port, the robot can be connected directly to a power source using power over Ethernet. This allows the robot to function tethered without draining the battery, which would be useful particularly when traveling to or from the launching point so that the battery could be fully charged when the robot began investigating. The implementation used by the team allows powering of all electronic components except the camera entirely from an outside power source. The motors, however, are still battery-powered.

Allowing for the tracks to be tightened to remove slack would be another major change. On the current prototype the treads bow out a bit which could allow for larger debris to enter into the internal arm. In addition, having all components machined offsite would significantly decrease the time it would take to construct the model.

Another obstacle for the current prototype was traction on the treads. The team purchased the current treads due to lack of time for individual construction. In future prototypes the tracks would be fabricated

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

out of metal instead of plastic to increase the melting temperature and durability. Designing and fabricating a new track would also allow for the addition of studs to increase the gripping ability.

Motor breaking is a bit of an issue for the current model. If the arms are not straight the weight of the body causes it to drop back down. Instead of using the current gear system, a worm gear would be applied. This would eliminate the need for electrical or software solutions.

9

Conclusion

The goal of this project was to design and prototype a low cost robot for first response reconnaissance in structurally unsound or collapsed buildings and hazardous materials situations. The prototype produced has a ground speed of 10 inches per second, battery life of approximately 45 minutes, wireless range of between 50 and 150 feet (depending on conditions), weighs 14.5 pounds and has a high level of mobility. Based on the tests and performance of the final prototype, and given the budget and time constraint, Team RESCUE has demonstrated the plausibility of a future RESCUE robot (Figure 22).

the plausibility of a future RESCUE robot (Figure 22). Figure 22: Finished Robot with Cover Removed

Figure 22: Finished Robot with Cover Removed

10

List of Abbreviations

Analog to Digital Converter (ADC) American Society of Testing and Materials (ASTM) American Standard Code for Information Interchange (ASCII) Center for Robot-Assisted Search and Rescue (CRASAR) Computer Aided Design (CAD) Field Programmable Gate Array (FPGA) Global Positioning System (GPS) Graphical User Interface (GUI) National Marine Electronics Association (NMEA) Printed Circuit Board (PCB) Radio Frequency (RF) Robot for Extraction of Survivors Confined in Unreachable Environments (RESCUE) Unmanned Ground Vehicle (UGV) United States Dollar (USD)

11

Acknowledgements

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

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

Ryan Sparks with the Grand Rapids Fire Department

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

Ron Venneman with Calvin College Campus Safety

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

Ned Nielsen, Professor and Advisor, at Calvin College

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

Bob DeKraker, Technological Assistance, at Calvin College

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

12

Team Design CAD Drawings

RESCUE

37

Gear Box Assembly

38

Gear Box Front

39

Camera Inner Mount

40

Front Camera Cover

41

Gear Box Side

42

Lid

43

Second Plate Motor Holder

44

Body

45

Track Guard Inside

46

Track Guard Support

47

Arm Drive Axle (Tube Axle)

48

May 2012 37 Calvin College, ENGR 339/340
May 2012 38 Calvin College, ENGR 339/340

May 2012

38

Calvin College, ENGR 339/340

May 2012 39 Calvin College, ENGR 339/340

May 2012

39

Calvin College, ENGR 339/340

May 2012 40 Calvin College, ENGR 339/340

May 2012

40

Calvin College, ENGR 339/340

May 2012 41 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

43

Calvin College, ENGR 339/340

May 2012 44 Calvin College, ENGR 339/340

May 2012

44

Calvin College, ENGR 339/340

May 2012 45 Calvin College, ENGR 339/340

May 2012

45

Calvin College, ENGR 339/340

May 2012 46 Calvin College, ENGR 339/340

May 2012

46

Calvin College, ENGR 339/340

May 2012 47 Calvin College, ENGR 339/340

May 2012

47

Calvin College, ENGR 339/340

May 2012 48 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.

Guide Step 1: Remove four screws on outside of track arm. Step 2: Remove axle pin

Step 2: Remove axle pin and slide axle out.

screws on outside of track arm. Step 2: Remove axle pin and slide axle out. May

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

Step 3: Slide off outside track guard and track/hubs. Step 4: Remove four screws by drive

Step 4: Remove four screws by drive shaft.

track guard and track/hubs. Step 4: Remove four screws by drive shaft. May 2012 50 Calvin

Step 5: Slide track assembly off of drive shaft.

Step 5: Slide track assembly off of drive shaft. Step 6: Remove spacer from tube axle

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

shaft. Step 6: Remove spacer from tube axle and unscrew four holding screws. May 2012 51

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

Remove drive shaft pin and pull drive shaft out of gearbox. Step 8: Push in on

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.

if simply removing gearbox; remember to unplug motors and rotation sensor. May 2012 52 Calvin College,

Step 9: Remove gearbox holding screw.

Step 9: Remove gearbox holding screw. Step 10: Carefully remove gearbox side plate. Note that bushings

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

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.

are attached to side plate.

on gearbox holding screws (3) and drive shaft. are attached to side plate. May 2012 53

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.

document, the default keys will be used, as shown below. Note that all commands are relative

Note that all commands are relative to the camera view; that is, the raise and lower commands will move the arms in the opposite direction when the robot is turned upside down. This means that the operator does not need to change approaches when the robot is flipped; the button which

moves the camera “up” still moves it “up” relative to the view shown. Before starting the RESCUE program, ensure that the robot is fully powered and turned on. After a short time, the “RESCUE Bot” wireless network should be available. Connect to this network using the password T8RESCUE.

To begin, simply click on the RESCUE.jar file. The program will start up on its own. (If you wish to see motor messages as they are shown and accelerometer messages as they are received, start the jar using the command line.)

You will see a screen much like this:

the command line.) You will see a screen much like this: The left half of the

The left half of the screen is used for the view from the camera. This view will automatically flip upside down if the accelerometer on the robot detects that it is oriented upside down. (If the camera requests a user and password, enter admin as the user and click OK.)

The upper right section of the screen is used for a display of the robot. This display can be rotated left and right by the user to obtain a better understanding of the robot’s current orientation. Other rotations are automatically done by the program and represent the current orientation of the robot. As well, the legs (shown in green) rotate individually to show their orientations relative to the robot.

The bottom right corner is reserved for sensor data (in this case, GPS data) and interaction with the camera. The four buttons shown each have their own uses; hovering over a button displays its purpose below. From the top left, proceeding clockwise, these buttons are: record stream, take snapshot of stream, activate speaker to talk through robot, and activate microphone to receive audio from robot.