Time-based auton guesses. Sensor-based auton knows. This guide shows you how to replace fixed delays and drive times with conditions the robot actually measures — and why that change alone can double your skills consistency.
pros::delay() or fixed drive times to control positioning, it will drift. Every time. The question is only by how much.A time-based autonomous says: "run the motors for 800 milliseconds, then stop." The assumption is that 800ms always moves the robot the same distance. That assumption is wrong.
This is why teams that dominate skills runs don’t use time-based positioning — they use sensors. The distance a robot travels in 800ms varies with:
Time-based auton asks: "how long?"
Sensor-based auton asks: "until when?"
Instead of:
You write:
The robot drives until the distance sensor reads 300 mm or less — regardless of battery, floor, or weight. This is the core advantage: the condition is measured reality, not a timed assumption.
pid_drive_set() — general navigation, turning, anything not near a wallAdd once to robot-config.cpp and expose it in the header.
dist_sensor.get() returns distance in millimeters. Print it to the Brain screen during testing to find your real-world target values.
const int SCORE_DIST = 295;Three lines. This is the entire sensor-stop pattern:
A single exact value (== 300) can be missed if the robot moves faster than the sensor can read. Use a range instead:
Sensors occasionally return a bad reading. Require two consecutive confirmations to eliminate false stops:
while (dist == 300) pros::delay(10);. At competition the robot never stops. What's wrong?while (dist > 300)dist_sensor.reset() firstwhile (dist == 300) keeps looping only while the distance is exactly 300 mm — which almost never happens at speed. The robot flies past 300 and the loop exits immediately when the condition becomes false (because the sensor reads something below 300). Always use a threshold condition: while (dist_sensor.get() > 300).Each time your robot approaches a wall, you have an opportunity to reset its known position. Top skills teams exploit this deliberately:
pid_drive_set(), pid_turn_set(). This is fast and reliable for general movement. Don't use the sensor here.A single scoring cycle showing how sensor stops integrate with EZ Template PID moves:
| Symptom | Likely Cause | Fix |
|---|---|---|
| Robot never stops at the wall | Sensor condition never triggers — threshold too tight or sensor not reading | Print sensor value in the loop; widen the distance threshold |
| Robot stops too far from wall | Distance threshold too large, or sensor field too wide | Reduce the threshold value; check sensor angle with mounting guide |
| Auton triggers inconsistently | Game pieces blocking sensor line-of-sight mid-routine | Relocate sensor; add a minimum time before sensor condition is evaluated |
| Distance sensor returns -1 or 9999 | Sensor port number wrong, or cable not connected | Verify port in Brain Devices menu; check Smart cable seating |
| Robot drifts even with sensor stop | PID settle not completed — robot stops before fully settled | Add chassis.pid_wait() after the sensor-triggered movement |
A single distance sensor handles most use cases. When you need more precision or want to catch edge cases, combine it with the IMU or encoders.
During a sensor-based approach, the robot can drift off-angle. Adding IMU correction keeps the approach perpendicular to the wall — which keeps the stopping distance accurate.
If the sensor cable fails mid-match, the distance loop runs forever — the robot drives into the wall. A timeout using encoder distance prevents this:
Write once, use everywhere. These three functions cover the most common sensor-based scenarios. Put declarations in autons.hpp.
speed until dist_sensor.get() ≤ target_mm. Default speed is 55 — safe for most approaches.Adding a pros::delay(800) after the sensor stop "just to be safe" defeats the purpose — the robot may not actually be at the right position when the timer expires.
== Instead of > or <The loop condition dist == 300 is almost never true at speed. The robot passes through 300mm in a single loop cycle and the condition is missed.
while (dist_sensor.get() > 300). The loop exits the moment you reach or pass the target.At 100+/127 speed, momentum carries the robot 30–60mm past the target before the motors can stop. The sensor reads the target correctly but the robot overshoots.
If the sensor cable disconnects mid-match, the loop condition is never met and the robot drives full speed into the wall until the match ends.
This drill separates "works sometimes" from "competition-ready." Run 10 consecutive reps from different starting distances. Measure and log the actual stopping position each time.
driveToWall(300, 55) from 6 feet, 4 feet, and 2 feet awaydriveToWallSmooth(300) and repeat the drill at higher speedSensor stops working. Now chain movements together efficiently with exit conditions to recover 1–2 seconds per auton run.
⚡ Exit Conditions & Chained Movements →