Implementing Manipulators in Competition Robotics

In the FIRST Robotics Competition, choosing a manipulator that achieves your team’s strategy goals is crucial to fielding a successful robot. However, designing and building one is often one of the most challenging aspects of the competition. Successful teams have learned how to use the engineering design process to produce better results in the short six week build season. This tutorial will teach you how to use this process to choose, prototype, refine, and implement a manipulator for FRC. Though this tutorial is about using the engineering design process in FIRST Robotics, a similar process can be applied to any engineering competition.

In industry, the engineering design process is usually a formal series of steps. In competition robotics, the formality is usually discarded in favor of a faster turnaround time. There are about as many different implementations of the engineering design process as there are engineers. In this tutorial, the general process we will follow is illustrated in the opening picture. In the FIRST Robotics Competition, this circular process is accompanied by the mantra “design is iterative,” as popularized by John V-Neun of Innovation First International.

To fully adopt and successfully implement this iterative approach to design is challenging. Your team will need to have the motivation to continue working even when you face repeated failure. You will have to be willing to develop and re-develop a manipulator until you achieve excellence. Attaining it will not come naturally, only through hard work not just during the build season, but during the rest of the year as well.

Finally, the process you use to implement a manipulator heavily depends on an honest evaluation of your team’s resources. A team that has access to materials, work time, and experienced people will operate differently than a second year team that is still learning the ins and outs of building a robot and only has several hours per week to work. Failing to make adjustments appropriate to your team’s capabilities will inevitably result in failure.

The pictures in this tutorial are primarily from my team's (FRC Team 2374) design process for the 2012 FRC game, Rebound Rumble.

This tutorial was made through the Autodesk FIRST High School Intern program.

Step 1: Develop a Strategy

The first step in designing a successful manipulator is to develop a strategy. It is important to understand the rules of the game before trying to choose your strategy. Otherwise, you may waste time developing a strategy that violates the rules. Most often, a team’s strategy will be a list of robot capabilities. Many teams also rank the robot features, using a system that labels each capability as a demand, a desire, or a wish. The example below possible robot capabilities and how they may be ranked:

The robot’s max speed is 8 ft/s – Demand
The robot’s max speed is 12 ft/s – Desire
The robot can shift with max speeds of 7 and 15 ft/s – Wish

As shown in the example, an important step in determining these capabilities is creating specific performance requirements for each feature. These create a quantifiable goal against which to measure your prototypes’ performance. Making reasonable estimates for performance requirements can be tricky, because they are often based on experience and intuition, especially for game specific tasks. In some cases, using physics to determine performance requirements can be beneficial. For example, teams in 2011 FRC game were able to use information about the allowed motors to determine the minimum possible time for a miniature robot to climb a 10 ft. tall pole.

The final part of developing a strategy is ensuring that it does not overshoot your team’s abilities. Your team must check that your goals are achievable with your given resources. If they are not, you must focus on fewer, higher priority objectives rather than spreading your team too thin.

Step 2: Brainstorm Solutions

The next step is to brainstorm ways to achieve each goal set out in your team’s strategy. There are many ways to brainstorm, so I will just provide a few tips to help you out. First, look at previous games if they had similar elements. For example, the 2012 FRC game was similar to the 2006 and 2001 FRC games. Since there are many robots from each year, an easy way to identify successful approaches is to look at videos from the championship matches. By seeing what manipulators the top alliances choose, you can easily get an idea of the best approaches. In addition, the Chief Delphi forum has a wealth of information about previous years.

Second, look at real world examples for inspiration. For example, a FRC team may have looked at a forklift if they were designing an elevator for 2011 game.

Finally, don’t reject ideas at this stage, as one crazy idea may inspire a brilliant one. In addition, if individuals see others’ ideas shot down, they may be afraid to share their own ideas.

Step 3: Choose Initial Prototypes

The next step is to choose which solutions for each task your team wants to prototype. Before you start narrowing down the list of brainstormed ideas, you must determine which systems need to be prototyped. If you have experience building a system on your robot, your team may not have to spend valuable time developing prototypes. After determining which systems you must prototype, begin to narrow down the brainstormed list of solutions. Begin by eliminating approaches that are obviously illegal, silly, definite failures, and not feasible. Now, there are many ways to determine which of the viable ideas should be prototyped. Some example methods include following team enthusiasm, using a Weighted Objective Table, and voting. Like so much of this process, the number of prototypes your team pursues should depend on your abilities. If your team must work on a strict schedule, don’t waste time making “fun” prototypes and instead focus on the most promising approaches.

More information about Weighted Objective Tables (WOT):
A WOT is a tool used by designers to quickly and objectively evaluate possible solutions to a problem. You can learn more about how to use a WOT in this paper.

Step 4: Begin Prototyping

Now, you can begin prototyping the designs you have chosen. However, if you narrowed your choices down to only one design, you may want to skip over this step and immediately begin refining that one design. If this is the case, it is wise to have a backup idea in mind in case your primary approach does not behave as expected.

At this stage, your prototypes do not even have to be close to perfect. Instead, they should demonstrate that a concept will have potential if it were further developed. Because the prototypes should be very crude, they should be able to be completed in one or two meetings. It is also important that testing is done to see how the prototypes actually behave, particularly in relation to the field elements. It is not necessary to have field elements built to do this. Instead, your team can use a crude mockup of the important elements using common items such as garbage cans.

Continue trying different ideas until your team has found one that will work. However, remember that you have very limited time during the build season. This stage of the process should not take longer than one week for the majority of teams.

Step 5: Refine a Single Design

Now that you have tested different rough approaches to the problem, your team must choose one design to further refine. This must be done objectively using the best data and information available. At this stage a simple vote is not an appropriate tool. Again, a Weighted Objective Table can be used to help make decisions (See Step 3 to learn more about this tool).

After selecting one design, your team can begin to refine your prototype. This is where the “design is iterative” mantra comes in. Only by iteratively improving a design will a team be able to meet their performance specifications. It is important to determine your team’s goal, or what it wants to learn, for each version of the prototype. This goal will guide the changes you make and help to indicate when to move on to the next iteration. If possible, measure the performance of your prototype at each stage. This will help your team determine how each iteration has improved (or diminished) the prototype’s performance. In addition, the measurements will help you determine if your improvements have helped you achieve your goal for the iteration.

Also during this stage, your design team should begin to figure out how each of the incomplete parts will interface together. Otherwise, you will have several different systems that do not function when assembled together.

Finally, you need to decide when you have refined the prototype enough begin final design. While the refined prototype does not need to work as well as the final version, your team does need to know how they can improve it. Knowing when you have reached this level of refinement is challenging. It requires knowledge, experience, and a fair amount of intuition.

Step 6: Design Final Manipulator

Now your team can design the manipulator that will ultimately appear on the robot. Most teams use 3D Computer Aided Design software such as Autodesk Inventor to do detailed design. This allows them to easily ensure that all of their parts fit before they are manufactured. At this stage, the design team must also integrate the manipulator with any systems it attaches to. In addition, they must incorporate any changes that could be made to improve the final manipulator.

Step 7: Build and Test

Now that the final design has been completed, the team must build and test it. Using whatever fabrication methods your team has available, build the robot you designed. Your team should aim to finish assembling the robot two weeks before they must stop working on it. These two weeks are critical and can make the difference between fielding a competent and a truly amazing robot. First, they give the programmers time to develop software on the final robot. They also give the mechanical team time to solve problems that arise. The two weeks give both teams time to make improvements that enhance robot performance. Finally, they give time for the drive team to practice and become better prepared for competition.

The process of iterative improvement does not end on “Stop Build Day.” If your team builds a practice robot, they can continue to practice and find improvements until their first competition. These improvements can then be added to the competition robot on the first day of the tournament. If your team attends multiple competitions, you are often allowed to make improvements based on your robot’s performance at the first. However, be aware that it is difficult at best to drastically change your robot from one competition to the next. You will have much better luck refining your robot’s performance at this point in the design process.

Step 8: Final Thoughts

Once you have finished your competitions, your team is ostensibly finished with the robot design process. However, many teams attend offseason events that are hosted within their area. If this is the case with your team, you may find it beneficial to continue working on your robot. Not only will you do better at the offseason events, but you will learn more as a team about the process of iterative development.

Hopefully this tutorial has given you the information you need to prototype and design manipulators more effectively. Though I tried to cover as many aspects of the design process as I could, I have inevitably missed important points. Listed below are several resources that you can use to learn more about the engineering design process and prototyping.

Finally, I would like to thank Jon Stratis, Isaac Rife, and Al Skierkiewicz, who answered my questions about how their teams prototype. Their insight helped me flesh out the process I outlined in this tutorial.