trabajo fin de grado en - bibing.us.esbibing.us.es/proyectos/abreproy/91585/fichero/... · a indus...

1

Trabajo Fin de Grado en

Ingeniería Electrónica, Robótica y Mecatrónica

Autor: Víctor Valseca Martínez

Tutor: Federico Cuesta Rojo

Calibración y control de un robot móvil de bajo coste

Dep. Ingeniería de Sistemas y Automática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017

iii

Trabajo Fin de Grado en

Ingeniería Electrónica, Robótica y Mecatrónica

Calibración y control de un robot móvil de

bajo coste

Autor:

Víctor Valseca Martínez

Tutor:

Federico Cuesta Rojo

Profesor Titular de Universidad

Dep. de Ingeniería de sistemas y Automática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017

v

Proyecto Fin de Carrera: Calibración y control de un robot móvil de bajo coste

Autor: Víctor Valseca Martínez Tutor: Federico Cuesta Rojo

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2017

El Secretario del Tribunal

vi

A todos aquellos que se quedaron por el camino que jamás se olvidaran.

viii

Agradecimientos

Primero de todo me gustaría agradecer este trabajo a mis tutores Federico Cuesta y Francisco

López, ya que siempre han estado a mi disposición cuando me han surgido dudas o cuando me

ha faltado un empujón. Es algo que siempre les agradeceré.

A mi familia, pilar fundamental en los momentos más duros. Siempre estarán ahí para lo que

necesite y siempre podrán contar conmigo.

A mis amigos, la familia que se escoge, pero sobretodo a Pan de Pueblo sin ellos no podría

haber perdido la mitad de la vida por los disgustos que me dan.

A Tino, por las noches de muerte y destrucción, de las cuales solo sacábamos úlceras de las

rabietas que nos pegábamos.

A Legacy por tolerar todas mis meteduras de pata y soportarme.

A Indus con dos cojones.

x

Resumen

En este documento, se va a tratar de descomponer el robot Andruino R2 sistema por sistema.

Explicando cada uno de sus componentes y funcionamiento dentro del conjunto. Por último y

no menos importante, se expondrá el trabajo realizado por el alumno, así como sus conclusiones

y posibles mejoras que pudiera aportar al robot móvil.

xii

Abstract

In this document, we are going to try to decompose the robot Andruino R2 system by system.

Explaining each of its components and its functioning within the set. Last but not least, the work

done by the student will be presented, as well as his conclusions and possible improvements that

he could bring to the mobile robot.

xiii

Índice

Agradecimientos ......................................................................................................................... viii

Resumen ........................................................................................................................................ x

Abstract ........................................................................................................................................ xii

Índice ........................................................................................................................................... xiii

Índice de tablas ............................................................................................................................ xv

Índice de figuras ......................................................................................................................... xvii

Notación ...................................................................................................................................... xix

1. INTRODUCCIÓN ..................................................................................................................... 1

1.1. Antecedentes ................................................................................................................. 1

1.2. Objetivos ........................................................................................................................ 1

1.3. Estructura del trabajo ..................................................................................................... 2

2. Hardware de Andruino .......................................................................................................... 3

2.1. Estructura de soporte ..................................................................................................... 3

2.1.1. Base ....................................................................................................................... 3

2.1.2. Canaleta ................................................................................................................. 3

2.2. Ruedas y motores .......................................................................................................... 4

2.3. Batería ............................................................................................................................ 4

2.4. Puente H ......................................................................................................................... 5

2.5. Arduino .......................................................................................................................... 5

2.6. Sensores ........................................................................................................................ 7

2.6.1. Sensores de ultrasonidos ....................................................................................... 7

2.6.2. Sensores de luz ...................................................................................................... 8

2.6.3. Giroscopio y acelerómetro ..................................................................................... 8

2.7. Dispositivos móviles utilizados ...................................................................................... 9

2.7.1. BQ Aquaris E5 ........................................................................................................ 9

2.8. Ordenador utilizado ...................................................................................................... 11

2.9. Andruino R2 montado .................................................................................................. 11

xiv

3. Software de Andruino ......................................................................................................... 13

3.1. Ubuntu ......................................................................................................................... 13

3.2. ROS .............................................................................................................................. 13

3.2.1. Sistema de archivos ............................................................................................. 14

3.2.2. Grafos de computación ........................................................................................ 15

3.3. Andruino R2 firmware ................................................................................................... 16

4. Calibración y control ........................................................................................................... 17

4.1. Calibración automática ................................................................................................. 17

4.2. Calibración del modelo cinemático ............................................................................... 19

4.3. Controladores .............................................................................................................. 24

4.3.1. Implementación del filtro de Kalman 1-D .............................................................. 26

5. Herramientas para realizar el mapeado.............................................................................. 27

5.1. Costmap 2D .................................................................................................................. 27

5.1.1. Breve descripción ................................................................................................ 27

5.1.2. Ocupación de estados .......................................................................................... 28

5.1.3. Actualizaciones del mapa ..................................................................................... 28

5.1.4. Transformadas ..................................................................................................... 28

5.1.5. Inflación/Aumento ................................................................................................ 28

5.1.6. Tipos de mapas .................................................................................................... 29

5.2. Odometría visual y filtro de Kalman para diferentes medidas ....................................... 30

6. Conclusiones y mejoras ....................................................................................................... 31

6.1. Mejoras ........................................................................................................................ 31

7. Bibliografía .......................................................................................................................... 33

xv

Índice de tablas

Tabla 2-1: Especificaciones de Arduino UNO 6

Tabla 2-2: Especificaciones sensor ultrasónico 7

Tabla 2-3: Especificaciones LDR 8

Tabla 2-4: Especificaciones BQ Aquaris E5 y Aquaris E5 HD 10

xvii

Índice de figuras

Figura 2-1: Base utilizada para Andruino R2 3

Figura 2-2: Motores de corriente continua proporcionados por el kit 4

Figura 2-3: Ruedas de Andruino R2 prporcionadas por el kit 4

Figura 2-4: Portapilas utilizado para alojar las baterías 4

Figura 2-5: Circuito impreso que conforma el Puente H 5

Figura 2-6: Sensor de ultrasonidos 7

Figura 2-7: Sensor LDR 8

Figura 2-8: Imagen de giroscopio 9

Figura 2-9: Imagen de móvil BQ Aquaris E5 10

Figura 2-10: Andruino R2 montado 11

Figura 2-11: Andruino R2, muestra de disposición de las baterías y cables 11

Figura 4-1: Relación entre PWM-ω, conjunto derecho 18

Figura 4-2: Relación PWM-ω, conjunto izquierdo 18

Figura 4-3: Esquema de control utilizado por el vehículo móvil 25

Figura 5-1: Calificación de los estados de las celdas en Costmap 2D 29

xix

Notación

A* Conjugado

c.t.p. En casi todos los puntos

c.q.d. Como queríamos demostrar

∎ Como queríamos demostrar

e.o.c. En cualquier otro caso

e número e

IRe Parte real

IIm Parte imaginaria

sen Función seno

tg Función tangente

arctg Función arco tangente

sen Función seno

sinxy Función seno de x elevado a y

cosxy Función coseno de x elevado a y

Sa Función sampling

sgn Función signo

rect Función rectángulo

Sinc Función sinc

∂y ∂x

x

Derivada parcial de y respecto

Notación de grado, x grados.

Pr(A) Probabilidad del suceso A

SNR Signal-to-noise ratio

MSE Minimum square error

: Tal que

< Menor o igual

> Mayor o igual

\ Backslash

⇔ Si y sólo si

Introducción

1

1

1. INTRODUCCIÓN

En este proyecto se trabajará con el robot Andruino R2 que está enfocado para ser estudiado por

aquellos que pretendan iniciarse en el ámbito de la robótica móvil, ya que está compuesto por

elementos fáciles de adquirir. Este robot móvil entra dentro del grupo de vehículos con

distribución skid-steer. En este documento se explicará como se podrá relacionar con el robot de

locomoción diferencial, con el cual comparte algunas similitudes.

Andruino R2 es un robot sencillo pero que posee un gran potencial en cuanto a desempeño de

funciones se refiere, a pesar de que está equipado con un número reducido de sensores.

Hay que destacar, que para la realización de este trabajo, se dispone de todo el hardware de

Andruino R2 necesario, además del software y tests de calibración desarrollados e

implementados en el robot.

1.1. Antecedentes

Andruino R2, como se ha mencionado con anterioridad, es un robot que está enfocado al uso

estudiantil, por su destacada simpleza y coste. Se han implementado multitud de tests en el

programa de Arduino, además de una relación entre la cinemática de un robot skid-steer y

diferencial y programación de algoritmos de control para la velocidad lineal y angular del

móvil. Es necesaria, por tanto, una validación de todo lo anterior, para demostrar que se han

realizado correctamente y así pasar al desarrollo de las aplicaciones que pudiera desempeñar.

1.2. Objetivos

Los objetivos que se tratarán de cumplir a través de la realización de este trabajo son los

siguientes:

- Validar la calibración diseñada por el creador de Andruino R2.

- Mejorar los tests disponibles y su automatización.

- Mejorar los controladores disponibles.

- Analizar la viabilidad de nuevos controladores junto con la odometría visual, y los posibles

módulos que se utilizarían para el desarrollo del mapeado.

Introducción

2

2

1.3. Estructura del trabajo

A continuación se expondrá una breve descripción de cada uno de los siete capítulos contenidos

en la memoria. Sin contar por supuesto con el primer capítulo perteneciente a la introducción, ni

el último dedicado a la bibliografía utilizada.

Capítulo 2: Hardware de Andruino

En dicho capítulo se expondrán los componentes de Andruino R2, así como una explicación de

la labor que ejercen en el sistema.

Capitulo 3: Software de Andruino

Se tratará en dicho capítulo de explicar ROS, así como el sistema operativo usado y el firmware

utilizado.

Capítulo 4: Calibración y control

Se expondrán los desarrollos realizados relativos a la calibración y control.

Capítulo 5: Herramientas para realizar el mapeado

En este tema se realizará un análisis acerca de los diferentes módulos que se emplearían para la

realización del mapa de un área sobre la que Andruino pudiera operar.

Capítulo 6: Conclusiones y mejoras

En él se presentarán las conclusiones a las que el autor de este texto ha llegado y de las posibles

mejoras que se le pueden aplicar a Andruino R2.

Hardware de Andruino

3

3

2. Hardware de Andruino

2.1. Estructura de soporte

2.1.1. Base

La base utilizada para el robot Andruino R2 es un kit cuyo fin es servir para la educación de los

estudiantes, aficionados a la robótica, etc. Viene con una base de plástico en la cual se pueden

montar seis ruedas o seis pies. Además de dos motores de corriente continua, posee orificios en

la parte superior para por si surgiese añadirle más elementos. Como sucede en nuestro caso.

Figura 2 - 1: Base utilizada para Andruino R2

2.1.2. Canaleta

La canaleta es el lugar donde irá alojado el móvil, la placa de Arduino UNO y la placa del

puente H. Los planos para su construcción fueron elaborados por los profesores Federico Cuesta

y Francisco López. Recibe este nombre porque tal soporte está elaborado por un conducto de

PVC cuyo fin original era albergar cables. Es posible utilizar otro tipo de soportes siempre y

cuando sea posible que en él se pueda incluir, sin riesgo para los elementos electrónicos, la

placa de Arduino y el puente H.


4

4

2.2. Ruedas y motores

Como se ha mencionado antes el kit posee como componentes dos motores de corriente

continua que moverán, mediante un conjunto de engranajes, las ruedas de cada lado a la misma

velocidad angular. Dicho motores serán de 4.5 V cada uno, capaces de alcanzar una velocidad

de 200 RPM.

Figura 2 - 2: Motores de corriente continua proporcionados por el kit

Por otra parte, las ruedas que vienen con el kit son de plástico, y siempre están en contacto con

el suelo, en caso de ser éste una superficie plana.

Figura 2 - 3: Ruedas de Andruino R2 prporcionadas por el kit

2.3. Batería

El robot cuenta con dos portapilas que contendrán dos pilas cada una de 1.5 V. Lo que supondrá

una fuente de alimentación de 6 V al puente H, el cual, regulará dicha tensión para suministrar

la correspondiente al Arduino y que no sufra daños.

Figura 2 - 4: Portapilas utilizado para alojar las baterías


5

5

2.4. Puente H

El elemento principal es el circuito integrado L293D, el cual incluye cuatro circuitos para

manejar cargas de potencia media , en especial sirve para pequeños motores y cargas inductivas,

con la capacidad de controlar una corriente de hasta 600 mA en cada circuito y una tensión entre

4.5 V y 36 V.

Los circuitos individuales se pueden usar de manera independiente para controlar cargas de todo

tipo y, en el caso de ser motores, manejar un único sentido de giro. Pero además, cualquiera de

estos cuatro circuitos sirve para configurar la mitad de un puente H. El integrado permite

formar, entonces, dos puentes H completos, con los que se puede realizar el manejo de dos

motores. En este caso el manejo será bidireccional y con posibilidad de implementar el control

de velocidad.

Figura 2 - 5: Circuito impreso que conforma el Puente H

En nuestro caso utilizaremos el puente H para suministrar tensión a la placa de arduino y regular

la intensidad y el voltaje proporcionado por la señal PWM de la salida de la placa, que irá

dirigida al control de los motores.

2.5. Arduino

Arduino UNO: Es una placa con un microcontrolador de la marca Atmel y con toda la

circuitería de soporte, que incluye, reguladores de tensión, puerto USB conectado a un módulo

adaptador USB-Serie que permite programar el microcontrolador desde cualquier PC.

Dispone de 14 pines que pueden configurarse como entrada o salida y a los que puede

conectarse cualquier dispositivo que sea capaz de transmitir o recibir señales digitales de 0 y 5

V.

También dispone de entradas y salidas analógicas. Mediante las entradas analógicas podemos

obtener datos de sensores en forma de variaciones continuas de un voltaje. Las salidas

analógicas suelen utilizarse para enviar señales de control en forma de señales PWM.


6

6

Arduino UNO es la última versión de la placa, existen dos variantes, la Arduino UNO

convencional y la Arduino UNO SMD. La única diferencia entre ambas es el tipo de

microcontrolador que montan.

Se ha utilizado la placa arduino UNO convencional, ya que ésta permite programar el chip sobre

la propia placa y después integrarlo en otros montajes.

Cada uno de los 14 pines digitales se puede usar como entrada o como salida. Funcionan a 5,

cada pin puede suministrar hasta 40 mA. La intensidad máxima de entrada también es de 40

mA. Cada uno de los pines digitales dispone de una resistencia de pull-up interna de entre 20kΩ

y 50kΩ que está desconectada, salvo que nosotros indiquemos lo contrario.

Arduino también dispone de 6 pines de entrada analógicos que trasladan las señales a un

conversor analógico/digital de 10 bits.

Pines especiales de entrada y salida:

RX y TX: Se usan para transmisiones serie de señales TTL.

Interrupciones externas: Los pines 2 y 3 está configurados para generar una interrupción

en el atmega. Las interrupciones pueden dispararse cuando se encuentra un valor bajo

en estas entradas y con flancos de subida o bajada de la entrada.

PWM: Arduino dispone de 6 salidas destinadas a la generación de señales PWM de

hasta 8 bits.

SPI: Los pines 10,11,12 y 13 pueden utilizarse para llevar a cabo comunicaciones SPI,

que permiten trasladar información full dúplex en un entorno Maestro/esclavo.

I2C: Permite establecer comunicaciones a través de un bus I2C. El bus I2C es un

producto de Phillips para interconexión de sistemas embebidos. Actualmente se puede

encotnrar una gran diversidad de dispositivos que utilizan esta interfaz, desde pantallas

LCD, memorias EEPROM, sensores...

Alimentación a través del propio cable USB o a partir de una fuente de alimentación externa.

Los límites están entre los 6 y los 12 V. Como única restricción hay que saber que si la placa se

alimenta con menos de 7 V, la salida del regulador de tensión a 5V puede dar menos que este

voltaje y si sobrepasamos los 12V, dañaremos la placa.

Microcontrolador Atmega328

Voltaje de operación 5 V

Voltaje de entrada (Recomendado) 7 - 12 V

Voltaje de entrada (Límite) 6 - 20 V

Pines para entrada - salida digital 14 (6 pueden usarse como salida PWM)

Pines de entrada analógica 6

Corriente continua por pin IO 40 mA

Corriente continua en el pin 3.3 V 50 mA

Memoria Flash 32KB (0.5 KB ocupados por el bootloader)

SRAM 2 KB

EEPROM 1 KB

Frecuencia de reloj 16 MHz

Tabla 2-1: Especificaciones de Arduino UNO

Software de Andruino

7

7

Este sistema está compuesto por varios elementos que se describirán más tarde. Tales elementos

se encargan del transporte y obtención de datos.

2.6. Sensores

Los sensores de los que dispone Andruino R2 se ocuparán de extraer la información del entorno

con el fin de utilizar dichos datos para realizar cualquier actividad que se pretenda programar.

Como sería el caso de la elaboración de un mapa, orientarse hacia la luz u obtención de

parámetros que puedan servir para la calibración del robot.

2.6.1. Sensores de ultrasonidos

En primera estancia son los encargados de medir la distancia del móvil con respecto a un

obstáculo cercano. También, debido a las medidas que se obtendrán a lo largo del tiempo,

servirán para determinar la velocidad del vehículo.

El sensor utilizado para ello, es el HC-SR04, el cual se compone de un transmisor ultrasónico,

receptor y circuito de control. Cuando se dispara, envía una serie de pulsos de ultrasonidos de

40 kHz y recibe le eco de los objetos. La distancia entre la unidad y el objeto se calcula

midiendo el tiempo de desplazamiento del sonido y emitiéndolo como el ancho de un pulso

TTL.

Figura 2-6: Sensor de ultrasonidos

Están conectados al puente H y situados en forma de arco sobre el mismo. Formando un campo

sensorial junto con los LDRs. Su punto fuerte es que puede medir la distancia con objetos

relativamente lejanos del móvil. Sin embargo, son susceptibles al ruido y a las interferencias del

entorno por lo que se hace necesaria la aplicación de filtros sobre estos.

A continuación se relataran algunas de sus detalles técnicos:

Fuente de alimentación 5 V DC

Corriente de reposo < 2 mA

Ángulo efectivo < 15º

Distancia 2 ~ 1000 cm

Resolución 0.3 cm

Modelo ES-EL-SM-001

Peso 9 g

Dimensiones 3 x 1.5 x 3 cm

Tabla 2-2: Especificaciones sensor ultrasónico


8

8

2.6.2. Sensores de luz

Incluidos en la placa que conforma el puente H, se utilizan para varias pruebas en las que el

robot trata de orientarse allá donde la intensidad de la luz sea mayor.

Los sensores utilizados son los comunes LDR. Sensores que varían su resistencia en función de

la luminosidad del lugar en el cual se encuentren.

Figura 2-7: Sensor LDR

Detalles técnicos:

Resistencia (con luz) ≈ 1kΩ

Resistencia (oscuridad) ≈ 10kΩ

Voltaje máximo 150 V

Disipación 100 mW max

Dimensiones del sensor 2 x 4 x 5 mm

Separación entre pines 4 mm

Largo de patillas 31 mm

Tabla 2-3: Especificaciones LDR

2.6.3. Giroscopio y acelerómetro

El acelerómetro y el giroscopio son dos de los sensores más importantes del sistema sensorial

del vehículo, los cuales están incluidos en el dispositivo móvil que está conectado con la placa

Arduino UNO, a la que envían información relativa a la orientación del coche y a la velocidad

angular del mismo.

2.6.3.1. Giroscopio

Mide los movimientos de un dispositivo con un brazo de accionamiento, sobre el que, cuando el

smartphone rota, actúan la fuerza de Coriolis y se produce una vibración vertical. Esto hace que

la parte que no se mueve, un estator fijo, se doble, produciendo movimiento sobre el brazo de

detección. Este hecho ayuda a calcular la velocidad angular, que más tarde se transforma en una

señal eléctrica que el dispositivo procesa de manera instantánea.


9

9

Figura 2-8: Imagen de giroscopio

2.6.3.2. Acelerómetro

Fabricado en silicio, es el responsable de detectar los cambios de orientación en los terminales,

con el fin de que estos puedan rotar el contenido de la pantalla hacia una posición vertical u

horizontal. En nuestro caso, nos indicará el ángulo de orientación del marco del móvil con

respecto al marco global.

Está formado por dos placa metálicas (una fija y otra móvil) enfrentadas que componen un

condensador. A ellas se suma un material como por ejemplo papel, que sea dieléctrico. Cuando

se produce la aceleración y el teléfono la detecta, cambia la capacidad del condensador. Al

producirse movimiento, la placa del móvil también se desplaza y reduce o aumenta la distancia.

El papel se encargará de almacenar la energía que llega de las placas. El sensor cuantificará y

enviará la carga al chip para que procese y halle qué aceleración se ha producido, lo que en

última instancia es tenido en cuenta para ejecutar una acción en el sistema.

2.7. Dispositivos móviles utilizados

Para enviar los datos recibidos por los sensores se utilizaron dos dispositivos móviles, de los

cuales solo se hablará sobre uno de ellos, aquel que cumpla la función de comunicar la placa de

Arduino con el ordenador. El otro simplemente no poseerá otra función que no sea la de ser

punto de acceso al cual todos los dispositivos del sistema se conecten.

2.7.1. BQ Aquaris E5

Es el tercer modelo en la escala de la nueva gama de smartphones bq Aquaris E. Sus principales

bazas son su pantalla de cinco pulgadas, un potente procesador de cuatro núcleos y 2 GB de

memoria RAM que ofrece una mayor fluidez del sistema, Android 4.4 KitKat. La batería es de

polímeros de litio con capacidad para 2.500 mAh. Además, la estructura de la carcasa está

reforzada por una capa de aluminio y magnesio. Aparte de lo anterior, lo que realmente nos

interesa de este smartphone es que pueda alojar aplicaciones de Android, lo cual cumple al ser

éste su sistema operativo.


10

10

Figura 2-9: Imagen de móvil BQ Aquaris E5

Detalles técnicos:

Estándar 2G GSM 850/900/1800/1900 Mhz

3G HSPA+900/1200 Mhz

Peso y dimensiones 142 x 71 x 8.65 mm

134 g

Memoria 8 GB

Ampliable con tarjetas microSD hasta 32 GB

2 GB de memoria RAM

Pantalla Pantalla multitáctil capacitiva

IPS de 5 pulgadas

Resolución Full HD (1920x1080 píxeles) 440ppp

Resolución HD (1290 x 720 píxeles) 295 ppp

178º ángulo de visión

Cámara Sensor de 13 megapíxeles trasero

Enfoque automático

Doble Flash LED

Grabación de vídeo a 1080 p

Sensor de 5 megapíxeles frontal

Controles y conexiones Android 4.4 KitKat

Procesador modelo FHD: Octa Core Cortex A7

hasta 2 GHz Media Tek

Procesador modelo HD: Quad Core Cortex A7

hasta 1.3 GHz Media Tek

3G

Wi-Fi 802, 11 b/g/n 2.4 Ghz

Dual SIM

GPS

Bluetooth

MicroUSB

Salida de 3.5 milímetros para auriculares

Tabla 2-4: Especificaciones BQ Aquaris E5 y Aquaris E5 HD

Realmente cualquier teléfono es válido siempre y cuando cumpla el requisito de tener Android

como sistema operativo y posea giroscopio y acelerómetro.


11

11

2.8. Ordenador utilizado

El ordenador utilizado en este trabajo es un Acer Aspire 5750G, el cual posee los

requerimientos básicos para ser utilizado como maestro. Posee una partición en el disco duro

con Ubuntu 16.04 LTS como sistema operativo. Hay que destacar que cualquier ordenador que

pueda albergar ROS Groovy o superior, o una máquina virtual que tenga instalada una versión

de ROS mayor o igual a Groovy, puede utilizarse para este proyecto.

2.9. Andruino R2 montado

A continuación se mostrarán imágenes del vehículo montado y listo para ser iniciado.

Figura 2-10: Andruino R2 montado

Figura 2-11: Andruino R2, muestra de disposición de las baterías y cables


12

12


13

13

3. Software de Andruino

3.1. Ubuntu

Ubuntu es el sistema operativo que se ha usado para alojar ROS. Es un sistema operativo basado

en GNU/Linux que se distribuye como software libre. Es un sistema modular orientado a

proporcionar facilidad de uso. El primer lanzamiento del sistema operativo Ubuntu, fue el 20 de

octubre de 2004. La versión más reciente es Ubuntu 17.04 Zesty Zapus (Pícaro Zepus) lanzada

en el año 2017. No obstante, la versión que se ha utilizado para desarrollar el trabajo es la

versión de Ubuntu 16.04 LTS Xenial Xerus.

Una de las novedades más importantes de la versión es la inclusión de paquetes Snap, que

permitirá al usuario actualizar las aplicaciones más frecuentemente, sean más convergentes, y

estén aisladas del resto del sistema para mejorar la seguridad y estabilidad.

Además, viene con una versión modificada del Kernel 4.4 de Linux, que añade mejoras a la

estabilidad, el rendimiento y la eficiencia del sistema, así como en el manejo del sistema de

archivos. Incorpora además soporte para el último hardware de Intel y AMD, los procesadores

Intel SKylake o la gráfica Corsair Vengeance K90, así como los chips TPM 2.0 y volúmenes

RAID5, entre otras muchas cosas.

Es bueno saber que cada seis meses se publica una versión nueva de Ubuntu que recibe soporte

durante nueve meses. La versión que se ha utilizado al ser LTS (Long Term Support) recibe

soporte técnico durante cinco años desde la fecha de lanzamiento.

La principal razón por la que se ha usado Ubuntu, es porque ROS (Sistema Operativo del

Robot) solo está disponible para dicha plataforma. Otra razón por la cual es interesante usar

Ubuntu, es porque es un sistema operativo de código abierto y cuenta con una comunidad de

desarrolladores bastante extensa, que mejoran dicho sistema de manera continua.

3.2. ROS

ROS (Robot Operating System) es un conjunto de librerías y herramientas que permiten crear

aplicaciones para robots. ROS no es un sistema operativo en sí, sin embargo, provee de los

servicios estándar de éste tales como abstracción de hardware, control de dispositivos de bajo

nivel, implementación de funcionalidades usadas habitualmente, paso de mensajes entre


14

14

procesos y mantenimiento de paquetes. También ofrece herramientas y librerías para escribir y

ejecutar código mediante múltiples computadoras.

El ámbito de ROS abarca una red peer-to-peer (de igual a igual) de nodos, que pueden estar

distribuidos entre varias computadoras y que se comunican libremente usando la infraestructura

de comunicaciones de ROS.

La meta de ROS no es ser el entorno con el mayor número de características. De hecho el

principal fin es apoyar la reutilización de código en la búsqueda y desarrollo de aplicaciones.

ROS es un marco de procesos distribuido que posibilita su realización para ser diseñadas de

forma aislada y desacopladas en el tiempo de ejecución. Estos procesospueden ser agrupados en

Packages (paquetes) y Stacks (Pilas), los cuales son más fáciles de distribuir. ROS también

ampara un sistema federado de Repositories (Depósitos) que posibilita la colaboración entre

grupos.

Para poder lograr el fin último de compartir y colaborar, hay múltiples puntos que deben ser

satisfechos en el ámbito de ROS:

-Liviano: ROS está diseñado para ser lo más ligero posible, por lo que el código escrito para

ROS puede ser usado con otros tipos de softwares de robots.

-Librerías ROS-agnostic: el modelo de desarrollo preferido es escribir librerías ROS-agnostic

con interfaces funcionales.

-Independencia de lenguajes: el entorno de ROS es relativamente fácil de implementar en

cualquier lenguaje de programación. Tenemos a nuestra disposición librerías en Python, C++ y

Lisp. Aunque también existen librerías experimentales en Java y Lua. Lo que queremos decir

con ello, es que nuestros nodos o programas podrán estar programados en los distintos lenguajes

anteriormente nombrados, sin posibilidad relativa de conflicto entre ellos.

-Fácil de probar gracias a que posee un entorno de pruebas llamado "rostest", la cual hace más

fácil la comprobación y reparación de los errores que se pudieran cometer.

-Ajuste: ROS es apropiado para sistemas con tiempos de ejecución extensos y para un número

amplio de procesos.

3.2.1. Sistema de archivos

Los componentes del sistema de archivos que abarcan la mayoría de los recursos de ROS son

los siguientes:

-Paquetes(Packages): es la unidad de organización de software del código de ROS. Cada

paquete puede contener librerías, nodos, scripts, archivos de configuración, etc. En definitiva,

cualquier documento que pueda ser útil organizado todo en un mismo directorio.

-Metapaquetes (Metapackages): Son paquetes especializados cuyo propósito es representar a un

grupo relacionado de paquetes.


15

15

-Manifiesto de paquetes (Package Manifests): es la descripción de un paquete. Su propósito es

definir las dependencias del paquete, los tipos de mensajes y guardar información acerca del

mantenedor del mismo, la versión, licencia, etc.

-Depósitos (Repositories): es una colección de paquetes que comparte un mismo sistema de

control de versiones y pueden actualizarse mediante una herramienta que proporciona el entorno

de ROS.

-Tipos de mensajes (msg): descripciones de mensajes, definen la estructura de datos para los

mensajes mandados en ROS.

-Tipos de servicios (srv): descripciones de servicios, definen las peticiones y las respuestas de la

estructura de datos para los servicios en ROS.

3.2.2. Grafos de computación

El grafo de computación es una red de igual a igual (peer-to-peer) de los procesos de ROS que

están tratando datos de manera conjunta. Las ideas básicas del grafo de computación de ROS

son los nodos, Maestro, Servidor de parámetros, mensajes, servicios, topics (temas), y bags

(bolsas), todo ello provee de información al grafo en diferentes aspectos.

Estos conceptos están implementados en el repository "ros_comm":

-Nodos: es un ejecutable que usa ROS para comunicarse con otros nodos por medio de los

topics o servicios. ROS está diseñado para ser modular por lo que un sistema de control robótico

tendrá normalmente varios nodos. Un nodo de ROS estará escrito normalmente en C++ o

Python, utilizando las librerías roscpp o rospy.

-Maestro: el Maestro de ROS provee de un nombre de registro y cuida del resto del grafo de

computación. Sin el Maestro, los nodos no podrían encontrarse los unos con los otros, cambiar

mensajes o invocar servicios.

-Servidor de parámetros: permite guardar y recuperar los datos de una localización específica.

-Mensajes: los nodos se comunican entre ellos mediante el uso de mensajes. Un mensaje es una

estructura simple de datos que contiene campos determinados (entero, lógico, float, etc).

-Topics: los mensajes entre nodos se mandan mediante una vía de transporte con la semántica de

publicación/suscripción. Un nodo envía un mensaje por medio de una publicación a un topic

dado. El topic es un nombre que es usado para identificar el contenido del mensaje. El nodo que

está interesado en cierto tipo de dato se suscribirá al topic apropiado. Puede haber múltiples

nodos publicadores y suscriptores para un solo topic y solo un nodos que pueda

publicar/suscribirse a varios topics.

-Servicios: se utiliza para interacciones de petición/respuesta. Un nodos ofrece un servicio bajo

un cierto nombre, y otro nodo solicita dicho servicio enviando una petición y esperando una

respuesta. Tal es el caso como se hablará más tarde de la calibración de la cámara.


16

16

-Bags: es un método para guardar y reproducir datos de mensaje de ROS. Es de utilidad para el

desarrollo y las pruebas de algoritmos. Ya que a veces puede ser difícil obtener información útil

de algunos sistemas.

3.3. Andruino R2 firmware

Programar un Arduino consiste en traducir a líneas de código las tareas automatizadas que

queremos hacer leyendo de los sensores y en función de las condiciones del entorno programar

la interacción con el mundo exterior mediante unos actuadores.

Arduino proporciona un entorno de programación sencillo y potente para programar, y además

incluye las herramientas necesarias para compilar el programa y grabar el mismo ya compilado

en la memoria flash del microcontrolador. El IDE nos ofrece un sistema de gestión de librerías y

placas muy práctico. Como IDE es un software sencillo que carece de funciones avanzadas

típicas de otros IDEs, pero suficiente para programar.

El lenguaje de programación de Arduino es C++ "adulterado", es decir, es una adaptación que

proviene de avr-libc que proee de una librería de C de alta calidad para usar con GCC

(compilador de C y C++) en los microcontroladores AVR de Atmel y muchas utilidades

específicas para las MCU AVR de Atmel como avrdude.

Las herramientas necesarias para programar los microcontroladores AVR de Atmel son avr-

binutils, avr-gcc y avrlibc y ya están incluidas en el IDE de Arduino, pero cuando compilamos y

cargamos un sketch estamos usando estas herramientas.

Aunque se hable de que existe un lenguaje propio de programación de Arduino, no es cierto, ya

que la programación se realiza en C++ pero Arduino ofrece una api o core que facilitan la

programación de los pines I/O y de los puertos de comunicación, así como otras librerías para

operaciones específicas. El propio IDE ya incluye estas librerías de forma automática y no es

necesario declararlas expresamente. Otra diferencia con respecto a C++ es la estructura del

programa.

En Arduino se pueden diferenciar dos bloques. Dichas partes son necesarias y no se deben

obviar. Por un lado, tenemos setup() el cual es la parte encargada de recoger la configuración,

en nuestro caso inicializa los parámetros de nuestro robot, y luego está loop() que contiene el

programa que se ejecuta cíclicamente realizando las tareas correspondientes al estado en el cual

se encuentra.

Calibración y control

17

17

4. Calibración y control

4.1. Calibración automática

Como se ha indicado Andruino R2 disponía de diferentes test para el autoajuste de los

parámetros. No obstante, estaban poco automatizados y necesitaban de la asistencia del usuario

para obtener los resultados finales. Ya sea variables o gráficas de utilidad. Por ello se ha

realizado un programa que ejecute los test que el vehículo necesitaba para calibrarse de la

manera más automática posible.

Como ejemplo se muestra a continuación el ajuste de la relación entre las señales PWM y la

velocidad angular mediante el suso de los siguientes cuatro parámetros:

-SlopeLeft (Pendiente de la relación entre el PWM y la velocidad angular): dicho parámetro

corresponde a la pendiente de la función hallada en el test 4, cuya función es relacionar el PWM

con la velocidad angular de las ruedas del robot. En este caso corresponde al conjunto de ruedas

izquierdo.

-OffsetLeft(Offset de la relación entre el PWM y la velocidad angular): esta constante

corresponde al offset de la función que relaciona PWM suministrado al conjunto de ruedas

izquierdo con la velocidad angular de dicho conjunto.

-SlopeRight (Pendiente de la relación entre el PWM y la velocidad angular): dicho parámetro

corresponde a la pendiente de la función hallada en el test 4, cuya función es relacionar el PWM

con la velocidad angular de las ruedas del robot. En este caso corresponde al conjunto de ruedas

derecho.

-OffsetRight(Offset de la relación entre el PWM y la velocidad angular): esta constante

corresponde al offset de la función que relaciona PWM suministrado al conjunto de ruedas

derecho con la velocidad angular de dicho conjunto.

Para hallar la relación entre ambas magnitudes se empleará script. El test se compone de cuatro

partes. En cada parte un grupo de ruedas recibirá la señal de PWM desde el valor mínimo hasta

el máximo. Una vez finalizado, se obtienen las muestras de las velocidades angulares en cada

parte del test, se filtran los datos y se realiza una regresión lineal de cada parte. Obtendremos de

esta forma cuatro curvas que relacionarán el PWM con la velocidad angular obtenida. Estas

rectas poseen una pendiente y un offset que serán asociados a cada conjunto de ruedas. Al grupo

derecho le corresponderán los parámetros SlopeRight y OffsetRight mientras que al izquierdo

los parámetros SlopeLeft y OffsetLeft.


18

18

En las siguientes figuras podemos observar la relación PWM/ω del conjunto de ruedas derecho

e izquierdo para el primer y tercer estado de la prueba. Como se puede notar, es necesario

realizar un filtrado de las muestras para un correcto ajuste de las rectas de regresión y que se

obtenga una buena relación.

Figura 4-1: Relación entre PWM-ω, conjunto derecho

Figura 4-2: Relación PWM-ω, conjunto izquierdo


19

19

Finalmente, en el script, se preguntará al usuario si desea modificar dichos valores hallados por

el test por los valores por defecto.

Tendremos entonces los parámetros SlopeLeft, SlopeRight, OffsetLeft y OffsetRight.

Cuyos valores hallados mediante la prueba son:

- SlopeLeft: 124.2

- SlopeRight: 103.07

- OffsetLeft: 112.5

- OffsetRight: 117.4

4.2. Calibración del modelo cinemático

El ajuste del modelo cinemático se basa principalmente en el uso de tres parámetros:

-Kssr (modificación del radio de las ruedas): este parámetro sirve para hacer equivalente el radio

de las ruedas del skid-steer al radio que poseerían las ruedas si fuera un robot diferencial.

-Kssb (modificación de la distancia entre las ruedas): constante que relaciona la distancia entre

las ruedas del robot skid-steer que poseemos con la distancia entre ruedas de un robot

diferencial.

-KssICCR (modificación del radio de curvatura): este valor se utiliza para adaptar el

movimiento circular que pudiera realizar el robot skid-steer con respecto al movimiento circular

que realizaría el robot diferencial. El valor de dicha constante se ha considerado igual a uno

debido a que el centro de rotación del vehículo que poseemos se sitúa sobre la rueda central de

cada conjunto de ruedas.

Para hallar los tres parámetros correspondientes al ajuste de las constantes cinemáticas del

robot, es necesario entender las ecuaciones del modelo cinemático de un robot skid-steer y del

robot diferencial, para que así se pueda ver de manera clara la relación entre ambos modelos y la

forma de obtención de dichas constantes.

Andruino R2 pertenece al grupo de robots móviles skid-steer, los cuales poseen ciertas

similitudes a los vehículos del grupo diferencial. Sin embargo, se diferencian en que los

primeros pueden poseer más de dos ruedas y como se detallará más adelante, el skid-steer

normalmente posee el centro instantáneo de giro fuera del propio robot, en lugar de estar

localizado bajo la huella de la rueda más cercana al centro de giro, como sucede en el caso del

robot diferencial. No obstante hay que nombrar también las similitudes existentes entre los dos

tipos de robots. Las ruedas de ambos son fijas, por lo que variarán su dirección regulando la

velocidad angular de ambas ruedas.

Para entender mejor la analogía del robot Andruino (skid-steer) con la de un robot diferencial,

se deberán de hacer algunas consideraciones:


20

20

1. El centro de masas del robot está localizado en el centro geométrico del cuerpo.

2. Las ruedas de cada lado rotan a la misma velocidad. Este hecho es algo que se ha

comprobado de manera analítica, dando valores de velocidad angular a los engranajes y

utilizando las relaciones de transmisión para obtener las velocidades angulares de cada

rueda.

3. El robot realiza su movimiento en un superficie uniforme, y todas las ruedas siempre

están en contacto con el suelo.

Definimos un marco inercial (X,Y) (marco global) y un marco local (cuerpo del robot) (x, y). Se

supone que el robot se mueve en un plano con velocidad lineal expresada en el marco local

como v=(vx, vy, 0)T y rota con una velocidad angular w=(0, 0, ω z)

T. Si q=(X, Y, Ɵ)

T es el vector

de estados que describe de manera general las coordenadas del robot (por ejemplo, la posición

en el eje de coordenadas y la orientación Ɵ del marco de coordenadas local con respecto al

marco inercial), por tanto, q'=(X', Y', Ɵ')T es el vector generalizado de las velocidades. Es

sencillo calcular la relación entre ambos marcos (global y local):

z

y

x

v

v

sen

sen

Y

X

100

0cos

0cos

'

'

'.

(1)

Dejemos que ωi, i=1,2, ..., 6 sean las velocidades angulares de las ruedas, siendo ω1:=velocidad

angular de la rueda delantera izquierda, ω3:= velocidad angular de la rueda trasera izquierda, y

ω4 y ω6 las velocidades correspondientes a las ruedas de la derecha. En nuestro caso tendremos

seis ruedas, por lo que habiendo asumido las hipótesis anteriores:

ω l= ω 1= ω 2= ω 3 ω r= ω 4= ω 5= ω 6

Luego la cinemática directa en el plano se podrá estipular como:

STr

STl

z

y

x

r

rfv

v

(2)

donde v=(vx, vy) es la velocidad de traslación del vehículo con respecto a su marco local, y ωz es

su velocidad angular, r es el radio de las ruedas.

Cuando el robot móvil se mueve, denotamos el centor de rotación instantáneo (ICR) de la marca

del lado izquierdo, marca del lado derecho y el cuerpo del robot como ICRl, ICRr e ICRG,

respectivamente. Es sabido que ICRl, ICRr e ICRG, yacen sobre una línea paralela al eje x.

Definimos el eje de coordenadas x-y para ICRl, ICRr e ICRG como (xl, yl), (xr, yr) y (xG, yG)

respectivamente.

Nótese que las huellas tienen la misma velocidad angular ωz que el cuerpo del robot. Podemos

obtener la siguiente relación geométrica:


21

21

z

y

rlG

z

STrx

r

z

STlx

l

z

x

G

vxxx

rvy

rvy

vy

(3)-(6)

De las ecuaciones de la (4) a la (7), las relaciones cinemáticas (3) pueden ser representadas

como:

STr

STl

z

y

x

r

rJv

v

(7)

Donde los elementos de la matriz Jω dependen de las coordenadas de las huellas ICR (centro

instantáneo de giro):

11

1GG

lr

rl

xx

yy

yyJ (8)

Si el robot móvil se simétrico como sucede en nuestro caso, podemos obtener el modelo

cinemático simétrico (por ejemplo los ICRs descansan simétricamente sobre el eje x por lo que

xG = 0), por lo que la matriz Jω puede ser escrita como sigue:

11

002

100

0

yy

yJ (9)

donde y0 = yl = -yr es el punto donde se sitúa el ICR. Nótese que vl = ωlr, vr = ωrr, para el

modelo simétrico se han obtenido las siguientes ecuaciones:

00 22

022

y

vv

y

rr

v

vvrrv

rlSTrSTl

z

y

rlSTrSTl

x

(10)

Gracias a las suposiciones anteriores y a las ecuaciones anteriores, podemos obtener la siguiente

ecuación matricial:


22

22

'

'

'

y

x

=

100

0cos

0cos

sen

sen

X

00

0

0

0

0

2

1

2

100

22

yy

y

y

y

y

X

STr

STl

r

r

(11)

Resolviendo (11), siendo ayudado también por las igualdades (1) - (10), nos queda:

'

'

'

y

x

=

)(2

)(2

cos)(2

0

lrST

rl

ST

rlST

y

r

senr

r

(12)

Sabiendo las ecuaciones cinemáticas del robot Andruino (skid-steer), nos dispondremos a

nombrar brevemente el modelo cinemático de un robot diferencial.

El modelo para determinar la posición de un móvil de tracción diferencial se puede obtener a

partir de las velocidades vl y vr, las cuales se obtienen con la siguiente ecuación.

vl = ω l rdiff vr = ω r rdiff (13)

donde wl y wr son las velocidades angulares de cada rueda. Las velocidades lineales y angulares

del robot se obtienen con las ecuaciones posteriores.

2

)(

2

2

)(

2

diffrllr

difflrlr

rvv

rvvv

(14) y (15)

Considerando que el robot diferencial se mueve en una superficie plana, sin deslizamiento y que

los ejes de las ruedas son perpendiculares a la superficie plana, se puede demostrar que si p = (x,

y. Ɵ)T es el vector de coordenadas de la posición y orientación del robot y que q' = (v,ω)

T es el

vector de la velocidad lineal y angular del móvil, se pueden escribir las siguientes ecuaciones:

'

'

'

y

x

=

10

0cos

0

sen

X

v (16)

Sustituyendo las ecuaciones (13) y (14) en la ecuación (15) podemos obtener:


23

23

'

'

'

y

x

=

diff

diff

diff

diff

diffdiff

diffdiff

L

r

L

r

rr

senr

senr

2

cos

2

cos22

X

r

l

(17)

Y resolviendo (17), obtendremos:

'

'

'

y

x

=

)(

)(2

cos)(2

lr

diff

diff

lr

diff

lr

diff

L

r

senr

r

(18)

Contando con ambos modelos cinemáticos solo queda igualar para poder sacar kssr y kssb

constantes que adaptan las ecuaciones del skid-steer al modelo diferencial. Utilizamos entonces

(12) y (18), igualamos y llegamos a la conclusión de que:

ST

diff

ssrSTssrdiffr

rkrkr (19)

Damos un valor al radio de la rueda del vehículo diferencial tal que el área de dicha rueda sea

igual a tres veces el área de una de las ruedas de nuestro robot, ya que cada lado posee tres

ruedas. Por tanto, siendo cmrST 75.1 :

22 863.283 cmrA diffRdiff

031.3863.28

diffr (20)

Si sustituimos (20) en (19), obtenemos que:

732.1ssrk

Hallado finalmente el parámetro que modifica el radio, falta por hallar aquel que modifica la

distancia entre los ejes. Para ello, igualaremos de nuevo (12) y (18) y nos fijaremos en la última

ecuación. Después de una simplificación de términos, nos queda que:

diff

ssr

diff

STssrST

diff

diffST

L

k

yL

rk

y

r

L

r

y

r

000 2

1

22

Hay que hallar por tanto cuál es el valor de y0. Al considerar que el centro de rotación

instantáneo está situado bajo la rueda central de uno de los dos conjuntos de ruedas, será de

cmy 45.70 . Por lo que:


24

24

cmykL ssrdiff 8068.252 0

Sin embargo, y0 en caso del skid-steer no es la longitud que separa ambas ruedas entre sí. En

nuestro caso, cada conjunto de rueda está situada en forma de arco, por lo que la distancia entre

ejes no es la misma desde cada rueda. No obstante consideraremos que el arco que forma cada

grupo de ruedas tiene un centro cercano al infinito, con lo cual la distancia entre los ejes será la

misma:

cmLST 9.14

Con dicho valor, realizamos lo siguiente para hallar kssb:

732.1ST

diff

ssbSTssbdiffL

LkLkL

Como bien se ha dicho varias veces, consideramos que el ICR reside bajo la marca de la rueda

central del conjunto de ruedas que disminuye su velocidad para realizar el arco, por lo que

1ssICRk .

Como bien es sabido para realizar el control de cualquier tipo de robot es necesario hallar el

modelo cinemático inverso de éste. El fin ello es que nuestro esquema de control reciba la

velocidad lineal y velocidad angular deseadas para obtener las velocidades angulares de cada

conjunto de ruedas y se haga una conversión de éstas variables a valores PWM, como se

detallará más adelante.

El siguiente, es el modelo cinemático inverso de un robot diferencial con las constantes de

modificación del radio y la longitud entre las ruedas, el cual es el modelo que está

implementado en el Arduino:

v

Lk

Lk

rk ssb

ssb

STssrr

l

21

21

1

4.3. Controladores

El programa de Arduino posee un total de tres controladores PID que se utilizarán tanto para los

diferentes test que se poseen como para las distintas trayectorias que se realicen:

PID para movimiento en línea recta:

KpLine: Corresponde a la constante proporcional del PID.

KiLine: Corresponde a la constante integral del PID.

KdLine: Corresponde a la constante derivativa del PID.


25

25

PID para giro:

KpSpin: Corresponde a la constante proporcional del PID.

KiSpin: Corresponde a la constante integral del PID.

KdSpin: Corresponde a la constante derivativa del PID.

PID para movimiento circular:

KpArc: Corresponde a la constante proporcional del PID.

KiArc: Corresponde a la constante integral del PID.

KdArc: Corresponde a la constante derivativa del PID.

Todas las constantes se han hallado de manera experimental. Para ver los efectos de los

parámetros que poseen los PIDs existen varios test que se pueden ejecutar a través del script.

En la siguiente figura podremos ver el esquema de control que se ha utilizado para el Andruino

R2.

Figura 4-3: Esquema de control utilizado por el vehículo móvil

Debido a la necesidad de verificar el código implementado en Andruino R2, se ejecutaron

múltiples pruebas que probarán la fiabilidad de los controladores, y se determinó que, aunque

funcionaban, poseían un error integral que se acumulaba de un experimento a otro. Este hecho,

desencadenó en la revisión y posterior inclusión de un PID y un PD de tipo incremental, el cual

es por naturaleza anti wind-up. También es denominado incremental, porque el control lo

realiza a incrementos sobre la señal de control. Es decir, va aproximando la señal de control

mediante incrementos sobre la señal de control anterior.

A continuación se expondrán de manera más clara las ecuaciones, esta vez si, tanto del PID

incremental como del PD incremental.

)2()( 211 kkkkkkk eeeKdeKieeKpPID

kkk PIDPIDPID 1


26

26

)2()( 211 kkkkkk eeeKdeeKpPD

kkk PDPDPD 1

Sin embargo, la implementación de estos controladores no solucionó del todo el problema, ya

que la deriva del acelerómetro y el giroscopio son en los muchos experimentos que se han

realizado, bastante considerables. Pudiendo hacer que el robot siguiese una línea recta de

manera perfecta, a realizar una trayectoria totalmente diferente para los mismos parámetros de

control. Por esto último se hizo necesaria la inclusión del filtro de Kalman.

4.3.1. Implementación del filtro de Kalman 1-D

Como bien es sabido, el filtro de Kalman posee varias cualidades interesantes para ser aplicados

a sensores que ofrezcan una medida poco fiable. Tal es el caso de los sensores de ultrasonido, y

del acelerómetro y giroscopio que posee Andruino. Debido a los diversos problemas con los que

el usuario del robot se puede topar en relación a la calibración, es indispensable su inclusión.

Para probar la eficacia de dicho filtro, se realizó un test que posee dos estados y consiste en lo

siguiente:

- El robot está quieto, y toma las medidas de los objetos que están situados enfrente de él. Al

mismo tiempo, el filtro está siendo ejecutado. El test en este estado, está comparando las

medidas de los sensores y las estimaciones del filtro de Kalman, mostrando de esta forma un

error entre la medida tomada y la estimación.

- Llegado a un cierto tiempo desde que se inició el test, el robot se pone en marcha hasta que

alcanza una distancia igual o inferior a 0.5 metros con respecto de un obstáculo. El límite de

distancia se ha comparado con la estimación realizada del filtro de Kalman, por lo que

podremos saber si las estimaciones realizadas son fiables.

Herramientas para realizar el mapeado

27

27

5. Herramientas para realizar el

mapeado

El último objetivo de este proyecto era que Andruino R2 realizará un mapa del área en la cual se

encontrase. Para ello se va a analizar la viabilidad de utilizar una herramienta denominada

Costmap 2D utilizando los sensores de ultrasonidos y de orientación disponibles en Andruino

R2.

5.1. Costmap 2D

El paquete llamado "costmap_2d" ofrece la implementación de un mapa 2-D que toma los datos

a través de los sensores, con cuya información, construye una cuadrícula de gastos 2-D o 3-D, y

aumenta los costes en un mapa de costes 2-D basado en el casillero y en un radio de aumento

especificado por el usuario. Este paquete también provee de ayuda para la inicialización de un

servidor de mapas de coste, páginas de mapas de coste, y parámetros de suscripción y

configuración de los topics de los sensores.

5.1.1. Breve descripción

Costmap 2D ofrece una estructura configurable que mantiene la información acerca de a dónde

el robot debería de ir de la mano de un ajedrezado de costes. El mapa de costes utiliza los datos

que proporcionan los sensores y la información del mapa estático para almacenar y actualizar la

información sobre los obstáculos del mundo a través de costmap_2d::Costmap2DROS . El

elemento anterior provee de una interfaz 2-D para sus usuarios, lo que significa que las

consultas sobre los obstáculos solo pueden hacerse mediante columnas. Por ejemplo, una mesa

y un zapato en la misma posición del plano X-Y, pero con diferentes coordenadas Z poseerán el

mismo valor de coste en el mapa de costes.

La interfaz principal es costmap_2d::Costmap2DROS, la cual mantiene muchas de las

funcionalidades de ROS. Contiene un costmap_2d::LayeredCostmap el cual es usado para

realizar un seguimiento de cada capa. Cada página está instanciada en el "Costmap2DROS"

usando pluginlib y es añadida al LayeredCostmap. Las capas pueden ser compiladas

individualmente, permitiendo cambios arbitrarios para el mapa de costes a través de la interfaz

de C++. La clase costmap_2d::Costmap2D implementa la estructura básica de datos para

almacenar y acceder a los mapas de coste de dos dimensiones.

Costmap automáticamente se suscribe a los topics de los sensores a través de ROS y se

actualiza. Cada sensor es usado para cualquier marca (insertar información acerca de un

obstáculo en el mapa de costes), limpiar (elimina la información del obstáculo en el mpa de

costes) o ambos. Una operación de calificación es solo un índice dentro de un array para


28

28

cambiar el coste de una celda. Una operación de limpieza, no obstante, consiste en buscar a

través de la cuadrícula desde el origen del sensor hacia afuera para cada observación reportada.

5.1.2. Ocupación de estados

Mientras cada celda del mapa de costes posee uno de los 255 diferentes costes, la estructura

subyacente que lo usa es capaz de representar sólo tres. Específicamente, cada celda en ésta

estructura puede ser libre, ocupada o desconocida. Cada estatus tiene un coste especial asociado.

Las columnas que tienen un cierto número de casillas ocupadas son asignadas al grupo Letal, las

que tienen un cierto número de celdas desconocidas, al Espacio Desconocido, aquellas

columnas que no están ocupadas por ningún objeto serán asignadas al grupo Libre.

5.1.3. Actualizaciones del mapa

El mapa de costes se actualiza cada cierto ciclo especificado por el parámetro update_frecuency.

En cada ciclo, los sensores obtienen información, se realizan las operaciones de marcado y

limpiado en la estructura subyacente del mapa de costes, y dicha estructura es proyectada dentro

del mapa donde los valores de los costes son asignados como se ha descrito anteriormente.

Después de todo lo anterior, se hace un aumento de cada obstáculo calificado como Letal.

5.1.4. Transformadas

Para incluir datos de los sensores en el mapa de costes costmap_2d::Costmap2DROS

realiza dicha labor. Específicamente, asume que todas las transformaciones entre el marco de

coordenadas especificadas por los parámetros global_frame, robot_base_frame y las fuentes de

los sensores están conectadas y actualizadas.

El parámetro transform_tolerance fija el máximo valor de retraso permitido entre dichas

transformadas. Si el árbol de transformadas no está actualizado a su debida frecuencia, el

navigation_stacks para el robot.

(Navigation_stacks toma información de la odometría y los sensores y publica comandos de

velocidad para mandarlos a la base del móvil).

5.1.5. Inflación/Aumento

Es el proceso de propagar los valores de los costes más allá de las zonas letales con la intención

de evitar la colisión del robot con los objetos del entorno. Para ello, definimos cinco tipos de

valores definidos en el mapa de costes:

-Letal: significa que existe un obstáculo en dicha zona. Por lo que si el robot llega a esa zona

existirá la colisión.

-Inscrito: significa que la distancia entre el obstáculo y el radio inscrito del robot es menor a una

celda. Por lo que el robot estaría cerca de colisionar.

-Posiblemente circunscrito: similar al coste anterior, pero usando el radio circunscrito del robot

como distancia de corte. Si el centro del robot yace sobre una celda sobre o próxima a este

valor, dependerá de la orientación del robot el riesgo que tendrá éste de colisionar con el

obstáculo.


29

29

-Espacio Libre: se asume que es cero o próximo a cero. Y significa que no hay nada que pueda

poner en riesgo al robot en esa localización.

-Desconocido: este coste representa que no se conoce nada sobre dicho lugar, lo cual puede

llevar al usuario a diversas interpretaciones.

-Todos los demás costes son asignados a valores entre "Posiblemente circunscrito" y "Espacio

Libre".

Figura 5-1: Calificación de los estados de las celdas en Costmap 2D

5.1.6. Tipos de mapas

Existen varias formas de iniciar un costmap_2d::Costmap2DROS. La primera es utilizar

un mapa estático. En este caso, el mapa de costes es iniciado para encontrar la anchura, altura e

información acerca de los obstáculos del mapa estático. Esta configuración es usada

normalmente junto con un sistema de localización, que permite al robot registrar los obstáculos

en el marco del mapa y actualizar el mapa de costes gracias a la información obtenida de los

sensores a medida que va avanzando en el entorno.

La segunda forma de inicializarlo es dar la altura y la anchura del espacio y fijar el parámetro

rolling_window a true. Dicho parámetro mantendrá al robot en el centro del mapa de costes a

medida que se va moviendo a través del mundo, ofreciendo información acerca de los

obstáculos que se encuentre. Es la llamada inicialización dinámica.


30

30

5.2. Odometría visual y filtro de Kalman para diferentes medidas

El hecho de que se tenga una deriva bastante alta en las medidas del giroscopio y acelerómetro,

complica mucho la navegación por un entorno cerrado, así como la elaboración de mapas, los

cuales no serían del todo fiables. Por lo que es necesaria la inclusión de la odometría visual.

La odometría visual permite obtener la localización del móvil a partir de las imágenes obtenidas

a través de una cámara. La cual, localiza una serie de puntos de la imagen en áreas, que

comparará cada cierto período de tiempo para ver si su posición (x, y) ha variado y con esto

determinar la posición actual del robot.

Hay que tener en cuenta que es necesario realizar la calibración de la misma. Para ello

utilizaremos el paquete camera_calibration. En nuestro caso, para poner en marcha la

calibración hemos usado el nodo camera_calibrator.py, que es la versión programada en Python.

Realizada la calibración, se deben publicar cada ciclo los datos de la misma por medio de

camera_info, como ya se ha dicho antes.

Teniendo en cuenta todo lo anterior, lo que queda es filtrar las medidas de la odometría. De eso

se encargará el paquete robot_pose_efk, el cual aplica un filtro de Kalman a las medidas

obtenidas, tanto a la proporcionada por la "falsa odometría" de los sensores de ultrasonido,

como la hallada mediante la visión. Publicando una estimación de la posición del robot en

función de las medidas entregadas.

Con dichas estimaciones, se ejecutará el sistema de mapeado del cual se disponga. En este caso,

sería costmap 2D.

Conclusiones y mejoras

31

31

6. Conclusiones y mejoras

Andruino R2 es un robot que cumple su función de manera adecuada. Sirve para aquellos

estudiantes que se quieran iniciar en el mundo de la robótica móvil, pues posee los elementos

esenciales con los que poder trabajar y poder sacar conclusiones.

En el transcurso de este proyecto se han podido validar la calibración mediante la realización de

numerosas pruebas y ejecuciones de los tests implementados. Además se ha mejorado la

realización de la calibración y la relación Andruino R2 usuario, mediante el script, que facilita

enormemente la realización de las pruebas, así como la obtención y gestión de datos.

Además, la implementación de los controladores anti wind-up de tipo incremental, se ha

realizado de forma exitosa, permitiendo que se puedan realizar pruebas sin que se integren el

error evitando de esta forma resultados catastróficos.

Por otra parte cabe destacar, que se ha profundizado en el entendimiento de las herramientas de

elaboración de mapas, así como en todo a lo que concierne al tratamiento de imágenes

propiciado por el objetivo de lograr construir un mapa y localizar a Andruino R2 en él.

6.1. Mejoras

Como posibles mejoras se encuentran las siguientes.

- Calibración de la cámara. La calibración de la cámara se podría simplificar incluyendo

el servicio /set_camera_info, que es requerido por el nodo camera_calibrator.py en la

apliación Android.

- Interfaz de usuario avanzada: el programa de calibración que se ha realizado se podría

mejorar realizando un interfaz y guardando los resultados en un directorio del cual

serían extraídos los datos para su posterior comparación.

Conclusiones y mejoras

32

32

Bibliografía

33

33

7. Bibliografía

https://aprendiendoarduino.wordpress.com/2017/01/23/programacion-arduino-5/

http://robots-argentina.com.ar/MotorCC_L293D.htm

http://www3.gobiernodecanarias.org/medusa/ecoblog/ralvgon/files/2013/05/Caracter%C3%AD

sticas-Arduino.pdf

http://wiki.ros.org/ROS/Concepts

http://wiki.ros.org/navigation

https://hipertextual.com/2016/08/acelerometro-giroscopio

http://nbviewer.jupyter.org/github/Pybonacci/notebooks/blob/master/Regresi%C3%B3n%20Lin

eal.ipynb

https://playground.arduino.cc/Main/Smooth

https://www.norwegiancreations.com/2016/03/arduino-tutorial-simple-high-pass-band-pass-

and-band-stop-filtering/

http://wiki.ros.org/viso2_ros

https://gist.github.com/rossbar/ebb282c3b73c41c1404123de6cea4771

http://wiki.ros.org/costmap_2d

trabajo fin de grado en - bibing.us.esbibing.us.es/proyectos/abreproy/91585/fichero/... · a indus...

Documents