Latest revision as of 19:18, 25 November 2014

• Project Name: Evolución de la Solución de Asistencia MYRA para su Despliegue en Plataformas Android
• Authors: Aitana Alonso Nogueira
• Dates: September 2013 - September 2014
• Degree: Master
• Tags: android, MYRA, ROS, ArUco, Realidad Aumentada
• Technologies: ROS, C++, Android, ArUco
• Status: Finished

Introducción

Desde hace varios años este grupo está trabajando en plataformas de asistencia. El grupo ha diseñado un robot llamado MYRABot con la finalidad de ayudar a la gente mayor utilizando para ello Realidad Aumentada. Este robot es controlado con el software ROS (Robot Operating System) y cuenta con su propio software: MYRA. Este último, es el objetivo de nuestro proyecto.

Este proyecto esta basado en la integración del software MYRA con ROS y una plataforma móvil con Android.

¿Por qué realizar este proyecto? Es decir, ¿Es necesario adaptar la solución de escritorio MYRA para móvil? Sin lugar a dudas, las aplicaciones para dispositivos móviles tienen varias ventajas. La principal es que con ellos puedes llevar tu aplicación de realidad aumentada a cualquier parte, o si surge que en la zona geográfica en que estás hay disponible alguna aplicación concreta de esa zona podrías usarla, puesto que dispondrías del hardware necesario. Esto es muy útil cuando se trata, por ejemplo, de aplicaciones que son fuentes de información acerca de algo que necesitamos saber o hacia lo que sentimos curiosidad.

Otra ventaja viene dada por la accesibilidad a los dispositivos móviles ya que actualmente la mayor parte del mundo ya dispone de ellos y son utilizados diariamente en multitud de tareas. Elegimos la plataforma Android porque cuenta con mayor número de usuarios, según Gartner un 74.4% de los dispositivos móviles adquiridos durante el año 2013 contaban con este sistema operativo.

Por lo tanto, este proyecto va a describir el trabajo realizado para añadir funcionalidades al software MYRA en su versión de escritorio, para su despliegue en móviles. Para ello tendremos que replantear la arquitectura propuesta actualmente en la solución para montar todo lo necesario y poder lanzar en paralelo instancias de la aplicación MYRA.

Para conseguir la integración hemos analizado soluciones relacionadas en varios entornos: Android y PC de escritorio.

Durante el desarrollo se han realizado mejoras en paralelo como un interface de configuración, un interface de debug y otro para visualizacion de mensajes de ROS en MYRA.

A nivel de software hemos refactorizado código e integrado la librería de RA Aruco con ROS mediante un paquete proporcionado por PAL Robotics. Reciprocamente la solución móvil integrará una versión ligera de control de la medicación de la misma forma que hace MYRA de escritorio.

Como resultado hemos obtenido, por un lado nuevas funcionalidades en el software de escritorio MYRA y una aplicación Android que cuenta con un sistema de teleoperación para el robot y con un sistema de realidad aumentada basado en el reconocimiento de marcadores y haciendo uso de la libreria de Aruco, todo ello integrado con el software de control ROS.

Objetivos

Los objetivos principales de este proyecto son los siguientes:

• Actualizar el interface MYRA para integrarlo con ROS.

• Añadir a la solución MYRA una ventana de configuración y otra de debug.

• Actualizar el entorno para que MYRA pueda ser lanzado desde la plataforma Android.

Planificacion inicial

Primero hemos identificamos las necesidades del proyecto, por un lado que que la RA de la que hace uso el software MYRA funcionara en dispositivos Android, porque son más asequibles y fáciles de manejar por personas mayores que los tradicionales ordenadores y por otro lado, integrar el software con ROS para que haya un control sobre el robot.

Después de una etapa de estudio intensivo en la materia, incluyendo el estudio del trabajo anterior realizado en el grupo de robótica, se paso a la búsqueda de posibles soluciones para realizar el proyecto y por último al desarrollo del mismo en las siguientes fases:

La primera se centra en la integración de ROS, ArUco y Android, mediante una aplicación Android.

En la segunda, se realizarán modificaciones sobre el software actual MYRA, para permitir nuevas funcionalidades, se realizarán los siguientes cambios:

• Añadir interface para una configuración rápida de MYRA con ROS.

• Crear interface para visualización de logs.

Después de este ultimo, se decidió añadir al primer entregable teleoperación para que así fuera más uniforme la el software de escritorio y el de android.

Arquitectura

A lo largo de este apartado revisaremos la platforma MYRABot sobre la que se ha realizado este trabajo. Además presentaremos las decisiones tomadas para modificar su arquitectura actual para adaptarla a un entorno de trabajo con plataformas móviles.

Fotografía del robot MYRABot.

MYRABot

El robot MYRABot es un robot de bajo coste de asistencia en el hogar (ver figura). Esta especialmente dedicado a la asistencia de personas mayores. Dicho robot tiene las siguientes características:

• Construido con técnicas de prototipado rápido.
• Bajo coste.
• Adecuado para realizar tareas básicas y desplazarse en el hogar.

Aunque vamos a presentar ambos componentes, hardware y software, nos centraremos en la parte de software que es en lo que vamos a trabajar en el proyecto e incluiremos un nuevo bloque con despliegue sobre la plataforma Android (Figura \ref{fig:DiagramaSysMLMyrabot_es}).

La figura representa la arquitectura MYRA mediante el lenguaje de modelado SysML. Se muestran los componentes hardware y software del robot y las relaciones entre ellos.

Hardware

En cuanto a hardware se tienen dos elementos muy diferenciamos, por un lado la plataforma robótica cuyos componentes hardware son los siguientes:

• iRobot Roomba 520, Arduino Mega, y la estructura de madera.
• Dinamixel Arm (5x12a) para la manipulación de móviles de pequeños objetos rígidos.
• Notebook (procesador Atom), la pantalla se ha situado en la parte superior del robot
• Kinect para la navegación.
• Asus Xtion for 3D object recognition.

Por otro lado, el dispositivo móvil, que puede tratarse de una table o smartphone con sistema operativo Android y que cuente con una cámara.

Software

El software de la arquitectura se clasifica en:

• ROS (robot control)
• MYRA (C/C++, ArUCo, Qt, openCV)

Software MYRA

El software MYRA (Mayores y Realidad Aumentada, realidad aumentada y ancianos), es un sistema asistencial que mediante realidad aumentada ayuda al mayor en distintas labores de asistencia, como por ejemplo en el control de la medicación. Esto se aplica en dos contextos diferentes:

• Ayudar a las personas mayores en su hogar en el día a día. Consiste en un sistema de control para la medicación diaria que un del anciano. Las tecnologías que se han utilizado en esta parte son las siguientes: C++, Qt, OpenCV y ArUco, que es una librería de Realidad Aumentada basada en OpenCV.
• Un sistema de teleasistencia genérico.

A alto nivel la solución actual de la propuesta realiza unas tareas bien definidas como se puede ver en la figura.

El paradigma de desarrollo que se aplica en el software MYRA es el Modelo Vista Controlador (MVC), que consiste en separar los datos de una aplicación (Modelo), la interfaz de usuario (Vista) y la lógica de negocios (controlador) en tres componentes distintos que se relacionarán para al final tener como resultado nuestra aplicación.

Modelo Vista Controlador

• Modelo que abarca el software necesario para conectarse a otras bibliotecas que MYRA necesita, como por ejemplo: OpenCV, ArUco, bibliotecas pjproject y ROS. Estas bibliotecas proporcionan el reconocimiento de imágenes, realidad aumentada y los servicios de VoIP, respectivamente. ROS proporciona el control del robot.
• Vista, es el encargado de construir la interfaz e interactuar con los usuarios, además mostrará la información al usuario en la pantalla del robot.
• Controlador está compuesto por los subsistemas que procesan los datos y generar la información que necesitan los niveles más altos de la aplicación.

Además tratándose de una integración con Android, utilizaremos Android UI framework que está basado en el patrón de diseño MVC ( ver figura).

Modelo Vista Controlador en Android

Propuesta

Tras la presentación de estos componentes, revisar el estado del arte y ver evaluar cual sería la mejor aproximación, creemos que la arquitectura que será necesaria desarrollar para que la solución continue siendo útil es la que se puede ver en la figura.

Tecnologías utilizadas

En esta sección solo se van a enunciar las plataformas, lenguajes y bibliotecas utilizadas para el desarrollo del presente proyecto, sin pretender entrar en una explicación de las mismas.

Plataformas de Desarrollo

Se trata de un proyecto de integración de tres plataformas:

• Plataforma Linux, sistema operativo basado en Unix, en concreto la distribución Ubuntu 12.04(tanto la versión de 32 como la de 64 bits).
• Plataforma Android, versión 4.2.2 Jelly Bean.
• ROS, versión hydro.

Entornos de desarrollo integrados (IDE's)

Qtcreator

Qt Creator es un IDE multiplataforma adaptado a las necesidades de los desarrolladores de Qt.

Qt Creator proporciona entre otras las siguientes características que ayudan a desarrollar código:

• Editor de código con soporte C + +, QML y ECMAscript.
• Herramientas rápidas de navegación de código.
• Resaltado de sintaxis y autocompletado de código.
• Comprobación de código estático.
• Soporte para la refactorización del código fuente.
• Ayuda contextual.
• Incluye herramientas para el desarrollo de interfaces de usuario. Lo que permite construir rápidamente y poder visualizar como van a quedar las diferentes ventanas, imágenes, botones...

Android Studio

Android Studio es un IDE multiplataforma para desarrollar aplicaciones android.

Incluye el SDK de Android que es el que proporciona las bibliotecas y las herramientas de desarrollo necesarias para crear, probar y depurar aplicaciones para android.

El sistema de construcción de Android Studio se basa en un plugin de Android para Gradle. Gradle es un conjunto de herramientas de construcción avanzada que gestiona las dependencias y le permite definir una lógica de construcción para las aplicaciones personalizada.

Lenguajes y bibliotecas utilizadas

Para el desarrollo de la aplicación se han utilizado varias tecnologías, lenguajes y herramientas, así como un conjunto de aplicaciones con licencia GPLv3 previamente desarrolladas por otros usuarios y profesionales en la materia. Las veremos clasificadas en herramientas de control, herramientas de visión artificial y RA, herramientas para el desarrollo de la teleasistencia y otras herramientas utilizadas para llevar a cabo el desarrollo del software.

Herramientas de control

• ROS (Robot Operating System)

Herramientas de Visión Artificial y RA

• OpenCV
• OpenGL
• Aruco

Herramientas de teleasistencia

• QjSimple
• pjSIP

Otras herramientas y lenguajes de programación

• C++
• Qt
• GiT
• cmake
• make

Desarrollo

A lo largo de este apartado se detallan las fases en que se han desarrollado finalmente en el proyecto.

Fase I

En la primera fase, se realizó la integración de ROS, ArUco y Android. El modelo que deseamos obtener es el que se aparece en la figura, en donde el anciano a través de la cámara de su dispositivo android envía imágenes al robot ( en este caso un PC), mediante la conexión wifi y a su vez recibe de manera inmediata mediante un marcador que medicina le toca tomar en ese momento. Veamos en los siguientes apartados los pasos necesarios para conseguir esta integración.

Los pasos necesarios para conseguir esta integración son:

• Despliegue del sistema base
• Conexión entre sistemas
• Validación de comunicaciones entre sistemas
• Integrar solución de realidad aumentada
• Validación de funcionamiento en todos los sistemas

Los desarrollamos a continuación.

Despliegue del sistema base

En esta fase tendremos que lanzar los cimientos del sistema de control. Roscore es un conjunto de nodos y programas que son pre-requisitos de un sistema basado en ROS. Se debe ejecutar roscore para que los nodos ROS para comunicarse. Por tanto, esto es lo primero que debemos hacer en la máquina que tengamos instalado ROS ( en nuestro caso versión hydro). Para iniciarlo se hace con el comando roscore.

En nuestro caso, podremos prescindir de ejecutar este comando porque si utilizamos roslaunch, que más adelante explicaremos inicia automáticamente roscore si no se esta ejecutando ya.

Roscore inicia los siguientes recursos:

• Maestro o master
• Servidor de parámetros
• Un nodo de registro: \rosout

Debemos también modificar las siguientes variables del entorno ROS:

export ROS_MASTER_URI=http://localhost:11311

export ROS_HOSTNAME=localhost

En el lugar de localhost irá la IP del equipo donde se ejecuta el roscore.

Conexión entre sistemas

Para realizar la aplicación de Android que se conectará con el master de ROS, nos hemos ayudado de \android\core, que esta basado en el cliente rosjava. En la figura se ven las dependencias que existen entre los diferentes paquetes oficiales de ROS para java.

Diagrama de dependencias rosjava-android

Para el desarrollo de la aplicación se ha utilizado Android Studio y se ha ejecutado sobre varios dispositivos android. Una vez instalada la aplicación en el dispositivo y ejecutado el roscore o roslaunch. Se ejecutará la aplicación android y nos aparecerá la siguiente pantalla (Ver figura ) dónde debemos introducir la IP del equipo donde se ejecuta el roscore para que se realice la conexión y pueda así comunicarse el nodo del dispositivo android con los demás nodos del sistema.

Validación de comunicaciones entre sistemas

Una vez establecida la conexión el nodo android que se encarga de publicar las imágenes /ros_camera_preview_view empezará a publicar bajo el topic /camera/image/compressed.

Después vamos a necesitar que el nodo que se va a encargar del procesamiento de la imagen y de la realidad aumentada, el nodo aruco_android, se suscriba a las imágenes publicadas por el nodo /ros_camera_preview_view.

El paquete image_transport, se usa siempre que se trata de publicar y suscribirse a imágenes, este proporciona un soporte transparente para transportar las imágenes comprimidas.

Android publica las imágenes en formato compressed, pero el nodo aruco_android necesita que estas estén en formato raw (es el tipo de transporte por defecto). Por eso deberemos republicar las imágenes cambiando el tipo de transporte. La sintaxis para hacer esto es la siguiente:

republish in_transport in:=<in_base_topic> [out_transport] out:=<out_base_topic>

En nuestro caso haremos:

cd /opt/ros/hydro/lib/image_transport
./republish compressed in:=/camera/image raw out:=/camera/image_test

Y con esto obtendremos la imagen en el formato por defecto raw nombrada con el topic /camera/image_test que será la imagen a la que se suscriba el nodo de RA. En la figura se ve como se realiza la publicación, republicación y suscripción.

Integrar solución de realidad aumentada

PAL Robotics propone una solución o paquete de integración de la libreria ArUco con ROS. Se ha trabajado, sobre ese paquete modificando algunas de las funciones de ArUco y se ha añadido un lanzador android.launch para poder ejecutar dicho paquete con los parámetros correspondientes al dispositivo móvil.

Los lanzadores .launch son archivos ROS de configuración escritos en XML en los que se especifican los nodos a lanzar, los argumentos de entrada a éstos y los parámetros necesarios para crear una aplicación completa. Como todo archivo XML, se compone de una serie de etiquetas que tienen una serie de opciones a rellenar.

Este será el archivo que ejecutaremos con el roslaunch:

roslaunch aruco_ros android.launch

Al ejecutarlo, se creara el nodo aruco_android (Ver figura), el cual se suscribe al topic /camera/image_test, realiza todo el procesado de las imágenes y pinta sobre ellas reconociendo los marcadores de RA, su código, está imagen es la que posteriormente publica con diferentes formatos con el topic /aruco_android/result y /aruco_android/result/compressed.

Validación de funcionamiento en todos los sistemas

Es el topic /aruco_android/result/compressed al que se suscribirá el nodo de android /ros_image_view que se encargará de mostrar en la pantalla del dispositivo el resultado después de aplicar la RA como se muestra en la siguiente figura.

Aplicación Android reconociendo los marcadores de RA

El modelo resultante incluyendo los topics de publicación del robot y del dispositivo móvil se muestra en la figura.

Fase II

Comprende las nuevas funcionalidades del software de escritorio y la teleoperación del robot.

Funcionalidades software MYRA

En este primer paso, se ha realizado una modificación del software de escritorio MYRA, añadiéndole nuevas funcionalidades. Esta modificación consiste en una actualización de la interfaz de usuario, añadiendo por un lado una ventana de configuración y por otra parte, una ventana de debug y debug topic.

• La ventana de configuración (Ver figura), nos da la opción de seleccionar la url del máster al que queremos conectarnos y la IP del equipo que se va a conectar. Por defecto, suponemos que el máster y el equipo que se conecta son el propio que ejecuta la aplicación MYRA, por eso los parámetros por defecto son http://localhost:11311/ y la IP localhost.

Captura de la ventana de configuración de MYRA

• La ventana de MYRA, donde no se ha hecho ninguna modificación. Esta es la parte que se encarga de la visualización de la RA para indicar que medicina le toca al anciano. Un ejemplo de su funcionamiento se aprecia en la figura.

Captura de la ventana de medicación de MYRA

• La ventana de Teleop, desde donde se puede teleoperar el robot y a la que se ha añadido la posibilidad de cambiar el topic de visualización desde la ventana de configuración. En este ejemplo por ejemplo (Ver figura) se está visualizando el topic /aruco_android/result.

Captura de la ventana de teleoperación de MYRA

• La ventana de debug (Ver figura) muestra los logs generados por la aplicación indicando su nivel entre cinco posibles: debug, info, warning, error, fatal. Además da la opción de filtrar los registros según dicho nivel, es decir si indicamos que queremos un nivel de log de warning por ejemplo, nos apareceran aquellos mensajes cuyo nivel sea warning, error o fatal.

Captura de la ventana de debug de MYRA

Teleoperación

En la aplicación android, se ha decidido añadir un sistema de teleoperación, que va a permitir al usuario de la aplicación controlar los desplazamientos del robot. La idea de como permite mediante el dispositivo móvil teleoperar el robot se muestra en la figura.

De esta forma, quedaría más uniforme el software, puesto que la aplicación contaría con la ventana de conexión y la ventana de teleoperación y realidad aumentada en una misma pantalla.

Para realizar esta teleoperación, se utilizara el nodo android/virtual_joystick que se subscribe al topic /odom, que contiene datos odométricos, una estimación de la posición y velocidad de un robot en el espacio y publica en el topic /cmd_vel las velocidades del robot.

La apariencia visual de la aplicación con el joystick o palanca de control se ve en la figura.

Imagen del joystick de la aplicación Android.

En la figura se ve el nodo android/virtual_joystick y todas sus relaciones con el robot.

Experimentación

En este capítulo vamos a ver el resultado final obtenido. Para ello mostraremos un diagrama total de ROS, donde se ven todos los nodos conectados entre sí y unas figuras dónde se ve la aplicación funcionando.

Toda la la fase experimental se ha realizado en el aula utilizando los dispositivos reales, es decir, pastilleros y plataforma robótica.

Para hacer las pruebas se va a utilizar el pastillero de medicación que aparece en la figura.

Imagen del pastillero para las pruebas.

Los experimentos se han realizado en dos etapas:

• En el test 1 hemos validado experimentalmente el funcionamiento con todas las cámaras que despliega el sistema (dispositivo móvil y PC + cámara integrada o cámara USB) el funcionamiento del sistema de realidad aumentada. En este test hemos realizado pruebas de regresión para comprobar que el sistema anterior seguía funcionando.

• En el test 2 hemos realizado pruebas con el robot para validar que el sistema de conexión, debug y teleoperación es funcional con la plataforma robótica.

Test 1

En esta primera fase, teníamos que comprobar el correcto funcionamiento de la RA y su despliegue sobre android. Primero se hicieron pruebas de la integración de Aruco y ROS utilizando la webcam del PC. Una vez que eso estaba verificado, se paso a la comprobación del envió de imágenes y recepción en el dispositivo Android a través de ROS. Y por último, ya comprobado eso sólo quedo la validación de la RA aplicada a la medicación en el dispositivo móvil.

Test 2

En esta fase se han hecho pruebas de conexión con diferentes plataformas ROS en PC y con el propio robot. Se comprobó que el sistemas de mensajes de registro estuviera funcionando correctamente de acuerdo al nivel introducido por el usuario. Y por último, se hicieron pruebas de la teleoperación del robot, sobre un simulador de turtlebot y sobre el propio robot.