In various design processes, several steps, done in many different ways, generally aim for one goal: Prioritize tasks to more efficiently delegate resources. In a nutshell, here’s my thoughts on that and how I do it.

The first formal design process I’ve looked at is JVN’s process, the one 148 uses. After the problem is defined, specifications are generated and then ranked. This is universally true for nearly any design process, but rather underrated in its performance. In particular, I think this needs to be the most spelled out and black and white part of the process. If these decisions are firmly made early, it saves time arguing and debating later, as long as everyone agrees to stand behind them.

In the context of robotic competition, I find it’s best to start with a very general strategy overview and setting your game objectives in a firm priority list. This list needs to be absolute and followed; if there is any conflict, resources go to the more important game objective. From there, you can break the game objectives down by subsystem and make a Want-Preferred-Demand chart for individual features and criteria. I find this slight tweak to the design process a lot easier and more relevant in competition robotics; that way you don’t need to list all of the requisite features of a subsystem under “demand” with other criteria like “robot must drive around well”. Once you get this firm list and agree to it, you can work on the design details, formally incorporating things from the Manual in there. One should have read the full manual by now to know if everything sought after is legal, but this is when you spell it out in your requirements.

Here’s an example for the Vex game my IED team is working on. We never wrote this down, so I’m somewhat making this up, but it’s a good example.

  1. Robot must be able to drive over the stairs. The starting area and the part of the field with every single scoring opportunity besides autonomous is separated by a set of stairs. If we don’t climb the stairs, our robot is worthless. Your first priority should always be your drivetrain requirements.
  2. Arm must reach 14 inches in the air and pick up / touch objects on a shelf 6 inches deep. The highest value game pieces are behind an unlatched door with a doorknob about 12 inches in the air. Many game pieces are on a shelf as well.
  3. Gripper must hold soda cans, juice boxes, and cereal boxes. These game pieces have the highest point value and are also the easiest to grip.
  4. Robot must complete Autonomous Mode. It’s worth 2 soda cans, but is not required to play the game.
  5. Gripper must grab plastic bowl and utensils. Difficult to grip and only 5 points, so not as high a priority as the other objects.
  6. Robot must stow as many objects as possible inside itself. We can ferry items 1 by 1 to the human player so this isn’t required, but if we can add it in we will.

Pretty simple list outlining all of the tasks the robot can do in this game in a ranked order. This has led to some very interesting (in my opinion) design tradeoffs.

We removed all drive encoders from our drivetrain. This is pretty important for autonomous mode, so why was that done? The encoders were too big and would be pretty difficult to mount in a manner that didn’t interfere with climbing the stairs. Instead of spending a week working out a custom mount in CAD and stress testing, we just left them off the robot, and as a result we more quickly climbed the stairs. (Bump sensors are used to detect when to stop now. Not pretty but it works.)

How many times has your team had this problem? 2791 spent two weeks arguing about whether or not to keep working on a hanger. About 2/3rds of our team was working on that. Only one team member was working on a ball magnet. Just one person. If we stuck to this, someone would have stepped up and said “we don’t have ball control done, thus all work on the hanger needs to be dropped”, we could have been more competitive.