Simulador de seguimiento de trayectorias: Pure Pursuit
Recorre un circuito con Pure Pursuit o Stanley considerando retardos de dirección reales. Ajusta la distancia de mira y analiza el impacto del ruido GPS.
- Categoría
- Robots autónomos
- Tiempo
- 20–40 min
- Plataforma
- Browser · Arduino · Raspberry Pi
01 / Empieza aquí
Introducción
Un planificador entrega una trayectoria geométrica, pero no indica cómo gobernar los actuadores. Este simulador cubre esa brecha comparando Pure Pursuit y Stanley sobre un circuito de waypoints, considerando retardos de dirección y sensado. Un modelo sin retardos aparenta óptimos falsos; aquí, al mover los waypoints o la distancia de mira, la trayectoria completa se recalcula en tiempo real.
Live lab / Path following
Path following simulator
Pure pursuit and Stanley steering the same course, with the lag a real robot has. Drag the lookahead and the whole run replots — too short oscillates, too long cuts corners, and the best value moves with speed.
The dashed line with dots is the course you asked for; the solid line is where the robot went. The faint line is the whole run at the current settings, computed the moment you change one. Below, cross-track error along the path — dotted verticals are corners. Drag a waypoint to rebuild the course.
- Commanded path
- Driven
- Full run preview
- GPS fix
- RMS error
- —
- Worst error
- —
- Corner cut
- —
- Steering effort
- —
- Progress
- 0%
- Lap time
- —
Keyboard: focus the course, then Space to run/pause, N to step, R to reset, C for a new course, F for full screen. Press 1–8 to pick a waypoint and the arrow keys to move it.
Controles
Controlador permite alternar entre Pure Pursuit y Stanley. Distancia de mira es el parámetro central de Pure Pursuit (deshabilitado en Stanley, que no lo utiliza).
Velocidad y distancia de mira interactúan fuertemente: analiza la respuesta óptima a 1 m/s y compárala posteriormente a 3 m/s.
Fuente de posición sustituye la odometría ideal por una señal GPS de 1 Hz con ruido métrico retenida entre periodos. El error siempre se puntúa frente a la trayectoria física real.
Arrastra cualquier punto de paso (waypoint) o pulsa 1–8 para seleccionarlo y reubicarlo mediante las flechas del teclado.
Teoría
Ambos esquemas resuelven el cálculo del ángulo de dirección a partir de la pose actual y la trayectoria deseada, pero desde paradigmas distintos:
Pure Pursuit se basa en pura geometría. Determina un punto objetivo sobre el camino a una distancia de mira L_d por delante y calcula el arco circular tangente que conecta el eje trasero con dicho punto:
κ = 2y / L_d² δ = atan(2 b sin α / L_d)
donde y representa la desviación lateral del punto objetivo en el marco del robot y b es la batalla entre ejes. Posee un único parámetro con dimensión de longitud, facilitando su extrapolación entre distintos vehículos.
Stanley se basa en teoría de control. Toma como referencia el eje delantero y suma dos contribuciones:
δ = θ_e + atan(k · e / v)
el error de orientación relativo a la tangente de la trayectoria más el arco tangente del error transversal escalado inversamente con la velocidad. Dividir por la velocidad permite conservar estabilidad en un amplio rango dinámico. La ganancia k es adimensional y específica de cada vehículo.
Algoritmo
En cada periodo de control:
- Proyectar la posición del robot sobre el camino, restringiendo la búsqueda en una ventana próxima a la longitud de arco alcanzada en la iteración previa.
- Resolver empates en esquinas asignando la proyección al segmento saliente, evitando errores ficticios nulos mientras el chasis continúa recto.
- Calcular el ángulo de dirección según la ley seleccionada y acotarlo a los límites mecánicos del tren delantero.
- Aplicar los retardos dinámicos e integrar el modelo cinemático de bicicleta.
- Calcular el error respecto a la verdad fundamental física.
Código fuente
Implementación completa de Pure Pursuit lista para microcontrolador:
float lastS = 0; // arc length last reached — state, and it only moves forward
float pursue(float x, float y, float heading, float speed) {
// The lookahead is scheduled on speed, with a hard floor: at a standstill a
// proportional schedule asks for zero, which is a division by zero in disguise.
float lookahead = constrain(0.7f * speed + 0.4f, 0.4f, 3.0f);
float s = projectOntoPath(x, y, lastS); // windowed around lastS
lastS = max(lastS, s);
Point goal = pointAtArcLength(lastS + lookahead);
float dx = goal.x - x, dy = goal.y - y;
float lateral = -sinf(heading) * dx + cosf(heading) * dy;
float ld = max(0.3f, hypotf(dx, dy)); // clamp, or curvature blows up
float curvature = 2.0f * lateral / (ld * ld);
return curvature; // omega = v * curvature
}
Aspectos esenciales: fijar una distancia de mira mínima no nula en reposo, garantizar la monotonicidad creciente de lastS y acotar la distancia efectiva ld para prevenir divergencias en el cálculo de curvatura.
Suposiciones y diferencias con el hardware
El entorno asume un mapa exacto, distancia entre ejes perfectamente conocida, adherencia ideal y retardos lineales de primer orden. En un robot físico, el deslizamiento de ruedas altera la estimación odometría, la holgura mecánica introduce bandas muertas en cada inversión de giro y en vehículos de tracción diferencial la velocidad angular de guiado sustituye al ángulo de dirección (ω = v · κ).
Diagrama de circuito
El controlador requiere una infraestructura sensorial precisa:
Posición. Encoders en cuadratura en ambas ruedas con odometría diferencial calculada en cada ciclo de lazo.
Orientación. Giróscopo para integración de corto plazo asistido por magnetómetro para referencias absolutas de rumbo.
Corrección absoluta exterior. Módulo GPS integrado mediante filtro de fusión en lugar de guiado directo sobre coordenadas crudas.
Para profundizar en los fundamentos matemáticos, consulta los tutoriales de persecución pura (pure pursuit) y controladores de error transversal; para el montaje físico, el rover guiado por waypoints GPS desarrolla la integración progresiva.
Lista de hardware
Componentes
- Chasis móvil con control directo de dirección o velocidad de rueda
- Estimador de pose: encoders en interior, fusionados con GPS en exterior
- Referencia de rumbo sin deriva apreciable durante la misión
- Frecuencia de lazo cuya latencia sea inferior a la distancia de mira
Explora el grafo
Dónde se usa este simulador
Los proyectos, rutas de aprendizaje y tutoriales que se basan en este laboratorio.
Sigue construyendo
Descargar recursos
Usa estas referencias de la página mientras trabajas en el proyecto. Los paquetes descargables del proyecto se añadirán solo cuando se publiquen su código fuente y su versión.
Preguntas comunes
Preguntas frecuentes
¿Por qué reducir la distancia de mira no siempre mejora el guiado?
En un modelo ideal sin retardo sí lo hace, lo que vuelve engañosas muchas deducciones teóricas. Un robot físico tarda tiempo en alcanzar el ángulo de rueda ordenado y opera sobre una pose calculada con decenas de milisegundos de retraso. Este laboratorio incluye una constante de tiempo de dirección de 0.25 s y 0.15 s de retardo sensorial. Con ese desfase, la curva de error adquiere forma de U: una distancia de mira excesivamente corta comanda correcciones que llegan cuando el robot ya superó la desviación, provocando sobreoscilación. Un controlador más veloz que sus actuadores entra en inestabilidad.
¿Cómo se determina la distancia de mira (lookahead) óptima?
Mide el retardo total del lazo, multiplícalo por la velocidad y toma como punto de partida entre una y dos veces esa distancia. En este simulador, con 0.4 s de retardo total, los óptimos medidos van de 0.9 m a 1 m/s hasta 1.4 m a 3 m/s. El óptimo crece con la velocidad pero de forma sublineal; conviene programarlo como una función lineal de la velocidad con un límite inferior rígido para evitar división por cero en reposo.
¿Qué controlador es preferible: Pure Pursuit o Stanley?
Cada uno presenta compromisos distintos. En este circuito a 2 m/s, Pure Pursuit recorta las curvas y completa el recorrido con un 0.8 % menos de longitud; Stanley se niega a abandonar la línea teórica, abre la trayectoria y recorre un 2.2 % adicional de distancia. Stanley garantiza mayor fidelidad a la trayectoria trazada pero exige cuatro veces más esfuerzo de dirección (18.5 rad frente a 4.3 rad en el actuador), con mayor desgaste y consumo. Usa Pure Pursuit si el trazado admite tolerancias suaves, y Stanley cuando ceñirse al carril sea mandatorio.
¿Por qué el error se calcula contra la posición real y no contra la estimada?
Porque un robot que confía ciegamente en una estimación sesgada reportará error cero por definición. Al activar la fuente GPS, el controlador pasa a guiarse por coordenadas ruidosas actualizadas a 1 Hz, mientras el simulador computa el error contra la verdad fundamental del modelo físico. Esto evidencia el costo del ruido: el error RMS salta de 0.09 m a 1.25 m y el esfuerzo de guiado se cuadruplica.
¿Qué representa la línea tenue en el simulador?
Muestra la trayectoria completa recalculada de inmediato ante cualquier cambio de parámetros. Cada deslizador ejecuta la simulación headless en unos veinte milisegundos, permitiendo apreciar el resultado antes de pulsar marcha. La línea gruesa anima el avance del vehículo.
¿Por qué el vehículo no puede negociar vértices extremadamente agudos?
Ambos algoritmos están restringidos por el radio de giro mínimo que imponen la batalla del chasis y el ángulo máximo de dirección. Ninguna sintonización puede superar esa barrera física. La solución debe aplicarse aguas arriba: suavizar la trayectoria mediante acuerdos circulares o decelerar antes del vértice mediante un perfil de movimiento adecuado.
Lecturas adicionales
Referencias
Fuentes autorizadas para profundizar más allá del modelo educativo acotado de este simulador.