The Story of our Robot

2017-2018 season

This season, our approach to designing our robot has changed. Last season, we noticed that many interesting, potentially high scoring designs that we prototyped never made it on the robot, such as a cap ball lifter and an improved, spring loaded shooter. We found the reason was because we were too focused on getting the robot working now rather than thinking towards what are robot should look like in the future. Because of this, our engineering process this season started out with prototyping every possible mechanism so we didn’t need to leave any point scoring elements off our robot later in the season.  Our strategy was to be as offensive as possible, as defense didn’t look like a viable option, given the extremely reduced and sectioned space in this year’s challenge. Compatibility, which was a large part of last year’s game, was a low priority as well, as no missions in autonomous or TeleOp required both alliance partners to work well with each other to succeed. This in mind, we set out to make a robot that could be effective while alone, and help an alliance partner, too.

With our strategy decided upon, we shifted towards prototyping three key scoring elements: a glyph delivery system, a glyph collector, and a stable drive train.


Our initial drive train was a 6-wheel tank drive utilizing Rev’s extrusion mounting system, which gave us a lightweight and customizable base for our robot.


After brainstoming couple ideas for a delivery mechanism, we decided on a conveyor system that could extend to deliver glyphs from a distance, giving us a significant time advantage when compared to a claw delivery system.


2016-2017 season

Our robot has gone through many different software changes, designs, and redesigns, but through all of it our main strategy has stayed the same. At the beginning of our season we brainstormed what our strategy should be. We considered all of our flaws in last year’s strategies and also the few scoring elements in this year’s game, and its heavy focus on autonomous. Our strategy for TeleOp is to be good at all three components of this year’s game. Considering there are only three ways to score we decided that it would be possible to design a robot that would be able to do everything well. We started with shooting, and once we finished making our shooting mechanism we added a beacon pusher. While adding all these we have kept in mind the fact that later in the season we will be adding a cap ball mechanism. Doing some of everything allows us to be compatible with all other teams, allowing both us and our alliance partner to perform as well as they can. However, at the beginning of the season we knew we would need something to carry us through to the regional tournament, our autonomous. For this year we bought a whole bunch of new sensors including a color sensor, ultrasonic sensor, and a light sensor. We used these to create a consistent, high scoring autonomous. In the first thirty seconds of a match we are able to shoot two “particles” (whiffle balls), hit two beacons to the correct color, and park on either the center or corner vortex, depending on what our partner does. Our autonomous program can consistently score 100 points without breaking a sweat.

Once we had a good strategy, it was time to build. Our robot mechanisms have gone through many complete redesigns including our shooting mechanism, collection mechanism and even our chassis.

In October, we brainstormed different ideas for how to launch the balls into the center vortex, and how to collect them. We started building a launching mechanism similar in design to a baseball pitching machine.

We then tried adding a barrel to the end to direct the ball and make it more accurate.  

This design was kept till early November when we began work on a new catapult idea. At this time our team also began work on the chassis.


For the chassis we attempted a “U” shaped design in order to make it easier to collect the balls later on. However this design proved to be flimsy and unstable so we added a cross beam to the front to secure the chassis.

We continued to work and improve on our original ball launcher idea, but a prototype of a catapult kind of launcher was also worked on.

Between the pitching machine launcher and the catapult launcher, we concluded that the catapult was the more efficient and consistent option. We decided to try a Fibonacci curve, which looks like a snail shell, as the shape for the cam.  Then, when we had calculated the proportions needed, we copied it out on wood, drilled a hole in the middle, and sawed it out.  Finally, we mounted a hub to it, mounted it to the robot, and tested it using the battery from Jacob’s drill.  It worked perfectly!

The finished project.

The chassis went through many changes, but we kept the same basic design. We decided to go with mecanum wheels for more mobility. However the mecanum wheels had a different shape than our old wheels so we had to change our chassis a bit to adjust for them.

Our first collection mechanism was a claw with two painter’s tape rolls on the sides to clamp down on the ball. This collector was extremely inefficient, but it got us through Meet 0 and Meet 1.

This was our first beacon pusher. It wasn’t very effective, and it also caused us issues in robot inspection for its “Exposed sharp edges”.

The robot finally all came together, and we began testing.

We deconstructed our robot, because we saw that our mecanum wheels weren’t working. At first we thought that it was a weight distribution problem, but after testing it we saw it made little to no difference. We concluded that the problem wasn’t the weight distribution, but it may be a problem with the cleanliness and/or design of our wheels. We cleaned our wheels, but after testing, again, we saw that there was little to no difference. We finally concluded we need to purchase a gyro sensor, in order to be able to move sideways with the mecanum wheels and do that correctly.

We built a new beacon pusher that was much easier for driver to hit the beacon, due to its large surface area.

We saw during competition that our claw collection mechanism had some flaws. It could not hold more than two balls at a time, it took too long to collect, and it was very challenging for the driver to line up with the ball just right. We made a prototype of a new collector that could hold 3 balls and could collect them with ease. We debated on whether the collector should be run on friction or should have flaps to help the ball go into the shooter.

 The collection mechanism is completed and put on the robot. Only minor changes have to be done to compensate for the new collector.

This is the beacon pusher for autonomous.  It has cork on it and is connected to a servo. Above that is a color sensor to see what button it has to hit, corresponding to the given alliance.  

This is the finished robot at this point in time.

Some work has been done on a new shooter design. This design would shoot the ball by using a piston powered by a spring contained in a cylinder.  The ball would ideally be launched at an almost vertical angle. This would allow the drivers to align themselves with the center vortex much more easily. In theory this design should also improve consistency as well as speed. This would allow us to score more points during the driver control period.

We also plan to have a cap ball mechanism.  At first, we put this off because it seemed too hard to do for only 40 points, but now, after working on other parts of the game, and seeing how other robots went about raising the cap ball, as well as seeing its effects on the competition points, we started to plan our own.  We bought drawer sliders to use because they are the only mechanism that is sturdy and small enough to fit and function on our robot.  After the Inter-League Tournament, we will add it to our robot.


2015-2016 season

Our Epic Robot- Metal Gear

11/21/2015- Modified PushBot

Our first design was a variation of PushBot, a basic robot built from instructions on the FIRST website. Key points are the wood base, the monstrous useless arm, and loose wheels that couldn’t do much. We made no progress up the mountain with this one, for obvious reasons.

12/3/2015- Six-Wheeled Monstrosity

We had expected treads by this time, but they were back-ordered. This was our pitiful attempt at fixing that- two extra wheels. It was still too top heavy to make it onto the ramp. At least we held the electronics better with this one.

12/13/2015- MiniBot

We visited another team and got some better ideas about our design. After doing some planning, we took apart our old robot and created a new base- all metal, sturdy, and ready to add more attachments. The robot made it higher up the mountain than ever before, which was another indication that we needed balanced weight to succeed.

12/16/2015- The Heavy-Weight

We had our base; the next step was to add an arm that ran on rack-and-pinion. And so we did. But the design wasn’t quite right yet… it was too heavy to make it up the mountain, and we weren’t sure the arm would work even if we did. Another problem is that the wires got tangled up.

12/19/2015- Tread Boss

We finally got our treads! We could make it part of the way up the mountain, but it always kept flipping over. We needed a better arm design… something that was strong enough to lift the robot, yet light and compact enough that it wouldn’t hinder our mountain climbing. (Also notice the zip-ties keeping our wires together)

1/15/2016- Tread Boss v2.0 (Now climbs mountains!) A.K.A. The Tumbler

We used a completely different method to climb up the mountain- a tape measure. It’s strong, durable, light and slim, and (most importantly) it works! It’s amazing! It also has two attachments for flipping switches, a bumper for pushing obstacles, two wheels in the back to help it get over the bars, and various stability improvements.

2/xx/2016- The Unicorn ResQer

We ran into a problem at our second tournament- our switch-flipping attachments were not strong enough to activate the levers. We fixed it by putting the servos at a different angle and putting a shield around the bars. Another addition was a one-way hinge in the back that would protect electrical components from debris (in one round the debris detached a wire and shut down the entire robot) but bends out of the way when our robot goes up the bars. Also note that we used plastic for our tape measure holder rather than wood (which kept breaking apart); we included a ‘unicorn horn’ to hold the climbers and drop them into the basket; we added omni-wheels to allow the robot to turn better, and we added a mechanism to activate the all clear signal at the top of the mountain.

?/??/2016- FutureBot

And what’s next for Metal Gear? We still could make a device to collect debris or work on sensors for a better autonomous. We could also use an arm to press the button on the rescue beacon. The possibilities are endless!