Req 5 — Show and Explain Your Robot

This requirement is your chance to show that the project is real. Your counselor is not just looking for a robot that moves. They are looking for evidence that you understand what it was supposed to do, how well it did it, and what you learned from the design process.

This requirement covers two connected jobs:

• showing the robot in action
• explaining the engineering decisions behind it

Requirement 5a:

A good demonstration is simple and repeatable. Start by explaining the task from Req 4a in one sentence. Then run the robot through the main action you designed it to do.

Before you demonstrate, prepare the area so the run is easy to understand. Mark the start point, the target area, or the obstacle with tape or simple labels. If your robot uses a sensor, point out what it is reading and what behavior that input is supposed to trigger.

What makes a strong demonstration?

• the goal is clear before the run starts
• the audience can see the important parts of the robot
• the robot shows the sensor-driven behavior, not just random motion
• you can explain what happened afterward

Requirement 5b:

Your notebook tells the story of the project. It should show the mission, design sketches, build notes, code or flowchart, tests, and improvement ideas. When you share it, do not just hand it over. Walk your counselor through the highlights.

How well did the robot accomplish the task?

Be honest and specific. “It worked” is not enough. Explain what it did reliably, what failed sometimes, and what evidence you collected during testing. If the robot only completed part of the mission, say that clearly and explain why.

What would you improve next time?

This is where real engineering thinking shows. Maybe the sensor needed better placement. Maybe the robot was top-heavy. Maybe the code needed a cleaner state change. Maybe the mechanism had too much friction. Improvement ideas matter because no first version is perfect.

What did you learn about the design process?

The design process is usually less like a straight line and more like a loop:

• define the problem
• imagine solutions
• plan and sketch
• build
• test
• improve

That last step sends you back around again. If you learned that simple designs are easier to debug, or that testing early saves time, or that your first mission was too ambitious, those are strong lessons to share.

By demonstrating and reflecting, you are doing something every real robotics team does after a build season: show the machine, review the results, and think about what comes next.