Post on 20-Jul-2020
Paola Sanchez Chacon
Control de un vehículo autónomo no tripulado a través
de ROS
TRABAJO DE FIN DE GRADO
Dirigido por el Dr. José Luís Ramírez Falo
Grado en Ingeniería Electrónica Industrial y Automática
Tarragona
2018
2
Control de un vehículo autónomo no tripulado a través de ROS Agradecimientos
3
Agradecimientos
Me gustaría agradecer a todas las personas que han hecho posible este proyecto.
En primer lugar a mi tutor, el Dr. José Luís Ramírez Falo, sin el cual no me hubiera
lanzado a esta aventura tan atrevida e inesperada. Gracias a su apoyo y a sus ganas de
superación de obstáculos que transmite, he podido realizar este proyecto sin dejar de ser
yo misma.
A mi familia por ayudarme en todo lo que han podido y más.
A la asociación URBots por dejarme todo este magnífico material, sin el cual no hubiera
podido realizar el proyecto. Y también por dejar que les importunara con mis preguntas
sobre este nuevo mundo para mí.
Por último, y no por ello menos importante, mi pareja, con la que he compartido los
momentos de frustración, alegría y decepción y la cual me ha apoyado en todo a pesar
de él también estar realizando su propio TFG.
Control de un vehículo autónomo no tripulado a través de ROS Índice
4
Índice
Introducción ...................................................................................................................... 7
1.1. ¿Qué es conducción autónoma? ......................................................................... 7
1.1.1. Conducción autónoma en vehículos ........................................................... 8
1.1.2. Conducción autónoma en robots ................................................................ 8
1.2. Sistemas utilizados en conducción autónoma .................................................... 8
1.2.1. Hardware .................................................................................................... 8
1.2.1.1. Cámara de visión ................................................................................. 8
1.2.1.2. Sensor infrarrojo .................................................................................. 9
1.2.1.3. LIDAR ............................................................................................... 10
1.2.1.4. Sensor ultrasónico ............................................................................. 11
1.2.2. Software .................................................................................................... 12
1.2.2.1. SAM .................................................................................................. 12
1.2.2.2. Apollo ................................................................................................ 13
1.2.2.3. ROS ................................................................................................... 13
1.3. Grados de automatización ................................................................................ 14
1.3.1. Según la SAE ............................................................................................ 14
1.3.2. Según la CEA ........................................................................................... 15
Memoria descriptiva ....................................................................................................... 17
2.1. Objeto del proyecto .......................................................................................... 17
2.2. Alcance ............................................................................................................ 17
2.3. Antecedentes .................................................................................................... 17
2.4. Recursos ........................................................................................................... 18
2.4.1. Hardware .................................................................................................. 18
2.4.2. Software .................................................................................................... 18
2.5. Metodología ..................................................................................................... 18
2.5.1. Que hay actualmente y que implementar ................................................. 19
2.5.2. Comprobar el estado de los componentes ................................................ 19
2.5.3. Realización del código.............................................................................. 22
Hardware del robot ......................................................................................................... 26
3.1. Introducción ..................................................................................................... 26
3.2. Conexiones físicas del hardware ...................................................................... 26
3.3. Componentes del robot .................................................................................... 30
Control de un vehículo autónomo no tripulado a través de ROS Índice
5
3.3.1. LIDAR ...................................................................................................... 30
3.3.2. Cámara ...................................................................................................... 32
3.3.3. Motores ..................................................................................................... 33
3.3.4. USB2Dynamixel ....................................................................................... 35
3.3.5. PCB ........................................................................................................... 37
3.3.5.1. Funciones .......................................................................................... 37
3.3.5.2. Diseño................................................................................................ 38
3.3.6. Batería ....................................................................................................... 39
3.3.7. PC ............................................................................................................. 40
Software implementado .................................................................................................. 42
4.1. Software del PC ............................................................................................... 42
4.1.1. Elección e instalación del sistema operativo Ubuntu ............................... 42
4.1.2. Elección e instalación de ROS ................................................................. 42
4.1.3. Problemáticas y soluciones ....................................................................... 43
4.2. Software del robot ............................................................................................ 43
4.2.1. Creación del espacio de trabajo ................................................................ 43
4.2.2. Creación de los paquetes .......................................................................... 45
4.2.3. Comunicación ........................................................................................... 48
4.2.3.1. Sensores-PC ...................................................................................... 48
4.2.3.2. Motores-PC ....................................................................................... 51
4.2.3.3. Sensor-Motores ................................................................................. 51
4.2.4. Tratamiento de la información ................................................................. 52
4.2.4.1. Datos del LIDAR .............................................................................. 52
4.2.4.2. Datos de los motores ......................................................................... 54
Puesta en marcha y resultados ........................................................................................ 56
Conclusiones ................................................................................................................... 69
Futuros desarrollos ......................................................................................................... 70
Referencias ..................................................................................................................... 71
Anexo ............................................................................................................................. 79
9.1. Código .............................................................................................................. 79
9.1.1. Contenido del fichero de mensaje “LaserScan” ....................................... 80
9.1.2. Código fuente “check_obstacle_node” ..................................................... 82
9.1.3. Contenido del fichero de mensaje “Comunication” ................................. 85
Control de un vehículo autónomo no tripulado a través de ROS Índice
6
9.1.4. Código fuente “motor_simulation_node” ................................................. 86
9.2. Representación de la comunicación entre los nodos........................................ 90
9.3. Modificaciones en la PCB ............................................................................... 91
9.3.1. Imagen 9.3.a. ............................................................................................ 91
9.3.2. Imagen 9.3.b. ............................................................................................ 92
9.3.3. Imagen 9.3.c. ............................................................................................ 93
9.4. Tabla de la interpretación de la información del sensor LIDAR. .................... 93
9.5. Tabla de interpretación para saber el giro de los motores. .............................. 96
9.6. Tabla de control de los motores ....................................................................... 96
9.7. Mensajes del “topic” “scan” ............................................................................ 98
Control de un vehículo autónomo no tripulado a través de ROS Introducción
7
Introducción
Lo que intento conseguir con este proyecto es que un “vehículo” robótico, cedido por la
asociación URBots y que anteriormente ya había sido utilizado para otros fines algo
similares, conduzca de forma autónoma con un nuevo sistema operativo más rápido y
más utilizado en el mundo de la robótica.
Este proyecto está estructurado en seis temas: Conocimiento del antiguo entorno,
conocimiento del nuevo entorno, instalación del mismo, comunicación de los sensores-
entorno de trabajo y motores-entorno de trabajo, escritura del código y puesta en marcha
y resultados.
En el primer tema, investigamos sobre los componentes y anterior utilización del robot
para comprender su estructuración e historia.
En el segundo tema, encontramos la recolección de toda la información necesaria para
comprender el funcionamiento del nuevo entorno en el que vamos a trabajar y las
compatibilidades que este tiene con los elementos que conforman del “vehículo”.
En el tercer tema, veremos cómo he realizado la instalación del SO desde cero y la
plataforma ROS Kinetic con los cuales trabajaremos.
En el cuarto tema, se encuentran los llamados “paquetes” de ROS, a través de los
cuales conseguimos la comunicación con los sensores y los motores.
En el quinto tema, veremos fragmentos de la escritura de los diferentes códigos
utilizados en el proyecto.
En el sexto tema, se encuentran las diferentes fases por las que se ha avanzado durante
el proceso de puesta en marcha del vehículo y los resultados obtenidos.
1.1. ¿Qué es conducción autónoma?
La conducción autónoma es una modalidad de conducción. Esta consiste en el manejo
del vehículo o robot sin el control activo de una persona cuando su tecnología está
activa. Un vehículo o robot autónomo está considerado como tal cuando está equipado
con la suficiente tecnología como para que este permita su manejo sin precisar
activamente el control o supervisión de un “conductor”, tanto si esta tecnología
autónoma está activada o desactivada, de forma permanente o temporal. [1]
Control de un vehículo autónomo no tripulado a través de ROS Introducción
8
1.1.1. Conducción autónoma en vehículos
La conducción autónoma en vehículos, se define por la capacidad de un vehículo de
imitar las capacidades humanas de manejo y control. Como vehículo autónomo, es
capaz de percibir el medio que le rodea y navegar en él.
Estos perciben el entorno mediante técnicas complejas como láser, radar, LIDAR,
sistema de posicionamiento global y visión computarizada. Una vez percibido el
entorno, los sistemas de control interpretan la información y con ello identifican la ruta
a seguir, los obstáculos y las señalizaciones. [2]
1.1.2. Conducción autónoma en robots
Un robot autónomo es un robot que puede operar con alto grado de autonomía, deseable
normalmente en campos como la exploración espacial y tareas difíciles de hacer para el
hombre, ya sea porque son complejas, tediosas o en espacios reducidos.
Un robot autónomo tiene la capacidad de obtener información del entorno, trabajar y
moverse a través de su entorno operativo durante un período prolongado sin
intervención o ayuda humana. También tiene la capacidad de evitar situaciones que son
perjudiciales para las personas, bienes o sí mismos y poder aprender o adquirir nuevos
conocimientos, como el ajuste de nuevos métodos, para el cumplimiento de su objetivo
o adaptación a los cambios de su entorno. [3]
1.2. Sistemas utilizados en conducción autónoma
Los sistemas utilizados en la conducción autónoma se pueden clasificar en hardware y
software.
1.2.1. Hardware
Algunos de los componentes electrónicos que se utilizan en la conducción autónoma
son los siguientes.
1.2.1.1. Cámara de visión
Control de un vehículo autónomo no tripulado a través de ROS Introducción
9
Las cámaras de visión artificial usadas en los vehículos analizan, principalmente, las
señales de tráfico. Con esto el sistema puede realizar el control de la velocidad a la que
va el vehículo, tanto en situaciones habituales como en extraordinarias, ej. obras en
carretera.
Imagen 1.2.1.a. Dúo de cámaras de visión [4]
Imagen 1.2.1.b. Cámara de visión [5]
1.2.1.2. Sensor infrarrojo
El sensor de infrarrojos es un sensor de medición de distancia, que se basa en un sistema
de emisión/recepción de radiación lumínica en el espectro de los infrarrojos. Este
sistema es en el que se basa el funcionamiento del LIDAR, anteriormente mencionado.
[6]
Con esto el sistema puede realizar el control de aparcamiento del vehículo.
Control de un vehículo autónomo no tripulado a través de ROS Introducción
10
Imagen 1.2.1.c. Sensado de sensores infrarrojos en el adelantamiento [7]
Imagen 1.2.1.d. Sensor de infrarrojos [6]
1.2.1.3. LIDAR
El LIDAR, acrónimo de Laser Imaging Detection and Ranging, es el componente
electrónico que proporciona al coche la capacidad de “ver” y por tanto reconocer y
detectar objetos en la carretera contra los que pudiéramos chocar. El funcionamiento de
este elemento, consiste de manera muy básica en un foco emisor de haces de rayos láser
infrarrojos, y una lente receptora de los mismos una vez han rebotado en los objetos.
Hay dos tipos: fijos, aunque hacen girar su receptor de señal, y giratorios. Los primeros
cubren entre 170º y 250º, dependiendo del modelo, y los segundos cubren los 360º
girando sobre sí mismo para cubrir todo el entorno.
Control de un vehículo autónomo no tripulado a través de ROS Introducción
11
Imagen 1.2.1.e. LIDAR de tipo giratorio [8]
Imagen 1.2.1.f. Mapeo de un vehículo [9]
Imagen 1.2.1.g. Posicionamiento de LIDAR en un vehículo (posicionamiento lateral [10] y en parabrisas [11] de
izquierda a derecha)
1.2.1.4. Sensor ultrasónico
Los sensores ultrasónicos usados en los vehículos, analizan las distancias entre el
mismo y los objetos que lo rodean. Con esto el sistema puede, por ejemplo, realizar el
control del aparcamiento del vehículo de una forma muy precisa.
Su funcionamiento básico es el de emitir una onda sónica y recibir ésta misma reflejada
una vez ha rebotado en el objeto.
Control de un vehículo autónomo no tripulado a través de ROS Introducción
12
Imagen 1.2.1.h. Modelos de sensor ultrasónico [12]
Imagen 1.2.1.i. Lugar de instalación de los sensores ultrasónicos para la ayuda del aparcamiento [13]
1.2.2. Software
El software básico para realizar los códigos es uno de tiempo real. Esto es debido al
hecho de tener que tratar variables muy diversas de forma rápida, para poder tomar las
medidas y/o realizar las acciones necesarias en el menor tiempo posible.
A continuación describiré algunos de los software usados para la conducción autónoma
tanto en vehículos como en robótica.
1.2.2.1. SAM
SAM son las siglas Seamless Autonomus Mobility, o movilidad inteligente constante.
Este es un sistema de Inteligencia Artificial de Nissan, en colaboración con la NASA,
Control de un vehículo autónomo no tripulado a través de ROS Introducción
13
con el que el fabricante pretende optimizar la toma de decisiones de los coches
autónomos en situaciones especialmente complejas o impredecibles. Con este software
se está tratando la problemática de toma de decisiones por parte del vehículo, para ello
utiliza una técnica de aprendizaje de la conducción como la que realizaría un conductor
“humano” mientras adquiere experiencia. Esta experiencia es la que le servirá para
elegir las decisiones más adecuadas ante situaciones, según el esquema: observación del
entorno, selección de estímulos que interesan, comparación con otras situaciones, toma
de decisión y ejecución de la decisión.
Este software está diseñado para que un consultor humano, un gestor especialista en
movilidad, sea quién enseñe al coche, lo que sería equivalente a un profesor de
autoescuela pero para coches. Posteriormente este adquiriría su experiencia a partir de
sus vivencias y tomas de decisiones suyas y de otros vehículos, las cuales se encuentran
en la nube.
1.2.2.2. Apollo
Apollo es un programa de conducción autónoma desarrollado por la empresa china del
motor Baidu. Este programa se distribuye gratuitamente para todo aquel que quiera
usarlo. Este programa se está enfocando actualmente para los sistemas de transporte
públicos, como autobuses, los cuales realizan rutas programadas o vehículos de
trayectos cortos para personas con discapacidad. Este software le da la capacidad a los
vehículos autónomos de responder de la “manera educada” cuando se encuentra con un
humano o una señal de stop, y actúa de forma cautelosa entre ciclistas. A pesar de todo
este desarrollo aún queda mucho por recorrer. [14]
1.2.2.3. ROS
ROS son las siglas Robot Operating System, se trata de un meta sistema operativo de
código abierto mantenido por la Open Source Robotics Foundation (OSRF). Este meta
sistema proporciona los servicios que ofrece un SO, como abstracciones de hardware,
control de dispositivos a bajo nivel, paso de mensajes entre procesos, etc; además de
esto también proporciona herramientas y librerías para obtener, compilar, escribir y
ejecutar código a través de múltiples ordenadores.
Su funcionamiento se basa en una composición de nodos independientes, escritos en
C++ o Python, los cuales se comunican entre ellos utilizando el sistema modelo de
publicador/subscriptor. Con esto los distintos nodos procesan y controlan distintos
dispositivos y se comunican entre ellos con la ayuda de un nodo “Master”. Este SO está
diseñado para ser modular en escala de grado fino. [15]
Control de un vehículo autónomo no tripulado a través de ROS Introducción
14
1.3. Grados de automatización
En este apartado veremos los diferentes grados de automatización, según el
Comisariado Europeo del Automóvil (CEA) [16] y la Sociedad de Ingenieros de la
Automoción (SAE). [17]
1.3.1. Según la SAE
Esta sociedad define los grados de automatización de un vehículo de la siguiente forma:
-Nivel 0: todas las acciones son realizadas en su totalidad por el conductor. Se trata de
coches que cuentan únicamente con dispositivos de alerta, ya sean luminosos o sonoros.
-Nivel 1: se introduce un primer grado de automatización. El automóvil puede tomar el
control del volante o de los pedales, pero no de los dos a la vez. Los coches con
controles de velocidad adaptativos y asistentes de mantenimiento de carril estarían en
esta categoría.
-Nivel 2: el coche, en determinados escenarios, puede controlar tanto los pedales como
la dirección. En cualquier caso, el conductor sigue siendo el único responsable de la
conducción y debe permanecer atento a la carretera en todo momento. Los modelos
capaces de aparcar de forma completamente autónoma se encuadran en esta categoría.
-Nivel 3: un vehículo de este nivel asume las tareas de manejo en determinadas
condiciones gracias a la motorización del entorno 360º, pero el conductor tiene que estar
dispuesto en todo momento para retomar el control cuando el sistema lo solicite. El
coche, mientras conduce con el dispositivo activado, puede tomar decisiones como
cuándo cambiar de carril, así como responder a los incidentes que pudiesen ocurrir en el
trayecto. Todo ello, con el respaldo del humano.
-Nivel 4: en este grado de automatización ya no es necesaria la supervisión de un
humano. El coche es capaz de circular por sí solo en un gran número de escenarios y, en
caso de detectar algún contratiempo, está capacitado para detenerse progresivamente en
el arcén. Actualmente, no hay coches en el mercado con este nivel de automatización.
-Nivel 5: el conductor y los pasajeros se desentienden de la conducción. De hecho,
fabricantes como Ford y General Motors ya han anunciado que sus coches futuros
prescindirán de volante y pedales. Asimismo, BMW mostró en el Mobile World
Congress 2018 el funcionamiento de un i3 dotado de esta tecnología. No obstante, para
que sea viable la llegada al mercado de este tipo de coches se antoja esencial, además de
un cambio en la legislación de tráfico, lograr la conectividad vehículo a vehículo (V2V)
y vehículo a infraestructura (V2I), un objetivo cuya demora depende en gran medida del
tiempo que tarde en implementarse el sistema de comunicación 5G.
Control de un vehículo autónomo no tripulado a través de ROS Introducción
15
1.3.2. Según la CEA
Los grados de automatización de un vehículo según este comisariado son:
-Nivel 0: Sin automatización en la conducción. Todas las acciones son realizadas en su
totalidad por el conductor.
-Nivel 1: Asistencia en la conducción. El vehículo cuenta con algún sistema de ayuda a
la conducción, como por ejemplo: mantenimiento del carril, controles de velocidad
adaptativos o no. Este nivel está pensado para que el conductor pueda tener una
conducción más cómoda, es una ayuda que mejora la seguridad al volante.
-Nivel 2: Automatización parcial. Se precisa conductor, aunque este no realizará tareas
relativas al movimiento. El vehículo cuenta con control de movimiento tanto
longitudinal como lateral, aunque no tiene detección y respuesta ante objetos. El
vehículo tendrá capacidad de actuar de forma independiente ya que pueden realizar una
o varias tareas hasta ahora realizadas por el conductor.
-Nivel 3: Automatización condicionada. Se precisa conductor y aunque la autonomía
sea más elevada, este deberá estar atento para intervenir. Tiene sistemas de
automatización en lo referente al control de movimiento longitudinal y lateral; detección
y respuesta ante objetos. El vehículo podrá decidir cuándo cambiar de carril, frenar para
evitar colisionar con otro vehículo, etc., pero, el factor humano seguirá siendo clave ya
que el sistema puede precisar de su intervención.
-Nivel 4: Automatización elevada. No se precisará de la intervención humana en ningún
momento ya que será el propio vehículo quién controlará el tráfico y las condiciones del
entorno, definirá la ruta o alternativas y responderán ante cualquier situación. En el caso
de existir algún fallo del sistema principal, el vehículo cuenta con respaldo para actuar y
seguir conduciendo.
-Nivel 5: Automatización completa. El vehículo tendrá la capacidad, bajo demanda
realizada a través del interfaz por el que se introducirán nuestras órdenes, de ir a
cualquier lugar sin necesidad de volante, pedales ni mandos, ya que, el vehículo cuenta
con sistemas de automatización a todos los niveles. A este nivel la figura del conductor,
no existe, subiremos al coche, le indicaremos nuestro destino y este se pondrá en
marcha. Cuentan con un sistema de automatización que en caso de fallo se respaldará
con otro sistema, por lo que, él mismo solucionará cualquier imprevisto.
Control de un vehículo autónomo no tripulado a través de ROS Introducción
16
Imagen 1.3.2.a. Diagrama de grados de automatización [16]
Control de un vehículo autónomo no tripulado a través de ROS Memoria descriptiva
17
Memoria descriptiva
2.1. Objeto del proyecto
El objeto de este proyecto es conseguir la conducción autónoma de un “vehículo”, a
pequeña escala, a través del sistema operativo Ubuntu y la plataforma ROS Kinetic.
Para poder lograrlo se han seguido las siguientes pautas:
- Conocer el funcionamiento anterior del robot para comprender su estructuración.
- Determinar el sistema operativo compatible con los sensores y demás elementos
que conforman el vehículo autónomo y la plataforma ROS Kinetic.
- Realizar la instalación de este sistema operativo y de la plataforma ROS Kinetic.
- Realizar la comprobación del correcto funcionamiento y conexión del LIDAR y
los motores.
- Realizar el programa.
- Comprobar que el sistema en conjunto funciona, a través de una puesta en
marcha.
La finalidad de este proyecto es el conocimiento de las nuevas formas de conducción
que se encuentran a la orden del día, además de nuevas formas de programación y
plataformas de desarrollo desconocidas para mí hasta el momento; y que todo esto me
lleve a realizar la conducción autónoma de este “vehículo”.
2.2. Alcance
El alcance de este proyecto es la realización tanto del software como la implementación
e instalación de este en el nuevo hardware y la puesta en marcha del robot.
2.3. Antecedentes
Este robot, utilizado en un proyecto de final de carrera anterior, procede de la familia de
robot San Bernardo y es la tercera versión. Su diseño estaba hecho para la utilización de
varios sistemas de guía como GPS, acelerómetro, cámara, etc. sin embargo, para este
proyecto se utiliza otro llamado LIDAR. Además de esto, el sistema operativo utilizado
Control de un vehículo autónomo no tripulado a través de ROS Memoria descriptiva
18
en esa versión era un PC con sistema Windows, en esta ocasión se ha cambiado por un
PC nuevo con sistema operativo Ubuntu para un procesado de datos más rápido.
2.4. Recursos
Los recursos utilizados en este proyecto se dividen, principalmente, en hardware y
software. A continuación se realizará una breve descripción de los mismos, ampliada
posteriormente.
2.4.1. Hardware
El hardware en el que se basa este proyecto es el robot Turing, utilizado en anteriores
proyectos con el nombre de San Bernardo V3. Consiste, principalmente, en un robot
móvil de cuatro ruedas motrices con un diseño que le permite el desplazamiento por
terrenos desiguales y de difícil circulación.
Además de esto, como se ha mencionado anteriormente, se le ha cambiado el PC por
uno nuevo y con mayor potencia.
2.4.2. Software
Para la creación del código que controle los sensores y motores se ha usado ROS
Kinetic sobre un sistema operativo Ubuntu. ROS es un meta sistema operativo de
código abierto muy usado en la actualidad en el mundo de la robótica, en la
investigación, educación e industria. Su modo de funcionamiento se basa en un número
de nodos independientes que se comunican con otros nodos utilizando un modelo
publicador/subscritor.
Para configurar los motores y verificar su correcto funcionamiento, se utilizó el SO
Windows y el programa RoboPlus 1.0, de libre descarga y disponible en internet.
2.5. Metodología
Para alcanzar el objeto de este proyecto se han llevado a cabo tres tareas principales que
se explican a continuación.
Control de un vehículo autónomo no tripulado a través de ROS Memoria descriptiva
19
2.5.1. Que hay actualmente y que implementar
Los componentes electrónicos del robot, a utilizar en este proyecto, ya están montados
en el mismo, motores y LIDAR, no obstante se ha de hacer de cero la implementación
del nuevo sistema operativo en el nuevo PC y su software, ROS, además del código del
control y comunicación de los componentes anteriormente mencionados.
2.5.2. Comprobar el estado de los componentes
Para comprobar el estado de los motores, utilizaremos el software RoboPlus 1.0 [18]
que nos proporciona el fabricante de los motores. Para ello seguimos los siguientes
pasos:
Imagen 2.5.2.a. Selección del modo de conexión
Control de un vehículo autónomo no tripulado a través de ROS Memoria descriptiva
20
Imagen 2.5.2.b. Selección del puerto
Imagen 2.5.2.c. Búsqueda de los motores según su “baud rate”
Control de un vehículo autónomo no tripulado a través de ROS Memoria descriptiva
21
Imagen 2.5.2.d. Dar la orden de moverse en sentido anti horario al motor con id 1
Para la comprobación del funcionamiento del LIDAR seguí los pasos descritos en el
foro ROS Q&A [19] para el sensor Hokuyo a través del paquete “urg_node” [20]. Para
comprobar que usando este paquete se iniciaba el “topic” “scan” usé el comando:
$ rostopic list. Este también nos indica que “topics” están en ese momento abiertos
y a través de los cuales se puede establecer una comunicación.
Imagen 2.5.2.e. Lista de “topics”
Además utilicé un comando que nos proporciona una visualización, por terminal, de los
mensajes que se están publicando en el “topic” que se elija, en este caso “scan”
(Imagen 9.7).
Control de un vehículo autónomo no tripulado a través de ROS Memoria descriptiva
22
2.5.3. Realización del código
Este paso se realiza después de la instalación del nuevo software en el PC y comprobar
que tanto LIDAR como motores funcionan correctamente.
Realicé los tutoriales que se encuentran en la página de ROS tutorials [21] para los
motores. Estos tutoriales no consiguieron establecer la comunicación para la que
estaban diseñados.
Imagen 2.5.3.a. Intento de conexión con los motores a través de ROS (Parte 1)
Control de un vehículo autónomo no tripulado a través de ROS Memoria descriptiva
23
Imagen 2.5.3.b. Intento de conexión con los motores a través de ROS (Parte 2)
Se ha analizado el código fuente, procedente de open source, que compone estos
tutoriales en busca de la razón por la que no es capaz de cumplir su misión. Finalmente
después de horas de búsqueda e investigación, ya no solo en el código sino en foros y
vídeo-tutoriales, no conseguí dar con el problema; a pesar de intentar con otros
métodos, como Dynamixel SDK [22], establecer esta conexión sin éxito.
Después de invertir gran parte del tiempo en intentar resolver este inconveniente, pasé a
visualizar de forma gráfica las lecturas del sensor a través de Rviz1, siguiendo los
siguientes pasos:
1 Rviz es un visualizador gráfico propio de ROS.
Control de un vehículo autónomo no tripulado a través de ROS Memoria descriptiva
24
Imagen 2.5.3.c. Apertura del programa Rviz
Imagen 2.5.3.d. Elección del tipo de dispositivo a visualizar
Control de un vehículo autónomo no tripulado a través de ROS Memoria descriptiva
25
Imagen 2.5.3.e. Visualización gráfica de los datos del sensor
Imagen 2.5.3.f. Entorno real
Después de este paso, empecé con la realización del código de procesado de la lectura
del sensor. Más adelante, en el apartado de Software, se explica con mayor detalle que y
como se realiza.
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
26
Hardware del robot
En este capítulo se pretende dar una explicación detallada de cada componente que
conforma el robot.
3.1. Introducción
El robot objeto de este proyecto comunica el LIDAR con el PC a través de USB y los
motores a través del bus RS485 con un adaptador USB2Dynamixel para transformar la
señal, y a través de USB realizar la comunicación con el PC. A continuación se
mencionan los principales componentes del robot:
- Está dotado de una batería de litio recargable de 14,8V.
- Consta de 4 ruedas con un servomotor en cada una de ellas y se comunican mediante
el bus RS-485. Con dichos motores se consigue la tracción y dirección del robot.
- Dispone de un LIDAR. Se usa un cable USB para alimentarlo y comunicarse con él.
- La batería proporciona 14,8V, pero para poder alimentar otros componentes que
requieren otro voltaje, se fabricó una PCB.
- Dispone de un pulsador de paro de emergencia.
- Conexión para alimentar al robot sin hacer uso de la batería.
- Conexión para cargar la batería.
- Interruptor de arranque.
- Cámara con vista de profundidad.
3.2. Conexiones físicas del hardware
En este apartado se verán el antes y el después de las conexiones físicas del robot.
Debido a que cuando me lo entregaron, este carecía de algunas de las conexiones ya que
su anterior hardware se había sustraído para sustituirlo por el nuevo.
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
27
Imagen 3.2.a. Conexionado recibido
A continuación, realicé una serie de investigaciones para intentar realizar las nuevas
conexiones de la forma más segura y correcta posible para evitar dañar cualquier
componente. El antes y el después de estas conexiones se puede observar a
continuación:
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
28
Imagen 3.2.b. Antes de la conexión definitiva (Parte 1)
Imagen 3.2.c. Después de la conexión definitiva (Parte 1)
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
29
Imagen 3.2.d. Antes de la conexión definitiva (Parte 2)
Imagen 3.2.e. Después de la conexión definitiva (Parte 2)
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
30
Todas las nuevas conexiones se han realizado con fastons, excepto el GND de la señal
del USB2Dynamixel que ha sido soldado. Esta elección de tipo de conexionado es
debida a que si fuera necesario hacer cambios en el hardware, bien porque se haya
estropeado o porque se quiera reemplazar por cualquier otro motivo, el cambio y
reconexión se produzca de la forma más cómoda posible. El cable de GND ha sido
soldado ya que si se tuviera que cambiar, este cableado es independiente por lo que se
debería simplemente poner uno nuevo.
3.3. Componentes del robot
En este apartado comentaré de forma detallada el funcionamiento, conexionado y parte
más técnica de cada elemento que compone este robot.
3.3.1. LIDAR
El sistema de mapeo de entorno de este robot es el LIDAR (Laser Imaging Detection
and Ranging) Hokuyo URG-04LX-UG01, un escáner láser 2D para aplicaciones de
robótica, de la empresa Hokuyo Automatic.
Peso (g) 160
Precisión ± 3% de la medida
Interfaz USB 2.0
Alimentación 5V / 0.5 A
Rango 240º
Distancia máxima (m) 4
Frecuencia de escaneo (Hz) 10 Tabla 3.3.1.a. [23]
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
31
Imagen 3.3.1.a. LIDAR Hokuyo URG-04XL-UG01 [24]
Este componente es un LIDAR fijo con un rango de operación de 240º. Su recorrido de
escaneo es anti horario, visto desde la parte superior del mismo. Los puntos de medida
son llamados Steps. El Step 0 es el primer punto de medida. El Step A es el punto inicial
de medición en el rango de detección. El Step B es el punto central del rango de
medición y el punto de medición frontal del sensor. El Step C es el punto final de
medición en el rango de detección. El Step D es el úlimo punto de medida.
Imagen 3.3.1.b. Área de detección [24]
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
32
Imagen 3.3.1.c. Puntos de detección [25]
Imagen 3.3.1.d. Cantidad de puntos medidos [25]
3.3.2. Cámara
La cámara que tiene el robot es la BlasterX Senz3D, Esta es una cámara web inteligente
que posee tecnología y conocimientos avanzados. La característica por la que la hace
tan especial es debido a que como el ojo humano, detecta la profundidad y rastrea el
movimiento humano.
Esta cámara consta de tres lentes para capturar los datos visuales: una cámara RGB, una
cámara de infrarrojos y un proyector láser. Estas tres lentes trabajan de manera conjunta
para una mayor y completa captura de datos visuales.
Peso (g) 350
FOV (Campo de visión) 77º (RGB), 85º (profundidad de IR)
Interfaz USB 3.0
Alimentación 5V / 0.5 A
Rango de distancias 0.2 m ~ 1.5 m
Distancia máxima (m) 5.6
Respuesta de frecuencia (kHz) 0.02 ~ 20
Sensibilidad (1 kHz) 37 ± 3 dB Tabla 3.3.2.a. [26]
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
33
Imagen 3.3.2.a. Cámara BlasterX Senz3D [26]
Imagen 3.3.2.b. Partes de la cámara BlasterX Senz3D [27]
3.3.3. Motores
Este robot tiene un sistema con tracción y dirección a cuatro ruedas. Para realizar su
desplazamiento dispone de cuatro motores, uno en cada rueda, los cuales proporcionan
tracción y dirección al robot.
Estos motores, de la empresa ROBOTIS, son servomotores Dynamixel de la serie RX y
modelo RX-64 con control a través del bus RS-485. A continuación se mencionan las
características técnicas del mismo.
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
34
Peso (g) 125
Dimensión (mm) 40.2x61.1x41
Gear ratio 200:1
Operating voltage (V) 12~18.5 (recommendend14.8)
Stall Torque (N*m) 4.0 (14.8 V)
Stall Current (A) 2.1
Velocidad sin carga
(rpm) 49 (14.8 V)
Operating Range Actuator mode : 300 degrees
Wheel mode : Endless turn
Interface Protocol RS485 Asynchronus Serial Communication (8 bit, 1stop, no parity)
Motor Maxon Motor Tabla 3.3.3.a. [28]
Imagen 3.3.3.a. Motor RX-64 [29]
Como hemos dicho anteriormente, este motor se comunica con la CPU a través del bus
RS-485. Sus pines de conexión nos permiten realizar la alimentación y transmisión de
datos a través de un multicable de dos pares, uno para la alimentación y el otro para la
transmisión de datos.
Imagen 3.3.3.b. Pines de conexionado de un motor [30]
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
35
Imagen 3.3.3.c. Interconexión entre motores [30]
Como se puede observar en la imagen anterior, se puede hacer interconexión entre los
motores para realizar así un conexionado más sencillo para comunicar el PC con los
motores. Aún así se ha de hacer el conexionado de forma adecuada y teniendo en cuenta
que se cruzan los pines al conectar los motores entre ellos. Con este sistema se le envía
la orden a un solo motor, el conectado directamente al PC, y este se encarga de
transmitir esta orden a los demás motores conectados a él. Cada motor tiene un ID de
manera que en la transmisión de ordenes se puede actuar de forma independiente en
cada motor. Estos IDs son:
Imagen 3.3.3.d. ID de motores
3.3.4. USB2Dynamixel
El USB2Dynamixel es un adaptador USB a distintos modos de comunicación que es
capaz de controlar cualquier tipo de red de actuadores Dynamixel directamente desde el
PC. Este se conecta al puerto USB del PC, y los conectores 3P, 4P y RS-232 realizan la
conexión y establecen comunicación con los distintos Dynamixels.
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
36
Imagen 3.3.4.a. USB2Dynamixel [31]
Nombre Descripción
Status Display LED Muestra el estado de la alimentación, TxD
(escritura de datos) y RxD (lectura de datos)
Function Selection Switch Selecciona el método de comunicación entre
TTL, RS-485 y RS-232
3P Connector Conecta Dynamixels de la serie AX a través
del bus de comunicación TTL
4P Connector Conecta Dynamixels de las series DX y RX a
través del bus de comunicación RS-485
Serial Connector Cambia de puerto USB a puerto serie
mediante comunicación RS-232 Tabla 3.3.4.a. [31]
Imagen 3.3.4.b. Conexionado de pines de los distintos modos de comunicación [31]
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
37
USB2Dynamixel no proporciona alimentación a los Dynamixel, por lo que han de ser
alimentados aparte, como se observa en la imagen que hay a continuación.
Imagen 3.3.4.c. Aplicación de la alimentación entre USB2Dynamixel y motores Dynamixel [31]
Estos motores son compatibles con el software escogido, ROS, para realizar este
proyecto. Además, disponemos de un software desarrollado por el fabricante
ROBOTIS, el mismo que el de los servomotores, llamado RoboPlus el cual es gratuito y
nos ayuda con la asignación de IDs de los motores y su comprobación de que funcionan
de forma correcta.
3.3.5. PCB
3.3.5.1. Funciones
La PCB del robot tiene dos funciones, proporcionar las diferentes alimentaciones a cada
dispositivo y la de gestionar la carga de la batería.
Como hemos observado, el robot está formado por diferentes componentes, los cuales
se alimentan a distintas tensiones que nos puede proporcionar tanto la batería como el
cargador. Las diferentes alimentaciones son:
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
38
Además de alimentar los distintos elementos también controla el paro de emergencia,
que en caso de ser pulsado, este desconecta la alimentación de los motores para parar el
robot inmediatamente como medida de seguridad. También controla el encendido y
apagado de la alimentación a través de un pulsador.
Como he mencionado anteriormente, la PCB gestiona la alimentación de los
dispositivos y la gestión de la carga de la batería, también se encarga de la alimentación
externa. Con ello tenemos tres casos:
- Caso 1 (batería): se alimenta la PCB a través de la batería.
- Caso 2 (cargador): En el momento en que se conecta el cargador en sus
correspondientes bornes y la batería en las suyas, automáticamente se procede a
la carga de la batería; para un mayor efecto se desconecta la alimentación de la
batería de todos los componentes, optimizando así el tiempo de carga.
- Caso 3 (alimentación externa): esta es la opción a través de la cual el robot es
alimentado sin usar la batería. Para ello, se ha de conectar el cargador en las
bornes en las que se conecta de forma convencional la batería.
3.3.5.2. Diseño
Esta PCB fue diseñada por un compañero de URBots para un proyecto anterior. Este
diseño fue modificado posteriormente por el antiguo autor de dicho proyecto. A
continuación explicaré como fue diseñada y que modificación se le hizo para su
funcionamiento actual y que partes de ésta hago uso en este proyecto.
En el diseño de la PCB de la Imagen 9.3.a. se observa que las alimentaciones de la
cámara y el router son independientes a la de los motores.
Fue descubierto que así no podían funcionar los tres elementos al mismo tiempo, por lo
que el autor del antiguo proyecto optó por cortocircuitar los pines 3 y 6 del
“RELE_CONEXION”, poniendo así en conjunto la alimentación de los tres elementos y
conseguir que puedan funcionar al mismo tiempo; cortó también la entrada de
alimentación del relé, pin 5, ya que ya no era necesaria.
Motores PCB Batería
Cargador
14.8 V
16.8 V
14.8 V
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
39
A pesar de toda esta modificación en la alimentación, visible en Imagen 9.3.c., mantuvo
el paro de emergencia como medida de seguridad, de tal forma que en pulsarse, la
alimentación se desconecta.
El resultado final del circuito completo se encuentra en Imagen 9.3.b., disponible en el
anexo.
De lo que se hace uso en este proyecto de dicha PCB, por el momento, es la
alimentación de los motores. El PC usado se alimentará con su conexión a la red y el
sensor LIDAR se alimenta desde PC.
De lo que se hace uso en este proyecto de dicha PCB, por el momento, es la
alimentación de los motores. El PC usado se alimentará con su conexión a la red.
3.3.6. Batería
La batería que tiene este robot es una batería de polímero de litio del fabricante
TENERGY. Esta batería está formada por cuatro celdas de 14.8 V 10,000 mAh.
Imagen 3.3.6.a. Batería del robot [32]
Peso (g) 920
Voltage (V) 14.8
Over-charge cut-off (V) 17.4
Over-discharge cut-off (V) 9.6
Régimen de descarga continua (Amps) 5
Capacidad de la batería (mAh) 10,000 Tabla 3.3.6.a. [32]
Como se puede observar, tiene una desconexión por sobrecarga de 9.6 V; cuando fui a
poner en funcionamiento el sistema con la batería me percaté que su tensión era muy
inferior a esta, aproximadamente 6.7 V. Después de hablar y pedir consejo a los
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
40
miembros de la URBots, decidimos probar a cargar dicha batería durante
aproximadamente 15 h; después de este proceso de carga tomé medida de la tensión de
la batería y comprobé que su valor era aún menor, aproximadamente 5.6 V. Después de
estas acciones, llegué a la conclusión de que su vida útil había finalizado. Esta
conclusión fue tomada debido a que su tensión había llegado a niveles demasiado bajos;
además de haber pasado más de tres años desde su compra, tiempo de vida útil que le da
el fabricante.
Como el robot puede funcionar y obtener su alimentación de forma externa a la batería,
a través del cargador, por el momento he decidido obtenerla de esta forma y en un
futuro se puede implementar la compra de una batería nueva.
3.3.7. PC
El PC utilizado en este proyecto es el ODROID-XU4. Este es un dispositivo
informático de nueva generación con un hardware más potente y eficiente
energéticamente y un factor de forma más pequeño. Ofreciendo soporte de código
abierto, la placa puede ejecutar distintos SO, como por ejemplo varias versiones de
Linux, como el último Ubuntu 16.04, y varias de Android, como el 4.4 KitKat, 5.0
Lollipop y 7.1 Nougat. Es necesaria una tarjeta MicroSD o un módulo eMMC para
iniciar dicho sistema.
Mediante la implementación de las interfaces eMMC 5.0, USB 3.0 y Gigabit Ethernet,
el ODROID-XU4 cuenta con altas velocidades de transferencia de datos, característica
cada vez más necesaria para soportar la potencia de procesamiento. Esto permite a los
usuarios experimentar realmente una actualización en la informática, especialmente con
un arranque más rápido, navegador web, redes y juegos 3D.
Las características técnicas de este nuevo dispositivo son:
Core Samsung Exynos5422 Cortex™-A15 2Ghz
and Cortex™-A7 Octa core CPUs
Puertos USBs 2 x USB 3.0 Host y 1 x USB 2.0 Host
Puerto Ethernet Gigabit
Puerto HDMI HDMI 1.4a
Size (mm) 83 x 58 x 20 (incluyedo cooler)
Alimentación 5 V/ 4 A
Kernel Linux Kernel 4.14 LTS
PoP Stacked 2Gbyte LPDDR3 RAM
Flash Storage eMMC5.0 HS400 Tabla 3.3.7.a. [33]
Control de un vehículo autónomo no tripulado a través de ROS Hardware del robot
41
Imagen 3.3.7.a. ODROID-XU4 con ventilador de refrigeración activa [33]
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
42
Software implementado
4.1. Software del PC
En este apartado se explicaran los procedimientos seguidos para instalar el sistema
operativo y el metasistema ROS.
4.1.1. Elección e instalación del sistema operativo Ubuntu
El sistema operativo escogido para el nuevo PC de este proyecto es Ubuntu. Ubuntu es
un sistema operativo de código abierto, de fácil uso y de gran versatilidad y flexibilidad.
La versión de este sistema operativo debía ser la Wily (Ubuntu 15.0), Xenial (Ubuntu
16.0) o Jesse (Debian2 8) para su compatibilidad con la versión de ROS escogida.
Después de valorar cual es la más adecuada tanto para el núcleo o Kernel del PC como
para el procesado de datos y la capacidad del PC, he optado por la versión Xenial
(Ubuntu 16.0). Para la instalación de este SO se ha utilizado una imagen ISO3 del
Ubuntu Mate4 16.04.2 [34] quemada
5 sobre una tarjeta MicroSD.
4.1.2. Elección e instalación de ROS
El sistema sobre el que se va a trabajar con el robot es ROS (Robot Operating System).
De este meta sistema hay distintas versiones, la escogida para el proyecto es una versión
llamada Kinetic. Esta versión es compatible con todos los elementos que componen el
robot, motores, cámara y LIDAR, por lo que es la más idónea; a esto hay que añadir que
es una versión bastante nueva como para ser innovadora, pero al mismo tiempo lleva el
tiempo suficiente como para poder trabajar con ella teniendo suficiente información.
Este sistema fue instalado con la ayuda de los miembros de la URBots debido a su
anterior experiencia con éste en otros proyectos. Para realizar con éxito la instalación
debimos realizar una serie de cambios en el SO Ubuntu. Finalmente, después de varios
cambios, conseguimos con éxito dicha instalación.
2 Debian es un SO muy similar a Ubuntu.
3 Una imagen ISO es un archivo informático donde se almacena una copia o imagen exacta de un sistema de
archivos; normalmente usado para la distribución de sistemas operativos. [57] 4 Mate es el tipo de escritorio que el usuario utiliza para navegar por el SO, el descargado en este caso es: ubuntu-
16.04.2-mate-odroid-xu4-20170510.img. 5 Quemar una imagen ISO es el método usado para poder utilizar aquel sistema que contiene sin tener que hacer
cambios permanentes en el equipo. [60]
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
43
4.1.3. Problemáticas y soluciones
Antes de tener éxito en las instalaciones de dichos software tuvimos diversas
problemáticas y pasamos por distintas fases, sobre todo en lo referido al SO del PC.
Inicialmente se intentó instalar la versión de Debian 8 (minimal6) debido a su gran
utilidad en la programación, pero finalmente no era 100% adecuado para el procesador
del PC.
Indagando más sobre las versiones adecuadas y compatibles para el PC utilizado,
obtuvimos como resultado que la mejor opción era el Ubuntu 16.0 o Xenial. Primero
realizamos la instalación de esta versión de Ubuntu sin un escritorio predeterminado, es
decir minimal, para posteriormente instalar aquel que se nos adecuara. Al intentar
realizar la instalación de ROS, no se podían realizar los cambios adecuados en el SO
para poder realizarla con éxito por lo que optamos por desinstalar este SO e instalar uno
con escritorio.
Después de todo esto llegué a la opción que se instaló definitivamente, la versión
Ubuntu Mate 16.04.2 (Xenial Xerus).
En lo que a ROS se refiere realizamos varios intentos, como he dicho anteriormente,
incluso en la versión finalmente instalada de SO. Los primeros intentos la problemática
eran los SO instalados en el PC y en el último se debieron cambiar más configuraciones
del sistema de las que aparecían en los pasos a seguir por el tutorial de ROS Wiki. [35]
4.2. Software del robot
En este apartado se explicaran los procedimientos seguidos para la preparación del
espacio de trabajo y la escritura de los códigos necesarios y como funcionan estos. Todo
el proceso siguiendo los tutoriales de ROS tutorials [36].
4.2.1. Creación del espacio de trabajo
La creación del “work space” o espacio de trabajo es muy importante para tener un
orden y un espacio donde trabajar. Para ello en una terminal se ha de realizar el
siguiente comando para poder usar los comandos de ROS.
$ source /opt/ros/<distro>/setup.bash
6 La versión minimal de Debian 8 no tiene escritorio instalado
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
44
A continuación ya se puede realizar la creación del “work space” en aquel directorio
que se quiera. Para ello nos dirigimos al directorio donde se quiere y se ejecuta el
siguiente comando:
$ mkdir –p ~/“work_space_name”/src
Imagen 4.2.1.a. Creación del directorio del “work space”
Con esto ya se ha creado el espacio de trabajo como se puede observar en la imagen
superior, aunque aún no es utilizable. Para hacerlo útil se ha de ir a al directorio de
nuestro “work space” y realizar un “build” con el comando:
$ catkin_make.
Acto seguido se actualiza el mismo con el comando:
$ source devel/setup.bash
Imagen 4.2.1.b. “Work space” antes de los dos comandos anteriores
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
45
Imagenes 4.2.1.c. “Work space” después de los dos comandos anteriores
Una vez hecho esto, nuestro espacio de trabajo ya estaba listo para ser usado.
4.2.2. Creación de los paquetes
Para crear un paquete para el funcionamiento del sistema, es necesario realizar una serie
de pasos. Estos pasos varían dependiendo de si el paquete es de creación propia o es
open source.
El primer paso, en cualquiera de los dos casos es situarse en la carpeta de códigos
fuente, “src”, en el “work space”.
El segundo paso sí que discierne entre si el paquete es propio o de open source.
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
46
Si el paquete proviene de open source se puede instalar desde el “distro” del ROS que
estemos usando o clonar desde la página web de open source github. Para ello se
utilizan los siguientes comandos:
$ apt-get install ros-<distro>-“package_name”
$ git clone “link a web ‘github’”
Imagen 4.2.2.a. Instalación de paquetes procedentes de open source
Si el paquete es de creación de propia se utiliza el siguiente comando:
$ catkin_create_pkg “package_name” [depend_1] [depend_2] … [depend_n]
Imagen 4.2.2.b. Creación de paquete propio
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
47
El siguiente paso es muy importante, tanto si se ha realizado una instalación o clonaje
como un paquete propio. Este consiste en asegurarse de que para todos los archivos que
componen el paquete tengan toda la información necesaria.
Esta información puede ser tanto quiénes son sus ejecutables del paquete, las
dependencias que necesita, si se generan archivos de mensaje donde se guardan, si se
necesitan archivos de mensaje donde se encuentran o si se necesitan de otros nodos o
librerías con los que se interactúe o de los que necesite información. Toda esta
información se encuentra en los documentos llamados CMakeLists.txt, package.xml.
Este último contiene toda la meta información sobre el paquete.
Estos archivos han de componer cualquier paquete para que este pueda ser ejecutado
como nodo y pueda interactuar con los demás.
El cuarto paso, necesario para cualquier paquete de creación propia, es realizar un
archivo que contenga el código ejecutable del paquete. Para que este sea reconocido
como el ejecutable del paquete y haga su función, hay que indicarlo mediante la
ejecución del siguiente comando:
$ chmod +x “executable_file_name”
Imagen 4.2.2.c. Archivo ejecutable antes y después de hacerlo reconocible.
El quinto paso, para cualquiera de los casos, es realizar un “build” del “work space”
donde se han creado o instalado los paquetes. Este paso se ha de hacer siempre que se
haga una modificación el cualquiera de los documentos que componen un paquete. Para
realizar este paso nos debemos desplazar a la carpeta del “work space” y a continuación
usar el siguiente comando:
$ catkin_make
Despues de hacer este paso, debemos actualizar el “work space” para que este sea capaz
de ver estos nuevos paquetes. Para ello ejecutamos el siguiente comando:
$ source devel/setup.bash
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
48
4.2.3. Comunicación
4.2.3.1. Sensores-PC
La comunicación física, entre el LIDAR y el PC, se realiza a través del conector USB
proporcionado por el propio fabricante.
La transmisión de datos entre el sensor y el host se realiza mediante comandos
previamente definidos. Estos tienen un formato específico conocido como formato de
comunicación. Este formato, de forma básica, se puede ver en las figuras 4.2.1.1.a. y
4.2.1.1.b. y se denomina SCIP2.0. La comunicación es iniciada desde el host; este envía
un comando que consiste en el Símbolo de comando, Parámetro, Caracteres de cadena y
seguidamente un salto de línea o retorno de carro o ambos. Cuando el sensor recibe la
comanda envía una respuesta a través del Comando Echo o Command Echo seguido del
Status, Sum de todo lo anterior, un salto de línea, los datos relacionados con el
comando, Sum y dos saltos de línea consecutivos como terminación de la trama.
Figura 4.2.3.1.a. Trama de comunicación HOST -> SENSOR [37]
Figura 4.2.3.1.b. Trama de comunicación SENSOR -> HOST [37]
Los datos que envía el sensor son codificados para reducir el tiempo de transmisión
entre el sensor y el host. Estos datos son decodificados por parte del host antes de
procesarlos. Hay tres formas distintas en las que los datos son codificados dependiendo
del tamaño de los mismos.
Codificación de dos caracteres.
Esta técnica es usada para expresar datos cuya longitud máxima no supere los 12 bits.
La codificación se realiza separando los 6 bits más altos de los más bajos,
posteriormente se realiza su equivalencia en hexadecimal y a continuación se les suma
0x30 para convertirlos en caracteres ASCII.
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
49
Figura 4.2.3.1.c. Ejemplo de codificación de dos caracteres [37]
Figura 4.2.3.1.d. Ejemplo de decodificación de dos caracteres [37]
Codificación de tres caracteres.
Esta técnica es usada para expresar datos cuya longitud máxima no supera los 18 bits.
La codificación se realiza separando los 6 bits altos, medios y bajos, posteriormente se
realiza su equivalencia en hexadecimal y a continuación se les suma 0x30 para
convertirlos en caracteres ASCII.
Figura 4.2.3.1.e. Ejemplo de codificación de tres caracteres [37]
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
50
Figura 4.2.3.1.f. Ejemplo de decodificación de tres caracteres [37]
Codificación de cuatro caracteres.
Esta técnica es usada para expresar datos cuya longitud máxima no supera los 24 bits.
La codificación se realiza separando en cuatro partes iguales de 6 bits la totalidad de los
datos, posteriormente se realiza su equivalencia en hexadecimal y a continuación se les
suma 0x30 para convertirlos en caracteres ASCII.
Figura 4.2.3.1.g. Ejemplo de codificación de cuatro caracteres [37]
Figura 4.2.3.1.h. Ejemplo de decodificación de cuatro caracteres [37]
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
51
4.2.3.2. Motores-PC
La comunicación física, entre los motores y el PC, se realiza a través del
USB2Dynamixel, con el protocolo de comunicación RS-485.
La transmisión de datos entre los motores y el host se realiza mediante una trama con
una estructura muy concreta. Esta trama está formada por un start of frame seguido del
ID del motor sobre el que queremos actuar, la longitud del paquete, la instrucción que
queremos realizar, los parámetros necesarios para cumplimentar dicha instrucción y el
check sum7 (Figura 4.2.3.2.a.).
Figura 4.2.3.2.a. Formato de trama de envío [38]
En esta trama, el “check sum” está compuesto por la suma de: ID + length + instruction
+ parameter1 … + parameter n. Si esta suma es mayor a 255, el byte más bajo se define
como el check sum.
Una vez se le envía la trama al motor, este responde con una trama Status. Esta trama
también está formada por un start of frame seguido del ID del motor del que se recibe la
respuesta, la longitud del paquete, la codificación del error que se ha producido, si es
que se ha producido alguno, los parámetros que dan información adicional si la hay y el
check sum (Figura 4.2.3.2.b.).
Figura 4.2.3.2.b. Formato de trama de respuesta [38]
4.2.3.3. Sensor-Motores
La forma de comunicación entre el nodo que trata la información del sensor,
“check_obstacle_node”, y el nodo que se encargaría de los motores,
“motor_simulation_node”, es a través del “topic” llamado “talker_check_obst”. Este
“topic” o canal publica los campos que se encuentran en el archivo de mensaje llamado
“Comunication”. Este archivo contiene la información necesaria que, en función de las
lecturas del sensor, los motores deben usar para mover el vehículo salteando los
obstáculos del entorno.
7 El check sum es un método de computación para la comprobación de la correcta recepción de la trama.
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
52
4.2.4. Tratamiento de la información
La comunicación y tratamiento de datos son los elementos que componen este apartado.
La comunicación descrita en los siguientes apartados se encuentra como representación
gráfica en el anexo del documento (Imagen 9.2.a.)
4.2.4.1. Datos del LIDAR
La información dada por el sensor LIDAR pasa por un paquete procedente de open
source. [20] Este paquete, llamado “urg_node”, coge la información que le transmite el
LIDAR, usando el método mencionado anteriormente, y lo decodifica. La información
decodificada la publica en un archivo de mensaje llamado “LaserScan” (Contenido en
Anexo apartado 9.1.1.), el cual es publicado en el “topic” llamado “scan”. Los
parámetros publicados en el archivo de mensaje, que nosotros necesitamos, se publican
en el campo “ranges” al cual puede acceder cualquier nodo que lo necesite.
La información publicada, es de todos los puntos que analiza el sensor, un total de 768
puntos. De estos puntos he escogido siete puntos para realizar un análisis del entorno.
Estos siete puntos se encuentran repartidos por el perímetro del alcance del sensor de
forma equidistante.
Imagen 4.2.4.1.a. Puntos de escaneo escogidos
Para realizar el análisis del entorno he realizado una tabla con siete entradas y cuatro
salidas (Tabla 9.4.a.). Las entradas se corresponden a los siete puntos señalados en rojo
y las salidas a si el vehículo debe ir a derecha, izquierda, adelante o pararse. A través de
los mapas de Karnaugh simplifiqué la relación entre las entradas y las salidas
obteniendo las siguientes funciones:
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
53
(adelante)
(parar)
(girar a la derecha)
(girar a la izquierda)
Las entradas las consideré como true o verdaderas siempre y cuando fueran menores a
0.7 m las correspondientes a I, B y J, y menores a 0.5 m las L, K, G y H. También he
tenido en cuenta, que si alguno de los valores da una lectura errónea, este es
considerado como si la lectura diera un valor inferior a 0.7 m o 0.5 m, respecto a los
punto de lectura anteriormente mencionados. Además, para asegurar que no se
produjera un choque por proximidad al intentar girar a izquierda o derecha, o continuar
recto, también he definido que para cualquiera de las entradas que fuera menor a 0.3 m
se transmitiera un mensaje de frenada. Para saber en que sentido deberá girar cada
motor he creado una tabla (Tabla 9.5.a.). Simplificándola he obtenido las siguientes
expresiones:
motor_id_1 = motor_id_2 = 2 (CCW)
motor_id_1 = motor_id_2 = motor_id_3 = motor_id_4 = 0
motor_id_1 = motor_id_4 = 1 (CW)
motor_id_3 = motor_id_4 = 2 (CCW)
motor_id_3 = motor_id_4 = 1 (CW)
Estos datos se escriben en el fichero de mensaje “Comunication” (Contenido en Anexo
apartado 9.1.3.). Como se puede ver los motores nombrados con id_1 e id_2 giran en la
misma dirección y en dirección contraria a los motores con id_3 e id_4 para realizar un
movimiento hacia adelante. Esto es debido a que los motores del lado derecho están
enfrentados a los del lado izquierdo.
El código donde se encuentra todo este proceso es el código fuente del paquete, de
creación propia, llamado “check_obstacle_node” (Código en Anexo apartado 9.1.2.).
Para tener una mayor ayuda visual sobre los datos captados por el LIDAR he usado el
programa Rviz, mencionado con anterioridad. Con él he obtenido la imagen que se
muestra a continuación:
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
54
Imagen 4.2.4.2.b. Representación gráfica
4.2.4.2. Datos de los motores
Debido a lo mencionado en anteriores apartados, los motores no se han podido conectar
a este nuevo sistema. De todas formas he realizado un código que simula la generación
de tramas que se le enviarían a los motores.
Este código lee los campos del fichero de mensaje “Comunication” y en función de eso
decide si debe hacer una nueva trama o si se sigue con la misma trama anteriormente
generada. Las tramas enviadas nada más iniciar el nodo son: la trama de endless turn,
para poner a los motores en modo rueda giratoria, y la trama de paro de motores, de esta
forma aseguramos un inicio controlado y correcto.
Cada motor puede girar en distintos sentidos, CCW y CW, dependiendo de la
necesidad. Cada motor puede también girar a distintas velocidades, por ello cada motor
se ha de especificar de forma concreta. Para ello se genera una sola trama, evitando así
una desincronización entre motores. Esta trama tiene la misma estructuración inicial y
final que se ha explicado en el apartado Motores-PC. La diferencia se encuentra en los
parámetros que se le indica transmitir a los motores debido al tipo de instrucción
utilizada.
La instrucción utilizada para generar estas tramas es la SYNC WRITE. Esta se usa para
controlar varios Dymanixel al mismo tiempo. Se puede hacer uso de ella si todos los
Control de un vehículo autónomo no tripulado a través de ROS Software del robot
55
motores escriben a partir de la misma dirección en la tabla de control y la longitud de
datos a escribir es la misma. Esta trama está constituida de la siguiente forma:
start of frame: 0xFF 0xFF
ID: 0xFE (ID utilizado para referirse a varios dispositivos)
Longitud del paquete: (L+1)*N + 4 (L: longitud de los datos a escribir para cada
actuador; N: cantidad de actuadores)
Instrucción: 0x83
Parámetro1: dirección de inicio de escritura de la tabla de control de los actuadores
Parámetro 2: longitud de los datos a ser escritos (L)
Parámetro 3: ID del primer actuador
Parámetro 4: primer dato a escribir
Parámetro 5: segundo dato a escribir
…
check sum: suma de todos los componentes de la trama a partir del componente ID.
Todo este proceso se ve reflejado en el código fuente del paquete, de creación propia,
llamado “motor_simulation_node”. (Código en Anexo apartado 9.1.4.)
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
56
Puesta en marcha y resultados
En este apartado, como su nombre indica, haré mención a los pasos o puntos seguidos
para realizar una comprobación del correcto funcionamiento del código escrito durante
el proyecto.
1. Realicé las conexiones del sensor LIDAR para poder iniciar las pruebas de
detección de obstáculos a distintas distancias.
2. Pongo en marcha el nodo “roscore”8, sin el cual no pueden establecer
comunicación entre los demás nodos.
Imagen 5.2.a. Inicio de “roscore”
3. Inicié el nodo, “urg_node” y comprobé que establecía conexión correctamente a
dicho sensor.
Imagen 5.3.a. Inicio del nodo “urg_node”
8 “roscore” es una colección de nodos y programas que son prerrequisitos esenciales para un correcto
funcionamiento de un sistema basado en ROS.
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
57
4. Comprobé que estaba suscrito y/o publicaba de forma correcta en los “topics”
correspondientes.
Imagen 5.4.a. Información del nodo “urg_node”
5. Una vez este proceso está iniciado, pongo en marcha el nodo
“check_obsacle_node” y compruebo que sus suscripciones y publicaciones a los
“topics” que le corresponden son correctas.
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
58
Imagen 5.5.a. Información del nodo “check_obstacle_node”
6. A continuación, pongo en marcha el nodo “motor_simulation_node” y realizo el
mismo procedimiento que en los anteriores nodos.
Imagen 5.6.a. Inicio del nodo “motor_simulation_node”9
Imagen 5.5.b. Información del nodo “motor_simulation_node”
7. Acto seguido, inicio el programa Rviz para tener una visualización gráfica del
entorno en cada momento.
Una vez hecho esto procedo a realizar las pruebas, obteniendo los resultados que se
observan a continuación:
Detección de posible obstáculo a menos de 0.7 m frontalmente al robot en el
campo de visión del sensor.
9 Hay que tener en cuenta que justo después de iniciar este nodo no había ningún obstáculo alrededor de
robot.
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
59
Imagen 5.a. Entorno Real
Imagen 5.b. Datos por pantalla del nodo “check_obstacle_node”
Imagen 5.c. Datos por pantalla del nodo “motor_simulation_node”
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
60
Imagen 5.d. Representación gráfica de los datos del sensor
Detección de obstáculo a menos de 0.7 m a la izquierda del robot en el campo
de visión del sensor.
Imagen 5.e. Entorno Real
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
61
Imagen 5.f. Datos por pantalla del nodo “check_obstacle_node”
Imagen 5.g. Datos por pantalla del nodo “motor_simulation_node”
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
62
Imagen 5.h. Representación gráfica de los datos del sensor
Detección de obstáculo a menos de 0.7 m a la derecha del robot en el campo de
visión del sensor.
Imagen 5.i. Entorno Real
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
63
Imagen 5.j. Datos por pantalla del nodo “check_obstacle_node”
Imagen 5.k. Datos por pantalla del nodo “motor_simulation_node”
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
64
Imagen 5.l. Representación gráfica de los datos del sensor
Detección de obstáculo a menos de 0.3 m del robot en el campo de visión del
sensor.
Imagen 5.m. Entorno Real
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
65
Imagen 5.n. Datos por pantalla del nodo “check_obstacle_node”
Imagen 5.o. Datos por pantalla del nodo “motor_simulation_node”
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
66
Imagen 5.p. Representación gráfica de los datos del sensor
Detección de obstáculo a menos de 0.4 m frontalmente al robot en el campo de
visión del sensor.
Imagen 5.q. Entorno Real
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
67
Imagen 5.r. Datos por pantalla del nodo “check_obstacle_node”
Imagen 5.s. Datos por pantalla del nodo “motor_simulation_node”
Control de un vehículo autónomo no tripulado a través de ROS Puesta en marcha
y resultados
68
Imagen 5.t. Representación gráfica de los datos del sensor
Control de un vehículo autónomo no tripulado a través de ROS Conclusiones
69
Conclusiones
Después de todo este proceso, puedo decir que he aprendido mucho sobre el trabajo en
solitario y lo que comporta empezar un proyecto nuevo. A decir verdad, después de todo
el proceso, lo que incluye los errores, aciertos y decepciones, puedo decir que estoy
muy satisfecha con el resultado obtenido, a pesar de no haber salido todo lo bien que
hubiera querido. Todo esto por supuesto, teniendo en cuenta que me he introducido en
un mundo totalmente desconocido para mí.
A esto, tengo que añadir que ha sido una experiencia muy grata debido a que he
comprendido lo duro que puede ser, después de toda una carrera que fomenta el trabajo
en equipo, el trabajar en solitario. También decir que he aprendido a no dar por hecho,
que toda la información que se me proporciona es correcta. Esto se debe a que con el
paso del tiempo, la información que era válida se vuelve obsoleta debido a cambios en
metodologías o hardware o porque simplemente se descubren nuevas formas de realizar
un mismo proceso. Esto me ha llevado a tener que investigar y desenvolverme en un
entorno completamente nuevo para mí.
Estoy también muy contenta de todos los conceptos nuevos aprendidos, y de los cuales
estoy segura que seguiré desarrollando ya sea en el ámbito profesional o personal. Esto
incluye el nuevo lenguaje de programación en el que me he iniciado, Python, como en
este nuevo sistema operativo, Ubuntu, del cual he aprendido que tanto profesionalmente
como personalmente es una herramienta muy potente.
También, una vez he acabado este proyecto, puedo decir que, a pesar de los
inconvenientes que he tenido, con los códigos generados durante el proceso podría
calificar que la autonomía en la conducción de este robot/“vehículo”, sería de Nivel 3
según la SAE y de Nivel 3 también según el CEA. Esto es debido a que el “vehículo” es
capaz de reconocer su entorno, aunque no sea en los 360º, y tomar decisiones en
función de ello.
Control de un vehículo autónomo no tripulado a través de ROS Futuros desarrollos
70
Futuros desarrollos
En futuros desarrollos se podría investigar más sobre establecer la comunicación con los
motores de forma exitosa. Esto se podría realizar en el PC usado en este proyecto o bien
a través de otros como Raspberry o Arduino, los cuales según el fabricante también son
compatibles.
Se podría también implementar la utilización de la cámara, actualmente instalara en el
robot, para cumplimentar la información procedente del entorno. Con ella se podrían
detectar señales de tráfico, con lo que se conseguiría una mayor recepción de
información, por lo que se podría navegar de forma más completa por el entorno. A esto
hay que añadir que también se le podrían instalar otra clase de sensores, como los de
ultrasonidos mencionados en este documento, obteniendo así un mayor control sobre el
entorno.
También se podría generar un mapa con los datos captados por el sensor LIDAR de
manera que se pueda iniciar la navegación por espacios ya reconocidos. Con ello
podríamos trazar rutas para ir de un punto A a un punto B.
Control de un vehículo autónomo no tripulado a través de ROS Referencias
71
Referencias
[1] A. Pérez, «PERIODISMO DEL MOTOR,» 01 08 2017. [En línea]. Available:
https://periodismodelmotor.com/que-es-conduccion-autonoma-
autopilot/169482/. [Último acceso: 17 06 2018].
[2] Unknown, «Wikipedia,» 12 02 2018. [En línea]. Available:
https://es.wikipedia.org/wiki/Veh%C3%ADculo_aut%C3%B3nomo#cite_note-
ELMUNDO_1-1. [Último acceso: 23 06 2018].
[3] Unknown, «Wikipedia,» 28 06 2016. [En línea]. Available:
https://es.wikipedia.org/wiki/Robot_aut%C3%B3nomo. [Último acceso: 23 06
2018].
[4] L. Reyes, «autonoción.com,» 17 03 2015. [En línea]. Available:
https://www.autonocion.com/camaras-coche-dashcam-legales-ilegales/. [Último
acceso: 17 06 2018].
[5] TAOtTAO, «Amazon.es,» Unknown. [En línea]. Available:
https://www.amazon.es/TAOtTAO-grabadora-salpicadero-veh%C3%ADculo-
nocturna/dp/B075SXWHHC. [Último acceso: 17 06 2018].
[6] Wiki Community, «Wiki de Robótica,» Unknown. [En línea]. Available:
http://wiki.robotica.webs.upv.es/wiki-de-robotica/sensores/sensores-
proximidad/sensor-infrarrojos/. [Último acceso: 18 06 2018].
[7] M. Odoroaga, «123RF,» Unknown. [En línea]. Available:
https://es.123rf.com/photo_55079485_sensores-de-autom%C3%B3viles-
utilizan-en-los-coches-de-auto-conducci%C3%B3n-datos-de-la-
c%C3%A1mara-con-im%C3%A1genes-de-radar-y-
l.html?fromid=S0IwOXEzdi9rK2lsSkF0K0FOMmozdz09. [Último acceso: 18
06 2018].
[8] A. Martinez Lopez, «f(t),» 13 10 2017. [En línea]. Available:
http://fdetonline.com/lidar-tecnologias-de-deteccion/. [Último acceso: 18 06
2018].
[9] Ibáñez, «motorpasión,» 28 09 2017. [En línea]. Available:
https://www.motorpasion.com/tecnologia/que-es-un-lidar-y-como-funciona-el-
sistema-de-medicion-y-deteccion-de-objetos-mediante-laser#comments. [Último
acceso: 18 06 2018].
Control de un vehículo autónomo no tripulado a través de ROS Referencias
72
[10] L. del Valle Hernández, «Programafacil.com,» Unknown. [En línea]. Available:
https://programarfacil.com/podcast/coche-autonomo-estado-del-arte/. [Último
acceso: 18 06 2018].
[11] A. Callejo, «FC,» 05 03 2018. [En línea]. Available:
https://forococheselectricos.com/2018/03/por-que-elon-musk-no-quiere-utilizar-
sensores-lidar-para-la-conduccion-autonoma-cuando-el-resto-de-la-industria-
apuesta-por-ellos.html. [Último acceso: 18 06 2018].
[12] Pepperl&Fuchs, «Pepperl&Fuchs,» Unknown. [En línea]. Available:
https://www.pepperl-fuchs.com/spain/es/classid_182.htm. [Último acceso: 18 06
2018].
[13] Unknown, «Automoción Total,» Unknown. [En línea]. Available:
http://automociontotal.hiperarticulos.com/sensores-de-aparcamiento/. [Último
acceso: 18 06 2018].
[14] R. Metz, «MIT Technology Review,» 15 01 2018. [En línea]. Available:
https://www.technologyreview.es/s/9924/baidu-empieza-probar-su-software-de-
conduccion-autonoma-de-codigo-abierto. [Último acceso: 26 06 2018].
[15] Unknown, «Erle Robotics,» Unknown. [En línea]. Available:
http://erlerobotics.com/blog/ros-introduction-es/#What_is_ros. [Último acceso:
16 06 2018].
[16] R. M. García Álvarez, «CEA,» Unknown. [En línea]. Available:
https://www.cea-online.es/blog/213-los-niveles-de-la-conduccion-autonoma.
[Último acceso: 17 06 2018].
[17] D. Galán, «Ecomotor.es,» 22 03 2018. [En línea]. Available:
http://www.eleconomista.es/ecomotor/motor/noticias/9024040/03/18/Asi-son-
los-seis-niveles-de-conduccion-autonoma.html. [Último acceso: 17 06 2018].
[18] Unknown, «RoboPlus 1.0,» Unknown. [En línea]. Available:
http://www.robotis.us/roboplus1/. [Último acceso: 29 04 2018].
[19] ROS community, «ROS Q&A,» 04 09 2014. [En línea]. Available:
https://answers.ros.org/question/191868/urg-node-on-ros-indigo/. [Último
acceso: 17 07 2018].
[20] Unknown, «Github,» Unknown. [En línea]. Available: https://github.com/ros-
drivers/urg_node. [Último acceso: 18 07 2018].
[21] H. Toquica, «ROS wiki,» 8 Noviembre 2017. [En línea]. Available:
http://wiki.ros.org/dynamixel_controllers/Tutorials.
Control de un vehículo autónomo no tripulado a través de ROS Referencias
73
[22] Unknown, «Github,» Unknown. [En línea]. Available:
https://github.com/ROBOTIS-GIT/DynamixelSDK. [Último acceso: 16 07
2018].
[23] Unknown, «Hokuyo,» Unknown. [En línea]. Available: https://www.hokuyo-
aut.jp/search/single.php?serial=165. [Último acceso: 19 07 2018].
[24] Unknown, «UTCoupe,» 10 08 2017. [En línea]. Available:
http://assos.utc.fr/utcoupe/wiki/doku.php?id=informatique:hokuyo. [Último
acceso: 02 07 2018].
[25] Unknown, «Touchdesigner,» 19 06 2018. [En línea]. Available:
https://docs.derivative.ca/index.php?title=Hokuyo_CHOP. [Último acceso: 02
07 2018].
[26] Unknown, «Creative,» Unknown. [En línea]. Available:
https://es.creative.com/p/web-cameras/blasterx-senz3d. [Último acceso: 11 07
2018].
[27] B. Rodríguez, «El chapuzas informatico,» 10 08 2016. [En línea]. Available:
https://elchapuzasinformatico.com/2016/08/creative-blasterx-senz3d-controla-
pc-cuerpo-escanea-objetos-3d/. [Último acceso: 11 07 2018].
[28] Unknown, «Robotis,» Unknown Unknown Unknown. [En línea]. Available:
http://www.robotis.us/dynamixel-rx-64-hn05-n1/. [Último acceso: 18 06 2018].
[29] Unknown, «RX-64,» Unknown. [En línea]. Available:
http://support.robotis.com/en/product/actuator/dynamixel/rx_series/rx-64.htm.
[Último acceso: 30 04 2018].
[30] Robotis, «RX series,» 2010. [En línea]. Available:
http://support.robotis.com/en/product/actuator/dynamixel/dxl_rx_main.htm.
[Último acceso: 01 07 2018].
[31] Robotis, «USB2Dynamixel,» 2010. [En línea]. Available:
http://support.robotis.com/en/product/auxdevice/interface/usb2dxl_manual.htm.
[Último acceso: 01 07 2018].
[32] Unknown, «batteryjunction.com,» Unknown. [En línea]. Available:
https://www.batteryjunction.com/tenergy-31357.html. [Último acceso: 15 07
2018].
[33] Unknown, «Odroid,» Unknown. [En línea]. Available:
https://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239
825. [Último acceso: 30 04 2018].
Control de un vehículo autónomo no tripulado a través de ROS Referencias
74
[34] Ubuntu Community, «Ubuntu ISO,» Unknown. [En línea]. Available:
https://odroid.in/ubuntu_16.04lts/. [Último acceso: 25 02 2018].
[35] Open Source Robotics Foundation, «Ubuntu install of ROS Kinetic,» 25 07
2017. [En línea]. Available: http://wiki.ros.org/kinetic/Installation/Ubuntu.
[Último acceso: 28 02 2018].
[36] O. S. R. Foundation, «ROS.org,» Unknown. [En línea]. Available:
http://wiki.ros.org/ROS/Tutorials. [Último acceso: 28 02 2018].
[37] Kawata, Communication Protocol Specification For SCIP2.0 Standard, 2006.
[38] Robotis, User's Manual Dynamixel RX-64, 2006.
[39] M. Anaimi, Pruebas reales de control de pocición de un robotmóvil basadas en
GPS, Tarragona, 2013.
[40] Y. Pyo, «ros,» 04 04 2018. [En línea]. Available:
http://wiki.ros.org/dynamixel_sdk. [Último acceso: 17 07 2018].
[41] K. Okada, «Ros,» 09 01 2015. [En línea]. Available:
http://wiki.ros.org/hokuyo_node/Tutorials. [Último acceso: 17 07 2018].
[42] Unknown, «Github,» Unknown. [En línea]. Available: https://github.com/ros-
drivers/urg_node/issues/21. [Último acceso: 18 07 2018].
[43] Unknown, «Ros Answers,» Unknown. [En línea]. Available:
https://answers.ros.org/question/243232/how-to-install-hokuyo_nodeurg_node-
on-kinetic/. [Último acceso: 18 07 2018].
[44] Unknown, «Github,» Unknown. [En línea]. Available: https://github.com/ros-
drivers/urg_node/pull/13. [Último acceso: 18 07 2018].
[45] Unknown, «Ros Discourse,» 04 10 2016. [En línea]. Available:
https://discourse.ros.org/t/new-packages-for-kinetic-2016-10-04/544. [Último
acceso: 18 07 2018].
[46] Unknown, «Github,» Unknown. [En línea]. Available: https://github.com/ros-
drivers/urg_node/issues/11. [Último acceso: 18 07 2018].
[47] Unknown, «Github,» 17 10 2017. [En línea]. Available: https://github.com/ros-
drivers/urg_node/pull/35. [Último acceso: 18 07 2018].
[48] Unknown, «Github,» 12 12 2016. [En línea]. Available: https://github.com/ros-
drivers/urg_node/issues/23. [Último acceso: 18 07 2018].
Control de un vehículo autónomo no tripulado a través de ROS Referencias
75
[49] Unknown, «Github,» 09 12 2016. [En línea]. Available: https://github.com/ros-
drivers/urg_node/commit/51d33eabc73dd290c1df37ec74592b4b0050df8b.
[Último acceso: 18 07 2018].
[50] Unknown, «Github,» Unknown. [En línea]. Available: https://github.com/ros-
drivers/urg_node/issues?q=is%3Aissue+is%3Aclosed. [Último acceso: 18 07
2018].
[51] Unknown, «Polemicus,» Unknown. [En línea]. Available:
http://polemicus.com/. [Último acceso: 18 07 2018].
[52] A. L. Raigada, «Universidad Politecnica de Madrid,» 07 2015. [En línea].
Available: http://oa.upm.es/38630/1/TFG_Alejandro_Lara_Raigada.pdf.
[Último acceso: 19 07 2018].
[53] R. F. Ferrer, «Universidad Politecnica de Valencia,» 2014. [En línea].
Available:
https://riunet.upv.es/bitstream/handle/10251/50219/TFG%20completo_1404667
8682001481229077977317933.pdf?sequence=2. [Último acceso: 19 07 2018].
[54] MatsWichmann, «Python wiki,» 17 04 2017. [En línea]. Available:
https://wiki.python.org/moin/ForLoop. [Último acceso: 25 07 2018].
[55] Pranjalmittal, «Python Wiki,» 06 07 2017. [En línea]. Available:
https://wiki.python.org/moin/BitwiseOperators. [Último acceso: 25 08 2018].
[56] Unknown, «Universidad Autonoma,» 2016. [En línea]. Available:
https://moodle2015-16.ua.es/moodle/mod/book/tool/print/index.php?id=82546.
[Último acceso: 30 08 2018].
[57] Unknown, «Wikipedia,» 29 03 2018. [En línea]. Available:
https://es.wikipedia.org/wiki/Imagen_ISO. [Último acceso: 05 07 2018].
[58] Unknown, «Github,» Unknown. [En línea]. Available: https://github.com/ros-
drivers/urg_c. [Último acceso: 18 07 2018].
[59] Unknown, «Cyberdroïd,» 03 03 2014. [En línea]. Available:
http://wiki.cybedroid.com/index.php?title=Fichier:CablageDynamixel4pins.jpg.
[Último acceso: 01 06 2018].
[60] Unknown, «Yahoo respuestas,» 2008. [En línea]. Available:
https://es.answers.yahoo.com/question/index?qid=20081026191455AA73njB&
guccounter=1. [Último acceso: 05 07 2018].
[61] Open Source Robotics Foundtaion, «Ros wiki,» 26 06 2017. [En línea].
Control de un vehículo autónomo no tripulado a través de ROS Referencias
76
Available: http://wiki.ros.org/urg_node. [Último acceso: 17 07 2018].
[62] Open Source Robotics Foundation, «Ros wiki,» 09 01 2015. [En línea].
Available: http://wiki.ros.org/hokuyo_node/Tutorials/UsingTheHokuyoNode.
[Último acceso: 18 07 2018].
[63] Community, «Odroid by Hardkernel,» 22 11 2015. [En línea]. Available:
https://forum.odroid.com/viewtopic.php?f=96&t=17542. [Último acceso: 20 02
2018].
[64] ROBOTISCHANNEL, «FAQ DYNAMIXEL Wizard,» 04 12 2012. [En línea].
Available:
https://www.youtube.com/watch?time_continue=106&v=YJ9b68hx5Qc.
[Último acceso: 29 04 2018].
[65] Ubuntu Community, «Ubuntu Downloads,» Unknown. [En línea]. Available:
https://www.ubuntu.com/download/desktop/thank-
you?country=ES&version=16.04.3&architecture=amd64. [Último acceso: 12 02
2018].
[66] Open Source Robotics Foundation, «ROS Support,» Unknown. [En línea].
Available: http://www.ros.org/install/. [Último acceso: 28 02 2018].
[67] Ubuntu Community, «Ubuntu install,» Unknown. [En línea]. Available:
https://tutorials.ubuntu.com/tutorial/tutorial-install-ubuntu-desktop#0. [Último
acceso: 12 02 2018].
[68] Ubuntu Community, «Ubuntu tutorials,» Unknown. [En línea]. Available:
https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-windows#0.
[Último acceso: 12 02 2018].
[69] M. Contreras, «Rufus Download,» Unknown. [En línea]. Available:
https://rufus-usb.uptodown.com/windows. [Último acceso: 12 02 2018].
[70] B. S. Marco, «Mclibre,» Unknown. [En línea]. Available:
http://www.mclibre.org/consultar/python/lecciones/python-variables.html.
[Último acceso: 26 08 2018].
[71] Unknown, «Apollo,» Unknown. [En línea]. Available:
http://apollo.auto/index.html. [Último acceso: 26 06 2018].
[72] Unknown, «Github,» Unknown. [En línea]. Available: https://github.com/ros-
drivers/hokuyo_node. [Último acceso: 18 07 2018].
[73] Unknown, «Github,» Unknown. [En línea]. Available: https://github.com/ros-
Control de un vehículo autónomo no tripulado a través de ROS Referencias
77
drivers/driver_common. [Último acceso: 18 07 2018].
[74] Unknown, «Intelligent Mobility,» Unknown. [En línea]. Available:
https://www.nissan.es/experiencia-nissan/intelligent-
mobility.html?&cid=psmZ4MOQ73P_dc|. [Último acceso: 26 06 2018].
[75] Unknown, «Mundo Digital,» 09 2016. [En línea]. Available:
http://www.mundodigital.net/camara-blasterx-senz3d-un-complemento-
perfecto/. [Último acceso: 11 07 2018].
[76] Unknown, «Nissab motor corporation,» Unknown. [En línea]. Available:
https://www.nissan-global.com/EN/TECHNOLOGY/OVERVIEW/sam.html.
[Último acceso: 26 06 2018].
[77] Unknown, «Nissan en España,» 23 02 2017. [En línea]. Available:
https://newsroom.nissan-europe.com/es/es-
es/media/pressreleases/426183182/nissan-integra-tecnologia-de-la-nasa-para-el-
desarrollo-de-un-coche-autonomo-que-aprende-y-adquiere. [Último acceso: 26
06 2018].
[78] Unknown, «PTCarretera,» 13 01 2017. [En línea]. Available:
http://www.ptcarretera.es/el-sistema-sam-la-integracion-inteligente-nissan-
definitiva/. [Último acceso: 26 06 2018].
[79] Unknown, «Robotis,» Unknown. [En línea]. Available:
http://en.robotis.com/service/downloadpage.php?ca_id=80. [Último acceso: 29
04 2018].
[80] Open Source Robotics Foundation, «ROS Wiki,» 18 02 2018. [En línea].
Available: http://wiki.ros.org/es. [Último acceso: 28 02 2018].
[81] J. Camós, «motorpasión,» 09 01 2017. [En línea]. Available:
https://www.motorpasion.com/tecnologia/asi-es-sam-la-apuesta-de-nissan-por-
las-escuelas-de-coches-autonomos-utilizando-ia-y-la-experiencia-de-la-nasa.
[Último acceso: 26 06 2018].
[82] W. Knight, «MIT Technology Review,» 04 08 2015. [En línea]. Available:
https://www.technologyreview.es/s/5065/una-camara-basta-para-crear-un-
coche-casi-autonomo. [Último acceso: 17 06 2018].
[83] M. Á. y. S. V. M. Á. García Garrido, «Universidad de Alcalá,» 13 01 2006. [En
línea]. Available: https://www.uah.es/es/investigacion/servicios-para-
empresas/patentes/Sistema-de-Vision-Artificial-a-bordo-de-un-automovil-para-
la-deteccion-automatica-de-senales-de-trafico-y-el-aviso-de-infracciones-
cometidas-por-el-conductor/. [Último acceso: 17 06 2018].
Control de un vehículo autónomo no tripulado a través de ROS Referencias
78
[84] Isaac, «Linux adictos,» 01 09 2017. [En línea]. Available:
https://www.linuxadictos.com/debian-vs-ubuntu.html. [Último acceso: 08 07
2018].
[85] J. Gomar, «Profesional review,» 13 06 2016. [En línea]. Available:
https://www.profesionalreview.com/2016/06/13/ubuntu-16-04-xenial-xerus-
review/. [Último acceso: 05 07 2018].
[86] N. Martinez, «noBBOT,» 15 11 2017. [En línea]. Available:
https://www.nobbot.com/futuro/tecnologia-lidar/. [Último acceso: 18 06 2018].
[87] P. Sanchez, «Youtube,» 2017. [En línea]. Available:
https://www.youtube.com/playlist?list=PLHj3aennrSE7E9NP4PNvwmjh2xm0T
8Etf&disable_polymer=true. [Último acceso: 25 08 2018].
Control de un vehículo autónomo no tripulado a través de ROS Anexo
79
Anexo
9.1. Código
En este apartado del anexo se encuentran los códigos generados durante el proyecto, así
como los ficheros de mensaje.
Control de un vehículo autónomo no tripulado a través de ROS Anexo
80
9.1.1. Contenido del fichero de mensaje “LaserScan”
# Single scan from a planar laser range-finder
# If you have another ranging device with different behavior (e.g. a
sonar
# array), please find or create a different message, since
applications
# will make fairly laser-specific assumptions about this data
Header header # timestamp in the header is the acquisition
time of
# the first ray in the scan.
#
# in frame frame_id, angles are measured
around
# the positive Z axis (counterclockwise, if Z
is up)
# with zero angle being forward along the x
axis
float32 angle_min # start angle of the scan [rad]
float32 angle_max # end angle of the scan [rad]
float32 angle_increment # angular distance between measurements [rad]
float32 time_increment # time between measurements [seconds] - if
your scanner
# is moving, this will be used in
interpolating position
# of 3d points
float32 scan_time # time between scans [seconds]
float32 range_min # minimum range value [m]
float32 range_max # maximum range value [m]
Control de un vehículo autónomo no tripulado a través de ROS Anexo
81
float32[] ranges # range data [m] (Note: values < range_min or
> range_max should be discarded)
float32[] intensities # intensity data [device-specific units]. If
your device does not provide intensities, please leave the array
empty.
Control de un vehículo autónomo no tripulado a través de ROS Anexo
82
9.1.2. Código fuente “check_obstacle_node”
#! /usr/bin/env python
import rospy
from sensor_msgs.msg import LaserScan
from check_obstacle_message_node.msg import Comunication
def callback(msg):
print "L=", msg.ranges[639]
print "K=", msg.ranges[554]
print "J=", msg.ranges[469]
print "B=", msg.ranges[384]
print "I=", msg.ranges[299]
print "H=", msg.ranges[214]
print "G=", msg.ranges[129]
if (msg.ranges[639] < 0.5 or msg.ranges[639] == "nan"):
l=1
else:
l=0
if (msg.ranges[554] < 0.5 or msg.ranges[554] == "nan"):
k=1
else:
k=0
if (msg.ranges[469] < 0.7 or msg.ranges[469] == "nan"):
j=1
else:
j=0
if (msg.ranges[384] < 0.7 or msg.ranges[384] == "nan"):
b=1
else:
Control de un vehículo autónomo no tripulado a través de ROS Anexo
83
b=0
if (msg.ranges[299] < 0.7 or msg.ranges[299] == "nan"):
i=1
else:
i=0
if (msg.ranges[214] < 0.5 or msg.ranges[214] == "nan"):
h=1
else:
h=0
if (msg.ranges[129] < 0.5 or msg.ranges[129] == "nan"):
g=1
else:
g=0
if (msg.ranges[639] < 0.3 or msg.ranges[554] < 0.3 or
msg.ranges[469] < 0.3 or msg.ranges[384] < 0.3 or msg.ranges[299] <
0.3 or msg.ranges[214] < 0.3 or msg.ranges[129] < 0.3):
print ("Stop! You can't continue going on without colliding
with something")
pub.publish(command_to_motors="S")
pub.publish(motor_id_1=0)
pub.publish(motor_id_2=0)
pub.publish(motor_id_3=0)
pub.publish(motor_id_4=0)
else:
if ((b==0 and j==0) or (i==0 and b==0 and j==1)):
print ("Go on")
pub.publish(command_to_motors="G")
pub.publish(motor_id_1=2)
pub.publish(motor_id_2=2)
pub.publish(motor_id_3=1)
pub.publish(motor_id_4=1)
Control de un vehículo autónomo no tripulado a través de ROS Anexo
84
if ((i==1 and j==1) or (b==1 and ((i==1 and k==1) or (h==1
and j==1 and i==0) or (h==1 and k==1 and i==0)))):
print ("Stop! You can't continue going on without
colliding with something")
pub.publish(command_to_motors="S")
pub.publish(motor_id_1=0)
pub.publish(motor_id_2=0)
pub.publish(motor_id_3=0)
pub.publish(motor_id_4=0)
if (h==0 and i==0 and ((g==0 and b==1) or (g==1 and b==1
and (j==1 or k==1 or l==1)))):
print ("Turn right, there is an obstacle on the
left")
pub.publish(command_to_motors="R")
pub.publish(motor_id_1=2)
pub.publish(motor_id_2=2)
pub.publish(motor_id_3=2)
pub.publish(motor_id_4=2)
if (b==1 and j==0 and k==0 and (i==1 or (h==1 and i==0) or
(g==1 and h==0 and i==0 and l==0))):
print ("Turn left, there is an obstacle on the
right")
pub.publish(command_to_motors="L")
pub.publish(motor_id_1=1)
pub.publish(motor_id_2=1)
pub.publish(motor_id_3=1)
pub.publish(motor_id_4=1)
rospy.init_node('check_obstacle_node')
sub = rospy.Subscriber('/scan', LaserScan, callback)
pub = rospy.Publisher('/talker_check_obst', Comunication,
queue_size=10)
rospy.spin()
Control de un vehículo autónomo no tripulado a través de ROS Anexo
85
9.1.3. Contenido del fichero de mensaje “Comunication”
string command_to_motors
int8 motor_id_1
int8 motor_id_2
int8 motor_id_3
int8 motor_id_4
Control de un vehículo autónomo no tripulado a través de ROS Anexo
86
9.1.4. Código fuente “motor_simulation_node”
#! /usr/bin/env python
import rospy
from check_obstacle_message_node.msg import Comunication
###All the variables are declared as global because we need to
maintain their value between calls and every time we want to change
its value we need to «say» that theu are global
global a
global count
global length
global check_t
global check
global trama
global trama_ini
global command_anterior
a = 1
count = 2
length = 0
check_t = 0
check = 0
trama = []
trama_ini = []
command_anterior = "S"
def callback_fun(msg):
global a
global count
global length
global check_t
Control de un vehículo autónomo no tripulado a través de ROS Anexo
87
global check
global trama
global trama_ini
global command_anterior
if (a == 1):
a = 0
trama_ini = [0xFF, 0xFF, 0xFE, 0x18, 0x83, 0x06, 0x04,
0x01, 0x00, 0x00, 0x02, 0x00, 0x00, 0x03, 0x00, 0x00, 0x04, 0x00,
0x00, 0x00] #endless turn array
check=trama_ini [-1]
length=len(trama)-1
count=2
for count in range (2,length):
check = check + trama_ini [count]
count=2
check_t=check & 0x00FF
trama_ini [-1] = check_t
print trama_ini
trama = [0xFF, 0xFF, 0xFE, 0x10, 0x83, 0x20, 0x02, 0x01,
0x00, 0x00, 0x02, 0x00, 0x00, 0x03, 0x00, 0x00, 0x04, 0x00, 0x00,
0x00]
check=trama [-1]
length=len(trama)-1
count=2
for count in range (2,length):
check = check + trama [count]
count=2
check_t=check & 0x00FF
trama [-1] = check_t
print trama
print ("End of the first two arrays")
else:
Control de un vehículo autónomo no tripulado a través de ROS Anexo
88
if (command_anterior != msg.command_to_motors):
if (msg.command_to_motors == "S"):
trama = [0xFF, 0xFF, 0xFE, 0x10, 0x83, 0x20,
0x02, 0x01, 0x00, 0x00, 0x02, 0x00, 0x00, 0x03, 0x00, 0x00, 0x04,
0x00, 0x00, 0x00]
check=trama [-1]
length=len(trama)-1
for count in range (2,length):
check = check + trama [count]
count=2
check_t=check & 0x00FF
trama [-1] = check_t
print trama
print ("End of array S")
command_anterior=msg.command_to_motors
elif (msg.command_to_motors == "G"):
trama = [0xFF, 0xFF, 0xFE, 0x10, 0x83, 0x20,
0x02, 0x01, 0x00, 0x02, 0x02, 0x00, 0x02, 0x03, 0x00, 0x06, 0x04,
0x00, 0x06, 0x00] #50% of speed
check=trama [-1]
length=len(trama)-1
for count in range (2,length):
check = check + trama [count]
count=2
check_t=check & 0x00FF
trama [-1] = check_t
print trama
print ("End of array G")
command_anterior=msg.command_to_motors
elif (msg.command_to_motors == "R"):
trama = [0xFF, 0xFF, 0xFE, 0x10, 0x83, 0x20,
0x02, 0x01, 0x00, 0x02, 0x02, 0x00, 0x02, 0x03, 0x00, 0x02, 0x04,
0x00, 0x02, 0x00] #50% of speed
Control de un vehículo autónomo no tripulado a través de ROS Anexo
89
check=trama [-1]
length=len(trama)-1
for count in range (2,length):
check = check + trama [count]
count=2
check_t=check & 0x00FF
trama [-1] = check_t
print trama
print ("End of array R")
command_anterior=msg.command_to_motors
elif (msg.command_to_motors == "L"):
trama = [0xFF, 0xFF, 0xFE, 0x10, 0x83, 0x20,
0x02, 0x01, 0x00, 0x06, 0x02, 0x00, 0x06, 0x03, 0x00, 0x06, 0x04,
0x00, 0x06, 0x00] #50% of speed
check=trama [-1]
length=len(trama)-1
for count in range (2,length):
check = check + trama [count]
count=2
check_t=check & 0x00FF
trama [-1] = check_t
print trama
print ("End of array L")
command_anterior=msg.command_to_motors
rospy.init_node('motor_simulation_node')
sub = rospy.Subscriber('/talker_check_obst', Comunication,
callback_fun)
rospy.spin()
Control de un vehículo autónomo no tripulado a través de ROS Anexo
90
9.2. Representación de la comunicación entre los nodos.
Imagen 9.2.a. Representación gráfica de la transmisión de información entre nodos
Control de un vehículo autónomo no tripulado a través de ROS Anexo
91
9.3. Modificaciones en la PCB
9.3.1. Imagen 9.3.a.
Imagen 9.3.a. Diseño original de la PCB [39]
Control de un vehículo autónomo no tripulado a través de ROS Anexo
92
9.3.2. Imagen 9.3.b.
Imagen 9.3.b. Esquemático de la PCB con modificación en alimentación
Control de un vehículo autónomo no tripulado a través de ROS Anexo
93
9.3.3. Imagen 9.3.c.
Imagen 9.3.c. Cambio en la PCB
9.4. Tabla de la interpretación de la información del sensor LIDAR.
g h i b j k l L S G R
0 0 0 0 1
0 0 0 1 1
0 0 1 0 1
0 0 1 1 1
0 1 0 0 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 1
0 0 0 1 0 0 0 1
1 0 0 1 1
1 0 1 0 1
1 0 1 1 1
1 1 0 0 1
1 1 0 1 1
1 1 1 0 1
1 1 1 1 1
0 0 0 0 1
0 0 0 1 1
0 0 1 0 1
0 0 1 1 1
0 1 0 0 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 1
0 0 1 1 0 0 0 1
1 0 0 1 1
1 0 1 0 1
Control de un vehículo autónomo no tripulado a través de ROS Anexo
94
1 0 1 1 1
1 1 0 0 1
1 1 0 1 1
1 1 1 0 1
1 1 1 1 1
0 0 0 0 1
0 0 0 1 1
0 0 1 0 1
0 0 1 1 1
0 1 0 0 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 1
0 1 0 1 0 0 0 1
1 0 0 1 1
1 0 1 0 1
1 0 1 1 1
1 1 0 0 1
1 1 0 1 1
1 1 1 0 1
1 1 1 1 1
0 0 0 0 1
0 0 0 1 1
0 0 1 0 1
0 0 1 1 1
0 1 0 0 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 1
0 1 1 1 0 0 0 1
1 0 0 1 1
1 0 1 0 1
1 0 1 1 1
1 1 0 0 1
1 1 0 1 1
1 1 1 0 1
1 1 1 1 1
0 0 0 0 1
0 0 0 1 1
0 0 1 0 1
0 0 1 1 1
0 1 0 0 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 1
1 0 0 1 0 0 0 1
1 0 0 1 1
1 0 1 0 1
1 0 1 1 1
1 1 0 0 1
1 1 0 1 1
1 1 1 0 1
1 1 1 1 1
Control de un vehículo autónomo no tripulado a través de ROS Anexo
95
0 0 0 0 1
0 0 0 1 1
0 0 1 0 1
0 0 1 1 1
0 1 0 0 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 1
1 0 1 1 0 0 0 1
1 0 0 1 1
1 0 1 0 1
1 0 1 1 1
1 1 0 0 1
1 1 0 1 1
1 1 1 0 1
1 1 1 1 1
0 0 0 0 1
0 0 0 1 1
0 0 1 0 1
0 0 1 1 1
0 1 0 0 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 1
1 1 0 1 0 0 0 1
1 0 0 1 1
1 0 1 0 1
1 0 1 1 1
1 1 0 0 1
1 1 0 1 1
1 1 1 0 1
1 1 1 1 1
0 0 0 0 1
0 0 0 1 1
0 0 1 0 1
0 0 1 1 1
0 1 0 0 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 1
1 1 1 1 0 0 0 1
1 0 0 1 1
1 0 1 0 1
1 0 1 1 1
1 1 0 0 1
1 1 0 1 1
1 1 1 0 1
1 1 1 1 1
Tabla 9.4.a. Tabla de entradas y salidas
Control de un vehículo autónomo no tripulado a través de ROS Anexo
96
9.5. Tabla de interpretación para saber el giro de los motores.
Dirección de
giro del robot motor_id_1 motor_id_2 motor_id_3 motor_id_4
Left 1 1 1 1
Stop 0 0 0 0
Go on 2 2 1 1
Right 2 2 2 2
Tabla 9.5.a. Tabla de sentido de giro de los motores
9.6. Tabla de control de los motores
Address Item Access Initial Value
0(0x00) Model Number (L) RD 64(0x40)
1(0x01) Model Number (H) RD 0(0x00)
2(0x02) Version of Firmware RD ?
3(0x03) ID RD, WR 1(0x01)
4(0x04) Baud Rate RD, WR 34(0x22)
5(0x05) Return Delay Time RD, WR 250(0xFA)
6(0x06) CW Angle Limit (L) RD, WR 0(0x00)
7(0x07) CW Angle Limit (H) RD, WR 0(0x00)
E 8(0x08) CCW Angle Limit (L) RD, WR 255(0xFF)
E 9(0x09) CCW Angle Limit (H) RD, WR 3(0x03)
P 10(0x0A) (Reserved) - 0(0x00)
R 11(0x0B) The Highest Limit Temperature RD, WR 85(0x55)
O 12(0x0C) The Lowest Limit Voltage RD, WR 60(0x3C)
M 13(0x0D) The Highest Limit Voltage RD, WR 240(0xF0)
14(0x0E) Max Torque (L) RD, WR 255(0xFF)
area 15(0x0F) Max Torque (H) RD, WR 3(0x03)
16(0x10) Status Return Level RD, WR 2(0x02)
17(0x11) Alarm LED RD, WR 4(0x04)
18(0x12) Alarm Shutdown RD, WR 4(0x04)
19(0x13) (Reserved) RD, WR 0(0x00)
20(0x14) Down Calibration (L) RD ?
21(0x15) Down Calibration (H) RD ?
22(0x16) Up Calibration (L) RD ?
23(0x17) Up Calibration (H) RD ?
24(0x18) Torque Enable RD, WR 0(0x00)
25(0x19) LED RD, WR 0(0x00)
26(0x1A) CW Compliance Margin RD, WR 0(0x00)
27(0x1B) CCW Compliance Margin RD, WR 0(0x00)
28(0x1C) CW Compliance Slope RD, WR 32(0x20)
29(0x1D) CCW Compliance Slope RD, WR 32(0x20)
30(0x1E) Goal Position (L) RD, WR [Addr36] value
31(0x1F) Goal Position (H) RD, WR [Addr37] value
32(0x20) Moving Speed (L) RD, WR 0
R 33(0x21) Moving Speed (H) RD, WR 0
A 34(0x22) Torque Limit (L) RD, WR [Addr14] value
M 35(0x23) Torque Limit (H) RD, WR [Addr15] value
Control de un vehículo autónomo no tripulado a través de ROS Anexo
97
36(0x24) Present Position (L) RD ?
area 37(0x25) Present Position (H) RD ?
38(0x26) Present Speed (L) RD ?
39(0x27) Present Speed (H) RD ?
40(0x28) Present Load (L) RD ?
41(0x29) Present Load (H) RD ?
42(0x2A) Present Voltage RD ?
43(0x2B) Present Temperature RD ?
44(0x2C) Registred Instruction RD, WR 0(0x00)
45(0x2D) (Reserved) - 0(0x00)
46(0x2E) Moving RD 0(0x00)
47(0x2F) Lock RD, WR 0(0x00)
48(0x30) Punch (L) RD, WR 32(0x20)
49(0x31) Punch (H) RD, WR 0(0x00)
Tabla 9.6.a. Tabla de control de los motores [38]
Control de un vehículo autónomo no tripulado a través de ROS Anexo
98
9.7. Mensajes del “topic” “scan”
Control de un vehículo autónomo no tripulado a través de ROS Anexo
99