Difference between revisions of "Aitana-TFM-Android-MYRA"
(→Arquitectura) |
(→Arquitectura) |
||
Line 75: | Line 75: | ||
Además presentaremos las decisiones tomadas para modificar su arquitectura actual para adaptarla a | Además presentaremos las decisiones tomadas para modificar su arquitectura actual para adaptarla a | ||
un entorno de trabajo con plataformas móviles. | un entorno de trabajo con plataformas móviles. | ||
− | [[File:myrabot.png| thumb| | + | [[File:myrabot.png| thumb| 200px |Fotografía del robot MYRABot.]] |
== MYRABot == | == MYRABot == |
Revision as of 13:00, 13 October 2014
- Project Name: Evolución de la Solución de Asistencia MYRA para su Despliegue en Platformas 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.
MYRABot
Hardware
Software
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.
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.
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.
- 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.
- 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.
- 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.
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.
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.
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 (Ver figura).