La llamada physical AI parte de una idea simple: la inteligencia no debería detenerse en la percepción. Un sistema que percibe su entorno, razona sobre él y actúa en un mismo ciclo continuo es lo que separa a un dispositivo que observa de uno que efectivamente hace algo.
Los robots móviles autónomos, o AMR por su sigla en inglés, son una de las expresiones más claras de ese planteamiento. Un robot de reparto que circula por una bodega debe llevar piezas al estante correcto o dejarlas en una cinta transportadora para inspección o empaque. En el trayecto tiene que detenerse si alguien se cruza, o recalcular su ruta si movieron un carro. Necesita entender lo que lo rodea, determinar su posición, calcular una trayectoria y responder a los cambios del entorno hasta llegar a destino.
Todo eso, además, mientras controla sus ruedas con precisión, lee sensores de forma continua y reacciona rápido ante obstáculos cercanos.
¿Por qué un AMR necesita dos computadores?
En todos los AMR esas tareas exigen dos tipos distintos de cómputo. La navegación, la visión por computador y la inteligencia artificial se benefician de la flexibilidad y el rendimiento de Linux. El control de motores y la gestión de sensores sensibles al tiempo requieren la capacidad de respuesta de un microcontrolador.
VENTUNO Q junta esos dos mundos, combinando un MPU capaz de correr Linux con un MCU de tiempo real en una sola plataforma. Arduino explica la arquitectura a partir de un caso hipotético, un robot de reparto de comida donde percepción, ROS 2, inteligencia artificial en el borde y control físico trabajan en conjunto.
Dos mundos de cómputo, un solo robot
En un prototipo convencional de AMR, el cómputo de alto nivel y el control de motores suelen estar repartidos en placas separadas. Un computador con Linux corre ROS 2 y procesa datos de cámaras y LiDAR, mientras un microcontrolador administra motores, encoders y sensores locales. El esquema funciona, pero agrega trabajo de integración: hay que conectar las placas, definir su protocolo de comunicación, mantener varios entornos de desarrollo y depurar la interacción entre sistemas que fueron diseñados de manera independiente.
VENTUNO Q ofrece un punto de partida más integrado. Su MPU puede alojar Linux, ROS 2, software de navegación, visión por computador y cargas de trabajo de inteligencia artificial. Su MCU permanece cerca del robot físico, gestionando el control de ruedas, la realimentación de encoders, las mediciones inerciales, la detección de corto alcance y la comunicación con los controladores de motor. La separación de responsabilidades es nítida: el MPU determina hacia dónde debe ir el robot, mientras el MCU convierte esa decisión en movimiento físico controlado.
Percibir: cómo arma el robot su mapa del entorno
Ningún sensor por sí solo entrega toda la información necesaria, así que la arquitectura combina varias fuentes complementarias.
Un LiDAR 2D aporta la base geométrica de la navegación. Sus barridos láser describen muros, pasillos, mobiliario y otras estructuras alrededor del robot. Combinados con la odometría de las ruedas y los datos inerciales, esos barridos permiten que el software de SLAM construya un mapa y luego ayude al robot a estimar su posición dentro de él. Pero un LiDAR que escanea en un solo plano no describe todos los obstáculos: la superficie de una mesa, un cajón abierto o un objeto que sobresale hacia el paso del robot pueden quedar por encima o por debajo de ese plano.
Una cámara estéreo de profundidad agrega información tridimensional y ayuda a percibir formas que no aparecen con claridad en un barrido plano. Una cámara MIPI aporta entrada visual para tareas más específicas, como detectar personas, reconocer una estación de entrega o verificar si hay una bandeja presente.
Imagen de referencia
Más cerca del chasis, un nodo Modulino Distance vigila los puntos ciegos o detecta objetos inmediatamente al frente. Un Modulino Movement entrega datos de aceleración y velocidad angular, que contribuyen a la estimación de movimiento y ayudan a identificar vibraciones anómalas, colisiones o desplazamientos inesperados.
Los encoders de rueda completan el cuadro midiendo cómo se está moviendo realmente el robot. El MCU usa esa realimentación para regular la velocidad de cada rueda, y la odometría resultante se comparte con el software de navegación que corre sobre Linux. En lugar de depender de un único sensor "inteligente", el robot construye conciencia del entorno combinando información geométrica, visual, inercial y mecánica.
Decidir: ROS 2 como columna vertebral
Sobre el MPU, ROS 2 provee un entorno de software común para conectar todos esos elementos. El LiDAR publica barridos láser. La cadena de la cámara entrega imágenes o información de profundidad. El robot publica odometría y mediciones inerciales. Los componentes de navegación consumen esos datos para estimar la posición, planificar una ruta y responder cuando el entorno cambia.
Imagen de referencia
Durante su primera exploración de un espacio, un paquete de SLAM en ROS 2 combina datos del LiDAR y odometría para crear un mapa. Una vez disponible ese mapa, el robot se localiza y usa Nav2 para moverse entre destinos. Si la aplicación lo envía desde la bodega a la estación de empaque, Nav2 calcula una ruta apropiada y la actualiza de forma continua a medida que llega nueva información de los sensores. Luego genera comandos de velocidad que describen con qué rapidez debe avanzar y rotar. Esos comandos expresan la intención de movimiento, pero no controlan los motores de forma directa: esa responsabilidad pasa del dominio Linux al MCU.
Actuar: del comando ROS 2 al giro de la rueda
Cuando Nav2 publica un comando de velocidad, una capa de comunicación entre MPU y MCU traslada la petición a la aplicación de control en tiempo real. El MCU traduce el movimiento lineal y angular solicitado en objetivos para la rueda izquierda y la derecha. Después se comunica con los controladores de motor, potencialmente sobre CAN, y usa la realimentación de los encoders para mantener la velocidad requerida.
Ese lazo de control corre con temporización predecible, de forma independiente al grafo de software ROS 2 que opera sobre Linux. La información también viaja en sentido contrario: mediciones de encoders, datos inerciales, lecturas de distancia de corto alcance y diagnósticos del sistema de tracción pasan del MCU al MPU, donde quedan disponibles para la aplicación ROS 2.
Esa conexión entre los dos dominios de cómputo es uno de los elementos más importantes de la arquitectura, según Arduino. Permite que el software de navegación de alto nivel interactúe con el robot físico sin pedirle a Linux que administre cada detalle eléctrico y mecánico sensible al tiempo.
También abre espacio para reacciones locales. Si un sensor de corto alcance detecta un objeto justo al frente, el MCU puede llevar el sistema de tracción a un estado de detención controlada y reportar el evento al MPU. La capa de navegación reevalúa entonces la situación, actualiza la ruta o avisa a la aplicación.
Inteligencia artificial en el borde para dar contexto
El LiDAR, la odometría y Nav2 ya permiten navegar por un entorno mapeado. La inteligencia artificial se vuelve valiosa cuando el robot necesita entender el significado de lo que percibe. El sistema de navegación puede detectar un obstáculo, pero un modelo de visión determina si ese obstáculo es una persona, una silla o un carro de reparto. Ese contexto adicional habilita comportamientos más apropiados: si alguien se acerca, el robot puede desacelerar, esperar o anunciar que llega una entrega.
Edge Impulse ofrece uno de los flujos de trabajo posibles para desarrollar ese tipo de inteligencia específica. A través de su integración con ROS 2, un modelo de inferencia consume datos de imagen y deja sus resultados disponibles para el resto de la aplicación robótica. Con la plataforma integrada, el despliegue hacia Arduino App Lab queda a un clic.
Crecer el prototipo por etapas
Aunque la arquitectura de referencia incluye navegación, sensado de profundidad e inteligencia artificial, no es necesario introducir todas las capacidades de una vez. El primer prototipo puede concentrarse solo en la base móvil, con el MCU controlando los motores y leyendo los encoders. Una vez que el movimiento básico es confiable, la capa de control se conecta a ROS 2 en el MPU para que el robot acepte comandos de velocidad estándar y devuelva odometría.
Agregar el LiDAR introduce mapeo, localización y navegación autónoma. El sensado de profundidad y los sensores de corto alcance mejoran después la conciencia de obstáculos. Finalmente, la visión con inteligencia artificial transforma la plataforma genérica en un robot de reparto capaz de reconocer personas, destinos y eventos específicos de la aplicación.
VENTUNO Q no elimina los desafíos de ingeniería que implica construir un AMR. El diseño mecánico, la gestión de energía, el dimensionamiento de motores, el ajuste de la navegación, la ubicación de los sensores y la seguridad siguen exigiendo trabajo cuidadoso. Su valor está en ofrecer un punto de partida más coherente.
De la percepción al movimiento
Un robot de reparto de comida es solo una expresión de esta arquitectura. El mismo modelo de cómputo puede sostener vehículos de bodega, robots de inspección, sistemas de logística hospitalaria, plataformas agrícolas y otras máquinas autónomas. Los sensores, los sistemas de tracción y los modelos de inteligencia artificial cambian, pero el desafío de fondo es el mismo: conectar la inteligencia de alto nivel con la acción física responsiva.
La placa se vende a través de la tienda oficial de Arduino y de distribuidores como DigiKey, Farnell, Mouser, Robu.in y RS. Para quienes compran desde Chile, esa lista importa más de lo que parece: los tres primeros despachan a la región, pero el costo de internación y los tiempos de aduana suelen pesar tanto como el precio de la placa.
