Run a Real Design Review

A design review is not a presentation where everyone politely admires the robot.

It is a structured attempt to find weak assumptions before competition finds them for you.

Review claims, not personalities

Every major subsystem should make claims such as:

• meets the game requirement;
• fits within robot constraints;
• can be operated safely;
• has enough torque/speed;
• has a valid electrical/control architecture;
• can be serviced;
• has been tested under realistic conditions;
• has a recovery plan.

The review asks for evidence behind each claim.

Traceability

A useful chain is:

game / system requirement
      ↓
design decision
      ↓
implementation
      ↓
test
      ↓
evidence
      ↓
remaining risk

If a design decision cannot be connected to a requirement, ask why it exists.

If a requirement has no test, it is still an assumption.

Example review

Requirement:

Intake must acquire a game piece from a reasonable approach angle.

Design decision:

Use compliant rollers and a funnel.

Evidence:

18 successful acquisitions in 20 controlled trials across three approach offsets.

Remaining risk:

Success rate dropped when the piece contacted the outer frame first.

Revision:

Increase funnel guidance and repeat the edge-case test.

That is much stronger than “the intake works.”

Build your review board

Create sections for:

• architecture;
• mechanical systems;
• electrical/CAN;
• software;
• sensing/control;
• autonomous/driver interface;
• strategy;
• reliability;
• safety/inspection.

For each section, include one claim, one piece of evidence, and one unresolved risk.

Red-team your own robot

For five minutes, stop defending the design.

Try to break the claims on paper.

Questions:

• What depends on one connector?
• What happens after a hard impact?
• What fails if a sensor lies?
• Can the driver cancel automation?
• What happens at lower battery voltage?
• Can a critical part be replaced quickly?
• Which subsystem has the weakest test evidence?
• Which rule assumption needs to be rechecked?

The goal is not negativity. It is finding cheap failures before they become expensive failures.

Failure mode: review by confidence

Senior students and mentors can be wrong with impressive vocabulary.

Ask for the test record.

Confidence is not evidence. The robot does not care who sounded certain in the meeting.

Your design-review board becomes the skeleton of the final dossier.