Lo difícil no fue hacerlo caminar. Fue lograr que entendiera dónde estaba.

Cuando alguien ve un robot cuadrúpedo caminando por una habitación, la primera reacción suele ser pensar en movimiento.

Caminar. Girar. Esquivar una silla. Ir de un punto A a un punto B.

Pero durante el desarrollo de mi sistema de navegación autónoma para un Unitree Go2 descubrí que esa era probablemente la parte menos interesante del problema.

El verdadero problema era otro:

¿Cómo sabe el robot dónde está?

Porque para una persona una oficina es obvia.

Hay un pasillo. Una puerta. Una pared. Una mesa. Un espacio por donde se puede caminar y otro por donde no.

Para una máquina, inicialmente, no existe nada de eso.

Solo existen sensores y mediciones.

Un robot no ve una habitación

El sistema contaba con sensores como LiDAR y una cámara de profundidad RealSense.

Eso significa que el robot puede obtener muchísima información sobre su entorno, pero disponer de información y comprender el espacio son cosas distintas.

Un LiDAR puede devolver miles de distancias.

Una cámara de profundidad puede representar superficies.

Pero todavía necesitamos transformar todo eso en algo que permita responder preguntas aparentemente simples:

• ¿Dónde estoy?
• ¿Dónde estaba hace cinco segundos?
• ¿Dónde está la pared?
• ¿Esta zona es transitable?
• ¿Puedo llegar hasta aquel punto?
• ¿El objeto frente a mí estaba allí antes?
• ¿Estoy observando una puerta o simplemente una apertura temporal?

Ahí es donde navegación autónoma deja de ser un problema de movimiento y empieza a convertirse en un problema de representación.

El mapa tiene que convertirse en una fuente de verdad

Uno de los primeros obstáculos fue precisamente la calidad de los mapas.

Un mapa ligeramente incorrecto para una persona puede seguir siendo perfectamente comprensible.

Para un robot puede hacer que toda la navegación falle.

Ruido, desplazamientos, lecturas inconsistentes o pequeñas desviaciones terminan acumulándose.

Si el sistema cree que una pared está veinte centímetros donde no está, puede ser una molestia.

Si cree que el pasillo se desplazó, el problema ya es mucho mayor.

Por eso gran parte del trabajo terminó alrededor de la relación entre:

sensores → localización → mapa → planificación → movimiento.

No simplemente alrededor de enviar comandos al robot.

De teleoperación a misiones

Mi objetivo tampoco era construir un control remoto sofisticado.

Eso ya existe.

Quería que el robot pudiera recibir una misión:

patrulla esta zona.

Y que el sistema resolviera el resto.

Para eso fui construyendo una capa de operación donde pudiera trabajar con:

• navegación autónoma,
• mapas 2D y 3D,
• evasión de obstáculos,
• telemetría,
• zonas,
• puntos importantes,
• y misiones programadas.

La interfaz web terminó siendo una parte importante del sistema.

No porque el robot necesitara una página web para caminar, sino porque una persona necesita entender qué cree el robot que está ocurriendo.

Ese principio terminó siendo fundamental.

Una buena interfaz de robótica no sirve únicamente para controlar.

Sirve para hacer visible el estado interno del sistema.

Autonomía no significa simplemente quitar al operador

Hay una forma muy sencilla de construir algo que parece autónomo:

ocultar todas las decisiones.

Pero eso produce sistemas extremadamente difíciles de diagnosticar.

Prefiero pensar en autonomía como una colaboración.

El robot ejecuta.

El sistema interpreta.

El operador puede observar.

Si algo falla, existe suficiente telemetría y contexto para comprender por qué.

La verdadera autonomía no consiste en eliminar completamente al humano.

Consiste en reducir las decisiones repetitivas que necesita tomar.

El aprendizaje más importante

Este proyecto cambió bastante mi forma de pensar sobre software.

Cuando construyes una aplicación tradicional, muchas veces el mundo que estás modelando ya es digital.

Usuarios.

Órdenes.

Pagos.

Eventos.

En robótica ocurre algo diferente.

Primero tienes que convertir el mundo físico en información suficientemente confiable como para poder operar sobre ella.

Y ahí aparece el patrón:

mundo físico → sensores → datos → representación → decisión → acción.

Eso terminó conectándose mucho con otros sistemas que he construido.

IoT.

Tracking.

Automatización.

Inteligencia artificial.

Al final, el problema casi nunca es simplemente mover una máquina.

El problema es conseguir que el sistema tenga una representación suficientemente buena del mundo como para tomar decisiones útiles.

Por eso, después de trabajar en navegación autónoma, mi conclusión sigue siendo la misma:

Lo difícil no fue hacerlo caminar. Fue lograr que entendiera dónde estaba.