1. Programaci´n de robots m´viles
o o
Jos´ Mar´ Ca˜as Plaza
e ıa n
Universidad Rey Juan Carlos
2 de agosto de 2004
Resumen
El comportamiento de un robot aut´nomo viene determinado por el pro-
o
grama que gobierna sus actuaciones. La creaci´n de programas para ro-
o
bots debe cumplir con ciertos requisitos espec´ ıficos frente a la programaci´n
o
en otros entornos m´s tradicionales, como el ordenador personal. En este
a
art´
ıculo planteamos que el software de los robots se estructura actualmente
en tres niveles: sistema operativo, plataforma de desarrollo y aplicaciones
concretas. En los ultimos a˜os, han surgido con fuerza plataformas de de-
´ n
sarrollo con la idea de facilitar la construcci´n incremental de estas aplica-
o
ciones rob´ticas. M´s all´ del acceso b´sico a los sensores y actuadores, las
o a a a
plataformas suelen proporcionar un modelo para la organizaci´n del c´digo
o o
y bibliotecas con funcionalidades comunes. En este art´ ıculo se identifican
y analizan esos tres niveles, describiendo desde esta perspectiva los entor-
nos de desarrollo de los robots reales m´s extendidos, y las tendencias m´s
a a
recientes.
´
Indice
1. Introducci´n
o 2
2. Software de robots 4
2.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Sistemas operativos, plataformas y aplicaciones . . . . . . . . . . . 7
2.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Sistemas operativos 12
3.1. Sistemas operativos dedicados y generalistas . . . . . . . . . . . . . 12
3.2. Procesadores, sensores y actuadores . . . . . . . . . . . . . . . . . . 15
1

2. ´
1 INTRODUCCION 2
4. Plataformas de desarrollo 17
4.1. Abstracci´n del hardware . . .
o . . . . . . . . . . . . . . . . . . . . . 18
4.2. Arquitectura software . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Funcionalidades de uso com´nu . . . . . . . . . . . . . . . . . . . . . 21
4.4. Arquitectura cognitiva . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5. Plataformas de software libre . . . . . . . . . . . . . . . . . . . . . 25
5. Entornos de programaci´n o de robots 29
5.1. Aibo de Sony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. RCX de LEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3. Pioneer de ActivMedia . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4. B21 de iRobot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. Conclusiones y perspectivas 36
1. Introducci´n
o
El principal objetivo de la rob´tica es la construcci´n de m´quinas capaces
o o a
de realizar tareas con la flexibilidad, la robustez y la eficiencia que exhiben los
humanos. Los robots son potencialmente utiles en escenarios peligrosos para el ser
´
humano, aburridos, sucios o dif´ ıciles. En este sentido los brazos rob´ticos que se
o
emplean en las f´bricas de coches para soldar y pintar, los robots m´viles que se
a o
env´ a Marte, o los que se utilizan para limpiar centrales nucleares son varios
ıan
ejemplos de aplicaciones reales en las cuales se utilizan robots hoy d´ ıa.
Hay muchos tipos de robots: con ruedas, con patas, brazos manipuladores, con
orugas, de forma humanoide, de forma cil´ ındrica, etc. Sin embargo, la morfolog´
ıa
no es una caracter´ıstica esencial, lo que identifica a cualquier robot es que combina
en la misma plataforma a sensores, actuadores y procesadores. Los sensores miden
alguna caracter´ıstica del entorno o propia (e.g. c´maras, sensores de obst´culos,
a a
etc.). Los actuadores permiten al robot hacer algo, llevar a cabo alguna acci´n o o
simplemente desplazarse (e.g. los motores). Los procesadores hacen los c´mputos
o
necesarios y realizan el enlace l´gico entre sensores y actuadores, materializando
o
el comportamiento del robot en el entorno en el cual se encuentra inmerso.
Generar comportamiento es programar
La existencia de robots que realicen aut´nomamente tareas de modo eficiente
o
depende fundamentalmente de su construcci´n mec´nica y de su programaci´n.
o a o
Una vez construido el cuerpo mec´nico del robot, conseguir que realice una tarea
a
se convierte en la pr´ctica en un problema de programaci´n. La generaci´n de com-
a o o
portamiento en un robot consiste entonces en escribir el programa que al ejecutarse

3. ´
1 INTRODUCCION 3
en el robot causa ese comportamiento cuando ´ste se encuentra en cierto entorno.
e
La autonom´ y la “inteligencia” residen en ese programa. Por ejemplo, en los ro-
ıa
bots m´viles el comportamiento principal es su movimiento. Los programas que se
o
ejecutan en el robot determinan c´mo se mueve ´ste por el entorno, reaccionando
o e
ante obst´culos percibidos por los sensores, acerc´ndose a alg´n destino, etc. y
a a u
para ello tienen que enviar continuamente las ´rdenes pertinentes a los motores.
o
El mercado de los robots y la autonom´
ıa
Muchos de los robots que se venden en la actualidad se compran como produc-
tos cerrados, programados por el fabricante e inalterables, por ejemplo la aspira-
dora rob´tica Roomba de iRobot1 o el perrito Aibo2 de Sony en sus inicios3 . En
o
contraste, otra parte relevante del mercado son los robots programables. Los prin-
cipales clientes de estos robots son los centros de investigaci´n, que normalmente
o
est´n interesados en programarlos ellos mismos. En estos casos, el fabricante vende
a
los robots con un software que permite su programaci´n por el usuario.
o
La tendencia actual del mercado de robots es de crecimiento real: cada vez
son m´s los productos rob´ticos que se venden y m´s frecuentes los movimientos
a o a
empresariales alrededor de la tecnolog´ rob´tica. Por ejemplo, recientemente Sony
ıa o
compr´ la licencia del software de visi´n a la peque˜a empresa Evolution Robotics4 ,
o o n
para usarla en sus robots. Los robots de LEGO como juguetes imaginativos y
los perritos Aibo vendidos como mascotas son ´xitos de ventas significativos, con
e
centenares de miles de unidades cada uno.
Aunque est´ en v´ de consolidaci´n, en t´rminos generales el mercado de los
a ıas o e
robots m´viles est´ inmaduro y todav´ no se ha abierto al gran p´blico. Esto
o a ıa u
se debe en parte a la fragilidad de los resultados (sobre todo comparados con las
expectativas) y las limitaciones en autonom´ que tienen los robots conseguidos
ıa
hasta la fecha. De hecho, el grado de autonom´ y de fiabilidad que seamos capaces
ıa
de conseguir en los robots ser´ una cuesti´n determinante en la evoluci´n futura
a o o
de ese mercado. El crecimiento en autonom´ abre la puerta a nuevas aplicaciones
ıa
comerciales rob´ticas, como los robots de servicio y los de entretenimiento. Avances
o
recientes en esta l´
ınea son los ya mencionados de la aspiradora rob´tica Roomba
o
y la mascota Aibo.
Sin embargo la autonom´ es dif´
ıa ıcil, y salvo casos contados, el desarrollo de
aplicaciones con robots sigue siendo materia de investigaci´n. Al d´ de hoy, los
o ıa
proveedores de robots hacen negocio vendiendo los componentes hardware (pla-
1
http://www.irobot.com
2
http://www.aibo-europe.com
3
En el verano de 2002 Sony hizo p´blica la interfaz de programaci´n de sus perritos, Open-R,
u o
en parte forzados por un hacker que hab´ conseguido desvelar algunas de sus interfaces
ıa
4
http://www.evolution.com/

4. 2 SOFTWARE DE ROBOTS 4
taformas f´ısicas, motores, sensores, etc.) y con algunas soluciones a medida para
clientes espec´ıficos. Tambi´n venden el software de desarrollo, m´s o menos com-
e a
pleto, e incluso algunas aplicaciones de ejemplo sencillas y/o m´s maduras, como
a
la construcci´n de mapas o el seguimiento de personas.
o
Este art´
ıculo est´ organizado en seis partes contando con esta introducci´n.
a o
En la segunda secci´n se rese˜an las peculiaridades que tiene la programaci´n de
o n o
robots y se presentan los tres niveles identificados en ese software, la evoluci´n o
hist´rica que ha desembocado en ellos y las tendencias actuales. En la tercera
o
secci´n se describe el nivel m´s bajo: el hardware que conforma t´
o a ıpicamente un
robot y los sistemas operativos que permiten acceder a ´l, repasando dos ejemplos
e
concretos (ROBIOS y Linux). En el cuarto apartado se detallan las caracter´ ısticas
principales de las plataformas de desarrollo que han aparecido en los ultimos a˜os
´ n
y se analizan varios ejemplos particulares. A modo de ilustraci´n, en la quinta
o
secci´n se describen con cierto detalle los entornos de programaci´n de cuatro
o o
robots comerciales muy difundidos (LEGO, Aibo, Pioneer y B21) enmarc´ndolosa
en los tres niveles mencionados. Finalizamos con las conclusiones principales de
este trabajo.
2. Software de robots
En el manejo de robots conviene diferenciar entre el usuario final y el progra-
mador, pues el robot ofrece interfaces muy distintas a uno y a otro. El usuario es
quien aprovecha las aplicaciones que ha desarrollado el programador. Para ´l la in-
e
terfaz de uso suele ser extremadamente sencilla, m´xime si el usuario es el p´blico
a u
en general. Por ejemplo, la interfaz de uso de la aspiradora Roomba es un simple
bot´n. Por el contrario, la interfaz de programaci´n requiere de ciertos conocimien-
o o
tos por parte del desarrollador, y su objetivo es permitir la creaci´n de programas
o
para el robot. A lo largo de este art´ıculo se analizan las diferentes posibilidades de
programaci´n de los robots m´viles que se venden en la actualidad.
o o
En los ultimos a˜os los avances en aplicaciones de robots m´viles aut´nomos
´ n o o
han sido significativos. Hoy en d´ hay resultados fiables en aplicaciones como
ıa,
la construcci´n de mapas, la navegaci´n autom´tica, la localizaci´n, la detecci´n
o o a o o
de caras o el procesamiento de visi´n est´reo. Por ejemplo, en algunas f´bricas
o e a
hay robots que se mueven solos de un punto a otro remoto sin chocar con ning´n u
obst´culo, transportando piezas pesadas. La funcionalidad de los prototipos de in-
a
vestigaci´n construidos es cada vez mayor: gu´ de museos, cuidadores de ancia-
o ıas
nos, etc. No hay magia: detr´s de esas aplicaciones hay programas que determinan
a
el comportamiento de esos robots, programas que han escrito los dise˜adores y que
n
consiguen que el robot se mueva como lo hace.
A la hora de crear esas aplicaciones, una primera separaci´n distingue a la
o

5. 2 SOFTWARE DE ROBOTS 5
programaci´n autom´tica de la programaci´n manual [BM03]. En la programaci´n
o a o o
autom´tica se engloban los sistemas con aprendizaje y la programaci´n basada en
a o
demostraci´n. Este enfoque es posible en brazos industriales robotizados donde
o
la ejecuci´n deseada es el recorrido por una secuencia de puntos, los cuales se
o
pueden introducir en el robot simplemente conduciendo externamente al brazo
por las posiciones deseadas. Sin embargo en robots m´viles, con escenarios m´s
o a
variables, ese planteamiento es inviable y normalmente el dise˜ador escribe a mano
n
el programa que determina su comportamiento.
Entre los programadores de robots m´viles figuran los propios fabricantes (co-
o
mo Sony, ActivMedia, iRobot, etc.), algunas empresas dedicadas (como Evolution
Robotics), y los centros de investigaci´n. Gran parte del software existente hoy
o
d´ para robots ha sido desarrollado por grupos de investigaci´n, lo cual est´ en
ıa o a
consonancia con la inmadurez ya comentada del mercado rob´tico. Afortunada-
o
mente ese software suele estar disponible libremente en Internet, reflejo del deseo
de difusi´n del conocimiento en esos grupos.
o
2.1. Requisitos
Escribir programas para robots es una tarea complicada, porque los robots son
sistemas complejos. De hecho, la programaci´n de robots m´viles suele ser m´s
o o a
exigente que la creaci´n de programas tradicionales como aplicaciones de ofim´tica,
o a
bases de datos, etc. En esta secci´n enumeramos algunos condicionantes espec´
o ıficos
diferenciadores.
En primer lugar, los programas de robots m´viles est´n empotrados en la rea-
o a
lidad f´
ısica, a trav´s de sensores y actuadores. Con los sensores miden alguna
e
caracter´ıstica de la realidad y con los actuadores pueden provocar cambios en ella.
Por un lado, esta situaci´n implica que el software de robots m´viles debe ser
o o
a
´gil, pues debe tomar decisiones con vivacidad para controlar correctamente cier-
tos actuadores. Por lo tanto se tienen requisitos de tiempo real, si no estricto, al
menos blando. Por otro lado, hay una enorme variedad de dispositivos sensoriales
y de actuaci´n, as´ como de interfaces, que un programador debe dominar si quiere
o ı
escribir programas para robots.
En segundo lugar, una aplicaci´n de robots m´viles t´
o o ıpicamente ha de estar
pendiente de varias fuentes de actividad y objetivos a la vez. El programa de un
robot tiene que atender a muchas cosas simult´neamente: recoger nuevos datos
a
de varios sensores, refrescar la interfaz gr´fica, enviar peri´dicamente consignas
a o
a los motores, enviar o recibir datos por la red a otro proceso de la aplicaci´n,o
etc. Por ello las aplicaciones de robots suelen ser concurrentes, lo cual les a˜ade
n
cierta complejidad. En este sentido los sistemas operativos de robots m´s avanza-
a
dos incorporan mecanismos multitarea y de comunicaci´n interprocesos. Con ello
o
permiten la distribuci´n de las tareas en diferentes hebras que se ejecutan con-
o

6. 2 SOFTWARE DE ROBOTS 6
currentemente y una programaci´n modular que se adapta a la naturaleza de las
o
aplicaciones de robots mejor que la estrictamente secuencial.
Tercero, otra cuesti´n relevante que deben contemplar las aplicaciones que co-
o
rren a bordo de los robots es su interfaz gr´fica. Aunque la interfaz gr´fica no
a a
es indispensable para generar y materializar el comportamiento aut´nomo en el
o
robot, normalmente resulta muy util como herramienta de depuraci´n. Adem´s de
´ o a
las posibilidades de interacci´n con el usuario, la interfaz gr´fica permite la visua-
o a
lizaci´n en tiempo de ejecuci´n de estructuras internas (e.g. representaciones del
o o
mundo), las trazas y el an´lisis de variables internas del programa que pueden afec-
a
tar a la conducta observable del robot. El c´digo de la aplicaci´n deber´ encargarse
o o a
de actualizar esa interfaz y de atender la interacci´n por parte del usuario.
o
Cuarto, el software de robots es cada vez m´s distribuido, tal y como apuntan
a
Woo et al.[WMT03]. Es usual que las aplicaciones de robots tengan que establecer
alguna comunicaci´n con otros procesos ejecutando en la misma o en diferente
o
m´quina. Para generar comportamiento en un unico robot esta distribuci´n no es
a ´ o
imprescindible, pero ofrece posibilidades ventajosas como ubicar la carga compu-
tacional en nodos con mayor capacidad o la visualizaci´n remota; y en sistemas
o
multirrobot, hace posible la integraci´n sensorial, la centralizaci´n y la coordina-
o o
ci´n. Por ejemplo, las comunicaciones permiten el acceso remoto a los sensores del
o
robot, muy util en aplicaciones de teleoperaci´n. Esta distribuci´n implica que el
´ o o
c´digo de la aplicaci´n debe encargarse de mantener la comunicaci´n por red con
o o o
los otros procesos remotos.
En quinto lugar, las aplicaciones de robots no cuentan con un marco esta-
ble, no hay est´ndares abiertos que propicien la colaboraci´n [USEK02, MRT03,
a o
CLM+ 04], la reutilizaci´n de c´digo y la integraci´n. En otros campos de la in-
o o o
form´tica hay bibliotecas que un programador puede emplear para construir su
a
propio programa, ganando en fiabilidad y acortando el tiempo de desarrollo. Por
el contrario, en rob´tica cada aplicaci´n pr´cticamente ha de construirse de cero
o o a
para cada robot concreto. No hay una base s´lida y firme para el desarrollo de
o
nuevas aplicaciones. Esa falta se debe en parte a la heterogeneidad end´mica en
e
rob´tica, tanto en hardware como en software, y en parte a la inmadurez del mer-
o
cado de robots programables. En cualquier caso, esa ausencia est´ frenando las
a
posibilidades de crecimiento del mercado rob´tico.
o
En la actualidad hay avances hacia la estandarizaci´n, como las plataformas
o
de desarrollo que veremos en la secci´n 4. La aparici´n de esas plataformas supone
o o
un paso m´s hacia la madurez, tratando de estabilizar una interfaz sobre la que
a
construir aplicaciones de robots, pero queda a´n mucho camino por recorrer.
u
En sexto lugar, y ligado con el condicionante anterior, el conocimiento sobre
c´mo generar y descomponer el comportamiento artificial es muy limitado. C´mo
o o
dividir el comportamiento de robots en unidades b´sicas sigue siendo materia de
a

7. 2 SOFTWARE DE ROBOTS 7
investigaci´n, y no hay una gu´ universalmente admitida sobre c´mo organizar el
o ıa o
c´digo de las aplicaciones de robots para que sea escalable y se puedan reutilizar sus
o
partes. Cada desarrollador programa su aplicaci´n combinando ad hoc los bloques
o
de c´digo que puedan existir en su entorno.
o
2.2. Sistemas operativos, plataformas y aplicaciones
El modo en que se programan los robots ha ido evolucionando con el paso de los
a˜os. Hist´ricamente los robots eran desarrollos unicos, no se produc´ en serie,
n o ´ ıan
y los programas de control se sol´ construir empleando directamente los drivers
ıan
para acceder a los dispositivos sensoriales y de actuaci´n. El sistema operativo
o
era m´ınimo, b´sicamente una colecci´n de drivers con rutinas para leer datos de
a o
los sensores y enviar consignas a los actuadores. En este contexto, el programa
de aplicaci´n le´ las medidas obtenidas por los sensores y escrib´ las ´rdenes
o ıa ıa o
de movimiento a los motores invocando directamente las funciones de librer´ que
ıa
ofrec´ el fabricante en sus drivers. Como muestra la figura 1(a), en este caso la
ıa
aplicaci´n se situaba directamente encima del sistema operativo.
o
Aplicación
Aplicación Plataforma
desarrollo
drivers Sistema Operativo
Hardware del robot Hardware del robot
(a) (b)
Figura 1: Programaci´n de robots: (a) sobre drivers espec´
o ıficos de sensores y ac-
tuadores. (b) sobre una plataforma de desarrollo
Con el asentamiento de los fabricantes, el trabajo de muchos grupos de investi-
gaci´n y la evoluci´n de los a˜os han ido apareciendo plataformas de desarrollo que
o o n
simplifican la programaci´n de aplicaciones rob´ticas. Estas plataformas ofrecen
o o
acceso m´s sencillo a sensores y actuadores, suelen incluir un modelo de programa-
a
ci´n que establece una determinada organizaci´n del software y permite manejar la
o o

8. 2 SOFTWARE DE ROBOTS 8
creciente complejidad del c´digo cuando se incrementa la funcionalidad del robot.
o
El dise˜ador programa sus aplicaciones rob´ticas finales sobre esa plataforma de
n o
desarrollo.
Las aplicaciones suelen resolver un problema concreto e incluir t´cnicas es-
e
pec´ıficas: de extracci´n de informaci´n, de toma de decisiones, etc. A la hora de
o o
su programaci´n el usuario tiene hoy dos alternativas: la tradicional de programar
o
directamente sobre el sistema operativo, y la m´s reciente de programar dentro
a
de la plataforma de desarrollo, utilizando sus abstracciones. La primera interfaz
suele ofrecer m´s flexibilidad, con el coste de mayor complejidad en la progra-
a
maci´n, pues es el propio programador de la aplicaci´n quien debe cuidar que su
o o
c´digo realice las tareas de las que se podr´ encargar la plataforma. La figura
o ıa
1(b) ilustra estas dos posibilidades. En ambos casos las aplicaciones se apoyan en
una infraestructura de programaci´n, bien sea b´sica como el sistema operativo, o
o a
m´s abstracta como la plataforma de desarrollo. En las secciones 3 y 4 se detallan
a
ampliamente las caracter´ ısticas de ambas infraestructuras.
2.3. Herramientas
El procedimiento de creaci´n de aplicaciones para robots no difiere especial-
o
mente del de otras aplicaciones. El programador tiene que escribir la aplicaci´n o
en cierto lenguaje, compilar y enlazar su c´digo con las librer´ de la plataforma
o ıas
y/o del sistema operativo, y finalmente ejecutarla en los computadores a bordo
del robot. Esa ejecuci´n genera el comportamiento deseado cuando el robot se
o
encuentra en el entorno adecuado. Para todos estos pasos el dise˜ador cuenta con
n
varias herramientas: editores para escribir el programa fuente en el lenguaje elegi-
do, compilador, simuladores, depuradores espec´ ıficos, compilador cruzado, etc.
Muchos robots tienen recursos computacionales y de almacenamiento limitados:
carecen de disco duro, pantalla suficiente, etc. En estos casos se utiliza el PC como
entorno de desarrollo y se emplean compiladores cruzados para generar en el PC
el programa ejecutable que correr´ sobre el procesador a bordo del robot. Es el
a
caso de la mayor´ de robots peque˜os, como el RCX de LEGO, Aibo de Sony,
ıa n
EyeBot5 , Kephera de K-Team6 , Pekee de Wany Robotics7 , etc.
Una herramienta particular, muy util en la programaci´n de robots son los
´ o
simuladores. Los simuladores ofrecen un entorno virtual en el que emulan las ob-
servaciones de los sensores y los efectos de las ´rdenes a los actuadores. Sirven
o
como evaluaci´n, depuraci´n y ajuste del programa de control antes de llevar la
o o
aplicaci´n al robot real.
o
5
http://www.ee.uwa.edu.au/~braunl/eyebot
6
http://www.k-team.com
7
http://www.wanyrobotics.com

9. 2 SOFTWARE DE ROBOTS 9
Los buenos robots no son baratos y necesitan mantenimiento. Los simuladores
son una opci´n econ´mica para quienes quieren investigar programando robots pe-
o o
ro no cuentan con el dinero o el material necesario. Esto se hace a´n m´s patente
u a
en el caso de investigar con poblaciones grandes de robots. Aunque actualmen-
te han perdido credibilidad como demostrador de resultados experimentales, los
simuladores no han perdido valor como herramienta util.
´
Los primeros simuladores eran poco realistas y almacenaban mundos planos
donde hab´ obst´culos bidimensionales. Con los a˜os se ha ido ganando en rea-
ıa a n
lismo, incorporando ruido en los sensores y en las actuaciones. Hoy d´ se tienen
ıa
simuladores tridimensionales, como Gazebo8 (en la figura 2(b) se puede observar
un mundo simulado con Gazebo) y JMR [LOIBGL01], capaces de simular senso-
res tan complejos como la visi´n. Tambi´n se ha incluido en los simuladores m´s
o e a
potentes la capacidad de representar un conjunto de robots operando en el mismo
escenario, simult´neamente.
a
(a) (b)
Figura 2: Simuladores de robots: (a) SRIsim c (b) Gazebo
Muchos fabricantes de robots incluyen un simulador para sus robots (e.g.
EyeSim para el robot EyeBot, Webots para Kephera y Koala) aunque tambi´n e
hay muchos desarrollos libres (Stage, Gazebo, JMR). Los simuladores libres tratan
de incluir soporte para los robots de varios fabricantes. La configuraci´n concreta
o
de el/los robot/s a simular, la disposici´n y par´metros de sus sensores se suele
o a
especificar en un fichero de configuraci´n. Algunos simuladores relevantes son el
o
SRIsim9 de Kurt Konolige, que se emplea en los robots de ActivMedia (en la fi-
gura 2(a) se puede ver un mundo simulado con SRIsim), los simuladores Stage y
8
http://playerstage.sourceforge.net
9
http://www.ai.sri.com/~konolige/saphira

10. 2 SOFTWARE DE ROBOTS 10
Gazebo de software libre orientados a multirrobot (Stage soporta 2D y colonias
numerosas de robots, y Gazebo soporta 3D). Tambi´n incluye visi´n y realidad
e o
tridimensional el simulador JMR [LOIBGL01], que est´ escrito en Java.
a
2.4. Lenguajes
En cuanto a los lenguajes que se emplean para programar robots, no hay dife-
rencias significativas con los utilizados en otras aplicaciones m´s tradicionales. Si
a
bien hay casos de programaci´n funcional y programaci´n l´gica de robots, sin nin-
o o o
guna duda los m´s utilizados son los lenguajes gen´ricos procedimentales. Normal-
a e
mente los lenguajes utilizados son gen´ricos, es decir, se usan en otras aplicaciones
e
inform´ticas, y la parte espec´
a ıfica de rob´tica se encapsula en bibliotecas u objetos
o
particulares. Tambi´n ha habido intentos de establecer lenguajes espec´
e ıficos para
robots, como Task Description Language (TDL) de Simmons [SA98] o Reactive
Action Packages (RAP) de Firby [Fir94], que tratan de incluir en la propia sin-
taxis del lenguaje primitivas ventajosas para la programaci´n de robots, como la
o
descomposici´n de tareas, la monitorizaci´n de ejecuci´n, la sincronizaci´n, etc.
o o o o
Estos lenguajes llevan asociada una sem´ntica que es una apuesta cognitiva sobre
a
c´mo generar el comportamiento en los robots.
o
En los brazos robotizados industriales es frecuente el uso de lenguajes de ba-
jo nivel, pr´cticamente ensamblador [BM03] del microprocesador de turno. Por
a
el contrario, en los robots m´viles quedan lejos los tiempos de programaci´n en
o o
ensamblador para hacer un c´digo eficiente en extremo. La incorporaci´n creciente
o o
del ordenador personal como procesador principal ha abierto el paso a toda suerte
de lenguajes de alto nivel. Hay robots programados con JAVA, con Python, con
C, con C++, Visual Basic, etc. Incluso para robots con microprocesadores suele
haber compiladores cruzados espec´ ıficos que permiten la programaci´n en lengua-
o
jes de alto nivel. Por ejemplo, el robot EyeBot que incorpora el microcontrolador
Motorola 68332, se programa en C.
Normalmente la plataforma de desarrollo suele determinar el lenguaje en el
que se escribe la aplicaci´n, pues se obliga a ello para reutilizar la funcionalidad
o
ya resuelta en la plataforma. Del mismo modo, un conjunto amplio de grupos de
investigaci´n realiza sus desarrollos en C/C++, y la reutilizaci´n e integraci´n
o o o
de su software es m´s sencilla en este lenguaje com´n. Tambi´n hay platafor-
a u e
mas que no imponen un lenguaje determinado a las aplicaciones. Por ejemplo, en
Player/Stage/Gazebo (PSG) [GVH03, VGH03] la funcionalidad se ofrece a trav´s e
de mensajes de red a un servidor, la aplicaci´n puede estar escrita en cualquier
o
lenguaje siempre que respete el protocolo, y existen librer´ hechas en C, C++,
ıas
Tcl, Python, Java y Common Lisp que encapsulan ese di´logo en el cliente. En
a
la plataforma Miro [USEK02] la funcionalidad se ofrece a trav´s de objetos COR-
e
BA que exportan sus interfaces, las aplicaciones pueden escribirse en cualquier

11. 2 SOFTWARE DE ROBOTS 11
lenguaje en el que exista soporte para el estandard CORBA.
Sin duda los lenguajes m´s utilizados en la programaci´n de robots son los
a o
basados en texto, por su flexibilidad y potencia expresiva. Sin embargo, un caso
curioso de lenguaje es el que incluye LEGO para que los ni˜os programen sus
n
robots RCX [BM03], c´digo-RCX, que es completamente visual. En c´digo-RCX un
o o
programa consiste en una columna que se forma encadenando en secuencia bloques
gr´ficos que son instrucciones. Estas instrucciones son de espera, de actuaci´n,
a o
de suma a una variable, etc. Se incluyen bloques condicionales, con dos ramas
salientes, que hacen avanzar el flujo de programa por una de ellas, dependiendo
de alguna condici´n sensorial. Se pueden incluir varias columnas, a modo de hilos
o
de ejecuci´n concurrentes. Tambi´n se utiliza un lenguaje visual en los entornos
o e
Robolab10 y RobotFlow/FlowDesigner [CLM+ 04], que permiten encadenar bloques
gr´ficos funcionales con entradas y salidas. El programa del robot se materializa
a
en una red de bloques que configura un determinado flujo de la informaci´n desde
o
los sensores a los actuadores.
Un lenguaje que tuvo mucha presencia en los primeros a˜os de la rob´tica, y que
n o
rezuma la influencia de los trabajos en Inteligencia Artificial es Lisp. Actualmente
uno de los lenguajes m´s extendidos para programar robots es C. Este lenguaje
a
supone un buen compromiso entre potencia expresiva y rapidez. Como lenguaje
compilado su eficiencia temporal es superior a otros lenguajes interpretados. Hasta
hace unos a˜os gran parte del software proporcionado por los fabricantes de robots
n
estaba codificado en C, como las librer´ de Saphira [Act99] con que se vend´ los
ıas ıan
robots de Activmedia, o el entorno de desarrollo de los robots de RWI [RWI96].
Muchos robots peque˜os se programan en C, como el robot EyeBot [Br¨03] y
n a
el robot LEGO RCX, que se puede programar con una variante recortada de C
llamada NQC [Bau00].
Recientemente se puede observar un crecimiento en los desarrollos y aplica-
ciones en C++. Por ejemplo, el entorno ARIA [Act02] para programar robots de
ActivMedia, el entorno OPEN-R [Son03a, Son03b] de programaci´n del perrito Ai-
o
bo de Sony, la plataforma Miro [USEK02], la plataforma Mobility [RWI99], etc. El
principal avance sobre C es que proporciona la abstracci´n de orientaci´n objetos,
o o
con los mecanismos de herencia y polimorfismo asociados. Potencialmente tambi´n e
simplifica la reutilizaci´n de componentes. Una ventaja m´s es que la portabilidad
o a
desde C a C++ es relativamente sencilla. Este crecimiento refleja la tendencia en
la programaci´n de robots a la orientaci´n a objetos, a encapsular la funcionalidad
o o
en forma de objetos con m´todos que se pueden invocar.
e
10
http://www.ni.com/company/robolab.htm

12. 3 SISTEMAS OPERATIVOS 12
3. Sistemas operativos
Como hemos mencionado, la primera opci´n para el desarrollador de aplicacio-
o
nes rob´ticas consiste en escribir su c´digo sobre la funcionalidad que le proporcio-
o o
na el sistema operativo de la computadora a bordo del robot. La misi´n principal
o
de ese sistema operativo es ofrecer a los programas acceso b´sico al hardware del
a
robot, permitir su manipulaci´n y uso desde los programas. Fundamentalmente
o
debe permitir recoger lecturas de los sensores y enviar ´rdenes a los actuadores.
o
Para ´sto el sistema operativo incorpora drivers que dan soporte software de bajo
e
nivel a los dispositivos f´
ısicos. Por ejemplo, en el B21 [RWI94] el kernel de Linux in-
corpora el driver de la tarjeta ISA a la que se conectan los sensores de ultrasonidos
(Access Bus Card ), y que permite al programa obtener sus medidas.
Si el robot tiene hardware de comunicaciones, t´ ıpicamente inal´mbrico para
a
mayor movilidad, el sistema operativo ofrece el soporte para utilizarlo desde el
programa de aplicaci´n. Por ejemplo, el perrito Aibo incorpora en sus ultimos
o ´
modelos una tarjeta wireless 802.11 para comunicaci´n inal´mbrica. Su sistema
o a
operativo permite al programa el env´ y recepci´n de datos a trav´s de esa tarjeta,
ıo o e
implementando una pila de TCP/IP.
En cuanto a la multitarea, el sistema operativo y las librer´ que los acom-
ıas
pa˜an suele ofrecer la posibilidad de programar con distintos procesos y/o con
n
varias hebras, ya sean con o sin desalojo. Tambi´n suele incluir mecanismos de co-
e
municaci´n interprocesos como la memoria compartida, las tuber´ (pipes), etc. y
o ıas
recursos t´ ıpicos de concurrencia (como los sem´foros y los monitores) para la sin-
a
cronizaci´n, para evitar las condiciones de carrera y los interbloqueos, garantizar
o
exclusi´n mutua, etc.
o
Los sistemas operativos y las librer´ que los acompa˜an suelen incluir tam-
ıas n
bi´n soporte para los elementos de interacci´n del robot, ya sean botones f´
e o ısicos,
pantallas peque˜as, pantallas normales de ordenador, etc. Este soporte permite la
n
creaci´n de interfaces gr´ficas, lo que combinado con las comunicaciones, puede
o a
facilitar la visualizaci´n remota en un ordenador externo.
o
Adem´s de las interfaces de programaci´n, el sistema operativo de un robot
a o
ofrece siempre los medios para cargar distintos programas en ´l y ejecutarlos en los
e
procesadores de a bordo. Esta funci´n es necesaria porque los robots programables,
o
por su propia definici´n, no tienen un c´digo inalterable sino que pueden ejecutar
o o
diferentes programas.
3.1. Sistemas operativos dedicados y generalistas
En el mercado de robots m´viles programables gran parte de los robots pe-
o
que˜os tienen su propio sistema operativo dedicado, muy ligado al procesador, a
n
los sensores y a los actuadores concretos. El sistema operativo ROBIOS en el robot

13. 3 SISTEMAS OPERATIVOS 13
EyeBot [Br¨03] (en la figura 3), Aperios en el Aibo (en la figura 7), o BrickOS11
a
[Nie00] para el LEGO RCX (en la figura 8) son ejemplos relevantes.
Con la irrupci´n de los ordenadores personales (port´tiles o no) como procesa-
o a
dores principales en los robots, los sistemas operativos de prop´sito general como
o
Linux o MS-Windows han entrado en el mundo de los robots. Estos sistemas,
adem´s de los drivers del hardware, incluyen abstracciones y un conjunto muy
a
extenso de bibliotecas gen´ricas, que tambi´n son utiles para la programaci´n de
e e ´ o
robots. Por ejemplo, bibliotecas e interfaces para la multitarea, las comunicaciones
y las interfaces gr´ficas.
a
Figura 3: Robot EyeBot en el corre el sistema operativo ROBIOS
ROBIOS
ROBIOS es una muestra significativa de sistema operativo dedicado. El robot
EyeBot [Br¨03] es un robot de peque˜o tama˜o que viene equipado con un mi-
a n n
croprocesador Motorola 68332 a 35 MHz. Al robot se le conectan dos motores con
encoders, tres sensores de infrarrojos y una c´mara digital. Su hardware tambi´n
a e
incluye una peque˜a pantalla, cuatro botones y un radioenlace. El sistema ope-
n
rativo permite la carga de programas a trav´s de un puerto serie y su ejecuci´n
e o
pulsando los botones. Como acceso b´sico al hardware desde los programas, RO-
a
BIOS incluye una API (Application Programming Interface) con funciones para
recoger las lecturas de los sensores de infrarrojos, para obtener las im´genes de la
a
c´mara y para hacer girar los motores a cierta velocidad.
a
En cuanto a comunicaciones, ROBIOS incluye dos funciones que le permiten
enviar y recibir bytes a trav´s del radioenlace, a otros EyeBots o un PC que se
e
11
El sistema operativo libre para el RCX se llamaba inicialmente LegOS, posteriormente cam-
bi´ su nombre oficial a BrickOS
o

14. 3 SISTEMAS OPERATIVOS 14
encuentren dentro del alcance radio de su antena. En cuanto a la interfaz gr´fica,
a
ROBIOS incluye primitivas para muestrear si los botones est´n pulsados, pintar y
a
refrescar la pantalla.
Con respecto a la multitarea, ROBIOS tiene primitivas para crear hebras, de-
tenerlas durante un tiempo, matarlas, etc. Adem´s ofrece dos modos de repartir el
a
tiempo de procesador entre ellas: con desalojo (en rodajas de tiempo) y sin desalojo
(con un testigo que va pas´ndose de una hebra a la siguiente). Correspondi´ndose
a e
a las hebras de kernel o de usuario t´ ıpicas de sistemas operativos tradicionales.
Tambi´n ofrece sem´foros para coordinar la ejecuci´n concurrente de esas hebras
e a o
y el acceso a variables compartidas.
GNU/Linux
Un sistema operativo generalista que ha ganado gran aceptaci´n en la comuni-
o
dad rob´tica es GNU/Linux [RWI99, GVH03, MRT03]. Este sistema es software
o
libre y cuenta con una comunidad muy activa y amplia de desarrolladores, lo
cual garantiza en la pr´ctica la incorporaci´n al sistema del soporte de los nuevos
a o
dispositivos hardware que van ofreciendo los avances tecnol´gicos. Este sistema
o
operativo es muy potente y robusto, y ofrece sus servicios en forma de llamadas
al sistema y de funciones de biblioteca. Hay llamadas para crear procesos, hebras,
controlar su coordinaci´n, comunicaciones, etc. Adem´s incluye un amplio abanico
o a
de herramientas de desarrollo, como el compilador de C/C++ gcc, el editor emacs,
etc.
Respecto a la multitarea, GNU/Linux incluye la biblioteca Pthreads como re-
ferencia para materializar las hebras de las aplicaciones. Este paquete genera he-
bras POSIX de kernel que se pueden comunicar a trav´s de memoria compartida.
e
GNU/Linux tambi´n ofrece sem´foros para controlar el acceso a esas variables
e a
compartidas o resolver problemas de concurrencia que puedan aparecer. Estos me-
canismos se suman a los que ya ofrece GNU/Linux como creaci´n de procesos,
o
tuber´ fifos, memoria mapeada, etc., que siempre est´n disponibles.
ıas, a
En cuando a comunicaciones GNU/Linux ofrece los sockets para la comunica-
ci´n interm´quina entre varios programas, una abstracci´n que permite olvidarse
o a o
de los detalles de red, protocolos de acceso al medio, etc. En concreto soporta
IP para el nivel de red, y los protocolos del nivel de transporte TCP y UDP. De
esta manera el programador de la aplicaci´n no debe preocuparse de localizar la
o
m´quina destino, ni modificar su c´digo cuando, por ejemplo, el robot se conecta
a o
a la red por ethernet en vez de red inal´mbrica.
a
GNU/Linux ofrece tambi´n las librer´ necesarias para crear y manejar inter-
e ıas
faces gr´ficas en X-Window, que es el sistema m´s extendido en el mundo Unix.
a a
Encima de las librer´ b´sicas (Xlib y Xt-intrinsics), que son flexibles pero
ıas a
complejas, GNU/Linux dispone de varias librer´ que simplifican el manejo de
ıas

15. 3 SISTEMAS OPERATIVOS 15
la interfaz gr´fica, como Qt, XForms, GTK, etc. Una ventaja natural de las inter-
a
faces en X-Window es la visualizaci´n remota: es muy sencillo que un programa
o
ejecut´ndose en un ordenador GNU/Linux (e.g. el ordenador a bordo del robot)
a
vuelque su interfaz gr´fica a otro ordenador GNU/Linux (e.g. el PC de trabajo del
a
programador).
Una de las desventajas del uso de GNU/Linux en rob´tica es que no es un
o
sistema de tiempo real, pues no permite acotar plazos. No ofrece garant´ de plazos
ıa
(tiempo real duro) porque su sistema de planificaci´n de procesos no implementa
o
esas garant´ En este sentido contrasta con sistemas operativos similares como
ıas.
QNX, o la variante RT-Linux. Sin embargo, GNU/Linux resulta suficientemente
a
´gil para los requisitos de aplicaciones no cr´
ıticas. Por ejemplo, permite detener
hebras durante milisegundos.
3.2. Procesadores, sensores y actuadores
El hardware de los robots consiste principalmente en un conjunto de procesa-
dores, sensores y actuadores, y puede incorporar tambi´n elementos de comuni-
e
caciones e interacci´n. Adem´s de ser muy heterog´neo, este hardware evoluciona
o a e
r´pidamente, porque los avances tecnol´gicos proporcionan nuevos y mejores dis-
a o
positivos a un ritmo alto. Este dinamismo se contagia al software, que debe evo-
lucionar continuamente para asimilar el soporte a las prestaciones de los nuevos
dispositivos.
En cuanto a sensores, la tendencia reciente m´s marcada es la incorporaci´n de
a o
la visi´n y del l´ser al equipamiento sensorial de los robots. En primer lugar, las
o a
c´maras son cada vez m´s frecuentes en los robots, tanto monoculares como pares
a a
est´reo. Hasta ahora las m´s utilizadas eran anal´gicas, las cuales sol´ ser caras y
e a o ıan
necesitaban de tarjetas capturadoras (Matrox, BTTV, etc.) con drivers espec´ ıficos
para digitalizar la imagen. En los ultimos a˜os la tecnolog´ ha proporcionado
´ n ıa
c´maras digitales a un precio razonable (principalmente destinadas a aplicaciones
a
multimedia), que se han introducido en los robots como otro sensor m´s. Las a
prestaciones de esas c´maras siguen mejorando r´pidamente, hacia mayor calidad
a a
de imagen, mayor frecuencia, etc. Para dar soporte a estas c´maras y las anteriores
a
en Linux se ha estandarizado la interfaz video4linux. Tambi´n hay soporte para
e
el bus IEEE-1394 (firewire), con el cual se pueden tener dos c´maras digitales
a
capturando a 30 fps sin apenas consumo computacional. La principal dificultad
asociada a las c´maras es que resulta dif´ extraer informaci´n util del enorme
a ıcil o ´
flujo de datos que proporcionan. En segundo lugar, desde finales de los a˜os 90 n
se ha difundido enormemente el empleo del sensor l´ser (por ejemplo de la casa
a
SICK) como sensor de obst´culos en los robots de interiores. Este dispositivo mide
a
la distancia a obst´culos en un haz de 180o , con una resoluci´n de 1-2 cm y precisi´n
a o o
inferior a 1 grado. El l´ser proporciona informaci´n muy precisa de obst´culos, con
a o a

16. 3 SISTEMAS OPERATIVOS 16
una interpretaci´n directa para la navegaci´n.
o o
En cuanto a los actuadores, se ha observado un crecimiento en el n´mero de
u
robots con patas, tanto en productos comerciales (los Aibo de Sony) como en los
prototipos b´ ıpedos (Asimo de Honda, Qrio de Sony). Sin embargo sigue siendo
mayoritario el uso de robots con ruedas, que obvian los problemas de equilibrio
y ofrecen una interfaz m´s sencilla para el movimiento. Tambi´n se aprecia una
a e
tendencia a la miniaturizaci´n: mientras a principios de los a˜os 90 los robots m´s
o n a
exitosos en entornos de investigaci´n eran el B21 o los Nomad, en los ultimos a˜os
o ´ n
son m´s frecuentes robots menores como el Pioneer o incluso los Aibo.
a
En cuanto a los procesadores, antes de 1970 los c´mputos se realizaban fuera del
o
robot. Los ordenadores eran demasiado grandes y pesados para pensar en ponerlos
sobre un robot m´vil. Por ejemplo, el robot pionero Shakey utilizaba una placa
o
de control l´gico en el veh´
o ıculo y un computador SDS-940 fuera para realizar el
an´lisis de im´genes y los c´lculos necesarios. Con el avance de la tecnolog´ (e.g.
a a a ıa
bater´ m´s peque˜as) y la reducci´n en el tama˜o de los ordenadores se tendi´ a
ıas a n o n o
incluir todo el c´mputo necesario a bordo del robot m´vil. Por ejemplo, en los
o o
a˜os 80 el robot Hilare ya utilizaba una red de procesadores espec´
n ıficos dentro de
su estructura mec´nica: IBM 30/33, Intel 8085/86, Sel 32 77/80, etc.
a
Desde comienzo de los a˜os 90 los ordenadores personales (PC) se han insertado
n
como elementos principales de c´mputo en los robots de investigaci´n, primero los
o o
PCs de sobremesa y despu´s los PC port´tiles. El precio relativamente asequible y
e a
el crecimiento exponencial de su capacidad de c´lculo han favorecido esa irrupci´n.
a o
Los procesadores espec´ ıficos son cada vez m´s escasos y se han dejado para tareas
a
de bajo nivel, muy concretas. Por ejemplo, los procesadores digitales de se˜al n
dedicados al procesamiento espec´ ıfico de im´genes; o los microcontroladores para
a
controlar los motores y recoger medidas de sensores con poco ancho de banda
(como los ultrasonidos, los od´metros y los de contacto) que incorporan robots
o
como el Pioneer o el B21 (figura 4).
La configuraci´n de un PC y varios microcontroladores es muy frecuente hoy
o
d´ En los microcontroladores se ejecuta un sistema operativo de bajo nivel, como
ıa.
el P2OS en los Pioneer [Act03], o rFLEX en los B21 [RWI99], y la comunicaci´n o
con el PC se realiza a trav´s del puerto serie RS232, respetando cierto protocolo
e
estable. Esta configuraci´n concentra la mayor parte del c´mputo en el PC, que
o o
es el procesador m´s poderoso, y ofrece la ventaja de que actualizar el PC cuando
a
se queda obsoleto es muy f´cil.
a
En cuanto a la conexi´n de sensores y actuadores con el procesador del PC,
o
el puerto serie es una buena opci´n. Es el caso de los cuellos mec´nicos (pantilt),
o a
los esc´neres l´ser de SICK, sensores de GPS, etc. Otras interfaces estandarizadas
a a
son el bus USB o el bus IEEE-1394. Una opci´n m´s de conexi´n son las tarjetas
o a o
especiales dedicadas, que se enganchan a alg´n bus del PC (ISA, PCI o incluso
u

17. 4 PLATAFORMAS DE DESARROLLO 17
red inalámbrica
802.11b
radioenlace Pentium III
portátil
red ethernet interna
RS232 RS232 RS232 USB
Intel 486 Pentium Pro paquetes SIP
pantilt
Microcontrolador
láser
RS232 Siemens 88C166
RS232
bus de acceso cámara
microcontroladores sónares
odómetros motores
contacto PWM odómetros
motores PanTilt cámara
sónares contacto
Figura 4: Arquitectura de computadores (a) de un B21 (b) de un Pioneer
PCMCIA). Es el caso de la tarjeta que hay en el B21 para s´nares, las tarjetas
o
digitalizadoras de im´genes, etc. Una tercera opci´n son las tarjetas de adquisici´n
a o o
de datos que incorporan conversores A/D, D/A, entradas y salidas tanto digitales
como anal´gicas. Estas tarjetas permiten integrar sensores a muy bajo nivel.
o
4. Plataformas de desarrollo
Las aplicaciones con robots presentan cada vez de mayor complejidad y ofrecen
mayor funcionalidad. Como hemos argumentado en la secci´n 2, escribir programas
o
para robots es complicado. En muchos campos del software se ha ido implantando
middleware que simplifica el desarrollo de nuevas aplicaciones en esos campos; por
ejemplo, Matlab para aplicaciones de ingenier´ CORBA o ACE para aplicaciones
ıa,
distribuidas, J2EE para aplicaciones y servicios web, etc. Este middleware propor-
ciona contextos n´ıtidos, estructuras de datos predefinidas, bloques muy depurados
de c´digo de uso frecuente, protocolos est´ndard de comunicaciones, mecanismos
o a
de sincronizaci´n, etc. Del mismo modo, a medida que el desarrollo de software
o
para robots m´viles ha ido madurando han ido apareciendo diferentes plataformas
o
middleware [USEK02].
Hoy d´ los fabricantes m´s avanzados incluyen plataformas de desarrollo para
ıa a
simplificar a los usarios la programaci´n de sus robots. Por ejemplo, Activmedia
o
ofrece la plataforma ARIA [Act02] para sus robots Pioneer, PeopleBot, etc.; iRo-
bot ofrece Mobility [RWI99] para sus B21, B14, etc.; Evolution Robotics vende
su plataforma ERSP; y Sony ofrece OPEN-R [MGCCM04] para sus Aibo. Otros
fabricantes menos avanzados carecen de plataforma de desarrollo u ofrecen una

18. 4 PLATAFORMAS DE DESARROLLO 18
muy limitada. Por ejemplo, para programar los robots RobuCar y RobuLab de
Robosoft el desarrollador s´lo dispone de unas bibliotecas con primitivas en C que
o
ofrecen una interfaz b´sica, de sistema operativo.
a
Adem´s de los fabricantes, muchos grupos de investigaci´n han creado sus pro-
a o
pias plataformas de desarrollo. Varios ejemplos son la suite de navegaci´n CAR-
o
12
MEN [MRT03] de Carnegie Mellon University, Orocos [Bru01], PSG [GVH03],
Miro [USEK02], JDE [CM02], etc. La mayor´ de estas plataformas se distribuyen
ıa
como software libre por los propios creadores. Al igual que ocurre con los simu-
ladores, mientras los fabricantes buscan que su plataforma sirva para todos sus
modelos, los grupos de investigaci´n aspiran a mayor universalidad y sus platafor-
o
mas tratan de incluir soporte para los robots de sus laboratorios, t´ ıpicamente de
diferentes fabricantes.
El objetivo fundamental de estas plataformas es hacer m´s sencilla la creaci´n
a o
de aplicaciones para robots. Hemos identificado varias caracter´ ısticas que estas
plataformas presentan para lograrlo: uniforman y simplifican el acceso al hard-
ware, ofrecen una arquitectura sofware concreta y proporcionan un conjunto de
bibliotecas o m´dulos con funciones de uso com´n en rob´tica que el cliente pue-
o u o
de reutilizar para programar sus propias aplicaciones. Dedicaremos esta secci´n a
o
describir estas tres caracter´
ısticas.
Aunque hay plataformas m´s y menos completas, en general aumentan la in-
a
dependencia de las aplicaciones respecto del hardware y de los sistemas operativos
subyacentes. Las plataformas establecen un suelo m´s o menos firme para el de-
a
sarrollo de aplicaciones con robots. Son ellas las que asimilan los cambios de bajo
nivel, tratando de mantener la misma interfaz abstracta para las aplicaciones,
tanto en el acceso a sensores y actuadores como a los mecanismos multitarea o
funcionalidades ya asentadas en los robots.
4.1. Abstracci´n del hardware
o
En primer lugar, la plataforma uniforma y simplifica el acceso al bajo nivel.
Normalmente ofrece un acceso a sensores y actuadores m´s abstracto y simple que
a
el que proporciona el sistema operativo. Por ejemplo, si se dispone de un robot
Pioneer equipado con un sensor l´ser SICK, la aplicaci´n puede acceder a sus
a o
medidas a trav´s de las funciones de la plataforma ARIA o pedirlas y recogerlas
e
directamente a trav´s del puerto serie. Utilizando ARIA basta invocar al m´todo
e e
getRawReadings sobre un objeto de la clase ArSick, la plataforma se encarga de
mantener actualizadas las variables con las lecturas. Utilizando directamente el
sistema operativo la aplicaci´n debe solicitar y recoger peri´dicamente las lecturas
o o
al sensor l´ser a trav´s del puerto serie, y conocer el protocolo del dispositivo para
a e
12
http://www-2.cs.cmu.edu/~carmen

19. 4 PLATAFORMAS DE DESARROLLO 19
componer y analizar correctamente los mensajes de bajo nivel.
El acceso abstracto tambi´n se ofrece para los actuadores. Por ejemplo, en vez
e
de ofrecer comandos de velocidad para cada una de las dos ruedas motrices de un
robot Pioneer, la plataforma Miro [USEK02] ofrece una sencilla interfaz de V-W
(velocidad de tracci´n y de giro) para la actuaci´n motriz a trav´s de la clase
o o e
position. Ella se encarga de hacer las transformaciones oportunas, de enviar a
cada rueda las consignas necesarias para que el robot consiga esas velocidades
comandadas de tracci´n (V) y de giro (W).
o
Hattig et al. [HHB03] apuntan que la uniformidad en el acceso al hardware es el
primer paso para favorecer la reutilizaci´n de software dentro de la rob´tica. Esta
o o
caracter´ıstica est´ presente en todas las plataformas que hemos estudiado, aunque
a
cada una lo haga a su manera. En la plataforma ERSP de Evolution Robotics el
acceso al bajo nivel recibe el nombre de Hardware Abstraction Layer, (figura 5)y
en Miro, Service Layer. En OPEN-R, en Mobility y en ARIA la API de acceso a
los sensores y actuadores viene dada por los m´todos de un conjunto objetos. En
e
JDE [CM02] y en PSG el acceso abstracto al hardware lo marca un protocolo, con
vocaci´n de est´ndard, entre las aplicaciones y los servidores.
o a
Con la interfaz abstracta de acceso a sensores y actuadores, m´s o menos es-
a
table, las plataformas favorecen la portabilidad de las aplicaciones entre robots
distintos. Ellas se encargan de materializar la misma interfaz para cada diferente
robot soportado. Por ejemplo, una misma aplicaci´n de movimiento escrita sobre
o
Miro [USEK02] puede gobernar con m´ ınimas adaptaciones robots diferentes como
el B21, el Pioneer o el robot casero Sparrow porque todos ellos est´n soportados en
a
la plataforma. Otro ejemplo m´s, en Miro la clase de sensor distancia vale para
a
dispositivos diferentes como los s´nares, los infrarrojos o el l´ser, cada uno de los
o a
cuales proporciona informaci´n de proximidad a objetos, con sus peculiaridades.
o
4.2. Arquitectura software
En segundo lugar, la plataforma ofrece una arquitectura software determina-
da. Con ello fuerza a escribir las aplicaciones de cierta manera, recortando en
flexibilidad, pero ganando en simplicidad y en portabilidad.
La arquitectura software fija la manera concreta en la que el c´digo de la
o
aplicaci´n debe acceder a las medidas de los sensores, ordenar a los motores, o uti-
o
lizar la funcionalidad ya desarrollada. Muchas son las alternativas software para
ello: llamar a funciones de biblioteca, leer variables, invocar m´todos de objetos,
e
enviar mensajes por la red a servidores, etc. Por ejemplo, la plataforma CAR-
MEN [MRT03] presenta interfaces funcionales, la plataforma Miro la invocaci´n o
de m´todos de objetos distribuidos, la plataforma TCA [SGFB97] requiere del
e
paso de mensajes entre distintos m´dulos, la plataforma JDE [Ca˜03] requiere la
o n
activaci´n de procesos y la lectura o escritura de variables. Esta apariencia de las
o

20. 4 PLATAFORMAS DE DESARROLLO 20
interfaces depende de c´mo se encapsule en cada plataforma la funcionalidad ya
o
desarrollada.
Al escribirse dentro de la arquitectura software de la plataforma, el programa
de la aplicaci´n toma una organizaci´n concreta. As´ se puede plantear como una
o o ı,
colecci´n de objetos (como en OPEN-R), como un conjunto de m´dulos dialogando
o o
a trav´s de la red (como en TCA), como un proceso iterativo llamando a funciones,
e
etc. Esta organizaci´n est´ influida por la arquitectura cognitiva, y supone un mo-
o a
delo de programaci´n, una estructura determinada para escribir las aplicaciones.
o
Hay plataformas muy cerradas, que obligan estrictamente a cierto modelo. Por
ejemplo, en la plataforma RAI [RWI96] los clientes han de escribirse forzosamente
como un conjunto de m´dulos RAI (hebras sin desalojo), con ejecuci´n basada en
o o
iteraciones. Otras arquitecturas software son deliberadamente abiertas, restringen
lo m´ınimo, como PSG o CARMEN.
En cuanto al modelo de programaci´n, una opci´n es organizar la aplicaci´n
o o o
como un unico hilo de ejecuci´n que se encarga de todo. Este modelo monohilo es
´ o
muy sencillo para la programaci´n reactiva: muchas iteraciones por segundo com-
o
probando las condiciones relevantes. Sin embargo, cuando la aplicaci´n rob´tica
o o
crece en complejidad, la programaci´n secuencial se queda corta, y entonces resulta
o
m´s natural la programaci´n concurrente. Las arquitecturas software de las pla-
a o
taformas m´s avanzadas establecen mecanismos concretos para que la aplicaci´n
a o
se distribuya en varias unidades concurrentes. Por ejemplo, la plataforma ARIA
ofrece tareas s´ıncronas y as´
ıncronas (ArPeriodicTask, ArASyncTask, ArThread),
los objetos distribuidos de Miro y de Mobility pueden ser objetos activos, con hilos
de ejecuci´n en su interior, y pueden notificar eventos de manera as´
o ıncrona.
El mecanismo multitarea que ofrece la plataforma envuelve y simplifica la inter-
faz del kernel subyacente para la multiprogramaci´n, en la cual se apoyan siempre.
o
Al igual que ocurre con la interfaz abstracta de acceso al hardware, la interfaz
abstracta de multitarea facilita la portabilidad. Por ejemplo, la de ARIA est´ so-
a
portada sobre Linux y sobre MS-Windows, es exactamente la misma en ambos
casos.
La distribuci´n de las aplicaciones rob´ticas en procesos concurrentes es una
o o
tendencia firmemente confirmada en los ultimos a˜os. La distribuci´n es doble,
´ n o
tanto de un proceso compuesto de varias hebras, como de varios procesos ejecu-
tando en m´quinas diferentes, comunic´ndose a trav´s de la red. Todos los hilos de
a a e
ejecuci´n interact´an y cooperan para el fin com´n de la aplicaci´n. Los m´dulos
o u u o o
de RAI y las tareas as´ ıncronas de ARIA son ejemplos de hebras, con y sin desa-
lojo respectivamente, dentro del mismo proceso. Los servidores y clientes de RAI,
una aplicaci´n sobre PSG, los objetos distribuidos de CARMEN, de Mobility o
o
de Miro son muestras de la aplicaci´n compuesta de varios procesos ejecut´ndose
o a
en m´quinas potencialmente diferentes. Esta tendencia a la distribuci´n tiene sus
a o

21. 4 PLATAFORMAS DE DESARROLLO 21
ra´ıces cognitivas en las arquitecturas basadas en comportamientos, en contraste
con el desarrollo monohilo secuencial que hab´ predominado hasta principios de
ıa
los a˜os 90.
n
La distribuci´n en varias hebras o procesos lleva obligatoriamente a la nece-
o
sidad de comunicaci´n y coordinaci´n entre ellos. Para los hilos ejecutando en la
o o
misma m´quina la plataforma ARIA ofrece variables comunes y varios objetos de
a
sincronizaci´n (ArMutex y ArCondition). Para procesos corriendo en m´quinas
o a
diferentes PSG y JDE ofrecen un protocolo sencillo de mensajes de texto a trav´s e
de sockets. PSG incluye unas bibliotecas con una interfaz funcional para el env´ y
ıo
recepci´n de mensajes hacia/desde el servidor acorde a ese protocolo. Miro y Mobi-
o
lity resuelven la comunicacion entre objetos distribuidos con CORBA; CARMEN
con TCX [Fed94]. ARIA ofrece la clase Arsockets con primitivas de apertura, etc.
para que el programa maneje expl´ ıcitamente las comunicaciones.
4.3. Funcionalidades de uso com´ n
u
En tercer lugar, las plataformas m´s completas incluyen funcionalidades de uso
a
com´n en rob´tica, ya resueltas. El programador puede incorporarlas sin esfuerzo
u o
en su propia aplicaci´n si lo necesita. Adem´s de las librer´ sencillas de apo-
o a ıas
yo, como filtros de color y dem´s, estas funcionalidades engloban alguna t´cnica
a e
rob´tica concreta, relativamente madura, ya sea de percepci´n o de algoritmos de
o o
control: localizaci´n, navegaci´n local segura, navegaci´n global, seguimiento de
o o o
personas, habilidades sociales, construcci´n de mapas, etc.
o
La ventaja de integrarlas en la plataforma es que el usuario puede reutilizarlas,
enteras o por partes. Esta reutilizaci´n permite acortar los tiempos de desarrollo y
o
reducir el esfuerzo de programaci´n necesario para tener una aplicaci´n. Al incluir
o o
funcionalidad com´n, el desarrollador no tiene que repetir ese trabajo y puede
u
construir su programa reutiliz´ndola, concentr´ndose en los aspectos espec´
a a ıficos
de su aplicaci´n. Adem´s, suele estar muy probada, lo cual disminuye el n´mero
o a u
de errores en el programa final.
La forma concreta en que se reutilizan las funcionalidades depende nuevamente
de la arquitectura software y de c´mo se encapsulen en ella: m´dulos, objetos
o o
distribuidos, objetos locales, funciones, etc. Por ejemplo, en PSG se incluye la
localizaci´n como un nuevo sensor y a su funcionalidad se accede intercambiando
o
mensajes con el servidor Player. En Miro la funcionalidad se encapsula en objetos
distribuidos, con sus propios m´todos que se ponen a disposici´n de los dem´s
e o a
objetos. Por ejemplo, en el robot EyeBot las funcionalidades se ofrecen en forma
de librer´ El sistema operativo ROBIOS ofrece primitivas para leer la imagen
ıas.
que est´ capturando la c´mara, y para girar cada rueda motriz a cierta velocidad.
a a
Sobre esas primitivas hay una librer´ que ofrece control V-W y otra con varios
ıa
filtros para las im´genes (filtro Sobel, filtro Laplace, etc.). En Miro, el control V-
a

22. 4 PLATAFORMAS DE DESARROLLO 22
W se ofrece en la capa de abstracci´n del hardware, mientras que en el EyeBot se
o
ofrece como librer´ de uso opcional.
ıa
Figura 5: M´dulos de navegaci´n, visi´n e interacci´n en la plataforma ERSP
o o o o
Otras funcionalidades m´s elaboradas son la navegaci´n de un lugar a otro pla-
a o
nificando trayectorias, la construcci´n de mapas basados en rejillas, la localizaci´n
o o
basada en correspondencia de segmentos, la localizaci´n con filtros de part´
o ıculas,
el procesamiento visual est´reo, etc. Normalmente estas funcionalidades nacieron
e
como t´cnicas novedosas de investigaci´n y al consolidarse van siendo integradas
e o
en las plataformas de desarrollo, tanto en aquellas de grupos de investigaci´n como
o
en las de los fabricantes. De esta manera, la cantidad de bibliotecas disponibles va
creciendo a medida que van madurando las t´cnicas concretas.
e
La plataforma Miro incluye en su Miro Class Framework [USEK02] clases con
algunos comportamientos, con algoritmos de localizaci´n y est´n trabajando pa-
o a
ra incorporar algoritmos de planificaci´n de caminos. La plataforma CARMEN
o
[MRT03] incluye navegaci´n basada en planificaci´n por descenso de gradiente,
o o
de Konolige, y m´dulos con las t´cnicas m´s exitosas desarrolladas en Carnegie
o e a
Mellon como la construcci´n probabil´
o ıstica de mapas de ocupaci´n con forma de
o
rejilla y la localizaci´n dentro de esos mapas siguiendo t´cnicas de MonteCarlo.
o e
Tambi´n incorpora la detecci´n de personas y el seguimiento.
e o
Los fabricantes suelen vender esas funcionalidades por separado o incluirlas
como valor a˜adido de su propia plataforma. Por ejemplo, la empresa ActivMedia
n
proporciona gratuitamente la plataforma de desarrollo ARIA, pero vende sepa-
radamente sus paquetes ARNL para navegaci´n y localizaci´n, la utilidad Mapper
o o
para la construcci´n de mapas y ACTS para el seguimiento de color. La plataforma
o
ERSP incluye tres paquetes sobre su arquitectura b´sica: uno de interacci´n, otro
a o

23. 4 PLATAFORMAS DE DESARROLLO 23
de navegaci´n y otro visi´n, seg´n ilustra la figura 5. En el m´dulo de interac-
o o u o
ci´n se incluye la capacidad de reconocimiento del habla y s´
o ıntesis de voz, para
interactuar de modo verbal con su robot. En el m´dulo de navegaci´n se incluye
o o
la capacidad de construcci´n autom´tica de mapas, la localizaci´n en ellos y su
o a o
utilizaci´n para planificar trayectorias.
o
4.4. Arquitectura cognitiva
Los comportamientos que se han conseguido en robots reales y a los que se
aspira son cada vez m´s ricos y variados, y con ello m´s dif´
a a ıciles de generar. De
manera que los programas que los causan tienden a ser cada vez m´s complejos. La
a
arquitectura software ofrece un modelo de programaci´n, una cierta manera de or-
o
ganizar ese c´digo. Normalmente este modelo resulta suficiente cuando se persigue
o
generar un comportamiento espec´ ıfico en el robot, pero no suele escalar cuando
se quiere integrar en un unico sistema un abanico amplio de comportamientos.
´
Es decir, suele resultar insuficiente cuando la aplicaci´n apunta a un repertorio
o
amplio de conductas artificiales y este repertorio ha de desplegarse coherentemen-
te en cada momento dependiendo de los objetivos del robot y del entorno. Este
problema es muy complejo y al d´ de hoy sigue siendo un tema abierto y activo
ıa
de investigaci´n, no hay una soluci´n universalmente admitida.
o o
Se denomina arquitectura cognitiva de un robot a la organizaci´n de sus capa-
o
cidades sensoriales y de actuaci´n para generar un repertorio de comportamientos
o
[Ca˜03]. Para comportamientos simples casi cualquier organizaci´n resulta v´lida,
n o a
pero para comportamientos complejos se hace patente la necesidad de una bue-
na organizaci´n cognitiva. De hecho, puede llegar a ser un factor cr´
o ıtico: con una
buena organizaci´n s´ se puede generar cierto comportamiento y con una mala no,
o ı
se tiene un codigo fr´gil y la complejidad se vuelve inmanejable. En la comunidad
a
rob´tica han surgido a lo largo de su historia diversas escuelas cognitivas o para-
o
digmas para orientar la organizaci´n del sistema en esos casos. En [Ca˜03] hay una
o n
buena recopilaci´n de los principales paradigmas con sus arquitecturas cognitivas
o
m´s representativas: sistemas deliberativos, reactivos, sistemas h´
a ıbridos (de tres
capas, TCA,...), sistemas basados en comportamientos, basados en etolog´ etc. ıa,
M´s all´ de la interfaz estable para el acceso a un hardware diverso que propor-
a a
cionan las plataformas, la estandarizaci´n del comportamiento artificial, su divisi´n
o o
en unidades reutilizables, es una cuesti´n muy complicada. Hattig et al.[HHB03]
o
opinan que a´n es demasiado pronto para buscar est´ndares en este nivel, en el
u a
modo de generar comportamientos. Recomiendan ce˜irse por ahora la estanda-
n
rizaci´n del acceso a los sensores y actuadores, de lo que ellos llaman bloques
o
constituyentes.
La relaci´n entre las arquitecturas cognitivas y las de software es m´ltiple.
o u
Las arquitecturas cognitivas se materializan en alguna arquitectura software, de

24. 4 PLATAFORMAS DE DESARROLLO 24
manera que los comportamientos generados siguiendo cierto paradigma acaban im-
plement´ndose con alg´n programa concreto. De hecho, las propuestas cognitivas
a u
m´s fiables cuentan con implementaciones pr´cticas relevantes en arquitecturas
a a
software concretas: deliberativas (SOAR), h´ ıbridas (e.g. TCA [Sim94, SGFB97],
Saphira [KM98]), basadas en comportamientos (subsunci´n [Bro86], JDE), etc.
o
Una buena arquitectura cognitiva favorece la escalabilidad de la plataforma.
Hay plataformas software debajo de las cuales subyace un modelo cognitivo,
pero tambi´n hay otras en las que no. No obstante, unas arquitecturas software
e
cuadran mejor con ciertas escuelas cognitivas que con otras. Los sistemas delibe-
rativos cl´sicos cuadran con la programaci´n l´gica (e.g. Prolog), con una des-
a o o
composici´n funcional en bibliotecas (m´dulos especialistas) y con las aplicaciones
o o
monohilo con un s´lo flujo iterativo de control (sensar-modelar-planificar-actuar).
o
Por el contrario, los sistemas basados en comportamientos cuadran mejor con la
programaci´n concurrente, donde se tienen varios procesos funcionando en parale-
o
lo y que colaboran al funcionamiento global. Resulta natural asimilar cada unidad
de comportamiento al concepto software de proceso, o incluso al de objeto activo.
La distinci´n entre arquitectura software y arquitectura cognitiva se hace pa-
o
tente en el ejemplo de Saphira [KM98]. El nombre Saphira antes designaba a la
propuesta cognitiva y tambi´n la plataforma software13 [Act99] asociada. Ahora
e
se han separado, la plataforma se ha reescrito y rebautizado como ARIA [Act02].
Ella ofrece una capa de acceso abstracto al hardware y una arquitectura software
basada en objetos. El nombre de Saphira se ha reservado para el software que ma-
terializa la arquitectura cognitiva h´
ıbrida, la cual se monta encima de ARIA. Esta
separaci´n tambi´n es clara en el caso de JDE [Ca˜03], que ofrece una plataforma
o e n
software de servidores por un lado, y un conjunto de esquemas que materializan
la apuesta cognitiva por otro.
4.5. Plataformas de software libre
Como ya hemos comentado, existen plataformas de desarrollo creadas por los
fabricantes de robots y otras creadas por grupos de investigaci´n. La mayor´ de
o ıa
estas ultimas se publican con licencia de software libre, con la idea de contribuir
´
al libre intercambio de conocimiento en el ´rea y con ello al avance de la dis-
a
ciplina rob´tica. Dedicamos esta secci´n a enumerar las plataformas libres m´s
o o a
importantes; en las referencias se pueden encontrar descripciones m´s detalladas.
a
13
hasta la versi´n 6.2
o

25. 4 PLATAFORMAS DE DESARROLLO 25
Plataforma Robots soportados Sistema Operativo Sw libre
Player/Stage Pioneer, B21 Linux s´
ı
Miro Pioneer, B21, Sparrow Linux s´
ı
CARMEN Pioneer, B21 Linux s´
ı
JMR Pioneer s´
ı
Robotflow/Flowdesigner Pioneer s´
ı
Webots, SysQuake Koala, Kephera no
ARIA Pioneer Linux/MS-Windows s´
ı
OPEN-R Aibo Aperios no
ERSP ER1 Linux/MS-Windows no
Mobility RWI B21 Linux no
Cuadro 1: Tabla con plataformas de programaci´n robots
o
Player/Stage/Gazebo
La plataforma Player/Stage/Gazebo14 (PSG) [GVH03] fue creada inicialmente
en la Universidad de South California. Actualmente est´ mantenida por Richard
a
Vaughan, Andrew Howard y Brian Gerkey. Se compone de dos simuladores Stage y
Gazebo (que ya fueron comentados en la secci´n 2.3), y un servidor Player al que se
o
conecta el programa de la aplicaci´n para recoger los datos sensoriales o comandar
o
las ´rdenes a los actuadores. El soporte a robots variados como los Pioneer, los
o
B21, etc. y los simuladores que incorpora la convierten en una plataforma muy
completa. Ha ganado popularidad y usuarios, actualmente m´s de 20 laboratorios
a
la utilizan en sus proyectos.
En PSG los sensores y actuadores se contemplan como si fueran ficheros [VGH03],
flujos, dispositivos de modo car´cter al estilo de Unix, y por ello se manipulan a
a
trav´s de cinco operaciones b´sicas: abrir, cerrar, leer, escribir y configurar. Para
e a
usar un sensor, las aplicaciones tienen que abrir el dispositivo, quiz´ configurarlo
a
y leer de ´l, cerr´ndolo al final. An´logamente, para utilizar un actuador, las apli-
e a a
caciones tienen que abrirlo, tal vez configurarlo y escribir datos en ´l, cerr´ndolo
e a
al final. Cada tipo de dispositivo se define en PSG con una interfaz, de manera
que los sensores sonar del robot Pioneer y los sensores sonar del robot B21 son
instancias de la misma interfaz. La unica diferencia, invisible para los programas,
´
es que las lecturas se obtienen del sensor concreto empleando drivers diferentes.
El conjunto de interfaces posibles presenta una m´quina virtual, con toda suerte
a
de sensores y actuadores. El robot concreto instancia las interfaces relativas a los
dispositivos realmente existentes.
Adicionalmente, PSG tiene un dise˜o cliente/servidor: las aplicaciones estable-
n
14
http://playerstage.sourceforge.net/