Robótica

Localizar con la Cámara

NOTAS

Bienvenidos a la semana 13. La semana pasada terminamos con una conclusión incómoda: por más que calibremos el radio y la trocha, el robot no cierra los cuadrados. La odometría es una estimación que solo puede empeorar, porque cada pequeño error se suma a los anteriores. Hoy vamos a ver cómo se sale de ese problema.

La respuesta es mirar hacia afuera. Un robot que solo cuenta las vueltas de sus ruedas es como alguien que camina con los ojos cerrados contando pasos: al principio sabe muy bien dónde está, pero a los cien pasos ya no. Si abre los ojos y reconoce una puerta o una esquina, puede corregir su estimación de golpe.

Nuestro "ojo" va a ser la cámara del celular montada sobre el EV3. Con ella vamos a hacer dos cosas: reconocer marcas en el piso para saber dónde está el robot, y seguir una línea cerrando el lazo de control con lo que ve la cámara.

🎨 Prompt sugerido: "Pixel art of a small LEGO-style robot that has ONLY TWO wheels in total, one on each side of its body like a two-wheeled balancing robot, carrying a smartphone mounted on top that looks down at a floor covered with square black-and-white fiducial marker tiles, a soft cone of light from the phone camera onto one tile, a faint dotted path behind the robot, wide scene with clear empty space in the upper half for a title. 16-bit retro style, teal, orange and grey palette, no text."

Plan de hoy: tres bloques

#	Bloque	Pregunta que responde
1	¿Por qué localizar?	¿Por qué no basta la odometría de la semana pasada?
2	Mapas y landmarks	¿Con qué referencia externa corrige el robot su posición?
3	Cerrar el lazo con la cámara	¿Cómo se convierte lo que ve la cámara en una orden para las ruedas?

Al final: las prácticas con el celular montado sobre el EV3.

NOTAS

La clase tiene tres bloques. El primero conecta con la semana 12: vamos a ver por qué el error de la odometría no se arregla calibrando más, y por qué cualquier robot móvil serio necesita una referencia externa. Ahí aparecen dos ideas que vamos a formalizar en la semana 15: la creencia del robot sobre su posición y el ciclo predicción–corrección.

El segundo bloque es sobre la referencia externa: qué es un mapa, qué es un landmark, y cómo un marcador ArUco impreso en papel le dice al robot dónde está, con una precisión de milímetros.

El tercero es sobre usar la cámara en lazo cerrado. Vamos a convertir una fila de píxeles en un error, el error en una velocidad de giro, y a ver qué pasa cuando la ganancia es muy baja o muy alta. Cerramos con las prácticas de la semana.

¿Por qué localizar?

NOTAS

Antes del GPS, los barcos navegaban por estima: rumbo, velocidad y tiempo. Funcionaba, pero el error crecía día a día, y por eso los navegantes buscaban con ansiedad un faro o una costa conocida. Cuando veían el faro, corregían la posición en la carta y el error volvía a ser pequeño.

Nuestro robot está en la misma situación: la odometría es su navegación por estima, y hoy le vamos a dar faros.

🎨 Prompt sugerido: "Pixel art of a small robot that has ONLY TWO wheels in total, one on each side of its body like a two-wheeled balancing robot, standing at night on a dark coast-like floor, surrounded by a fuzzy glowing cloud of possible positions, while a distant lighthouse beam sweeps across the scene and lights up a square marker on the ground. 16-bit retro style, deep blue, yellow and grey palette, no text."

¿Por qué localizar?

• Aun con $r$ y $l$ perfectos, el patinaje aleatorio hace crecer la nube en cada esquina
• Calibrar quita lo sistemático; lo aleatorio solo se acota midiendo afuera

NOTAS

Esta figura retoma la simulación de la semana pasada, pero ahora con los cuadrados del laboratorio. Los parámetros del modelo son exactos, no hay ningún error sistemático: lo único que hay es un 3 % de patinaje aleatorio en cada rueda. El robot repite 300 veces la serie de cuatro cuadrados, y cada punto es dónde quedó al volver al punto de partida, la cruz negra.

Fíjense cómo crece la nube con cada cuadrado. No crece tan rápido como la distancia, porque los errores aleatorios a veces se compensan, pero nunca deja de crecer. Y esto es solo patinaje: en el robot real se suma lo que la calibración no logró quitar.

La conclusión es la misma de la semana 12, pero ahora con más fuerza: calibrar corrige lo que se repite, y lo que no se repite no lo arregla ninguna calibración. La única salida es medir algo que no dependa de las ruedas.

Incertidumbre de sensores y efectores

Fuente	En nuestro laboratorio
Ruido del efector: una misma orden produce movimientos distintos	patinaje en las juntas del piso, batería que baja
Ruido del sensor: la lectura cambia aunque nada se mueva	la cámara con poca luz, desenfoque al moverse
Aliasing: lugares distintos producen la misma lectura	dos esquinas iguales, dos baldosas iguales

Un solo dato casi nunca basta: se necesita una serie de lecturas.

NOTAS

El libro de Siegwart separa tres fuentes de incertidumbre. La primera ya la conocemos: los efectores, las ruedas y los motores, no hacen exactamente lo que les pedimos. Eso es el error de odometría.

La segunda es el ruido del sensor. Si ponen la cámara quieta frente al piso y grafican una fila de píxeles, van a ver que la curva tiembla aunque nada se mueva: ruido del sensor, compresión del video, cambios de luz. En la práctica de "La información de la cámara" lo van a ver en vivo.

La tercera es la más interesante y la más propia de los robots: el aliasing. Pasa cuando dos lugares distintos se ven igual para el sensor. Un sensor de color que ve gris no sabe en qué parte del piso gris está. Una cámara que ve una esquina no sabe cuál de las cuatro esquinas del cuarto es. Eso es lo que vamos a ver en la siguiente diapositiva.

Aliasing: muchos lugares, la misma lectura

Moverse y volver a mirar elimina las hipótesis que no son consistentes.

NOTAS

Un robot en un pasillo con tres puertas idénticas. Al empezar no sabe dónde está: su creencia es plana, todas las posiciones son igual de probables. Ve una puerta, y la creencia se concentra en tres picos, uno en cada puerta: la lectura sirve, pero no basta.

Ahora avanza 2 metros y vuelve a ver una puerta. Solo una de las tres hipótesis es consistente con eso: la que empezó en la puerta de 1 metro y llegó a la de 3. Las otras dos habrían llegado a 5 y 9 metros, donde no hay puertas. Fíjense además que el pico final es un poco más ancho que la puerta: el movimiento de 2 metros también tuvo incertidumbre.

Esto que acabamos de hacer, alternar mover y mirar y multiplicar probabilidades, es la localización de Markov. La vamos a formalizar en la semana 15. Hoy quédense con la idea: la información viene de la combinación de movimiento y observación, no de una sola lectura.

Predicción y corrección

• Los encoders predicen: rápido, siempre disponible, pero el error crece
• La cámara corrige: solo cuando ve una marca, pero no acumula error

NOTAS

Este es el esquema general de casi cualquier sistema de localización. En cada paso, el robot primero predice dónde está usando la odometría: lo que hicimos la semana pasada. Esa predicción viene con una incertidumbre que crece.

Luego, si un sensor externo ve algo conocido, compara lo que ve con lo que esperaba ver desde la pose predicha y corrige. La incertidumbre baja. Y el ciclo vuelve a empezar.

Noten que los dos sensores se complementan: los encoders dan información todo el tiempo pero acumulan error; la cámara solo sirve cuando hay una marca a la vista, pero lo que mide no depende de la historia. El filtro de Kalman de la semana 15 es la receta óptima para pesar estas dos fuentes; hoy lo vamos a hacer de la forma más simple posible: cuando veo una marca, le creo a la marca.

Corregir con una marca

• Sin marcas, la incertidumbre crece sin límite
• Con una marca cada metro, queda acotada: diente de sierra

NOTAS

Esta gráfica muestra la incertidumbre lateral del robot en función de la distancia recorrida. En rojo, solo con odometría: crece sin parar. En verde, el mismo robot, pero cada metro la cámara ve una marca cuya posición conocemos con un error de un centímetro.

La forma de diente de sierra es la firma de la localización con landmarks: entre marca y marca la incertidumbre crece, porque solo hay odometría; al ver la marca cae casi a la precisión de la cámara. Lo importante es que ya no crece sin límite: el robot puede recorrer kilómetros con un error acotado.

De aquí sale una pregunta de diseño: ¿cada cuánto hay que poner marcas? Depende de qué tan rápido crece el error de la odometría y de cuánto error toleramos. Un robot bien calibrado necesita menos marcas. Por eso lo que hicieron la semana pasada sigue sirviendo.

¿Localizar o no localizar?

Navegación por comportamientos	Navegación basada en mapas
reglas que producen el movimiento: "seguir la línea"	el robot sabe dónde está en un mapa
no necesita saber su posición	la posición es explícita y se puede mostrar
rápida de programar en un entorno	escala a otros entornos y destinos
no escala: cada lugar exige otro programa	exige un mapa y un buen sistema de localización

Hoy hacemos las dos: ArUco para localizar y control P para seguir una línea.

NOTAS

Hay dos grandes filosofías. Una dice: no localices, diseña comportamientos. Si quiero ir del laboratorio a la cafetería, sigo la pared de la izquierda hasta la segunda puerta. Funciona, es rápido de programar, pero solo sirve para ese recorrido. Si cambio el destino, tengo que pensar un comportamiento nuevo.

La otra dice: construye un mapa y sabe en todo momento dónde estás en él. Cuesta más al principio, pero una vez que el robot se localiza, ir a cualquier lugar es solo planear una ruta. Además, la posición es transparente para las personas: el operario ve en la pantalla dónde cree estar el robot.

En el laboratorio van a hacer las dos. Seguir una línea con la cámara es navegación por comportamientos: el robot nunca sabe en qué coordenada está, solo sabe si la línea está a la izquierda o a la derecha. Leer un ArUco y deducir la pose es navegación basada en mapas. Al final de la clase les pregunto cuál prefieren para el proyecto.

Mapas y Landmarks

NOTAS

Un landmark es cualquier cosa que el robot pueda reconocer y cuya posición esté en el mapa: una puerta, una esquina, una lámpara del techo, un código impreso en el piso. Los humanos lo hacemos todo el tiempo: "después de la panadería, gire a la derecha".

En este bloque vamos a ver cómo se guarda un mapa en la memoria del robot y qué landmark es el más fácil de reconocer con una cámara.

🎨 Prompt sugerido: "Pixel art of a top-down view of a warehouse floor laid out as a grid, with a square black-and-white fiducial marker tile at every grid intersection, several flat round robots shaped like robot vacuum cleaners carrying tall shelves on top and moving along the grid lines, a glowing map overlay in one corner. 16-bit retro style, orange, teal and grey palette, no text."

Mapas y Landmarks

Representación	Ventaja · desventaja
Continua	precisa y compacta · cara de comparar con el sensor
Grilla de ocupación	simple, ideal con sensores de rango · ocupa mucha memoria
Topológica	se ajusta a lo que el robot reconoce · pierde la geometría

NOTAS

El mismo lugar, dos salas unidas por una puerta y una mesa, representado de tres formas. La continua guarda las paredes como segmentos de recta y la mesa como un polígono: es exacta y ocupa poquísima memoria, y por eso es la favorita cuando el sensor es un láser que extrae líneas.

La grilla de ocupación divide el piso en celdas, aquí de 25 cm, y marca cuáles están ocupadas. Es muy fácil de construir y de usar para planear rutas, pero miren el costo: si la celda es pequeña, el mapa es enorme, y si es grande, se pierden detalles; una puerta angosta puede desaparecer.

La topológica no guarda medidas: guarda lugares y conexiones. Es la que usamos los humanos para dar indicaciones. Funciona muy bien cuando los nodos son cosas que el robot reconoce con seguridad, y ahí entran los landmarks. Nuestro piso con marcadores ArUco es en realidad las dos cosas: un mapa métrico, porque cada marcador tiene coordenadas, y uno topológico, porque cada marcador tiene un nombre único.

¿Dónde cree el robot que está?

• Hipótesis única: fácil para decidir, pero no sabe cuánto se equivoca
• Múltiples hipótesis: guarda la incertidumbre, pero cuesta más calcular y decidir

NOTAS

Así como hay que representar el mapa, hay que representar la creencia del robot sobre su posición. La odometría de la semana 12 es una hipótesis única: el robot dice "estoy en x, y, θ" y punto. Es muy cómodo para planear, pero el robot no tiene idea de cuánto puede estar equivocado.

La Gaussiana agrega la incertidumbre: una media y una elipse que dice "probablemente estoy por aquí, con este margen". La elipse es alargada porque, como vimos la semana pasada, el error de orientación se convierte en error lateral. Es lo que usa el filtro de Kalman.

Las partículas son la representación más flexible: miles de hipótesis a la vez, que pueden formar dos grupos si el robot no sabe en cuál de dos lugares parecidos está, como en el pasillo de las tres puertas. El precio es el cálculo. Todo esto es tema de la semana 15; hoy nos basta con saber que existe.

Landmarks en la industria

Tipo	Ejemplo
Naturales	esquinas, puertas, columnas que ya existen
Artificiales pasivos	códigos en el piso: KIVA / Amazon Robotics · marcas en el techo
Balizas activas	GPS al aire libre · UWB en interiores
Rutas marcadas	cinta en el piso, cable guía enterrado: el robot sigue un "riel"

Modificar el entorno es barato y confiable: por eso la industria lo prefiere.

NOTAS

Los landmarks naturales son el sueño de la investigación: que el robot se localice con lo que ya hay. Funciona, pero es difícil, porque las esquinas se parecen entre sí y las personas se mueven y tapan las cosas.

La industria casi siempre hace trampa, y con razón: modifica el entorno. Los robots de Amazon, que empezaron como KIVA, se mueven sobre una grilla de códigos pegados en el piso; cada vez que pasan por encima de uno, una cámara que mira hacia abajo lo lee y el robot sabe exactamente dónde está. Entre código y código usan odometría. Es exactamente el diente de sierra de hace un rato.

Las balizas activas, como el GPS o los sistemas UWB para interiores, emiten señales y el robot calcula su posición con los tiempos de llegada. Y las rutas marcadas son la versión más sencilla: el robot ni siquiera se localiza, solo sigue la línea. Hoy vamos a probar dos de estas: códigos en el piso y una ruta marcada.

Marcadores ArUco

• Un borde negro fácil de encontrar y 16 bits que codifican el ID
• El diccionario DICT_4X4_50 tiene 50 marcadores elegidos para no confundirse entre sí

NOTAS

Un marcador ArUco es un código de barras cuadrado pensado para cámaras. El borde negro grueso es lo primero que busca el algoritmo: los cuadriláteros oscuros se encuentran rápido en cualquier imagen. Una vez encontrado el borde, el algoritmo endereza el cuadrado y lee la cuadrícula interior de 4 por 4 bits, blanco o negro.

Con 16 bits caben 65.536 combinaciones, pero el diccionario solo usa 50. ¿Por qué? Porque los eligieron lo más distintos posible entre sí, también al rotarlos. Así, si la cámara lee mal uno o dos bits, el resultado no coincide con otro marcador válido y el error se detecta. Eso es lo que lo hace robusto al ruido y al aliasing: cada marcador es único.

Y hay un detalle que lo hace todavía más útil: como el cuadrado no es simétrico en sus bits, el detector sabe cuál esquina es la cero. Eso significa que el marcador no solo dice dónde está, sino también hacia dónde apunta. Los que van a usar en el laboratorio se imprimen de una pulgada de lado: 2.54 cm.

Detectar un marcador

dic = cv2.aruco.getPredefinedDictionary(cv2.aruco.DICT_4X4_50)
detector = cv2.aruco.ArucoDetector(dic, cv2.aruco.DetectorParameters())

corners, ids, _ = detector.detectMarkers(gray)
if ids is not None:
    c = corners[0][0]                 # 4 esquinas (x, y) en píxeles
    centro = (c[0] + c[2]) / 2        # mitad de la diagonal
    vx, vy = c[1] - c[0]              # borde superior del marcador
    lado_px = np.hypot(vx, vy)
    escala = lado_px / 0.0254         # píxeles por metro
    angulo = np.degrees(np.arctan2(vy, vx))

NOTAS

Este es el núcleo de los programas C06 y C07. Tres líneas crean el detector y lo aplican a la imagen en escala de grises. Lo que devuelve son dos listas: las esquinas de cada marcador encontrado, en píxeles, y su ID.

Con las cuatro esquinas sale todo lo demás. El centro es el punto medio de la diagonal. El lado en píxeles, comparado con el lado real en metros, da la escala de la imagen: cuántos píxeles hay en un metro a esa altura. Y el ángulo del borde superior dice cómo está girado el marcador respecto a la cámara.

Una observación sobre C07: allí la escala se calcula solo con la diferencia en x entre las dos primeras esquinas. Si el marcador está girado, esa diferencia es menor que el lado y la escala sale mal. Usar la longitud del vector, como aquí, lo arregla. Y midan sus marcadores impresos antes de confiar en el valor de MARKER_SIZE.

De píxeles a metros

$$\text{escala} = \frac{80\,px}{0.0254\,m} \approx 3150\,px/m$$

$$\Delta x = \frac{90}{3150} = 2.9\,cm$$

$$\Delta y = \frac{-120}{3150} = -3.8\,cm$$

NOTAS

Así se ve lo que entrega el detector en la imagen del celular, que es de 480 por 640 píxeles en vertical. Ojo con los ejes: en una imagen, x crece hacia la derecha y y crece hacia abajo. Las esquinas están numeradas desde la cero, arriba a la izquierda, en sentido horario.

En el ejemplo el marcador mide 80 píxeles de lado; como mide 2.54 cm, la escala es de unos 3150 píxeles por metro, o 31.5 por centímetro. El centro del marcador está 90 píxeles a la derecha del centro de la imagen: 2.9 cm. Y está 120 píxeles por encima: 3.8 cm hacia adelante del robot, si el celular está montado con la parte de arriba de la imagen hacia el frente.

Esta cuenta tan simple supone que la cámara mira perpendicular al piso y a una altura fija, y que el lente no deforma la imagen. Con el celular apuntando hacia el piso es una buena aproximación. Si la cámara se inclina, hace falta calibrarla y usar estimatePoseSingleMarkers, que es el siguiente nivel.

Corregir la odometría con una marca

$$\theta = \theta_{marca} - \alpha$$

$$x = x_{marca} - (\Delta x \cos\theta - \Delta y \sin\theta) \qquad y = y_{marca} - (\Delta x \sin\theta + \Delta y \cos\theta)$$

NOTAS

Este es el paso que conecta la cámara con la localización. El mapa dice que la marca 9 está en el punto 0.5, 0.5 del piso, alineada con los ejes. La odometría, en naranja punteado, cree que el robot está en un lugar; la cámara ve la marca a cierta distancia y con cierto ángulo α en el marco del robot.

Si la marca está girada α respecto al robot, el robot está girado −α respecto a la marca: de ahí sale θ. Y si la marca está en Δx, Δy en el marco del robot, la posición del robot es la de la marca menos ese vector rotado al marco del mundo. Es la misma transformación homogénea del bloque de manipuladores, solo que en dos dimensiones y despejada al revés.

Dos detalles prácticos. Primero, los Δx, Δy de la imagen están en el marco de la cámara, que no coincide con el del robot: hay que cambiar los ejes y sumar la distancia entre el lente y el centro del eje de las ruedas. Segundo, la corrección es un salto: si el robot está en movimiento, la pose cambia de golpe y el controlador debe tolerarlo. El filtro de Kalman suaviza ese salto pesando cuánto le cree a cada fuente.

Cerrar el Lazo con la Cámara

NOTAS

Hasta ahora usamos la cámara para saber dónde está el robot. Ahora la vamos a usar para algo más directo: decidir, imagen por imagen, cuánto girar. Es lo que hace un conductor que mantiene el carro en el centro del carril sin pensar en coordenadas: mira la línea y corrige.

🎨 Prompt sugerido: "Pixel art seen from slightly above and behind a small robot that has ONLY TWO wheels in total, one on each side of its body like a two-wheeled balancing robot, with a smartphone mounted on top tilted down toward the floor, driving forward along a winding black tape line that continues ahead of it on a light wooden floor, the line curving to the left in front of the robot, a small floating camera-view window in the upper corner showing the black line with a red horizontal scan line across it. 16-bit retro style, red, black and warm grey palette, no text."

La cámara como sensor

Resolución	Píxeles por imagen
1920 × 1080 (Full HD)	2 073 600
640 × 480	307 200
320 × 240	76 800

• Cada píxel tiene 3 canales de color: millones de datos por imagen
• En visión para robots se reduce la resolución para procesar más imágenes por segundo

NOTAS

La cámara es un sensor exteroceptivo muy especial. Un sensor de color del EV3 da un número; una cámara da millones. Una imagen Full HD tiene más de dos millones de píxeles, cada uno con tres canales de color.

Eso es una ventaja y un problema. Ventaja, porque hay muchísima información del entorno. Problema, porque procesarla toma tiempo, y en control el tiempo importa: una decisión que llega tarde puede ser peor que no decidir. Por eso en visión para robots casi siempre se baja la resolución: 640 por 480, o incluso 320 por 240, y se trabaja en escala de grises.

En nuestro caso hay un retraso adicional: la imagen viaja por wifi del celular al computador, y el computador manda la orden al EV3 por Bluetooth. Fíjense que los programas descartan cinco imágenes con cap.grab() antes de leer una: es para no procesar imágenes viejas acumuladas en el búfer. Ese retraso lo vamos a ver aparecer en el control.

Una fila de la imagen

• Lo que está por debajo del umbral es la línea; su centro de masa es su posición
• El error es la distancia entre ese centro y el centro de la imagen

NOTAS

No necesitamos procesar toda la imagen para seguir una línea: basta con una fila. Esta es la fila central de la imagen en escala de grises, donde cero es negro y 255 es blanco. El piso es claro, con una iluminación que no es pareja, y la cinta negra aparece como un valle profundo.

El programa C03 define un umbral relativo, el 70 % del promedio de la fila, para que funcione aunque cambie la luz. Todo lo que está por debajo del umbral cuenta como línea, y pesa más mientras más oscuro sea. El centro de masa de esos pesos es la posición de la línea, con precisión de fracciones de píxel.

Con eso ya tenemos un sensor: un número, el error en píxeles, que vale cero cuando la línea está centrada y cambia de signo según el lado. Fíjense que la curva vibra aunque la cámara esté quieta: es el ruido del sensor del primer bloque. El centro de masa promedia muchos píxeles, y por eso es mucho más estable que tomar solo el píxel más oscuro.

Control proporcional

$$vr = K_p \cdot \text{error}_x \qquad \text{error}_x = \frac{\text{width}}{2} - \text{centro}_x$$

• P reacciona al error presente · I acumula el error pasado · D anticipa con su tendencia

NOTAS

Ahora cerramos el lazo. La referencia es el centro de la imagen; la medida es el centro de la línea; la diferencia es el error. El controlador proporcional multiplica el error por una ganancia, Kp, y ese resultado es la velocidad de giro que le pedimos al robot. Si la línea está a la derecha, el robot gira a la derecha, más rápido mientras más lejos esté.

Este es el control continuo: una señal que varía suavemente con el error. El control lógico, en cambio, es de reglas: "si la línea está a la derecha, gire a la derecha a velocidad fija". Es más fácil de programar, pero el robot zigzaguea. Muchos sistemas reales combinan los dos: lógica para decidir qué hacer y control continuo para hacerlo bien.

El controlador PID agrega dos términos al proporcional: el integral suma el error a lo largo del tiempo y elimina errores que se quedan pegados; el derivativo mira la tendencia del error y frena antes de pasarse. Hoy usamos solo P, y en la siguiente diapositiva vamos a ver por qué a veces no alcanza.

¿Por qué no se alinea?

• Con $K_p$ bajo, el robot se queda quieto antes de llegar al centro
• Con $K_p$ alto, se pasa y oscila: la imagen llega tarde

NOTAS

Esta es una simulación simple del giro en el sitio hacia la línea, con lo que tiene el programa real: el control se ejecuta cada décima de segundo, la imagen llega con unos 0.2 segundos de retraso, y la velocidad se convierte a entero antes de mandarla al motor.

Con Kp de 0.05, la curva azul baja bien pero se queda quieta lejos de cero. Con Kp de 0.5, la roja se pasa de lado a lado y no se estabiliza. La verde, con 0.2, se pasa un poco y se acomoda en un par de segundos. Antes de ver la explicación, pregúnteles: ¿qué está pasando en cada caso?

Lo que deben descubrir: la franja gris es la zona donde int(Kp * error) vale cero; el robot recibe la orden de no moverse aunque el error no sea cero. Y además los motores necesitan un mínimo de potencia para vencer la fricción, así que en el robot real esa zona es todavía más ancha. Con Kp alto, el robot sigue girando con base en una imagen vieja y se pasa. Las soluciones son las del PID: un término integral para el error que se queda, no truncar la orden, y reducir el retraso o la ganancia para la oscilación.

Seguir la línea

$$v_d = v_t + v_r \qquad v_i = v_t - v_r \qquad \text{turn} = 100\left(1 - \frac{v_{min}}{v_{max}}\right)$$

Se pide	speed	turn	El robot
vt = 20, vr = 0	20	0	va recto
vt = 20, vr = 10	30	66	curva a la izquierda
vt = 20, vr = −10	30	−66	curva a la derecha
vt = 10, vr = 10	20	100	pivota sobre la rueda izquierda

En el ejercicio: ↑ ↓ cambian $v_t$ · ← → cambian $K_p$

NOTAS

Para seguir la línea, además de girar hay que avanzar. La función update_speed_turn de los programas combina una velocidad de avance, vt, y una de giro, vr, en las velocidades de las ruedas derecha e izquierda. Es la cinemática inversa de la semana 12 en otras unidades: la rueda derecha va a v más ω·l, la izquierda a v menos ω·l.

Pero move de ev3_dc no recibe las dos velocidades sino speed y turn: la velocidad de la rueda rápida y qué tanto más lenta va la otra. Con turn igual a cero las ruedas van iguales; con 100 la rueda interior se detiene; con 200 gira hacia atrás a la misma velocidad, o sea, giro en el sitio. El signo de turn dice hacia qué lado.

Verifiquen la segunda fila: la derecha va a 30 y la izquierda a 10, así que turn vale 100 por uno menos un tercio, 66 al truncarlo a entero. En la última, la izquierda queda en cero y turn vale 100: el robot pivota sobre esa rueda, como en los casos especiales de la semana 12. En el ejercicio con teclado van a subir la velocidad de avance y la ganancia por separado: noten que con más velocidad hace falta más ganancia para tomar las curvas, pero también aparece antes la oscilación.

De la línea a un punto: ir a $(x, y)$

$$d = \sqrt{\Delta x^2 + \Delta y^2} \qquad \Delta\alpha = \operatorname{atan2}(\Delta y, \Delta x) - \theta$$

Situación	Orden
mal orientado: más de 5°	girar en el sitio hacia el objetivo
bien orientado	avanzar ∝ distancia y corregir ∝ ángulo
a menos de 0.5 cm	siguiente objetivo

C10: un cuadrado de 50 cm como lista de puntos, no de giros

NOTAS

El último programa de la semana, C10, cambia la pregunta: ya no "¿dónde está la línea?", sino "¿dónde está el punto al que quiero ir?". Con la pose del robot y la del objetivo se calculan dos errores: la distancia y el ángulo que le falta girar. Sobre los dos se aplica control proporcional.

La regla es sencilla: si el robot está muy mal orientado, primero gira en el sitio; cuando ya apunta al objetivo, avanza con una velocidad proporcional a la distancia y corrige el rumbo sobre la marcha. Un detalle importante: el ángulo hay que envolverlo entre −180° y 180° con atan2 del seno y el coseno, o el robot puede dar una vuelta completa para corregir 2 grados.

Y fíjense en lo que hace con el cuadrado: ya no es "avance 50 cm, gire 90°" como la semana pasada, sino "vaya a estos cuatro puntos". Ese programa usa la odometría como pose. Si la pose se corrige cada vez que la cámara ve una marca, el robot cierra el cuadrado aunque las ruedas patinen. Ese es el ejercicio de la semana.

El robot con celular

• App: IP Webcam (Android) o IP Camera Lite (iOS)
• Celular y PC en la misma red: si la de la universidad falla, un hotspot
• La IP del celular cambia con cada red: revísenla en la app antes de correr C01

NOTAS

Esta es la plataforma de la semana: el mismo robot diferencial, con un marco sobre el ladrillo para sostener el celular. El modelo de Studio está en la guía "Uso cámara del celular", para que lo armen antes de la clase.

El celular transmite video al computador con una aplicación de cámara IP. El computador procesa la imagen con OpenCV y le manda las órdenes al EV3 por Bluetooth, como en la semana 12. Es decir, hay dos enlaces inalámbricos en el lazo, y cada uno agrega retraso: por eso vimos que el retraso importa.

El problema más común en el laboratorio no es de robótica sino de redes: el celular y el computador tienen que estar en la misma red, y la red de la universidad a veces aísla los dispositivos. Si no conecta, creen una zona de cobertura desde el computador o el celular. Y la IP cambia cada vez que se conectan, así que actualícenla en el programa.

Prácticas de la semana

#	Guía	Qué se aprende
1	Uso cámara del celular	transmitir el video al PC (C01, C02)
2	La información de la cámara	una fila, el umbral y el centro de masa (C03)
3	Control continuo	control P del giro y seguir una línea (C04, C05)
4	ArUco	detectar marcas y medir distancias (C06, C07, C08)
5	Ejercicio	mejorar los cuadrados con lo visto hoy

Guías: Semana 13 en el sitio del curso

NOTAS

Estas son las prácticas, en el orden en que conviene hacerlas. Las dos primeras son de preparación: conectar la cámara y entender qué entrega. Si la primera no funciona, ninguna de las siguientes va a funcionar, así que háganla antes de llegar al laboratorio.

La tercera es el control P: primero solo girando hacia la línea, y luego siguiéndola con el teclado para cambiar la velocidad y la ganancia. Respondan las preguntas de la guía con lo que vimos en "¿Por qué no se alinea?". La cuarta es la de ArUco: detectar los marcadores, medir su distancia al centro de la imagen y, con una foto de alta resolución, medir las distancias entre cuatro marcadores puestos en las esquinas de un cuadrado.

La quinta es el ejercicio que cierra el bloque de plataformas móviles: retoman los cuadrados de la semana 12 y los mejoran con todo lo que tienen: calibración, giroscopio, y si se animan, marcas en el piso para corregir la pose. Instalen opencv-contrib-python, que trae el módulo de ArUco.

¿Qué nos llevamos hoy?

1. Ya calibraron $r$ y $l$, pero después de cuatro cuadrados el robot sigue terminando a unos 10 cm del inicio. Un compañero propone repetir la calibración con más cuidado. ¿Resolverá el problema? ¿Qué le falta al robot?

2. Imprimieron los marcadores con la opción "ajustar a la página" y quedaron de 2.3 cm de lado, pero el programa sigue usando 0.0254. ¿Qué les pasa a las distancias que mide la cámara, y a qué error de la semana 12 se parece?

3. Con $K_p = 0.05$ el robot se queda quieto con la línea a 15 px del centro; con $K_p = 0.5$ se mueve de lado a lado sin parar. ¿Qué explica cada comportamiento y qué cambiarían en el programa?

NOTAS

Para cerrar, en parejas, unos dos minutos por pregunta y sin mirar las diapositivas anteriores. Son situaciones que les pueden pasar esta semana en el laboratorio.

Pregunta 1 (por qué localizar). Queremos que lleguen a que calibrar de nuevo ayuda poco: lo sistemático ya se corrigió, y lo que queda es en buena parte aleatorio, como el patinaje, y crece con la distancia. Ninguna calibración lo elimina; hace falta una referencia externa, una marca que el robot reconozca, para acotar el error. Si no llegan, retomen "¿Por qué localizar?" con la figura de las nubes y "Corregir con una marca".

Pregunta 2 (landmarks). La escala en píxeles por metro sale de dividir el lado en píxeles por 0.0254, cuando el lado real es 0.023: la escala queda cerca de un 10 % baja y todas las distancias salen cerca de un 10 % más grandes de lo real, siempre en el mismo sentido. Es un error sistemático, idéntico a usar un radio de rueda mal medido: se corrige midiendo el marcador impreso, es decir, calibrando. Si dudan, vuelvan a "De píxeles a metros".

Pregunta 3 (cerrar el lazo). Con Kp de 0.05 y 15 px de error, Kp por error es 0.75, que al convertirlo a entero da cero: el robot recibe la orden de no moverse. Además, los motores tienen fricción. Con Kp de 0.5 el robot reacciona con fuerza a una imagen que llega tarde y se pasa. Lo que deberían proponer: no truncar o usar un término integral para el primer caso, y bajar la ganancia o reducir el retraso, por ejemplo con menor resolución, para el segundo. Retomen "¿Por qué no se alinea?". Con esto cerramos y pasamos al laboratorio.