8
TRANSPORTE DE PERSONAS CON VEH ´ ICULOS AUT ´ ONOMOS EN ENTORNOS URBANOS Luis Merino Universidad Pablo de Olavide, Crta. Utrera, km. 1, 41013 Sevilla, [email protected] Francisco Real, Pablo Soriano, An´ ıbal Ollero Universidad de Sevilla, Camino de los Descubrimientos, s/n, 41092, Sevilla, {psoriano,aollero}@cartuja.us.es Resumen El art´ ıculo presenta la arquitectura y algoritmos de navegaci´on de una coche el´ ectrico aut´onomo capaz de navegar en zonas peatonales urbanas para las tareas de transporte de personas y objetos. Se des- cribe fundamentalmente la arquitectura de nave- gaci´on,as´ ı como la integraci´on del veh´ ıculo en un sistema de robots en red, que provee al veh´ ıculo de autonom´ ıa operacional y le permite colaborar con otros robots y sensores en el entorno para realizar sus tareas. El art´ ıculo presenta resultados experi- mentales obtenidos en los experimentos finales del proyecto europeo URUS. Palabras clave: Robots urbanos, navegaci´ on, localizaci´ on. 1 INTRODUCCI ´ ON Muchas de las grandes ciudades europeas buscan reducir el tr´ afico en ciertas ´ areas, para as´ ı mitigar la poluci´ on ac´ ustica y ambiental, los atascos y, en definitiva, mejorar la calidad de vida. Para ello, ciertas tareas llevadas a cabo en dichas zonas por autom´ oviles podr´ ıan ser sustituidas por sistemas aut´ onomos. El proyecto europeo URUS [12] ha indagado en esta idea: la introducci´ on de robots de servicio urbanos. El presente art´ ıculo describe un veh´ ıculo aut´ onomo capaz de navegar en zonas peatonales para la tarea de transporte de personas (lo que denominamos misi´ on TAXI). El objetivo es que, bajo la petici´ on de una persona (a trav´ es de una interfaz en su tel´ efono m´ ovil), el veh´ ıculo sea capaz de recogerla en un determinado lugar y llevarla a un lugar distinto en la zona peatonal. Esta misi´ on involucra no olo el desarrollar una navegaci´ on aut´ onoma segura, sino tambi´ en gestionar la interacci´ on hombre-robot (la persona a bordo debe poder no s´ olo indicar el destino, sino tambi´ en parar o reiniciar el veh´ ıculo en cualquier momento). Adem´ as, el sistema desarro- llado en URUS permite al robot colaborar con otros robots y usar las redes de c´ amaras y otros sensores disponibles en el entorno urbano para Figura 1: Descripci´ on del escenario. Se trata de un cuadrado de unos 100 metros de lado. Hay complicaciones como rampas (c, d, j) y escaleras (h, i); y por supuesto hay gente habitualmente en el escenario. realizar las tareas correspondientes. Por ejemplo, las redes de c´ amaras se emplean para localizar a las personas para realizar ciertos servicios; o robots tipo humanoide pueden colaborar para guiar a las personas a las estaciones de taxi. El art´ ıculo se centra en la arquitectura y algorit- mos de navegaci´ on desarrollados para la tarea de transporte autom´ atico. Tambi´ en se describe la in- tegraci´ on de un veh´ ıculo aut´ onomo en la arquitec- tura URUS. Se presentan resultados experimen- tales en los que el veh´ ıculo realiza misiones TAXI en entornos peatonales. El escenario de dichos ex- perimentos se muestra en la Fig. 1. Este escenario presenta varios retos desde el punto de vista de la navegaci´ on, como es la presencia de peatones y la existencia de obst´ aculos como pendientes, es- caleras, ´ arboles y pasillos estrechos, as´ ı como la falta de cobertura GPS. Tras resumir algunos trabajos relacionados, el art´ ıculo describe someramente la arquitectura URUS para robots urbanos en la Secci´ on 2. A continuaci´ on, la Secci´ on 3 describe el veh´ ıculo con- siderado en este art´ ıculo. La Secci´ on 4 presenta los algoritmos de navegaci´ on y, finalmente, la Secci´ on 5 presenta los resultados experimentales previa- mente a las conclusiones.

TRANSPORTE DE PERSONAS CON VEH ICULOS ...robotics.upo.es/~lmercab/publications/papers/ja11romeo.pdftonom a del robot aportando una serie de m odulos de m as alto nivel. Los diferentes

  • Upload
    lebao

  • View
    212

  • Download
    0

Embed Size (px)

Citation preview

TRANSPORTE DE PERSONAS CON VEHICULOSAUTONOMOS EN ENTORNOS URBANOS

Luis MerinoUniversidad Pablo de Olavide, Crta. Utrera, km. 1, 41013 Sevilla, [email protected]

Francisco Real, Pablo Soriano, Anıbal OlleroUniversidad de Sevilla, Camino de los Descubrimientos, s/n, 41092, Sevilla, {psoriano,aollero}@cartuja.us.es

Resumen

El artıculo presenta la arquitectura y algoritmos denavegacion de una coche electrico autonomo capazde navegar en zonas peatonales urbanas para lastareas de transporte de personas y objetos. Se des-cribe fundamentalmente la arquitectura de nave-gacion, ası como la integracion del vehıculo en unsistema de robots en red, que provee al vehıculo deautonomıa operacional y le permite colaborar conotros robots y sensores en el entorno para realizarsus tareas. El artıculo presenta resultados experi-mentales obtenidos en los experimentos finales delproyecto europeo URUS.

Palabras clave: Robots urbanos, navegacion,localizacion.

1 INTRODUCCION

Muchas de las grandes ciudades europeas buscanreducir el trafico en ciertas areas, para ası mitigarla polucion acustica y ambiental, los atascos y, endefinitiva, mejorar la calidad de vida. Para ello,ciertas tareas llevadas a cabo en dichas zonas porautomoviles podrıan ser sustituidas por sistemasautonomos. El proyecto europeo URUS [12] haindagado en esta idea: la introduccion de robotsde servicio urbanos.

El presente artıculo describe un vehıculoautonomo capaz de navegar en zonas peatonalespara la tarea de transporte de personas (lo quedenominamos mision TAXI). El objetivo es que,bajo la peticion de una persona (a traves de unainterfaz en su telefono movil), el vehıculo seacapaz de recogerla en un determinado lugar yllevarla a un lugar distinto en la zona peatonal.Esta mision involucra no solo el desarrollaruna navegacion autonoma segura, sino tambiengestionar la interaccion hombre-robot (la personaa bordo debe poder no solo indicar el destino,sino tambien parar o reiniciar el vehıculo encualquier momento). Ademas, el sistema desarro-llado en URUS permite al robot colaborar conotros robots y usar las redes de camaras y otrossensores disponibles en el entorno urbano para

Figura 1: Descripcion del escenario. Se trata deun cuadrado de unos 100 metros de lado. Haycomplicaciones como rampas (c, d, j) y escaleras(h, i); y por supuesto hay gente habitualmente enel escenario.

realizar las tareas correspondientes. Por ejemplo,las redes de camaras se emplean para localizara las personas para realizar ciertos servicios; orobots tipo humanoide pueden colaborar paraguiar a las personas a las estaciones de taxi.

El artıculo se centra en la arquitectura y algorit-mos de navegacion desarrollados para la tarea detransporte automatico. Tambien se describe la in-tegracion de un vehıculo autonomo en la arquitec-tura URUS. Se presentan resultados experimen-tales en los que el vehıculo realiza misiones TAXIen entornos peatonales. El escenario de dichos ex-perimentos se muestra en la Fig. 1. Este escenariopresenta varios retos desde el punto de vista de lanavegacion, como es la presencia de peatones yla existencia de obstaculos como pendientes, es-caleras, arboles y pasillos estrechos, ası como lafalta de cobertura GPS.

Tras resumir algunos trabajos relacionados, elartıculo describe someramente la arquitecturaURUS para robots urbanos en la Seccion 2. Acontinuacion, la Seccion 3 describe el vehıculo con-siderado en este artıculo. La Seccion 4 presenta losalgoritmos de navegacion y, finalmente, la Seccion5 presenta los resultados experimentales previa-mente a las conclusiones.

1.1 TRABAJOS RELACIONADOS

Hay un interes creciente en el desarrollo devehıculos capaces de navegar autonomamente enzonas urbanas. Es bien conocido el DARPAUrban Challenge [1], cuyo objetivo es el desar-rollo de vehıculos inteligentes capaces de circu-lar autonomamente en ciudades, cumpliendo almismo tiempo con las reglas de circulacion. Laprincipal caracterıstica de las soluciones propues-tas es que normalmente se emplea equipamientomuy costoso, incluyendo GPS y sistemas inercialespara la localizacion; asimismo, no se considera lanavegacion en zonas peatonales. [13] muestra unejemplo de los vehıculos disenados.

El presente artıculo describe un robot para lanavegacion en areas peatonales para el transportede pasajeros. En [8], los autores muestran la arqui-tectura de navegacion de un robot para el TsukubaChallenge, competicion que requiere la navegacionen corredores peatonales durante 1 kilometro. Al-gunas conclusiones y decisiones de diseno en dichoartıculo son similares a las descritas aquı, aunqueotras son muy diferentes, como el uso de cober-tura de GPS diferencial. Ademas, la plataformaempleada es una plataforma diferencial.

Una de las mayores limitaciones en nuestro casoes que empleamos un vehıculo no-holonomo condireccion Ackermann. Un ejemplo de cochesautonomos es el Cycab [10]. La arquitec-tura de navegacion tiene semejanzas, emple-ando una combinacion probabilıstica de coman-dos de movimiento que son generados por distin-tos modos de navegacion (evitacion de obstaculos,seguimiento de caminos, etc). El robot empleamarcas artificiales para la localizacion. Sin em-bargo, si se busca la introduccion de robots enentornos urbanos es necesario desarrollar metodospara la localizacion que no impongan requerim-ientos en la infraestructura de la ciudad. En [3],los autores presentan tecnicas para el uso de la in-formacion en Sistemas de Informacion Geografica(SIG) para la localizacion de robots en entornosurbanos.

El SmarTer [5] es un Smart modificado parala navegacion autonoma en exteriores. En elproyecto URUS el robot ha sido adaptado paranavegar en zonas peatonales.

2 LA ARQUITECTURA URUS

La Figura 2 muestra los modulos de la arquitec-tura software desarrollada en URUS para robotsurbanos conectados en red con el entorno. La ar-quitectura fue disenada para poder integrar unconjunto de robots heterogeneos mediante lo que

Figura 2: La arquitectura de Romeo como unrobot URUS.

se denomina el protocolo URUS. La arquitecturaasume que cada robot a ser integrado es capaz deseguir caminos usando sus modulos propietarios.A partir de ahı, la arquitectura aumenta la au-tonomıa del robot aportando una serie de modulosde mas alto nivel.

Los diferentes componentes software han sido de-sarrollados por distintos miembros del proyecto, yse integran en los distintos robots usando una Ar-quitectura Orientada a Servicios (SOA). Algunode los modulos son:

• Un servicio de asignacion de tareas multi-robot [9].

• Un modulo de supervision a cargo de con-trolar las tareas que indica el modulo ante-rior. Para realizar eso, el supervisor es ca-paz de controlar el resto de servicios de la ar-quitectura a traves de una serie de interfacestambien definidas en el protocolo URUS.

• Un planificacion de caminos global basado enA∗ que determina los caminos para alcanzarlos destinos seleccionados y que es la inter-faz principal con los modulos propietarios denavegacion de cada robot.

• Una interfaz hombre-robot (HRI en sus siglasinglesas), que informa a las personas del es-tado del robot y que permite a las personasindicar comandos, expresar sus intenciones ycrear una nueva mision si es necesario.

• El servicio de comunicaciones permite alrobot comunicarse con otros robots y el restodel sistema. Este servicio monitoriza el nivelde senal de la conexion WiFi y es capaz decambiar a 3G en cualquier momento en quedicho nivel cae por debajo de un determinadoumbral.

Figura 3: Sensores a bordo de Romeo. Posee sen-sores para localizacion (GPS, girosocopos, cod-ificadores, laser Sick), percepcion del entorno ynavegacion (laseres).

• Un modulo de percepcion descentralizado[2, 12] que permite al robot mejorar supercepcion local combinandola con la infor-macion de otros robots y los sensores del en-torno.

3 DESCRIPCION DE ROMEO

Romeo es un coche electrico modificado consensores y actuadores para navegar de formaautonoma en escenarios en exteriores, incluyendoentornos urbanos.

3.1 HARDWARE

La Fig. 3 muestra el robot y los principales sen-sores que incorpora:

• Odometrıa: Romeo posee codificadores parala estimacion de la velocidad y la curvatura,giroscopos de KVH Industries y una unidadde medida inercial (IMU en sus siglas ingle-sas) para la estimacion de las velocidades an-gulares.

• Laseres: Romeo tiene un laser SICK LMS220 en la parte frontal, a 95 cm. de al-tura, para evitacion de colisiones y local-izacion. Ademas, posee dos laseres HokuyoURG-04LX (con un rango de 4 m.) en loslaterales para percibir obstaculos hacia los la-dos y hacia atras; y un laser Hokuyo UTM-30LX (con un rango de 30 m.) en el techo deRomeo, inclinado ligeramente para obteneruna percepcion 3D del entorno, como se veraen la seccion siguiente.

• Un receptor GPS diferencial de Novatel.

• Una camara de color firewire, que puede serempleada para seguimiento y guiado de per-sonas.

Figura 4: Arquitectura software basica de Romeo.

• Una pantalla tactil, que se emplea para con-trolar el robot y para interacciones hombre-robot.

Romeo tiene un motor electrico que actua sobreel volante, ademas del que actua sobre las ruedasde traccion. Los controladores de mas bajo nivelcierran los bucles con los codificadores, aceptandoreferencias en velocidad linear y curvatura para elvehıculo.

3.2 ARQUITECTURA SOFTWARE DEBAJO NIVEL

La Figura 4 muestra la arquitectura softwarebasica para la navegacion en entornos urbanos.Para la localizacion, Romeo fusiona todos sus sen-sores de odometrıa (codificadores, giroscopos eIMU) ası como la informacion obtenida con suslaseres mediante un filtro extendido de Kalman(modulo EKFLoc) para estimar su posicion y ori-entacion en 6D.

Para navegacion, Romeo combina la informacionde la localizacion con la de sus laseres para con-struir un modelo del entorno, basicamente unmapa de obstaculos: es decir, una malla en laque para cada celda se indica si puede ser atrav-esada por Romeo o no. Tambien permite iden-tificar obstaculos moviles. La informacion deeste modelo la emplea el modulo de evitacionde obstaculos (obstacle avoidance) para con-trolar el robot. La salida de este modulo escombinada con la salida del seguidor de caminos(path tracker) por un arbitro de comportamien-tos (arbiter), que asegura que no se producencolisiones mientras trata de seguir el camino indi-cado de la forma mas precisa posible.

4 NAVEGACION SEGURA DEBAJO NIVEL

Los modulos de navegacion de bajo nivel decualquier robot que quiera integrarse en el sistema

Figura 5: Cobertura GPS en el escenario con-siderado (mientras mas rojo mayor el numero desatelites). Notese que no solo la cobertura es lim-itada, sino que ademas el numero de satelites esbajo en la mayor parte del entorno.

URUS deben ser capaces de seguir caminos comocapacidad basica. Es decir, el robot debe ser capazde seguir un camino dado de la forma mas precisaposible, mientras evita obstaculos; la seguridad delos peatones es la prioridad principal.

4.1 LOCALIZACION

Para navegar en los escenarios considerados (Fig.Fig. 1) se necesita una localizacion en 6 gra-dos de libertad (posicion en 3 dimensiones y laorientacion en el espacio). El algoritmo em-pleado para esto es un filtro de Kalman exten-dido (EKF en sus siglas inglesas) que combinatoda la informacion disponible (giroscopos, IMU,codificadores, etc). El filtro emplea un modelocinematico del vehıculo, discretizado y linealizado,en cada paso de prediccion.

Si hay medidas GPS, el filtro, de forma au-tomatica, es capaz de estimar la orientacion re-lativa del robot con respecto al sistema de refe-rencia del GPS, y emplear sus medidas para can-celar la deriva. El principal problema es que elentorno considerado no dispone de una coberturaGPS fiable. Como muestra la Fig. 5, la coberturaGPS esta limitada a un area determinada del esce-nario. Ademas, el numero de satelites en tal areaes pequeno. Esto, unido a efectos multi-trayecto,imposibilita el uso del GPS (pues sus estimacionesestan normalmente afectadas por grandes saltos).

Por tanto, un sistema de localizacion basado enmapas se incorpora en el sistema. El algoritmo,descrito en [7], ha sido desarrollado por colegas dela Universidad Politecnica de Cataluna, e incor-porado en Romeo empleando el protocolo URUS.

Figura 6: Esquema de percepcion de obstaculos.Izquierda: las medidas de los laseres horizontalesse relacionan directamente con los obstaculos, yse incorporan directamente al mapa. Derecha: elanalisis del laser situado en el techo es hecho lıneaa lınea. La localizacion del robot se emplea paratrasladar los resultados a coordenadas globales.

Se trata de en un filtro de partıculas que empleala informacion del laser delantero y un mapa paraseguimiento de posicion, y es capaz de dar estima-ciones de la posicion con una frecuencia de 1Hz.Por tanto, aunque el algoritmo es suficientementepreciso para la localizacion a largo plazo, se nece-sitan estimaciones basadas en odometrıa para lanavegacion. La solucion final basada en EKF in-tegra la odometrıa a 40 Hz., e incorpora las correc-ciones del modulo de localizacion basado en ma-pas como un GPS virtual en el filtro. La Seccion5 mostrara los resultados de dicho sistema.

4.2 PERCEPCION 3D

El sistema de percepcion debe ser capaz de catego-rizar como obstaculo o zona navegable el terrenocircundante al robot, terreno que contiene elemen-tos como aceras, pendientes y caıdas desde dife-rentes niveles o escaleras. Estos elementos son,en el mejor de los casos, solo parcialmente ob-servable por los laseres horizontales. Al mismotiempo, es necesario tener en cuenta los obstaculosdinamicos.

El algoritmo de percepcion consta de dos niveles(ver Fig. 6). En primer lugar, cada laser en elvehıculo es analizado por separado para determi-nar los obstaculos de su zona de cobertura. A

Figura 7: Informacion 3D obtenida por Romeo a partir de sus laseres. Se puede identificar variosobstaculos. como escaleras (derecha), arboles y pequenos escalones (esta figura puede apreciarse mejoren la version electronica del artıculo).

continuacion, las medidas obtenidas por los dis-tintos laseres se combinan en un mapa global deocupacion de forma dinamica empleando un filtroBayesiano.

4.2.1 Analisis de los laseres horizontales

Las medidas procedentes de laseres con barridohorizontal se procesan del mismo modo: cadapunto del laser dentro del rango maximo del sen-sor se asume que es un obstaculo, y la lınea rectahacia el libre de obstaculos a la altura a la que seencuentra el laser.

4.2.2 Analisis del laser frontal superior

El laser 2D situado en el techo de Romeo (in-clinado hacia abajo, ver Fig. 6, derecha) es lafuente principal para la percepcion 3D del entorno.Dicho laser, combinado con la localizacion y elmovimiento de Romeo, actua como un laser debarrido 3D. Determinar si un punto correspondea un obstaculo o no a partir de la informacion deeste laser no es tan sencillo como en el caso an-terior, pues el mismo obtiene en cada instante uncorte 2D del entorno 3D.

En una primera aproximacion al problema, setrato de reconstruir la nube de puntos 3D com-binando los cortes 2D empleando informacion dela odometrıa. En ese caso, los obstaculos se calcu-lan empleando tecnicas de filtrado sobre la nube3D (por ejemplo, calculando la pendiente local encada punto). Esta aproximacion da buenos resul-tados en la mayor parte de los casos. Sin embargo,los experimentos mostraron que errores pequenosen la estimacion de la orientacion se amplificancon la distancia a los puntos, dando lugar a rugosi-dades en la nube 3D (sobre todo cuando el robotgira). Dichas rugosidades inducen obstaculos fan-tasma no existentes. En resumen, el principalproblema de esta aproximacion es que la coheren-cia del mapa depende en gran medida de la pre-

cision en la estimacion de la posicion (sobre todola orientacion).

La solucion adoptada finalmente depende enmenor medida de la localizacion. Cada medidadel laser (cada corte 2D) se procesa de forma in-dividual (ver Figura 6). La suposicion es queel suelo es una lınea aproximadamente horizon-tal situada delante del robot; por tanto, el suelose extrae de la medida laser mediante un ajustede mınimos cuadrados y empleando un algoritmoRANSAC modificado. La modificacion permitedefinir una funcion de probabilidad antes de la fasede muestreo de RANSAC, favoreciendo ciertas re-giones espaciales de busqueda.

Una vez el suelo es identificado, dos lıneas rectas seextraen a ambos lados del mismo. La continuidadde dichas lıneas con respecto al suelo es analizada,y si es ası, se consideran rampas. Los puntos dedichas rampas se consideran navegables si la pen-diente de la rampa es menor que un cierto umbral,y obstaculos en otro caso. Una vez determinadoslos obstaculos, se emplea la localizacion para ac-tualizar el mapa global.

Adicionalmente, la informacion de lıneas previasdel laser se emplea para determinar la fiabilidadde las medidas. En particular, se chequea la alturaestimada del suelo relativa al robot, cambiandoel estado interno a no confiable cuando el lasercasualmente incide en un muro o en otra superficieelevada. La Figura 7 muestra un ejemplo de loselementos clasificados como obstaculos a partir deun conjunto de medidas laser.

4.2.3 Mapa global de obstaculos

La informacion de todos los laseres se combina em-pleando la regla de Bayes. Sin embargo, al com-binar la informacion de los distintos laseres en elmapa, se tiene en cuenta la altura de cada medida.Se asume que los obstaculos surgen del suelo. Portanto, si se recibe una medida de espacio libre en

la celda (i, j) con una laser a una altura zm, dichamedida no modificara la clasificacion de esa celdacomo obstaculo si un obstaculo con altura z < zmfue previamente detectado en la misma celda.

4.3 CONTROL DEL ROBOT

El objetivo de control de los modulos de bajonivel es tratar de seguir el camino comandadode la forma mas fiel posible mientras se evitanlos obstaculos presentes (estaticos y dinamicos).Para ello, se emplea un modulo de arbitraje, ins-pirado por el trabajo desarrollado en [11], querecibe consignas de una serie de modulos de com-portamiento; en este caso, de los modulos deseguimiento de caminos y evitacion de colisiones.

Cada uno de estos modulos genera una deter-minada intencion sobre el espacio de actuacion.Dicha intencion se codifica como una serie de vo-tos {hc, hs}, cada voto un histograma normalizadosobre una variable de actuacion (en este caso,velocidad y curvatura). El modulo de arbitrajemantiene una copia de los histogramas que recibey los fusiona empleando una regla simple de mul-tiplicacion. El maximo del histograma resultantese elige como la actuacion a enviar a los motores.

4.3.1 Evitacion de colisiones

La evitacion de colisiones es especialmente com-plicada en el escenario, un campus universitarioprincipalmente disenado para peatones. Los pa-sillos estrechos y curvas pronunciadas pueden lle-var a situaciones de bloqueo para un vehıculo noholonomo (ver Fig. 1).

El algoritmo de evitacion reactiva tiene en cuentala cinematica del vehıculo, en lınea con la pro-puesta de Mınguez et al. [6]. Un laser virtual, gen-erado a partir del mapa global de obstaculos, dala distribucion de obstaculos alrededor de Romeo.Basado en dicha informacion, se calcula la dis-tancia d(τ) hasta el obstaculo mas cercano paracada curvatura τ (considerando trayectorias decurvatura constante). A cada curvatura se le aso-cia un peso dado por:

w(τ) =

0 d(τ) < dNEAR

1 d(τ) ≥ dFAR

f(d(τ)) otherwise

donde f(.) es una funcion monotona de la distan-cia entre 0 y 1. En el caso de regiones libres deobstaculos, se anade una campana a los pesos cen-trada en la curvatura media de dicha region, deforma que se priorizan las curvaturas situadas enel centro de las areas libres de obstaculos.

Los pesos, una vez normalizados, constituyen la

intencion de curvatura generada por el modulo deevitacion de obstaculos. La intencion en velocidadse modela como una distribucion normal, con sumedia proporcional a la cantidad de espacio libreque rodea al robot. Puesto que la seguridad tienela maxima prioridad, la velocidad se pone a 0 enel momento en que un obstaculo entra dentro deuna distancia de seguridad.

4.4 Seguimiento de caminos

Un algoritmo de persecucion pura adaptado ala aplicacion, descrito en [4], se emplea paraseguimiento de caminos. Los comandos dadospor dicho algoritmo se convierte en votos parael modulo de arbitraje situando una campanade Gauss con media dichos comandos y unadesviacion tıpica de modo que la campana cubrael rango admisible de controles.

5 RESULTADOSEXPERIMENTALES

Romeo ha participado en los experimentos finalesdel proyecto europeo URUS. Como se ha comen-tado, el rol principal de Romeo era el realizar mi-siones TAXI. En cada mision, el robot es requeridoa desplazarse hacia una estacion desde su posicionactual, donde un usuario es recogido. A contin-uacion, el usuario indica su destino y es llevadoallı. A lo largo del camino, el usuario puede parary reanudar la marcha del robot a traves de la in-terfaz HRI.

Aquı se resume uno de los experimentos. Esteconsiste en 4 misiones TAXI consecutivas. La lon-gitud total recorrida en el mismo es de 772 metros,y la duracion es de 34 minutos, sin ninguna inter-vencion externa. El experimento incluye 8 paradasy reanudaciones por los usuarios que estan siendotransportados, ası como la ejecucion de 25 trayec-torias distintas.

En relacion con la localizacion del robot en el ex-perimento, la Fig. 8 muestra los resultados. Latrayectoria consta de varios bucles. Puede obser-varse como la correccion basada en mapa permitemantener acotado el error de localizacion.

La Fig. 9 muestra algunos detalles del compor-tamiento del robot durante la navegacion. Puedeverse el camino realmente ejecutado frente alcamino indicado por el planificador. La presenciade desviaciones es previsible, pues el robot tieneque evitar peatones en su camino. La Fig. 10describe una vista de los obstaculos tıpica en otroexperimento. Un grupo de personas esta situadosobre el camino planificado, de forma que el robotevita dicho grupo ejecutando el camino de coste

Figura 8: Izquierda: posicion 2D estimada considerando solamente odometrıa (lınea discontınua roja) ycon la correccion basada en mapas (lınea contınua azul). Derecha: desviacion estandar de la estimacion.Las lıneas rectas son momentos donde el robot esta parado por solicitud del usuario o cuando una tareaa finalizado.

Figura 9: Trayectoria de referencia (cırculos) ycamino realmente ejecutado. Se incluye una vistade detalle. Las desviaciones se deben sobre todo alcomportamiento de evitacion. La mision involucrola ejecucion de 25 trayectorias distintas.

mınimo indicado por el arbitro.

A lo largo de la semana de experimentos, Romeose desplazo de modo totalmente autonomo masde 7 kilometros, con un tiempo de funcionamientoaproximado de 590 minutos. Durante los 2 ultimosdıas ejecuto toda la arquitectura descrita en laSeccion 3 y realizo 10 misiones completas. Ochode las misiones fueron totalmente exitosas, in-cluyendo la descrita mas arriba. Una mision nose completo debido a un fallo hardware en uno delos laser Hokuyo empleados. En la otra, el robotacabo en una situacion de bloqueo seguro al evitarun obstaculo de la que no pudo recuperarse debidoa las restricciones de maniobrabilidad del robot.

6 CONCLUSIONES

El presente artıculo ha presentado la arquitecturade un coche electrico para realizar servicios enzonas urbanas. Los algoritmos de bajo nivel hansido descritos. La arquitectura ha sido probadaen experimentos reales en los que se realizaron mi-siones de taxi, en las que un pasajero es trasladadoa un destino determinado.

Una de las principales conclusiones es la posibi-lidad que ofrecen coches electricos para las tar-eas propuestas. La arquitectura desarrollada esflexible para evitar el sobreajuste al escenario delproyecto. Si se busca la introduccion de robotsen entornos urbanos, estos deben imponer requer-imientos mınimos en la infraestructura disponible.El principal requerimiento de la arquitectura pre-sentada es un mapa para la localizacion del robot.

Una importante leccion aprendida esta rela-cionada con la actuacion de robots en entornoscompartidos con humanos. Tras algunos dıas deexperimentos, la mayorıa de la gente en el cam-pus se acostumbra a la presencia de los robots,

Figura 10: Mapa de obstaculos. Punteada en rojose muestra la trayectorıa ejecutada, frente a la re-querida (en azul). El robot debe evitar un grupode personas situadas en su camino.

sin preocuparse de sus acciones. Esto tiene quever con el modo en el que los robots se mueven.Romeo ha sido programado para moverse de formasuave, evitando maniobras agresivas. Parece claroque el uso de movimientos aceptables socialmentees necesario para la integracion de robots en en-tornos urbanos, lo que requerira el desarrollo denuevos algoritmos de planificacion.

Agradecimientos

Este trabajo ha sido parcialmente financiadopor el proyecto URUS (IST-2006-33579), de laComision Europea, y el proyecto Robotica Ubıcuaen Entornos Urbanos (P09-TIC-5121) financiadopor la Junta de Andalucıa. Los autores agrade-cen la colaboracion de todos los miembros delproyecto URUS durante los distintos experimen-tos en Barcelona.

Referencias

[1] Martin Buehler, Karl Iagnemma, and SanjivSingh. Editorial: Special Issue on the 2007DARPA Urban Challenge. Journal of FieldRobotics, 25(8):423–424, 2008.

[2] J. Capitan, L. Merino, F. Caballero, andA. Ollero. Delayed-state information filterfor decentralized tracking. In Proc. of theIEEE Intl. Conf. on Robotics and Automa-tion, ICRA, 2009.

[3] C.U. Droguer, A.B. Koku, and M. Dolen.Novel Solutions for Global Urban Localiza-tion. Robotics and Autonomous Systems,2009.

[4] F. Gomez-Bravo, D.A. Lopez, F. Real,L. Merino, and J.M. Matamoros. Integratedpath planning and tracking for autonomouscar-like vehicles maneuvering. In Proc. of the

6th Intl. Conf. on Informatics in Control, Au-tomation and Robotics, ICINCO, 2009.

[5] P. Lamon, S. Kolski, and R. Siegwart. TheSmartTer - a Vehicle for Fully AutonomousNavigation and Mapping in Outdoor Envi-ronments. In Proceedings of CLAWAR, 2006.

[6] J. Minguez, L. Montano, and J. Santos-Victor. Reactive navigation for non-holonomic robots using the ego kinematicspace, 2002.

[7] J. M. Mirats-Tur, C. Zinggerling, andA. Corominas-Murtra. Geographical infor-mation systems for map based navigationin urban environments. Robotics and Au-tonomous Systems, 57(9):922–930, 2009.

[8] Yoichi Morales, Alexander Carballo, EijiroTakeuchi, Atsushi Aburadani, and TakashiTsubouchi. Autonomous robot navigation inoutdoor cluttered pedestrian walkways. Jour-nal of Field Robotics, 26(8):609–635, 2009.

[9] Alejandro R. Mosteo and Luis Montano. Sim-ulated annealing for multi-robot hierarchi-cal task allocation with flexible constraintsand objective functions. In Workshop onNetwork Robot Systems: Toward intelligentrobotic systems integrated with environments,IROS, 2006.

[10] C. Pradalier, J. Hermosillo, C. Koike,C. Braillon, P. Bressiere, and C. Laugier.The Cycab: a car-like robot navigating au-tonomously and safely among pedestrians.Robotics and Autonomous Systems, 50(1):51–68, 2005.

[11] Julio Rosenblatt. Damn: A distributed ar-chitecture for mobile navigation - thesis sum-mary. In Journal of Experimental and Theo-retical Artificial Intelligence, pages 339–360.AAAI Press, 1995.

[12] A. Sanfeliu, J. Andrade-Cetto, M. Bar-bosa, R. Bowden, J. Capitan, A. Corominas,A. Gilbert, J. Illingworth, L. Merino, J.M.Mirats, P. Moreno, A. Ollero, J. Sequeira,and M.T.J. Spaan. Decentralized Sensor Fu-sion for Ubiquitous Networking Robotics inUrban Areas. Sensors, 10:2274–2314, 2010.

[13] Christopher Urmson et al. Autonomous driv-ing in urban environments: Boss and theurban challenge. Journal of Field Robotics,25(1):425–466, June 2008.