Tutorial · Intermedio · 25 min de lectura
Frenado en el borde: latencia y distancia de frenado
Un sensor de caída te compra un número fijo de milímetros antes del abismo. Cómo se consumen: distancia de reacción por latencia y distancia de frenado físico.
El presupuesto está en milímetros, no en milisegundos
Un robot con un sensor hacia abajo recibe una sola pieza de información —blanco, ahora— y una distancia fija para actuar sobre ella. Un ring de mini sumo da 25 mm de borde. El borde de una mesa da lo que sea que resulte ser la distancia de montaje hacia delante de tu sensor. Sea como sea, es una distancia, y el robot la gasta de dos maneras muy distintas:
overshoot = v × t_latency + v² / (2a)
El primer término se paga y se gasta antes de que empiece el frenado. El segundo es lo que cobra el suelo una vez que frena.
Se comportan de forma completamente distinta al subir la velocidad, y saber cuál de los dos estás pagando es la diferencia entre arreglar esto en una tarde y reescribir tu lazo de control para nada.
Dónde se va realmente la latencia
«La latencia» no es el sensor. Es todo lo que hay entre los fotones cambiando y los neumáticos haciendo fuerza en el otro sentido, y casi siempre la domina un término que nadie midió:
| Etapa | Típico |
|---|---|
| Asentamiento del emisor de IR y el fototransistor | ~1 ms |
| Esperar a la siguiente pasada de tu bucle | hasta 20 ms |
| Decisión y escritura del PWM | <1 ms |
| Corriente del motor invirtiéndose de verdad | ~3 ms |
| Cruzar la holgura de la reductora antes de que el par llegue a la rueda | ~1 ms |
| Total, en el peor caso | ~25 ms |
El periodo del bucle son cuatro quintas partes de eso, y es la única línea que puedes arreglar gratis.
Un sensor que lees a 50 Hz es un sensor que estás ignorando 20 ms cada vez. La causa habitual no es un procesador lento — es una llamada bloqueante. Un pulseIn() en un sensor ultrasónico son hasta 30 ms de ceguera total, y un delay(20) para un servo es exactamente lo mismo escrito de otra forma. Leer el sensor de borde en cada pasada de un bucle no bloqueante no cuesta nada y elimina la mayor parte de la distancia de reacción.
La última fila es la que sorprende a la gente. Invertir los motores no invierte las ruedas hasta que los engranajes han cruzado su holgura, así que la holgura de la reductora es recorrido libre en el peor momento posible: 4° de juego en la salida sobre una rueda de 32 mm son 1,1 mm de inercia antes de que llegue cualquier par de frenado.
Frenar es un problema de rozamiento, no de motor
El segundo término parece que debería depender de lo fuertes que sean los motores. No depende.
Esos mismos motores que pueden entregar 25 N de fuerza de empuje decelerarían un robot de 500 g a 50 m/s². El suelo permite µg — 11,8 m/s² en silicona, 6,9 m/s² en plástico duro. El tren motriz tiene cuatro veces la autoridad que se le permite usar, así que la distancia de frenado la fijan enteramente los neumáticos, y un motor más grande la acorta exactamente en nada.
Por eso el panel inferior tiene dos curvas en vez de una. A 25 ms de latencia, pasar de plástico a silicona sube la velocidad segura de 0,79 a 0,98 m/s — una ganancia del 24 % de un componente que además te da un 72 % más de empuje.
Un ajuste de honestidad: el µ medido arrastrando un robot parado es el coeficiente estático, y una inversión brusca hace patinar las ruedas, lo que te pone en el cinético — normalmente entre un 10 y un 20 % más bajo. Trata la velocidad calculada como una cota optimista y corre al 80 % de ella.
Qué término domina, y por tanto qué arreglar
Iguala los dos términos y el punto de cruce queda limpio:
v × t = v² / 2a → v = 2at
A 25 ms y µ 1,2 eso son 0,59 m/s.
- Por debajo, estás limitado por latencia. Reducir a la mitad el periodo del bucle compra más que cualquier neumático. Ahí es donde vive un robot que busca, y es la buena noticia: el arreglo es un cambio de software.
- Por encima, estás limitado por tracción. El agarre y la distribución de masa importan más que la tasa de bucle, y pasado cierto punto la única respuesta que queda es ir más despacio.
La mayoría de los robots que se caen de las cosas están en el primer régimen y se están ajustando como si estuvieran en el segundo.
Regálate más milímetros
El presupuesto no es fijo. Es la anchura del borde más la distancia a la que el sensor está montado por delante de las ruedas, y ese segundo término es una variable de diseño gratuita:
budget = border + sensor lead
Un sensor 40 mm por delante del eje motriz convierte 25 mm de borde en 65 mm de espacio de frenado, que es la diferencia entre 0,60 m/s y 0,98 m/s. Resuélvelo al revés cuando tengas una velocidad objetivo:
budget = v·t + v²/(2a)
Límites prácticos sobre cuánto puedes adelantar:
- Tiene que ver el borde, no el ring de fuera. Montado demasiado lejos delante está mirando más allá de la línea mientras el robot todavía está a salvo, lo que te cuesta velocidad sin ningún motivo.
- Móntalo bajo y cúbrelo. Un sensor de reflectancia IR a 3 mm está leyendo la superficie; a 15 mm está leyendo la superficie más las luces de la habitación. Este es el mismo problema de umbral y calibración que tiene un seguidor de línea, con un modo de fallo mucho peor.
- Pon uno en cada esquina delantera. Un único sensor central te dice que el borde está por delante. Dos te dicen hacia qué lado girar para alejarse de él, sin latencia extra.
- No olvides la parte trasera. Un robot al que empujan hacia atrás cruza el borde en la dirección equivocada, y los sensores delanteros no lo verán nunca.
Primero frena hacia atrás, luego gira
Dado un presupuesto fijo, el orden de las operaciones importa más que el ajuste.
Marcha atrás completa, de inmediato. No dejándote llevar — un robot que rueda libremente decelera solo por la resistencia de rodadura, que es una fracción pequeña de µg, y el sobrepaso se multiplica por unas tres. Ni frenando tampoco con suavidad: este es el único momento donde un perfil de movimiento es el instinto equivocado, porque la restricción es la distancia y no la suavidad.
Luego gira, una vez que te has parado. Girar mientras todavía avanzas convierte tu problema de recta en un arco que lleva una esquina del robot más hacia fuera que su centro. Para primero y después reorienta — y recuerda que un giro sobre el sitio está frotando los neumáticos de lado todo el tiempo.
Fija la detección. Una sola muestra de blanco basta. Esperar dos lecturas consecutivas para confirmarla dobla tu distancia de reacción en el peor caso, y el falso positivo que evita es mucho más barato que la caída.
Medir tu propia latencia
El número de la tabla es una estimación inicial. El tuyo se mide en unos quince minutos.
Desde dentro. Registra micros() cuando el sensor cruza el umbral y otra vez en la línea que escribe el PWM invertido. Eso captura la mitad de software, que es la mitad que puedes arreglar. Imprime el peor valor visto en cien detecciones, no la media — el peor caso es el que decide si el robot se cae.
Desde fuera. Grábalo a 240 fps con un móvil. Cuenta los fotogramas entre el paso del sensor por la línea y el punto en que las ruedas se ven invertir; cada fotograma son 4,2 ms. Eso captura el retardo eléctrico y mecánico que el software no puede ver, y es la única forma de confirmar el total.
De extremo a extremo. Conduce a una velocidad conocida hasta una línea pegada con cinta y mide hasta dónde pasado el robot se detiene. Resta la distancia de frenado calculada v²/2a y lo que queda es v × t — la latencia total, medida con una regla.
El último lleva cinco minutos y merece la pena hacerlo antes de cualquier ajuste, porque te dice cuál de los dos términos estás pagando realmente.
Cuando va mal
| Síntoma | Normalmente |
|---|---|
| Para bien despacio, se cae a toda velocidad | Funcionando como está diseñado — vas más allá de la velocidad que permite el presupuesto |
| Se pasa siempre una cantidad constante | Latencia; mídela de extremo a extremo y acorta el bucle |
| Se pasa una cantidad variable | Una llamada bloqueante en algún sitio — el periodo del bucle no es el que crees |
| Ve la línea tarde | Sensor montado demasiado alto o demasiado atrás, o umbral ajustado para otra habitación |
| Detecta un borde que no está | Suelo reflectante o IR ambiente; cubre el sensor y recalibra |
| Para a tiempo y luego se cae igualmente | El giro de apartación ocurrió mientras todavía se movía; para primero |
| Se cae hacia atrás | Sin sensores traseros |
La misma aritmética cubre un robot de borde de mesa, un aspirador que evita escaleras y una parada por obstáculo — solo cambia el presupuesto. El simulador de evitación de obstáculos expone exactamente esta geometría de distancia de frenado con un sensor que mira hacia delante en vez de hacia abajo, y el proyecto mini sumo es donde tiene que funcionar contra un rival que intenta que fracases.
Explora el grafo
Forma parte de estos montajes
Proyectos y rutas de aprendizaje que incluyen este tutorial.
Lecturas adicionales