Programación de robots de servicio

Qué hacemos para el cliente

Tomamos tu plataforma de servicio (un robot de reparto, de desinfección o de recepción) y escribimos para ella el software operativo y los escenarios de comportamiento. La programación de robots de servicio en nuestro caso significa el despliegue del stack en el ordenador de a bordo, la configuración de los drivers del lidar, las cámaras y la base con ruedas, la construcción del mapa del espacio y la lógica de las rutas. No fabricamos el chasis ni imprimimos la carcasa: transporta y desinfecta el equipo del cliente, y nosotros preparamos la capa de control que lo hace actuar de forma predecible. El trabajo incluye la integración con tus sistemas: llamada del ascensor, apertura de puertas, entrega del pedido, transmisión de estados al sistema de gestión mediante una API. Como resultado obtienes no una demo, sino una máquina configurada que ejecuta las tareas definidas en tu edificio.

Cómo funciona en esencia

El robot construye y refina de forma continua el mapa del espacio a partir de los datos del lidar y la odometría, y luego se localiza en ese mapa en tiempo real. Sobre la localización trabaja el planificador: traza la ruta global hasta el objetivo y de inmediato recalcula la trayectoria local, esquivando personas, carros y obstáculos temporales. Cada acción de aplicación (entrar en una habitación, situarse junto a un mostrador, rodear una cola) se describe con un escenario propio con condiciones y reacciones ante fallos. Configuramos los umbrales de velocidad, las zonas de seguridad y el comportamiento ante la pérdida del objetivo, para que la máquina se detenga y no embista el obstáculo. Toda esta combinación de navegación y escenarios es lo que convierte el hardware del cliente en un robot de servicio funcional.

De dónde surgió la robótica de servicio

Como punto de partida se suele tomar el robot Shakey, que en el Stanford Research Institute (SRI) se desarrolló entre 1966 y 1972. Fue el primer robot móvil de propósito general capaz de razonar sobre sus propias acciones: percibía el entorno, elaboraba un plan, dividía el comando en pasos y se recuperaba tras un error. La robótica de servicio comercial arrancó más tarde: Joseph Engelberger fundó Transitions Research Corporation en 1984, y en 1988 instaló el primer robot hospitalario HelpMate en el hospital de Danbury (Connecticut). HelpMate repartía por sí solo medicamentos y muestras por las plantas, y en una década máquinas así ya funcionaban en más de un centenar de hospitales. Es precisamente esta línea, del Shakey de investigación al HelpMate en serie, la que marcó la lógica de navegación y escenarios sobre la que se asienta toda la técnica de servicio actual.

Por qué es crítica la parte de software

En un robot de servicio la física del chasis es secundaria: el resultado lo determina la precisión de la localización y la calidad de los escenarios. Un error de posicionamiento de diez centímetros significa que la máquina no acertará en el hueco de la puerta o se situará al lado del mostrador de entrega; un desajuste entre el mapa y la realidad provoca el atasco en un pasillo. Por eso el ajuste de los parámetros del planificador, el filtrado del ruido de los sensores y la calibración de las zonas de seguridad influyen en el resultado más que las características de los motores. El robot rueda y desinfecta con su propio hardware, pero lo conduce el software, y de él depende que llegue sin colisiones ni intervención del operario. Una buena programación de robots de servicio no es una opción adicional a la plataforma, sino la condición sin la cual esta sigue siendo un conjunto inmóvil de componentes.

Sobre qué stack trabajamos

La herramienta base es ROS2, un framework abierto para robótica: sobre él se construye la arquitectura de nodos, el intercambio de mensajes entre los sensores y el control, y el arranque y diagnóstico de los módulos. La navegación la implementamos sobre el stack Nav2, la solución estándar para ROS2, encargada de la construcción del mapa, la localización, la planificación global y local de la ruta y los árboles de comportamiento. La combinación de ROS2 y Nav2 cubre toda la ruta del robot: desde la recepción de la nube de puntos del lidar hasta el comando concreto al accionamiento. La lógica de aplicación (el orden de las tareas, las reacciones a eventos, la integración con ascensores y sistemas de gestión) la escribimos por encima de ese stack para el edificio concreto del cliente. El stack es abierto y mantenido, por lo que la solución no está atada a un único proveedor y evoluciona junto con el ecosistema.

Cuándo aparecieron las herramientas clave

El propio ROS (Robot Operating System) apareció en la empresa Willow Garage: el repositorio del proyecto se creó el 7 de noviembre de 2007, y la versión 1.0 salió en 2010 y se convirtió rápidamente en el estándar del sector para la investigación y el desarrollo. La primera generación tenía limitaciones arquitectónicas para tareas en serie y multirrobot, por eso se reescribió: la primera distribución de ROS2, con el nombre Ardent Apalone, salió el 8 de diciembre de 2017. Nav2 se desarrolló como sucesor del antiguo stack de navegación de ROS, reelaborado para ROS2 usando enfoques del transporte autónomo. Estas fechas importan en la práctica: trabajamos sobre la segunda generación actual, pensada para la explotación industrial, y no sobre una rama obsoleta. El stack está probado por el tiempo y la comunidad, lo que reduce los riesgos en la explotación prolongada de tu plataforma.

Por qué puedes confiárnoslo

Detrás del desarrollo hay un equipo con una experiencia combinada en TI de más de 45 años, y para nosotros el robot es ante todo un reto de ingeniería, no de marketing. No prometemos milagros de tu hardware: evaluamos con sobriedad lo que la plataforma es capaz de hacer y llevamos el software hasta ese límite. Cada escenario pasa una comprobación en simulación y en banco antes de que el robot salga a la zona de trabajo con personas; la puesta en marcha solo se hace después de ejecutar las situaciones anómalas. Respondemos por la capa de control: la navegación, los escenarios, las integraciones y la configuración del equipo del cliente, dejando la fabricación del hardware a su fabricante. Este enfoque diferenciado da una zona de responsabilidad clara y un resultado que se reproduce, y no que solo queda bonito en una única demostración.