Interesting Survey about different Robotic Software Frameworks for Distributed Robotics

This work identifies many aspects of the distributed robotics and compare ROS and other Robotic Frameworks for distributed robotics. Here I show the abstract:

Abstract

Robotics is an area of research in which the paradigm of Multi-Agent Systems (MAS) can prove to be highly useful. Multi-Agent Systems come in the form of cooperative robots in a team, sensor networks based on mobile robots, and robots in Intelligent Environments, to name but a few. However, the development of Multi-Agent Robotic Systems (MARS) still presents major challenges. Over the past decade, a high number of Robotics Software Frameworks (RSFs) have appeared which propose some solutions to the most recurrent problems in robotics. Some of these frameworks, such as ROS, YARP, OROCOS, ORCA, Open-RTM, and Open-RDK, possess certain characteristics and provide the basic infrastructure necessary for the development of MARS. The contribution of this work is the identification of such characteristics as well as the analysis of these frameworks in comparison with the general-purpose Multi-Agent System Frameworks (MASFs), such as JADE and Mobile-C.

Keywords

  • Robotics;
  • MAS;
  • Agents;
  • Software frameworks;
  • Middleware;
  • Architecture

Basic Rotations with Quaternions

The quaternions is a very interesting mathematical tools that make possible perform rotation operations without using rotation matrices. This method is efficent and secure (avoiding the gimbal lock effect) in dynamic situations. A very interesting explanation about the mathematical foundations and capacities of quaternions can be found here.

The ROS library TF provide several functions to handle quaternions in C++ and Python. There exists many opensource libraries which provides quaternion funciontalities like Eigen, Bullet to name a couple of them.

Rotating a point
ROS works with the right hand axis convention. This axis convention is specially adequate for mobile robots. Here the robot is always looking to the axis-x infinity.

import roslib
roslib.load_manifest('tf')
import tf
from tf.transformations import *

# we want to rotate the point using the x-axis ("roll")
rot=quaternion_from_euler(-numpy.pi/4,0,0)

# the object is located in the y=1. We use the format [x,y,z,w] and w is allways 0 for vectors
vec= [0,1,0,0]

#now we apply the mathematical operation res=q*v*q'. We use this function for multiplication but internally it is just a complex multiplication operation.
result=quaternion_multiply(quaternion_multiply(rot, vec),quaternion_conjugate(rot))

In [33]: result
Out[33]: array([ 0. , 0.70710678, -0.70710678, 0. ])

Concatenate Rotations
Here I show how to concatenate multiple rotations using quaternions:

q1=quaternion_from_euler(-numpy.pi/4,0,0)
q2=quaternion_from_euler(numpy.pi/4,0,0)
q3=quaternion_from_euler(-numpy.pi/4,0,0)
q4=quaternion_from_euler(numpy.pi/4,0,numpy.pi/4)

#the full transform is q4*q3*q2*q1
rot= quaternion_multiply(q4,quaternion_multiply(q3,quaternion_multiply(q2,q1)))
result=quaternion_multiply(quaternion_multiply(rot, vec),quaternion_conjugate(rot))

In [86]: result1
Out[86]: array([ 0. , 0.70710678, -0.70710678, 0. ])

In [90]: result2
Out[90]: array([ 0., 1., 0., 0.])

In [93]: result3
Out[93]: array([ 0. , 0.70710678, -0.70710678, 0. ])

In [96]: result
Out[96]: array([-0.70710678, 0.70710678, 0. , 0. ])

Robotics – Simultaneous Localization And Mapping (SLAM) con ROS

Una tarea muy importante que debe realizar un robot autónomo es adivinar donde está localizado dado un mapa conocido, en  la bibliografía este problema es referido como “el problema de la localización”. Las cosas se complican cuando el mapa también es desconocido: Esta situación se conoce como “The kidnaped robot problem”. En estos casos hay que utilizar técnicas de SLAM (Localización y Mapeo Simultaneo) para ambos: localizarse y construir el mapa del entorno simultáneamente. De forma laxa podríamos decir que se trata de un tipo de exploración del robot en un entorno desconocido. Existen muchas y diversas técnicas de SLAM típicamente para 2D y 3D y utilizando sensores Lasers Rangers, Sonars o Cámaras mono o estéreo.

ROS dispone de varios paquetes para realizar SLAM usando visión  con cámaras y principalmente usando Lasers Rangers: vslam, gmapping, kartoMapping, graphmapping.

Este post trataremos como arrancar un ejemplo básico con gmapping, El objetivo es aprender vagamente como funciona y poder aplicarlo en nuestros proyectos.

El algoritmo GMapping

GMapping es una librería libre perteneciente al proyecto OpenSLAM y que implementa una extensión la técnica SLAM Grid Mapping. En cualquier caso, utilizaremos este software como si fuera una caja negra. Sabemos que su salida son la localización del robot en el mapa y el mapa en si mismo. Como entradas toma  información periódica sobre una estimación de la posición del robot (odometría – calculada por los encoders del motor) y la medida del sensor laser ranger (vector de distancia) en un entorno con superficie plana.

Demo GMapping en ROS

¿Como probar este software en ROS? Sencillo, la gente de Bosch ya ha realizado una demo, con el simulador stage para que podamos abordar el problema. Esta demo está localizado en el paquete explore_stage. Consiste en un mapa desconocido por un robot móvil tipo erratic. Observemos la wiki del paquete vemos la siguiente información de repositorio donde se ubica el código:

Descargaremos todo el directorio […]stacks/exploration/demos ya que contiene algunos paquetes adicionales con mapas y modelos que nos serán necesarios.

geus@geus-vaio:/opt/ros/cturtle/stacks/external/demos$ svn co https://bosch-ros-pkg.svn.sourceforge.net/svnroot/bosch-ros-pkg/trunk/stacks/exploration
[…]
geus@geus-vaio:/opt/ros/cturtle/stacks/external/demos/exploration$ roscd explore_stage/
geus@geus-vaio:/opt/ros/cturtle/stacks/external/demos/exploration/explore_stage$ ls
config   explore.launch       explore_slam.xml  explore.xml   move.xml
explore  explore_slam.launch  explore.vcg       manifest.xml

Como se observa el paquete es muy sencillo, solo algunos componentes .launch con la aplicaciones.  Antes que nada compilemos el stack exploration ya que contiene un paquete exploration/explore con el código para realizar la exploración en el mapa desconocido.

geus@geus-vaio:/opt/ros/cturtle/stacks/external/demos/exploration/explore$ rosmake exploration
[ rosmake ] Packages requested are: [‘exploration’]
[…]
[ rosmake ] Results:
[ rosmake ] Built 53 packages with 0 failures.

En concreto la aplicación de explorar está en el explore_slam.launch. Lanzamos la aplicación:

geus@geus-vaio:/opt/ros/cturtle/stacks/external/demos/exploration/explore_stage$ roslaunch explore_slam.launch

Algunos problemas con Stage

Pueden que los usuarios de ubuntu reciban el siguiente error, debido a los cambios en la política de archivos del servidor gráfico X11. Existe un problema que no se encuentra el archivo rgb.txt que es una base de datos con colores.

[Loading /opt/ros/cturtle/stacks/external/full_organization_repositories/bosh-ros-pkg/bosch_demos/bosch_worlds/maze-noisy.world][Include segway-noisy.inc][Include sick.inc][ INFO] [1291307466.316198795]: Subscribed to Topics: base_scan
err: unable to open color database: No such file or directory (try adding rgb.txt’s location to your STAGEPATH) (/tmp/buildd/ros-cturtle-simulator-stage-1.2.1/debian/ros-cturtle-simulator-stage/opt/ros/cturtle/stacks/simulator_stage/stage/build/Stage-3.2.2-Source/libstage/color.cc Color)

El problema se soluciona de forma sencilla añadiendo a la variable de entorno $STAGEPATH una ruta que contenga un rgb.txt correcto. En nuestro caso, el mismo paquete stage contiene ese archivo. Lo añadimos:

geus@geus-vaio:/opt/ros/cturtle/stacks$ find $ROS_PACKAGE_PATH | grep rgb.txt
/opt/ros/cturtle/stacks/simulator_stage/stage/share/stage/assets/rgb.txt
/opt/ros/cturtle/stacks/simulator_stage/stage/share/stage/rgb.txt
/opt/ros/cturtle/stacks/simulator_stage/stage/build/Stage-3.2.2-Source/assets/rgb.txt
/opt/ros/cturtle/stacks/simulator_stage/stage/build/Stage-3.2.2-Source/libstage/rgb.txt
geus@geus-vaio:/opt/ros/cturtle/stacks$ export STAGEPATH=`rospack find stage`/share/stage
geus@geus-vaio:/opt/ros/cturtle/stacks$ echo $STAGEPATH
/opt/ros/cturtle/stacks/simulator_stage/stage/share/

Ahora si. Lanzamos y ya funciona y podemos ver como arrancan varios procesos definidos en el archivo .launch.

geus@geus-vaio:/opt/ros/cturtle/stacks/external/demos/exploration/explore_stage$ roslaunch ./explore_slam.launch

Otra alternativa es añadir en el archivo explore_slam.launch el valor de la variable de entorno:



...

Interpretación de resultados

Tras lanzar el explore_slam.launch se ejecutan diversos procesos ROS. Entre ellos se abre el simulador stage, mostrado en la imagen. A los pocos segundos, tras algo de proceso el robot empieza a navegar y a explorar su entorno. Para poder ver bien que está ocurriendo podemos abrir la herramienta rviz. Primera imagen de este artículo.

geus@geus-vaio:/opt/ros/cturtle/stacks$ rosrun rviz rviz

Añadimos los visualizadores (plugins) de rviz “map”, “tf” y “laser scan”.

  • “map” – sirve para que podamos ver el mapa que se está construyendo.  Mas concretamente monitorizar los mensajes de tipo nav_msgs/OccupancyGrid publicados en el topic “/map”.
  • “tf” – sirve para monitorizar la posición estimada por el sistema SLAM.
  • “laser scan”- sirve para monitorizar el escaneo laser que está realizando el robot. Mas concretamente mensajes del tipo sensor_msgs/LaserScan

Podemos observar que se han creado tres procesos principales: “/explore” “/move_base” “/stage” “/gmaping”.

  • “/stage”- es el nodo simulador. Se limita a enviar al exterior mensajes de las lecturas del laser y la posición del robot a través del tópic /tf. También acepta comandos de movimiento a través del topic /cmd_vel
  • “/gmaping”- es el nodo que crea que realiza el SLAM. Crea el mapa a partir de la posición estimada y las lecturas del sensor Laser (topic /base_scan de tipo “sensor_msgs/LaserScan”).
  • “/explore” – es el nodo que realiza el algoritmo de exploración. Utiliza el mapa resultante y la posición del robot para estimar zonas donde es mas interesante seguir explorando. Una vez decidido un plan de exploración se lo indica al nodo “/move_base”
  • “/move_base” – es el nodo que se encarga de ejecutar un plan de ejecución. Se trata de un paquete esencial y genérico que ROS provee. Simplente sigue las ordenes del nodo “/explore” y ordena al “/stage” como debe mover los motores haciendo uso del topic “/cmd_vel” de tipo de mensaje “geometry_msgs/Twist
    “, siempre intentando crear una trayectoria sin colisionar.

Esto es todo. Si lográis sustituir el nodo stage por un robot real con odometría y sensor laser, tenéis un sistema de SLAM listo para ser ejecutado.

Saludos y Happy Robotics! 😉

Desarrollo en ROS con Eclipse

Hemos hablado diversos posts sobre la plataforma ROS y ya sabemos de su potencia:

Por desgracia ROS, a pesar de su buena organización y documentación no presenta una curva de aprendizaje rápida. Inicialmente cuesta ubicarse entre tantos paquetes existentes y además el proceso de desarrollo puede ser lento si no se dispone de un IDE adecuado.

Eclipse puede solucionar ambos problemas simultáneamente, nos permitirá desarrollar de una manera mas cómoda y a la vez nos permitirá ubicarnos entre los distintos paquetes de ROS y aprender mas rápidamente. Con Eclipse es mas sencillo navegar entre los ficheros de código, paquetes y stacks. Por ejemplo cuando un símbolo en c++ es extraño para nosotros podemos ir a su definición usando ctrl+ left click. Además el desarrollo de nuevos paquetes es también mas sencillo dado que se puede utilizar el autocompletar. Por último también podrás depurar tu proyecto. Algo bastante importante.

Pasos para poder compilar y usar la herramienta de auto-completar:

  1. Descargar Eclipse con soporte CDT
  2. Establecer el workspace de eclipse en la raíz de la instalación (el directorio base de roscd)
  3. Arrancar desde consola el eclipse (se supone que tenéis registrado en vuestro .bashrc el setup.sh de ROS)
  4. Crear un nuevo proyecto C++ llamado stacks (directorio ya existente, aparecerá un warning)
      • Utilizar el tipo C++ -> Makefile Project -> Empty Project -> Ohter Toolchain
      1. Crear otro proyecto C++ llamado ros (directorio ya existente)
      2. Si te interesa compilar un paquete concreto, en las propiedades del proyecto-> C/C++ Build
          • make -C .
          • make -C . VERBOSE=1
          • rosmake nombrepaquete
        • Elige en BuildLocation-> Build Directory -> La url del paquete que deses compilar (es útil utilizar el botón workspace)
        • Deschequea el checkbox “Use Default Build Command” para utilizar un comando de construcción personalizado. Puedes poner varias alternativas
      3. Establece en el “Build Directory” el directorio del paquete que desees construir (haciendo uso del botón Workspace)
      4. Fin. Estas listo para navegar por el código de ros y recompilar paquetes
      5. Realizar el mismo proceso de creación de un proyecto para la carpeta /opt/ros/cturtle/ros, de esta forma podrás también navegar en las librerías básicas de ROS


        Observaciones:

        1. El autocompletar dentro del proyecto “stacks” funcionará correctamente pero solo con el código que esté situado en stacks. Por ejemplo <ros/ros.h> no funcionará puesto que está en el otro proyecto “ros”, para que funcione el autocompletar hay que establecer los Paths and Symbols en las propiedades del proyecto.
        2. Suponiendo que la instalación del código que estás utilizando es cturtle u otra instalación por defecto proveniente de un repositorio, es interesante crear un enlace simbólico en la carpeta /opt/ros/cturtle/stacks ($ROS_PACKAGE_PATH) a una carpeta externa donde ubiquemos nuestros proyectos y otras descargas o compilaciones manuales (por ejemplo de otros repositorios federados)

        ROS: Como instalar y utilizar un paquete de un repositorio federado

        El proyecto ROS contiene cientos de paquetes software para el desarrollo de sistemar robóticos. Estos paquetes están organizados en repositorios de código. Los paquetes pertenecientes al core y  funciones básicas son administrados por Willow Garage y pueden ser instalados vía svn o vía  gestores de paquetes (http://www.ros.org/wiki/cturtle/Installation). Por otro lado, existe otro conjunto que son administrados y desarrollados de forma abierta por la comunidad ROS: organizaciones, instituciones o incluso ros-hobbilists.  Estos repositorios no son administrados por Willow Garage pero son considerados parte del proyecto ROS.

        Habitualmente se hopsedan en forjas libres (google.code, sourceforge, github, etc.) o en servidores própios de la institución. En cualquier caso, todos son son abiertos y son referenciados en http://www.ros.org formando una federación de repositorios http://www.ros.org/wiki/Repositories y http://www.ros.org/browse/list.php.  Por eso nos referimos a ellos en este post como “repositorios federados”. En este post exponemos un how-to básico sobre como instalar paquetes pertenecientes a un repositorio federado y algunos aspectos interesantes que deben ser tenidos en cuenta.

        Empezamos entonces. IHeartRobotics (http://www.iheartrobotics.com/) es un blog que forma parte de la comunidad ROS y sus miembros administran un repositorio federado: http://www.ros.org/wiki/iheart-ros-pkg . Este repositorio  tiene un paquete que nos interesa: rind (ROS Indicator) . Se trata de una interfaz gráfica básica para controlar los nodos, topics y parameters en ROS. Es una herramienta útil, especialmente para aquellos que estén empezando y se sientan mas incómodos manejando los comandos de consola de ROS. En la documentación de iheart-ros-pkg podemos encontrar la dirección del repositorio (git en este caso): git://github.com/IHeartRobotics/iheart-ros-pkg.git

        Otra opción es ejecutar el comando roslocate para obtener la url del repositorio svn o git en internet:

        geus@geus-vaio:/opt/ros/cturtle$ roslocate svn rind
        git://github.com/IHeartRobotics/iheart-ros-pkg

        Visitamos la forja en sí para echarle un vistazo: ver la organización de directorios, etc. (http://www.ros.org/wiki/iheart-ros-pkg). El primer aspecto que salta a la luz es que es un repositorio que utiliza la tecnología git y que tiene tres stacks (en octubre de 2010): ihr_demos, ihr_tools y rovio

        ¿Dónde ubicar el nuevo software?

        El procedimiento habitual para descargar un paquete de un repositorio federado es /opt/ros/stacks.
        NOTA: La razon de que sea este directorio es que los comandos de consola de ROS (como roscd, rosrun, etc) buscan los paquetes y proyectos en ese directorio.  De hecho, existe una variable de entorno $ROS_PACKAGE_PATH que apunta al directorio base de todos los repositorios.

        geus@geus-vaio:/opt/ros/cturtle/stacks$

        Recomiendo crear un directorio llamado “external” en un lugar seguro y utilizar un enlace simbólico para ubicarlo dentro de stacks. Además recomiendo la siguiente organización de subdirectorios de “external”:

        1. bags -Carpeta donde ubicar archivos .bag (con experimentos grabaso)
        2. demos – Carpeta donde ubicar paquetes de tipo demo. Habitualmente sólo con archivos .launch y sin código.
        3. full_organization_repositories – Carpeta donde ubicar repositorios federados completos, incluidos demos, stacks,  etc. Por ejemplo el repositorio de iheart-ros-pkg o bosh-ros-pkg
        4. packages – Carpeta donde ubicar paquetes individuales descargados cuando no convenga la descarga completa de un stack o un repositorio completo (una especie de sandbox)
        5. stacks – Carpeta donde ubicar las stacks individuales descargados (una especie de sandbox)

        Descargamos ahora, se creará una carpeta llamada IheartRobotics, como el nombre del repositorio git:

        geus@geus-vaio:~$ roscd
        geus@geus-vaio:/opt/ros/cturtle/ros$ cd ../stacks/external/packages

        git clone git://github.com/IHeartRobotics/iheart-ros-pkg.git
        cd iheart-ros-pkg/ihr_tools

        Ahora las stacks y los paquetes instalados son detectados por ROS.
        NOTA: La carpeta iheart-ros-pkg no es  una stack en sí, simplemente un directorio que contiene a las tres stacks.

        geus@geus-vaio:/opt/ros/cturtle/stacks/external/packages$ roscd rind
        geus@geus-vaio:/opt/ros/cturtle/stacks/external/packages/iheart-ros-pkg/ihr_tools/rind$

        El siguiente paso sería solucionar las dependencias y compilar el código via rosdep y rosmake.

        NOTAS: Las dependencias son paquetes “third-party” que deben ser instalados para el funcionamiento del paquete. Por ejemplo un paquete de ROS con una interfaz gráfica podría necesitar tener instalado el paquete libgtk2.0-dev (en ubuntu). No es extraño pensar que las dependencias pueden ser un infierno, mas aún teniendo en cuenta que distintas versiones de linux utilizan distintos gestores de paquetes (apt, yum, etc.) y que los nombres de paquetes pueden cambiar.

        ROS soluciona el problema de las dependencias mediante el comando rosdep. Primeramente, las dependencias de las stacks y los paquetes son especificadas en los archivos rosdep.yaml y stack.xml o manifest.xml.  Luego se ejecuta el comando “rosdep install”. En cualquier caso,  la mayoría de paquetes de ROS no tienen dependencias externas y en el caso contrario es habitual que estén añadidas directamente en el paquete en el directorio /lib o /dep. De este modo se pretende evitar problemas de compatibilidad con nuevas versiones, etc.

        geus@geus-vaio:/opt/ros/cturtle/stacks/external/packages/iheart-ros-pkg/ihr_tools/rind$ rosdep install ihr_tools    (ya que en este stack.xml y rosdep.yaml están especificadas las dependencias)
        geus@geus-vaio:/opt/ros/cturtle/stacks/external/packages/iheart-ros-pkg/ihr_tools/rind$ rosmake rind

        Hemos completado el proceso, ahora podemos ejecutar ejecutable contenido en el paquete:
        NOTA: habitualmente los ejecutables en un paquete representan un nodo dentro de la arquitectura distribuida de tu sistema robótico. Estos nodos necesitan que el proceso roscore esté funcionando. Sin embargo esto no tiene por que ser así. Por ejemplo rind es una herramienta que arranca ella misma el roscore.

        geus@geus-vaio:/opt/ros/cturtle/stacks/external/packages/iheart-ros-pkg/ihr_tools/rind$ rosrun rind rind

        El robot Lego NXT ya funciona en ROS

        ROS <http://www.ros.org/wiki/> es posiblemente la plataforma de desarrollo de arquitecturas software robóticas mas potente de la actualidad y con mayor proyección a medio y largo plazo. Una de sus principales filosofías es integrar el mayor número de tecnologías populares(tanto HW como SW) ya desarrolladas. Siguiendo esta filosofía los chicos de ROS han sacado un paquete para el uso del robot “Lego NXT”. <http://www.ros.org/wiki/nxt>  Está basado en el software Python-NXT e implementa los sensores/actuadores: motor, bumper, ultra-sonido, sensor de color, giróscopo y acelerómetro (todos ¿no?)

        Bien ¿Que ventaja nos trae ROS para programar con el NXT que no  tuviéramos de antemano con el software de fábrica?

        – Muchas, La principal ventaja es que puedes reutilizar mucho software hecho para ROS y que ya funcionan para otros robots móviles. Por ejemplo: hay un paquete (robot_pose_ekf <http://www.ros.org/wiki/robot_pose_ekf> – Filtro de Kalman Extendido) que es capaz de integrar y fusionar la información que proviene de múltiples sensores: la odometría de los motores, un sonar y un giróscopo. De este modo, la posición en el plano del robot es mucho mas fiable que la que se podría conseguir con la típica técnica de ir integrando los ticks de la odometría (ya que a medida que el robot se mueve van acumulando error en la posición, debido a micro-deslizamientos de las ruedas).

        Esta técnica permite navegar por edificios e ir construyendo mapas mientras que el robot se autolocaliza (SLAM) de una forma mucho mas precisa y que antes hubiera costado semanas de trabajo e investigación. También teóricamente se pueden utilizar otros muchos paquetes mas (como los relacionados con auto-localización en un mapa y construcción de mapas). Otra ventaja es que puedes utilizar un visualizador genérico (rviz) de robots de forma que nos muestre qué está viendo el robot en cada instante en un entorno virtual 3D (creo que esto no lo tenía el software estándar del NTX). En fin… canela fina 🙂

        Os recomiendo que echéis un vistazo al vídeo aquellos que el NXT os sea familiar:

        Como desventaja comentar que ROS tiene una curva de aprendizaje algo mas dura respecto a la que pueda tener utilizar la API de c# o Java para Lego, además se necesita algo de soltura en sistemas unix, preferiblemente ubuntu-linux, python y/o C. (Aunque presumiblemente ROS funciona también con JAVA,LISP, MATLAB, URBI, LUA, etc. no se, habrá que investigar)

        ROS: ¿El nuevo estándar de facto en robótica?

        ROS corre el riesgo de convertirse en el estándar de facto en el desarrollo de sistemas robóticos. Los chicos de Willow Garage no paran de sorprender a todo el mundo y convierten en oro todo lo que tocan. Lo genial de la historia es que la SpinOff de Stanford publica como software libre todo el código que desarrolla, están mas que abiertos a la colaboración y documenta todo de manera excelente realizando grandes esfuerzos de divulgación. Todo un ejemplo.

        Sigo a este grupo desde hace un año (casi desde su nacimiento) y sinceramente, los admiro profundamente. Para el que no sepa que es esto de ROS, intentaré hacer una breve introducción (aunque es muy complicado porque tiene muchísimas cosas):

        ¿Qué es ROS?

        El nombre de ROS viene de  “Robot Operative System” ROS puede clasificarse como un Framework de Desarrollo en Robótica (RSF) y ofrece herramientas y librerías para el desarrollo de sistemas robóticos. A pesar de su nombre, ROS no es  un sistema operativo propiamente dicho (de hecho funciona sobre linux), sino de una infraestructura de desarrollo, despliegue y ejecución de sistemas robóticos así como una gran federación de repositorios que  ofrecen paquetes con software  de todo tipo para robots. A diferencia de la mayoría de los RSFs existentes, ROS pretende dar una solución integral al problema de desarrollo de robots aportando soluciones a las áreas de:

        • Abstracción de Hardware (HAL) y reutilización e integración de robots y dispositivos encapsulando estos tras interfaces estables y manteniendo las diferencias en archivos de configuración.
        • Algoritmos de robótica con bajo acoplamiento: desde algoritmos de bajo nivel de control, cinemática, SLAM, etc. Hasta algoritmos de alto nivel como planificación o aprendizaje. También otros muchos mas específicos como: como lograr que el robot X coja un objeto o el robot Y se autoenchufe a la red eléctrica.
        • ROS provee de un mecanismo comunicaciones (middleware) distribuido entre nodos del sistema robótico. Un nodo es cualquier pieza de software del sistema (desde un algoritmo SLAM hasta un driver para el manejo de un motor). El objetivo de este sistema es doble: 1- encapsulado/abstracción/reutilización de software e 2- ubicuidad, es decir, independencia de donde este nodo está localizado (un sistema robótico puede tener muchos procesadores).  Estos nodos se comunican entre ellos mediante mecanismos de paso de mensajes RPC o Publish/Subscribe, Service lookup, etc. Permite crear arquitecturas P2P de componentes robóticos distribuidos.
        • Simulación de sistemas robóticos en mundos virtuales con dinámicas de sólidos rígidos.
        • Herramientas de desarrollo, despliegue y monitorización de sistemas robóticos.

        Para darle algo de alegría al post, adjunto un vídeo con un poco de acción. Este es uno de las decenas de vídeos en youtube sobre ROS, trata sobre la herramienta de monitorización rviz, puede servir para que veáis un poco la esencia de ROS:

        ¿Qué ofrece respecto a otros RSFs?

        Pocas cosas en ROS son auténticamente nuevas a nivel técnico, ROS parece estar inspirado en muchos otros RSFs existosos como Player/Stage/Gazebo, Yarp, Orocos, Carmen, Orca, OpenRave, Open-RTM (todos ellos OpenSource) e incluso en muchos aspectos se asemeja a tecnologías mas lejanas como JADE (Sistemas Multi-Agentes). Sin embargo, ROS ha logrado agrupar las muchas de las mejores características de todos estos proyectos dando una solución integral y muy uniforme al problema de desarrollo de sistemas robóticos. En se caracteriza por ser una plataforma multi-lenguaje (c++,python,octave,java), peer2peer, orientado a herramientas, ligero y OpenSource. En cualquier caso, en este post no me quiero centrar en los aspectos técnicos (a pesar de que se trata de una plataforma técnicamente genial).  Para conocer mas sobre ella mejor echarle un vistazo a su wiki http://www.ros.org/wiki o a este paper del ICRA 2009 (primer paper de ROS del que tengo noticia) que presenta una buena introducción:

        http://pub1.willowgarage.com/~konolige/cs225B/docs/quigley-icra2009-ros.pdf

        En cualquier caso, ROS destaca por su filosofía, su comunidad, en el COMO están siendo capaces de empatizar con la comunidad del software libre y el mundo universitario y de investigación.

        ¿Quienes están por detrás de todo esto?

        Se trata de un proyecto de Software Libre con el apoyo de una empresa llamada Willow Garage. Sabemos por experiencia que el apoyo de empresas en proyectos de software libre fomenta la promoción del mismo,  dos ejemplos claros son Eclipse y  Ubuntu. Además WillowGarage es una SpinOff de Stanford y cuenta con el apoyo y contacto con grupos de investigación como STAIR y profesores reconocidos como Gary Bradsky (principal responsable del famoso proyecto de visión artificial OpenCV). Todos estos factores son una garantía, Stanford es una de las cunas de la informática y la robótica, allí han nacido empresas tan importantes como Apple o Google. En cualquier caso su uso y apoyo se está extendiendo fuera de estas fronteras, muchas universidades de todo el mundo están comenzando a desarrollar sus investigaciones con ROS, desde América a Japón, pasando por Europa. También a muchos, le sonará Brian Gerkey, uno de los principales responsables del proyecto Player(probablemente el RSF mas reconocido hasta la fecha), él actualmente forma parte del equipo de ROS, ahí lo dejo.

        ¿Cúal está siendo la clave de su éxito?

        Son muchas las razones, pero desde mi punto de vista la clave de su éxito es su filosofía: científica, divulgativa, abierta e integradora.

        • Científica. Muchos de los paquetes mas importantes desarrollados van acompañados de artículos científicos. Además como ya he comentado, están respaldados por universidades, grupos de investigación e investigadores reconocidos.
        • Divulgativa. Se nota la influencia de jóvenes investigadores y desarrolladores de la generación web2.0 porque hacen uso de estos medios de forma masiva. ROS es un proyecto que puede considerarse una ametralladora de conocimiento: RSS, Vídeos en Youtube, Blogs, Wikis, Tweeters, Cursos online, etc. Todo lo que saben lo enseñan y lo comparten en Internet. En ocasiones es tanto lo que hacen y comparten que es difícil para una persona que no se dedique a la investigación seguir día a día sus progresos. Es sorprendente el volumen y la organización de la documentación, mas aún sabiendo que se trata uno de los clásicos puntos débiles de los proyectos de software libre.
        • Abierta. El software que hacen es libre, el software que utilizan es libre. La mayor parte de paquetes desarrollados ofrecen una rica documentación (una de las mayores lacras en el mundo del software libre), tutoriales, etc.
        • Integradora. Su filosofía es no reinventar la rueda. Sería insensato, mas en un área como la robótica donde es necesario una infraestructura basada en un sólido ecosistemas software. Exitosos proyectos de software libre de diversa índole son utilizados: cmake, Boost, Yaml, Opencv, Python, Ogre, Gazebo, Stage, etc. Además también reutiliza o es compatible parcialmente con otros RSFs como OpenRave, Player o YARP.

        Conclusiones

        En mi opinión en que nos encontramos en un momento de cambio, un punto de inflexión en la historia del desarrollo de robots. Una robótica mucho mas accesible por y para todos. Las posibilidades se multiplican. Una mina para la creatividad.

        Por fin encontramos una plataforma de desarrollo robótica que ofrece el suficiente potencial, estabilidad y aceptación para el avance de la robótica a un ritmo mucho mayor. Creo que en los próximos años escucharemos hablar de ROS hasta en la sopa. Además, por fin, los informáticos vamos a encontrar el lugar en la robótica que nunca tuvimos.  Se reconocerá mas la labor del ingeniero informático. Una robótica donde las arquitecturas software, los sistemas distribuidos y la inteligencia artificial cobran vital importancia.

        LLamada a la colaboración

        Somos muchos los estamos interesados en el desarrollo de la robótica en el mundo del software libre. Somos muchos los que queremos aprender robótica compartiendo el conocimiento, entre todos y sin miedo. En el Departamento de Arquitectura y Tecnología de Computadores de la E.T.S.I. Informática de Sevilla estamos empezando a apostar por esta plataforma y queremos promover su uso. Se ha creado un grupo de alumnos internos dedicado a la robótica y la experiencia está siendo muy positiva. Aquellos que estén interesados en compartir, charlar y aprender pueden ponerse en contacto con nosotros.

        Otro buen punto de contacto, son las asociaciones de la escuela, están abiertas para gente de dentro y fuera de la escuela, asociaciones como el Simulation Student Chapter, grupo de robótica del club .NET, IEEE o Sugus son lugares excelentes para crear comunidad. En concreto estoy interesado personalmente en dar un impulso a los dos primeros grupos (a los que pertenezco) en las próximas semanas para fomentar y promover la creación de comunidad alrededor de estas tecnologías, ya veremos como va la cosa :-). En cualquier caso, sed todos bienvenidos, estamos en contacto.