SISTEMAS OPERATIVOS FÉLIX BELLA FÉLIX BELLA EDUARDO ROS EDUARDO ROS.
SIMULACIÓN DE UN ROBOT HEXAPODO CON ROS Y GAZEBO
38
1 } TRABAJO FIN DE GRADO EN INGENIERÍA EN AUTOMATIZACIÓN FACULTAD DE CIENCIAS E INGENIERÍAS SIMULACIÓN DE UN ROBOT HEXAPODO CON ROS Y GAZEBO Jorge Ivan Labrador Aya Diego Fernando Romero Ibañez 2020
Transcript of SIMULACIÓN DE UN ROBOT HEXAPODO CON ROS Y GAZEBO
1
}
TRABAJO FIN DE GRADO EN INGENIERÍA EN AUTOMATIZACIÓN
FACULTAD DE CIENCIAS E INGENIERÍAS
SIMULACIÓN DE UN ROBOT HEXAPODO CON ROS Y
GAZEBO
Jorge Ivan Labrador Aya
Diego Fernando Romero Ibañez
2020
2
SIMULACIÓN PARA UN ROBOT HEXAPODO CON ROS
Y GAZEBO
Tesis de pregrado
AUTORES:
Jorge Ivan Labrador Aya
Ingeniería en automatización
Diego Fernando Romero ibañez
Ingeniería en automatización
DIRECTOR:
PhD. Olmer García Bedoya
3
Pregrado de Ingeniería en automatización
Bogotá, Colombia
2020
Tabla de contenido
Índice de figuras .......................................................................................................................... 5
Resumen ...................................................................................................................................... 6
Abstract ......................................................................................................................................... 6
Introducción .................................................................................................................................. 7
1. Antecedentes ....................................................................................................................... 8
2. Justificación .......................................................................................................................... 8
3. Objetivos ............................................................................................................................... 9
3.1. Objetivo General .......................................................................................................... 9
3.2. Objetivos específicos .................................................................................................. 9
4. Marco Teórico .................................................................................................................... 10
4.1. Ros (Robot System Operating) ................................................................................... 10
4.1.1. Historia ........................................................................................................................ 10
4.1.2. ¿Por qué ROS? ......................................................................................................... 12
4.1.3. Componentes principales de ROS ......................................................................... 12
4.2. Rviz .............................................................................................................................. 13
4.3. Gazebo........................................................................................................................ 14
4.3.1. La importancia de la simulación .............................................................................. 15
4.4. Moveit .......................................................................................................................... 15
4.4.1. Interfaz de usuario .................................................................................................... 17
4.4.2. Configuración del Moveit .......................................................................................... 17
4.5. Planeación de trayectorias .......................................................................................... 17
4.6. Websocket ...................................................................................................................... 18
4.6.1. Historia ........................................................................................................................ 18
4.6.2. Funcionamiento ......................................................................................................... 19
4.7. Raspberry pi ................................................................................................................... 19
4
4.7.1. Historia ........................................................................................................................ 19
4.7.2. ¿Qué es? .................................................................................................................... 20
5. Metodología........................................................................................................................ 20
5.1. Diseño del robot ............................................................................................................ 20
5.1.1. Primera versión .......................................................................................................... 20
5.1.2. Primeras pruebas. ..................................................................................................... 21
5.1.3. Diseño propio ..................................................................................................... 22
5.2. Construcción .................................................................................................................. 25
5.2.1. Conexión con la raspberry ....................................................................................... 25
5.3. Topología ........................................................................................................................ 25
5.4. Programación en ROS ............................................................................................. 26
Nodo operators .................................................................................................................. 29
5.5. URDF .............................................................................................................................. 31
6. Resultados. ........................................................................................................................ 32
7. Agradecimientos ................................................................................................................ 36
8. Referencias ........................................................................................................................ 38
5
Índice de figuras Fig. 1. Jumpstart the Industry Time Our Program Other ResearchersOther Researchers. [5] ... 11 Fig. 2. Entorno percibido por un robot visualizado en Rviz. Open Robotics. [4] ............................ 13 Fig. 3. Entorno de simulación con SDFormat. [7] ............................................................................... 15 Fig. 4. Planeación de trayectorias con Movit y Rviz. [8] .................................................................... 16 Fig. 5 Acciones y servicios que componen el nodo primario move_group ..................................... 16 Fig. 6 Comparación entre Ajax Polling y web socket, se observa como mejoran los tiempos de
respuesta y la baja latencia entre mensajes ....................................................................................... 19 Fig. 7 Chip de la raspberry PI tomado de www.raspberrypi.org ....................................................... 20 Fig. 8 Primera versión del robot ............................................................................................................ 21 Fig. 9 Prueba de locomoción con 2 patas ........................................................................................... 22 Fig. 10 Prueba de locomoción en avance con cuatro patas ............................................................. 22 Fig. 11 Eslabon 3 visualizado en formato STL ................................................................................... 23 Fig. 12 Base del robot visualizada en stl ............................................................................................. 23 Fig. 13 Eslabón 3 impreso en material PLA (Diferentes vistas) ....................................................... 24 Fig. 14 Distribución de las extremidades de ROZH. .......................................................................... 26 Fig. 15 Valores y rangos de movimiento del modelo ax-12a ............................................................ 28 Fig. 16 Matriz de inercias en el software Autodesk Inventor. .................................................................... 32 Fig. 17 Definición del primer link de la extremidad uno. ............................................................................ 33 Fig. 18 Definición de los joint de una extremidad. ..................................................................................... 33
Fig. 19 Definición de las posiciones finales del robot. ................................................. 34
Fig. 20 Planeación de trayectorias en moveit .............................................................. 35
Fig. 21 Simulación en gazebo ..................................................................................... 35
6
Resumen
En este proyecto de grado se evidencia el proceso que se llevó a cabo para el diseño
y posterior simulación de un robot móvil usando el sistema operativo para robots
(ROS), particularmente la distribución Melodic Morenia que trabaja sobre la
distribución de Ubuntu 18.04 Bionic Beaver. El robot usado en este proyecto es un
robot móvil hexápodo de tipo zoomórfico (araña) nombrado RoZH (Robot zoomórfico
hexápodo) con tres grados de libertad por cada pata, para un total de 18 grado de
libertad y que tiene como actuadores 18 servomotores marca Dynamixel de la serie AX
referencia 12a.
Este proyecto se divide en tres partes, la primera tiene como objetivo el desarrollo del
modelo cinemático de una de las patas del robot. La segunda, consta del proceso
ejecutado para la simulación del robot en Gazebo y el desarrollo de un interfaz web
para la interacción con esta. La tercera es un complemento del manejo de los
paquetes ROS para el control de los servomotores Dynamixel, particularmente los
Dynamixel AX-12a.
Abstract
This graduation project demonstrates the process taken to design and show the
simulation of a mobile robot using the Robot Operating System (ROS), particularly the
Melodic Morenia distribution that works over the Ubuntu 18.04 distro Bionic Beaver.
The robot used in this project is a mobile hexapod of type zoomorphic (spider) named
RoZH (Robot zoomórfico hexápodo in Spanish) with three degrees of freedom on each
paw, for a total of 18 degrees of freedom represented by 18 actuators of type
servomotor of the brand Dynamixel AX 12a.
This project is divided into three parts, the first one has as objective the development of
the cinematic model of one of the paws. Secondly, it's shown the process executed to
simulate the robot in Gazebo and the development of a Web GUI for the interaction
with it. Thirdly, there's an extra section about the management of the ROS packages
for the control of the Dynamixel servomotors.
7
Introducción
La robótica es una de las ramas de la tecnología, que estudia el proceso que se lleva a
cabo para el diseño y la posterior construcción de una maquina o un robot.
Actualmente es un campo de estudio que está en auge y este incrementa a medida
que pasa el tiempo.
En la actualidad la robótica se puede ver aplicada en distintos espacios de nuestro
entorno cotidiano. En los últimos años las industrias buscan automatizar sus plantas
para la optimización de los procesos y la reducción de costos, se diseñan maquinas o
robots que se encargan de realizar tareas repetitivas o tareas de riesgo a corto o largo
plazo para los humanos, en la mayoría de los casos se encuentran manipuladores.
Estos son brazos robóticos los cuales desempeñan una tarea específica como por
ejemplo soldar, pintar, acomodar piezas. Además de los robots manipuladores que se
encuentran en las industrias, existen robots en el campo de la salud ya sea para ayuda
de los médicos en los quirófanos que en la mayoría de los casos son manipuladores
que ayudan a que las cirugías.
A parte de robots manipuladores en la robótica se han desarrollado otro tipo de robots
los cuales se denominan robots móviles, en los que se encuentran los robots con
piernas y los robots que usan llantas. Los robots con piernas normalmente se basan
en la anatomía de animales, están los robots de Una, Dos, Cuatro, y, seis piernas.
Tienen la ventaja de moverse por terrenos de difícil acceso. Un ejemplo de estos
robots son los robots de rescate, se desempeñan en terrenos con escombros. Por otro
lado, los robots con ruedas han sido el mecanismo de locomoción más popular en la
robótica móvil, ya que el equilibrio en este tipo de robots no suele ser un problema
porque los robots con ruedas en la mayoría de los casos están diseñados para que
sus ruedas estén sobre el suelo, a diferencia de los robots con piernas que para
mantener en equilibrio el robot se necesita que cada extremidad cuente con ciertos
grados de libertad para que logre mantenerse de pie.
8
1. Antecedentes
• (Arroyo, 2017) Sistema de control para un robot hexápodo de exploración.
En este trabajo de grado se encuentra la descripción completa de un robot
hexápodo de un grado de libertad por cada pata en ROS el planeamiento y el
modo de ejecución de las marchas del robot, además de la simulación en
Gazebo y una breve introducción a la locomoción de estos robots.
• (Bañó, 2015) Diseño monitorización y control de un hexápodo con ROS.
En este trabajo de grado se centra en programar un software utilizando como
herramienta el entorno de ROS para lograr mover un robot de tipo hexápodo.
Además, se encuentra la definición de paquetes y nodos con este objetivo, ¡la
simulación mediante MoveIt! Y el estudio de la cinemática inversa que
permite resolver el movimiento del robot.
• (Franco Tedeschi, 2014) Este articulo contiene el estado del arte de los robots
caminante de tipo hexápodo, desde el inicio de esta tecnología hasta los
mayores avances hasta la fecha (2014), además hace un estudio del diseño de
estos robots que tiene como objetivo final proponer el diseño de un robot
hexápodo con ciertas características y resaltando la efectividad de este.
2. Justificación
La robótica móvil es considerada por varios expertos en el tema el foco de
investigación en la actualidad, se estima que muchas de las mejores
universidades y laboratorios tienen como eje central este tema. Hoy en día se
encuentra presente en sectores como: El sector industrial, en el área
de servicios, en aplicaciones de vigilancia, militares y en el área de exploración entre
otras, siendo los dos últimos los sectores pioneros en este tipo de desarrollos.
Ahora bien, de Robot Operating System (Ros) hay que decir que su mayor ventaja es
el trabajo colaborativo que ofrece, al ser tan complejo la creación de un software para
robots robusto desde cero, Ros ofrece un entorno en donde equipos de
trabajo contribuyen y además puedan basarse en el trabajo de
otros equipos similares.
Al igual que la robótica móvil, Ros viene en ascenso y ya muchas universidades
adoptaron en sus cátedras la utilización de este framework.
Siguiendo la línea de proyectos de grado como “PLIPE” por Platin,
Juan Sebastian diseñador industrial y tecnólogo en robótica y
9
automatización y “DISEÑO DE SISTEMA DE CONTROL PARA BRAZO SCORBOT-
ER III” por Suarez, Ian y Herrera, Luciano ingenieros en automatización industrial, que
dejan guías de aprendizaje para los estudiantes en diferentes temas, se desea realizar
un proyecto que contenga entre sus entregables guías de aprendizaje sobre los
distintos temas tratados durante la realización del proyecto.
3. Objetivos
3.1. Objetivo General
Desarrollar guías educativas para la programación de robots con base en el robot
hexapobot y el entorno ROS y su respectiva simulación en el software gazebo.
3.2. Objetivos específicos
• Construir una araña de 6 patas, la cual utiliza como sistema de control una
raspberry PI modelo 3b y el sistema operativo ROS.
• Estudiar y desarrollar un software que permita planear trayectorias de la araña.
• Desarrollar la simulación del robot usando el software gazebo.
• Desarrollar una guía de laboratorio para que los estudiantes desarrollen y
conozcan.
10
4. Marco Teórico
4.1. Ros (Robot System Operating)
Aunque ROS es definido por algunos conoceros como un meta sistema operativo que
trabaja sobre un SO (Linux, particularmente Ubuntu para este proyecto) para crear
software para robots, la definición que confiere directamente el sitio oficial mantenido
por Open Robotics es que ROS es un framework para el desarrollo de software para
robots. Provee una colección de herramientas, librerías y convenciones que tienen
como objetivo hacer menos compleja la tarea de crear aplicaciones robóticas robustas
usando una amplia variedad de hardware (Open Robotics, s.f.).
4.1.1. Historia
ROS comenzó como un pequeño proyecto en Stanford desarrollado por Erick Berger y
Keenan Wyrobek mientras realizaban sus estudios de doctorado. En un artículo
publicado por la IEEE Espectrum sobre los inicios de ROS, Wyrobek justifica el
desarrollo del framework como una necesidad evidente, impulsado por el patrón
repetitivo de los desarrolladores de software para robots, “la reinvención de la rueda”,
ya que, como se ilustra en la figura 1 (una de las figuras que utilizaron en la
presentación con la que pretendían atraer inversionistas) pasaban más del 90% del
tiempo reescribiendo el código antes ya desarrollado y solo un 10% mejorando.
11
Fig. 1. Jumpstart the Industry Time Our Program Other ResearchersOther Researchers. (Wyrobek, 2017)
Así nace Personal Robotics Program que fue una versión del framework, que usaron
para promocionar el proyecto y atraer inversionistas, desarrollada para atacar el
problema mencionado y que traía consigo la construcción del PR1 (Personal Robot
versión 1) como robot de pruebas. Con los fondos recaudados, construyeron 10 copias
del modelo PR1 con el objetivo de llevarlos a distintas universidades, en donde
empezaron a desarrollar aplicaciones con su framework. (conocedores dan crédito que
de allí se desarrollaron librerías como Rviz y rq_tools) (Wyrobek, 2017).
Tras su salida de Stanford, el proyecto fue alojado por Willow Garage desde el 2007,
un laboratorio de incubación de proyectos de robótica fundado por Scott Hassan fue
allí en donde se formalizó ROS como una entidad y en donde el proyecto obtuvo la
ambición que en pocos años lo convertiría en el estándar del mundo de la robótica. En
el 2009 lanzan el PR2, un año de después construyen 11 copias de este modelo y una
vez más los distribuyen entre distintas universidades, de esta forma comenzaron a
construir la comunidad ROS, algo primordial para la evolución del proyecto. La primera
distribución de ROS fue lanzada en el 2010 nombrada ROS Box Turtle, en el mismo
año es lanzada ROS C Turtle, la segunda versión de ROS, un año después se lanzó la
tercera distribución ROS Diamondback, durante este tiempo la simulación se convierte
en una herramienta poderosa, así que ROS decide adoptar a Gazebo, el simulador 3D
12
del framework Player/Stage, como el simulador estándar en ROS. En el 2012 se lanzó
ROS Grovy Galapagos, la sexta distribución del framework.
En el 2013, tras el anuncio de la disolución de Willow Garaje, ROS pasa a ser guiado
por la Open Source Robotics Foundation, bajo el mando de la OSRF se lanza ROS –
Industrial, consorcio que busca la aproximación y enfoque del framework a la robótica
industrial. Desde ese momento hasta el 2020 se han lanzado siete distribuciones más,
siendo las dos últimas la distribución ROS Noetic Ninjemys lanzada en el 2020 y la
ROS Melodic Morenia lanzada en el 2018, distribución usada en este proyecto, ambas
versiones LTS.
4.1.2. ¿Por qué ROS?
Aunque en los inicios de ROS había otros frameworks para robótica, como Open-R de
Sony, YARP, Player/Stage, entre los más reconocidos, fue la manera en la que ROS
logro crear una comunidad de desarrolladores de código lo que permitió que el
proyecto sobresaliera y en gran medida lo que lo convirtió en el estándar del mundo de
la robótica hoy, además de ser un proyecto libre.
Así que una de las razonas por las que usar ROS es su amplia y activa comunidad,
que proporciona soporte, ROS, cada vez más, es adoptado por el sector comercial,
particularmente en robótica industrial y de servicios. Por su naturaleza distribuida ROS
recibe paquetes desarrollados por su comunidad que agregan valor y robustez al
proyecto.
Cada porción de código desarrollado por la comunidad requiere un respectivo
licenciamiento, la mayor parte de ROS está construido bajo la licencia BSD que es
muy permisiva en cuanto el desarrollo colaborativo.
4.1.3. Componentes principales de ROS
Middleware: ROS proporciona una infraestructura de comunicación entre procesos,
con la que se puede publicar y suscribir, grabar y reproducir mensajes, llamadas de
servicios, entre otras.
Mensajes estándar: ROS ofrece un conjunto de mensajes que permiten la
interoperabilidad entre aplicaciones, van desde datos de transformaciones hasta datos
de navegación.
Librería tf: La solución al problema cinemático de la robótica dentro de ROS.
URDF: El formato de descripción de robots que ofrece ROS, un archivo XML que
provee la solución para el robot y las herramientas del ecosistema ROS.
ActionLib: A parte de la comunicación a través de temas y servicios ROS ofrece un
tipo de comunicación similar los servicios pero que permite obtener datos acerca del
servicio en tiempo de ejecución (Open Robotics, s.f.).
13
Topología Peer-to-peer: Una aplicación ROS se distribuye bajo la topología P2P, en
donde existe un nodo máster al que los demás nodos se anuncian para permitir la
comunicación entre procesos dentro de la aplicación a través de la infraestructura de
comunicación de ROS.
4.2. Rviz
Entre las herramientas de ROS encontramos una muy importante, sobre todo en el
momento de desarrollar una aplicación en la que se quiera obtener la simulación de un
robot. Rviz es el visualizador para ROS, así que esta herramienta provee un modelo
tridimensional de un robot descrito en formato URDF.
En Rviz se pueden visualizar los datos que adquiere un sensor, por ejemplo, una lidar,
o una IMU, o una cámara, o un sensor propioceptivo como un enconder, etc. El
resultado de la visualización de esos datos es algo como lo ilustrado por la figura 2.
Usa la librería tf para visualizar esos datos en el marco de referencia del robot. Estos
datos son mensajes publicados desde un robot físico o un robot en un entorno de
simulación, por ejemplo, en Gazebo (Open Robotics, s.f.).
Fig. 2. Entorno percibido por un robot visualizado en Rviz. Open Robotics. (Open Robotics, s.f.)
Para poder obtener una visualización del modelo tridimensional de un robot, como se
mencionó anteriormente, Rviz requiere una descripción de este en formato URDF, que
14
es un archivo en XML en donde se especifican, el tamaño del robot, el número de
joints y links y la posición de estos, los ejes de rotación, los tipos de joints, entre otros
datos que servirán para una representación fiel del modelo del robot dentro de Rviz.
4.3. Gazebo
Gazebo es el simulador dinámico tridimensional predeterminado en ROS, tiene la
capacidad de simular con precisión y eficiencia múltiples robots en entornos
complejos. Si bien es similar a los motores de juegos, Gazebo ofrece una simulación
física con un grado mucho más alto de fidelidad, un conjunto de sensores e interfaces
para usuarios y programas (Open Source Robotics Foundation, 2014).
Comenzó como un proyecto que daría solución a la necesidad de una simulación fiel
de robots en entornos complejos, fue desarrollado por del Dr. Andrew Howard y Nate
Koenig en la University of Southern California en el 2002, en ese entonces y durante
mucho tiempo se empleó como plugin del simulador Stage de Player/Stage. En el
2009 el proyecto es integrado a ROS con la simulación del PR2 por Jhon Hsu, con la
aparición de la Open Source Robotics Foundation (OSFR), desde el 2012 se continua
con el desarrollo del proyecto, ahora con el liderazgo y administración de esta
organización.
Entre las características más relevantes de Gazebo se incluyen:
• Uso de múltiples motores de simulación física de alto rendimiento.
• Uso de OGRE, uno de los motores de representación gráfica de mejor
rendimiento y además open source, con el que logra una representación fiel de
entornos simulados.
• Reproducción de datos recolectados por diferentes tipos de sensores dentro
del entorno de simulación.
• Soporte de un gran número de modelos de robots entre los que se destacan el
PR2, Pioneer DX, TurtleBot, entre otros.
• Es un proyecto open source, lo que permite modificarlo ampliamente.
• Aunque el formato elegido por la OSRF para Gazebo es el SDF (Simulation
Description Format), que entre otras características incluye la descripción de
todo el entorno de simulación (en la figura X. se ilustra la simulación de dos
robots en su entorno de trabajo usando SDFormat), Gazebo soporta el formato
de descripción estándar dentro del universo ROS, más adelante se mostraran
las etiquetas necesarias para que Gazebo pueda traducir un modelo de un
robot en formato URDF y representarlo en un entorno.
15
Fig. 3. Entorno de simulación con SDFormat. (Foundation, 2020)
4.3.1. La importancia de la simulación
Desarrollar un entorno de simulación para un robot se convierte en una herramienta
poderosa dentro de un proyecto de robótica, ya que a través de una simulación fiel se
pueden hacer pruebas de forma rápida optimizando de esta manera recursos, en
especial tiempo y dinero, y sin arriesgar el hardware.
4.4. Moveit
Moveit es la principal herramienta, o mejor, conjunto de herramientas para la
planeación de trayectorias y la manipulación dentro de la robótica móvil en ROS.
Inicialmente desarrollado por un equipo de trabajo en Willow Garage desde el año
2011, posteriormente apoyado por SRI International desde el 2013 hasta el 2015, en la
mitad del 2015 y hasta entonces la plataforma pasa a ser liderada por PickNik
(PickNik, s.f.).
16
Fig. 4. Planeación de trayectorias con Movit y Rviz. (PickNik, s.f.)
Moveit cuenta con un nodo primario nombrado move_group, este funciona como un
integrador, es decir une todos los componentes individuales para proporcionar un
conjunto de acciones y servicios ROS.
Fig. 5 Acciones y servicios que componen el nodo primario move_group
17
4.4.1. Interfaz de usuario
Esta herramienta permite acceder a las acciones y servicios proporcionados por el
nodo primario move_group de tres distintas formas:
Con c++: Usando el paquete move_group interface que proporciona una interfaz c++
Con Python: Usando el paquete moveit_commander
A través de una GUI: Usando un plugin de nombre Complemento planeación de
movimiento para Rviz. (PickNik, s.f.)
4.4.2. Configuración del Moveit
Utiliza el servidor de parámetros ROS para obtener tres tipos de información
URDF; El nodo move_group busca el parámetro robot_description en el servidor de
parámetros ROS para obtener el URDF del robot
SDRF; El nodo move_group busca el parámetro robot_description_semantic en el
servidor de parámetros para obtener el SDRF, normalmente el SDRF se crea usando
el moveit setup assistant.
Configuración de Moveit, el nodo move_group se encargará de buscar en el servidor
ROS otras configuraciones específicas de moveit, incluyendo limites conjuntos,
planeación de movimiento. Los archivos de configuración para estos componentes son
generados por el asistente de configuración Moveit. (PickNik, s.f.)
4.5. Planeación de trayectorias
La planeación de trayectorias es la búsqueda de una sucesión de puntos en el espacio
para un robot, los cuales establecen un punto de referencia inicial y una posición final.
La configuración de una trayectoria queda definida por la distribución de los obstáculos
que rodean el entorno en el que se encuentra el robot, por la geometría de este y sus
capacidades de movimiento. De esta manera la topología del entorno restringirá el
espacio libre de obstáculos, en el que se establecerán las trayectorias para alcanzar la
posición deseada.
Existen dos formas básicas para especificar el movimiento.
• Mediante puntos consecutivos e ignorando la trayectoria que describe el robot
entre dos puntos, a esta forma se le conoce como control punto a punto, tiene
interés practico cuando los puntos están separados, de lo contrario, se vuelve
18
muy tedioso. Por otra parte, los puntos no deben estar tan separados, ya que
corre el riesgo de que se generen movimientos imprevisibles o no controlados.
En el control punto a punto, el sistema de control automático del robot debe
realizar la interpolación entre los puntos especificados, de forma tal que,
posteriormente sea posible realizar el control de movimientos para que el robot
pase por dichos puntos.
• Especificando el camino que debe unir los puntos mediante una determinada
trayectoria, tal como una línea recta o un círculo, que debe describir el robot en
su entorno, esta estrategia se denomina se le denomina control de trayectoria
continua. En este caso, el sistema de control debe hacer que el robot
reproduzca lo más exacto posible la trayectoria deseada.
Suponiendo que la trayectoria que debe seguir el robot es especificada en el plano
cartesiano, existen dos formas de ejecución.
• Definir los lazos de control directamente en el espacio cartesiano y controlar el
robot para que se anule el error de seguimiento de trayectoria en el entorno.
Esta forma es comúnmente usada para robots móviles, donde la curvatura del
camino generado en el espacio cartesiano este directamente relacionada con
la variable de control que se emplea para el seguimiento de trayectorias.
• Transformar la trayectoria del espacio cartesiano al espacio de las variables
articulares y controlar la evolución de cada una de las variables definiendo los
lazos de control. (Chile, s.f.)
4.6. Websocket
Websocket surge como un estándar para el reemplazo de las técnicas comet,
especialmente para aquellas aplicaciones web que generan contenido en tiempo real,
como pueden ser chats bolsas de comercio, herramientas colaborativas, o
aplicaciones subastadas. Es la manera de brindar un marco estandarizado para estas
aplicaciones en vez de desarrollarlas sobre técnicas que son verdaderos parches para
el protocolo. (Tzancoff, 2011)
4.6.1. Historia
El protocolo websocket comenzó siendo parte de la especificación de HTML 5, pero
ahora se mantiene como un estándar separado a cargo de la IETF y de la W3C.
(Tzancoff, 2011)
En 2011, la IEFT (Grupo de trabajo en ingeniería de internet – The internet
Engineering Task Force) estandarizo el protocolo 𝑅𝐹𝐶2 − 6455 el cual hace
referencia al protocolo websocket. Desde Entonces, la mayoría de los
navegadores web implementaron clientes que soportan este protocolo.
También se desarrollaron librerías java para la implementación del protocolo
websocket desde otros clientes como por ejemplo aplicaciones
𝐴𝑛𝑑𝑟𝑜𝑖𝑑 𝑜 𝑗𝑎𝑣𝑎𝐹𝑋. (Luis Vivas)
19
4.6.2. Funcionamiento
Websocket define un interfaz de programación de aplicaciones (API) que establece
conexiones socket entre un servidor y un navegador web. Permite una conexión
persistente entre el cliente y el servidor, ambas partes pueden empezar a enviar
mensajes en cualquier momento. (Luis Vivas)
Fig. 6 Comparación entre Ajax Polling y web socket, se observa como mejoran los tiempos de respuesta y la baja latencia entre mensajes
4.7. Raspberry pi
4.7.1. Historia
En mayo del 2009, la fundación Raspberry pi fue fundada en caldecote, south
Cambridgeshire, reino unido como una asociación caritativa que es regulada por la
comisión de caridad de Inglaterra y gales.
La fundación raspberry pi surge con el objetivo en mente: Desarrollar el uso y
entendimiento de los ordenadores en las escuelas. La idea era desarrollar
ordenadores de bajo coste y portables que permitieran que los niños los usarán sin
miedo.
En agosto del 2011, se fabricaron 50 placas Alpha, un modelo similar al B, a diferencia
de que eran un poco más grandes para integrar bien unas interfaces de depuración.
(Dominguez, 2015)
20
4.7.2. ¿Qué es?
Es un ordenador de bajo coste del tamaño de una tarjeta de crédito, cuenta con un
chip integrado broadcom BCM2835, que contiene un procesador ARM11 con distintas
frecuencias de funcionamiento(overclocking) hasta 1GHz, un procesador grafico
VideoCore IV, y memoria ram que varía dependiendo del modelo (desde 256MB hasta
1GB). Además, cuenta con una salida de audio y video a través de un conector HDMI,
con un puerto de conexión ethernet, además de puertos USB y con su respectiva
entrada de alimentación. (Raspberry Shop, s.f.)
Fig. 7 Chip de la raspberry PI tomado de www.raspberrypi.org
5. Metodología
5.1. Diseño del robot
5.1.1. Primera versión
Inicialmente la idea fue aprovechar al máximo los elementos disponibles en el
inventario del laboratorio de robótica de la universidad (CERI), de ahí la decisión de
integrar al proyecto el modelo hexabot perteneciente al laboratorio como componente
(hardware) principal.
21
Fig. 8 Primera versión del robot
5.1.2. Primeras pruebas.
Después de haber leído la documentación de la librería desarrollado por Robotis de
nombre Dynamixel Workbench para el control de los servos dynamixel soportada por
la mayor parte de modelos de servos manufacturados por la marca y compatible con
ROS, Linux, macOS y Arduino. Dentro de ROS la librería toma el papel de un meta-
paquete, que contiene tres paquetes; dynamixel_workbench_controllers,
dynamixel_workbench_operators y dynamixel_work-bench_toolbox en él [referencia].
Se procedió a manejar los paquetes controllers y operators, más adelante se resumirá
la función de cada paquete.
Posteriormente se configuraron las posiciones de los motores de dos de las patas del
hexabot fig. 8 en el respectivo archivo dentro del paquete operators, luego se hizo el
mismo proceso para cuatro de las patas fig. 9, estructurando la locomoción en avance
del robot, durante estas pruebas se evidenció que los actuadores requerían torques
elevados para lograr mover los eslabones de las patas, se concluyó que la razón
principal del problema era el mecanismo de unión eslabón-actuador que reproducia
elevadas inercias por vencer para los servomotores.
22
Fig. 9 Prueba de locomoción con 2 patas
Fig. 10 Prueba de locomoción en avance con cuatro patas
5.1.3. Diseño propio
Partiendo del problema mencionado, se decidió cambiar el modelo del robot por otro
de diseño propio, teniendo como parámetro principal la medida estándar en los puntos
de unión actuador-eslabón para el nuevo prototipo. Se elige la impresión 3D como
proceso de fabricación de las nuevas piezas por relación costo-beneficio,
23
principalmente porque mediante este proceso se logró garantizar los parámetros de
diseño en las piezas destinando poco tiempo y con poca inversión económica.
La primera tarea que se desarrolló fue el análisis, incluyendo las medidas de las
piezas estándar que contienen los sets Bioloid de Robotis, en concreto las referencias
FP04-F2, FP04-F3 y la FP04-F4, usadas como; primer eslabón, ensamble para el
segundo eslabón y unión para el tercer eslabón respectivamente.
Los modelos CAD de las piezas estándar fueron descargados desde la página oficial
de Robotis al igual que el modelo del servomotor AX-12a. Para completar el modelo
del nuevo prototipo del hexabot se realizó el diseño del tercer eslabón y de la base del
robot con ayuda del software CAD Inventor de Autodesk, los resultados del diseño se
pueden ver en las figuras 10 y 11.
Fig. 11 Eslabon 3 visualizado en formato STL
Fig. 12 Base del robot visualizada en stl
24
En el caso del eslabón se imprimió en 3d teniendo como material de aporte el PLA,
elegido por su densidad y la facilidad que presenta en el momento de imprimir, en la
figura 12 se presentan los resultados de la impresión. Para la base, primero se ensayó
un modelo con lamina de acrílico de 3mm cortada en laser, los resultados que se
obtuvieron fueron buenos, pero se decidió cambiar el material del prototipo final del
hexabot por fibra de vidrio con resina poliéster por su resistencia mecánica.
Fig. 13 Eslabón 3 impreso en material PLA (Diferentes vistas)
25
5.2. Construcción
5.2.1. Conexión con la raspberry
Para el control del robot se usó una raspberry pi modelo 3b, la cual se tomó prestada
del laboratorio de la universidad, en la cual se desarrolló el software de control en
ROS.
El primer paso que se realizo fue hacer la instalación de la imagen de Ubuntu mate
18.04 LTS ya que esta imagen es el requisito para poder hacer uso de la versión
melodic de ROS , en una memoria micro SD con un. Después de que se instaló la
imagen del sistema operativo, se insertó la memoria en la raspberry y se procedió a
realizar el proceso de instalación, después de que se instaló se configuro el Ubuntu
mate en la raspberry pi 3b correctamente, después se prosiguió a descargar y hacer la
correcta instalación de los paquetes de ROS necesarios para el desarrollo del
proyecto. Principalmente los relacionados con los motores Dynamixel, entre los que se
encuentran Dynamixel workbench. Después de la correcta instalación de los paquetes
se conectaron los 18 motores que componen las 6 patas del robot en una topología de
bus, usando dos convertidores de datos STL a USB.
5.3. Topología
Como ya se mencionó anteriormente, la topología usada para la conexión de los
dynamixel’s es la comunicación en bus. La comunicación bus es la más simple de
todas las topologías, todos los nodos son conectados a un solo cable, este tipo de
topología ofrece la ventaja de conexiones más fáciles por lo tanto no es necesario
emplear cables de extenso tamaño para una correcta comunicación entre los
elementos presentes. En este caso los dieciocho actuadores conectados a dos
convertidores. Los nueve motores a cada convertidor es decir tres extremidades del
robot están conectadas de tal forma que las tres extremidades forman un triángulo,
como se puede observar en la figura 13, un convertidor se encarga del grupo de
extremidades que contiene la 1, 6, y, 4 y el otro convertidor se encarga de las
extremidades restantes.
26
Fig. 14 Distribución de las extremidades de ROZH.
Estos convertidores cuentan con unos parámetros que funcionan según el número de
actuadores que se encuentren conectados a este, cuando se inició con el proyecto, los
18 motores estaban conectados a un solo convertidor, esto causaba que los
parámetros que ya vienen establecidos en los paquetes de ROS provocarán errores,
por esto mismo se decidió conectar dos convertidores de señal, por lo tanto cada
convertidor usb2dynamixel se encarga de 9 actuadores (3 extremidades).
5.4. Programación en ROS
Como se mencionó, los servomotores dynamixel cuentan con una librería o meta-
paquete desarrollado por Robotis y soportado por ROS, entre algunas otras
plataformas. Es pertinente mencionar que, aunque hay otros paquetes para el control
de los servomotores dentro de ROS desarrollados por la comunidad, en la distribución
Melodic Morenial el framework se enfocó en dar soporte únicamente a este paquete.
27
Un meta-paquete hace referencia a un conjunto especializado de paquetes que se
relacionan de algún modo, por ejemplo, en su función. El meta-paquete Dynamixel-
Workbench es la solución de dynamixel para ROS. Este meta-paquete le permite
cambiar fácilmente la ID, la velocidad de transmisión y el modo operativo del
Dynamixel. Además, es compatible con varios controladores basados en el modo
operativo y Dynamixel SDK [http://wiki.ros.org/dynamixel_workbench].
En total, Dynamixel-Workbench incluye tres paquetes controllers, operators y toolbox.
El paquete Controllers muestra cómo emplear DYNAMIXEL en diferentes modos
operativos usando el paquete Dynamixel Workbench Toolbox. Por su parte, el
paquete Operators contiene algunos ejemplos directos de como operar el paquete
controllers.
Dentro de la documentación de Dynamixel-Workbench se presentan las funciones con
más detalle, además de la instalación, modos de uso y la configuración inicial de los
paquetes dentro del entorno ROS. Del análisis de la documentación se concluyó que
el nodo que debíamos personalizar era el nodo joint_operators dentro del paquete
dynamixel-workbench -operators.
A continuación, se resumirá los pasos que se llevaron a cabo hasta la puesta en
marcha de RoZH usando Dynamixel-Workbench.
Se verificó el estado de los motores usando R + Manager 2.0. Este software
comprende una herramienta optimizada para administrar dynamixel desde varios
sistemas operativos. Con este se configuro las id’s de los servomotores acorde a la
estructura del robot desde el número 1 al 18, de forma secuencial en cada una de las
patas del hexabot.
A continuación, usando el nodo find_dynamixel del paquete controllers y especificando
el puerto al cual se conectó el conversor USB2Dynamixel se obtuvó el número de
servomotores conectados, la frecuencia de trabajo, las id’s y por último la serie de los
motores. Para que todos los servomotores puedan ser detectados por el nodo tienen
que estar conectados a una fuente de alimentación de 11.0 voltios, estar conectados
en serie y tener un firmware compatible con el framework.
Luego se debe configurar un archivo yaml como insumo para el nodo dynamixel_work-
bench_controllers, además el nombre del puerto al que se han conectado los servos y
la frecuencia de funcionamiento de los dynamixel’s, deben ir estructurados dentro de
un archivo launch que iniciara el nodo controllers de nombre dynamixel_workbench
_controllers.launch, la configuración del archivo yaml debe ir como se muestra a
continuación:
nom_servo1:
ID: 1 Return_Delay_Time: 0
nom_servo2: ID: 2 Return_Delay_Time: 0
28
Con esta configuración se crea un mapa que contiene dos objetos, específicamente el
archivo crea una lista de vectores asociativos con dos combinaciones clave – valor, en
el caso del modelo AX-12a. Particularmente en el archivo de muestra se crean dos
servomotores, el primero responderá al nombre nom_servo1 dentro del ecosistema
ROS y los comandos asignados serán ejecutados por el dynamixel con la ID 1 en el
hardware, para la configuración de RoZH el primer servomotor de la primera pata, de
igual modo el dynamixel con la ID 2 responderá a los comandos asignados a el objeto
con nombre nom_servo2.
Un paso recomendado es la llamada al servicio ROS <</dynamixel_command>> con
el que se puede ejecutar comandos que el dynamixel traduce en posición. El modelo
AX-12a tiene una resolución de 0,29º y una posición límite de 300º, como se ilustra en
la figura 13.
Fig. 15 Valores y rangos de movimiento del modelo ax-12a
Antes de llamar al servicio ROS se debe iniciar el nodo <<controllers>> para
ejecutarlo simplemente se ejecuta desde la terminal el comando roslaunch el nombre
del paquete y a continuación el nombre del archivo .launch, como se muestra.
Asumiendo que ya se han compilado los paquetes y además los comandos dentro del
workspace que contiene los paquetes son visibles para la terminal.
Después de ejecutar estos comandos la lista de dynamixels configurados en el archivo
yaml anteriormente serán cargados y los servomotores conectados estarán
disponibles dentro del ecosistema ROS. Ahora bien, como se ha mencionado
$ cd ~/dynamixels_ws && catkin_make $ source devel/setup.bash $ roslaunch dynamixel_workbech_controllers dynamixel_controllers.launch
29
anteriormente para que un servomotor ejecute una posición desde un comando se
debe hacer la llamada al servicio <</dynamixel_ command>>, esto se puede hacer
desde rqt o usando la línea de comandos así:
El siguiente paso es la creación del archivo de configuración que se aprovecha como
insumo en el archivo joint_operator.launch. Aquí son llamados los servomotores que
fueron configurados en el primer archivo yaml, siguiendo el ejemplo, de la combinación
funcional de estos dos archivos resultaría una configuración como la que sigue:
Dentro de este archivo se crean los comandos formados por los pares motor –
posición que tendrán que seguir los servomotores. El archivo se forma por dos mapas;
joint y motion de configuración para el nodo operators. El primer mapa incluye la lista
names, que comprende los nombres de todos los servomotores configurados en el
primer archivo yaml. Siguiendo el ejemplo, los servomotores con id 1 y 2,
respectivamente dentro de la lista. El segundo mapa incluye una nueva lista names
formada por una lista de vectores asociativos, estos vectores comprenden dos claves,
la primera nombrada step, es una lista de ángulos en radianes a los que el servomotor
debe ir, estas listas son emparejadas con las listas names del mapa joint, de manera
que, siguiendo el ejemplo, en el vector de nombre <<centro>> el servomotor con la id
1 tomará la posición 0 radianes y el servomotor con la id 2 tomará la posición 2.6
radianes, y en el vector de nombre <<arriba>> intercambiaran de posiciones, así
mismo estas listas deberán contar con la misma cantidad de elementos.
Nodo operators
La edición del paquete operators comienza con el archivo de cabecera, que dentro del
ámbito de este proyecto suma algunas declaraciones adicionales. En concreto se
agregó un tema, que junto a el tema existente forman la infraestructura de
comunicación que usara el nodo para publicar las trayectorias a seguir por cada uno
de los <<grupos cinemáticos>> formados, además se ampliaron las llamadas a los
$ rosservice call /dynamixel_workbench/dynamixel_command “command: ‘‘ id: 1 addr_name: ’Goal_Position’ value: 1023”
joint: names: [nom_servo1, nom_servo_servo2] motion:
names: [centro, arriba] centro: step: [0.0, 2.6] time_from_start: 1.0 arriba: step: [2.6, 0.0] time_from_start: 2.0
30
servicios, obligatorios para cada mensaje de trayectoria diferente (lista de vectores
asociativos dentro del mapa motion).
Lo siguiente fue la edición del archivo de código fuente del nodo, para este archivo se
implementaron las declaraciones que fueron adicionadas en el archivo de cabecera.
Es práctico mencionar que el algoritmo de publicación usado en el nodo comienza con
el llamado a la función <<getTrajectoryInfo()>> que recibe como argumentos el
nombre del archivo yaml que contiene los comandos de locomoción, una instancia
JointTrajectory y un string. La finalidad de esta función es cargar los vectores
asociativos dentro del archivo yaml en las instancias JointTrajectory, el valor de
asignación al argumento string se usa como recurso para cargar el mapa de igual
nombre. Por ejemplo, la línea de código para cargar el mapa de nombre motion en la
estructura mostrada antes es como sigue:
El valor asignado al string yaml_file es un parámetro de asignación del archivo launch
del paquete. La función retorna un valor booleano, que será verdadero si el archivo
yaml está bien estructurado.
Ahora bien, el siguiente paso realizado para la publicación de los comandos es la
creación del servicio, como se indica en los tutoriales de la página oficial ros, partiendo
desde una interfaz y, posteriormente llamando a la función adverticeService. Esta
recibe como argumentos el nombre del servicio y el nombre de la funcion callback que
iniciara al ser llamada, así:
Este servicio, al igual que la función callback estan declarados en el archivo de
cabecera. La función callback es la encargada de realizar la publicación del mensaje,
de tal manera que al llamar al servicio se publicara el mensaje. A continuación, se
mostrará la estructura de publicación dentro de la función callback.
• a los motores
• Visualización del robot en ROS (URDF+RVIZ)
• Planeamiento de trayectorias.
std::string yaml_file = node_handle_.param<std::string>("trajectory_info_", ""); jnt_tra_msg_ = new trajectory_msgs::JointTrajectory; bool result = getTrajectoryInfo(yaml_file, jnt_tra_msg_, "motion");
move_command_server_ = node_handle_.advertiseService("nom_servicio", &JointOperator::moveCommandMsgCallback, this);
bool JointOperator::moveCommandMsgCallback(std_srvs::Trigger::Request &req, std_srvs::Trigger::Response &res) { joint_trajectory_pub_.publish(*jnt_tra_msg_); res.success = true; res.message = "Success to publish joint trajectory"; ROS_INFO("Avance"); return true; }
31
diseñar solo dos brazo y usar transmisión en el rdf para mover de a tres patas.
5.5. URDF
El urdf es un formato de lenguaje escrito en XML para representar el modelo de un
robot. A continuación se mostrará el URDF que se desarrolló para ROZH
En la imagen anterior se muestra la primera parte del urdf, para cada link definido hay
tres etiquetas, la etiqueta visual, la etiqueta colisión y la etiqueta inertial. En la etiqueta
visual se encuentran las características visibles de la pieza, es decir se define una
posición en el plano XYZ, sus ángulos de rotación, la escala de la pieza y la ruta en la
que se encuentra el archivo .STL. Para la etiqueta colisión se recomienda tener un
modelo simplificado del robot para que el tiempo de la realización de los cálculos de
colisión se reduzca, en caso de que se defina el mismo modelo que en la etiqueta
visual el procesamiento de datos es mayor y el tiempo para la solución de estos
cálculos es más complejo, por esta razón se coloca un modelo simplificado e igual que
32
en la etiqueta visual se define, la posición inicial en un plano XYZ, sus ángulos de
rotación, la escala de la pieza y la ruta del .STL. En la etiqueta de inercia se agregan
los valores que se obtuvieron en la matriz de inercia. Está matriz de obtiene de un
programa CAD, para el caso de este proyecto se obtuvo está matriz del software
Autodesk Inventor como se ve en la figura 16.
Fig. 16 Matriz de inercias en el software Autodesk Inventor.
Para cada link del robot se hace lo expuesto anteriormente, es decir para los 18 links de ROZH
se definen las tres etiquetas: visual, collision e inertial.
33
Fig. 17 Definición del primer link de la extremidad uno.
El robot ROZH cuenta con 18 joint, es decir 3 por extremidad y en el urdf van definidos de la
siguiente forma:
Fig. 18 Definición de los joint de una extremidad.
34
En la figura 18, nos muestra como se definen los joint en el URDF del robot, se da el parámetro
de un link padre y un link hijo, como es un joint de tipo continuo se debe especificar el eje de
rotación y su posición inicial. Lo mostrado en la figura 18 se repite para cada una de las
extremidades por lo tanto se tienen que definir 18 joint dentro del urdf.
Resultados.
• Se hicieron dos grupos de locomoción uno formado por las extremidades 1,4, y
6 y el otro con las extremidades restante 2, 3, y 5, esto se hizo con el fin de
reducir el número de controladores para la simulación del robot
• El OMPL (planeador de trayectorias de moveit) es el encargado de planear las
trayectorias. Estas trayectorias en las que van definidas dos poses, la pose
inicial de la extremidad y la pose a la que se quiere llegar, es decir a una pose
final.
Fig. 19 Definición de las posiciones finales del robot.
35
Fig. 20 Planeación de trayectorias en moveit
Fig. 21 Simulación en gazebo
36
6. Agradecimientos
Jorge Ivan Labrador Aya.
En primer lugar, quiero agradecer a mi madre Luz por ser el pilar más importante, a
mis abuelos maternos Ana y Custodio, y a mi tío Alex, su esposa victoria y sus hijos
Jimmy y Estaban, a mis hermanas Valentina Y Nikol por el amor, el esfuerzo y el
apoyo incondicional que me ofrecieron para llegar a cumplir una meta más, gracias por
inculcar en mí, valores los cuales fueron de vital importancia para cumplir este logro.
También un agradecimiento a la Familia Rangel parales, por brindarme su apoyo en
un momento crucial para culminar esta meta.
Así mismo, quiero expresar mi agradecimiento al director de proyecto Olmer Garcia,
por habernos guiado, aconsejado y corregido a lo largo del desarrollo de este
proyecto, a mis compañeros de grupo por ser partícipes del desarrollo de esta etapa
en especial a mi compañero de tesis Diego.
Diego Fernando Romero
Quiero agradecer a mis padres, y a mis hermanos que fueron el pilar para que pudiese
cumplir esta meta, gracias por brindarme su apoyo, su amor y su paciencia.
También quiero agradecer al director de proyecto Olmer Garcia, a mis compañeros de
grupo por ser partícipes de mi crecimiento en el ámbito profesional.
37
7. Conclusiones
• Para un robot zoomórfico de seis extremidades la cinemática es más compleja
que la de un robot con cuatro extremidades, pero la ventaja de un mayor
número de extremidades en el robot es la estabilidad. Y en comparación a un
robot con locomoción de ruedas, un robot con extremidades se puede
desempeñar mejor en diferentes tipos de terreno.
• Para proyectos de robótica es esencial desarrollar una buena simulación, esto
hace que se reduzcan los recursos del proyecto (tiempo, dinero) y no se
arriesgar el hardware del robot.
• Dentro del diseño del robot hay que asegurar que las uniones no presenten
inercias exageradas que se traducen en picos de corrientes que puedan llegar
a dañar el hardware del robot. Además, se debe seleccionar adecuadamente
los materiales de las piezas en términos de resistencia mecánica y masa
evitando que los actuadores del robot tengan que soportar pesos excesivos y
asegurando que las piezas resistan.
• La principal ventaja de usar ROS es que es una plataforma open source, hay
paquetes desarrollados por la comunidad que se pueden usar en el proyecto
para agregar valor, y robustez. Además la comunidad de ROS es bastante
amplia y en los últimos años viene aumentando más y más, esta brinda soporte
es cada paquete que han desarrollado
• Para la simulación de un robot con uniones paralelas resulta útil usar la
etiqueta mimic la cual hace que se reduzcan el número de controladores, en el
caso de este proyecto sin esta etiqueta se ocupan 6 controladores es decir un
controlador por extremidad, con esta etiqueta se redujeron a dos controladores.
Un controlador por cada grupo de 3 extremidades.
38
8. Referencias
Arroyo, R. C. (2017). Sistema de control para robot hexápodo de exploración. Madrid, España.
Bañó, C. I. (2015). Diseño monitorización y control de un hexápodo con ROS. Valencia.
Chile, U. d. (s.f.). UdeSantiagoVirtual. Recuperado el 07 de 06 de 2020, de
http://www.udesantiagovirtual.cl/moodle2/mod/book/view.php?id=24819
Dominguez, C. G. (2015). Aplicaciones orientadas a la domotica con raspberry pi. Sevilla.
Foundation, O. S. (2020). SDFormat. Recuperado el 05 de 06 de 2020, de http://sdformat.org/
Franco Tedeschi, G. C. (2014). Design Issues for Hexapod Walking Robots . Robotics.
Luis Vivas, H. M. (s.f.). Arquitecturas de software con Websocket para aplicaciones web
multiplataforma. Recuperado el 07 de 06 de 2020, de
https://www.researchgate.net/publication/268150437_Arquitectura_de_software_co
n_websocket_para_aplicaciones_web_multiplataforma
Open Robotics. (s.f.). ROS. Recuperado el 11 de 02 de 2020
Open Source Robotics Foundation. (2014). Gazebo: Tutorials Beginner: Overview. Recuperado
el 06 de 04 de 2020, de http://gazebosim.org/tutorials?cat=guided_b&tut=guided_b1
PickNik. (s.f.). Moveit. Recuperado el 07 de 06 de 2020, de https://moveit.ros.org/
Raspberry Shop. (s.f.). Recuperado el 07 de 06 de 2020, de
https://www.raspberryshop.es/guia-completa-raspberry-pi.php
Tzancoff, M. D. (2011). Comparación de performance e implementación de aplicaciones web.
La plata.
Wyrobek, K. (31 de Oct de 2017). IEEE spectrum. Recuperado el 11 de 03 de 2020, de The
Origin Story of ROS, the Linux of Robotics:
https://spectrum.ieee.org/automaton/robotics/robotics-software/the-origin-story-of-
ros-the-linux-of-robotics
