Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Engineering 1282.01H
Spring 2018
Team B6
Kathleen Albert
Luke Ciccone
Kara Flint
Christopher Wright
R. Freuler 8:00
April 22, 2018
Executive Summary
This report documents Team B6’s project of designing, building, programming, and testing
an autonomous robot for the chance to be chosen as the pit crew robot in the Formula EH Grand
Prix. The robot had to be programmed using a Proteus microcontroller to complete multiple tasks
The team went through a brainstorming process involving decision matrices before
building a mockup out of cardboard to determine what aspects of the design should change before
beginning to build the actual robot. Once the robot was built, it was heavily tested in terms of
design as well as code in order to perfect it for the competition, and modifications were added as
The robot was made up of a laser-cut rectangular acrylic chassis with two wheels which
each had a VEX motor and two skids made of spoons. Many additional pieces were laser-cut out
of acrylic and attached, and the task mechanisms were custom-made and 3-D printed for use with
servo motors. Sensors that were added to the robot include a line following circuit board, shaft
encoders, bump switches, a QR code for use with RPS, and a CdS cell.
The final design worked very well and enabled the robot to complete all of the tasks,
although not always consistently. Many methods of navigation and task completion were
implemented, allowing the team to earn 80+ points out of a possible 100 fairly regularly by the
end of the project, with only fluke accidents causing significantly less than 80 points.
However, in the future, the team would certainly make some changes. The biggest change
would be to use templates in the placement of the robot on the course, which would remove
inconsistency and prevent the aforementioned fluke accidents from happening often, if at all.
ii
Table of Contents
List of Figures ....................................................................................................................................... vi
1. Introduction ...................................................................................................................................... 1
iii
3.3.4 Performance Test 4 ............................................................................................................... 18
5.5 Schedule........................................................................................................................................ 33
References ............................................................................................................................................ 40
iv
Appendix F: Budget ............................................................................................................................. F1
Appendix G: Schedule......................................................................................................................... G1
v
List of Figures
Figure 2.1: A graphic model of the competition course is shown, with each of the tasks labeled. [1]. ........ 4
Figure 2.2: The strategy for what order the robot should run the course is in shown. [1]. ........................... 7
Figure 2.3: A sketch of the chassis and a SolidWorks model of the T-bar are shown................................ 10
Figure 5.1: The SolidWorks model of the entire design is shown.. ............................................................ 26
Figure 5.2: The laser cut main body of the chassis is shown. ..................................................................... 27
Figure 5.5: Pie chart displaying the amount of budget expended across each category.. ........................... 31
Figure 5.6: Line graph showing how the budget was spent over time. ....................................................... 32
Figure B1: Front, rear, and side views of the first mockup of the robot are shown.. ................................. B2
Figure D1: The Proteus Block Diagram of the elctrical connections for this robot. .................................. D2
vi
List of Tables
Table 2.1: The decision matrix for the chassis and drivetrain is shown. ...................................................... 8
Table 2.2: The final weighted decision matrix for the entire layout of the robot is shown. ......................... 9
Table A1: The decision matrix for the chassis and drivetrain is shown again for reference. .................... A2
Table A2: The decision matrix for the car jack mechanism is shown. ...................................................... A2
Table A3: The decision matrix for the fuel crank mechanism is shown. ................................................... A2
Table A4: The decision matrix for the wrench mechanism is shown. ....................................................... A2
Table F1: The Excel table that displays all purchased parts is shown. ....................................................... F2
vii
1. Introduction
In the world today, robots are used to perform countless tasks, from building products in
factories to cleaning up in homes. The engineers who design these robots spend a great deal of
time carefully planning out each step of the process so that their final product can be as perfect as
possible. They brainstorm, build prototypes, run tests, and change the design when necessary.
When these steps are followed carefully, engineers can produce incredible products that help a
This design project was meant to follow the steps as laid out in the previous paragraph, also
known as the engineering design process. The goal was to design, build, and program an
autonomous robot that would act as part of a pit crew and compete for the chance to be chosen for
use in the Formula EH Grand Prix. Through multiple tasks, this robot was tested to determine if it
could be successfully implemented in a real pit crew scenario. Ohio State Research and
Development (OSURED) contacted many first-year engineering students at The Ohio State
University to compete for the chance to be chosen. This team was made up of Kathleen Albert,
Luke Ciccone, Kara Flint, and Christopher Wright. Kara and Kathleen were in charge of
programming the robot; Luke was in charge of building the robot, including soldering electrical
components and designing and putting together the robot; and Christopher was in charge of the
documentation. However, each team member helped out wherever necessary, particularly in the
building and testing of the robot. The team was formed on January 24, 2018, and had ten weeks to
brainstorm, design, build, test, and perfect their robot before the final competition in which the
winning design was chosen. There were four performance tests along the process to track the
team’s progress. Additionally, there was an individual competition on March 30 before the final
1
Section 2, Preliminary Concepts & Ideas, will describe the requirements for the project and
the team’s brainstorming process. Section 3, Analysis, Testing, and Refinements, will explain how
the robot was tested, what was learned from the tests, and what changes were made along the way.
Section 4, Individual Competition, will discuss the individual competition, including the team’s
strategy, performance, and reasons for success or failure. Section 5, Final Design, will describe the
final design of the robot, including sketches, prototypes, and other items such as budget and the
robot’s final code. Section 6, Final Competition, will examine the strategy and results of the final
competition, as well as analyzing the team’s success. Finally, Section 8, Summary & Conclusions,
will provide a summary of the most important details from the report and a discussion of future
improvements that could be made to the robot. After that, the references will be listed and the
2
2. Preliminary Concepts & Ideas
This robot had very specific requirements for its size, materials, and capabilities. It was also
given a list of tasks that it should be able to accomplish. These requirements are listed in the
following subsections, as well as the brainstorming process that the team went through, all the way
from initial concepts to decision making and the first design of the robot.
The robot had to be an autonomous vehicle programmed to drive across the course and
complete the tasks all on its own. It was required to fit in a 9-inch-by-9-inch box on the course, be
less than 12 inches tall, and be controlled by a programmable Proteus microcontroller. To allow
the course control system to recognize it, it had to have a QR code mounted on top of it 9 inches
above the course. Additionally, the team was given a total budget of $160 which it could not
exceed; the parts and services, such as laser cutting and 3D printing, all had to be bought from the
The robot was also required to connect with the Robot Positioning System, or RPS for short.
The robot could use this to know its location in real time and to detect signals that told it which
type of fuel the racecar needed, which affected the direction it needed to turn the fuel crank.
The course to be completed was designed to model a real-life pit crew scenario. It had many
tasks that the robots had to complete in order to determine which one was the best choice. These
tasks are each labeled in Figure 2.1. Each robot was given two minutes to complete the course,
and each task earned it points, adding up to a total of 100. Only in the case of a tie would the total
3
Figure 2.1: A graphic model of the competition course is shown, with each of the tasks labeled [1].
To begin, the robot had to be placed in position 1, detect a light turning on beneath it with a
CdS cell, and react by beginning its run. Then, the rest of the tasks could be completed in any
order, not necessarily in the numbered order shown in the figure. At position 2, the robot had to
deliver a certain type of fuel to the racecar. Through a signal in the RPS, it would have to deliver
either 98 octane fuel by turning the crank 180° clockwise or nitromethane by turning the crank
180° counterclockwise. There was a tolerance of 20° either way to allow for slight error. At
position 3, the robot had to pick up a wrench, secure it, and deposit it in the garage at position 4.
It had to push up a car jack to release the car at position 5, and read a light on the ground at position
6, then determine whether it was red or blue, and press the corresponding button to run a certain
type of diagnostic test on the racecar. If the light was blue, the robot would run a test on the car’s
telemetry sensors, and if the light was red, the robot would run a test on the electronic control unit,
or ECU. Finally, the robot had to press the final button at position 7 to end its run, as well as the
timer.
4
2.3 Initial Brainstorming
Each team member brainstormed ideas for every aspect of the robot on their own, and then
held a meeting to share, discuss, and build upon each other’s ideas in order to come up with the
best plan. The categories that the group brainstormed and discussed were the chassis and
drivetrain, the mechanisms for each of the individual tasks, and the strategy for the order in which
2.3.1 Chassis
The discussion of began with possible drivetrain designs. Among these were drivetrains with
two wheels, four wheels, omnidirectional wheels, and treads. Omnidirectional wheels were a
special type of wheel which could move not only forward and backward like any normal wheel
but also to the right and left by having special rollers built into them. This meant that they allowed
for high maneuverability, but they also each required a motor to run. It was decided that this high
cost could not be justified, so they were removed as a possibility. Treads were also removed,
because it was determined they would not give the robot enough maneuverability. Finally, both
two wheels and four wheels had their merits; four wheels allowed for excellent control and good
maneuverability, and two wheels sacrificed a bit of this, but saved money on motors.
The materials that the chassis should be made from were also discussed. The options were
acrylic, MDF, and aluminum. Acrylic was a favorable choice because it could be laser cut to
provide precisely what was wanted. The MDF could also be laser cut, but the acrylic was thought
to be more durable, and extra acrylic features could be attached with acrylic glue, which is
incredibly strong.
5
2.3.2 Task Mechanisms
There were a multitude of different ideas for the various task mechanisms. One of the
criterion necessary for the task mechanisms was something that could be highly adaptable and
work for multiple of the tasks. A T-shaped bar, similar in design to a field goal post, was discussed
a great deal due to its versatility for use of picking up and dropping off the wrench, hitting the
crank to turn it, and pressing the buttons. A bucket similar in appearance to a bulldozer with a gap
in the middle was also considered for picking up and dropping off the wrench. Additionally, a
single bar was discussed due to the fact that it could have all the same functions as the T-bar, but
with much less precision. A circular wheel was also mentioned for use on the fuel crank, as it could
provide more precision than just hitting the crank with a bar.
When deciding on the course strategy, a short, efficient route was desired, allowing the robot
to go from task to task quickly. There were a couple of ideas, but they all involved the robot going
around the course in a nearly circular pattern, so that it would do one task and then keep going in
the same direction to get the next one, and go in order like that before finally circling back around
to the finish button. The route laid out below in Figure 2.2 was decided upon because it was an
6
Figure 2.2: The strategy for what order the robot should run the course is in shown [1].
To judge each team members’ ideas after discussion, criteria were determined and used to
judge them. Criteria that were applicable for most of the aspects of the robot included cost,
maintenance, and complexity to build. Another criterion that applied to each of the task
mechanisms was how much precision would be required with that method of completing the task.
In order to remove subjectivity and opinion, decision matrices were applied to each of the
aspects of the robot. These involved selecting criteria to judge each possible design compared to a
reference design. A sample decision matrix is shown on the next page in Table 2.1, and the rest of
7
Table 2.1: The decision matrix for the chassis and drivetrain is shown. Similar decision matrices were applied to
each task mechanism as well.
Reference: Four wheels, two drive, box frame C: Two drive wheels, three skids, pentagonal frame
A: Two drive wheels, two skids, box frame D: Four drive wheels, two motors, box frame
B: Two drive wheels, one skid, pentagonal frame E: Three wheels, two drive, box frame
Criterion Reference A B C D E
Cost 0 + + + 0 +
Maneuverability 0 + + + 0 -
Ability to get up the ramp 0 0 0 - + 0
Complexity 0 0 0 - - 0
Speed (friction) 0 0 0 0 + 0
Total 0 2 2 0 1 0
After applying the decision matrices, the ideas for each part of the robot were narrowed
down. The chassis was narrowed down to two wheels with two skids and a box frame or two
wheels with one skid and a pentagonal frame. The task mechanisms were narrowed down to either
a T-bar or a single bar for use in most of the tasks, and possibly a wheel with pegs sticking out for
Three layouts for the entire robot combining various options were created, and these were
further tested with a weighted decision matrix. Weighted decision matrices were very similar to
decision matrices, but each criterion was given a percent weight (out of 100) and then each design
was given a score from 1-5 for each criterion. This allowed the most important criterion to have
more weight in the final decision. Layout idea #1 was a two-wheeled box-shaped chassis with two
skids and a T-bar. Layout idea #2 was a two-wheeled box-shaped chassis with two skids and a
single bar. Layout idea #3 was a two-wheeled pentagonal chassis with one skid and a T-bar. These
8
three layouts were tested with a weighted decision matrix to decide on the best design. This can
Ability to
12.5% 4 0.5 2 0.25 4 0.5
get/deposit wrench
A box chassis with two wheels and two skids and a T-bar for the task mechanisms was
decided upon as the best design. However, after this, a wheel with pegs was added to the design,
as it was decided that it would be a better option to turn the fuel crank. Finally, sketches, CAD
models, and real-life mockups of the robot were created. An orthographic sketch of the chassis and
a CAD model of the T-bar are shown in Figure 2.3. A rough mockup of the entire robot built out
of cardboard and other scrap pieces can also be seen in Figure B in Appendix B.
9
Figure 2.3: A sketch of the chassis and a SolidWorks model of the T-bar are shown.
After building the initial mockup, the team met with members of the OSURED staff to review
it. This mockup can be seen in Figure B1 in Appendix B. Potential problems were pointed out to
the team that needed to be changed. Chief among these was the fact that the chassis of the robot
was very low to the ground, which would have caused the robot to get stuck on the lip of the ramp
when trying to go to the upper level of the course. The chassis was redesigned to ensure that it
would be high enough off the ground to avoid this problem. Another problem was the plan to use
the T-bar to press the buttons. Although it would have been effective, the OSURED staff drew
attention to the fact that applying pressure perpendicular to the servo arm could be harmful to the
motor, so it was decided that the robot could press the buttons by driving into them instead.
The nature of the project and design of the robot required cooperation between components
that perform different operations and process different types of data. Because of this, the goal in
programming was to write code that could be easily modified and followed human logic as closely
as possible. In addition, the program needed to account for error in the robot’s physical
10
performance. Enumerations, global constants, and custom functions were essential to efficient
Components of the robot that received input from the environment returned different
numerical values depending on the state of that component. To simplify the interpretation of this
data, enumerations of all possible states for the components were defined and assigned to their
corresponding numerical outputs. For example, a CdS cell value of less than 0.92 was assigned to
the “RED_LIGHT” state and of more than 1.2 to the “BLUE_LIGHT” state. Constants were
defined for these numerical values so that if they needed to be changed, the adjustment could be
made quickly by redefining the constant. This was done to default values such as left and right
motor powers, the number of encoder counts corresponding to one inch, and the servo angle for
Since much of the robot’s operation would be repetitive, creating custom functions for
moving straight and for turning seemed to be the most efficient structure for constructing the main
function. The arguments of the function for driving straight were percentages for left and right
motor powers and number of encoder counts to reach. When called, this function reset the encoder
counts to zero and set the motors at the percentages specified. The motors remained at this power
only while the average of the two encoder counts was less than the desired number of counts. The
functions for turning right and left followed a similar logic, except when called, only one motor
percentage was specified in the argument and one motor was set to the negative of this percentage.
11
2.7.3 Position Adjustment Functions
To supplement the maneuvering functions, additional functions were needed to execute some
sequence of corrections until a specific condition was met. The preliminary line following function
only executed while the average of the left and right encoder counts was below the amount
specified in the argument. A series of if statements determined the position of the robot relative to
the line based on the reflectivity measured by the optosensors, and a switch case structure set the
left and right motors to powers that would correct the position. This way, the robot would turn
slightly any time it was not centered on the line. Functions that utilize RPS were also written to
correct the position and orientation of the robot on the course. Their only argument was the x-
coordinate, y-coordinate, or heading angle the robot needed to be at. While the RPS value was not
in the desired range, the robot was driven straight or turned slightly in the direction that would
lessen the error in position. This was done by setting the motors to a default percentage for one
encoder count, stopping the motors, and re-checking the RPS value.
In case the robot needed to perform a specialized operation more than once, these operations
were written as their own functions to expedite their implementation into the main function. One
such operation was pausing further execution of the program until the CdS cell detected a change
in light. While this was only required at the start of the robot’s run, it was thought that a light
detection function could be a useful tool for navigation. This way, instead of relying on encoder
counts, the robot could drive until it “saw” a light. Detecting the color of the light based on the
CdS cell reading was also written as its own function that returned a 1 for red light and a 2 for blue
light.
12
3. Analysis, Testing, and Refinements
Once the initial design for the robot was decided upon, there was much more to do in order
to perfect the robot, both in terms of its design and its code. The team analyzed which motor would
be the best choice, the robot went through four performance tests, and the team modified aspects
of its design and programming along the way as necessary changes became apparent.
In order to determine what motor would be most suitable for use with this robot,
measurements on the course and calculations were made to determine the speed and torque
necessary to move the required distance across the course in the allotted two-minute time period.
These speed and torque values were compared to multiple motors’ speed-torque curves to
determine which ones would provide both the speed and the torque necessary.
To determine the speed required, measurements and calculations had to be made. The
measured distance of the chosen path was 336 inches, the wheel radius of a VEX wheel was 1.375
inches, and the total time was estimated to be 1:45 to allow for some error. These values were used
to find a speed required of 3.2 inches per second, using Equation 1 below. (#4/5, showed the
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
𝑠𝑝𝑒𝑒𝑑 = (1)
𝑡𝑖𝑚𝑒
Next, the radius of a VEX wheel, 1.375 inches, was used to find its circumference of 8.64
inches, and this circumference was used to determine that a rotational speed of 22.2 revolutions
per minute would be necessary to complete the course in the desired time. The equations used to
solve for circumference and rotational speed can be seen in Equations 2 and 3.
13
𝑐𝑖𝑟𝑐𝑢𝑚𝑓𝑒𝑟𝑒𝑛𝑐𝑒 = 2𝜋 ∗ 𝑟𝑎𝑑𝑖𝑢𝑠 (2)
𝑠𝑝𝑒𝑒𝑑
𝑟𝑜𝑡𝑎𝑡𝑖𝑜𝑛𝑎𝑙 𝑠𝑝𝑒𝑒𝑑 = (3)
𝑐𝑖𝑟𝑐𝑢𝑚𝑓𝑒𝑟𝑒𝑛𝑐𝑒
Measurements and calculations were also necessary to determine the torque needed to
climb the ramp on the course. The mass of each part that the team could borrow from the FEH
Store was measured, and the masses of other parts that were not currently in stock were estimated.
These masses were added to up to find the approximate total mass of the robot. This approximate
total mass was found to be 1390 grams, which, when converted to weight, was 49 ounces. The
horizontal and vertical components of the ramp were 9 inches and 3 inches, respectively; these
values were used to determine the ramp angle of 18.4°, using Equation 4 below.
𝑣𝑒𝑟𝑡𝑖𝑐𝑎𝑙 𝑐𝑜𝑚𝑝𝑜𝑛𝑒𝑛𝑡
𝑎𝑛𝑔𝑙𝑒 (𝛳) = tan−1( ) (4)
ℎ𝑜𝑟𝑖𝑧𝑜𝑛𝑡𝑎𝑙 𝑐𝑜𝑚𝑝𝑜𝑛𝑒𝑛𝑡
Finally, all of this was combined with force calculations to determine the force necessary
to drive up the hill, and that was used to solve for the torque, which was 32.27 ounce-inches. Since
the robot had two motors, this number was divided by 2 to determine that each motor needed to
provide a minimum torque of 16.1 ounce-inches. The internal friction used in the calculations was
estimated to be 8 ounces, a value provided by the OSURED team. The equations used to find the
After finding both the speed and the torque required of the motors, these values were
compared to the torque-speed curves of the motors that were sold in the FEH Company Store. It
was found that every single motor could produce the required speed and torque, so the decision
had to come down to cost and performance of the motors. VEX-393 motors were chosen because
14
they were durable, had good levels of speed and torque, and were not too expensive. Servo motors
were eliminated because of the extra hassle required in hacking them to allow them to rotate 360°.
Futaba and Igwan motors were determined to be too expensive to be chosen for this robot.
3.2 Explorations
To learn how to code using various methods of navigation, the team participated in three lab
explorations. In each exploration, the team used robot provided by the OSURED staff which had
a CdS cell, bump switches on the front and back, two IGWAN motors, and a line following circuit
board with three optosensors. The team used the Proteus provided by the OSURED staff for each
of the explorations.
In the first exploration, the team learned how to use the Proteus to code for motors, bump
sensors, and light detection using a CdS cell. Light detection was implemented because it allowed
the team to start with the beginning light and detect the correct light color in order to press the
corresponding button at the button board. Bump sensors were also implemented because they
allowed the team to code the robot to drive to a specific location by bumping into walls and other
objects. This was very helpful in coding the robot to run into the wall near the button board to line
it up to press the correct button, as well as after pressing the button to successfully maneuver to
In the second exploration, the team learned how to code the robot for line following and shaft
encoding. Line following was implemented because it allowed the robot to drive straight up to the
wrench to pick it up and the garage to deposit it. Shaft encoding was implemented because it
allowed the team to set the robot to drive a specific distance by telling it to stop after the wheels
turned a specific number of revolutions. This was used in many of the task mechanisms to allow
15
In the third and final exploration, the team learned how to use the RPS and how to log data
with the Proteus. Using RPS was implemented because it allowed the team to code the robot to
drive to a specific location and to check its heading to make sure it was driving in the correct
direction. Data logging was not implemented, but it would have allowed the team to test what went
wrong in any specific run by seeing what the robot read for various values such as its bump sensor
or light detection readings. The RPS was very helpful in allowing the robot to line up with the car
Along the design process, the team completed four performance tests which were monitored
by the OSURED staff. These were meant to keep the team on track for the final competition. Each
performance test had a set task that the robot had to perform, so that the teams could practice each
In the first performance test, the robot was required to begin with the starting light, push up
the car jack, and drive up to the top level of the course. Difficulties were found in the consistency
of the robot; it could successfully complete the required tasks, but not every time. In fact, in the
five official attempts that the team completed, the robot never got it perfect. The robot needed to
be placed very carefully in the starting box to allow it to be successful; if it was placed incorrectly,
it would often run into walls or other objects such as the wrench stand and get stuck or be thrown
off path. This was due to the fact that the robot had no bump switches, so all the distances it drove
were hard coded based on the counts of the shaft encoder. This required a very precise positioning,
and the team’s failure inspired the implementation of bump switches for the future tests.
16
3.3.2 Performance Test 2
The second performance test was more successful than the first. The robot was required to
start with the light, maneuver to the buttons, determine if the light on the floor was red or blue,
and press the corresponding button. The implementation of bump switches allowed the robot to
make decisions on its own once it bumped into walls and other objects, which removed a lot of the
inconsistency. The team did have trouble with the robot’s corners getting stuck on walls from time
to time when it tried to turn, so the corners were filed down a bit to round them out before the
official test. The robot got full points on this performance test within the five tries.
In the third performance test, two new methods of navigations were implemented: line
following and RPS. These were used along with shaft encoding and bump switches to allow the
robot to start with the light, pick up the wrench, and deposit it in the garage on the upper level.
Unfortunately, there was trouble with consistency of both picking up the wrench and depositing
it. The team never got a perfect run in the five attempts allotted. Some of the error in picking up
the wrench stemmed from placement issues in the starting box, as well as an issue where the robot
sometimes would follow the diagonal red-and-white lines next to the wrench rather than the dark
blue line leading up to the wrench as was desired (this can be seen in Figure 2.2 on page 6). The
main issue with depositing the wrench was that the robot could maneuver to the garage very well,
but it would often never back up off the wall. It was supposed to back up after 5 seconds had
passed, but there was an issue with the time-out statement in the code. To fix these errors for the
future, the team decided to further test the line following and the time-out statement.
17
3.3.4 Performance Test 4
The task in the fourth and final performance test was to start with the light, connect to the
RPS, receive the signal for which direction to turn the fuel crank, and maneuver to it and turn it
180° in the appropriate direction. The team had a great deal of trouble achieving success in this
task. In order to turn the crank, the robot had to line itself up perfectly with the fuel crank, which
proved to be a difficult task. The code was written so that the robot would maneuver to the upper
level and turn itself towards the fuel crank. Then, it would use RPS to check its heading, and adjust
to allow itself to drive towards the crank with the correct angle. However, if its position was off,
it would still not line up correctly with the crank. As a result, the team attempted to use geometry
to write code that would allow the robot to check its position before checking its heading, but this
caused more error, and resulted in the team not finishing the performance test with a perfect score.
This performance test left the team with much to perfect for the individual and final competitions.
Due to the nature of laser cut acrylic, once the chassis had been designed, no major design
changes could be made without completely scrapping the original chassis. This meant that the
initial design was very similar to the final design, and the only changes made to the design were
The chassis was designed initially with the intention of allowing every mechanism and part
of the robot to fit and function well. The locations and methods of attaching the motors, encoders,
wheels, and skids were all planned, as well as the Proteus and both of the servo motors needed for
the task mechanisms. However, small changes were still made about how these components fit
together. Holes were included in the initial design to fasten the servo motors in, but they were
attached using hot glue in the actual design. A CdS cell and a piece of cardboard were attached to
18
enable the robot to read the light, and the Proteus was attached with Velcro instead of the initial
Throughout the testing process, parts had to be added to attach bump switches, a circuit board for
line following, and a mount for the QR code to use RPS; the QR code was required even if the
robot did not use the RPS in its code. Small rectangles, hooks, and beams were designed and added
to attach the microswitches, circuit board, and QR code, respectively. Similarly, small support
triangles were added to the skids and the motor walls to provide extra support, and the team
number, B6, was added as the OSURED staff specified during the testing process. Additionally,
some sharp corners were getting caught on walls or the edge of the ramp, so these corners were
filed to round them out. Specifically, the front two corners, including the bump switch platforms,
and the back corners of the two motor walls were filed. These additions and alterations can be seen
below in Figure 3.1. The whole robot can be seen in Figures C1-C3 in Appendix C.
A) B) C)
Figure 3.1: Small modifications to the chassis are shown. A) A wire holder keeps the wires organized and untangled. B) The line following
circuit board hangs underneath the chassis from hooks that were laser cut. C) A bump switch platform is shown, as well a one of the corners
which was filed to a rounder point.
19
Problems involving the drivetrain included that the wheels were not getting enough traction
on the course and the screws attaching the encoders to the motor walls loosening and repeatedly
requiring maintenance. To give the wheels a better grip, rubber bands were added to them, which
proved successful; to prevent the screws from loosening so frequently, nail polish was used as a
thread adhesive for the screws attaching the encoders to the motor walls. These modifications can
Figure 3.2: The drivetrain system with modifications is shown. Nail polish was used as adhesive to prevent the
screws from loosening and rubber bands were added to the wheels to give them greater traction.
The task mechanisms both had modifications which increased the success of completion of
the tasks. The robot had a lot of difficulty lining up its pegs perfectly with the fuel crank, so rubber
bands were added over them. The goal of this was to allow the wheel to be able to turn the crank
without requiring so much precision in the robot’s position. The wrench arm was also lengthened
using cardboard and duct tape to allow the robot to pick up the wrench more consistently without
dropping it. These minor changes can be seen on the next page in Figure 3.3.
20
A) B)
Figure 3.3: Modifications to the task mechanisms are shown. A) Rubber bands allowed the wheel to turn the fuel crank more
efficiently with less precision required. B) The wrench arm was lengthened with cardboard and duct tape to allow it to more
consistently pick up the wrench.
Testing the robot’s performance often had unanticipated outcomes and each revision
revealed new flaws in the program. As the code progressed, several modifications had to be made
to the preliminary functions to correct errors in logic and account for a lack of consistency in the
physical environment. One of these corrections involved increasing the threshold for light
detection to prevent a shadow from initiating the program instead of the starting light. The left and
right motors also did not perform the same when set to the same percentage, so their default motor
powers had to be adjusted to allow the robot to drive straight. Additionally, variations in RPS
readings between courses made it necessary to conduct a series of RPS calibrations before each
21
Precautionary measures were also implemented whenever it became apparent that failure
to complete a certain task could hinder the rest of the robot’s performance. One modification to
the turning function backed up the robot if a bump switch was pressed so it could complete the
turn without getting stuck on a solid object, and bump switch states were included alongside
encoder counts as a condition of all maneuvering functions. The functions that utilize RPS were
enclosed in conditional statements that only allowed execution if the RPS returned a positive value.
This way if the robot was not able to activate RPS on the top portion of the course or it accidentally
ended up in the dead zone near the garage, it would not try to adjust its position using RPS. Finally,
time fail-safes were included in the light detection, maneuvering, and position adjustment
functions. This prevented the robot from getting stuck at any point in the program. If a light could
not be detected or an encoder count could not be reached because the robot was stuck on a solid
object, the program would continue its execution when a specified amount of time had passed.
22
4. Individual Competition
The individual competition took place on Friday, March 30, 2018 at 8:00 AM on the official
course in Room 208 of Hitchcock Hall. The team had three runs to show the OSURED staff how
the project was going with just a week left before the final competition. In each of the three runs,
the methods for picking the course, the button color, and the direction that the fuel crank needed
to be turned was different; for the first run, it was random, for the second run, it was chosen by the
OSURED staff, and for the third run, it was chosen by the team. The scores from the individual
competition were used to seed the teams for the final competition bracket.
4.1 Strategy
The team’s strategy remained the same as the initial strategy determined at the beginning of
the project, at least in terms of the order in which the tasks are completed. Small changes to the
strategy occurred in the calibration of the robot’s RPS before every run in order to prevent error
due to the differences in each course’s RPS system. The team had a minute to prepare its robot
before each run began, so RPS heading and position values were read and stored in the code as
variables to enable the robot to drive to the correct positions and in the correct direction.
4.2 Performance
In its first run, the robot was on Course D, the button color was blue, and the fuel crank
needed to be turned clockwise. The robot earned 57 points. It did most of the tasks very well,
except that it missed the white button at the bottom of the course. This meant that it did not activate
the RPS at the top of the course, and it depended on that to deposit the wrench in the garage and
maneuver to the fuel crank. As a result, the robot did not complete those two tasks successfully.
The robot also missed the car jack by a tiny margin, so it did not earn those points either.
23
In the second run, the OSURED staff chose Course H, blue, and counterclockwise. This was
the robot’s most successful run, earning it 76 points. The main points it missed involved the
wrench, because it almost successfully picked it up, but then dropped it. This resulted in getting
points for picking it up, but none for controlling it or depositing it in the garage. Additionally, the
robot turned the fuel crank farther than 180° and got stuck on the wall while driving down the
ramp, preventing it from pressing the final button. These mistakes all seemed like flukes to the
team, so further testing was required to ensure that they would not occur on the day of the final
competition.
In the third and final run, the team chose Course A, the blue light, and counterclockwise for
the fuel crank. These choices were nearly random, because the robot had very similar performance
on each course and with each fuel crank direction during testing, but the blue light was chosen
because the robot was slightly more consistent with that than the red light. Unfortunately, the robot
never got a chance to run the course, because twice in a row it started before the light actually
turned on. These were declared as false starts, and the team was permitted to have one, but was
disqualified for the second one. This was an issue that had very rarely ever happened in testing,
and never twice in a row. The team made it a priority to determine what caused the false starts and
Most of the mistakes that the robot made during the individual competition were little
mistakes that were not repeated often, which made it difficult to determine what aspects of the
code needed to change. The team continued to test in the week between the individual competition
and the final competition to determine which mistakes repeated themselves and how best to correct
these issues in order to have the best possible performance in the final competition.
24
The biggest change made was to ensure the robot would not false start in the final
competition. The robot was always programmed to read the light value, and start once that value
changes by a certain amount. The team believed that the robot falsely read a change in the light,
so the amount that the light value needed to be changed in order to activate the robot was made
larger. This was meant to ensure that the robot did not sense a tiny change in the light due to
25
5. Final Design
Every aspect of the robot’s final design will be described in detail in the following section.
As previously explained, major overhauls to the robot’s design were not possible due to the laser-
cut acrylic chassis. However, small changes to the task mechanisms, electrical systems, and code
were made, and additional features were added as necessary based on tests and, specifically, the
individual competition. In addition, the budget had to be monitored throughout the process, as well
The final version of the robot can be seen below in Figure 5.1. Each aspect of this design
26
5.1 Design Strengths
One strength of the design was that the robot could change its orientation depending which
task it needed to perform. To flip up the car jack, pick up the wrench, and press the buttons, the
robot would approach with the front to use the wrench arm or the bump sensors. To turn the fuel
crank and to press the final button, the robot would approach with the back to use the crank wheel.
Another strength was that the robot had multiple methods to ensure it travelled in the correct
direction, by using bump sensors to turn at walls, using line following to pick up and deposit the
wrench, and using RPS to check its heading in multiple places, such as when driving towards the
fuel crank.
5.1.1 Chassis
The chassis’ main body was a rectangle made out of laser cut acrylic which was ¼ inch thick,
7.7 inches long, and 5.4 inches wide. It had rectangular holes in it to attach the motor walls and
skids and circular holes to provide places for wires to thread through. In addition, there was a small
rectangular cutout in the front to allow the wrench arm to rotate freely up and down without being
inhibited by the chassis. This is also where the line following circuit board hung from the chassis,
so that it could be centered on the wrench arm to allow it to be used when picking up and depositing
the wrench. Bump sensors sat on small laser-cut platforms that were attached to the front of the
chassis, and the QR code sat on a mount that was attached to the chassis on either of side of where
the Proteus sat. The 3D-printed chassis, without the skids and motor walls, can be seen below in
Figure 5.2.
27
Figure 5.2: The laser cut main body of the chassis is shown.
5.1.2 Drivetrain
The drivetrain was made up of VEX-393 motors, VEX encoders, and VEX wheels. The
encoders and the motors were attached on either side of the chassis’ motor walls with screws and
then attached to each other with the VEX square axles. The wheels were located at the back of the
robot, and two skids with spoons on the bottom were attached to the front of it. The drivetrain can
Figure 5.3: The left motor-encoder-wheel system is shown. The right system is a mirror image.
28
5.1.3 Task Mechanisms
There were two specific mechanisms for completing the tasks: one two-pronged arm for
picking up and depositing the wrench and one wheels with six pegs to turn the fuel crank. These
were both attached to FITEC servo motors to allow for rotation. Both of these parts were custom
designed by the team and 3D-printed by OSURED staff to ensure that they exactly met the team’s
A) B)
Figure 5.4: The two task mechanisms are shown. A) The two-pronged arm to pick up and deposit the wrench.
B) The wheel to turn the fuel crank.
All sensors and motors on the robot were plugged into the Proteus microcontroller. The VEX
motors used for the drivetrain were plugged into the first and second of the Proteus’ DC motor
ports. Two of the servo motor ports were utilized for the FITEC servo motors that controlled the
movement of the arm and the fuel crank wheel. All other sensors and mechanisms, such as the CdS
cell, microswitches, encoders, and line-following optosensors, were plugged into the Flex I/O
ports. Many of the wires were managed using laser-cut wire holders, which kept them organized
29
and out of the way. Information on the specific port that each mechanism was connected to can be
found in Appendix D.
5.3 Code
The final code began with a large amount of information grabbing from the course’s RPS.
Coordinates and headings were stored for the fuel crank, the top of the concrete ramp, the
diagnostic light, and the car jack. After this, the robot was placed in the start box and began
executing code once the start light was detected. First, the car jack was navigated to and raised by
the wrench arm. This was done by using a series of custom straight-moving, turning, and RPS-
coordinate-checking functions. Then, the robot turned toward the wrench stand and used a line
following function to fit the wrench arm into the holes of the wrench. The arm was raised to
retrieve the wrench, and then the robot turned 180 degrees toward the diagnostic button panel. The
indicating light for the diagnostic test was navigated to using the prior mentioned RPS-coordinate-
checking functions and the coordinates stored from the beginning. The color of the light was read
by a custom function that used conditional statements based on the value of the CdS cell. Then,
maneuvering was done based on the state that was returned and the correct test button was held
down along with the white RPS activation button. A while loop made it so that these would be
continually pressed until RPS was activated on the top level or until ten seconds had passed. Then,
the robot navigated to the top level using the concrete ramp and used a custom function to check
for the RPS heading that was grabbed initially. This heading allowed navigation directly to the
garage and line following was once again used to deposit the wrench. Then, the robot backed up
until it was just out of the dead zone that surrounds the garage and turned so that its rear was
directed toward the fuel crank. The fuel crank was then reached and turned using a custom rotation
function that rotated in the direction returned by the course. The robot then navigated back down
30
the concrete ramp and to the final button which was backed into by the fuel crank wheel. The
5.4 Budget
The budget allotted for the Formula EH autonomous robot project was $160. Of this amount,
the team spent $122.81. Figure 5.1 displays the breakdown of how this amount was spent across
Mechanisms, $30.44
Drivetrain, $57.54
Sensors, $4.45
Chassis, $28.48
Fasteners, $1.90
Figure 5.1: Pie chart displaying the amount of budget expended across the robot’s assembly categories.
Nearly half of the amount spent went towards the robot’s drivetrain. This was due to the
expensive yet reliable VEX motor with VEX encoders drivetrain combination. Mechanisms made
up approximately a quarter of the budget due to the use of custom made 3D printed mechanisms
mounted on high-torque FITEC servo motors. The chassis made up about 20% of the budget over
31
the course of three laser cut acrylic orders for precise and sturdy structural elements. Sensors and
The amount spent over time is a good indicator of the course of the project. Figure 5.2 is a
line graph that shows these changes in the amount of budget remaining. The steep drops in the
budget approximately one week apart from each other were combinations of laser cut and 3D
printing orders due to machining day schedules. The largest drop on February 20th was when the
majority of the motors and drivetrain elements were ordered due to them just coming in stock.
Most of the building was finished by early March as seen by the flatline in budget remaining for
the rest of the project. No more purchases were made after the second week of April. Details on
the exact purchases made and the costs of each are displayed in Appendix D Table D1.
$140.00
$120.00
$100.00
$80.00
$60.00
$40.00
$20.00
$0.00
Figure 5.2: Line graph showing how the budget was spent over time.
32
5.4 Schedule
In the initial stages of this project, the team made a schedule for every aspect of the project.
This kept the team on track to finish everything on time and not allow anything to be forgotten.
This schedule listed which team members were primary, secondary, or simply contributors for
each aspect. The team set estimated start and finish dates, estimated hours that would be spent, and
due dates for each aspect. In addition, spaces were left to document the actual start and finish dates,
as well as the actual hours spent. The general trend was that the team overestimated how early they
would begin each aspect and underestimated how many hours each aspect would take. However,
the team finished every assignment on time, usually a day or two early except for aspects of the
project that required large amounts of work and time. The entire schedule can be seen in Appendix
G.
33
6. Final Competition
The final head-to-head team competition took place on Saturday, April 7 at the RPAC at The
Ohio State University. 63 teams competed in three rounds of round robin play before moving to
single-elimination tournament play. The three round robin runs were randomized, while in the
head-to-head tournament the teams were seeded based on the results of the individual competition.
In every round of the final competition, the course, button color, and fuel crank direction was
randomized.
6.1 Strategy
The team had the same strategy for the final competition that it did for the individual
competition. The biggest part of this strategy was to calibrate the robot’s RPS values for important
points in its run by placing it on the course in the various positions and having it grab and save
those coordinates and/or heading angles in the one minute allowed before each run began. This
helped the robot correctly maneuver to some tasks, specifically the fuel crank, as finding the
correct heading angle to line up with the fuel crank proved to be quite difficult.
6.2 Performance
The team performed very well in the three round robin rounds. In the first round, the team
earned 83 points, only missing the car jack and accidentally turning the fuel crank in the wrong
direction. The distance that the robot drove to the car jack was shortened in the code to avoid
missing it in the future rounds. In the second round, the team earned 83 points again, but this time
missed both the fuel crank direction and turned it too far. Nothing in the code was changed, because
the robot was so inconsistent on the fuel crank that the team did not feel comfortable diagnosing
what the exact problem was. In the third round, the team earned 84 points, only failing to turn the
fuel crank far enough and to press the final button. Again, nothing in the code was changed,
34
because missing the final button was a fluke and the team would have required more testing to
After starting with the light, the robot maneuvered to the car jack, but there the front left corner of
its chassis got stuck on the side of the jack, and this stopped it from reaching the encoder counts
that it was programmed to reach. Thus, the robot never stopped trying to reach these encoder
counts, and was stuck there for the remainder of the time allowed. This earned the team only 9
points, which meant they were eliminated because other teams had earned many more. This issue
had occurred during testing, though it was rare, and the team’s attempt to fix it by placing a time-
The team ultimately decided that the biggest reason for the failure in the head-to-head
tournament was due to the fact that no templates were ever implemented in placing the robot in its
calibration positions or in the starting box. This caused the placement of the robot to be quite
inconsistent, and the team believes that the robot was placed too far to the left during its RPS
calibration near the car jack, which is what caused it to run into it and get stuck.
However, this did not discount the fact that the team had great success in performing many
of the tasks in the previous runs. The team successfully implemented many programs, such as line
following, bump switches, light detection, and RPS, to perform many of the tasks very dependably.
Before the robot got stuck near the car jack, it consistently earned most of the points available,
which is a clear success. Specifically, the use of line following for the pickup and deposit of the
wrench, as well as the use of the CdS cell and bump switches to line up with and press the correct
button, were nearly flawless; other than when it got stuck at the car jack, the robot never failed at
35
those tasks on the day of the final competition. With a few modifications, this robot could serve
the role as a pit robot in the FEH Grand Prix very well.
36
7. Summary & Conclusions
In this project, the team designed, built, and coded an autonomous vehicle to compete on a
course for the chance to be chosen as the pit crew robot in the Formula EH Grand Prix. The team
began by brainstorming ideas, drawing sketches, and designing the robot’s chassis, drivetrain, and
task mechanisms, as well as deciding the strategy for the final competition. The team used decision
matrices to make the most unbiased choices for each aspect of the robot’s design. Then, a mockup
of the robot was built out of cardboard and household objects to give the team an idea of where
the various parts could fit. After reviewing the success of the mockup with the OSURED staff, the
team began to build the actual robot, and eventually began testing it with code on the course.
To help learn how to write code for the various sensors, such as bump switches, line
following, shaft encoders, and RPS, the team went through three lab explorations. These involved
the team using robots provided by the OSURED team to learn from experience how to code the
various types of navigation. Additionally, the robot underwent four performance tests to keep the
team on track to perform well in the final competition. Along these stages of the testing,
modifications were made to the design and code of the robot as they became necessary.
The final design included a chassis made out of laser-cut acrylic, two VEX motors along
with encoders and wheels, and two skids made out of spoons. It also included two servo motors
for use with the 3-D printed wrench arm and fuel crank wheel as well as bump switches, a CdS
cell, a line following circuit board, and a mount for the QR code. The team spent $122.81 out of
Only a week before the final competition, the team competed in the individual competition
to show the OSURED team how far the robot had come, to test how prepared it was for the final
competition, and to allow the OSURED staff a chance to seed the teams based on performance for
37
the final competition. The team did well in the individual competition, earning 76 points out of a
possible 100, but there was still plenty to improve for the final competition. The team spent the
week in between the two perfecting the code to ensure the robot did as well as possible in the final
competition.
Finally, the team competed in the final head-to-head competition. In the final competition,
the team performed well during the round robin, but the robot got stuck near the car jack during
the first elimination round, earning only 9 points and removing itself from the competition. The
team believed that this problem was caused by inconsistent placement of the robot during
Although many of the tasks worked quite well, the robot could be improved in many ways
to allow it to be more successful in the future. Main areas of improvement that the team sees are
the crank wheel, the wrench arm, and the use of a template in the robot’s placement.
Although the crank wheel’s six pegs allowed it to turn the fuel crank very effectively, it
proved a very difficult task to ensure that the robot could line up with the fuel crank so precisely
that the pegs would fit in the holes. Accordingly, the team recommends that in the future, a flat,
frictional wheel should be used to allow the fuel crank mechanism to require less precision, which
In addition, the wrench arm was great at picking up and depositing the wrench, but only
after the team extended its length with cardboard was it flawless. Thus, the team recommends that
the wrench arm should be 3-D printed again with longer arms so that it could be more consistent
38
Finally, the team’s worst enemy proved to be the placement of the robot on the course. In
the future, the team recommends the use of one or multiple templates while placing the robot on
the course to calibrate its RPS, as well as placing it in the starting box. This would allow for much
more consistency, and would prevent such issues as getting stuck by the car jack which ended the
39
References
40
Appendix A: Decision Matrices
Table A1: The decision matrix for the chassis and drivetrain is shown again for reference. The best ideas were two
wheels and two skids, two wheels with one skid, and four wheels with two motors and a gear system so all motors were
powered.
Reference: Four wheels, two drive, box frame C: Two drive wheels, three skids, pentagonal frame
A: Two drive wheels, two skids, box frame D: Four drive wheels, two motors, box frame
B: Two drive wheels, one skid, pentagonal frame E: Three wheels, two drive, box frame
Criterion Reference A B C D E
Cost 0 + + + 0 +
Maneuverability 0 + + + 0 -
Ability to get up the ramp 0 0 0 - + 0
Complexity 0 0 0 - - 0
Speed (friction) 0 0 0 0 + 0
Total 0 2 2 0 1 0
Table A2: The decision matrix for the car jack mechanism is shown. The best ideas were found to be a T-bar, a
wedge, and a single bar. Simply driving into the car jack with any part of the chassis was also considered.
A2
Table A3: The decision matrix for the fuel crank mechanism is shown. The best ideas were found to be a single bar
and a two-pronged arm in combination with a T-bar.
Table A4: The decision matrix for the wrench mechanism is shown. The best ideas were found to be a T-bar and
a bulldozer-like bucket with a hole in the middle that the post holding the wrench would fit through.
A3
Appendix B: Mockup
A) B)
C)
Figure B1: The first mockup of the robot is shown. This mockup was meant as a rough estimate of the final design to help get an idea for how the
various parts should fit together to be effective and fit the size requirements. A) The front of the robot is shown, in which the wrench arm can be
seen. B) The back of the robot is shown, in which the wheel to turn the fuel crank can be seen. C) The side of the robot is shown, in which most
aspects of the robot’s design can be seen well.
B2
Appendix C: First Design
Figure C1: The side view of the robot is shown. The beam holding up the QR code mount can be seen in detail, as well as the
beams attached to the skids.
Figure C2: The front view of the robot is shown. The T-bar used to pick up and deposit the wrench can be seen in detail, as well
as the line following circuit board and the bump microswitches.
C2
Figure C3: The rear view of the robot is shown. The wheel used to turn the fuel crank is shown in detail, as well as the motors,
encoders, and wheels.
C3
Appendix D: Electrical Systems
Figure D1: The Proteus Block Diagram of the electrical connections for this robot.
D2
Appendix E: Code
#include <FEHLCD.h>
#include <FEHIO.h>
#include <FEHUtility.h>
#include <FEHServo.h>
#include <FEHMotor.h>
#include <FEHRPS.h>
#include <math.h>
#include <LCDColors.h>
#define PI 3.14159265359
//define number of encoder counts per inch & counts for making 90 degree turns
#define FACTOR_90_R 6.5
#define FACTOR_90_L 6.3
#define COUNTS_1_INCH 18.197186
E2
#define MIDOPTO_BLACK 2.8
#define RIGHTOPTO_BLUE 2.6
#define RIGHTOPTO_BLACK 2.9
#define MIDOPTO_GRASS 3.2
#define RIGHTOPTO_GRASS 3.2
//Declare T-beam servo motor and left and right wheel motors
FEHServo armservo(FEHServo::Servo0);
FEHServo crankservo(FEHServo::Servo7);
FEHMotor leftmotor(FEHMotor::Motor0,9.0);
FEHMotor rightmotor(FEHMotor::Motor1,9.0);
E3
void check_heading(float);
void check_x_plus(float);
void check_x_minus(float x_coordinate);
void check_y_minus(float);
void check_y_plus(float);
void diag_position_adjust(float, float, float);
//declare crank rotation function
int crank_rotation(float, float);
//define grass adjustment function
void get_off_my_grass();
double tstart;
int main(void)
{
//declare variables for touchscreen position
float xposition, yposition;
/*PRELIMINARY CALIBRATIONS*/
RPS.InitializeTouchMenu();
Sleep(0.5);
LCD.WriteLine("CALIBRATE");
//fuel crank
float crankheading, crankX, crankY;
while (frontright.Value() == 1 && frontleft.Value() == 1)
{
E4
crankheading = RPS.Heading();
crankX = RPS.X();
crankY = RPS.Y();
}
LCD.WriteLine(crankheading);
LCD.WriteLine(crankX);
LCD.WriteLine(crankY);
Sleep(1.0);
armservo.SetDegree(70);
Sleep(2.0);
//colored light
float lightX, lightY;
while (frontright.Value() == 1 && frontleft.Value() == 1)
{
lightX = RPS.X();
lightY = RPS.Y();
}
LCD.WriteLine(lightX);
//print checklist
checklist();
E5
Sleep(0.5);
//set initial crank servo position based on the direction it needs to turn
int crankdirection;
if (RPS.FuelType() == 1)
{
crankdirection = CLOCK;
}
if (RPS.FuelType() == 2)
{
crankdirection = COUNTER_CLOCK;
}
switch (crankdirection)
{
case CLOCK:
crankservo.SetDegree(2);
break;
case COUNTER_CLOCK:
crankservo.SetDegree(178);
break;
}
E6
move_straight(R_FULL_POWER, L_FULL_POWER, 1.95 * COUNTS_1_INCH, ONLY_LEFT);
check_y_minus(wrenchY);
//Raise servo arm and lever
int degree = 70;
while (degree < 160)
{
armservo.SetDegree(degree);
degree += 33.3;
Sleep(0.1);
}
Sleep(0.1);
//Back out of car jack space
check_y_minus(wrenchY + 1.0);
//move_straight(-R_FULL_POWER, -L_FULL_POWER, 0.002 * COUNTS_1_INCH,
ONLY_LEFT);
Sleep(0.2);
move_straight(-R_FULL_POWER, -L_FULL_POWER, 4 * COUNTS_1_INCH, ONLY_LEFT);
turn_right(L_HALF_POWER, FACTOR_90_R * COUNTS_1_INCH);
move_straight(R_MANEUVER_POWER, L_MANEUVER_POWER, 0.1 * COUNTS_1_INCH,
ONLY_LEFT);
check_y_plus(lightY + 4);
check_heading(90.0 + heading_calibration);
E7
turn_right(L_HALF_POWER, 0.9 * FACTOR_90_R * COUNTS_1_INCH);
check_heading(heading_calibration);
Sleep(0.2);
int color;
color = color_detection();
LCD.WriteLine(color);
//drive to wall
turn_left(L_HALF_POWER, FACTOR_90_L/3.6 * COUNTS_1_INCH);
move_straight(R_HALF_POWER, L_HALF_POWER + 2, 2 * COUNTS_1_INCH, BOTH);
if (RPS.Y() < (lightY + 2.0))
{
move_straight(-R_HALF_POWER, -L_HALF_POWER, 2 * COUNTS_1_INCH,
ONLY_LEFT);
turn_left(L_HALF_POWER, FACTOR_90_L/5 * COUNTS_1_INCH);
move_straight(R_HALF_POWER, L_HALF_POWER + 2, 2 * COUNTS_1_INCH, BOTH);
}
Sleep(0.3);
//maneuver based on color of light
if (color == 1)
{
rightmotor.Stop();
leftmotor.Stop();
LCD.SetBackgroundColor(RED);
LCD.WriteLine("RED!!!!!!!");
rightencoder.ResetCounts();
leftencoder.ResetCounts();
rightmotor.SetPercent(-R_MANEUVER_POWER);
leftmotor.SetPercent(-L_MANEUVER_POWER);
while((leftencoder.Counts() + rightencoder.Counts()) / 2. < (3.65 *
COUNTS_1_INCH));
rightmotor.Stop();
leftmotor.Stop();
turn_right(L_MANEUVER_POWER, 1.05 * FACTOR_90_R * COUNTS_1_INCH);
}
else
{
LCD.SetBackgroundColor(MEDIUMBLUE);
E8
LCD.WriteLine("BLUE!!!!!!");
turn_right(L_MANEUVER_POWER, FACTOR_90_R * COUNTS_1_INCH);
}
rightmotor.SetPercent(-10);
leftmotor.SetPercent(-10);
E9
}
else
{
turn_left(L_HALF_POWER, 0.8 * FACTOR_90_L * COUNTS_1_INCH);
}
Sleep(0.4);
check_heading(topheading-1.0);
move_straight(R_FULL_POWER, L_FULL_POWER, 15 * COUNTS_1_INCH, ONLY_LEFT);
degree = 170;
while (degree > 100)
{
armservo.SetDegree(degree);
degree = degree - 15;
Sleep(0.1);
}
line_follow_black(11.5 * COUNTS_1_INCH);
armservo.SetDegree(80);
move_straight(-R_FULL_POWER, -L_FULL_POWER, 7 * COUNTS_1_INCH, ONLY_LEFT);
armservo.SetDegree(170);
Sleep(0.5);
/*CRANK MECHANISM*/
diag_position_adjust(crankX, crankY, crankheading);
turn_left(L_HALF_POWER, FACTOR_90_L * COUNTS_1_INCH);
Sleep(0.5);
int checks = 0;
while(checks < 3)
{
check_heading(crankheading);
move_straight(-R_FULL_POWER, -L_FULL_POWER, 5.3 * COUNTS_1_INCH,
ONLY_LEFT);
checks += 1;
}
int position;
Sleep(0.3);
position = crank_rotation(crankX, crankY);
Sleep(1.0);
move_straight(R_FULL_POWER, L_FULL_POWER, 11.25 * COUNTS_1_INCH, ONLY_LEFT);
get_off_my_grass();
\
E10
//drive to ramp based on position at crank
switch (position)
{
case BACK:
LCD.WriteLine("back");
move_straight(R_FULL_POWER, L_FULL_POWER, 17.25 * COUNTS_1_INCH,
ONLY_LEFT);
break;
case FORWARD:
LCD.WriteLine("forward");
move_straight(R_FULL_POWER, L_FULL_POWER, 15.75 * COUNTS_1_INCH,
ONLY_LEFT);
break;
case MIDDLE:
LCD.WriteLine("middle");
move_straight(R_FULL_POWER, L_FULL_POWER, 16.25 * COUNTS_1_INCH,
ONLY_LEFT);
break;
}
/******MISC FUNCTIONS******/
E11
LCD.Clear();
LCD.WriteLine("DID YOU.....");
LCD.WriteLine("- fix the crank");
LCD.WriteLine("- push down the lever");
LCD.WriteLine("- plug in everything");
LCD.WriteLine("- check the optosensors");
LCD.WriteLine("- check the motors");
LCD.WriteLine("- push in servo");
LCD.WriteLine("PRESS BUMP SWITCHES WHEN READY");
LCD.Clear();
LCD.SetBackgroundColor(SCARLET);
LCD.WriteRC("READY TO ROLL", 7, 7);
}
E12
}
}
light = lightcell.Value();
LCD.WriteLine(light);
switch (color)
{
case RED_LIGHT:
return 1;
break;
case BLUE_LIGHT:
return 2;
break;
}
}
E13
{
position = BACK;
}
else
{
position = FORWARD;
}
direction = COUNTER_CLOCK;
//back up from crank and set servo to proper initial position
move_straight(R_MANEUVER_POWER,L_MANEUVER_POWER, COUNTS_1_INCH,
ONLY_LEFT);
crankservo.SetDegree(178);
move_straight(-R_MANEUVER_POWER,-L_MANEUVER_POWER, 1.25 *
COUNTS_1_INCH, ONLY_LEFT);
}
else
{
position = MIDDLE;
}
}
if (RPS.FuelType() == 2)
{
direction = COUNTER_CLOCK;
//if on the side of the fuel crank, switch the direction of rotation
if (RPS.X() < 0 || (RPS.X() < (crankX - 1.28) || RPS.X() > (crankX +
1.28)))
{
if (RPS.X() < crankX - 1.4)
{
position = BACK;
}
else
{
position = FORWARD;
}
direction = CLOCK;
//back up from crank and set servo to proper initial position
move_straight(R_MANEUVER_POWER,L_MANEUVER_POWER, COUNTS_1_INCH,
ONLY_LEFT);
crankservo.SetDegree(2);
move_straight(-R_MANEUVER_POWER,-L_MANEUVER_POWER, 1.25 *
COUNTS_1_INCH, ONLY_LEFT);
}
else
E14
{
position = MIDDLE;
}
}
switch (direction)
{
//turn crank clockwise
case CLOCK:
LCD.WriteLine("clockwise");
degree = 2;
while (degree < 177)
{
crankservo.SetDegree(degree);
degree += 2.5;
Sleep(0.05);
}
E15
{
crankservo.SetDegree(degree);
degree += 5;
Sleep(0.1);
}
}
}
break;
E16
degree = 178;
while (degree > 100)
{
crankservo.SetDegree(degree);
degree = degree - 5;
Sleep(0.1);
}
}
}
break;
}
return position;
}
/******MANEUVERING FUNCTIONS******/
//driving straight
void move_straight(int percentR, int percentL, int counts, int switches) //using
encoders
{
//Declare state variable (whether or not the robot should self-adjust against
a wall)
int state;
E17
};
if (switches == 2)
{
state = ONLY_RIGHT_HIT;
};
if (switches == 3)
{
state = STRAIGHT_ON_SURFACE;
};
if (switches == 4)
{
state = EITHER_HIT;
}
int n = 0;
tstart = TimeNow();
//set motor percentage to start driving
rightmotor.SetPercent(percentR);
leftmotor.SetPercent(percentL);
switch (state)
{
if (frontleft.Value() == 0)
{
rightmotor.Stop();
leftmotor.Stop();
}
break;
E18
case ONLY_RIGHT_HIT:
if (frontright.Value() == 0)
{
rightmotor.Stop();
leftmotor.Stop();
}
break;
}
if (frontright.Value() == 0)
{
rightmotor.Stop();
}
break;
case EITHER_HIT:
if (frontright.Value() ==0 || frontleft.Value() == 0)
{
rightmotor.Stop();
E19
leftmotor.Stop();
}
break;
}
Sleep(0.2);
Sleep(0.1);
//turn right
void turn_right(int percent, int counts)
//using encoders
{
//Declare variable for partial turn adjustment
int partturn;
E20
//Stop motors
rightmotor.Stop();
leftmotor.Stop();
if (frontleft.Value() == 0 || frontright.Value() == 0)
{
LCD.WriteLine("oof");
//Back up off of the wall that was hit
rightmotor.SetPercent(-percent);
leftmotor.SetPercent(-percent);
while ((leftencoder.Counts() + rightencoder.Counts()) / 2. < (1 *
COUNTS_1_INCH));
rightmotor.Stop();
leftmotor.Stop();
//turn left
void turn_left(int percent, int counts)
//using encoders
{
//Declare variable for partial turn adjustment
int partturn;
E21
//Set both motors to desired percent
rightmotor.SetPercent(percent);
leftmotor.SetPercent(-percent);
//Stop motors
rightmotor.Stop();
leftmotor.Stop();
if (frontleft.Value() == 0 || frontright.Value() == 0)
{
LCD.WriteLine("oof");
//Back up off of the wall that was hit
rightmotor.SetPercent(-percent);
leftmotor.SetPercent(-percent);
while ((leftencoder.Counts() + rightencoder.Counts()) / 2. < (1 *
COUNTS_1_INCH));
rightmotor.Stop();
leftmotor.Stop();
//blue line
void line_follow_blue(int counts)
E22
{
//Declare local optosensor value variables
float leftvalue, midvalue, rightvalue;
//Declare local state function value variable for line following
int position;
switch (position)
{
case LINE_ON_RIGHT:
leftmotor.SetPercent(L_GENTLE_POWER + 10);
rightmotor.SetPercent(R_GENTLE_POWER);
break;
case ON_LINE:
leftmotor.SetPercent(L_GENTLE_POWER);
rightmotor.SetPercent(R_GENTLE_POWER);
break;
case LINE_ON_LEFT:
E23
leftmotor.SetPercent(L_GENTLE_POWER);
rightmotor.SetPercent(R_GENTLE_POWER + 10);
break;
}
}
rightmotor.Stop();
leftmotor.Stop();
}
//black line
void line_follow_black(int counts)
{
//Declare local optosensor value variables
float leftvalue, midvalue, rightvalue;
//Declare local state function value variable for line following
int position;
tstart = TimeNow();
E24
switch (position)
{
case LINE_ON_RIGHT:
leftmotor.SetPercent(L_GENTLE_POWER + 15);
rightmotor.SetPercent(R_GENTLE_POWER);
break;
case ON_LINE:
leftmotor.SetPercent(L_GENTLE_POWER);
rightmotor.SetPercent(R_GENTLE_POWER);
break;
case LINE_ON_LEFT:
leftmotor.SetPercent(L_GENTLE_POWER);
rightmotor.SetPercent(R_GENTLE_POWER + 15);
break;
}
}
rightmotor.Stop();
leftmotor.Stop();
}
/********RPS FUNCTIONS*******/
//check RPS heading angle
void check_heading(float heading)
{
//this function is skipped if the robot is in a dead zone or not seen by RPS
if (RPS.X() > -1)
{
tstart = TimeNow();
upperbound=heading+2;
lowerbound=heading-2;
//adjust upper and lower bounds to reflect the same degree measurements
as the RPS
if (upperbound >= 360)
{ upperbound = upperbound - 360; }
if (lowerbound < 0)
{ lowerbound = lowerbound + 360; }
E25
//if acceptable range is positioned over 0 degrees
/*NOTE: the "upper" angle is less than the "lower" angle in this scenario
because
of their relative positions when viewed in the standard unit circle*/
//i.e., the "upper" angle is in the 0-90 degree quadrant, the "lower" in
270-360
if (upperbound < lowerbound)
{
//turn until heading is within 2 degrees of the desired angle or 5
seconds has passed since starting the adjustment
while ((RPS.Heading() > upperbound) && (RPS.Heading() < lowerbound)
&& (TimeNow() - tstart < 5.0))
{
//if angled 180-270 degrees
if (lowerbound - RPS.Heading() < RPS.Heading() - upperbound)
{ turn_left(20, 1);
Sleep(100);
}
//if angled 0-180 degrees
if (lowerbound - RPS.Heading() > RPS.Heading() - upperbound)
{ turn_right(20, 1);
Sleep(100);
}
}
}
{
//turn right if correct heading is to the right
if (RPS.Heading()+(360-upperbound) < lowerbound -
RPS.Heading())
{
turn_right(20, 1);
Sleep(100);
}
//turn left if correct heading is to the left
E26
if (RPS.Heading()+(360-upperbound) > lowerbound -
RPS.Heading())
{ turn_left(20, 1);
Sleep(100);
}
}
{
//this function is skipped if the robot is in a dead zone or not seen by RPS
if (RPS.X() > -1)
{
tstart = TimeNow();
E27
//Reset encoder counts
rightencoder.ResetCounts();
leftencoder.ResetCounts();
E28
{
LCD.WriteLine("checking y minus");
if(RPS.Y() > y_coordinate + 1)
{
//Reset encoder counts
rightencoder.ResetCounts();
leftencoder.ResetCounts();
{
//Reset encoder counts
rightencoder.ResetCounts();
leftencoder.ResetCounts();
}
LCD.WriteLine(TimeNow() - tstart);
}
LCD.WriteLine("I'm not stuck");
}
}
E29
//this function is skipped if the robot is in a dead zone or not seen by RPS
if (RPS.X() > -1)
{
tstart = TimeNow();
//check whether the robot is within an acceptable range
{
LCD.WriteLine("checking y plus");
if(RPS.Y() > y_coordinate)
{
//Reset encoder counts
rightencoder.ResetCounts();
leftencoder.ResetCounts();
{
//Reset encoder counts
rightencoder.ResetCounts();
leftencoder.ResetCounts();
E30
}
}
}
{
//this function is skipped if the robot is in a dead zone or not seen by RPS
if (RPS.X() > -1)
{
tstart = TimeNow();
//check whether the robot is within an acceptable range
{
LCD.WriteLine("checking x minus");
if(RPS.X() > x_coordinate)
{
//Reset encoder counts
rightencoder.ResetCounts();
leftencoder.ResetCounts();
leftmotor.SetPercent(10);
rightmotor.Stop();
leftmotor.Stop();
}
E31
rightencoder.ResetCounts();
leftencoder.ResetCounts();
E32
Appendix F: Budget
Table F1: The Excel table that displays all purchased parts with their ID’s, dimensions, quantity purchased, price per unit,
total price, order number, and date of order.
Part Part ID Dimensions Quantity Price per Unit Total Price Order Date
Laser Cut Chassis LASER01 1 $10.68 $10.68 1 15-Feb
VEX Motor Axle Rod, 3 VEXAX07 3" length 2 $0.75 $1.50 1 15-Feb
VEX Wheels 2.75" WHLVEX01 2.75" diam. 2 $2.50 $5.00 1 15-Feb
Plastic Spoons - 2 $0.01 $0.02 - 15-Feb
VEX Motor 393 MOT11 2 $15.00 $30.00 2 20-Feb
VEX Encoder VEXENC 2 $10.00 $20.00 2 20-Feb
Analog Optosensor SENOPTA 2 $0.77 $1.54 2 20-Feb
Line Following Circuit Board ELEC02 1 $1.00 $1.00 2 20-Feb
6 Pack #6 Screws, Nuts, Washers SCREW10 0.75" screws 1 $0.20 $0.20 3 20-Feb
Motor Terminal Block MOTTERM 2 $0.05 $0.10 4 20-Feb
6 Pack #8 Screws, Nuts, Washers SCREW04 0.75" screws 1 $0.20 $0.20 5 20-Feb
Plastic Spacer 038B Small OD 2 $0.22 $0.44 6 20-Feb
Velcro Strips VELCRO per inch 6 $0.15 $0.90 7 20-Feb
Carboard - 2.0" x 4.0" 1 $0.01 $0.01 - 20-Feb
Microswitch SENSWSS Straight blade, small 1 $1.00 $1.00 8 21-Feb
Laser Cut Attachments LASER01 1 $7.21 $7.21 8 21-Feb
Rubber Bands RBAND03 Wide 8 $0.03 $0.24 9, 10, 11 22-Feb
Shrink Tubing ELEC13 3/32" diameter, per foot 1 $0.20 $0.20 12 26-Feb
High-Torque FITEC Servo Motor MOT14 2 $12.00 $24.00 12 26-Feb
Red Plastic Filter FILTERR 3" x 3" 1 $0.10 $0.10 13 26-Feb
Male Header Strip SENHDRM 36 pins 1 $0.60 $0.60 14 27-Feb
3D Printed Mechanisms 3D 1 $3.23 $3.23 15 28-Feb
Epoxy EPOXY 1 $0.20 $0.20 16 1-Mar
Epoxy EPOXY 1 $0.20 $0.20 17 5-Mar
3D Printed Revised Crank Mechanism 3D 1 $3.09 $3.09 18 7-Mar
Laser Cut QR Mount LASER01 1 $9.78 $9.78 19 7-Mar
Epoxy EPOXY 1 $0.20 $0.20 20 8-Mar
Rubber Bands RBAND03 Wide 4 $0.03 $0.12 21 29-Mar
Rubber Bands RBAND03 Wide 8 $0.03 $0.24 22 4-Apr
Paper - 3" x 3" 1 $0.01 $0.01 - 11-Apr
Crystals - 4 $0.20 $0.80 - 11-Apr
F2
Appendix G: Schedule
Table G1: The schedule of all the tasks is shown, including estimated and actual start and finish times, due dates, estimated and
actual hours, and labels of which team members were primary (P), secondary (S), or just contributors (C) to a task.
Task Est. Est. Due Actual Actual Katie Luke Kara Chris Est. Act.
Start Finish Date Start Finish Hrs Hrs
Final Report Outline 19-Feb 20-Feb 21-Feb 19-Feb 20-Feb C C C P 1.5 1.5
G2
Task Est. Est. Due Actual Actual Katie Luke Kara Chris Est. Act.
Start Finish Date Start Finish Hrs Hrs
G3
Task Est. Est. Due Actual Actual Katie Luke Kara Chris Est. Act.
Start Finish Date Start Finish Hrs Hrs
G4
Appendix H: SolidWorks Models
ITEM NO. PART NAME MATERIAL QTY.
1 Proteus N/A 1
2 Chassis Assembly N/A 1
3 Drivetrain Assembly N/A 2
4 QR Mount Assembly N/A 1
5 Bump Switch Assembly N/A 2
6 Wrench Arm Assembly N/A 1
7 Line Following Assembly N/A 1
8 Crank Wheel Assembly N/A 1
9 CdS Cell Assembly N/A 1
The Ohio State University Dwg. Title: ROBOT ASSEMBLY (2) Inst.: RJF Scale: 1:4 Dwg. No.: R19-25
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/15/18
4
8
1
5
5
4
4
4
4
2
4
8
8
8
7
7
ITEM NO. PART NAME MATERIAL QTY.
1 VEX_Motor N/A 1
5 Motor Wall Acrylic 1
3 VEX Axle Steel 1
4 VEX Shaft Encoder N/A 1
5 Spacer (Small OD) Plastic 1
6 VEX Wheel N/A 1
7 #6 Screw (0.75") Steel 2
8 #8 Screw (0.75") Steel 3
9 #8 Hex Nut Steel 3
The Ohio State University Dwg. Title: DRIVETRAIN ASSEMBLY Inst.: RJF Scale: 3:5 Dwg. No.: R19-5
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/4/18
ITEM NO. PART NAME MATERIAL QTY.
1 Crank Wheel Plastic 1
2 Servo Arm N/A 1
3 FITEC Servo Motor N/A 1
The Ohio State University Dwg. Title: CRANK WHEEL ASSEMBLY (2) Inst.: RJF Scale: 1:1 Dwg. No.: R19-30
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/15/18
3
The Ohio State University Dwg. Title: LINE FOLLOWING ASSEMBLY (2) Inst.: RJF Scale: 1:1 Dwg. No.: R19-31
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/15/18
3
1
1
1
1
The Ohio State University Dwg. Title: LINE FOLLOWING ASSEMBLY Inst.: RJF Scale: 1:1 Dwg. No.: R19-7
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/4/18
ITEM NO. PART NAME MATERIAL QTY.
1 QR Post Acrylic 4
2 QR Beam Acrylic 1
3 QR Square Acrylic 1
4 Wire Holder Acrylic 1
The Ohio State University Dwg. Title: QR MOUNT ASSEMBLY (2) Inst.: RJF Scale: 1:2 Dwg. No.: R19-32
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/15/18
3
.223
.125
1.000
.650
.350
The Ohio State University Dwg. Title: BUMP SENSOR BOTTOM Inst.: RJF Scale: 2:1 Dwg. No.: R19-10
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/4/18
.300
.250
.240
The Ohio State University Dwg. Title: BUMP SENSOR SIDE Inst.: RJF Scale: 8:1 Dwg. No.: R19-11
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/4/18
.450 .500
.050 .050
.450
.500
1.200
The Ohio State University Dwg. Title: CdS CELL CARDBOARD BOX Inst.: RJF Scale: 2:1 Dwg. No.: R19-12
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/4/18
2.24 2.28
.02
1.53
The Ohio State University Dwg. Title: SPOON HEAD Inst.: RJF Scale: 1:1 Dwg. No.: R19-13
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/15/18
0.23
0.40
0.40
The Ohio State University Dwg. Title: SUPPORT TRIANGLE Inst.: RJF Scale: 4:1 Dwg. No.: R19-14
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/4/18
.53
.42
.12
.12
.12
.19
.63
The Ohio State University Dwg. Title: WIRE HOLDER Inst.: RJF Scale: 4:1 Dwg. No.: R19-15
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/5/18
7.700
6.950
6.200
5.950
2.250
1.350
6x .450
.800 6x .230
2x .250 .450 .150 .230
.500
2x .600
2x .230 4x .138
5.400
4.090
3.290
2.540 3.240
1.380
.650
.130 4x .138
1.500 .400
1.990
The Ohio State University Dwg. Title: MAIN CHASSIS Inst.: RJF Scale: 2:5 Dwg. No.: R19-16
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/5/18
.50
.38
.13 .23
.23
2.23 2.11
.13
.38
The Ohio State University Dwg. Title: SKID LEG Inst.: RJF Scale: 1:1 Dwg. No.: 4/6/18
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/6/18
2.70
2.25
1.80
1.35
.90
.45 .23
.25
2.23
2x .14
2.00
1.48
.98
3x .16 .48
.96
1.46
1.96
2.46
The Ohio State University Dwg. Title: MOTOR WALL Inst.: RJF Scale: 1:1 Dwg. No.: R19-18
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/6/18
2.50 .74
.24 .21
R.95
.10 R.53
R.82
R1.05
R.72
.21
330.00°
The Ohio State University Dwg. Title: CRANK WHEEL Inst.: RJF Scale: 1:1 Dwg. No.: R19-19
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/10/18
.50
.24
.18
.06 .12
1.45
1.25
.50
.20
The Ohio State University Dwg. Title: CIRCUIT BOARD HOLDER Inst.: RJF Scale: 2:1 Dwg. No.: R19-20
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/6/18
1.00
.75
.25 .23
5.40
4.95
.45
The Ohio State University Dwg. Title: QR BEAM Inst.: RJF Scale: 1:2 Dwg. No.: R19-21
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/6/18
2.50
1.75
1.50
1.00
.75 .23
6.25
6.00
.50
The Ohio State University Dwg. Title: QR POST Inst.: RJF Scale: 1:2 Dwg. No.: R19-22
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/6/18
.21 R.53 .24
.02 .14
.21
.02
330.00°
The Ohio State University Dwg. Title: SERVO MOUNT Inst.: RJF Scale: 2:1 Dwg. No.: R19-23
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/15/18
2.00
2.30
2.86 3.80
2.99 3.50
2.05
1.75
.30
30.00° .62
.30
The Ohio State University Dwg. Title: WRENCH ARM Inst.: RJF Scale: 1:1 Dwg. No.: R19-24
First Year Engineering Drawn By: B6 Hour: 8:00 Units: INCH Date: 4/15/18