Engineering Process

We follow the Engineering Design Process in our projects. For a general description, read https://curriculum.vexrobotics.com/curriculum/intro-to-engineering/what-is-the-engineering-design-process.html. The following describes our implementation of the process for the mechanical design of both competition robots and offseason projects. Similar processes can be applied to software design or other areas of the team.

Step 1: Define the Problem

For designing solutions to competition games, this involves reading the rules. The rules give us a description of the exact problems that need to be solved. It is important at this stage to only consider the actual, hard requirements imposed by the rules. Assuming too much about the form the solution will take is a critical error when analyzing the games. Try to avoid jumping to the first solution that comes to mind.

For offseason projects, the problem is often known before the project is started. “Build a t-shirt cannon” seems pretty self-explanatory. However, it is important in these cases to make sure that the reason why we are doing the project is well-defined, and everyone involved agrees on what will be considered a successful outcome to the project.

Step 2: Gather Data

This step is about discovering what factors will affect the performance of different designs.

We might do mathematical experiments or build a few small mechanical models if we need to test the physics of interacting with different types of objects. We also do research into past designs from our team and other teams if there are previous years’ games that share elements with the current challenge. For competition games, we run mock matches with humans standing in as robots in order to get a sense of how the game flows and start figuring out what strategies might be.

Step 3: Determine Solution Specifications

Based off of our experiments in Step 2, we define a set of general capabilities or attributes that the final design must have in order to be successful at the problem as we defined it in Step 1.

These specifications should be independent of any particular mechanical solution. “Must be able to travel at least 10 feet per second,” “must be able to hold at least 18 balls,” or “must be at able to shoot at 80% accuracy from 15 ft” are good specifications. “Must have a claw” is not. Specifications should almost always be quantitative – i.e., be measurable and have a specific number as part of the specification. “Must be able to travel at least 10 feet per second” is a good specification, “must be able to go fast” and “must be aesthetically pleasing” are less so.

Step 4: Generate Concept Solutions

Next, we brainstorm different solutions that will meet the specifications created in Step 3. This is the point where we begin creating specific, realizable, and testable designs.

We start by sketching the designs, either on whiteboards or on paper. We find this to be the fastest way of communicating the design to others for initial feedback.

For projects with a larger number of people working on them, such as the FIRST competitions, we may also do initial brainstorming in small groups before regrouping to share all the ideas.

The objective at this point is to fully explore the space of possible designs. The process after this will largely consist of narrowing down to a single solution, so we want to make sure to start with as large a number of possibilities as possible to make sure we don’t miss something that might lead to a superior solution.

Step 5: Prototype the Solutions

The purpose of creating prototypes is to discover exactly how well the design concepts generated in Step 4 perform on the criteria created in Step 3. Prototypes are simple versions of the design concept that can be built quickly in order to test out the essential aspects of the design.

When creating prototypes, it is important to keep in mind the principle of failing fast (see above) and always be asking yourself 1. what the prototype you’re working on is trying to prove or disprove and 2. what the fastest way to come to that conclusion is. It is wasteful, primarily in time but also in material, to create an elaborate prototype of an entire design when a simpler model can be made that can test the necessary characteristics.

Spend as much time on each design concept as it needs, but always keep an eye on efficiency. The objective of this stage is to fully test as many different designs as we can.

Step 6: Choose a Final Concept

In Step 6, we evaluate the designs against the criteria developed in Step 3 using the results from the prototypes. We then pick the best one to turn into the final product.

There are many ways to decide which design concept is the best. Some teams vote on the designs, but we prefer to let the numbers do the talking rather than popularity. A tool called a Weighted Objective Table is helpful in integrating all the data and producing final scores for each design concept. Read the white paper at http://www.chiefdelphi.com/media/papers/2175 for an introduction to WOTs.

If the robot will have several mechanisms to do different tasks, this process may be performed separately for each one.

Step 7: Do Detailed Design

Now that we have settled on a design concept, we must make sure that it will perform with the level of reliability and robustness required of the production robot. The design we’ve come up with must also be integrated with the other parts of the robot - other mechanisms, electrical and pneumatic systems, etc. We can also fine tune parameters of the design during this stage - lengths of arms, gear ratios, materials used for construction, etc.

This is a lot to keep track of, and the design can get very complex, so we use computer aided design (CAD) tools to create the detailed design. These tools allow us to create a virtual model of the entire robot before we begin building. Keeping in mind the principle of failing fast, virtual parts on the computer can be changed and redesigned much more quickly and cheaply than physical parts.

Step 8: Get Feedback & Approval

During the course of the detailed design process, mentors and students collaborate in order to create the best version of the design possible. Once the CAD model is complete, we do a final design review with the entire team so that everyone on the team has a chance to review the design and point out where improvements can be made.

Step 9: Implement the Detailed Solution

After the computer model of the design is complete and is reviewed by the team, we use the dimensions taken from the model in order to manufacture physical parts.

Adjustments to the design may need to be made if problems are encountered in the transition from virtual to physical parts.

Step 10: Test the Solution

Once the robot has been built, we test the design to make sure it performs as it is designed to, and actually meets the specifications we created for its performance.

This testing can be end-to-end testing of the robot on a practice field, or stationary tests of each mechanism individually.

Step 11: Iterate

Based off of the results of testing, improvements or corrections are made to the design. Depending on the severity of the issues encountered, the process to make improvements may begin at Step 7, or may jump back to Step 4 if the design solution chosen previously has fundamental issues and a completely new solution needs to be pursued.

The team should leave enough time in its project schedules to allow for testing and iteration to occur. This is a very essential part of the process. The likelihood that we’re able to design a robot that’s perfect the first time through is basically 0.

The team should also continue iterating through the entire competitive season. This is why we say the build season extends through the end of March, even though FIRST says the build season stops in mid-February. We’re always trying to find ways to improve and upgrade the robot.

Failing Fast

The principle of failing fast is this: why continue doing something when you can tell early in the process that the current approach won’t work? Failing fast should be seen as a positive outcome - you are saving the team time, energy, and resources. It allows you to more quickly pivot to an approach that will succeed.

Team 766 strives to apply the principle of failing fast to all our endeavors. In engineering projects, this means that we do small, simple experiments before we commit to a design, and we continue to look for ways to do testing at every stage of our development. In team management, we fail fast by being open to continual changes in team planning, and by assigning specific responsibilities on the team, instead of just electing people to office.