Table of Contents

1. Introduction 3

2. Kickoff and Game Analysis 4

2.1 Kickoff Weekend 4

2.2 Scoring Analysis 4
2.2.1 Autonomous Strategy 4
2.2.2 Teleoperation Strategy 5
2.3 Strategic Conclusion 6

3. Robot Design and Control 7

4.1 Drive Train 7

4.1.1 Initial Design and Prototyping 7
4.1.2 Final Design 7
4.1.3 Control System 8
4.2 Gear Manipulator 9
4.2.1 Initial Design and Prototyping 9
4.2.2 Final Design 9
4.2.3 Control System 10
4.3 Fuel Intake 11
4.3.1 Initial Design and Prototyping 11
4.3.2 Final Design 11
4.3.3 Control System 12
4.4 Shooter – Conveyor 13
4.4.1 Initial Design and Prototyping 13
4.4.2 Final Design 13
4.4.3 Control System 14
4.5 Climbing Mechanisms 15
4.5.1 Initial Design and Prototyping 15
4.5.2 Final Design 15
4.5.3 Control System 16

5. Software and Controls 17

5.1 FRC Architecture and Object Oriented Programming 17

5.2 Collaborative Work Environment 17
5.3 Implementing the Programming Process 18
5.4 Teaching New Programmers 18
5.5 Human Machine Interface 19
5.6 Raspberry Pi Project 20

1
6. Manufacturing 21

7. Practice Field and Pit 22

7.1 Practice Field 22

7.2 Competition Pit 22

8. Conclusion 23

2
1. Introduction
Team 5401 the Bensalem High School Fightin’ Robotic Owls is thrilled to be participating in 2017 FIRST
Steamworks. Last year’s Stronghold was amazing and successful for our team. We finished 4th place at the
end of Qualifications at the Westtown competition, 2nd at the MAR Regional Championships, and
qualified for Semi-finals Archimedes Division at the 2016 FIRST Championships. Building off of the
success and knowledge gained from last year we were, and still are, excited for this season. We have
welcomed many new members onto our team and also welcomed back many veterans to FIRST. Our
expanded Student Leadership positions (Figure 1) and more hands on student involvement demonstrates
our goal of teaching STEAM values, inspiring younger generations, and preparing students for life after
high school. This year, Team 5401 presents, Henry, which can shoot high goals, deliver gears, and climb.
Henry is named after the blue Hungry Hippo and after Henri Giffard, the inventor of the steam powered
blimp.

3
2. Kickoff and Game Analysis
2.1 Kickoff Weekend
Our kickoff weekend began by sending a small group of about 10 students to our regional Kick-Off
location, Hatboro-Horsham High School. The rest of the team reported to Bensalem High School
where we watched the kickoff video and immediately began reading the rules and game manual. By
the end of Day One, we had determined our overall strategy for playing the game, and students are
sent home with homework to read the game manual and ensure they have a full understanding of
the year’s game. Day Two was spent entirely on robot design, where we discussed potential robot
systems. At the end of Day Two, we had concluded what type of robot systems we wanted and a
general direction of design.
2.2 Scoring Analysis
Game analysis began by creating a spreadsheet that calculated all of the possible scoring
permutations. Refer to Table 1 for an excerpt of these variations.
Max for
alliance-
gears ball auto, Quals-
min for 3 gears +10 high+ high+ gear high auto, hybrid Elims is
gears rotors high in gear high+gea auto+1 only gears tele-2 120
only-max spinning auto high only auto r tele gear tele in tele rotors higher
Auto-total pts 65 65 75 15 75 45 75 45 45 221.6667
line 5 5 5 5 5 5 5 5 5 15
gears 1 1 1 0 1 0 1 0 0 3
rotor points 60 60 60 0 60 0 60 0 0 120
balls-high 0 0 10 10 10 40 10 40 40 65
balls low 0 0 0 0 0 0 0 0 0 65
tele-total pts 130 130 130 93.33333 90 123.3333 120 170 153.3333 527.7778
gears 7 5 5 0 0 1 1 6 2 9
rotor points 80 80 80 0 0 40 40 120 80 80
balls-high 0 0 0 130 120 100 90 0 70 670
balls-low 0 0 0 0 0 0 0 0 0 670
climb 50 50 50 50 50 50 50 50 50 150
rotors spinning 3 3 3 1 1 1 2 3 2 4
gears req. for RP 4 6 6 12 11 11 10 6 10 0
Balls high req in tele for RP 120 120 90 -40 -30 -100 0 0 -70 -1033.33
Balls low req in tele for RP 360 360 270 -120 -90 -300 0 0 -210 -3100
RP 0 0 0 1 1 1 1 1 1 2
total points 195 195 205 108.3333 165 168.3333 195 215 198.3333 749.4444
Table 1: Sample of Scoring Analysis
2.2.1 Autonomous Strategy
The maximum number of points that can be achieved during the 15 second autonomous
period, per action is:
Reaching the base line
+5 points per robot – +15 points total
Rotors turning
+60 points per rotor – 3 rotors per team
Rotor 1 needs 1 pilot placed gear, Rotor 2 needs 2 pilot placed gears
4
  Assuming all 3 get delivered and placed and the pilot gets the rotors turning in the
15 seconds time period, the max amount of points is +120 points (Table 2)
o Fuel delivered to boiler
 +1 point/+1 kPa per fuel delivered to boiler in high goal
 Maximum amount of high goals possible in Autonomous is roughly 70 (+70
pts/+70kPa)
 +1 point/+1 kPa per three (3) fuel delivered in low goal
 Maximum amount of low goals possible in Autonomous is roughly 70 (+23
pts/+23kPa)
 Conclusion: The higher point advantage results from high goals
 Ready for takeoff
o Not possible (Rule H11)
 Total Ranking Points based on max points above
o 1 RP from reaching max kPa
2.2.2 Teleoperation Strategy
The maximum number of points that can be achieved during the 2:15 teleop period, per
action is:
 Reaching the base line
o No points in teleop
 Rotors turning
o +40 points per rotor
o Assuming one (1) rotor gets turning during autonomous, and based off Table 2,
that leaves 11 gears left to be delivered in teleop
o The max amount of points if all gears get delivered and the rotors activated,
that is 120 points for 3 rotors turning
 Fuel delivered to boiler
o +1 point/+1 kPa per three (3) fuel delivered to boiler in high goal
o Maximum amount of high goals possible in teleop is roughly 699 based on the
theoretical amount of balls that can be received from hoppers and retrieval
zone within the 2:30 teleop time limit. (+233 pts/+233 kPa)
o +1 point/+1 kPa per nine (9) fuel delivered in low goal
o Maximum amount of low goals possible in teleop is roughly 669 based off of
balls received from hoppers and retrieval zone (+74 pts/+74 kPa)
o Conclusion: The higher point advantage results from high goals

5
  Ready for takeoff
o 50 points
 Total Ranking Points based on max points above
o 4 RP
o +1 from max kPa
o +1 from all rotors turning
o +2 win

2.3 Strategic Conclusion

Based off of the maximum scoring values we decided on a practical strategy for our team. Where
the highest priorities are: delivering gears and scoring points for rotors, being able to shoot in the
high goal, and climbing the rope for end game are all of the highest priority. These strategic
conclusions will ultimately drive the design of our robot and dictate the list of tasks our robot will
need to complete.
1. Drive
2. Hold balls and intake balls on floor
3. Score high w/ greater than 33%
4. Start w/ gear, deliver gear
5. Climb

6
3. Robot Design and Control
4.1 Drive Train
4.1.1 Initial Design and Prototyping
Some of the potential drive systems we considered were an H-drive system, Mecanum drive
system, and a West coast drive (WCD) system (both 6 wheel and 8 wheel). Knowing that
we would need extra speed in this game to traverse the field quickly and the ability to resist
outside factors such as a defensive robot, we decided on a WCD base (6 wheel). The other
systems, we decided, would be too weak and allow us to be pushed around by other robots.
4.1.2 Final Design

Henry has a 6 wheel “West Coast” style drive with each of the two rear wheels being
directly driven by a 3 CIM Ball Shifting Gearbox (217-3195). The low gear is a 33.33:1
ratio, and yields a speed of 4.50 ft per second. The high gear is a 9.07:1 ratio, and yields a
speed of 16.56 per second. The center wheels on each side are dropped 1/16”, and the
outer two wheels are raised 1/16” to aid in maneuverability and turning. All of the wheels
are 4” Vex Pro Traction wheels equipped with Blue-Nitrile Roughtop Tread. The traction
wheels and low gear help against defenders, and the high gear helps with crossing the field
quickly. Henry’s frame perimeter is 28.5”x28”. The drivetrain uses #35 chain and 12 tooth
sprockets. The entire structure composed of .1 thickness aluminum 1x2 box tube, riveted
together using VexPro T-gussets and the bellypan made out of 0.090” sheet of
polycarbonate plastic, with clearance slots for the gearboxes.

7
4.1.3 Control System
The DriveBase subsystem uses two different inputs: one trigger value to control throttle
and one analog stick value to change direction. It uses the angle from the joystick to decide
at what speed each set of wheels should be turning. Our controller input is called GTA
Drive, because it is similar to the driving controls from the game Grand Theft Auto. Our
DriveBase also has auto transmission for gear shifting. Auto transmission utilizes the
encoders placed the drive gearboxes to determine the velocity that the robot is moving.
When the robot reaches the maximum velocity for low gear, the DriveBase shifts up (this
occurs at 4.16 ft/sec) and when the robot reaches a low velocity in high gear, the
‘DriveBase’ shifts down (occurs at 3.33 ft/sec). The auto transmission gives the robot the
benefit of two gears in driving as well as relieving pressure on the drivers about when to
shift gears, though the drivers may override the automatic transmission with a button
press.

8
4.2 Gear Manipulator
4.2.1 Initial Design and Prototyping
Prototyping of the gear manipulator started with a cardboard model. This cardboard model
was used to get the correct spacing of the manipulator and ensure that the proposed design
would effectively retrieve the gear from the human player. After we had a cardboard design
we were confident with, we made another version out of sheet metal. This version had
working pneumatics to test that our design would actually work. Once we knew that our
design would work and had a final design we produced our final version that would be
placed on the robot.
4.2.2 Final Design

Henry has an active gear manipulator that retrieves gears from the human player station,
and pushes them onto the peg. The gear is pushed by two claws that are actuated by two
double acting one inch stroke actuators. The backplate and ramps allow the gear to
smoothly slide in between the “claws.” The ramps on the mechanism extend past the frame
perimeter after the start of a match. The claws are spring loaded and use integral stops to
maintain volume requirements. The claws are made of ¼” CNC machined aluminum, and
the vertical struts are made of ½” aluminum round shafts. Polycarbonate plates are used to
keep the gear in place. The gear manipulator is attached to the robot with five ¼” cap
screws to allow for easy removal, which gives access to drive gearboxes.

9
4.2.3 Control System
The pneumatic that is our gear manipulator extends when a button is pressed and retracts
when it is pressed again.

10
4.3 Fuel Intake
4.3.1 Initial Design and Prototyping
Some of the ideas we had for potential ball intake mechanisms are as follows: a paddle
wheel, an over the top “Hungry Hungry Hippos” style conveyor, a brush infeeder, an active
“scooper” that is similar to a backhoe, or a through bumper collector. We critiqued each
system in an effort to expose any weaknesses and also examined the resources needed for
each system, how reliable the system would be at capturing balls, and complexity. The idea
we decided on was the over the top “Hungry Hungry Hippos” conveyor because it is cost
effective to build and able to capture many balls at one time.

4.3.2 Final Design

11
 The infeed uprights extend and retract to stay within the frame perimeter at the beginning
of a match. They also serve as a hopper agitator for when there is a fuel jam. When
extended, the fuel capacity more than doubles. The uprights are actuated by two 5 inch
stroke actuators. The infeed itself is an over the bumper infeed, to allow for more fuel
intake. The rollers are run by two bag motors with a 5:1 reduction. They are actuated by
two 3” stroke cylinders and utilizes a 4 bar linkage to fold into starting configuration. The
climber is attached to the uprights, and under the uprights there are three ½ inch bars to
help guide fuel to the conveyor. The infeed uses polyurethane belts to push fuel into the
conveyor
4.3.3 Control System
The infeeder goes up when the left joystick on the operator controller is pushed up and
down when that joystick is pushed down. There is also a button to have the infeeder feed
in and a separate button to feed out.

12
4.4 Shooter – Conveyor
4.4.1 Initial Design and Prototyping
The potential shooting systems we discussed were: fly wheel shooter, spring plunger,
conveyor, or a catapult. We decided that any high goal shooter we have must be at least
33% accurate and have a fast throughput, in order to make a worthwhile game strategy.
The spring plunger and the catapult were both decided against due to their complexity and
their slow throughput. In the end, we decided on a fly wheel shooter because we can
modify this system to shoot 2 or 3 balls at one time, thus greatly increasing our scoring
potential. For the hopper, we knew that it should be a passive system that helps contain
balls. We wanted to hold a large number of balls that could have three channels. After
taking all of these requirements into consideration, we decided the hopper should be made
out of Lexan with three dividers to channel the balls into each of the flywheels.
4.4.2 Final Design

Shooter:
Henry has a three flywheel shooter driven by 775 pro motors on each side of the plate,
with a 1:4 reduction via pulleys and belts. The triple flywheel design allows the shooter to
continuously launch three fuel at once. The metering roller, powered by a single bag motor
with a 10:1 reduction, guides the fuel into the shooter flywheels at the same time and when
the shooter flywheels are at maximum RPM. The entire shooter support rests on the drive
structure and the backplate is made of 0.090” thick polycarbonate, with grip tape to help
compress the fuel. The backplate itself rests on twelve ⅜” thick aluminum bars. The
flywheels are made from three Fairlane Products flywheels that have custom made
aluminum hubs broached at ½ hex and placed a steel shaft

13
 Conveyor/Hopper:
The Hopper/Conveyor system divides the fuel into three lanes before reaching the
metering roller. The conveyor is powered by a bag motor with a 10:1 reduction. The
hopper holds 55-65 fuel when the infeed is fully extended. During a match, the conveyor
stays in the lowered position. The conveyor can be propped up against the shooter and the
entire hopper is removable with just four bolts, making access to the battery and service of
electronics easy. The Hopper and the conveyor dividers made out of 1/8” polycarbonate
plastic. There are three polyurethane belts that are 2 inches wide that serve as the conveyor
belts.
4.4.3 Control System
The shooter takes in the input from a button on the controller to determine when to run.
When that button is pressed, the wheels will spin up to a predetermined speed. We are
using two CAN Talon SRX speed controllers, one set to Control Mode Speed, and one set
to follower, we are then supplying them with a PID input to account for errors. The loader
subsystem runs the motors and moves balls into the shooter once the shooter is up to
speed based on the encoder input, or when the driver initiates it manually by pressing a
button.

14
4.5 Climbing Mechanisms
4.5.1 Initial Design and Prototyping
It was determined that being able to climb the rope attached to the airship for takeoff
would be a major performance factor in this year’s game. Some potential mechanisms that
we considered were: a winch system that coils the rope inside the robot, Velcro to attach to
the end of the field rope, and wheels with friction. Each of these systems had their
advantages and disadvantages. For example, the use of Velcro would give is an easy way to
hold on to the end of the rope, but there would be no guarantee that it would be easy to
initially grab the rope or that it would be strong enough to hold the weight of the robot. In
the end, we ultimately decided on a winch system that would latch onto the rope and
collect it around a drum inside the robot. This system, though it will take up a significant
amount of space, should be more efficient than other designs we considered.
4.5.2 Final Design

The climbing mechanism is mounted on the infeed uprights. The 4” long drum is powered
by two 775 pro motors with a 28:1 reduction on each. The drum has two hook velcro
straps to stick to the rope and roll it in. A ½” ratchet is attached to the steel hex shaft
which allows the drum to only spin in one direction, preventing backdrive once the robot
has successfully climbed. The planetary gearboxes are connected to the drum via 12 tooth
pulleys and #35 chain and the vertical climber supports and horizontal bar is mounted
with custom ⅛” gussets and 10-32 bolts for more durability.

15
4.5.3 Control System
The climber reacts to a button and runs while it is pressed

16
5. Software and Controls
5.1 FRC Architecture and Object Oriented Programming
 Over the summer, our team switched from programming in the language C++ to Java. This is
partly due to us having a Java course in our school but also because there are more resources in
Java for FIRST and we are still a relatively new team.
 We program using the FRC command-based architecture. It uses object-oriented programming to
allow an easy way to organize and link together various pieces of code. It starts out with a “main”
block of code that gets run over and over. From there, each Subsystem is created and most
Subsystems have their own Commands that are constantly run. We also have a group of
autonomous Commands that the “main” block of code is able to choose from and run in
autonomous mode. Another vital part of our architecture is our RobotMap, which is a list of
values we can reference that hold any constants such as channel numbers that we may need to use.
5.2 Collaborative Work Environment
 The entire programming team often gathers during meetings and for some sessions outside of our
general meeting times to test code on the robot. For the most part, our programmers work
individually, in pairs, or in groups of three due to the fact that a large group is not necessary to
draft, write, or test individual pieces of code. As a result, the work environment for programmers
requires good communication between each individual programmer and thus utilizes various
applications.
 Applications used:
o Slack

Slack is a cloud based collaboration tool used primarily for communications. Slack
is where the programmers post their goals that have yet to be completed. In
addition, Slack, is used by the programming leader to monitor and check whether
or not the programming team is on schedule.
o GitHub
 The GitHub website is used as a code repository. The robot code is always stored in
a GitHub repository. Individual programmers can commit changes and upload the
changes to GitHub site through the GitHub application. Using GitHub allows the
programmers to modify code on any computer and access code through any device
with an Internet connection.
 GitHub has a convenient branch system. A branch is version of code in that
repository. The main robot code is the master branch. Branching allows the code in
the master branch to be copied and modified as separate versions that we can later
merge together. These separate versions are utilized as test versions to test if a
subsystem works.
o Google Drive

17
  Google Drive is utilized to share other files that are not code. Code documentation
is created in Google Docs and block diagrams are kept in Google Slides.
Mechanical and programming teams share a Google sheet detailing all the PWM,
sensor, and pneumatic channels for the robot. Controller mappings are
documented and stored on Google Drive as well.
5.3 Implementing the Programming Process
 Identifying the Problem
o The first step in our programming process is to arrange a meeting with the whole
programming team and talk about what is it we need to accomplish. Basic
identifications of tasks that our robot needs to perform were already discussed in a
meeting with our entire FRC team. During a programming session, we set out to create
Block Diagrams of each subsystem so that we could easily tell what sort of inputs and
outputs we would need. We have included these at the end of each Subsystem section.
o During this step, the programming team has talks with the design team to get a high
level description of each subsystem.
 Designing/Drafting the Solution
o During this step, the programming team converts the Block Diagrams into pseudocode.
Pseudocode is not “real” code and consists of comments strung together in order to
provide and outline for the real robot code. Pseudocode also helps work out logical
problems and permit peer review
 Writing the Program
o During this step, the programming team converts the pseudocode into actual
programming code. Each subsystem and its related commands are separated into
separate branches through GitHub.
o During this step, the programming team heavily interacts with the CAD team. The
programming team has one big meeting to discuss the motors and actuators and how
each subsystem works in detail. Many smaller meetings occur to clarify topics that were
missed in the big meeting.
 Testing and Revising the Program
o After the practice robot is created, the programming team tests the code on the practice
robot. As subsystems are assembled and installed on the practice robot, the software
team tests the control system on the robot. Discrepancies between the final design and
the software controls are noted and patched.
o The testing process occurs with one subsystem at a time. Once a subsystem works and
no physical changes relating to that subsystem will be made to the robot, the
programming team merges the subsystem’s branch into the master branch.
o Interactions with the CAD and assembly team are necessary to make sure the robot
does not break and is working as it should be.
5.4 Teaching New Programmers
Part of the responsibility of the programming team is to get new members up to speed. If
they have no experience, then we start them off on the basics. Once they have an adequate
18
 understanding of basic object-oriented programming, we start to integrate them into robot
development by having them code just a Command and then onto an entire Subsystem.
Meanwhile, our more advanced programmers take on new projects and start researching
how to do them. This could be anything from figuring out how to use a new speed
controller to getting our previous year’s robot running off a Raspberry Pi.

5.5 Human Machine Interface

 Controller Mappings:
o We use two Xbox controllers to run our robot this year. We’ve set up controller maps
to be used as references for anyone in need of controlling the robot.

19
  Dashboard
o This year we started using the new SFX SmartDashboard for our drivers so they could
have a much nicer, cleaner, and more intuitive dashboard that uses dials and colors
over just plain text and numbers. The programmers themselves simply use the default
Java SmartDashboard for their diagnostics, as it is much simpler to use.

5.6 Raspberry Pi Project

This year, we decided to do a side project using last year’s robot we fondly named Tim. We
attempted to run the Victor SP Controllers using the Raspberry Pi 3 computer, in the hopes of
making him fully functional on a cost-effective computer. The motives for this were to keep Tim,
who was a 2016 World Championship contender, as a functional part of our team, so we could
practice all the aspects of competing on a successful, but decommissioned robot while avoiding the
need to purchase an additional RoboRIO. We also sought to familiarize ourselves with the
Raspberry Pi 3 computer in order to use it in vision processing on our future competing robots.
Our efforts allowed us to control two Victor SP controllers on Tim and run the connected motors
successfully. More work is needed in order to restore Tim to fully operational, but this small win is
a major asset to the team, and will prove to help them in years to come.

20
6. Manufacturing
In conjunction with FIRST Robotics, the Technical Education program has gotten a 21st century
STEM facelift, and is a featured part of the developing STEM academy at Bensalem High School. Thanks
to our new space, all manufacturing of Henry was done in-house in the Technical Education Shop of
Bensalem High School, adjacent to our robotics lab, by our student-led manufacturing team consisting of
three students. The one exception is our custom shooter plates which were plasma cut by our sponsor
Coren Metals. The frame, infeed, shooter structure, climber, and bumper mounts are constructed of box
tube aluminum, while custom gussets and blocks are made from a wide range of different sizes of
aluminum and Delrin. Due to our intricate design, new techniques were acquired in order to drill small
holes in odd shapes and round corners for clearance on the robot. Shafts and other turned parts that were
not purchased complete were turned on the shop lathe in the Technical Education area. All drawings
given to manufacturing for production can be seen in the Drawings section at the appendix of this
technical summary. Henry was assembled in the robotics lab, in the team’s fully functional pit, which is
discussed further below.
In order to support the ambitious strategy the team decided on, and to make use of the internal
machining capability, a prototype practice robot was built to learn lessons, provide a tool for drive team to
practice on, and a test bed for software while the competition robot was built.

21
7. Practice Field and Pit
7.1 Practice Field
Using the Technical Education Shop of Bensalem High School, wooden field elements were built
to assist prototyping of robot assemblies, as well as give the drive team a practice field on which to
hone their skills.

7.2 Competition Pit

Assembly of Henry took place in Team 5401’s fully functional competition pit, set up in the
robotics lab at Bensalem High School. The team decided that working in the pit would not only
give them the best access to tools and equipment, but would provide lessons about pit layout and
flow that would be applied to make the pit more functional at competition.

22
8. Conclusion
With the expansion of the team to around 45 members, a broader student leadership team, and new
student roles on the team such as design captain and assembly captain, we have created a robot that brings
the team a sense of pride and achievement. From day one of kickoff weekend, our goal was simple: build a
machine that achieves our goals, is expertly engineered to exceed our quality standards, and is a robot we
are proud to show off at competition. Although it was tough build season with many setbacks and
challenges, we have achieved all of our goals and we look forward to flying high at competition.

23