Testing and reliability
Build reproducible tests, isolate failures, interpret trial results, and qualify the integrated robot.
Reliability is the ability to perform the intended task under stated conditions repeatedly. A demonstration shows that success is possible; a test program investigates how often it happens and why it fails.
Repeatable tests
Record the and versions and the conditions that could affect the result: battery, load, surface, game pieces, and starting position. Say what the robot should do, how you will measure it, and what counts as a pass. Decide how many attempts to run before starting, and record the failures too.
Separate subsystem tests from integrated tests. A bench can pass its pickup test while a complete robot fails because the lift the object's path. Repeat the affected task after and after changes to shared interfaces.
Results and recovery time
For a task, record success, time, miss type, jam, damage, and recovery. Look at the spread of times as well as the average. An occasional long jam can matter more than a small improvement in the typical successful cycle.
For an illustrative 20-run test with 18 successes, the observed success fraction is 90%. That is a description of those runs, not proof that every match has a 90% success probability. Similar starts, one driver, a fresh battery, and a small sample limit what can be inferred.
Broaden conditions deliberately: different object orientations, reasonable start errors, the actual payload, repeated operation, and simultaneous use. Change one factor first to understand its effect, then test realistic combinations.
Fault diagnosis
Start with the symptom and identify what is known. "Lift stopped at half travel" is an observation. " is weak" is a hypothesis.
| Symptom | Useful first checks |
|---|---|
| High effort with little motion | Binding guide, cable snag, hard stop, overloaded linkage |
| moves but output does not | Loose hub, slipping transmission, broken string, wrong measured |
| Fault only during simultaneous actions | Shared current demand, drop, interference, physical collision |
| Failure after replacement | Wrong revision, spacer stack, direction, reference position, |
| Position changes after a collision | Loose joint, bent mount, shifted , lost reference |
Use a known working part, cable, battery, or code revision as a controlled substitution where appropriate. Avoid changing several components together unless immediate safe shutdown requires it.
Transfer and launcher tests
Run a complete load through the robot's actual intake, staging path, and launcher. Hand-placing every object directly against the flywheel can hide a transfer problem.
Use a short record for each object:
| Record | What it helps separate |
|---|---|
| Arrival and release times | Slow delivery, inconsistent spacing, or an unexpected pause |
| Staging and passage readings | A missed object, double feed, or sensor placement issue |
| Wheel speed before and after contact | Speed recovery from changes in arrival conditions |
| Shot result | Whether the chosen feed interval still gives acceptable accuracy |
| Jam and recovery outcome | A recoverable miss from a sequence that disables the mechanism |
When two changes happen together, such as lower wheel speed and an off-center feed, investigate both rather than assigning every miss to tuning. Repeat the sequence with driving and other intended simultaneous actions. Stop a trial if a roller remains blocked or a component overheats; do not complete a run at the expense of the hardware.
Failure priorities
List credible and their consequences. Give attention to failures that disable the robot, cause damage, create unsafe motion, or cannot be recovered from during a match. Include how the failure is detected and what the operator or software should do.
A transfer may return to a known holding state. A failed home switch may require stopping the lift and alerting the driver. A broken retention clip may require a physical design change. A retry is useful only when its starting state and attempt limit are defined.
Robot testing
Run representative match sequences with the intended driver, payload, simultaneous actions, and battery routine. Inspect the robot between runs for wear, loose , hot components, shifted mounts, and string damage.
Repeat the affected tests after repairs. Preserve the passing evidence for unchanged behavior, but rerun anything whose geometry, code, power demand, or calibration changed. Keep the raw results so a new student can distinguish a measured limit from team folklore.