domingo, 14 de octubre de 2012

Elección de un RSF (Middleware para robots) adecuado.


Voy a tratar de enlazar lo antes posible el asunto de los middleware de robots, porque mi intención es comenzar un pequeño tutorial para todo aquel que desee hacer sus experimentos.

Lo primero que hay que tener claro es el tipo de entorno en el que vamos a desarrollar los experimentos, los requisitos de nuestro experimento (osea lo que vienen siendo requisitos no funcionales en ingeniería del software), y el hardware del que disponemos (requisitos no funcionales). De estos factores se desprenderá la dificultad del conjunto y las características a las que deberá cumplir el RSF. 

Existen muchos artículos de investigación que hacen una recopilación de los middleware mas extendidos y sus características, con lo que consultándolos se podría hacer una aproximación a la elección.

Ref: 
  • PabloIñigo-Blasco, Fernando Diaz-del-Rio, Mª Carmen Romero-Ternero, Daniel Cagigas-Muñiz, Saturnino Vicente-Diaz, "Robotics software frameworks for multi-agent robotic systems development", Robotics and Autonomous Systems 60(2012).
  • Ayssam Elkady y Tarek Sobh, "Robotics Middleware: A Comprehensive Literature Survey and Attribute-Based Bibliography", Journal of Robotics Volume 2012, Article ID 959013, Enero 2012.
  • Nader Mohamed, Jameela Al-Jaroodi y Imad Jawhar, "Middleware for Robotics: A Survey", (RAM 2008), Septiembre 2008.

Bien, pondré un supuesto con el cual se hará la elección.

En principio plantearemos un entorno controlado como el interior de una casa o un patio, donde cualquiera puede hacer sus pinitos en robótica avanzada. Además asumiré que el experimento será un éxito con tan solo mover el robot y obtener una posición. Y por último, el hardware que se usará es un turtlebot.

Dados estos requisitos, parece obvio que lo mejor es usar ROS, ya que Willow Garage es el desarrollador de este robot y a estas alturas se trata del RSF más extendido y con más futuro. El problema es la gran capacidad de disco que requiere, la falta de versión para programar en otros leguajes de programación que no sean C++, y la total imposibilidad de instalarlo en otros sistemas que no sean Unix like.

Para un experimento de pocas pretensiones, muy versátil, accesible a todo el mundo (no necesario saber de GNU/Linux) y con posibilidad de hacer todo tipo de simulaciones antes de llevar el software al robot, mi elección es la de Player/Stage. El uso de Player/Stage nos permite abaratar más el robot, y podríamos ahorrarnos el poner una Kinect e incluso usar el ipaq como equipo de computo (bueno esto es por frikismo de mi parte)

Bien, Player/Stage es un robotics software framework cuya comunicación se realiza entre el cliente y el servidor de los datos por TCP. Este es uno de los aspectos más débiles del middleware, pero dado que el software cliente estará funcionando en una red local o incluso dentro del mismo turtlebot, y no habrá un flujo de datos abrumador, no tiene mucho sentido preocuparse por este aspecto. Lo mas interesante, además de la multiplataforma, es su plena integración con el simulador Stage. 

Stage simula las lecturas de datos de los sensores y componentes con los que se conforme el robot, por lo que el algoritmo que queramos probar en el software cliente de nuestro turtlebot podrá ser probado en simulación. Esto ayuda a la depuración y mejora antes de pasar a la acción real, la detección de fallos es esencial, pero también podremos inducir a ellos introduciendo ruido aleatorio en las lecturas para ver que tal se comporta.

Player provee de los datos al clientes mediante unos proxies, que a su vez están conectados a los drivers del hardware de forma que hacen de capa de abstracción para facilitar la vida al desarrollador. Estos drivers a su vez están conectados a Stage que sustituirá al hardware cuando se simule.

Esquemas del funcionamiento.


Esquema de Player-Hardware


Esquema Player/Stage


Recopilamos el porque he dedidido usar Player/Stage:

-Muy extendido, por lo que tiene una comunidad de usuarios amplia que puede ayudar.
-Ocupa poco en disco.
-Programación en varios lenguajes.
-Portado a distintos SO.
-Simulador integrado de serie.
-Soporte para Kinect, y para el Roomba de iRobot.
-Facil configuración.

En contra se puede decir que la instalación no es muy simple, ya que ofrece problemas de compatibilidad con librerías, y el tipo de comunicaciones.

No hay comentarios: