Diferencia entre revisiones de «Integracion ros butia»

Revisión del 11:28 11 dic 2014

Integrantes

• Ignacio Escudero
• Rodrigo Quinta
• Andrés Tipoldi

Introducción

Robot Operating System

Robot Operating System (ROS) es una plataforma OpenSource de desarrollo de software de robótica. Esta plataforma ofrece servicios como comunicación entre procesos, instalación de dependencias y abstracción del hardware. Además, cuenta con bibliotecas de alto nivel que permiten realizar tareas complejas como manejo de sistemas de coordenadas, procesamiento de imágenes, integración de movimientos y visualización 3D.

Objetivo

El objetivo del proyecto es integrar el robot Butiá a ROS brindando la posibilidad de controlarlo usando esta plataforma.
Esta integración habilitaría la posibilidad de implementar comportamientos y arquitecturas de control de robots aprovechando las herramientas que brinda el sistema. [1]

Análisis de Requerimientos

La siguente presentación detalla los principales conceptos de la plataforma ROS y presenta una primera aproximación al trabajo a realizar para integrar el robot Butiá. Media:Presentacion_ROS.zip

Plataforma ROS

ROS es un “Meta-Sistema Operativo” que se ofrece bajo una licencia de código abierto BSD.

Provee una forma de comunicación entre procesos por medio de mensajes en una red. Por medio de una abstracción de hardware, controladores de dispositivos, bibliotecas, visualizadores y herramientas ayuda a los desarrolladores de software a crear aplicaciones para robots.

El “runtime graph” de ROS es una red peer-to-peer de procesos poco acoplados, que usan la infraestructura de comunicación del sistema. ROS implementa diferentes formas de comunicación, incluyendo, comunicación sincrónica (RPC-style) sobre servicios, comunicación asincrónica basada en tópicos, y almacenamiento de información en un “Parameter Server”.

Nodos

Los nodos son procesos encargados de un comportamiento o una función específica. ROS está diseñado para ser modular; un sistema de control de un robot puede estar integrado por varios nodos.
Los nodos forman un grafo de comunicación, donde ésta se lleva a cabo utilizando los tópicos y servicios. Por lo general un nodo se encarga de una única función del robot (path planning, mover motores, etc). Esto proporciona modularidad al sistema y por lo tanto brinda beneficios tales como un mejor manejo de fallas, individualidad de los nodos, bajo acoplamiento (un nodo puede exponer una API). Para implementar un nodo el desarrollador dispone de una “Client Library”, que proporciona acceso a las funciones principales de ROS. Actualmente existen implementaciones para C++ y Python.

ROS Master

El ROS Master permite establecer conexiones entre los nodos ofreciendo funcionalidades de registro y búsqueda de los mismos, en un estilo similar a los servidores DNS. Como observación cabe aclarar que los nodos no se comunican mediante el Master, sino que la comunicación se da directamente entre nodos, el Master simplemente establece esta comunicación. Este componente almacena la información para el registro y acceso a Tópicos y Servicios y provee actualizaciones a los nodos sobre el estado de los demás. El Master provee el Parameter Server, el cual se describe a continuación.

Parameter Server

Es un servidor compartido que almacena parámetros. Éstos pueden ser registrados y consultados por los nodos en tiempo de ejecución. Su principal uso es el almacenamiento de parámetros de configuración.

Mensajes

Los nodos se comunican a través de mensajes. Éstos consisten en una estructura de datos con atributos tipados, los que contendrán datos que sean de interés para el receptor.
Aunque existen varios tipos estándar de mensajes ya definidos, también se pueden definir nuevos por medio de un archivo de texto plano. Los mensajes pueden tener una estructura anidada; un mensaje puede estar integrado por otros mensajes.

Tópicos

Proporcionan un vía de transporte con semántica publicación / suscripción. Cuando algún nodo envía un mensaje a un tópico, los nodos suscriptos a éste reciben una copia del mismo. Por lo general los suscriptores y los que efectúan la publicación no se conocen entre ellos. Los tópicos conforman un bus de mensajes y cualquiera se puede conectar para enviar o recibir. Permiten una comunicación asincrónica entre varios nodos (many-to-many). Están orientados a la comunicación unidireccional.

Servicios

Los nodos pueden publicar Servicios. Éstos proporcionan una forma de comunicación sincrónica, por medio de la cual un nodo “consumidor” invoca un servicio ofrecido por otro mediante el envío de un mensaje de solicitud y este último brinda una respuesta en forma de otro mensaje. Esta es una forma de comunicación uno-a-uno en forma de RPC (llamada a procedimiento remoto).
Quien implementa el nodo que expone un servicio, define también los tipos de los mensajes de solicitud y respuesta Una invocación a un servicio es bloqueante, es decir que el “consumidor” detiene su ejecución hasta recibir la respuesta correspondiente.

Modelo URDF

El modelo URDF (Unified Robot Descriptor Format) ofrece una descripción del robot. Describe las partes que lo componen y la dinámica de éstas, además ofrece una representación visual y el modelado de colisiones de estas componentes.
Este modelo es una especificación en xml. Hoy en día solamente soporta tres componentes, el Robot, Links y Joints.

Descripción de la Solución

Componentes

En ROS cada tipo de robot es modelado mediante un “Robot Stack”. Para integrar el robot Butiá a esta plataforma es necesario implementar un Stack específico.
Éstas estructuras están integradas por cuatro componentes principales:

• Driver:

Consiste en el controlador para el robot. Es el componente que ejecuta los comandos específicos de control, quien “sabe hablar” con el mismo. Para el caso del robot Butiá se consideró la utilización de un PyBot Client cumpliendo la función de driver, en comunicación con un PyBot Server. [2]

• Nodo:

Es un nodo de ROS que funciona como “envoltura” (wrapper) para el Driver. Implementa una API de ROS exponiendo las formas de comunicación con el robot (servicios, tópicos).
Éste puede comunicarse con otros nodos.

• Modelo:

Consiste en el URDF del robot, que provee una descripción física del mismo; ubicación de sensores, actuadores.
En el caso del robot Butiá, dado que su estructura no es estática (los sensores son móviles pueden colocarse en ubicaciones diferentes), una primera aproximación podría consistir en un modelo fijo con una configuración típica.

• Inicialización:

Contiene los scripts de startup necesarios. Aquí se invocan funciones de inicialización.

Implementación

Se implementaron dos soluciones para el manejo del robot Butiá desde la Plataforma ROS.
Como se mencionó anteriormente ROS soporta principalmente dos formas de comunicación entre nodos. Usando Tópicos, o por medio de servicios. Mientras que los primeros permiten una comunicación asíncrona, los segundos aseguran una comunicación uno a uno.
Al analizar las necesidades del robot Butiá, y las formas de comunicación con el ROS, se decidió implementar ambas formas de comunicación. Esto permite tener una integración más versátil, permitiendo a los desarrolladores de aplicaciones para ROS/Butiá, utilizar cualquiera de las dos soluciones según les sea mas conveniente.

Implementación de Servicios

Para la implementación de servicios se creó un script python que expone los servicios existentes definidos en el pybot. El butia_ros_server.py, provee estos servicios a cualquier nodo que se desee utilizar el robot Butiá.
Cada vez que un consumidor invoque un servicio provisto por el butia_ros_server.py, éste invocará el servicio deseado por medio de una instancia de pybot_client.

Para demostrar cómo se consumirían los servicios, también se implementó un cliente que llama a los servicios expuestos por el server. El cliente acepta como parámetro los distintos sensores disponibles. Para ejecutarlo se debe correr la siguiente línea de comando.

$ rosrun Butia butia_ros_client.py get_button 2

Una vez invocado, el programa llama al servicio expuesto por el butia_ros_server.py especificado (get_button en el caso de arriba) y muestra en consola el resultado de la invocación al servicio.
Además de los servicios que brindan las lecturas de los sensores (get_button, get_gray, get_distance) se implementó otro para setear la velocidad de los motores. Éste puede ser invocado utilizando el cliente mediante el siguiente comando:

$ rosrun Butia butia_ros_client.py set_2_motor_speed 1 400 0 400

Implementación de Tópicos

Al ser los servicios bloqueantes y uno a uno, surgió la necesidad de implementar también un modulo que permitiera generar tópicos asíncronos que expusieran los valores de los distintos sensores del robot Butiá.
El butia_ros_server_topics.py permite generar tópicos específicos por sensores. El mismo recibe como parámetro cuatro elementos:

• Nombre del tópico: Nombre que se le asignará al tópico
• Velocidad (hertz): Frecuencia con la que el valor del sensor será expuesto en tópico.
• Comando: Sensor que nos interesa exponer en el tópico.
• Numero de Sensor: Numero de sensor a ser consultado.

El programa toma los parámetros anteriores, y genera un tópico. Luego según la velocidad establecida en hertz, el script consulta el sensor especifico del robot (mediante el pybot_client) y lo publica en el tópico.
De esta forma, cualquier nodo, que quiera estar al tanto del valor de los sensores del robot, puede simplemente consumir los mensajes de los tópicos.

Comparación entre el uso de Tópicos y Servicios

Las siguientes son algunas consideraciones a tener en cuenta al momento de usar tópico o servicios.

• Siendo que los Tópicos funcionan de forma asincrónica, el nodo consumidor, no se bloquea para esperar una respuesta. El valor del sensor siempre estará disponible para el cliente. El cliente puede escuchar el tópico y modificar una variable local, permitiendo al programa tener acceso a la información necesaria de forma inmediata.
• Dependiendo de la velocidad previamente estipulada de consulta al tópico, la información disponible puede no estar actualizada. Quiere decir que si un proceso precisa tener la información exacta, tendrá que utilizar un servicio, o definir el tópico con un intervalo de consulta muy pequeño, para minimizar la diferencia.
• Como el valor es expuesto en un tópico, el estado del sensor se encontrara disponible para todos los subscriptores al mismo tiempo. De otra forma, con el uso de servicios, todos los clientes interesados en saber el estado de un sensor tendrían que hacer llamadas independientes al servicio.
• Con el uso de servicios, uno se puede asegurar de que no se están haciendo llamadas innecesarias al servidor. Esto permite minimizar la posible sobrecarga de la conexión debido a las llamadas iterativas del topic_server al pybot.

Experimentos y Pruebas

Ejecución de la solución

Para ejecutar una prueba de la solución presentada se deben ejecutar los siguientes pasos.
Se deben levantar 5 consolas y ejecutar los comandos a continuación:

• Consola 1 - Levantar el ROS core.

$ roscore

• Consola 2 - Levantar el pybot_server

$ python pybot_server.py 

• Consola 3 - Levantar el server que expone los servicios

$ rosrun butiaros butia_ros_server.py

• Consola 4 - Levantar el client que consume los servicios (en este caso get_button). Verificar que el resultado se muestre en consola.

$ rosrun butiaros butia_ros_client.py get_button 2

• Consola 5 - Levantar el server para generar un topico. Verificar que los valores se muestren en consola con el intervalo de tiempo especificado

$ rosrun butiaros butia_ros_server_topics.py Button 10 get_button 2

Prueba Local

En caso de no contar con un robot Butia, que pueda atender los pedidos del pybot server, se puede ejecutar este mismo en modo "chotox".

$ python pybot_server.py chotox

Al ejecutarlo en este modo, el pybot server simula una conexión con un robot butiá, y devuelve valores a las llamadas efectuadas desde el client. Esto permite ejecutar pruebas sobre ROS, sin tener que disponer de un robot Butiá.

Conclusiones y Trabajo a Futuro

Mediante los componentes desarrollados es posible controlar el robot Butiá utilizando la plataforma ROS, accediendo a las lecturas de sus sensores de Grises, Distancia y Botón, ya sea en forma sincrónica mediante la invocación de servicios o asincrónica mediante la creación y suscripción a tópicos, así como controlar sus motores seteando su velocidad utilizando el servicio implementado con tal fin.
Con este resultado se alcanza el objetivo planteado haciendo posible la implementación de comportamientos y arquitecturas de control de robots aprovechando las herramientas que brinda el sistema.
Considerando el trabajo realizado como una primera etapa de investigación, con productos generados que permiten controlar el robot, mencionamos a continuación posibles líneas de trabajo a futuro:

• Implementación de servicios y tópicos para las lecturas otros sensores. Ésta puede ser realizada de manera relativamente sencilla, tomando como base lo ya implementado.
• Modelo URDF. En esta etapa se experimentó con la creación del modelo utilizando la herramienta xacro e investigando modelos existentes. Sin embargo la creación de un modelo preciso para el robot Butiá queda planteada como trabajo a futuro.
• Investigación en torno a otros sensores, como por ejemplo una cámara, cuyas entradas no se obtienen directamente de PyBot Server. En este punto es posible aprovechar los controladores genéricos brindados por ROS.
• Butia Stack. Luego de contar con el modelo, el próximo paso consistiría en generar el Componente de Inicialización (bringup), en el cual se podría iniciar el PyBot Server por ejemplo y realizar las tareas de arranque necesarias. A continuación los cuatro componentes (driver, nodo, modelo, inicialización) se “empaquetarían” para formar el Robot Stack del Butiá.

Código Fuente y Documentación

El siguiente archivo contiene el código fuente de la solución implementada Media:Integracion ROS Butia - Codigo.tar.gz. Debe descomprimirse en el directorio de instalación de ROS, bajo share. Para la versión hydro corresponde a la siguiente ruta: /opt/ros/hydro/share
Documentación del Proyecto: Media:Integracion de ROS con Butia.zip
Presentación Final del Proyecto, que incluye el análisis inicial, descripción del modelo URDF y detalles de la implementación de la solución: Media:Butia-ROS - Presentacion Final.zip

Referencias

• Página oficial de ROS
• Wiki oficial de ROS - Documentación / Tutoriales
• Guía de instalación ROS en Ubuntu
• Ejemplo Robot Lego NXT
• Presentación Introductoria a la Plataforma ROS (Benjamin Cohen)
• ROS Cheat Sheet
• Modelo URDF
• Modelado para ROS tutoriales
• PyBot