Diseño de un Robot Compatible con RDS

Publicado en

Microsoft Robotics Developer Studio (RDS) es una plataforma para el desarrollo de aplicaciones robóticas. RDS provee un framework de programación, ambiente de ejecución (runtime), herramientas para creación y simulación de aplicaciones, ejemplos de código, plantillas y tutoriales entre otras cosas. En este artículo veremos los aspectos fundamentales de un robot diseñado para operar aplicaciones creadas con RDS.

Las personas que desean construir aplicaciones robóticas se en- cuentran con que existe una gran variedad de robots disponibles en el mercado, con poca estandarización entre ellos y gran variedad en capacidades y precios. Ante esta problemática, el equipo de Microsoft Robotics se dio a la tarea de definir las características esenciales de un robot que aproveche los servicios de RDS. El objetivo es que las personas puedan facilmente construir su propio robot, o que terceros construyan y vendan robots “listos para usarse”, de manera que los desarrolladores pueden concentrarse más en construir las aplicacio- nes del robot, que en construir el robot en sí. El resultado de este es- fuerzo es la “RDS Reference Platform”. Esta plataforma de referencia es una guía que describe el diseño recomendado para crear un robot “real” (es decir, un robot físico) que pueda operarse con RDS.

MARK

El diseño robótico de referencia utiliza al sensor Microsoft Kinect, el cual provee una cámara de video, sensor de profundidad 3D y micrófono. Este diseño fue bautizado como MARK (Mobile Autonomous Robot using Kinect). El diseño del MARK se basa en cuatro principios: mobilidad, autonomía, interactividad y extensibilidad.

  • La mobilidad es provista por una tracción diferencial, la cual es fácil de controlar y permite que el robot gire en su mismo lugar.
  • Para ser autónomo, el robot recurre a una computadora a bordo. Las capacidades avanzadas como visión computarizada, reconocimiento de voz, o conectividad a redes, requieren capacidad de procesamiento mucho mayor a la que proveen los mi- crocontroladores de bajo rango. Incorporar una PC en el diseño también permite comunicación inalámbrica con otras PCS y/o robots por medio de WiFi.
  • La interactividad considera dos aspectos: la interacción humano-robot, y la interacción del robot con el ambiente. El campo de la robótica personal tiene la necesidad de interfaces de usuario sencillas y confiables. La interactividad es facilitada por la inclusión del sensor Kinect, lo cual puede simplificar dramáticamente la programación de la interfaz de usuario, proporcionando datos 3D e información esqueletal. Los datos 3D también son muy útiles para que el robot pueda desplazarse exitosamente a través de obstáculos.
  • La extensibilidad es inherente al diseño de referencia ya que no especifica detalles de bajo nivel, por lo que no está restringido a una construcción en particular. Este permite que los usuarios y partners de Microsoft Robotics puedan cambiar piezas o variar el diseño siempre y cuando se respeten los aspectos fundamentales.

Arquitectura de hardware

La figura 1 muestra el ejemplo de una implementación de un robot MARK.



A continuación se describe de forma general el hardware de este robot.

Bases. Se requiere un mínimo de dos bases o plataformas en el robot. En la base inferior va el sistema de tracción y en la superior va la computadora y el Kinect. La base de mayor tamaño (típicamente la inferior) debe ser circular y ningún componente debe rebasar su circunferencia, esto permitirá que el robot pueda girar en su lugar sin golpear objetos externos. Se recomienda que las bases tengan un diámetro menor a 60 cm para que puedan pasar por las puertas de una casa. La base superior debe tener un soporte para montar la cámara del Kinect. Para maximizar el campo de visión del Kinect, la altura ideal a la que se debe montar es a 60 centímetros del suelo.

Sistema de tracción. La tracción diferencial consiste en dos ruedas cuya velocidad puede variar de manera independiente. Los motores típicamente se controlan utilizando circuitos de tipo puente H (H-brid-ge). El sistema de tracción considera: las ruedas, el eje de las ruedas, los motores que las mueven, los sensores de rotación de las ruedas (wheel encoder), los puentes H, y los accesorios de montaje. Se recomienda utilizar motores silenciosos, no solo para evitar la molestia del ruido, sino también porque afecta la capacidad de reconocimiento de voz. Dado que la tracción diferencial consiste de solamente dos ruedas, para que el robot tenga estabilidad se recomienda agregar ruedas (una al frente y otra atrás) para que den estabilidad. Estas ruedas deben ser giratorias para no obstruir el desplazamiento y rotación del robot.

Sensores de proximidad. A pesar de que podríamos utilizar el sensor de profundidad del Kinect para detectar obstáculos y evadirlos, se recomienda tener sensores de proximidad dedicados para la evasión de obstáculos. Se debe incluir al menos dos tipos distintos de sensores, ya que combinar distintos tipos incrementa la probabilidad de detectar obstáculos. Por ejemplo los sensores infrarrojos no detectan vidrio pero los de sonar sí, asímismo hay objetos que no son bien detectados por los de sonar pero sí por los infrarrojos.

Controlador de I/O. El controlador de I/O, conocido como brick (ladrillo) es una tarjeta de circuitos que actúa como interfaz entre el hardware del robot y la PC.

Sistema de energía. La energía para el robot debe ser provista por una o más baterías recargables. Se recomienda utilizar baterías de 12V tipo SLA (Sealed Lead Acid). Los componentes del robot que requieren energía incluyen: Kinect (12V a 1.1A), motores y controladores, sensores de proximidad, controlador IO. Por simplicidad, la computadora a bordo puede utilizarse con su batería por lo que no es necesario contemplarla en la lista de componentes soportados por el sistema de energía.

Arquitectura de software

La figura 2 ilustra a grandes rasgos la arquitectura de software de la plataforma de referencia del RDS.

En la capa superior tenemos servicios de alto nivel que pueden ser provistos por RDS, terceros, o creados por el desarrollador. Un servicio en esta capa que ya está incluido como parte del RDS es el Robot Dashboard, un aplicativo que funciona como consola maestra para permitir al usuario controlar al robot y consultar su estatus. Otro servicio de esta capa que ya es provisto por RDS es el de evasión de obstáculos.

Los servicios de bajo nivel son una capa de abstracción de hardware. Proveen servicios para interactuar con el hardware (Kinect, sistema de tracción, sensores) mediante el controlador de I/O. Los servicios de esta capa son programados por el fabricante del robot, o el usuario en caso de estar construyendo su propio robot.

El CCR (Concurrency and Coordination Runtime) y DSS (Decentralized Software Services) son componentes de RDS. Todos los servicios se ejecutan en el contexto de un nodo DSS, y varios nodos DSS se pueden comunicar entre sí a través de una red.

RDS está basado en .NET, el cual a su vez opera sobre el sistema operativo Windows.

En la capa más baja está el hardware. Algunos dispositivos, como el control de Xbox están directamente soportados por drivers para Windows. El controlador de I/O contiene firmware que se comunica via Windows utilizando un puerto serial, USB, red u otro medio.

Para crear aplicaciones robóticas que funcionen con RDS se requiere una computadora con el siguiente software: Windows 7 (32bit o 64bit), Visual Studio 2010 Express o superior, Kinect for Windows SDK (y prerrequisitos asociados), Robotics Developer Studio 4 (y prerrequisitos asociados).

Conclusión

Hemos visto algunos aspectos fundamentales para el diseño de un robot con RDS. Te invito a que consultes la especificación completa y que comiences a desarrollar aplicaciones robóticas. Te comento que RDS incluye una versión simulada de esta plataforma de referencia, de modo que puedes comenzar a desarrollar aplicaciones robóticas en un ambiente simulado sin necesidad de contar con el robot físico. La figura 3 muestra este ambiente de simulación.


 

Bio

Pedro Galván es cofundador y director editorial de SG Software Guru. De vez en cuando quiere publicar artículos sobre temas para los que no encuentra autores y no le queda otra más que escribirlos él mismo por lo que que pasa noches en vela para poder conocer lo suficiente sobre el tema para escribir dichos artículos.