Una vez más creo oportuno hacer un break en mis entrada de opinión para ponerme un poco técnico y tratar de ayudar a los que sean curiosos o tengan problemas en sus proyectos. Esta vez voy a hacer una pequeña introducción a la robótica.
La robótica a gran escala, me refiero a sistemas con hardware de gran envergadura y no a los robots BEAM u otro tipo de robots simples (que no por ello son menos importantes), requiere de dispositivos cuyo manejo necesita de un software complejo. Por ejemplo, cuando se quiere usar un laser como es comprensible el acceso a los datos que provee este aparato, no es lo mismo que usar un sensor de proximidad de infrarojos o un sensor de ultrasonidos que pueden ser manejados por un simple PIC. De estas necesidades software se derivan muchas otras necesidades como: un sistema de computo potente (ordenador, pc104, placas con procesadores ARM potentes...), un conocimiento mucho más en profundidad del hardware, etc.
De esta problemática surgieron programas gigantes y nada reutilizables, para el control de un robot y de todos los dispositivos que lo componían. Por lo que si se construía un nuevo robot con componentes similares al anterior, no era posible reutilizar ni tan solo el software de esos componentes (salvo un buen diseño software). Gracias a Dios, entre los miembros de esta comunidad de investigadores habían muchos licenciados en computer science engineering (aka ingenierios informáticos) y se dio con una solución bastante potente para el problema. Esta solución es el middleware para robots o RSF de las siglas Robotics Software Framework.
¿Cual es la utilidad de un RSF? Bien, se trata de una capa de abstracción software que sirve para que el programador se despreocupe de la implementación específica de un hardware y de todos sus detalles como drivers o APIs del fabricante. De esta forma se normaliza la programación para robots, y permite por ejemplo usar un laser dando igual la marca o modelo que sea, siempre que este tenga soporte dentro del middleware para robots.
Ahora viene lo mejor, esos componentes hardware concretos tienen sus correspondientes módulos/componentes software genéricos que homogeinizan el hardware, pero tienen que estar corriendo en un servidor al cual se conecta el software desarrollado por el usuario del robot. Bien, esto quiere decir que debe existir alguna forma de comunicarse con esos módulos para poder obtener información y controlarlo. Lo habitual, contra todo pronóstico, es que esa comunicación se realice mediante la pila de protocolos de red, haciendo uso de TCP/UDP. ¿Por qué esto? para dar más flexibilidad de la que da el propio diseño modular, distribuir los componentes de un robot, permite la construcción de un sistema robótico mas complejo aún y por tanto más potente aunque a costa de problemas derivados de la comunicación.
Para que se entienda mejor el funcionamiento, pongo una imagen de un middleware comercial.
Los middleware más extendidos son Open source y por eso mismo son los más recomendables (si se encuentra un bug, se puede modificar, son los más extendidos por lo tanto son los que tienen mayor número de componentes..). Pero también a la hora de hacer la elección del RSF que se quiere usar en el robot, debería ser un factor muy importante la existencia de un software de simulación.
El software de simulación con normalidad se integra perfectamente con el RSF, consiguiendo que el desarrollador no necesite tener el hardware real para programar la aplicación que maneja el robot. Además, no solo simula el hardware sino también un entorno, pudiendo representar casi de forma fidedigna la respuesta del aparato en un entorno real.
Una pequeña recopilación de los RSF:
-ROS
-Player/Stage
-Miro
-UPnP
-ORCA
-Urbi
-OpenRDK
-OROCOS
No hay comentarios:
Publicar un comentario