La robótica de servicios reúne aplicaciones muy diferentes: hacer inventario, interactuar con personas o manipular objetos. Elegir la forma y las capacidades de un robot requiere empezar por la tarea que debe resolver. Francesco Ferro desarrolla esa idea en el capítulo 36 de Toque de Ingenio, donde explica la trayectoria de PAL Robotics y las decisiones que separan una demostración tecnológica de una herramienta útil.
Invitado: Francesco Ferro, cofundador de PAL Robotics.
Conversación publicada: 3 de febrero de 2025. Episodio: 36. Duración: 1 h 31 min.
En este capítulo:
- Por qué un robot de inventario y un robot social pueden necesitar formas distintas.
- Cómo una plataforma modular facilita desarrollar nuevas aplicaciones de manipulación.
- Qué conviene observar al evaluar una demostración y su posible uso real.
Francesco sitúa el origen de PAL Robotics en un proyecto para construir un robot que jugara al ajedrez. El equipo acabó proponiendo una solución humanoide y desarrollándola desde Barcelona. La entrevista recorre el aprendizaje acumulado desde aquel comienzo y los productos y proyectos descritos en febrero de 2025.
Empezar por la función que aporta valor
El episodio muestra cómo la robótica de servicios puede responder a necesidades operativas concretas. En lugar de hablar de un robot genérico capaz de hacerlo todo, Francesco utiliza ejemplos de inventario, interacción y manipulación. Cada aplicación tiene una manera distinta de justificar su utilidad.
En una tienda, conocer qué productos hay y dónde se encuentran ayuda al trabajo del personal. En una experiencia social, la función puede estar en recibir o interactuar con visitantes. Las capacidades técnicas se evalúan con objetivos diferentes y no deberían compararse solo por la apariencia del robot.
Esta distinción orienta las primeras decisiones de desarrollo. Sensores, movilidad, brazos e interfaz deben elegirse según la tarea y el entorno. Añadir una capacidad que no se necesita puede aumentar complejidad sin mejorar el resultado que espera el cliente.
Para proyectos de ingeniería y automatización, la pregunta inicial es qué trabajo debe realizar el sistema y cómo se comprobará que lo hace bien. Una definición concreta permite priorizar recursos y preparar pruebas relacionadas con el uso previsto.
Un robot de inventario que necesita pasar desapercibido
Francesco describe una plataforma móvil que recorre tiendas para ayudar a mantener el inventario y localizar productos. El valor no está únicamente en saber que una unidad existe, sino en encontrarla cuando no está donde debería. Esa información puede ahorrar búsquedas al personal.
El entorno comercial introduce dificultades que no aparecen en una prueba de laboratorio. La conversación menciona coordinación con alarmas, horarios y otros detalles de implantación. Un robot que se mueve de manera autónoma necesita convivir con los sistemas y rutinas del establecimiento.
La forma exterior también responde a la tarea. Para un equipo centrado en inventario, atraer la atención de visitantes podía interferir con su recorrido. Francesco explica que, en ese caso:
«la idea es justamente no darle forma humana».
Francesco Ferro, 22:27.
La observación muestra que el diseño de interacción incluye decidir cuándo no se quiere provocar una interacción. Un objeto puede necesitar resultar comprensible y seguro sin invitar a jugar con él. La apariencia tiene consecuencias operativas y debe evaluarse en su contexto.
La interacción social plantea otros requisitos
Francesco contrapone ese uso con robots preparados para relacionarse con personas. En la entrevista menciona experiencias de bienvenida y participación en espacios comerciales. En ellas, el aspecto y los recursos expresivos forman parte de la función buscada.
El diálogo recorre la relación entre apariencia humana y expectativas. Un robot que parece capaz de conversar o comprender una situación puede generar una expectativa que luego debe sostener. Diseñar su presencia exige pensar en lo que la persona interpretará al verlo.
También se distingue interacción social e interacción física. Hablar o mostrar información no tiene las mismas exigencias que ayudar a mover un objeto o establecer contacto con una persona. Cada aplicación necesita definir capacidades y condiciones de funcionamiento propias.
Desde el diseño de experiencia de usuario, el caso recuerda que interfaz, forma y comportamiento comunican conjuntamente. La persona no ve módulos separados de hardware y software: percibe una conducta. La coherencia entre lo que el robot sugiere y lo que puede hacer influye en la confianza.
TIAGo y el valor de una plataforma que puede evolucionar
Francesco presenta TIAGo como una plataforma desarrollada con un foco importante en investigación. Su configuración combina movilidad y manipulación, y permite incorporar distintos sensores y equipos. Esa flexibilidad facilita que otros grupos trabajen sobre aplicaciones propias.
El invitado relaciona la modularidad con la posibilidad de añadir capacidades:
«sin tener que comprar un robot nuevo».
Francesco Ferro, 35:50.
La plataforma proporciona una base sobre la que experimentar, pero la aplicación concreta sigue necesitando desarrollo. Cambiar un sensor o una herramienta abre nuevas posibilidades y también exige integración. Un sistema modular debe definir bien cómo se conectan sus partes.
La conversación incluye un ejemplo de investigación en agricultura, donde la herramienta de manipulación se adapta a una tarea específica. Un brazo no resuelve por sí solo la interacción con cualquier objeto. El extremo que lo sujeta o actúa sobre él debe responder al trabajo que se quiere realizar.
Este principio es útil para empresas que diseñan familias de máquinas. Una base común puede reducir trabajo repetido, mientras los módulos permiten especializar funciones. La arquitectura gana valor cuando mantiene claras las interfaces y las condiciones de cada combinación.
El software compartido reduce trabajo de integración
Francesco explica el uso de ROS como una base de software para comunicar e integrar componentes. La finalidad es que quienes desarrollan una aplicación puedan concentrarse en sus algoritmos y capacidades, en vez de reconstruir continuamente la infraestructura de funcionamiento.
La entrevista también menciona contribuciones de PAL Robotics a herramientas compartidas. Ese trabajo facilita combinar módulos y relacionar diferentes sistemas. La interoperabilidad aparece como una necesidad práctica cuando una aplicación incorpora componentes o robots de varios orígenes.
La lección de desarrollo es distinguir qué parte debe aportar la plataforma y qué parte pertenece a la aplicación. Una infraestructura estable puede acelerar experimentos y facilitar mantenimiento. Para conseguirlo, el equipo necesita conocer las dependencias y comprobar que el conjunto responde como se espera.
En la validación de un robot, los prototipos permiten observar esa integración en funcionamiento. La prueba debe ir más allá de cada módulo aislado: interesa saber cómo se comporta la secuencia completa y qué ocurre cuando cambian las condiciones del entorno.
De una demostración a una operación repetible
Edgar pregunta por vídeos de robots humanoides que realizan tareas llamativas. Francesco propone mirar qué hay detrás de la demostración: el grado de autonomía, la preparación del entorno y la forma en que se ha conseguido el resultado. Un vídeo puede mostrar una capacidad sin explicar todas sus condiciones.
La conversación compara robots con ruedas y robots con piernas. Francesco relaciona la elección con el terreno y con la necesidad de superar ciertos obstáculos. La forma adecuada depende de la aplicación; una superficie plana puede admitir soluciones distintas de un recorrido con escaleras.
Ese criterio ayuda a evaluar propuestas con menos atención al espectáculo y más al trabajo. Importan repetibilidad, coste de operación y adecuación al entorno. Las capacidades deben revisarse con la tarea real que el cliente necesita resolver.
Qué puede aprender otro equipo de desarrollo
- Definir la tarea antes de elegir apariencia, movilidad y herramientas del robot.
- Diseñar la interacción que conviene a la operación, incluida la posibilidad de pasar desapercibido.
- Utilizar plataformas modulares con interfaces claras para desarrollar aplicaciones distintas.
- Evaluar demostraciones por sus condiciones, autonomía y capacidad de repetir el resultado.
PAL Robotics muestra cómo la experiencia acumulada se convierte en decisiones concretas de producto. Para empresas que desarrollan sistemas de automatización o equipos que deben interactuar con su entorno, i-mas puede ayudar a definir requisitos y preparar una validación útil. Puedes contarnos el reto que quieres resolver.
Para seguir leyendo: La automatización del picking de almacén con Illumo Robotics.
Fuente del artículo: entrevista de Edgar Guerrero con Francesco Ferro en Toque de Ingenio, publicada el 3 de febrero de 2025. Las citas enlazan con sus pasajes en el vídeo; los aprendizajes son una síntesis editorial de la conversación.
