PALE · Pose And Localization Engine
Where does the robot think it is?
Long skills routes made our odometry estimate drift. I built PALE for 3142C to test corrections from field sensors, then found a harder problem: a plausible-looking correction can be wrong. When should the robot refuse it?
Interactive concept · illustrative simulation
Three ways to estimate one route.
Same route, different localization behavior. This simplified model explains the idea; it is not robot telemetry or a measured result.
MCL + PALE — PALE checks whether the correction is trustworthy, then corrects or holds the estimate.
Push adds a repeatable offset; play to watch localization recover.
MCL estimates where the robot is. PALE decides when that estimate is trustworthy enough to use.
The problem
A plausible pose is not proof.
Wheel slip and field contact can pull odometry away from the real position. A distance sensor might see another robot instead of a wall, and GPS can arrive in the wrong coordinate frame. A particle filter can still produce a convincing estimate from bad evidence.
MCL estimates possible positions. PALE is the robot-specific localization layer around it: sensor setup, GPS alignment, confidence checks, and the decision to correct or hold the current estimate. This page describes the implementation, not a measured claim of match improvement.
The loop
Estimate, then decide whether to trust it.
The development code configures 300 particles and a 20 ms update interval. That is a configuration, not a measured runtime or accuracy result.
Predict
Move a cloud of possible poses using odometry. The IMU remains the heading reference.
Compare
Compare each possible pose with distance-sensor readings against field walls. Reject blocked, oblique, or implausible readings; use GPS only after its field coordinate frame is aligned.
Decide
Use confidence and sensor coverage to decide whether a correction is safe. With no valid wall readings or GPS, the filter skips that measurement update instead of forcing a new pose.
What the last route taught me
A safe fallback is part of the design.
The code has gates for impossible odometry jumps, sensor readings that disagree with the expected wall, GPS alignment, and low-confidence particle estimates. It also records diagnostic events so a bad correction can be investigated afterward.
In the last recorded skills route, continuous correction was switched off while a one-shot localization step remained at the start. PALE remains an engineering experiment within our shared robot code. I cannot attribute a measured competition gain to it; the team's results belong to the whole robot and team.