1. Introduction
Companies often use autonomous robots to complete tasks that humans cannot
because of strength requirements or hazardous environments. The Fundamentals of
Engineering Honors Space Administration, or FEHSA, needs an autonomous robot to
complete several tasks in preparation of the launch of their latest rocket. These tasks
include delivering supplies from the lower level of the spaceport to a crate on the upper
level, supplying the rocket with the appropriate liquid fuel, toggling switches to initiate
communications systems, and activating the final launch indicator [1]. The task given to
the company is to construct and program a prototype robot that will perform the
aforementioned tasks correctly within two minutes.
Successful completion of this task is critical for the safety of FEHSA personnel
and the effectiveness of FEHSA's space exploration mission. The hazardous nature of the
materials in the spaceport prevents humans from working there safely and efficiently, so
an autonomous robot is necessary. Furthermore, the crew of the rocket depends on the
robot completing its tasks correctly for them to safely launch the rocket, breathe while in
the rocket, and communicate with land.
The company members working on this task are Sam Reifsteck, Tony Maggio,
Marissa Banks, and Jesse Weber. The assigned task was released on January 17, 2016,
and the final acceptance test took place on April 9, 2016.
The following sections describe the team's response to the described task. Section
2, Preliminary Concepts, describes the team's initial ideas for robot design and course
strategy using words and diagrams, as well as the process through which they were
decided. Section 3, Analysis, Testing and Refinements, discusses how the final design
1
and strategy was determined, necessary calculations were made, and completion of tasks
was tested in various stages. Section 4, Individual Competition, presents the performance
of the team's robot in the first competition and its effect on future modifications. Section
5, Final Design, provides an in-depth description of the robot, including chassis,
drivetrain, mechanisms, sensors, course strategy, and code. Section 6, Final Competition,
describes the performance of the team's robot in the second competition. Finally, Section
7, Summary and Conclusions, gives an overview of the report and suggests future
improvements.
2. Preliminary Concepts
2.1. Introduction
The team's first step in creating and programming the autonomous robot was to decide
how to accomplish the required tasks. After considering the constraints on the robot, the team
compared several options for each section of the robot and chose what it considered the best
combination. This decision was elaborated with CAD, a cardboard mockup, and pseudocode,
all shown in the following section.
2.2. Requirements and Constraints
The robot must fit inside a 9"x9" square, and have a height of no more than 12", in its
starting configuration. The team was given $160 dollars with which to purchase all materials
for the robot, not including the Proteus and any sensors in the provided basic sensor kit. The
robot must be autonomous, relying on no signals except those given by the course. A QR
code must be mounted at least 9" above the course base in every test and competition after
Performance Test 2 [1].
2
2.3. Brainstorming
2.3.1. First Matrix
Several ideas were brainstormed for each of the components of the robot (chassis,
drivetrain, and mechanism/method for completing each task). Of these, one per component
was chosen as a baseline, and all other ideas were compared to it in categories such as
simplicity, maintenance, and cost. The matrices for each component are shown in Appendix
A.
2.3.2. Second Matrix
After the top 3-4 options were decided for each component of the robot, each team
member chose an option from each category for a layout of the entire robot. Those layouts were
given a rating from 1 to 5, with 5 being the best, in each of 8 weighted categories, as shown in
Table below.
Table 1: Design matrix for full robot design
3
2.4. Description of First Brainstorming
Of the four final designs, the second idea, with a score of 3.35 out of a possible 5, was
chosen as the preliminary design. It was chosen because of its relatively low cost compared to
other designs, its ease of turning (compared to treads), the simplicity of its fuel button
mechanism, and the reliability of its supplies mechanism. This design was modified heavily
throughout performance tests before it became the final design, but it served as a starting point
for constructing the robot.
The preliminary robot had a hollow chassis consisting of a rectangular-prism frame
reinforced by beams connecting the sides diagonally, and four wheels each controlled by a
motor. The Proteus would be mounted onto a platform above the motors and mechanisms due to
space limitations. A motor-controlled long bar on the front of the robot would push all switches
forward on the lower level, and a short bar on the left side would push necessary switches
forward on the upper level, according to information sent by the course. A rod on the back of the
robot, also connected to a motor, would move up or down to the level of the correct fuel button.
An electromagnet attached to arm on the front of the robot would pick up, carry, and deposit the
supplies by turning the magnet on or off. The robot would press the final button by running into
it with the fuel delivery button. One CdS cell, used for both recognizing light colors and line
tracking, would be mounted behind the back wheels.
The CAD of the preliminary design is located in Appendix F.
4
2.4.1. Sketch
Figure 1: Sketch of Preliminary Design
2.4.2. Mockup
The team constructed a cardboard mockup of the robot to demonstrate the position of the
mechanisms, motors, and Proteus on the chassis. The mockup was not precisely to scale,
especially the white box representing the Proteus, which was too small compared to the rest of
the robot.
5
Figure 2: Mockup Facing Left
Figure 3: Mockup Facing Forward
6
2.5. Description of Course Strategy
2.5.1. Diagrams
The general course strategy was to leave the starting platform, push the necessary
switches, maneuver to and pick up the supplies, drive up the short ramp, push the correct fuel
delivery button, line follow to drop off the supplies, push the rest of the switches, drive back
down the short ramp, and push the final button. This strategy was diagrammed and separated
into sections with colored arrows, as shown in Figure 4 on the next page.
Figure 4: Diagram of Preliminary Course Strategy
7
2.5.2. Pseudocode
Once the team decided on an overall course strategy, team members wrote a basic
description of each function the robot needed to execute, including inputs and outputs. The
entire text of the pseudocode is located in Appendix B.
3. Analysis, Testing, and Refinements
3.1. Development of Final Design
3.1.1. Before Performance Test 1
After completing the mockup, the team concluded that the preliminary
design was impractical for the design task, and so began to re-brainstorm ideas for
mechanisms. During a meeting at the challenge course, the supplies mechanism
was changed from an electromagnet to a permanent magnet because the team
decided the extra effort required to purchase and assemble a functioning
electromagnet was disproportionate to its advantages over a permanent magnet.
Furthermore, the fuel button mechanism was changed from a protruding rod to a
two-rod pulley system to simplify the required motion of device and eliminate the
potential of using gears.
As parts were ordered and the chassis was built, the drivetrain design
changed from four Igwan-motor-powered wheels to two Igwan-motor-powered
wheels in the back and two skids in the front. This design cost less than the fourwheel design and allowed the robot to turn more easily. In addition, the CdS cell
was mounted below the middle the robot instead of the back so the robot could
read the fuel light without running into a button. After exploring the use of bump
8
switches, the team bought two bump switches and mounted them to the front of
the robot to sense when the robot ran into a wall. Figure F2 in Appendix F shows
the robot used in Performance Test 1.
3.1.2. Performance Test 1-Performace Test 2
The team realized that the current switch-flipping mechanism design
would extend the robot’s width beyond the permitted 9 inches, so a new
mechanism was designed: an arm that would hang down in front of the robot in its
starting position and be raised by a servo motor. This mechanism could push
switches at either height, eliminating the need for the second switch-flipping arm.
The servo planned to be used for the second arm was now delegated to raising and
lowering the supplies button. Furthermore, the two-rod fuel button mechanism
was eliminated and the task of pushing the fuel buttons assigned to the switch
arm. Figure F3 in Appendix F shows a CAD model of the robot used in
Performance Test 2, and Figure below shows the physical robot as it looked
during that test.
Figure 5: Robot Design Used in Performance Test 2
9
3.1.3. Performance Test 2-Performance Test 3
In order to comply with the requirements for Performance Test 3 and
onward, a QR code was mounted to a platform above the back of the robot for
RPS navigation. The permanent magnet was added to the robot in order to use the
arm to pick up the supplies. Instead of using the CdS cell to line-follow, the team
purchased a set of three opto-sensors, which were mounted below the front of the
robot. Two additional bump switches were added, one on each skid, to determine
when the robot ran into the supplies storage area. Finally, to create more traction
on the ramp, a rubber band was added to each wheel. Figure E1 in Appendix E
and Figure F4 in Appendix F show the described changes.
3.1.4. Performance Test 3-Performance Test 4
In testing after Performance Test 3, the team discovered that the main arm
was not stable enough to push the fuel buttons without slipping, so a servocontrolled arm was built and attached to the back of the robot. The magnet was
permanently attached to the main arm, the servo closest to the front was now
designated to raise and lower the main arm, and the servo closest to the back
controlled the fuel button arm. The wheel of the main arm servo detached
frequently, so it was secured with Velcro. Figure E2 in Appendix E and Figure F5
in Appendix F show the robot as it appeared during Performance Test 4.
3.1.5. Performance Test 4-Individual Competition
An appropriately sized screw was found to hold the main arm servo wheel
in place, so the Velcro was replaced with that screw. A bump switch originally
10
intended for the magnet (before it was permanently attached) was mounted to the
frame of the main arm to keep it from raising too high and over-winding the
string. Two bump switches were mounted to the robot facing the outside to
indicate when the robot had turned into the wall. Figure E3 in Appendix E and
Figure F6 in Appendix F show the updated robot during the individual
competition.
3.2. Analysis and Calculations
3.2.1. Drivetrain Calculations
Using estimates of the distance (in inches) traveled by the robot on the
course and the time required to complete each test, the minimum linear speed for
the robot was determined to be about 3.00 inches per second. Using a wheel of
1.25 inches, this would necessitate a motor rotational speed of 22.92 rpm.
After estimating the mass of the robot to be 43.76 ounces and calculating
the angle of the ramp to be 20.56 degrees, the team determined the torque
required per motor to get the robot up the ramp to be 14.60 oz-in.
Based on the combination of speed and torque, the Futaba, Fitec, GMH,
VEX, Acroname, and Igwan motors all satisfy the needs of the team’s robot [2].
The team decided to use Igwan motors for the robot because of their reliability,
strength, and built-in shaft encoders.
3.2.2. Shaft Encoding Calculations
As calculated in Exploration 2, the combination of 1.25-inch radius wheels
and the shaft encoders built into the Igwan motors results in a theoretical 40
counts per inch, or 243 counts per 6 inches. Furthermore, to turn 90 degrees in
11
place, one motor must turn approximately 140 counts forward and the other 140
counts backward.
3.3. Tests for Performance Check 1
3.3.1. Description
Fifteen tests were conducted between February 24 and 25, 2016. Before
the first test, a code was written that commanded the robot to start with the
starting light, navigate up the side ramp, read a fuel delivery color, and press
either fuel button. This was done using shaft encoding and bump switches.
Between each subsequent test, minor modifications, such as motor power and
encoder counts, were applied in attempt to resolve any errors observed in the
tests.
3.3.2. Results
Errors noticed in testing decreased in number and severity as testing
continued. The robot successfully started with the light, drove completely to the
upper level, and read and displayed the color of the fuel light by the fifteenth test
on Friday, February 25 at 4:16 PM.
3.3.3. Refining
In several tests, it was observed that the right motor was more powerful
than the left motor, causing the robot to turn slightly to the left as it drove
forward. Differences in motor power were accounted for in future code by
modifying assigned motor power in driving functions. In addition, changes in
starting position were eliminated by creating a cardboard template for future tests.
12
3.4. Tests for Performance Check 2
3.4.1. Description
At least forty tests were conducted between March 3 and 4, 2016. As for
the previous performance test, before any testing, measurements were taken on
the course to write a baseline code. This code commanded the robot to start with
the start light, push the blue switch toward the upper level, go up the ramp, push
the white switch toward the lower level, and push a fuel delivery button. Most
tests evaluated tweaks of this program, though a new program was written on
March 4 as a last-chance effort to gain more points.
3.4.2. Results
The robot failed to drive consistently to and up the ramp, only generally
succeeding in pushing one switch forward. Attempts to correct the turn before
driving onto the ramp caused the robot to turn too much or too little on different
tests of the same code. A separate code was written to push one switch forward
and pull one switch backward from the lower level as a last attempt, but it was
only tested twice and failed on both tests. However, pulling switches from the
first level instead of pushing them from the second level of the course proved a
viable option.
3.4.3. Refining
After noting the unreliability of shaft encoding for navigation during
testing, the team resolved to incorporate RPS navigation in future code to verify
angle and distance. In addition, the consistent issue of the robot's wheels slipping
13
on the ramp was resolved by adding rubber bands to the wheels and using line
tracking on the ramp.
3.5. Tests for Performance Check 3
3.5.1. Description
Tests for this check were conducted over the course of three days,
spanning March 9-11. This test consisted of beginning with a start light, touching
and controlling the supplies, and depositing the dumbbell in the proper place on
the top level of the robot course. For extra credit, the robot had to drive back
down to the bottom level. Tests conducted adjusted the code in parts. The first
part consisted of driving to and picking up the supplies. The second part included
driving to and up the ramp. The third was driving to and dropping off the supplies
and the final, extra part was driving back down to the lower level.
3.5.2. Results
This performance check was more successful than the last one. The robot
successfully picked up and deposited the dumbbell of supplies in the container on
the second level. As for the individual sections of code, the robot consistently was
able to pick up the supplies, because it relied on a combination of bump switches
and RPS checks. It had some trouble entering the ramp, but once it was on it, it
used a line following program and bump switches to consistently navigate to the
top of the ramp. The travel to and delivery of the supplies was also very
consistent, and it utilized RPS, line following, shaft encoding, and bump switches
together. The extra credit portion was not met, however. The team did not have
enough time to refine the code, and the robot starting failing to even pick up the
14
supplies and became very inconsistent towards the end of testing. This could have
been due to low battery on the Proteus.
3.5.3. Refining
In future tests, the team concluded to utilize the RPS only at critical points
on the course. The RPS checks took too long to execute and would prevent the
robot from moving efficiently in the final competition. Because the robot was able
to consistently pick up and deposit the supplies, the code used for those portions
was chosen to be integrated into the final code. The team also concluded that it
was important to ensure the Proteus was well charged before any testing.
3.6. Tests for Performance Check 4
3.6.1. Description
Approximately 45 tests were conducted between March 23 and March 25,
2016.This test consisted of beginning with the start light, driving to the upper
level, pressing and holding the correct fuel button for five seconds, driving back
to the lower level, and pressing and holding the final button, with bonus points for
controlling the supplies. The team started with part of the code for the previous
week’s performance test, from the beginning to when the robot reached the upper
level. Additional sections of code were then added in parts: first reaching and
reading the fuel light, then pushing and holding the correct fuel button, then
driving back down the side ramp, then pushing the final button. Each section was
adjusted to include the correct values before another section was added, and
sections were re-adjusted as necessary.
15
3.6.2. Results
Minor errors still occasionally occurred, but the robot became more
consistent as testing continued. After two unsuccessful performance tests, the
robot successfully completed all required tasks on Friday, March 25.
3.6.3. Refining
Several mechanical problems occurred during testing when the servo
wheel detached as the arm was raised. This problem was resolved in future tests
by screwing the servo wheel into the hub, securing it permanently.
4. Individual Competition
4.1. Description of Competition
The individual competition took place on Friday, April 1st, 2016, between 3:00
and 4:15 PM. The competition consisted of three rounds: one in which course location
and values (switch positions and fuel light color) were randomized, one in which the
instructors and TAs chose course location and values, and one in which the team chose
course location and values [3] The purpose of the individual competition was to
determine team rankings for the elimination round of the final competition.
4.2. Strategy
The team’s strategy for the course was to start with the start light, pick up the
supplies, drive up the side ramp, press and hold the correct fuel button, drop off the
supplies, drive down the ramp, toggle the white switch, and push the final button. The
team chose not to attempt to toggle all three switches in order to save time and focus on
completing the primary tasks more accurately. This task sequence utilized the beginning
16
of the code from Performance Test 4, in which the robot started with the light, picked up
the supplies, drove up the side ramp, and pressed and held the correct fuel button.
4.3. Robot Performance
4.3.1. Round 1
The robot correctly started with the start light and picked up and
controlled the supplies. However, the robot backed up too far from picking up the
supplies and turned too far to the left, so it ran into the wall to the left of the ramp
entrance and did not gain any more points. A total of 28 points were earned
during the run.
4.3.2. Round 2
The robot once again correctly started with the start light and picked up
and controlled the supplies. This time, the robot drove onto the ramp, but was
angled too far to the right, and the robot was not able to correct itself and align
with the ramp wall using the bump switches. The kill switch was flipped while the
robot was still on the ramp. The robot earned 28 points during the run.
4.3.3. Round 3
The robot behaved very similarly to Round 1, starting with the light and
picking up the supplies but turning incorrectly after backing up from the supplies.
This time, it did not turn far enough to the left, so the right edge of the robot
became stuck on the wall to the right side of the ramp. The robot earned 28 points
during the run.
17
4.3.4. Overall
The robot earned an average of 28 points per run during the individual
competition. It had high accuracy during the first thirty seconds of the program,
but a navigational error early in the program prevented it from attempting most of
the required tasks.
4.4. Analysis of Results
The combination of shaft encoding, RPS navigation, and bump switches allowed
the robot to start at the correct time and pick up the supplies with good accuracy.
However, the robot backed up from the supplies storage area at inconsistent angles, and
the code did not account for slight differences in height between the course and the ramp,
so entrance onto the ramp was very inconsistent. It is uncertain how accurate the rest of
the code was because it was never observed during the competition.
4.5. Suggested Modifications
In order to resolve the inaccuracy in driving onto the ramp, the team suggested
several modifications. One team member suggested having the robot turn 180 degrees and
drive forward towards the ramp because, for an unknown reason, the robot swerved to the
side less using the “drive forward” than using the “drive backward” function. Others
suggested completing RPS checks of y coordinate and heading before driving onto the
ramp and adjusting the skids to more easily travel over possible bumps between the course
and the ramp.
The team finally decided to attach metal bumpers to the left and right of the robot,
which would guide it to move into the correct position if a corner hit the edge of the ramp
entrance. The “drive forward” and “drive backward” functions were also modified to
18
increase the power of the appropriate wheel if the encoder counts for the two wheels were
significantly unequal. Because of the addition of the bumpers interfered with their use, the
side bump switches mounted during the previous week were moved to the back of the
robot Later in the week, the back bump switches were removed because they were never
used and possibly interfered with the chassis hitting the blue fuel button.
5. Final Design
5.1. Chassis and Drivetrain
The robot has a rectangular chassis made of laser-cut wood and covered
with a layer of PVC. Two Igwan-powered, 2.5” diameter wheels are mounted on
the back of the robot, one on either side, under the chassis. A rubber band covers
the tread of each wheel for additional traction. Two 3-D printed skids are mounted
under the chassis on the front of the robot. Figure F8 in Appendix F shows the
CAD of the chassis and drivetrain.
5.2. Task Mechanisms and Methods
To toggle the switches, the robot uses an arm that extends outward in front
of the chassis from a frame mounted on the chassis. This arm is raised and
lowered by a servo motor, which winds or unwinds fishing wire attached to a
support beam on the arm. The arm can push the switches forward or hook around
them to pull them back.
The robot also uses this arm to control and deposit the supplies. A
permanent magnet tied to the arm attracts and holds the supplies to control them.
To drop off the supplies, the robot drags the arm across the trough, separating the
supplies from the magnet.
19
To push the blue delivery button, the robot drives into it; the chassis is at
the same level as the blue button. When the robot needs to push the red button, it
uses a short arm mounted to a servo motor on the back of the robot. A piece of
PVC mounted below the switch prevents the switch from lowering too much and
pushing the red button. Finally, the robot pushes the final button by driving into it.
Figure F7 in Appendix F shows the CAD of all task mechanisms on the
chassis.
5.3. Sensors
The final design of the robot uses one CdS cell with a red filter to detect
the presence of the start light and the color of the fuel detector lights. The red
filter was determined to be ideal through an exploration. Two bump switches are
mounted to the front of the robot and one on each skid to allow the robot to align
with walls. Two additional bump switches facing left and right are mounted to the
front of the robot to allow it to recognize when it has run into a wall on the ramp.
A seventh bump switch mounted to the arm indicates when the arm has been
raised to its maximum height. Finally, a set of three optosensors is mounted under
the front of the robot for line following.
5.4. Final Budget
Of the $160 allotted, the team spent $137.79, with $22.21 remaining in the
budget. The details of each purchase are listed in Appendix C. Figure 6 below
visually displays how the money in the budget was spent over time.
20
Figure 6: Budget Graph
5.5. Final Schedule
A table containing each task, estimated and actual start and end dates, due
dates, each team member’s role in the task, estimated and actual time necessary to
complete the task, and how much progress has been made on the task is located in
Appendix D. The original estimations for date started, date completed, and hours
spent on each task underestimated the amount of time it would take to test the
code. As a result, starting at the week of Performance Test 3, the team started
coding and testing code as early as construction allowed (which varied from week
to week). In addition, tasks not directly related to building and coding the robot,
such as writing drafts of the final report, were started later than expected because
of a team focus on construction and code.
21
5.6. Summary of Final Code
The final code is very modular, relying almost entirely on calling
functions. The code executes basic navigation by calling functions such as
move_forward or turn_left, which use motor power and encoder counts as input
variables. RPS check functions for x, y, and header allow the robot to correct
itself if relying on encoder counts results in the wrong position. Several functions
command the robot to navigate based on sensor input, such as driving forward
until both bump switches are hit or turning until the center optosensor sees a
yellow line. The two arms are controlled using functions that raise or lower them
either for a certain amount of time or until the bump switch on the main arm is
pressed. More complicated functions combine basic functions to complete tasks
such as pressing and holding the correct fuel button or dropping off the supplies.
The final code is listed in its entirety in Appendix G.
22
5.7. Electrical Diagram
Figure 7: Electrical Diagram
6. Final Competition
6.1. Description of Competition
The final competition took place on Saturday, April 9, 2016 between 12:30 PM
and 5:30 PM. The first three rounds of competition were against randomly decided teams.
The next rounds, up to three, were seeded according to performance in the individual
competition [4]. Awards were given out for top performance, best engineered robots,
23
most innovative robots, documentation, and most innovative robots at the end of the
competition [1].
6.2. Strategy
The team’s strategy for the course was to start with the start light, pick up the
supplies, drive up the side ramp, press and hold the correct fuel button, drop off the
supplies, drive down the ramp, toggle the switches, and push the final button. The team
developed an accurate code for completing all tasks but toggling all three switches five
days before the competition, so the individual competition strategy was changed to
attempt to earn more points.
6.3. Robot Performance
6.3.1. Round 1
The robot successfully started with the light, picked up the supplies,
pushed and held the correct fuel delivery button, deposited the supplies, and
toggled two switches. However, the robot became stuck while turning to toggle
the blue switch, so it neither toggled the final switch nor pushed the final button.
The robot earned 82 points during the run.
6.3.2. Round 2
The robot successfully started with the light, picked up the supplies,
deposited the supplies, toggled all switches, and pushed the final button.
However, the arm used to push the red button was about ½" too far to the left of
the red button, so no fuel button was pushed or held. The robot earned 74 points
during the run.
24
6.3.3. Round 3
The robot successfully started with the light and picked up the supplies.
However, a heading check of 180 degrees was added into the code where the
heading should have been 0 degrees, so the robot ran into the wrong fuel button
and was unable to continue the run. The robot earned 36 points during the run.
6.3.4. Elimination Rounds
The robot was a 13 seed as a result of the individual competition. In the
first round, the robot successfully started with the light, picked up the supplies,
pushed and held the correct fuel delivery button, and controlled the supplies.
Unfortunately, the robot brushed against the weather station platform on its way
to toggle the switches, so its alignment was off for the rest of the run and it was
unable to toggle any switches or push the final button. The robot earned 62 points
during this run. Another team earned over 80 points during this round, eliminating
G1 from the competition.
6.3.5. Overall
The robot earned an average of 62.5 points per run during the competition.
The robot picked up and deposited the supplies very consistently, and, assuming
the heading check added during the competition resolved the issue of missing the
fuel button, could push and hold the correct fuel button consistently with the final
code. However, the robot could only sometimes toggle the switches correctly,
depending on which course it was on and at what angle it drove from the side
ramp to the lower level. Because of this, pushing the final button was also
inconsistent.
25
6.4. Analysis of Results
During the competition, the robot was very reliable in starting with the light,
picking up the supplies, dropping off the supplies, and driving up and down the ramp. This
was due to using a combination of shaft encoding, RPS, and line following for navigation.
Using the side bumpers when entering the ramp and setting a maximum height for the
main arm with a bump switch also contributed to the reliability. It is assumed, but
uncertain, that the heading check added during the competition would make pressing the
fuel button reliable because of the code’s combination of shaft encoding, RPS, line
following, and CdS readings. However, the robot did not consistently flip the switches or
push the final button. This is due to the navigation to the switches not accounting for
variations in the courses, which could cause the weather station to interfere with the
robot’s travel.
7. Summary and Conclusions
7.1. Summary
Team G1 responded to the Fundamentals of Engineering Honors Space
Administration (FEHSA)’s need to complete several pre-launch tasks in a hazardous
environment by constructing a 9” x 9” x 12” autonomous robot prototype. First, the team
brainstormed several ideas for the chassis, drivetrain, mechanisms, and strategy; used
matrices to determine the best ideas; and modeled a preliminary concept both physically
and electronically. Through mathematical analysis and several performance tests, the
team refined this preliminary idea to create a finalized robot for the final competition.
This robot consisted of a rectangular chassis, a two-wheel, two-skid chassis, two servo-
26
controlled arms, and sensors such as CdS cells, optosensors and microswitches. These
allowed the robot to push switches, pick up and drop off supplies, push and hold the
correct fuel delivery button, and push the final button. The robot performed poorly in the
individual competition, but greatly improved to earn more than half of the available
points during all but one round of the final competition.
7.2. Conclusions
Overall, the robot was successful in completing some, but not all, of FEHSA’s
requirements. This prototype could be improved for full-scale implementation by
increasing the speed of the arm, making the fuel button arm more sturdy, redesigning the
arm frame to allow for easier access to the Proteus, reducing the reliance on electrical
tape in construction through the purchase of more screws, and determining which
expenses could be eliminated due to unused products or a more efficient design. These
changes would allow G1’s design to successfully prepare FEHSA’s rocket for launch.
References
[1]
SP16 Robot Scenario. 2016, February 23. www.carmen.osu.edu.
[2]
2016 FEH Motors Graph. 2016, March 18. www.carmen.osu.edu.
[3]
Individual Competition Preview. 2016, April 1. www.carmen.osu.edu.
[4]
Final Competition Preview. 2016, April 3. www.carmen.osu.edu.
27
28