algoritmo de navegacion aut onoma basado en una … · 2014. 9. 11. · algoritmo de navegacion aut...

Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, ValenciaISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC)

ALGORITMO DE NAVEGACION AUTONOMA BASADOEN UNA ARQUITECTURA DISTRIBUIDA

A. Soriano, M. Valles, A. Valera, P. Albertosemail: {ansovi, mvalles, giuprog, pedro}ai2.upv.esInstituto de Automatica e Informatica Industrial

Universitat Politecnica de Valencia, Camino de Vera s/n, 46022 Valencia, Espana

Resumen

Este artıculo propone una solucion al problemade la navegacion autonoma basada en una arqui-tectura distribuida donde cada fase del algoritmoesta dividida en modulos independientes de soft-ware capaces de intercomunicarse entre sı para en-tre todos converger en una solucion global efectiva.Para ello, se expone en primer lugar una revisionde las subtareas de las que depende directamentela problematica de la navegacion autonoma, comoson la localizacion del robot, la correcta detecciondel entorno que lo rodea, la generacion de trayec-torias libres de obstaculos, etc., y a continuacionse describe el funcionamiento y la integracion dedichas tareas dentro del algoritmo propuesto. Porultimo, se describe la aplicacion del metodo sobreun entorno de simulacion 3D y posteriormente seexplican varias pruebas de navegacion autonomarealizadas sobre un robot movil Summit XL deconfiguracion diferencial, con resultados satisfac-torios.

Palabras clave: Navegacion autonoma, ar-quitecturas distribuidas, algoritmos modulares,robotica movil, simulacion, arquitecturas decontrol, sensorizacion de robots.

1 INTRODUCCION

Los avances en la tecnologıa informatica, en lascomunicaciones inalambricas y en las tecnologıasde sensorizacion estan originando un interes no-table en el campo emergente de la robotica y,en concreto, la mecatronica. Hace unos anos laproduccion y programacion de robots se centrabaen ofrecer un diseno robusto y cerrado donde elrobot cumpliera con exito la mision de realizaruna tarea especıfica y controlada. En los ultimosanos, existe un alto interes desde la comunidadinvestigadora por extender el uso de la roboticaa campos como la medicina ([12],[4]), la asisten-cia a personas ([3], [8]), las operaciones de rescate([9]), misiones en entornos peligrosos o inaccesi-bles por humanos ([15]), etc. Estas tareas se re-alizan normalmente en entornos no controlados,difıcilmente predecibles y que en ocasiones pueden

requerir la cooperacion entre sistemas robotizadospara alcanzar sus objetivos. Estos retos han origi-nado la aparicion de nuevas arquitecturas o mid-dlewares de control sobre robots que intentan ofre-cer la flexibilidad y adaptabilidad necesaria parapoder afrontar dichas situaciones.

Los middlewares de control de robots, tambienconocidos normalmente como ”Robotics SoftwareFrameworks” (RSFs), ofrecen un conjunto de he-rramientas genericas, ası como bibliotecas, contro-ladores y metodologıas o algoritmos, para facilitarla integracion y el desarrollo software de robots.A diferencia de la tradicional tendencia hacia unaprogramacion secuencial donde paso a paso se vanresolviendo las distintas fases que componen unobjetivo, en los ultimos anos, este tipo de arquitec-turas han evolucionado hacia una estructura cadavez mas modular [16]. Los sistemas modulares sonconsiderados sistemas distribuidos complejos for-mados por distintos modulos independientes querealizan distintas tareas como la integracion entreel hardware y el software ([1]). Los sensores, ac-tuadores y controladores del sistema se conviertenen instrumentos individualizados controlados porestos modulos que cooperan juntos para alcanzartareas especıficas. La estructura de estos sistemasfacilita su escalabilidad, reusabilidad, flexibilidady ademas permite la capacidad de interaccion conotros sistemas a traves de redes de comunicacionde una manera sencilla y transparente.

Por otro lado, la problematica de la navegacionautonoma de vehıculos es una de las areas masestudiadas dentro del campo de la robotica movily que ha sido ampliamente estudiada en la liter-atura ([10], [11]). Aplicaciones como la vigilanciade recintos a modo de centinelas, la supervision deinstalaciones de acceso peligroso para humanos,la exploracion de entornos hostiles o desconoci-dos, la busqueda de objetos de interes en escenar-ios peligrosos, etc., requieren dar solucion a esteproblema. La navegacion autonoma engloba dis-tintos subproblemas como son la localizacion cor-recta del vehıculo dentro de un escenario, la de-teccion del entorno que lo rodea, la planificacionde la trayectoria desde donde se encuentra hastael punto objetivo que desea alcanzar, la estrate-


gia de seguimiento de trayectoria escogida paraseguir el camino planificado, la evasion de los posi-bles obstaculos que se pueden interponer en sutrayectoria, etc. En la literatura, existen multitudde aproximaciones y proposiciones para resolverdichos problemas, sin embargo, llevar a cabo suimplementacion en robots reales de la maneratradicional o funcional, requiere constantes tra-ducciones de codigo segun el tipo de lenguaje so-portado por cada plataforma; ademas, de la con-stante modificacion del codigo segun las distintasopciones hardware o software disponibles.

El presente trabajo ofrece una solucion al prob-lema de la navegacion autonoma de robots movilesdesde un punto de vista modular basandose enel uso de una arquitectura distribuida. El docu-mento se organiza de la siguiente manera. Enla siguiente seccion se presentan las diferentesproblematicas que componen una estrategia denavegacion autonoma. A continuacion se describeel middleware de control y el algoritmo modulardesarrollado. En el cuarto apartado se define laplataforma robotica sobre la que se ha implemen-tado el algoritmo de navegacion ası como las prue-bas realizadas sobre la misma y, por ultimo, lasconclusiones.

2 NAVEGACION AUTONOMADE VEHICULOS

Se entiende por navegacion autonoma a la capaci-dad de un robot para desplazarse a traves de un es-cenario por sı solo. Historicamente la navegaciones uno de los campos que mas esfuerzos ha con-centrado dentro de la comunidad investigadora enrobotica y hoy en dıa es un area muy madurada.Para el caso concreto de la robotica movil, la prob-lematica del espacio de trabajo se reduce al plano2D por inherencia del sistema, puesto que el robotsolo es capaz de moverse en el plano XY. La pre-cision de un algoritmo de navegacion autonoma esdirectamente proporcional a la tasa de exito en laresolucion de las siguientes tareas:

Localizacion: Para que el robot se desplace deun lugar a otro es fundamental saber donde seencuentra en cada momento. La localizacion es elproceso por el cual el robot obtiene su posicion res-pecto a una referencia determinada. Es un temamuy estudiado en la literatura ([5], [7], [2], [13],[14]) y existen dos enfoques diferenciados: la lo-calizacion global y la localizacion local. La prin-cipal diferencia reside unicamente en la referenciade posicion sobre la que se localiza el robot. Lalocalizacion global pretende situar al robot den-tro de un espacio de coordenadas global normal-mente definido por un mapa del escenario dondese ha especificado un punto de referencia fijo. En

cambio la localizacion local utiliza como referen-cia la posicion del propio robot, es decir, mideel desplazamiento relativo a una posicion anteriorconocida sin tener en cuenta el sistema de coor-denadas del mundo. Las fuentes de informacionen las que se basan estas estrategias suelen partirde medidas u observaciones ofrecidas por sensoresinstalados en el propio robot como encoders enlas ruedas, sensores de ultrasonidos, camaras, sen-sores laser, etc. Para resolver esta problematica,existen muy diversas estrategias y metodologıassegun el numero y el tipo de sensores incorpora-dos en el robot.

Mapping o percepcion del entorno: Lametodologıa de percepcion del entorno (conocidanormalmente como Mapping) es tambien un as-pecto crıtico para la navegacion ya que esta li-gada estrechamente a las tareas de localizaciony planificacion. Normalmente la instrumentacionmas extendida para la percepcion del entorno sonsensores laser para el reconocimiento geometricodel entorno y camaras para la deteccion de bal-izas u objetos de interes. Existen tambien mul-titud de metodologıas que abordan esta tarea, enalgunos casos se trabaja sobre un mapa global pre-vio conocido y en otros se va construyendo poco apoco segun el robot recorre el escenario.

Planificacion de trayectorias: Esta tareatambien es conocida como path planning y re-quiere en la mayorıa de los casos, partir de unmapa conocido o al menos parcialmente conocidoy preferiblemente estatico. El problema a re-solver es encontrar un camino factible desde unpunto inicial del mapa a otro punto objetivo, evi-tando cualquier obstaculo que este situado en elcamino. Existen diversas estrategias para resolvereste problema como las busquedas basadas enmapas discretizados en cuadrıculas (Grid-BasedSearch), busquedas geometricas, algoritmos po-tenciales de atraccion y repulsion, etc.

Estrategias de seguimiento de trayectorias:Una vez que se obtiene la trayectoria del caminoque el robot debe seguir, es necesario realizar elcontrol de su seguimiento, y es esa la problematicaque abarca esta tarea. Partiendo de la posicion ac-tual donde se encuentra el robot, esta tarea debecalcular las acciones de control necesarias parahacer que el robot alcance la trayectoria planifi-cada y la siga fielmente hasta alcanzar el obje-tivo. Es una tarea que depende practicamentede todas las anteriormente descritas y que paraobtener buenos resultados debe tener en cuentaparametros como la configuracion del robot con elque se trabaja, su cinematica, la fiabilidad de lalocalizacion, etc. Entre las estrategias mas popu-lares del control de seguimiento de trayectorias se


encuentra la persecucion pura y el punto descen-tralizado.

La combinacion de las tareas descritas anterior-mente puede variar segun el tipo de algoritmo denavegacion que se desee implementar o segun losrecursos de instrumentacion o computacion de losque disponga el robot. Como muestra el grafico dela Figura 1, los algoritmos que combinan estrate-gias de localizacion y path planning, se agrupancon el termino de localizacion activa, los algorit-mos que utilizan unicamente el mapping o la de-teccion del entorno para resolver tareas de pathplanning se denominan algoritmos de exploraciony los algoritmos que se basan en la deteccion delentorno o mapping para localizarse se engloban enalgoritmos de SLAM (Simultaneous LocalizationAnd Mapping). Por ultimo tambien existe unaclase de algoritmos denominados SPLAM (Simul-taneous Planning Localization And Mapping) loscuales intentan combinan las estrategias de las tresareas para navegar de manera autonoma.

Figura 1: Relacion entre las distintas tareas denavegacion autonoma

El algoritmo que se presenta en este artıculo tienecomo objetivo ofrecer las tareas de las que dependela navegacion autonoma de robots moviles a modode modulos configurables, reutilizables, escalablese independientes que se comunican entre sı parallevar a cabo una tarea mas compleja como es lanavegacion autonoma.

3 ALGORITMO DISTRIBUIDODE NAVEGACIONAUTONOMA

En este apartado se describe el middleware decontrol utilizado para la implementacion del algo-ritmo ası como la descripcion del funcionamientoy la estructura del mismo.

3.1 MIDDLEWARE DECONTROL/SOFTWAREUTILIZADO

Entre los middlewares de control o RSFs masextendidos, ROS (Robotic Operating System)destaca por estar basado en una arquitectura dis-tribuida, completamente modular, y disponer deuna comunidad de desarrolladores muy activa.Comparte algunas caracterısticas de otros RSFcomo Player, YARP, Orocos, CARMEN, Orca,MOOS o Microsoft Robotics Studio. No obstante,ROS es un software de codigo totalmente abiertoque ofrece a cualquier desarrollador la posibilidadde compartir sus aportaciones con la comunidad.De ese modo los investigadores no estan reinven-tando la rueda constantemente, si no que puedenpartir sus investigaciones desde algoritmos que yahan sido probados y verificados. ROS soporta laprogramacion en C++, Python, Octave, LISP eincluso JAVA. Esta desarrollado bajo licencia Cre-ative Commons Attribution 3.0, lo que permite sulibre uso, distribucion y modificacion de todo elcodigo con la condicion de que se especifique siem-pre a los desarrolladores originales.

Los principales componentes de ROS son:

Nodo ROS Master: Se trata del proceso prin-cipal de la arquitectura. Es quien permite que losnodos se encuentren entre sı e intercambien men-sajes. Se podrıa decir que es la pizarra donde losnodos se registran y a la vez buscan lo que les hacefalta.

Nodos: Un nodo es el mınimo proceso decomputo de la arquitectura. Los nodos consti-tuyen los principales componentes del Frameworkde ROS. Dado su diseno modular, el sistema decontrol de un robot suele estar compuesto por di-versos nodos, donde cada uno lleva a cabo unafuncion concreta. Estos nodos se pueden escribirtanto en C++ como en Python utilizando las li-brerıas ofrecidas por ROS.

Topics: Los topics son el principal medio decomunicacion entre nodos de ROS. Unos no-dos pueden publicar mensajes mediante topics auna determinada frecuencia y otros nodos puedensuscribirse a dichos topics para recibirlos. De esamanera se establece una comunicacion asıncronade informacion entre nodos.

Servicios: Los servicios se encargan de lasinteracciones que no pueden resolverse mediantetopics. Tambien son publicados por nodos, sinembargo son sıncronos y responden a una comu-nicacion mediante eventos, es decir, de llamada yrespuesta.


Figura 2: Funcionamiento del protocolo de comu-nicacion de ROS

La figura 2 muestra un ejemplo de la estructuraque tiene una arquitectura en ROS formada porun ROS master y dos nodos (NodoA y NodoB).Cuando el NodoA se inicia, se registra en elROS Master y este anota el nombre del topicque publica (denominado bar en el ejemplo), suROS HOSTNAME (foo) que lo identifica como sifuera una IP unica y el puerto del nodo publicador(1234 en este caso). En el siguiente paso (1 en lafigura), el NodoB se inicia y se registra en el ROSMaster, solicitando ademas una suscripcion a untopic de nombre bar y el ROS Master le envıa elROS HOSTNAME y el puerto del nodo que lo pu-blica (paso 2). De esta manera el NodoB solicitauna conexion de tipo TCP al NodoA, quien re-sponde con el puerto de su servidor TCP (2345 ).Es entonces cuando el NodoB envıa una solicitudde conexion al servidor TCP y el NodoA la acepta,creandose de ese modo el canal de comunicaciondirecto entre los dos nodos. Como se puede obser-var el ROS Master gestiona tan solo el vınculo dela comunicacion pero despues ya no interviene amenos que se realice una consulta distinta. Es poreste motivo por el que una vez abierto el canal, siel ROS Master se cae, la comunicacion entre losdos nodos continua funcionando.

3.2 DESCRIPCION DEL ALGORITMO

Se han definido una serie de modulos de softwareorganizados concretamente en nodos del stack denavegacion de ROS [6]. Cada modulo (Fig. 3) seejecuta de forma independiente al resto, no ob-stante existe una serie de dependencias entre al-gunos modulos que les obliga a comunicarse entreellos para poder ofrecer resultados. Un moduloviene definido por una serie de entradas y sali-das. Las entradas se definen como suscripcionesa topics que ofrecen la informacion necesaria parael buen funcionamiento del modulo y las salidasofrecen la informacion resultante de la ejecuciondel modulo, por ejemplo mediante la publicacionde topics o servicios.

Figura 3: Descripcion general de la definicion deun modulo software.

En el nivel mas bajo del algoritmo, se encuentranlos modulos que gestionan los dispositivos hard-ware disponibles en el robot y que no requierenninguna informacion de entrada si no que se limi-tan a publicar las lecturas que ofrecen los disposi-tivos que gestionan. Para este trabajo es el casode los nodos del laser Hokuyo y el giroscopo queincorpora el robot. Uno publica las medidas dellaser por un topic llamado /scan y otro las medi-das del giro por /gyro.Un nivel por encima se encuentra el modulode control (denominado Controller) el cual de-pende estrictamente de su suscripcion al topic delgiroscopo para la deteccion de la velocidad angulardel robot. Mediante la lectura del topic del giro ya partir de la lectura de los sensores de efecto hallque tienen las ruedas, el nodo Controller ofreceuna primera odometrıa basica publicada por untopic llamado /Odom. Ademas es el modulo en-cargado de recibir las velocidades de referencia quedeben alcanzar las ruedas, implementando paraello un controlador PD. Para ofrecer ese servicio,el nodo se suscribe a un topic llamado /cmd por elcual deberan publicar aquellos nodos que deseenactuar sobre las ruedas.Una vez obtenida la odometrıa, es posible inte-grar el nodo Mapping el cual implementa unaestrategia basada en tecnicas de SLAM. Estenodo se suscribe a los topics /scan del nodoHokuyo y /Odom del Controller para publicartanto el mapa que va construyendo (/map) comola posicion global calculada dentro del mismo(/Global Odom). Para el manejo del robot porel escenario, se puede lanzar el nodo Mandoque gestiona la teleoperacion del robot medianteun mando inalambrico conectado vıa Bluetooth,el cual publica las velocidades deseadas por eltopic cmd recibido por el Controller. De estemodo, la estructura de los modulos que componeneste algoritmo de SLAM queda como se muestragraficamente a continuacion:

Figura 4: Interconexiones entre los modulos o no-dos que forman el algoritmo de SLAM.


Mediante este algoritmo es posible por ejemplo,realizar un mapa del escenario por donde el robotva a navegar de manera autonoma posteriormente.En la figura 5 se muestra el mapa resultante de lanavegacion teleoperada del robot Summit XL porel departamento.

Figura 5: Mapa del departamento ai2 realizadocon el algoritmo de SLAM.

Una vez conseguido el mapa estatico global pordonde el robot va a navegar, se lanza el nodoMap server que ofrece dicho mapa mediante supublicacion por un topic llamado /map. Estemapa global permite por ejemplo hacer uso de al-goritmos de localizacion activa como Montecarlo.El nodo de localizacion por Montecarlo recibe elnombre de Amcl y ademas de la suscripcion almapa global, tiene como entradas la suscripcional topic que ofrece la odometrıa (/Odom)y lasuscripcion al topic /scan que ofrece las medi-das del laser. El nodo Amcl implementa un fil-tro de partıculas basado en Montecarlo ofreciendocomo salida un vector con todas las posibles solu-ciones a la localizacion global del robot dentrodel mapa (topic /particles) y otra salida conuna unica posicion global del robot por el topic(/Amcl Pose), su mejor estimacion. La figura 6muestra la interaccion de los distintos modulos queparticipan para conseguir llevar a cabo la local-izacion.

Figura 6: Nodos que forman parte del algoritmode localizacion por Montecarlo.

Una vez obtenido el mapping del entorno y unabuena estimacion de la posicion global, el si-guiente paso es el desarrollo de un modulo depath planning que lea la posicion local o globaldel robot y dada una posicion destino calcule latrayectoria que debe seguir el robot para alcan-zar el objetivo. Para ello, se implementan losmodulos Local P lanner y Global P lanner, segun

si la navegacion es en base a un destino con coor-denadas globales o un destino relativo a la posicionlocal del robot. Estos modulos dependen cada unode su propio mapa de costes donde se especificanlos posibles obstaculos que debe tener en cuentael algoritmo para calcular la trayectoria. Estosmapas los generan los modulos Local Costmap yGlobal Costmap. Este ultimo se suscribe al topic/map ofrecido por el modulo Map server y altopic /scan ofrecido por el nodo Hokuyo parade ese modo publicar un mapa estatico de costesglobal por el topic /costmap global. A ese topicse suscribe el nodo Global P lanner para calcularuna trayectoria global libre de obstaculos hastaun objetivo determinado dentro del mapa. Dichatrayectoria la publica por el topic /global path, alcual esta suscrito el nodo Local P lanner. Comose ha comentado anteriormente, este nodo tienetambien su propio mapa de costes ofrecido porel modulo Local Costmap, que junto a las lec-turas del laser y de la odometrıa (topics /scany Odom), planifica la trayectoria local necesariapara alcanzar la trayectoria global, teniendo encuenta los obstaculos dinamicos que puedan serdetectados por el laser. El mismo planificadorlocal es quien finalmente manda las acciones decontrol necesarias al nodo Controller para queel robot siga finalmente la trayectoria calculada.Hay que tener en cuenta que la frecuencia deejecucion del nodo local siempre debe ser mayorque la del nodo global, ya que si no la evasionde obstaculos dinamicos no funcionarıa correcta-mente. Tambien es necesario configurar ciertosparametros de los planificadores como la distan-cia que se desea dejar como margen de seguridadrespecto a los obstaculos o la fiabilidad con la quedebe cenirse el planificador local al global. Lafigura 7 muestra la arquitectura que describe elalgoritmo de navegacion autonoma implementadoen el robot.

Figura 7: Comunicaciones entre los modulos delalgoritmo de navegacion autonoma.

Hay que tener en cuenta que gracias a la arqui-tectura modular, la navegacion autonoma no re-quiere necesariamente una posicion objetivo den-tro del mapa global. Es posible enviar la referenciade la posicion destino en relacion a la odometrıao a una posicion local, lo que permite al robotnavegar de manera autonoma pero sin tener encuenta la informacion global de los modulos. De lamisma manera es posible incorporar los algoritmos


de SLAM y localizacion de Montecarlo al algo-ritmo, obteniendo de esa manera tres estimacionesde posicionamiento distintas. El problema a lahora de implementarlo en el presente trabajo hasido que la capacidad de computo del robot no escapaz de ejecutar todos los modulos en el tiempocorrespondiente (los algoritmos de SLAM y Mon-tecarlo requieren mucha carga computacional) yse generan retardos que en ocasiones hacen el sis-tema inestable.

4 IMPLEMENTACION YPRUEBAS DEL ALGORITMO

El algoritmo de navegacion autonoma se ha imple-mentado en la plataforma robotica movil SummitXL, a la cual se le ha incorporado un sensor laserpara la deteccion del entorno. A continuacion sedescribe el hardware utilizado, su adaptacion alentorno de simulacion V-REP y los resultados delas pruebas realizadas en entornos reales.

4.1 SUMMIT XL CON LASERHOKUYO

Figura 8: Robot movil Summit XL con HokuyoURG-04LX-UG01

El robot Summit XL (Fig. 8) ha sido desar-rollado por la empresa Robotnik. Se trata deuna plataforma movil en configuracion diferen-cial basada en cuatro motores brushless indepen-dientes. Tiene un peso aproximado de 30Kg, so-porta una carga maxima de 20Kg adicionales, al-canza una velocidad maxima de 3m/s y tiene unaautonomıa de 180 minutos. Su cerebro se com-pone de una tarjeta mini ITX con un procesadorIntel Atom CPU N2800 a 1.86GHz, una memoriaDDR3 de 2GB y un disco duro de estado solido de128GB. Ofrece las conexiones tıpicas de una placamini ITX como son puertos USB, Ethernet, salidaVGA y HDMI e incorpora tambien un router con-figurado como punto de acceso para conectarse alrobot vıa WiFi. El sistema operativo que vienede fabrica es un Linux Ubuntu LTS. Ademas elrobot viene configurado de fabrica para ser inte-grado completamente en ROS. Ofreciendo tantolos modelos urdf y xacro del mismo para sus simu-

laciones en Gazebo o rviz, como los controladoresbasicos de odometrıa y teleoperacion.

Para la deteccion del entorno se ha integrado alrobot, un laser 2D modelo Hokuyo URG-04LX-UG01. Este dispositivo se situa entre los range-finder laser mas pequenos del mercado gracias aque pesa menos de 160 gramos y consume 2.5 va-tios. Esta especıficamente disenado para aplica-ciones de interior y permite medir hasta 5.6 metroscon un angulo de vision de 240o, ofreciendo unasmedidas fiables con una resolucion aproximada de0.352o. ROS ofrece un paquete para gestionar estemodelo de laser con cualquier plataforma, lo cualfacilita mucho su integracion.

4.1.1 Simulacion en V-REP

V-REP es un simulador 3D enfocado a la roboticaque esta basado en una arquitectura de controldistribuida, donde cada objeto o modelo puedeser controlado mediante un script embebido (em-bedded script), un plug-in, un nodo de ROS o uncliente API remoto en lenguajes como C/C++,Java, Python, Lua, Matlab o Urbi. Tambien per-mite la navegacion por el escenario a traves deluso del raton, haciendo posible visualizar la escenadesde cualquier sitio en cualquier momento de lasimulacion. Los modelos de los robots incluyencaracterısticas intrınsecas como la definicion desu cinematica, su peso, etc. V-REP incorporaalgunos modelos de robots ya programados conmetodos simulados de navegacion o de evasion decolisiones.

Figura 9: Planta, Alzado, Perfil y modelo 3D de-sarrollado del Summit XL con el laser.

Para la simulacion del Summit XL en V-REPfue necesario en primer lugar llevar a cabo elmodelado del robot en 3D (Fig. 9). Una vezse obtuvo el cuerpo y las ruedas, fue necesariodefinir y posicionar las juntas de revolucionque dan movimiento en V-REP. Se ensamblo almodelo una junta de revolucion por cada rueda,se acoplaron las ruedas al cuerpo, se recubrio el


modelo con primitivas invisibles para el calculode colisiones, se definio la cinematica y el pesode los elementos y por ultimo se agrego y sesituo el laser Hokuyo al modelo, cuyo modeladovenıa incluido en la biblioteca de modelos deV-REP. La figura 10 muestra el modeladoterminado en V-REP y en la siguiente direccionse puede ver un vıdeo de la simulacion: http:

//wks.gii.upv.es/cobami/webfm_send/225

Figura 10: A la izquierda se muestra la integracionde las juntas de revolucion en cada rueda. A laderecha, el modelo 3D simulado en V-REP.

Una de las principales motivaciones para utilizarel simulador V-REP en este trabajo es la facil in-tegracion con otros RSF, concretamente con ROS.La comunicacion entre ambos sistemas se realizamediante topics de ROS por los que se envıany reciben una serie de mensajes con unas carac-terısticas determinadas. Por ejemplo, en caso dequerer simular en V-REP el resultado de algorit-mos desarrollados en ROS para el robot real, elmodelo del Summit en V-REP se suscribirıa a lasvelocidades de las ruedas y las reproducirıa taly conforme lo harıa cada rueda del robot real.Ademas, tambien es posible trabajar a la inversa,es decir, desarrollar un algoritmo en V-REP quesea quien dicte por un topic de ROS las accionesde control que el robot real debe aplicar a cadarueda.

4.1.2 Pruebas con el Summit XL

Para la validacion del algoritmo de navegacion,se ha llevado a cabo su implementacion en elrobot Summit XL. Despues de diversas pruebasde navegacion local y global en el laboratorio, serealizo una prueba final en un garaje interior deautomoviles, con resultados satisfactorios. Paradicha prueba, primero se escaneo el garaje encuestion con un sensor laser 3D FARO Focus3Dcomo el que se muestra en la figura 11. Enel siguiente enlace se puede ver un vıdeo con elprocedimiento de captura y la malla de puntosobtenida finalmente: http://wks.gii.upv.es/

cobami/webfm_send/226

Debido a que el Summit XL unicamente lleva in-corporado un escaner laser 2D, la nube de pun-tos obtenida del garaje fue reducida a un mapa

Figura 11: Escaner 3D FARO Focus 3D utilizadopara el modelado del entorno del garaje.

2D cortando a la altura en la que se encuentrael laser. Los coches aparcados fueron elimina-dos del mapa puesto que se consideran obstaculosdinamicos que no deben tenerse en cuenta comomapa global estatico.Una vez obtenido el mapa global y situado el Sum-mit en el garaje, hubo que calibrar correctamentesu estimacion de posicion global dentro del mismo.Para ello se asigno una primera posicion orienta-tiva mediante el programa rviz y se utilizo el algo-ritmo de localizacion de Montecarlo para obteneruna posicion fiel a donde realmente se encontraba.Una vez bien localizado dentro del mapa global,se seleccionaron varias posiciones destino que elrobot tuvo que ir alcanzando evitando las coli-siones con los pilares y con los coches aparcadosque habıan en ese momento.

Figura 12: Captura de la ejecucion del algoritmode navegacion autonoma.

La figura 12 muestra un instante de la ejecuciondel algoritmo. Esta dividida en tres imagenes,la imagen de la izquierda se corresponde con larepresentacion en la interfaz de rviz donde semuestra el mapa global del garaje con paredes ypilares sobre el que esta representada la posiciondel robot, la zona de deteccion del mapa localde costes y la trayectoria global que debe seguirpara alcanzar el punto objetivo. Las imagenes dela derecha se corresponden a dos camaras, unaa bordo del Summit (imagen inferior) y otra ex-terna (superior), las cuales no intervienen paranada en el desarrollo del algoritmo, tal solo seusaron para registrar su correcto funcionamiento.La demostracion completa del experimento estadisponible en el siguiente enlace: http://wks.

gii.upv.es/cobami/webfm_send/157


5 CONCLUSIONES

Este artıculo presenta una solucion al problema dela navegacion autonoma aplicada concretamentepara robots moviles, basada en una arquitecturadistribuida. Las distintas tareas que componenel algoritmo de navegacion han sido individuali-zadas en formato de modulos software dotadosde cierta capacidad de comunicacion entre ellos,dotando al sistema de gran flexibilidad, escalabi-lidad y reusabilidad.

Se ha expuesto el desarrollo y la estructura dela arquitectura basada en el framework de pro-gramacion de robots ROS, describiendo las solu-ciones a los distintos problemas que engloba lanavegacion autonoma.

Por ultimo, se ha integrado el robot movil SummitXL en el software de visualizacion 3D V-REP parallevar a cabo pruebas de simulacion y verificacionde comportamientos. Ademas, una vez corrobo-rado el correcto funcionamiento del algoritmo ensimulacion, se ha implementado en la plataformareal Summit XL realizando varias pruebas en en-tornos interiores y obteniendo resultados satisfac-torios.

Agradecimientos

Los autores desean expresar su agradecimiento alMinisterio de Economıa y Competitividad Espanapor la financiacion parcial de este trabajo bajo losproyectos de investigacion DPI2011-28507-C02-01y DPI2013-44227-R.

Referencias

[1] B. Basso, B. Kehoe, and J. K. Hedrick. Amulti-level modularized system architecturefor mobile robotics. ASME 2010 DynamicSystems and Control Conference, 2010.

[2] P. Chand and D. A. Carnegie. Mapping andexploration in a hierarchical heterogeneousmulti-robot system using limited capabilityrobots. Robotics and Autonomous Systems,61:565–579, 2013.

[3] T. Kortner, A. Schmid, and D. Batko-Klein.How Social Robots Make Older Users ReallyFeel Well – A Method to Assess Users’ Con-cepts of a Social Robotic Assistant. SpringerBerlin Heidelberg, 2012.

[4] Lo, C. Albert, and Guarino. Robot-assistedtherapy for long-term upper-limb impair-ment after stroke. New England Journal ofMedicine, 362(19):1772–1783, 2010.

[5] I. Loevsky and I. Shimshoni. Reliable and ef-ficient landmark-based localization for mobile

robots. Robotics and Autonomous Systems,58:520–528, 2010.

[6] E. Marder–Eppstein. Ros navigation stack.http://wiki.ros.org/navigation, 2011.

[7] M. Mirkhani and R. Forsati. A novel effi-cient algorithm for mobile robot localization.Robotics and Autonomous Systems, 2013.

[8] T. Mukai and Hirano. Development of anursing-care assistant robot riba that can lifta human in its arms. In Intelligent Robots andSystems (IROS), 2010 IEEE/RSJ Interna-tional Conference on, pages 5996–6001, Oct2010.

[9] K. Nagatani and Kiribayashi. Redesign of res-cue mobile robot quince. In Safety, Security,and Rescue Robotics (SSRR), 2011 IEEE In-ternational Symposium on, pages 13–18, Nov2011.

[10] D. Nakhaeinia and S. H. Tang. A review ofcontrol architectures for autonomous naviga-tion of mobile robots. International Journalof Physical Sciences, pages 169–174, 2011.

[11] D. Sales, O. F., and D. Wolf. Topologi-cal autonomous navigation for mobile robotsin indoor environments using ann and fsm.In Proceedings of the I Brazilian Conferenceon Critical Embedded Systems (CBSEC), SaoCarlos, Brazil, 2011.

[12] T. Shibata. Therapeutic seal robot asbiofeedback medical device: Qualitative andquantitative evaluations of robot therapy indementia care. Proceedings of the IEEE,100(8):2527–2538, Aug 2012.

[13] R. Siegwart, I. R. Nourbakhsh, and D. Scara-muzza. Introduction to autonomous mobilerobots. The MIT Press, 2004.

[14] I. Skog and P. Handel. In-car positioning andnavigation technologies - a survey. Intelli-gent Transportation Systems, IEEE Transac-tions., 10:4–21, 2009.

[15] D. Toit, N.E., and J. Burdick. Robot mo-tion planning in dynamic, uncertain envi-ronments. Robotics, IEEE Transactions on,28(1):101–115, Feb 2012.

[16] M. von Essen and J. Hirvonen. Roboticsoftware frameworks and software componentmodels in the development of automated han-dling of individual natural fibers. J Micro-BioRobot, 2014.

algoritmo de navegacion aut onoma basado en una … · 2014. 9. 11. · algoritmo de navegacion aut...

Documents