Team 8, Final Report Comp 1

RBE1001 B16: TEAM 8
“The Great EGGscape” Final Project Report
Worcester Polytechnic Institute
15 December 2016
Team Member Signature Contribution %
Mingquan Liu
________________________ 33
Skyler Kim
________________________ 33
Sam White
________________________ 33
Grading: Presentation _____/20
Design Analysis _____/30
Programming _____/30
Accomplishment _____/20
Total _____/100

i
Table of Contents
Table of Contents-----------------------------------------------------------------------------------------------i
List of Figures ------------------------------------------------------------------------------------------------- ii
Introduction ---------------------------------------------------------------------------------------------------- 1
Preliminary Discussion --------------------------------------------------------------------------------------- 2
Problem Statement -------------------------------------------------------------------------------------------- 4
Design Specifications-------------------------------------------------------------------------------------- 4
Preliminary Designs------------------------------------------------------------------------------------------- 6
Drivetrain---------------------------------------------------------------------------------------------------- 6
Potential Lift Mechanisms -------------------------------------------------------------------------------- 9
Potential Game Piece Manipulators --------------------------------------------------------------------13
Sensor Usage-----------------------------------------------------------------------------------------------16
Selection of Final Design -----------------------------------------------------------------------------------18
Final Design Analysis ---------------------------------------------------------------------------------------20
Driveline----------------------------------------------------------------------------------------------------20
Chassis ------------------------------------------------------------------------------------------------------25
Intake--------------------------------------------------------------------------------------------------------27
Lift-----------------------------------------------------------------------------------------------------------28
Programming-----------------------------------------------------------------------------------------------30
Summary/Evaluation-----------------------------------------------------------------------------------------31
Overview of Final Design State-------------------------------------------------------------------------31
Critical Design Review (CDR)--------------------------------------------------------------------------33
Optional Extended Demonstration (OED)-------------------------------------------------------------34
Appendix ------------------------------------------------------------------------------------------------------35
Pictures of Robot’s Final Design State-----------------------------------------------------------------35
Robot Code-------------------------------------------------------------------------------------------------42

ii
List of Figures
Figure I: The Great EGGscape Game Field with lables ------------------------------------------------- 1
Figure II: First driveline design configuration ------------------------------------------------------------ 6
Figure III: Second driveline design configuration-------------------------------------------------------- 7
Figure IV: Third driveline design configuration---------------------------------------------------------- 8
Figure V: 4-Bar lift diagram --------------------------------------------------------------------------------- 9
Figure VI: 6-Bar lift diagram -------------------------------------------------------------------------------11
Figure VII: Roller intake/outtake diagram----------------------------------------------------------------14
Figure VIII: CG & VTC considerations, side view of robot -------------------------------------------22
Figure IX: CG & VTC considerations, top view of robot ----------------------------------------------22
Figure X: CG & VTC considerations, front view of robot ---------------------------------------------22
Figure XI: CG when arm is at maximum horizontal distance -----------------------------------------25
Figure XII: Right side view of robot with 6-Bar lifted -------------------------------------------------35
Figure XIII: Left side view of robot with 6-Bar lifted --------------------------------------------------35
Figure XIV: Front view of robot with 6-Bar lifted ------------------------------------------------------36
Figure XV: Right side of two-stage lift gearing, e=1/15 -----------------------------------------------37
Figure XVI: Left side of two-stage lift gearing, e=1/15 ------------------------------------------------37
Figure XVII: Perspective view of robot with 6-Bar lift down -----------------------------------------38
Figure XVIII: Right side view of robot with 6-Bar lift down------------------------------------------38
Figure XIX: Front view of robot with 6-Bar lift down -------------------------------------------------39
Figure XX: Right side driveline encoder gearing, e=5 -------------------------------------------------39
Figure XXI: Left side driveline encoder gearing, e=5 --------------------------------------------------40
Figure XXII: Drivetrain geometry and motor placement-----------------------------------------------40
Figure XXIII: Wooden, broken cranks for 6-Bar--------------------------------------------------------41

1
Introduction
“The Great EGGscape” is a challenge centered around manipulating wooden EGGs. The
EGGs can be scored in the NEST, a platform elevated 16” above the ground in a 32” tall BARN,
the PEN, a movable, elevated platform, and the COOP, a bounded floor area. The NEST is the
high tier scoring area, the PEN is a middle tier scoring area, and the COOP is the low tier scoring
area. The other major aspect of this challenge is a 30” long ramp that leads to a 32” high PERCH
that is used to suspend robots off of the field. Matches consist of a 20 second autonomous period,
followed by a 120 teleop period. There are various point values for each activity, including
specific point values for objectives completed during autonomous and specific point values for
objectives completed in the last 30 seconds of the match.
Figure I: The Great EGGscape Game Field with lables

2
Preliminary Discussion
Our team began this project by first studying the game rules and the field design, since a
solid understanding of the challenge is critical to success. We began our brainstorming by
considering every possibility of gaining points in different sections of the game. We divided the
game into three section – autonomous, teleop, and endgame – to organize strategies for each
section.
For autonomous section, we decided that the highest priority for this section is to score as
many EGGS into the nest as possible, since the EGGS we put in will be double counted in both
autonomous section and teleop section. In this game, each alliance can have two preloaded
EGGS and there are five EGGS under each PEN for a total of seven easily accessible EGGS.
Keeping this in mind, our highest priority goal for our robot was to push the PEN out of the way,
pick up the eggs under the PEN of our starting position(See figure 1.1), and score them into the
NEST by the end of autonomous section. Other strategies we considered include collecting the
36 EGGS poured from the RAD at the end of autonomous either by our robot’s intake or by
positioning our PEN. Because we can use encoders and bump switches to accurately positon the
robot, our team decided that with any remaining time in autonomous, we would attempt to either
push the PEN under the RAD (in front of NEST) or setting our box under the RAD.

3
,Our strategy for teleop is relatively simple but straightforward. The only things we
wanted our robot to do was collect eggs with our intake consistently and pour them into the
NEST without spilling. Since each alliance’s nest field is on the other alliance’s side of the field
(See figure 1.1), we wanted our robot to be able to score from our side of the field, which meant
the lift needed to be able to reach from one side of the BARN to the NEST on the other side.
This ability of scoring will allow us to save time that would otherwise be spent driving. As an
added bonus, a longer intake allows us to score from a father distance away when we are in front
of our own NEST.
At the endgame section, the only task for our robot is climbing the ramp and hang
on the PERCH. This is a reliable and fast way to score a large amount of points. We estimated
that this will take about 10 to 15 seconds.

4
Problem Statement
Design a robot to pick up and transport EGGs from different position of the game field,
settle them into the NEST and lift itself on the PERCH.
Design Specifications
High priority – The designs aspects that are most import and will be achieved on our robot.
I. Drive
a. Not fall over when the arm is lifting game pieces
b. Quickly move around the field
c. Able to push the PEN
II. Lift
a. Reach height of nest and floor level
b. Reach nest from the other side of field
III. Intake
a. Pick up eggs on the field at any orientation
b. Hold at least eight eggs in the box
IV. Sensors
a. Potentiometer to control height
b. Encoder on each drive train which has relative high resolution of data output
V. Physical Aspects
a. Weight not exceeding 10 lbs
b. Cannot exceed 15” x 15” x 18” in any dimension
c. Keep the center of gravity low and close to robot itself when the lift is extended

5
Medium priority – These design specifications should be attempted. As many of these
specifications should be completed as time allows.
I. Drive:
a. High tractive force with little to no slippage
b. Drive up to the ramp
II. Lift
a. Reach over a robot to score into NEST
b. Lift the PEN to score in the nest
III. Intake
a. Collect the EGGS at the end of autonomous section from the RAD
b. Pick up EGGS swiftly
IV. Endgame of teleop
a. Get up ramp
b. Hang from Perch
Low priority – These design specifications are of low priority to the team. These are only to be
accomplished given through enough time and materials.
I. Physical aspects
a. Weight less than 7 lbs
II. Use pneumatics to lock lift to provide no back drive when robot is hanging from PERCH

6
Preliminary Designs
Our team brainstormed all kinds of designs of different parts of designs (drivetrain, intake,
lift, and sensors) and analyzed the pros and cons of separate combinations of them.
Drivetrain
The options considered for the drivetrain fall under three main designs.
Three Wheels
The first driveline design resembled the robot that all of our labs were completed with,
where two wheels were driven and a third wheel was placed some distance away and would slide
during turns. The virtual turning center of this design in our experience will be located close to
the midpoint between the two driven wheels. This is useful if the game piece manipulator is
located over those wheels for maneuverability, but given the lift considerations this would put
lots of weight on the single wheel, leading to instability.
Figure II: First driveline design configuration

7
Four Wheels
The second design considered was a rectangular drivetrain with four wheels, one in each
corner. The gear ratio and number of motors per side will be determined by calculations, but this
particular design allows for good stability by maximizing the wheel base and wheel track.
Traction is also relatively constant. The virtual turning center in this design will generally be
centered. This allows turning in place, which simplifies point turns and driving.
Figure III: Second driveline design configuration

8
Four Wheels With Two Fixed Wheels That Can Rotate on an Axis
The third design considered was one that was inspired by the driveline of a forklift. That
means that there are four wheels. One set of parallel wheels on the same axis are able to rotate
about the midpoint between those wheels on the axis. The other set of wheels are not driven. For
practical implementation, the wheels that are on the rotatable axis are each powered
independently. This particular design is useful in that it allows for highly smooth and variably
unique driving maneuvers. Specifically, the design allows for a virtual turning center that can be
anywhere from between the non-driven wheels and infinitely outward along the axis of those
non-driven wheels. This design would utilize all high traction wheels, which would be beneficial
for avoiding wheel slippage, which will keep the encoders from getting as off track. This design
was not chosen because of its relative complexity to drive and construct. As well, stability is a
variable factor depending on the rotation of the axis the driven wheels are on.
Figure IV: Third driveline design configuration

9
Potential Lift Mechanisms
4-Bar Linkage
A 4-Bar linkage is a type of mechanism that has four parts: the crank, coupler, follower,
and ground. The crank is powered by a motor while the coupler and follower move with it. For
analysis purposes, the ground is considered to be static. If we were to use a 4-Bar linkage on our
lift, the towers holding the lift is the ground, the lower bar is the crank, the end attached to the
game piece manipulator is the coupler, and the upper member is the follower. The lengths of each
member can be manipulated to change the geometry of the linkages as the crank moves. In
Figure V, the lengths are adjusted to resembled a parallelogram. This would make the
coupler/game piece manipulator remain vertically oriented as the lift is moving upwards.
Figure V: 4-Bar lift diagram
The benefits to a 4-Bar linkage are simplicity, low torque requirements, and the ability to
control the game piece manipulator. The 4-Bar is simple because of the low number of members.
This makes it easy to do free body diagram calculations on the torque needed to lift our game
piece manipulator and the game pieces.

10
The 4-Bar is also more reliable than a one member arm because the follower member above
the crank can help relieve some of the load the crank sees. This makes lifting in a 4-Bar linkage
slightly easier than if you had a one member arm. Lower torque requirements on the motor
means that our speed reduction for the lift does not need to be as low. If the speed reduction were
to be very low, multiple compound stages of gears would be needed. As you increased the
number of stages of compound gears, efficiency loss and the chance for gears skipping increases.
The ability to control the game piece manipulator can also be useful because we can
optimize the game piece manipulator for picking up objects and scoring objects. For example,
when our lift is down, we can position the game manipulator so that it can pick up the game
pieces well. When we lift upwards to score, we can alter the orientation of the game piece
manipulator, such as tilting the manipulator forward, to help score the game pieces into the goals.
The 4-Bar linkage has disadvantages in height and reach. The 4-Bar linkage’s height is
limited by how far off the ground the lowest bar is. Since the lowest bar needs to below the
highest most bar, maximum length of the crank is less than the diagonal between the arm towers
of the robot and the front of the robot. Other lifts can have their limiting member placed at the
top of their arm towers, meaning that other lifts can reach a higher height. Being able to reach
high might be useful when attempting to grab the PERCHs. In a similar manner, the smaller
length of the crank limits how far out the game piece manipulator can stick out. Being able to
have the game piece manipulator stick out in front of the robot would make scoring take less
time since the robot does not have to drive as close to the goal to score.
6-Bar Linkage
A 6-Bar linkage is a type of mechanism that has six parts. It is constructed similar to a 4-
Bar linkage. However, there are two quadrilaterals present in the 6-Bar linkage, where the 4-Bar
linkage has only one quadrilateral. The two quadrilaterals in this type of lift can be thought of as

11
two 4-Bar linkages. Similarly, adjusting the lengths of the members in the mechanism can
change how the linkage changes shape as it lifts. In Figure VI, the lengths are adjusted to
resembled two parallelograms. This would make the vertical bars in the linkage remain vertically
oriented as the lift is moving upwards.
Figure VI: 6-Bar lift diagram
The benefits to a 6-Bar linkage are speed, reliability, height, reach, and the ability to
control the game manipulator. The 6-Bar linkage has benefits similar to the 4-Bar linkage
because the 6-Bar linkage is constructed out of two 4-Bar linkages. This is why the 6-Bar linkage
can have its member lengths manipulated to change how the final stage/game piece manipulator
moves. In addition, the different members in the 6-Bar linkage help relieve the load the motor on
the crank sees in a similar fashion to the 4-Bar linkage.
However, unlike the 4-Bar linkage, the 6-Bar linkage has the advantage of height and
reach. In a 6-Bar linkage lift, the limiting member is the member attached to the top of the arm
towers and to the bottom of the game piece manipulator. Since the member can be placed at the
highest point on the robot, it can achieve a further reach and a higher height than a 4-Bar linkage
can.

12
As a result of being able to reach higher, the lift would need to raise itself a lower
percentage of its maximum height to reach the NESTs. This means that a smaller change in angle
on the crank is required for the game piece manipulator to reach the require height. So if you
were to compare a 6-Bar linkage lift and a 4-Bar linkage lift, assuming a constant speed ratio for
both mechanisms, a 6-Bar linkage would take less time to reach the height of the goal than a 4-
Bar linkage trying to reach the height of the goal.
At the same time, the 6-Bar linkage is limited in its stability and torque requirement.
Since the 6-bar has the ability to move the game piece manipulator far away from the chassis of
the robot. This means that the center of gravity of the robot can be shifted far outward when the
robot is lifting the game piece manipulator. When the lift is fully extended, the center of gravity
is then shifted upward. This can make the robot very unstable, as small movements would make
it easy for the center of gravity to move outside the plane of stability and cause the robot to tip.
In addition to stability, the chance of a toggle occurring is much greater. A toggle is when 3 or
more joints in the mechanism align. If this happens, then it is ambiguous on how the members
will move next. If this were to happen on the lift, it is possible for the lift to lock itself into place.
A 6-Bar linkage can also cause problems meeting torque requirements to lift the game piece
manipulator since you are holding the game pieces farther outward than if you had a 4-Bar
linkage lift. This might mean we have to compromise the speed of our lift with the amount of
game pieces our game piece manipulator can hold.

13
Potential Game Piece Manipulators
Flywheel Launcher
A flywheel launcher would consist of two rollers, spinning in opposite directions in high
speeds. The idea is that there is enough friction force in the wheels that the tangential velocity of
the wheels can be transferred to an EGG as it is passed through the two wheels. This would result
in the EGG flying across the field, hopefully into the goal.
The benefits of the flywheel shooter is the increased ability to score. With a flywheel
shooter, the robot could theoretically score from across the field. This is a huge benefit because
while other robots would need to go back and forth between the EGGs and the goal, a robot with
a flywheel shooter would be able to stay near the EGGs and continuously score. The motor
speeds of the flywheel launcher could also be slowed or sped up accordingly to adjust for shorter
or longer shots.
The disadvantages of the flywheel shooter is the fine tuning aspect. In order for a flywheel to
work effectively and quickly, it would need to be fined tuned in many different fields. In order to
make the flywheel be able to shoot EGGs consistently, the launcher would have to have to
uniformly apply the friction of the flywheels onto the EGGs, no matter the orientation. The
motors of the flywheel and the gearbox would also have to be optimized so that it has enough
torque to move the flywheel with a high speed ratio. The motors would also have to handle
moving the wheels while EGGs are being passed through them since shooting an EGG would
greatly slow the speed of the flywheel.

14
Roller Intake/Outtake
A roller-styled intake would be a roller that pulls EGGs into a basket. This basket/roller
manipulator would then be lifted up to score. The roller would then be used to remove the EGGs
from the holding area into the goal. The removal of EGGs from the box would only work if the
box was slanted in a way such that the EGGs naturally rolled toward the roller, as in Figure VII.
The actual roller would be rubber bands stretched between two gears or sprockets. This design
was inspired by the 2015-2016 VEX game, where a similarly designed roller handled round foam
balls very well because the rubber bands can deform around the object to a larger extent
compared to tread, flaps, or wheels.
Figure VII: Roller intake/outtake diagram

15
The benefits of a roller intake/outtake is simplicity and lightweight. With a roller
intake/outtake, only one moving component is required. This is because the same component is
used to pick up EGGs and release them into the goal. Having less moving components would
make the device simpler to construct, test, and revise. The lower number of components in the
subsystem can also mean that we can use less pieces to build it. This means the roller
intake/outtake has the potential to be very light, which would be useful since the lift motors
would see less load.
The downsides to a roller intake/outtake are jamming and entanglement. There is a
possibility that the roller will get stuck on certain orientation of eggs. For example, the roller
could get stuck on the EGGs standing upright, but work perfectly on EGGs lying on the ground.
For entanglement, there is a possibility of the material on the roller getting caught on corners of
game elements, such as the PEN. This may damage the roller and make it difficult for the robot
to pick up EGGs again.

16
Sensor Usage
Encoders
We considered all possible position we may need encoders for our autonomous section. First
of all, we definitely need encoders for measuring how many turns our wheel actually has moved
so that we can have accurate driving. This will allow us to drive in straight lines in both
autonomous and in teleop with less drift. In autonomous, encoders will also allow more reliable
and therefore more complex maneuvers, where time will no longer be the dependent dead
reckoning factor. While encoders are still a dead reckoning sensor because they will gradually
drift over time, by having the encoder geared to rotate at more rotations per rotation of the
wheels, we will gain a factor of accuracy in the relationship between the distance traveled by the
wheel and the number of counts of the encoder. A standard VEX encoder has 360 counts per
revolution, so with a 2.75” wheel, that is slightly less than 42 encoder counts per inch traveled by
the robot. If the encoder is geared to travel five revolutions for every revolution of the wheel,
now there is 208 encoder counts per inch of wheel travel. So depending on the ratio of gears
chosen, the encoder can become more accurate. Limitations to this would be slop in the gears
creating inaccuracy, as well as exceeding the max RPM of the encoder.
Potentiometer
In our game strategy, reaching the NEST through the BARN was a high priority, so we
definitely would want to know for autonomous coding where the arm is by using a
potentiometer. This also allows the usage of PID control on the arm’s position, which is a more
accurate control of the arm not only in reaching the desired position but also in maintaining that
arm position.

17
Bump switch
Because the EGGs being picked up in autonomous are underneath the PEN, a bump switch
can be used to detect when the robot contacts the pen. The robot could then know when to turn
the intake on. The bump switch can also be used in conjunction with the encoders to verify that
the robot is reaching specific obstacles that can be bumped into.

18
Selection of Final Design
Four Wheel Drivetrain:
The design with four wheels arranged in a rectangle was chosen for its good stability and
relatively simple design and construction. The design for the driveline with three wheels was
ruled out because of concerns over the intrinsic instability of such a drivetrain. The design with
four wheels with two fixed wheels that can rotate on an axis (similar to the drivetrain found on a
forklift) was not chosen because of its relative complexity to drive and construct. As well,
stability is a variable factor depending on the rotation of the axis the driven wheels are on.
Lift: 6-Bar linkage
A 6-Bar linkage for a lift was chosen primarily for being able to quickly reach the NEST
with a 6-Bar linkage, we have a longer reach than with a 4-Bar linkage. This means that we do
not have to drive as far to score in our NEST. We also figured that it would be possible to have a
reach long enough to be able to score in your coalition’s NEST from the other side of the BARN.
That is, the blue robot would be able to reach through the red side of the BARN and into the blue
NEST. This would greatly decrease the time it takes to score as you do not need to cross the field
every time you need to score. Finally, the extra reach/height on the 6-Bar linkage would assist
having our robot reach the bar on the PERCHs without having to drive off the ramp. Being able
to grab the PERCH bar from the ramp without driving off would allow us to hang without the
chance of our robot missing and damaging itself.

19
Game Piece Manipulator: Roller Intake/Outtake
We decided to go with the roller intake/outtake because of the simplicity of the design.
With a roller intake/outtake, we only have one moving component that both picks up EGGs and
releases them into goals. With a flywheel launcher, we would have to use motors for moving the
wheels and more motors for getting the EGGs to the wheels. We also believed that we would not
be able to fully tune the flywheel launcher to be able to score properly. Finally, we believed with
the roller intake/outtake’s simplicity, we would have enough time to fine tune it to prevent the
roller from getting jammed or getting caught on field elements. The other important
consideration was that if we used a flywheel launcher to score EGGs, then there would be no
need for a lifting mechanism. Since this is required by the rules, the flywheel design became a
non-option.

20
Final Design Analysis
Driveline

22
Center of gravity considerations
Prior to robot construction, the robot was constructed in Autodesk Inventor. The parts in
Inventor match the parts used on the actual robot. From the digitally constructed robot, we can
calculate the center of gravity of the robot. The center of gravity is calculated to be 6.02 inches
from the back of the robot, 7.162 inches from the right side of the robot, and 3.127 inches off the
ground.
Figure VIII: CG & VTC considerations, side view of robot
Figure IX: CG & VTC considerations, top view of robot
Figure X: CG & VTC considerations, front view of robot

24
Virtual Turning Center:
The drive base only uses omniwheels, meaning that the virtual turning center of the robot
is on the same vertical axis as the center of gravity. The benefits to having the virtual turning
center at the center of gravity is that the center of gravity is relatively close to the center of the
robot. Having the virtual turning center near the center of the robot makes it easier to control the
position of the robot when programming turns in autonomous.

25
Chassis
Stability
Since the robot has a long reach, there could be issues when the robot is lifting with too
much weight. Using the CAD model, we calculated that if the robot weight 8.5 lbs, and the game
piece manipulator takes up 2 lbs of that, then the robot can hold 4.5 lbs before the center of
gravity falls outside the robot’s plane of stability. The plane of stability is formed by the point of
contact between all of the robot’s wheels.
Figure XI: CG when arm is at maximum horizontal distance

26
Geometry
The robot was designed to have the longest arm possible. This is the diagonal for a
triangle with legs 15 inches and 18 inches. In order to achieve this, the front of the robot had to
have room for the arm. Assuming the arm width would be 1 inch, the longest possible drive base
width is 15 inches, with the wheels 12.25 inches apart. This allows us to have the longest plane
of stability along the side of the drive train, which would help in keeping the robot upright when
lifting.

30
Programming
We would like to have accurate control over the position of our lift mechanism and our
autonomous driving. Since we have one motor on each side of the lift, two potentiometers were
added to measure the arm position and keep two arms at the same level. Proportional and
derivative control was used to prevent the weight of arm from back driving the motor and keep it
at the desired position. For consistent driving in autonomous, two encoders were added to each
front wheel for controlling the movement. To maintain accuracy, we geared the encoders so that
for every rotation of the drive’s wheel, the encoder would make five full revolutions so that we
have five times of the resolution. Also, for the drive control, proportional and derivative control
was used. The program was organized into several files and functions in order to increase
readability. In some cases, normal motor values (0 to 180) were mapped from (-90 to 90) also to
increase readability.

31
Summary/Evaluation
Overview of Final Design State
The final state of the robot’s design was generally acceptable. All high priority items
were achieved or exceeded with only minor exceptions. Features that exceeded expectations
include having a weight of 8.1 lbs and scoring 18 EGGs into the NEST. We had originally
planned the robot to be 8.5 lbs and only be able to score 8 EGGs into the NEST.
Goals that were not achieved were speed, reach, and hanging. While the robot speed was
sufficient, it would have been useful to have greater speed. Navigating the field to pick up and
score EGGs took a considerable amount of time due to the drive’s slow speed. The robot was
also unable to score through our opponent’s side of the BARN and into our NEST. The robot
could only do this partially, as described in the CDR section. Our robot was also unable to drive
up the lift, and as a result, was not able to hang itself onto the PERCH. There was also no
mechanism for lifting the PEN into our NEST.
Noticeable features of the final robot that were not in the initial design are the cranks on
the 6-Bar lift, speed ratio of the intake, and encoders on the drive. Both the cranks on the 6-Bar
lift broke before the CDR, and had to be quickly repaired with metal instead of wood. The
damage to the lift was caused by an error in reading the potentiometer. When we were
troubleshooting, we found that the output of our potentiometers on the lift had completely
changed after we switched batteries. We concluded that the potentiometers performance was
related to battery life and decided to remove the methods in the code regarding the
potentiometers.

32
The speed ratio on the roller was changed from 3 to 5/3. While the intake was functional
with a speed ratio of 3, this was changed to a ratio of 5/3 to prevent frequent stalling of the 269
motor. While it was believed that there would be an issue with the roller not moving fast enough
to match the drive, the slow speed of the drive counteracted this and allowed us to still pick up
EGGs with ease. See Appendix for all photos of changes.
The initial design also called for two encoders, with one for each drive train. However,
prior to the CDR, both encoders on the robot stopped working. Switching ports and programs did
not solve the problem. Since we were only able to get one replacement encoder, we had to
modify the autonomous methods to work one encoder. This meant that the robot relied purely on
the values being sent to the motors to drive straight. Since this is less than ideal, the robot very
rarely drove perfectly straight or made consistent turns. To fix this, we had the robot align itself
with landmarks on the field, such as the COOP walls and the walls of the field.

33
Critical Design Review (CDR)
The robot’s performance at the CDR was satisfactory. The robot was able to pick up a
large number of EGGs and score them into the NEST with teleop controls.
The autonomous routine showed off in the CDR had the robot collect the EGGs
underneath the nearby PEN. After picking up the EGGs, the robot drives over to the front of its
NEST for scoring. The robot did not score the EGGs it was holding. The robot ran this
autonomous routine starting on the right blue starting tile. The justification for this autonomous
is that it moves the PEN in autonomous gaining five points and collects a decent amount of
EGGs to be scored during the teleop period. The autonomous routine also places the robot closer
to where the EGGs are going to be released and closer to the NEST where efforts will be focused
during teleop.
The robot also demonstrated its ability to partially score over our opponent’s NEST and
into our coalition’s NEST. The robot attempted to score four EGGs into our NEST this way, and
two of the four EGGs were scored. The remaining two EGGs were placed in our opponent’s
goal. This is below satisfactory since the robot would increase the score of our opponents just as
much as our score would increase.
The robot had trouble traversing the carpet near the blue NEST. This is because we did
not take into account the inconsistencies that were allowed on the field. Specifically, we did not
take into account the unevenness or the inconsistent material of the carpet. Carpet string also
frequently got caught in the gears on our driveline and caused them to become unmeshed. This
inconsistency is what prevented the robot from scoring the EGGs it had picked up in the
autonomous routine.

34
Optional Extended Demonstration (OED)
The robot’s performance at the OED was above average, with the robot having 4 wins
and 0 losses. The average number of EGG’s dumped into the NEST per attempt was about 10
EGGS, with our max being 18 EGGS. Our cumulative score was 657 points. Our highest
individual match score was 218 points.
The two major objectives we were able to achieve at the OED were multiple autonomous
routines and scoring autonomous routines. The autonomous routine we showed off in the CDR
set up our robot for scoring in the NEST. We decided that since our autonomous routine has the
robot near our coalition’s PEN, the robot should just score the EGGs it picked up into the PEN.
This gave us an autonomous score of 66, which is 5 EGGs x 6 points + 2 EGGs x 3 points. This
is considerably better than an autonomous score of zero.
The robot was also able to run autonomous routines from different starting tiles on the
field, making the robot able to play the game as either coalition. Previously, for the CDR, the
robot’s autonomous routine only worked from the right blue starting tile. Over the course of the
OED, we were able to mirror the autonomous routine for the left red starting tile. The final
version of the robot has two autonomous routines that work on both red and blue starting tiles.

35
Appendix
Pictures of Robot’s Final Design State
Figure XII: Right side view of robot with 6-Bar lifted
Figure XIII: Left side view of robot with 6-Bar lifted

36
Figure XIV: Front view of robot with 6-Bar lifted

37
Figure XV: Right side of two-stage lift gearing, e=1/15
Figure XVI: Left side of two-stage lift gearing, e=1/15

38
Figure XVII: Perspective view of robot with 6-Bar lift down
Figure XVIII: Right side view of robot with 6-Bar lift down

39
Figure XIX: Front view of robot with 6-Bar lift down
Figure XX: Right side driveline encoder gearing, e=5

40
Figure XXI: Left side driveline encoder gearing, e=5
Figure XXII: Drivetrain geometry and motor placement

41
Figure XXIII: Wooden, broken cranks for 6-Bar

42
Robot Code
Main.ino
#include "Drive.h"
#include "Intake.h"
#include "controllerDrive.h"
#include <DFW.h>
#include <Servo.h>
//Main.ino:
// -Handles setup and main loop
// -Initiates different subsystems
// -Allows joystick control
// -Limits autonomous and teleop periods
//Objects and variables for the joystick control
int ledpindebug = 13;
DFW dfw(ledpindebug);
void setup()
{
//Initiate motors // Set up the controller
pinMode(22, INPUT);
initController();
driveInit(); // Set up the drive / intake / lift systems
intakeInit();
liftSetup();
}
void loop()
{
autonomousM(20); //time in seconds to run autonomous code
teleop(120); //time in seconds that teleop code will run
}
void autonomousM(volatile unsigned long time) // function definition from RBE1001
Template
{
while (dfw.start() == 1) // waits for start button
{
Serial.println("waiting for start");
dfw.update();
delay(20);
}
unsigned long startTime = millis(); // sets start time of autonomous
time = time * 1000; // modifies milliseconds to seconds
while ((millis() - startTime <= time) && (dfw.select())) // compares start time to
time entered in the autonomous function and
{
// The select button can be used to skip the autonomous code.
// Enter Autonomous User Code Here
Serial.println("Autonomous"); //prints Autonomous over serial (usb com port)
//autonomous(); // choosing from different autonomous
autonomous2();
dfw.update();//used for autonomous skip
delay(20); //delay to prevent spamming the serial port and to keep servo and dfw
libraries happy
}

43
}
void teleop(unsigned long time) // function definition from RBE1001 Template
{
unsigned long startTime2 = millis(); // sets start time of teleop
time = time * 1000; // modifies milliseconds to seconds
while (millis() - startTime2 <= time) // compares start time to time entered in the
teleop function
{
controllerDrive(); //use controller
Serial.println("TeleOp"); //prints Teleop over serial (usb com port)
delay(20); //delay to prevent spamming the serial port
}
exit(0); // exits program
}

44
ControllerDrive.h
#include <DFW.h>
#include "Drive.h"
#include "Intake.h"
void controllerDrive(); // The default running will be shown in the loop to
control the robot
void liftHandleCheck(); // reading the left L1 L2 value to control the lift
void intakeHandleCheck(); // Reading the right R1 R2 to control the intake
void initController(); // Set up the controller

45
Controller.Drive.ino
#include <DFW.h>
#include "Drive.h"
#include "Intake.h"
#include "controllerDrive.h"
//ControllerDrive.ino:
// -Handles all driver control joystick mapping.
// -Calls methods in subsystem classes to control them.
// -Holds method for initiating DFW
//Holder variables for intake and lift methods.
int liftControlCase =0;
int intakeControlCase =0;
void controllerDrive() // The default running will be shown in
the loop to control the robot
{
dfw.update();
cruise(dfw.joysticklv() - 90, dfw.joystickrv()-90); // Controls drive motors
liftHandleCheck(); // Controls lift motors
intakeHandleCheck(); // Controls intake motor
}
void liftHandleCheck() // reading the left L1 L2 value to
control the lift
{
dfw.update();
Serial.println(dfw.l1());
if(dfw.l1()==0&&dfw.l2()==0) // If both of the lift buttons are
pressed
liftControlCase =0;
else if(dfw.l1()==0) // If top lift button is pressed, we want
lift to go up
liftControlCase =1;
else if(dfw.l2()==0) // If bottom lift button is pressed, we
want lift to go down
liftControlCase =2;
else
liftControlCase =0;
liftButControl(liftControlCase); // Calls lift controls with specific
state we want
}
void intakeHandleCheck() // Reading the right R1 R2 to control the
intake
{
if(dfw.r1()==0&&dfw.r2()==0) // If both intake buttons are pressed, do
nothing
intakeControlCase =0;
else if(dfw.r1()==0) // If top intake button is pressed, run
intake inward
else if(dfw.r2()==0) // If bottom intake button is pressed, run
intake outward
else // If no intake button is pressed, do
nothing
intakeButControl(intakeControlCase); // Run intake as specified

46
delay(20);
}
void initController() // Set up the controller
{
dfw.begin(9600, 1);
dfw.update();
while (dfw.start() == 0) //waits for controller to init
{
Serial.println("init");
dfw.update();
delay(20);
}
}

47
AutonomousLogic.ino
// AutonomousLogic.ino:
// -Contains all autonomous routines
// -3 Routines:
// -Blue side autonomous
// -Red side autonomous
// -Middle starting zone autonomous
int currState = -1; // Every state start at -1 state
int armPos = 960;
// Blue Auto:
// -Start: Right blue starting tile
// -Picks up EGGs under PEN
// -Scores EGGs in PEN
// -Minimum 3 points (1 EGG)
// -Maximum 66 points (2 preloaded EGG, 5 autonomous scored EGGs)
void autonomous()
{
switch(currState)
{
case -1: // Setup state, then goes to state 0
forwardDrivePos(5800); // set up moving forward 5800 ticks and change state
currState = 0;
break;
case 0: // Robot moves forward out of starting tile, then
goes to state 1
if(followDrive())
{
turnDesired(-2700); // set up turning left
resetError();
currState=1;
delay(200);
}
break;
case 1: // Robot turns left, then goes to state 2
if(followDrive())
{
cruise(-90,-90); // back the robot up against wall for an accurate
angle
delay(650);
cruise(0,0);
forwardDrivePos(4500); // Setup moving forward
resetError();
currState = 2;
delay(200); // Wait 0.2 seconds before continuing on with routine
(to prevent jerky movements)
}
break;
case 2: // Robot moves forward towards PEN, then goes to state
3
if(followDrive())
{
turnDesired(2700); // set up turning right
resetError();
currState =3;
delay(200);

48
}
break;
case 3: // Robot turns right toward PEN, then goes to state 4
if(followDrive())
{
cruise(-90,-90); // back the robot up into COOP border for an accurate
angle
delay(400);
cruise(0,0);
forwardDrivePos(700); // set up driving forward
resetError();
delay(200);
currState =4;
}
break;
case 4: // Robot drives forward to PEN, then goes to state 5
if(followDrive())
{
forwardDrivePos(4500);// set up driving forward
resetError();
currState =5;
delay(200);
}
break;
case 5: // Robot drives forward and pushes PEN and EGGs, then
goes to state 6
if(followDrive())
{
forwardDrivePos(3300); // set up for driving forward
currState =6;
resetError();
delay(200);
}
break;
case 6: // Robot drives forward with intake on, picking up EGGs,
then goes to state 7
runIntake(); // Run intake motor to pick up EGGs
delay(200); // Let intake roller get up to speed
if(followDrive())
{
currState = 7;
forwardDrivePos(-2000); //set up for driving backward
resetError();
delay(200);
}
break;
case 7: // Robot drives backwards from PEN, then lifts upward,
runIntake(); // keep the intake running and move the arm up
liftButControl(1);
delay(60);
liftButControl(0);
if(followDrive())
{
currState = 8;
forwardDrivePos(4500); // set up for driving forwards
resetError();
delay(200);

49
}
break;
case 8: // Robot drives forwards towards PEN, then goes to state
9
if(followDrive())
{
resetError();
currState = 9;
delay(100);
}
break;
case 9: // Robot runs intake outward and stops moving
outPutIntake();
cruise(0,0);
break;
default: // Robot doesn't move if something with the state machine
goes wrong.
cruise(0,0);
break;
}
}
// Blue Auto:
// -Start: Left blue starting tile
// -Picks up EGGs under PEN
// -Scores EGGs in PEN
// -Minimum 3 points (1 EGG)
// -Maximum 66 points (2 preloaded EGG, 5 autonomous scored EGGs)
void autonomous2()
{
switch(currState)
{
case -1: // Setup state, then goes to state 0
forwardDrivePos(5800); // set up moving forward 5800 ticks and change state
currState = 0;
break;
case 0: // Robot moves forward out of starting tile, then
goes to state 1
if(followDrive())
{
turnDesired(2700); // set up turning right
resetError();
currState=1;
delay(200);
}
break;
case 1: // Robot turns right, then goes to state 2
if(followDrive())
{
cruise(-90,-90); // back the robot up against wall for an accurate
angle
delay(650);
cruise(0,0);
forwardDrivePos(4500); // Setup moving forward
resetError();
currState =2;

50
delay(200); // Wait 0.2 seconds before continuing on with
routine (to prevent jerky movements)
}
break;
case 2: // Robot moves forward towards PEN, then goes to
state 3
if(followDrive())
{
turnDesired(-2700); // set up turning left
resetError();
currState =3;
delay(200);
}
break;
case 3: // Robot turns left toward PEN, then goes to state 4
if(followDrive())
{
cruise(-90,-90); // back the robot up into COOP border for an
accurate angle
delay(400);
cruise(0,0);
resetError();
delay(200);
currState =4;
}
break;
case 4: // Robot drives forward to PEN, then goes to state 5
if(followDrive())
{
resetError();
currState =5;
delay(200);
}
break;
case 5: // Robot drives forward and pushes PEN and EGGs, then
goes to state 6
if(followDrive())
{
forwardDrivePos(3300); // set up for driving forward
currState =6;
resetError();
delay(200);
}
break;
case 6: // Robot drives forward with intake on, picking up
EGGs, then goes to state 7
runIntake(); // Run intake motor to pick up EGGs
delay(200); // Let intake roller get up to speed
if(followDrive())
{
currState = 7;
forwardDrivePos(-2000); //set up for driving backward
resetError();
delay(200);
}
break;

51
case 7: // Robot drives backwards from PEN, then lifts upward,
runIntake(); // keep the intake running and move the arm up
liftButControl(1);
delay(60);
liftButControl(0);
if(followDrive())
{
currState = 8;
forwardDrivePos(4500); // set up for driving forwards
resetError();
delay(200);
}
break;
case 8: // Robot drives forwards towards PEN, then goes to
state 9
if(followDrive())
{
resetError();
currState = 9;
delay(100);
}
delay(20);
break;
case 9: // Robot runs intake outward and stops moving
outPutIntake();
cruise(0,0);
break;
default: // Robot doesn't move if something with the state
machine goes wrong.
cruise(0,0);
break;
}
}
// Blue/Red Auto:
// -Start: Right red starting tile OR left blue starting tile
// -Maximum 0 points
// -Interrupts opponents autonomous routine
void autonomous3() // our Autonomous 3 is for starting at the
inner side either red or blue
{ // our Robot will move backwards and block the
team tries to get the eggs under (purely for OED)
switch(currState)
{
case -1 : // Drive backward for 5 seconds
cruise(-90,-90);
delay(5000);
currState =0;
break;
case 0: // Stop moving and keep intake running
runIntake();
cruise(0,0);
break;
}
}

52
Motor.h
#include <Servo.h>
void runMotor(Servo a, int speed); // The speed for controlling the motor are from -90
to 90 90 is clockwise and -90 is counter-clockwise

53
Motor.ino
//#include "PID.h"
#include <Servo.h>
//Motor.ino:
// -Handles powering motors.
void runMotor(Servo a,int speed) // The speed for controlling the motor are from
-90 to 90 90 is clockwise and -90 is counter-clockwise
{
//Limit the value being sent to the motor. Values being sent should have a minimum
of -90 and a maximum of 90
if(speed < -90)
{
speed = -90;
}
if(speed >90)
{
speed = 90;
}
//write value of speed to motor
a.write(-speed+90);
}

54
Drive.h
#include <Servo.h>
#include <Encoder.h>
#include "Motor.h"
//#include "PID.h"
void driveInit(); // Attach physical motors to servo
objects
void cruise(int leftSpeed, int rightSpeed); // Changes the speeds of the drive
motors, controlling the different parts of the drive train
void forwardDrivePos(int ticks); // Changes desired position to the
current value of the encoders plus the distance
void turnDesired(int ticks); // Changes desired position to
current value of encoders with plus or minus the desired ticks
bool followDrive(); // This method will let the motors
to follow the desired turn or value we set
void resetError(); // Reset the error so the follow
drive could run again

55
Drive.ino
#include <Servo.h>
#include <Encoder.h>
#include "Motor.h"
#include "Drive.h"
//Intake.ino:
// -Handles drive methods (for autonomous and driver control)
// -Hold PD controller for drive motors. Uses encoders as value to monitor
// Drive motor ports
int leftFrontMotorPin = 6;
int leftBackMotorPin = 5;
int rightFrontMotorPin = 7;
int rightBackMotorPin = 4;
// Amount of error allowed before command is allowed to be considered "finished" and
code moves on
// This is a set amount
int driveTolerance = 30;
// PID Routine data holders.
// 0 refers to left drive
// 1 refers to right drive
int currPosDrive[2]; // Current position of drive encoders
int desiredPosDrive[2]; // Desired position of drive encoders. Manually write the
desired position before calling drive control methods
int errorDrive[2]; // Current error
int pErrorDrive[2]; // Previous error
int pDrive[2]; // Proportional value
int dDrive[2]; // Derivative value
int driveValDrive[2]; // Values sent to drive motors
// PID routine constants
float kpDrive[2];
float kdDrive[2];
int leftComponent;
int rightComponent;
Servo leftFrontMotor;
Servo leftBackMotor;
Servo rightFrontMotor;
Servo rightBackMotor;
Encoder leftEnc(18,19);
Encoder rightEnc(2,3);
void driveInit() // Attach physical motors
to servo objects
{
leftFrontMotor.attach(leftFrontMotorPin, 1000,2000);
leftBackMotor.attach(leftBackMotorPin, 1000,2000);
rightFrontMotor.attach(rightFrontMotorPin, 1000,2000);
rightBackMotor.attach(rightBackMotorPin, 1000,2000);
//set PID constants
kpDrive[0] = 0.2;
kdDrive[0] = 0.1;
kpDrive[1] = 0.35;
kdDrive[1] = 0.05;
//Initialize all PID controller variables to 0
currPosDrive[0] = 0;
currPosDrive[1] = 0;
desiredPosDrive[0] = 0;

56
desiredPosDrive[1] = 0;
errorDrive[0] = 500;
errorDrive[1] = 500;
pErrorDrive[0] = 0;
pErrorDrive[1] = 0;
pDrive[0] = 0;
pDrive[1] = 0;
dDrive[0] = 0;
dDrive[1] = 0;
driveValDrive[0] = 0;
driveValDrive[1] = 0;
leftComponent =1;
rightComponent =1;
}
// Changes the speeds of the drive motors, controlling the different parts of the
drive train
// 90,90 should make the robot go forward
void cruise(int leftSpeed, int rightSpeed)
{
if(leftSpeed < -90)
{
leftSpeed = -90;
}
if(leftSpeed >90)
{
leftSpeed = 90;
}
if(rightSpeed < -90)
{
rightSpeed = -90;
}
if(rightSpeed >90)
{
rightSpeed = 90;
}
runMotor(leftFrontMotor, leftSpeed); // Left front motor must move clockwise
to move forward
runMotor(rightFrontMotor, -rightSpeed); // Right front motor must move counter
clockwise to move forward
runMotor(leftBackMotor, -leftSpeed); // Left back motor must move counter
clockwise to move forward
runMotor(rightBackMotor, rightSpeed); // Right back motor must move clockwise
to move forward
}
// Changes desired position to the current value of the encoders plus the distance
// you want to travel
void forwardDrivePos(int ticks)
{
desiredPosDrive[1] = rightEnc.read() - ticks; // subtract ticks because right
encoder counts down when driving forward
leftComponent =1;
}
// Changes desired position to current value of encoders with plus or minus the
desired ticks
// right position is lower than current position so that robot turns right
void turnDesired(int ticks) //Positive for right and negative for left
{
desiredPosDrive[1] = rightEnc.read() + ticks; // Add ticks because right encoder
counts up when driving backwards
leftComponent =-1; // Inverse the left

57
}
// PID routine for drive
// Returns true if error is within tolerance. Otherwise false
// Routine does not run if it is within tolerance
// Make sure to change the desiredPosDrive to what you want
bool followDrive() // This method will let the motors to follow the
desired turn or value we set
{
// If both errors are within tolerance
if(abs(errorDrive[1])<driveTolerance)
{
return true;
}
else // If this happens, then we need to decrease the error with the routine
{
// read current position of encoders
currPosDrive[0] = leftEnc.read();
currPosDrive[1] = rightEnc.read();
// Calculate error
errorDrive[1] = desiredPosDrive[1] - currPosDrive[1];
// Calculate proportional
pDrive[1] = errorDrive[1];
// Calculate derivative (error minus last error)
dDrive[1] = errorDrive[1] - pErrorDrive[1];
// Calculate value to send to motors
driveValDrive[1] = kpDrive[1]*pDrive[1] + kdDrive[1]*dDrive[1];
Serial.print("Error 0 ");
Serial.println(rightEnc.read());
Serial.println(leftEnc.read());
// Write value to motors
// cruise(driveValDrive[0], -driveValDrive[1]);
cruise(-driveValDrive[1]*leftComponent, -driveValDrive[1]*rightComponent); //
The motors are inversed when turning
pErrorDrive[1] = errorDrive[1];
return false;
}
}
void resetError() // Reset the error so the follow drive could run again
{
errorDrive[1] =500;
}

58
Lift.h
#include "Motor.h"
#include <Servo.h>
void liftSetup(); //Set up the left motor and the right
motor
void liftButControl(int buttonValue); // This is for the controller control of
the lift
void liftControl(int Pos); // Proportional control of the arm
float sensorUsage(int Pos); //Returns error between current arm
position and desired arm position multiplied with kp

59
Lift.ino
#include "Motor.h"
#include <Servo.h>
//Lift.ino:
// -Handles lift controlling methods (for both autonomous and driver control)
// -Holds P controller for lift (for autonomous)
Servo leftMotor; // They are the different Motors for the lift controlling
system one on the left and the other
Servo rightMotor; // on the right side, the right side is going counter
clockwise for going up, the left side is going clockwise for going up
int leftMotorPin = 8;
int rightMotorPin = 9;
int sensorPin =A0;
float Kp = 1.0f; // The proportional control constant for the arm control
int moveSpeed = 90; // When using the controller, the arm motor moves at
moveSpeed
int currentPos =800; // this is for storing the current position of the robot
when we have controller control(should be set up as the starting position)
void liftSetup() //Set up the left motor and
the right motor
{
leftMotor.attach(leftMotorPin,1000,2000);
rightMotor.attach(rightMotorPin,1000,2000);
}
void liftButControl(int buttonValue) // This is for the
controller control of the lift
{
switch(buttonValue)
{
case 0: // case 0 is the case
where the arm should be stayed the same position(This position comes from current
positon which we record at case 1 and 2 or the default value)
//liftControl(currentPos);
runMotor(leftMotor,0);
runMotor(rightMotor,0);
break;
case 1: // case 1 is moving the
arm up with the moveSpeed
runMotor(leftMotor,moveSpeed);
runMotor(rightMotor,-moveSpeed);
currentPos=analogRead(sensorPin);
break;
case 2: // case 2 is moving the arm
down with the moveSpeed;
runMotor(leftMotor,-moveSpeed);
runMotor(rightMotor,moveSpeed);
currentPos=analogRead(sensorPin);
break;
}
}

60
void liftControl(int Pos) // Proportional control of the
arm
{
int drive =(int)sensorUsage(Pos);
runMotor(leftMotor,drive); //The two Motor works
differently, so speed written to motors is inversed
runMotor(rightMotor,-drive);
}
float sensorUsage(int Pos) // Returns error between
currernt arm position and desired arm position multiplied with kp
{
float drive =Kp*(analogRead(sensorPin)-Pos ); // The error equals Kp times
the difference between desired position
Serial.println(analogRead(sensorPin));
// As the difference gets
smaller our arm moves slower
return drive;
}

61
Intake.h
#include <Servo.h>
#include "Motor.h"
void intakeInit(); // Set up the intake motor
void controlIntake(int bottomValue); // Use right side button to control our
intake
void runIntake(); // Runs intake inward to pick up eggs
void stopIntake(); // Stops intake movement
void outPutIntake(); // Runs intake outward to release eggs

62
Intake.ino
#include <Servo.h>
#include "Motor.h"
//Intake.ino:
// -Handles intake controlling methods (for both autonomous and driver control)
Servo motor;
int motorPin = 10; // Our intake system will only have one motor and these are the
data for this motor
int intakeSpeed = 90; //Set up the three running speed variables
int outputSpeed = -90;
int stationarySpeed =0;
void intakeInit() // Set up the intake motor
{
motor.attach(motorPin,1000,2000);
}
void intakeButControl(int buttomValue) // Use right side button to control our
intake
{
switch(buttomValue)
{
case 0:
runMotor(motor,0);
break;
case 1:
runMotor(motor,intakeSpeed);
break;
case 2:
runMotor(motor,outputSpeed);
break;
}
}
void runIntake() // Intake eggs
{
runMotor(motor,intakeSpeed);
}
void stopIntake() // Keep staying
{
runMotor(motor,0);
}
void outPutIntake() //Output eggs
{
runMotor(motor,outputSpeed);
}

Team 8, Final Report Comp 1

More Related Content

Viewers also liked (11)

Similar to Team 8, Final Report Comp 1 (12)

Team 8, Final Report Comp 1