Diseno de un sistema de conducci˜ on aut´ onoma´ para un robot...

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INGENIERIA INFORMATICA

GRADO EN INGENIERIA INFORMATICA

TRABAJO FIN DE GRADO

TECNOLOGIA ESPECIFICA DE COMPUTACION

Diseno de un sistema de conduccion autonomapara un robot Pioneer 3 DX en entornos

controlados e integracion dentro del entornoRobocomp

Daniel Jimenez Martınez

2

Julio de 2014

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INGENIERIA INFORMATICA

Departamento de Sistemas Informaticos

TRABAJO FIN DE GRADO

TECNOLOGIA ESPECIFICA DE COMPUTACION

Diseno de un sistema de conduccion autonomapara un robot Pioneer 3 DX en entornos

controlados e integracion dentro del entornoRobocomp

Autor: Daniel Jimenez Martınez

Directores: Ismael Garcıa Varea

Jesus Martinez Gomez

Julio de 2014

Resumen

Este documento tiene como finalidad no solo dar a conocer el mundo de larobotica al lector, introduciendolo de lleno en la robotica autonoma y en especial,de los vehıculos terrestres autonomos (en adelante robots autonomos), sino ademas,servir como guıa a los futuros investigadores y desarrolladores de nuestra escuelaque pretendan trabajar con esta clase de robots haciendo uso de ARIA y Robocomp,tecnologıas de las que se hablara con mas detalle en las proximas lıneas y de lasque no hay documentacion alguna (en lo referente a trabajar con ambas de formasimultanea).

No se pretende que el lector acabe sabiendo programar su propio robot autono-mo, mas bien dar a conocer los principios basicos de los mismos de forma que, sifinalmente se decide por implementar el suyo propio, posea el mınimo conocimien-to de donde empezar a buscar.

En cuanto al documento, esta estructurado en diferentes capıtulos, cada uno consus propias secciones, organizados segun lo que debe conocer el lector en cada mo-mento para poder seguir sin problema la evolucion del trabajo, incluso sin que esteposea altos conocimientos en robotica o programacion.

El primer capıtulo se centrara en hacer un breve repaso cultural sobre el fascinan-te mundo de la robotica, haciendo especial hincapie en los primeros y mas antiguosingenios que aparecieron hace mas de dos mil anos. Se conoceran los origenes y ladefinicion de la palabra robot, asi como a los mas destacados autores de los mencio-nados inventos y como ha ido cambiando la robotica desde entonces hasta nuestrosdıas, visualizando los usos que le damos actualmente a los robots y que podemosesperar de los mismos en el futuro mas proximo.

El segundo capıtulo resumira las peculiaridades de los robots autonomos, sinentrar demasiado en el hardware ni el software, explicando de forma sencilla y en-tendible los tipos de robots autonomos con los que podemos encontrarnos, ası comoel tipo de entornos en que podemos introducirlos y la finalidad y objetivos que losdefinen. Se expondra la problematica de la robotica autonoma y su solucion usando:

Localizacion mediante el filtro de partıculas

Optimizacion y planificacion de rutas usando A*

II

Control y movimiento mediante la ecuacion PID

Estos algoritmos se explicaran mediante ejemplos graficos y sencillos, sin entraren detalles concretos de implementacion.

Durante el tercer capıtulo, se daran a conocer las dos tecnologıas que han traıdola redaccion de este documento y la realizacion del trabajo de investigacion. En el,se vera que es Pioneer SDK y Robocomp, que define a cada uno, para que sirven,ventajas e invenientes, ejemplos de uso y al final, como se ha realizado la integracionde ambas haciendo posible aprovechar la potencia interna de cada una. Tambien seexpondran los aspectos tecnicos y de hardware del robot Pioneer 3 DX (P3-DX enadelante), ası como los requisitos para hacerlo arrancar y como trabaja ARIA parahacerlo manipulable de cara al usuario.

El capıtulo cuarto esta destinado a exponer los programas y pruebas desarro-lladss para poner de manifiesto todo lo estudiado, investigado y descubierto en elcapıtulo anterior.

El ultimo capıtulo esta reservado para las conclusiones y propuestas que tienencomo objetivo continuar el trabajo recien iniciado aquı. Este proyecto es solo el prin-cipio del camino que aun queda por recorrer en el ambito de la robotica distribuida.

Todos los comandos de consola se han realizado usando un ordenador del labo-ratorio Software 1 bajo la distribucion de Linux Ubuntu 13.04.

Cualquier material, ejemplo o paquete necesario a instalar para trabajar con elrobot se ha adjuntado al CD. Para descargar las versiones mas actualizadas de estospaquetes visitar las fuentes originales de software disponibles en la bibliografıa.

A mis familiares y amigos.

Agradecimientos

La realizacion de este proyecto no habrıa sido posible sin el apoyo incondicionalde amigos, familiares y profesores, que han estado siempre ahı para aquello que henecesitado.

Agradecer a mis amigos por interesarse tanto por el proyecto, mostrando un in-teres abrumador e incitarme a seguir trabajando en el proyecto, que a menudo sehacıa cuesta arriba.

Tambien a mis tutores Ismael Garcıa y Jesus Martinez. A Ismael por mostrarmeel fascinante mundo de la robotica aplicada, estando disponible siempre que ha sidonecesario y hacer todo lo posible por que tuviese disponible el laboratorio y el ma-terial necesario. A Jesus por ofrecerme toda la ayuda necesaria con robocomp paralograr que sacasemos adelante este proyecto de investigacion. Sin su ayuda posible-mente no habrıa sido posible avanzar y descubrir muchos detalles sin documentarhasta el dıa de hoy.

Gracias a todos.

Indice general

INDICE DE FIGURAS IX

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1. INTRODUCCION 1

1.1. Definicion y origen de robot . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. La robotica antıgua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. La robotica moderna . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. La robotica actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5. Expectativas de futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. LA ROBOTICA AUTONOMA 11

2.1. Los vehıculos autonomos . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Tipos de entornos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3. Problematica de los vehıculos autonomos . . . . . . . . . . . . . . . . 13

3. INVESTIGACION DEL HARDWARE Y SOFTWARE DEL ROBOT 27

3.1. Hardware del robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2. Conectar con el robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3. Software de robotica necesario . . . . . . . . . . . . . . . . . . . . . . 33

3.4. Pioneer SDK al detalle . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.5. RoboComp al detalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.6. Integracion de Pioneer SDK y RoboComp . . . . . . . . . . . . . . . . 57

4. IMPLEMENTACION, EXPERIMENTOS Y RESULTADOS 61

4.1. Programas basados en Aria y ArNetworking . . . . . . . . . . . . . . 61

4.2. Componente RoboComp: ServerRobotComp . . . . . . . . . . . . . . 65

VII

VIII Indice general

5. CONCLUSIONES Y PROPUESTAS 715.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

BIBLIOGRAFIA 76

CONTENIDO DEL CD 77

A. Manual de usuario de Pioneer SDK 79A.1. Instalacion del SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79A.2. Compilar un programa basado en ARIA . . . . . . . . . . . . . . . . . 80A.3. Como usar el simulador MobileSim . . . . . . . . . . . . . . . . . . . 82

B. Manual de usuario Robocomp 85B.1. Instalacion de RoboComp . . . . . . . . . . . . . . . . . . . . . . . . . 85B.2. Instalacion y configuracion de DSLEditor . . . . . . . . . . . . . . . . 87B.3. Compilando un modulo cliente/servidor . . . . . . . . . . . . . . . . 88B.4. Solucion de problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

INDICE DE FIGURAS

1.1. Concepto de agencia/Sistema multiagente . . . . . . . . . . . . . . . 1

1.2. Puertas automaticas de Heron . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Leon (izquierda) y androide (derecha) de Da Vinci. . . . . . . . . . . . 4

1.4. Robot bıpedo P3 de Honda. . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5. Robot Stanley de la universidad de Stanford. . . . . . . . . . . . . . . 7

1.6. Guardium (izquierda) y SGR-1 (derecha). . . . . . . . . . . . . . . . . 8

1.7. Enjambre de robots de la universidad de Pensilvania. . . . . . . . . . 8

2.1. Ejemplo de vehıculo autonomo . . . . . . . . . . . . . . . . . . . . . . 12

2.2. Primera etapa de medicion del robot de 4 posiciones fijas del entorno(landmarks). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3. Etapa de remuestreo de las partıculas. . . . . . . . . . . . . . . . . . . 16

2.4. Mapa del entorno, con el punto de partida (azul) y el destino (rojo). . 19

2.5. Primera iteracion de la busqueda. . . . . . . . . . . . . . . . . . . . . . 21

2.6. Resultado A∗ (izquierda) y ruta devuelta (derecha). . . . . . . . . . . 22

2.7. Coche robot, ruedas (azul) y ruta (rojo). . . . . . . . . . . . . . . . . . 23

2.8. Resultado de usar el controlador-P. . . . . . . . . . . . . . . . . . . . . 24

2.9. Resultado de usar el controlador-PD. . . . . . . . . . . . . . . . . . . . 25

2.10. Resultado de usar el controlador-PD con desviacion en la direccion. . 25

2.11. En azul el sesgo cometido. En naranja la correccion de la funcion in-tegradora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1. Pioneer 3-DX en configuracion Laser Navigation. . . . . . . . . . . . 28

3.2. Interruptor general y placa del ordenador a bordo. . . . . . . . . . . . 29

3.3. Esquema distribucion de Aria y ArNetworking . . . . . . . . . . . . . 35

3.4. Ciclo de ejecucion de ArRobot. . . . . . . . . . . . . . . . . . . . . . . 40

IX

X INDICE DE FIGURAS

3.5. Esquema funcionamiento de IceStorm. . . . . . . . . . . . . . . . . . 513.6. Diagrama de un componente Robocomp. Figura obtenida de [7]. . . 56

4.1. Funcionamiento ServerRobotComp. . . . . . . . . . . . . . . . . . . . 66

B.1. Configuracion del entorno Robocomp. . . . . . . . . . . . . . . . . . . 86B.2. Interfaz de DSLEditor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

CAPITULO 1

INTRODUCCION

Antes de exponer los periodos historicos en que podemos dividir la evolucion dela robotica, resulta curioso saber como, cuando y donde aparecio el termino robot.

1.1. Definicion y origen de robot

¿Como podemos definir lo que es un robot? Un robot es, a fin de cuentas, unamaquina (o programa) compuesto por una serie de sensores que le permiten recibirinformacion del entorno, un conjunto de actuadores con los que puede modificar omanipular el entorno y una funcion que define su comportamiento. Por esta razon,un robot casa perfectamente con el concepto de agencia [3] (ver Figura 1.1).

Figura 1.1: Concepto de agencia/Sistema multiagente

1

2 Capıtulo 1. INTRODUCCION

El termino ((robot)), surgio de la traduccion de la palabra checa ((robota)) (que sig-nifica ”trabajo duro o forzado”, generalmente el que se refiere al que realizaban lossiervos). Se acuno durante el primer quinto del siglo XX, gracias a la obra teatral deciencia ficcion R.U.R.”(Robot Universales Rossum) de Karel Capek [1890]; si bien,Capek aclaro que dicho termino fue sugerido por su hermano Josef. Dicho terminovendrıa a sustituir a la ya empleada hasta entonces ((automat)) [1].

Posteriormente, sobre mitad de siglo, Isaac Asimov introdujo el termino ((roboti-ca)) en sus escritos de ciencia ficcion, definiendose finalmente como la ciencia encar-gada del estudio y desarrollo de los robots, cuyas bases se asientan sobre la mecani-ca, la electronica, la fısica y las matematicas. Tambien creo las famosas tres leyes dela robotica:

Un robot debe obedecer siempre al ser humano.

Un robot no puede danar a los humanos, incluso cuando esta ley entre enconflicto con la primera.

Un robot debe hacer todo lo posible por no resultar danado, siempre y cuandoesta ley no entre en conflicto con las anteriores.

La finalidad de estas leyes era evitar que en caso de que los humanos acaba-sen desarrollando maquinas inteligentes, estas no acabasen revelandose contra loshumanos como sucedıa en sus propios escritos. Mas tarde la EPSRC (Engineeringand Physical Sciences Research Council) y la AHRC (Arts and Humanities ResearchCouncil) tomo esas leyes y anadio ademas una serie de normas eticas y moralesque aclaraban mejor lo que un buen desarrollador robotico debıa seguir para lograrmaquinas que realmente fuesen de ayuda para todos.

Pese a que el termino de robot y robotica sean practicamente recientes y nos pue-da parecer una ciencia relativamente contemporanea, la existencia y construccion derobots como maquinas capaces de trabajar por sı mismas, se inicio hace mas de 2000anos. Podemos distinguir entonces en la historia tres fases de cambio y evolucion dela robotica:

Periodo antiguo: engloba los comienzos de la robotica y los automatas (proto-robots).

Periodo moderno: agrupa los inventos del siglo XX que ya usan electricidad ycircuitos electronicos.

1.2 La robotica antıgua 3

Periodo contemporaneo: data los inventos en los que se trabaja actualmenteen el siglo XXI.

1.2. La robotica antıgua

Los primeros automatas y maquinas automaticas datan del siglo IV A.C., demano de Arquitas de Tarento (430-360 a.c.), quien desarrollo una ave mecanica ac-cionada por vapor. Este fue el comienzo de lo que se suelen denominar proto-robots,segun algunos historiadores [4].

El ingeniero y matematico Heron de Alejandrıa (10-70 d.c.), uno de los mas re-conocidos inventores y piedra angular de la robotica, llego a construir una grancantidad de artilugios mecanicos, que incluso sin el uso de la electricidad ni losmicrochips y apoyandose exclusivamente en poleas, engranajes y palancas, eran ca-paces de moverse y actuar por sı solos. De entre sus numerosos ingenios, los masreconocidos (dentro del campo de la robotica) son, por ejemplo, unas puertas au-tomaticas capaces de abrirse por sı solas tras encender un fuego (Figura 1.2).

Figura 1.2: Puertas automaticas de Heron

Otra de las mas sofisticadas de la epocaa fue la precursora de las actuales maqui-


nas expendedoras, una maquina la cual al introducirle una moneda era capaz deproporcionar una bolita de jabon y activar una fuente de agua para que el usuariopudiese lavarse las manos, apagandose sola tras un cierto rato.

Existen multitud de inventos similares creados por Heron y otros inventores pos-teriores, que van desde teatros de marionetas automatizadas y reprogramables (eraposible modificarlas cambiando ciertos engranajes o reduciendo la longitud de lascuerdas usadas) hasta relojes activados por agua que tocaban melodıas diferentessegun la fecha y hora.

Leonardo Da Vinci (1452-1519 d.c.) tambien llego a construir multitud de maqui-nas articuladas autopropulsadas con la capacidad de ser reprogramables. Los inven-tos mas conocidos son su leon mecanico y su androide articulado (ver Figura 1.3),entre otros.

Figura 1.3: Leon (izquierda) y androide (derecha) de Da Vinci.

El leon era capaz de moverse por sı solo al darle cuerda, como si de un relojse tratase. Tras hacer los movimientos que tenıa programados, finalmente abrıa supecho mostrando un ramo de flores. El comportamiento podıa ser alterado modifi-cando los engranajes para que actuasen a diferentes tiempos.

El androide, por otra parte, era un automata capaz de simular ciertos movimien-tos humanos. Poseıa las mismas articulaciones que un humano, a diferencia de queinternamente era movido por poleas y cuerdas. En la representacion que se ha he-cho posteriormente, tras perderse buena parte de los documentos de Da Vinci, secomprobo que el androide era totalmente funcional y capaz de realizar movimien-tos como sentarse o saludar sin problema. Una clara demostracion de hasta donde

1.3 La robotica moderna 5

llego la investigacion de Leonardo en el campo de la mecanica y la anatomıa y queactualmente sirve de base para los robots humanoides actuales.

En China, otro inventor muy conocido fue Hisashige Tanaka (1799-1881 d.c.),quien usando tambien sistemas autopropulsados al darles cuerda, diseno juguetescapaces de servir y repartir bebidas en la mesa.

1.3. La robotica moderna

En este periodo podemos clasificar aquellos inventos y desarrollos roboticos queya comenzaron a utilizar la electricidad y la microelectronica. A diferencia de losproto-robots, estos comienzan a destacar por su movilidad y su generalizacion (estosignifica su capacidad para adaptarse a diferentes entornos). Actualmente, un robotsolo se considera como tal si cumple esas dos caracterısticas, lo que nos permite dis-tinguirlos de los denominados automatas.

Se pueden distinguir, por regla general, 3 tipos:

Robots industriales: comenzaron a desarrollarse a partir de 1938, cuando laempresa DeVilbiss invento una maquina capaz de pintar con spray. Posterior-mente en 1951 se creo el primer brazo robotico. Son robots cuya movilidadesta limitada al entorno en el que se instalen y por lo general funcionan de for-ma repetitiva y exclusivamente para la tarea o tareas para las que se programe.

Vehıculos autonomos: son el tipo de robot que nos trae a este trabajo. Se ca-racterizan por ser capaces de desplazarse libremente por el entorno, ya seacerrado o abierto. Su funcion se limita al planeo de rutas, navegacion y tras-lacion de objetos y cargas. Se pueden subdividir a su vez en diferentes tipos:terrestres, aereos y marıtimos, aunque si bien lo unico que los diferencia es elmedio y el sistema de propulsion utilizado.

Robots caminantes: son, de lejos, el tipo de robot mas general que existe ac-tualmente y una variacion mas compleja de los autonomos. Ademas de tenerla capacidad de moverse libremente por el entorno, se pueden adaptar a dife-rentes casos y problemas. En esta clase de robots entran los bıpedos (como losde aspecto humanoide) y los de multiples articulaciones o artropodos (que separecen mas a los animales e insectos). Fue en 1986 cuando Honda comenzo a


investigar con esta clase de robots (principalmente bıpedos), publicando sufamoso P3 (ver Figura 1.4) en 1997. Posteriormente este robot fue redisenadoy denominado como ASIMO, convirtiendose en la vanguardia de los robotsbıpedos.

Figura 1.4: Robot bıpedo P3 de Honda.

1.4. La robotica actual

Esta etapa supone la fase mas actual en la que se encuentra la robotica. Com-prende todos los descubrimientos y avances desde que se mejoro la tecnologıa deintegracion y las conexiones de alta velocidad (siglo XXI), muy importantes paraexpandir tanto la capacidad de computo como las areas donde se pueden aplicarrobots.

Actualmente la robotica ha invadido practicamente todos los sectores de la eco-nomıa, desde la agricultura hasta el sector servicios o defensa. En el sector industrial,debido al surgimiento de la crisis y a que la inmensa mayorıa del sector ya se en-cuentra completamente robotizado, la creacion de robots en este se ha estabilizado,abriendo paso a investigaciones mucho mas ambiciosas que hace 20 anos, cuando latecnologıa no era capaz de cumplir con las espectativas necesarias.

Uno de los casos mas recientes y que mas impacto tuvo fue el robot Stanley, de launiversidad de Stanford, como participacion en la competicion ”Darpa Grand Cha-llenge”de 2005, un desafıo en el desierto de Mojave (EEUU) en el que unos vehıculos

1.4 La robotica actual 7

autonomos debıan realizar una carrera con la simple informacion del punto destinomarcado por GPS. Stanley fue el primer vehıculo autonomo capaz de superar el reto.

Figura 1.5: Robot Stanley de la universidad de Stanford.

Actualmente este robot se puede visitar en el museo Smithsonian de EstadosUnidos.

El reto ha ido evolucionando desde entonces, siendo en 2007 una prueba urbanay actualmente (2013) una prueba centrada en vehıculos con una alta capacidad deadaptacion en combate. No serıa de extranar que en futuras ediciones el programase centre en los vehıculos aereos, con los cuales se lleva trabajando desde hace bienpoco pero que gracias a los nuevos y mas sofisticados sensores y los circuitos inte-grados cada vez mas pequenos y potentes, se hace mas posible y viable construirpequenos dispositivos voladores, cuya utilidad va mas alla de la vigilancia, el res-cate y el traslado de mercancıa por el aire.

Por supuesto se siguen trabajando en los robots humanoides, cada vez mas pa-recidos a humanos y algunos incluso capaces de expresar emociones, hablar y mo-verse cada vez mas rapido, ahora accesibles a cualquier usuario. Por regla general,Japon es la actual pionera en este apartado, si bien muchas empresas como Inteltambien estan trabajando en este ambito.

Como lado negativo en ambitos de la robotica util para el ser humano se cono-ce de sobra la existencia de las llamadas ((armas anonimas)), haciendo referencia eltermino a aquellos robots (usados principalmente por los los departamentos de de-fensa de los principales ejercitos) cuya finalidad es detectar y tratar con las posiblesamenazas en las fronteras de los paıses mas conflictivos sin intervencion humana.Ejemplos de zonas donde se estan utilizando actualmente son la frontera de Israel,con su robot Guardium, o Corea del Sur, con el Samsung SGR-1 (ver Figura 1.6).Actualmente la ONU esta debatiendo sobre el uso legal o no de este tipo de robots


[14].

Figura 1.6: Guardium (izquierda) y SGR-1 (derecha).

1.5. Expectativas de futuro

De cara al futuro podemos encontrar que los principales investigadores siguentrabajando en lograr obtener vehıculos autonomos de uso publico. Google, por ejem-plo, esta desarrollando su propio coche civil basado en la tecnologıa de Stanley.Actualmente es capaz de desplazarse por las ciudades y principales carreteras deEstados Unidos y se estima que de aquı a unos pocos anos, los principales fabrican-tes saquen a la venta sus coches autonomos.

Figura 1.7: Enjambre de robots de la universidad de Pensilvania.

Otras investigaciones que podemos encontrar, en aprovechamiento de la compu-tacion en la nube, se basan en el conocido como ”pensamiento enjambre”, la capa-cidad de hacer que muchos robots sean capaces de trabajar de forma cooperativapara lograr fines comunes. Este trabajo se esta llevando a cabo en la universidad dePensilvania. Usando pequenos drones cuatrirotor son capaces de comunicarse en-tre ellos, volar en formacion sin chocarse y recoger y trasladar objetos (ver Figura1.7). Esto abrira un sin fin de puertas a la nanotecnologıa, y una muestra es lo que

1.5 Expectativas de futuro 9

se esta logrando poco a poco con drones cada vez mas pequenos. Podemos acabardiciendo que en 10 anos seguramente encontremos robots en nuestras casas que nosolo limpien el suelo, sino tambien nos faciliten la vida en muchos aspectos que hoydia, podrıamos pensar que se trata de ciencia ficcion, al igual que pensaban nuestrosantepasados hace mas de 50 anos.

CAPITULO 2

LA ROBOTICA AUTONOMA

En el capıtulo anterior se comento brevemente los diferentes y mas importantestipos de robots que podemos encontrarnos actualmente. A dıa de hoy podrıamosincluso subdividir aun mas esos tipos, aunque ese tema se escapa de los lımites y lafinalidad de este trabajo.

2.1. Los vehıculos autonomos

Uno de los tipos de robot que actualmente estan ganando fuerza desde hace po-cos anos son los comentados robots autonomos, o vehıculos autonomos para sermas precisos (se usaran ambas formas indistinguiblemente). El mismo tipo de robotcon el que se ha trabajado para la realizacion de este documento.

Los vehıculos autonomos terrestres, que son los que nos interesan, se caracteri-zan por lo siguiente:

Suelen disponer de dos o mas ruedas.

Tienen la capacidad de desplazarse en 2D.

Usan ultrasonidos, laseres y otros sensores (como el GPS) para reconocer elentorno y localizarse.

Pueden servir para interiores o exteriores.

11

12 Capıtulo 2. LA ROBOTICA AUTONOMA

Se utilizan para multitud de tareas que implican ir desde el punto A al B (de-pende del tipo de entorno).

Figura 2.1: Ejemplo de vehıculo autonomo

Los vehıculos aereos, mas complejos de trabajar, son similares y se fundamentanen las mismas bases, salvo que en lugar de moverse en un espacio 2D, ademas serıancapaces de hacerlo en el tercer eje de altura. Tampoco pueden utilizar los mismos al-goritmos, ya que estos estan pensados para trabajar en mundos 2D. Sin embargo,si pueden adaptarse los conocimientos de los vehıculos terrestres a vehıculos aeros,siempre y cuando podamos paliar con la problematica del coste computacional y deespacio anadidos.

2.2. Tipos de entornos

Se ha comentado que la meta de un vehıculo autonomo puede variar segun elentorno en el que se mueva. Existen dos tipos de entornos principales:

Entornos controlados: en los entornos controlados el robot posee de antemanoun mapa (una representacion grafica del entorno, generalmente en 2D). Son labase para los robots con autolocalizacion, planificacion de rutas y navegacion.Si un robot no posee un mapa sobre el que poder situarse (localizarse), jamassabra que pasos debe realizar para llegar a su objetivo. La desventaja que po-see este tipo de robots es la baja capacidad de adaptacion si colocamos al roboten una zona desconocida. Se utilizan principalmente para vigilancia, guiar tu-ristas en museos y en general cualquier tipo de desplazamiento que impliquellegar del punto A al punto B.

Entornos no controlados: se denominan ası a aquellos entornos en los que nose sabe a ciencia cierta que obstaculos, peligros o bifurcaciones contiene. Es-te tipo de entornos hace mas compleja la implementacion eficaz de un robotautonomo, aunque si bien, dan como resultado robots con una alta capacidad

2.3 Problematica de los vehıculos autonomos 13

de adaptacion. Un robot colocado en este tipo de entornos suele implementarcasi la totalidad de las veces un sistema SLAM1. Este tipo de robots se utilizansobre todo para escanear zonas desconocidas y peligrosas para el ser humano.

Aparte, como cabrıa imaginarse, estos pueden ser a su vez interiores o exteriores,aunque esto ultimo ya depende principalmente de la capacidad de movimiento delrobot, pues no sera igual para un robot orientado a interiores (que usara ruedas degoma o plastico) que para exteriores (que usara neumaticos con dibujo para evitardeslizamientos).

2.3. Problematica de los vehıculos autonomos

Se han expuesto las caracterısticas superficiales que definen a los vehıculos roboti-cos autonomos y que nos permiten distinguirlos de otros tipos de robots. Tambiense ha hablado sobre los diferentes tipos de entornos a los que estos robots debenenfrentarse. Ahora bien, ¿que debemos hacer para poder disenar un robot de estascaracterısticas y hacer que funcione correctamente en el mundo real?

Antes de proceder al diseno y construccion de un vehıculo autonomo, es necesa-rio hacer un repaso de los grandes problemas a los que debemos hacer frente parapoder lograr nuestro objetivo. Si bien, podrıamos aventurarnos directamente usan-do un sistema de ensayo-error, pero evidentemente, esto supone mas costes de losque en la vida real podemos permitirnos. Para ello, nunca esta de mas tener algo deconocimiento extra sobre las herramientas matematicas que podemos utilizar antesde proceder a escribir codigo alguno.

La clave a la hora de resolver el problema de los vehıculos roboticos consiste enresponder (o mejor dicho, hacer que el robot sea capaz de responder) tres sencillaspreguntas: ¿donde estoy?, ¿como puedo llegar? y ¿que tengo que hacer? Preguntaspropuestas por Sebastian Thrun [15].

1SLAM, o Localizacion y Mapeo Simultaneos, es el algoritmo que permite a un robot dibujar unmapa (en 2D o 3D) del entorno al mismo tiempo que se desplaza. Es la tecnica mas compleja queactualmente se esta desarrollando.


2.3.1. ¿Donde estoy?

Es la pregunta inicial que un robot debe hacerse. Los humanos somos capacesde orientarnos en el mundo en el que vivimos, pero una maquina no dispone deesta capacidad de serie. Si no tiene referencias de donde esta en un momento dado,¿como podrıamos pedirle que alcanzase un lugar diferente?

Para responder a la pregunta de donde esta el robot, nos puede parecer bastanteutil instalarle un localizador GPS2, igual que harıamos nosotros en nuestro cochepara saber por donde vamos. Si bien esta solucion es valida, tiene un pequeno pro-blema: la precision. En esta clase de dispositivos, la precision usando satelites es deentre 2-10 metros, algo que no nos podemos permitir en, por ejemplo, una autopis-ta de tres carriles a 120km/h. La posibilidad de tener un accidente es demasiadoalta, podrıa salirse el coche de la calzada, invadir la mediana o incluso impactarotros vehıculos. Para poder fiarnos de un sistema de localizacion en esta clase deentornos donde prima la precision, debemos reducir el error a como mucho 10cm(dependera del caso que tratemos el permitir mayor o menor precision).

Para localizar un robot, existen diferentes metodos y tecnicas que utilizan comobase las mediciones obtenidas por los sensores (sobre todo mediciones laser y deultrasonidos, mucho mas precisas que el GPS) y representan de forma probabilısticala creencia de donde se encuentra un robot tras sucesivos movimientos y deteccio-nes. Todas ellas requieren ademas que el robot posea conocimiento previo sobre elentorno en el que va a moverse (un mapa). A continuacion se explicara ”a grossomodo” el funcionamiento del que posiblemente sea el algoritmo mas utilizado: losFiltros de Partıculas.

Los filtros de partıculas son, de lejos, la opcion mas utilizada y recomendada porlos expertos en la materia sobre localizacion global. Su idea es muy simple y efectivay tiene la ventaja anadida de que ademas es muy facil de implementar, siempre ycuando se tengan claros ciertos conceptos con los que cuenta. Veamos con un senci-llo ejemplo como funciona el algoritmo.

2GPS o Sistema de Posicionamiento Global es el sistema que permite geolocalizar una posicionhaciendo uso de satelites. La precision es variable en funcion de la posicion y la cantidad de satelitesdisponibles.


Ejemplo

Supongamos que disponemos de un robot equipado con un sensor laser situadoen algun lugar de un entorno controlado del cual se conoce su mapa.

Durante una primera etapa de inicializacion, el algoritmo genera una cantidadN de partıculas que distribuye aleatoria y uniformemente por el plano del entorno.Estas partıculas son vectores de tres componentes (coordenada X , coordenada Y ydireccion θ) los cuales representarıan una posible situacion del robot en el entorno.La cantidad de partıculas a generar depende del desarrollador, aunque se debe teneren cuenta que a mayor cantidad mejores resultados (mayor precision y localizacionen menos tiempo) pero tambien mayor coste computacional.

El robot realiza a continuacion una primera etapa de medicion, detectando cua-tro puntos del espacio los cuales marcara y usara para iniciar el proceso de locali-zacion. La cantidad de landmarks (o marcadores) que se pueden utilizar dependeexclusivamente del desarrollador. Cuantos mas se utilicen, mejores seran las refe-rencias que se tendran del lugar y por tanto el robot podra auto-localizarse muchoantes.

Figura 2.2: Primera etapa de medicion del robot de 4 posiciones fijas del entorno(landmarks).

Cada landmark o marcador vendra caracterizado por una distancia desde el sen-sor al punto del obstaculo ası como un angulo respecto a la direccion del robot (indi-


cada en la Figura 2.2 como una lınea negra). Como es de esperar, el sensor disponede un pequeno error de medicion, por lo que es habitual incluir el error del aparatousando una funcion gaussiana definida por su media y varianza (µ, σ2) para definirla posicion de cada marcador (se escoge un valor aleatorio proporcionado por dichafuncion).

Figura 2.3: Etapa de remuestreo de las partıculas.

En la siguiente etapa, conocida como remuestreo, a cada una de las partıculas seles asigna un valor o peso en funcion de la precision de los marcadores respecto alos marcadores que habrıa medido cada partıcula. En la figura 2.3 se puede observaruna posible partıcula (en morado) a la cual se le han incluido las medidas captadasdel robot. Se comprueba si para esa partıcula en concreto, los posibles marcadorescoinciden con puntos de obstaculos en el entorno. Si coinciden, entonces el peso quese le asignarıa serıa alto, mientras que si se comete cierto error el peso se reducirıa.En la Figura 2.3 puede observarse (en negro) para una partıcula dada, la posicion ala que deberıan encontrarse los marcadores medidos solo coinciden para L2 y L3,mientras que para L1 y L4 se comete cierto error, pues hay obstaculos mucho antesde donde se esperaban. Esto resultara en esa partıcula en concreto un menor pesoque otra que este situada exactamente en la posicion real del robot (en verde).

Tras el calculo de los pesos, es necesario normalizar los resultados de cada partıcu-la aplicando la siguiente expresion:

αi = wi/W (2.1)


donde W =∑wi y αi el peso de la partıcula i normalizado. Estos resultados se

usaran como probabilidades para la siguiente etapa.

En la etapa de seleccion, teniendo las recien calculadas probabilidades, debemoshacer que N partıculas sean escogidas de nuevo. Por lo general, se suele utilizar unmetodo parecido al de una ruleta de la fortuna, dando la posibilidad de que unamisma partıcula sea escogida varias veces o ninguna. Como se puede imaginar, amayor probabilidad mayores oportunidades hay de que sea escogida cierta partıcu-la varias veces.

La idea es que al final, con las sucesivas iteraciones, solo mantengamos con vi-da aquellas partıculas que mas se asemejan al robot real (en cuanto a su posicion ydireccion en el espacio); en esencia, algo muy parecido a como funcionan los algo-ritmos geneticos.

Por ultimo, se procede a realizar la etapa de movimiento del robot o etapa de esti-macion, la cual tambien se traduce en una modificacion de las coordenadas de cadapartıcula para simular el movimiento realizado. Como sucedıa con las mediciones,se suele incluir el error del movimiento usando tambien funciones gaussianas a lahora de determinar las nuevas coordenadas.

¿Que funciones gaussianas se deben escoger? No existe una respuesta concretapara cada tipo de problema. La funcion que determina el ruido y/o error anadido alrealizar mediciones o desplazamientos la debe definir el propio desarrollador. Porejemplo, en el caso de que conozcamos de forma casi exacta que con un tipo derueda, el robot nunca resbala en cierto tipo de suelo, para ese caso podemos usarfunciones gaussianas donde la varianza sera muy pequena. En otros casos puedeque interese una varianza mayor. En cualquier caso la media usada en esta funcionserıa la estimacion exacta de donde estarıa nuestra medida, generandose a conti-nuacion un valor aleatorio con dicha funcion gaussiana para ”simular”3 los efectosde enfrentarnos al mundo real.

2.3.2. ¿Como puedo llegar?

Tras saber el robot donde se encuentra, el siguiente paso es ser capaz de llegar alobjetivo propuesto, sea por la razon que sea. Planificar rutas y ser capaz de seguirlas

3Se ha comprobado que muchos algoritmos y conceptos matematicos manejan muy bien los pe-quenos errores, dando resultados realistas, como el caso de las redes neuronales.


es el dıa a dıa de cualquier tipo de vehıculo. Planificar una ruta consiste en encontrary escoger el camino de menor coste posible de entre todos los posibles caminos, loque en algorıtmica se suele conocer como encontrar el camino optimo. Se trata portanto de un problema de busqueda en un espacio de soluciones.

Existen multitud de algoritmos que permiten encontrar soluciones optimas, estanlos voraces o de busqueda no informada, capaces de dar una solucion a menudorapidamente pero que en ciertas ocasiones dista bastante de la solucion optima oesperada y que no suele ser posible su aplicacion en problemas NP-duros4. Lue-go estarıan los algoritmos de busqueda informada, caracterizada por mejorar a losanteriores al anadir conocimiento sobre costos al problema, lo que permite guiary reducir en gran medida el espacio de busqueda. Si vamos aun mas lejos, encon-trarıamos tambien la programacion dinamica (solo aplicable en problemas que pue-dan dividirse en subproblemas) o los algoritmos geneticos, especialmente disenadospara optimizar pero que para problemas tan simples como el calculo de rutas resul-tan demasiado complejos en tiempo y en espacio como para utilizarlos.

El algoritmo por antonomasia que suele utilizarse en la mayorıa de robots es,sin lugar a dudas, el algoritmo A∗ (A Estrella), para busquedas informadas. Carac-terizado por ser muy facil de implementar, disponer una buena base matematica yofrecer un comportamiento excelente en comparacion a sus semejantes no informa-dos. El algoritmo A∗ basa su funcionamiento en el algoritmo ”Busqueda de primeroel mejor” (Best-First Search), un tipo de busqueda de tipo arbol en el que un nodose explora si es mejor candidato que el resto de nodos disponibles para explorar(un candidato en nuestro caso serıa una posicion XY en el plano) pero que ademasintroduce el concepto de funcion heurıstica, generalmente una funcion que retornaun valor numerico con el coste estimado de llegar al objetivo desde el nodo actual.La idea es que se exploren solo aquellos nodos que, guiados por nuestra heurıstica,sean mas propensos a llevarnos directamente al objetivo.

La heurıstica escogida solo debe cumplir la condicion de admisibilidad para ase-gurar que A∗ puede encontrar la solucion optima, si existe. Dicha condicion dice losiguiente:

h(ni) ≤ g(nt) (2.2)

donde h(ni) es el coste estimado de ir desde un nodo ni hasta el nodo objetivo nt

y siendo g(nt) el coste real hasta dicho nodo. Ademas, si h(ni) = 0, estarıamos ante

4Un problema NP-Completo, o simplemente NP-duro, es un tipo concreto de problema decaracter matematico cuya solucion es inviable usando tecnicas voraces, como es el caso de problea-mas de combinatoria. Su solucion pasa por usar tecnicas especıficas para el problema concreto.


el caso del algoritmo ”Primero el mejor”, pues solo considerarıa el coste del caminoactual sin evaluar el posible coste de explorar un nodo ni.

La funcion heurıstica que se suele utilizar en problemas de rutas optimas sinsuponer un coste computacional anadido demasiado grande es la distancia euclıdeaentre el nodo estudiado y el nodo objetivo, y vendrıa dada por la expresion:

h(n) =√

(xn − xt)2 + (yn − yt)2 (2.3)

donde xn e yn hacen referencia a las coordenadas en el plano del nodo n, y xt e yt lascoordenadas del punto destino.

Tambien se podrıa utilizar la distancia Manhattan o cualquier otra expresion maso menos compleja, pero siempre debemos asegurarnos de que sea admisible y no so-breestimar el coste real.

A continuacion, se expondra con un sencillo ejemplo su funcionamiento.

Ejemplo

Partimos del siguiente problema, codificado en forma de una matriz de 8x8 cel-das que representa el mapa del entorno donde se mueve nuestro robot, ya localizado(figura 2.4).

Figura 2.4: Mapa del entorno, con el punto de partida (azul) y el destino (rojo).

El robot viene representado por el icono situado en la esquina superior izquier-da, de coordenadas (0, 0). La meta donde debe desplazarse viene dada por el cuadrorojo en la esquina inferior derecha, de coordenadas (7, 7). Los cuadros azules repre-sentan los nodos ya explorados, mientras que los blancos serıan aquellos aun desco-nocidos. Los negros son obstaculos que el robot debe evitar. El robot solo podra mo-


verse a cualquiera de los 8 cuadros adyacentes (diagonal, horizontal o vertical) y elcoste de realizar un movimiento sera de 1. La funcion heurıstica que se usara sera lacomentada anteriormente, la distancia euclıdea. El plan a seguir es el siguiente:

1. En primer lugar partimos de una lista de nodos inicial, denominada Abiertosque solo contendra (por el momento) al nodo inicial donde se encuentra el robot.Tambien se creara una lista (vacıa) denominada V isitados que almacenara los no-dos ya explorados.

Ademas, lo ideal serıa mantener una tercera lista indexada, que permita enlazarlos nodos visitados unos con otros, de forma que cuando finalice el algoritmo seacapaz de devolver la ruta optima en forma de una secuencia de puntos a seguir.

2. Seleccionamos el nodo con menor coste de la lista Abiertos, para lo cual apli-camos la funcion de coste:

f(ni) = g(ni) + h(ni) (2.4)

donde f(ni) es el coste dado por la suma del coste actual del camino g(ni) (lo quellevamos recorrido hasta dicho nodo ni) mas el coste estimado hasta el destino dadapor la heurıstica h(n).

Como solo hay un nodo cuyo coste es f([0, 0]) = h([0, 0]) = 9,8995 (pues g(n)

es 0), borramos de la lista Abiertos dicho nodo y lo movemos a V isitados. Tambienanadirıamos el nodo a la lista indexada, indicando que al nodo [0, 0] se llega desde”Origen”, de esta forma marcarıamos que dicho nodo es el punto inicial de partida).Acto seguido agregamos a la lista Abiertos los nodos correspondientes a las celdasadyacentes pertenecientes a la 8− vecindad de la celda (0, 0).

Notese que al finalizar la exploracion del nodo ni, el siguiente nodo ni + 1 a ex-plorar tendra su g(n) = 1, pues en este caso el coste de avanzar un paso ha sido 1. Sideseasemos penalizar ciertas acciones, como atravesar ciertos terrenos, bastarıa conactualizar g(n) para cada nodo segun se vayan explorando los afectados.

La listas quedarıan ası:

Abiertos = {[0, 1], [1, 0], [1, 1]} (2.5)

V isitados = {[0, 0]} (2.6)

Ruta = {([0, 0], ”Origen”)} (2.7)

y graficamente el estado actual de la busqueda serıa como el mostrado en la Figura


2.5.

Figura 2.5: Primera iteracion de la busqueda.

3. En la siguiente iteracion tenemos disponibles tres nodos, a los cuales les apli-camos la correspondiente funcion de coste y seleccionamos al menor de todos ellos(recordemos que buscamos minimizar el coste de la ruta). Los valores de los costespara cada nodo serıan los siguientes:

f([0, 1]) = 1 + 9,2195 = 10,2195 (2.8)

f([1, 0]) = 1 + 9,2195 = 10,2195 (2.9)

f([1, 1]) = 1 + 8,4852 = 9,4852 (2.10)

El nodo que supone el menor coste serıa el [1, 1], por lo que en la segunda itera-cion del algoritmo el nodo que explorarıamos y anadirıamos a V isitados serıa ese, eindicarıamos en la lista indexada que al nodo [1, 1] se llega desde [0, 0], justo el nodoanterior que lo abrio.

Iterativamente se repite el proceso mientras no este el nodo objetivo (en este caso[7, 7]) en la lista V isitados.

4. Al finalizar, recorriendo la lista indexada desde la entrada final ([xt−1, yt−1], [7, 7])

hasta llegar a ([0, 0], Origen) se va reconstruyendo la ruta optima resultante de labusqueda realizada.

El resultado final podrıa ser algo como lo mostrado en la Figura 2.6 (a la izquier-da nodos V isitados en azul y Abiertos en verde; a la derecha ruta optima devuelta).

A menudo se suele suavizar el camino resultante y anadir un margen de espacia-do entre dos obstaculos para evitar colisiones y giros bruscos. Anadir el espaciadose puede realizar durante el calculo de la ruta, simplemente anadiendo la condicion


Figura 2.6: Resultado A∗ (izquierda) y ruta devuelta (derecha).

de que un nodo tiene un mayor coste si esta a una distancia muy cercana de unobstaculo. El suavizado de la ruta debe realizarse en una segunda etapa y aplicandola siguiente ecuacion de gradiente descendente:

n′i = ni (2.11a)

n′i = n′i + α ∗ (ni − n′i) + β ∗ (n′i + 1 + n′i − 1 + 2n′i) (2.11b)

donde ni es un nodo perteneciente a la ruta optima calculada previamente, n′i elmismo nodo pero perteneciente a la ruta suavizada; α es la influencia que queremosdarle al camino original y β la influencia que queremos que tenga el camino sua-vizado en el resultado. Esta ecuacion debe aplicarse a las componentes X e Y delnodo en cuestion. El algoritmo no se aplica a los nodos inicial ni final, pues son losunicos que realmente nos sirven como referencia para guiar al robot.

El resultado final sera una ruta similar a la original si el peso que le damos aalpha es mayor que el dado a beta, o mas directo al objetivo si es al reves. En cuantoa que valores asignar a α y β, se recomienda dar valores no muy grandes (inferioresa 1,0) ni nulos. Encontrar el equilibrio entre ambas constantes ya depende del desa-rrollador y el problema al que se enfrente (por ejemplo, podemos coger valores dea = 0,1 y b = 0,5).

2.3.3. ¿Que tengo que hacer?

A continuacion de la pregunta anterior, y una vez definida la ruta hasta el obje-tivo marcado, lo siguiente que debe ser capaz de resolver el robot es que accionesdebe realizar en cada momento para poder seguir la ruta, es decir, cuando debe girar,


cuantos grados, a que velocidad, etc. Para ello se utiliza una funcion de control de-nominada PIDController (Controlador Proporcional-Integral-Derivativo), un me-canismo matematico retroalimentado que permite que el robot se ajuste al plan deruta evitando zigzagueos y movimientos bruscos durante los desplazamientos, dan-do como resultado un control mas natural y similar al que realizarıamos nosotros ennuestro vehıculo. Analicemos en profundidad el significado de PID.

Controlador-P/Proporcional

El control proporcional es el encargado de adaptar el eje de giro del robot paraque este se acerque mas y mas a la ruta a seguir. Supongamos el siguiente ejemplo.

Tenemos un robot de 4 ruedas con forma de coche. Solo las ruedas delanteraspueden girar hasta un angulo maximo y de izquierda a derecha, tal y como se mues-tra en la Figura 2.7.

Figura 2.7: Coche robot, ruedas (azul) y ruta (rojo).

En rojo se muestra la ruta optima que fue calculada por A* previamente y poste-riormente dibujada sobre el plano. Como se puede apreciar, el robot dista una dis-tancia D de la ruta, llamada CTE o CrossTrackError (traducido como error trans-versal). Si tenemos que escoger un metodo que nos permita adaptar el eje de girode las ruedas, la mejor manera serıa adaptar dicho angulo de giro segun el valor delCTE, es decir, que a mayor valor nos interesara que las ruedas giren mas y hacıa lapropia ruta.

La funcion matematica que nos permite calcular el angulo de giro α en funciondel CTE sera la siguiente:

α = −τ ∗ CTE (2.12)


donde τ es una constante que nos permite adaptar el angulo en mayor o menor me-dida. Para actualizar la direccion del robot bastarıa con sumar a θ el valor α reciencalculado.

El principal problema que tiene usar el Controlador-P de forma independiente esque el robot tendera a sobrepasar una y otra vez la ruta (ver Figura 2.8), debido a ladistancia existente entre el eje trasero y delantero del mismo, teniendo que reajustar-se a la ruta continuamente (oscilara) cada vez que la alcance, independientementede como de pequeno configuremos el factor τ .

Figura 2.8: Resultado de usar el controlador-P.

Controlador-PD/Proporcional+Derivativo

Para solucionar el problema de las oscilaciones que aparecıan con elControlador−P , a la funcion definida previamente se le debe anadir una funcion matematica quenos permita adaptar el angulo de giro del robot conforme mas se va acercando a laruta, de forma que no pretenda siempre acercarse con el mayor angulo posible (queese era el problema anterior), sino que cuanto mas cerca o menor sea el CTE, tiendaa rectificar el giro para unirse poco a poco a la ruta de una forma mas suave.

Para lograr esto, se debe anadir al Controlador − P una funcion derivada deltiempo, que reduzca el angulo de compensacion cuanto mas cerca este de la rutacorrecta:

α = −τp ∗ CTE − τd ∗d

dt∗ CTE (2.13)

o lo que es lo mismo:

α = −τp ∗ CTEt − τd ∗CTEt − CTEt−1

∆t(2.14)

Donde τp es la constante de influencia del Controlador − P y τd la constante de


influencia del Controlador −D.

El resultado que obtendremos sera como el mostrado en la Figura 2.9, donde ve-mos al robot acercarse suavemente hacia la ruta correcta sin llegar a sobrepasarla.

Figura 2.9: Resultado de usar el controlador-PD.

Controlador-PID/Proporcional+Integral+Derivativo

Pese a haber logrado que el robot sea capaz de adaptarse a la ruta a seguir deforma adecuada, en el mundo real puede suceder que las ruedas no esten alineadascompletamente, el robot resbale o un sinfın de problemas varios, haciendo que a lalarga el vehıculo se desvıe sin percatarse que el camino real no se encuentra dondedeberıa [16] (ver Figura 2.10).

Figura 2.10: Resultado de usar el controlador-PD con desviacion en la direccion.

Este problema de sesgo puede solucionarse si hacemos que el robot tenga cons-tancia de que se esta cometiendo un error en la orientacion a lo largo de un ciertoperiodo de tiempo. Para lograr esto, hay que anadir a la funcion del controlador unnuevo termino que incluya dicho error y que sea capaz de compensar esa tendencia


de desviacion que pueda tener.

La funcion final que definira el Controlador-PID vendra dada por:

α = −τp ∗ CTE − τd ∗d

dt∗ CTE − τi ∗

∑CTE (2.15)

donde τi sera la constante de influencia del termino de la integral y∑CTE el su-

matorio de todos los CTE contemplados hasta el momento.

La idea es que si por ejemplo, en cada intervalo de tiempo el CTE tiene un va-lor de 0.6 y este se mantiene constante durante varios intervalos de tiempo mas, elsumatorio tendera a aumentar el valor del CTE global, dando como resultado unacompensacion del giro mas acusada (ver Figura 2.11).

Figura 2.11: En azul el sesgo cometido. En naranja la correccion de la funcion inte-gradora.

El ultimo detalle que quedarıa por contestar serıa: ¿como seleccionamos los parame-tros τ? Estamos de nuevo ante un problema similar a como sucedıa al intentar es-coger las funciones gaussianas para introducir errores realistas en las estimacio-nes. Existen dos maneras, la primera depende del desarrollador, dando valores yajustandolos segun le interese. La segunda, mas sofisticada y que como ingenierospuede interesarnos, serıa utilizar algun algoritmo de optimizacion el cual sea capazde, dado un vector con los tres parametros, los vaya ajustando hasta lograr come-ter un error por debajo de un umbral. Se podrıa utilizar por ejemplo un algoritmogenetico o una variacion de este, si bien este aspecto se escapa ya de los lımites ypropositos de este trabajo.

CAPITULO 3

INVESTIGACION DEL HARDWARE Y SOFTWARE DEL

ROBOT

Esta seccion del documento comprende todo el grueso del trabajo de analisis einvestigacion realizado, tanto sobre el hardware de la plataforma con la que se hatrabajado como el software compatible con la misma.

Algunas caracterısticas mencionadas pueden cambiar de cara al futuro, y es po-sible que algunas otras dejen de estar disponibles, debido a que muchos aspectosson, a dıa de hoy, todavıa experimentales.

3.1. Hardware del robot

El robot con el que contamos en el laboratorio corresponde al modelo Pioneer 3-DX (a partir de ahora se referenciara como P3-DX) adquirido de la empresa MobileRobots (anteriormente conocida como ActivMedia, http://www.mobilerobots.com/) en la configuracion ”Laser Navigation”(ver Figura 3.1).

El P3-DX se caracteriza por ser uno de los robots autonomos para investigacionmas populares gracias a su versatilidad, fiabilidad y durabilidad. A diferencia deotros robots del mercado, como los kits orientados a ensenanza de tipo caja negra,el P3-DX es de codigo abierto y completamente programable. Ademas, se le puedeninstalar multitud de dispositivos y accesorios extra para tareas para las que no fuepensado desde un principio.

27

http://www.mobilerobots.com/

http://www.mobilerobots.com/

28 Capıtulo 3. INVESTIGACION DEL HARDWARE Y SOFTWARE DEL ROBOT

El robot dispone de las siguientes caracterısticas tecnicas [11]:

Especificaciones

• Dimensiones: 455x381x237mm

• Velocidad maxima: 1.2m/s

• Velocidad de giro: 300º/s

• Peso: 9kg

• Carga maxima: 17kg

• Voltage: 12V

• Autonomıa: 8-10h

• Tiempo de carga: 12h o 2.4h (cargador especial)

Fuselage

• Carcasa en aluminio de 1.6mm

• 2 Ruedas de goma de 195mm en el eje delantero.

• Rueda trasera giratoria de 62mm

Ordenador a bordo

• Cobra EBX-12 Versalogic

• Controlador diferencial de conduccion

• Tarjeta de red Ethernet con antena Wi-Fi

Software

• S.O. Debian (ARCOS)

• Pioneer SDK

Figura 3.1: Pioneer 3-DX en configuracion Laser Navigation.

3.2 Conectar con el robot 29

Accesorios y sensores

• Bumpers frontales para colisiones

• Array frontal de 8 sensores Sonar

• Laser SICK LMS-500 190º 75Hz 0-80m

• Brujula

• Camara Canon VC-C50i 3-ejes 460p Zoom optico 26x

• Giroscopio

Alimentacion

• Array de 3 baterıas 12V 2.5A

3.2. Conectar con el robot

Antes de proceder a encender el robot, se recomienda siempre seguir el siguienteprocedimiento:

Conectar el hardware adicional necesario (pantalla, raton, teclado, etc).

Enchufar el robot a la red electrica usando el adaptador.

Poner en ON el interruptor de la alimentacion.

Encender el ordenador poniendo en ON el interruptor del mismo (Figura 3.2).

Figura 3.2: Interruptor general y placa del ordenador a bordo.

Durante la ejecucion del robot, se pueden conectar y desconectar en caliente elteclado, el raton y el monitor si estos estuviesen conectados, pero nunca los senso-res, como el laser, si estos estan en uso, pues podrıa quemarse la placa base.

Una vez encendido, el robot puede ser accedido de dos formas, de forma fısica(como si se tratase de un PC normal y corriente) o como si fuese un servidor remoto.


3.2.1. Acceso Fısico

Para conectarse fısicamente al robot es necesario conectar una pantalla, un te-clado y un raton (opcional si se desea usar el entorno grafico) al panel lateral delordenador a bordo (ver Figura 3.2). Los puertos son los mismos que en cualquierordenador, usando los de tipo PS/2 para teclado (morado) y raton (verde) y el V GApara la pantalla (azul).

Opcionalmente se le puede habilitar la conexion a red ya sea conectando el tıpicocable de red RJ−45 al puerto Ethernet eth0 o bien configurando la interfaz wirelessath0 (ver la seccion de Acceso Remoto para mas informacion).

Para lograr acceder a la base del S.O., tras encender el robot y cargar el kernelaparecera (en modo consola) un aviso en pantalla donde introducir las credencialesde la cuenta de usuario del robot. Por defecto se ha establecido que el usuario y lacontrasena sean ”guest”, ıdem para acceder al modo superusuario (necesario parafunciones avanzadas).

Si se desea activar el entorno grafico, tras loguearnos introducir el comando:

[ ] $ s t a r t x

Podremos ver el escritorio de Debian y usar el raton para interactuar con las apli-caciones graficas, como el simulador o el controlador del robot.

3.2.2. Acceso Remoto

El P3-DX tambien nos permite acceder y controlar el robot de forma remota, esdecir, a distancia sin necesidad de tener que conectarse fısicamente al robot (comosucedıa en el modo local). Es algo mas complejo de configurar, pero con unos sen-cillos pasos y siguiendo el orden adecuado podremos hacer las mismas tareas queharıamos si tuviesemos al robot al lado.

En primer lugar debemos tener la certeza de que el robot es accesible median-te una conexion local, preferiblemente wifi. Este router tiene como SSID el nombrerobotica y asignara de forma exclusiva y reservada la ip 161.67.196.331. Para queel router pueda conectarse a la red de la escuela y asignar dicha ip, debemos conec-tar un cable de red del laboratorio a la interfaz eth1 del router. Para que todo salga

1Este caso de configuracion ha sido el usado para la realizacion de este trabajo y puede cambiaren el futuro, siendo necesario adaptar los datos.

3.2 Conectar con el robot 31

bien, es preferible conectar primero este cable antes de encender el propio router.

Si el robot es encendido tras ese paso, durante el arranque Debian tratara deobtener la configuracion wifi del recien conectado router y se le asignara la ip co-rrespondiente. En caso contrario, si se le asignase una ip diferente apagar el router,revisar la interfaz donde esta conectado el cable de red de la escuela y repetir el pro-ceso.

Otro problema que puede surgir a la hora de establecer la conexion es que lainterfaz wifi del robot se desactive durante el arranque (suele suceder si no se en-cuentra una conexion disponible durante la etapa de descubrimiento de la red). Parasolucionarlo, una vez estemos en logueados en el SO, debemos reconfigurar la in-terfaz ath0 del robot, para ello introducir en una consola lo siguiente:

// R e i n i c i a r l a i n t e r f a z :[ ] $ ifdown ath0[ ] $ i fup ath0

//Comprobar que l a as ignac i on surgi o e f e c t o usando :[ ] $ i f c o n f i g ath0

Si se muestra un mensaje de que ifconfig no ha sido reconocido por bash, sepueden hacer dos cosas:

O introducir la ruta absoluta del programa

[ ] $ /sbin/ i f c o n f i g ath0

O acceder como administrador y repetir la orden:

[ ] $ su − //El prompt cambiara a r o j o[ ˜ ] $ i f c o n f i g ath0

Para comprobar que cualquier cliente remoto tiene conexion al robot, se reco-mienda siempre mandar un ping y esperar su respuesta:

[ ] $ ping −c 4 1 6 1 . 6 7 . 1 9 6 . 3 3

Por supuesto, esto solo sera posible si el cliente tambien esta conectado a la redde la escuela o en su defecto al router inalambrico.


A partir de ahora se usara dicha ip en los parametros de Aria y ArNetworkingpara los accesos al hardware. En caso de realizar las ejecuciones en otras redes loca-les, adaptar las IPs y credenciales segun sea necesario.

Por ultimo, solo quedarıa conectarnos remotamente al robot. Este tipo de cone-xiones solo estan disponibles mediante consola, por lo que no servira de nada tratarde lanzar el entorno grafico. Para establecer la conexion finalmente bastarıa con eje-cutar la siguiente orden en una Terminal (si estamos en Ubuntu):

[ ] $ ssh guest@161 . 1 6 7 . 1 9 6 . 3 3

Acto seguido aparecera una sesion local desde el robot (veremos el cambio delprompt). Si queremos finalizarla, ejecutarıamos:

[ ] $ logout

Otras acciones que tambien tenemos disponibles es la subida y descarga de fi-cheros. La forma mas rapida y sencilla serıa instalar una interfaz como FileZilla enel cliente. Opcionalmente tambien podemos usar el programa scp en caso de solo te-ner que transmitir un fichero. Para este ultimo caso bastarıa con escribir lo siguienteen la consola del cliente:

$ scp <p a t h f i l e> guest@161 . 6 7 . 1 9 3 . 3 3 : < dest path>

Esa orden nos permite solamente transmitir un fichero desde el cliente al robot.Para descargarlo bastarıa con invertir los dos parametros.

Para que los archivos se suban correctamente es estrictamente necesario incluirla ruta. Notese ademas el caracter separador ”:” entre la ip del host y el path destino.

Todos estos comandos han sido debidamente preparados en shell scripts (.sh)para Ubuntu y vienen adjuntos al CD junto a este documento. De esta forma es massencillo realizar todas estas tareas sin necesidad de tener que revisar la documenta-cion.

En la seccion de ArNetworking y Aria se explicara con mas detalle como lo-grar que el robot se mueva usando los programas de ejemplo preparados para elcaso, ası como activar los sensores, establecer puntos de ruta destino o recibir image-nes de la camara.

3.3 Software de robotica necesario 33

3.3. Software de robotica necesario

MobileRobots, proporciona junto a sus productos de robotica un SDK (bajo elnombre de Pioneer SDK) propio con el que poder trabajar y manipular el hardwa-re. Esta compuesto por una amplia variedad de programas y librerias compatiblestanto con Windows como con distribuciones Linux, entre las que se encuentran:

ARIA: es el nombre con el que se conoce al Framework2 utilizado por MobileRobots. Basicamente son un conjunto de librerıas de caracter ”open source”

(software libre) programadas en C++ cuya finalidad se centra en facilitar aldesarrollador la creacion de aplicaciones que manipulen el hardware de losrobots, vease: laseres, GPS, motores, brujula, etc. Actualmente incluye ”wrap-pers”que permiten escribir codigo en Java o incluso en Python, aunque paraun desarrollo mas eficiente recomiendan usar C++, debido a su potencia y aque las librerıas estan desarrolladas en este lenguaje.

Adicionalmente, se le pueden incluir tambien las librerıas ARNL para la na-vegacion y localizacion laser, MOGS para el uso con antenas GPS y SONARNL,usado especialmente con los detectores de ultrasonidos de corto alcance queincorporan la mayorıa de robots.

MobileEyes: es el programa de acceso remoto utilizado para conectar conel robot o en su defecto con un simulador. Proporciona una sencilla interfazgrafica con la que visualizar la localizacion del robot en un mapa, enviar yprogramar ordenes e incluso mostar imagenes en directo desde las camaras,entre otras cosas.

MobileSim: es el simulador con el que se pueden realizar las pruebas de losprogramas antes de ejecutarlas en un robot real. Incluye una sencilla interfazen la que se precarga un mapa conocido (en formato .map) y en el que se colo-cara el modelo de robot deseado, igual que si se tratase del real. Estos modelosvirtuales incluyen sus correspondientes laseres, sonars, bumpers, etc., con elfin de obtener una simulacion lo mas realista posible. Tiene la capacidad deponer en funcionamiento multiples robots simultaneamente por si se desearealizar algun trabajo de sistemas multiagentes.

Mapper3: es la aplicacion utilizada para editar los escaneos laser obtenidostras una sesion de mapeado (usando los laseres de un robot). Generalmente,se hace necesario preprocesar los resultados mediante esta utilidad, ya que

2Framework (”marco de trabajo”) es una arquitectura software que permite trabajar dentro de undominio fuertemente definido con la finalidad de estandarizar los diferentes modulos y artefactosque se desarrollen.


ademas de limpiar el mapa de ruido y unir las diferentes secciones, permitetambien editarlo y anadir zonas prohibidas, zonas de carga, waypoints y otrasopciones.

ACTS/SAV: son las librerıas adicionales con las que se provee a ciertos robots,principalmente aquellos que acompanan a una camara de video. ACTS es unaaplicacion que permite realizar tareas de aprendizaje sobre las imagenes cap-turadas, y usar el robot para identificar objetos en funcion de su color y forma.Permite implementar lo que se conoce como un sistema de vision artificial.SAV, por su parte, da la capacidad de poder usar las camaras de video en cual-quier programa. Es totalmente esencial disponer de estas librerıas si se quieretrabajar con las camaras.

Por otro lado, desde el grupo SIMD del I3A de Albacete, y en colaboracion con laUniversidad de Extremadura (UNEX), disponemos y hemos hecho uso del frame-work denominado como ROBOCOMP con el objetivo de integrar el software de Mobi-leRobots dentro de este marco. Esta plataforma ”open source” incluye el editor DSL,con el cual se pueden programar modulos de caracter cliente/servidor abstrayendoa los desarrolladores de tener que paliar con los aspectos tecnicos de la transmisionde datos ası como ofrecer la posibilidad de usar un mismo modulo en diferentesrobots. Todo esto se detallara mas profundamente en las proximas secciones de estecapıtulo.

3.4. Pioneer SDK al detalle

Anteriormente se describio el contenido completo del SDK de MobileRobots. Elproceso de instalacion de las librerıas y aplicaciones viene descrito paso a paso en elApendice A para un sistema Ubuntu reciente.

Centrandonos en las librerıas que se han utilizado en la investigacion de este pro-yecto y que son necesarias para el uso total del robot en cualquiera de sus posiblescapacidaes, se detallaran las caracterısticas internas que definen a ARIA, ARNL/-SONARNL y SAV/ACTS.

3.4.1. Aria y ArNetworking

Aria [10] y ArNetworking [9] (o ARIA cuando las referenciamos simultaneamen-te) son el conjunto de librerıas base necesarias para poder ”mover” al robot. Aria

3.4 Pioneer SDK al detalle 35

contiene toda la funcionalidad de mas bajo nivel de que disponemos para acceder alhardware, por lo que a diferencia de otras, debe estar obligatoriamente instalada enel ordenador a bordo del robot, o en su defecto del sistema que corra el simuladorMobileSim. ArNetworking, por su parte, no puede funcionar si no esta instaladoAria de antemano, ya que este conjunto de librerıas solo permiten expandir las ca-pacidades de Aria a entornos de red.

Figura 3.3: Esquema distribucion de Aria y ArNetworking


El esquema de la Figura 3.3 muestra como Aria y ArNetworking se comunicanentre sı. Dicho esquema es esencial para comprender como debemos codificar nues-tros programas y como funcionan realmente Aria y ArNetworking. Como puedeobservarse, Aria es la capa software de alto nivel que se encuentra justo por encimadel hardware del robot (recuerdese que el robot puede ser sustituido por el simula-dor). Si deseasemos manipular el robot y hacer que avanzase cierta distancia haciaadelante, Aria sera el encargado de ofrecer esa orden. Ahora bien, esto implicarıaque siempre estuviesemos conectados fısicamente al mismo o que lanzasemos lasaplicaciones y algoritmos desde el propio ordenador a bordo del robot, en ocasionesalgo poco deseable si lo que pretendemos es distribuir o reducir la carga de trabajoque deba realizar la maquina. Aquı entra en juego ArNetworking, una interfaz queconecta con Aria y que ademas permite dar funcionalidades de tipo cliente/servi-dor. Dicho esto, podemos ahora instalar ArNetworking en un ordenador remoto ymanipular el hardware a distancia, sin necesidad de que el robot disponga de losprogramas y algoritmos localmente.

Veamos detalladamente que debe hacer Aria para poder establecer comunica-cion con el Hardware.

Aria

El proceso a seguir se basa en realizar unas sencillas pautas de programacioncuando creemos una nueva aplicacion. En resumen un programa debe seguir la si-guiente estructura:

Inicializar el motor3 de Aria.

Analizar los parametros de configuracion pasados.

Conectar con los dispositivos y accesorios.

Ejecutar las acciones del robot.

Finalizar el motor de Aria.

Es esencial seguir ese procedimiento, pues es la estructura base que MobileRo-bots exige en su framework para poder trabajar internamente con el robot. Veamosloen un pequeno programa real en C++ (ver Codigo 3.1).

Primero antes que nada debemos anadir la cabecera de la librerıa de Aria. Por de-fecto, en linux podemos localizar el fichero en la ruta /usr/local/Aria/include.

3No confundir con los motores de las ruedas del robot.


Codigo 3.1: aria example.cpp

# include ” Aria . h”# include <iostream>

i n t main ( i n t argc , char * * argv ){

Aria : : i n i t ( ) ; / / I n i c i a l i z a e l e n g i n e de Ar ia .ArArgumentParser parser (&argc , argv ) ;ArSimpleConnector simpleConnector (& parser ) ;ArRobot robot ;parser . loadDefaultArguments ( ) ;

robot . runAsync ( t rue ) ;

robot . lock ( ) ;/ / Gira e l r o b o t 90Aºrobot . setHeading ( 9 0 ) ;robot . unlock ( ) ;

Aria : : shutdown ( ) ; / / F i n a l i z a e l e n g i n e de Ar ia}

Lo ideal no es referenciar la cabecera .h usando el path completo, por lo que si desea-mos compilar correctamente un programa que use Aria.h, debemos incluir el direc-torio anterior al compilador para que este pueda generar el codigo objeto correcta-mente. La informacion necesaria para compilar un programa de diferentes formasesta adjunta en el Apendice A.

En el cuerpo principal del programa, veremos que lo primero que se ejecuta esla lınea Aria::init(). Con esto, el motor de Aria arranca y prepara el terreno delhardware para poder comunicarse con el programa. Si no se realiza esto antes, nadade lo que venga despues tendra efecto. Se trata por tanto de una lınea obligatoriaque siempre se debe anadir. Para finalizar el motor, Aria cerrara las comunicacionescon el hardware si se produce un error, se pierde la conexion o el desarrollador ejecu-ta el metodo Aria::shutdown() (como se muestra en la ultima lınea del Codigo3.1). De cualquiera de las maneras, Aria debe ser iniciado al principio y finalizadoal final, antes de usar cualquier otra subclase y despues de ello.


La clase ArArgumentParser permite analizar automaticamente los parametrosintroducios al programa desde las variables argc y argv. Esta clase se encuentra enpracticamente todos los programas de ejemplo, tanto disponibles en la documenta-cion original como en otros ejemplos de terceras personas. Facilita la tarea al desa-rrollador de tener que analizar manualmente los posibles parametros que puedanpasarse. El listado de parametros completo puede visualizarse ejecutando cualquierprograma que use Aria usando el parametro -help. Los parametros dependen ex-clusivamente del programa y el tipo de conexion que se realice. Para programas quese ejecuten localmente en el robot o el simulador, no es necesario pasar parametroalguno, pues la lınea parser.loadDefaultArguments() se encargara de confi-gurar el programa automaticamente, usando el robot fısico si este esta disponible oen su defecto el simulador si esta en ejecucion.

La ultima de las clases mas importantes que Aria importa al anadir su cabeceraal programa es ArRobot. Esta clase contiene multitud de metodos y atributos queproveen de toda la informacion relevante del robot como el voltaje de la baterıa, po-sicion y direccion, velocidad maxima, etc. De lejos, es posiblemente la clase que masse usara si nuestro programa desea comunicarse directamente con el robot en sı (so-bretodo si lo que buscamos es crear nuestro propio servidor remoto para manejar elrobot). Para poder usarlo, primero debemos instanciar un objeto de la clase, para ellobastarıa con usar la lınea ArRobot robot. A partir de ahora, basta con ir anadien-do a dicho objeto los diferentes dispositivos con los que cuente el robot (vease ellaser, sonar, bumpers, etc.), dispositivos que por defecto no se agregan (pues existenmultitud de variaciones de robots, cada uno con sus propios accesorios y Aria debeser capaz de trabajar con todos ellos). La forma de hacer esto consistirıa en crearobjetos de las clases correspondientes a cada tipo de accesorio, anadirlo al objetodel robot usando el metodo addRangeDevice() y por ultimo tras configurar losdispositivos que se usaran, establecer la conexion con el hardware usando la claseArConnector o ArSimpleConnector.

Por ejemplo, si deseamos anadir nuestro laser SICK como el mencionado en lasespecificaciones del hardware, deberıamos hacer algo como lo mostrado en el Codi-go 3.2.

Codigo 3.2: Conectando el laser a la clase ArRobot

. . .ArRobot robot ; / / i n s t a n c i a m o s l a c l a s e ArRobot/ / Cargamos l o s p a r a m e t r o s de c o n f i g u r a c i o n de l a c o n e x i o n


ArSimpleConnector connector (& parser ) ;ArSick l a s e r ;

/ / a c t i v a m o s e l l a s e r en un h i l o a p a r t emyLaser . runAsync ( ) ;/ / comprobamos que nos podemos c o n e c t a r a l l a s e ri f ( ! connector . connectLaser (& l a s e r ) ) {

e x i t ( 0 ) ;}/ / en l azamos e l l a s e r a l o b j e t o ArRobotrobot . addRangeDevice(& l a s e r ) ;

. . .

Este proceso habrıa que repetirlo para cada tipo de dispositivo, con la salvedadde que en lugar de usar la clase ArSick (usado para los laseres de tipo SICK) de-berıamos usar las correspondientes clases de cada dispositivo. En la Tabla 3.1, semuestra un pequeno listado de las posibles clases que podemos usar ası como eldispositivo que conectarıan.

Tabla 3.1: Algunas de las clases usadas para conectar dispositivos.

Clase DispositivoArSick Laser rangefinder

ArBumper Detector colisionesArSonar UltrasonidosArVCC4 Camara

La lista completa se puede encontrar en la documentacion de Aria, ası como otracoleccion de utiles metodos que nos permiten generalizar las conexiones con losdispositivos y dejar que sea la propia clase ArRobot la que se encarge de buscar yconectar todos los dispositivos disponibles para su uso.

Mencionar tambien el aspecto importante del metodo runAsyc(). La claseArRobot,como se comento, gestiona todos los recursos del robot (sea o no el simulador). Eshabitual, y en muchos fuentes de ejemplo se podra comprobar, que antes de pro-ceder a enviarle ordenes se ponga su ejecucion en segundo plano usando dichometodo. La cuestion a tratar aquı es que el robot bloquearıa el programa actual ala espera de finalizar las ordenes transmitidas, de forma que si le indicamos queavance hacia adelante una distancia X , hasta no finalizar su tarea nuestro programa


no proseguirıa con su ejecucion. Es por eso que se suele poner en segundo plano laejecucion del propio robot, para ası evitar que el lapso entre que se envıa la orden,se ejecuta y se responde de su finalizacion, interfiera con la ejecucion habitual de laaplicacion.

Figura 3.4: Ciclo de ejecucion de ArRobot.

En la Figura 3.4, se puede observar el proceso habitual de comunicacion que rea-liza la clase ArRobot con el robot o el simulador. Como se muestra, el programa secomunica mediante la transmision de paquetes denominados SIP (Server Informa-tion Packet), los cuales se transmiten cada 100ms (configurable desde el firmware)y que contienen informacion actualizada sobre el robot y sus accesorios [10]. El fun-cionamiento del ciclo es como se describe a continuacion.

En un ciclo, el robot transmite un paquete SIP, el cual es capturado por la claseArRobot. El programa analiza su contenido, creando un snapshot (una vista) del es-tado del robot (posicion, baterıa, mediciones de los sensores, etc.), lo cual permiteacceder a toda la informacion obtenida usando posteriormente los metodos de la


clase. En la ultima etapa del ciclo, el cliente agrega al paquete la nueva informacionde estado, que puede incluir tareas de movimiento o cualquier otra accion que elusuario desee, y se envıa de nuevo al robot, el cual lo analizara para realizar loscambios de estado solicitados, produciendose a continuacion un nuevo ciclo.

Como puede apreciarse, es estrictamente necesario tener un control adecuado delos hilos de ejecucion de nuestras aplicaciones, principalmente aquellas que transmi-tan ordenes de movimiento al robot. El robot no es capaz de identificar que ordenesdebe ejecutar y en que orden, ya que tras recibir el paquete de cambio de estado, eltratara de aplicarlas y a veces, incluso puede combinarlas. Si desemos que el robotejecute las ordenes de movimiento de forma secuencial, deberemos ser cautelososcon los hilos de nuestro programa y sincronizar en todo momento la transmision depaquetes manualmente, para evitar comportamientos extranos o indeseados.

ArNetworking

Si Aria nos permitıa manipular el hardware del robot a nivel local (en la propiamaquina), ArNetworking comprende la otra mitad de las librerıas que nos permi-ten extender su uso de forma remota, esto es, poder programar tareas para el robotdesde una maquina externa (ver Figura 3.3), muy util si deseamos que el robot semueva a distancia. Es lo que en programacion solemos denominar como interfaz.

El uso de estas librerias requiere obligatoriamente incluir en nuestro proyectolas librerıas de Aria, sino no podremos hacer uso de ellas, independientemente deque estemos programando un servidor o un cliente. Para el caso del servidor, elprograma debe ejecutarse en la maquina del robot/simulador, ya que sera esta laque ofrezca los servicios de Aria a los clientes remotos. Si estamos programando uncliente que se conecta al servidor, debemos igualmente incluir al proyecto ambas li-brerıas. La diferencia esta en que clases y metodos invoca cada programa para actuarcomo servidor o como cliente, las cuales se detallaran a continuacion con ejemplossencillos.

Como lo primero que necesitamos es un programa que provea a los posiblesclientes de ciertos servicios4, es necesario, primero, conectar con el hardware al quedaremos acceso remoto, y segundo, publicar los servicios que nos interesen que ma-nipulen dicho hardware. La forma de llevar a cabo esta tarea se realiza usando la

4Un servicio puede ser, por ejemplo, hacer que el robot se pare, de informacion de estado o avanceuna distancia X .


clase ArServerBase. Gracias a esa clase de ArNetworking, todos los aspectos deconfiguracion del servidor se realizan de forma automatica, de forma que el desa-rrollador no debe preocuparse por configurar los protocolos ni las comunicaciones,sino simplemente el puerto de escucha sobre el que se publicaran los servicios.

Acto seguido, una vez instanciada la clase y despues de haber enlazado todoel hardware al objeto de la clase ArRobot (como se mostro en la seccion anteriorde Aria), debemos lanzar el demonio del servidor que se encargara de recibir las co-municaciones y tratarlas. Esto se logra mediante la clase ArServerSimpleOpener,la cual se instancia pasandole los parametros de configuracion del servidor (dichosparametros pueden incluir el puerto de escucha de las conexiones externas). Usandoentonces el metodo ArServerSimpleOpener::open(&server), estarıa nuestrorecien creado servidor online y listo para recibir conexiones.

Por ultimo, solo faltarıa adjuntar al servidor, ya online, los servicios de que vaa disponer y pasar su ejecucion a un hilo aparte (modo asıncrono). Los serviciosse publican instanciando las clases referentes a cada servicio, las cuales reciben co-mo parametros los objetos de la clase ArServerBase y ArRobot. Para el ejemplo deestudio, se analizo el servidor de ejemplo que podemos encontrar en el directorio/usr/local/Aria/ArNetworking/examples. En esa ruta existe un fuente lla-mado serverDemo.cpp el cual muestra la forma de llevar a cabo la publicacion delos servicios y la configuracion del servidor. Podremos ver en dicho ejemplo (verCodigo 3.3) que, por ejemplo, si deseamos permitir que el robot sea manejado ma-nualmente (usando un joystick, teclado o cualquier otro medio manual) bastarıa conanadir la lınea siguiente a nuestro programa.

Codigo 3.3: serverDemo.cpp

/ / I n s t a n c i a c i o n de l o s o b j e t o s ArRobot y A r S e r v e r B a s eArRobot robot ;ArServerBase server ;. . ./ / Conectamos l o s d i s p o s t i v o s a &r o b o t. . ./ / Creamos e l o b j e t o e n c a r g a d o de c o n f i g u r a r e l s e r v i d o r/ / y l o lanzamosArServerSimpleOpener simpleOpener(& parser ) ;simpleOpener . open(& server , f i l e D i r , port ) ) ;. . ./ / Anadimos l o s s e r v i c i o s d e s e a d o s


ArServerModeRatioDrive modeRatioDrive(& server , &robot ) ;. . .

Hay una lista inmensa de servicios que se pueden proporcionar a los clientes,que van desde proveer informacion de los sensores y dar ordenes de bajo nivel hastaprogramar tareas complejas de alto nivel como indicar que vaya a una posicion dadao active el modo de patrulla, entre otros. En la Tabla 3.2 se indican algunos de losservicios mas comunes, con acciones de bajo y alto nivel. En el CD se adjunta ademasun log (serverDemo.log) completo con todas las acciones que podemos solicitaral servidor del fuente comentado, si bien hemos encontrado que esta informacionno esta disponible ni documentada de forma adecuada en la documentacion oficial(resultado de muchas pruebas).

Tabla 3.2: Algunas de las clases y servicios que se pueden publicar.

Clase Parametros FuncionArServerInfoRobot server,robot Datos estado robotArServerInfoSensor server,robot Datos telemetrıaArServerInfoDrawings server Graficos telemetrıaArServerModeStop server,robot Modo parada emergenciaArServerModeRatioDrive server,robot Mover robot manualmenteArServerModeWander server,robot Modo patrulleroArServerSimpleComUC commands,robot Envıa ordenes usando stringsArServerSimpleComGyro commands,robot,gyro Configura el giroscopioArHybridForwarderVideo server,host,puerto Permite enlazar el servidor de vıdeo

Existen muchos mas servicios. Algunos permiten que el servidor guarde y mues-tre un log de todo lo que sucede, ejecuta o envıa, util para hacer debugging. Comonota adicional, si deseamos que el servidor provea de imagenes obtenidas de lacamara, es necesario tener activo un servidor de retransmision de vıdeo. Esto se de-tallara mejor en la seccion sobre SAV.

El caso del cliente sigue una estructura similar, con la salvedad de que no es ne-cesario usar un objeto de la clase ArRobot. La clase que se usara para establecer laconexion con el servidor remoto sera ArClientBase, cuyo uso e instanciacion essimilar al de ArServerBase. La conexion en sı se usara creando un objeto de la claseArClientSimpleConnector, con el cual, usando el metodo connectClient()se abrira una conexion TCP/IP con el servidor, pudiendo a continuacion solicitaralguno de los servicios disponibles.

A continuacion, un ejemplo de como se conectarıa un cliente remoto a un servi-dor usando ArNetworking:


. . .Aria : : i n i t ( ) ;. . ./ / I n s t a n c i a m o s l a c l a s e d e l c l i e n t e r emotoArClientBase c l i e n t ;/ / Conf iguramos l a c o n e x i o n a p a r t i r de l o s p a r a m e t r o s/ / p a s a d o s a l programaArClientSimpleConnector c l i en tConnec tor (& parser ) ;. . ./ / Se e s t a b l e c e l a c o n e x i o n . S i s e p r o d u c e e r r o r s e f i n a l i z ai f ( ! c l i en tConnec tor . connec tCl ient (& c l i e n t ) ) {

. . .e x i t ( 1 ) ;

}

/ / Obtenemos e l nombre d e l r o b o t , pa ra su uso en p a n t a l l a/ / ( u t i l pa ra h a c e r l o g s )c l i e n t . setRobotName ( c l i e n t . getHost ( ) ) ;

/ / Ponemos l a c o n e x i o n d e l c l i e n t e en un h i l o s e p a r a d oc l i e n t . runAsync ( ) ;

/ / R e a l i z a m o s a q u i l a s s o l i c i t u d e s de l o s s e r v i c i o s/ / e n v i a n do p a q u e t e s ArNetPacke t. . .

/ / F i n a l i z a m o s l a c o n e x i o nc l i e n t . d isconnect ( ) ;Aria : : shutdown ( ) ;. . .

La solicitud de los servicios debe realizarse transmitiendo paquetesArNetPacket.Esta clase dispone de la estructura que se encargara de formatear los paquetes ytransmitirlos al servidor, ası como de desmenuzarlos para leer la informacion con-tenida. Veamos con un ejemplo sencillo como se crea un paquete para solicitar alrobot que avance 100 unidades:

ArClientBase myClient ;. . .


ArNetPacket packet ;packet . doubleToBuf ( 1 0 0 ) ; / / D i s t a n c i apacket . doubleToBuf ( myRotRatio ) ; / / D i r e c c i o npacket . doubleToBuf ( 5 0 ) ; / / V e l o c i d a dpacket . doubleToBuf ( 0 ) ; / / D e s p l a z a m i e n t o l a t e r a lmyClient−>requestOnce ( ” r a t i o D r i v e ” , &packet ) ;

El comando ratioDrive, la orden de mas bajo nivel que nos permite mover elrobot manualmente, toma como parametros (en formato doble precision) la distan-cia a moverse (si es negativo retrocedera), la cantidad de giro a realizar, la velocidadmaxima permitida (hasta un maximo de 100 %) y el desplazamiento lateral (no usa-do en el P3-DX). Esos parametros deben ser pasados a bytes y adjuntados al paqueteantes de enviarlo. El metodo requestOnce() es el encargado de enviar el paquetea traves de la conexion establecida al servidor y recibe como parametros la ordensolicitada (puede ser de envıo o recepcion de datos, en este ejemplo es de envıo) y elpaquete con los parametros para dicha orden. Al recibirlo el servidor, este usara lamisma clase ArNetPacket para desmenuzar la solicitud, si corresponde a un servi-cio disponible la pasara al robot para que la ejecute, en caso contrario respondera alcliente con un mensaje indicando que no se pudo encontrar el servicio solicitado.

Los paquetes de solicitud de informacion, como por ejemplo getBatteryInfo

(que solicita informacion sobre el estado de la baterıa) suelen solicitarse cada ciertotiempo, pues nos interesa tener la informacion mas actualizada sin tener nosotrosque andar haciendo solicitudes cada X tiempo. Esto se puede pre-programar usan-do el metodo del cliente request("getBatteryInfo",100), que en ese casosolicitaria al servidor que cada 100ms envıa de forma automatica los datos sobreel estado de la baterıa. Si en algun momento deseamos finalizar la recepcion deese paquete, usarıamos el metodo requestStop("getBatteryInfo"). Eviden-temente, cuando recibamos el paquete en nuestro cliente, debemos desmenuzarloigual que lo harıa el servidor, para lo que hay que anadir un control de eventos que,en caso de recibir paquete alguno, lo analice y extraiga la informacion pertinente(el codigo del programa clientDemo muestra una forma de gestionar los paquetesrecibidos usando eventos).

Se ha dispuesto de una lista de como configurar los paquetes ArNetPacket, ası co-mo los parametros a pasar para enviar las solicitudes correctamente al servidor. Seha descubierto que esta informacion no se haya disponible de forma explıcita en ladocumentacion oficial de ArNetworking, por esa razon en el fichero serverDemo.logincluıdo en el CD se muestra una lista bastante extensa sobre este tema. Como anota-


cion indicar que para la activacion y desactivacion de modos, como el modo wandero el modo de conducion segura ”safeDrive”, se debe pasar siempre un byte indican-do si se activa el modo en cuestion o no.

Otro ejemplo, de como activar el modo patrulla libre, usando ArNetPacket:

. . .ArNetPacket packet ;packet . byteToBuff ( value ) ;&c l i e n t−>requestOnce ( ”wander” ,& packet ) ;. . .

donde value sera un entero, 0 o 1, para desactivar o activar el modo respectivamente.

3.4.2. ARNL y SONARNL

ARNL, o sistema de navegacion y localizacion inteligente por laser, es un conjun-to de aplicaciones que solo se encuentran disponibles para el paqueteLaserNavigationde MobileRobots, por lo que solo esta disponible si se ha adquirido previamenteun sistema laser SICK. Permite usar los algoritmos de localizacion (como el filtrode partıculas), planificacion de rutas (una version mejorada del A*) y de mapeosimultaneo (SLAM, lo que permite generar mapas 2D) usando la informacion pro-cedente de un dispositivo laser SICK.

ARNL hace uso de Aria y ArNetworking, por lo que es necesario tener dichaslibrerıas previamente instaladas en el equipo (ver Apendice A). Incluye el programaarnlServer, en la ruta /usr/local/Arnl/examples, que se debe ejecutar en elpropio robot. El programa incluye un servidor con el que poder solicitar serviciosremotamente, como se hacıa en ArNetworking. Por normal general, se suele usarjunto a SONARNL, el cual viene incluıdo junto a este (aunque tambien se encuentradisponible por separado para todos los usuario), y que se usa para la misma finali-dad pero haciendo uso de los dispositivos de ultrasonidos que puede tener el robot.

El caso de MOGS, al igual que ARNL o SONARNL, tambien permite realizar lastareas de localizacion pero usando las mediciones obtenidas por un GPS. Como nodisponemos en la escuela de este dispositivo, el acceso a la documentacion asi comoal software no ha sido posible y, por tanto, no se ha incluıdo en el CD.

Todos estos programas estan pensados principalmente para ser usados junto


al programa MobileEyes, la interfaz de control remoto que se incluye junto en elPioneer SDK. Lanzando previamente el servidor arnlServer y conectando a conti-nuacion mediante MobileEyes (/usr/local/MobileEyes/), podemos crear losmapas del entorno, programar rutas y hacer uso de todas las funciones que Ariaprovee. Una de las opciones que MobileEyes incluye es la posibilidad de crear unlog completo de los paquetes ArNetPacket usados para enviar y recibir las ordenessolicitadas, la unica y la mejor manera existente (debido a la falta de esa parte de ladocumentacion oficial) de descubrir el nombre que tienen los servicios disponiblesy que parametros reciben.

3.4.3. SAV y ACTS

SAV y ACTS son las unicas aplicaciones proporcionadas en SDK que permitenmanipular la camara de vıdeo del robot y capturar imagenes.

ACTS es el programa desarrollado por el Dr. Paul Rybski que permite al robotusar la camara para realizar tareas de vigilancia, rastreo de colores y, en resumen,cualquier tarea relacionada con la vision artificial. Provee de una avanzada interfazgrafica con la que se puede entrenar al robot a detectar y reconocer hasta 320 objetosa todo color con una tasa de frames de 30fps5. El sistema de entrenamiento se reali-za haciendo en primer lugar una sesion de captura de imagenes (a mayor cantidadmejor aprendizaje), luego aplicando los algoritmos de reconocimiento de patronesque implementa el programa y por ultimo ejecutando dichos algoritmos duranteuna captura en tiempo real. Un ejemplo sencillo de aplicacion practica serıa hacerque el robot se acercase a un objeto de color rojo.

Por otro lado se encuentra SAV (actualmente en proceso de actualizacion a Ar-Video). SAV es una aplicacion de tipo servidor asentado sobre ArNetworking quese encarga exclusivamente de ofrecer un enlace directo con los drivers de la camara,de forma que se pueda mover y capturar. Para poder implementar un servidor queofrezca en tiempo real imagenes, es necesario lanzar este servidor previamente, yposteriormente establecer la conexion usando los servicios como se comento en laseccion de ArNetworking. Para ello, basta con ejecutar el programa savServer

ubicado en la ruta, por defecto, /usr/local/SAV desde el propio robot. Si to-do sale bien, aparecera un mensaje indicando que se ha preparado un servidoren el puerto 7070. A continuacion, bastarıa con ejecutar nuestro servidor de ser-vicios (como el programa serverDemo), esperar a que localice el servidor SAV y

5Un fps equivale a una imagen por segundo (frame per second).


habilite el servicio de retransmision (en esta ocasion se habilitarıa sobre el puerto7272), de forma que para solicitar imagenes desde un cliente solo debamos enviaruna solicitud usando requestOnce("sendVideo"), o su variacion de solicitudde datos en el tiempo request("sendVideo",intervalo). Ademas, para po-der hacer pruebas de que el servidor funciona correctamente y ofrece imagenesdirectamente obtenidas de la camara, se puede usar el cliente SAV, localizado en/usr/local/acts/SAV/savClient.

SAV permite tambien poder mover la camara. La camara disponible (la VC-C50ide Canon) tiene capacidad de movimiento en 3 ejes (vertical, horizontal y zoom).Los lımites de estos vienen dados por la Tabla 3.3.

Tabla 3.3: Lımites de los ejes de la camara.

Eje Mınimo MaximoVertical -98.0º(Left) 98.0º(Right)Horizontal -30.0º(Down) 88.0º(Up)Zoom 0.0 %(Out) 100.0 %(In)

Para poder moverla usando los paquetes ArNetPacket debemos usar el coman-do cameraAbs que recibe tres parametros de tipo double o el comando camera, querecibe tambien tres parametros similares, siendo el primero el eje horizontal (pan), elsegundo el vertical (tilt) y el tercero el zoom. Se ha comprobado que MobileEyes,por alguna razon, solo usaba el primero comando para establecer la direccion de lacamara, dejando el zoom sin modificar, que para este caso, usaba la segunda ordenpero con los dos primeros a 0. La razon, por lo que se ha podido comprobar, se debea que el comando cameraAbs trabaja con valores incrementales, esto significa quesi deseamos que la camara mire a 90º a la derecha y actualmente esta mirando a 30ºa la derecha, debemos enviar multiples paquetes con un valor numerico pequenoindicando la velocidad de incremento del angulo de la camara y controlando queno supere el angulo buscado. Algo un poco confuso y que, por desgracia, tampocose explica en ningun lugar de la documentacion oficial. Si en cualquier momentodeseamos centrar la camara a sus valores iniciales, bastarıa con enviar un paquetecon el comando cameraAbs y en un paquete sin parametros (en lugar de adjuntarlos tres doubles).

En el directorio /usr/local/Aria/ArNetworking/examples, hay disponi-ble tambien una aplicacion (sin compilar) llamada getVideoExample. Este pro-grama permite realizar grabaciones en tiempo real de lo que sucede en la camara.La forma de poder grabar la he realizado con exito siguiendo el siguiente procedi-miento:

3.5 RoboComp al detalle 49

/ / I n i c i a m o s e l s e r v i d o r SAV en e l r o b o t[ ] $ cd /usr/ l o c a l /SAV[ ] $ ./ savServer

/ / Compilamos e l g r a b a d o r y l o lanzamos d e s d e un c l i e n t e$ /usr/ l o c a l /Aria/ArNetworking/examples$ make getVideoExample$ ./ getVideoExample −host 1 6 1 . 6 7 . 1 9 6 . 3 3

−p 7070 −r a t e 30 −counter

/ / Cuando f i n a l i c e m o s l a e j e c u c i o n de ge tVideoExampl e/ / comprimimos l a s imagenes en v i d e o usando f fm peg

$ ffmpeg − i video %d . jpg −r 30 movie . mpeg

El grabador getVideoExample requiere como parametros la ip o nombre delhost donde esta lanzado el servidor SAV, el puerto donde debe conectarse (por de-fecto 7070, o 7272 si lo ofrece un servidor como serverDemo), la cantidad de image-nes por segundo (fps) que deseamos recibir (si se omite solo solicitara una y final-zara el programa) y, opcionalmente, con el parametro counter podemos indicarque queremos que cada imagen recibida lleve un numero, necesario para luego crearel vıdeo.

Para comprimir las imagenes en un vıdeo, se pueden usar diferentes programas.Se ha probado especialmente ffmpeg, por la sencilla razon de que resulta extrema-damente sencillo y rapido crear los vıdeos a partir del lote de imagenes. Para ellosolo hay que pasarle como parametros el formato de nombre que usan las imagenes(de ahı la utilidad de usar el -counter), que en el caso sera video%d.jpg (don-de%d es el numero del contador), -r la cantidad de imagenes por segundo usadaspara la compresion (si se establece una captura de 30fps, aquı deberemos usar tam-bien 30 para que haya consistencia) y por ultimo el nombre que deseamos que tengael fichero de vıdeo resultante, en formato .mpeg.

3.5. RoboComp al detalle

RoboComp es un proyecto de software libre llevado a cabo por RoboLab (http://robolab.unex.es/), de la universidad de Extremadura. Se trata de un frame-work orientado a la robotica y la vision artificial, cuyo objetivo es unificar el desarro-

http://robolab.unex.es/

http://robolab.unex.es/


llo de software para cualquier clase de robot, mediante la creacion de modulos quepuedan servir para diferentes arquitecturas hardware y con la capacidad de poderser ejecutados de forma distribuida6. Provee para ello de un repositorio con el quetodos los investigadores pueden trabajar, utilizando los modulos ya creados o biencreando y compartiendo nuevos modulos. Sus principios se basan en la eficiencia,la reusabilidad, la facilidad de uso y la abstraccion de hardware.

Para lograr todo esto, RoboComp utiliza un sistema de tipo cliente/servidor quese coloca entre la capa software mas cercana al hardware (por ejemplo Aria en elcaso que se trata en este trabajo) y la capa software mas superior que se encargarıade la ejecucion de los algoritmos de calculo (rutas, mapeado, localizacion, etc.). Es-ta idea es lo que se conoce como middleware, una capa software interecalada entreotras dos capas (software o hardware) que sea la encargada de comunicar ambosbandos independientemente de las cualidades fısicas de uno u otro. Ademas, estesistema permitirıa tambien ejecutar esos algoritmos de alto coste computacional (yespacial) ser lanzados en distintas maquinas y procesadores de forma distribuida yremota, lo que facilitarıa que robots pequenos y anticuados (limitados en capacidadde computo y/o memoria) puedan realizar tareas que de otra forma, no podrıandebido a la poca potencia de su hardware.

RoboComp hace uso de la tecnologıa de Ice y IceStorm para cumplir su co-metido. Ice (Internet Computer Engine) es una herramienta orientada a objetos quepermite al desarrollador programar sus aplicaciones distribuidas sin tener que de-dicar sus esfuerzos a las comunicaciones de red (abrir conexiones, serializar objetos,etc.), centrandose exclusivamente en la logica de sus programas. IceStorm, por suparte, proporciona a Ice de un servicio de publicacion/subscripcion mediante uncolector de datos, que permite a las aplicaciones pasarse informacion de multiplesmaneras mediante el manejo de eventos (ver Figura 3.5).

Un ejemplo donde IceStorm ganarıa fuerza serıa con un servidor que propor-cionase continuamente datos obtenidos por un sensor laser del robot. El programaenviarıa al colector (o buffer) dichos datos numericos, y ya los clientes que deseenesos datos se encargarıan de recogerlos cuando pudiesen o los necesiten. IceStormpermite configurar los modos de comunicacion para centrar el flujo de datos en co-nexiones unicas o de tipo radiodifusion.

6Un sistema distribuido comprende aquel cuya capacidad de computo es repartida (distribuida)sobre un cluster de maquinas o procesadores.


Figura 3.5: Esquema funcionamiento de IceStorm.

Robocomp es actualmente distribuido a traves de un repositorio disponible enhttp://robocomp.sourceforge.net/wordpress/?page_id=31. Su actua-lizacion, a diferencia de su descarga, requiere de disponer de permisos de escriturasobre el mismo, reservado a los deserrolladores que ası lo indiquen. Al estar su tec-nologıa pensada para poder desarrollarse en diferentes plataformas hardware, esperfectamente compatible tanto con Linux como con Windows, si bien las herra-mientas de que dispone y que se crearon para facilitar la tarea de desarrollo estanorientadas para su uso bajo Linux. En el Apendice B se puede encontrar toda la in-formacion referente a su instalacion en un entorno Ubuntu, asi como la descarga,instalacion y configuracion del editor adjunto y la solucion de problemas que pu-diesen surgir.

Actualmente, el grupo SIMD del I3A de Albacete dispone en el repositorio devarios componentes ya creados en este framework y que pueden ser usados con elsimulador innerModel que tambien incluye.

A continuacion, se detallara en mas profundidad sobre el contenido que incluyeel repositorio ası como las herramientas que han sido utilizadas para el desarrollode este trabajo.

3.5.1. Contenido del repositorio RoboComp

La estructura del repositorio se subdivide en multiples carpetas, de las cualesnos interesan exclusivamente tres, que son con las que se ha trabajado:

Components: contiene todos los artefactos software que los investigadores hanido creando y compartiendo. La norma general que se ha de seguir es la si-guiente. Se crea una carpeta que indique el nombre de la empresa o entidad

http://robocomp.sourceforge.net/wordpress/?page_id=31


que ha desarrollado los componentes y dentro de esa carpeta se crean las sub-carpetas correspondientes al proyecto. Cuando dentro de una carpeta se vayana incluir los fuentes del modulo programado, este debe terminar su nombrecon la palabra Comp. Por ejemplo, para la realizacion de este proyecto se hadearrollado un servidor que engloba algunos de los servicios de Aria mas in-teresantes, para lo cual se creo bajo la carpeta Components el subdirectorioDaniJimenez, el cual aloja en su interior los componentes desarrollados, co-mo el caso del ServerRobotComp, que engloba algunas de las funciones masusadas por Aria para manipular el robot P3-DX.

Interfaces: esta carpeta posee otra denominada IDSLs, en la cual se debenalmacenar todos los ficheros IDSL que vayamos necesitando.

Tools: este directorio almacena los editores y herramientas que necesitamospara trabajar con RoboComp. El editor DSL para la creacion de los componen-tes esta guardado aquı.

El editor DSLEditor utilizado para la creacion y compilacion de los componenteses distribuido de forma independiente al repositorio, si bien, se incluye en este unscript en python que permite descargarlo remotamente. El mayor problema con estees que, debido a donde se encuentra alojado, es batante probable que no este dispo-nible actualmente, por esa razon se ha incluıdo una version funcional en el CD queacompana a este documento. Su funcionamiento y uso viene explicado detallada-mente en el Apendice B, ası como la forma de manejarlo para la creacion de nuevoscomponentes.

Por ultimo, se incluye el simulador InnerModel. Antes de proceder a ejecu-tar los componentes que usen dicho simulador, debe ser recompilado el InnerMo-delDSL para su uso. En el desarrollo de este trabajo no ha sido necesario su uso,aunque si ha sido necesario realizar la recompilacion por otros problemas tecnicosque surgieron durante la instalacion y preparacion del framework.

3.5.2. Los ficheros CDSL, IDSL y PDSL

Los ficheros CDSL, IDSL y PDSL son los mas importantes a la hora de generar ydesarrollar componentes en RoboComp. Cada uno de ellos tiene una finalidad con-creta que se explicara a continuacion, ası como el formato interno que deben tener.


RoboComp usa los IDLs (Interface Definition Language) para definir las interfa-ces que seran usadas por nuestros componentes. El problema con los IDLs de terce-ros, es que tienden a crear ciertas dependencias innecesarias debido a que a menudo,los tipos de datos ası como los proxys se combinan junto al codigo fuente del usua-rio. Esto provocaba que, si en algun momento modificasemos la definicion de lainterfaz (el IDL), debıamos tambien modificar el codigo que la implementaba. Paraevitar esto, se desarrollaron los IDSLs (Interface Description Specific Language), quepermiten disenar las interfaces de los componentes de forma que esas dependenciasmencionadas desapareciesen, facilitando la tarea de desarrollo al no tener que rees-cribir la interfaz con cada nueva modificacion (todo se hace de forma automatica,como se muestra en el ejemplo de compilacion propuesto en el Apendice B). LosIDSL pueden ser traducidos al formato del lenguaje IDL en cualquier momento sifuese necesario.

Los IDSL deben almacenarse en el directorio del repositorio robocomp/Interfaces/IDSLs,teniendo estos el siguiente esqueleto:

module RoboCompMiInterfaz{i n t e r f a c e MiInter faz {

<t ipo> misMetodos(< t ipo> misParametros ) ;} ;

} ;

Los ficheros CDSL, de forma similar a los IDSL, definen su propio lenguaje espe-cifico, aunque en esta ocasion orientado a establecer los modelos de comunicacionde tipo cliente/servidor o de tipo publicador/subscriptor. Por ejemplo, un servidordebe realizar una serie de operaciones que permitan preparar todo el entorno de redpara poder recibir y atender las solicitudes de servicios que se indiquen, de la mis-ma forma sucede con el cliente. La finalidad de los CDSL es automatizar toda estalabor, de forma que el propio desarrollador no deba preocuparse por el tema de lascomunicaciones ni el tratamiento de las conexiones (una de las metas que buscabaRoboComp y por lo que usaba Ice). Para poder definir los CDSL, suele ser necesariohacer referencia a los metodos definidos en una interfaz dada por un IDSL (o porvarios, segun el caso), por lo que es necesario tener creado el IDSL antes de procedera crear el CDSL.

Los CDSL, por su parte, deben almacenarse en los correspodientes subdirecto-rios donde se van a generar los componentes cuyas rutas estaran bajo la carpetarobocomp/Components/.../MiComponenteComp, teniendo estos el siguienteesqueleto:


import ”/robocomp/ I n t e r f a c e s /IDSLs/MiInter faz . i d s l ” ;Component MiComponenteComp{

Communications{<modo> MiComponente ;

} ;language Cpp ;

} ;

Se permite en esta ocasion definir el lenguaje de programacion en que se va aimplementar, siendo en el ejemplo descrito en C++.

El tercer tipo de fichero, que aunque no fue requerido para las pruebas realizadassobre RoboComp en este trabajo sı que resulta de interes comentarlo, son los PDSL.Los PDSL, definen el lenguaje de definicion de parametros, usados principalmentepor los desarrolladores mas experimentados para reducir la tasa de errores durantela puesta en marcha de los componentes. Los PDSL permiten configurar el editorpara que automaticamente genere todas las plantillas necesarias con los paramtrosprecargados, lo que hace que en caso de error primero se avise al usuario para quemodifique la plantilla, en lugar de lanzar el componente y que este genere erroresque de otra forma no podrıamos permitirnos. Esta clase de ficheros debe ser creadodespues de los CDSL, ya que debe indicarsele el componente sobre el que debe ac-tuar.

La estructura de estos ficheros es como la que sigue:

import ”MiComponente . c d s l ” ;ComponentParams MiComponentenComp{

<parametro> <t ipo> <valor> <min : max> T ;} ;

Como se puede apreciar, opcionalmente (segun el tipo de datos) se puede definirel rango de valores que se permite, una forma ideal de chequear que se han intro-ducido los valores correctos sin tener que programarlo explıcitamente. El valor, porsu parte, define el valor por defecto que se asignarıa, en caso de que fuese necesariasu inicializacion.


3.5.3. Modos de comunicacion

Como se comento, IceStorm permite a los artefactos software comunicarse usan-do un colector de datos. Ahora bien, ¿que tipos de comunicaciones podemos esta-blecer y que resultados podemos esperar?

Con RoboComp, podemos establecer cuatro tipos de comportamiento:

publishes: prepara al colector de datos para indicar que el componente ofreceinformacion al mismo.

subscribeTo: prepara el colector de datos para indicar que el componente reci-be informacion del mismo.

implements: indica al CDSL que ese componente implementa los metodos delIDSL importado.

requires: indica al CDSL que ese componente utiliza los metodos del IDSLimportado (los invoca).

Esto debe configurarse para cada metodo del IDSL que se importe en los ficherosCDSL.

El uso que se de de los diferentes metodos depende exclusivamente del progra-ma que se este buscando desarrollar, aunque todos tienen la peculiaridad de que encaso de que, o bien el que ofrece los servicios/informacion falle, o bien falle el quelos recibe, el sistema completo no se bloquee completamente.

3.5.4. Funcionamiento de los componentes: SpecificWorkers

RoboComp tiene la capacidad de pregenerar todo el codigo necesario para po-der crear aplicaciones cliente/servidor de forma rapida y automatica, como se co-mento en los puntos anteriores. Ahora bien, ¿como trabajan internamente los com-ponentes para comunicarse entre si? Para responder a esta pregunta debemos entraren detalle con algunos de los fuentes mas importantes que se generan a partir de unCDSL, como son los SpecificWorkers.


Figura 3.6: Diagrama de un componente Robocomp.Figura obtenida de [7].

En la Figura 3.6 se muestra el modelo de comunicacion interno que utiliza ca-da componente, y que se encarga de establecer las comunicaciones, ası como deabrir las conexiones necesarias para su ello. Como se puede apreciar, todo el codigogenerico es el creado automaticamente por el CDSL, mientras que la funcionalidadmisma del componente acaba delegada en el specificWorker y el specificMonitor.El codigo que nos interesa conocer en detalle es el specificWorker, que sera el en-cargado de llevar la parte logica de nuestro componente (por esa razon no se auto-completa solo al generar el CDSL).

Su localizacion, tras generar el codigo de un CDSL, sera encontrada bajo la sub-carpeta MiComponenteComp/src. En ella, podremos encontrarlo bajo el nombrespecificworker.cpp, siendo su cabecera specificworker.h. La estructura que siguen,al ser en lenguaje C++, es la misma que en cualquier aplicacion creada en dicholenguaje. La cabecera define la clase SpecificWorker que hereda de GenericWorker(que a su vez hereda material del resto de fuentes pregenerados). El fuente .cpp

implementa los prototipos de las funciones y metodos definidos en la cabecera. Siabrimos el fuente, comprobaremos que en su interior estan creados el constructorde la clase, un metodo llamado compute() y, en el caso del servidor que imple-mente los metodos de la interfaz, un esqueleto con dichos metodos cuyo tipo de-vuelvo es Ice::<tipo>. Si en lugar de implementar el metodo lo usase (caso deun cliente que lo invoca), este prototipo no existirıa y en su lugar, en la cabeceragenericworker.h tendrıamos un proxy para esa interfaz que nos permitirıa invocarlos metodos remotamente, cuya declaracion sigue la nomenclatura MiInterfazPrx

3.6 Integracion de Pioneer SDK y RoboComp 57

miInterfaz proxy;.

En resumen, si estamos implementando los metodos definidos en el IDSL, debe-mos editar el specificworker.cpp y buscar las lıneas como:

. . .I c e : :< t ipo> Speci f icWorker : : miMetodo(< t ipo> parametros ){

/* aquı l a l o g i c a del s e r v i c i o */}. . .

Mientras que si lo que implementamos es al cliente que los invoca, deberemosbuscar el metodo compute(), y anadir las solicitudes allı:

. . .void Speci f icWorker : : compute ( ){

/* aquı l a l o g i c a de llamadas */miInterfaz proxy−>miMetodo(<parametros > ) ;

}. . .

Realizandose las invocaciones de los servicios como se muestra.

Todo el proceso para crear un componente, compilarlo y ejecutarlo viene descritodetalladamente con un ejemplo practico en el Apendice B. Recomendamos encare-cidamente su lectura, debido a la importancia de este tema para lograr una imple-mentacion correcta.

3.6. Integracion de Pioneer SDK y RoboComp

Tras estudiar en profundidad el funcionamiento interno de Aria y RoboComp,uno de los aspectos mas duros de llevar a cabo (y de la que no se disponıa documen-tacion previa alguna) fue, sin lugar a dudas, la integracion de todo el framework deAria con el sistema de comunicaciones de RoboComp. Esto demostro el duro trabajocon el que a menudo se encuentran los investigadores en cualquier disciplina.

El proceso de integracion ha sido el resultado de meses de estudio y aprendizaje,no solo de los frameworks ya mencionados, sino tambien de otras aplicaciones ytecnologıas en las que se apoya y con las que no habrıa sido posible su trabajo de no


haberlas analizado previamente.

La mayor dificultad encontrada al tratar de integrar las librerıas de Aria en uncomponente de RoboComp fue la necesidad de tener que referenciarlas de algu-na manera para que el compilador supiese donde encontrarlas. Para anadirlas aun nuevo proyecto basta con agregar la lınea include ”Aria.h”;, siguiendo elesquema habitual usado en C/C++ para agregar nuevas librerıas al proyecto. A di-ferencia de cabeceras y fuentes que se encuentren en el mismo directorio que el pro-pio componente, esto no es suficiente para que el compilador localice la cabecera deAria. Las sucesivas pruebas nos llevaron a un fichero llamadoCMakeListsSpecific.txt

(ver Codigo 3.4), localizado en la carpeta src del componente.

Codigo 3.4: CMakeListsSpecific.txt Original

# S o u r c e s s e tSET ( SOURCES

s p e c i f i c w o r ke r . cpps p e c i f i c m o n i t o r . cpp

)# Headers s e tSET ( HEADERS

s p e c i f i c w o r ke r . hs p e c i f i c m o n i t o r . h

)

La solucion a este problema pasa por incluir las rutas a las librerıas, ası como alos directorios donde se encuentran los fuentes de estas al fichero mencionado.

Siguiendo la documentacion de CMake [2], para anadir el nuevo directorio don-de se encuentran los fuentes que deseamos enlazar al compilador, se hace uso delcomando:

INCLUDE DIRECTORIES( ruta )

Donde ruta debe ser sustituido por la ruta absoluta a la carpeta donde se en-cuentran las cabeceras y fuentes que se desean anadir. Para el caso de Aria, dichosfuentes se encuentran en /usr/local/Aria/include.

El siguiente paso consiste en agregar las librerıas de dichos fuentes. CMake re-quiere para ello agregar una nueva variable que indique la ruta absoluta a las mis-mas ası como el nombre en cuestion de las librerıas a anadir. Esto se realiza creando

3.6 Integracion de Pioneer SDK y RoboComp 59

una nueva variable con el comando SET , tal y como se describe a continuacion:

SET ( LIBS${LIBS} −L<ruta> < l i s t a l i b r e r i a s >

)

Donde ruta debe ser reemplazado por la ruta absoluta donde se encuentran losficheros de librerıas (ficheros .so que actualmetne se encuentran en /usr/local/Aria/lib)y lista librerias por una lista separada por espacios con el nombre de las li-brerıas a anadir.

El fichero de CMake que permite al compilador localizar Aria dentro de Robo-Comp quedarıa por tanto como el mostrado en el Codigo 3.5.

Codigo 3.5: CMakeListsSpecific.txt

INCLUDE DIRECTORIES(/usr/ l o c a l /Aria/include

)

# Sources s e tSET ( SOURCES . . . )

# Headers s e tSET ( HEADERS

/usr/ l o c a l /Aria/include/Aria . h. . . )

SET ( LIBS${LIBS} −L/usr/ l o c a l /Aria/ l i b Aria

)

¿Que sucederıa si a continuacion se desea agregar tambien las librerıas de Ar-Networking? La respuesta a esta pregunta es similar a como se hizo para referenciarAria. En primer lugar anadimos el directorio donde se encuentran las cabeceras yfuentes de, en esta ocasion, ArNetworking, y a continuacion agregamos su librerıa.Los fuentes de ArNetworking, se pueden encontrar actualmente en el directorio:

/usr/local/Aria/ArNetworking/include

, mientras que su librerıa esta almacenada en el mismo directorio que las de Aria.La modificacion del fichero CMakeListsSpecific.txt quedarıa por tanto comose muestran en el Codigo 3.6.


Codigo 3.6: CMakeListsSpecific.txt

# Include d i r sINCLUDE DIRECTORIES(

/usr/ l o c a l /Aria/include/usr/ l o c a l /Aria/ArNetworking/include

)

# Sources s e tSET ( SOURCES . . . )

# Headers s e tSET ( HEADERS

/usr/ l o c a l /Aria/include/Aria . h. . . )

SET ( LIBS${LIBS} −L/usr/ l o c a l /Aria/ l i b Aria ArNetworking

)

Notese que en lugar de usar repetidas veces el comando INCLUDE DIRECTORIES,se ha introducido bajo el mismo parentesis ambos directorios con los fuentes. Estemetodo puede realizarse con cualquier otra clase de librerıa o cabecera que se deseeagregar al componente, independientemente de su localizacion en el sistema. Si seda el caso de que la librerıa a anadir no se encuentra en el mismo directorio, se debeusar el parametro -L<ruta><lista librerıas> para seguir enlazando las nue-vas librerıas bajo la misma variable LIBS.

Tras varias pruebas, se observo que tanto Aria como ArNetworking funcionabancorrectamente y podıan conectarse sin problemas al robot real y al simulador de for-ma remota, como en cualquier otra aplicacion que hacıa uso de estas librerias.

Tambien se logro lo que andabamos buscando, la posibilidad de usar cabeceras yfuentes externas sin tener que referenciarlas usando rutas absolutas o bien teniendoque adjuntarlas al proyecto manualmente (algo que reduce bastante su portabilidadsi en el futuro se actualiza Aria).

CAPITULO 4

IMPLEMENTACION, EXPERIMENTOS Y RESULTADOS

Tras todo el estudio realizado sobre Aria y RoboComp, el ultimo paso restantepara poner en practica los conocimientos adquiridos fue la implementacion de dife-rentes programas que pusiesen a prueba ambos frameworks, ası como el testeo delos mismos sobre el simulador y el robot real.

4.1. Programas basados en Aria y ArNetworking

Se han incluıdo una serie de aplicaciones de prueba que usan las librerias deAria y ArNetworking, de forma que puedan estudiarse los principales mecanismosde comunicacion y configuracion desarrollados en el Capıtulo 3.

Algunos de estos programas han sido creados usando un IDE (Code::Blocks yEclipse), mientras que otros se compilaron usando makefiles. La finalidad de estoera conseguir proveer de la informacion necesaria sobre como podemos compilarun programa que use Aria, algo importante para futuros desarrolladores no muyexperimentados sobre esta parte de la materia. Tambien se pretendia hacer pruebassencillas para comprender como establecer conexion con el robot y manipularlo.

En la carpeta fuentes disponible en el CD, se incluyen todos los programas deejemplo que se crearon. Algunos corresponden a los ejemplos que se daban en ladocumentacion oficial, mientras que otros son el resultado de las experimentacio-nes personales llevadas a cabo.

61

62 Capıtulo 4. IMPLEMENTACION, EXPERIMENTOS Y RESULTADOS

Uno de esos ejemplo es un programa que conecta con el robot (fısicamente, esdecir, usando solo Aria) y permite controlar el robot usando las teclas WASD.

El codigo fuente es el siguiente:

Codigo 4.1: robot keyevent 1.cpp

/** robot keyevent 1 . cpp

** Created on : Dec 13 , 2013

* Author : razorbreak

*/# i n c l u d e ” Aria . h”# i n c l u d e < s t d i o . h># i n c l u d e <u n i s t d . h># i n c l u d e <t e r m i o s . h># i n c l u d e <i o s t r e a m>

# i n c l u d e <math . h>

i n t main ( i n t argc , char * * argv ){s t r u c t termios o l d t i o , new tio ;unsigned char c ;double d i s t a n c e =500 .0 , t h e t a = 4 5 . 0 ;

/* get the terminal s e t t i n g s for s t d i n */t c g e t a t t r ( STDIN FILENO,& o l d t i o ) ;new tio= o l d t i o ;/* d i s a b l e canonica l mode ( buffered i /o ) and l o c a l echo */new tio . c l f l a g &=(˜ICANON & ˜ECHO) ;/* s e t the new s e t t i n g s immediately */t c s e t a t t r ( STDIN FILENO ,TCSANOW,& new tio ) ;

Aria : : i n i t ( ) ; // S t a r t Aria EngineArArgumentParser parser (&argc , argv ) ;ArSimpleConnector simpleConnector (& parser ) ;ArRobot robot ;parser . loadDefaultArguments ( ) ;i f ( ! Aria : : parseArgs ( ) | |

4.1 Programas basados en Aria y ArNetworking 63

! parser . checkHelpAndWarnUnparsed ( ) ) {Aria : : logOptions ( ) ;e x i t ( 1 ) ;

}i f ( ! simpleConnector . connectRobot (& robot ) ) {

p r i n t f ( ”Could not connect to robot . . . e x i t i n g \n” ) ;Aria : : e x i t ( 1 ) ;

}// t rue means i f we l o s e connect ion the robot should stop

robot . runAsync ( t rue ) ;

robot . lock ( ) ;robot . comInt (ArCommands : : ENABLE, 1 ) ; //Enable motorsrobot . unlock ( ) ;

s td : : cout << ”\n\n ROBOT READY FOR INPUT ! ! ! ” << std : : endl ;

do { //Event f e t c hstd : : cout << ” Current l o c a t i o n : ( ” <<

robot . getX ( ) << ” , ” <<

robot . getY ( ) << ” , ” <<

robot . getPose ( ) . getTh ( ) << ” ) ”<< ”\n−−−B a t t e r y : ” << robot . ge tBat te ryVol tage ( )<< ”V. ” << std : : endl ;

c=getchar ( ) ;i f ( c ==’w’ ) {

robot . move( d i s t a n c e ) ;} e lse i f ( c == ’a ’ ) {

robot . setDeltaHeading(− t h e t a ) ;} e lse i f ( c == ’s ’ ) {

robot . move(−d i s t a n c e ) ;} e lse i f ( c == ’d ’ ) {

robot . setDeltaHeading ( t h e t a ) ;}

}while ( c ! = ’ q ’ ) ;

Aria : : shutdown ( ) ; // F i n a l i z e Aria engine and stops robot

/* r e s t o r e the former s e t t i n g s */


t c s e t a t t r ( STDIN FILENO ,TCSANOW,& o l d t i o ) ;}

Para lograr la captura de las teclas se hace uso de la funcion getchar() de C,tras una modificacion de la consola que permite capturas los caracteres conforme seescriben (sin necesidad de presionar Enter para su envıo). Los ejemplos de MobileRobots usan clases internas llamadas ArFunctor, las cuales permiten asignar accio-nes tras la recepcion de un evento.

El resto del funcionamiento mostrado en el Codigo 4.1 es similar a como se ex-plico en el Capıtulo 3 sobre Aria. Primero se lanza el engine usando Aria::init(),se le pasan los parametros del programa a la clase ArArgumentParser para que losanalice, y a continuacion se crea el objeto de ArRobot que nos permitira usar sumetodos para controlarlo y recibir informacion directa del robot. Se puede observartambien las comprobaciones que se deben hacer para, en caso de que algun parame-tro no coincida, muestre un mensaje de ayuda sobre Aria. Acto seguido se establecela conexion con el hardware y si todo sale bien, se procede a ejecutar las acciones decontrol.

Algunos de los metodos que se pueden apreciar por primera vez y que corres-ponden a la claseArRobot son getX(), getY(), getBatteryVoltage(), move()o setDeltaHeading(). Respectivamente, permiten obtener informacion sobre laposicion relativa (a no ser que este el robot localizado en un mapa), el nivel de ba-terıa actual y ejecutar movimientos (adelante y atras, segun sea positivo o negativo)o girar (rotar) un angulo determinado.

El fuente fue creado usando Eclipse, por lo que se acompana con toda la car-peta que mantiene el proyecto. Sin embargo, esto no limita su compilacion usandomakefiles (se ha agregado uno de prueba en la carpeta fuentes que permite com-pilar cualquier programa que use Aria y ArNetworking). En el ejemplo mostrado,se puede observar el proceso llevado a cabo para inicializar el motor de Aria, co-nectarse con el robot (y comprobar que la conexion se ha llevado con exito antes detratar de conducirlo) y por ultimo, como podemos acceder a la informacion del ro-bot (como posicion o el estado de la baterıa) ası como enviarle ordenes directamentea los motores para mover el robot (usando los metodos adecuados, como move() osetDeltaHeading()).

Hay disponibles mas ejemplos que conectan al laser y otros accesorios asi comootros programas que permiten manejar la camara, obtener imagenes, etc. Su lectu-

4.2 Componente RoboComp: ServerRobotComp 65

ra esta completamente recomendada si se desea comenzar a desarrollar programasorientados al robot.

4.2. Componente RoboComp: ServerRobotComp

La culminacion de toda la integracion de los frameworks dio como resultadola implementacion de un servidor remoto que conectase con el propio robot, permi-tiendo ası que desde otros componentes RoboComp se pudiese obtener informaciondel robot o manipularlo a conciencia.

La finalidad de este modulo es servir como base para que futuros desarrollado-res puedan expandir su funcionalidad de forma facil y rapida sin tener que repetirel mismo camino que se tuvo que realizar para lograr las metas planteadas, o al me-nos, que el camino fuese algo mas sencillo y comprensible.

El proyecto que implementa este componente se haya disponible en el CD enuna carpeta llamada implementacion. Dentro existe otra llamada robocomp que debeser copiada a la carpeta donde esta descargado el respositorio de RoboComp. En elinterior de esta, se puede observar que sigue la misma estructura de directorios, deforma que su despliegue sea rapido y seguro. En la carpetaDaniJimenez existe otrallamada TestAria, la cual contiene el componente en cuestion que implementa elservidor.

El funcionamiento de las comunicaciones del componente se realizan como semuestra en el diagrama de la Figura 4.1.

La idea en torno al componente se centra en usar el propio servidor de Robo-Comp como un cliente de ArNetworking clasico, con la diferencia de que a su vez,sirve como proveedor de servicios para otros clientes RoboComp. El componentedebe hacer uso de ArNetworking y establecer la conexion con un servidor en eje-cucion en el robot (cualquiera de los mencionados en la seccion de Aria sirve, co-mo serverDemo). De esta forma podemos aislar completamente de Aria a cualquiercliente que desee trabajar con el robot.

Para lograr todo esto, se ha creado un IDSL que implementa algunas de las ta-reas tıpicas del robot, como puede ser hacer que se mueva manualmente, manipularla direccion de la camara, enviarlo a una posicion del mapa, etc. El codigo de dicho


IDSL se muestra a continuacion.

Codigo 4.2: Interfaces/IDSLs/ImpAria.idsl

module RoboCompImpAria{i n t e r f a c e ImpAria{

i n t conectarRobot ( ) ;i n t desconectarRobot ( ) ;i n t ratioDriveMode ( double t r a n s l a t i o n ,

double r o t a t i o n ,double l a t e r a l ) ;

i n t wanderMode ( bool a c t i v a t e ) ;i n t moveCamera ( double pan , double t i l t , double zoom ) ;i n t resetCameraPos ( ) ;i n t getCameraImage ( ) ;i n t s e tS a fe Dr ive ( bool a c t i v a t e ) ;i n t stopRobot ( ) ;i n t setGyro ( bool enable ) ;} ;

} ;

La razon por la que se ha escogido esta estructura es debida a la clase ArNetPac-ket. Cada uno de esos metodos generara un paquete de dicha clase que sera enviada

Figura 4.1: Funcionamiento ServerRobotComp.


al servidor del robot. Se ha tratado de seguir la misma estructura que en Aria, paramantener la consistencia entre las llamadas.

Como requisito indispensable para crear el componente, se ha generado tam-bien el correspondiente fichero CDSL, que indica que el servidor implementara esosmetodos de la interfaz.

Codigo 4.3: Components/.../ServerRobotComp/ServerRobot.cdsl

import ”/robocomp/ I n t e r f a c e s /IDSLs/ImpAria . i d s l ” ;Component ServerRobotComp{

Communications{implements ImpAria ;

} ;language Cpp ;

} ;

Tras ello, se debe generar el codigo usando el menu contextual del editor DSL, loque creara todos los fuentes, scrtips y ficheros de configuracion que el compiladornecesitara para generar el ejecutable del componente. Antes de compilarlo, debe-mos implementar los servicios que proveera el servidor, para que cualquier clienteque los requiera los invoque.

La implementacion se realiza sobre el fichero specificworker.cpp, anadiendo lalogica que queremos que posea cada metodo. Para evitar listar todo el codigo (dis-ponible tambien en el directorio implementacion del CD), nos limitaremos a exponerla implementacion de algunos de los metodos, en concreto del que activa el modo depatrulla libre y el que permite enviar ordenes de movimiento directamente al robot.

Codigo 4.4: Components/.../ServerRobotComp/src/specificworker.cpp

. . .I c e : : I n t Speci f icWorker : : wanderMode ( bool a c t i v a t e ){

i n t value =1;i f ( ! a c t i v a t e ) value =0;ArNetPacket packet ;packet . byteToBuf ( value ) ;(& c l i e n t )−>requestOnce ( ”wander” ,& packet ) ;return 0 ;


}

i n t Speci f icWorker : : ratioDriveMode ( double t r a n s l a t i o n ,double r o t a t i o n ,double l a t e r a l )

{ArNetPacket packet ;packet . doubleToBuf ( t r a n s l a t i o n ) ;packet . doubleToBuf ( r o t a t i o n ) ;packet . doubleToBuf ( 1 0 0 ) ; //maxima velocidadpacket . doubleToBuf ( l a t e r a l ) ;(& c l i e n t )−>requestOnce ( ” r a t i o D r i v e ” , &packet ) ;return 0 ;

}. . .

Esos metodos, sirven de ejemplo para mostrar como se pueden transmitir lasordenes de Aria al robot usando la clase ArNetPacket. El resto de metodos sigue elmismo esquema.

Uno de los detalles, quizas mas importantes, fue la necesidad de configurar laconexion con el servidor remoto que se lanza desde el robot, y al que debe conectarseeste componente. El problema principal residia en que, en los ejemplos habituales deAria, los parametros de configuracion se pasaban al programa a traves de la consola.En robocomp esto no es posible, ya que los parametros transmitidos al ejecutable delcomponente no se pueden transmitir a la clase SpecificWorker. Para poder lograrque el componente se pudiese conectar al servidor, fue necesario anadirlos a nivelde codigo, desde el propio constructor de la clase usando las siguientes lıneas:

Codigo 4.5: Components/.../ServerRobotComp/src/specificworker.cpp

. . .char * parameters [ ] = {”robocomp” , ”−host ” , ” 1 6 1 . 6 7 . 1 9 6 . 3 3 ” } ;i n t numParameters = 3 ;ArArgumentParser parser (&numParameters , parameters ) ;

. . .

Acto seguido se podıa proceder como de costumbre para establecer la conexionusando la clase ArSimpleConnector, como se mostro en el anterior capıtulo.

Para realizar las pruebas, se creo un segundo componente llamadoClientRobotComp,


en el que en su metodo compute() se realizaban llamadas a los metodos creados enel IDSL. El resultado fue el esperado. Cuando se invoco el metodo del modo wanderusando la lınea de codigo:

imparia proxy−>wanderMode ( t rue ) ;

El robot automaticamente recibıa el paquete desde ServerRobotComp y se ponıaa deambular por el laboratorio.

Solo habıa que tener cuidado con las constantes solicitudes que el cliente realiza-ba, pues el metodo compute() es ejecutado multiples veces cada cierto periodo detiempo, lo que puede saturar el ancho de banda del robot y provocarle ralentizacio-nes en su comportamiento (recuerdese el ciclo de comunicacion que el robot realizacon Aria y que se explico al principio del Capıtulo 3).

CAPITULO 5

CONCLUSIONES Y PROPUESTAS

5.1. Conclusiones

Como se resumio al comienzo de la redaccion de este documento, el objetivoprincipal que se ha perseguido con este Trabajo Fin de Grado ha sido el de ofrecer,en un unico documento toda la base de conocimientos necesarios para iniciarse enla programacion de robots usando los frameworks que se han descrito.

Se ha comentado el estado actual del arte y las nociones basicas que todo desa-rrollador de robots autonomos debe conocer de antemano, como son los algoritmosmas usados y que conforman el pilar fundamental de cualquier robot de este tipo.En el mundo real, puede que muchas aplicaciones practicas cambien ligeramente, sibien la base seguira siendo la misma y resultara de gran ayuda antes de embarcarseen proyectos mas complejos y ambiciosos.

En cuanto a las tecnologıas, hay mucho camino por delante aun por hacer. Lomostrado es, posiblemente, solo una pincelada superficial de todo el potencial queaun se puede aprovechar de los frameworks. El camino no es sencillo, como se hapodido comprobar. Hay una enorme cantidad de informacion disponible, y el hechode que actualmente se siga trabajando con ellos, hace que esta informacion aumentey se expanda cada vez mas con el paso del tiempo para paliar las diferentes necesi-dades que le surgen a los desarrolladores en sus trabajos. Lo expuesto solo abarca,como se ha dicho, el pilar basico sobre el que asientan el resto de elementos, pero unpilar que consideramos extremadamente necesario y que se ha tratado de explicar

71

72 Capıtulo 5. CONCLUSIONES Y PROPUESTAS

concienzudamente para que los nuevos y futuros desarrolladores no se abrumenante tal ingente cantidad de informacion, fuentes y ejemplos. Desde el principio,nos costo bastante coger un punto de referencia sobre el que comenzar a trabajar.Si hemos logrado que alguien nuevo e interesado en el tema entienda lo que se haexpuesto y vea mas facil como funciona todo el sistema, podre decir que todo eltrabajo habra merecido la pena.

Hemos comprobado de primera mano lo que significa realmente trabajar en unproyecto de investigacion, donde tratar de descubrir cosas que nadie antes ha he-cho, ademas de ser un gran reto (de estar acostumbrado a tener documentos quehablen de todo a no tenerlos es un cambio, que cuanto menos podemos conside-rar como curioso de experimentar), supone un gran aliciente para seguir trabajandoduro cuando se logra. El punto mas complejo que surgio y que se comento con an-terioridad, fue trabajar con RoboComp y agregarle toda la funcionalidad de Ariapara su uso con los robots con que disponemos en el laboratorio. Se le han dedicadoincontables horas a la solucion de problemas tecnicos, algunos relacionados con lapuesta en marcha (y que se pueden leer en el Apendice B), y otras tantas mas alestudio de aplicaciones que aparentemente no entraban dentro del plan propuesto(como CMake). Otras tantas horas se han dedicado tambien a reparar los robots ysus S.O., lo que nos enseno la diferencia existente entre trabajar solamente con soft-ware a hacerlo tambien con hardware y lograr que funcionase. Ha sido todo un reto.

5.2. Trabajo futuro

Debido al tiempo y a que la mayorıa de los esfuerzos se han dedicado a com-prender los conceptos de Aria y RoboComp, han quedado fuera del tintero muchasotras cosas que se pueden llevar a cabo usando las bases proporcionadas.

Una de ellas serıa la creacion de un componente en RoboComp que sirva decliente y permita al usuario interactuar correctamente con el robot. Serıa interesanteimplementar alguno de los algoritmos de localizacion global usando este sistemadistribuido, de forma que por ejemplo, el servidor provea de las lecturas del laser alcolector de datos y el cliente las reciba para pasarselas a otro cliente encargado derealizar los calculos usando el filtro de particulas. Supone un caso de estudio muyconcreto y especializado, pero disponer de ese algoritmo en el repositorio puede re-sultar de gran ayuda a otros tantos desarrolladores. Como este ejemplo hay muchosotros relacionados con la implementacion de los algoritmos mas comunes, incluso

5.2 Trabajo futuro 73

la posiblidad de comprobar su comportamiento si se distribuyen los calculos entrevarias maquinas.

Otro aspecto relacionado con los vehıculos autonomos era la posibilidad de adap-tar los algoritmos para vehıculos aereos. En este trabajo solo se ha trabajado con losterrestres, ya que son los unicos de que disponemos. Si algun dia fuese posible tra-bajar con drones, seria interesante ver que cambios supone respecto a los terrestresy que capacidades ofrece, asi como el tipo de sensores tıpicos que utilizan, limita-ciones, etc.

En el capıtulo sobre el estado del arte se menciono que la Universidad de Pen-silvania estaba trabajando en la tecnologia de enjambre. Serıa interesante ver en elfuturo proyectos relacionados con ese tipo de sistemas multiagentes en comunidadusando robots (aereos o terrestres). Puede que aquı RoboComp ayude bastante gra-cias a su metodologıa de sistemas distribuidos.

Se puede ver que hay infinidad de ramas que yacen de la simple y sencilla temati-ca de los robots autonomos. En unos anos seguramente surgiran nuevas ideas gra-cias a la evolucion tecnologica y los cambios en las nuevas arquitecturas hardwareque hayan disponibles para entonces. Solo se han nombrado algunas en las que tam-bien nos habrıa gustado trabajar, pero casi seguro que a cualquiera interesado en eltema le surgiran otras muchas mas.

BIBLIOGRAFIA

[1] Biography of Karel Capek, 2014. http://en.wikipedia.org/wiki/

Karel_%C4%8Capek (consulta: Junio 2014).

[2] CMake Documentation, 2014. http://www.cmake.org/cmake/help/v3.0/(consulta: Junio 2014).

[3] Cesar Llamas Bello. Introduccion a los Agentes y Sistemas Multiagente. Universi-dad de Valladolid, 2000.

[4] Canal Historia. Robots de la antiguedad, 2008. http://

www.nuevoordenmundial.es/videos/canal-historia/

los-robots-de-la-antiguedad/ (consulta: Mayo 2014).

[5] Marco A. Gutierrez, Luis J. Manso y Pablo Bustos. Wiki RoboComp. Robo-Lab, 2014. http://sourceforge.net/p/robocomp/wiki/Home/ (con-sulta: Junio 2014).

[6] Nicolai M. Josuttis. The C++ Standar Library. 2012.

[7] M.A.Gutierrez, A.Romero-Garces, P.Bustos y J.Martinez. Progress in robo-comp. JOURNAL OF PHYSICAL AGENTS, 2013.

[8] MobileRobots. ACTS Advanced Color Tracking System User Manual, 2008.

[9] MobileRobots. ArNetworking Developer’s API Reference Manual, 2010.

[10] MobileRobots. ARIA Developer’s Reference Manual, 2012. http://robots.

mobilerobots.com/Aria/docs (consulta: Julio 2014).

[11] MobileRobots. Pioneer 3 Operations Manual, 2012.

75

http://en.wikipedia.org/wiki/Karel_%C4%8Capek

http://en.wikipedia.org/wiki/Karel_%C4%8Capek

http://www.cmake.org/cmake/help/v3.0/

http://www.nuevoordenmundial.es/videos/canal-historia/los-robots-de-la-antiguedad/



http://sourceforge.net/p/robocomp/wiki/Home/

http://robots.mobilerobots.com/Aria/docs

http://robots.mobilerobots.com/Aria/docs

76 BIBLIOGRAFIA

[12] MobileRobots. Getting Started with the ARNL Laser Navigation System, 2014.

[13] R.Siegwart y I.R.Nourbakhsh. Introduction to Autonomous MobileRobots. MITPress, 2004.

[14] Adrian Carrion Sanchez. La prohibicion de los robots militaresautonomos., 2013. http://www.mentenjambre.com/2013/04/

la-prohibicion-de-los-robots-militares.html (consulta: Julio2014).

[15] S.Thrun, W.Burgard y D.Fox. Probabilistic Robotics. MIT Press, 2003.

[16] Sebastian Thrun. Artificial Inteliligence for Robotics. Coursera, 2013. https:

//www.udacity.com/course/cs373 (consulta: Junio 2014).

[17] Kapil Vyas, Vangelis Metsis y Fillia Makedon. ARIA: Getting Started Quickly,2013.

[18] ZeroC. How to install Ice, 2014. http://download.zeroc.com/Ice/3.5/Ice-3.5.0-DEB_README (consulta: Julio 2014).

http://www.mentenjambre.com/2013/04/la-prohibicion-de-los-robots-militares.html

http://www.mentenjambre.com/2013/04/la-prohibicion-de-los-robots-militares.html

https://www.udacity.com/course/cs373

https://www.udacity.com/course/cs373

http://download.zeroc.com/Ice/3.5/Ice-3.5.0-DEB_README

http://download.zeroc.com/Ice/3.5/Ice-3.5.0-DEB_README

CONTENIDO DEL CD

En el contenido del CD que acompana a la memoria podemos encontrar los si-guientes recursos:

Memoria del trabajo en los formatos PDF y LATEX, dentro del directoriomemoria.

Codigos fuentes de los ejemplos creados con ARIA en el directorio fuentes.

Rama del repositorio de RoboComp que incluye las pruebas e implementaciondel componente ServerRobotComp en el directorio implementacion.

Paquetes necesarios para la instalacion de todo el software utilizado en la car-peta paquetes.

Algunos libros y documentos de la bibliografia que se encuentran disponiblesy que se han usado, como los manuales del robot. Disponibles en la carpetabibliograf ıa.

77

APENDICE A

Manual de usuario de Pioneer SDK

En las siguientes lıneas se explicara paso a paso todos los requisitos y accionesnecesarias para instalar el SDK, ası como para compilar programas basados en ARIAusando el compilador gcc y otras caracteristicas referentes al manejo de algunas apli-caciones.

A.1. Instalacion del SDK

A continuacion, se detalla el procedimiento, paso a paso, para poder instalar elSDK de los robots Pioneer correctamente bajo un sistema operativo Ubuntu 12.04 osuperior (en el laboratorio de Software 1 se dispone de la distribucion 13.04).

Los paquetes .deb que contienen todo el software utilizado vienen adjuntos alCD, en la carpeta paquetes, para poder instalarlos basta con hacer doble click so-bre los mismos, lo que hara que se abra elCentrodeSoftwaredeUbuntu. Acto seguidopinchar con el raton sobre el boton Instalar que aparecera arriba a la derecha.

Para que se instalen correctamente todas las librerıas, debe hacerse todo bajo unestricto orden de preferencia, siendo este:

libaria 2.8.0+ubuntu12+gcc4.6 amd64.deb

arnl-base 1.8.0+ubuntu12+gcc4.6 amd64.deb

libarnl 1.8.0+ubuntu12+gcc4.6 amd64.deb

79

80 Capıtulo A. Manual de usuario de Pioneer SDK

libsonarnl 1.8.0+ubuntu12+gcc4.6 amd64.deb

acts 2.3.0 i386.deb

sav 0.9-2 i386.deb

mobilesim 0.7.3+ubuntu12+gcc4.6 amd64.deb

mobileeyes 2.2.4-1 i386.deb

mapper3 2.2.5-1 i386.deb

Si la instalacion finaliza correctamente, en el directorio /usr/local/ localizare-mos los nuevos directorios que contienen las librerıas y aplicaciones recientementeinstaladas. Para ello ejecutar en una terminal el comando:

[ ] $ l s /user/ l o c a l

Deberan mostrarse las carpetas Aria, Arnl, SAV , Acts, MobileSim, Mapper3 yMobileEyes.

Es bastante probable que actualmente esten disponibles las ultimas versionesde dichos paquetes, ası como para sistemas Windows. Para descargarlas, visitarlos orıgenes del software, disponibles en http://robots.mobilerobots.com/

wiki/Software. El software privativo (como ARNL o ACTS) requiere de introdu-cir las credenciales pertinentes. Preguntar al encargado al mando de la asignaturade robotica para obtener informacion y acceso.

A.2. Compilar un programa basado en ARIA

La compilacion de un programa que use las librerias de Aria y ArNetworkingsigue las mismas pautas que compilar un programa en C++. Solo hay que incluircorrectamente las cabeceras al proyecto ası como enlazar las librerias en el linker delcompilador. El proceso mas sencillo y rapido consiste en usar los ficheros makefile.

Primero, creamos un directorio en cualquier lugar de nuestra carpeta Home, quecontendra los codigos fuente en formato .cpp y .h con el programa que usa Aria y/oArNetworking. A continuacion, creamos un nuevo fichero llamado makefile, sinextension. El contenido del fichero debe ser como el siguiente:

a l l : programCFLAGS=−fPIC −g −Wall

http://robots.mobilerobots.com/wiki/Software

http://robots.mobilerobots.com/wiki/Software

A.2 Compilar un programa basado en ARIA 81

ARIA INCLUDE=−I /usr/ l o c a l /Aria/includeARNET INCLUDE=−I /user/ l o c a l /Aria/ArNetworking/includeARIA LINK=−L/usr/ l o c a l /Aria/ l i b −lAr ia . . .

. . . − lArNetworking −lpthread − l d l

%: %.cpp$ (CXX) $ (CFLAGS) $ (ARIA INCLUDE) $ (ARNET INCLUDE ) . . .. . . $< −o $@ $ ( ARIA LINK )

Si nuestro programa no usase las librerıas ArNetworking, bastarıa con eliminarla variable ARNET INCLUDE del fichero.

Para realizar la compilacion, desde una terminal usamos el comando cd < ruta >

para movernos por el sistema de ficheros hasta acceder a la carpeta que contiene elproyecto y el makefile. Acto seguido ejecutamos:

[ ] $ make <nombre programa>

Donde nombre programa es el nombre del fichero .cpp principal de nuestro pro-grama. Si por ejemplo tuviesemos un fichero llamado laserConnector.cpp que fueseel fuente principal (el que contiene la funcion main()), deberiamos ejecutar:

[ ] $make laserConnector

Si no se producen errores, resultara un fichero ejecutable con el nombre laserConnector,que podremos ejecutar escribiendo:

[ ] $ ./ laserConnector <parametros>

Por supuesto, Aria puede ser igualmente usado en Eclipse o Code::Blocks sinproblemas. Solo bastarıa con anadir las librerıas de Aria localizadas en /usr/local/Aria/libe incluir los directorios include con las cabeceras de las mismas (ver makefile paraconocer las rutas). Es importante no olvidar anadir tampoco las librerıas de C++lpthread y ldl, requeridas por los manipuladores de hilos que utiliza Aria.

Por ejemplo, en Code::Blocks, debemos hacer click derecho sobre la carpeta delproyecto, pinchar sobre Build options, anadir a la pestana Searchdirectories >Compiler la ruta a los fuentes de Aria (/usr/local/Aria/include) y la corres-pondiente a los de ArNetworking (/usr/local/Aria/ArNetworking/include).A continuacion en la pestana Linker, anadir la ruta a las librerias, la cuales se en-cuentran en:

(/usr/local/Aria/lib)

82 Capıtulo A. Manual de usuario de Pioneer SDK

Por ultimo, en la pestana de Linker settings, anadir las palabrasAria,ArNetworking,pthread y dl.

A.3. Como usar el simulador MobileSim

A menudo es necesario realizar pruebas en el simulador antes de ejecutarlas so-bre el propio robot, en primer lugar por lo altamente susceptible que son los progra-mas a tener errores que puedan hacer que el robot se dane, o dane a terceros.

Para poder usarlo y probar nuestras aplicaciones de conexion, manipulacion desensores y demas, basta con ejecutarlo antes de lanzar cualquier otro programa oservidor (podemos probar tambien los accesos remotos, si se desea). Para ello, bastacon escribir en una Terminal lo siguiente:

[ ] $ cd /usr/ l o c a l /MobileSim[ ] $ ./ MobileSim −map <nombre mapa>.map −r <modelo> −p <puerto>

MobileSim admite diferentes parametros, aunque los mas usuados son el puerto(-p) de escucha con el que conectaremos al robot (por defecto es el 8101, asignadosa cada robot secuencialmente) y el modelo del robot (-r), que por defecto se cargariael modelo P3-DX (otra opcion seria escribiendo -r p3dx). Tambien es posible cargarlos parametros para otros robots usando el fichero de configuracion que los define,los cuales pueden encontrarse en /usr/local/Aria/params.

El mapa es necesario para simular el entorno en el que el robot se mueve. Real-mente no proporciona conocimiento alguno al propio robot, sino simplemente per-mite que en caso de usar la simulacion de un dispositivo laser, de las medidas comosi el robot fuese el real y estuviese en ese mapa.

Una vez iniciado nos aperecera una interfaz grafica con el escenario cargado y elrobot en la posicion (0, 0), listo para trabajar.

El resto de pasos para hacerlo funcionar sigue los mismos principios practicosexplicados en Aria y ArNetworking, usando la misma informacion, clases y meto-dos para moverlo y darle ordenes.

Como es de esperar, si queremos usar las librerıas de ArNetworking, tendre-mos que crear o lanzar un servidor que conecte con el robot simulado, igual que loharıamos con el robot real, y usar el mismo sistema cliente/servidor explicado en la

A.3 Como usar el simulador MobileSim 83

seccion 3.4 de este documento.

APENDICE B

Manual de usuario Robocomp

El siguiente manual no es sino la recopilacion de informacion que se ha obtenidoal tratar de instalar el framework en diferentes maquinas con diferentes especifica-ciones. Es posible, que de una version del SO a otra cambien algunas cosas, aunquelas bases para su correcta preparacion son las mismas. Todas los procedimientos sehan realizado bajo el S.O. Ubuntu 13.04, en todos los ordenadores disponibles, de launiversidad y privados.

B.1. Instalacion de RoboComp

El proceso de instalacion de RoboComp requiere previamente disponer de unacuenta con acceso al repositorio usado por los investigadores del I3A. Si bien, es-to no impide poder descargar una copia del repositorio (aunque sin privilegios deescritura). Se debe tener como mınimo 4GB de espacio libre en el disco duro y unabuena conexion ADSL para su descarga.

Para descargarlo, instalarlo y configurar el entorno de RoboComp es necesarioseguir los siguientes pasos:

Descargar el repositorio de Sourceforge, desde el siguiente enlace: http://sourceforge.net/p/robocomp/code/ci/master/tree/. Para ello po-demos usar Git, mediante el siguiente comando introducido en una terminal:

[ ] $ g i t c lone g i t :// g i t . code . s f . net/p/robocomp/coderobocomp−code

85

http://sourceforge.net/p/robocomp/code/ci/master/tree/

http://sourceforge.net/p/robocomp/code/ci/master/tree/

86 Capıtulo B. Manual de usuario Robocomp

Opcionalmente, si disponemos de una cuenta con privilegios, podemos usarla orden:

[ ] $ g i t c lonessh ://<usuario>@git . code . s f . net/p/robocomp/coderobocomp−code

Donde usuario se debe sustituir por el nombre de usuario de Sourceforge.

Una vez descargado el repositorio, debe quedar bajo nuestro propio Home unacarpeta llamada robocomp (/home/usuario/robocomp). Creamos entoncesun enlace simbolico en /home de la siguiente manera:

[ ] $ ln −s /home/<usuario> /home/robocomp

A partir de ahora, se podra acceder a robocomp desde cualquier cuenta deusuario que posea la maquina accediendo a la ruta /home/robocomp/robocomp.

Configuramos el entorno RoboComp ejecutando el script disponible en la car-peta robocomp/Tools:

[ ] $ cd robocomp/Tools[ ] $ chmod +x robocompInsta l ler . py[ ] $ python robocompInsta l ler . py

En la ventana que aparecera, pinchar en Next hasta que aparezca una pantallaque nos pregunte sobre que acciones queremos tomar. Seleccionamos las op-ciones Install required packages y Set environment variables.Pinchamos en Next y esperamos a que termine de descargarse todo.

Figura B.1: Configuracion del entorno Robocomp.

B.2 Instalacion y configuracion de DSLEditor 87

Antes de finalizar la configuracion, nos pedira que seleccionemos las variablesde entorno a anadir. Para nuestro proposito, solo nos es necesario indicar laruta donde tenemos el repositorio de RoboComp y donde se encuentran susejecutables. Para ello solo debemos marcar las opciones como se muestra en laFigura B.1.

Si todo ha funcionado correctamente, nuestro sistema deberıa tener ahora con-figuradas las variables de entorno y ser capaz de compilar nuevos modulos.

B.2. Instalacion y configuracion de DSLEditor

El editor DSL basado en Eclipse y necesario para poder programar y compilarnuestros modulos, ası como generar el codigo fuente usando los CDSL e IDSL no seencuentra disponible en una version compatible. Se hace necesario por tanto usarla version de 2006. Esta version viene incluıda en el CD, en un fichero comprimidollamado DSLEditor.

Para instalarlo, basta con descomprimirlo bajo la ruta robocomp/Tools, que-dando entonces la ruta completa:

/home/.../robocomp/Tools/RobocompDSL/DSLEditor

Para ejecutarlo y probar su funcionamiento, bastarıa con ejecutar los siguientescomandos en una Terminal:

[ ] $ cd robocomp/Tools/RobocompDSL/DSLEditor[ ] $ ./ DSLEditor

Acto seguido deberıa aparecer la interfaz de Eclipse como la mostrada en la Fi-gura B.2.


Figura B.2: Interfaz de DSLEditor.

Si no nos aparece la carpeta del proyecto, bastarıa con importarlo, para lo que hayque seleccionar la opcion Import de Eclipse y buscar la carpeta raız de RoboComp.Aparecera entonces la carpeta donde se almacenan los componentes que creamosası como una segunda carpeta con las interfaces IDSL.

En la seccion mas baja, se encontraran las vistas de las clases, modulos e inter-faces, las cuales deberıan listar todos los componentes que se vayan creando (lasversiones actualizadas del editor daban excepciones y no permitıan mostrar estoscontenidos, ası como tampoco compilar o generar codigo).

Y por ultimo, en la barra de herramientas, en la pestanaRoboComp se encuentranlos accesos directos para poder anadir CDSL/IDSL, generar los fuentes a partir delos anteriores y compilar nuestros modulos.

B.3. Compilando un modulo cliente/servidor

El proceso para compilar un modulo cliente/servidor en RoboComp se centraen seguir unos sencillos pasos:

Crear una carpeta donde se almacenara el componente.

Crear el fichero IDSL en la carpeta Interfaces/IDSL.

Crear el fichero CDSL importando los IDSL a usar y como los va usar.

Generar los fuentes de los CDSL.

Compilar el modulo tras implementar las funciones del SpecificWorker.

B.3 Compilando un modulo cliente/servidor 89

(Opcional) En caso de actualizar el IDSL, se debe volver a generar los fuentesy recompilar el modulo.

Veamos el proceso para crear un servidor que ofreza el servicio Suma(x,y) queretorna el valor de la suma de los parametros pasados x e y.

En primer lugar, creamos en la ramaComponents del proyecto una nueva carpetacon nuestro nombre. Quedara en el navegador del proyecto algo como robocomp>robocomp>Components>Usuario. En su interior se crearan dos carpetas mas. Enuna estara el modulo que implementara el servicio suma (servidor) y que sera llama-do ServerSumaComp (resulta de vital importancia anadir la cadena Comp, sino Ro-boComp no lo reconocera como componente) y en la otra, denominada ClientSumaComp,se encontrara el cliente que solicitara el servicio.

A continuacion creamos la interfaz IDSL, para lo cual vamos a la carpeta Interfaces>IDSLs del proyecto, hacemos click sobre la barra de herramientas en RoboComp yanadimos un nuevo IDSL. Como nuestro servicio es de sumas, lo llamaremos sim-plemente Suma.idsl. En su interior debemos anadir el codigo con el metodo quequeramos implementar:

module RoboCompSuma{i n t e r f a c e Suma{

i n t suma ( i n t x , i n t y ) ;} ;

} ;

Acto seguido, procedemos a crear los CDSL de los componentes que usaran es-ta interfaz. Para ello, en la carpeta donde estara el servidor del servicio anadimosun nuevo fichero CDSL (siguiendo los mismos pasos que para el IDSL). El nombreque tendra sera ServerSuma.cdsl. En su interior debemos importar la interfaz (ointerfaces que usara) ası como el tipo de relacion con la misma (puede ser de tipoimplements, subscribesTo, requieres, etc.):

import ”/robocomp/ I n t e r f a c e s /IDSLs/Suma . i d s l ” ;Component ServerSumaComp{

Communications{implements Suma ;

} ;language Cpp ;

} ;


Para el caso del cliente debemos hacer lo mismo, pero creando un CDSL llamadoClientSuma.cdsl:

import ”/robocomp/ I n t e r f a c e s /IDSLs/Suma . i d s l ” ;Component ServerSumaComp{

Communications{r e q u i r e s Suma ;

} ;language Cpp ;

} ;

Ahora deben crearse los fuentes para proceder a implementar tanto el servi-dor como el cliente. Para logar esto basta con tener visualizado (abierto) el fiche-ro CDSL del componente a compilar, y en la barra de tareas, seleccionar la opcionRoboComp>Generate Code. Tras una barra de carga, se indicara con un mensajeque nuestro codigo se ha generado con exito. Si refrescamos la carpeta del proyecto,veremos que efectivamente, se han creado nuevas carpetas y archivos dentro de ca-da componente. Podemos por tanto proceder a la implementacion de los mismos.

La implementacion del servidor es sencilla. Solo debemos editar el fuente lla-mado specificworker.cpp, dentro de la subcarpeta ServerSumaComp/src. Sivemos la parte baja, veremos que el esqueleto del metodo suma(x,y) esta listo paraser rellenado:

. . .I c e : : I n t Speci f icWorker : : sumar ( i n t x , i n t y ){

/ * Tu c o d i g o a q u ı * /return x+y ;

}. . .

En su interior, insertaremos el codigo que realiza la tarea de sumar. Con esto solonos queda compilar el modulo usando la opcion RoboComp>Compile Component.Cuando en la consola de Eclipse se indique que la compilacion fue un exito, tendre-mos listo el ejecutable de nuestro servidor.

Si deseamos agregar en el futuro mas servicios, primero debemos actualizar elIDSL, y posteriormente los CDSL, para lo cual deberemos repetir el proceso de ge-neracion de codigo. De todos los fuentes pre-generados, solo el specificworker no semodifica, por lo que deberemos anadir manualmente los nuevos metodos o cambiarlos existentes.

B.4 Solucion de problemas 91

El cliente, por su lado, debe implementar sus acciones en el metodo compute()de su specificworker.cpp. Para poder invocar al servicio suma, se debe codificar losiguiente:

. . .void Speci f icWorker : : compute ( ){

std : : cout<<”Suma : ”<< suma proxy−>sumar ( 1 , 1 ) <<”\n” ;}. . .

Esta implementacion es solo un ejemplo, y el unico resultado que obtendremossera que cada X tiempo se imprima por pantalla el resultado que el servidor nosdevuelva (en este caso siempre devolverıa 2).

Para poder ejecutar los componentes y comprobar su funcionamiento, basta conejecutar los .sh que se acaban de crear en la carpeta bin de cada uno. El servidortendra de nombre startServerSumaComp.sh, y el cliente startClientSumaComp.sh.

B.4. Solucion de problemas

En ciertos sistemas Ubuntu, sobre todo actualizados, pueden surgir ciertos con-flictos a la hora de configurar RoboComp y tratar de compilar cualquier componen-te que creemos. Algunos estan relacionados con la necesidad de tener que compilarciertas librerıas internas que usa RoboComp, mientras que otras estan relacionadascon las versiones antiguas de Ice y otras dependencias que pueden no seguir dispo-nibles en los repositorios oficiales de Ubuntu, surgiendo la necesidad de tener queinstalar las nuevas versiones manualmente.

Si al tratar de compilar un modulo surgen errores con Ice o cualquier otra de-pendencia externa. En la siguiente lista se muestran las dependencias cuya correctainstalacion en el equipo se deben revisar para que todo funcione sin problemas.

En la Tabla B.1, la columna de la izquierda muestra los paquetes que nuestroequipo debe tener instalados para que todo funcione correctamente. A la derecha,se indica el comando que debemos ejecutar para poder instalarlo. Algunos paquetesse pueden instalar simplemente usando el gestor de paquetes Synaptic y marcandolos paquetes (o subpaquetes) que conforman la dependencia, mientras que otros de-bemos de compilarlos manualmente (esto sucede si durante la ejecucion del script


Tabla B.1: Lista de dependencias de RoboComp.

Dependencia Como obtenerlocmake synapticqmatrix cmake robocomp/Classesinnermodel cmake robocomp/Classesqt4 synaptic: qt-sdk, qt assistant, qt creator, qt 4 designer, qt 4 inguistopenscenegraph apt-get install openscenegraphdoxygen synapticgsl synaptic: libgsl0-devblas synaptic: libopenblas-dev, libopenblas-base

de RoboComp algo no se realiza bien).

En el caso de tener problemas con Ice (actualmente el script no descarga la ver-sion 3.4, al estar disponible una mas actualizada), es necesario desinstalar antes cual-quier version existente (el gestor Synaptic es suficiente para eliminar el paquete) y acontinuacion instalar la version mas reciente siguiendo las intrucciones en la paginahttp://www.zeroc.com/ en caso de no estar aun disponible en el repositorio.Por si fuese de ayuda, se ha incluıdo la version 3.5.1 en la carpeta paquetes delCD. Su instalacion se realiza como cualquier otro paquete .deb.

http://www.zeroc.com/

Diseno de un sistema de conducci˜ on aut´ onoma´ para un robot...

Documents

Transcript of Diseno de un sistema de conducci˜ on aut´ onoma´ para un robot...