# data[].attributes.attachment_link.readable_text
The engineering design process is a series of steps that engineers follow when they are trying to solve a problem and design a solution for something; it is a methodical approach to problem solving. There is no single universally accepted design process, and most engineers have their own twist for how the process works. The process generally starts with a problem and ends with a solution, but the middle steps can vary.

One common characteristic of most design processes is that they are iterative and designers may have to go back to previous steps in the process and/or repeat the entire process over and over again until they reach a minimally viable solution.

The engineering design process outlined in this article is not the only correct version of the process, it is just one example. It should provide a good starting point for students to explore the engineering process.

A very simple design process may only include 3 steps as shown below: Define, Develop Solutions, and Optimize (this illustration is available as a full-size poster at posters.vex.com if you want one for your classroom!).

Another design process example is Project Lead The Way's Gateway Design Process.

Steps of the Engineering Design Process

For this article, we'll consider a design process that matches what Judges look for when interviewing teams and reviewing their engineering notebooks at REC Foundation competitions.

Identify the Challenge & Set Goals

This is sometimes referred to as "Ask" or "Define." Identifying the challenge should always be the first step that is addressed in the design process.

For the first iteration of the design process, the team's notebook should include a very brief description of the overall game challenge and break it down into smaller challenges that must be accomplished for success. Best practice is to list questions that need to be answered through research or testing, for example:

What is the most effective strategy for playing the game?

What are the ways to score points?

How fast does the robot need to move?

How can the robot pick up the scoring objects?

How many scoring objects does the robot need to hold?

Through this process, teams should come up with a list of features they might want in their robot, and lists of the game's requirements and constraints. For instance, if a challenge requires a robot to stack objects as high as possible, the team might decide they want their robot to be tall. However, the game manual may have a constraint on how tall the robot can be at any given time. All of these criteria should be explored and understood before moving on to the brainstorming phase.

For later cycles of the design process, this step might be to identify something on the robot that isn't working as well as expected or needed and to describe what a good solution would include. For example, a challenge might be that "The robot arm needs to be able to reach higher to score the ball," and a goal to accomplish the challenge might be "The bottom of the claw has to be able able to reach up to 16" when holding a ball." Constraints for this challenge may overlap larger constraints from the game, for example, size and vertical expansion limits.

Brainstorm & Diagram

Good brainstorming starts with a shared understanding of the problem, including all requirements and constraints. Without understanding the problem, time may be wasted on irrelevant ideas that do not satisfy the basic problem at hand. During brainstorming, it's also important to avoid judging each other's ideas. This can stifle the creative process and discourage team members from participating.

If it becomes clear that members of the team do not fully understand the problem, the team should start over at the first step of the process (i.e., "Identify the problem" or "Ask").

During brainstorming, students may also want to investigate challenges from the real world that are similar to the one posed by the game. They can also look to see if any other robotics competitions have utilized similar challenges in the past. Brainstorming includes gathering data from other sources to help students create a successful solution.

Promising solutions should be documented in the team's notebook, including labeled drawings or pictures. If the team gets ideas from other sources, those sources should be clearly identified in the notebook.

Choose a Solution & Make a Plan

Once brainstorming has been completed and several ideas have been generated, teams should objectively evaluate each idea. The goal is to find the best solution for the team, regardless of the source. A table might help teams consider and compare the merits of each idea in relation to specific design desires and constraints. In the example below, each criteria is evaluated on a 0-5 point scale where 0 does not meet and 5 exceeds expectations. Because "Idea 4" has the highest overall score, it would be the objective choice.

The team should document this process in the notebook, and explain how and why they choose their solution. They should also fully describe the solution in their engineering notebook, including a plan for how they'll build it. For advanced teams, this plan may include creating CAD models or detailed assembly drawings.

Build & Program

This is where teams will spend most of their time, and when prototypes and final robots and programs are created. Builds-both for code and for robots-generally start off as basic designs and evolve as details are added in later cycles of the design process. Students should take detailed notes in their notebook while building & coding, recording what they see, trying to figure out why some things work better than others, and then creating additional prototypes or programs to test new ideas. Gathering data, and recording it in the notebook, is an important part of building and coding.

Test the Solution

During this step, students will test what they've built or programmed to see what works, what doesn't, and what can be improved. Testing procedures should be well-documented in the notebook, and should include all measurable results. The main goal of this step is to decide whether the build or code meets the challenge and performs as expected and needed.

Repeat the Design Process

What happens when something doesn't work in testing? Students analyze the problem to identify the new challenge it presents, and they start a new cycle of the design process!

Not all design process cycles will need all steps, and some may jump from step to step or repeat a step multiple times before moving on to the next one. Design teams shouldn't be afraid of going backwards in the design process. The ultimate goal is to create the best design possible by improving it over and over again. Design cycles will probably overlap, too, especially between robot subsystems and code. Teams should do their best to identify which design process step(s) they're working in as they make entries in the notebook.

So how does a team decide when their robot is done? Simple: the team needs to set a schedule, and then stick to it. This schedule will vary greatly from team to team depending on their circumstances. If a team has six weeks to design and build their robot before the first competition, they should come up with some sort of schedule for this time period. Some teams will plan out each and every step in their build process while others will just do a quick overview.

The schedule is not always set in stone; ultimately the only fixed dates are the project start date and the robot completion deadline (usually the date of a competition). Everything else is likely to shift as the process unfolds.

# data[].attributes.attachment_link.description
The engineering design process is a series of steps that engineers follow when they are trying to solve a problem and design a solution for something; it is a methodical approach to problem solving...

# data[].attributes.attachment_link.readable_text
Introduction

The VEX IQ 2nd gen Competition Kit is a comprehensive collection of parts designed to facilitate advanced robotic design and problem-solving. The competition add-on provides additional components tailored for competitive environments.

The base VEX IQ 2nd gen Education Kit is comprehensive, but the competition add-on is designed for those seeking to engage in competitions. It offers enhancements for mechanical efficiency, sophisticated designs, and competitive advantages.

Categories of Parts and Their Applications

This section provides details on the exclusive components in the VEX IQ 2nd gen Competition Kit, which are absent in the Education Kit. For a complete list of the Competition Kit components, view this poster from the VEX Library. Note the Education Kit is the first page contents, and the second page is the Competition Add-On. Together, these two pages make up an entire Competition Kit.

This list presents the components exclusive to the Competition Add-On Kit. The kit also includes several foundational parts from the Education Kit, such as motors, connectors, wires, and wheels, ensuring a comprehensive building experience.

Competition Kit Benefits

Incorporating the competition add-on offers more than just additional parts; it broadens the scope of design possibilities. As robotics and STEM disciplines continue to advance, possessing the right tools becomes essential. The VEX Robotics Competition Kit, enhanced with the competition add-on, equips users for leading-edge innovation.

# data[].attributes.attachment_link.description
Welcome to the VEX Library, a library of information about all things VEX.

# data[].attributes.attachment_link.description
Welcome to the VEX Library, a library of information about all things VEX.

# data[].attributes.body
A drivetrain allows a robot to be mobile by using wheels, tank treads, or another method. A drivetrain is sometimes referred to as a drive base. Identifying which kind of drivetrain to use is one of the first considerations when designing a robot. The VEX IQ Clawbot drivetrain is fine for starting out, but additional drivetrain designs can allow the robot much more functionality, such as being able to move sideways in addition to turning and moving forward and backward. This type of movement is called omni-directional. Drivetrains may also be required to travel over obstacles. Robots which are being designed to play a game can gain a competitive advantage by selecting a drivetrain to match their game strategy.

# data[].attributes.attachment_link.readable_text
A drivetrain allows a robot to be mobile by using wheels, tank treads, or another method. A drivetrain is sometimes referred to as a drive base. Identifying which kind of drivetrain to use is one of the first considerations when designing a robot. The VEX IQ Clawbot drivetrain is fine for starting out, but additional drivetrain designs can allow the robot much more functionality, such as being able to move sideways in addition to turning and moving forward and backward. This type of movement is called omni-directional. Drivetrains may also be required to travel over obstacles. Robots which are being designed to play a game can gain a competitive advantage by selecting a drivetrain to match their game strategy.

Some Things to Consider when Selecting a Drivetrain for a Competition Robot

Are there obstacles on the playing field which need to be driven over or climbed up on? Tank Treads or larger diameter wheels can help with going over obstacles.

How much of an advantage is there for the drivetrain to be omni-directional?

Is the drivetrain going to be pushing multiple/heavy game pieces, or does it need to be fast? The maximum speed or torque produced by a drivetrain can be adjusted by changing to a different gear ratio and/or by changing the diameter of the wheels.

How high and how far out will the robot design be able to reach? Robots which reach high and/or reach out, benefit from a larger drivetrain footprint and a lower center of gravity. Small diameter wheels can help with both.

How many motors are going to be needed for functions other than the drivetrain? Some game rules limit the number of motors on a robot.

These considerations are examples of the analysis which should be used when selecting a drivetrain for a classroom game robot or a VEX IQ Challenge robot.

Descriptions of Some Types of Drivetrains

Standard Drive

Standard Drive Base

H Drive

H Drive

Holonomic

The Holonomic Drivetrain is omni-directional. This design can be assembled with either three 200mm Travel Omni-Directional Wheels and three Smart Motors or four 200mm Omni-Directional Wheels and four Smart Motors.

The three Omni-Directional Wheels and three drive motors version is assembled with the wheels set at 120 degrees to each other. The Kiwi drive build instructions feature this type of drive.

The four Omni-Directional Wheels and four motors version can be assembled by either angling the wheels at each of the corners (sometimes called an X drive) or placing the drive wheels at the center of each side of the drive base.

These Holonomic Drivetrains require a more complex programming code for their motion than the Standard Drive. The 3 wheel drivetrain is not as stable as the 4 wheel drivetrains.

Kiwi Drive

X Drive

Track Drive

Track Drive

Comparison of Some Types of Drivetrains

Safety Hazard:

Pinch Points

Slowly move wheels, sprockets, and gears to ensure there are no wires, tubing, elastic materials, or hardware which will be caught by the motion, before powering up the robot.

# data[].attributes.attachment_link.description
Welcome to the VEX Library, a library of information about all things VEX.

# data[].attributes.body
Let Mrs. Williams know if you would like her to assign you a self-paced coding class for over the summer (python or C++)

# data[].attributes.body
Use your APS Google credentials to register for this class.

# data[].attributes.attachment_link.readable_text
Create a student account

Not in a section?

Create a school administrator account

Create a teacher account

Create a free account Create a basic account Create a grading account

Have a class code?

# data[].attributes.attachment_link.description
Create a student account Not in a section? Create a school administrator account Create a teacher account Create a free account Create a basic account Create a grading account Have a class code?

# data[].attributes.attachment_link.description
Welcome to the VEX Library, a library of information about all things VEX.

# data[].attributes.body
When building a custom VEX IQ Robot, sometimes you just need more power. One easy way to do this is to add another motor. These two motors working together are known as a motor group.

# data[].attributes.headline
Downloading and Running a VEX IQ Blocks Project

# data[].attributes.subject
Downloading and Running a VEX IQ Blocks Project

# data[].attributes.attachment_link.readable_text
Next, connect the Brain and check that its icon is green and the Download and other icons are white.

Then, select Download to download the project to the Brain's selected slot.

Note: The Download, Run, and Stop icons will be disabled until the download is complete.

Your project will show in the Programs menu on the Brain screen. A (1st generation) Brain is pictured on the left, and a (2nd generation) screen is pictured on the right.

# data[].attributes.attachment_link.description
Welcome to the VEX Library, a library of information about all things VEX.

# data[].attributes.attachment_link.title
Simple Motorized Lift - Building Instructions

# data[].attributes.attachment_link.title
The Engineering Design Process | Purdue SIGBots Wiki

# data[].attributes.attachment_link.description
The Engineering Design Process is a fluid series of steps used to streamline and maximize the efficiency of progress designing, building, and testing a robot.

# data[].attributes.attachment_link.readable_text
When considering this criteria in writing an Engineering Notebook, it is important to repeat this step for every design cycle. The objective should be to gain a sufficient understanding of the regulations and guidelines, compile insight on field integrants and setup, and identify the general focus of the game. One common example of this criteria is a game analysis segment at the beginning of the notebook. Many instances, however, do not follow up with any further analysis or design briefs later in the notebook, and often lose points because of this.

To obtain maximum points in this segment, it is important to repeat the criteria for every major design cycle and thoroughly analyze the problem(s) in question. Having a set of actionable goals that can be easily translated into Gantt Charts or other similar timelines also goes far to increase points earned in this category.

For this criteria, it is important to remember that just listing solutions, while important, is not enough to secure maximum points. Each solution must have a thorough analysis and breakdown describing how it could be used to meet the goals established from the section above.

In addition to showcasing more thought behind each solution, adding this additional detail can be very beneficial to tie into the next rubric criteria. Just as well, be sure to list three or more solutions - while this is a minor part of the criteria, it is still important to meet for maximum points.

While Decision Matrices are the most common method of addressing this criteria, and for good reason, there are other methods that should be used to supplement the standard Decision Matrix. Although mentioned briefly, testing is a phenomenal way to increase the amount of points scored in this criteria. Using testing data for each solution as an additional factor in a Decision Matrix can help to make a more informed decision for your robot, as well as stand out compared to other Engineering Notebooks.

Additionally, it is important to follow up the Decision Matrix with a detailed plan to implement the solution. This can be accomplished with a variety of methods, some of which could include Gantt Charts, lists of steps to take, and resource allocation tables.

The key to achieving maximum points for this criteria is through use of extreme detail when recording the action process for this step. Achieving a high level of detail can be accomplished through recording each step to complete the action, a list of all parts used in each step, and pictures of the action at various stages of completion, as a few examples.

One additional item to consider for this criteria is consistency - many engineering notebooks will begin with a high level of detail for the overall initial robot design at the start of a season, and then begin to use less detail with smaller changes later in the season. It is important to introduce a consistently high level of detail throughout the season for maximum points.

Although prominent in the rubric, this section is a very common loss of points for many teams. There are many way to introduce good testing into a notebook, the first of which being to intertwine the testing with other rubric criteria. For instance, rubric tacked on to an entry will receive less points than testing used to support the results of a decision matrix or to highlight a problem that needs to be solved.

Additionally, maintaining a consistent level of testing throughout the season is essential to receive maximum points on the rubric. Testing after each change to the robot or program will receive more points than testing once a few days away from competition.

In addition to meeting this criteria, repeating the Design Process throughout the notebook will reinforce the other criteria on the rubric, as each criteria will have more opportunities to be repeated and shown to judges - making Criteria 6 that much more important.

In the beginning stages of your robot, researching for the tasks to be completed is necessary, as many released designs or otherwise may be used as inspiration. This criteria showcases imagination and creativity in not only building, but also prototyping and designing your robot. Many, or most, designs should be original and genuine rather than "holecounted" from another team.

Criteria 7 should demonstrate and verify Criteria 2 of brainstorming and prototyping designs. Innovation and originality may lead to effective design and show how those outcomes are possible.

In completing the previous seven criteria effectively and in detail, this criteria should be met without that much additional effort on behalf of the team. Specific to this step, it is important to clearly indicate the level of progress in each design cycle as it is being recorded. Having a clear record of the current step in each iteration or cycle will make the project history much more comprehensible.

This criteria provides several good methods to record Project Management within the description itself, which are a key method towards achieving maximum points for this criteria. Relevant to other criteria, it is important to make sure that Design Cycles are labeled according, as described in Criteria 6, as well as thoroughly recording the details in each design cycle.

Specific to this criteria, the addition of charts and tables showcasing budget constraints and material and resource (parts, plastic, time) allocation are essential towards receiving maximum points.

With this criteria being fairly self-explanatory, the main thing to keep in mind is to consistently record the name and date on each entry. Otherwise, a well-organized table of contents is essential to earning maximum rubric points.

# data[].attributes.attachment_link.title
Engineering Notebook Rubric Breakdown | Purdue SIGBots Wiki

# data[].attributes.attachment_link.description
When considering this criteria in writing an Engineering Notebook, it is important to repeat this step for every design cycle. The objective should be to gain a sufficient understanding of the regulations and guidelines, compile insight on field integrants and setup, and identify the general focus of the game.

# data[].attributes.headline
Block Coding Tutrial -2. Adding Semi-Automation to Driver Control

# data[].attributes.subject
Block Coding Tutrial -2. Adding Semi-Automation to Driver Control

# data[].attributes.attachment_link.title
VEXcode IQ Blocks - 2. Adding Semi-Automation to Driver Control

# data[].attributes.headline
Block Coding Tutorial - 3. Simple Autonomous Movements

# data[].attributes.subject
Block Coding Tutorial - 3. Simple Autonomous Movements

# data[].attributes.attachment_link.title
VEXcode IQ Blocks - 3. Simple Autonomous Movements

# data[].attributes.headline
Block Coding Tutorial - 4. Displaying Information on the Screen

# data[].attributes.subject
Block Coding Tutorial - 4. Displaying Information on the Screen

# data[].attributes.attachment_link.title
VEXcode IQ Blocks - 4. Displaying Information on the Screen

# data[].attributes.headline
Block Coding Tutorial - 5. Using the Touch LED

# data[].attributes.subject
Block Coding Tutorial - 5. Using the Touch LED

# data[].attributes.attachment_link.title
VEXcode IQ Blocks - 5. Using the Touch LED

# data[].attributes.headline
Block Coding Tutorial - 6. Using the Colour Sensor

# data[].attributes.subject
Block Coding Tutorial - 6. Using the Colour Sensor

# data[].attributes.attachment_link.title
VEXcode IQ Blocks - 6. Using the Colour Sensor

# data[].attributes.headline
Block Coding Tutorial 8. Using the Colour Sensor to Sort Objects

# data[].attributes.subject
Block Coding Tutorial 8. Using the Colour Sensor to Sort Objects

# data[].attributes.attachment_link.title
VEXcode IQ Blocks - 8. Using the Colour Sensor to Sort Objects

# data[].attributes.attachment_link.description
Engage users, become greener and modernise your technical communications with 3D instruction manuals from Cadasio

# data[].attributes.attachment_link.readable_text
The VEX IQ Smart Motor has many functions to use when coding in VEXcode IQ. This can come in handy when coding arms, claws, and intakes as well as drivetrains and other mechanisms created using VEX IQ. Understanding how the motors can be coded will help to alleviate issues such as projects stalling or motors not working as intended.

Motor Encoder

Not only does the VEX IQ Smart Motor turn electrical energy into mechanical energy, as most motors do, it also has features that most motors do not have, which make it "smart." One of its main features is the quadrature encoder. This encoder is mounted on the interior of the motor in order to track the speed and/or the position of the motor shaft.

Reports from the VEX IQ Smart Motor's encoder make it possible to know:

The direction of the motor's turn (forward/reverse or open/closed)

The position of the motor and the amount of the motor's turn and position (either in turns or degrees)

The speed of the motor's turn (based on the encoder's position over time)

Because the encoder reports the motor's states, they can be used in behind-the-scenes calculations to make many of the Motion and Sensing commands work within the VEXcode IQ.

Coding Individual Motors

Before beginning to code individual smart motors in VEXcode IQ, you need to configure the motor. Individual motors are frequently used for additional mechanisms like intakes, arms, and claws. However all of the information does still apply to other mechanisms using individual motors.

With a single motor configured, commands to control that motor will appear in the Toolbox. You will notice there are different types of commands: waiting and non-waiting.

Waiting versus Non-Waiting Commands

Note that all of the images here show blocks. All of these projects can be rebuilt in Python or C++ and contain the same functionality as blocks.

Motor Timeouts

When coding a motor as part of an arm or claw, it is important to remember the difference between waiting and non-waiting blocks and how those will impact the movement of your robot. Motor timeouts allow you to set a time limit for the motor to reach the intended target position. If it has not met that position when time expires, the motor will stop trying to spin and the project will move to the next command.

Coding Smart Motors as Part of a Drivetrain

Before beginning to code a drivetrain in VEXcode IQ, you need to configure the drivetrain including the motors used. The motors are configured within the drivetrain to ensure they are controlled with the same commands like [Drive] and [Drive for].

Waiting and Non-Waiting Commands

When coding a drivetrain, waiting and non-waiting commands are available to control the movement of the robot.

# data[].attributes.attachment_link.description
Welcome to the VEX Library, a library of information about all things VEX.

# data[].attributes.attachment_link.readable_text
Sensors provide the ability for a robot to receive feedback from the environment. There are a variety of VEX IQ (2nd gen) sensors that can be used to obtain different types of input for the robot. The table below provides an overview of what each sensor can do, and examples of how it can be used in a project.

VEX IQ (2nd gen) Sensor Comparison Table

Sensor

Function

Example Uses

Bumper Switch

Tells the robot whether its bumper is pressed (sensor value of 1) or released (sensor value of 0).

Detecting if the robot has bumped into an object, such as a maze wall or game object

Triggering a robot action, when pressed or released

Toggling to turn on or off motors when pressed

Detecting other parts of the robot, such as an arm, when it presses in the bumper

Touch LED

Can detect capacitive touch, such as the touch of a finger.

Can be set to display many colors.

Triggering a robot action when touched

Starting or pausing a program when touched

Displaying different colors during different parts of a program, so it is easier to pinpoint code for troubleshooting

Optical Sensor

Detect the color of an object

Detect an object

Detect the brightness level of ambient light

Measure the numerical Hue Value of an object

White LEDs on the sensor can provide a consistent light source when detecting colors regardless of the surrounding light conditions.

Coding the robot to interact specifically with an item of a certain color, such as sorting cubes by color

Detecting whether an object is present, such as a wall or game object

Triggering the robot to perform a behavior when the light level is at a certain brightness

Understanding precisely how the Optical Sensor is detecting color in varied lighting conditions

Following a line

Detecting whether an object is present

Distance Sensor

Detects if there is an object in front of it

Measures the distance between itself and an object

Determine the relative size of an object

Reports the velocity of an object

Driving forward until the sensor detects that it is a certain distance away from a wall, then stopping driving.

Driving forward a certain distance to pick up a game object

Driving away from an object or surface until it has reached a specific distance

Interacting with an object that is one size and avoiding interacting with an object that is another size, such as picking up only the small balls on a Field

Determining the velocity of an approaching object and printing it on the Brain's screen

Additional Sensor Information

Note that the IQ (2nd gen) Brain has a built in Inertial Sensor rather than a Gyro Sensor. For detailed information on IQ (2nd gen) Sensors, see the following articles:

# data[].attributes.attachment_link.description
Welcome to the VEX Library, a library of information about all things VEX.

# data[].attributes.attachment_link.readable_text
This sensor is a switch. It tells the robot whether its bumper is pressed (sensor value of 1) or released (sensor value of 0).

How the Bumper Switch Works: Completing the Circuit

The VEX IQ Bumper Switch is based on probably the most commonly used electrical device: the switch. A switch consists of two terminals (places to attach a wire) and a wire bridge to 'make' the connection when the switch is pressed. As shown in this animation, when you press on the connecting wire you 'complete' the circuit, and the Robot Brain registers that in your program!

Basically the Bumper Switch is a part of a circuit which is unconnected, or broken. When you press the Bumper Switch, the connection is made, and electricity is allowed to flow.

Common Uses of the Bumper Switch

This sensor can trigger a robot action when pressed or released.

This sensor can be used as a toggle to turn motors on and off when pressed, as shown in the animation below.

This sensor can detect walls or objects when the bumper runs into them, as shown the animation below.

The sensor can detect other parts of the robot, such as an arm, when it presses the bumper.

Uses of the Bumper Switch on a Competition Robot

While in autonomous mode, a Bumper Switch can be used so that your robot will wait to carry out a certain action until it is pressed by some sort of object.

The Bumper Switch can detect when it comes into contact with a surface such as a perimeter wall, or an object such as a game piece.

Two Bumper Switches can be used, for example on the front and side of the robot, so that the robot can position itself in a corner. Then the robot can more accurately navigate from that corner to other positions on the competition field.

You can use a Bumper Switch to have your robot detect when one part of it, such as its arm, comes into contact with another part of it, such as its chassis.

Using the Bumper Switch in VEXcode IQ

Adding the Bumper Switch as a Device in VEXcode IQ

Coding the Bumper Switch in Blocks

Coding the Bumper Switch in Python

Note: To code an VEX IQ (1st generation) Bumper Switch in Python, it must be connected to a VEX IQ (2nd generation) Brain. The VEX IQ (1st generation) Brain does not support Python.

drivetrain.drive(FORWARD)
while not bumper_1.pressing():
 wait(20, MSEC)
drivetrain.stop()

# data[].attributes.attachment_link.description
Welcome to the VEX Library, a library of information about all things VEX.