Control de un vehículo autónomo no tripulado a través de...

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

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


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


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]


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


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.


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.


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.


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,


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]


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.


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.


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


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.


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


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”


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).


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)


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.


24

Imagen 2.5.3.c. Apertura del programa Rviz

Imagen 2.5.3.d. Elección del tipo de dispositivo a visualizar


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.


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:


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)


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)


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]


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]


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]


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.


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]


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.


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]


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:


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


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


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]


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]


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


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


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.


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


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


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.


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]


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]


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.


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:


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:


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


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.


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.


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.


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”


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


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”


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


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”


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


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”


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


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”


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].


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].


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.


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.


[30] Robotis, «RX series,» 2010. [En línea]. Available:

http://support.robotis.com/en/product/actuator/dynamixel/dxl_rx_main.htm.


[31] Robotis, «USB2Dynamixel,» 2010. [En línea]. Available:

http://support.robotis.com/en/product/auxdevice/interface/usb2dxl_manual.htm.


[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].


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.


[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].


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].


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].



[47] Unknown, «Github,» 17 10 2017. [En línea]. Available: https://github.com/ros-

drivers/urg_node/pull/35. [Último acceso: 18 07 2018].




75


drivers/urg_node/commit/51d33eabc73dd290c1df37ec74592b4b0050df8b.



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.


[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.



https://es.wikipedia.org/wiki/Imagen_ISO. [Último acceso: 05 07 2018].


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.


[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].


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.


[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.


[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.


[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.


[71] Unknown, «Apollo,» Unknown. [En línea]. Available:

http://apollo.auto/index.html. [Último acceso: 26 06 2018].


drivers/hokuyo_node. [Último acceso: 18 07 2018].



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.


[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.


[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].


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.


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]


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.


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


k=1

else:

k=0


j=1

else:

j=0


b=1

else:


83

b=0


i=1

else:

i=0


h=1

else:

h=0


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)




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")






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")





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")





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")





rospy.init_node('check_obstacle_node')

sub = rospy.Subscriber('/scan', LaserScan, callback)

pub = rospy.Publisher('/talker_check_obst', Comunication,

queue_size=10)

rospy.spin()


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


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


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


check = check + trama [count]

count=2


trama [-1] = check_t

print trama

print ("End of the first two arrays")

else:


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



count=2



print trama

print ("End of array S")

command_anterior=msg.command_to_motors

elif (msg.command_to_motors == "G"):


0x02, 0x01, 0x00, 0x02, 0x02, 0x00, 0x02, 0x03, 0x00, 0x06, 0x04,

0x00, 0x06, 0x00] #50% of speed

check=trama [-1]

length=len(trama)-1



count=2



print trama

print ("End of array G")


elif (msg.command_to_motors == "R"):


0x02, 0x01, 0x00, 0x02, 0x02, 0x00, 0x02, 0x03, 0x00, 0x02, 0x04,

0x00, 0x02, 0x00] #50% of speed


89

check=trama [-1]

length=len(trama)-1



count=2



print trama

print ("End of array R")


elif (msg.command_to_motors == "L"):


0x02, 0x01, 0x00, 0x06, 0x02, 0x00, 0x06, 0x03, 0x00, 0x06, 0x04,

0x00, 0x06, 0x00] #50% of speed

check=trama [-1]

length=len(trama)-1



count=2



print trama

print ("End of array L")


rospy.init_node('motor_simulation_node')

sub = rospy.Subscriber('/talker_check_obst', Comunication,

callback_fun)

rospy.spin()


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


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]


92

9.3.2. Imagen 9.3.b.

Imagen 9.3.b. Esquemático de la PCB con modificación en alimentación


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


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


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


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


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]


98

9.7. Mensajes del “topic” “scan”


99

Control de un vehículo autónomo no tripulado a través de...

Documents

Transcript of Control de un vehículo autónomo no tripulado a través de...