Design: Minimum Competitive Concept

A Minimum Competitive Concept Robot, or MCC for short, is an idea that’s been around FRC for a while. The idea is to design and build a robot that any team could build and remain reasonably competitive at an event. These aren’t world championship caliber robots, but they’re the kind of robot you’d love to have as a partner at a smaller tournament and probably even your state championship.

In FRC the two most popular MCC robots are one designed by our friends at West Coast Products (simply called MCC) and the EveryBot designed by FRC Team 118 – The Robonauts. Even though they seem very simple, clones of these robots have typically performed above average at most regionals and usually make it into eliminations.

We’ve decided that we’re going to try and do an MCC style robot for this year’s FTC game, Rover Ruckus. Our guidelines for this are:

  1. Use as many common off the shelf (COTS) items as possible
  2. Any fabrication must be achieved with basic hand and power tools (hack saw, hand drill, etc)
  3. Minimal 3D printing
  4. Give teams a solid starting point that they can use to build and improve upon
  5. Functions with simple software

Having gone through our own strategic analysis, we’ve come up with a simple MCC robot that we feel any team can build and almost any team would want to be aligned with in a qualification match (and maybe even eliminations).

Robot Features:


  • 4-6 wheel drive
  • Geared between 16:1 and 20:1
  • Can easily drive into and out of Crater


  • “Touch It, Own It”
  • Can pick up both Gold and Silver Minerals
  • Can hold at least 2 Minerals at a time

Mineral Scoring

  • Depot-only
  • Scores from the opposite side of intake

End Game

  • Can attach and lift robot off ground in less than 30 seconds


  • Can start on Lander
  • Can lower robot from Lander
  • Ability to achieve multiple autonomous tasks
  • Capable of delivering team marker to Depot


  • Short enough to drive under Lander
  • Ideally between 20-30 lbs
  • Can be built with one expansion hub


Some of this might seem crazy, so let’s walk through some of our decisions:



Ideally we would like the drivetrain to have 4 wheels to help keep weight down. By keeping the overall weight down, we can get more aggressive with the gearing and make a faster overall robot. The heavier your robot is, the slower you have to gear it.


“Touch It, Own It” is an important concept. Many times teams struggle with intakes and waste a lot of time just trying to acquire a game object. The idea behind “Touch It, Own It” is that you want to make an intake that acquires a game object the second it touches the intake.

To help keep the robot simple, we want the intake to be able to pick up both Gold and Silver minerals. Not only does it cut down on the number of mechanisms, but it’ll also help keep the overall weight of the robot down.

Mineral Scoring

The Depot-only robot was one we talked about for awhile. The reason we decided to move forward with this concept was because we felt that if implemented correctly, it could be more effective than most of the robots that attempt to score in the Cargo Hold.

This seems like a stretch, but there’s one subtle element of scoring in the Cargo Hold that will slow down almost every robot. It may not be very obvious, but this happens to be sorting Minerals. At some point during your cycle you will have to sort objects. This means you’ll either have to make the effort to intake two of the same object, or you’re going to have to score in two different places after you pick up the Minerals.

So how can a Depot-only robot be just as, if not more, effective than a Cargo Hold robot? It’s simple, you’re just 2.5x faster. Let’s think about the two ideal list of actions that a Cargo Hold robot will have to perform:

Scenario 1

  • Find and acquire Mineral 1
  • Find and acquire Mineral 2 (the same type as Mineral 1) 
  • Drive to Lander
  • Lift Minerals
  • Score Minerals

Scenario 2

  • Find and acquire Mineral 1
  • Find and acquire Mineral 2 (not the same type as Mineral 1) 
  • Drive to Lander
  • Lift Minerals
  • Score Mineral 1
  • Lower lift (optional)
  • Drive to other side of the Lander
  • Score Mineral 2

Each of these actions require X amount of time. However, a Depot-only robot only has perform the following actions:

  • Acquire Mineral 1 
  • Acquire Mineral 2 (does not have to be the same type as Mineral 1)
  • Drive to Depot
  • Dump Minerals

Again, these actions take time, but consider that a Depot-only robot doesn’t care about sorting, doesn’t have to lift game objects and doesn’t care about the precise positioning of the objects they’re trying to score.

Will that mean that a Depot-only robot will always be better? Of course not. Again, we’re not trying to build a world championship caliber robot. We’re trying to build a robot that any team could build and be competitive with.

Since we want to cut down on our cycle times, we need to do everything we can to optimize the robot’s cycles. One of our key design choices is putting the ‘outtake’ on the opposite end of the intake. This will eliminate the additional action of our robot having to turn around and outtaking elements, while also improving overall cycle times.

Not to mention that a Depot-only robot also requires much less sophisticated software, which makes it more accessible to teams.

End Game

Since Minerals in the Depot are only worth 2 points, we wanted to optimize our scoring potential by making the robot hang from the Lander at the end of the match.


The same reason we want the robot to hang is why we want the robot to start on the Lander and lower itself down. We’re trying to maximize our scoring potential. We also believe that we can complete both of these actions by using the same system. Using the same system for multiple tasks is a great way to optimize your robot and keep its weight low.

Since claiming the Depot is a must for a Depot-only robot, we want the robot to be able to do its part in autonomous.

Lastly, this robot could have the potential (assuming time is still available) to receive points for parking and the sample bonus. This would give the robot an 80 point autonomous mode.


Since the Depot can be defended, we wanted to give the robot the ability to “beat” a defender. There are two concepts here – the first is make the robot very agile and minimize the areas of the field it cannot access. The second is to make the robot faster than most (or all) robots. When combining these two concepts, it becomes much more difficult for a potential defender.

With this in mind, we wanted to make the robot drive under the Lander. This way, if an opponent tries to block our path to the Depot, we can simply drive under the Lander instead. Weight is also an important factor to this as well. The lighter the robot is, the faster we can gear it and the easier it’ll be to drive around defense.

Finally, we also wanted to build the robot with a single Expansion Hub. This seems like an odd requirement, but there’s a couple design and resource benefits here:

  1. Reduced cost. 2x REV Expansion Hubs are $350, or $175 each. The REV Servo Power Module is $40 and can run 2x VEX EDR 393 Motors each. So we could use up to 8x VEX EDR 393 Motors and still be cheaper than buying 2x Expansion Hubs.
  2. Limiting ourselves to 4x motors and achieving the rest of our movements with servos allow us to keep weight down. Less weight means less power required to move the robot, and also allows us to gear the robot faster and keep our cycle times down.

This is our idea of an MCC for FTC. Stay tuned for later as we discuss different gameplay strategies for the MCC robot!