Robotica de Enjambre Aplicacion A Logistica de Almacen Cerdan Amat Marcos

Escuela
Politécnica
Superior
Robótica de enjambre.
Aplicación a logística
de almacén.
Grado en Ingeniería Informática
Trabajo Fin de Grado
Autor:
Marcos Cerdán Amat
Tutor/es:
Fidel Aznar Gregori
Robótica de enjambre. Aplicación a
logística de almacén.
Autor
Marcos Cerdán Amat
Tutor/es
Fidel Aznar Gregori
CIENCIA DE LA COMPUTACION E INT. ARTIF.
Grado en Ingeniería Informática
Escuela
Politécnica
Superior
ALICANTE, Julio 2023

Justifiación y objetivos
Son varios los motivos por los cuales he elegido un trabajo relacionado con el campo de la
robótica siendo mi campo la ingeniería informática. Uno de ellos y el más importante es la
curiosidad por conocer y comprender cómo funcionan por dentro los sistemas de un robot y
han evolucionado a lo largo del tiempo. Más allá de mi interés por los avances en robótica,
también quería dar un primer paso e investigar por mi cuenta las distintas salidas que ofrece
este mundo, pues más adelante quiero hacer el máster de robótica y esta propuesta me ha
parecido una buena primera toma de contacto con el sector.
El objetivo principal de este trabajo es crear y desarrollar una red de robots de forma
distribuida, es decir, que estos no dependan de ningún servicio central para poder desempeñar
sus funciones. Una arquitectura distribuida significa también implementar algoritmos que
coordinen el trabajo de todos los robots de forma que puedan comunicarse con el resto del
enjambre. He leído y revisado literatura relacionada, como la creación de feromonas artificiales
para simular el comportamiento de un enjambre de hormigas Na y cols.(2021-08-01).
Por último, para la realización de pruebas y experimentos, he usado el simulador Webots.
Este simulador me ha proporcionado diferentes herramientas para poder crear escenarios con
robots. Más adelante hablaré más en profundidad sobre este simulador, las ventajas que tiene
frente a otros simuladores, algunos conceptos básicos para la creación de robots, los diversos
problemas que he tenido y cómo los he solucionado.
v
Agradecimientos
Agradecer a mi tutor Fidel por sus rápidas respuestas, por su paciencia para explicar las
cosas que desconocía y por su triple acierto a la hora de recomendar Python, Webots y RPYC.
Sinceramente me he encontrado muy cómodo trabajando con estas herramientas.
A mi familia, amigos y novia, los cuales me han escuchado cuando les contaba cómo avan-
zaba mi proyecto, las dificultas que iba encontrando y los resultados. Uno no sabe la suerte
que tiene de estar rodeado de personas que se interesan por tu día a día.
Agradecer a todos esos profesores que se esfuerzan por dar una enseñanza de calidad, a
todos esos docentes que se enfrentan año tras año a la misma asignatura y no pierden el
interés e inspiran a generaciones enteras a elegir su futuro.
vii
Índice general
Justifiación y objetivos v
Agradecimientos vii
1. Introducción 1
2. Estado del arte 3

2.1. Introducción a la robótica de enjambre . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Arquitecturas alternativas al enjambre . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Diferencias entre arquitecturas . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Aplicaciones dentro de la robótica de enjambre . . . . . . . . . . . . . . . . . 8
2.4.1. Técnicas habituales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2. Proyectos e iniciativas reales aplicadas al sector . . . . . . . . . . . . . 10
3. Objetivos 13
3.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Simulaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Propósito del enjambre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Metodología 19
5. Desarrollo 21
5.1. Simuladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Webots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.1. Creación de un mundo . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2. Modificación del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.3. Mecánicas para la construcción de objetos complejos . . . . . . . . . . 28
5.2.3.1. Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.3.2. Estructura en forma de árbol . . . . . . . . . . . . . . . . . . 29
5.2.3.3. Define-Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
ix
x Índice general
5.2.4. Diseño y construcción de un robot . . . . . . . . . . . . . . . . . . . . 32

5.2.5. El objeto PROTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.6. Robot Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Programación del robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1. Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.2. API de Webots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.3. Main Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.4. Código del robot supervisor . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4. Comunicación entre robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4.1. RPYC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4.2. Atributos de clase vs atributos de instancia . . . . . . . . . . . . . . . 50
5.4.3. RPYC en Webots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5. Demo simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.5.1. Objetivo y estructura del enjambre . . . . . . . . . . . . . . . . . . . . 51
5.5.2. Mapa de la simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5.3. Robots de la simulación . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5.3.1. Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.5.3.2. Robot buscador . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.5.3.3. Robot sigue líneas . . . . . . . . . . . . . . . . . . . . . . . . 62
6. Resultados 67
6.1. Demo final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2. Trazas y capturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2.1. Algoritmo de selección anillo . . . . . . . . . . . . . . . . . . . . . . . 68
6.2.2. Comunicaciones en robots buscadores . . . . . . . . . . . . . . . . . . 70
6.2.3. Comunicaciones en robots sigue líneas . . . . . . . . . . . . . . . . . . 74
6.3. Métricas de escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3.1. 2 Robots buscadores - 2 Robots sigue líneas . . . . . . . . . . . . . . . 79
Índice general xi

6.3.6. Resultados obtenidos en las pruebas . . . . . . . . . . . . . . . . . . . 83
7. Conclusiones 85
Bibliografía 89
A. Código API Webots 91
B. Código RPYC 95
C. Códigos generales y enlaces de resultados 99

Índice de figuras
5.1. Mundo inicial Webots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2. Parámetros de un nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Estructura en forma de árbol de un objeto . . . . . . . . . . . . . . . . . . . . 30
5.4. Mecanismo DEF-USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5. Sólido con colisiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6. Creación de un robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.7. Estructura árbol del robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.8. Robot base con sensores y cámara . . . . . . . . . . . . . . . . . . . . . . . . 34
5.9. Gráfica de valores medidos de un sensore en función de la distancia . . . . . . 35
5.10. Cámara reconociendo un objeto con recognitionColors . . . . . . . . . . . . . 36
5.11. Robots incluidos por defecto en Webots . . . . . . . . . . . . . . . . . . . . . 37
5.12. Objeto PROTO de un robot E-Puck . . . . . . . . . . . . . . . . . . . . . . . 38
5.13. Flujo de control de Webots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.14. Mapa demo simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.15. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.16. Diagrama clases robot supervisor . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.17. Robot buscador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.18. Estados robot buscador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.19. Diagrama de clases robot buscador . . . . . . . . . . . . . . . . . . . . . . . . 61
5.20. Robot sigue líneas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.21. Estados robot sigue líneas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.22. Diagrama de clases robot sigue líneas . . . . . . . . . . . . . . . . . . . . . . . 66
6.1. Estado inicial vídeo simulación . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2. Traza algoritmo selección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3. Estado inicial situación 1 buscadores . . . . . . . . . . . . . . . . . . . . . . . 70
6.4. Estado final situación 1 buscadores . . . . . . . . . . . . . . . . . . . . . . . . 71
xiii
xiv Índice de figuras
6.5. Estado inicial situación 2 buscadores . . . . . . . . . . . . . . . . . . . . . . . 72

6.6. Estado final situación 2 buscadores . . . . . . . . . . . . . . . . . . . . . . . . 73
6.7. Estado inicial situación 1 sigue líneas . . . . . . . . . . . . . . . . . . . . . . . 74
6.8. Estado final situación 1 sigue líneas . . . . . . . . . . . . . . . . . . . . . . . . 75
6.9. Estado inicial situación 2 sigue líneas . . . . . . . . . . . . . . . . . . . . . . . 76
6.10. Estado final situación 2 sigue líneas . . . . . . . . . . . . . . . . . . . . . . . . 77
6.11. Robot 6 esperando a que el robot 5 libere la zona de descarga . . . . . . . . . 78
6.12. Robot 4 esperando a que el robot 6 libere la zona de descarga . . . . . . . . . 78
6.13. Estado inicial prueba 2-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.14. Estado final prueba 2-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.20. Estado intermedio prueba 4-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Índice de cuadros
4.1. Etapas del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Frecuencia de aparición en búsquedas de simuladores . . . . . . . . . . . . . . 22
6.1. Tabla tiempos finales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
xv
Capítulo 1
Introducción
La robótica de enjambre es un área de investigación centrada en estudiar comportamientos

que se dan en la naturaleza para poder llevarlos al área de la robótica. Es importante destacar
que dentro de este área hay muchas ramas científicas que juegan un papel importante:
• Empezando por lo más bajo, tenemos la propia rama de la biología encargada de des-
cifrar los patrones que siguen diferentes insectos para ser capaces de comunicarse entre
ellos. Gracias a diferentes estudios Garnier y cols.(2007-06-01), somos capaces de com-
prender las diferentes formas que tienen estos insectos para llevar a cabo tareas de forma
organizada. Lo más importante a destacar aquí es que estamos investigando mecanismos
de comunicación fuera de lo convencional.
• En la capa intermedia, encontramos los algoritmos e implementaciones informáticas

para trasladar estos comportamientos a código. Aquí es donde usaré todo lo que he
aprendido a lo largo de la carrera, desde la propia programación hasta diferentes me-
canismos de visión por computador. Recalcar también la importancia del aprendizaje
sobre redes y sistemas distribuidos.
• Por último, la capa donde convergen el hardware y el software. Nos encontramos ya

con el propio conjunto de robots programados y listos para realizar una tarea de forma
coordinada. El propio acto de realizar la tarea, a pesar de ser importante, no es lo
principal, puesto que lo que estamos estudiando en este trabajo es la capacidad de
que ese conjunto de robots estén sincronizados, que sean tolerantes a fallos, la rápida
resolución de esos fallos y que una fallo en un robot no afecte al resto del enjambre (de
ahí la importancia de las arquitecturas distribuidas)
A medida que los campos de la robótica e informática avanzan, la capacidad de usar

enjambres de robots se vuelve más viable ya que problemas como la capacidad de cómputo,
1
2 Introducción
el ancho de banda para enviar información o las propias limitaciones de los robots cada vez
son menores. Tenemos ejemplos actuales de enjambres de robots en los almacenes de Amazon,
donde podemos ver cómo un conjunto de robots es capaz de clasificar las diferentes mercancías
de forma coordinada. Esta tecnología se puede aplicar a otros sectores como la agricultura,
la exploración o cualquier tarea que precise la búsqueda de un elemento.
Además, otro aspecto importante a tener en cuenta para el desarrollo de un enjambre
de robots es la propia incertidumbre del entorno, pues tendremos que tener en cuenta la
variabilidad del terreno, las capacidades del hardware o los posibles errores que surjan en un
entorno real.
Mediante el desarrollo de este TFG, no solo se pretende el estudio teórico del conocimiento
actual sobre la robótica de enjambre, sino llevar a cabo simulaciones donde se puedan evaluar
las diferentes soluciones propuestas.
En resumen, siendo conscientes de los conocimientos necesarios para abarcar un campo
tan amplio como la robótica de enjambre, se pretende establecer una red de robots de forma
distribuida sin dejar de lado otras materias como el propio propósito del enjambre.
Capítulo 2
Estado del arte
2.1 Introducción a la robótica de enjambre
Para conocer un poco más de qué trata esta rama y algunas de sus diferentes investigaciones,
voy a introducir qué es exactamente la robótica de enjambre y algunos de sus métodos y
técnicas habituales.
Según Arnold y cols.(2019-10), la robótica de enjambre se define como, cito textualmente:

”Swarm robotics has been defined as an approach to the coordination of multiple
robots as a system which consist of large numbers of mostly simple physical
robots”, aunque con el paso del tiempo y la evolución de la materia esta definición no es
del todo precisa. No es necesario que un enjambre esté conformado solo por robots simples,
dependiendo de la escala del problema y del nivel de dificultad, será necesario agregar nuevos
robots de mayor complejidad. Tampoco es necesario disponer de una gran cantidad de robots,
ya que con un grupo mayor de 3 robots sería suficiente. Lo que caracteriza a un enjambre
frente a otro tipo de sistemas multi-robot se sostiene sobre 3 pilares fundamentales:
1. Tamaño del enjambre: Como ya se ha dicho, el enjambre puede ir desde 3 hasta cientos
de robots.
2. Control Humano: Se debe limitar al máximo la interacción humana dentro del enjambre.
Se puede permitir hasta una persona supervisando el enjambre.
3. Cooperación: Los robots no compiten por los recursos ni trabajan de forma aislada,
sino que cooperan entre sí para completar esta.
3
4 Estado del arte
2.2 Arquitecturas alternativas al enjambre
Actualmente existen otro tipo de sistemas o arquitecturas para implementar un conjunto

de robots o entidades que colaboren entre sí, cada una con sus diferentes características que
las definen. A pesar de sus semejanzas, se establecen ciertas diferencias Arnold y cols. (2019-
10) para saber clasificar con qué arquitectura estamos trabajando y para qué casos es más
conveniente usar unas frente a otras. Entre otros sistemas que implementan interacciones
entre sus componentes como lo hace la robótica de enjambre, los más famosos son:
• Sistemas multi-robot
Los sistemas multi-robot clásicos se caracterizan por tener una tendencia más centrali-
zada. Un solo robot o servidor coordina al resto siendo este es que toma las decisiones,
además de asignar las tareas al resto de robots. El coordinador será siempre el mis-
mo nodo, no siendo posible que otros nodos tomen el papel de coordinador. Además, la
comunicación puede ser tanto entre robot-robot como robot-coordinador. Suelen ser sis-
temas cerrados a cambios, donde la escalabilidad no es importante y se prioriza invertir
en una infraestructura estática frente a una dinámica.
• Red de sensores
Compuesta por sensores simples, no se llegan a integrar en ningún momento los robots.
Estos sensores transmiten y recogen información que será enviada a una unidad central.
Los sensores se mantienen fijos en posiciones establecidas, por lo que no pueden realizar
acciones físicas. A pesar de ser una arquitectura que coordina diferentes elementos, esta
es usada para la monitorización, no tanto para el cumplimiento de tareas.
• Sistemas multi-agente
Consiste en un sistema formado por diferentes entidades autónomas que cooperan entre
ellas para lograr un objetivo común. Estas entidades pueden colaborar de manera cen-
tralizada en una sola máquina o puede construirse sobre una base distribuida. Aunque
es posible que dentro de esta red se puedan incluir robots, no necesariamente deben
serlo, puesto que podemos agregar elementos como un servidor. Estos sistemas se im-
plementan para casos más genéricos donde podemos incluir módulos de diferentes tipos.
2.3. Diferencias entre arquitecturas 5
2.3 Diferencias entre arquitecturas
Para añadir contexto a la información que he descrito, explicaré las diferencias de estas
arquitecturas frente a la de enjambre. Con esto, lo que pretendo es mostrar en qué casos es
mejor aplicar la tecnología de enjambre, los pros y contras encontrados y las características
que separan a esta del resto de arquitecturas.
• Sistemas multi-robot
En primer lugar, hemos hablado de los sistemas multi-robot. Esta es la estructura que
más se asemeja a la de enjambre, ya que ambas están relacionadas con el ámbito de
la robótica y ambas comparten unas bases similares. La principal diferencia es que en
las multi-robot, se suelen encontrar estructuras jerárquicas, donde se pre-asignan roles
de prioridad a robots para que estos tengan más control frente a otros robots. Aunque
ambas tecnologías enfaticen en el cumplimiento de tareas mediante la colaboración,
las reglas que rigen la colaboración en las multi-robot ya están definidas de antemano
(el robot A se comunicará con el robot B), mientras que en las de enjambre no nece-
sariamente tendremos que especificar estas relaciones, puesto que el comportamiento
programado ya implica cualquier comunicación con cualquier otro robot. Aunque in-
cluir comunicaciones predeterminadas en el enjambre no lo descalifica como enjambre,
se priorizan la interacción espontánea frente a estas.
Otra de las grandes diferencias entre estos es que a menudo, en el multi-robot, se em-
plean patrones más centralizados donde existe una figura autoritaria que controla todo
el enjambre, siendo la que asigna las tareas y gestiona los recursos. Un inconveniente de
esto es que si esta unidad sufre algún fallo, es difícil relegar esta autoridad a otro robot.
Sin embargo, en las de enjambre, al descentralizar este proceso, cada robot está pro-
gramado para decidir su propia tarea. Más adelante veremos cómo se ha implementado
un coordinador en el enjambre de manera que no rompa con esta descentralización.
Por último, un factor clave que resalta frente al multi-robot es la escalabilidad. Los
sistemas multi-robot generalmente se trabaja con un número limitado de robots. Es
importante saber de cuántos robots disponemos antes de comenzar a trabajar en una
tarea. Sin embargo, en el enjambre disfrutamos de una escalabilidad ilimitada, puesto
6 Estado del arte
que unos robots no dependen de otros, dando así la posibilidad de quitar o añadir robots
al enjambre sin sufrir alteraciones en el comportamiento de este.
En resumen, para casos donde el escenario se haya estudiado previamente y se hayan

establecido unos requisitos fijos o estáticos, el sistema multi-robot sería más conveniente
frente al enjambre. Mientras no existan alteraciones en el escenario o en el grupo de
robots, ofrecerá una mayor estabilidad a nivel de rendimiento. Por otro lado, si nos
encontramos con una situación donde desconocemos el escenario y prevemos futuros
cambios, el enjambre sería una opción más correcta.
• Red de sensores
Aun siendo conceptos relacionados, la red de sensores y la robótica de enjambre son

arquitecturas diferentes. Mientras que la naturaleza general de la red de sensores está
constituida por los propios sensores que recopilan los datos, en la robótica de enjambre
los participantes son los propios robots. A su vez, estos robots tienen como propósito
el cumplimiento de una tarea física, esto no ocurre en la red de sensores, donde el
objetivo es recopilar una serie de información que más tarde será analizada en otro
dispositivo. Por otra parte, la manera más típica de implementar estos sensores es de
forma centralizada con un dispositivo central recibiendo todos los datos.
Aunque estas dos arquitecturas a primera vista parezca que no comparten similitudes,
la red de sensores se puede interpretar como un conjunto de módulos que cooperan
para recoger información del entorno. Si elevamos esta interpretación a un nivel mayor,
es posible combinar sensores con enjambre para desarrollar diferentes funcionalidades
dentro del propio enjambre. Pongamos como ejemplo que queremos que nuestro enjam-
bre, a parte de cumplir con una determinada tarea, mida al mismo tiempo los niveles
de alguna sustancia peligrosa en el ambiente. Una posible solución para ello es imple-
mentar una capa extra sobre el enjambre donde se realicen las mediciones al mismo
tiempo que se realiza otra tarea. No necesariamente deben acoplarse estas capas, por
lo que el éxito del enjambre no está regido por el éxito de la red de sensores.
• Sistemas multi-agente
Al igual que pasa con la red de sensores, los sistemas multi-agente y la robótica de
2.3. Diferencias entre arquitecturas 7
enjambre son dos enfoques diferentes para abordar problemas complejos. En los siste-
mas multi-agente se denomina como agente a una entidad autónoma que coopera con
otras entidades para la resolución de una tarea. Ambos incorporan una naturaleza des-
centralizada y comportamientos inteligentes, usando técnicas para dividir la lógica del
problema en problemas más pequeños.
Si bien es verdad que estas dos arquitecturas hacen uso de entidades autónomas y la
cooperación entre estas, los sistemas multi-agente son usados frecuentemente para la
resolución de problemas como el tráfico de redes, mientras que la robótica de enjambre
concierne otros problemas diferentes, como la búsqueda de objetos o el reconocimiento
de campo.
En cierto modo, la robótica de enjambre podría considerarse como una funcionalidad

específica dentro de un sistema multi-agente puesto que estas dos nacen de la misma
base. Es por ello que decir que la robótica de enjambre es una aplicación de un sistema
multi-agente no sería incorrecto, concretando diferentes matices.
8 Estado del arte
2.4 Aplicaciones dentro de la robótica de enjambre
Ahora que ya conocemos el transfondo de la robótica de enjambre, voy a hablar de algunas

aplicaciones y proyectos. Esencialmente, esta tecnología ha sido usada mayoritariamente en
el sector de la industria Schranz y cols.(2020 debido a su amplio abanico de aplicaciones
enfocadas a la navegación, organización espacial y toma de decisiones. A pesar de esto, la
industria no ha llegado a evolucionar suficientemente para incluir explotar del todo esta
tecnología. A día de hoy, se siguen prefiriendo alternativas centralizadas, pues un contexto
industrial, la naturaleza implícita de la robótica de enjambre dice que la interacción entre los
robots debe surgir de manera local, es decir, no debemos programar estos comportamientos de
manera ”artificial”. Esto puede resultar difícil de predecir, lo que genera incertidumbre dentro
de este sector donde se prima la seguridad con escenarios deterministas. Por otro lado, las
infraestructuras actuales de comunicación no tienen una alternativa descentralizada, por lo
que se acaba optando por soluciones convencionales de carácter centralizado. Por último,
realizar pruebas en estos entornos industriales podría ser peligroso y, a su vez, es posible que
los simuladores no sean suficientemente realistas para dar un nivel de realismo suficiente.
Es por todos estos motivos que la robótica de enjambre es un área emergente pero todavía
en desarrollo, siendo posible que en un futuro, con los avances actuales, se alcancen los
estándares que se piden para poder ser integrados en la industria convencional.
2.4.1 Técnicas habituales
Para implementar ciertas funcionalidades que caracterizan al enjambre, se usan diferentes

técnicas que permiten simular el comportamiento de un enjambre. Todas estas funcionalidades
en conjunto son las que otorgarán a cada robot la etiqueta de autónomo, al mismo tiempo
que le permitirán a este interactuar localmente con el resto del enjambre.
Dentro de los comportamientos estudiados, podemos encontrar:
• Posicionamiento y localización del robot
Para que un robot pueda reconocer el sitio en el que se encuentra, solo existe una forma,
creando un registro del entorno e ir almacenándolo en un mapa virtual (actualmente el
uso de GPS u otras herramientas de geolocalización no son lo suficientemente exactas
2.4. Aplicaciones dentro de la robótica de enjambre 9
para poder ser integradas como mecanismo de posicionamiento). Para implementar este
mapa virtual se utiliza una técnica llamada SLAM (simultaneous localization and map-
ping), la cual consiste en almacenar la topología del terreno en un mapa virtual. Esta
técnica aprovecha la cooperación entre robots para memorizar zonas ya previamente
descubiertas por un robot y que puedan ser conocidas por el resto del enjambre.
Otra aproximación sería el uso de balizas o marcas que limitasen el área usando meca-
nismos como la triangulación. De otro modo, un robot mismamente podría servir como
baliza en el caso de que no se quisieran usar elementos externos. Para este método es
preciso conocer la posición inicial de todos los robots y, en base a esta posición absoluta,
se puede calcular de manera la posición relativa de cada robot.
• Percepción colectiva
Esta característica se define como la unión de toda la información del enjambre para
que esta pueda ser conocida por todos los robots. Esto permite la toma de decisiones
colectiva para llegar a una solución óptima.
Algunos de los métodos más comunes es la clasificación de los objetos en base a unos
modelos predefinidos. Se debe añadir un contexto extra cuando se clasifican estos objetos
para que el resto de los robots puedan interpretar esta información de forma correcta.
Esta información puede ser transmitida de varias formas, siendo las más comunes el uso
de redes inalámbricas o redes locales.
• Sincronización
Otra característica es la sincronización de los robots para compartir un escenario común

dentro del escenario global. Un ejemplo de esto sería la coordinación de relojes o el uso de
coordinadores que actúen como responsables de objetos críticos que deban ser accedidos
por varios robots al mismo tiempo.
Dentro de un simulador, la frecuencia de todos los robots ya se establece por defecto

en un mismo valor. En casos reales, se hace uso de osciladores para mantener una
frecuencia fija.
• Recuperación
10 Estado del arte
En caso de que un miembro del enjambre sufra algún fallo, es preciso realizar tareas
de recuperación para que este pueda reiniciares o bien que otro robot supla al robot
averiado. El objetivo de esto es minimizar el impacto de una avería y permitir que la
ejecución de la tarea pueda seguir su curso.
Una forma de reparación de robots defectuosos es que otro robot asista al robot averiado.
Un enfoque más sencillo sería simplemente ignorar al robot averiado.
2.4.2 Proyectos e iniciativas reales aplicadas al sector
Dentro de todas las aplicaciones posibles, las más destacadas son referentes en los cam-
pos de la educación, monitorización ambiental, exploración espacial, agricultura, rescates de
emergencia, logística y desarrollo militar. He seleccionado algunos proyectos de mi interés
para estudiarlos con más detalle.
• Amazon Kiva
https://www.youtube.com/watch?v=HSA5Bq-1fU4
En este vídeo se nos muestra cómo una flota de cientos de pequeños robots son capaces
de manejar el inventario de un almacén de Amazon. Los robots, de compacto tamaño,
están diseñados para mover los estantes con los diferentes productos por todo el almacén.
Se pueden observar diferentes comportamientos de enjambre, donde cada unidad autó-

noma está programada para cumplir una tarea al mismo tiempo que interactúa con el
resto de robots para evitar colisiones en su recorrido. En el sentido estricto, como cada
robot se centra en su propia tarea y evita influir en el resto de robots, no sería com-
pletamente un comportamiento de enjambre. En este sentido, la parte de coordinación
para que todos los robots logren una tarea común no estaría presente para este caso.
• Swarmathon
Swarmathon se trata de una competición creada en 2016 por la NASA Schranz y cols.
(2020). Esta competición anima a diferentes estudiantes de diferentes universidades a
participar en el desarrollo de un proyecto para recolectar diferentes recursos usando
un conjunto de robots prediseñados llamados Swarmies. Estos consisten en pequeños
2.4. Aplicaciones dentro de la robótica de enjambre 11
robots equipados con diferentes sensores, motores, un micro controlador y una cámara
capaz de procesar imágenes para la detección de los objetos.
El objetivo de los estudiantes es desarrollar un software que cumpla con los requeri-
mientos de la competición. En 2016 el objetivo era identificar unos objetos marcados
con un código, recolectarlos y volver a la base para ganar un punto. A través de los
años, la dificultad aumentaba, incluyendo obstáculos que simulaban los desniveles de
Marte.
Los participantes debían construir sus simuladores utilizando Gazebo, un famoso simu-
lador de robots, haciendo uso del framework ROS y utilizando el lenguaje de programa-
ción C++. Con todo esto, los estudiantes debían investigar nuevas formas de completar
las distintas tareas, lo que incluía también el estudio en el campo de la robótica de
enjambre, puesto que mucho de los requisitos exigidos iban destinados a enfocar el
problema desde un punto de vista descentralizado enfocado en la cooperación de sus
entidades.
Este proyecto me ha resultado interesante ya que abre muchas puertas a los estudiantes,
apoyados con becas de estudio por parte de la NASA y permitiendo que muchos de ellos
aprovechasen esta experiencia para la búsqueda de empleo en el sector.
En este vídeo se puede ver el ganador de 2019, donde se nos muestra la simulación
formada por el enjambre.
https://www.youtube.com/watch?app=desktop&v=ZoLTRkHQBLw
• Guardians
Guardians Marjovi y cols.(2009-10-11) es un proyecto diseñado para ser usado en si-

tuaciones críticas que involucren incendios en zonas de inventario grandes, como puede
ser el ejemplo que hemos visto anterioremente de Amazon Kiva. Los robots de este
proyecto están diseñados para acompañar al bombero sin necesidad de que este le de
ningún comando, otorgándole así la etiqueta de autónomo. El rol principal (o la tarea)
del enjambre no es otra que asistir al bombero, cumpliendo así el requisito de completar
una tarea común entre todos los robots.
12 Estado del arte
Por otro lado, en el artículo se explica cómo el sistema está montado sobre una arqui-
tectura descentralizada, evitando una vez más el rol de un supervisor que controle al
enjambre. Se emplea una red WiFi compartida por todas las unidades para la comuni-
cación al mismo tiempo que se usa SLAM para el reconocimiento de un área cerrada.
Por último, se incluyen diferentes sensores para monitorizar varios parámetros que ayu-
darán a asistir al bombero en tareas como la exploración o la detección de personas en
riesgo.
El artículo expone las diferentes ventajas ventajas (mayormente la autonomía de los

robots) y las desventajas a usar un modelo centralizado, demostrando uno de los casos
en los que la implementación de una tecnología todavía en desarrollo como al robótica
de enjambre es superior a implementaciones convencionales.
Capítulo 3
Objetivos
En esta capítulo describiré con más detalle los objetivos propuestos. Ante todo, mi objetivo
personal es poder aplicar los conocimientos adquiridos en la carrera sobre un campo nuevo
para mí. Si bien parto con una base, me gustaría poder aprovechar la realización de este TFG
para ver qué papel desempeña un informático dentro de este mundo y cómo ambas ramas de
la ingeniería cooperan para construir y desarrollar los robots.
Se establecen los siguientes objetivos de cara a desarrollar un enjambre de robots:
1. Estudiar en profundidad el campo de la robótica de enjambre, las características que

lo definen y los proyectos de actualidad.
2. Aprender a utilizar un simulador, su entorno y cómo estructurar y diseñar un robot

funcional.
3. Programar el comportamiento de un robot, desde su movimiento hasta los diferentes

sensores que utilizará a lo largo de la ejecución.
4. Crear una simulación donde se pueda reconocer un comportamiento de enjambre en los

robots que la conformen.
3.1 Requisitos
No a todos los conjuntos de robots se les pueden llamar enjambres. Existen una serie de
características que otorgan a dicho conjunto la propiedad de enjambre. Estas características
están extraídas del siguiente artículo Cheraghi y cols.(2022).
• Flexibilidad
Es de gran importancia que los robots cooperen para completar la tarea asignada. El
rol de la flexibilidad es necesario para que cada robot conozca su papel individual dentro
13
14 Objetivos
del enjambre y, si es necesario, cambiar dicho papel cuando haga falta. Un ejemplo real
de esto son los diferentes roles presentes en un enjambre de abejas, donde podemos
distinguir roles como constructoras, cuidadoras o el rol principal, la abeja reina.
Para implementar esta característica dentro de mi sistema, he decidido usar un algo-

ritmo de elección de coordinador el cual asignará un rol principal (como es el rol de la
reina) y este será el encargado de coordinar el enjambre.
• Escalabilidad
Otro de los requisitos es que el tamaño del conjunto debe poder ser dinámico. Debemos
ser capaces de ajustar este parámetro para que los robots sigan siendo capaces de com-
pletar la tarea asignada independientemente del tamaño. Así mismo, también debemos
facilitar herramientas para que sea posible agregar y eliminar robots de forma sencilla.
• Robustez
Se define como un sistema robusto a aquel que posee la habilidad de seguir operando a
pesar de los cambios en el entorno, tales como el incremento de obstáculos, pérdida de
robots o cambios en el terreno. Como ya he mencionado antes, un robot de por sí no
significa nada, pues este forma parte de un todo. Dado el caso de que un robot falle,
otro robot debe ser capaz de sustituir a este para mantener la eficiencia de la tarea.
Existen también otras características adicionales que diferencian a las arquitecturas de

robots de enjambre de otras arquitecturas similares como las arquitecturas multi-agente o las
basadas en sensores.
• Autonomía
Cada robot debe ser capaz de funcionar y tomar decisiones por sí mismo, es decir, no
debe depender de ningún organismo central para poder efectuar su trabajo.
• Organización interna
Esta característica hace referencia a la capacidad que deben tener los robots para lidiar
con los problemas del entorno y reorganizarse en función del momento. Un ejemplo de
esto sería cuando un conjunto de robots ha finalizado un tarea, estos deben ser capaces
3.1. Requisitos 15
de reactivarse para ayudar al resto. Es una forma más de alcanzar una cooperación
entre robots.
• Auto-ensamblaje
Capacidad por la cual los propios robots son capaces de organizarse en estructuras sin
la intervención externa.
• Descentralizado
Una de las características más importantes. Se permite una figura coordinadora, pero
no debe ser obligatoria para el funcionamiento del enjambre. Esta puede aportar control
sobre el reparto de tareas, posicionamiento o información adicional. Además, puede ser
reemplazable por cualquier otro robot en caso de fallo. Los robots deben ser conscientes
del estado del coordinador y deben poseer herramientas para elegir uno nuevo.
• Estigmergia
La estirmergia es el concepto que se le da a la comunicación indirecta entre robots. En

el mundo real, un ejemplo de esto serían las feromonas que usan algunos insectos para
marcar los caminos hacia la comida.
16 Objetivos
3.2 Simulaciones
Otro de los objetivos es estudiar los diferentes simuladores que ofrece el mercado y selec-
cionar uno que nos de la flexibilidad necesaria para implementar las pruebas necesarias.
A su vez, la no necesidad de tener que montar un robot real desacopla el desarrollo hardware
(como el propio ensamblamiento del robot o los ajuste de sensores) del desarrollo software
(controlador del robot). Esto facilita la implementación de la lógica del robot antes de que
el hardware esté listo. Entre otras muchas ventajas que puedan ofrecer, una de las más
recalcables es la flexibilidad para modificar el número de robots usados para la simulación.
Un simulador también sirve como punto base para aprender y obtener la experiencia base
para trabajar con robots sin necesidad de disponer uno de ellos. Podremos elegir entre una
gran variedad de lenguajes de programación que implementarán una interfaz para ocultar la
lógica compleja.
Más adelante explicaré, en la sección 5.1 Simuladores veremos los diferentes simuladores
que se han tenido en cuenta, las diferencias entre ellos y las ventajas que ofrecen unos frente
a otros.
3.3. Propósito del enjambre 17
3.3 Propósito del enjambre
El propósito final del TFG es implementar una tarea conjunta que será ser completada de
forma cooperativa por todos los robots. Tras concretar el propósito, se creará una demo para
a poner en escena todas las características vistas a lo largo del proyecto de forma visual.
Capítulo 4
Metodología
En este apartado explicaré qué metodología he empleado para desarrollar el proyecto, cómo
me he estructurado las diferentes etapas y los tiempos entre etapas.
En primer lugar, pensé optar por utilizar el clásico SCRUM, pero me di cuenta que al
no estar desarrollando un producto software como tal, no se ajustaba a las etapas que tenía
previstas. Mi idea inicial para estructurar el TFG está basada en desarrollar una serie de
prototipos iniciales y, en base a dichos prototipos, ir añadiendo módulos encima creando un
modelo por capas. En general no he usado una metodología específica, sino que he usado un
conjunto de las siguientes:
• Investigación bibliográfica
Analizar diferentes artículos de revistas y estudios relacionados con el campo de la

robótica de enjambre.
• Estudio de casos
Buscar diferentes proyectos de actualidad. Más adelante, en la sección 5.5 Demo simu-
lación veremos cómo me he inspirado en uno de estos proyectos para realizar mi propia
demo.
• Prueba y error
En las diferentes simulaciones de prueba que he hecho, he ido recogiendo diferentes

datos. En base a estos datos (mayormente errores que iba cometiendo) he ajustado
diferentes parámetros hasta estar conforme para avanzar a la siguiente etapa.
A continuación, expondré las diferentes etapas seguidas, así como su dificultad y el tiempo
que me ha tomado finalizarlas.
19
20 Metodología
Etapa Dificultad Tiempo requerido

Investigación bibliográfica Media 3 semanas
Elección simulador Media 1 semana
Realizar tutoriales del simulador Alta 1 mes
Diseñar primer robot Baja 1 día
Aprender a usar sensores y cámaras Baja 1 día
Crear primer prototipo Media 2 semanas
Mecanismos de comunicación entre procesos Baja 1 día
Estudiar librería RPYC Media 2 semanas
Estudiar mecanismos de posicionamiento Media 1 semana
Crear segundo prototipo Media 2 semanas
Crear tercer prototipo Alta 2 meses
Redactar memoria Alta 1 mes
Cuadro 4.1: Etapas del proyecto
Otras herramientas que he utilizado a lo largo del proyecto han sido:
• Picsart: diseñar y dibujar el mapa de la demo
• Latex Overleaf: redactar memoria
• Zotero: Añadir bibliografía
• Lucidchart: Diseño de diagramas y casos de uso

Capítulo 5
Desarrollo
Se explicarán las diferentes etapas seguidas durante el desarrollo del TFG, así como los dife-
rentes problemas encontrados, la toma de decisiones y demás explicaciones para documentar
correctamente el documento.
5.1 Simuladores
El primer paso en la realización de este trabajo consiste en el análisis de los diferentes

simuladores que hay en el mercado. Para ello, se priorizan factores como la sencillez, las
funcionalidades ofrecidas, la flexibilidad de lenguajes de programación o el propio soporte del
simulador por la comunidad o los desarrolladores.
A continuación mostraré una tabla con la frecuencia con de aparición de los diferentes
simuladores en base a las diferentes búsquedas realizadas , seguidas de las referencias donde
se ha encontrado la información. Solo se han añadido los simuladores que se han tenido en
cuenta a la tabla debido a que algunos de ellos se han descartado de primera mano debido a
que su propósito no era adecuado para lo que estamos buscando (generalmente los simuladores
descartados tenían un propósito más centrado en el ámbito industrial). Entre otros factores,
también se han descartado diversos simuladores debido a su antigüedad, cese de desarrollo o
incompatibilidad
21
22 Desarrollo
Simulador Frecuencia Referencias

Webots 1 [4] [12] [5] [11] [3]
CoppeliaSim (V-Rep) 1 [4] [12] [5] [11] [3]
Gazebo 0,8 [4] [12] [11] [3]
Blender 0,2 [12]
Unity 0,2 [5]
Player/Stage 0,6 [4] [11] [3]
ARGoS 0,6 [4] [11] [3]
TeamBots 0,6 [4] [11] [3]
Cuadro 5.1: Frecuencia de aparición en búsquedas de simuladores
La frecuencia de cada simulador se calcula de la siguiente forma, donde N es el número total

de fuentes usadas para extraer información de simuladores y refi el número de ocurrencias
entre todas las fuentes.
refi
fi = (5.1)
N
A continuación, daré una breve descripción de cada simulador y algunos de sus aspectos
a destacar. Generalmente, las fuentes de información ya muestran tablas comparativas con
diferentes características como el soporte del sistema operativo, lenguajes de programación
aptos o detalles de los desarrolladores, pero he decidido darle mi propio enfoque en base a
los requisitos que yo estaba buscando.
• Webots
Simulador finalmente seleccionado para ser usado en este TFG. Su nombre aparece en
todas las fuentes revisadas y, a pesar de que su propósito inicial no sea para la robótica
de enjambre, tiene otros muchos beneficios. Su diseño adaptado para el aprendizaje y
la variedad de tutoriales que tiene lo convierte en una opción fantástica. Además, su
instalación es tan simple como descargar un ejecutable. Se pueden encontrar diversos
contenidos (como vídeos en Youtube) que facilitan la introducción a diferentes herra-
mientas. Si algo he valorado de este simulador es que pone las cosas fáciles para los
novatos. Tanto la interfaz como la estructura de los robots es intuitiva y en poco tiempo
puedes diseñar tu propio robot desde 0. Finalmente, la documentación de Webots en
su propia página web es clara y completa, además de venir documentada en diversos
lenguajes de programación.
5.1. Simuladores 23
Como nota, fue Fidel (mi tutor de TFG) el que me recomendó usar este simulador y la
verdad es que fue un acierto.
• CoppeliaSim (V-Rep)
Este simulador también aparece en todas las fuentes y por buen motivo. También podría
haber servido para el propósito de este TFG puesto que ofrece diferentes funcionali-
dades para las simulaciones multi-robot (como suscripción de mensajes o sockets). Se
explicará más adelante en la sección 5.4 Comunicación entre robots cómo se ha pro-
gramado manualmente esta funcionalidad en Webots. A primera vista, este comparte
muchas características con Webots. Su instalación es fácil, la interfaz es intuitiva y la
documentación está muy bien redactada, pero lo que me hizo decantarme por Webots
fue quizás su parte más educacional, ya que aunque Coppelia a primera vista sea mejor
opción para el área multi-robot, mi sensación como novato no fue tan grata como con
Webots.
• Gazebo
Uno de los problemas que tuve con Gazebo es que la instalación en Windows me dio
algunos fallos, pero en Ubuntu me iba perfectamente. A parte de eso, la interfaz es un
poco tosca pero a fin de cuentas es funcional. La documentación está al día y tiene
una comunidad activa que da soporte a numerosas preguntas. Está pensado para ser
integrado con ROS, un framework que no usaremos debido a su naturaleza centralizada,
pero también se puede trabajar independiente a este. Al tratarse de un proyecto de
código abierto, la comunidad que hay detrás está conformada por diferentes expertos
en el sector, lo que le da una muy buena reputación a Gazebo y lo convierte en una
opción atractiva. A pesar del alto calibre de Gazebo, lo descarto por los mismos motivos
que Coppelia, considero que Webots logra mejor la introducción de usuarios novatos
al mundo de la simulación robot. Es posible que en un futuro use este simulador para
otros proyectos.
• Blender y Unity
Aunque estas dos opciones no destaquen en el campo de la robótica, me parecía in-

teresante añadirlas ya que son programas de alto renombre y me parecía curioso que
24 Desarrollo
apareciesen en listas de simuladores de robots. Realmente no he podido encontrar nada

útil a lo que respecta en simulación de robots en Blender. Con Unity pasa algo parecido.
Su propósito no es tanto la simulación de robots sino la recreación de la interacción entre
estos. Es por ello que, aunque estas opciones destaquen en otras áreas de la simulación
de robots, no entrarían en mi lista de posibilidades.
• Player/Stage
Este simulador está solamente disponible para Linux. A diferencia del resto, este mues-
tra una interfaz en 2D, que no es algo excluyente pero sí a tener en cuenta. No es
realmente un simulador conocido, por lo que cuesta encontrar documentación y no
tiene una comunidad activa detrás. Es un simulador más básico que centrado en lo
fundamental de una simulación, por lo que sería también una buena opción para la
realización de pruebas en máquinas que tengan menos recursos.
• ARGoS
ARGoS fue creado con el propósito de proporcionar un entorno de simulación flexible

y poderoso para la investigación en robótica autónoma y sistemas de enjambres, por
lo que es también una opción ideal. Disponible solo para Linux, su página web oficial
ofrece diferentes tutoriales y documentaciones para dar los primeros pasos. Lo que hace
especial a este simulador frente al resto es su motor de físicas. ARGoS posee su propio
motor de físicas para asemejarse lo más posible a la realidad. Si bien es verdad que este
simulador también podría haberse utilizado, mis requisitos no andan encaminados a un
enfoque más realista sino a uno que sea más amigable con el usuario al mismo tiempo
que le de a este una amplia gama de funcionalidades.
• TeamBots
Lo que caracteriza a este simulador es que los entornos de desarrollo de simulación son
transferibles a un entorno real mediante el uso de TBHard, un entorno desarrollado con
TeamBots que facilita la migración del desarrollo a un escenario real. También incluye
una característica muy interesante llamada RoboComm, la cual simplifica la comuni-
cación asíncrona entre robots. Aunque he encontrado documentación útil, no he sido
capaz de encontrar contenido de la comunidad para este simulador. También reducimos
5.1. Simuladores 25
las posibilidades de programación debido a que este entorno ha de ser programado en

Java. En definitiva, no me parece una mala opción de cara al futuro por las diferentes
propuestas que ofrece.
26 Desarrollo
5.2 Webots
Como se ha dicho antes, el simulador finalmente seleccionado ha sido Webots. En esta

sección daré una descripción detallada de los diferentes pasos a seguir para crear un mundo
con sus correspondientes robots funcionales.
5.2.1 Creación de un mundo
En webots, un mundo es el escenario donde trabajaremos para crear el terreno junto con
los robots. Para crear un mundo primero es necesario crear un proyecto. Un proyecto es el
directorio raíz, el cual está a su vez subdividido en carpetas. Hay 3 carpetas a tener en cuenta:
• worlds Dentro de esta carpeta encontraremos todos los mundos que creemos dentro
del proyecto. Podemos crear diferentes mundos dentro del mismo proyecto, lo cual nos
sirve para estructurar las diferentes etapas del desarrollo o para crear pruebas rápidas.
• protos Los protos son modelos de robots previamente guardados. Dentro de un mundo
de webots, podemos crear un robot para poder exportarlo a formato .proto. Esto nos
permite reutilizar este mismo robot en diferentes mundos sin tener que volver a rehacer
el robot desde 0. Más adelante explicaré cómo crear un proto correctamente para poder
cambiar sus parámetros desde otro mundo en la sección 5.2.5 El objeto PROTO.
• controllers En esta carpeta se ubican todos los controladores creados. Los controla-
dores no son más que el código que ejecuta el robot cuando se inicia la simulación. Se
pueden crear varios controladores y se puede asignar cualquier controlador a cualquier
robot.
Una vez tengamos clara la estructura, ya podemos crear nuestro primer proyecto con su
correspondiente mundo. Para ello, abriremos Webots, nos iremos a la barra de herramientas
y haremos click en Archivo →New →Directorio de proyecto nuevo. Especificamos las rutas
deseadas y marcamos la casilla de incluir una arena cuadrada. Tras esto, ya tendríamos listo
nuestro primer mundo.
5.2. Webots 27
Figura 5.1: Mundo inicial Webots
5.2.2 Modificación del entorno
A nuestra izquierda podemos ver una lista de elementos. Estos elementos se denominan
como nodos. Existen diferentes tipos de nodos con sus diferentes parámetros. Cuando hacemos
click en un nodo, se despliega una lista con todos los parámetros que podemos modificar. Para
el caso, si queremos cambiar el tamaño de la arena para hacerla más grande, tendremos que
cambiar el parámetro floorSize y especificar el ancho y el largo. En el siguiente ejemplo he
cambiado el tamaño a 2x2:
28 Desarrollo
Figura 5.2: Parámetros de un nodo
Actualmente hay una gran cantidad de nodos, cada uno con su funcionalidad y parámetros
correspondientes. Podemos encontrar la lista completa en https://cyberbotics.com/doc/
reference/nodes-and-api-functions. Usando en conjunto estos nodos, podemos crear es-
tructuras complejas o incluso robots funcionales. Para explicar cómo simular un robot desde
0, iré explicando poco a poco los principios básicos que dicta Webots para construir estas
estructuras complejas.
5.2.3 Mecánicas para la construcción de objetos complejos
Partiendo de la base más elemental, tenemos el nodo Solid. Este es uno de los nodos más
simples de Webots para la representación de un cuerpo sólido. A partir de la combinación
de diferentes nodos Solid, podemos crear el cuerpo de nuestro robot. Para unir estos nodos
Solid, disponemos del nodo Joint (nodo abstracto que implementa el funcionamiento de una
articulación). Este actúa como unión entre 2 nodos para poder crear estructuras funcionales
móviles. Estas articulaciones pueden configurarse para otorgar el numero de grados de libertad
necesarios, de esta forma podemos simular el funcionamiento de las ruedas del robot, uniendo
un motor a un sólido cilíndrico que representará una rueda. Otro nodo muy usado es el nodo
5.2. Webots 29
Sensor. Más concretamente, el nodo Sensor desciende del nodo Device. Dentro del nodo Device
tendremos desde cámaras hasta sensores infrarrojos.
5.2.3.1 Herencia
He mencionado que un nodo ”desciende” de otro, esto se debe a que Webots está diseñado
para utilizar el mecanismo de herencia. Este mecanismo de herencia es el mismo que podemos
encontrar en el patrón de programación orientada a objetos, donde tendremos nodos genéricos
como Device, que serán extendidos por objetos hijos como Camera. El mecanismo de herencia
es muy común en Webots, siendo el pilar principal para el ensamblaje de robots complejos.
Para entender un ejemplo de cómo funciona este mecanismo en la práctica, un nodo Solid es la
representación genérica de un objeto sólido. Para ver con más detalle cuál es la interpretación
de Webots respecto a este Solid, tendremos que ir a la documentación de Webots para ver
la implementación abstracta y sus atributos encapsulados (https://cyberbotics.com/doc/
reference/solid). A primera vista, vemos que el nodo Solid hereda del nodo Transform.
5.2.3.2 Estructura en forma de árbol
Bien, sabemos que un Solid solo representa un objeto con propiedades físicas como la
masa y que extiende una clase Transform para poder desplazarse por el mapa, pero, ¿Cómo
le añadimos una forma? Aquí es donde entra en juego otro mecanismo muy importante
de Webots, el mecanismo de composición Padre-Hijos. Para construir figuras complejas, se
pueden añadir nodos hijos a un nodo padre y, a su vez, los nodos hijos podrán también tener
otros nodos hijos. Dicho de otro modo, la estructura de un objeto complejo es un árbol, donde
la hoja padre será el nodo principal, compuesto por las hojas hijas. Para el caso, añadiremos
un nodo hijo Shape. Este nodo es una hoja base debido a que no acepta otros nodos hijos.
El resulta final será el siguiente:
30 Desarrollo
Figura 5.3: Estructura en forma de árbol de un objeto
5.2.3.3 Define-Use
El último paso para tener un nodo sólido funcional es añadir las colisiones, es decir, regis-
trar las dimensiones del objeto y delimitar el área de este para que concuerde con la forma
para que más adelante el simulador sea capaz de saber cuándo un Solid choca contra otro.
Para esto, rellenaremos el atributo ”boundingObject” con las dimensiones del nodo Shape.
Para facilitarnos el trabajo y que las dimensiones del nodo Shape sean correspondientes al
nodo Solid, Webots nos facilita el trabajo con el mecanismo ”DEF-USE”. Lo que hace este
mecanismo es definir un nodo para que sea reusado dentro del árbol. Esto evita la duplica-
ción de nodos y nos ayuda a la reutilización de nodos ya definidos. Para usar este mecanismo,
5.2. Webots 31
iremos al panel de control del nodo y le daremos el nombre que nosotros queramos para la
definición. Para nuestro caso, como queremos reutilizar el nodo Shape para que concuerde
con las delimitaciones del nodo Solid, definiremos el nodo Shape con el nombre ”cuerpo”:
Figura 5.4: Mecanismo DEF-USE
Ahora, para indicar que queremos usar esa definición como delimitador de área, rellenamos
el campo ”boundingObject” con la nueva definición creada. Podemos ver que ahora el objeto
está resaltado con unas líneas blancas que indican que ahora ya tiene colisiones:
Figura 5.5: Sólido con colisiones

32 Desarrollo
5.2.4 Diseño y construcción de un robot
Haciendo uso de los mecanismos que nos ofrece Webots, ya podremos construir nuestro
primer robot. Empezamos añadiendo un nodo Robot. Este objeto actuará como objeto padre,
siendo una instancia vacía que representará un robot genérico (solo tendremos acceso a los
parámetros relacionados con el objeto ”Robot”).
Figura 5.6: Creación de un robot
Sobre este nodo iremos añadiendo las diferentes piezas necesarias. Estas piezas, haciendo
referencia a lo explicado anteriormente, serán los nodos hijos. Ya hemos explicado cómo añadir
una pieza sólida que represente el cuerpo del robot. Para añadir las ruedas, haremos uso de las
articulaciones (nodo HingeJoint). Esta articulación unirá un motor (nodo RotationalMotor)
con un nodo Solido. Para hacer esto, el nodo HingeJoing dispone de 2 campos: device y
endpoint. En el campo device será donde agreguemos el motor y en el campo endpoint
crearemos la forma de la rueda con un nodo Solid. Como todas las ruedas serán iguales,
podemos hacer uso del mecanismo DEF-USE para evitar duplicación de nodos. Finalmente,
5.2. Webots 33
añadiremos un nodo Physics para que puedan interactuar de forma real con en el entorno.
Gráficamente, nuestro robot tendría la siguiente estructura árbol. He extraído la siguiente
foto directamente de la documentación de Webots https://cyberbotics.com/doc/guide/
tutorial-6-4-wheels-robot.
Figura 5.7: Estructura árbol del robot
Sobre esta base, podremos añadir diferentes dispositivos como sensores o cámaras. Para
ello, haremos uso de los nodos ”DistanceSensor” y ”Camera”. Estos nodos a su vez estarán
representados físicamente por un Solid. En mi caso, he añadido también una estructura para
la cámara con un motor rotacional para que pueda rotar sobre el eje Y. El robot final, con
los sensores y la cámara agregados, quedaría tal que así:
34 Desarrollo
Figura 5.8: Robot base con sensores y cámara
Para saber con más detalle cómo funcionan los sensores, consultaremos la documentación
para ver los diferentes detalles sobre la implementación. El campo más importante es el campo
”lookupTable”. Este sirve para interpretar los valores medidos durante la simulación. Funciona
de la siguiente forma: le indicaremos un valor de distancia (en metros) y le asignaremos el
correspondiente valor a esa distancia. Construiremos una matriz con estos valores, de forma
que que el valor máximo de distancia será el tope de distancia y el valor mínimo generalmente
será 0 o la distancia que nosotros consideremos para representar que un objeto está al mínimo
de distancia para que no se pueda acercar más. Los valores intermedios a estos dos extremos
servirán para establecer una gráfica de valores en función de la distancia asignada. La siguiente
foto está sacada directamente de la documentación de Webots https://cyberbotics.com/
doc/reference/distancesensor.
5.2. Webots 35
Figura 5.9: Gráfica de valores medidos de un sensore en función de la distancia
Por otro lado, vamos a ver también cómo trabajar con el nodo Camera. Los campos más
importantes que tendremos que tener en cuenta para configurar correctamente son width,
height y fieldOfView. Los dos primeros servirán para establecer la resolución de la imagen,
a mayor resolución, mayor calidad de imagen. El tercero nos permite ajustar aumentar el
campo de visión o disminuirlo. No hay que confundir el campo de visión con el zoom (se
incorpora una opción para añadir un zoom a una cámara pero no vamos a utilizarlo).
Para la parte de computer vision y reconocimiento de objetos, se estudió la forma de integrar

modelos de reconocimiento de imagen, ya que Webots nos ofrece una API para recoger la
matriz de valores de color de la cámara. La matriz, de tamaño AxL siendo A el ancho de la
cámara y L el largo, tiene en cada posición un vector de 3 valores RGB. Realizando algunas
pruebas, se llegó a la conclusión de que el sistema no funcionaba correctamente debido a que
ralentizaba mucho la simulación, por lo que se estudió otra alternativa que ofrece Webots.
Dentro de los campos del nodo Camera, encontramos el campo ”recognition”. Este campo
36 Desarrollo
sirve para activar el mecanismo de reconocimiento de objetos, pero, ¿Cómo sabe qué objetos
tiene que detectar?. Para esto, dentro de los campos de un nodo Solid, existe una propiedad
llamada ”recognitionColors”. Cuando activamos este campo, estamos indicando que ese Solid
será reconocido por la cámara y, además, podemos especificar los colores de dicho objeto.
Figura 5.10: Cámara reconociendo un objeto con recognitionColors
En la anterior figura, vemos el Overlay de la cámara, con el objeto reconocido enmarcado

en un recuadro rojo y alguna información adicional. Mediante código, podemos recuperar
esta información para realizar las operaciones que necesitemos, como por ejemplo que solo
detecte los objetos de un determinado color.
5.2.5 El objeto PROTO
Bien, hemos visto cómo ensamblar un robot básico y cómo funciona el ecosistema de Webots
así como sus diferentes mecánicas. Aunque podamos ensamblar nuestro propio robot, Webots
ya nos ofrece una amplia gama de robots que vienen incluidos por defecto.
5.2. Webots 37
Figura 5.11: Robots incluidos por defecto en Webots
A estos robots se les da la denominación de PROTOS, pero, ¿qué es un PROTO y para

qué se usa?. Un PROTO cumple el mismo papel que un nodo Robot, con la diferencia de
que un PROTO encapsula los campos que podrá ser manipulados por el usuario. Dicho de
otra forma, cuando nosotros creamos un Robot y queremos exportarlo para usarlo en otros
proyectos o que otros usuarios puedan usarlo sin necesidad de conocer la implementación,
podemos definir en un fichero de texto todas las partes (incluidos los hijos) y definir algunos
parámetros por defecto. Una vez tenemos el robot definido, podemos indicar los campos que
podrán ser modificados cuando importemos el objeto PROTO. De esta forma, simplificamos
la comprensión de nuestro robot e indicamos a otros usuarios los campos que pueden modificar
al mismo tiempo que restringimos el acceso a campos que no deben ser modificados.
38 Desarrollo
Figura 5.12: Objeto PROTO de un robot E-Puck
En la anterior figura, podemos ver el PROTO de un robot que viene por defecto llamado
E-Puck. Tiene campos que de normal un nodo Robot no tendría, como el tamaño de la
cámara o slots para añadir dispositivos, lo que significa que han encapsulado los elementos
más importantes del robot para que podamos modificarlos sin necesidad de conocer cómo
está ensamblado. De todas formas, si queremos modificar la estructura, podemos hacer click
derecho en el nodo y seleccionar ”Convert to base Node”, esto cambiará el PROTO en un
nodo Robot convencional.
5.2. Webots 39
Para crear nuestro propio PROTO, tenemos 3 opciones:
1. Crear archivo .proto
La manera más convencional es, siguiendo un estilo de etiquetas definidas Webots para
generar un robot directamente desde un fichero de texto.
1 #VRML_SIM R2023a utf8

2 PROTO FourWheelsRobot [
3 field SFVec3f translation 0 0 0
4 field SFRotation rotation 0 0 1 0
5 field SFFloat bodyMass 1
6 ]
7 {
8 Robot {
9 translation IS translation
10 rotation IS rotation
11 children [
12 # list of children nodes
13 ]
14 boundingObject USE BODY
15 physics Physics {
16 density -1
17 mass IS bodyMass
18 }
19 controller "four_wheels_collision_avoidance"
20 }
21 }
En el ejemplo, definimos un objeto PROTO con su nombre. Vemos que dentro del
PROTO hemos definido un nodo Robot, esto significa que no solamente podremos
crear Protos que sean robots, sino que también podremos crear otro tipo de Protos
como estructuras complejas compuestas por diferentes nodos Solid.
40 Desarrollo
A continuación, iremos especificando los diferentes campos que componen nuestro PRO-
TO en forma de árbol. También indicaremos la lista de hijos e incluso podremos usar
el mecanismo DEF-USE como vemos reflejado en el campo boundingObject.
Para indicar los campos que podrán ser modificados una vez tengamos nuestro PROTO
generado, se indicarán mediante el campo field (líneas 3-4). Estos campos recibirán un
tipo, un nombre y un valor por defecto.
2. Exportar URDF
Investigando, he visto que Webots daba la posibilidad de exportar un nodo Robot a

formato URDF (Unified Robot Description Format). Existe una herramienta creada de
forma pública urdf2webots(2023-06-20) que permite hacer la conversión de un archivo
URDF a un archivo PROTO, por lo que evitamos tener que definir toda la estructura
de un robot a mano.
3. Archivo .wbt
Cuando se crea un mundo en webots, se genera un archivo con formato wbt. Si abrimos
este archivo con un lector de texto, podemos ver todos los objetos que se han definido,
incluyendo el nodo Robot que queramos definir como PROTO, por lo que solo tendría-
mos que copiar la definición del robot (creada manualmente desde webots) y pegarla
en nuestro archivo proto.
Como nota, para realizar algunas pruebas en diferentes mundos de webots con diferentes
robots, me he dado cuenta que se pueden copiar los nodos de un mundo y se pueden pegar en
otro, por lo que si abrimos un mundo, hacemos ”Ctrl + c” de un nodo, creamos otro mundo
y hacemos ”Ctrl + v” sobre el mundo nuevo, se copiará el nodo en el mundo nuevo.
5.2.6 Robot Supervisor
En webots, existe la figura del Supervisor. Para modificar objetos u alterar el comporta-
miento del escenario en tiempo de ejecución, los robots solo pueden acceder a sus campos y
atributos. Un supervisor actúa de la misma forma que un robot, pero puede acceder al resto
de nodos de la simulación, siendo capaz de mover objetos, alterar atributos de los nodos o
5.3. Programación del robot 41
gestionar los recursos de la simulación. Para elegir un robot como supervisor, solo tendremos
que marcar el campo ”Supervisor” de un robot como TRUE. A nivel funcional, el robot se
comportará de la misma forma, pero, desde el controlador del robot, podremos acceder a la
API del supervisor, la cual nos permitirá acceder a diferentes métodos que un robot conven-
cional no podría. Más adelante explicaré con más detalle el rol de supervisor y para qué ha
sido utilizado en la sección 5.5.3.1 Supervisor.
5.3 Programación del robot
Ya conocemos la estructura básica de un robot y los diferentes elementos que lo conforman,

ahora hablaremos de cómo podemos programar su comportamiento para movernos por el
entorno, utilizar los sensores o recuperar información de la cámara.
5.3.1 Controladores
En Webots, existe la figura del controlador, que no es más que el código que ejecutará
el robot cuando se inicie la simulación. Este controlador puede estar escrito en diferentes
lenguajes de programación, pero para el caso, nos centraremos en Python. Para crear un
controlador nuevo, simplemente tendremos que dirigirnos al menú de herramientas en la
barra superior de Webots y en la pestaña ”Archivo” seleccionar New →Controlador de nuevo
robot, seleccionamos el lenguaje de programación deseado y le asignamos un nombre. Los
controladores por defecto se almacenan en la carpeta controllers en la raíz de la carpeta del
proyecto.
Python, al ser un lenguaje de scripting, no es necesario compilarlo, por lo que en este sentido
realizar modificaciones de código es más rápido. Lo que me ha supuesto un problema es que
para ejecutar los archivos .py, estos deben guardarse en una carpeta con el mismo nombre (por
ejemplo, si llamamos prueba.py al controlador este estará guardado en una carpeta llamada
prueba), lo que hace que la estructura de archivos pueda resultar un poco problemática si
queremos agregar archivos .py auxiliares, ya que el entorno de ejecución de un controlador
es la propia carpeta del controlador, resultando difícil agregar módulos auxiliares que se
encuentren en otras carpetas. Si el módulo se encuentra en la propia carpeta del controlador,
no hay ningún problema ya que se puedo importar sin mayor problema, pero si queremos
42 Desarrollo
reutilizar un módulo auxiliar para 2 controladores, es necesario duplicar este archivo en las 2
carpetas de los 2 controladores, con los inconvenientes de tener que actualizar los 2 archivos
para que sean iguales.
5.3.2 API de Webots
Webots tiene su propia API que nos ofrece diferentes métodos en Python para programar
un robot. En esta sección vamos a ver los métodos más importantes y cómo usarlos para
comunicarnos con la simulación de Webots. La API que usaremos será para Python.
En primer lugar, para usar la API de un robot, importamos la clase Robot desde la librería
controllers. Aunque nuestro IDE nos avise de que esta librería no existe en el sistema, no
pasa nada, ya que Webots la tiene integrada cuando ejecuta el script. Para usar los métodos
de un robot necesitaremos crear una instancia de la clase Robot(). En cada script, solo
podremos ejecutar una sola instancia robot ya que esta instancia se corresponde al robot
controlado. Esto no significa que varios robots no puedan usar el mismo script, sino que dentro
de nuestro código solo podremos tener una instancia declarada. También declararemos una
variable global para la frecuencia del robot. Esta frecuencia se extrae directamente del campo
”basicTimeStep” ubicado en el nodo World de nuestro mundo Webots. Un ”time step” no es
más que la frecuencia de ejecución del robot, o dicho de otro modo, el tiempo que pasa entre
iteración e iteración dentro del bucle infinito que tiene el robot.
De forma general, para almacenar en una variable un componente del robot, se utiliza el
método robot.getDevice(’nombre del componente’), por lo que usaremos este método para
registrar todos los componentes en variable. Algunos dispositivos, como las cámaras o los
sensores han de ser activados usando el método .enable(TIME_STEP). Puedes encontrar el
código para construir, manejar y usar los diferentes dispositivos de un robot con más detalle
en el apéndice A.1 Código para gestionar un robot y sus dispositivos
Ahora veremos las funcionalidades más importantes para las ruedas, los sensores y la cá-
mara
• Ruedas
Las ruedas tendrán el propósito de avanzar, girar a la izquierda, girar a la derecha y

frenar. Para ello, a cada rueda se le puede asignar una velocidad determinada, por lo
que siendo V una velocidad constante, para avanzar tendremos que asignar a todas las
ruedas la velocidad V. Si queremos que el robot pare en seco, V = 0
Por otro lado, al no haber diseñado el robot con volante ni dirección, para girar, el
robot girará sobre sí mismo. Si queremos girar a la izquierda, se le asignará a las ruedas
del lado izquierda una velocidad -V, mientras que las del lado derecho tendrán una
velocidad V. Para girar a la derecha será al revés.
• Sensores de distancia
De los sensores de distancia solo necesitaremos ir recuperando el valor medido. Como

se ha explicado antes, estos valores irán desde un valor mínimo y un valor máximo.
Para simplificar la medición, no se han establecido valores intermedios, por lo que si si
el sensores devuelve el resultado mínimo significa que el objeto está pegado al robot y
si devuelve el máximo significa que no hay nada delante. En el momento que el sensor
devuelva un valor entre el mínimo y el máximo, significa que delante del robot hay algo.
Dependiendo de si el valor es mayor o menor, el objeto estará más o menos alejado.
• Cámara
La cámara será la encargada de ir detectando los diferentes objetos del mundo. Solo los
nodos que tengan el campo recognitionObject activado serán los que se registrarán en
la cámara.
De cada objeto reconocido, podremos extraer la siguiente información:
Tamaño del objeto en la cámara. Cuando más lejos esté el objeto, más pequeño
será. El objeto detectado en la cámara tendrá unas dimensiones (X,Y) en relación a la
resolución de la cámara. Si la cámara tiene una resolución de 100x100 y el tamaño del
44 Desarrollo
objeto detectado es de 10x10, significa que dicho objeto está ocupando un 10% de la
cámara
Posición del objeto en la cámara. Esto nos será útil para determinar si el objeto
está a la izquierda, a la derecha o en el centro de la imagen. Con esta información
podremos centrar al robot para que se ponga en línea recta con el objeto. Obtendremos
una coordenada (X,Y) que representa la posición del objeto dentro de la resolución de la
cámara, por lo que para saber si el objeto está a la derecha o a la izquierda, tendremos
que comprobar si dicho valor es menos o mayor a la mitad de la resolución X de la
cámara. Si dicho valor se aproxima a esta medida, el objeto estará centrado.
Color del objeto. Si queremos excluir objetos que no sean de un color específico,
necesitaremos conocer su color. Para esto, podemos usar el siguiente método que nos
devolver una lista de 3 colores RGB
5.3.3 Main Loop
El Main Loop será el bucle principal encargado de mantener en ejecución constante al

robot. Este bucle se creará de la siguiente forma:
1 while robot.step( TIME_STEP ) != -1:

2 ## Código del robot
No se puede crear un bucle convencional con while(True) ya que es la función

robot.step(TIME_STEP) la que sincroniza la información recibida y transmitida de los dis-
positivos hacia el controlador y del controlador hacia los dispositivos. Esta función es crucial
y debe aparecer en todos los controladores, pues en caso de que algún controlador se blo-
quee (tenga un bloqueo y no llegue a ejecutar la función robot.step()), se bloqueará toda
la simulación, causando que esta entre en un estado de suspensión hasta que se detecte el
error y se termine con el controlador defectuoso.Desde la propia documentación de la función
(https://cyberbotics.com/doc/reference/robot#wb_robot_step)se dice lo siguiente:
”If the wb_robot_step function is not called then there will be no actuation in Webots
and no update of the sensors in the controller.”
Esta función ha sido crítica para el desarrollo de este TFG, por lo que se ha invertido más
tiempo para comprender el verdadero funcionamiento de esta y cómo se ha de usar correcta-
mente. Un matiz importante es que la información recibida por los sensores es dependiente
de esta función (las variables que registran el estado de un sensor se actualizan con cada
step del robot), por lo que uno de los problemas que más tiempo me ha llevado resolver
es que no se puede actualizar ni leer valores de dispositivos sin usar la función
robot.step(TIME_STEP).
Figura 5.13: Flujo de control de Webots
Para comprender mejor cómo se comunica Webots con Python para ejecutar el código,
explicaré con más detalle el flujo de la figura 5.13.
En primer lugar, Webots ejecuta los procesos correspondientes a los controladores en
Python (el equivalente a ejecutar python archivo.py desde la terminal) para cada robot.
Desde el código, a través de la instancia de la clase Robot() o de la clase Supervisor(), se
enlazarán los diferentes dispositivos de los robots a una variable. De esta forma, cada motor,
sensor o dispositivo estará asignado a una variable almacenada en memoria que a su vez hará
referencia al dispositivo real de Webots.
Una vez que ya hayamos declarado todos los dispositivos que vayamos a utilizar, pasaremos
46 Desarrollo
a la ejecución del robot dentro del Main Loop. Dentro de este bucle infinito podremos realizar
todas las operaciones necesarias sobre los dispositivos. De forma general, estas operaciones
nos permitirán recuperar información (valor medido de los sensores) o cambiar el estado de
algún dispositivo (cambiar la velocidad de las ruedas). El código se ejecutará secuencialmente
hasta que alcance el final del bucle, momento en el que invocará la función robot.step()
Cuando robot.step() es invocada, enviará los nuevos estados de los motores y las peticiones
de los sensores y quedará a la espera hasta que Webots complete un ”simulation step” (un
step es un intervalo de tiempo medido en milisegundos). Durante este tiempo de espera, el
controlador permanece inactivo hasta que recibe una nueva señal de Webots indicando que
ha completado un ”step”. Es importante saber que Webots no comenzará un nuevo ”step”
hasta que haya recibido una señal de todos los controladores, por eso es importante que
ningún controlador entre en un estado de espera sin enviar previamente una señal a Webots
o directamente acabar con la ejecución del controlador. De otra forma, Webots se quedará
esperando infinitamente e impedirá continuar con la ejecución de otros robots.
Este ciclo se repetirá infinitamente hasta que reiniciemos la simulación. Cuando esto pase,
la función robot.step() devolverá -1 y se saldrá del main loop. Si es necesario realizar acciones
de limpieza una vez acabe la ejecución, dispondremos de un segundo para realizar dichas
acciones antes de que Webots fuerce la salida del proceso.
5.3.4 Código del robot supervisor
Aunque un supervisor siga siendo un robot normal (sigue teniendo un Main Loop para la
ejecución del robot), es posible crear una instancia de un robot vacío que simplemente ejecute
comando de supervisor. De esta forma, solo accederemos a los métodos de tipo supervisor sin
tener que preocuparnos de programar un robot funcional. El código para crear un supervisor
junto con sus diferentes métodos se puede encontrar en el anexo A.2 Código de un robot
Supervisor
Para empezar a trabajar con un robot supervisor, deberemos definir una instancia Super-
visor(). A través de esta instancia, podremos acceder a todos los nodos del mundo, leer sus
campos y modificar sus valores. Para recuperar un objeto, lo podemos hacer de varias for-
mas, pero esencialmente hay 2 formas principales, a través de su definición y a través de su
identificador único.
Una vez que tenemos la instancia del objeto almacenado en memoria, podemos acceder a
sus atributos y métodos. Al tratarse de objetos con un comportamiento encapsulado, podemos
usar el comando help() de python para ver qué atributos y métodos tiene. También podemos
consultar la documentación de Webots, pero el comando help() otorga más información de
forma más directa.
Si buscamos modificar un campo en concreto, como el campo ”translation”, que se corres-
ponde a la posición X,Y,Z del objeto, lo haremos con el método getField(). Cada ”field” es a
su vez otro tipo de dato, por lo que tendremos que comprobar de qué tipo es antes de realizar
operaciones.
48 Desarrollo
5.4 Comunicación entre robots
Una de las características que se incluye dentro de la robótica de enjambre es que los robots
sean capaces de compartir información con el resto del enjambre. Este mecanismo de comuni-
cación se puede implementar de diferentes formas, a través de sensores, redes inalámbricas o
cualquier mecanismo que implique transmitir un mensaje. Un mecanismo comunicación de un
enjambre real, como puede ser el caso de las hormigas, emplea el uso de feromonas, que son
una sustancia química que altera el comportamiento de otros miembros del enjambre. Exis-
ten estudios Na y cols.(2021-08-01) que simulan el comportamiento de las feromonas como
mecanismo de comunicación en un enjambre de robots, pero para nuestro caso no usaremos
mecanismos tan complejos.
Webots por defecto no incluye ninguna herramienta para la comunicación entre robots.
Si es cierto que una instancia Supervisor puede acceder al resto de propiedades del resto de
robots, este mecanismo no está destinado a ello, puesto que es una comunicación ”ficticia”
que solo se produce en el simulador. Desde una instancia Robot directamente no podremos
acceder a ninguna propiedad que no sea del propio robot.
Una solución más realista sería emplear el uso de una red inalámbrica Wi-Fi, donde cada
robot tendrá su dirección IP para comunicarse con el resto de robots. Para facilitar el de-
sarrollo en local, todos los robots compartirán la misma red local (127.0.0.1) y se asignará
un puerto diferente a cada robot en función del nombre del robot. Más adelante explicaré
con más detalle la implementación de esta red local en Webots en la sección 5.4.3 RPYC en
Webots.
5.4.1 RPYC
RPYC es una librería de Python que proporciona una forma sencilla de implementar co-
municación remota entre procesos y máquinas mediante la serialización de objetos y la trans-
misión de datos a través de la red. El uso más común de esta librería es encapsular atributos
o métodos dentro de un objeto en Python para que puedan ser usados remotamente por otro
proceso. Esto nos ahorra tener que crear una capa de red donde definamos el estándar de
comunicación (Sockets, API) para que, usando los estándares que dicta la librería, podamos
5.4. Comunicación entre robots 49
implementar una comunicación TCP/IP sin tener que irnos a un nivel más bajo.
Su uso es muy sencillo. Primero tendremos que crear el servicio (una clase) que extienda
el comportamiento de la clase rpyc.Service. Dentro de esta clase podremos crear los métodos
y atributos que queramos. Para que un método o atributo sea ”visible” para el resto de
procesos, habrá que añadirle ”exposed” al principio del nombre. De esta forma, estamos
indicando que ese recurso sera accesible. El resto de atributos o métodos que no incluyan esto
en el nombre no podrán ser accedidos. También podemos implementar las clases on_connect
y on_disconnect (métodos heredados de la clase Service, nosotros solo implementamos el
comportamiento) por si queremos manejar el inicio y fin de una conexión.
Cuando ya tengamos definido nuestros servicio, iniciaremos el servidor encargado de es-
cuchar las peticiones entrantes. Hay que aclarar que este servidor es un bucle infinito de
escucha, por lo que tendremos que implementar nuestro propio sistema de comunicación
asíncrona para que podamos realizar otras tareas mientras se atienden las peticiones. Más
adelante explicaré cómo implementar este sistema en la sección 5.4.3 RPYC en Webots. Este
servidor serializará la clase MyService en una dirección IP determinada. Otro proceso podrá
conectarse a dicha dirección IP para explotar un recurso expuesto. El código para crear este
servidor junto con sus propiedades expuestas se puede encontrar en el anexo B.1 Servidor
RPYC
Desde el lado del cliente, nos conectaremos a la dirección IP correspondiente, accederemos a
la raíz del recurso (la clase creada) e invocaremos el método expuesto deseado. Si intentamos
acceder a algún recurso que no esté etiquetado con ”exposed”, nos dará un error de permisos,
de la misma forma que si ejecutamos algún método o atributo que no exista, nos dará un
error de acceso. El código cliente se puede encontrar en el anexo B.2 Cliente RPYC
50 Desarrollo
5.4.2 Atributos de clase vs atributos de instancia
Hay un factor que debemos tener en cuenta para evitar posibles errores. En Python, al igual
que en otros lenguajes que implementan la POO, se pueden crear atributos de clase y atributos
de instancia. De forma resumida, los atributos de clase serán compartidos por todas las
instancias creadas de esa clase, mientras que los atributos de instancia serán independientes
del resto de instancias.
Cuando nosotros serializamos una clase para usarla en un servidor RPYC, lo que estamos
haciendo es enviar una instancia de dicha clase al otro proceso. Esto significa que dicha
instancia se construye primero con el constructor de clase, por lo que los atributos de clase
expuestos estarán inicializados según hayamos indicado en el constructor. Sin embargo esto
no pasa con los atributos de clase, puesto que estos son iguales para todas las instancias tanto
locales como serializadas por RPYC. Para aclarar este punto mejor, he creado un ejemplo en
el anexo B.3 Comparativa instancia vs clase. En el ejemplo podemos ver que los atributos
de clase expuestos se mantienen independientes entre clientes mientras que los atributos
expuestos de clase se comparten entre clientes (el valor es el mismo para todos los clientes).
5.4.3 RPYC en Webots
Implementar un servidor RPYC en cada robot no ha sido una tarea sencilla, puesto que
tenemos el inconveniente de que tanto en el código del robot como en el código del servidor
RPYC son dos bucles infinitos. Para solucionar esto, necesitaremos un enfoque de servidor
asíncrono orientado a eventos, donde tendremos la ejecución del main loop del robot corriendo
en primer plano y por detrás tener el servidor RPYC a la espera de recibir cualquier evento.
Como primera aproximación, se podrían crear 2 hilos, uno para cada bucle infinito, pero
esto me ha dado algunos problemas debido a la naturaleza indeterminista de los threads en
Python debido a que si se ejecutaba primero el hilo con el servidor RPYC, por algún motivo
este impedía la ejecución del main loop del robot a pesar de que los 2 hilos se ejecutaban de
forma concurrente.
Investigando en la documentación de RPYC, he dado con la solución para crear este tipo
de servidores enfocados a eventos https://rpyc.readthedocs.io/en/latest/tutorial/
tut5.html. Con este tipo de servidor lo que hacemos es iniciar un ThreadedServer con nuestro
5.5. Demo simulación 51
servicio. Este servicio consiste a su vez en la clase rpyc.Service que hemos visto anteriormente.
En el constructor de esta clase es posible iniciar otro Thread encargado de ejecutar el main
loop. De esta forma eliminamos la indeterminación de los hilos y establecemos el main loop
dentro del propio servicio. El código de este servidor orientado a eventos se puede encontrar
en el anexo B.4 Servidor rpyc con main loop de webots
Más adelante explicaré por qué con esta estructura no hemos resuelto todos los problemas,
puesto que como he explicado anteriormente, para recuperar información de los campos del
robot, los métodos deben estar incluidos en el main loop para que se pueda sincronizar la
información del controlador con los dispositivos de Webots. Esto significa que no podremos
crear funciones que requieran recuperar información del robot fuera del main
loop. Si creamos un método exposed fuera del main loop que por ejemplo recupere infor-
mación de un sensor, una llamada desde otro robot congelará la ejecución de la simulación
debido a que al estar fuera del main loop, esta romperá el flujo de control de Webots 5.13.
5.5 Demo simulación
Como último punto del desarrollo, se ha creado una demo en Webots que reúne todos
los aspectos citados en este TFG. Para la creación de esta demo me he inspirado en el
ejemplo de los robots Kiva de Amazon y he creado un sistema de control de logística con
un conjunto de robots. Estos robots trabajarán de manera autónoma y usarán todas los
mecanismos y herramientas explicados. Si bien esta simulación no se ciñe al 100% a lo que
sería un comportamiento de enjambre, representa todos los suficientes elementos como para
categorizarse como un enjambre parcial, puesto que cumple con los 3 pilares fundamentales
de un enjambre: tamaño del enjambre, sin interacción de un humano y cooperación entre
todos los miembros del enjambre para cumplir la tarea. Hay que tener en cuenta también que
se ha desarrollado esta demo teniendo en cuenta las limitaciones del simulador y del propio
entorno virtual.
5.5.1 Objetivo y estructura del enjambre
Como objetivo o tarea del enjambre se ha propuesto la recolección de unas cajas para
ser previamente almacenadas en una ubicación final. El enjambre será de tipo heterogéneo,
52 Desarrollo
puesto que disponemos de 3 robots buscadores y 3 robots sigue líneas. El objetivo de los
robots buscadores será recolectar las diferentes cajas dispersas por el mapa y dejarlas en su
zona de recolección correspondiente en función de su color. La tarea de los robots sigue líneas
será recolectar estas cajas almacenadas por los robots buscadores y agruparlas en una única
zona final, de tal forma que si tenemos 5 cajas rojas y 5 cajas azules, al final de la demo
deberán haber 10 cajas en la zona final.
Se ha creado también la figura del coordinador. Esta figura se ha creado con el propósito
de añadir persistencia al enjambre, puesto que el coordinador tendrá acceso a una base de
datos para ir registrando el estado actual de la tarea. En caso de que algún robot requiera
conocer algún dato del estado de la simulación, se dirigirá al coordinador para obtener esta
información. Como tal el rol de coordinador no añade ningún comportamiento adicional a la
tarea que esté realizando el robot, por lo que en cualquier momento, si el robot que tiene
el rol de coordinador sufre alguna caída, el resto de robots pueden detectar esta caída para
rápidamente asignar a un nuevo coordinador que tenga acceso a la base de datos.
Los robots también se podrán comunicar entre ellos sin necesidad de usar el coordinador,
siendo capaces de distinguir el tipo de robot (buscador o sigue líneas) o información del
estado interno del resto de robots. El estado interno de un robot no se compartirá con el
coordinador, puesto que este existe para persistir información de carácter general, mientras
que si un robot quiere reunir el estado de sus robots semejantes, deberá comunicarse con
estos directamente.
Por último, aunque no tenga impacto sobre el enjambre, la parte que representa la acción de
carga y descarga de una caja se ha simulado. Esto quiere decir que los robots no tienen ningún
mecanismo para levantar una caja y cargarla en un módulo. Todo este comportamiento se
ha omitido debido a que estaríamos entrando en otra materia que no nos concierne para esta
simulación. En su defecto, será un supervisor de Webots el que gestione todas las interacciones
de carga y descarga para ver el estado de la simulación.
5.5.2 Mapa de la simulación
Figura 5.14: Mapa demo simulación

54 Desarrollo
El mapa, creado con la herramienta de edición Piscart, consiste en 2 zonas principales:
• Zona 1
La zona número 1 contendrá tanto los robots buscadores como las cajas. Tanto los
robots como las cajas se pueden poner de forma arbitraria, pero siempre deben estar
en la zona 1. Los robots recolectarán las cajas de color azul y rojo y las depositarán las
cajas azules en la zona azul y las cajas rojas en la zona roja.
• Zona 2
La zona número 2 será exclusiva para los robots sigue líneas. Todos los robots deben
empezar en la línea amarilla y, en función del estado de la simulación, irán recorriendo
la línea negra para almacenar tanto cajas rojas como azules en la zona gris. Cuando
hayan terminado de almacenar una caja en la zona gris, volverán a la línea amarilla
para repetir el proceso.
Antes de almacenar una caja en la zona gris, hay unas pequeñas marcas grises en la
línea negra antes de llegar a la la línea amarilla. Estas líneas se usan para que solo haya
un robot al mismo tiempo almacenando una caja en la zona gris. Hasta que esta zona
no se libere, los robots esperarán detrás de esta línea gris
5.5.3 Robots de la simulación
En esta sección voy a explicar cómo he desarrollado los diferentes robots de la simulación.
También explicaré las dificultades encontradas a la hora de programar los diferentes compor-
tamientos y las soluciones que he encontrado. Por último, desarrollar cómo he estructurado el
código de cada robot, las diferentes clases auxiliares que he usado para estructurar el código
y darle una mayor cohesión. A la hora de ir desarrollando el código, me ha sido muy útil
dividir los diferentes módulos del robot. Aunque esta parte de estructuración de código no
influya en la ejecución, pienso que es importante aplicar los conocimientos que nos han dado
en la carrera para escribir código limpio para su fácil lectura y mantenimiento.
Antes de entrar en detalle, he diseñado el comportamiento de los robots siguiendo el patrón
de una máquina de estados. Es decir, cada robot tendrá una serie de estados, entradas y
salidas. Aunque el comportamiento del robot esté programado para seguir estas pautas, el
robot será completamente autónomo, no siendo necesario que intervenga ningún operario para
que cambie de estado. También he diseñado un diagrama de casos de uso para representar
las funcionalidades del sistema.
Figura 5.15: Casos de uso
5.5.3.1 Supervisor
El primer robot que voy a explicar será el supervisor. Como tal, el supervisor es una entidad
creada desde el propio Webots para simular la acción de coger o soltar cajas. Esta entidad,
a pesar de que cumple también con el rol de robot, no se ve en la simulación debido a que
no tiene cuerpo, es decir, el propio nodo supervisor solo cumple la función de ejecutar una
lógica por detrás sin tener una presencia física en la simulación.
El supervisor funcionará como un servidor de escucha permanente. Cuando le llegue una
petición de cargar una caja, este manipulará la posición de la caja para situarla encima del
robot. Lo mismo pasará cuando le llegue una petición de descarga, este moverá la caja a
las coordenadas descritas en la llamada. Este mecanismo se ha usado exclusivamente para
simular este comportamiento.
56 Desarrollo
Manteniéndome fiel a la estructura de enjambre, el supervisor no podrá transmitir ningún

tipo de información adicional al resto de robots.
Este sería el diagrama de clases del robot supervisor.
Figura 5.16: Diagrama clases robot supervisor
5.5.3.2 Robot buscador
Figura 5.17: Robot buscador
La tarea principal de estos robots será identificar las diferentes cajas repartidas por el mapa
para almacenarlas en su zona correspondiente.
Para identificar las cajas, el robot dispone de una cámara para detectar los diferentes
elementos de su entorno. A través de esta cámara, el robot podrá extraer datos como el
color del objeto, la posición del objeto en la cámara y el tamaño en píxeles. En función de
estos parámetros, el propio robot podrá elegir su siguiente objetivo. También contará con
4 sensores de distancia ubicados en su parte delantera. Con estos sensores, el robot podrá
esquivar obstáculos e incluso detectar si su objetivo está delante.
El comportamiento principal del robot buscador se divide en 6 estados:
• Estado 1: Buscar caja
Al principio de la ejecución de la simulación, se le asignará un color objetivo aleatorio

a cada robot buscador. Una vez haya almacenado la primera caja, preguntará al resto
de buscadores qué colores están buscando ellos. Si hay más cantidad de buscadores con
un objetivo rojo, el color de la próxima caja objetivo será azul. Pasará al contrario si
hay más buscadores con un objetivo azul. Si existe la misma cantidad de buscadores
rojos y azules, preguntará al coordinador qué zona tiene menos cajas almacenadas para
buscar ese color. Si resula que siguen siendo iguales, se asignará un color aleatorio.
El robot se irá desplazando a lo largo del mapa buscando una caja del color asignado.
Una vez haya tenga localizado su objetivo, pasará al siguiente estado.
• Estado 2: Desplazarse hacia la caja
Para desplazarse hacia la caja objetivo, el robot usará la cámara para centrar la caja
en el encuadre de la cámara. Una vez esté el objetivo centrado, el robot avanzará en
línea recta hasta estar lo suficientemente cerca de la caja para poder recogerla.
A lo largo del recorrido hacia la caja, he creado una lógica para esquivar cualquier
obstáculos. Si el robot detecta que el obstáculo es otro robot, se frenará en seco y
avisará al resto de robots de que está parado. Esto se hace para evitar que dos robots
se detengan si se detectan mutuamente como obstáculo.
También puede pasar que mientras se esquiva un obstáculo, se pierda la imagen del
objetivo. Si esto sucede, se volverá a buscar un nuevo objetivo. Al principio del desarrollo
de la lógica de los buscadores se implementó una funcionalidad que permitía cambiar
la caja objetivo por otra que estuviese más cerca si se daba el caso. Esta funcionalidad
58 Desarrollo
acabó dando algunos problemas y se tomó la decisión de eliminarla, por lo que ahora
un robot permanecerá siempre con la misma caja objetivo a no ser que la pierda de
vista. Es por esto que los robots no buscarán el objetivo más óptimo (el más cercano)
sino que irán a por el primero que vean.
• Estado 3: Recoger caja
Una vez que el robot este lo suficientemente cerca de la caja, realizará una petición de
carga al supervisor y pasará al siguiente estado.
• Estado 4: Buscar zona
Este estado comparte el mismo comportamiento con el estado de buscar caja, con la
diferencia de que en vez de buscar una caja, buscará señal identificativa de la zona
respectiva al color de la caja que esté portando. Las señal amarilla será identificativa
para la zona roja y la señal cian para la zona azul. Estas señales estarán situadas justo
encima de cada zona. Cuando tenga localizada la señal, pasará al siguiente estado.
• Estado 5: Desplazarse hasta la zona
Con el objetivo ya centrado, el robot seguirá la misma lógica de desplazarse hacia una
caja, pero para desplazarse hasta una zona evitando también obstáculos. Cuando se
haya aproximado lo suficiente a la zona, cambiaremos al siguiente estado.
• Estado 6: Depositar caja
Una vez más, el robot realizará una petición al supervisor para almacenar la caja en su
correspondiente zona. Antes de volver a buscar otro objetivo, el robot se reposicionará
mirando al centro del mapa (marcado con una señal verde). Este último comportamiento
se ha agregado debido a que he tenido algunos problemas cuando un robot almacenaba
una caja. De esta forma, todos los robots tendrán la misma posición inicial para buscar
una nueva caja.
Figura 5.18: Estados robot buscador
Respecto a la estructuración del código, lo he dividido en las siguientes clases:
• searcher.py
Clase principal encargada de instanciar el resto de clases auxiliares. Contendrá la lógica

para transicionar entre los diferentes estados. También tiene la responsabilidad de iniciar
el sevidor rpyc y de cread el main loop del robot.
• camSearcher.py
Clase encargada de inicializar la cámara del robot. Contiene toda la lógica para recu-
perar los distintos objetos del entorno y realizar las operaciones para seleccionar los
objetivos.
• moveSearcher.py
Clase encargada de inicializar los motores de las ruedas y los sensores. Contiene toda
la lógica para mover el robot y evitar los obstáculos a su paso.
• networkSearcher.py
Clase creada para toda operación que requiera comunicarse con otro robot, con el
supervisor o con el coordinador. Todas las conexiones se realizarán mediante una interfaz
60 Desarrollo
cliente de la librería RPYC.
• utils.py
Herramientas varias como encapsulación de datos o colores.
• coordinator.py
En caso de que un robot buscador sea asignado coordinador, dentro de esta clase estarán
todos los métodos necesarios para acceder y modificar la información de la base de datos.
La base de datos se ha creado con la librería sqlite3 de Python, que creará una base de
datos local en una ruta del disco del ordenador. En caso de que el robot coordinador
sufra una caída, se asignará un nuevo coordinador usando el algoritmo de selección de
anillo Fatima(s.f.).
Para este algoritmo, todos los nodos deben conocer su nodo vecino. Cuando un nodo
detecta que el supervisor ha caído, iniciará una votación. La votación irá recorriendo
el anillo y volverá al nodo que ha iniciado la votación. Este último mensaje contendrá
una lista con todos los nodos que ha recorrido la votación y sus respectivos valores.
Por último, el nodo elegirá al nuevo coordinador y mandará un nuevo mensaje para
anunciar al nuevo coordinador al resto de nodos.
Este algoritmo fue visto en la asignatura Sistemas Distribuidos de tercer año, se puede
encontrar el pseudocódigo en el anexo C.1 pseudocódigo algoritmo anillo. Se ha extraído
directamente de la diapositiva 33 del tema Sincronización de tiempo y coordinación
Este sería el diagrama de clases del robot buscador con los atributos y métodos más im-
portantes
Figura 5.19: Diagrama de clases robot buscador

62 Desarrollo
5.5.3.3 Robot sigue líneas
Figura 5.20: Robot sigue líneas
Los robots sigue líneas tendrán como tarea principal transportar las cajas desde su zona de
color hasta una zona central. Para ello, irán recorriendo un camino preestablecido marcado
con una línea negra.
Para detectar los diferentes colores del suelo, este robot lleva incorporado dos sensores
infra-rojos en su parte inferior de forma que estarán constantemente analizando sobre qué
colores está moviéndose el robot. También tendrá un pequeño sensor de distancia en su parte
delantera para impedir chocar contra otros robots sigue líneas.
La lógica del robot se dividirá en 8 estados:
• Estado 1: Línea amarilla
Estado inicial de los robots sigue líneas. Todos ellos deben empezar la simulación sobre
esta línea. Esta línea amarilla sirve para reagrupar a todos los robots en un mismo
punto tanto al iniciar la simulación como tras almacenar una caja. Cuando se llegue al
final de esta línea amarilla, se avanzará al siguiente estado.
• Estado 2: Selección color de zona Se iniciará una comunicación con el resto de

robots para optimizar la recogida. Si por ejemplo ya hay un robot desplazándose a la
zona roja, este irá a la azul y viceversa. Si ya hay 2 robots desplazándose a ambas
zonas, se iniciará una comunicación con el supervisor para comprobar qué zona tiene
más cajas. Elegirá esta zona como destino. Si aún así las zonas están igualadas, el robot
elegirá una zona aleatoria.
Dependiendo del color elegido, el robot girará hacia la izquierda o hacia la derecha
hasta encontrar la línea negra, momento en el que cambiará al siguiente estado
• Estado 3: Desplazarse hasta zona de color
El robot avanzará siguiendo la línea negra hasta alcanzar la zona de color. Una vez se
detecte que la línea del suelo ya no es negra, significará que estamos en una zona de
color y avanzaremos al siguiente estado.
• Estado 4: Recoger caja
Una vez estemos en la zona de color y listos para recoger la caja, pueden pasar 2 cosas:
que haya una caja disponible o que no hayan cajas.
Si hay una caja disponible, se enviará una petición al supervisor para cargar esta caja
sobre el robot y se avanzará al siguiente estado.
Si no hay cajas disponibles, para evitar que el robot realice un número elevado de
peticiones al supervisor y colapse el sistema, avanzará al estado 8 para entrar en un
estado de pausa. Cada X tiempo, el robot volverá a realizar una nueva petición para
comprobar si hay cajas disponibles.
• Estado 5: Desplazarse hasta zona final
El robot girará hasta encontrarse de nuevo con la línea negra. Irá siguiendo esta hasta
detectar una línea gris, momento en el que avanzaremos al siguiente estado
• Estado 6: Comprobar estado final

64 Desarrollo
Esta línea gris se ha creado con el propósito de crear una sección crítica. Dentro de esta
sección crítica solo podrá haber un robot, por lo que al llegar a esta línea gris, podrán
pasar 2 cosas: que no haya ningún robot ocupando la sección crítica o que sí que haya
un robot
Si no hay ningún robot, se avanzará con normalidad hasta el siguiente estado y, muy
importante, se indicará al resto de robots que la sección crítica está ocupada.
Si el robot detecta que esta sección está ocupada, de la misma forma que en el estado
4, se transicionará al estado 8 para no colapsar el sistema con muchas peticiones. Una
vez que se reciba la señal del estado 8, se volverá a comprobar la sección crítica
• Estado 7: Depositar caja
Tras volver a detectar la línea amarilla, el robot enviará una petición al supervisor para
descargar la caja en la zona final y se reincorporará a la línea amarilla para repetir el
ciclo.
• Estado 8: Temporizador pausa
Estado transitorio donde se pone el robot a la espera. Cuando el robot termine su pausa,
se enviará de vuelta una señal para que pueda continuar su ejecución con normalidad.
Figura 5.21: Estados robot sigue líneas

Respecto a la estructuración del código, se ha seguido la misma estructura que los robots
buscadores
• liner.py
Clase principal encargada de manejar los diferentes estados del robot. También inicia-
lizará el servidor RPYC e instanciará las clases auxiliares.
• moveLiner.py
Clase creada para gestionar todo el movimiento del robot, principalmente para que
avance centrado en una línea de un determinado color.
• networkLiner.py
Clase creada para encapsular toda la comunicación que se hace con el resto de robots
sigue líneas y con el coordinador.
• utils.py
Clase auxiliar para encapsular el reconocimiento numeral de colores infra-rojos a una

representación textual.
• coordinator.py
Exactamente el mismo archivo que los robots buscadores, puesto que el comportamiento
de un coordinador es independiente al tipo de robot
Este sería el diagrama de clases del robot sigue líneas con los atributos y métodos más
importantes
66 Desarrollo
Figura 5.22: Diagrama de clases robot sigue líneas
Tanto el código del coordinador, del buscador y del sigue líneas se puede encontrar en el
anexo C Códigos generales y enlaces de resultados
Capítulo 6
Resultados
6.1 Demo final
Como resultado obtenido, se ha grabado una simulación completa de la demo propuesta.

En esta contamos con 3 robots sigue líneas, 3 robots sigue líneas, 8 cajas rojas y 8 cajas
azules.
En el vídeo todos los robots se comunican entre ellos para alcanzar un propósito global:
almacenar todas las cajas en un mismo punto final. Tanto los robots sigue líneas como los
buscadores se comunican con el resto del enjambre para comprobar el estado de las zonas de
colores. No se distingue qué robot es el coordinador, debido a que este es uno más dentro del
enjambre realizando su tarea como el resto, pero con un propósito extra (persistir los datos
en caso de caída).
El enlace con el vídeo está en el anexo C Códigos generales y enlaces de resultados
Figura 6.1: Estado inicial vídeo simulación
67
68 Resultados
6.2 Trazas y capturas
6.2.1 Algoritmo de selección anillo
He extraído una traza de los logs que se muestran en caso de que el coordinador sufra una
avería y se requiera realizar una nueva selección de coordinador a través del algoritmo del
anillo. Debido a que las salidas por pantalla no aparecen en el orden correcto, he dibujado
una serie de números de diferentes colores que representan el orden secuencial.
Figura 6.2: Traza algoritmo selección
En esta traza, el coordinador antiguo era el robot 5. Tras eliminar este robot de la simula-
ción, el primero en darse cuenta es el robot 1. Más adelante explicaré por qué este es el peor
de los casos y los diferentes costes de tiempo de este anillo.
Tras darse cuenta, empieza una nueva selección, correspondiente a los números rojos. Robot
tras robot, se van enviando su identificador. Un identificador más grande premia sobre uno
más pequeño. Al llegar al robot 6 (número 9), este vuelve a iniciar una nueva selección que
6.2. Trazas y capturas 69
empezará de nuevo por el robot 1. Esta nueva selección está representada por los números
amarillos. Tras finalizar, el robot 6 recibe el identificador 3006 (número 10 amarillo). Al ser
este su identificador, procede a anunciar que él será el nuevo coordinador.
El robot 1 recibe de nuevo el mensaje del nuevo coordinador y lo propaga. Estos últimos
mensajes donde se anuncia el nuevo coordinador están representados por los números lilas.
Como ya he dicho, este sería el peor caso de este algoritmo debido a que se han enviado
el número máximo de mensajes: En la primera ronda se han enviado un total de 6 mensajes,
en la segunda 6 y en la tercera haciendo un total de 17 mensajes (3n-1). El peor caso se
presenta cuando es el vecino del nuevo coordinador el que inicia la elección (1, vecino de 6 (el
próximo nuevo coordinador), inicia la elección). Para este caso, todo este proceso ha tardado
alrededor de 10 segundos.
En otra traza donde se comprueba el mejor caso se realizan 12 mensajes (2n). En esta
traza, 5 es el antiguo coordinador, pero esta vez es 6 el que se da cuenta de la avería. En
este caso, solamente se realizarían 6 mensajes para elegir al nuevo coordinador y otros 6 para
anunciar al ganador. Par el mejor caso, se ganan 3 segundos respecto al peor caso, tardando
alrededor de 7 segundos.
Cuantos más robots haya en la simulación, más se tardará en elegir al nuevo coordinador,
por lo que hay que tener esto en cuenta para el rendimiento del enjambre.
70 Resultados
6.2.2 Comunicaciones en robots buscadores
• Situación 1: superioridad numérica en buscadores
Figura 6.3: Estado inicial situación 1 buscadores
Voy a explicar la imagen 6.3 para entender qué está pasando. Los 3 robots buscadores
ya han encontrado una caja y se dirigen a la zona roja para almacenarla. Todos ellos
están portando una caja roja. Veamos qué pasa cuando el robot_1 deposite la primera
caja.
Figura 6.4: Estado final situación 1 buscadores
Tras depositar la caja, el robot_1 ha preguntado al resto de buscadores sus colores

objetivos. Como ambos han respondido rojo, su nuevo objetivo será azul.
72 Resultados
• Situación 2: superioridad numérica en cajas
Figura 6.5: Estado inicial situación 2 buscadores
Continuando con la ejecución, el robot_2 depositará su caja en la zona roja. El robot_3

seguirá con un objetivo rojo y el robot_1 tendrá un objetivo azul. Veamos qué pasa
cuando el robot_2 deposite su caja.
Figura 6.6: Estado final situación 2 buscadores
Tras depositar su caja, ha comprobado que hay el mismo número de robots buscadores
rojos - azules. Procederá a pregunta al coordinador el total de cajas de ambas zonas.
Como solo hay una caja roja almacenada (la que ha almacenado el propio robot_2), el
coordinador le responderá que hay más cajas rojas que azules. El nuevo objetivo será
entonces azul.
Si se da el caso de que haya las mismas cajas rojas y azules, se asignará un color
aleatorio.
74 Resultados
6.2.3 Comunicaciones en robots sigue líneas
• Situación 1: superioridad numérica en sigue líneas
Figura 6.7: Estado inicial situación 1 sigue líneas
En esta primera situación, tenemos a 2 sigue líneas esperando en la línea amarilla y a

otro avanzando hacia la zona roja. Veamos qué hará el siguiente sigue líneas para elegir
zona.
Figura 6.8: Estado final situación 1 sigue líneas
Al ver que ya había un robot encargado de la zona roja, este elegirá la zona azul
76 Resultados
• Situación 2: superioridad numérica en cajas
Figura 6.9: Estado inicial situación 2 sigue líneas
En esta situación, ya tenemos cubiertas ambas zonas por 2 sigue líneas. Veamos qué
hará el tercer sigue líneas para elegir su zona.
Figura 6.10: Estado final situación 2 sigue líneas
Como vemos, el robot_4 ha comprobado que ambas líneas estaban ocupadas. Ha deci-
dido entonces preguntar al coordinador para ver qué zonas tenían más cajas. Al ser la
zona azul, ha elegido esta como su próxima zona
78 Resultados
• Situación 3: esperar en zona crítica
Para evitar que 2 robots sigue líneas entren en la zona de descarga final al mismo
tiempo, estos se comunicarán, para comprobar si está libre o ocupada. En las siguientes
capturas podemos ver cómo los robots esperan en las marcas grises esperando a que la
zona de descarga quede libre.
Figura 6.11: Robot 6 esperando a que el robot 5 libere la zona de descarga
Figura 6.12: Robot 4 esperando a que el robot 6 libere la zona de descarga

6.3. Métricas de escalabilidad 79
6.3 Métricas de escalabilidad
En esta sección realizaré diferentes pruebas alternando el tamaño del enjambre. Estas
pruebas tienen el propósito de medir el tiempo que tarda el enjambre en almacenar todas
las cajas en función del número de robots disponibles. Para todas las pruebas, se colocarán 4
cajas rojas y 4 cajas azules en la misma posición inicial.
6.3.1 2 Robots buscadores - 2 Robots sigue líneas
Figura 6.13: Estado inicial prueba 2-2
Figura 6.14: Estado final prueba 2-2

80 Resultados
Tiempo total: 5 minutos 15 segundos
El vídeo con el estado inicial y el estado final se puede encontrar en el anexo C Códigos
generales y enlaces de resultados


82 Resultados
Figura 6.20: Estado intermedio prueba 4-2

6.3.6 Resultados obtenidos en las pruebas
Como hemos visto en las diferentes pruebas realizadas, hemos obtenido los siguientes tiem-
pos para cada prueba.
Robots buscadores Robots sigue líneas Tiempo

2 2 5:15
3 3 3:31
4 4 3:02
2 4 4:24
4 2 4:53
Cuadro 6.1: Tabla tiempos finales
Se observa que incrementando el número de robots, los tiempos mejoran. Cuando incre-
mentamos el tamaño de 2-2 a 3-3, obtenemos una mejora de 1 minuto y 30 segundos, pero
la mejora que se obtiene al incrementar de 3-3 a 4-4 solo es de 30 segundos. Esto se debe a
que al aumentar el tamaño, aumentará el tiempo para evitar colisiones, así como los tiempos
84 Resultados
de espera de los robots sigue líneas. Seguir aumentando el tamaño a partir de este punto nos
podrá dar incluso resultados peores.
En las pruebas donde no se usan la misma cantidad de robots buscadores y sigue líneas,
vemos que a pesar de tener el mismo tamaño que en la prueba 3-3 (6 robots), los tiempos
son peores. Se demuestra así que un enjambre no compensado puede resultar poco eficiente.
En la figura 6.20 se ve cómo se han acumulado una gran cantidad de cajas en las zonas de
colores, resultado de tener solo 2 sigue líneas frente a 4 buscadores.
Capítulo 7
Conclusiones
Hemos visto los principios fundamentales de la robótica de enjambre, así como otras es-
tructuras multi-robot y sus funciones.
Aunque la robótica de enjambre no ofrezca escenarios tan deterministas como otros sis-
temas, es posible que en un futuro, con el avance de la inteligencia artificial y las mejoras
en computación, sea posible implementar estos sistemas en la industria convencional. Quién
sabe si el día de mañana serán los propios robots los que creen su propia estructura para
coordinarse entre ellos.
Lo que es seguro es que un área tan emergente como esta tendrá su papel en la industria
4.0 y será parte de una nueva revolución industrial donde cada vez se irán integrando poco a
poco robots autónomos al trabajo cotidiano o incluso a la vida cotidiana.
Hemos estudiado en profundidad el simulador Webots y las diferentes funcionalidades que
ofrece. Considero que aunque este simulador no sea el más indicado para la implementación
de un enjambre, este me ha facilitado mucho el trabajo con su documentación bien redactada
y con sus tutoriales para principiantes. No hay que infravalorar este simulador puesto que
para nuestra tarea no hemos utilizado numerosas funcionalidades que ponen a este simulador
como uno de los Top 3 simuladores de robots.
Se ha estudiado cómo incorporar la librería RPYC a este entorno creando una API que
se auto-define en los propios atributos de un objeto de Python. RPYC me ha sorprendido
gratamente debido a su sencillez y efectividad y ha servido como una poderosa herramienta
para la comunicación entre robots.
Se ha creado una demo completa incorporando todos los elementos anteriores para crear
un resultado final, así como diferentes pruebas para evaluar el rendimiento y la escalabilidad.
Por último, me gustaría concluir redactando algunas posibles ampliaciones del trabajo
actual de cara al futuro, así como una lista de las asignaturas que me han sido útiles a lo
largo del proyecto.
85
86 Conclusiones
1. En primer lugar, mejorar el sistema para evitar obstáculos. Aunque el actual sistema
cumpla con su función en evitar colisiones con otros objetos, se podría estudiar diferentes
formas de repartir los sensores de distancia, e incluso utilizar más de una cámara para
que el reconocimiento de campo sea mayor.
2. Implementar módulos de recuperación de robots en caso de fallo. Si un robot buscador

sufre alguna avería, el resto de robots simplemente lo ignorarían como un obstáculo más,
pero en los robots sigue líneas, si un robot se avería en mitad de una línea, impedirá el
acceso a otros robots.
3. Recreación de la demo con robots reales.
4. Agregar articulaciones mecánicas para que los robots puedan interactuar físicamente
con el entorno.
5. Desarrollar un módulo de computer vision para que a través de la imagen de la cámara,

se apliquen técnicas de reconocimiento de imágenes usando algún modelo entrenado.
6. Crear diferentes mapas para la demo, con un terreno irregular que dificulte el avance
de los robots o estructuras que impidan la visión directa de las cajas.
Finalmente resumir rápidamente algunas asignaturas que me han inspirado a elegir este
TFG y que me han acompañado en la realización de este.
1. Sistemas Distribuidos, por su gran semejanza en temas de desarrollo de APIs y comu-

nicación entre procesos.
2. Automatización y Robótica, por inspirarme a querer continuar mi carrera profesional

en el mundo de la robótica.
3. Programación concurrente, gracias a los conocimientos en hilos he podido detectar

rápidamente algunos errores en los Threads de Python.
4. Sistemas de tiempo real y los conocimientos en servidores basados en eventos.
5. Sistemas embebidos, donde trabajé por primera vez con un Arduino y vi el funciona-
miento de un main loop.
87
6. Programación 1, 2 y 3, pues gracias a estas sé como escribir y estructurar un código

limpio y funcional.
Bibliografía
API reference — RPyC. (s.f.). Descargado 2023-05-02, de https://rpyc.readthedocs.io/

en/latest/api.html
Arnold, R., Carey, K., Abruzzo, B., y Korpela, C. (2019-10). What is a robot swarm: A
definition for swarming robotics. En 2019 IEEE 10th annual ubiquitous computing, elec-
tronics & mobile communication conference (UEMCON) (pp. 0074–0081). doi: 10.1109/
UEMCON47517.2019.8993024
Calderón-Arce, C., Brenes-Torres, J. C., y Solis-Ortega, R. (2022-06). Swarm robotics:

Simulators, platforms and applications review. , 10(6), 80. Descargado 2023-06-15, de
https://www.mdpi.com/2079-3197/10/6/80 (Number: 6 Publisher: Multidisciplinary Di-
gital Publishing Institute) doi: 10.3390/computation10060080
Cheraghi, A. R., Shahzad, S., y Graﬀi, K. (2022). Past, present, and future of swarm
robotics. En K. Arai (Ed.), Intelligent systems and applications (pp. 190–233). Springer
International Publishing. doi: 10.1007/978-3-030-82199-9_13
Colombel, J., Charles, J.-L., Fabre, R., Jean-Baptiste, H., Mollard, Y., N’Guyen, S., …
Geneste, J. (s.f.). Comparison of main simulators. Descargado 2022-11-25, de https://
learn.e.ros4.pro/en/robotic_simulators/comparison/
Fatima, E. (s.f.). What is ring election algorithm? Descargado 2023-06-01, de https://

www.educative.io/answers/what-is-ring-election-algorithm
Garnier, S., Gautrais, J., y Theraulaz, G. (2007-06-01). The biological principles of swarm
intelligence. , 1(1), 3–31. Descargado 2023-07-05, de https://doi.org/10.1007/s11721
-007-0004-y doi: 10.1007/s11721-007-0004-y
Marjovi, A., Marques, L., y Penders, J. (2009-10-11). Guardians robot swarm exploration
and firefighter assistance..
89
90 Bibliografía
Na, S., Qiu, Y., Turgut, A. E., Ulrich, J., Krajník, T., Yue, S., … Arvin, F. (2021-08-01). Bio-
inspired artificial pheromone system for swarm robotics applications. , 29(4), 395–415. Des-
cargado 2023-07-01, de https://doi.org/10.1177/1059712320918936 (Publisher: SAGE
Publications Ltd STM) doi: 10.1177/1059712320918936
Nguyen, L. A., Harman, T. L., y Fairchild, C. (2019-09). Swarmathon: A swarm ro-

botics experiment for future space exploration. En 2019 IEEE international symposium
on measurement and control in robotics (ISMCR) (pp. B1–3–1–B1–3–4). doi: 10.1109/
ISMCR47492.2019.8955661
RoboticsBiz. (s.f.). Top 11 swarm robotics simulation platforms. Descargado 2022-11-25,

de https://roboticsbiz.com/top-11-swarm-robotics-simulation-platforms/
Ruijiao Li, R. (s.f.). List of robotics simulation softwares. Descarga-

do 2022-11-25, de https://sites.google.com/site/ruijiaoli/resources/
roboticssimulationsoftwarelist
Schranz, M., Umlauft, M., Sende, M., y Elmenreich, W. (2020). Swarm robotic behaviors
and current applications. , 7 . Descargado 2023-06-21, de https://www.frontiersin.org/
articles/10.3389/frobt.2020.00036
urdf2webots. (2023-06-20). Cyberbotics Ltd. Descargado 2023-06-23, de https://github

.com/cyberbotics/urdf2webots (original-date: 2018-07-05)
Webots documentation: Webots reference manual. (s.f.). Descargado 2023-01-31, de https://

cyberbotics.com/doc/reference
Anexo A
Código API Webots
Listing A.1: Código para gestionar un robot y sus dispositivos
1 from controller import Robot

2
3 robot = Robot ()
4 TIME_STEP = int(robot. getBasicTimeStep ())
5
6 ## RUEDAS
7 w1 = robot. getDevice ('wheel1 ')
11 wheels = [w1 ,w2 ,w3 ,w4]
12 lwheels = [w1 ,w3]
13 rwheels = [w2 ,w4]
14 move_speed = 4
15 turn_speed = 4
16
17 for w in wheels :
18 w. setPosition ( float('inf '))
19 w. setVelocity (0.0)
20
21 def avanzar ():

22 [w. setVelocity ( move_speed ) for w in wheels ]
23
24 def parar ():

25 [w. setVelocity (0) for w in wheels ]
26
27 def girar( sentido ):

28 if( sentido == "iz"):
91
92 Código API Webots
29 [w. setVelocity ( turn_speed ) for w in self. rwheels ]

30 [w. setVelocity (- turn_speed ) for w in self. lwheels ]
31 elif( sentido == "de"):
32 [w. setVelocity ( turn_speed ) for w in self. rwheels ]
33 [w. setVelocity (- turn_speed ) for w in self. lwheels ]
34
35 ## CÁMARA
36 cam = robot . getDevice ('CAM ')
37 cam. enable ( TIME_STEP )
38
39 ## Reconocimiento objetos
40 cam_objects = cam. getTecognitionObjects ()
41 object = cam_objects [0]
42
43 object_size = object . getSizeOnImage ()

44 object_position = object . getPositionOnImage ()
45 object_color = object . getColors ()
46
47 # SENSORES
48 ds_l = robot. getDevice ('ds_left ')
49 ds_r = robot. getDevice ('ds_right ')
50 ds_c = robot. getDevice ('ds_center ')
51
52 sensors = [ds_l , ds_r , ds_c]

53 [s. enable ( TIME_STEP ) for s in sensors ]
54
55 left_sensor_value = ds_l.value
56 right_sensor_value = ds_r.value
57 center_sensor_value = ds_c.value
Listing A.2: Código de un robot Supervisor
2 from controller import Supervisor

3
4 supervisor = Supervisor ()
5 TIME_STEP = int( supervisor . getBasicTimeStep ())
6
93
7 ## Recuperamos el objeto definido como " caja_1 "

8 caja = supervisor . getFromDef (" caja_1 ")
9
10 ## Recuperamos el objeto con identificaror 1

11 id_1 = supervisor . getFromId (1)
12
13 ## Queremos ver qué atributos y métodos tiene el objeto caja

14 help(caja)
15
16 ## Posición del objeto ( Vector 3 dimensiones )

17 pos = caja. getField ('translation '). getSFVec3f ()
18
19 ## Añadimos 5 cm a su eje Y ( posición 1 en el vector )

20 pos [1] += 0.5
21
22 ## Actualizamos valor
23 caja. getField ('translation '). setSFVec3f (pos)
Anexo B
Código RPYC
Listing B.1: Servidor RPYC
1 import rpyc
2 from rpyc.utils . server import ThreadedServer
3
4 class MyService (rpyc. Service ):

5 def on_connect (self , conn):
6 ## Código cuando otro proceso se conecta
7
8 def on_disconnect (self , conn):

9 ## Código cuando otro proceso se desconecta
10
11 ## Método expuesto
12 def exposed_method (self):
13 return 10
14
15 ## Atributo expuesto
16 exposed_atributo_expuesto = 20
17
18 t = ThreadedServer (MyService , hostname =" 127.0.0.1 ", port =3000)

19 t.start ()
Listing B.2: Cliente RPYC
1 conn = rpyc. connect (127.0.0.1 , 3000)

2 ## se ejecuta on_connect () en el servidor
3
4 x = conn.root. exposed_method ()
5 print (x) ## imprime 10
6
7 x = conn.root. exposed_atributo_expuesto
95
96 Código RPYC
8 print(x) ## imprime 20
9
10 conn.close ()
11 ## se ejecuta on_disconnect () en el servidor
Listing B.3: Comparativa instancia vs clase
1 class MiClase (rpyc. Service ):

2 exposed_y = 1 ## Atributo de clase expuesto
3 def __init__ (self):
4 self. exposed_x = 2 ## Atributo de instancia expuesto
5
6 def exposed_incrementar_y (self):

7 MiClase . exposed_y += 1
8
9 def exposed_incrementar_x (self):

10 self. exposed_x += 1
11
12 ### EJECUCIÓN CLIENTE 1

13
14 conn = rpyc. connect (" 127.0.0.1 ", 3000)

15 print(conn.root.x) ## Imprime 1
16 print(conn.root.y) ## Imprime 1
17
18 conn.root. incrementar_x () ## Sumamos 1 a x

19 conn.root. incrementar_y () ## Sumamos 1 a y
20
23 conn.close ()
24
25 ## EJECUCIÓN CLIENTE 2
26
27 conn = rpyc. connect (" 127.0.0.1 ", 3000)

30
31 conn.root. incrementar_x () ## Sumamos 1 a x

97
32 conn.root. incrementar_y () ## Sumamos 1 a y

33
34 print (conn.root.x) ## Imprime 2

35 print (conn.root.y) ## Imprime 3
36 conn. close ()
Listing B.4: Servidor rpyc con main loop de webots
1 class MiClase (rpyc. Service ):

2 def __init__ (self):
3
4 ## Creamos e iniciamos el Thread del main loop

5 self. thread = Thread ( target =self. main_loop )
6 self. thread .start ()
7
8 ## Método target para el hilo del main_loop

9 def main_loop (self):
10 ## Bucle infinito robot
11
12 servicio = MiClase ()
13 ## iniciamos la escucha del servidor rpyc
14 ThreadedServer (servicio , hostname =" 127.0.0.1 ", port =3000) .start ()
Anexo C
Códigos generales y enlaces de resul-

tados
Listing C.1: pseudocódigo algoritmo anillo
1 Inicialmente todos los procesos son no - candidatos

2 - Al iniciar una elección :
3 se marca como candidato en el mensaje
4 envía mensaje de elección con su identificador al vecino
5
6 - Cuando un proceso recibe un mensaje de elección :

7 si identificador del mensaje es mayor que el suyo:
8 lo reenvía a sus vecino
9 si es menor:
10 si es no - candidato :
11 sustituye el identificador por el suyo
12 lo envía al vecino
13 se marca como candidato
14 si es el suyo:
15 se marca como elegido
16 envía mensaje de elegido a su vecino añadiendo su identidad
17
18 - Cuando un proceso recibe un mensaje de elegido :

19 se marca como no - candidato
20 lo envía a su vecino
Enlace a GitHub con el código de la demo: https://github.com/mca88/TFG

Enlace al vídeo de Youtube con la ejecución de la simulación https://www
.youtube.com/watch?v=g43breTD9z0
99

Robotica de Enjambre Aplicacion A Logistica de Almacen Cerdan Amat Marcos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Robotica de Enjambre Aplicacion A Logistica de Almacen Cerdan Amat Marcos

Cargado por

Copyright:

Formatos disponibles

Escuela

Trabajo Fin de Grado

Grado en Ingeniería Informática

ALICANTE, Julio 2023

2. Estado del arte 3

5.2.4. Diseño y construcción de un robot . . . . . . . . . . . . . . . . . . . . 32

6.3.5. 4 Robots buscadores - 2 Robots sigue líneas . . . . . . . . . . . . . . . 82

A. Código API Webots 91

C. Códigos generales y enlaces de resultados 99

5.1. Mundo inicial Webots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.1. Estado inicial vídeo simulación . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.5. Estado inicial situación 2 buscadores . . . . . . . . . . . . . . . . . . . . . . . 72

4.1. Etapas del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1. Frecuencia de aparición en búsquedas de simuladores . . . . . . . . . . . . . . 22

6.1. Tabla tiempos finales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

La robótica de enjambre es un área de investigación centrada en estudiar comportamientos

• En la capa intermedia, encontramos los algoritmos e implementaciones informáticas

• Por último, la capa donde convergen el hardware y el software. Nos encontramos ya

A medida que los campos de la robótica e informática avanzan, la capacidad de usar

Estado del arte

2.1 Introducción a la robótica de enjambre

Según Arnold y cols.(2019-10), la robótica de enjambre se define como, cito textualmente:

2.2 Arquitecturas alternativas al enjambre

Actualmente existen otro tipo de sistemas o arquitecturas para implementar un conjunto

2.3 Diferencias entre arquitecturas

En resumen, para casos donde el escenario se haya estudiado previamente y se hayan

Aun siendo conceptos relacionados, la red de sensores y la robótica de enjambre son

En cierto modo, la robótica de enjambre podría considerarse como una funcionalidad

2.4 Aplicaciones dentro de la robótica de enjambre

Ahora que ya conocemos el transfondo de la robótica de enjambre, voy a hablar de algunas

2.4.1 Técnicas habituales

Para implementar ciertas funcionalidades que caracterizan al enjambre, se usan diferentes

• Posicionamiento y localización del robot

Otra característica es la sincronización de los robots para compartir un escenario común

Dentro de un simulador, la frecuencia de todos los robots ya se establece por defecto

2.4.2 Proyectos e iniciativas reales aplicadas al sector

Se pueden observar diferentes comportamientos de enjambre, donde cada unidad autó-

Guardians Marjovi y cols.(2009-10-11) es un proyecto diseñado para ser usado en si-

El artículo expone las diferentes ventajas ventajas (mayormente la autonomía de los

1. Estudiar en profundidad el campo de la robótica de enjambre, las características que

2. Aprender a utilizar un simulador, su entorno y cómo estructurar y diseñar un robot

3. Programar el comportamiento de un robot, desde su movimiento hasta los diferentes

4. Crear una simulación donde se pueda reconocer un comportamiento de enjambre en los

Para implementar esta característica dentro de mi sistema, he decidido usar un algo-

Existen también otras características adicionales que diferencian a las arquitecturas de

La estirmergia es el concepto que se le da a la comunicación indirecta entre robots. En

3.3 Propósito del enjambre

Analizar diferentes artículos de revistas y estudios relacionados con el campo de la

En las diferentes simulaciones de prueba que he hecho, he ido recogiendo diferentes

Etapa Dificultad Tiempo requerido

Cuadro 4.1: Etapas del proyecto

Otras herramientas que he utilizado a lo largo del proyecto han sido:

• Picsart: diseñar y dibujar el mapa de la demo

• Latex Overleaf: redactar memoria

• Zotero: Añadir bibliografía

• Lucidchart: Diseño de diagramas y casos de uso

El primer paso en la realización de este trabajo consiste en el análisis de los diferentes

Simulador Frecuencia Referencias

Cuadro 5.1: Frecuencia de aparición en búsquedas de simuladores

La frecuencia de cada simulador se calcula de la siguiente forma, donde N es el número total

Aunque estas dos opciones no destaquen en el campo de la robótica, me parecía in-

apareciesen en listas de simuladores de robots. Realmente no he podido encontrar nada

ARGoS fue creado con el propósito de proporcionar un entorno de simulación flexible