Plataforma universal para la coordinación de sistemas multirobot

Curso: 2024-2025 Director/Directora: Mancisidor Barinagarrementeria, Aitziber <FOTO (Tamaño máximo: 10x10cm.)> Estudiante: Hervás Gutiérrez, María PLATAFORMA UNIVERSAL PARA LA COORDINACIÓN DE SISTEMAS MULTIROBOT MÁSTER UNIVERSITARIO EN INGENIERÍA DE CONTROL, AUTOMATIZACIÓN Y ROBÓTICA TRABAJO FIN DE MASTER Fecha: Bilbao, 12, Septiembre, 2025 Resumen Trilingüe Resumen El desarrollo de sistemas robóticos avanza hacia escenarios cada vez más complejos, en los que la heterogeneidad de plataformas y la necesidad de trabajar con flotas de robots de distinta tipología plantean nuevos retos. La situación actual está marcada por una fuerte dependencia del software propietario de cada fabricante, lo que limita la interoperabilidad y dificulta la reutilización de soluciones entre diferentes entornos, con repercusiones en flexibilidad y costes de formación, integración y sustitución de equipos. En este Trabajo de Fin de Máster ( TFM ) se ha diseñado e implementado una arquitectura modular que permite gestionar y coordinar misiones en entornos multirobot de manera genérica e independientemente del hardware específico. La validación se ha realizado en Gazebo Sim, lo que proporciona un laboratorio virtual seguro, flexible y reproducible. El sistema se estructura en capas que abarcan desde la interacción con el usuario, a través de un panel personalizado en RViz, hasta la gestión de los modelos robóticos mediante servicios en Robot Operating System (ROS) 2. Se han integrado cinco robots representativos (ABB YuMi, KUKA LBR iiwa, UFactory XArm6, UFactory 850 y UR10e), elegidos tanto por su relevancia en la investigación como por su disponibilidad en el laboratorio donde se ha desarrollado el trabajo. Esto refuerza la aplicabilidad de la propuesta, ya que sienta las bases para nuevas líneas de investigación en el departamento. Además, la interfaz gráfica implementada facilita la configuración de misiones de forma intuitiva y accesible para el usuario. Palabras clave: Coordinación Multirobot, Gazebo Sim, Misiones Distribuidas, ROS 2, RViz 3 Abstract The development of robotic systems is progressing towards increasingly complex scenarios, where the heterogeneity of platforms and the need to work with fleets of robots of different types pose new challenges. The current situation is marked by a strong dependence on proprietary software from each manufacturer, which limits interoperability and hinders the reuse of solutions across different environments, with consequences on flexibility as well as training, integration, and equipment replacement costs. In this Master’s Thesis (TFM), a modular architecture has been designed and implemented to manage and coordinate missions in multirobot environments in a generic way, independently of the specific hardware. Validation has been carried out in Gazebo Sim, providing a safe, flexible, and reproductible virtual laboratory. The system is structured in layers, ranging from user interaction, through a customized panel in RViz, to the management of robotic models via services in ROS 2. Five representative robots (ABB YuMi, KUKA LBR iiwa, UFactory XArm6, UFactory 850, and UR10e) have been integrated, selected both for their relevance in research and for their availability in the laboratory where the project has been developed. This strengthens the applicability of the proposal, as it lays the foundation for new lines of research in the department. Furthermore, the implemented graphical interface facilitates the configuration of missions in an intuitive and accessible way for the user. Keywords: Distributed Missions, Gazebo Sim, Multirobot Coordination, ROS 2, RViz 4 Laburpena Sistema robotikoak gero eta agertoki konplexuagoetan erabiltzen dira, non plataformen heterogeneotasunak eta tipologia desberdineko roboten flotekin lan egin beharrak, erronka berriak planteatzen dituzten. Gaur egun, robot bakoitzak bere fabrikatzailearen softwarearekiko mendekotasun handia du, eta horrek mugatu egiten du fabrikatzaile desberdinen roboten arteko elkarlana eta berrerabiltzea. Master Amaierako Lan (MAL) honetan, multirobot inguruneak kudeatzeko eta koordinatzeko aukera ematen duen arkitektura modular bat diseinatu eta inplementatu da. Diseinua Gazebo Sim-en egiaztatu da, honek laborategi birtual segurua eta malgua erreproduzitzeko aukera eskaintzen baitu. Sistema geruzatan egituratzen da, erabiltzailearekiko elkarreraginetik hasi (RViz panel pertsonalizatu baten bidez) eta ROS 2 zerbitzuen bidezko eredu robotikoen kudeaketaraino. Bost robot adierazgarri integratu dira (ABB YuMi, KUKA LBR iiwa, UFactory XArm6, UFActory 850 eta UR10e). Robot hauek, ikerketan duten garrantzia eta lana egin den laborategian duten erabilgarritasunagatik aukeratu dira. Honek, proposamenaren aplikagarritasuna indartzen du, sailean ikerketa-ildo berrietarako oinarriak ezartzen baititu. Gainera, inplementatutako interfaze grafikoak misioen konfigurazioa errazten du, modu intuitibo eta eskuragarrian. Hitz gakoak: Gazebo Sim, Misio Banatuak, Multirobot Koordinazioa, ROS 2, RViz 5 Índice Índice de Figuras 11 Índice de Tablas 13 Acrónimos 15 1 Introducción 1 2 Contexto 3 3 Objetivos y alcance 5 3.1 Objetivos ................................. 5 3.2 Alcance .................................. 6 4 Beneficios 7 4.1 Objetivos de Desarrollo Sostenible (ODS) . . . . . . . . . . . . . . . . 8 5 Análisis del estado del arte 9 5.1 Introducción ............................... 9 5.2 Frameworks y arquitecturas para el desarrollo de sistemas robóticos . 10 5.3 Entornos de simulación robóticos . . . . . . . . . . . . . . . . . . . . 11 5.4 Ficheros de descripción de robots . . . . . . . . . . . . . . . . . . . . 12 5.5 Conclusiones del estado del arte . . . . . . . . . . . . . . . . . . . . . 13 6 Análisis de alternativas 15 6.1 Frameworks y arquitecturas para el desarrollo de sistemas robóticos . 15 6.2 Entornos de simulación . . . . . . . . . . . . . . . . . . . . . . . . . 18 7 Diseño y desarrollo de la solución propuesta 21 7.1 Arquitectura general del sistema . . . . . . . . . . . . . . . . . . . . . 21 7.2 Capa de ejecución física o simulada . . . . . . . . . . . . . . . . . . . 24 7.2.1 Descripción de los modelos . . . . . . . . . . . . . . . . . . . 25 7.2.2 Funcionalidad de Gazebo Sim . . . . . . . . . . . . . . . . . . 27 7.2.3 Robots disponibles en ejecución . . . . . . . . . . . . . . . . . 29 7.3 Capa de planificación y control . . . . . . . . . . . . . . . . . . . . . 32 7.4 Capa de gestión de robots . . . . . . . . . . . . . . . . . . . . . . . . 33 7 7.4.1 Servicios personalizados de ROS 2 . . . . . . . . . . . . . . . 34 7.4.2 Funcionamiento del nodo MissionManager ........... 34 7.5 Capa de interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . 35 7.5.1 Desarrollo del panel personalizado . . . . . . . . . . . . . . . 36 7.5.2 Funcionamiento del panel . . . . . . . . . . . . . . . . . . . . 37 7.6 Despliegue del sistema completo . . . . . . . . . . . . . . . . . . . . 38 8 Estudio de rendimiento del sistema 41 8.1 Metodología experimental . . . . . . . . . . . . . . . . . . . . . . . . 41 8.2 Análisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9 Metodología 47 9.1 Descripcióndetareas........................... 47 9.2 DiagramadeGantt............................ 50 10 Aspectos económicos 51 10.1Recursoshumanos ............................ 51 10.2 Material amortizable . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 10.3Costesindirectos ............................. 52 10.4 Coste total del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 52 11 Conclusiones y trabajo futuro 53 11.1Conclusiones ............................... 53 11.2Trabajofuturo............................... 54 Bibliografía 55 A Despliegue del sistema 59 A.1 Instalación de ROS 2 Humble . . . . . . . . . . . . . . . . . . . . . . 59 A.2 Instalación de Gazebo Sim . . . . . . . . . . . . . . . . . . . . . . . . 60 A.3 Dependencias adicionales . . . . . . . . . . . . . . . . . . . . . . . . 61 A.4 Compilación del espacio de trabajo . . . . . . . . . . . . . . . . . . . 61 A.5 Ejecucióndelsistema........................... 61 B Código de la solución propuesta 63 B.1 Carpeta robot_simulation ......................... 63 B.1.1 Paqueterobot_description ..................... 63 B.1.2 Paquete robot_gazebo ....................... 65 B.2 Paquete mission_management ...................... 73 B.2.1 Servicios personalizados de ROS 2 . . . . . . . . . . . . . . . 73 B.2.2 Fichero de lanzamiento del sistema completo . . . . . . . . . 74 B.2.3 Código del nodo MissionManager . . . . . . . . . . . . . . . . 75 B.2.4 Fichero de lanzamiento del nodo MissionManager . . . . . . . 81 B.3 Paquete custom_rviz_panels ....................... 82 8 B.3.1 mission_panel.cpp ......................... 82 B.3.2 mission_panel.hpp ........................ 87 B.3.3 Fichero de descripción del plugin ................ 88 9 1 Introducción Este Trabajo de Fin de Máster (TFM) se enmarca en el Máster Universitario en Ingeniería de Control, Automatización y Robótica ( INCAR ) de la Universidad del País Vasco (UPV/EHU). El TFM se ha desarrollado en el Departamento de Ingeniería de Sistemas y Automática de la Escuela de Ingeniería de Bilbao, contando además con la colaboración del centro tecnológico IKERLAN S. COOP, con sede en ArrasateMondragón. Esta investigación surge de la dificultad para definir y ejecutar misiones de trabajo de forma unificada entre robots de distintos fabricantes. Esta situación genera una fuerte dependencia tecnológica y económica, obliga a formar al personal en múltiples plataformas propietarias y limita la flexibilidad a la hora de reemplazar o integrar nuevos dispositivos. Como respuesta, en este TFM se propone una plataforma universal para la coordinación de misiones y operaciones, diseñada con independencia del hardware subyacente. En este contexto, la estructura del presente trabajo es la siguiente: El Capítulo 2 pone en contexto el trabajo desarrollado. En el Capítulo 3 se exponen los objetivos y el alcance del TFM . El Capítulo 4 describe los beneficios que aporta el trabajo realizado desde el punto de vista tecnológico, económico, medioambiental y social, además de su contribución a la consecución de los Objetivos de Objetivos de Desarrollo Sostenible ( ODS ). El Capítulo 5 comprende un estudio de los antecedentes bibliográficos relacionados con los objetivos expuestos anteriormente. El Capítulo 6 recoge un análisis de las diferentes alternativas para el desarrollo del sistema de coordinación de misiones. En el Capítulo 7 se detallan los pasos seguidos en el desarrollo de la solución propuesta. El Capítulo 8 presenta un estudio del rendimiento del sistema en simulación. El Capítulo 9 recoge la descripción de las tareas y fases del TFM , junto con un diagrama de Gantt que refleja su planificación. El Capítulo 10 aborda los aspectos económicos del TFM . Finalmente, en el Capítulo 11 se presentan las conclusiones extraídas y se plantean posibles mejoras y líneas de investigación futuras. Además, el documento incluye dos anexos: el Anexo A, que describe los pasos necesarios para instalar y ejecutar el sistema completo, y el Anexo B, donde se recopila el código de los principales ficheros desarrollados. 1 2 Contexto La robótica atraviesa una transformación profunda como resultado de la digitalización de los procesos industriales, el incremento de la capacidad de procesamiento y la proliferación de entornos de desarrollo open source o de código abierto. Esta nueva etapa tecnológica se caracteriza por la convergencia entre sistemas físicos y digitales, donde los robots dejan de ser elementos aislados para formar parte de sistemas ciberfísicos heterogéneos, interconectados y distribuidos. En este nuevo paradigma, los sistemas robóticos deben ser capaces de adaptarse dinámicamente al entorno, colaborar entre sí y compartir información de forma eficiente y segura [18, 23]. En línea con esta evolución, el mercado global del software robótico alcanzó en 2024 un valor estimado de 20.000 millones de dólares, con una previsión de crecimiento sostenido del 22,4% anual durante la próxima década [15]. Concretamente, el mercado de soluciones basadas en ROS fue valorado en 50.160 millones de dólares en 2023, con expectativas de alcanzar los 88.220 millones de dólares en 2030, lo que representa un crecimiento anual compuesto del 8,4% [16]. Sin embargo, el desarrollo de soluciones robóticas sigue enfrentando importantes limitaciones técnicas y metodológicas. Una de las más relevante es la elevada dependencia de soluciones propietarias impuesta por muchos fabricantes, lo que da lugar asoftware cerrado, APIs no estandarizadas e incompatibilidad entre plataformas [50]. Esto dificulta la reutilización de código, incrementa los tiempos y costes de desarrollo y limita la escalabilidad de las soluciones hacia escenarios multirobot y multifabricante. Además, la falta de compatibilidad entre sistemas entorpece la transferencia de soluciones entre proyectos, sectores o entornos académicos e industriales [4]. Frente a este escenario, la comunidad científica ha comenzado a promover enfoques orientados a la independencia del hardware mediante el uso de estándares abiertos y arquitecturas desacopladas que favorezcan la integración entre plataformas, la modularidad y la reutilización de componentes [6]. En esta línea, la evolución hacia ROS 2 constituye un avance significativo, al proporcionar una plataforma de programación de robots basado en el estándar Data Distribution Service ( DDS ), que incorpora mejoras sustanciales en la comunicación distribuida, la gestión del ciclo de vida de los nodos, el soporte para sistemas de tiempo real y la introducción de mecanismos de seguridad integrados [22]. Una encuesta reciente indica que un 78% de desarrolladores gráficosa estas capacidades como elementos clave para su 3 adopción, y ya se han documentado despliegues funcionales en entornos industriales con más de 100 robots operando de forma simultánea, superando con creces las limitaciones estructurales de ROS 1 [22, 27]. Asimismo, en el proceso de desarrollo de soluciones robóticas complejas, cobra especial relevancia la validación en entornos simulados, que permite realizar pruebas de forma segura, reproducible y a bajo coste. Entre las plataformas más utilizadas en este ámbito se encuentran Gazebo Sim, ampliamente extendida en la comunidad científica, Webots, reconocida por su estabilidad y facilidad de uso, o CoppeliaSim, que destaca por su flexibilidad y bajo consumo de recursos. También se emplean entornos como PyBullet, con gran orientación a la investigación en aprendizaje, o Isaac Sim y Unity, más centrados en gráficos realistas y aplicaciones industriales. Todas estas herramientas ofrecen capacidades avanzadas para modelar dinámicas físicas, sensores y escenarios multirobot, lo que es esencial para acelerar el ciclo de desarrollo y garantizar una transición robusta hacia entornos reales [5, 9, 42]. En este contexto, el presente TFM aborda de forma directa una problemática aún no resuelta: la falta de un entorno unificado que permita definir y ejecutar misiones robóticas sin depender del tipo de robot ni del fabricante. Para dar respuesta, se plantea el desarrollo de un entorno de aplicación independiente del hardware y basado en tecnologías abiertas, capaz de gestionar la ejecución de misiones robóticas en sistemas multirobot y multifabricante, promoviendo así la interoperabilidad, la escalabilidad y la reutilización de soluciones. Con ello, se sientan las bases para el desarrollo de un control de flotas heterogéneas de robots plenamente operativo, con posibilidad de extenderse a robots reales en fases posteriores. 4Chapter 2 Contexto 3 Objetivos y alcance 3.1 Objetivos El objetivo principal de este TFM es el desarrollo de un entorno de aplicación universal que permita la configuración de misiones y operaciones de forma ágil, con independencia del hardware de actuación. Para alcanzar este propósito, se establecen los siguientes objetivos parciales: •Objetivo 1: Análisis del estado de integración actual. El primer objetivo consiste en realizar un estudio exhaustivo sobre el estado de integración actual de múltiples fabricantes en diferentes entornos de desarrollo. Este análisis se centra en la identificación de los métodos, protocolos y estándares empleados, además de los principales obstáculos técnicos y de compatibilidad. Esta primera investigación orientará las fases posteriores del trabajo. •Objetivo 2: Desarrollo de un entorno de aplicación universal. El segundo objetivo del trabajo es el desarrollo de un entorno de aplicación universal para la definición y ejecución de misiones de trabajo con independencia del fabricante y la tipología del hardware. Este espacio deberá abstraerse de las características específicas de cada plataforma robótica, brindando al usuario la posibilidad de diseñar y ejecutar misiones de manera uniforme y flexible. La modularidad, la escalabilidad y la compatibilidad con estándares abiertos serán claves, ya que se busca facilitar su adopción en diversos contextos industriales y académicos. •Objetivo 3: Validación de la aplicación en un entorno de simulación. Tras completar el Objetivo 2, se realizan pruebas en entornos de simulación para comprobar el funcionamiento del sistema. Se utilizan robots manipuladores de diferentes fabricantes para asegurarse de que el hardware se abstrae correctamente, que los sistemas son interoperables y que se cumplen todos los requisitos funcionales definidos. 5 3.2 Alcance El presente TFM se centra en el diseño e implementación de una arquitectura modular para la definición y ejecución de misiones en entornos multirobot heterogéneos. El sistema se valida íntegramente en simulación, utilizando Gazebo Sim como entorno de ejecución, sobre un mundo vacío adaptado para optimizar el rendimiento del conjunto. No se contempla en esta fase el despliegue en robots físicos, aunque la arquitectura está planteada para facilitar esa transición en futuros desarrollos. La solución implementada incluye tres componentes principales: la capa de gestión de robots, responsable de instanciar y eliminar modelos en el simulador mediante servicios de ROS 2; la capa de interfaz de usuario, desarrollada como un panel personalizado en RViz para simplificar la configuración de misiones; y la capa de ejecución en simulación, encargada de desplegar los modelos en Gazebo y aplicarles las propiedades físicas definidas en sus descripciones. Además, se definen los mecanismos de comunicación necesarios entre las capas, garantizando que los datos introducidos por el usuario (tipo de robot, posición inicial, activación del control) se traduzcan en operaciones concretas dentro del entorno simulado. Queda fuera del alcance de este TFM la implementación de la capa de planificación y control, que se plantea como trabajo futuro. Aun así, la arquitectura está preparada para su integración gracias a la forma en la que se ha estructurado el espacio de trabajo, la modularidad en el diseño de los paquetes y la incorporación de RViz como entorno base, ya que puede integrar MoveIt de forma nativa mediante el plugin MoveIt Motion Planning. Estos elementos garantizan que, cuando se desarrolle la capa de control, pueda añadirse sin modificaciones sustanciales en el resto del sistema. 6Chapter 3 Objetivos y alcance 4 Beneficios Este TFM propone una solución flexible y escalable para la definición y ejecución de misiones robóticas con independencia del hardware y del fabricante. El diseño modular del sistema, basado en principios de abstracción y reutilización, no solo presenta ventajas desde el punto de vista técnico, sino que también genera impactos positivos en otros aspectos clave de la vida y la sociedad. A continuación, se clasifican estos beneficios según su naturaleza: 1. Beneficios tecnológicos La implementación de sistemas robóticos utilizando software de código abierto fomenta la colaboración multidisciplinar y la integración de nuevas tecnologías. El uso de estándares abiertos y formatos de descripción interoperables garantiza la compatibilidad con múltiples entornos de simulación y ejecución. Estas características favorecen el desarrollo de software más robusto, de fácil mantenimiento y portable, lo que resulta esencial para sistemas robóticos distribuidos y heterogéneos. 2. Beneficios económicos La posibilidad de tener un entorno universal que permita abstraerse de la tipología y del fabricante de los robots utilizados, conlleva una reducción de costes asociados a la formación del personal en entornos específicos. Además, eliminar la dependencia de un solo fabricante, implica flexibilidad para integrar equipos específicos que puedan optimizar el proceso o dispositivos más económicos de otros fabricantes. 3. Beneficios medioambientales Se facilita una transición tecnológica escalonada, de forma que la sustitución de equipos se pueda realizar de forma progresiva evitando desechar equipos funcionales por problemas de compatibilidad. 4. Beneficios sociales El desarrollo de un entorno de aplicación universal contribuye a ampliar el acceso a tecnologías robóticas avanzadas, especialmente para pequeñas y medianas empresas, centros educativos y organizaciones que no cuenten con grandes recursos económicos y tecnológicos. Al estandarizar y hacer más accesible la información, se fomenta la colaboración interdisciplinar y la transferencia de conocimiento entre sectores. Esto no solo promueve la innovación, sino que también ayuda a desarrollar habilidades técnicas en la sociedad en general. 7 4.1 Objetivos de Desarrollo Sostenible (ODS) Los Objetivos de Desarrollo Sostenible (ODS) son un conjunto de 17 objetivos globales definidos en 2015 por la Asamblea General de las Naciones Unidas, dentro del marco de la Agenda 2030 para el Desarrollo Sostenible. Estos objetivos buscan abordar de forma integral los grandes desafíos a los que se enfrenta la humanidad, tales como la pobreza, la desigualdad, el cambio climático, la degradación del medio ambiente, la paz y la justicia [49]. Cada ODS se compone de objetivos concretos que simplifican la gestión de políticas públicas, iniciativas sociales, investigaciones académicas y acciones individuales hacia un progreso más justo y sostenible a escala global. Este TFM contribuye al Objetivo 8 (Promover el crecimiento económico sostenido, inclusivo y sostenible, el empleo pleno y sostenible y fomentar la innovación). Esto se logra principalmente a través de los beneficios económicos y sociales que genera el entorno de aplicación universal. Al permitir la independencia del hardware de actuación, se produce una reducción de costes asociados a la formación del personal en entornos robóticos específicos. Además, al eliminar la dependencia de un solo fabricante, se facilita la transición tecnológica. Por otro lado, la democratización del acceso a la tecnología robóticas avanzadas fomenta la innovación en sectores que antes encontraban barreras de entrada debido a la complejidad y el coste. Además, el trabajo apoya el Objetivo 9 (Construir infraestructuras resilientes, promover la industrialización inclusiva y sostenible y fomentar la innovación). El desarrollo de un entorno de aplicación universal, modular, escalable y compatible con estándares abiertos, sienta las bases para una infraestructura software más resiliente para el control robótico en diversos contextos industriales y académicos. Finalmente, el TFM se alinea con el Objetivo 12 (Garantizar modalidades de consumo y producción sostenibles), principalmente a través de sus beneficios medioambientales. La solución propuesta facilita una transición ecológica escalonada. Esto significa que, en lugar de desechar equipos funcionales por problemas de compatibilidad con nuevos sistemas o software de control, las empresas puede realizar la sustitución de sus equipos de forma progresiva. Este enfoque contribuye a reducir los residuos tecnológicos. 8Chapter 4 Beneficios 5 Análisis del estado del arte 5.1 Introducción El avance de la robótica en los últimos años ha estado marcado por una creciente complejidad en los sistemas y la necesidad de diseñar arquitecturas modulares, escalables y adaptables. En este contexto, los robots modernos se conciben como sistemas ciberfísicos en los que convergen elementos de computación, comunicación y control embebido, ligados estrechamente al entorno físico en el que operan [2, 24]. Esta transición ha abierto nuevas posibilidades, pero también plantea desafíos significativos en cuanto a interoperabilidad, gestión eficiente de recursos, despliegue en entornos heterogéneos y validación a gran escala [47]. Dentro de este panorama, la robótica de enjambre ha surgido como un enfoque para la descentralización de sistemas robóticos. Este paradigma coordina múltiples robots mediante comportamientos emergentes y un código común ejecutado en cada miembro del enjambre [8, 10]. Buzz, un lenguaje de programación para enjambres de robots, permite implementar esta dinámica a través de una máquina virtual. En [44] se introduce ROSBuzz, una integración de Buzz en ROS que ofrece una solución robusta para el desarrollo de comportamientos distribuidos. Sin embargo, su principal limitación radica en que todos los robots del enjambre comparten el mismo código, lo que reduce la individualidad de los robots dentro del sistema y dificulta la implementación de control distribuido efectivo. Más allá de los enfoques específicos para enjambres, el desarrollo de sistemas robóticos heterogéneos requiere analizar las tecnologías de base que los hacen posibles. En este capítulo se abordan de forma independiente tres pilares fundamentales: las plataformas de programación de robots, los entornos virtuales de simulación y los formatos de descripción de robots. Por ello, en este capítulo se analizan de forma independiente tres pilares fundamentales en la robótica actual: las plataformas de programación de robots (Sección 5.2), los entornos virtuales de simulación (Sección 5.3) y los formatos de descripción de robots 5.4). 9 actualizada, foros de discusión, paquetes aportados por terceros y soporte activo por parte de los desarrolladores. • Licencias y coste: Tipo de licencia bajo la cual se distribuye el framework, así como su coste. Se priorizan las soluciones de código abierto que permiten el uso libre y sin restricciones. A principios de los 2000, surgieron diferentes frameworks ymiddleware robóticos impulsados por laboratorios de investigación y comunidades académicas. Entre ellos destacan Yet Another Robot Platform ( YARP ), concebido como un entorno ligero y flexible para modularidad y reutilización de código en robots humanoides [45]; Open Robot Control Software ( OROCOS ), orientado al control en tiempo real con su Real-Time Toolkit y bibliotecas de cinemática y dinámica en C++ [30]; MIRA, desarrollado en C++ para aplicaciones distribuidas con énfasis en la eficiencia de las comunicaciones y en la creación de módulos reutilizables [28]; y ORCA, que ofrece un entorno modular para la integración de sensores y actuadores en sistemas heterogéneos [29]. Fue en este contexto cuando, en 2007, se lanzó ROS , que destacó por su amplio ecosistema de bibliotecas y paquetes, convirtiéndose en el framework de referencia, aunque no fuera técnicamente superior a las alternativas existentes [14, 22]. Sin embargo, al enfrentase a demandas comerciales, comenzaron a evidenciarse sus limitaciones en seguridad, fiabilidad, capacidades en tiempo real y compatibilidad con otros sistemas [22]. Para superar estos desafíos, ROS 2 fue diseñado desde cero, adoptando el middleware DDS como base para mejorar su rendimiento en estas áreas [22, 25]. Este rediseño ha consolidado a ROS 2 no solo como framework de referencia en investigación, sino también como una solución robusta para aplicaciones comerciales modernas. El resto de plataformas no han introducido mejoras significativas en los últimos años y la comunidad investigadora ha pivotado casi por completo hacia ROS y ROS 2. En paralelo, han surgido nuevas propuestas que buscan superar algunas de las limitaciones de los frameworks clásicos. Entre ellas destaca XBot2, un middleware en tiempo real, modular y orientado a la reutilización, diseñado para garantizar robustez y escalabilidad en aplicaciones avanzadas de control robótico [21]. También se han planteado arquitecturas de nueva generación centradas en la ejecución determinista y en la reducción de latencias de comunicación, con un enfoque específico en sistemas distribuidos y heterogéneos [1]. Estas plataformas reflejan el dinamismo actual del campo, pero ninguna cuenta con la comunidad, la madurez ni el ecosistema de librerías que caracterizan a ROS 2. Por todo lo expuesto, se concluye que ROS 2 es la plataforma más adecuada para el desarrollo de este trabajo, al ser la única que combina un ecosistema amplio, soporte industrial y académico, y una comunidad activa en constante crecimiento. Una 16 Chapter 6 Análisis de alternativas vez establecida esta elección, resulta necesario seleccionar la distribución concreta de ROS 2 sobre la cual se construirá el sistema. Se escoge Humble Hawksbill por tratarse de una versión Long-Term Support ( LTS ) y ser compatible con Ubuntu 22.04 Jammy Jellyfish que también es una distribución LTS . Esta combinación garantiza un entorno estable, con mantenimiento extendido y actualizaciones aseguradas hasta abril de 2027. Además, Humble lleva más de dos años en circulación, lo que implica una documentación actualizada y madura, un amplio soporte de la comunidad, paquetes ampliamente probados y validados, mayor estabilidad respecto a versiones más recientes y una notable reducción de errores durante el desarrollo. A esto hay que añadirle la inercia en el ecosistema, que ha hecho que muchas más herramientas, librerías y recursos prioricen la compatibilidad con Humble. Existe, además, una gran cantidad de tutoriales, foros y soluciones a problemas comunes ya documentadas específicamente para esta distribución. Esto se traduce en una reducción de la pendiente de la curva de aprendizaje y de los tiempos de integración. La Figura 6.1, extraída del último análisis de rendimiento disponible de ROS , muestra que la distribución más descargada en octubre de 2024 es Humble, muy por delante de las demás distribuciones. Se observa también un amplio porcentaje de descargas de la versión Noetic por ser la última disponible de ROS 1 antes de su fin de vida el 31 de mayo de 2025. Figura 6.1: Porcentajes de descargas de las diferentes distribuciones de ROS en octubre 2024 [43]. Además, en la Figura 6.2 se observa cómo Humble continúa recibiendo un porcentaje significativo de aportaciones o commits de mantenimiento por parte del repositorio oficial de rosdistro. Este hecho refleja que se trata una versión activa y en evolución constante. 6.1 Frameworks y arquitecturas para el desarrollo de sistemas robóticos 17 Figura 6.2: Porcentaje de commits por rosdistro para el mantenimiento de las distintas distribuciones de ROS. 6.2 Entornos de simulación Teniendo en cuenta la descripción de los entornos de simulación utilizados en el campo de la robótica del Capítulo 5, se analizan los simuladores más populares en el sector para encontrar el que mejor encaje en este desarrollo. Para escoger el simulador utilizado, se tienen en cuenta los siguientes criterios, alguno de los cuales coinciden con los de la elección de la plataforma de programación de robots: • Compatibilidad con ROS 2: dado que en la sección anterior se ha establecido ROS 2 como la base de desarrollo de este trabajo, el simulador debe integrarse de forma nativa con este framework o, en su defecto, contar con puentes oficiales que garanticen la comunicación con los nodos y el resto de la infraestructura del sistema. • Fidelidad física: Se valora la precisión de los motores físicos que utiliza el simulador, así como su capacidad para representar colisiones u otras dinámicas físicas de manera realista. • Escalabilidad: El simulador debe permitir la integración de nuevos modelos, sensores, actuadores y plugins. Además, debe de ser capaz de simular múltiples robots de forma eficiente. • Comunidad y soporte: Se considera la madurez del simulador, su nivel de adopción en la comunidad, la disponibilidad de documentación actualizada, ejemplos de uso y paquetes de terceros. • Licencias y coste: Se priorizan soluciones de código abierto que no impliquen restricciones en su uso o distribución. 18 Chapter 6 Análisis de alternativas La Tabla 6.1 recoge una comparativa de los principales entornos de simulación empleados actualmente en el ámbito de la robótica, en base a los criterios mencionados y a estudios comparativos recientes [5]. Nombre Logo Motor físico Soporte Headless Código Abierto Soporte ROS2 Soporte ML Gazebo Classic Bullet, DART, ODE, Simbody Total Sí Sí Externo Gazebo Sim DART Total Sí Sí Externo Webots ODE Parcial Sí Sí Externo Isaac Sim PhysX Total No Sí Integrado Unity Havok, PhysX, RaiSim Total No No Externo PyBullet Bullet Total Sí No Externo CoppeliaSim (V-REP) Bullet, Newton, ODE, Vortex Dynamics Total No Sí Externo MuJoCo MuJoCo Total Sí No Externo Tabla 6.1: Comparativa de entornos de simulación más populares en robótica [5]. El análisis permite observar que no existe un simulador que pueda considerarse como la mejor opción en términos absolutos, sino que cada uno ofrece ventajas particulares según el tipo de aplicación. Por ejemplo, Gazebo y Webots destacan por su estabilidad y su integración consolidada en proyectos de investigación, mientras que PyBullet y CoppeliaSim presentan un consumo computacional más reducido, lo que los hace atractivos para simulaciones ligeras o pruebas rápidas. Isaac Sim y Unity, por su parte, proporcionan entornos visuales muy realistas y con integración de técnicas de aprendizaje automático, aunque a costa de un mayor consumo de recursos y con la limitación de no ser completamente de código abierto [5]. En el contexto de este trabajo, la elección del simulador está condicionada principalmente por dos factores: la compatibilidad con ROS 2 y la necesidad de soportar escenarios multirobot. Bajo estos criterios, Gazebo se presenta como la alternativa más adecuada, ya que ofrece una integración nativa con ROS 2 a través del paquete oficial ros_gz_bridge , lo que facilita una comunicación fluida entre el simulador y los nodos de ROS sin depender de soluciones externas [36]. Además, es totalmente funcional en modo headless, lo cual es esencial cuando se ejecutan múltiples robots 6.2 Entornos de simulación 19 de forma simultánea y cuenta con una comunidad activa que lo mantiene como estándar de facto en investigación [5]. La amplia disponibilidad de modelos de robots en formato URDF y SDF facilita la incorporación de nuevas plataformas al entorno. Una vez seleccionada la familia Gazebo como entorno de simulación, es necesario aclarar la evolución de sus versiones para evitar confusiones. La coexistencia de los términos Gazebo, Gazebo Classic, Ignition y Gazebo Sim ha generado cierta ambigüedad en la documentación y en la propia comunidad. Gazebo tiene su origen en 2002 y, tras 15 años de desarrollo, se impulsó una nueva línea bajo el nombre Ignition, mientras la versión original pasó a denominarse Gazebo Classic. Sin embargo, debido a cuestiones relacionadas con el uso de la marca comercial "Ignition", en 2022 se recuperó el nombre original, estableciendo como denominación oficial Gazebo, aunque en la práctica suele referirse a esta nueva generación como Gazebo Sim para distinguirla de Gazebo Classic [33]. Aunque Gazebo Classic (versión 11) ha sido históricamente el simulador de referencia para ROS 1, su soporte finalizó con la distribución Noetic, la última versión oficial de ROS 1. Gazebo Classic no es compatible para las versiones de ROS 2 posteriores a Humble, siendo reemplazado por Gazebo Sim, que se convierte en la alternativa recomendada y la seleccionada para este TFM [35]. 20 Chapter 6 Análisis de alternativas 7 Diseño y desarrollo de la solución propuesta En esta sección se describe el planteamiento, el desarrollo y la implementación para la gestión y coordinación de misiones en entornos multirobot heterogéneos. Se detalla el proceso seguido, que parte de una arquitectura modular por capas y continúa con el desarrollo de las herramientas necesarias para la configuración de las misiones: la interfaz de usuario, la preparación y el despliegue de los robots en el entorno de simulación. El flujo de trabajo se valida en un entorno simulado con Gazebo Sim, garantizando que la estructura desarrollada pueda, en futuros desarrollos, integrarse con la capa de planificación y control y ejecutarse sobre robots físicos sin modificar las capas superiores. Aunque la arquitectura propuesta contempla una capa de planificación y control para la ejecución de misiones, en la versión actual del trabajo esta parte no ha sido implementada debido a las limitaciones de tiempo y alcance del proyecto. Su desarrollo se plantea como trabajo futuro, manteniendo la estructura actual preparada para integrarla sin modificaciones sustanciales en el resto del sistema. El capítulo se organiza de forma paralela a la arquitectura planteada: primero se presenta la visión general por capas, explicadas de mayor a menor nivel, después se dedica una sección a cada capa y, por último, se aborda el despliegue completo del sistema. Aunque la arquitectura del sistema se organiza en capas de arriba hacia abajo, la explicación de cada capa sigue el orden inverso. Este enfoque facilita la lectura, ya que permite partir de los elementos más tangibles (robots y simulación) para después profundizar en las herramientas de coordinación y, finalmente, en la interacción con el usuario. 7.1 Arquitectura general del sistema El sistema propuesto se ha diseñado siguiendo un enfoque modular y por capas, con el objetivo de garantizar la escalabilidad, la reutilización de componentes y la independencia frente al hardware específico de cada robot. Este diseño responde a la necesidad de integrar en un mismo entorno funcionalidades que van desde la definición de la misión por parte del usuario hasta su ejecución en un robot físico o simulado. 21 El objetivo principal es disponer de un entorno capaz de coordinar, de forma simultánea y genérica, una flota de robots heterogénea, evitando dependencias con fabricantes, modelos o configuraciones específicas. Esto implica que cada componente de la arquitectura debe diseñarse para adaptarse fácilmente a nuevos robots y escenarios sin grandes modificaciones. Figura 7.1: Arquitectura por capas del sistema propuesto. Se propone una arquitectura organizada en cuatro capas principales 7.1: 1. Capa de interfaz de usuario Es el punto de interacción directa entre el operador y el sistema. Permite la definición y configuración de misiones de manera intuitiva y accesible. En la versión actual del sistema, la interfaz está implementada como un panel personalizado integrado en RViz, orientado a la instanciación y eliminación de robots en el entorno de simulación. La comunicación con las capas inferiores se realiza mendiante servicios de ROS 2 que envían la información introducida por el usuario (tipo de robot, posición inicial, activación o desactivación del control, etc). Aunque RViz es una herramienta capaz de mostrar en tiempo real el entorno y el estado de los robots, en la versión actual no se ha habilitado esta visualización, ya que la capa de control aún no está operativa. No obstante, el diseño de la interfaz se ha planteado para que, en futuras implementaciones, pueda habilitarse la capa de control. 22 Chapter 7 Diseño y desarrollo de la solución propuesta 2. Capa de gestión de robots Recibe las solicitudes procedentes de la interfaz con la configuración de la misión definida por el usuario y la traduce en acciones concretas sobre el entorno de ejecución. Su función principal es desplegar y configurar los robots, asignándoles identificadores únicos y vinculándolos a sus descripciones (URDF o XACRO) y parámetros cinemáticos o inerciales específicos, si es necesario. Esta capa funciona como puente entre la configuración abstracta de la misión y la representación física o simulada de los robots, considerando en todo momento que no haya conflictos en escenarios multirobot. Además, al utilizar servicios en ROS 2 que usa un modelo petición-respuesta evita tráfico innecesario. 3. Capa de planificación y control (prevista para futuras implementaciones) Aunque no se ha implementado en la versión actual, esta capa es fundamental en el diseño general. Será la responsable de recibir la misión definida y transformarla en comandos ejecutables por cada robot, teniendo en cuenta sus capacidades, limitaciones y el estado del entorno. Está previsto integrar planificadores como MoveIt para la generación de trayectorias junto con ros2_control para la ejecución modular y estandarizada de comandos en actuadores reales o simulados. La estructura actual está preparada para incorporar esta capa sin cambios sustanciales en el resto del sistema. 4. Capa de ejecución física o simulada Constituye la base del sistema y es donde se lleva a cabo la misión, ya sea en robots físicos en un entorno real o en modelos virtuales en Gazebo Sim. En la versión actual, la ejecución se limita exclusivamente al entorno de simulación, lo que permite validar las misiones en condiciones controladas y reproducibles sin riesgo para el hardware. Esta capa recibe desde la gestión de robots toda la información necesaria para crear o eliminar instancias de modelos, y se encarga de renderizarlos y simular su comportamiento físico. Figura 7.2: Estructura del sistema de archivos del espacio de trabajo. 7.1 Arquitectura general del sistema 23 El espacio de trabajo (o workspace en el lenguaje de ROS 2) se ha estructurado en distintos paquetes en función de su funcionalidad, manteniendo siempre un enfoque modular. La Figura 7.2 muestra la organización general del espacio de trabajo control_multirobot , donde los paquetes se agrupan según la capa de la arquitectura en la que participan. Así, el paquete custom_rviz_panels corresponde a la capa de interfaz de usuario; mission_management a la gestión de robots; y los paquetes robot_description y robot_gazebo , incluidos dentro de la carpeta robot_simulation , conforman la capa de ejecución física o simulada. Por su parte, robot_control queda reservado para la futura capa de planificación y control. Este esquema global refleja el carácter modular del sistema, en el que cada paquete encapsula su propia funcionalidad y puede evolucionar de manera independiente sin afectar al resto. Con el objetivo de que el sistema sea portable, todas las rutas dentro de los ficheros se han definido de forma relativa al espacio de trabajo y no como rutas absolutas. De esta manera, el sistema queda encapsulado en el espacio de trabajo. Asimismo, se ha procurado no modificar variables dentro del entorno de Linux, lo que simplifica el despliegue en otros dispositivos. En las siguientes secciones se describen en detalle cada una de las capas que conforman la arquitectura, siguiendo un orden de más alto a más bajo nivel. 7.2 Capa de ejecución física o simulada La capa de ejecución constituye la base de la arquitectura, ya que es en ella donde las misiones definidas por el usuario se llevan a cabo, ya sea en un entorno virtual o sobre robots físicos. En el contexto actual del proyecto, esta capa se implementa exclusivamente mediante Gazebo Sim, un simulador de código abierto ampliamente utilizado en robótica que ofrece un motor físico realista, renderizado 3D y compatibilidad con múltiples formatos de descripción de robots. Gazebo permite recrear con precisión el comportamiento de los robots, simulando tanto su dinámica como la interacción con el entorno. Gracias a su integración con ROS 2, la comunicación entre el simulador y el resto del sistema se hace de forma transparente, lo que permite ejecutar en simulación los mismos flujos de trabajo que, en el futuro, se desplegarán en robots reales. En la versión actual, la capa de ejecución recibe desde la capa de gestión de robots las instrucciones necesarias para instanciar o eliminar modelos en el mundo simulado. Estas instrucciones incluyen el tipo de robot, su posición inicial y si debe cargarse con control habilitado. Actualmente, la opción de control debe permanecer desactivada ya que la capa de control y planificación no está operativa. Gazebo se encarga de renderizar el modelo y aplicar las propiedades físicas definidas en su descripción. 24 Chapter 7 Diseño y desarrollo de la solución propuesta Figura 7.3: Mundo vacío en Gazebo Sim. En este trabajo, la simulación se desarrolla sobre un mundo vacío personalizado en Gazebo Sim (Figura 7.3). Este mundo está diseñado para ofrecer un entorno limpio y libre de elementos adicionales, de forma que se minimicen los recursos de cálculo. Esta consideración es clave en la simulación multirobot ya que el uso de recursos computacionales crecerá exponencialmente conforme aumente el número de robots en simulación. El archivo de definición ( custom_empty_world.sdf ) configura aspectos básicos como el plano del suelo, la iluminación y los parámetros físicos globales, sirviendo como escenario base para instanciar cualquier combinación de robots disponibles en el sistema. Dentro del espacio de trabajo, la funcionalidad de simulación se organiza en dos paquetes: robot_description , orientada a la descripción de los robots u otros modelos que puedan añadirse a la simulación en el futuro como pueden ser obstáculos y sensores (mallas, URDF / XACRO , parámetros); y robot_gazebo , orientada a Gazebo Sim de forma específica (mundos, ficheros de lanzamiento, utilidades de simulación). La carpeta robot_simulation actúa únicamente como contenedor de estos dos paquetes por motivos de organización pero no es un paquete ROS 2. 7.2.1 Descripción de los modelos Como se observa en la Figura 7.4, el paquete robot_description contiene tres carpetas principales: en config/ se encuentran los parámetros relativos a la cinemática e inercias de algunos modelos de robots disponibles; la carpeta meshes/ contiene todos los ficheros de mallas de cada uno de los eslabones de cada robot; y en la carpeta urdf/ se encuentran los ficheros de descripción de cada robot. Este paquete se construye con ament_cmake porque contiene las descripciones de los robots y no nodos ejecutables. Usar CMake garantiza que los recursos se instalen 7.2 Capa de ejecución física o simulada 25 7.3 Capa de planificación y control Aunque en la versión actual no se encuentra implementada, esta capa es fundamental en el diseño del sistema. Su función será transformar las misiones definidas en la interfaz de usuario en trayectorias y comandos ejecutables por los robots, teniendo presentes las capacidades, limitaciones y características de cada entidad en entornos multirobot. En este contexto, se prevé la integración de dos componentes clave del ecosistema ROS 2: MoveIt yros2_control. MoveIt es un conjunto de herramientas de código abierto diseñado para facilitar la planificación de movimiento, la percepción, el control y la simulación de sistemas robóticos, con especial foco en los robots manipuladores. MoveIt proporciona una interfaz unificada que abstrae la complejidad de operaciones de alto nivel como la planificación cinemática, la manipulación de objetos, la evitación de colisiones o la generación de trayectorias. A partir de una solicitud de movimiento, el sistema consulta la configuración del robot (definida en URDF y SDF ), evalúa la viabilidad del objetivo en la escena de planificación y genera una trayectoria válida utilizando motores como OMPL, CHOMP o STOMP. Una vez validada, dicha trayectoria se transmite a ros2_control para su ejecución. MoveIt se integra de forma nativa con RViz mediante el plugin MoveIt Motion Planning, que permite configurar la escena de planificación, establecer estados iniciales y objetivos de forma interactiva, probar diferentes planificadores y visualizar el resultado antes de ejecutarlo, ya sea en simulación o sobre hardware real. Esta integración facilitará, en versiones futuras, que el usuario defina misiones completas desde un mismo entorno visual. Por su parte, ros2_control es una infraestructura modular orientada a la ejecución de bajo nivel de las trayectorias planificadas. Está compuesta por tres elementos principales: las interfaces hardware, que permiten el acceso al robot físico o simulado; los controladores, que ejecutan tareas como el seguimiento de trayectorias o la regulación de velocidad; y el Control Manager, responsable de orquestar la carga, activación y actualización de dichos controladores. En el contexto de este trabajo, ros2_control será lo que permita que la ejecución de las misiones sea independiente del hardware, garantizando la portabilidad entre robots físicos y simulados sin cambios sustanciales en las capas superiores. 32 Chapter 7 Diseño y desarrollo de la solución propuesta Figura 7.11: Estructura del sistema de archivos del paquete destinado a la gestión de la misión. 7.4 Capa de gestión de robots La capa de gestión de robots actúa como puente entre la configuración de la misión definida por el usuario y los robots que deben ejecutarla. Su función es recibir las órdenes que provienen de la interfaz gráfica de usuario y traducirlas en operaciones concretas sobre los modelos en el entorno de simulación, garantizando que cada instancia de robot se configure con los parámetros adecuados para operar de forma coordinada en un escenario multirobot. La Figura 7.11 muestra cómo los principales archivos se dividen en tres directorios principales: la carpeta launch/ contiene los ficheros de lanzamiento del sistema completo y del nodo MissionManager que coordina la gestión de la misión, la carpeta scripts/ que contiene el código fuente del nodo MissionManager; y la carpeta srv/ que contiene el formato de los servicios personalizados de instanciación y eliminación de instancias. También se incluyen el fichero de compilación CMakeLists.txt y el fichero de de dependencias package.xml. 7.4 Capa de gestión de robots 33 Aunque el nodo principal está escrito en Python, el paquete define servicios personalizados ( .srv ) y requiere la generación de interfaces ROSIDL. Por ello, el paquete se construye con ament_cmake , permitiendo integrar en un mismo paquete tanto los códigos en Python como las definiciones de servicios y sus artefactos generados. 7.4.1 Servicios personalizados de ROS 2 En esta implementación, la comunicación entre la interfaz de usuario y la capa de gestión de robots se realiza mediante servicios de ROS 2. Los servicios son especialmente adecuados para tareas bajo demanda, como crear o eliminar robots de forma dinámica en el entorno o configurar ciertos parámetros de la misión sobre la marcha (on-the-fly). A diferencia de los tópicos, que siguen un patrón publicador-suscriptor con un flujo constante de datos, los servicios emplean un modelo petición-respuesta donde un nodo cliente envía una solicitud y espera una respuesta del servidor, confirmando que la operación ha sido recibida o procesada. Esto evita el uso innecesario de ancho de banda en operaciones puntuales. Cada servicio se define en un fichero .srv que incluye dos secciones: petición y respuesta, separadas por --- . En este trabajo se ha definido, dentro del paquete mission_management/srv, los servicios: •SpawnRobot.srv , para instanciar un nuevo robot en la simulación de un tipo concreto, en una posición determinada y activando el control o no. Es importante destacar que en esta primera versión del sistema, como se ha mencionado anteriormente, el control debe permanecer desactivado al no estar operativa la capa de control y planificación. •DeleteRobot.srv , para eliminar una instancia concreta identificada por su namespace. 7.4.2 Funcionamiento del nodo MissionManager El núcleo de esta capa es el nodo MissionManager, que actúa como servidor de los servicios anteriormente mencionados. Este nodo, además de gestionar las llamadas a los diferentes servicios, también lleva un registro del número de robots que se han instanciado por cada tipo y genera un namespace único para cada una de las instancias. Esta función es clave en un escenario multirobot en el que el sistema debe manejar varios robots de forma simultánea sin que haya colisiones en los tópicos. El fichero que define este nodo es mission_manager_node.py mientras que mission_manager.launch.py es el que se encarga de levantarlo. Ambos ficheros pueden encontrarse completos en el Anexo B. 34 Chapter 7 Diseño y desarrollo de la solución propuesta Cuando se solicita la incorporación de un robot a la simulación, el nodo busca el fichero de descripción correspondiente (URDF o XACRO) al tipo de robot y, en los casos que lo requieren, también añade sus parámetros cinemáticos e inerciales. A continuación, lanza el proceso que se encargará de crearlo en Gazebo, guardando el identificador del proceso para poder detenerlo más adelante si el usuario decide eliminarlo. En el caso de recibir la orden de eliminar un robot, el MissionManager se conecta con el servicio de borrado de entidades de Gazebo. Para realizar esta conexión, es necesario exponer el servicio nativo de Gazebo como servicio de ROS 2. Esto se realiza levantando un proceso llamado ros_gz_bridge al inicializar el nodo. La eliminación de una instancia, junto con todos los procesos asociados, resulta especialmente importante cuando el robot se encuentra con el control activo, ya que en ese caso se generan procesos adicionales que el proceso nativo de eliminación de entidades de Gazebo no puede detener por sí mismo. En la versión actual del sistema, en la que la capa de planificación y control aún no está implementada, estos procesos adicionales no se llegan a generar, por lo que no es necesario contemplarlos al eliminar la instancia. Este diseño facilita la escalabilidad. No es necesario realizar cambios sustanciales en el sistema cuando se quiera añadir un nuevo tipo de robot, basta con incorporar su fichero de descripción y sus parámetros cinemáticos e inerciales a los diccionarios internos si lo requiere. Además, el uso de un nodo específico que gestiona la misión, permite la incorporación de nuevos servicios más avanzados para modificar trayectorias o asignar tareas específicas a cada robot de la flota durante la ejecución. 7.5 Capa de interfaz de usuario En esta capa se encuentran las herramientas de interacción directa con el usuario, orientadas a permitir la definición y configuración de misiones robóticas de forma intuitiva y accesible. En la versión actual del sistema, la interfaz se ha implementado como un panel personalizado en RViz, desde el que se pueden instanciar (spawn) y eliminar robots en el entorno de simulación introduciendo datos como el tipo de robot, su posición inicial o la activación del control. En futuras versiones, este entorno servirá también para la definición de trayectorias o puntos de destino. La Figura 7.12 muestra el entorno de RViz con el panel personalizado integrado. RViz (ROS Visualization) es la herramienta principal de visualización 3D del ecosistema de ROS . Permite inspeccionar y depurar el estado de un sistema robótico en tiempo real mostrando modelos URDF , datos de sensores (LIDAR, cámaras RGB o de profundidad), mapas 2D/3D y trayectorias. Basado en la biblioteca Qt, RViz permite 7.5 Capa de interfaz de usuario 35 Figura 7.12: Entorno de RViz con el panel personalizado. integrar paneles y herramientas personalizadas a través de su sistema de plugins. Esta capacidad de extensión lo convierte en una pieza clave para que el usuario pueda añadir, configurar y reorganizar pantallas para visualizar la información que considere relevante. 7.5.1 Desarrollo del panel personalizado Para el desarrollo del panel se escogió C++ como lenguaje base, ya que RViz fue concebido originalmente y su soporte en ROS 2 es más maduro y estable que el disponible en Python. La implementación se realizó en un paquete independiente, custom_rviz_panels , siguiendo la estructura e indicaciones de la documentación oficial de RViz para la creación de plugins. Este paquete se compila con ament_cmake , puesto que es necesario generar la biblioteca compartida que RViz carga dinámicamente al ejecutar el sistema. La Figura 7.13 muestra la estructura de archivos del paquete. Los ficheros principales son mission_panel.hpp , que define la clase y los manejadores de la interfaz y mission_panel.cpp , que contiene la lógica de interacción con ROS 2. Ambos se complementan con el fichero de registro ( rviz_common _plugins.xml ) y con los ficheros de compilación CMakeLists.txt y package.xml . La clase base rviz_common::Panel sirve como punto de partida y el registro se 36 Chapter 7 Diseño y desarrollo de la solución propuesta Figura 7.13: Estructura del sistema de archivos del paquete destinado a la interfaz de usuario. realiza a través de pluginlib . El código completo puede consultarse en el Anexo B. 7.5.2 Funcionamiento del panel El panel se divide en dos secciones principales: en la parte superior, un formulario permite seleccionar el tipo de robot desde un menú desplegable, fijar sus coordenadas iniciales (X, Y, Z) y marcar si debe activarse la capa de control y planificación. En esta versión, dicha casilla debe permanecer desactivada para garantizar el funcionamiento correcto del sistema. Al pulsar el botón Spawn Robot, se envía una solicitud al servicio personalizado /spawn_robot, que es gestionada por el nodo MissionManager. En la parte inferior se encuentra la sección de eliminación de instancias: el usuario introduce el namespace de la instancia y pulsa Delete Robot, lo que genera una petición al servicio personalizado /delete_robot para retirar el modelo de la simulación. La Figura 7.14 muestra en detalle el panel desarrollado. 7.5 Capa de interfaz de usuario 37 Figura 7.14: Panel personalizado en RViz para la configuración de la misión. Figura 7.15: Desplegable para selección de tipo de robot en el panel de configuración de la misión. El menú desplegable incluye los cinco tipos de robots disponibles en esta primera versión del trabajo (Figura 7.15. Este menú podrá ampliarse conforme se amplíe el catálogo de ficheros de descripción en el sistema con tan solo modificar el fichero mission_panel.cpp. Para simplificar el uso, se define una configuración preestablecida ( custom_multirobot _view.rviz ) que hace que el panel aparezca cargado automáticamente al iniciar RViz, sin necesidad de añadirlo manualmente mediante Panels (Figura 7.16 y 7.17). En próximas versiones, cuando la capa de control y planificación esté operativa, este entorno podrá mostrar en tiempo real el estado de los robots, sus trayectorias y los datos relevantes de la misión. De esta manera, podrá cerrarse el ciclo entre definición, planificación y supervisión. 7.6 Despliegue del sistema completo Una vez implementadas las distintas capas de la arquitectura, es necesario proporcionar un mecanismo sencillo para lanzar el sistema en su conjunto. Con este propósito se ha creado el fichero bringup.launch.py dentro del paquete mission_management . Este fichero se encarga de orquestar el arranque de los 38 Chapter 7 Diseño y desarrollo de la solución propuesta Figura 7.16: Menú "Panels." Figura 7.17: Ventana emergente de "Add New Panel". 7.6 Despliegue del sistema completo 39 componentes principales: inicia el mundo vacío en Gazebo Sim, lanza el nodo MissionManager con sus servicios de gestión y abre RViz con la configuración necesaria para mostrar directamente el panel personalizado de usuario. Las instrucciones para el despliegue del sistema se incluyen de forma detallada en el A y el código de bringup.launch.py se incluye de forma íntegra en el Anexo B. En este capítulo se ha descrito la arquitectura por capas y su implementación en Gazebo Sim, la gestión de robots y la interfaz en RViz. El sistema puede desplegarse de forma unificada y queda preparado para integrar la capa de planificación y control. El siguiente capítulo se centra en la evaluación del rendimiento del sistema en función del número de robots simulados y en cómo las limitaciones de los recursos computacionales pueden afectar a su funcionamiento. 40 Chapter 7 Diseño y desarrollo de la solución propuesta 8 Estudio de rendimiento del sistema En este capítulo se presentan los resultados de una serie de pruebas experimentales orientadas a evaluar el impacto del número de robots simulados sobre el rendimiento computacional del sistema desarrollado. El propósito de este análisis es determinar hasta qué punto la simulación multirobot puede escalar en un equipo de cómputo convencional y cuáles son las limitaciones que aparecen antes de incorporar la capa de control y planificación. El estudio se centra en escenarios controlados en los que se varía el número de robots instanciados en un mundo vacío de Gazebo Sim, manteniendo constantes tanto el hardware empleado como la configuración de la simulación. Se monitorizan métricas clave como el RTF , que mide la relación entre el tiempo simulado y el tiempo real, junto con el consumo de CPU y el uso de memoria RAM . Estas métricas permiten cuantificar la degradación del rendimiento a medida que aumenta la complejidad del escenario. El capítulo se organiza en dos secciones principales. En primer lugar, la Sección 8.1 describe la metodología experimental seguida para la toma de datos, incluyendo el procedimiento de muestreo y los criterios de estabilización del sistema. Posteriormente, la Sección 8.2 presenta y analiza los resultados obtenidos, identificando los principales cuellos de botella y sus implicaciones para la escalabilidad del sistema y su aplicación en entornos reales. 8.1 Metodología experimental Para llevar a cabo el análisis de rendimiento, se han diseñado experimentos en los que se varía el número de robots simulados en un mismo mundo vacío de Gazebo Sim, manteniendo inalterables el hardware y los parámetros de configuración. De este modo, se garantiza que las diferencias observadas en las métricas sean atribuibles únicamente al incremento en el número de instancias. Los ensayos se han ejecutado en un equipo Dell OptiPlex 7090 con procesador Intel Core i7 y 16 GB de memoria RAM. 41 siones. Duración: 10 días. •Tarea 5: Desarrollo del entorno de simulación Creación de un mundo vacío en Gazebo Sim que sirviera como escenario base para la simulación multirobot. Se configuraron los parámetros físicos globales, la iluminación y los elementos mínimos necesarios, priorizando la optimización de recursos computacionales para permitir la ejecución de múltiples instancias de robots. Duración: 15 días. •Tarea 6: Desarrollo y validación del nodo MissionManager Implementación del nodo encargado de gestionar los servicios de instanciación y eliminación de robots en el entorno de simulación. Se incluyó la definición de servicios personalizados, la gestión de namespaces para evitar conflictos en escenarios multirobot y la integración con el servicio nativo de eliminación de entidades de Gazebo mediante el puente ros_gz_bridge. Duración: 20 días. •Tarea 7: Inclusión de nuevos robots y generalización del sistema Adaptación y validación de los ficheros de descripción de distintos modelos de robots (UR10e, XArm6, UFactory 850, ABB YuMi y KUKA LBR iiwa) para garantizar su compatibilidad con Gazebo Sim y ROS 2. Esta fase implicó un trabajo detallado de revisión de parámetros para su unificación en todos los ficheros, así como la generalización del proceso de instanciación para hacerlo independiente del tipo de robot. Duración: 25 días. •Tarea 8: Desarrollo de la interfaz de usuario Diseño e implementación de un panel personalizado en RViz para facilitar la interacción con el sistema por parte del usuario. El panel permite seleccionar el tipo de robot, su posición inicial y la activación de opciones de control, así como eliminar instancias ya creadas. Su desarrollo se basó en C++ y en la infraestructura de plugins de RViz. Duración: 10 días. •Tarea 9: Integración global y validación Unificación de todos los elementos desarrollados en un único fichero de lanzamiento que permite desplegar el sistema completo. Validación del flujo de trabajo en el entorno de simulación, comprobando que las distintas capas se integran de forma coherente y que las misiones pueden configurarse y ejecutarse correctamente. Duración: 5 días. 48 Chapter 9 Metodología •Tarea 10: Exploración de la capa de control Se realizó una primera toma de contacto con la infraestructura de ros2_control y con los conceptos básicos de MoveIt. Durante esta fase se trató de configurar ros2_control (controladores y gestor de control) sobre los modelos del sistema, ajustando las descripciones del robot y los parámetros necesarios. La funcionalidad no se incluyó en la versión final debido a problemas de integración, ya que no se logró establecer una comunicación estable de ros2_control con ROS 2. Aun así, la exploración permitió documentar requisitos, dependencias y próximos pasos para su incorporación futura. Duración: 10 días. •Tarea 11: Redacción de la memoria Redacción progresiva de la memoria del trabajo, iniciada en los primeros meses con los capítulos más teóricos y mantenida en paralelo al desarrollo. Durante el último mes la dedicación fue completa a esta tarea, centrándose en la elaboración de las secciones más técnicas, la revisión global y el formato final del documento. Duración: 120 días. 9.1 Descripción de tareas 49 9.2 Diagrama de Gantt Figura 9.1: Diagrama de Gantt. 50 Chapter 9 Metodología 10 Aspectos económicos En este capítulo se presenta el presupuesto estimado para la realización del trabajo. El cálculo se divide en tres bloques principales: los recursos humanos, el material amortizable y los costes indirectos. A partir de ellos se obtiene el coste total del proyecto. 10.1 Recursos humanos En la Tabla 10.1 se recogen los costes asociados a los recursos humanos implicados en el desarrollo del proyecto. El trabajo ha sido llevado a cabo principalmente por una ingeniera junior, con una dedicación parcial de 4 horas diarias de lunes a viernes desde septiembre de 2024 hasta agosto de 2025. Asimismo, se ha contado con la supervisión y orientación de la directora del TFM , que ha acompañado el proceso en las diferentes fases de desarrollo y redacción, asegurando el correcto seguimiento de los objetivos marcados. Trabajador Horas Coste unitario (C/h) Coste total (C) Ingeniera junior 880 30 26.400 Directora TFM 30 55 1.650 Total 28.050 Tabla 10.1: Coste asociado a los recursos humanos del proyecto. 10.2 Material amortizable El proyecto se ha desarrollado utilizando principalmente herramientas de software de código abierto, lo que reduce significativamente los costes. Sin embargo, se incluyen ciertos elementos de apoyo como suscripciones a plataformas externas, utilidades ofimáticas y hardware de uso compartido en el laboratorio. Los cálculos se han realizado proporcionalmente al uso durante la duración del TFM (Tabla 10.2). 51 Recurso Precio (C) Vida útil Uso Amortización (C) Ordenador 1.000 6 años 880 h / 6.000 h 147 Monitor 200 5 años 880 h / 6.000 h 29 The Construct 468 1 año completo 468 Microsoft 365 70 1 año completo 70 Overleaf Premium 179 1 año completo 179 Total 893 Tabla 10.2: Coste amortizable de recursos materiales y software de apoyo. 10.3 Costes indirectos Para reflejar los gastos generales derivados del uso de infraestructuras, consumo eléctrico y otros recursos no directamente imputables al proyecto, se ha aplicado un porcentaje del 8% sobre la suma de los costes de personal y material amortizable. En este caso, los costes indirectos ascienden a 2.308 C. 10.4 Coste total del proyecto Finalmente, en la Tabla 10.3 se muestra el presupuesto total estimado del trabajo, que asciende a 31.251 C. Concepto Coste (C) Recursos humanos 28.050 Material amortizable 893 Costes indirectos 2.308 Total 31.251 Tabla 10.3: Coste total del proyecto. 52 Chapter 10 Aspectos económicos 11 Conclusiones y trabajo futuro 11.1 Conclusiones El trabajo desarrollado en este TFM ha permitido verificar la viabilidad de una plataforma universal para la gestión y coordinación de misiones en entornos multirobot heterogéneos. A través de una arquitectura modular por capas, se ha conseguido integrar en un mismo entorno la configuración de misiones, el despliegue de robots y la validación en un escenario simulado. Aunque la implementación se ha limitado a la simulación mediante Gazebo Sim, los resultados obtenidos muestran que el sistema es escalable y adaptable, lo que sienta una base sólida para su futura extensión a robots físicos. Uno de los aspectos más relevantes es la incorporación de cinco tipos de robots de distinta naturaleza: ABB YuMi, KUKA LBR iiwa, UFactory XArm6, UFactory 850 y UR10e. Estos modelos no solo representan plataformas de referencia en investigación y en aplicaciones industriales, sino que incluyen robots recientemente adquiridos por el laboratorio en el que se ha desarrollado este trabajo, lo que permitirá abrir nuevas líneas de investigación en el departamento. Además, la interfaz de usuario implementada como un panel personalizado en RViz constituye otro de los elementos más destacables. Esta interfaz facilita la interacción con el sistema, permitiendo al usuario configurar misiones de forma sencilla y sin necesidad de utilizar el terminal, lo que incrementa la accesibilidad y la usabilidad del sistema. En cuanto a las limitaciones, se identifican tres aspectos principales: la ausencia de la capa de planificación y control, que no ha podido implementarse por falta de tiempo; la elevada carga computacional que conlleva la simulación de varios robots de forma simultánea, lo que puede limitar la escalabilidad práctica del sistema; y la ausencia de pruebas con robots físicos, que impide por el momento la validación de manera completa de la transición desde la simulación hacia un entorno real. En definitiva, este trabajo proporciona la base necesaria para abordar en el futuro la integración de la capa de control y planificación en entornos multirobot. La arquitectura desarrollada demuestra que es posible definir un marco común, independiente del hardware, sobre el que construir mecanismos de control avanzados capaces de gestionar de manera coordinada flotas de robots heterogéneos. 53 11.2 Trabajo futuro De cara a la continuación de este trabajo, la prioridad inmediata es la integración de la capa de planificación y control. La arquitectura ya desarrollada está preparada para ello, lo que permitirá incorporar herramientas como MoveIt y ros2_control para transformar las misiones definidas por el usuario en trayectorias ejecutables y aplicarlas sobre robots simulados o reales. Este avance será clave para que el sistema pueda coordinar flotas de robots heterogéneas de principio a fin, desde la definición de las misiones hasta su ejecución. Otro aspecto importante a abordar es la optimización del rendimiento del sistema. La simulación de múltiples robots genera una elevada carga computacional que puede comprometer la escalabilidad de la solución. Será necesario explorar mecanismos de paralelización y distribución de procesos o el despliegue en infraestructuras de mayor capacidad que permitan soportar un mayor número de robots en operación simultánea sin pérdida de rendimiento. En relación con la gestión de instancias, deberá contemplarse la correcta eliminación de los procesos relacionados con el control en el momento de borrar un robot de la simulación. En la versión actual, al no estar activa la capa de control, este problema no se presenta, pero en futuras implementaciones es fundamental garantizar que estos procesos no permanezcan activos, evitando así posibles conflictos o colisiones con el control de nuevas instancias que se generen. Asimismo, se plantea como línea de trabajo futuro la validación del sistema en robots físicos, especialmente con los disponibles en el laboratorio. Esta fase permitirá comprobar la portabilidad real de las misiones definidas en simulación y servirá para afianzar la transición entre entornos virtuales y entornos reales. Finalmente, otra dirección relevante será ampliar el catálogo de robots soportados, de modo que el sistema pueda abarcar más morfologías y escenarios de aplicación. Esto contribuirá a reforzar la versatilidad de la plataforma y consolidarla como una herramienta robusta para la investigación, la docencia o la industria en entornos multirobot heterogéneos. 54 Chapter 11 Conclusiones y trabajo futuro Bibliografía [1] Fares Abawi, Philipp Allgeuer, Di Fu, and Stefan Wermter. „Wrapyfi: A Python Wrapper for Integrating Robots, Sensors, and Applications across Multiple Middleware“. In: 2024 19th ACM/IEEE International Conference on Human-Robot Interaction (HRI). IEEE, Mar. 2024, pp. 860–864 (cit. on p. 16). [2] Mahbuba Afrin, Jiong Jin, Akhlaqur Rahman, et al. „Resource Allocation and Service Provisioning in Multi-Agent Cloud Robotics: A Comprehensive Survey“. In: IEEE Communications Surveys & Tutorials 23 (2 Apr. 2021), pp. 842–870 (cit. on p. 9). [3] Nicholas Albergo, Vivek Rathi, and John Paul Ore. „Understanding Xacro Misunderstandings“. In: Proceedings - IEEE International Conference on Robotics and Automation. Institute of Electrical and Electronics Engineers Inc., 2022, pp. 6247–6252 (cit. on pp. 13, 14). [4] Michel Albonico, Milica Ðor¯ devi´ c, Engel Hamer, and Ivano Malavolta. „Software engineering research on the Robot Operating System: A systematic mapping study“. In: Journal of Systems and Software 197 (Mar. 2023) (cit. on p. 3). [5] Florent P. Audonnet, Andrew Hamilton, and Gerardo Aragon-Camarasa. „A Systematic Comparison of Simulation Software for Robotic Arm Manipulation using ROS2“. In: 2022 22nd International Conference on Control, Automation and Systems (ICCAS). IEEE, Nov. 2022, pp. 755–762 (cit. on pp. 4, 11, 12, 14, 19, 20). [6] Andrea Bonci, Francesco Gaudeni, Maria Cristina Giannini, and Sauro Longhi. „Robot Operating System 2 (ROS2)-Based Frameworks for Increasing Robot Autonomy: A Survey“. In: Applied Sciences 13 (23 Nov. 2023), p. 12796 (cit. on pp. 3, 13). [7] Caio Camargo, José Gonçalves, Miguel Conde, et al. „Systematic literature review of realistic simulators applied in educational robotics context“. In: Sensors 21 (12 June 2021) (cit. on p. 11). [8] Liqun Chen and Siaw Lynn Ng. „Securing emergent behaviour in swarm robotics“. In: Journal of Information Security and Applications 64 (Feb. 2022) (cit. on p. 9). [9] Jack Collins, Shelvin Chand, Anthony Vanderkop, and David Howard. „A review of physics simulators for robotic applications“. In: IEEE Access 9 (2021), pp. 51416–51431 (cit. on pp. 4, 11). [10]Essam Debie, Kathryn Kasmarik, and Matt Garratt. „Swarm Robotics: A Survey from a Multi-Tasking Perspective“. In: ACM Computing Surveys 56 (2 Feb. 2023) (cit. on p. 9). [11] Ayssam Elkady and Tarek Sobh. „Robotics Middleware: A Comprehensive Literature Survey and Attribute-Based Bibliography“. In: Journal of Robotics 2012 (2012), pp. 1–15 (cit. on p. 10). 55 [12] Open Source Robotics Foundation. SDFormat. [Accedido: 4 de junio 2025]. 2020 (cit. on p. 13). [13] Muhammad Liman Gambo, Abubakar Danasabe, Basem Almadani, et al. „A Systematic Literature Review of DDS Middleware in Robotic Systems“. In: Robotics 14 (5 May 2025), p. 63 (cit. on pp. 10, 11). [14] Jesse Haviland and Peter Corke. „Robotics Software: Past, Present, and Future“. In: Annual Review of Control, Robotics, and Autonomous Systems 16 (2024), pp. 253–83 (cit. on p. 16). [15] GMI Global Market Insights. Robotic Software Market Size – By Software Type, Robot Type, Deployment Mode, Enterprise Size, End-use Industry Analysis, Share, Growth Forecast, 2025 – 2034. [Accedido: 6 de junio 2025]. 2025 (cit. on p. 3). [16] Precision Business Insights. Robot Operating System (ROS) Market Size, Share | Forecast 2031. [Accedido: 17 de junio 2025]. 2024 (cit. on p. 3). [17] Mikhail Ivanou, Stanislav Mikhel, and Sergei Savin. „Robot description formats and approaches: Review“. In: 2021 International Conference "Nonlinearity, Information and Robotics", NIR 2021. Institute of Electrical and Electronics Engineers Inc., 2021 (cit. on pp. 12–14). [18] Hasan Kivrak, Muhammed Zahid Karakusak, Simon Watson, and Barry Lennox. „Cyber–physical system architecture of autonomous robot ecosystem for industrial asset monitoring“. In: Computer Communications 218 (Mar. 2024), pp. 72–84 (cit. on pp. 3, 14). [19] Sophia Kolak, Afsoon Afzal, Claire Le Goues, Michael Hilton, and Christopher Steven Timperley. „It Takes a Village to Build a Robot: An Empirical Study of the ROS Ecosystem“. In: Proceedings - 2020 IEEE International Conference on Software Maintenance and Evolution, ICSME 2020. Institute of Electrical and Electronics Engineers Inc., Sept. 2020, pp. 430–440 (cit. on p. 10). [20]KUKA. LBR iiwa | KUKA AG. [Accedido: 25 de agosto 2025]. 2025 (cit. on pp. 29, 31). [21] Arturo Laurenzi, Davide Antonucci, Nikos G. Tsagarakis, and Luca Muratore. „The XBot2 real-time middleware for robotics“. In: Robotics and Autonomous Systems 163 (May 2023), p. 104379 (cit. on p. 16). [22] Steven Macenski, Tully Foote, Brian Gerkey, Chris Lalancette, and William Woodall. „Robot Operating System 2: Design, architecture, and uses in the wild“. In: Science Robotics 7 (66 May 2022) (cit. on pp. 3, 4, 10, 13, 16). [23] Francisco José Mañas-Álvarez, María Guinaldo, Raquel Dormido, and Sebastian DormidoCanto. „Scalability of Cyber-Physical Systems with Real and Virtual Robots in ROS 2“. In: Sensors 23 (13 July 2023) (cit. on p. 3). [24] Luca Muratore and Nikos Tsagarakis. „XBot2D: towards a robotics hybrid cloud architecture for field robotics“. In: Frontiers in Robotics and AI 10 (2023) (cit. on p. 9). [25] Jaeho Park, Raimarius Delgado, and Byoung Wook Choi. „Real-Time Characteristics of ROS 2.0 in Multiagent Robot Systems: An Empirical Study“. In: IEEE Access 8 (2020), pp. 154637–154651 (cit. on p. 16). [26] Martin Pecka. Unified Robot Description Format (URDF). [Accedido: 4 de junio 2025]. Mar. 2023 (cit. on p. 13). 56 Bibliografía [27] David Portugal, Rui P. Rocha, and João P. Castilho. „Inquiring the robot operating system community on the state of adoption of the ROS 2 robotics middleware“. In: International Journal of Intelligent Robotics and Applications (2024) (cit. on p. 4). [28] MIRA Project. MIRA Middleware for Robotic Applications. [Accedido: 5 de septiembre 2025]. 2025 (cit. on p. 16). [29] Orca Project. ORCA: Component-based Robotics Software. [Accedido: 5 de septiembre 2025]. 2025 (cit. on p. 16). [30] Orocos Project. OROCOS: Open Robot Control Software. [Accedido: 5 de septiembre 2025]. 2025 (cit. on p. 16). [31] robot-descriptions. awesome-robot-descriptions. [Accedido: 5 de septiembre de 2025]. 2025 (cit. on p. 27). [32] ABB Robotics. IRB 14000 YuMi® Dual Arm | robots | ABB. [Accedido: 25 de agosto 2025]. 2025 (cit. on pp. 29, 31). [33]Open Robotics. About - Gazebo. [Accedido: 31 de mayo 2025]. 2025 (cit. on p. 20). [34] Open Robotics. Installing Gazebo with ROS — Gazebo documentation. [Accedido: 20 de agosto 2025]. 2025 (cit. on p. 60). [35] Open Robotics. Installing Gazebo with ROS — Gazebo Fortress documentation. [Accedido: 20 de agosto 2025]. 2021 (cit. on p. 20). [36] Open Robotics. ROS 2 Integration — Gazebo Fortress documentation. [Accedido: 20 de agosto 2025]. 2021 (cit. on p. 19). [37] Open Robotics. ROS Wiki - Xacro. [Accedido: 6 de junio 2025]. Mar. 2022 (cit. on p. 13). [38] Open Robotics. Ubuntu (deb packages) — ROS 2 Documentation: Humble documentation. [Accedido: 20 de agosto 2025]. 2025 (cit. on p. 59). [39]Universal Robots. UR10e. [Accedido: 25 de agosto 2025]. 2025 (cit. on pp. 29, 30). [40] RobotShop. Brazo Robótico 850 de UFACTORY (6 Grados de Libertad) - RobotShop. [Accedido: 25 de agosto 2025]. 2025 (cit. on pp. 29, 30). [41] RobotShop. Brazo Robótico de 6 Grados de Libertad xArm - RobotShop. [Accedido: 25 de agosto 2025]. 2025 (cit. on pp. 29, 30). [42] Nirali Sanghvi, Rajdeep Niyogi, and Alfredo Milani. „Sweeping-Based Multi-Robot Exploration in an Unknown Environment Using Webots“. In: International Conference on Agents and Artificial Intelligence. Vol. 1. Science and Technology Publications, Lda, 2024, pp. 248–255 (cit. on pp. 4, 14). [43] Katherine Scott and Tully Foote. 2024 ROS Metrics Report. Tech. rep. Open Robotics, Mar. 2025 (cit. on p. 17). [44] David St-Onge, Vivek Shankar Varadharajan, Ivan Švogor, and Giovanni Beltrame. „From Design to Deployment: Decentralized Coordination of Heterogeneous Robotic Teams“. In: Frontiers in Robotics and AI 7 (May 2020) (cit. on p. 9). [45] Italian Institute of Technology. YARP: Yet Another Robot Platform. [Accedido: 5 de septiembre 2025]. 2025 (cit. on p. 16). Bibliografía 57 find_package ( ament_lint_auto REQUIRED ) # the following line skips the linter which checks for copyrights # comment the line when a copyright and license is added to all source files set(ament_cmake_copyright_FOUND TRUE) # the following line skips cpplint ( only works in a git repo ) # comment the line when this package is in a git repo and when # a copyright and license is added to all source files set(ament_cmake_cpplint_FOUND TRUE) ament_lint_auto_find_test_dependencies() endif () install( DIRECTORY urdf meshes config DESTINATION share/${PROJECT_NAME} ) ament_package () B.1.1.2 Dependencias El fichero package.xml se encarga de definir las dependencias del paquete y metadatos esencials para el sistema de construcción. <? xml version ="1.0"? > <?xml -model href =" http :// download .ros.org/ schema / package_format3 . xsd " schematypens =" http :// www. w3 .org /2001/ XMLSchema "?> <package format ="3" > <name > robot_description </ name > <version >0.0.0 </ version > <description >TODO: Package description </description > < maintainer email =" laboratorio@todo . todo "> laboratorio </ maintainer > <license > TODO: License declaration </ license > < buildtool_depend > ament_cmake </ buildtool_depend > <test_depend > ament_lint_auto </ test_depend > 64 Chapter B Código de la solución propuesta <test_depend > ament_lint_common </ test_depend > <export > <build_type >ament_cmake </ build_type > </ export > </ package > B.1.2 Paquete robot_gazebo Este paquete contiene todo el código relacionado con el entorno de Gazebo Sim. B.1.2.1 Fichero de lanzamiento para la instanciación de robots El fichero spawn_robot.launch.py se encarga de instanciar el robot del que se le envíen los datos como argumentos. #!/ usr/bin/env python3 import os import subprocess from launch import LaunchDescription from launch . actions import DeclareLaunchArgument , OpaqueFunction , TimerAction , RegisterEventHandler from launch . substitutions import Command , LaunchConfiguration , FindExecutable , PathJoinSubstitution from launch . event_handlers import OnProcessExit from launch_ros . actions import Node from launch_ros . substitutions import FindPackageShare from launch_ros . parameter_descriptions import ParameterValue from ament_index_python . packages import get_package_share_directory from controller_manager_msgs .srv import ListControllers def launch_setup ( context , *args , ** kwargs ): robot_namespace = LaunchConfiguration (" robot_namespace "). perform(context) print (f" DEBUG : robot_namespace = { robot_namespace }") robot_file = LaunchConfiguration (" robot_file "). perform ( context) robot_type = LaunchConfiguration (" robot_type ") . perform ( context) B.1 Carpeta robot_simulation 65 inertial_params_filename = LaunchConfiguration (" inertial_params_filename ") . perform ( context ) kinematics_params_filename = LaunchConfiguration (" kinematics_params_filename "). perform ( context ) x = LaunchConfiguration ("x ") . perform ( context ) y = LaunchConfiguration ("y ") . perform ( context ) z = LaunchConfiguration ("z ") . perform ( context ) with_control_str = str( LaunchConfiguration (" with_control ") .perform(context)) with_control = with_control_str . lower () == " true " # Convert string to boolean print (f "[ DEBUG ] robot_namespace : { robot_namespace }") print (f "[ DEBUG ] robot_file : { robot_file }") print (f"[ DEBUG ] x: {x}, y: {y}, z: {z}") print (" Con control :", with_control ) # Rutas pkg_path = get_package_share_directory (" robot_description ") urdf_path = os. path .join (pkg_path , " urdf ", robot_file ) print (f "[ DEBUG ] urdf_path : { urdf_path }") # Verificar si el archivo existe if not os. path .isfile ( urdf_path ): raise FileNotFoundError (f" El archivo URDF / Xacro no existe : { urdf_path }") # Ejecutar xacro si el fichero es un XACRO if robot_file . endswith (". xacro ") : cmd_list = [ " xacro ", urdf_path , f" robot_namespace :={ robot_namespace }" , f" with_control :={ ’ true ’ if with_control else ’ false ’}" ] if inertial_params_filename: cmd_list . append (f" inertial_params_filename :={ inertial_params_filename}") if kinematics_params_filename: cmd_list . append (f" kinematics_params_filename :={ kinematics_params_filename}") result = subprocess . run ( 66 Chapter B Código de la solución propuesta cmd_list, stdout = subprocess . PIPE , stderr = subprocess . PIPE , check = True , text=True ) # print ("[ DEBUG ] xacro output :\n", result . stdout ) print ("[ DEBUG ] xacro stderr :\n", result . stderr ) robot_description = ParameterValue ( result . stdout , value_type = str , ) else: # Leer URDF directamente with open ( urdf_path , ’r ’) as f: urdf_content = f. read () robot_description = ParameterValue ( urdf_content , value_type = str , ) # Nodo robot_state_publisher rsp_node = Node( package =" robot_state_publisher ", executable =" robot_state_publisher ", namespace = robot_namespace , name="robot_state_publisher", parameters =[{ "use_sim_time": True, "robot_description": robot_description }], output="screen" ) # Nodo de spawn en Gazebo spawn_node = Node ( package =" ros_gz_sim ", executable =" create ", name =f "{ robot_namespace } _spawn ", arguments =[ B.1 Carpeta robot_simulation 67 "- name ", robot_namespace , # Pasa los ficheros al nodo y se puede utilizar su valor en todos los ficheros relacionados "- topic ", f"{ robot_namespace }/ robot_description ", "-x", x, "-y", y, "-z", z, ], output="screen" ) # Spawner de controladores joint_state_broadcaster_spawner = Node( package =" controller_manager ", executable =" spawner ", namespace = robot_namespace , arguments =[" joint_state_broadcaster ", "-- controller - manager ", f "{ robot_namespace }/ controller_manager "], output="screen" ) robot_controllers = PathJoinSubstitution( [ FindPackageShare (" robot_control ") , "config", f"{ robot_type . lower ()} _controller . yaml " ] ) controller_manager_node = Node ( package =" controller_manager ", executable =" ros2_control_node ", namespace = robot_namespace , parameters =[ robot_controllers ], output =" both", remappings =[("~ robot_description ", f"{ robot_namespace }/robot_description")], ) robot_controller_spawner = Node( package =" controller_manager ", executable =" spawner ", namespace = robot_namespace , arguments =[" forward_position_controller ", "-- controller - manager ", f"{ robot_namespace }/ controller_manager "], ) 68 Chapter B Código de la solución propuesta # Delay start of joint_state_broadcaster after ‘ robot_controller ‘ # TODO ( anyone ): This is a workaround for flaky tests . Remove when fixed . delay_jsb_after_robot_controller_spawner = RegisterEventHandler( event_handler = OnProcessExit ( target_action=robot_controller_spawner , on_exit=[joint_state_broadcaster_spawner], ) ) nodes = [ rsp_node, spawn_node , ] if with_control: nodes . append ( controller_manager_node ) nodes . append ( delay_jsb_after_robot_controller_spawner ) return nodes def generate_launch_description(): return LaunchDescription([ DeclareLaunchArgument (" robot_type ", default_value ="" , description =" Tipo de robot ( uf850 , xarm6 , etc .) ") , DeclareLaunchArgument (" robot_file ", default_value ="" , description =" Archivo URDF o XACRO del robot ") , DeclareLaunchArgument (" inertial_params_filename ", default_value ="" , description =" Archivo de parametros inerciales del robot ") , DeclareLaunchArgument("kinematics_params_filename", default_value ="" , description =" Archivo de parametros cinematicos del robot ") , DeclareLaunchArgument ("x", default_value ="0.0" , description =" Posicion X del robot en Gazebo ") , DeclareLaunchArgument ("y", default_value ="0.0" , description =" Posicion Y del robot en Gazebo ") , DeclareLaunchArgument ("z", default_value ="0.0" , description =" Posicion Z del robot en Gazebo ") , DeclareLaunchArgument (" with_control ", default_value =" false ", description =" Indica si se debe cargar el controlador del robot ") , OpaqueFunction ( function = launch_setup ) ]) B.1 Carpeta robot_simulation 69 B.1.2.2 Simulación del mundo vacío El fichero custom_empty_world.sdf crea un mundo vacío personalizado en el espacio de trabajo. <? xml version ="1.0" ?> <sdf version ="1.6" > <world name =" empty "> <physics name ="1 ms" type =" ignored "> <max_step_size >0.001</max_step_size > <real_time_factor >1.0 </ real_time_factor > </ physics > <plugin filename =" ignition - gazebo - physics - system " name =" gz :: sim :: systems :: Physics "> </ plugin > <plugin filename =" ignition - gazebo -user - commands - system " name =" gz :: sim :: systems :: UserCommands "> </ plugin > <plugin filename =" ignition - gazebo - scene - broadcaster - system " name =" gz :: sim :: systems :: SceneBroadcaster "> </ plugin > <plugin filename =" ignition - gazebo - contact - system " name =" gz :: sim :: systems :: Contact "> </ plugin > <light type =" directional " name =" sun "> <cast_shadows >true</cast_shadows > <pose >0 0 10 0 0 0</ pose > <diffuse >0.8 0.8 0.8 1 </ diffuse > <specular >0.2 0.2 0.2 1</specular> <attenuation > <range >1000 </ range > <constant >0.9</constant > <linear >0.01 </ linear > <quadratic >0.001 </ quadratic > </attenuation > <direction > -0.5 0.1 -0.9 </ direction > </light > <model name =" ground_plane "> <static >true </ static > <link name="link"> <collision name =" collision "> 70 Chapter B Código de la solución propuesta <geometry> <plane> <normal >0 0 1 </ normal > <size >100 100 </ size > </plane > </geometry> </collision > <visual name =" visual "> <geometry> <plane> <normal >0 0 1 </ normal > <size >100 100 </ size > </plane > </geometry> <material> <ambient >0.8 0.8 0.8 1 </ ambient > <diffuse >0.8 0.8 0.8 1 </ diffuse > <specular >0.8 0.8 0.8 1</specular> </material> </ visual > </link > </model > </world > </sdf > Se crea además, un fichero de lanzamiento del mundo vacío llamado empty_world.launch.py . import os from ament_index_python . packages import ( get_package_prefix , get_package_share_directory) from launch import LaunchDescription from launch . actions import ( DeclareLaunchArgument , IncludeLaunchDescription) from launch . substitutions import ( PathJoinSubstitution , LaunchConfiguration) from launch.launch_description_sources import PythonLaunchDescriptionSource from launch_ros . actions import SetParameter , Node # ROS2 Launch System will look for this function definition # def generate_launch_description(): # Get Package Description and Directory # package_description = " robot_description " B.1 Carpeta robot_simulation 71 package_directory = get_package_share_directory ( package_description) # Set the Path to Robot Mesh Models for Loading in Gazebo Sim # # NOTE: Do this BEFORE launching Gazebo Sim # install_dir_path = ( get_package_prefix ( package_description ) + "/ share ") robot_meshes_path = os. path . join ( package_directory , "/ urdf /meshes") gazebo_resource_paths = [ install_dir_path , robot_meshes_path] if " IGN_GAZEBO_RESOURCE_PATH " in os. environ : for resource_path in gazebo_resource_paths : if resource_path not in os . environ [" IGN_GAZEBO_RESOURCE_PATH"]: os. environ [" IGN_GAZEBO_RESOURCE_PATH "] += (’:’ + resource_path ) else: os. environ [" IGN_GAZEBO_RESOURCE_PATH "] = (’: ’. join ( gazebo_resource_paths)) # Load Empty World SDF from Gazebo Sim Package # # world_file = " empty . sdf " world_file = os. path .join ( get_package_share_directory (" robot_gazebo ") , " worlds ", " custom_empty_world . sdf ") # world_file = os. path. join ( package_directory , " worlds / base_world . world ") world_config = LaunchConfiguration (" world ") # declare_world_arg = DeclareLaunchArgument (" world ", # default_value =[" - r ", world_file ], # description =" SDF World File ") declare_world_arg = DeclareLaunchArgument (" world ", default_value = world_file , description =" SDF World File ") # Declare GazeboSim Launch # gzsim_pkg = get_package_share_directory (" ros_gz_sim ") gz_sim = IncludeLaunchDescription( PythonLaunchDescriptionSource ( PathJoinSubstitution ([ gzsim_pkg , " launch ", " gz_sim . launch . py "]) ), 72 Chapter B Código de la solución propuesta launch_arguments ={" gz_args ": world_config }. items () , ) # Create and Return the Launch Description Object # return LaunchDescription( [ declare_world_arg , # Sets use_sim_time for all nodes started below ( doesn ’t work for nodes started from ignition gazebo) # SetParameter ( name =" use_sim_time ", value =True), gz_sim, ] ) B.2 Paquete mission_management Este paquete concentra los ficheros relacionados con la capa de gestión de robots. B.2.1 Servicios personalizados de ROS 2 B.2.1.1 SpawnRobot.srv Servicio para la instanciación de nuevos robots en simulación. El usuario introduce los datos desde la interfaz en RViz. string robot_type float64 x float64 y float64 z bool with_control --- bool success string message B.2.1.2 DeleteRobot.srv Servicio utilizado para la eliminación de la instancia seleccionada por el usuario desde la interfaz de usuario. string robot_namespace --- B.2 Paquete mission_management 73 f"[ DELETE ] Esperando a que / world / default / remove_entity e s t disponible ... ({ attempt + 1}/{max_attempts})" ) attempt += 1 if attempt >= max_attempts : self . get_logger () . error (" El servicio / world / emtpy / remove_entity no e s t disponible tras varios intentos .") response . success = False response .message = " Servicio de e l i m i n a c i n no disponible tras varios intentos ." return response req = DeleteEntity . Request () req.entity = Entity() req . entity . name = robot_namespace req. entity . type= 2 # MODEL # TODO : hacer que el nodo espere la respuesta del servicio de gazebo en lugar de asumir que lo ha borrado en 2 segundos . client . call_async ( req ) time . sleep (2) # Terminar proceso if robot_namespace in self . robot_processes : process = self . robot_processes [ robot_namespace ] process . terminate () process . wait () self . get_logger (). info (f"[ DELETE ] Proceso de { robot_namespace } terminado .") del self . robot_processes [ robot_namespace ] else: self . get_logger (). warn (f"[ DELETE ] No se encontro proceso para { robot_namespace }.") response . success = True response . message = f"Se ha eliminado la instancia { robot_namespace }." self . get_logger () .info (f "[ DELETE ] { response . message }") return response 80 Chapter B Código de la solución propuesta def main ( args = None ): rclpy . init ( args = args ) node = MissionManager() try: rclpy . spin ( node ) except KeyboardInterrupt: node . get_logger () .info (" Finalizando el nodo MissionManager.") finally: node.destroy_node() rclpy . shutdown () if __name__ == ’__main__ ’: main () B.2.4 Fichero de lanzamiento del nodo MissionManager A través de mission_manager.launch.py se lanza el nodo MissionManager. from launch import LaunchDescription from launch_ros . actions import Node from launch . substitutions import LaunchConfiguration def generate_launch_description(): return LaunchDescription([ Node( package =’ mission_management ’, executable=’mission_manager_node.py’, name =’ mission_manager ’, output="screen", arguments =[" - -ros - args ", "-- log - level ", " WARN "] # Adjust log level as needed ) ]) B.2 Paquete mission_management 81 B.3 Paquete custom_rviz_panels Este paquete contiene el código necesario para la creación del panel personalizado para la coordinación de misiones. Se toma como referencia la documentación oficial de ROS 2 Humble. B.3.1 mission_panel.cpp Este archivo contiene la lógica de ejecución para el funcionamiento del panel. # include < custom_rviz_panels / mission_panel .hpp > # include < rviz_common / display_context .hpp > # include <QVBoxLayout > # include <QHBoxLayout > # include <QComboBox > #include <QDoubleSpinBox > # include <QCheckBox > # include <QDebug > namespace custom_rviz_panels { MissionPanel :: MissionPanel ( QWidget * parent ) : Panel ( parent ) { const auto layout = new QVBoxLayout ( this ); // SERVICIO PARA SPAWN ROBOTS // Desplegable con los tipos de robots disponibles layout -> addWidget ( new QLabel (" Robot Type :")); robot_type_combo_ = new QComboBox ; robot_type_combo_ -> addItem (" uf850 "); robot_type_combo_ -> addItem (" xarm6 "); robot_type_combo_ -> addItem (" yumi "); robot_type_combo_ -> addItem (" ur10e "); robot_type_combo_ -> addItem (" iiwa_lbr "); layout -> addWidget ( robot_type_combo_ ); // S e l e c c i n de la coordenada X con QDoubleSpinBox auto x_layout = new QHBoxLayout ; x_layout -> addWidget ( new QLabel ("X:") ); x_spin_ = new QDoubleSpinBox ; x_spin_ -> setRange ( -1000.0 , 1000.0) ; x_spin_ -> setDecimals (3) ; x_spin_ -> setSingleStep (0.1) ; 82 Chapter B Código de la solución propuesta x_spin_ -> setValue (0.0) ; x_layout -> addWidget ( x_spin_ ); layout -> addLayout ( x_layout ); // S e l e c c i n de la coordenada Y con QDoubleSpinBox auto y_layout = new QHBoxLayout ; y_layout -> addWidget ( new QLabel ("Y:") ); y_spin_ = new QDoubleSpinBox ; y_spin_ -> setRange ( -1000.0 , 1000.0) ; y_spin_ -> setDecimals (3) ; y_spin_ -> setSingleStep (0.1) ; y_spin_ -> setValue (0.0) ; y_layout -> addWidget ( y_spin_ ); layout -> addLayout ( y_layout ); // S e l e c c i n de la coordenada Z con QDoubleSpinBox auto z_layout = new QHBoxLayout ; z_layout -> addWidget ( new QLabel ("Z:") ); z_spin_ = new QDoubleSpinBox ; z_spin_ -> setRange ( -1000.0 , 1000.0) ; z_spin_ -> setDecimals (3) ; z_spin_ -> setSingleStep (0.1) ; z_spin_ -> setValue (0.0) ; z_layout -> addWidget ( z_spin_ ); layout -> addLayout ( z_layout ); // Checkbox para control adicional control_checkbox_ = new QCheckBox (" With Control "); layout -> addWidget ( control_checkbox_ ); spawn_button_ = new QPushButton (" Spawn Robot "); layout -> addWidget ( spawn_button_ ); // SERVICIO PARA ELMINAR ROBOTS layout -> addWidget ( new QLabel (" Instance name :") ); delete_namespace_edit_ = new QLineEdit ; layout -> addWidget ( delete_namespace_edit_ ); delete_button_ = new QPushButton (" Delete Robot "); layout -> addWidget ( delete_button_ ); // Connect the event of when the button is released to our callback, // so pressing the button results in the callback being called. B.3 Paquete custom_rviz_panels 83 QObject :: connect (spawn_button_ , & QPushButton :: released , this , & MissionPanel :: onSpawnClicked ); QObject :: connect (delete_button_ , & QPushButton :: released , this , & MissionPanel :: onDeleteClicked ); } MissionPanel::~MissionPanel() = default; void MissionPanel::onInitialize() { // Access the abstract ROS Node and // in the process lock it for exclusive use until the method is done . node_ptr_ = getDisplayContext () -> getRosNodeAbstraction () . lock (); // Get a pointer to the familiar rclcpp :: Node for making subscriptions / publishers // (as per normal rclcpp code ) rclcpp :: Node :: SharedPtr node = node_ptr_ -> get_raw_node (); publisher_ = node -> create_publisher < std_msgs :: msg :: String >("/ output ", 10) ; subscription_ = node -> create_subscription < std_msgs :: msg :: String >( "/ input ", 10, std :: bind (& MissionPanel :: topicCallback , this , std :: placeholders ::_1)); // Crear los service clients spawn_client_ = node -> create_client < mission_management :: srv :: SpawnRobot >("/ spawn_robot "); delete_client_ = node -> create_client < mission_management :: srv :: DeleteRobot >("/ delete_robot "); } // When the subscriber gets a message , this callback is triggered , // and then we copy its data into the widget ’s label void MissionPanel :: topicCallback ( const std_msgs :: msg :: String & msg) { label_ -> setText ( QString ( msg . data . c_str () )); } // When the widget ’s button is pressed , this callback is triggered , // and then we publish a new message on our topic . 84 Chapter B Código de la solución propuesta void MissionPanel :: buttonActivated () { auto message = std_msgs :: msg :: String (); message . data = "[ MissionPanel ] Button clicked !"; publisher_ -> publish ( message ); qDebug () << "[ MissionPanel ] GO! button clicked "; } void MissionPanel :: onSpawnClicked () { qDebug () << "[ MissionPanel ] Spawn clicked !"; if (! spawn_client_ -> wait_for_service (std :: chrono :: seconds (2) )) { qDebug () << "[ MissionPanel ] Spawn service not available !"; return; } auto request = std :: make_shared < mission_management :: srv :: SpawnRobot :: Request >(); // request -> robot_namespace = ""; // V a c o para que mission_manager lo autogenere request -> robot_type = robot_type_combo_ -> currentText () . toStdString (); request ->x = x_spin_ -> value (); request ->y = y_spin_ -> value (); request ->z = z_spin_ -> value (); request -> with_control = control_checkbox_ -> isChecked () ; this -> spawn_future_ = this -> spawn_client_ -> async_send_request ( request ). future . share () ; rclcpp :: Node :: SharedPtr node = this -> node_ptr_ -> get_raw_node (); this -> spawn_check_timer_ = node -> create_wall_timer ( std :: chrono :: milliseconds (100) , [this ]() { if (this -> spawn_future_ . valid () && this -> spawn_future_ . wait_for ( std :: chrono :: seconds (0) ) == std :: future_status :: ready ) { auto result = this -> spawn_future_ . get (); qDebug () << "[ MissionPanel ] Spawn result :" << QString :: fromStdString ( result -> message ); this -> spawn_check_timer_ -> cancel () ; } } B.3 Paquete custom_rviz_panels 85 ); } void MissionPanel :: onDeleteClicked () { qDebug () << " Delete clicked !"; // qDebug () << "Robot Type :" << robot_type_combo_ -> currentText (); if (! delete_client_ -> wait_for_service (std :: chrono :: seconds (2))) { qDebug () << "[ MissionPanel ] Delete service not available !"; return; } auto request = std :: make_shared < mission_management :: srv :: DeleteRobot :: Request >() ; request -> robot_namespace = delete_namespace_edit_ -> text (). toStdString (); this -> delete_future_ = this -> delete_client_ -> async_send_request ( request ). future . share () ; rclcpp :: Node :: SharedPtr node = this -> node_ptr_ -> get_raw_node (); this -> delete_check_timer_ = node -> create_wall_timer ( std :: chrono :: milliseconds (100) , [this ]() { if (this -> delete_future_ . valid () && this -> delete_future_ . wait_for ( std :: chrono :: seconds (0) ) == std :: future_status :: ready ) { auto result = this -> delete_future_ . get (); qDebug () << "[ MissionPanel ] Delete result :" << QString :: fromStdString ( result -> message ); this -> delete_check_timer_ -> cancel () ; } } ); } } // namespace custom_rviz_panels # include < pluginlib / class_list_macros .hpp > PLUGINLIB_EXPORT_CLASS ( custom_rviz_panels :: MissionPanel , rviz_common :: Panel ) 86 Chapter B Código de la solución propuesta B.3.2 mission_panel.hpp Este archivo define la clase y los manejadores (handlers) para la interacción con la interfaz gráfica y el sistema de ROS 2. #ifndef CUSTOM_RVIZ_PANELS__MISSION_PANEL_HPP_ #define CUSTOM_RVIZ_PANELS__MISSION_PANEL_HPP_ # include < rviz_common / panel .hpp > # include < rviz_common / ros_integration / ros_node_abstraction_iface.hpp> # include < std_msgs / msg / string . hpp > # include <QLabel > # include <QPushButton > # include <QLineEdit > # include <QComboBox > # include <QCheckBox > #include <QDoubleSpinBox > # include " mission_management / srv / spawn_robot .hpp" # include " mission_management / srv / delete_robot . hpp " namespace custom_rviz_panels { class MissionPanel : public rviz_common :: Panel { Q_OBJECT public: explicit MissionPanel ( QWidget * parent =0) ; ~ MissionPanel () override ; void onInitialize () override ; protected : std :: shared_ptr < rviz_common :: ros_integration :: RosNodeAbstractionIface > node_ptr_ ; rclcpp :: Publisher < std_msgs :: msg :: String >:: SharedPtr publisher_ ; rclcpp :: Subscription < std_msgs :: msg :: String >:: SharedPtr subscription_ ; void topicCallback ( const std_msgs :: msg :: String & msg ); // Del Tutorial B.3 Paquete custom_rviz_panels 87 QLabel * label_; QPushButton * button_ ; // De mi nuevo panel QComboBox * robot_type_combo_ ; QDoubleSpinBox * x_spin_; QDoubleSpinBox * y_spin_; QDoubleSpinBox * z_spin_; QCheckBox * control_checkbox_ ; QPushButton * spawn_button_ ; QPushButton * delete_button_ ; QLineEdit * delete_namespace_edit_ ; // Para el control a s n c r o n o de llamadas de servicio rclcpp :: Client < mission_management :: srv :: SpawnRobot >:: SharedFuture spawn_future_; rclcpp :: Client < mission_management :: srv :: DeleteRobot >:: SharedFuture delete_future_ ; // Timers para esperar el resultado de la llamada rclcpp :: TimerBase :: SharedPtr spawn_check_timer_ ; rclcpp :: TimerBase :: SharedPtr delete_check_timer_ ; rclcpp :: Client < mission_management :: srv :: SpawnRobot >:: SharedPtr spawn_client_ ; rclcpp :: Client < mission_management :: srv :: DeleteRobot >:: SharedPtr delete_client_; private Q_SLOTS: void buttonActivated (); void onSpawnClicked(); void onDeleteClicked (); }; } // namespace custom_rviz_panels #endif // CUSTOM_RVIZ_PANELS__MISSION_PANEL_HPP_ B.3.3 Fichero de descripción del plugin Se añade el archivo rviz_commmon_plugins.xml con código estándar pluginlib. La clase tiene que coincidir con la invocación de PLUGINLIB del mission_panel.cpp . <library path =" mission_panel "> <class type =" custom_rviz_panels :: MissionPanel " base_class_type =" rviz_common :: Panel "> 88 Chapter B Código de la solución propuesta <description > RViz panel for mission management </ description > </class > </ library > B.3 Paquete custom_rviz_panels 89