Saltar al contenido

1

En unas declaraciones recientes, Richard Stallman avisa de que el cloud computing es una trampa. Hay parte de verdad en esta advertencia, pero no debemos cogerla cómo una negación del cloud computing.

Por un lado, es innegable que se trata de un término comercial. Como dice Stallman es un nombre nuevo a algo antiguo. Por otra parte, creo que necesitamos nombres nuevos cuando cambia algún aspecto antiguo. Dónde antes teníamos software embebido para terminales móviles, software de escritorio y programación web, ahora tenemos aplicaciones en nube. El objetivo debe ser unificar la programación en la medida de lo posible, la aplicación es única. Por ejemplo, el dúo outlook + blackberry, por mucha integración que haya no es comparable a acceder a gmail desde cualquier dispositivo.

Por otra parte, el miedo a la pérdida de privacidad es una cuestión de confianza, las empresas deben demostrar a los clientes que son dignas de su confianza.

Pero cuando Stallman habla de trampa, se refiere a que el software no es modificable, no sabemos que procesamiento de nuestros datos se estarán haciendo. Esto es un peligro inerente al software propietario y es independiente de si un software se usa en nube, en escritorio o en web. La solución es sencilla: frente a blogger, tenemos wordpress. Uno es cerrado y no sabemos cómo se manipulan nuestros datos, el otro es abierto y tenemos acceso al código fuente.

El peligro no es la nube, sino el software propietario. Al igual que linux se extendió lo suficientemente en un momento en que microsoft dominaba el mercado, surgirá la correspondiente aplicación libre en caso de que lo necesitemos.

6

En la asignatura de robótica del posgrado de inteligencia artificial de la Uned me he puesto a trastear con Player/Stage, uno de los entornos de robótica propuestos para hacer las prácticas. De entre los entornos que nos han sugerido, este era el que me parecía más interesante: open source, basado en linux, con entorno de simulación y ejecución y muy usado en diferentes robots y concursos.

En un primer momento, player/stage resulta un poco frustrante: la interfaz de usuario no es muy usable y la documentación no es demasiado completa. La curva de aprendizaje es un poco alta, pero con ponerse manos a la obra y hacer muchas pruebas se consegue que funcione.

El sistema se compone de 3 partes:

  • player: es el controlador del robot, se trata de un servidor tcp que ejecuta sobre el robot y sirve interfaces para controlarlo. La tarea del desarrollador es hacer un cliente que interactúe con player.
  • stage: se trata de un simulador de robots en 2D. No es demasiado detallado, pero al ser simple puede incluir un número alto de robots simultáneamente.
  • gazebo: es un simulador en 3D más realista, lo que hace que sea más lento y no apto para un número alto de robots.

Sólamente he tratado con el entorno player/stage para simulaciones en 2D, así que sólo comento estos módulos, nada sobre gazebo por ahora.

En cuanto a player, es el módulo que define la arquitectura del sistema. Cómo arquitectura de desarrollo es muy interesante: por un lado hay un entorno servidor que se ejecuta sobre el robot (real o simulado) que recibe peticiones tcp. Por otro hay un cliente que accede a ese robot, para lo que nos dan unas librerías cliente que nos evitan trabajar a bajo nivel. Para controlar un robot a través del servidor player existen una serie de interfaces (por ejemplo position2d para mover un robot en 2 dimensiones) que son implementadas por unos drivers (por ejemplo, un driver para el robot pioneer que implemente la interfaz position2d).

El desarrollador sólo necesita escribir un programa cliente que haga uso de los interfaces, normalmente a través de librerías cliente implementadas en diversos lenguajes de programación (C, C++, python, java). Las librerías se encargan del trabajo sucio de contactar con el servidor y enviar mensajes, y sólo necesitamos usar los interfaces para controlar nuestro robot. Con esta arquitectura, un mismo cliente que use unos interfaces, puede controlar diferentes robots que tengan los drivers apropiados para implementar los interfaces (incluso aunque el hardware sea muy diferente).

El servidor se configura de forma bastante sencilla con unos ficheros que definen dispositivos (devices): son asociaciones entre interfaces y drivers. Por ejemplo, el interfaz laser define el api para interactuar con un medidor de distancia láser (laser ranger). Un programa cliente sólo usa ese interfaz. Sin embargo tenemos un robot equipado con un sensor SICK LMS 200 que implementa el interfaz laser a través del driver sicklms200. En nuestro fichero de configuración, debemos definir un dispositivo que asocie el interfaz laser y el driver sicklms200:

driver
(
name "sicklms200" # The driver's name
provides ["laser:0"] # The device address
)

Si tenemos un programa cliente, este accedería al dispositivo "laser:0" que implementa el interfaz "laser", usando el driver "sicklms200".

Siguiendo esta sencilla arquitectura de drivers/interfaces/dispositivos podemos controlar nuestro robot. En mi caso, he hecho pruebas con python que, aunque no está totalmente documentado, se puede usar intuitivamente con la documentación de la librería cliente de C. Player se trata de una especie de sistema operativo para la robótica, definiendo los interfaces básicos para controlar un robot, pero que se ejecuta sobre tcp, lo que lo hace bastante flexible.

Ahora vamos con stage. Se implementa cómo un driver para player, así que necesitamos configurar un servidor player con un driver stage que se encarga de simular el robot ó robots. Esto difiere de la arquitectura player para un robot físico: para cada robot, deberíamos tener un servidor player diferente. Sin embargo en un entorno simulado con stage, tenemos varios robots simulados en un sólo servidor player. Además el servidor ejecuta una interfaz gráfica para mostrar los resultados de la simulación. El modelo del mundo se define en un fichero de configuración del mundo, donde definimos los objetos y robots que hay en el mundo y el plano del mundo se define en un fichero de imagen (jpg por ejemplo). Al ejecutar la simulación, vemos el plano del mundo con los objetos definidos incluyendo los robots. Si ejecutamos nuestro cliente, se actualiza la posición del robot el plano del mundo. El mismo cliente nos sirve para interactuar con un entorno simulado o real, sin ningún cambio: siempre interactúa con un servidor player.

El problema de esta arquitectura de simulación es que algunos drivers no están implementados en stage, como por ejemplo el driver amcl para localización (que devuelve una estimación de la posición en un mapa). Para usarlo es necesario definir un segundo servidor que utilice los interfaces del robot simulado. Hay ejemplos y es sencillo de realizar (aunque el algoritmo de localización no me terminó de funcionar) pero es enrevesado de configurar.

El conjunto player/stage como entorno de simulación funciona bastante bien, es bastante rápido y creo que lo suficientemente detallado. Podemos acceder a casi todos los interfaces de los robots simulados y he trasteado con sensores láser y sónar para generar mapas a partir de ellos. Me ha faltado probarlo con un robot real, para comparar la calidad de la simulación, pero no tengo acceso a ninguno de los robots reales.

En definitiva, se trata de un entorno bastante completo, con mucho código ya desarrollado y además open source. La parte negativa es que player ejecuta sobre linux, así que necesitaremos un hardware que ejecute el kernel y algunas dependencias, lo que nos limita a efectos prácticos a arquitecturas pc (esto significa robots caros). También hay que tener en cuenta que al ejecutar sobre tcp, la latencia puede darnos problemas.

Por el tipo de módulos existentes (mapas, localización, etc) parece más indicado para sistemas deliberativos o híbridos, pero el el sistema es completamente agnóstico en este aspecto, sólo define interfaces que podemos usar cómo queramos. En este sentido sería interesante desarrollar las librerías cliente, que actualmente se limitan a ofrecer los interfaces sin profundizar en las estructuras de control reactivo o deliberativo.

Por cierto, por falta de tiempo no podré terminar la asignatura a tiempo y probablemente repita el año que viene 🙁 lo bueno es que podré profundizar un poco más en ella.

En libelium, han lanzado un concurso sobre hardware abierto basado en Arduino. Al concurso se puede presentar cualquier proyecto en las categorías de hacks, arte y robótica. El premio es un módulo GPRS/GPS para arduino, que ha desarrollado libelium.

Para los que no lo conozcan, arduino es un proyecto open hardware/software muy interesante. Básicamente se trata de una tarjeta con un microcontrolador AVR, pensado para creaciones artísticas y que incluye un entorno de desarrollo multiplataforma (linux, mac, windows). La idea original es facilitar la vida de los artistas audiovisuales que quieren experimentar con electrónica, siguiendo la idea del physical computing . Pero como arduino es muy versátil, se ha usado para muchas más cosas y poco a poco se ha ido extendiendo a otros campos como la robótica. Personalmente, tengo 2 tarjetas arduino sin usar y en mente la nueva versión con bluetooth, que las usaré como base para mi robot de escritorio que todavía no ha nacido.

(Nota: No tengo ninguna relación comercial con libelium, ni con arduino)

He estado mirando plataformas open source de robótica y no parece que haya demasiado. Rectifico, no parece que haya ninguna plataforma muy extendida, sino que hay muchas iniciativas pequeñas intentando hacerse un hueco.

Probablemente la más importante sea el entorno player/stage/gazebo. En algún momento no sé dónde he leído que este entorno comenzó a desarrollarse en las competiciones de robosoccer y se ha extendido bastante. Mi idea preconcebida era que estaba demasiado orientado a este tipo de competiciones, pero parece que no es así. Tendré que mirarlo con más detalle.

Un entorno similar pero menos desarrollado es The rossum project. Aparentemente no ha alcanzado el mismo grado de popularidad y no parece que tenga demasiada aceptación. No está muerto, pero parece en vía muerta.

Otro entorno libre es TeRK, pero en este caso me pareció demasiado vinculado la plataforma Qwerk, así que de momento no creo que lo mire.

Open automation project tiene buena pinta, pero no se actualiza desde hace mucho (2003). Curiosamente sigue recibiendo mucho tráfico y muchas descargas. En principio parece bastante interesante, pero diría que es un proyecto zombie.

Hay dos que son semi-abiertos: urbi y claraty. El enfoque de urbi me gustó bastante (de hecho, salvando las distancias de complejidad me recordó a mi proyecto de fin de carrera), se trata de un lenguaje interpretado bastante sencillo para control de un robot. La pena es que el intéprete depende de la plataforma y no es libre. Claraty se liberó con una licencia pública pero que no es libre (en particular no permitía el uso comercial). Si estos proyectos cambiasen de licencia, serían muy interesantes.

¿Alguien conoce otras plataformas libres?

Actualización: Una que se me había pasado, orocos. También tiene buena pinta y es completamente open source, sin embargo ha evolucionado más hacia control que hacia robótica. Intentaré echarle un ojo, a ver qué ofrece.

Aunque ya había visto el proyecto TeRK anteriormente, me he animado a echarle un vistazo más en detalle después de leer un artículo en kurzweilAI, Democratizando el diseño de robots.

TeRK es una iniciativa de Carnegie Mellon University que propone un conjunto de recetas, proyectos, ideas, etc, para fomentar el desarrollo de la robótica, sobretodo para los niños. El principal módulo de teRK es Qwerk, que se trata de un ordenador basado en un micro ARM que ejecuta linux, lo que le permite conectar dispositivos USB, como cámaras web y adaptadores de red wifi. Tiene bastante software que se puede descargar de forma gratuita y parece que todo el software es libre con licencia GPL.

TeRK tiene ideas que le pueden llevar al éxito: software open source y uso de componentes hardware estandarizados (cámaras y wifi usb). Quizá falle en que está demasiado enfocado a una plataforma en concreto, Querk y el éxito del proyecto dependerá del éxito de esta plataforma.