Robot resuelto de laberintos de línea con memoria LSRB

Un seguidor de línea sigue. Un solucionador de laberintos sobre línea decide. Ese es el salto completo que hace este proyecto, y es mayor de lo que parece: el robot deja de ser un lazo de control con ruedas y se convierte en algo que explora un entorno que nunca ha visto, recuerda lo que encontró y actúa en función de ese recuerdo.

La gracia es que nada de eso sustituye al seguidor de línea: se apoya encima de él. Debajo, la misma matriz de reflectancia y el mismo lazo PID mantienen el robot centrado en la cinta, sin saber nada de laberintos. Encima, una capa de decisión fina vigila los momentos en que la línea se bifurca, clasifica de qué tipo de cruce se trata, elige una dirección y escribe un carácter. Esa separación es lo que hace tratable el proyecto, y es la misma división en dos capas que usan los robots reales en todas partes.

Así que el orden de construcción importa más de lo habitual. Primero obtienes un seguimiento de línea plano realmente estable —ajustado en el simulador y luego en un óvalo grande de cinta real— y solo entonces añades cruces. Salta esa disciplina y cada problema mecánico, cada deriva de calibración, cada rueda que se sale 2 mm de alineación aparecerá disfrazado de fallo de resolución de laberintos.

Sigue el árbol tecnológico de abajo de arriba abajo. Cada nodo se abre cuando sus prerrequisitos están cumplidos, y tu progreso se guarda en este dispositivo, para que puedas construir el robot a lo largo de un fin de semana sin perder el hilo.

Lista de materiales

Total: unos $35–45. La matriz de 8 canales es la única pieza en la que no conviene escatinar, y el motivo es concreto: un robot detecta una rama hacia la izquierda al observar que los sensores más exteriores del lado izquierdo se han puesto en oscuro mientras el centro sigue sobre la línea. Una matriz apenas más ancha que la cinta físicamente no puede verlo, así que la detección de cruces se convierte en adivinación por muy bueno que sea el código.

Por qué la matriz debe ser más ancha que la línea

   left branch                    array (8 channels, ~60 mm wide)
   ────────────────┐          [ x x x . . . . . ]   outer left dark -> a branch
                   │
   ════════════════╪═══════   [ . . . x x . . . ]   centre still on the line
                   │

Regla práctica: la matriz debería ser de al menos tres veces el ancho de la cinta. Para cinta de 19 mm eso son unos 60 mm, que es exactamente lo que te da una matriz de 8 canales con paso de 8 mm. Más estrecha y el robot no puede distinguir entre “la línea se ha curvado bruscamente” y “la línea se ha bifurcado”, que es la decisión central sobre la que se apoya todo el proyecto.

Constrúyelo por hitos

El orden de construcción importa aquí más que en cualquier otro proyecto del sitio. Un solucionador de laberintos es un seguidor de línea con una capa de decisión, y cada fallo mecánico o de calibración del seguidor reaparece disfrazado de fallo de resolución de laberintos.

El hito 1 no es negociable. “Sigue la línea casi siempre” se convierte en “de vez en cuando inventa un cruce”, y te pasarás una tarde depurando la simplificación de rutas por un fallo que en realidad es una rueda 2 mm fuera de alineación.

El hito 2 es el que se salta la gente. Un solucionador de laberintos ejecuta cientos de giros por pasada, y un giro que se queda sistemáticamente 5° corto se acumula hasta que el robot abandona la línea por completo. Aquí es exactamente donde aparece el backlash del reductor: un error que cambia de signo con la dirección es mecánico, no un fallo de ajuste.

La división en dos capas, en código

Merece la pena ver explícitamente la separación que hace tratable este proyecto:

             ┌─────────────────────────────────────┐
   decision  │  classify junction -> choose turn   │   runs only at junctions
     layer   │  record a character -> simplify     │   knows nothing about PWM
             └──────────────────┬──────────────────┘
                                │ "turn left" / "keep going"
             ┌──────────────────▼──────────────────┐
   following │  read array -> position -> PID      │   runs every loop, ~200 Hz
     layer   │  -> left and right wheel speeds     │   knows nothing about mazes
             └─────────────────────────────────────┘

La capa inferior nunca aprende qué es un laberinto. La capa superior nunca toca un motor. Cuando algo va mal, ese límite te dice en qué mitad mirar, y si no puedes decir en qué mitad vive un fallo, es que las capas no están bien separadas.

Qué significa hacerlo bien

La precisión en los cruces es genuinamente de todo o nada, y eso sorprende a la gente. Un cruce mal leído corrompe la cadena registrada, el simplificador produce entonces una ruta de aspecto válido pero equivocada, y la pasada de vuelta se mete con confianza en una pared. No hay crédito parcial, y por eso la exploración va lenta y la pasada de vuelta es donde recuperas el tiempo.

Resolución de problemas

Hacia dónde llevarlo después

Añade encoders y gira por distancia en vez de por tiempo. Los giros temporizados son la mayor fuente de irreproducibilidad en un primer solucionador de laberintos, porque el tiempo necesario cambia con la tensión de batería y con la superficie. Los giros con encoders no.

Pasa a un laberinto con paredes —el micromouse—, que sustituye la cinta por paredes y la regla LSRB por flood fill. Ese es el paso realmente mayor: LSRB es una heurística de seguimiento de pared que encuentra un camino, mientras que el flood fill calcula el más corto y replanifica según se descubren paredes nuevas.

Optimiza la pasada de vuelta. Una vez conocida la ruta, ya no queda ninguna decisión que tomar, así que el robot puede acelerar en rectas y bajar solo para los giros. Un perfil de movimiento sobre la ruta conocida es de donde salen las mejoras drásticas de tiempo, a menudo la mitad de la pasada de vuelta.