PROGRAMACI ON DE ROBOTS MOVILES

Jose M. Canas∗ Vicente Matellan∗ Rodrigo Mont ufar ∗∗,1

∗ Universidad Rey Juan Carlos, Mostoles, Espana∗∗ Inst. Nal. de Astrofısica,Optica y Electronica, Tonanzintla, Mexico

Resumen El objetivo de este tutorial es describir los entornos de programacion de robotsmoviles mas comunes en la actualidad, sus caracterısticas y las tendencias mas recientes.Actualmente el software de los robots moviles se estructura en tres niveles: sistema operativo,plataforma de desarrollo y aplicaciones concretas. Las plataformas de desarrollo han surgidolos ultimos anos con la idea de facilitar la construccion incremental de estas aplicacionesroboticas. Suelen ofrecer una interfaz uniforme de acceso al heterogeneo hardware de losrobots, una arquitectura software concreta y un conjunto de funcionalidades comunes listaspara su reutilizacion. c© 2004 CEA-IFAC

Keywords: Robot programming, autonomous mobile robots, software tools, programmingenvironments, simulators.

1. INTRODUCCION

Conseguir que los robots hagan cosasutiles autono-mamente es una tarea difıcil. Uno de los aspectosprincipales para ello es su programacion. Todos losrobots tienen sensores, actuadores y procesadores, yel software que se ejecuta en ellos es el que da lavida a esos componentes hardware, el que enlaza losdatos recibidos por los sensores con las respuestasde actuacion. Desde esta perspectiva, la generacionde comportamiento en un robot consiste en escribirel programa que al ejecutarse en el robotcausaesecomportamiento. La “autonomıa” y la “inteligencia”residen en ese programa. Por ejemplo, en los robotsmoviles el comportamiento principal es su movimien-to. Los programas que se ejecutan en el robot deter-minan la manera en queeste se mueve por el entorno,reaccionando ante obstaculos percibidos por los sen-sores, acercandose a algun destino, etc. y para ello tie-nen que enviar continuamente lasordenes adecuadasa los motores.

Muchos de los robots que se venden actualmenteson productos cerrados, programados por el fabrican-

1 Financiado parcialmente por la Agencia Espanola de Coopera-cion Internacional

te e inalterables, por ejemplo, la aspiradora roboticaRoomba de iRobot2 o en sus inicios3 . En contraste,otra parte relevante del mercado son los robots progra-mables, cuyos principales clientes son los centros deinvestigacion, normalmente interesados en programar-los ellos mismos. En estos casos, el fabricante vendelos robots con un software que permite su programa-cion por parte del usuario.

El modo en que se programan los robots ha ido evolu-cionando. Historicamente los robots eran desarrollosunicos, no se producıan en serie, y los programasde control se construıan empleando directamente losdriverspara acceder a los dispositivos sensoriales y deactuacion. Elsistema operativodel robot era mınimo,basicamente una coleccion dedriverscon rutinas paraleer datos de los sensores y enviar consignas a los ac-tuadores. En este contexto, el programa de aplicacionleıa las medidas obtenidas por los sensores y escribıalas ordenes de movimiento a los motores invocandodirectamente las funciones de la librerıa que ofrecıael fabricante en susdrivers. Como muestra la figura

2 http://www.irobot.com3 En el verano de 2002 Sony hizo publica la interfaz de progra-macion de sus perritos, Open-R, en parte forzados por unhackerla mascota robotica Aibo4 de Sony que habıa conseguido desvelaralgunas de sus interfaces

1(a), la aplicacion se situaba directamente encima delsistema operativo.

Hardware del robot

drivers

Aplicación

Hardware del robot

Aplicación

Plataformadesarrollo

Sistema Operativo

Figura 1. Programacion de robots: (a) sobredriversespecıficos de sensores y actuadores. (b) sobreuna plataforma de desarrollo

Con el asentamiento de los fabricantes, el trabajo demuchos grupos de investigacion y el paso de los anoshan ido apareciendoplataformas de desarrolloquesimplifican la programacion de aplicaciones roboti-cas. Estas plataformas ofrecen acceso mas sencillo asensores y actuadores, suelen incluir un modelo deprogramacion que establece una determinada orga-nizacion del software y permite manejar la crecien-te complejidad del codigo cuando se incrementa lafuncionalidad del robot. El disenador programa susaplicaciones roboticas finales sobre esa plataforma dedesarrollo, como muestra la figura 1(b).

En este tutorial pretendemos reflejar nuestra experien-cia de losultimos anos programando diferentes tiposde robots moviles, con diferentes entornos de progra-macion y en diferentes centros de investigacion, todoello con el objetivo de servir de punto de partida en latoma de decisiones en este contexto.

En la siguiente seccion abordamos las peculiaridadesde la programacion de robots moviles. En la tercerase describe el nivel basico: el hardware y los siste-mas operativos de robots. En la cuarta analizamos lasplataformas de desarrollo que han ido apareciendo losultimos anos y sus funciones. En la quinta se detallanalgunas de las plataformas concretas mas extendidas,y finalizamos con unas breves reflexiones en la seccionsexta a modo de conclusiones.

2. SOFTWARE DE ROBOTS

La mecanica de creacion de aplicaciones para robotsno difiere especialmente de la de aplicaciones en otrosambitos del software: El programador tiene que escri-bir la aplicacion en cierto lenguaje, compilar y enlazarsu codigo con las bibliotecas de la plataforma y/odel sistema operativo, y finalmente ejecutarla en loscomputadores a bordo del robot. Aunque la mecanicasea similar, las aplicaciones de robots moviles sı pre-sentan unos requisitos especıficos, como veremos acontinuacion, que condicionan las caracterısticas deesos programas.

Una caracterıstica comun a muchos robots es que tie-nen recursos computacionales y de almacenamientolimitados: carecen de disco duro, pantalla suficiente,etc. Por eso es normal que en esos casos se utilice elPC como entorno de desarrollo de aplicaciones y loscompiladores cruzados generen en el PC el programaejecutable que correra en el procesador a bordo del ro-bot. Esa ejecucion genera el comportamiento deseadocuando el robot se encuentra en el entorno adecuado.

2.1 Requisitos especıficos

Escribir programas para robots moviles es una tareacomplicada, ya que los robots son sistemas comple-jos. La programacion de robots moviles suele ser masexigente que la creacion de programas tradicionalescomo aplicaciones de ofimatica, bases de datos, etc.A continuacion se presentan algunos condicionantespropios, diferenciadores de otrosambitos del softwa-re.

1. Los programas de robots moviles estan directamen-te conectados a la realidad fısica, a traves de sensores yactuadores. Los sensores obtienen informacion de estarealidad y los actuadores la modifican. Esta situacionimplica que el software debe seragil, tomar decisio-nes con vivacidad para controlar correctamente a losactuadores. Por esta razon, se requiere de actuacion entiempo real, si no estricto, al menos blando.

2. Una aplicacion de robots moviles tıpicamente de-be estar pendiente de varias fuentes de actividad yobjetivos a la vez. El programa de un robot tieneque atender a muchas cosas simultaneamente: recogernuevos datos de varios sensores, refrescar la interfazgrafica, enviar periodicamente consignas a los moto-res, enviar o recibir datos por la red a otro proceso dela aplicacion, etc. Por ello estas aplicaciones suelen serconcurrentes, lo cual les anade cierta complejidad. Eneste sentido, los sistemas operativos para robots masavanzados incorporan mecanismos de multitarea y co-municacion interprocesos, permitiendo la distribucionde las tareas en diferentes hebras que se ejecutan con-currentemente, y una programacion modular que seadapta a la naturaleza de las aplicaciones de robotsmejor que la programacion estrictamente secuencial.

3. Otra cuestion relevante que deben contemplar lasaplicaciones que corren a bordo de los robots es suinterfaz grafica. Aunque la interfaz grafica no es in-dispensable para generar y materializar el compor-tamiento autonomo en el robot, normalmente resultamuy util como herramienta de depuracion. Ademasde las posibilidades de interaccion con el usuario, lainterfaz grafica permite la visualizacion en tiempo deejecucion de estructuras internas (e.g. representacio-nes del mundo, mapas, estados), las trazas y el analisisde variables internas del programa que pueden afectara la conducta observable del robot. El codigo de laaplicacion debera encargarse de actualizar esa interfazy de atender la interaccion con el usuario.

4. El software de robots es cada vez mas distribuido,tal y como apuntan Woo et al.(Wooet al., 2003).Es usual que las aplicaciones de robots tengan queestablecer alguna comunicacion con otros procesosejecutandose en la misma maquina o en una diferente.Si la aplicacion consiste en el comportamiento de ununico robot esta distribucion no es imprescindible,pero ofrece posibilidades ventajosas como ubicar lacarga computacional en nodos con mayor capacidado la visualizacion remota; y en sistemas multirrobot,hace posible la integracion sensorial, la centralizaciony la coordinacion.

5. Los programadores de robots se enfrentan a unacreciente heterogeneidad, en distintos sentidos, que di-ficulta su tarea. En cuanto al hardware, existe una grandiversidad de dispositivos sensoriales y de actuacion,ası como de interfaces, los cuales un programadordebe dominar si quiere escribir programas funciona-les para robots. En cuanto al software, las aplicacio-nes de robots no cuentan con un marco estable, nohay estandares abiertos que propicien la colaboracion(Utz et al., 2002; Montemerloet al., 2003; Cote etal., 2004), la reutilizacion de codigo y la integracion.En otros campos de la informatica hay bibliotecasque un programador puede emplear para construir supropio programa, ganando en fiabilidad y acortandoel tiempo de desarrollo. Por el contrario, en roboticacada aplicacion practicamente ha de construirse desdecero para cada robot concreto. No hay una base soliday firme para el desarrollo de nuevas aplicaciones quefavorezca la reusabilidad. Esa falta se debe en partea la heterogeneidad endemica en robotica, tanto enhardware como en software, y en parte a la inmadurezdel mercado de robots programables.

6. El conocimiento sobre como generar y descom-poner el comportamiento artificial es muy limitado.Como dividir el comportamiento de robots en unida-des basicas sigue siendo materia de investigacion, yno hay una guıa universalmente admitida sobre comoorganizar el codigo de las aplicaciones de robots paraque sea escalable y se puedan reutilizar sus partes.Cada desarrollador escribe su aplicacion combinandoad hoc los bloques de codigo que puedan existir en suentorno.

2.2 Lenguajes

En cuanto a los lenguajes que se emplean para pro-gramar robots, no hay diferencias significativas conlos utilizados en las aplicaciones informaticas tradi-cionales. Aunque han existido intentos de establecerlenguajes especıficos para programar robots, comoTask Description Language(TDL) (Simmons and Ap-felbaum, 1998) oReactive Action Packages(RAP)(Firby, 1994), no han sido nunca de uso general. Elobjetivo basico de estos lenguajes es incluir en lapropia sintaxis del lenguaje mecanismos que resultanventajosos para la programacion de robots, tales co-

mo la descomposicion de tareas, la monitorizacion deejecucion o la sincronizacion.

En los brazos robotizados industriales es frecuente eluso de lenguajes de bajo nivel, practicamente ensam-blador (Biggs and MacDonald, 2003) del microproce-sador de turno. Sin embargo, en los robots moviles laprogramacion con ensamblador ha desaparecido porel tamano y complejidad de su codigo. Ademas, lacreciente incorporacion del ordenador personal comoprocesador principal ha dado paso a toda suerte delenguajes de alto nivel: C, C++, JAVA, Python, etc.

La plataforma de desarrollo suele obligar a que lasaplicaciones se escriban en el lenguaje en que ellamisma esta programada, para que puedan accedera la funcionalidad ofrecida. No obstante, cada vezhay mas plataformas que no imponen un lengua-je determinado a las aplicaciones. Por ejemplo, enPlayer/Stage/Gazebo (PSG) (Gerkeyet al.,2003; Vaughanet al., 2003) la funcionalidad se ofrecea traves de mensajes de red a un servidor, la aplicacionpuede estar escrita en cualquier lenguaje siempre querespete el protocolo. Existen librerıas hechas en C,C++, Tcl, Python, Java y Common Lisp que encap-sulan ese dialogo en el cliente.

Sin duda los lenguajes mas utilizados en la progra-macion de robots son los basados en texto, por suflexibilidad y potencia expresiva. Sin embargo, unaexcepcion resenable es el lenguaje que incluye LEGOpara que los ninos programen sus robots RCX (Biggsand MacDonald, 2003). ElRCX-code es completa-mente visual y enel un programa consiste de unacolumna que se forma encadenando en secuencia blo-ques graficos que son instrucciones varias (de espera,actuacion, suma a una variable, etc). Incluye bloquesde condicion, con dos ramas salientes, que hacen avan-zar el flujo de programa por una de ellas, dependiendode la condicion sensorial. Se pueden incluir variascolumnas, a modo de hilos de ejecucion concurrentes.

Actualmente el lenguaje mas extendido para progra-mar robots es C. Este lenguaje supone un buen com-promiso entre potencia expresiva y rapidez. Comolenguaje compilado su eficiencia temporal es supe-rior a otros lenguajes interpretados. Hasta hace unosanos gran parte del software proporcionado por losfabricantes de robots estaba codificado en C, como laslibrerıas de Saphira con que se vendıan los robots deActivMedia, o el entorno de desarrollo de los robotsde RWI (RWI, 1999). Muchos robots pequenos se pro-graman en C, como el robot EyeBot (Braunl, 2003) yel robot LEGO RCX, que se puede programar con unavariante recortada de C llamada NQC (Baum, 2000).

Recientemente se puede observar un crecimiento enlos desarrollos y aplicaciones en C++. Por ejemplo, elentorno ARIA (ActivMedia, 2002) para programar ro-bots de ActivMedia, el entorno OPEN-R (Sony, 2003)de programacion del perrito Aibo de Sony, la platafor-ma Miro (Utzet al., 2002), Mobility (RWI, 1999), etc.

El principal avance sobre C es que proporciona la abs-traccion de orientacion objetos, con los mecanismosde herencia y polimorfismo asociados. Potencialmentetambien simplifica la reutilizacion de componentes.Una ventaja mas es que la portabilidad desde C a C++es relativamente sencilla.

2.3 Simuladores

Una herramienta particular, muyutil en la programa-cion de robots, son lossimuladores, los cuales ofrecenun entorno virtual en el que emulan las observacionesde los sensores y los efectos de lasordenes a los ac-tuadores. Sirven para evaluacion, depuracion y ajustedel programa de control antes de ser llevado al robotreal.

Los primeros simuladores eran poco realistas y alma-cenaban mundos planos donde habıa obstaculos estati-cos bidimensionales. Con los anos se ha ido ganan-do en realismo, incorporando ruido en los sensores yen las actuaciones. Hoy en dıa se tienen simuladorestridimensionales, como Gazebo5 (en la figura 2 sepuede observar un mundo simulado con Gazebo) yJMR (Lozano Ortegaet al., 2001), capaces de simularsensores tan complejos como la vision. En los simula-dores mas potentes se ha incluido tambien la capaci-dad de representar unconjuntode robots operando enel mismo escenario de modo simultaneo.

Figura 2. Simulador de robots Gazebo

Muchos fabricantes incluyen un simulador para susrobots (e.g.EyeSim para el robot EyeBot,Webotspara Kephera y Koala), aunque tambien existen mu-chos desarrollos libres (Stage , Gazebo , JMR, etc.).Los simuladores libres tratan de incluir soporte paralos robots de diversos fabricantes. La configuracionconcreta del conjunto de robots a simular, la disposi-cion y parametros de sus sensores se suele especificaren un fichero de configuracion. Dos de los simuladoresmas relevantes de hoy en dıa son elSRIsim 6 de KurtKonolige, que se emplea en los robots de ActivMediay los simuladoresStage y Gazebo de software libreorientados a multirrobot (Stage soporta 2D y colo-nias numerosas de robots, yGazebo soporta 3D).

5 http://playerstage.sourceforge.net6 http://www.ai.sri.com/˜konolige/saphira

3. SISTEMAS OPERATIVOS

Como mencionamos en la introduccion, la primeraopcion para el desarrollador de aplicaciones roboticasconsiste en escribir su codigo sobre la funcionalidadque le proporciona el sistema operativo encargado demanejar el hardware del robot. La mision principalde ese sistema operativo es ofrecer a los programasun acceso basico al hardware del robot, permitir sumanipulacion y uso desde los programas. Fundamen-talmente debe permitir recoger lecturas de los sensoresy enviarordenes a los actuadores incorporandodriversque dan soporte software de bajo nivel a los dispositi-vos fısicos.

En cuanto a la multitarea, los sistemas especıficosproporcionan librerıas que nos permiten la programa-cion con distintos procesos y/o con varias hebras, yasean con desalojo o sinel. Tambien suelen incluirmecanismos de comunicacion interprocesos como lamemoria compartida, las tuberıas (pipes), etc. y losrecursos tıpicos de concurrencia (como los semaforosy los monitores) para la sincronizacion, la evitacionde las condiciones de carrera y de los interbloqueos,la garantıa de exclusion mutua, etc.

El sistema operativo suele incluir tambien soporte parael hardware de comunicaciones (e.g. tarjetas de redinalambricas) y para los elementos de interaccion delrobot, ya sean botones fısicos, pantallas pequenas,pantallas de ordenador, etc. Este soporte permite lacreacion de interfaces graficas, lo que combinado conlas comunicaciones, puede facilitar la visualizacionremota en un ordenador externo.

3.1 Sistemas operativos dedicados y generalistas

Gran parte de los robots actuales incluyen sistemasoperativos de proposito especıfico. Sin embargo, des-de hace algun tiempo se ha extendido el uso de siste-mas operativos de proposito general, entendiendo porellos los que se utilizan en las computadoras persona-les, empleando en el robot bien ordenadores portatileso bien computadores de sobremesa empotrados. Elmotivo principal de su amplia aceptacion es sin dudasu ventajosa relacion prestaciones / precio.

Ası, los sistemas operativos de proposito general co-mo Linux o MS-Windows han entrado en el mundode los robots. Estos sistemas, ademas de losdriversdel hardware, incluyen abstracciones y un conjuntomuy extenso de bibliotecas genericas,utiles para laprogramacion de robots, tales como las bibliotecas einterfaces para la multitarea, las comunicaciones y lasinterfaces graficas.

A modo de ejemplo vamos a analizar en esta seccionun ejemplo de cada tipo de sistema operativo. Elsistema operativo ROBIOS (Braunl, 2003) en el robotEyeBot (figura 3) y GNU/Linux, el sistema operativo

de proposito general mas extendido en los centros deinvestigacion.

Figura 3. Robot EyeBot

ROBIOS ROBIOS es una muestra significativa desistema operativo dedicado. El robot EyeBot (Braunl,2003) es un robot de tamano pequeno equipado con unmicroprocesador Motorola 68332 a 35 MHz, al cual sele conectan dos motores conencoders, tres sensores deinfrarrojos y una camara digital. Su hardware tambienincluye una pequena pantalla, cuatro botones y unradioenlace. El sistema operativo permite la carga deprogramas a traves de un puerto serie y su ejecucionpulsando los botones. Como acceso basico al hardwa-re desde los programas, incluye una API (ApplicationProgramming Interface) con funciones para recogerlas lecturas de los sensores de infrarrojos, para obte-ner las imagenes de la camara y para hacer girar losmotores a cierta velocidad.

Ademas incluye dos funciones que le permiten enviary recibir bytes a traves de un radioenlace, a otrosEyeBots o un PC que se encuentren dentro del alcanceradio de su antena. En cuanto a la interfaz grafica, RO-BIOS incluye primitivas para muestrear si los botonesestan pulsados, pintar y refrescar la pantalla.

Con respecto a la multitarea, ROBIOS tiene primitivaspara crear hebras, detenerlas durante un tiempo, ma-tarlas, etc. Ofrece dos modos de repartir el tiempo deprocesador entre hebras: con desalojo (en rodajas detiempo) y sin desalojo (con un testigo que va pasando-se de una hebra a la siguiente), correspondientes a lashebras de kernel o de usuario tıpicas de sistemas ope-rativos tradicionales. Tambien ofrece semaforos paracoordinar la ejecucion concurrente de esas hebras y elacceso a variables compartidas.

GNU/Linux Un sistema operativo generalista que haganado gran aceptacion en la comunidad robotica esGNU/Linux (RWI, 1999; Gerkeyet al., 2003; Mon-temerloet al., 2003). Incluye un amplio abanico deherramientas de desarrollo, como el compilador deC/C++gcc , el editoremacs, etc.

En el ambito de la multitarea, la biblioteca mas usualesPthreadsque proporciona hebras POSIX de kernelque se pueden comunicar a traves de memoria com-partida. Pthreads tambien ofrece semaforos para con-

trolar el acceso a esas variables compartidas o resolverproblemas de concurrencia que puedan aparecer. Estosmecanismos se suman a los que ya ofrece GNU/Linuxcomo creacion de procesos, tuberıas,fifos , memo-ria mapeada, etc., que estan siempre disponibles.

El mecanismo de comunicaciones mas extendido enGNU/Linux son lossockets, que permiten la comuni-cacion intermaquina entre programas, una abstraccionque le permite olvidarse de los detalles de red, pro-tocolos de acceso al medio, etc. En concreto soportaIP para el nivel de red, y los protocolos del nivel detransporte TCP y UDP. De esta manera el programa-dor de la aplicacion no debe preocuparse de localizarla maquina destino, ni modificar su codigo cuando, porejemplo, el robot se conecta a la red por ethernet envez de usar red inalambrica.

GNU/Linux ofrece tambien multiples librerıas paracrear y manejar interfaces graficas conX-Window ,que es el sistema mas extendido en el mundo Unix.Encima de las librerıas basicas (Xlib o Xt ), queson flexibles pero complejas, GNU/Linux dispone devarias librerıas que simplifican el manejo de la interfazgrafica, comoQt , XForms , GTK, etc.

El potente soporte de GNU/Linux para la multitarea,las comunicaciones remotas y las bibliotecas graficasexistentes en ese entorno lo hacen un sistema ope-rativo muy relevante para las aplicaciones de robotsmoviles. En particular proporcionan herramientas efi-cientes y flexibles que permiten abordar conexito lanaturaleza concurrente, distribuida y la necesidad devisualizacion tıpicas de los programas para robots, talcomo vimos en la seccion 2.

Una de las desventajas del uso de GNU/Linux enrobotica es que no es un sistema operativo de tiemporeal, pues no permite acotar plazos. No ofrecega-rantıa de plazos (tiempo realduro) porque su sistemade planificacion de procesos no las asegura. En estesentido contrasta con sistemas operativos similarescomo QNX, o la variante RT-Linux. Sin embargo,GNU/Linux resulta lo suficientementeagil para losrequisitos de aplicaciones no crıticas. Por ejemplo,permite detener hebras durante milisegundos.

4. PLATAFORMAS DE DESARROLLO

Las aplicaciones con robots presentan cada vez mayorcomplejidad y ofrecen mayor funcionalidad. En mu-chos campos del software se ha ido implantandomidd-leware que simplifica el desarrollo de nuevas apli-caciones en esasareas. Estemiddlewareproporcionacontextos nıtidos, estructuras de datos predefinidas,bloques muy depurados de codigo de uso frecuente,protocolos estandar de comunicaciones, mecanismosde sincronizacion, etc. Del mismo modo, a medidaque el desarrollo de software para robots moviles haido madurando han ido apareciendo diferentes plata-formasmiddleware(Utz et al., 2002).

Hoy en dıa los fabricantes mas avanzados incluyenplataformas de desarrollo para simplificar a los usua-rios la programacion de sus robots. Por ejemplo, Ac-tivMedia ofrece la plataforma ARIA (ActivMedia,2002) para sus robots Pioneer, PeopleBot, etc.; iRo-bot ofrecıa Mobility (RWI, 1999) para sus B14 yB21; Evolution Robotics vende su plataforma ERSP;y Sony ofrece OPEN-R (Martın et al., 2004) para susAibo.

Ademas de los fabricantes, muchos grupos de inves-tigacion han creado sus propias plataformas de de-sarrollo. Varios ejemplos son la suite de navegacionCARMEN7 (Montemerloet al., 2003) de CarnegieMellon University, Orocos (Bruyninckx, 2001), PSG(Gerkeyet al., 2003), Miro (Utzet al., 2002), JDE(Canas and Matellan, 2002), etc. Tal como ocurre conlos simuladores, mientras los fabricantes buscan quesu plataforma sirva para sus modelos, los grupos deinvestigacion aspiran a una mayor universalidad y susplataformas tratan de incluir soporte para los robots desus laboratorios, tıpicamente de diferentes fabricantes.

El objetivo fundamental de estas plataformas es hacermas sencilla la creacion de aplicaciones para robots.Hemos identificado varias caracterısticas que estasplataformas presentan para lograrlo: uniforman y sim-plifican el acceso al hardware, ofrecen una arquitec-tura software concreta y proporcionan un conjunto debibliotecas o modulos con funciones de uso comun enrobotica que el cliente puede reutilizar para programarsus propias aplicaciones.

4.1 Abstraccion del hardware

Normalmente las plataformas ofrecen un acceso asensores y actuadores mas abstracto y simple que elproporcionado por el sistema operativo. Por ejemplo,si se dispone de un robot Pioneer equipado con unsensor laser SICK, la aplicacion puede acceder a susmedidas a traves de las funciones de la plataformaARIA o pedirlas y recogerlas directamente a traves delpuerto serie. Utilizando ARIA basta invocar un meto-do sobre cierto objeto de una clase y la plataforma seencargara de mantener actualizadas las variables conlas lecturas. Utilizando solo el sistema operativo, laaplicacion debe solicitar y recoger periodicamente laslecturas al sensor laser a traves del puerto serie, y debeconocer el protocolo del dispositivo para componer yanalizar correctamente esos mensajes de bajo nivel.

El acceso abstracto tambien se ofrece para los actua-dores. Por ejemplo, en vez de ofrecer comandos develocidad para cada una de las dos ruedas motrices deun robot Pioneer, la plataforma Miro (Utzet al., 2002)ofrece una sencilla interfaz de V-W (velocidad detraccion y de giro) para la actuacion motriz, la cualse encarga de hacer las transformaciones oportunas,de enviar a cada rueda las consignas necesarias para

7 http://www-2.cs.cmu.edu/˜carmen

que el robot consiga esas velocidades comandadas detraccion y de giro.

Hattig et al. (Hattiget al., 2003) apuntan que la uni-formidad en el acceso al hardware es el primer pasopara favorecer la reutilizacion de software dentro dela robotica. Esta caracterıstica esta presente en variasplataformas, aunque cada una lo hace a su manera. Enla plataformaERSPde Evolution Robotics (figura 4)el acceso al bajo nivel recibe el nombre deHard-ware Abstraction Layer(HAL), y en Miro, ServiceLayer. En OPEN-R, en Mobility y enARIA la APIde acceso a los sensores y actuadores viene dada porlos metodos de un conjunto objetos. EnJDE (Canasand Matellan, 2002) y en PSG el acceso abstracto alhardware lo marca un protocolo entre las aplicacionesy los servidores, con vocacion de estandar.

4.2 Arquitectura software

La arquitectura software de la plataforma de desarrollofija la manera concreta en la que el codigo de laaplicacion debe acceder a las medidas de los sensores,ordenar a los motores, o utilizar una funcionalidad yadesarrollada.

Existen muchas alternativas de software para ello: lla-mar a funciones de biblioteca, leer variables, invo-car metodos de objetos, enviar mensajes por la red aservidores, etc. Por ejemplo, la plataforma CARMEN(Montemerloet al., 2003) presenta interfaces funcio-nales, Miro usa la invocacion de metodos de objetosdistribuidos, TCA (Simmons and Apfelbaum, 1998)requiere del paso de mensajes entre distintos modulos,JDE requiere la activacion de procesos y la lectura oescritura de variables. Esta apariencia de las interfacesdepende de como se encapsule en cada plataforma lafuncionalidad ya desarrollada.

Al escribirse dentro de la arquitectura software de laplataforma, el programa de la aplicacion adopta unaorganizacion concreta. Ası, se puede plantear comouna coleccion de objetos (p.e. en OPEN-R), como unconjunto de modulos dialogando a traves de la red(p.e. en TCA), como un proceso iterativo llamandoa funciones, etc. Esta organizacion esta influida porla arquitectura cognitiva, y supone un modelo de pro-gramacion. Hay plataformas muy cerradas, que obli-gan estrictamente a cierto modelo. Por ejemplo, enla plataforma RAI (RWI, 1999) los clientes han deescribirse forzosamente como un conjunto de modulosRAI (hebras sin desalojo), con ejecucion basada eniteraciones. Otras arquitecturas software son delibera-damente abiertas, restringen lo mınimo, como PSG oCARMEN.

Las arquitecturas software de las plataformas masavanzadas establecen mecanismos concretos para quela aplicacion se pueda distribuir en varias unidadesconcurrentes. El mecanismo multitarea que ofrece laplataforma envuelve y simplifica la interfaz del kernel

subyacente para la multiprogramacion, en la cual seapoyan siempre. Al igual que ocurre con la interfazabstracta de acceso al hardware, la interfaz abstractade multitarea facilita la portabilidad.

Figura 4. Modulos de navegacion, vision e interaccionen la plataforma ERSPc©

4.3 Funcionalidades de uso comun

Ademas de las librerıas sencillas de apoyo, como fil-tros de color y demas, estas funcionalidades englobantecnicas relativamente maduras, ya sea de percepciono de algoritmos de control: localizacion, navegacionlocal segura, navegacion global, seguimiento de perso-nas, habilidades sociales, construccion de mapas, etc.

La ventaja de integrarlas en la plataforma es que elusuario puede reutilizarlas, enteras o por partes, locual permite acortar los tiempos de desarrollo y re-ducir el esfuerzo de programacion necesario para te-ner una aplicacion. Al incluir funcionalidad comun, eldesarrollador no tiene que repetir ese trabajo y puedeconstruir su programa reutilizandolas, concentrandoseen los aspectos especıficos de su aplicacion. Ademas,suele estar muy probada, lo cual disminuye el numerode errores en el programa final.

La forma concreta en que se reutilizan las funcionali-dades depende nuevamente de la arquitectura softwarey de como se encapsulen en ella: modulos, objetosdistribuidos, objetos locales, funciones, etc.

Los fabricantes suelen vender esas funcionalidadespor separado o incluirlas como valor anadido de supropia plataforma. Por ejemplo, la plataforma ERSP(figura 4) incluye tres paquetes en su arquitecturabasica: uno de interaccion, otro de navegacion y otrode vision. En el modulo de interaccion se incluye elreconocimiento del habla y la sıntesis de voz, parainteractuar de modo verbal con su robot. En el modulode navegacion se incluye la construccion automaticade mapas, la localizacion en ellos y su utilizacion paraplanificar trayectorias.

4.4 Arquitectura cognitiva

Se denominaarquitectura cognitivade un robot a laorganizacion de sus capacidades sensoriales y de ac-

tuacion para generar un repertorio de comportamien-tos. Para comportamientos simples casi cualquier or-ganizacion resulta valida, pero para comportamientoscomplejos se hace patente la necesidad de una buenaorganizacion cognitiva. De hecho, puede llegar a serun factor crıtico: con una buena organizacion sı sepueden generar ciertos comportamientos y con unamala no, fundamentalmente porque se tiene un codigofragil y la complejidad se vuelve inmanejable. En lacomunidad robotica han surgido a lo largo de su his-toria diversas escuelas cognitivas o paradigmas paraorientar la organizacion del sistema en esos casos.

Mas alla de la interfaz estable que proporcionan lasplataformas para el acceso a un hardware diverso, laestandarizacion del comportamiento artificial, su di-vision en unidades reutilizables, es una cuestion muycomplicada. Hattig et al.(Hattiget al., 2003) opinanque aun es demasiado pronto para buscar estandaresen el modo de generar comportamientos. Recomien-dan cenir por ahora la estandarizacion al acceso alos sensores y actuadores, a lo que ellos denominan“bloques constituyentes”.

La relacion entre las arquitecturas cognitivas y lasde software es multiple. Las arquitecturas cognitivasse materializan en alguna arquitectura software, demanera que los comportamientos generados siguiendocierto paradigma acaban implementandose con algunprograma concreto. De hecho, las propuestas cogniti-vas mas fiables cuentan con implementaciones practi-cas relevantes en arquitecturas software concretas: de-liberativas (e.g. SOAR), hıbridas (e.g. TCA (Simmonsand Apfelbaum, 1998), Saphira, etc.), basadas en com-portamientos (subsuncion, JDE, etc.), etc. Una buenaarquitectura cognitiva favorece la escalabilidad de laplataforma.

Hay plataformas software debajo de las cuales sub-yace un modelo cognitivo, pero tambien hay otras enlas que no. No obstante, unas arquitecturas softwarecuadran mejor con ciertas escuelas cognitivas que conotras. Los sistemas deliberativos clasicos cuadran conla programacion logica, con una descomposicion fun-cional en bibliotecas (modulos especialistas) y con lasaplicaciones monohilo con un solo flujo iterativo decontrol (sensar-modelar-planificar-actuar). Por el con-trario, los sistemas basados en comportamientos cua-dran mejor con la programacion concurrente, donde setienen varios procesos funcionando en paralelo y quecolaboran al funcionamiento global. Resulta naturalasimilar cada unidad de comportamiento al conceptosoftware de proceso, o incluso al de objeto activo.

4.5 Plataformas de software libre

Como ya hemos comentado, existen plataformas dedesarrollo creadas por los fabricantes de robots y otrascreadas por grupos de investigacion. La mayorıa deestasultimas se publican con licencia de software

libre, con la idea de contribuir al libre intercambiode conocimiento en elarea y con ello al avance de ladisciplina robotica.

Player/Stage/Gazebo (PSG)La plataforma PSG8

fue creada inicialmente en la Universidad de SouthCalifornia (Gerkeyet al., 2003). Esta formada por lossimuladores Stage y Gazebo, y por el servidor Playeral que se conecta el programa de la aplicacion pararecoger los datos sensoriales o comandar lasordenesa los actuadores. El soporte a robots variados y lossimuladores que incorpora la convierten en una pla-taforma muy completa. Ademas, cuenta con una cre-ciente comunidad de desarrolladores, muy activa, quecontinuamente anade nuevas capacidades y amplıa elhardware soportado.

En PSG los sensores y actuadores se contemplan comosi fueran ficheros (Vaughanet al., 2003), dispositivosde modo caracter al estilo de Unix, que se manipulancon cinco operaciones basicas: abrir, cerrar, leer, escri-bir y configurar. Para usar un sensor, las aplicacionestienen que abrir el dispositivo, configurarlo y leer deel, cerrandolo al final. De manera analoga se utilizanlos actuadores. Cada tipo de dispositivo se define enPSG con unainterfaz, de manera que los sensoressonar de algun robot en particular son instancias de lamisma interfaz. El conjunto de posibles interfaces pre-senta una maquina virtual, con toda suerte de sensoresy actuadores. El robot concreto instancia las interfacesrelativas a los dispositivos realmente existentes.

PSG tiene un diseno cliente/servidor: las aplicacionesestablecen un dialogo por TCP/IP con el servidor Pla-yer, que es el responsable de proporcionar las lectu-ras sensoriales y materializar los comandos de actua-cion. Ademas de permitir acceso remoto, este disenoproporciona a las aplicaciones construidas sobre PSGgran independencia de lenguaje y mınimas imposicio-nes de arquitectura. La aplicacion puede escribirse encualquier lenguaje, y con cualquier estilo, simplemen-te respetando el protocolo de comunicaciones con elservidor.

PSG se orienta principalmente a ofrecer una interfazabstracta del hardware de robots y no a la identifica-cion de bloques comunes de funcionalidad. No obs-tante, se puede incorporar cierta funcionalidad adi-cional con nuevos mensajes del protocolo, y servi-cios anadidos a Player. Por ejemplo, la localizacionprobabilıstica se ha anadido como una interfaz mas,localization , que proporciona multiples hipote-sis de localizacion. Esta nueva interfaz supera a latradicional,position , que acarrea la posicion es-timada desde la odometrıa.

ARIA Otra plataforma de software libre muy utiliza-da es ARIA (ActivMedia Robotics Interface for Appli-

8 http://playerstage.sourceforge.net/

cations) (ActivMedia, 2002). ARIA esta impulsada ymantenida por la empresa ActivMedia Robotics comointerfaz de acceso al hardware de sus robots, perose distribuye con licencia GPL y por tanto su codi-go fuente esta accesible. ARIA ofrece un entorno deprogramacion orientado a objetos, que incluye soportepara la programacion multitarea y para las comuni-caciones a traves de la red. Las aplicaciones han deescribirse forzosamente en C++. ARIA esta soportadaen Linux y en Win32 OS, por lo que una misma apli-cacion escrita sobre su API puede funcionar en robotscon uno u otro sistema operativo. Es un claro ejemplode portabilidad.

En el bajo nivel, ARIA tiene un diseno de cliente-servidor: el robot esta gobernado por un microcon-trolador que hace las veces de servidor. Ese servidorestablece un dialogo a traves del puerto serie con laaplicacion, escrita utilizando ARIA, que actua comocliente. En ese dialogo se envıan al cliente las medidasde ultrasonido, odometrıa, etc. y se reciben lasordenesde actuacion a los motores.

ComandosDirectos

de Movimiento

ConnectDisconnectCallbacks

ArResolver SensoresArActions

ArRobot PacketReceiver

ArRobot Device Connect

Robot(Simulado o Real)

SenderArRobot Packet

ArRobot

Figura 5. Estructura del API de ARIA

En cuanto al acceso al hardware, ARIA ofrece unacoleccion de clases, que configuran una API articu-lada segun muestra la figura 5. La clase principalArRobot contiene varios metodos y objetos rele-vantes asociados.Packet Receiver y PacketSender estan relacionados con el envıo y recepcionde paquetes por el puerto serie con el servidor. Den-tro de la claseArRangeDevices , se tienen clasesmas concretas comoArSonarDevice o ArSickcuyos objetos contienen metodos que permiten a laaplicacion acceder a las lecturas de los sensores deproximidad (sonares o escaner laser, respectivamente).

A diferencia de otras plataformas orientadas a objetos,los objetos de ARIA no son distribuidos, estan ubica-dos en la maquina que se conecta fısicamente al robot.No obstante, ARIA permite programar aplicacionesdistribuidas utilizandoArNetworking para mane-jar comunicaciones remotas, que es un recubrimientode lossocketsdel sistema operativo subyacente.

En cuanto a la multitarea, las aplicaciones sobre ARIApueden programarse en monohilo o multihilo. En esteultimo caso ARIA ofrece infraestructura tanto para

hebras de usuario (ArPeriodicTask ) como pa-ra hebras kernel (ArThreads ). Las ArThreadsson un recubrimiento de lasLinux-pthreads oWin32-threads . Para resolver los problemas desincronizacion y concurrencia, ofrece mecanismos co-mo losArMutex , y lasArCondition .

ARIA contiene comportamientos basicos como la na-vegacion segura, sin chocar contra los obstaculos. Pe-ro no incluye funcionalidad comun como la construc-cion de mapas o la localizacion, que se venden porseparado. Por ejemplo, ActivMedia vende el paqueteMAPPERpara la construccion de mapas,ARNL(RobotNavigation and Localization) para la navegacion ylocalizacion, y ACTS(Color-Tracking Software) parala identificacion de objetos por color y su seguimiento.

Miro Miro 9 (Utz et al., 2002) es una plataformabasada en objetos distribuidos para la creacion de apli-caciones para robots, desarrollada en la Universidadde Ulm y publicada bajo licencia GPL. En cuanto a ladistribucion de objetos, Miro sigue el estandard COR-BA, empleando la implementacion TAO de CORBA,ası como la librerıa ACE.

Miro consta de tres niveles: una capa de dispositivos,una capa de servicios y el entorno de clases. La ca-pa de dispositivos (Miro Device Layer) proporcionainterfaces en forma de objetos para todos los dispo-sitivos del robot. Es decir, sus sensores y actuadoresse acceden a traves de los metodos de ciertos objetos,que dependen de la plataforma fısica. Por ejemplo, laclaseRangeSensor define una interfaz para sen-sores como los sonares, infrarrojos o laser. La cla-seDifferentialMotion contiene metodos paradesplazar un robot con traccion diferencial. La capade servicios (Miro Services Layer) proporciona des-cripciones de los sensores y actuadores como serviciosespecificados en forma de CORBA IDL (InterfaceDefinition Language). De esta manera su funcionali-dad se hace accesible remotamente desde objetos queresiden en otras maquinas interconectadas a la red, in-dependientemente de su sistema operativo subyacente.El entorno de clases (Miro Class Framework) contieneherramientas para la visualizacion y la generacion dehistoricos, ası como modulos con funcionalidad deuso comun en aplicaciones roboticas, como la cons-truccion de mapas, la planificacion de caminos o lageneracion de comportamientos.

Dentro de Miro la aplicacion robotica tiene la formade una coleccion de objetos, remotos o locales. Ca-da uno ejecuta en su maquina y se comunican entresı a traves de la infraestructura de la plataforma. Losobjetos se pueden escribir en cualquier lenguaje quesoporte el estandar CORBA, ya que Miro no imponeninguno en concreto, aunque ha sido enteramente es-crita en C++.

9 http://smart.informatk.uni-ulm.de/MIRO

Existen otras muchas plataformas libres para la pro-gramacion de robots. Por ejemplo MARIE (Cote etal., 2004) que aborda la integracion de software derobots utilizando un paradigma de mediador entreaplicaciones heterogeneas. JDE (Canas and Matellan,2002) es una plataforma cliente-servidor, donde lasaplicaciones se componen de hebras concurrentes quese comunican por memoria compartida. CARMEN(Montemerloet al., 2003) es un conjunto de herra-mientas que facilitan la construccion de aplicacionesdistribuidas reutilizando modulos existentes de nave-gacion, construccion de mapas y localizacion.

APERTOS

OPEN−R

Aplicación C++

Figura 6. Arquitectura de software para el Aibo

5. ENTORNOS DE PROGRAMACION

Dentro del mercado de robots moviles hay variosproveedores mayoritarios a nivel mundial: ActivMe-dia10 , iRobot, Robosoft11 , K-Team12 , Sony, LEGO,etc. Cada uno de estos fabricantes incluye un entornode programacion para sus robots, y lo actualizan amedida que surgen nuevos disenos o dispositivos. Porejemplo, ActivMedia comercializa los robots Pioneer,AmigoBot, etc.; para los cuales estan los entornosSaphira y ARIA. iRobot comercializaba los robotsB21, Magellan, etc.; que utilizaban los entornos RAI,Beesoft, y recientemente Mobility. K-Team comercia-liza los robots Khepera y Koala, ası como sus platafor-mas de programacion y simulacion. En esta seccionvamos a analizar aquellos en los que tenemos expe-riencia mas directa. Todos ellos confirman la organi-zacion del software de robots en tres niveles diferen-ciados: sistema operativo, plataforma y aplicaciones.

5.1 Aibo de Sony

El robot Aibo (figura 6) se vende como mascota, conun programa que gobierna su comportamiento para

10http://www.activmedia.com11http://www.robosoft.fr/12http://www.k-team.com/

Robot Procesador Sistema Operativo Plataforma SimuladorLEGO RCX micro Hitachi BrickOS no legosim webotsSony Aibo RISC Aperios Open-R webotsActivMedia Pioneer micro + laptop Linux/MS-Windows ARIA Saphira JDE PSG PSG SRIsim JMRiRobot (aka RWI) B21 PCs Linux Mobility CARMEN Miro PSGEyeBot micro Motorola ROBIOS librerıas EyeSimK-Team Kephera y Koala micro Motorola KT BIOS SysQuake Korebot webotsRobuter micro Linux/MS-Windows librerıas noNomad PC Linux librerıas noER1 PC Linux/MS-Windows ERSP -

Cuadro 1. Tabla resumen de robots y sus entornos de programacion

exhibir conductas de perro (seguir pelota, buscar hue-so, bailar, etc.) y le permite incluso aprender con eltiempo. Desde el verano del ano 2002 se abrio laposibilidad de programarlo, disparandose su uso co-mo plataforma de investigacion. El robot tiene comosensores principales una camara situada en la cabeza,distintos sensores de contacto (apoyo en las patas, enla cabeza y lomo) y odometrıa en cada una de susarticulaciones. Como actuadores principales tiene laspatas, el cuello y la cola.

El sistema operativo que regula los dispositivos hard-ware del Aibo esAperios 13 , un sistema operativode tiempo real basado en objetos. Sobre este siste-ma, Sony incluye la plataforma OPEN-R, que incor-pora varios objetos especıficos, los cuales establecenuna interfaz de acceso al hardware del robot. Exis-ten objetos para el acceso basico a las imagenes ylas articulaciones (objetoOVirtualRobotComm ),para el manejo de la pila TCP/IP (objetoANT)y para el manejo del altavoz y microfono (objetoOVirtualRobotAudioComm ).

OPEN-R obliga a que la aplicacion se escriba enC++, y su arquitectura software hace que consista enuno o varios objetos, que utilizan los servicios de losobjetos basicos y que pueden intercambiarse datosentre sı (Martın et al., 2004; Serra and Baillie, 2003).Adicionalmente, OPEN-R permite la multitarea y laprogramacion orientada a eventos.

Para programar al Aibo se utiliza el PC como entornode desarrollo y un compilador cruzado para el proce-sador RISC. El programa generado se escribe desde elPC en una barra de memoria (memory stick), y esta seinserta en el propio perro para su ejecucion a bordo.

5.2 RCX de LEGO

Este robot (figura 7) se vende como juguete creativo yplataforma educativa. Esta compuesto por un procesa-dor central (el ladrillo RCX) y un conjunto de piezasLEGO que se ensamblan mecanicamente para montarel cuerpo. Entre los sensores, que se conectan comopiezas LEGO, los hay de luz, de choque, de rotacion,etc. Los actuadores son principalmente motores. Elprocesador es un micro Hitachi H8/3297 de 8 bits,

13Antes conocido como Apertos, y previamente como Muse

con 32 KB de memoria RAM, sobre el que se ejecu-ta un sistema operativo propio de LEGO (Ferrarietal., 2001).

drivers

Aplicación C

BrickOS

Figura 7. Arquitectura de software para el robot LEGO

Hay varias alternativas para programarlo, y todas uti-lizan el PC como entorno de desarrollo, descargandoel programa en el RCX a traves del enlace de infra-rrojos que posee (por puerto serie o USB). LEGOofrece un entorno visual de programacion orientadoa los ninos, llamadoRCX-code , que ya describimosen la seccion 2. estructuras de control (condicionales,bucles, etc.). Otro entorno grafico con el que se puedeprogramar es Robolab14 , una adaptacion de LabView,de National Instruments. Una posibilidad mas de pro-gramacion es el lenguaje NQC, creado por Dave Baum(Baum, 2000). Este lenguaje textual es una variante re-cortada de C que dispone de instrucciones propias parael acceso a sensores y actuadores. Tanto los programasen RCX-code como en NQC se compilan a codigointermedio que se interpreta en tiempo de ejecucionen el propio ladrillo.

Debido a la popularidad de este robot, algunos aficio-nados han desarrollado sistemas operativos alternati-vos que reemplazan al nativo de LEGO y exprimenmejor las posibilidades del hardware. El sistema ope-rativo libre BrickOS15 16 , desarrollado por MarkusL. Noga (Nielsson, 2000), permite la programaciondel ladrillo en lenguaje C. En este caso, el compiladorcruzado genera codigo no interpretado, que ejecutadirectamente sobre el micro, por lo que se gana en

14http://www.ni.com/company/robolab.htm15http://brickos.sourceforge.net/16antes conocido como LegOS

eficiencia temporal. Del mismo modo, el sistema ope-rativo LeJOS17 permite la creacion de aplicaciones enJAVA. Todos estos sistemas operativos, incluyendo aloriginal de LEGO, ofrecen la capacidad de multitarea.

En todos los casos el entorno de programacion es muybasico, de sistema operativo. Como es un robot muylimitado en cuanto a numero y calidad de sensores yde actuadores, los comportamientos generables coneltienden a ser sencillos. Por eso no es necesaria unaplataforma de desarrollo y las aplicaciones se puedenhacer sin problemas programando directamente sobrela API del sistema operativo.

5.3 Pioneer de ActivMedia

El robot Pioneer es un robot de tamano mediano,segun se aprecia en la figura 8, con 26 cm de radioy 22 cm de alto. Consta de una base movil con unpar de motores, sensores de ultrasonido, odometrosy opcionalmente, sensores de contacto y sensor laserde proximidad. Tiene un microcontrolador que se en-carga de recoger las medidas sensoriales y enviar lasordenes de movimiento a los motores, ademas de es-tar gobernado por un sistema operativo de bajo nivel(P2OS o AROS, segun modelos). En cuanto a la arqui-tectura de procesadores, el montaje mas frecuente delPioneer incorpora un ordenador portatil a bordo, en elque se ejecutan las aplicaciones, y enel un sistemaoperativo generalista como Linux. Las aplicacionesdialogan con el microcontrolador a traves del puertoserie utilizando un protocolo propio llamado SIP.

ARIA

Aplicación C++

P2OS / AROS

Linux / MS−Windows

Figura 8. Arquitectura de software para el Pioneer

Para crear aplicaciones se dispone de la plataformaARIA, publicada con licencia GPL. Como hemos des-crito profusamente en la seccion 4.5, esta plataformaestablece una interfaz abstracta de acceso al hardwarey una arquitectura software orientada a objetos paralas aplicaciones (forzosamente escritas en C++).

17http://lejos.sourceforge.net/

El fabricante incluye el simuladorSRIsim acom-panando a ARIA. Este simulador bidimensional per-mite emular ununico Pioneer en un entorno estaticoy sus sensores mas comunes: odometrıa, sonares ylaser. Recientemente han incorporado a su softwareel simuladorStage de PSG, renombrandolo comoMobileSim , y programando un recubrimiento paraque funcione con el codigo ya existente de ARIA. Estoes un ejemplo nıtido, a nivel de empresa, de reutiliza-cion de codigo en aplicaciones de robots, favorecidoporqueStage es software libre.

6. PERSPECTIVAS

El mercado de los robots moviles tiene actualmenteuna pujanza creciente, cada vez hay mas movimientosempresariales alrededor de la robotica. Los robotsAibo y LEGO son solo dos ejemplos deexitos deventas, superando cada uno las cien mil unidadesvendidas.

Ademas, los prototipos de investigacion cada vez tie-nen mayor funcionalidad, dejando de utilizarse exclu-sivamente en fabricas y aproximando su uso al hogarcomo robots de entretenimiento o de servicio.

Con el paso de los anos, el modo de programar losrobots ha ido evolucionando y se ha ido articulandoen tres niveles diferenciados: sistemas operativos, pla-taformas de desarrollo y aplicaciones concretas. En laseccion 5 hemos descrito el entorno de programacionde tres robots reales muy difundidos: Aibo, RCX yPioneer. En todos ellos hemos encontrado esos tresniveles de software.

Otra tendencia confirmada es la extension del ordena-dor personal (bien PC de sobremesa, bien PC portatil)como procesador principal de los robots. Mas alla delos sistemas operativos dedicados, esta incorporacionha traıdo la irrupcion en los robots de sistemas ope-rativos generalistas, como Linux o MS-Windows, yel uso creciente de lenguajes de alto nivel con susherramientas asociadas.

Tambien hemos identificado varias lıneas comunes en-tre plataformas: uniforman y simplifican el acceso alhardware, ofrecen una arquitectura software determi-nada e incorporan funcionalidad robotica comun comola navegacion, la construccion de mapas o la localiza-cion. A grandes rasgos, las plataformas tratan de fijaruna base estable sobre la cual desarrollar aplicacionesroboticas, y eso supone un paso hacia la madurezde la programacion de robots. Primero, favorecen laportabilidad de aplicaciones entre robots diferentes.Segundo, fomentan la reutilizacion de codigo, conlo cual disminuyen los tiempos de desarrollo de lasnuevas aplicaciones. Y tercero, con su arquitecturasoftware ofrecen una manera de organizar el codigo,lo cual permite afrontar la complejidad creciente delas aplicaciones de robots.

Hemos presentado una muestra representativa tanto delas de software libre (ARIA, PSG, Miro) como de laspropietarias (ERSP, OPEN-R). Habra que ver cualessobreviven de aquı a unos anos, y eso dependera enor-memente de cuantos usuarios y desarrolladores seancapaces de atraer cada una de ellas.

La aparicion de las plataformas de desarrollo suponeun relevante paso hacia adelante en el largo camino dela programacion de robots. Sin embargo, aunque la ne-cesidad de estandares en robotica ha sido identificadapor muchos autores, en la actualidad existenmuchasplataformas diferentes, tal vez demasiadas, reflejo deque no hay aun un estandar universalmente admitido.

7. REFERENCES

ActivMedia (2002). ARIA reference manual. Techni-cal Report version 1.1.10. ActivMedia Robotics.

Baum, Dave (2000).Dave Baum’s definitive guide toLEGO MINDSTORMS. APress.

Biggs, Geoffrey and Bruce MacDonald (2003). A sur-vey of robot programming systems. In:Procee-dings of the 2003 Australasian Conference onRobotics and Automation(Jonathan Roberts andGordon Wyeth, Eds.).

Bruyninckx, Herman (2001). Open robot control soft-ware: the OROCOS project. In:Proceedings ofthe 2001 IEEE/RSJ International Conference onIntelligent Robots and Systems (IROS-01). Vol. 3.Seoul (Korea). pp. 2523–2528.

Braunl, Thomas (2003).Embedded robotics. SpringerVerlag.

Canas, Jose M. and Vicente Matellan (2002). Dynamicschema hierarchies for an autonomous robot. In:Advances in Artificial Intelligence - IBERAMIA2002(Jose C. Riquelme y Miguel Toro FranciscoJ. Garijo, Ed.). Vol. 2527 ofLecture notes inartificial intelligence. pp. 903–912. Springer.

Cote, Carle, Dominic Letourneau, Francois Michaud,Jean-Marc Valin, Yannick Brosseau, ClementRaıevsky, Mathieu Lemay and Victor Tran(2004). Code reusability tools for programmingmobile robots. In: Proceedings of the 2004IEEE/RSJ International Conference on Intelli-gent Robots and Systems (IROS-04). Sendai (Ja-pan).

Ferrari, Mario, Giulio Ferrari and Ralph Hempel(2001). Building robots with LEGO MINDS-TORMS: The Ultimate Tool for Mindstorms Ma-niacs. Syngress.

Firby, R. James (1994). Task networks for controllingcontinuous processes. In:Proceedings of the 2ndInternational Conference on AI Planning Sys-tems AIPS’94. Chicago, IL (USA). pp. 49–54.

Gerkey, Brian P., Richard T. Vaughan and Andrew Ho-ward (2003). The Player/Stage project: tools formulti-robot and distributed sensor systems. In:Proceedings of the 11th International Conferen-ce on Advanced Robotics ICAR’2003. Coimbra(Portugal). pp. 317–323.

Hattig, Myron, Ian Horswill and Jim Butler (2003).Roadmap for mobile robot specifications. In:Proceedings of the 2003 IEEE/RSJ Internatio-nal Conference on Intelligent Robots and Systems(IROS-03). Vol. 3. Las Vegas (USA). pp. 2410–2414.

Lozano Ortega, MiguelAngel, Ignacio Iborra Baezaand Domingo Gallardo Lopez (2001). EntornoJava para simulacion y control de robots moviles.In: Actas de la IX Conferencia de la AsociacionEspanola Para la Inteligencia Artificial, CAEPIA2001. Gijon. pp. 1249–1258.

Martın, Francisco, Rafaela Gonzalez-Careaga,Jose M. Canas and Vicente Matellan (2004). Pro-gramming model based on concurrent objects forthe AIBO robot. In:Proceedings of the XII Jor-nadas de Concurrencia y Sistemas Distribuidos.pp. 367–379.

Montemerlo, Michael, Nicholas Roy and SebastianThrun (2003). Perspectives on standardization inmobile robot programming: the carnegie mellonnavigation (CARMEN) toolkit. In:Proceedingsof the 2003 IEEE/RSJ International Conferenceon Intelligent Robots and Systems (IROS-03).Vol. 3. Las Vegas (USA). pp. 2436–2441.

Nielsson, Stig (2000). Introduction to the LegOS ker-nel. Technical report.

RWI, Real World Interface (1999). Mobility Robot In-tegration software, User’s guide. Technical Re-port version 1.1. IS Robotics, Inc.

Serra, Francois and Jean-Christophe Baillie (2003).Aibo programming using OPEN-R SDK. tutorial.Technical report. ENSTA (Francia).

Simmons, Reid and David Apfelbaum (1998). A TaskDescription Language for robot control. In:Pro-ceedings of the 1998 IEEE/RSJ InternationalConference on Intelligent Robots and Systems(IROS-98). Vol. 3. Victoria (Canada). pp. 1931–1937.

Sony (2003). OPEN-R SDK, Programmer’s guide.Technical Report 20030201-E-003. Sony Corpo-ration.

Utz, Hans, Stefan Sablatnog, Stefan Enderle and Ger-hard Kraetzschmar (2002). Miro – middlewarefor mobile robot applications.IEEE Transactionson Robotics and Automation, Special Issue onObject-Oriented Distributed Control Architectu-res18(4), 493–497.

Vaughan, Richard T., Brian P. Gerkey and Andrew Ho-ward (2003). On device abstractions for porta-ble, reusable robot code. In:Proceedings of the2003 IEEE/RSJ International Conference on In-telligent Robots and Systems (IROS-03). Vol. 3.Las Vegas (USA). pp. 2121–2127.

Woo, Evan, Bruce A. MacDonald and Felix Trepa-nier (2003). Distributed mobile robot applica-tion infraestructure. In:Proceedings of the 2003IEEE/RSJ International Conference on Intelli-gent Robots and Systems (IROS-03). Vol. 2. LasVegas (USA). pp. 1475–1480.