Behind the Design | FRC67 (2012) – Ultimate Utility

How did you decide what portions of the game challenge to address?
We follow a standard process for all game analysis, pretty similar to the majority of teams. Watch kickoff video, read and understand rules, discuss with team. In our initial meetings we try focus on “what” instead of “how”. We list out all the scoring / defense options we see available in the game. Then we discuss and rank each action to determine how we want to play. Typically we will have a list of 10 game tasks that the robot design will need to meet. In 2012 the basic functions looked like this:


  1. Score in top hoop
  2. Score in middle hoop
  3. Score in bottom hoop
  4. Score in autonomous
  5. Catch balls from human player slot
  6. Pickup balls from floor
  7. Pickup balls from ramp
  8. Catch balls from other robots
  9. Shoot and collect at the same time
  10. Shoot balls from robot at multiple angles (turret?)
  11. Make shots that are close
  12. Shoot balls from a long way away (mid-court shot)
  13. Full court shots are pipe dreams
  14. Ball release above 60 degrees


  1. Balance on ramps
  2. Balance on ramps with partner
  3. Help 2 other robots balance
  4. Orient on ramps


  1. Tip Ramp in autonomous, get balls and score them
  2. Traverse barrier
  3. Traverse the ramps
  4. Tip a level ramp
  5. Tip an away tipped ramp
  6. Tip a ramp with a robot on the other end
  7. Evacuate balls from under ramps


  1. Block Shots
  2. Push other robots around

We then prioritized these functions and created the basic design priorities:

  1. Score in Hybrid
  • Score in Top Basket
  • Collect and score balls from middle ramp (tip level ramp)
  • Pickup balls from the floor
  • Camera aim
  1. Balance on both the Cooperative and Alliance Ramps
  • Balance 1, 2, or 3 robots
  • Traverse ramp
  1. Tele-operated Ball Scoring
  • Score quickly and accurately

You know, just a pretty simple do-everything approach to the game…

What process did you follow to evaluate different approaches to challenges?
We usually use a design, test, and iterate process. Once we select a design we don’t have an extensive prototype phase that occurs. For 2012, we created a prototype shooter to evaluate the accuracy of shooting from the “safe” zones. Through this testing it showed that was possible to meet our 90% accuracy targets from distance. This helped test the single wheel shooter concept, angle, and wheel speed targets

What other options did you evaluate?
We didn’t really evaluate any other options. The shooter was the only prototype. The utility arm was designed and built to be extremely robust. We felt we had a good understanding of the physics needed to push the ramp down and help balance the bridge. The rest of the robot was pretty straight forward – frame, drivetrain, and shifter designs had already been used in previous years.

How did you decide on the approaches you chose?
The most interesting part of the 2012 robot was the utility arm concept. That came from experience from previous years, seeing other teams utilize an arm to help stabilize a bridge. Going off of that concept of a balancing arm, we started to visualize how that might be possible. As we explored the rules for bumper openings and knowing we wanted to have the largest available size for ball collection, we decided to integrate the ball collection and the balance arm into one mechanism. Out of these 3-4 different actions (bridge manipulation, balance, pickup, pushing, etc…) we wanted to achieve, we determined they could all be combined and accomplished using the utility arm. It sort-of just morphed into this amazingly effective do-all mechanism throughout the design process.

How did you go about creating your solutions?
Our designs are usually developed in AutoCAD, then occasionally created in Solidworks as 3D models to determine if there are any issues with interferences that are hard to notice in 2D drawings. The frame, shooter, and hopper were designed exclusively in AutoCAD. The utility arm was done using both design programs.

Our two design mentors usually work independently on specific sub-systems but discuss daily on any integration areas where the systems attached or interfere with each other. This system has worked well for us, but does require constant communication and knowledge of the rest of the design.

What issues did you run into in design, fabrication, or use? How did you overcome them?
Much of this design was pretty simple to work out. The biggest issue we had was to determine how we transport balls from the utility arm to the shooter. We initially wanted a “power” feed system with an arm that would scoop the ball and press it into the shooter wheel (see FRC25 in 2006). Unfortunately with the “wide” chassis configuration there was no room to fit that type of mechanism in the robot with a low exit shooter. We struggled for a week trying to figure out how to solve this problem. Finally we simplified the idea to gravity feed the shooter instead, by releasing the ball from the feed roller early and allowing the ball to travel down a slight incline before contacting the shooter wheel. This allowed for less packaging space and did not reduce the intended accuracy of the shooter.

What would you do differently if you could redo it again?
After winning 3 districts, the Michigan State Competition, and leading a match into the final seconds of the Division finals there isn’t much that I would change about this machine.

It wasn’t perfect though, the intake to shooter transition took a little too long. We were jealous of teams that had intake systems that just sucked up balls into the robot ready to shoot. Our intake required a little more finesse to get the balls into the intake and ensure there was room for all three, otherwise you had to load two balls, then pick up the last ball and load it. It just made for a slightly slower process.

The only other change would be to add additional weight to the back of the robot. We were underweight by about 5-10lbs all season, but we never added ballast plates to the rear of the machine to make it easier to balance on the bridge. Our co-op bridge balancing act was rather awkward, since it required our balance partner to move out towards the end of their end of the bridge, before the utility arm could lift us up. This created a couple of pretty tense moments at the end of matches. Especially at Champs where a lot of teams were not familiar with how what we wanted them to do.

Any final thoughts on the overall solution?
Overall, we were very happy with the design, execution, and performance of this machine. My opinion is that it was definitely worthy of the FRC Top 25 #1 sticker it earned during the season and one of the best robots we have ever built.

Quick Facts Section

  • Drivetrain: 4CIM 8WD – 2 speed AM Super shifters.
  • Linear Speed: Theoretical top speed = 12Ft/s
  • Wheel Type: 4” Machined AL wheels with rough top tread.
  • Speed Controllers: Victors
  • Programming Language: C++
  • Official Record: 77-12-0
  • Waterford, Northville, Troy District Champion
  • Michigan State Champion
  • Archimedes Division Finalist

Additional Information: Drivetrain
The HOTBot drivetrain was designed as an 8WD setup, using two-speed AndyMark Supershifter gearboxes, with two CIM Motors mated to each gearbox driving 4” custom machined performance wheels.

These two-speed transmissions allow us to shift from high torque (10.67:1 gear ratio) to high speed (4.18:1 gear ratio). Students modified the gear boxes to increase their precision and to reduce the rotational inertia of the gears. The transmission output is a 22T to32Tchain and sprocket drive to our center driven wheels and a 1:1 chain drive to our front and rear driven wheels. This combination gives the HOTBot a top speed of approximately 15 feet per second.

Since we are not using pneumatics on our robot but we want higher power shifting than servos will provide, a Window motor shifter was designed to switch between high and low gear. This design uses an opposing cam design to push or pull the dog gear in the transmission from high to low gear. Springs were designed into the arms to allow for each side to shift at different times without destroying the other side. We were able to package this design so that it fits right between our gearboxes and take up no more room than a pneumatic setup.

Additional Information: Utility Arm
The need for a utility arm was developed based on the need for having some type of balancing aid to limit or lessen the movement of the ramps while attempting to balance. We knew it would be very difficult to balance the bridge while driving up a ramp with two or three robots. Based on analysis of previous year’s games, we saw it was much easier to balance if the ramps were not oscillating between positions. The arm

would be needed to be designed to reach below the frame and stabilize the bridge while the robot was on it, but not reach outside the 14” appendage rule stated in <G21>. The arm also functions as a wheelie bar and lift for our robot to traverse the barrier.

Once the geometry of the arm was known, the team had to create a design that would be robust against aggressive defense. Each arm was designed out of 2” x 3” rectangular aluminum tubing that was welded
together and joined by two pieces of 2” aluminum angle. The arm is driven via two BaneBot RS-550 motors through 26:1 P60 gearboxes, which are then inputs into a custom gearboxes bolted to the robot
chassis, using the internals from AndyMark CIMple Gearboxes. There is a gearbox setup on each side of the arm and outputs to a 16T sprocket, which is chain driven to a 100T sprocket on the arm assembly. The
overall gear ratio for the utility arm is 758:1. This gearing allows for both quick rotation (0.6 s/ ¼ revolutions) and high torque (370 ft-lb). This design allows the arm to push the bridge down with 138lbs of force. Gas struts were designed help hold the arm at the ball pickup position without straining the motors and help lift it up after balancing on the bridge.

Another function is that the ball collection system is integrated into the utility arm. With the required minimum 8” of bumpers on any corner, we wanted to take advantage of the largest possible opening for
balls collection. Additionally, to fit our Hybrid strategy we wanted to ensure the robot would not be able to collect more than three balls at any one time. The intake system utilizes a double roller setup to grab balls and pull them in and against the bumpers. A piece of ½” round aluminum lifts the balls off the ground to allow the robot to maneuver with collected balls. The front roller is covered with grip tape to grab balls, while to rear roller is un-covered PVC to allow the roller to slip on the ball without stalling the motors. The rollers are powered by dual Banebot RS550 motors placed into 16:1 P60 gearboxes which are chain driven from a 22T sprocket to a 32T sprocket. Additionally, 4” performance wheels are cantilevered on the inside of the arm to allow for additional power to push robots up the ramps.

Additional Information: Shooter
Based on analysis of previous ball related games, the team decided that a single wheeled shooter would provide the best combination of accuracy and backspin to reproduce to basketball type shot. The first step in determining our shooter strategy was to figure out how accurate a shooter could be at different areas on the floor.

Utilizing a prototype design and a power supply we tracked the shooting accuracy at different positions in the scoring zones, shooting angles, and ball compressions. There are basically two realistic spots to shoot
from on the field, either the key or the fender. The team felt that the protection provided at the key would be the best position for our team, but we needed to prove that it was possible to hit 90% of the shots from
the key for it to be a better shooting position than the fender. The prototype shooter team found that a shot angle of 45 degrees with 2” of ball compression at ~4000RPM would provide the required of accuracy and robustness to make shooting from the key acceptable.

With the results from the prototype design known, the team decided that afixed angle; non-turreted shooter was the best design to meet our desired strategy. Our typical shooting speed is around 4000RPM for shot anywhere on the key. To determine which motors to use and what gear ratio to choose to provide an optimized shooting speed, the team analyzed the relationship between shooter wheel speed and time to
reach our expected wheel speed. The shooter uses two 6” KOP wheels with the edges turned off and is powered by two AndyMark 500 series 9015 motors. The motors are geared down to ~8000RPM free speed
through a custom made gearbox with a ratio of 2.52:1.

The shooter is fully integrated into the frame with 1.5” diameter tubing to provide a rigid base for a repeatable shot. The shooter was positioned as far forward in the robot as possible, but facing rearward. This allows us the ability to grab balls off the Cooperative Bridge in Hybrid mode and score them without turning around.

Article Content Provided by: Adam Freeman

One comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s