Aslab D 2012 012

UNIVERSIDAD POLITCNICA DE MADRID
DEPARTAMENTO DE AUTOMTICA INGENIERA ELECTRNICA

E INFORMTICA INDUSTRIAL
Divisin de Ingeniera de Sistemas y Automtica (DISAM)

ARI Android Robot Interface
Android Robot Interface
AUTOR: TUTOR:
Francisco Javier Mata Sanz Carlos Hernndez Corbato Ricardo Sanz Bravo
Resumen
Este proyecto trata sobre el diseo de una interfaz grca de control basada en Android. La interfaz diseada ARI, Android Robot Interface, permite el control de robots que implementan el sistema ROS, Robot Operating System. El sistema operativo ROS es un framework que permite el desarrollo de software para aplicaciones robticas. La base de ROS consiste en proporcionar un sistema operativo con la funcionalidad de un clster informtico heterogneo. ROS fue desarrollado en 2007 bajo el nombre de "switchyard"por el Stanford Articial Intelligence Laboratory, con apoyo del proyecto Stanford AI Robot (STAIR). A partir de 2008, el desarrollo continu principalmente en Willow Garage, un instituto de investigacin de robtica con ms de veinte instituciones que colaboran en un modelo de desarrollo federado. La aplicacin est desarrollada para funcionar sobre el sistema operativo Android. Al contrario que otros sistemas operativos para dispositivos mviles como iOS o Windows Phone, Android se desarrolla de forma abierta. La estructura del sistema operativo Android se compone de aplicaciones que se ejecutan en un framework Java de aplicaciones orientadas a objetos. Estas aplicaciones corren sobre el ncleo de las bibliotecas de Java en una mquina virtual Dalvik con compilacin en tiempo de ejecucin. Dalvik es la mquina virtual que utiliza la plataforma, diseada por Dan Bornstein con contribuciones de otros ingenieros de Google. Dalvik est optimizada para requerir poca memoria y est diseada para permitir ejecutar varias instancias de la mquina virtual simultneamente, delegando en el sistema operativo subyacente el soporte de aislamiento de procesos, gestin de memoria e hilos. ARI permite al usuario el control de sistemas robticos desarrollados en el equipo de investigacin de ASLab. El Laboratorio de Sistemas Autnomos (ASLab) es un grupo de investigacin centrado en el desarrollo de la tecnologa necesaria para obtener sistemas autnomos y robustos. Los Sistemas Autnomos (AS), suponen la parte ms emocionante para la investigacin tcnica. Son verdaderamente sistemas muy complicados y se hacen absolutamente carsimos en el esfuerzo. Es necesaria una gran capacidad tanto de concentracin, como de abstraccin para conseguir realizar avances en la investigacin de esta tcnica.
ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz
II
R ESUMEN
ASLab est concienciado y preparado para cambiar el punto de vista que aportan los modelos tpicos en la investigacin acadmica. Pero, en cierto sentido, se realizan actividades desde una postura de miras al mundo industrial. Se pretende desarrollar tecnologa para sistemas autnomos en el mundo real, de forma que se dotar a los seres humanos de libertad de supervisin una vez que que el sistema est en funcionamiento. Ellos sern capaces de auto-gestionarse. Dentro del proyecto ASys existe una parte de prueba de los sistemas de control desarrollados. El robot Higgs es una de esas partes, en concreto del ASys Robot Control Testbed (RCT) , seleccionada para la demostracin de la dimensin cognitiva ms alta en un sistema fsico. La aplicacin ARI es la herramienta de control de los sistemas robticos desarrollados por el equipo de investigacin de ASLab , ofreciendo al usuario una interfaz porttil y sencilla para la interaccin con dichos sistemas.
III
Para ti abuelo Paco, esto sigue signicando mucho para m. Volvamos a compartirlo juntos.
El que ha comenzado bien, est a la mitad de la obra. Q UINTO H ORACIO F LACO
Ms le vale a un hombre tener la boca cerrada, y que los dems le crean tonto, que abrirla y que los dems se convenzan de que lo es. P ITGORAS DE S AMOS
Agradecimientos
Este proyecto no habra sido posible de no ser por todas aquellas personas que me apoyan. Siempre lo han hecho y espero que nunca dejen de hacerlo. En muchas ocasiones ste apoyo te hace ser ms fuerte, hacer frente a los problemas, y plantar cara a todo lo que se te venga encima. No soy partidario de tirar la toalla, nunca he pensado en ello como algo posible. Si por el contrario, optas por abandonar en el intento, puede que nunca se llegue a apreciar ese esfuerzo. La clave est en poner ganas, coger aire, resoplar, levantar la vista y enfrentarse a ello. A lo largo de estos ltimos cinco aos me he visto en situaciones difciles, complicadas. No es fcil salir de casa para estudiar en otro lugar. Por ello quiero agradecer la experiencia de vida que he compartido con mis compaeros de piso, Miquel, Javi y Fer. A Ricardo Sanz y Carlos Hernndez, director y coordinador de este proyecto, por su apoyo, orientacin y ayuda en el desarrollo del mismo, as como su disposicin plena para resolver cualquier tipo de duda. Agradecer tambin el haber compartido toda su experiencia conmigo, ya que he aprendido a manejarme en un rea que no se ensea en ninguna parte, sino que se adquiere con la experiencia de uno mismo. A mis amigos de innita paciencia. He aprendido de cada uno cosas distintas, a convivir, a sentir inters por temas que nunca me hubiera planteado explorar por mi cuenta. A toda mi familia, por todo lo que ha hecho por m. A mis tas, Nines y Loli, que siempre me han ofrecido su cario y animado para conseguir aquello por lo que luch. A mi abuelo Pepe, porque siempre quiere lo mejor para toda su familia y se esfuerza al mximo en que as sea, eso tampoco se ensea en ningn lado, slo de observar y comprender. Gracias a ti tambin abuelo Paco, porque creo que este espritu ingenieril proviene plenamente de tu estilo de vida. A mis abuelas, por tantas oraciones y por preocuparse a todas horas por mi bienestar. Siempre sabr que estaris cuidando de nosotros, vuestros nietos, de la mejor manera que sabis. Finalmente a mis padres y a mis hermanas, por la educacin que he recibido de vosotros, porque cada da aprendo a ser mejor persona cuando os veo y porque an nos queda mucho por compartir, vivir y sentir juntos. Os quiero mucho.
DOCUMENTO I
MEMORIA
ndice
I. Memoria
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
9 9 10 10 10 11 13 14 14 14 17 17 17 19 21 22 24 25 26 27 29 29 31 32 33 34 34 40
1. Introduccin 1.1. Autonomous Systems, ASys . . . . . . . 1.2. Autonomous Systems Laboratory, ASLab 1.3. Higgs Robot . . . . . . . . . . . . . . . . 1.3.1. Estructura de Higgs . . . . . . . . . . 1.3.1.1. La plataforma . . . . . . . . . . . 1.3.1.2. Componentes embarcados . . . . 1.3.1.3. Sistemas adicionales . . . . . . . 1.3.2. Descripcin funcional del robot . . . 1.4. Motivacin y objetivos . . . . . . . . . .
2. ESTADO DEL ARTE 2.1. Android . . . . . . . . . . . . . . . . . . . 2.1.1. Historia y precedentes . . . . . . . . . 2.1.2. Actualizaciones . . . . . . . . . . . . . 2.1.3. Caractersticas . . . . . . . . . . . . . . 2.2. ROS . . . . . . . . . . . . . . . . . . . . . 2.2.1. ROS fuerte . . . . . . . . . . . . . . . 2.2.2. ROS Java . . . . . . . . . . . . . . . . 2.3. Sistemas distribuidos de componentes . . . 2.3.1. Propiedades de los sistemas distribuidos 3. ENTORNO DE DESARROLLO 3.1. Sistema Operativo: Ubuntu . . . 3.2. ROS . . . . . . . . . . . . . . . 3.3. Plataforma de desarrollo Eclipse 3.3.1. ADT Plugin . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4. ARQUITECTURA DE SISTEMA 4.1. Arquitectura del sistema Higgs . . . . . . . . . . . . . . . . . . . . . 4.2. Arquitectura de Android . . . . . . . . . . . . . . . . . . . . . . . .
D OCUMENTO I. M EMORIA l NDICE
4.3. Arquitectura de ROS . . . . . . . . . . . . . . . . . . . . . . . . . . 5. ARI: Android Robot Interface 5.1. Creacin del proyecto Android . . 5.2. Diseo grco . . . . . . . . . . . 5.2.1. Componentes grcos en ARI 5.3. Desarrollo software . . . . . . . . 6. RESULTADOS Y CONCLUSIONES 7. DESARROLLO FUTURO 8. PLANIFICACIN Y ALCANCE DEL PROYECTO 8.1. Estructura de descomposicin del trabajo . . . . . . . . . . . . . . . . 8.2. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . BIBLIOGRAFA
46 50 50 52 55 64 80 82 84 84 88 90
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
II. Anejos
1. Manual de usuario 1.1. Introduccin . . . . . . . . . . . . . . . 1.2. Asus Transformer Prime . . . . . . . . 1.3. Inicio de la aplicacin . . . . . . . . . . 1.4. Robot ROS . . . . . . . . . . . . . . . 1.4.1. System State Viewer . . . . . . . . 1.4.2. Robot Operation . . . . . . . . . . 1.5. Cliente remoto . . . . . . . . . . . . . . 1.5.1. Men de opciones del cliente remoto 1.6. Apagado de la aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
92 92 92 94 96 97 99 105 108 117
III. Cdigo fuente

1. Cdigo Java de la aplicacin 1.1. MainActivity.java . . . . . . . . 1.2. RosActivityRobot.java . . . . . 1.3. NodeMainExecutorService.java . 1.4. RosRobot.java . . . . . . . . . . 1.5. TeleopFragment.java . . . . . . 1.6. NodeListFragment.java . . . . . 1.7. RosDataObserver.java . . . . . . 1.8. VirtualJoystickView.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
120
121 121 124 128 132 136 139 141 142
ndice de guras
1. Robot Higgs. Objetivo del desarrollo del RCT. Banco de pruebas de sistemas autnomos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Telfono HipTop, primer telfono que marcara la lnea de los Smartphones. 3. HTC Dream, el primer telfono Android de la historia. . . . . . . . . . . . 4. Android 1.5 Cupkake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Android 1.6 Donut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Android 2.0 Eclair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Android 2.2 Froyo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Android 2.3 Gingerbread . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Android 4.0 Ice Cream Sandwich . . . . . . . . . . . . . . . . . . . . . . 10. Conversin de .jar a .dex . . . . . . . . . . . . . . . . . . . . . . . . . . . 11. ltima actualizacin de ROS: ROS FUERTE . . . . . . . . . . . . . . . . 12. ROS Java permiti el desarrollo de aplicaciones para Android. . . . . . . . 13. Robot que puede ser manejado con un Smartphone con Android. . . . . . . 14. Arquitectura de un sistema distribuido. . . . . . . . . . . . . . . . . . . . . 15. Ubuntu 10.04 Lucid Lynx . . . . . . . . . . . . . . . . . . . . . . . . . . . 16. ROS: Robotic Operating System . . . . . . . . . . . . . . . . . . . . . . . 17. Entorno de desarrollo Eclipse Classic. Versin 4.2. . . . . . . . . . . . . . 18. Android Developer Tools Plugin . . . . . . . . . . . . . . . . . . . . . . . 19. Vista general de ujos de mensajes del sistema. . . . . . . . . . . . . . . . 20. Vista general del sistema robtico Higgs. . . . . . . . . . . . . . . . . . . 21. Histograma para la comprensin de la gura 20. . . . . . . . . . . . . . . . 22. Localizacin a travs del paquete de ROS amcl. . . . . . . . . . . . . . . . 23. Intefaz provista por el nodo move_base para la comunicacin con el resto de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24. Mapa de coste del robot durante la simulacin. . . . . . . . . . . . . . . . 25. Trayectorias de valor calculadas por el paquete base_local_planner. . . . . 26. Arquitectura de pila del sistema Android. . . . . . . . . . . . . . . . . . . 27. Versiones del Kernel de Linux de Android . . . . . . . . . . . . . . . . . . 28. Kernel de Linux de Android . . . . . . . . . . . . . . . . . . . . . . . . . 29. Libreras del sistema operativo Android . . . . . . . . . . . . . . . . . . .
11 18 18 19 20 20 20 21 21 22 24 25 25 26 30 31 32 33 35 36 37 38 38 39 39 40 41 42 42
30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67.
Entorno de ejecucin del sistema operativo Android . . . . . . . . . . . . . Framework de aplicaciones del sistema operativo Android . . . . . . . . . Multimedia en sistema operativo Android . . . . . . . . . . . . . . . . . . Aplicaciones del sistema operativo Android . . . . . . . . . . . . . . . . . Control de la trayectoria de una masa suspendida de un cable mediante ROS. Arquitectura ROS del sistema de control de una masa suspendida. . . . . . Creacin de un proyecto Android en Eclipse. . . . . . . . . . . . . . . . . Jerarqua de vistas de la interfaz de usuario Android. . . . . . . . . . . . . Ejemplo de cdigo XML de la interfaz grca de Android . . . . . . . . . Diferentes temas de Android. . . . . . . . . . . . . . . . . . . . . . . . . . Barra de sistema de ARI. . . . . . . . . . . . . . . . . . . . . . . . . . . . Noticaciones en Android. . . . . . . . . . . . . . . . . . . . . . . . . . . Ejemplo de barra de acciones. . . . . . . . . . . . . . . . . . . . . . . . . Barra de acciones de ARI. . . . . . . . . . . . . . . . . . . . . . . . . . . Lista de informacin ROS en ARI. . . . . . . . . . . . . . . . . . . . . . . Scroller en el sistema Android. . . . . . . . . . . . . . . . . . . . . . . . . Spinner de opciones de ARI. . . . . . . . . . . . . . . . . . . . . . . . . . Botones en el sistema Android. . . . . . . . . . . . . . . . . . . . . . . . . Casillas de texto de ARI para captar informacin necesaria. . . . . . . . . . Cuadros de dilogo en Android . . . . . . . . . . . . . . . . . . . . . . . . Aviso de conrmacin Android. . . . . . . . . . . . . . . . . . . . . . . . Diagrama para la utilizacin de avisos de conrmacin. . . . . . . . . . . . Versiones del sistema operativo Android. . . . . . . . . . . . . . . . . . . Interfaz visual de la actividad principal de ARI. . . . . . . . . . . . . . . . Interfaz visual de la actividad de control del robot de ARI. . . . . . . . . . Diagrama de secuencia del ciclo de vida de una Actividad Android. . . . . Implementacin de los mtodos del ciclo de vida de una actividad Android. Diseo del funcionamiento de fragmentos en ARI. . . . . . . . . . . . . . Fragmentos NodeListFragment y NodeInfoFragment de ARI. . . . . . Mtodos que implementa el Fragmento TeleopFragment de ARI. . . . . . . Diagrama de secuencia del ciclo de vida de un Fragment Android. . . . . . Diagrama de secuencia del ciclo de vida de ambos modos de un Servicio Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estructura de Descomposicin del Trabajo . . . . . . . . . . . . . . . . . Estructura de Descomposicin del Trabajo . . . . . . . . . . . . . . . . . Estructura de Descomposicin del Trabajo . . . . . . . . . . . . . . . . . Estructura de Descomposicin del Trabajo . . . . . . . . . . . . . . . . . Estructura de Descomposicin del Trabajo . . . . . . . . . . . . . . . . . Estructura de Descomposicin del Trabajo . . . . . . . . . . . . . . . . .
43 44 45 46 48 48 52 53 54 55 56 56 57 57 58 59 59 60 61 61 62 63 64 66 66 67 68 70 70 71 73 75 84 85 85 86 86 87
68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86.
Estructura de Descomposicin del Trabajo . . . . . . . . . . . . . . . . . 87 Diagrama de Gantt del proyecto. . . . . . . . . . . . . . . . . . . . . . . . 89 Asus Transformer Prime. . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Escritorio principal Asus Transformer Prime . . . . . . . . . . . . . . . . 94 Escritorio principal Asus Transformer Prime . . . . . . . . . . . . . . . . 94 Pantalla de bienvenida a la aplicacin de ASLab. . . . . . . . . . . . . . . 95 Informacin sobre grupo de investigacin de ASLab . . . . . . . . . . . . 95 Cmo aadir un nuevo robot a la interfaz de control . . . . . . . . . . . . . 96 Si se cancela el evento, el cuadro desaparece de la pantalla . . . . . . . . . 96 Cmo aadir un nuevo robot a la interfaz de control . . . . . . . . . . . . . 97 Opciones de control del sistema ROS . . . . . . . . . . . . . . . . . . . . 97 Opciones de control del sistema ROS . . . . . . . . . . . . . . . . . . . . 98 Es necesario pulsar en un nodo para actualizar la lista de nodos ROS . . . . 98 Es necesario pulsar para actualizar la lista de nodos ROS . . . . . . . . . . 99 Estructura del archivo tipo launch para la denicin de nodos ROS . . . . . 100 Simulacin en el PC del nodo Stage que permite obtener mediciones del lser 101 Simulacin del nodo Stage con un mapa diferente . . . . . . . . . . . . . . 102 Lanzamiento en el terminal de Ubuntu del chero de conguracin . . . . . 102 Lanzamiento en terminal de Ubuntu del nodo que suministra informacin del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 87. Ejemplo de manejo del robot con el Joystick Virtual . . . . . . . . . . . . . 103 88. El robot obedece las instrucciones del Joystick . . . . . . . . . . . . . . . 103 89. Se visualizan el mapa y el robot juntos. . . . . . . . . . . . . . . . . . . . 104 90. La aplicacin permite tambin hacer zoom y rotar la pantalla a gusto del usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 91. Seleccin del servicio de Cliente SSH de ASLab. . . . . . . . . . . . . . . 105 92. Cuadro de dilogo de la conexin remota, en este caso SSH. . . . . . . . . 106 93. Solicitud de contrasea para el usuario solicitado. . . . . . . . . . . . . . . 107 94. Conexin SSH realizada con xito. . . . . . . . . . . . . . . . . . . . . . . 107 95. Resultado de teclear ls en la ventana de comandos. . . . . . . . . . . . . 108 96. Resultado de teclear ls en la ventana de comandos. . . . . . . . . . . . . 109 97. Tocar y arrastrar para seleccionar la zona a copiar. . . . . . . . . . . . . . . 109 98. Seleccin de la zona a copiar. . . . . . . . . . . . . . . . . . . . . . . . . . 110 99. Pegado del contenido del portapapeles en la consola de comandos. . . . . . 111 100.Seleccin de opciones de conguracin. . . . . . . . . . . . . . . . . . . . 111 101.Nuevas dimensiones de la pantalla del terminal. . . . . . . . . . . . . . . . 112 102.Redimensionado de la pantalla del terminal. . . . . . . . . . . . . . . . . . 113 103.Colores disponibles para personalizar la apariencia de la herramienta. . . . 113 104.Conguracin personalizada de las opciones de la herramienta. . . . . . . . 114
D OCUMENTO I. M EMORIA l NDICE DE FIGURAS
105.Otros servicios ofrecidos para la conexin remota, aparte de la conexin SSH.114 106.Desconexin de la mquina. . . . . . . . . . . . . . . . . . . . . . . . . . 115 107.Cierre de la herramienta SSH y vuelta a la aplicacin de control visual. . . 116 108.Pantalla de la herramienta de control que se muestra al volver del cliente SSH.116 109.Iconos de la barra de sistema de Android. . . . . . . . . . . . . . . . . . . 117 110.Visor de aplicaciones recientes. . . . . . . . . . . . . . . . . . . . . . . . . 118 111.Visor de aplicaciones recientes vaco. . . . . . . . . . . . . . . . . . . . . 118 112.Apagado del sistema y del disposito Android. . . . . . . . . . . . . . . . . 119
PARTE I
MEMORIA
Captulo 1 Introduccin
1.1. Autonomous Systems, ASys
El proyecto ASys se centra en la investigacin de arquitecturas universales cognitivas. Es un proyecto que generaliza los conocimientos adquiridos del estudio de los cerebROS animales y se centra en el desarrollo de sistemas de control inteligente industrial. De este modo, se ofrece un modelo de cognicin que, efectivamente y de manera homognea, integra aspectos autonmicos, emocionales y cognitivos. El principal esfuerzo de este grupo consiste en desarrollar la ciencia y la tecnologa necesaria para crear sistemas totalmente autnomos para el mundo real, y en n litmo, las aplicaciones industriales. Ser completamente autnomo signica, no slo poder realizar tareas en ambientes que sean totalmente desconocidos, sino tambin la capacidad de manejo de aquellas tareas que son desconocidas, inciertas para el individuo u objeto de estudio en cuestin. Adems se debe contemplar la capacidad ms importante y determinante del asunto, la capacidad de auto-reconguracin. Esto es, pensar de forma evolutiva, de la misma forma que los seres se han adaptado al medio, los sistemas deben hacerlo. Dos naturalistas, Charles Darwin y Alfred Russel Wallace, propusieron de forma independiente ya en 1858, que la seleccin natural es el mecanismo bsico responsable del origen de nuevas variantes genotpicas y, en ltima instancia, de nuevas especies. Los sistemas completamente autnomos perciben, aprenden y son capaces de evolucionar a otra conguracin segn el entorno que les rodea. As son capaces de contemplar y ser conscientes de sus limitaciones, sus errores internos, etc. Modelos heterogneos con la capacidad de aportar mltiples soluciones a los problemas que surgen, control inteligente y, mucho ms importante, conciencia de s mismo, se debe proporcionar para que un sistema funcione correctamente. De esta forma se podr dotar a los sistemas de la capacidad de decisin, de valoracin sobre lo que es mejor o peor, de la conciencia de los elementos que lo componen y lo reodean.
I. M EMORIA l 1. I NTRODUCCIN
Todo ello para conseguir relizar una tarea con la mayor autonoma posible y aumentar la probabilidad del xito en la ejecucin de dicha tarea. La investigacin del proyecto ASys es por lo tanto, a veces, bastante abstracta y multidisciplinar por naturaleza. Siempre se trata de llevar un seguimiento de los desarrollos propios en tres diferentes aspectos: el mundo del control de proceso continuo, el mundo de la robtica y el mundo de la informtica.
1.2.
Autonomous Systems Laboratory, ASLab
El Laboratorio de Sistemas Autnomos es un grupo de investigacin centrado en el desarrollo de la tecnologa necesaria para obtener sistemas autnomos y robustos. Los Sistemas Autnomos (AS), suponen la parte ms emocionante para la investigacin tcnica. Son verdaderamente sistemas muy complicados y se hacen absolutamente carsimos en el esfuerzo. Es necesaria una gran capacidad tanto de concentracin, como de abstraccin para conseguir realizar avances en la investigacin de esta tcnica. ASLab est concienciado y preparado para cambiar el punto de vista que aportan los modelos tpicos en la investigacin acadmica. Pero, en cierto sentido, se realizan actividades desde una postura de miras al mundo industrial. Se pretende desarrollar tecnologa para sistemas autnomos en el mundo real, de forma que se dotar a los seres humanos libertad de supervisin, una vez que que el sistema est en funcionamiento. Ellos sern capaces de auto-gestionarse.
1.3.
Higgs Robot
Dentro del proyecto ASys existe una parte de prueba de los sistemas de control desarrollados. El robot Higgs es una de esas partes, en concreto del ASys Robot Control Testbed (RCT) , seleccionada para la demostracin de la dimensin cognitiva ms alta en un sistema fsico. En la gura 1 se observa el robot Higgs y sus componentes. Higgs permite la evaluacin de la arquitectura y de la tecnologa utilizada. Sus componentes son extrados de modelos biolgicos, por ejemplo, partes del cerebro de la rata como la amgdala, o la ganglia basal, o el hipocampo, que se tratan en otras actividades de investigacin.
1.3.1.
Estructura de Higgs
La base de Higgs es una plataforma mvil Pioneer 2-AT8 diseada por ActivMedia Robotics. Se trata de una plataforma robusta que incluye todos los elementos necesarios para implementar un sistema de control y de navegacin. Los elementos que componen
10
Figura 1. Robot Higgs. Objetivo del desarrollo del RCT. Banco de pruebas de sistemas autnomos la plataforma etn diseados especialmente para aplicaciones en exteriores. Adems es posible incorporar sistemas y elementos adicionales a esta plataforma. 1.3.1.1. La plataforma
La plataforma base se llama ASLab Higgs, como una referencia al Boson de Higgs. Higgs es un robot mvil de tamao pequeo. Su estructura est hecha de aluminio. Su peso total es de 15 kg, siendo capaz de transportar hasta 40 kg. Desde el punto de vista del hardware, Higgs se compone de: Panel del robot: Es la plataforma superior del robot, diseada para el montaje posterior de componentes nuevos como cmaras o sistemas de lser, etc. Cuerpo del robot: Es un elemento en forma de caja de aluminio. En su interior se encuentran las bateras, los actuadores, circuitos electrnicos y otROS elementos. Tambin incorpora elementos adicionales, tales como un PC de a bordo, un mdem y sensores. Panel de control: Es lugar por donde se accede al microcontrolador del robot, colocado en el panel de robot. Se compone de varios botones para el control del robot, leds de control de estado (encendido-apagado, estado del microcontrolador,
11
carga de la batera) y un puerto serie RS-232 que permite la conexin y es el enlace de comunicacin con un PC externo. Sensores de ultrasonidos: El robot mvil est provisto de dos conjuntos de ocho sensores cada uno, que permiten la deteccin y localizacin de objetos en el entorno. Las matrices de sensores se encuentran en la parte delantera y trasera del robot. Actuadores: El robot incorpora cuatro motores Pittman GM9236E204. Cada uno incluye un encder ptico para determinar la velocidad del robot y la posicin. Microcontrolador: Es un microcontrolador Hitachi H8S que incluye varios componentes, tales como memorias, puertos serie, entradas, salidas, buses de 8 bit, entre otROS. El microcontrolador lleva a cabo operaciones como enviar y registrar las seales de los sensores, controlar los actuadores, y algunas otras operaciones de bajo nivel. Bumpers: Son parachoques sensorizados adicionales que se han unido a la plataforma. Existen cinco unidades en la parte delantera y otROS cinco en la parte trasera. Bateras: Existen tres bateras de 12 VDC 7 Ah-h, situadas en la parte trasera del robot. Proporcionan 252 W-h, lo que asegura varias horas de autonoma durante el movimiento del robot. El nivel de carga de las bateras se puede comprobar observando el correspondiente LED del panel de control. Adems del hardware, el robot incorpora una parte de software. El software se divide en dos, el proporcionado por el fabricante y el desarrollado por los miembROS del equipo ASLab. AROS: ActivMedia Robotics Operating System, es el sistema operativo que consiste bsicamente en procesos de servicio que se ejecutan en el microcontrolador Hitachi de Higgs. Se trata de un software de bajo nivel que se encarga de la regulacin de la velocidad de los motores, las seales de los snares, las seales de los encoders, y otras tareas de bajo nivel. Este software tambin se encarga de comunicar la informacin obtenida de otras aplicaciones software a travs de la interfaz RS-232. ARIA: Se trata de una interfaz de programacin (API) basada en C + + para controlar el robot. Acta como el cliente en la conexin cliente-servidor y permite programar aplicaciones de alto nivel. Estas aplicaciones pueden ser de control inteligente, como la evasin de obstculos, reconocimiento de objetos,
12
exploracin, etc. El control del robot puede basarse en comandos directos, comandos de movimiento o acciones a nivel abstracto. Software del equipo ASLab: Existen adems una serie de mdulos desarrollados por los miembROS del equipo ASLab, que permiten ampliar y aadir capacidades a Higgs. Los mdulos desarrollados consisten en software de: 1. Comunicacin. 2. Emociones sintticas. 3. Integracin de voz SOAR. 4. Servidor de control RT-CORBA. 5. Registro del estado del robot, RT-CORBA. 6. Cliente Java basado en CORBA. 7. Operacin remota basada en CORBA. 8. Reconocimiento de supercies. 1.3.1.2. Componentes embarcados
Sobre la plataforma que sirve de base del robot, se encuentran montados una serie de componentes que permiten extender las funcionalidades del robot. Estos componentes se montan y conectan entre s, dotando a Higgs de un amplio abanico de posibilidades a la hora de llevar a cabo su misin. Como puede verse en la gura 1, los componentes se han montado sobre la plataforma base Pioneer 2-AT8. Ordenador de a bordo: Se trata de un ordenador conectado a la plataforma base, cuya misin es la de facilitar la comunicacin del microcontrolador, el control del robot, la ejecucin de las operaciones complejas de navegacin, y las operaciones adicionales de comunicacin. En cuanto al software, el ordenador de a bordo utiliza Linux como sistema operativo, adems de contar con un software en tiempo real RTAI y el servidor RT-CORBA. Lser: Es un lser Sick de escaneo para aplicaciones de robtica mvil. Est colocado en la parte frontal del panel de robot. Permite detectar obstculos adems de poder realizar mapas gracias a sus mediciones. Kinect: El robot incorpora un sensor que lo dota de la parte de visin y geometra 3D, al tiempo que permite la implementacin de reconocimiento de gestos, incluso comandos de voz. Radio: Se trata de un sistema de radio para DGPS.
13
GPS: Es un sistema GPS de alto rendimiento. Brjula: Permite al robot orientarse. AcelermetROS 1.3.1.3. Sistemas adicionales
Junto con la plataforma base y los sistemas de a bordo, Higgs incluye algunos sistemas adicionales de apoyo para completar su funcionamiento. Red inalmbrica: Es un subsistema adicional incluido en el banco de pruebas para permitir la comunicacin con la red inalmbrica local del laboratorio ASLab. Est compuesto por una tarjeta inalmbrica colocada en el ordenador de a bordo, una antena que se hace necesaria al estar la tarjeta colocada en el interior del cuerpo del robot. Tambin existe un punto de acceso conectado a la LAN del laboratorio. Mando de control: Se trata de un dispositivo porttil para el control remoto del robot.
1.3.2.
Descripcin funcional del robot
La descripcin funcional del banco de pruebas denominado robot Higgs se ha hecho a travs de la especicacin de casos de uso y requisitos, la cual no se incluye en este documento. Un requisito funcional ha sido denido en la ontologa como un requisito que especica una operacin o comportamiento que un sistema debe realizar. Los requisitos funcionales considerados para el RCT pueden clasicarse en primarios y secundarios. Un requisito funcional primario se reere a una capacidad principal que debe cumplir el sistema. En el caso del RCT, se han considerado la navegacin y la supervivencia como dos requisitos funcionales primarios. Un requisito funcional secundario se reere a una capacidad adicional deseada en el sistema. Para el RCT, estos requisitos funcionales secundarios son: explorar el medio ambiente, evitar un obstculo mientras el robot se mueve o est explorando, identicacin de un objeto en el medio ambiente y su bsqueda.
1.4.
Motivacin y objetivos
Este proyecto consiste en el desarrollo de una aplicacin informtica basada en un entorno de desarrollo de aplicaciones para dispositivos mviles. En concreto se trata de una aplicacin en el sistema operativo Android, que permita la interaccin con el robot Higgs descrito en el apartado 1.3 de este documento.
14
La aplicacin consistir en una interfaz grca intuitiva y fcil de manejar. El sistema operativo elegido ser Android, debido a su principal ventaja de utilizar cdigo abierto. Esto permitir poder desarrollar aplicaciones de forma libre, dinmica y con amplio soporte de la comunidad de desarrolladores que componen el marco de desarrollo de aplicaciones para dispositivos Android. Adems, la aplicacin desarrollada se podr testar en un dispositivo fsico que implemente un sistema operativo Android y cuya versin coincida con la versin en la que ha sido desarrollada la aplicacin, es decir, la version de Android 4.0.3. La arquitectura software que permitir la conexin con el robot, as como el envo de informacin entre ambos lados de la conexin, estar basada en ROS (Robot Operating System). ROS es sistema operativo que proporciona libreras y herramientas para el desarrollo de aplicaciones robticas. ROS, permite que el desarrollador se abstraiga de los aspectos hardware de la robtica, de los drivers necesarios, de las libreras, de la visualizacin y manejo de mensajes y de la gestin de software entre otras muchas ventajas. ROS, es adems, una comunidad de cdigo abierto que ofrece la posibilidad de mejorar y desarrollar futura tecnologa para acrecentar el soporte de sus usuarios. Los objetivos principales del proyecto son: La arquitectura software desarrollada debe estar basada en sistema operativo Android. La comunicacin con el robot ha de ser inalmbrica El sistema debe poder comunicarse con componentes tipo ROS. Esto facilitar la independencia de la capa fsica que se utilice y de sistema operativo en cada caso. El software utilizado permita la implementacin en dispositivos mviles tales como, smartphones, tablets, etc. Utilizar software libre, de forma que exista una gran comunidad de apoyo y cdigo abierto disponible. La interfaz de usuario debe ser de fcil comprensin y cmoda en el uso, tanto para la visualizacin de los datos del robot, como para la teleoperacin. Visualizacin en la pantalla de mapas. Visualizacin en la pantalla de los puntos escaneados por el lser. Control teleoperado de la plataforma robtica mvil. A poder ser con un joystick. Visualizacin en la pantalla de la imagen de la cmara del robot, que sirva para la teleoperacin y observar el movimiento del robot.
15
Visualizacin de los nodos del sistema ROS, para estar informados del estado del sistema. A nivel personal quiero destacar que mis objetivos fueron el mejorar mis conocimientos en el campo de la programacin orientada a objetos. Enfrentarme a situaciones complicadas, como es el desarrollo de aplicaciones para dispositivos mviles orientadas al usuario. Y de forma alguna, aprender a tomar decisiones importantes en cuanto a temas de desarrollo se trate. Adems de aprender a desenvolverme con herramientas de desarrollo totalmente desconocidas para m, como ha sido la plataforma de desarrollo Eclipse. Sobre todo, el inters que tena en el campo de desarrollo de aplicaciones para smartphones y tabletas electrnicas, que me ha hecho ver que las cosas no son tan fciles, aunque puedan parecerlo.
16
Captulo 2 ESTADO DEL ARTE

2.1.
2.1.1.
Android
Historia y precedentes
El sistema operativo ms usado en smartphones actualmente en el mundo, no es una idea que se le ocurri a alguien un da y tampoco tuvo un camino fcil para empezar a funcionar, sino que surge poco a poco y vive diferentes etapas hasta que el primer Android fue capaz de ver la luz. Para hablar de la "prehistoria"de Android se debe empezar por hablar de hombre llamado Andy Rubin. En 1986, Andy recibi su licenciatura en Ciencias de la Computacin en la Universidad de Utica, Nueva York. Se puede considerar que aqu empieza a gestarse todo lo que luego sera Android en su cabeza. Curiosamente, su primer trabajo importante como ingeniero fue en Apple. Luego pas a formar parte de una empresa que surgi de Apple llamada General Magic, participando en el desarrollo de Magic Cup, lo que pretenda ser un sistema operativo para telfonos o PDAs. Sin embargo, General Magic fracas y Andy se uni a Artemis Research, que acab comprada por Microsoft. Aos ms tarde, Andy fund Danger Inc., que nalmente sera tambin comprada por Microsoft. En Danger Inc. suceden cosas cosas muy importantes como el desarrollo del Hiptop, gura 2, un telfono que marcara las primeras lneas de lo que seran los Smartphones. En un momento dado, Andy, se siente tan frustrado que decide abandonar la compaa de la que era CEO. Todo ello le llevo a su paso nal en esta etapa, fundar en 2003 Android Inc. Andy Rubin llevaba desde 1989 hasta 2003 trabajando como ingeniero en telecomunicaciones y en el mundo de los telfonos mviles. En Agosto de 2005, cuando Android Inc. contaba con 22 meses de vida, Google adquiri la empresa. Andy pasa a formar parte del equipo de Google, y es nombrado vicepresidente de ingeniera de Google supervisando el desarrollo de Android.
17
I. M EMORIA l 2. ESTADO DEL ARTE
Figura 2. Telfono HipTop, primer telfono que marcara la lnea de los Smartphones. Android ya tena toda una base para empezar a trabajar y formarse. Un proceso que haba durado nada ms y nada menos que 16 aos haba construido una slida base sobre la que todo iba a empezar a funcionar. A partir de aqu comienza rumoreo acerca de qu estaba haciendo Google con una compaa de desarrollo de sistemas para telfonos mviles. Existen multitud de artculos, especialmente de Agosto de 2005, en los que se especula sobre muchsimas cosas, y algunas realmente curiosas. Ahora es cuando se sabe todo lo que estaba sucediendo, estaban planeando lo que pretendan llevar a ser el futuro de la telefona mvil, lo que queran convertir en el sistema operativo nmero uno de smartphone en el mundo.
Figura 3. HTC Dream, el primer telfono Android de la historia. No fue hasta el 5 de Noviembre de 2007 cuando el anuncio de Android se hizo ocial. Ese da se fundaba la OHA (Open Handset Alliance), una alianza comercial de 35 componentes iniciales liderada por Google, que contaba con fabricantes de terminales mviles, operadores de telecomunicaciones, fabricantes de chips y desarrolladores de software. El mismo da se dio a conocer por primera vez lo que hoy conocemos como Android, una plataforma de cdigo abierto para mviles que se presentaba con
18
la garanta de estar basada en el sistema operativo Linux. Pocos das despus, en concreto el 12 del mismo mes de Noviembre, se "liberaba.el primer "kit"de desarrollo de aplicaciones para que los programadores comenzasen a "hacer de las suyas", nacan las primeras apps del sistema. Google tuvo que llegar a acuerdos con fabricantes de telfonos mviles para desarrollar el primer dispositivo Android de la historia. La compaa HTC fue quin fabric el primer Nexus o Google Phone, adems el primer Android tambin fue HTC, el telfono Dream de esta compaia que fu lanzado el 22 de octubre de 2008. Vase la gura 3.
2.1.2.
Actualizaciones
Uno de los elementos diferenciales de Android respecto al resto de sistemas operativos mviles es la cantidad de actualizaciones que recibe. No hay ni que decir, que Android es de los que ms se preocupa por mejorar las prestaciones de su dispositivo sin necesidad de cambiarlo continuamente, y es innegable que en ese terreno Android es el nmero uno indiscutible. Sus actualizaciones continuas han permitido al usuario mantener los dispositivos en las ltimas versiones y con mejoras notables unas tras otras. Estas actualizaciones del sistema operativo base tpicamente arreglan bugs y agregan nuevas funciones. Generalmente cada actualizacin del sistema operativo Android es desarrollada bajo un nombre en cdigo de un elemento relacionado con postres. As tenemos un historial de actualizaciones en el que se pueden observar las mejoras introducidas por los desarrolladores de Android: Versin 1.0 Apple Pie Versin 1.1 Banana Bread Versin 1.5 Cupcake: trajo una gestin de la cmara y GPS del dispositivo ms rpidos, teclado virtual y subida directa de vdeos a Youtube
Figura 4. Android 1.5 Cupkake Versin 1.6 Donut: introdujo la bsqueda por voz, indicador grco de batera y la integracin de las funciones de la cmara con la galera de imgenes.
19
Figura 5. Android 1.6 Donut Versin 2.0 / 2.1 Eclair: llegaron mejoras sustanciales, entre las que destacan la gestin de mltiples cuentas de correo y sincronizacin de contactos simultneamente adems de soporte para Microsoft Exchange y la compatibilidad con HTML5.
Figura 6. Android 2.0 Eclair
Versin 2.2 Froyo: quedar como la primera en incorporar la funcin de compartir internet (convirtiendo el terminal mvil en un Hotspot Wi-Fi), aunque la implementacin del Flash de Adobe en su versin 10.1 supuso un gran avance.
Figura 7. Android 2.2 Froyo Versin 2.3 Gingerbread: trajo mejoras generales en velocidad y optimizacin global del sistema, adems de la compatibilidad para el estndar del futuro en medios de pago, el NFC. Versin 3.0 / 3.1 / 3.2 Honeycomb: la versin de Google para los dispositivos mviles de gran formato que estaba diseada especcamente para mejorar la experiencia de usuario y plantear batalla al iPad de Apple. Versin 4.0 Ice Cream Sandwich.
20
Figura 8. Android 2.3 Gingerbread
Figura 9. Android 4.0 Ice Cream Sandwich Versin 4.1 Jelly Bean.
2.1.3.
Caractersticas
Android, al contrario que otros sistemas operativos para dispositivos mviles como iOS o Windows Phone, se desarrolla de forma abierta. Se puede acceder tanto al cdigo fuente como al listado de incidencias. Se pueden ver problemas an no resueltos y reportar problemas nuevos. El que se tenga acceso al cdigo fuente no signica que se pueda tener siempre la ltima versin de Android en un determinado mvil, ya que el cdigo para soportar el hardware de cada fabricante no es pblico. En sus comienzos, Android era un sistema operativo pensado para ser usado con teclado, y gracias a un cursor, poder navegar entre las aplicaciones. Poco despus, antes del lanzamiento del primer telfono Android, esta losofa cambi para convertirse en eminentemente tctil, y poder competir contra el recin lanzado iPhone. La estructura del sistema operativo Android se compone de aplicaciones que se ejecutan en un framework Java de aplicaciones orientadas a objetos. Estas aplicaciones corren sobre el ncleo de las bibliotecas de Java en una mquina virtual Dalvik con compilacin en tiempo de ejecucin. Dalvik es la mquina virtual que utiliza la plataforma, diseada por Dan Bornstein con contribuciones de otros ingenieros de Google. Dalvik est optimizada para requerir poca memoria y est diseada para permitir ejecutar varias instancias de la mquina virtual simultneamente, delegando en el sistema operativo subyacente el soporte de aislamiento de procesos, gestin de memoria e hilos.
21
Figura 10. Conversin de .jar a .dex A menudo, Dalvik es nombrada como una mquina virtual Java, pero esto no es estrictamente correcto, ya que el bytecode con el que opera no es Java bytecode. Sin embargo, la herramienta dx incluida en el SDK de Android permite transformar los archivos Class de Java compilados por un compilador Java al formato de archivos Dex. Vase gura 10. El nombre de Dalvik fue elegido por Bornstein en honor a Dalvk, un pueblo de Islandia, donde vivieron antepasados suyos. Como curiosidad, el sistema operativo est compuesto por 12 millones de lneas de cdigo, incluyendo 3 millones de lneas de XML, 2,8 millones de lneas de lenguaje C, 2,1 millones de lneas de Java y 1,75 millones de lneas de C++.
2.2.
ROS
El sistema operativo ROS (Robot Operating System) es un framework de software que permite el desarrollo de software para aplicaciones robticas. La base de ROS consiste en proporcionar un sistema operativo con la funcionalidad de un clster informtico heterogneo. ROS fue desarrollado en 2007 bajo el nombre de "switchyard"por el Stanford Articial Intelligence Laboratory, con apoyo del proyecto Stanford AI Robot (STAIR). A partir de 2008, el desarrollo continu principalmente en Willow Garage, un instituto de investigacin de robtica con ms de veinte instituciones que colaboran en un modelo de desarrollo federado. ROS ofrece servicios tpicos de sistema operativo como son: Abstraccin de hardware. Control de dispositivos a bajo nivel.
22
Provisin de funcionalidades de uso comn. Paso de mensajes entre procesos. Gestin de paquetes. El sistema est basado en una arquitectura en la que los procesos se ejecutan en forma de nodos que reciben y envan mensajes de sensores, controles, estados, planicacin, actuadores, etc. Se compone de una biblioteca orientada a sistemas operativos tipo Unix, tales como Linux Ubuntu, considerada la ms estable, aunque tambin existen otras variantes como Fedora y Mac OS X, que se consideran en desarrollo experimental. ROS tiene dos tipos bsicos que lo componen, uno el Sistema Operativo tal y como se ha descrito hasta ahora, y otro referido a la gestin de paquetes desarrollados por los usuarios. Estos paquetes se organizan en carpetas denominadas stacks. Los paquetes son los encargados de ofrecer la funcionalidad de ROS propiamente dicha, por ejemplo funciones de localizacin, mapeo, planicacin de eventos, escaneo, simulacin, etc. Al mismo tiempo, ROS cumple con los trminos de licencia BSD, que permiten licencias de software libre, y es un software de cdigo abierto. Su uso es gratuito en el mbito comercial y el de la investigacin. Desde el lanzamiento de ROS se han sucedido hasta cinco versiones: Fuerte: 23 de Abril de 2012. Electric Emys: 30 de Agosto de 2011. Diamondback: 2 de Marzo de 2011. C Turtle: 3 de Agosto de 2010. Box Turtle: 1 de Marzo 2010. ROS 1.0: 22 de Enero de 2010.
Un sistema ROS se caracteriza por: Un nodo maestro, encargado de coordinar al resto de nodos. Publicadores o suscriptores a los ujos de datos: imgenes, msica, lser, control... Creacin y destruccin de nodos. Multiplexado de la informacin. Los nodos estn perfectamente distribuidos, permitiendo operar de forma organizada en procesos multi-ncleo, GPU y clsters.
23
Parmetros de servidor. Sistemas de prueba.
Los paquetes ROS se caracterizan, entre otras muchas cosas, por: Capacidad de percepcin. Capacidad de identicacin de objetos. Capacidad de reconocimiento facial y de gestos. Capacidad de seguimiento del movimiento. Capacidad de visin de forma estreo: percepcin de profundidad a travs de dos cmaras
2.2.1.
ROS fuerte
Figura 11. ltima actualizacin de ROS: ROS FUERTE ROS Fuerte Turtle es la quinta versin de la distribucin de ROS. Se lanz el da 23 de Abril de 2012 e incluye numerosas mejoras que permiten y facilitan la integracin de ROS con otros frameworks de software. Esta mejora incluye una nueva versin del sistema de compilacin, el cambio al Qt framework y a las libreras estndares. El objetivo de ROS es hacer el cdigo lo ms reutilizable posible dentro del mbito de la robtica, favoreciendo el desarrollo de la comunidad de usuarios y ampliando el abanico de oportunidades de implementacin del sistema ROS. Segn fuentes de ROS, esta versin es una nueva base slida para la generacin de grandes bibliotecas dentro del campo de la robtica.
24
2.2.2.
ROS Java
El desarrollo de nuevos elementos del sistema ROS es posible gracias a que ste utiliza cdigo abierto. Los usuarios y desarrolladores de ROS tienen la oportunidad de crear nuevos componentes, mejorar los ya existentes o simplemente ayudar a que el sistema sea ms robusto y exible. De esta forma se ayuda a que el sistema sea robusto, exible y heterogneo cuando se utilice en cualquier plataforma. ROS tiene una ventaja relevante y es que es capaz de implementar componentes desarrollados en cdigos de programacin distintos. Esto hace al sistema ser adaptativo en funcin del tipo de nodo que se requiera y sobre todo hace al sistema ser capaz de correr en gran variedad de mquinas. Esta caracterstica ha resultado ser de gran importancia en el desarrollo de este proyecto, ya que se precisa de cdigo Java para el desarrollo de aplicaciones para dispositivos mviles Android. En un principio, ROS
Figura 12. ROS Java permiti el desarrollo de aplicaciones para Android. ofreca la posibilidad de desarrollo del sistema sobre cdigo C++, o incluso cdigo Python, entre otros. No fue hasta su versin Electric Emys, publicada el 30 de Agosto de 2011, que fue posible el desarrollo de ROS en Android, realmente hablando, en Java. Gracias a Damon Kohler, un ingeniero de Google, se ampli la librera de Java existente y se construy una estructura slida sobre la que poder desarrollar aplicaciones Android. Pronto se ofrecieron nuevos componentes que permitiran crear aplicaciones grcas en dispositivos Android, y que haran posible la interaccin con robots que implementaran la arquitectura de software ROS.
Figura 13. Robot que puede ser manejado con un Smartphone con Android.
25
2.3.
Sistemas distribuidos de componentes
Los sistemas distribuidos suponen un paso ms en la evolucin de los sistemas informticos. Deben ser entendidos desde el punto de vista de las necesidades que las aplicaciones plantean y las posibilidades que la tecnologa ofrece. Un sistema distribuido se dene como un conjunto de computadores interconectados, que comparten un estado y ofrecen una visin general del sistema nica. Los recursos de las diferentes mquinas en red que componen del sistema, se integran de forma que se tiene la sensacin de trabajar con sistema completo y disponibe en todos los sentidos. El usuario accede a los recursos del sistema distribuido a travs de una interfaz grca de usuario desde un terminal, despreocupndose de su localizacin. Las aplicaciones ejecutan una interfaz de llamadas al sistema como si de un sistema centralizado se tratase, por ejemplo POSIX. Un servicio de invocacin remota resuelve los accesos a los recursos no locales utilizando para ello la interfaz de red. Los sistemas distribuidos proporcionan de forma transparente el proceso de compartir los recursos, facilitando el acceso y la gestin, e incrementando la eciencia y la disponibilidad del sistema.
Figura 14. Arquitectura de un sistema distribuido. Los sistemas distribuidos de componentes muestran los recursos de forma homognea, ocultando la distribucin interna. Es ms, el usuario y las aplicaciones propias del sistema no ven una red, sino un sistema que en realidad es totalmente indistinguible de uno centralizado. Cabe destacar que un sistema distribuido no es un sistema en red, ya que estos ltimos pueden denirse como un conjunto de sistemas con estados independientes. Un sistema distribuido se dene como un sistema con un estado global. 26
En realidad, la topologa y los atributos fsicos de la red se encuentran ocultos por los protocolos de red, mientras que la arquitectura de cada mquina est oculta por el sistema operativo que implemente. Adems, los componentes de un sistema distribuido pueden ser heterogneos, es por ello que se requiere de una capa de software, comunmente deniminada middleware, que permite la visin de un sistema nico. El mtodo que utiliza ROS es el clustering. Un cluster puede denirse como un grupo de computadores conectados entre s a travs de un sistema en red y un software que realiza la distribucin de la carga de trabajo entre los equipos. Por lo general, este tipo de sistemas cuentan con un centro de almacenamiento de datos nico. En el caso de ROS, el nodo mster.
2.3.1.
Propiedades de los sistemas distribuidos
Un sistema distribuido que pretenda ofrecer una visin de sistema nico deber cumplir las propiedades que se presentan a continuacin. 1. Transparencia: El objetivo principal de un sistema distribuido es proporcionar al usuario y a las aplicaciones del sistema una visin de los recursos que parezcan estar gestionados por una sola mquina. La distribucin fsica de los recursos es transparente. Pueden describirse diferentes aspectos de la transparencia: Identicacin: Los espacios de nombres de los recursos son independientes de la topologa de la red y de la propia distribucin de los recursos. De esta forma, una aplicacin puede referirse a un recurso con un nombre independientemente de en qu nodo se ejecute. Ubicacin: La ubicacin fsica de los recursos es desconocida tanto para las aplicaciones como para los usuarios. Esto implica tambin que los recursos pueden migrar entre nodos sin que las aplicaciones se vean afectadas. Replicacin: No es necesario para el usuario ni las aplicaciones conocer cuntas unidades de cada recurso existen. Paralelismo: Una aplicacin puede ejecutarse en paralelo sin tener que especicarlo, y sin inuir como consecuencia sobre la ejecucin de la misma. Sobretodo, esta propiedad tiene que ver con la capacidad del sistema de permitir distribuir procesos y memoria. Comparticin: El que un recurso compartido intente ser accedido simultneamente desde varias aplicaciones no tiene efectos sobre la ejecucin de la aplicacin. Rendimiento: Es inevitable que al implementar las propiedades de un sistema distribuido se produzca una prdida del rendimiento del sistema. Es
27
necesario siempre encontrar un compromiso entre las soluciones que este tipo de sistemas aportan, y la capacidad de respuesta unida al rendimiento que se necesite por parte del sistema. 2. Escalabilidad: Una de las caractersticas de los sistemas distribuidos es su modularidad. Esto permite una gran exibilidad y posibilita la escalabilidad del sistema, denida como la capacidad para crecer sin aumentar su complejidad ni disminuir su rendimiento. Uno de los objetivos del diseo de un sistema distribuido es extender la escalabilidad a la integracin de servicios. La escalabilidad presenta dos aspectos. El sistema distribuido debe proporcionar espacios de nombres sucientemente amplios, de forma que no supongan una limitacin inherente. El sistema debe mantener un buen nivel de rendimiento en el acceso a los recursos cuando el sistema crece. 3. Fiabilidad y tolerancia a fallos: La abilidad de un sistema puede denirse como la capacidad de realizar correctamente y en todo momento las funciones para las que se ha diseado. Se han de tener en cuenta dos aspectos: Disponibilidad: Es la fraccin de tiempo en la que el sistema est operativo. La disponibilidad se puede incrementar utilizando componentes de mayor calidad, o disear el sistema segn el criterio de replicacin de componentes que permita seguir operando al sistema an cuando algunos de ellos fallen. Tolerancia a fallos: An con una alta disponibilidad, un fallo en un momento determinado puede acarrear consecuencias desastrosas. La tolerancia a fallos expresa la capacidad del sistema para seguir operando correctamente ante el fallo de alguno de sus componentes, enmascarando el fallo al usuario o a la aplicacin. Por lo tanto, la tolerancia a fallos implica detectar el fallo y continuar con el servicio. 4. Consistencia: El problema de mayor complejidad es el de la gestin del estado global para evitar situaciones de inconsistencia entre los componentes del sistema. El problema radica en la necesidad de mantener un estado global consistente en un sistema con varios componentes, cada uno de los cuales posee su propio estado local. Los nodos del sistema se hallan fsicamente distribuidos, por lo que la gestin del estado global depende fuertemente de los mecanismos de comunicacin, a su vez soportados por una red sujeta a fallos.
28
Captulo 3 ENTORNO DE DESARROLLO

3.1. Sistema Operativo: Ubuntu
El sistema operativo que se ha utilizado para el desarrollo de este proyecto ha sido Ubuntu en su versin 10.04. Ubuntu es un sistema operativo mantenido por Canonical y la comunidad de desarrolladores. Utiliza un ncleo Linux y su origen est basado en Debian GNU/Linux. Ubuntu est orientado al usuario novel y promedio, con un fuerte enfoque en la facilidad de uso y mejorar la experiencia de usuario. Est compuesto de mltiple software normalmente distribuido bajo una licencia de software libre o de cdigo abierto. Algunas de las caractersticas tcnicas de Ubuntu 10.04, comparado con sus versiones anteriores, son: Utiliza un Kernel de Linux en su versin 2.6.32.11. Utiliza GNOME 2.30. En Kubuntu KDE SC 4.4.2. GIMP 2.6.8 slo disponible desde los repositorios. Posee un nuevo artwork. Renovado el slideshow del instalador Ubiquity. Removido HAL para hacer ms rpido el inicio del sistema y regresar despus de suspendido. Drivers open source para Nvidia ahora se incorporan por defecto. Nuevas caractersticas para Ubuntu Enterprise Cloud (UEC). Mejorada versin de likewise-open, paquete que provee autenticacin para Active Directory y soporte de servidor para Linux.
29
I. M EMORIA l 3. ENTORNO DE DESARROLLO
Ubuntu One mejora la sincronizacin. Explicando un poco ms las caractersticas anteriormente enumeradas se puede decir que el motor de todo sistema es el kernel. Esta actualizacin Kernel 2.6.32 incluye mejoras que hacen de Ubuntu 10.04 un sistema ms able, seguro y robusto. El Gnome, en su versin Gnome 2.30., es el entorno de escritorio por defecto en Ubuntu. Pequeos aadidos en Nautilus, Empathy, la gestin de usuarios, soporte para ipod, etc. El nuevo driver libre para tarjetas Nvidia es Nouveau. Al mismo tiempo se ha mejorado la integracin de los drivers propietarios de Nvidia. Mejoras en el Centro de software de Ubuntu. Muy importante, sobre todo para usuarios nuevos, facilitando la instalacin de aplicaciones en Ubuntu 10.04
Figura 15. Ubuntu 10.04 Lucid Lynx Una vez enumeradas sus caractersticas tcnicas se expondrn los motivos del de su eleccin. Ubuntu como se ha dicho es un sistema operativo de software libre, por lo que no necesita licencia al ser gratuito. Permite una gran versatilidad en el entorno y el sistema si el usuario posee los conocimientos necesarios. Adems el sistema en esta versin es el que mejor trabaja con las versiones de ROS, concretamente en su versin de Fuerte. Otros sistemas operativos como Windows y Mac son incompatibles con las versiones de ROS con las que se va a trabajar ya
30
que los responsables del mantenimiento de dichas libreras solo aseguran su correcto funcionamiento con un sistema operativo Ubuntu. Cabe destacar que el resto del grupo de investigacin trabaja tambin con este sistema operativo, es por ello que siempre se trata de conseguir las mismas condiciones de trabajo. Esto podra causar algn problema, ya que si alguno de los miembros utilizara una versin distinta del sistema, no se podra garantizar al cien por cien que el software desarrollado funcionara. Siempre se trata de mantener la mismas condiciones en los equipos para no tener problemas de software.
3.2.
ROS
Como ya se describe en el apartado 2.2 de este documento, el sistema ROS tiene dos tipos bsicos que lo componen, uno el Sistema Operativo y otro referido a la gestin de paquetes, tanto los ofrecidos por los desarrolladores como por los usuarios de la comunidad. Los paquetes se organizaban en carpetas denominadas stacks, y eran los paquetes los encargados de ofrecer la funcionalidad de ROS. Por ello, ha sido necesario utilizar el sistema de paquetes de ROS para congurar el entorno de trabajo, permitiendo as un desarrollo correcto de la aplicacin objeto del proyecto. En primer lugar ha sido necesario bajar los paquetes que permiten utlizar el entorno Java de ROS, los paquetes rosjava. Tambin han sido necesarios algunos paquetes relacionados con el grupo de desarrollo de Google que tienen relacin directa con la comunidad ROS, los paquetes Google.
Figura 16. ROS: Robotic Operating System Por otro lado, he de mencionar aquellos stacks que han sido desarrollados por el grupo de investigacin de ASLab. En concreto los stacks de navegacin y de control de misin del robot Higgs, desarrollados por Carlos Hernndez Corbato y que gracias a ellos es posible comandar el robot. Estos stacks estn desarrollados, la mayora, en cdigo Python y son la base del pilotaje de Higgs. Para el desarrollo de paquetes o stacks de ROS existen guas o tutoriales en la propia pgina de informacin del sistema. Esta pgina se encuentra en la direccin: www.ros.org.
31
3.3.
Plataforma de desarrollo Eclipse
Eclipse es un entorno de desarrollo integrado de cdigo abierto multiplataforma para desarrollar Aplicaciones de Cliente Enriquecido, ms comunmente conocidas como RCP (Rich Client Platform). Esta plataforma tpicamente ha sido usada para desarrollar entornos de desarrollo integrado, en ingls IDE, como el IDE de Java llamado Java Development ToolKit (JDT) y el compilador que se entrega como parte de Eclipse, que tambin son usados para desarrollar el mismo Eclipse. Eclipse fue desarrollado originalmente por IBM, ahora se desarrolla bajo la Fundacin Eclipse, una organizacin independiente sin nimo de lucro que fomenta una comunidad de cdigo abierto y un conjunto de productos complementarios, capacidades y servicios.
Figura 17. Entorno de desarrollo Eclipse Classic. Versin 4.2. Eclipse fue liberado originalmente bajo la Common Public License, pero despus fue re-licenciado bajo la Eclipse Public License. La Free Software Foundation ha dicho que ambas licencias son licencias de software libre, pero son incompatibles con Licencia pblica general de GNU. Eclipse es un programa que se puede descargar de manera gratuita de la propia pgina de Eclipse (www.eclipse.org). Posee varias versiones iniciales en funcin de las necesidades del desarrollador. La nica diferencia entre ellas son los plug-ins iniciales que lo conguran por defecto. Esto no supone problema alguno ya que Eclipse posee una estructura modular, y es por esta modularidad por la que se pueden ir aadiendo pequeas partes o plug-ins para incrementar su funcionalidad. Concretamente este proyecto ha sido desarrollado sobre Eclipse Indigo en su versin classic 4.2 para linux.
32
3.3.1.
ADT Plugin
El ADT (Android Developer Tools) es un plugin para Eclipse que proporciona herramientas que se integran con el entorno de Eclipse y ofrece acceso a muchas de las caractersticas que son necesarias y que ayudan a desarrollar aplicaciones Android rpidamente. Adems el ADT proporciona un acceso GUI a muchas de las herramientas de lnea de comandos del SDK (Software Development Kit) de Android. Tambin incluye herramientas de diseo de interfaces de usuario para la creacin rpida de prototipos y que el diseo y la construccin de la interfaz de la aplicacin sea lo ms sencillo posible. Debido a que el ADT sea un plugin para Eclipse, se obtiene una funcionalidad IDE que permite el desarrollo Andoid bien denda y establecida. Muchas de las herramientas del SDK estn integradas en los mens de Eclipse, tambin en las perspectivas, o procesos que corren por debajo de Eclipse gracias al ADT.
Figura 18. Android Developer Tools Plugin Se utilizan editores Java que tienen muchas caractersticas comunes con el IDE de Eclipse, como la comprobacin de sintaxis en tiempo de compilacin, auto-compilado, y documentacin integrada para los APIs del Android framework. Se incluyen editores personalizados XML que permiten editar los archivos XML especcos de Android de manera visual. Un editor grco permite disear interfaces de usuario de manera fcil y sencilla, con simples gestos como son los de arrastrar y soltar los elementos en la pantalla grca de diseo. Una funcin muy bien desarrollada consiste en el acceso a la documentacin de forma directa, solo con poner el cursor sobre las clases, mtodos, o variables aparecen cuadros de informacin con la documentacin necesaria para la comprensin de los elementos utilizados. Adems se incluyen hipervnculos a la documentacin online, de forma que siempre se est informado en la versin ms actualizada.
33
Captulo 4 ARQUITECTURA DE SISTEMA

Para comprender la arquitectura del sistema completo es necesario comprender primero cmo se organizan los sistemas que lo componen. Esto es, que es necesario profundizar en las arquitecturas de los sistemas Android, ROS y el sistema robtico en s. En concreto, conocer en detalle los componentes que caracterizan a cada uno de los sistemas, de forma que se pueda comprender la arquitectura nal de la aplicacin del proyecto.
4.1.
Arquitectura del sistema Higgs
Se muestran a continuacin las caractersticas, desde el punto de vista de la arquitectura, del robot con el que se trabaja, Higgs. La arquitectura de este robot ya fue mencionada a grandes rasgos en la seccin 1.3.1 de este documento. En ella se describen algunos de los componentes del robot y se detallan las caractersticas software y hardware del sistema robtico. En este apartado se pretende dar un visin global de la organizacin de los componentes embarcados en Higgs, as como las relaciones que existen entre ellos, cmo se comunican, en n, cmo es capaz el sistema de coordinar los eventos para que el robot funcione de manera correcta y acorde a las necesidades del usuario. En primer lugar se analiza el sistema desde el punto de vista de la organizacin de los componentes y las relaciones que guardan unos con otros. Para ello se muestra el diagrama de la gura 20. Este diagrama permite diferenciar entre los componentes que se encuentran embarcados en el Rover y los componentes que se encuentran fuera del chasis fsico de Higgs y que tambin forman parte del sistema. El diagrama de la gura 20 tambin permite diferenciar la tipologa de los componentes del robot. Esto es que, el sistema se construye con elementos hardware que implementan diferentes tipos de software para funcionar. Este hecho hace necesaria la gura 21 para comprender de qu tipo de componente se trata en cada caso.
34
I. M EMORIA l 4. ARQUITECTURA DE SISTEMA
Figura 19. Vista general de ujos de mensajes del sistema. Podemos comprobar que el sistema se distribuye en dos partes, una formada por los componentes que estn en el robot, y otra formada por sistemas remotos. Dentro del robot se observan componentes hardware tales como: la kinect, la brjula, una placa arduino, un lser, una placa de potencia, bateras, un ordenador porttil y la base Pioneer. Fuera del robot se encuentran: el mando wii de control del robot y un ordenador externo. Adems se encuentran componentes en desuso como los acelermetros, la mueca, la cmara o el mdulo GPS. Cabe mencionar que ste ltimo sufre algunos problemas debido a la escasa y mala seal que hay en el laboratorio, ya que ste se encuentra en una zona de poca cobertura de seal. Tambin se encuentra en desuso el mdulo de componentes de CORBA, que gracias a la placa arduino permita la comunicacin de los componentes tipo ROS con los CORBA. Estos componentes estn coloreados con borde de color rojo en el diagrama. Los componentes tipo ROS estn coloreados con borde azul. En cuanto al software, existen dos partes diferenciadas. Una, la del software que est a bordo del robot compuesta por los drivers necesarios para el funcionamiento de los componentes hardware. La segunda, la que se encuentra en los sistemas remotos de control.
35
Figura 20. Vista general del sistema robtico Higgs.

36
Figura 21. Histograma para la comprensin de la gura 20. La mayora de los drivers necesarios estn disponibles a travs de los paquetes que ROS incorpora en sus versiones. Esto permite el control del robot de una manera sencilla y sin tener que preocuparse de la programacin a bajo nivel de los componentes. Son muchas la facilidades que aporta ROS en este sentido y ayuda a la implementacin de componentes de forma rpida y dinmica. El software de control en la parte remota tambin implementa paquetes de conguracin realizados por el equipo de desarrollo de ASLab. Estos paquetes son necesarios para poner el sistema en marcha, de forma que se lanzan las conguraciones de los componentes a travs de archivos de conguracin con la extensin .launch. Es muy importante el componente ROS Navigation, que permite la autonoma de navegacin del robot, as como provee de informacin relacionada con la posicin del mismo. Para comprender mejor la funcin de este paquete se detallan algunos de sus componentes principales: amcl: Es un sistema de localizacin que utiliza mtodos probabilsticos para determinar la posicin del robot cuando se mueve en un plano 2D. Este sistema implementa un mtodo adaptado del mtodo de Monte Carlo con un ltro particular para estimar la posicin del robot en una mapa conocido. Vase la gura 22. Durante el proceso, amcl estima la posicin gracias a la informacin que proporciona la base del robot con respecto a las coordenadas globales del sistema. Tambin publica la posicin estimada del robot teniendo en cuenta las medidas de odometra que proporcionan el resto de sensores. move_base: Este es un paquete que tiene que ver con la ejecucin de tareas de movimiento. El paquete move_base realiza una planicacin de tareas globales y locales para conseguir el moviento deseado. Adems construye dos mapas de coste, uno para la planicacin global y otro para la local. Un mapa de coste es un mapa que contiene informacin con las distancias a los obstculos que hay
37
Figura 22. Localizacin a travs del paquete de ROS amcl. en el plano. Este mapa incluye una distancia de seguridad para salvaguardar de posibles colisiones con los objetos. Vase la gura 24. Se muestra en la gura 23 una visin general del nodo move_base y sus interacciones con otros componentes.
Figura 23. Intefaz provista por el nodo move_base para la comunicacin con el resto de componentes base_local_planner: Este paquete es importante por el hecho de proporcionar un controlador que maneja la base del robot en el plano. Utilizando el mapa, el paquete traza una posible trayectoria para llegar hasta el siguiente punto seleccionado. Es el encargado de mandar las velocidades necesarias al robot.
38
Figura 24. Mapa de coste del robot durante la simulacin.
Figura 25. Trayectorias de valor calculadas por el paquete base_local_planner.
39
4.2.
Arquitectura de Android
Para realizar un buen desarrollo de aplicaciones en Android es importante conocer cmo est estructurado el sistema operativo. A esto se le llama arquitectura, y en el caso de Android est formada por varias capas que facilitan el desarrollo y la creacin de aplicaciones. Adems, la distribucin de Android permite acceder a los niveles y capas ms bajas del sistema mediante el uso de libreras. Esto supone una ventaja para el desarrollador de forma que no tenga que programar las funciones de bajo nivel necesarias para que una aplicacin haga uso de los componentes hardware de los dispositivos. Cabe destacar que Android se desarrolla de forma abierta, ofreciendo a los desarrolladores la posibilidad de mejorar el sistema. Eso no pasa por ejemplo en plataformas como iOS o Windows Phone. El que se tenga acceso al cdigo fuente no signica que sea posible tener un dispositivo mvil siempre actualizado a la ltima versin de Android. Para soportar el hardware de cada fabricante, es necesario un cdigo que no es accesible al desarrollador, sino que es privado y cerrado de cada empresa.
Figura 26. Arquitectura de pila del sistema Android.
40
Para realizar estas funciones de bajo nivel, cada una de las capas utiliza elementos de la capa inferior. Por ello, a este tipo de arquitecturas se les conoce tambin como arquitecturas de pila. Para entender mejor lo descrito se muestra el diagrama de arquitectura del sistema Android tomada del sitio ocial de Android developers. Vase gura 26. Se explican en detalle cada una de las capas que componen la arquitectura de sistema Android, una arquitectura de pila: Kernel de Linux: El ncleo del sistema operativo Android est basado en el kernel de Linux versin 2.6. Es un un kernel de GNU/Linux con 12 millones de lneas de cdigo: 3 millones en XML, 2.8 en C, 2.1 millones en java y 1.75 millones en C++. Es un kernel similar al que incluye cualquier distribucin de Linux, por ejemplo Ubuntu. La nica diferencia consiste en que este kernel est adaptado a las caractersticas del hardware que utilizan los dispositivos mviles, que es donde se ejecuta Android.
Figura 27. Versiones del Kernel de Linux de Android El ncleo acta como una capa de abstraccin entre el hardware y el resto de las capas de la arquitectura. El desarrollador no accede directamente a esta capa, sino que debe utilizar las libreras disponibles en capas superiores. De esta forma se facilita el hecho de no tener que conocer las caractersticas concretas de cada dispositivo mvil. Por ejemplo, si se necesita hacer uso de la cmara, el sistema operativo se encarga de utilizar la cmara que incluya el dispositivo, independientemente del modelo, la marca o el fabricante de dicho dispositivo . Dentro del kernel existe un controlador o driver para cada elemento de hardware del dispositivo. Los controladores son los que permiten utilizar estos elementos directamente desde el software. El kernel tambin se encarga de gestionar:
41
Los diferentes recursos del dispositivo como la energa, la memoria, etc El sistema operativo en s. Esto son procesos, elementos de comunicacin, etc.
Figura 28. Kernel de Linux de Android
Libreras : La siguiente capa justo encima del kernel son las bibliotecas nativas de Android, son las llamadas libreras. Estas libreras estn escritas en C o C++ y compiladas para cada una de las arquitecturas hardware correspondientes a cada dispositivo. Normalmente las libreras estn hechas por los fabricantes, quienes tambin se encargan de instalarlas en los dispositivos antes de ponerlos a la venta. El objetivo de las libreras es proporcionar la funcionalidad que las aplicaciones necesitan para realizar tareas que se repiten con frecuencia. Esto evita tener que codicarlas cada vez que se necesiten y garantiza que las tareas se lleven a cabo de la forma "ms eciente"posible. Entre las libreras ms comunes se encuentran: OpenGL, que es la que facilita todo lo relacionado con el motor grco, bibliotecas multimedia, para formatos de audio, imagen y video.Tambin est Webkit que es un navegador, SSL que permite el cifrado en las comunicaciones, FreeType para las fuentes de texto, y SQLite que se encarga de las bases de datos, entre otras.
Figura 29. Libreras del sistema operativo Android Entorno de ejecucin: Como se aprecia en el diagrama de la gura 26, el entorno de ejecucin de Android no se considera una capa en s, esto es por que tambin
42
est formada por libreras. Aqu se encuentran las libreras con la funcionalidades habituales de Java, as como otras especcas de Android. El componente principal del entorno de ejecucin de Android es la mquina virtual Dalvik. Como ya se coment en la seccin 2.1.3 de este documento, las aplicaciones Android se codican en Java y son compiladas en un formato especco para que la mquina virtual pueda ejecutarlas. La ventaja de esto es que las aplicaciones se compilan una nica vez y de esta forma estarn listas para distribuirse con la total garanta de que podrn ejecutarse en cualquier dispositivo Android que disponga de la versin mnima del sistema operativo que requiera la aplicacin.
Figura 30. Entorno de ejecucin del sistema operativo Android Es necesario aclarar que Dalvik es una variacin de la mquina virtual de Java, por lo que no es compatible con el bytecode Java (instrucciones ejecutables independientes de la arquitectura hardware) que ejecutan las mquinas virtuales Java normales. Java se utiliza nicamente como lenguaje de programacin, y los ejecutables que se generan con el SDK de Android no son ejecutables Java convencionales. Como consecuencia, no se pueden ejecutar en mquinas virtuales Java convencionales. Durante el proceso de compilacin de los programas Java (archivos .java) s que se genera, de forma intermedia, el bytecode habitual (archivos .class). Pero esos archivos son convertidos al formato especco de Dalvik en el proceso nal (.dex, de Dalvik executable). Esto explica por ejemplo por qu no podemos correr aplicaciones Java en Android ni viceversa. Google hace esto por una cuestin de optimizacin. Los archivos .dex son mucho ms compactos que los .class equivalentes, hasta un 50 % menos de tamao. Esto permite ahorrar espacio en el dispositivo, que suele ser escaso, y acelerar el proceso de carga. Adems, a diferencia de las mquinas virtuales tradicionales, Dalvik se basa en registros en lugar de una pila para almacenar los datos, lo que requiere menos instrucciones. Esto permite ejecuciones ms rpidas en un entorno con menos recursos.
43
Las aplicaciones Android se ejecutan cada una en su propia instancia de la mquina virtual Dalvik, evitando as interferencias entre ellas, y tienen acceso a todas las bibliotecas mencionadas y, a travs de ellas, al hardware y al resto de recursos gestionados por el kernel. Framework de aplicaciones: La siguiente capa est formada por las clases y servicios que utilizan directamente las aplicaciones para realizar sus funciones. La mayora de los componentes de esta capa son libreras Java que acceden a los recursos de las capas anteriores a travs de la mquina virtual Dalvik.
Figura 31. Framework de aplicaciones del sistema operativo Android Siguiendo el diagrama de la gura 31 se encuentran los siguientes elementos: 1. Activity Manager: Se encarga de administrar la pila de actividades de la aplicacin, as como su ciclo de vida. 2. Windows Manager: Se encarga de organizar lo que se visualiza por pantalla. Bsicamente crea las supercies en la pantalla que posteriormente pasarn a ser ocupadas por las actividades. 3. Content Provider: Esta es una librera muy interesante, porque crea una capa que encapsula los datos que se compartirn entre aplicaciones para tener control sobre cmo se accede a la informacin. 4. Views: Son los elementos que permiten construir las interfaces de usuario: botones, cuadros de texto, listas y elementos ms avanzados como pueden ser navegadores web o visores como el de Google Maps. 5. Notication Manager: Engloba los servicios que sirven para noticar al usuario que algo requiere de su atencin mostrando alertas en la barra de estado. Un dato importante es que esta biblioteca tambin permite jugar con sonidos, activar el vibrador, incluso utilizar los LEDs de los dispositivos, si es que los tuvieran. 6. Package Manager: Esta biblioteca permite obtener informacin sobre los paquetes que estn instalados en el dispositivo, adems se encarga de gestionar la instalacin de nuevos paquetes.
44
Un paquete consiste en la forma en que se distribuyen las aplicaciones Android. Los paquetes contienen un archivo .apk, que a su vez incluye los archivos .dex con todos los recursos y archivos adicionales que necesita la aplicacin para su descarga e instalacin. 7. Telephony Manager: Con esta librera se pueden realizar llamadas o enviar y recibir SMS/MMS, aunque no permite reemplazar o eliminar la actividad que se muestra cuando una llamada est en curso. 8. Resource Manager: Con esta librera podremos gestionar todos los elementos que forman parte de la aplicacin y que estn fuera del cdigo, es decir, cadenas de texto traducidas a diferentes idiomas, imgenes, sonidos o layouts. 9. Location Manager: Permite determinar la posicin geogrca del dispositivo Android mediante GPS o redes disponibles, tambin permite trabajar con mapas. 10. Sensor Manager: Permite manipular los elementos de hardware del dispositivo como el acelermetro, girscopo, sensor de luminosidad, sensor de campo magntico, brjula, sensor de presin, sensor de proximidad, sensor de temperatura, etc. 11. Cmara: Con esta librera se puede hacer uso de las cmaras del dispositivo para tomar fotografas o para grabar vdeo, siempre y cuando el dispositivo cuente con alguna de ellas, claro. 12. Multimedia: Permite reproducir y visualizar audio, vdeo e imgenes en el dispositivo.
Figura 32. Multimedia en sistema operativo Android
45
Aplicaciones: En la ltima capa se incluyen todas las aplicaciones del dispositivo, tanto las que tienen interfaz de usuario como las que no, las nativas, que estn programadas en C o C++, y las administradas, programadas en Java, las que vienen preinstaladas en el dispositivo y aquellas que el usuario ha instalado. En esta capa encontramos tambin la aplicacin principal del sistema: Inicio o Home, que es la que permite ejecutar otras aplicaciones gracias a una lista. Tambin permite mostrar diferentes escritorios donde se pueden colocar accesos directos a aplicaciones o incluso widgets, que son tambin aplicaciones de esta capa.
Figura 33. Aplicaciones del sistema operativo Android Finalmente, lo ms importante de todo es darse cuenta de que todas las aplicaciones, ya sean las nativas de Android, las que proporciona Google, las que incluye el fabricante o las que instala despus el usuario, utilizan el mismo marco de aplicacin para acceder a los recursos del sistema operativo. Android proporciona un entorno y arquitectura lo sucientemente potentes para la programacin y el desarrollo de todo tipo de aplicaciones. Esto implica verdaderamente dos cosas, una es que podemos crear aplicaciones que usen los mismos recursos que utilizan las aplicaciones nativas de Android. Esto signica que nada est reservado o resulta inaccesible para el usuario o programador. Lo segundo, es que podemos reemplazar cualquiera de las aplicaciones del dispositivo por cualquier otra de caractersticas similares, incluso reprogramadas por uno mismo. Este es el verdadero potencial de Android y lo que lo diferencia de su competencia, el control total, por parte del usuario, del software que se ejecuta en el dispositivo.
4.3.
Arquitectura de ROS
ROS es un meta-sistema operativo de cdigo abierto para el manejo de robots. Con meta-sistema operativo me reero al conjunto de conocimientos, actividades, tecnologa y ciencia que envuelven el campo de la investigacin de la robtica. ROS provee aquellos servicios que son necesarios para trabajar con un sistema operativo, incluyendo la capacidad de abstraccin de hardware, la programacin a bajo nivel de los dispositivos, la implementacin de funciones bsicas y frecuentes, el paso de mensajes entre los procesos que corren en el equipo, y la gestin de paquetes.
46
Adems se icluyen las herramientas y libreras necesarias para la programacin de cdigo, su compilacin y nalmente su ejecucin en los dispositivos. Todo esto bajo un framework sosticado ofrecido por ROS. Para comprender bien la arquitectura de un sistema ROS es mejor observar el siguiente ejemplo. El sistema que se presenta trata de implementar un sistema de control en lazo cerrado para una masa que cuelga de un cable, de forma que se controlar la trayectoria que seguir la masa en suspensin. Se utiliza para el control una kinect. Son necesarios exactamente seis nodos para este sistema: Serial Node (C++): Consiste en el nodo de comunicacin con el robot a travs del puerto serie. Estimator Node (C++): Es el encargado de recoger la informacin sobre la masa colgante. Utiliza la posicin del robot gracias a los encoders que proporcionan informacin de la odometra del robot. Es el encargado de calcular la longitud del cable en cada instante y la velocidad del robot necesarias. Control Node (Python): Utiliza estados del robot para calcular adecuadamente las entradas en el siguiente instante de tiempo. Object Tracker Node (C++): Posiciona la masa colgante gracias a la nube de puntos que se genera por el nodo de la cmara. Marker Node (C++): Genera la visin 3D que precisa el robot y la masa y las dibuja con la orientacin y posicin correctas en el entorno grco de simulacin de ROS, el software rviz. Keyboard Node (C++): Es el encargado de adquirir la informacin de entrada a travs de teclado y modica el estado de operacin del sistema en funcin del comando tecleado. Puppeteer Messages (NA): Es una coleccin con toda la informacin de los mensajes publicados en los tpicos y los servicios utilizados en el sistema. Adems se utilizan otros dos nodos ms para el control de la masa colgante: Kinect Nodes: En realidad el software de la kinect es irrelevante para el ejemplo que se presenta. Proporciona la cmara para el control de la imagen y la profundidad para el control de la trayectoria. rviz: Como se ha mencionado antes, se utiliza un nodo que permite la visualizacin del sistema en un entorno software de simulacin. Es muy til para trabajar con informacin visual en 3D.
47
Figura 34. Control de la trayectoria de una masa suspendida de un cable mediante ROS.
Figura 35. Arquitectura ROS del sistema de control de una masa suspendida.
48
Se muestra en la imagen de la gura 35 el diagrama de ujo de informacin entre los nodos descritos anteriormente. El proceso de funcionamiento es el siguiente: La kinect inicia la cmara, sta recoge la imagen del objeto que a su vez inicia el estimador de posicin, seguidamente se lanza el control y ste enva nuevos comandos de actuacin al robot. Este proceso se repite continuamente para el control de la trayectoria de la masa colgante. Cabe destacar que la trayectoria de la que estamos hablando, es una trayectoria 3D, de forma que el control de la misma se realizar acortando o alargando la longitud del cable de suspensin. Tambin se vara la posicin del robot que se encuentra posicionado en el techo. De esta forma se presenta un ejemplo para la comprensin de la arquitectura de un sistema ROS. Es una arquitectura basada en la implementacin de nodos, de forma que se delegan las funciones y servicios a cada uno de los nodos. Es una arquitectura basada en la distribucin de componentes de forma organizada y transparente.
49
Captulo 5 ARI: Android Robot Interface

5.1. Creacin del proyecto Android
Para comenzar con la programacin de aplicaciones Android es necesario conocer y comprender cules son los elementos bsicos con los que cuenta el sistema, as como sus caractersticas y propiedades. Se hace imprescindible abordar este tema desde el punto de vista del diseo, comprendiendo las propiedades grcas de los distintos elementos, y tambin desde el punto de vista del desarrollo orientado a la correcta gestin de recursos que el sistema ofrece. An as se comentarn aquellos recursos del sistema Android que se consederan ms importantes, ya que existen multitud de ellos y se han ido actualizando con cada versin de Android. Muchos de los componentes que se exponen han sido utilizados en el desarrollo de ARI (Android Robot Interface), la aplicacin desarrollada en este proyecto. Antes de empezar con la creacin de aplicaciones en Android es necesario tener instalado el entorno de desarrollo. Se necesita: Descargar el entorno de programacin, Android SDK. Instalar el plugin ADT para Eclipse, si se va a utilizar Eclipse. Descargar las herramientas del SDK gracias al SDK Manager. Una vez completados los pasos anteriores se podrn crear aplicaciones Android gracias al entorno de desarrollo Android SDK. En primer lugar hay que crear un proyecto Android. Este proyecto contiene todos los archivos necesarios para comprender el cdigo fuente de una aplicacin Android. El entorno de desarrollo descargado (Android SDK) permite crear un proyecto Android de manera sencilla, incluyendo en el directorio del proyecto aquellos archivos de
50
I. M EMORIA l 5. ARI: A NDROID ROBOT I NTERFACE
conguracin necesarios para que la aplicacin funcione correctamente. Para ello se enumeran los siguientes pasos: 1. En Eclipse, hacemos click en New Android App Project. Si no se muestra esta opcin signica que no se ha instalado el plugin ADT. 2. Se rellenan los campos de texto y se completa la informacin requerida que se muestra en la gura 36. a) Application Name: Es el nombre de la aplicacin que se mostrar a los usuarios. b) Project Name: Es el nombre del directorio de proyecto y el que mostrar Eclipse. c) Package Name: Es el nombre del paquete de la aplicacin al igual que en la programacin Java. El nombre del paquete debe ser nico y debe permitir diferenciar a cada uno de los paquetes, tanto en el entorno de desarrollo Eclipse como en el sistema Android. Por esta razn es conveniente nombrar al paquete empezando por el nombre de dominio de la organizacin a la que pertenece el paquete de manera inversa. Por ejemplo en la gura 36 se observa el nombre del paquete: org.aslab.tablet_application". d) Build SDK: Es la versin de la plataforma en la que vamos a compilar la aplicacin. En este caso es la plataforma Android 4.0.3 (API 15)", aunque tambin se puede compilar la aplicacin para versiones anteriores teniendo siempre cuidado de utilizar elementos que sean soportados por las versiones que vamos a utilizar, de lo contrario el proyecto avisar de algn error. En este caso se escoge la plataforma acorde a la versin de Android que est corriendo en tablet Asus Transformer Prime que utilizamos en ASLab. e) Minimum Required SDK: Es la mnima versin que la aplicacin soportar. Es aconsejable cuantas ms versiones mejor, de forma que se puede escoger una versin baja para hacer que la aplicacin sea portable y compatible con el mayor nmero de dispositivos posible. 3. Las siguientes ventanas de dilogo que se muestran, permiten crear un icono personalizado de la aplicacin. 4. A continuacin se puede seleccionar una actividad para comenzar a desarrollar la aplicacin. Finalmente se dispondr de una aplicacin congurada correctamente para desarrollar la aplicacin deseada.
51
Figura 36. Creacin de un proyecto Android en Eclipse.
5.2.
Diseo grco
Es necesario saber que Android utiliza un sistema jerrquico para la construccin de interfaces grcas de usuario. Esta jerarqua se compone de vistas y grupos de vistas como muestra la gura 37. Los objetos tipo vista son objetos que se utilizan con bastante normalidad como botones, textelds, etc, se hablar de estos objetos ms adelante. Android ofrece adems cdigo XML para la edicin de la interfaz y los elementos grcos, de forma que se pueden disear estos elementos a travs de cdigo XML, implementando la jerarqua antes mencionada. Esto es gracias al archivo AndroidManifest.xml que se crea, como comentamos en el apartado anterior, cuando se crea un proyecto por primera vez. Toda aplicacin debe contener un archivo AndroidManifest.xml en el directorio raz del proyecto. Este archivo describe informacin esencial de la aplicacin para el sistema Android en el que corre, adems el archivo AndroidManifest.xml sirve tambin para: Declarar el paquete Java de la aplicacin, que sirve como identicador nico de la aplicacin.
52
Figura 37. Jerarqua de vistas de la interfaz de usuario Android. Declara los componentes de la aplicacin: las actividades, los servicios, etc. Estos componentes se describen ms adelante. Esta declaracin permite al sistema Android saber qu componentes debe implementar y bajo qu condiciones. Determina qu procesos ejecutarn los componentes de la aplicacin. Declara los permisos de la aplicacin a la hora de interactuar con otras que requieran acceso a partes protegidas del API. Declara los permisos que otros deben tener para poder interactuar con los componentes de la aplicacin. Provee informacin de las clases de instrumentacin que le dan un perl concreto e informacin de la aplicacin cuando sta est corriendo. Declara la versin mnima del API de Android que la aplicacin necesita para funcionar correctamente. Lista las libreras que la aplicacin necesita. El entorno de desarrollo del sistema Android (SDK) ya provee del framework necesario para el desarrollo de aplicaciones. Es importante conocer algunos aspectos relevantes a la hora de construir aplicaciones, por ejemplo dotarlas de una visin global del sistema, esto es contar con una vista principal que adquiera el papel de Home de la aplicacin, aadir vistas y marcos que produzcan sensacin de navegabilidad, incluir noticaciones al usuario, cuadros de dilogo, etc. Es importante mantener estos principios para guardar una experiencia comn entre los sistemas Android y hacerlos intuitivos. En cuanto a la apariencia de los sistemas Android, se utilizan los llamados Temas, que son mecanismos de Android para conseguir
53
Figura 38. Ejemplo de cdigo XML de la interfaz grca de Android un estilo slido y vistoso de las aplicaciones de cara al usuario. El estilo elegido por el diseador especica las propiedades visuales de los elementos que componen la aplicacin. Propiedades como el color, el tamao, el relleno o los fondos pueden cambiar en funcin del estilo escogido por el diseador de la aplicacin. Para que exista similitud y cohesin entre las aplicaciones en los diferentes dispositivos, Android ofrece tres tipos de temas: Holo Light Holo Dark Holo Light with dark action bars
54
Figura 39. Diferentes temas de Android.
5.2.1.
Componentes grcos en ARI
Se mencionan a continuacin algunos de los aspectos ms importantes para conseguir esa experiencia de la que se habla: Barra de sistema: Consisten en las diferentes zonas de la pantalla que permiten visualizar la informacin, las noticaciones, el estado del dispositivo, etc. Normalmente los System Bars se muestran continuamente mientras se ejecuta una aplicacin, aunque aquellas aplicaciones que muestran imgenes, vdeos u otros contenidos, pueden ocultar de forma temporal los System Bars para tener una experiencia total de pantalla completa. Noticaciones: Las noticaciones, como su propio nombre indica, son mensajes breves que sirven para informar al usuario acerca de situaciones del sistema o simplemente como informacin aclarativa. Normalmente se utilizan para recordar eventos, informar de actualizaciones, en n, informacin relevante para el usuario pero no lo sucientemente crtica como para interrrumpir continuamente al usuario. Tambin pueden utilizarse para explicar con detalle situaciones relevantes como cuando se colapsa el sistema. Se aconseja que no ocupen ms de un par de lneas. Si se arrastra la noticacin a la izquierda o a la derecha sta desaparece de la pantalla.
55
Figura 40. Barra de sistema de ARI.
Figura 41. Noticaciones en Android. Barra de acciones: Este componente est dedicado a mostrar el estado real de la aplicacin y se encuentra en la parte superior de la pantalla mientras se ejecuta la aplicacin. Ofrece varias funciones: Da un acceso rpido a aquellas acciones importantes que deben estar siempre a mano del usuario. Por ejemplo realizar una bsqueda. Permite la navegacin dentro de una aplicacin entre vistas internas, incluso permitiendo cambiar entre aplicaciones. Organiza las opciones ofrecidas, ocultando aquellas menos solicitadas. Permite personalizar las aplicaciones ofreciendo un espacio dedicado a ello. La barra de acciones es uno de los elementos ms importantes en el diseo de aplicaciones, sobretodo si se es novato.
56
Figura 42. Ejemplo de barra de acciones. Conforme a la gura 42 se explican los nmeros indicados: 1. Icono de la aplicacin 2. Control de vistas: permite cambiar de vistas para mostrar informacin diferente segn se requiera. Por ejemplo opciones de men, entre otras. 3. Botones: Normalmente ejecutan las acciones ms importantes de la aplicacin. Las acciones que no caben en la barra de acciones se incluyen en el stack de acciones que se detalla a continuacin. 4. Stack de acciones: Contiene las acciones menos utilizadas y las hace visibles al pulsar sobre su icono.
La aplicacin ARI incluye una barra de acciones que ofrece varias posibilidades para el control de robots. La barra est compuesta por el icono de la aplicacin y tres botones que aportan las funciones de aadir un nuevo robot, realizar operaciones con un robot concreto, e iniciar sesin en un cliente remoto SSH. Vase la gura 43.
Figura 43. Barra de acciones de ARI.
57
Listas: Las listas permiten al usuario ver la informacin de forma organizada. La informacin se muestra en lneas verticales apiladas unas encima de otras. Normalmente se utilizan para mostrar informacin seleccionable, de forma que se ejecute una accin al ser un elemento de la lista pulsado. En ARI se utilizan listas para visualizar la informacin del sistema ROS. Cuando el usuario quiere ver la informacin de los nodos ROS debe pulsar la opcin de visualizar los datos del sistema. En ese caso aparecen en pantalla listas con la informacin correspondiente a cada uno de los nodos. Vase la gura 44.
Figura 44. Lista de informacin ROS en ARI. Scroller: Es un elemento desplazador. Este componente permite navegar la informacin que se visualiza con un gesto de deslizamiento del dedo sobre la pantalla. La velocidad de desplazamiento de la informacin es proporcional a la velocidad con que se mueve el dedo sobre la supercie tctil de la pantalla. En ARI se utilizan desplazadores junto con las listas de informacin de manera que cuando una lista contiene ms informacin de la que la lista permite mostrar por pantalla, los desplazadores permiten arrastrar las listas hacia arriba y hacia abajo. Gracias a los desplazadores es posible observar toda la informacin que una lista contiene, de lo contrario slo se observara aquella informacin que cabe dentro del espacio visual reservado para la lista. Vanse las guras 44 y 45. Spinner: Es un elemento que permite seleccionar de forma rpida un valor de una lista de contenido. El valor que muestra el spinner por defecto es el indicado al
58
Figura 45. Scroller en el sistema Android. seleccionar un elemento de la lista. Al tocar el icono de un spinner se muestra en pantalla un men de contenido con todas la opciones disponibles, de las cuales el usuario podr seleccionar una. Los spinners son tiles para seleccionar opciones disponibles que el usuario puede escoger. Se integran muy bien con el resto de componentes, ya que se minimizan bien y no ocupan apenas espacio si la aplicacin incorpora muchos otros elementos.
Figura 46. Spinner de opciones de ARI.
59
En ARI se utilizan spinners en el men de opciones de la barra de acciones. Se utilizan principalmente para englobar las opciones que el usuario puede ejecutar para interactuar con el robot. Los spinners permiten mantener ocultas las opciones mientras la aplicacin est en uso. Si el usuario desea cambiar de opcin el spinner se despliega y muestra su contenido en forma de lista. Vase la gura 46. Botones: Los botones son elementos fcilmente reconocibles, ya que la mayora de las aplicaciones grcas implementan estos componentes. Normalmente incluyen un texto o una imagen relacionados con la accin que llevan a cabo al ser pulsados. En Android existen dos tipos de botones, los que incluyen borde y los que no, pero los ambos modelos contienen texto o una imagen.
Figura 47. Botones en el sistema Android. Casillas de texto: En ingls denominadas TextFields. Son elementos que permiten al usuario introducir texto en las aplicaciones. Existen casillas de texto de una nica lnea y tambin multi-lnea. Cuando se pulsa encima de una casilla de texto se muestra el cursor y automticamente aparece el teclado en la pantalla. Adems son elementos que permiten la edicin de texto como seleccionar, copiar, cortar, pegar, incluso auto-completar la informacin. En ARI se utilizan las casillas de texto para obtener informacin importante que necesita la aplicacin. Por ejemplo cuando se inicia el cliente SSH, se requiere informacin como el nombre de usuario, el puerto al que conectarse, la direccin IP de la mquina remota y el nick con el que nos registraremos en la aplicacin. Para todo ello se utilizan casillas de texto que permiten capturar la informacin y almacenarla para la gestin interna por parte de la aplicacin. Vase la gura 48. Cuadros de dilogo: Los cuadros de dilogo, como su propio nombre indica, son eventos que interactan con el usuario, preguntando sobre decisiones o pidiendo
60
Figura 48. Casillas de texto de ARI para captar informacin necesaria. por pantalla informacin adicional que la aplicacin necesita para continuar con su tarea. Normalmente son eventos de conrmacin, sencillas respuestas como Cancel/OK. Aunque puede ser que haya dilogos que requieran de ms informacin y resulten algo ms complejos de contestar, como seleccin de caractaersticas, etc.
Figura 49. Cuadros de dilogo en Android Tambin se considera como dilogo un elemento denominado Toast. Este componente es un recuadro pequeo e iluminado, para llamar la atencin del usuario, que se utiliza para dar un feedback sobre la operacin seleccionada. Por ejemplo cuando cuando se sale de la aplicacin de mail antes de enviar un correo que se estaba escribiendo, el sistema muestra un toast diciendo: Mensaje
61
guardado", para que el usuario sepa que podr continuar con su edicin ms tarde. Los toasts tienen la caracterstica de desaparecer por s solos pasados un tiempo que puede establecerse. En la aplicacin ARI se muestran toasts cada vez que se selecciona una opcin de un spinner, de forma que el usuario queda informado de la seleccin escogida. Conrmacin: En algunas situaciones, cuando el usuario pulsa sobre una accin, es conveniente informar de lo que est punto de suceder. Esta prctica puede ayudar al usuario para prestar atencin antes de realizar acciones indeseadas. Pero no todas las acciones deben implementar una conrmacin, para ello se propone el diagrama de la gura 51.
Figura 50. Aviso de conrmacin Android.
62
Figura 51. Diagrama para la utilizacin de avisos de conrmacin.

63
5.3.
Desarrollo software
La aplicacin ARI utiliza clases Java especcas de Android. Segn la programacin orientada a objetos podemos identicar a cada una de estas clases como un objeto de Android. Existen algunos componentes u objetos en Android que han sido desarrollados por Google, de forma que si se utilizan dichos componentes de manera apropiada, se pueden crear aplicaciones en Android.
Figura 52. Versiones del sistema operativo Android. Algunos de los componentes ms destacados y utilizados en la aplicacin son: Actividad: Una actividad es un componente Android que ofrece una apariencia en la pantalla con la que los usuarios pueden interactuar para hacer algo. Una aplicacin normalmente consiste en mltiples actividades que se dan paso unas tras otras. Es necesario, si existen varias actividades en la aplicacin, especicar cul de ellas es la principal". Esta actividad ser la primera que se muestre al usuario al iniciar la aplicacin por primera vez. Cada actividad puede por lo tanto, iniciar otras actividades para permitir la ejecucin de acciones en la aplicacin. Cada vez que una actividad empieza, la anterior se para, pero el sistema guarda la actividad cesada en un stack de actividades. Cuando se inicia una actividad, se incorpora al stack y se visualiza la interfaz que le corresponde.
64
El stack de actividades es un stack LIFO (last in, rst out), de manera que cuando el usuario est manejando una actividad y pulsa el icono de volver atrs, la actividad actual se elimina del stack y la anterior se muestra en la pantalla. Cuando una actividad se para porque una nueva se ha iniciado, se notica al sistema gracias a los mtodos que se implementan durante el ciclo de vida de la actividad. Estos mtodos pueden ser la creacin de la actividad, la parada, el retomarla o destruirla, en cada una de estas llamadas se ofrece la oportunidad al desarrollador de implementar cdigo para gestionar de manera adecuada la aplicacin. Es aconsejable que cuando una actividad se para, se eliminen aquellos objetos que ocupen gran cantidad de recursos en el sistema, como son las conexiones en red con otros dispositivos, o bases de datos, etc. Cuando la actividad vuelve al frente se pueden recuperar aquellos componentes que se pausaron y los servicios que quedaron a medias de ser ejecutados. Todo esto se contempla en la gura 55. Cuando se crea una actividad nueva en la aplicacin es necesario declararla en el archivo AndroidManifest.xml. Esta declaracin sirve para informar a la aplicacin de las actividades que maneja, tambin para que sea accesible para el sistema, incluso se pueden denir aspectos de diseo de la actividad como el Tema que implementa, el icono de la actividad, etc. En el archivo manifest se pueden declarar permisos de acceso o ltros, necesarios para denir la forma en que otras actividades harn uso de los recursos del resto de actividades. Para desarrollar la aplicacin ARI se han utilizado dos actividades, una principal que sirve de inicio de la aplicacin y otra que corresponde con la actividad bsica de manejo y control de un robot. La aplicacin se inicia con la primera de ellas, la segunda se hace visible cuando el usuario decide aadir un robot para controlarlo. El cdigo de las actividades se incluye en la parte III de este proyecto. El archivo de la acitividad principal se llama MainActivity y el del control de robots RosActivityRobot. En las guras 53 y 54 se muestran las interfaces grcas asociadas a cada una de las actividades. Como puede comprobarse, la actividad del robot contiene dos espacios de color negro en su interior, estos espacios se denominan fragmentos, y son otro tipo de componentes Android desarrollados por Google que se explican a continuacin.
65
Figura 53. Interfaz visual de la actividad principal de ARI.
Figura 54. Interfaz visual de la actividad de control del robot de ARI.
66
Figura 55. Diagrama de secuencia del ciclo de vida de una Actividad Android.
67
Figura 56. Implementacin de los mtodos del ciclo de vida de una actividad Android.
68
Fragmento: Un Fragmento es un elemento que representa el comportamiento de una porcin de la interfaz de usuario dentro de una actividad. Se pueden combinar varios fragmentos en una actividad para construir aplicaciones multipanel, de forma que cada uno de estos fragmentos incluya su lgica de cdigo por separado. Adems, un fragmento se puede reutilizar en todas la actividades que el programador desee. Se puede pensar en un fragmento como un mdulo insertado en una actividad, que adems posee su propio ciclo de vida, que se muestra en la gura 60, y recibe sus propios eventos de entrada. La ventaja de los fragmentos es que pueden ser eliminados mientras la actividad que los recoje est funcionando. Hay que tener la sensacin de que un fragmento es una especie de sub-actividad que se puede utilizar en mltiples actividades. En la gura 59 se muestra el cdigo Java de los mtodos que un Fragmento Android implementa por el hecho de ser un Fragmento. En concreto esta parte de cdigo pertenece al fragmento desarrollado en ARI para el control por teleoperacin de un robot. El fragmento incluye un Joystick y una capa de visualizcin que permite mostrar en la pantalla mapas. Gracias al Joystick es posible comandar el robot con el paso de mensajes de tipo velocidad, que el sistema ROS se encarga de gestionar adecuadamente. El cdigo de los fragmentos desarrollados para la aplicacin ARI se incluye en la parte III de este proyecto, en concreto se han desarrollado tres fragmentos: TeleopFragment: Es el fragmento que permite la tele-operacin del robot gracias al Joystick virtual y la visualizacin del mapa que sirve uno de los nodos ROS. NodeListFragment: Es el fragmento que corresponde con el listado de los nodos activos en el sistema ROS. En concreto este es un tipo de fragmento que permite el listado de elementos de forma sencilla, la clase es ListFragment y hereda directamente de la clase Fragment que es el fragmento en s. NodeInfoFragment: Es el fragmento que permite visualizar en pantalla la informacin de un nodo ROS en concreto, esto es visualizar los tpicos a los que el nodo est suscrito, los tpicos que publica, los parmetros que utiliza, etc. En la gura 57 se muestra el modo de funcionamiento que implementan los fragmentos de ARI. Para ver la informacin de uno de los nodos ROS es necesario pulsar sobre l dentro del fragmento del listado de nodos, de forma que aparece
69
Figura 57. Diseo del funcionamiento de fragmentos en ARI.
Figura 58. Fragmentos NodeListFragment y NodeInfoFragment de ARI.
70
en la porcin reservada para el fragmento de informacin NodeInfoFragment. Vase tambin la imagen de la gura 58 donde se muestra la informacin del nodo seleccionado /stageros, que es el nodo del simulador de robots en el PC.
Figura 59. Mtodos que implementa el Fragmento TeleopFragment de ARI. Es imprescindible que un fragmento est insertado en una actividad, de hecho su ciclo de vida le afecta directamente. Por ejemplo cuando una actividad se pausa, se pausan a su vez todos los fragmentos que se encuentren anidados dentro de ella. Cuando una actividad se destruye, se destruyen tambin todos los fragments que contenga. Sin embargo, cuando una actividad est corriendo, se puede manipular cada fragment de forma independiente, creando fragmentos nuevos o suprimiendo los ya existentes. Existen tambin las transiciones entre fragmentos, esto consiste en hacer visibles o no los fragmentos, de forma que se activa su ciclo de vida. Las transiciones de
71
los fragmentos estn controladas por la propia actividad que los acoge, y pueden ser aadidos al stack de actividades. De esta forma cuando un fragmento se aade al stack, la actividad es noticada de este evento para facilitar la posterior reinsercin del fragmento en la actividad y recuperar los procesos que estaban corriendo. Cuando el fragmento es insertado en el layout de una actividad se incorpora a la jerarqua de vistas de la que se habl con anterioridad. Es importante aclarar que el fragmento posee su propio layout dentro de la actividad. Tambin es posible que un fragmento sea invisible, esto es que el fragmento se crea como un proceso dentro de la actividad y no posee apariencia fsica dentro del layout de la actividad. Se muestra en la gura 60 el ciclo de vida de un fragmento en Android.
72
Figura 60. Diagrama de secuencia del ciclo de vida de un Fragment Android.

73
Servicios: Un servicio es un componente de la aplicacin que permite ejecutar operaciones de larga duracin sin ningn tipo de interfaz visual. Una aplicacin puede lanzar un servicio de forma que ste se mantiene vivo aunque el usuario cambie de aplicacin en el dispositivo. Adems otro componente puede contactar con un servicio para interactuar con l y comenzar un proceso de intercomunicacin (IPC). Por ejemplo, en la aplicacin ARI se utilizan servicios para intercomunicar los nodos ROS del sistema con el resto de nodos que se encuentran fuera del tablet. Un servicio puede lanzarse de dos formas: 1. Started: Un servicio se lanza en modo Started cuando un componente de la aplicacin invoca al mtodo startService(). Una vez lanzado, el servicio puede continuar vivo por detrs de la aplicacin de forma indenida, incluso cuando el componente que lo lanz es eliminado. Normalmente, un servicio en modo Started realiza una operacin sin devolver ningn valor al elemento que lo lanz. Cuando el servicio termina de hacer sus operaciones se para por l mismo. 2. Bound: Un servicio se lanza en modo Bound cuando un componente de la aplicacin invoca al mtodo bindService(). Un servicio de este tipo ofrece una interfaz cliente-servidor que permite a los componentes interactuar con el servicio. La diferencia consiste en que ste tipo de servicios slo corren cuando existe alguna conexin con otro elemento que requiere de sus operaciones. De esta forma pueden conectarse a un servicio muchos componentes pero cuando todos se hayan desconectado, el servicio ser eliminado. En la gura 61 se pueden observar los ciclos de vida por separado de cada uno de estos modos de lanzamiento de un servicio. En la aplicacin ARI se utilizan servicios para implementar la conexin de los nodos del sistema ROS. Existe una clase llamada NodeMainExecutorService que es la encargada de realizar la conexin con el nodo principal del sistema ROS. El servicio se lanza en modo Started, y el cdigo que lo implementa ha sido desarrollado por el equipo de ROS que ofrece una serie de clases Java denidas para el desarrollo de aplicaciones Android con el sistema de nodos ROS. Se incluye a continuacin el cdigo del servicio que permite a la aplicacin ARI mantener la conexin con el nodo principal de ROS en un PC externo.
74
Figura 61. Diagrama de secuencia del ciclo de vida de ambos modos de un Servicio Android.
75
NodeMainExecutorService.java:
/* * Copyright (C) 2011 Google Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); you may not * use this file except in compliance with the License. You may obtain a copy of * the License at * * * * * * * http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under * the License. */ package org.ros.android; import com.google.common.base.Preconditions; import import import import import import import import import import import import import import import import import import import import import android.app.Notification; android.app.PendingIntent; android.app.Service; android.content.Intent; android.net.wifi.WifiManager; android.net.wifi.WifiManager.WifiLock; android.os.Binder; android.os.IBinder; android.os.PowerManager; android.os.PowerManager.WakeLock; android.util.Log; org.ros.RosCore; org.ros.android.android_gingerbread_mr1.R; org.ros.concurrent.ListenerGroup; org.ros.concurrent.SignalRunnable; org.ros.exception.RosRuntimeException; org.ros.node.DefaultNodeMainExecutor; org.ros.node.NodeConfiguration; org.ros.node.NodeListener; org.ros.node.NodeMain; org.ros.node.NodeMainExecutor;
import java.net.URI; import java.util.Collection; import java.util.concurrent.ScheduledExecutorService; /** * @author damonkohler@google.com (Damon Kohler) */ public class NodeMainExecutorService extends Service implements NodeMainExecutor { private static final String TAG = "NodeMainExecutorService"; // NOTE(damonkohler): If this is 0, the notification does not show up. private static final int ONGOING_NOTIFICATION = 1;
76
static final String ACTION_START = "org.ros.android.ACTION_START_NODE_RUNNER_SERVICE"; static final String ACTION_SHUTDOWN = "org.ros.android.ACTION_SHUTDOWN_NODE_RUNNER_SERVICE"; static final String EXTRA_NOTIFICATION_TITLE = "org.ros.android.EXTRA_NOTIFICATION_TITLE"; static final String EXTRA_NOTIFICATION_TICKER = "org.ros.android.EXTRA_NOTIFICATION_TICKER"; private final NodeMainExecutor nodeMainExecutor; private final IBinder binder; private final ListenerGroup<NodeMainExecutorServiceListener> listeners; private private private private WakeLock wakeLock; WifiLock wifiLock; RosCore rosCore; URI masterUri;
/** * Class for clients to access. Because we know this service always runs in * the same process as its clients, we dont need to deal with IPC. */ class LocalBinder extends Binder { NodeMainExecutorService getService() { return NodeMainExecutorService.this; } } public NodeMainExecutorService() { super(); nodeMainExecutor = DefaultNodeMainExecutor.newDefault(); binder = new LocalBinder(); listeners = new ListenerGroup<NodeMainExecutorServiceListener>( nodeMainExecutor.getScheduledExecutorService()); } @Override public void onCreate() { PowerManager powerManager = (PowerManager) getSystemService(POWER_SERVICE); wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, TAG); wakeLock.acquire(); int wifiLockType = WifiManager.WIFI_MODE_FULL; try { wifiLockType = WifiManager.class.getField("WIFI_MODE_FULL_HIGH_PERF").getInt(null); } catch (Exception e) { // We must be running on a pre-Honeycomb device. Log.w(TAG, "Unable to acquire high performance wifi lock."); } WifiManager wifiManager = (WifiManager) getSystemService(WIFI_SERVICE); wifiLock = wifiManager.createWifiLock(wifiLockType, TAG); wifiLock.acquire(); } @Override public void execute(NodeMain nodeMain, NodeConfiguration nodeConfiguration, Collection<NodeListener> nodeListeneners) {
77
nodeMainExecutor.execute(nodeMain, nodeConfiguration, nodeListeneners); } @Override public void execute(NodeMain nodeMain, NodeConfiguration nodeConfiguration) { execute(nodeMain, nodeConfiguration, null); } @Override public ScheduledExecutorService getScheduledExecutorService() { return nodeMainExecutor.getScheduledExecutorService(); } @Override public void shutdownNodeMain(NodeMain nodeMain) { nodeMainExecutor.shutdownNodeMain(nodeMain); } @Override public void shutdown() { signalOnShutdown(); // NOTE(damonkohler): This may be called multiple times. Shutting down a // NodeMainExecutor multiple times is safe. It simply calls shutdown on all // NodeMains. nodeMainExecutor.shutdown(); if (rosCore != null) { rosCore.shutdown(); } if (wakeLock.isHeld()) { wakeLock.release(); } if (wifiLock.isHeld()) { wifiLock.release(); } stopForeground(true); stopSelf(); } public void addListener(NodeMainExecutorServiceListener listener) { listeners.add(listener); } private void signalOnShutdown() { listeners.signal(new SignalRunnable<NodeMainExecutorServiceListener>() { @Override public void run(NodeMainExecutorServiceListener nodeMainExecutorServiceListener) { nodeMainExecutorServiceListener.onShutdown(NodeMainExecutorService.this); } }); } @Override public void onDestroy() { shutdown(); super.onDestroy(); } @Override
78
public int onStartCommand(Intent intent, int flags, int startId) { if (intent.getAction() == null) { return START_NOT_STICKY; } if (intent.getAction().equals(ACTION_START)) { Preconditions.checkArgument(intent.hasExtra(EXTRA_NOTIFICATION_TICKER)); Preconditions.checkArgument(intent.hasExtra(EXTRA_NOTIFICATION_TITLE)); Notification notification = new Notification(R.drawable.icon, intent.getStringExtra(EXTRA_NOTIFICATION_TICKER), System.currentTimeMillis()); Intent notificationIntent = new Intent(this, NodeMainExecutorService.class); notificationIntent.setAction(NodeMainExecutorService.ACTION_SHUTDOWN); PendingIntent pendingIntent = PendingIntent.getService(this, 0, notificationIntent, 0); notification.setLatestEventInfo(this, intent.getStringExtra(EXTRA_NOTIFICATION_TITLE), "Tap to shutdown.", pendingIntent); startForeground(ONGOING_NOTIFICATION, notification); } if (intent.getAction().equals(ACTION_SHUTDOWN)) { shutdown(); } return START_NOT_STICKY; } @Override public IBinder onBind(Intent intent) { return binder; } public URI getMasterUri() { return masterUri; } public void setMasterUri(URI uri) { masterUri = uri; } public void startMaster() { rosCore = RosCore.newPrivate(); rosCore.start(); try { rosCore.awaitStart(); } catch (Exception e) { throw new RosRuntimeException(e); } masterUri = rosCore.getUri(); } }
79
Captulo 6 RESULTADOS Y CONCLUSIONES

Tras la realizacin de este proyecto puedo decir que sta ha sido para m una experiencia nica. Adems ha sido muy graticante, ya que me ha permitido hacer realidad una idea que tena en la cabeza desde hace ya un ao. A nales del verano de 2011 empec a interesarme por la programacin de dispositivos mviles, en concreto por la programacin de aplicaciones para iPhone, que es mi telfono mvil. Al principio empec a programar pequeas aplicaciones, pero me invadi por completo una sensacin que no pude resistir. Esta sensacin era la posibilidad de recongurar mi terminal, crear yo mismo las instrucciones que se ejecutaran en el mvil y poder personalizar el dispositivo al mximo. Ahora me ro, vaya iluso. Por razones de poltica de empresa y, en n, todos conocen la poltica de Apple, existan muchos problemas para poder cargar en el terminal las aplicaciones que diseaba. Es por ello que empec a conocer la potencia de Android como sistema operativo pero sobre todo, y lo ms importante, el hecho de que es un sistema open source y permite crear aplicaciones y cargarlas en los dispositovos de forma rpida y sencilla. He de comentar que como usuario preero el sistema iOS por varias razones, entre ellas la tecnologa que utiliza, que permite una experiencia muy distinta a la de los dispositovs Android. An as creo que la facilidad que Android ofrece al usuario para el desarrollo de sus propias aplicaciones lo hacen, sinceramente, especial. El resultado del proyecto ha sido una interfaz grca desarrollada en el sistema operativo Android. La aplicacin permite el control de los robots que se estn desarrollando en el equipo de investigacin de ASLab. La Interfaz permite la conexin con sistemas ROS y ofrece al usuario la posibilidad de interactuar con ellos, en concreto teleoperar robots, visualizar informacin relevante, entre otras. Recomiendo este tipo de experiencia a todo aqul que est pensando en sumergirse en la programacin de aplicaciones, ya que permite ver el resultado de tu trabajo rpidamente y en mi opinin, de forma sorprendente. Quien iba a decirme a m que
80
I. M EMORIA l 6. RESULTADOS Y CONCLUSIONES
algn da tendra la oportunidad de ser el propio desarrollador de mis aplicaciones, para mis dispositivos y casi sin apenas medios, solo un terminal Android y un ordenador. Este es el verdadero potencial de Android y lo que lo diferencia de su competencia, el control total por parte del usuario del software que se ejecuta en su dispositivo.
81
Captulo 7 DESARROLLO FUTURO

Nos encontramos en un momento nico en la historia, es un momento importante y lleno de oportunidades para todos aquellos que se sienten intrigados por el desarrollo de aplicaciones para dispositivos mviles. Hasta ahora, slo empresas con capital suciente, grandes esfuerzos en investigacin de nuevos sistemas de control de dispositivos y como no, suerte, eran capaces de hacerse un hueco en el mercado de telfonos mviles. Algunas de estas empresas tuvieron que realizar inversiones millonarias, luchar por mantener su posicin en lo alto, empresas como Nokia, que nalmente han acabado casi por desaparecer. La oportunidad es nica, ahora el usuario posee los recursos necesarios para desarrollar por su cuenta aplicaciones para sus dispositivos, acrecentar las posibilidades de control de su terminal. En mi opinin, esto es algo inconcebible hace unos aos. Comentado esto, es evidente que las opciones de desarrollo futuro estn completamente abiertas a todo tipo de proyecto que se plantee. Posiblemente una mejora que ha quedado a medias en esta versin de la aplicacin, es hacerla compatible con el control de varios robots al mismo tiempo. Es posible que sea algo sencillo de implementar, ya que ha quedado casi a punto de conseguirse. El futuro desarrollador de la aplicacin podr contemplar el hecho de que el diseo de la misma est pensado para ser extensible a mltiples plataformas que implementen la losofa de los sistemas distribuidos de componentes. Este hecho hace que el sistema sea robusto y lo dota de viabilidad para continuar con el proyecto. En concreto queda la opcin de implementar la comunicacin con los sistemas tipo CORBA que estn montados en el robot Higgs, de manera que no sera necesaria ninguna interfaz ROS para la comunicacin con dichos mdulos. Se hace tedioso el hecho de que el sistema deba utilizarse dentro del alcance de una red wi para que los componentes funcionen correctamente. Puede plantearse la implementacin de dos nodos de comunicacin Bluetooth, uno en el robot y otro en el tablet. Como el tablet ya cuenta con servicio Bluetooth nicamente hara falta el nodo en el robot. Lo que se propone es el diseo de un protocolo de comunicaciones de
82
I. M EMORIA l 7. DESARROLLO FUTURO
forma que se transmitiera la informacin de los nodos ROS de Higgs por Bluetooth. De esta forma existira una cadena de mensaje con la informacin de todos los mensajes de todos los nodos que corren en el robot. El tablet debe recibir por Bluetooth esa cadena y descodicar las mensajes de los nodos que estn corriendo en el robot.
83
Captulo 8 PLANIFICACIN Y ALCANCE DEL PROYECTO

8.1. Estructura de descomposicin del trabajo
Figura 62. Estructura de Descomposicin del Trabajo
84
I. M EMORIA l 8. PLANIFICACIN Y ALCANCE DEL PROYECTO
85
86
87
8.2.
Diagrama de Gantt
El proyecto se ha desarrollado en el equipo de investigacin de ASLab durante siete meses, en los que se distinguen cinco fases principales: Estudio del mercado de tabletas, Investigacin de las herramientas Eclipse y Android, Desarrollo de la interfaz, Pruebas y Documentacin. A continuacin se presenta en la gura 69 el diagrama de Gantt que muestra el desarrollo de las distintas actividades a lo largo de la realizacin del proyecto.
88
Figura 69. Diagrama de Gantt del proyecto.
89
Bibliografa
[1] Higgs Manual. A platform for Autonomy Research. Carlos Hernndez, Adolfo Hernando, Ricardo Sanz, Francisco Arjonilla. (Diciembre 2011) [2] Programacin Orientada a Objetos con Java. ngel Garca Beltrn y Jos Mara Arranz Santamara. (Septiembre de 2007) [3] Effective Java. Joshua Bloch. (2008) [4] Core Java Volume I - Fundamentals. Cay S.Horstmann - Gary Cornell. (1999) [5] Core Java Volume II - Advanced Features. Cay S.Horstmann - Gary Cornell. (2000) [6] Java 2. Herbert Schildt. (2001) [7] Android Application Development., Lauren Darcey - Shane Conder. (Junio 2010) [8] Android Wireless Application Development. Shane Conder - Lauren Darcey. (2011) [9] Curso de programacin Android. Salvador Gmez Oliver. (Noviembre 2011) [10] Autonomous Systems Laboratory. ASLab Objetives. http://www.aslab.org [11] Android Documentation. http://www.developer.android.com [12] Ros Documentation. http://www.ros.org
90
PARTE II
ANEJOS
Captulo 1 Manual de usuario

1.1. Introduccin
La aplicacin AIRA (ASLab Interface Robot on Android) ha sido desarrollada por el equipo de investigacin de ASLab. La investigacin de este grupo se dedica al desarrollo de sistemas autnomos. Los Sistemas Autnomos (AS), suponen la parte ms emocionante para la investigacin tcnica. Son verdaderamente sistemas muy complicados y se hacen absolutamente carsimos en el esfuerzo. Es necesaria una gran capacidad tanto de concentracin, como de abstraccin para conseguir realizar avances en la investigacin de esta tcnica. ASLab est concienciado y preparado para cambiar el punto de vista que aportan los modelos tpicos en la investigacin acadmica. Pero, en cierto sentido, se realizan actividades desde una postura de miras al mundo industrial. Se pretende desarrollar tecnologa para sistemas autnomos en el mundo real, de forma que se dotar a los seres humanos libertad de supervisin, una vez que que el sistema est en funcionamiento. Ellos sern capaces de auto-gestionarse. Por todo ello, AIRA ha sido diseada para facilitar al grupo el manejo y control de robots, permitiendo interactuar con ellos y los sistemas que corren bajo su hardware.
1.2.
Asus Transformer Prime
Para empezar a utilizar la aplicacin es necesario familirizarse con el tablet en el que est instalada. Las caractersticas del tablet son las siguientes: Modelo: Asus Transformer Prime TF201. Versin de Android: versin 4.0.3 Versin de GPS: V6.9.20
92
II. A NEJOS l 1. M ANUAL DE USUARIO
Versin de WI-FI: V6.1.1.24 Versin de Bluetooth: V9.29 Versin de cmara: TF201-0x9900 Versin del panel tctil: MXT-2.0 build-170 Versin del Kernel: 2.6.39.4; android@Venus#1 El tablet implementa Android en su ltima versin Ice Cream Sandwich. El Asus Transformer Prime es probablemente el tablet ms potente que hay en las tiendas ahora mismo. Con la envidiable agilidad que le da el procesador Nvidia Tegra 3, el resto de componentes y construccin han sido cuidados con autntico mimo hasta llegar a un tablet estiloso y no. Asus ofrece en el Transformer Prime una carcasa en aluminio cepillado en espiral. El peso se ve incrementado sensiblemente por esta eleccin de material, pero merece la pena. El Asus Transformer Prime consigue transmitir sensacin de solidez y de resistencia en un grosor realmente no. Sus dimensiones son de 263 x 180.8 x 8.3 milmetros que pasan a 17-19.4 milmetros al incorporarle el Dock. Su peso es de 586 gramos y de 1.123 con dock.
Figura 70. Asus Transformer Prime. El dock que aade un teclado y batera extra al Transformer Prime, presume del mismo buen acabado aunque el teclado tipo chiclet parece un tanto pobre y hubiera sido un lujo que hubiese estado retroiluminado. El teclado en pantalla funciona de manera uida. El touchpad del Transformer Prime se mueve realmente bien y con agilidad. Ms an, el tablet aguanta la conexin de ratones por USB o bluetooth lo que, combinado con el teclado, hace que el Asus Transformer Prime rivalice con los ultrabooks como equipo para trabajar en movilidad.
93
1.3.
Inicio de la aplicacin
Una vez familiarizados con el tablet de Asus, se dispone a lanzar la aplicacin diseada por ASLab para el manejo de robots. Cuando se enciende en tablet se observa un escritorio con algunas de las aplicaciones que trae el tablet por defecto, entre ellas hay algunas que permiten organizar archivos, temas relacionados con multimedia, etc. Vase gura 71.
Figura 71. Escritorio principal Asus Transformer Prime El sistema Android permite la convivencia de varios escritorios al mismo tiempo, es por ello que si arrastramos con el dedo el escritorio principal hacia la izquierda o la derecha, la vista cambia a uno de los nuevos escritorios que se encuentran a ambos lados del principal. Si desplazamos el escritorio a la derecha encontraremos una vista donde est el icono de acceso directo a la aplicacin. Su nombre es ASLab y su icono es la imagen del grupo de investigacin, reconocible tambin por el texto que muestra. Vase gura 72.
Figura 72. Escritorio principal Asus Transformer Prime
94
Si pulsamos sobre el icono de la aplicacin se abrir la primera vista. La pantalla que da la bienvenida a la aplicacin corresponde a una Actividad Android que es la principal de la aplicacin. Esta pantalla se muestra en la gura 108.
Figura 73. Pantalla de bienvenida a la aplicacin de ASLab. Cuando el usuario inicia la aplicacin puede ver el smbolo de ASLab en la esquina superior izquierda. Si se pulsa sobre ella se muestra por pantalla un cuadro de dilogo con toda la informacin del grupo de investigacin. En concreto, se muestran los objetivos que este grupo tiene a la hora de desarrollar sistemas autnomos. Vase la gura 74.
Figura 74. Informacin sobre grupo de investigacin de ASLab . Para comenzar a manejar la aplicacin exite un men en la parte superior de la aplicacin en el que se muestran botones que ejecutan acciones. Existe texto aclarativo
95
de las funciones de cada botn. Si se pulsa sobre el botn Add Robot aparece en pantalla un cuadro de dilogo que permite al usuario escoger el tipo de robot que desea controlar, por defecto ROS. Adems el usuario debe completar la direccin de red que pertenece a dicho robot. Figura 75.
Figura 75. Cmo aadir un nuevo robot a la interfaz de control .
Figura 76. Si se cancela el evento, el cuadro desaparece de la pantalla .
1.4.
Robot ROS
La accin de haber aadido un nuevo robot tipo ROS al sistema, provoca que se cree una Actividad Android que implementa servicios de conexin ROS. En la nueva vista, encontramos dos fragmentos con el fondo de color negro. En ellos se mostrar informacin relevante en cada accin. Lo primero que se debe identicar para saber que se ha aadido un robot tipo ROS es observar en pantalla una imagen como la de la gura 77. Un robot ROS permite acciones de control concretas, entre las que destacan la siguientes:
96
Figura 77. Cmo aadir un nuevo robot a la interfaz de control . Robot Operation: permite teleoperar el robot. System State Viewer: permite ver informacin del sistema ROS que est corriendo en el robot. En la gura 78 se observa la lista desplegable que Android ofrece para mostrar items seleccionables.
Figura 78. Opciones de control del sistema ROS .
1.4.1.
System State Viewer
Una de las opciones que permite la interfaz es observar la informacin que corre en el sistema ROS al que est conectada la aplicacin. En realidad el sistema ROS corresponde con el robot que hemos aadido anteriormente. Como se muestra en la gura 79, los fragmentos de fondo negro dejan ver informacin de los nodos ROS del sistema. Es necesario pichar en el botn Refresh"que
97
Figura 79. Opciones de control del sistema ROS . aparece en lateral izquierdo para que se actualice la lista de nodos que estn corriendo en el sistema. Una vez actualizada la lista aparece en pantalla algo parecido a la gura 80.
Figura 80. Es necesario pulsar en un nodo para actualizar la lista de nodos ROS . En el fragmento de la izquierda aparecen los nodos del sistema. En el fragmento de la izquierda se observan los datos y la informacin correspondiente al nodo pulsado
98
de la lista. Cada vez que se pulsa un nodo, se visualizan los tpicos a los que estn suscritos, tambin se muestran los tpicos que ellos mismo publican y los parmetros que el nodo acepta cuando se lanza.
1.4.2.
Robot Operation
Existe otro modo para interactuar con el robot, es el modo de tele-operar. Este modo permite la conexin con el robot de forma que se puedan enviar instrucciones de movimiento al sistema. Esto es gracias a la publicacin de comandos de velocidad en ROS.
Figura 81. Es necesario pulsar para actualizar la lista de nodos ROS . Cuando se inicia esta modalidad aparecen en el fragmento de la derecha elementos de control, en este caso aparece un joystick virtual. Este elemento se encuentra en la parte inferior derecha del fragmento y permite mandar comandos de velocidad al robot, de forma que todo nodo suscrito al tpico de velocidad suministrado por el joystic puede obedecer a las instrucciones de control. Vase gura 81. El sistema tambin puede visualizar mapas, si es que hubiera un nodo suministrador de ellos. Para poder ver el mapa que vemos en la gura 81 es necesario lanzar el nodo map_server que ofrece ROS en su stack de paquetes por defecto. Se aconseja seguir minuciosamente los siguientes pasos para conseguir visualizar el mapa en pantalla, y ms adelante el robot que controlaremos.
99
1. Lo primero es denir un chero tipo launch, este es un chero de conguracin que permite lanzar al mismo tiempo todos los nodos que el usuario desee. La gura 82 muestra la estructura que sigue un archivo tipo launch.
Figura 82. Estructura del archivo tipo launch para la denicin de nodos ROS . En este caso se dene en el archivo tipo launch los siguientes nodos: El nodo Stage"que es el simulador que permite que al robot simular las mediciones de escaneo del lser. Este simulador visualiza en la pantalla del PC una ventana con el mapa, que se dene en los parmetros del nodo, y el robot que se simula. Se muestra en la gura 83 la ventana de simulacin obtenida en el PC. Adems es posible cambiar los mapas de simulacin, vase la gura 84. El nodo map_server: este nodo es el que ofrece la informacin del mapa que el usuario indica en la denicin de los parmetros del nodo. La informacin suministrada tiene que ver con la imagen que dene la gura del mapa y la informacin de obstculos que se encuentran dentro del mapa. 2. El siguiente paso es correr el archivo tipo launch en el terminal del PC. Para ello es necesario tener instalado Ubuntu, como se menciona en el captulo 3 de este proyecto. Para lanzar el archivo abrimos el terminal de Ubuntu y tecleamos lo mismo que se indica en la gura 85. 3. Finalmente es necesario correr el nodo que suministra informacin de los nodos del sistema. Este nodo ha sido desarrollado por el grupo de investigacin de ASLab. Vase la gura 86.
100
Figura 83. Simulacin en el PC del nodo Stage que permite obtener mediciones del lser .
101
Figura 84. Simulacin del nodo Stage con un mapa diferente .
Figura 85. Lanzamiento en el terminal de Ubuntu del chero de conguracin .
Figura 86. Lanzamiento en terminal de Ubuntu del nodo que suministra informacin del sistema .
102
Figura 87. Ejemplo de manejo del robot con el Joystick Virtual
Figura 88. El robot obedece las instrucciones del Joystick
103
Figura 89. Se visualizan el mapa y el robot juntos.
Figura 90. La aplicacin permite tambin hacer zoom y rotar la pantalla a gusto del usuario.
104
1.5.
Cliente remoto
La interfaz de usuario permite tambin la implementacin de un cliente remoto. Esto permite acceder directamente al sistema operativo del robot mvil (por ejemplo, para congurar la parte residente del sistema de control del robot). Este proceso se hace realidad gracias a otra herramienta que debe estar instalada en el dispositivo. Esta herramienta no es ms que otra actividad Android que permite el servicio de conexin remota. La herramienta se denomina ASLab ssh y es una ampliacin de la aplicacin principal AIRA.
Figura 91. Seleccin del servicio de Cliente SSH de ASLab. Este servicio se encuentra disponible desde el men de la aplicacin, tanto desde la actividad principal al inicio, como desde la actividad que maneja el robot. En la gura 91 se observa que la opcin aparece en la esquina superior derecha, en este caso la gura muestra el acceso al servicio SSH desde la actividad principal de la aplicacin. Se comenta de nuevo, que es posible acceder a este servicio desde cualquiera de las actividades. Al pulsar el botn aparecer en la pantalla un cuadro de dilogo que requiere de cierta informacin que el usuario debe rellenar correctamente para que el servicio se inicie si problemas. El servicio ofrece una conexin SSH a un equipo remoto. SSH son las siglas de Secure SHell y lo que ofrece es una consola en un dispositivo remoto con los privilegios que tenga la cuenta con la que te registres. Es decir, si en un PC existen varias cuentas, este servicio permite conectarte desde otro equipo al primero con cualquiera de esas
105
cuentas y con sus respectivos privilegios. Podemos conectarnos por ejemplo a la cuenta root, la de administrador sudo o la de un usuario normal. Y todo esto con encriptacin de datos. Es necesario rellenar los campos de datos del cuadro de dilogo para que se inicie la conexin, adems se debe pulsar el botn Aceptar para comenzar con la identicacin del usuario. Vase la gura 92.
Figura 92. Cuadro de dilogo de la conexin remota, en este caso SSH. Los campos deben contener la siguiente informacin: User: es el nombre de usuario que existe en la mquina remota y que corresponde con la cuenta a la que queremos conectarnos. Host: es la direccin IP de la mquina a la que queremos conectarnos, es imprescindible que la direccin IP sea correcta y est asociada a la mquina que queremos, ya que de lo contrario la conexin ser fallida por dos motivos, por no existir la cuenta de usuario a la que queremos conectarnos, o por no existir directamente la direccin. Port: es el puerto por el cul nos conectaremos a la mquina deseada. Normalmente el puerto designado para la conexin de servicios SSH es el 22, si fuera necesario es posible cambiar este puerto en el cuadro de dilogo. Nick Name: ser el nombre con el que la herramienta de ASLab recordar conexiones anteriores. Esto es en realidad un nick interno de la aplicacin para identicar a los usuarios que han realizado conexiones anteriormente.
106
El cuadro rellena por defecto los datos de un usuario del grupo de ASLab, en concreto el mo, el autor del proyecto. Se debe mostrar en la pantalla el intento de conexin, para lo cul nos pide la contrasea (gura 93) de usuario en la parte inferior. Cuando se haya completado el proceso, la imagen debe ser como la de la gura 94
Figura 93. Solicitud de contrasea para el usuario solicitado.
Figura 94. Conexin SSH realizada con xito.
107
1.5.1.
Men de opciones del cliente remoto
La herramienta de cliente remoto ofrece algunas opciones de conguracin y de edicin del sistema, esto es que en el men de la herramienta se incorporan botones que implementan acciones concretas de conguracin y edicin de texto en el terminal. Adems, la herramienta ofrece otro tipo de conexiones que no sean necesariamente SSH, es por ello que se enuncian a continuacin algunas de estas caractersticas. Terminal. La herramienta ofrece las caractersticas bsicas del terminal de un sistema UNIX. Es por ello que se puede utilizar la interfaz como ventana de comandos para realizar cualquier tarea que un terminal permita. Si se observa la gura 95 puede comprobarse el resultado de haber tecleado el comando ls en el terminal. Este comando en realidad permite la exploracin del contenido de un directorio. En la imagen se observa el listado de cheros y archivos que se encuentran en el directorio /home de la mquina a la que se est conectado.
Figura 95. Resultado de teclear ls en la ventana de comandos. Al mismo tiempo se puede comprobar cul es el resultado del comando cd, que permite abrir un directorio y posicionarse en l. En el caso de querer ver su contenido deberemos teclear ls como en el caso anterior. Estos comandos son nociones bsicas de utilizacin del terminal en un sistema UNIX. Para ms informacin consltese un manual para el uso del terminal.
108
Figura 96. Resultado de teclear ls en la ventana de comandos. Copiar: Es posible que el usuario desee copiar algunos de los caracteres de la pantalla. La herramienta ofrece un botn que ejecuta tal accin, para lo cul el usuario debe pulsar el botn y desplazar el dedo sobre la zona de la pantalla que se desee copiar.
Figura 97. Tocar y arrastrar para seleccionar la zona a copiar.
109
La gura 97 muestra como la herramienta avisa al usuario de la accin que debe llevar a cabo para copiar satisfactoriamente una zona de la pantalla. La gura 98 muestra como se selecciona la zona deseada por el usuario al arrastrar con el dedo dicha zona. Se puede ampliar la zona de copia hasta toda la pantalla del terminal.
Figura 98. Seleccin de la zona a copiar. Para indicar al usuario que la copia se ha realizado con xito se muestra en la pantalla un mensaje de corta duracin, que desaparece transcurridos un par de segundos. El mensaje indica cuntos bytes se han copiado producto de la seleccin de una zona de la pantalla. Vase la gura 98. Pegar: Si existe la posibilidad de copiar una zona de la pantalla, como no, tena que existir la posibilidad de pegar la zona seleccionada. Esta opcin se facilita cuando existen cosas que pegar que estn guardadas en el portapapeles de la herramienta. Cuando hay cosas que pegar la opcin se habilita en el men de usuario en la parte superior de la pantalla. Hasta ese momento la opcin est desahabilitada ya que si el portapapeles est vaco no hay nada que pegar. En la gura 99 se observa como la opcin de pegar se muestra activa. Si la pulsamos el contenido del cortapapeles se pegar en la consola de comandos. vase el contenido pegado en la misma gura 99.
110
Figura 99. Pegado del contenido del portapapeles en la consola de comandos. Men de conguracin: La herramienta ofrece tambin la posibilidad de recongurar algunas de las opciones que se ofrecen. En el men de usuario se observa un smbolo con tres cuadros en vertical, este smbolo aparece en los mens cuando no todas las opciones caben en la apariencia visual de la aplicacin, o simplemente que el diseador ha escogido agrupar las opciones en un solo vnculo.
Figura 100. Seleccin de opciones de conguracin.
111
Si pulsamos en este botn se despliegan las opciones de conguracin de la herramienta. Entre ellas encontramos: Traducciones de puerto: permite redireccionar puertos. Escaneo de direcciones: realiza un escaneo de las direcciones posibles en la red en la que se encuentra. Forzar un tamao: permite ajustar el tamao de pantalla, de esta forma se permite hacer zoom para ver con ms claridad el texto. Vanse las guras 101 y 102. Ordenar por color: Esta opcin permite ordenar los usuarios registrados por un color que identica a cada uno de ellos. En caso ya de estar ordenados por color, esta opcin se mostrar como ordenar por nombre. Administrar claves pblicas: permite importar un llavero de claves pblicas para congurar usuarios. Colores: permite congurar la apariencia de la mquina con una paleta de colores muy extensa y variada. Vase la gura 103. Conguracin: permite algunas opciones de conguracin con las que el usuario puede personalizar la herramienta. Vase la gura 104. Ayuda: como su nombre indica es la ayuda de la herramienta.
Figura 101. Nuevas dimensiones de la pantalla del terminal.
112
Figura 102. Redimensionado de la pantalla del terminal.
Figura 103. Colores disponibles para personalizar la apariencia de la herramienta. Otros servicios: La herramienta no solo ofrece la posibilidad de implementar un servicio SSH, sino que permite tambin conexin local y telnet. Estas opciones se encuentran en la parte inferior de la pantalla, en el mrgen izquierdo, junto a la casilla de identicacin de usuarios. Es por ello que se pueden realizar estas conexiones si el usuario lo desea.
113
Figura 104. Conguracin personalizada de las opciones de la herramienta. Cabe mencionar que nicamente se puede cambiar el tipo de conexin una vez iniciada la herramienta, y nunca desde la interfaz de control que inicia directamente una conexin SSH. Vase la gura 105.
Figura 105. Otros servicios ofrecidos para la conexin remota, aparte de la conexin SSH.
114
Desconectar: Cuando se hayan realizado todas operaciones deseadas se puede realizar la desconexin remota de la mquina. Para ello debe pulsarse sobre la opcin Desconectar del men de la herramienta. Esta opcin cierra la conexin actual despus de que el usuario conrme tal operacin. Vase la gura 106.
Figura 106. Desconexin de la mquina. Return: Cuando se desee volver a la interfaz de control de robots, se debe pulsar el botn Return que se encuentra en el men de usuario. Este botn cierra el cliente de conexin remota y vuelve a mostrar la vista de control que exista antes de iniciar la conexin SSH. Vase la gura 107.
115
Figura 107. Cierre de la herramienta SSH y vuelta a la aplicacin de control visual.
Figura 108. Pantalla de la herramienta de control que se muestra al volver del cliente SSH.
116
1.6.
Apagado de la aplicacin
Cuando se desee cerrar la aplicacin, nicamente es necesario pulsar en el icono Home de la barra de sistema del dispositivo. Este icono se encuentra en la parte inferior izquierda, entre el icono de vuelta atrs (Back) y el icono de vista de aplicaciones activas. Vase la gura 109.
Figura 109. Iconos de la barra de sistema de Android. Al pulsar el icono Home todas las aplicaciones activas se minimizan de forma que se muestra en pantalla el escritorio de Android. Para terminar con la ejecucin de una aplicacin por completo se debe abrir el visor de aplicaciones recientes. Este visor se abre al pulsar sobre el icono de vista de aplicaciones que se muestra en la gura 109. El visor muestra todas las aplicaciones que se hayan abierto desde el encendido del dispositivo. Se debe ver en pantalla algo parecido a la imagen de la gura 110. Para cerrar la aplicacin es necesario arrastrar con el dedo la imagen de la aplicacin que queramos cerrar. Si no hubiera ms aplicaciones en el visor, la pantalla del dispositivo debe ser como la de la gura 111.
117
Figura 110. Visor de aplicaciones recientes.
Figura 111. Visor de aplicaciones recientes vaco.
118
Finalmente queda apagar el dispositivo. Para ello es necesario mantener pulsado el botn de apagado durante un par de segundos hasta que aparezca en pantalla un cuadro de dilogo que advierta del apagado. Para apagar pulsamos Aceptar y el dispositivo se apagar completamente.
Figura 112. Apagado del sistema y del disposito Android.
119
PARTE III
CDIGO FUENTE
Captulo 1 Cdigo Java de la aplicacin

1.1. MainActivity.java
package org.aslab.tablet_application; import org.aslab.tablet_application.SshChooserDialog.SshChooserDialogListener; import org.ros.android.MasterChooserDialog; import org.ros.android.MasterChooserDialog.MasterChooserDialogListener; import import import import import import import import import import import import import import import import import import import com.google.common.base.Preconditions; android.app.ActionBar; android.app.Activity; android.app.FragmentManager; android.app.FragmentTransaction; android.content.Context; android.content.Intent; android.net.Uri; android.os.Bundle; android.view.Menu; android.view.MenuInflater; android.view.MenuItem; android.view.View; android.view.View.OnClickListener; android.widget.AdapterView; android.widget.ArrayAdapter; android.widget.Button; android.widget.Spinner; android.widget.Toast;
public class MainActivity extends Activity implements MasterChooserDialogListener, SshChooserDialogListener{ public static Activity mainActivity; public Button addRobot; public ActionBar actionBar; private static final int DEFAULT_PORT = 22; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main);
121
III. C DIGO FUENTE l 1. C DIGO JAVA DE LA APLICACIN
//Para tener acceso al resto de variables mainActivity = this; //ActionBAr actionBar = getActionBar(); } public static MainActivity getInstance(){ return (MainActivity) mainActivity; } @Override public boolean onCreateOptionsMenu(Menu menu) { MenuInflater Inflater = getMenuInflater(); Inflater.inflate(R.menu.main, menu); // Calling super after populating the menu is necessary here to ensure that the // action bar helpers have a chance to handle this event. return true; } @Override public boolean onOptionsItemSelected(MenuItem item) { switch (item.getItemId()) { case android.R.id.home: InfoDialog ASLab_info = new InfoDialog(); ASLab_info.show(MainActivity.this.getFragmentManager(), "ASLab Info"); break; case R.id.addRobotBtn: MasterChooserDialog mcd = new MasterChooserDialog(); mcd.show(MainActivity.this.getFragmentManager(), "Master Chooser"); break; case R.id.sshBtn: SshChooserDialog scd = new SshChooserDialog(); scd.show(MainActivity.this.getFragmentManager(), "ssh Connection"); break; } return super.onOptionsItemSelected(item); } @Override public void onMasterChooserDialogCancelFinish(String message) { Toast.makeText(this, message, Toast.LENGTH_SHORT).show(); } @Override public void onMasterChooserDialogOkFinish(String masterUri, String robotType){ // TODO Chequear si el masteruri existe!! if (robotType.equals ("ros")){ // Package the intent to be consumed by the calling activity. Bundle bundle = new Bundle(); bundle.putString("ROS_MASTER_URI", masterUri); Intent intent = new Intent(MainActivity.this, RosActivityRobot.class); intent.putExtras(bundle); startActivity(intent); } else if (robotType.equals ("corba")){ // EXTENSION POINT } else { // TODO rise exception
122
Toast.makeText(this, "ERROR Al CREAR INTENT", Toast.LENGTH_SHORT).show(); }
} @Override public void onSshOkFinish(String user, String host, String port, String nickname) { if (Integer.parseInt(port) != DEFAULT_PORT){ startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse("ssh://"+user+"@"+host+":"+port+"/#"+nickname))); }else{ startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse((String)("ssh://"+user+"@"+host+":"+Integer.toString(DEFAULT_PORT)+"/#"+ } } @Override public void onSshCancelFinish(String message) { Toast.makeText(this, message, Toast.LENGTH_SHORT).show(); } }
123
1.2.
RosActivityRobot.java
package org.aslab.tablet_application; import java.net.URI; import java.util.ArrayList; import java.util.List; import meta_msgs.NodeInfo; import import import import import import import import import org.aslab.tablet_application.NodeListFragment.OnNodeSelectedListener; org.aslab.tablet_application.OptionsFrag.OnOptionSelectedListener; org.aslab.tablet_application.SshChooserDialog.SshChooserDialogListener; org.ros.address.InetAddressFactory; org.ros.android.MasterChooserDialog; org.ros.android.MasterChooserDialog.MasterChooserDialogListener; org.ros.android.RosRobot; org.ros.node.NodeConfiguration; org.ros.node.NodeMainExecutor;
import com.google.common.base.Preconditions; import import import import import import import import import import import import android.app.ActionBar; android.app.ActionBar.Tab; android.app.Fragment; android.app.FragmentManager; android.app.FragmentTransaction; android.content.Intent; android.net.Uri; android.os.Bundle; android.view.Menu; android.view.MenuInflater; android.view.MenuItem; android.widget.Toast;
public class RosActivityRobot extends RosRobot implements MasterChooserDialogListener, OnOptionSelectedListener, SshChooserDialogListener, OnNodeSelectedListener { public MapFragment map; public NodeMainExecutor nodeMainExecutor; public NodeConfiguration nodeConfiguration; public NodeInfoFragment nodeInfofrag; public ActionBar actionBar; private static final int DEFAULT_PORT = 22;
public RosActivityRobot() { super("RosActivityRobot", "RosActivityRobot"); } @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.rosrobot); actionBar = getActionBar();
124
} @Override public boolean onCreateOptionsMenu(Menu menu) { MenuInflater Inflater = getMenuInflater(); Inflater.inflate(R.menu.robot_menu, menu); // Calling super after populating the menu is necessary here to ensure that the // action bar helpers have a chance to handle this event. return true; } @Override public boolean onOptionsItemSelected(MenuItem item) { switch (item.getItemId()) { case android.R.id.home: InfoDialog ASLab_info = new InfoDialog(); ASLab_info.show(RosActivityRobot.this.getFragmentManager(), "ASLab Info"); break; case R.id.operacion: FragmentTransaction ft1 = getFragmentManager().beginTransaction(); TeleopFragment teleop = new TeleopFragment(); ft1.replace(R.id.view_frame, teleop); ft1.commit(); break; case R.id.observacion: FragmentTransaction ft2 = getFragmentManager().beginTransaction(); NodeListFragment nodelistfrag = new NodeListFragment(); nodeInfofrag = new NodeInfoFragment(); ft2.replace(R.id.options_frame, nodelistfrag); ft2.replace(R.id.view_frame, nodeInfofrag); ft2.commit(); break; case R.id.gestion: break; case R.id.addRobotBtn: MasterChooserDialog mcd = new MasterChooserDialog(); mcd.show(RosActivityRobot.this.getFragmentManager(), "Master Chooser"); break; case R.id.sshBtn: SshChooserDialog scd = new SshChooserDialog(); scd.show(RosActivityRobot.this.getFragmentManager(), "ssh Connection"); break; } return super.onOptionsItemSelected(item); }
@Override public void onMasterChooserDialogCancelFinish(String message) { Toast.makeText(this, message, Toast.LENGTH_SHORT).show(); } @Override public void onMasterChooserDialogOkFinish(String masterUri, String robotType){ // TODO Chequear si el masteruri existe!! if (robotType.equals ("ros")){ // Package the intent to be consumed by the calling activity.
125
Bundle bundle = new Bundle(); bundle.putString("ROS_MASTER_URI", masterUri); Intent intent = new Intent(RosActivityRobot.this, RosActivityRobot.class); intent.putExtras(bundle); startActivity(intent); } else if (robotType.equals ("corba")){ // EXTENSION POINT } else { // TODO rise exception } }
@Override public void onOptionSelected(String item){ FragmentTransaction ft = getFragmentManager().beginTransaction(); if (item.toLowerCase().contains("map")){ map = new MapFragment(); ft.replace(R.id.view_frame, map); ft.commit(); return; } if (item.toLowerCase().contains("teleoperar")){ map.onTeleopOptionClicked(); return; } if (item.toLowerCase().contains("camera")){ return; } }
@Override protected void init(NodeMainExecutor nodeMainExecutor) { NodeConfiguration nodeConfiguration = NodeConfiguration.newPublic(InetAddressFactory.newNonLoopback().getHostAddress()); nodeConfiguration.setMasterUri(getMasterUri()); this.nodeConfiguration = nodeConfiguration; this.nodeMainExecutor = nodeMainExecutor; } public NodeConfiguration getNodeConfiguration (){ return nodeConfiguration; } public NodeMainExecutor getNodeMainExecutor(){ return nodeMainExecutor; }
@Override public void onSshOkFinish(String user, String host, String port, String nickname) { if (Integer.parseInt(port) != DEFAULT_PORT){ startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse("ssh://"+user+"@"+host+":"+port+"/#"+nickname))); }else{ startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse((String)("ssh://"+user+"@"+host+":"+Integer.toString(DEFAULT_PORT)+"/#"+
126
} } @Override public void onSshCancelFinish(String message) { Toast.makeText(this, message, Toast.LENGTH_SHORT).show(); } @Override public void onNodeSelected(NodeInfo node) { nodeInfofrag.showInfo(node); } }
127
1.3.
NodeMainExecutorService.java
/* * Copyright (C) 2011 Google Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); you may not * use this file except in compliance with the License. You may obtain a copy of * the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the * License for the specific language governing permissions and limitations under * the License. */ package org.ros.android; import com.google.common.base.Preconditions; import import import import import import import import import import import import import import import import import import import import import android.app.Notification; android.app.PendingIntent; android.app.Service; android.content.Intent; android.net.wifi.WifiManager; android.net.wifi.WifiManager.WifiLock; android.os.Binder; android.os.IBinder; android.os.PowerManager; android.os.PowerManager.WakeLock; android.util.Log; org.ros.RosCore; org.ros.android.android_gingerbread_mr1.R; org.ros.concurrent.ListenerGroup; org.ros.concurrent.SignalRunnable; org.ros.exception.RosRuntimeException; org.ros.node.DefaultNodeMainExecutor; org.ros.node.NodeConfiguration; org.ros.node.NodeListener; org.ros.node.NodeMain; org.ros.node.NodeMainExecutor;
import java.net.URI; import java.util.Collection; import java.util.concurrent.ScheduledExecutorService; /** * @author damonkohler@google.com (Damon Kohler) */ public class NodeMainExecutorService extends Service implements NodeMainExecutor { private static final String TAG = "NodeMainExecutorService"; // NOTE(damonkohler): If this is 0, the notification does not show up. private static final int ONGOING_NOTIFICATION = 1;
128
static final String ACTION_START = "org.ros.android.ACTION_START_NODE_RUNNER_SERVICE"; static final String ACTION_SHUTDOWN = "org.ros.android.ACTION_SHUTDOWN_NODE_RUNNER_SERVICE"; static final String EXTRA_NOTIFICATION_TITLE = "org.ros.android.EXTRA_NOTIFICATION_TITLE"; static final String EXTRA_NOTIFICATION_TICKER = "org.ros.android.EXTRA_NOTIFICATION_TICKER"; private final NodeMainExecutor nodeMainExecutor; private final IBinder binder; private final ListenerGroup<NodeMainExecutorServiceListener> listeners; private private private private WakeLock wakeLock; WifiLock wifiLock; RosCore rosCore; URI masterUri;
/** * Class for clients to access. Because we know this service always runs in * the same process as its clients, we dont need to deal with IPC. */ class LocalBinder extends Binder { NodeMainExecutorService getService() { return NodeMainExecutorService.this; } } public NodeMainExecutorService() { super(); nodeMainExecutor = DefaultNodeMainExecutor.newDefault(); binder = new LocalBinder(); listeners = new ListenerGroup<NodeMainExecutorServiceListener>( nodeMainExecutor.getScheduledExecutorService()); } @Override public void onCreate() { PowerManager powerManager = (PowerManager) getSystemService(POWER_SERVICE); wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, TAG); wakeLock.acquire(); int wifiLockType = WifiManager.WIFI_MODE_FULL; try { wifiLockType = WifiManager.class.getField("WIFI_MODE_FULL_HIGH_PERF").getInt(null); } catch (Exception e) { // We must be running on a pre-Honeycomb device. Log.w(TAG, "Unable to acquire high performance wifi lock."); } WifiManager wifiManager = (WifiManager) getSystemService(WIFI_SERVICE); wifiLock = wifiManager.createWifiLock(wifiLockType, TAG); wifiLock.acquire(); } @Override public void execute(NodeMain nodeMain, NodeConfiguration nodeConfiguration, Collection<NodeListener> nodeListeneners) { nodeMainExecutor.execute(nodeMain, nodeConfiguration, nodeListeneners);
129
} @Override public void execute(NodeMain nodeMain, NodeConfiguration nodeConfiguration) { execute(nodeMain, nodeConfiguration, null); } @Override public ScheduledExecutorService getScheduledExecutorService() { return nodeMainExecutor.getScheduledExecutorService(); } @Override public void shutdownNodeMain(NodeMain nodeMain) { nodeMainExecutor.shutdownNodeMain(nodeMain); } @Override public void shutdown() { signalOnShutdown(); // NOTE(damonkohler): This may be called multiple times. Shutting down a // NodeMainExecutor multiple times is safe. It simply calls shutdown on all // NodeMains. nodeMainExecutor.shutdown(); if (rosCore != null) { rosCore.shutdown(); } if (wakeLock.isHeld()) { wakeLock.release(); } if (wifiLock.isHeld()) { wifiLock.release(); } stopForeground(true); stopSelf(); } public void addListener(NodeMainExecutorServiceListener listener) { listeners.add(listener); } private void signalOnShutdown() { listeners.signal(new SignalRunnable<NodeMainExecutorServiceListener>() { @Override public void run(NodeMainExecutorServiceListener nodeMainExecutorServiceListener) { nodeMainExecutorServiceListener.onShutdown(NodeMainExecutorService.this); } }); } @Override public void onDestroy() { shutdown(); super.onDestroy(); } @Override public int onStartCommand(Intent intent, int flags, int startId) {
130
if (intent.getAction() == null) { return START_NOT_STICKY; } if (intent.getAction().equals(ACTION_START)) { Preconditions.checkArgument(intent.hasExtra(EXTRA_NOTIFICATION_TICKER)); Preconditions.checkArgument(intent.hasExtra(EXTRA_NOTIFICATION_TITLE)); Notification notification = new Notification(R.drawable.icon, intent.getStringExtra(EXTRA_NOTIFICATION_TICKER), System.currentTimeMillis()); Intent notificationIntent = new Intent(this, NodeMainExecutorService.class); notificationIntent.setAction(NodeMainExecutorService.ACTION_SHUTDOWN); PendingIntent pendingIntent = PendingIntent.getService(this, 0, notificationIntent, 0); notification.setLatestEventInfo(this, intent.getStringExtra(EXTRA_NOTIFICATION_TITLE), "Tap to shutdown.", pendingIntent); startForeground(ONGOING_NOTIFICATION, notification); } if (intent.getAction().equals(ACTION_SHUTDOWN)) { shutdown(); } return START_NOT_STICKY; } @Override public IBinder onBind(Intent intent) { return binder; } public URI getMasterUri() { return masterUri; } public void setMasterUri(URI uri) { masterUri = uri; } public void startMaster() { rosCore = RosCore.newPrivate(); rosCore.start(); try { rosCore.awaitStart(); } catch (Exception e) { throw new RosRuntimeException(e); } masterUri = rosCore.getUri(); } }
131
1.4.
RosRobot.java
/* * Copyright (C) 2011 Google Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); you may not * use this file except in compliance with the License. You may obtain a copy of * the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the * License for the specific language governing permissions and limitations under * the License. */ package org.ros.android; import com.google.common.base.Preconditions; import import import import import import import import android.app.Activity; android.content.ComponentName; android.content.Intent; android.content.ServiceConnection; android.os.AsyncTask; android.os.Bundle; android.os.IBinder; android.widget.Toast;
import org.ros.exception.RosRuntimeException; import org.ros.node.NodeMain; import org.ros.node.NodeMainExecutor; import java.net.URI; import java.net.URISyntaxException; /** * @author damonkohler@google.com (Damon Kohler) */ public abstract class RosRobot extends Activity { private static final int MASTER_CHOOSER_REQUEST_CODE = 0; private final ServiceConnection nodeMainExecutorServiceConnection; private final String notificationTicker; private final String notificationTitle; private NodeMainExecutorService nodeMainExecutorService; private final class NodeMainExecutorServiceConnection implements ServiceConnection { @Override public void onServiceConnected(ComponentName name, IBinder binder) { nodeMainExecutorService = ((NodeMainExecutorService.LocalBinder) binder).getService(); nodeMainExecutorService.addListener(new NodeMainExecutorServiceListener() {
132
@Override public void onShutdown(NodeMainExecutorService nodeMainExecutorService) { RosRobot.this.finish(); } }); startMasterChooser(); } @Override public void onServiceDisconnected(ComponentName name) { } }; protected RosRobot(String notificationTicker, String notificationTitle) { super(); this.notificationTicker = notificationTicker; this.notificationTitle = notificationTitle; nodeMainExecutorServiceConnection = new NodeMainExecutorServiceConnection(); } @Override protected void onStart() { super.onStart(); startNodeMainExecutorService(); } private void startNodeMainExecutorService() { Intent intent = new Intent(this, NodeMainExecutorService.class); intent.setAction(NodeMainExecutorService.ACTION_START); intent.putExtra(NodeMainExecutorService.EXTRA_NOTIFICATION_TICKER, notificationTicker); intent.putExtra(NodeMainExecutorService.EXTRA_NOTIFICATION_TITLE, notificationTitle); startService(intent); Preconditions.checkState( bindService(intent, nodeMainExecutorServiceConnection, BIND_AUTO_CREATE), "Failed to bind NodeMainExecutorService."); } @Override protected void onDestroy() { if (nodeMainExecutorService != null) { nodeMainExecutorService.shutdown(); unbindService(nodeMainExecutorServiceConnection); // NOTE(damonkohler): The activity could still be restarted. In that case, // nodeRunner needs to be null for everything to be started up again. nodeMainExecutorService = null; } Toast.makeText(this, notificationTitle + " shut down.", Toast.LENGTH_SHORT).show(); super.onDestroy(); } /** * This method is called in a background thread once this {@link Activity} has * been initialized with a master {@link URI} via the {@link MasterChooser} * and a {@link NodeMainExecutorService} has started. Your {@link NodeMain}s * should be started here using the provided {@link NodeMainExecutor}. *
133
* @param nodeMainExecutor the {@link NodeMainExecutor} created for this {@link Activity} * */ protected abstract void init(NodeMainExecutor nodeMainExecutor); private void startMasterChooser() { Preconditions.checkState(getMasterUri() == null); Bundle bundle = getIntent().getExtras(); String masterUri = bundle.getString("ROS_MASTER_URI"); Intent intent = new Intent(); intent.putExtra("ROS_MASTER_URI", masterUri); onMasterChooserFinish(0,RESULT_OK,intent); } public URI getMasterUri() { Preconditions.checkNotNull(nodeMainExecutorService); return nodeMainExecutorService.getMasterUri(); } @Override public void startActivityForResult(Intent intent, int requestCode) { Preconditions.checkArgument(requestCode != MASTER_CHOOSER_REQUEST_CODE); super.startActivityForResult(intent, requestCode); } @Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { /* if (requestCode == MASTER_CHOOSER_REQUEST_CODE) { if (resultCode == RESULT_OK) { if (data == null) { nodeMainExecutorService.startMaster(); } else { URI uri; try { uri = new URI(data.getStringExtra("ROS_MASTER_URI")); } catch (URISyntaxException e) { throw new RosRuntimeException(e); } nodeMainExecutorService.setMasterUri(uri); } // Run init() in a new thread as a convenience since it often requires // network access. new AsyncTask<Void, Void, Void>() { @Override protected Void doInBackground(Void... params) { RosRobot.this.init(nodeMainExecutorService); return null; } }.execute(); } else { // Without a master URI configured, we are in an unusable state. nodeMainExecutorService.shutdown(); finish(); } } */ }
134
public void onMasterChooserFinish(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); if (requestCode == MASTER_CHOOSER_REQUEST_CODE) { if (resultCode == RESULT_OK) { if (data == null) { nodeMainExecutorService.startMaster(); } else { URI uri; try { uri = new URI(data.getStringExtra("ROS_MASTER_URI")); } catch (URISyntaxException e) { throw new RosRuntimeException(e); } nodeMainExecutorService.setMasterUri(uri); } // Run init() in a new thread as a convenience since it often requires // network access. new AsyncTask<Void, Void, Void>() { @Override protected Void doInBackground(Void... params) { RosRobot.this.init(nodeMainExecutorService); return null; } }.execute(); } else { // Without a master URI configured, we are in an unusable state. nodeMainExecutorService.shutdown(); finish(); } } } }
135
1.5.
TeleopFragment.java
/* * Copyright (C) 2011 Google Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); you may not * use this file except in compliance with the License. You may obtain a copy of * the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the * License for the specific language governing permissions and limitations under * the License. */ package org.aslab.tablet_application; import import import import import import import import import import import import import import import import import import import import import import android.app.Activity; android.app.Fragment; android.os.Bundle; android.view.LayoutInflater; android.view.Menu; android.view.MenuInflater; android.view.MenuItem; android.view.View; android.view.ViewGroup; android.view.View.OnClickListener; android.widget.ToggleButton; org.ros.android.view.VirtualJoystickView; org.ros.android.view.visualization.VisualizationView; org.ros.android.view.visualization.layer.CameraControlLayer; org.ros.android.view.visualization.layer.LaserScanLayer; org.ros.android.view.visualization.layer.OccupancyGridLayer; org.ros.android.view.visualization.layer.PathLayer; org.ros.android.view.visualization.layer.PosePublisherLayer; org.ros.android.view.visualization.layer.PoseSubscriberLayer; org.ros.android.view.visualization.layer.RobotLayer; org.ros.node.NodeConfiguration; org.ros.node.NodeMainExecutor;
/** * An app that can be used to control a remote robot. This app also demonstrates * how to use some of views from the rosjava android library. * * @author munjaldesai@google.com (Munjal Desai) * @author moesenle@google.com (Lorenz Moesenlechner) */ public class TeleopFragment extends Fragment { private static final String MAP_FRAME = "map"; private static final String ROBOT_FRAME = "base_link"; private VirtualJoystickView virtualJoystickView;
136
private VisualizationView visualizationView; private ToggleButton followme; public NodeMainExecutor nodeMainExecutor; public NodeConfiguration nodeConfiguration; public TeleopFragment() { } @Override public void onAttach(Activity activity){ super.onAttach(activity); this.nodeConfiguration = ((RosActivityRobot)activity).getNodeConfiguration(); this.nodeMainExecutor = ((RosActivityRobot)activity).getNodeMainExecutor(); } @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); } @Override public void onActivityCreated(Bundle savedInstanceState) { super.onActivityCreated(savedInstanceState); } @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { View view = inflater.inflate(R.layout.teleoperacion, container, false); virtualJoystickView = (VirtualJoystickView) view.findViewById(R.id.virtual_joystick_teleop); visualizationView = (VisualizationView) view.findViewById(R.id.visualization_teleop); visualizationView.getCamera().setFrame("map"); followme = (ToggleButton) view.findViewById(R.id.follow_me); followme.setOnClickListener(new OnClickListener() { @Override public void onClick(View v) { TeleopFragment.this.onFollowMeToggleButtonClicked(v); } }); init(); return view; } public void init() { visualizationView.addLayer(new CameraControlLayer(getActivity(), nodeMainExecutor.getScheduledExecutorService())); visualizationView.addLayer(new OccupancyGridLayer("map")); visualizationView.addLayer(new PathLayer("move_base/NavfnROS/plan")); visualizationView.addLayer(new PathLayer("move_base_dynamic/NavfnROS/plan")); visualizationView.addLayer(new LaserScanLayer("scan")); visualizationView.addLayer(new PoseSubscriberLayer("simple_waypoints_server/goal_pose")); visualizationView.addLayer(new PosePublisherLayer("simple_waypoints_server/goal_pose", getActivity())); visualizationView.addLayer(new RobotLayer("base_footprint")); nodeMainExecutor.execute(virtualJoystickView, nodeConfiguration.setNodeName("virtual_joystick"));
137
nodeMainExecutor.execute(visualizationView, nodeConfiguration.setNodeName("android/map_view")); } protected void onFollowMeToggleButtonClicked(View view) { boolean on = ((ToggleButton) view).isChecked(); if (on) { enableFollowMe(); } else { disableFollowMe(); } } private void enableFollowMe() { getActivity().runOnUiThread(new Runnable() { @Override public void run() { visualizationView.getCamera().jumpToFrame(ROBOT_FRAME); followme.setChecked(true); } }); } private void disableFollowMe() { getActivity().runOnUiThread(new Runnable() { @Override public void run() { visualizationView.getCamera().setFrame(MAP_FRAME); followme.setChecked(false); } }); } }
138
1.6.
NodeListFragment.java
package org.aslab.tablet_application;
import import import import import import import import import import import import
java.util.ArrayList; java.util.Iterator; java.util.List; org.ros.node.NodeConfiguration; org.ros.node.NodeMainExecutor; meta_msgs.NodeInfo; android.app.Activity; android.app.ListFragment; android.os.Bundle; android.view.View; android.widget.ArrayAdapter; android.widget.ListView;
public class NodeListFragment extends ListFragment { public interface OnNodeSelectedListener{ public void onNodeSelected(NodeInfo node); } OnNodeSelectedListener mListener; public RosDataObserver mDataObserver; public NodeMainExecutor nodeMainExecutor; public NodeConfiguration nodeConfiguration; public NodeListFragment(){ } @Override public void onAttach(Activity activity){ super.onAttach(activity); try { mListener = (OnNodeSelectedListener) activity; } catch (ClassCastException e) { throw new ClassCastException(activity.toString()+" must implement OnNodeSelectedListener"); } this.nodeConfiguration = ((RosActivityRobot)activity).getNodeConfiguration(); this.nodeMainExecutor = ((RosActivityRobot)activity).getNodeMainExecutor(); } @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); mDataObserver = new RosDataObserver(); nodeMainExecutor.execute(mDataObserver, nodeConfiguration); String[] values = new String[]{"Refresh"}; ArrayAdapter<String> adapter = new ArrayAdapter<String>(getActivity(), android.R.layout.simple_list_item_1, values); setListAdapter(adapter); } @Override public void onActivityCreated(Bundle savedInstanceState) {
139
super.onActivityCreated(savedInstanceState); } @Override public void onListItemClick(ListView l, View v, int position, long id) { Refresh(); String item = (String) getListAdapter().getItem(position); if (item != "Refresh") { List<NodeInfo> nodeList = mDataObserver.getNodeList(); for(Iterator<NodeInfo> i = nodeList.iterator(); i.hasNext();){ NodeInfo j = i.next(); if( (j.getNodeName()).equals(item)){ mListener = (OnNodeSelectedListener) getActivity(); mListener.onNodeSelected(j); return; } } } } public void Refresh() { List<NodeInfo> nodeList = mDataObserver.getNodeList(); if(nodeList != null){ String[] values = new String[nodeList.size()]; int n = 0; for(Iterator<NodeInfo> i = nodeList.iterator(); i.hasNext();){ values[n] = i.next().getNodeName(); n++; } ArrayAdapter<String> adapter = new ArrayAdapter<String>(getActivity(), android.R.layout.simple_list_item_1, values); setListAdapter(adapter); } } }
140
1.7.
RosDataObserver.java
package org.aslab.tablet_application; import java.util.ArrayList; import java.util.List; import meta_msgs.NodeInfo; import import import import import import org.ros.message.MessageListener; org.ros.namespace.GraphName; org.ros.node.AbstractNodeMain; org.ros.node.ConnectedNode; org.ros.node.topic.Subscriber; android.app.ListFragment;
public class RosDataObserver extends AbstractNodeMain { public ArrayList<NodeInfo> nodeList; public RosDataObserver(){ } @Override public GraphName getDefaultNodeName() { return GraphName.of("tablet/data_observer"); } @Override public void onStart(ConnectedNode connectedNode) { Subscriber<meta_msgs.NodesList> subscriber2 = connectedNode.newSubscriber("nodes_list", meta_msgs.NodesList._TYPE); subscriber2.addMessageListener(new MessageListener<meta_msgs.NodesList>() { @Override public void onNewMessage(meta_msgs.NodesList message) { nodeList = (ArrayList<NodeInfo>) message.getNodes(); } }); } public ArrayList<NodeInfo> getNodeList(){ return nodeList; } }
141
1.8.
VirtualJoystickView.java
/* * Copyright (C) 2011 Google Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); you may not * use this file except in compliance with the License. You may obtain a copy of * the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the * License for the specific language governing permissions and limitations under * the License. */ package org.ros.android.view; import import import import import import import import import import import import import import import import import import import import import import import import import android.content.Context; android.graphics.Point; android.util.AttributeSet; android.util.Log; android.view.Gravity; android.view.LayoutInflater; android.view.MotionEvent; android.view.animation.Animation; android.view.animation.Animation.AnimationListener; android.view.animation.AnimationSet; android.view.animation.LinearInterpolator; android.view.animation.RotateAnimation; android.view.animation.ScaleAnimation; android.widget.ImageView; android.widget.RelativeLayout; android.widget.TextView; android.widget.Toast; org.ros.android.android_honeycomb_mr2.R; org.ros.message.MessageListener; org.ros.namespace.GraphName; org.ros.node.ConnectedNode; org.ros.node.Node; org.ros.node.NodeMain; org.ros.node.topic.Publisher; org.ros.node.topic.Subscriber;
import java.util.Timer; import java.util.TimerTask; /** * VirtualJoystickView creates a virtual joystick view that publishes velocity * as (geometry_msgs.Twist) messages. The current version contains the following * features: snap to axes, turn in place, and resume previous velocity. * * @author munjaldesai@google.com (Munjal Desai) */ public class VirtualJoystickView extends RelativeLayout implements AnimationListener,
142
MessageListener<nav_msgs.Odometry>, NodeMain { /** * BOX_TO_CIRCLE_RATIO The dimensions of the square box that contains the * circle, rings, etc are 300x300. The circles, rings, etc have a diameter of * 220. The ratio of the box to the circles is 300/220 = 1.363636. This ratio * stays the same regardless of the size of the virtual joystick. */ private static final float BOX_TO_CIRCLE_RATIO = 1.363636f; /** * MAGNET_THETA The number of degrees before and after the major axes (0, 90, * 180, and 270) where the orientation is automatically adjusted to 0, 90, * 180, or 270. For example, if the contactTheta is 85 degrees and * MAGNET_THETA is 10, the contactTheta will be changed to 90. */ private float magnetTheta = 10.0f; /** * ORIENTATION_TACK_FADE_RANGE The range in degrees around the current * orientation where the {@link #orientationWidget}s will be visible. */ private static final float ORIENTATION_TACK_FADE_RANGE = 40.0f; /** * TURN_IN_PLACE_CONFIRMATION_DELAY Time (in milliseconds) to wait before * visually changing to turn-in-place mode. */ private static final long TURN_IN_PLACE_CONFIRMATION_DELAY = 200L; /** * FLOAT_EPSILON Used for comparing float values. */ private static final float FLOAT_EPSILON = 0.001f; /** * THUMB_DIVET_RADIUS The radius of the {@link #thumbDivet}. This is also the * distance threshold around the {@link #contactUpLocation} that triggers the * previous-velocity-mode {@link #previousVelocityMode}. This radius is also * the same for the {@link #lastVelocityDivet}. */ private static final float THUMB_DIVET_RADIUS = 16.5f; /** * POST_LOCK_MAGNET_THETA Replaces {@link #magnetTheta} once the contact has * been magnetized/snapped around 90/270. */ private static final float POST_LOCK_MAGNET_THETA = 20.0f; private static final int INVALID_POINTER_ID = -1; private Publisher<geometry_msgs.Twist> publisher; /** * mainLayout The parent layout that contains all the elements of the virtual * joystick. */ private RelativeLayout mainLayout; /** * intensity The intensity circle that is used to show the current magnitude. */ private ImageView intensity; /** * thumbDivet The divet that is underneath the users thumb. When there is no * contact it moves to the center (over the center divet). An arrow inside it * is used to indicate the orientation. */ private ImageView thumbDivet;
143
/** * lastVelocityDivet The divet that shows the location of last contact. If a * contact is placed within ({@link #THUMB_DIVET_RADIUS}) to this, the * {@link #previousVelocityMode} is triggered. */ private ImageView lastVelocityDivet; /** * orientationWidget 4 long tacks on the major axes and 20 small tacks off of * the major axes at 15 degree increments. These fade in and fade out to * collectively indicate the current orientation. */ private ImageView[] orientationWidget; /** * magnitudeIndicator Shows the current linear velocity as a percent value. * This TextView will be on the opposite side of the contact to ensure that is * it visible most of the time. The font size and distance from the center of * the widget are automatically computed based on the size of parent * container. */ private TextView magnitudeText; /** contactTheta The current orientation of the virtual joystick in degrees. */ private float contactTheta; /** * normalizedMagnitude This is the distance between the center divet and the * point of contact normalized between 0 and 1. The linear velocity is based * on this. */ private float normalizedMagnitude; /** * contactRadius This is the distance between the center of the widget and the * point of contact normalized between 0 and 1. This is mostly used for * animation/display calculations. * * TODO(munjaldesai): Omnigraffle this for better documentation. */ private float contactRadius; /** * deadZoneRatio ... * * TODO(munjaldesai): Write a simple explanation for this. Currently not easy * to immediately comprehend its meaning. * * TODO(munjaldesai): Omnigraffle this for better documentation. */ private float deadZoneRatio = Float.NaN; /** * joystickRadius The center coordinates of the parent layout holding all the * elements of the virtual joystick. The coordinates are relative to the * immediate parent (mainLayout). Since the parent must be a square centerX = * centerY = radius. */ private float joystickRadius = Float.NaN; /** * parentSize The length (width==height ideally) of a side of the parent * container that holds the virtual joystick. */ private float parentSize = Float.NaN; /** * normalizingMultiplier Used to convert any distance from pixels to a
144
* normalized value between 0 and 1. 0 is the center of widget and 1 is the * normalized distance to the {@link #outerRing} from the center of the * widget. */ private float normalizingMultiplier; /** * currentRotationRange The (15 degree) green slice/arc used to indicate * turn-in-place behavior. */ private ImageView currentRotationRange; /** * previousRotationRange The (30 degree) green slice/arc used to indicate * turn-in-place behavior. */ private ImageView previousRotationRange; /** * turnInPlaceMode True when the virtual joystick is in turn-in-place mode. * False otherwise. */ private volatile boolean turnInPlaceMode; /** * turnInPlaceStartTheta The orientation of the robot when the turn-in-place * mode is initiated. */ private float turnInPlaceStartTheta = Float.NaN; /** * rightTurnOffset The rotation offset in degrees applied to * {@link #currentRotationRange} and {@link #previousRotationRange} when the * robot is turning clockwise (right) in turn-in-place mode. */ private float rightTurnOffset; /** * currentOrientation The orientation of the robot in degrees. */ private volatile float currentOrientation; /** * pointerId Used to keep track of the contact that initiated the interaction * with the virtual joystick. All other contacts are ignored. */ private int pointerId = INVALID_POINTER_ID; /** * contactUpLocation The location of the primary contact when it is lifted off * of the screen. */ private Point contactUpLocation; /** * previousVelocityMode True when the new contact position is within */ private boolean previousVelocityMode; /** * magnetizedXAxis True when the contact has been snapped to the x-axis, false * otherwise. */ private boolean magnetizedXAxis; /** * {@code true} if the joystick should publish linear velocities along the Y * axis instead of angular velocities along the Z axis, {@code false} * otherwise. */
145
private boolean holonomic; /** * Velocity commands are published when this is true. Not published otherwise. * This is to prevent spamming velocity commands. */ private volatile boolean publishVelocity; /** * Used to publish velocity commands at a specific rate. */ private Timer publisherTimer; private geometry_msgs.Twist currentVelocityCommand; public VirtualJoystickView(Context context) { super(context); initVirtualJoystick(context); } public VirtualJoystickView(Context context, AttributeSet attrs) { super(context, attrs); initVirtualJoystick(context); } public VirtualJoystickView(Context context, AttributeSet attrs, int defStyle) { super(context, attrs, defStyle); } /** * @param enabled {@code true} if this joystick should publish linear velocities * along the Y axis instead of angular velocities along the Z axis, * {@code false} otherwise * */ public void setHolonomic(boolean enabled) { holonomic = enabled; } @Override public void onAnimationEnd(Animation animation) { contactRadius = 0f; normalizedMagnitude = 0f; updateMagnitudeText(); } @Override public void onAnimationRepeat(Animation animation) { } @Override public void onAnimationStart(Animation animation) { } @Override public void onNewMessage(final nav_msgs.Odometry message) { double heading; // For some reason the values of z and y seem to be interchanged. If they // are not swapped then heading is always incorrect. double w = message.getPose().getPose().getOrientation().getW(); double x = message.getPose().getPose().getOrientation().getX(); double y = message.getPose().getPose().getOrientation().getZ();
146
double z = message.getPose().getPose().getOrientation().getY(); heading = Math.atan2(2 * y * w - 2 * x * z, x * x - y * y - z * z + w * w) * 180 / Math.PI; // Negating the orientation to make the math for rotation in // turn-in-place mode easy. Since the actual heading is irrelevant it does // no harm. currentOrientation = (float) -heading; // Only update the orientation images if the turn-in-place mode is active. if (turnInPlaceMode) { post(new Runnable() { @Override public void run() { updateTurnInPlaceRotation(); } }); postInvalidate(); } } @Override public boolean onTouchEvent(MotionEvent event) { final int action = event.getAction(); switch (action & MotionEvent.ACTION_MASK) { case MotionEvent.ACTION_MOVE: { // If the primary contact point is no longer on the screen then ignore // the event. if (pointerId != INVALID_POINTER_ID) { // If the virtual joystick is in resume-previous-velocity mode. if (previousVelocityMode) { // And the current contact is close to the contact location prior to // ContactUp. if (inLastContactRange(event.getX(event.getActionIndex()), event.getY(event.getActionIndex()))) { // Then use the previous velocity. onContactMove(contactUpLocation.x + joystickRadius, contactUpLocation.y + joystickRadius); } // Since the current contact is not close to the prior location. else { // Exit the resume-previous-velocity mode. previousVelocityMode = false; } } // Since the resume-previous-velocity mode is not active generate // velocities based on current contact position. else { onContactMove(event.getX(event.findPointerIndex(pointerId)), event.getY(event.findPointerIndex(pointerId))); } } break; } case MotionEvent.ACTION_DOWN: { // Get the coordinates of the pointer that is initiating the // interaction. pointerId = event.getPointerId(event.getActionIndex()); onContactDown(); // If the current contact is close to the location of the contact prior // to contactUp.
147
if (inLastContactRange(event.getX(event.getActionIndex()), event.getY(event.getActionIndex()))) { // Trigger resume-previous-velocity mode. previousVelocityMode = true; // The animation calculations/operations are performed in // onContactMove(). If this is not called and the users finger stays // perfectly still after the down event, no operation is performed. // Calling onContactMove avoids this. onContactMove(contactUpLocation.x + joystickRadius, contactUpLocation.y + joystickRadius); } else { onContactMove(event.getX(event.getActionIndex()), event.getY(event.getActionIndex())); } break; } case case // if MotionEvent.ACTION_POINTER_UP: MotionEvent.ACTION_UP: { Check if the contact that initiated the interaction is up. ((action & MotionEvent.ACTION_POINTER_ID_MASK) >> MotionEvent.ACTION_POINTER_ID_SHIFT == pointerId) { onContactUp();
} break; } } return true; } /** * Allows the user the option to turn on the auto-snap feature. */ public void EnableSnapping() { magnetTheta = 10; } /** * Allows the user the option to turn off the auto-snap feature. */ public void DisableSnapping() { magnetTheta = 1; } /** * Initialize the fields with values that can only be determined once the * layout for the views has been determined. */ @Override protected void onLayout(boolean changed, int l, int t, int r, int b) { // Call the parents onLayout to setup the views. super.onLayout(changed, l, t, r, b); // The parent container must be a square. A square container simplifies the // code. A non-square container does not provide any benefit over a // square. if (mainLayout.getWidth() != mainLayout.getHeight()) { // TODO(munjaldesai): Need to throw an exception/error. For now the // touch events will not be processed. this.setOnTouchListener(null); }
148
parentSize = mainLayout.getWidth(); if (parentSize < 200 || parentSize > 400) { // TODO: Need to throw an exception for attempting to create // a virtual joystick that is either too small or too big. For now the // touch events will be processed. this.setOnTouchListener(null); } // Calculate the center coordinates (radius) of parent container // (mainLayout). joystickRadius = mainLayout.getWidth() / 2; normalizingMultiplier = BOX_TO_CIRCLE_RATIO / (parentSize / 2); // Calculate the radius of the center divet as a normalize value. deadZoneRatio = THUMB_DIVET_RADIUS * normalizingMultiplier; // Determine the font size for the text view showing linear velocity. 8.3 % // of the overall size seems to work well. magnitudeText.setTextSize(parentSize / 12); } /** * Scale and rotate the intensity circle instantaneously. The key difference * between this method and {@link #animateIntensityCircle(float, long)} is * that this method does not attach an animation listener and the animation is * instantaneous. * * @param endScale The scale factor that must be attained at the end of the * animation. * / * private void animateIntensityCircle(float endScale) { AnimationSet intensityCircleAnimation = new AnimationSet(true); intensityCircleAnimation.setInterpolator(new LinearInterpolator()); intensityCircleAnimation.setFillAfter(true); RotateAnimation rotateAnim; rotateAnim = new RotateAnimation(contactTheta, contactTheta, joystickRadius, joystickRadius); rotateAnim.setInterpolator(new LinearInterpolator()); rotateAnim.setDuration(0); rotateAnim.setFillAfter(true); intensityCircleAnimation.addAnimation(rotateAnim); ScaleAnimation scaleAnim; scaleAnim = new ScaleAnimation(contactRadius, endScale, contactRadius, endScale, joystickRadius, joystickRadius); scaleAnim.setDuration(0); scaleAnim.setFillAfter(true); intensityCircleAnimation.addAnimation(scaleAnim); // Apply the animation. intensity.startAnimation(intensityCircleAnimation); } /** * Scale and rotate the intensity circle over the specified duration. Unlike * {@link #animateIntensityCircle(float)} this method registers an animation * listener. * * @param endScale The scale factor that must be attained at the end of the * animation. *
149
* @param duration The duration in milliseconds the animation should take. * */ private void animateIntensityCircle(float endScale, long duration) { AnimationSet intensityCircleAnimation = new AnimationSet(true); intensityCircleAnimation.setInterpolator(new LinearInterpolator()); intensityCircleAnimation.setFillAfter(true); // The listener is needed to set the magnitude text to 0 only after the // animation is over. intensityCircleAnimation.setAnimationListener(this); RotateAnimation rotateAnim; rotateAnim = new RotateAnimation(contactTheta, contactTheta, joystickRadius, joystickRadius); rotateAnim.setInterpolator(new LinearInterpolator()); rotateAnim.setDuration(duration); rotateAnim.setFillAfter(true); intensityCircleAnimation.addAnimation(rotateAnim); ScaleAnimation scaleAnim; scaleAnim = new ScaleAnimation(contactRadius, endScale, contactRadius, endScale, joystickRadius, joystickRadius); scaleAnim.setDuration(duration); scaleAnim.setFillAfter(true); intensityCircleAnimation.addAnimation(scaleAnim); // Apply the animation. intensity.startAnimation(intensityCircleAnimation); } /** * Fade in and fade out the {@link #orientationWidget}s. The widget best * aligned with the {@link #contactTheta} will be the brightest and the * successive ones within {@link #ORIENTATION_TACK_FADE_RANGE} the will be * faded out proportionally. The tacks out of that range will have alpha set * to 0. */ private void animateOrientationWidgets() { float deltaTheta; for (int i = 0; i < orientationWidget.length; i++) { deltaTheta = differenceBetweenAngles(i * 15, contactTheta); if (deltaTheta < ORIENTATION_TACK_FADE_RANGE) { orientationWidget[i].setAlpha(1.0f - deltaTheta / ORIENTATION_TACK_FADE_RANGE); } else { orientationWidget[i].setAlpha(0.0f); } } } /** * From http://actionsnippet.com/?p=1451. Calculates the difference between 2 * angles. The result is always the minimum difference between 2 angles (0< * result <= 360). * * @param angle0 One of 2 angles used to calculate difference. The order of * arguments does not matter. Must be in degrees. * @param angle1 * One of 2 angles used to calculate difference. The order of *
150
arguments does not matter. Must be in degrees. * * @return The difference between the 2 arguments in degrees. */ private float differenceBetweenAngles(float angle0, float angle1) { return Math.abs((angle0 + 180 - angle1) % 360 - 180); } /** * Sets {@link #turnInPlaceMode} to false indicating that the turn-in-place is * no longer active. It also changes the alpha values appropriately. */ private void endTurnInPlaceRotation() { turnInPlaceMode = false; currentRotationRange.setAlpha(0.0f); previousRotationRange.setAlpha(0.0f); intensity.setAlpha(1.0f); } /** * Sets up the visual elements of the virtual joystick. */ private void initVirtualJoystick(Context context) { // All the virtual joystick elements must be centered on the parent. setGravity(Gravity.CENTER); // Instantiate the elements from the layout XML file. LayoutInflater.from(context).inflate(R.layout.virtual_joystick, this, true); mainLayout = (RelativeLayout) findViewById(R.id.virtual_joystick_layout); magnitudeText = (TextView) findViewById(R.id.magnitude); intensity = (ImageView) findViewById(R.id.intensity); thumbDivet = (ImageView) findViewById(R.id.thumb_divet); orientationWidget = new ImageView[24]; orientationWidget[0] = (ImageView) findViewById(R.id.widget_0_degrees); orientationWidget[1] = (ImageView) findViewById(R.id.widget_15_degrees); orientationWidget[2] = (ImageView) findViewById(R.id.widget_30_degrees); orientationWidget[3] = (ImageView) findViewById(R.id.widget_45_degrees); orientationWidget[4] = (ImageView) findViewById(R.id.widget_60_degrees); orientationWidget[5] = (ImageView) findViewById(R.id.widget_75_degrees); orientationWidget[6] = (ImageView) findViewById(R.id.widget_90_degrees); orientationWidget[7] = (ImageView) findViewById(R.id.widget_105_degrees); orientationWidget[8] = (ImageView) findViewById(R.id.widget_120_degrees); orientationWidget[9] = (ImageView) findViewById(R.id.widget_135_degrees); orientationWidget[10] = (ImageView) findViewById(R.id.widget_150_degrees); orientationWidget[11] = (ImageView) findViewById(R.id.widget_165_degrees); orientationWidget[12] = (ImageView) findViewById(R.id.widget_180_degrees); orientationWidget[13] = (ImageView) findViewById(R.id.widget_195_degrees); orientationWidget[14] = (ImageView) findViewById(R.id.widget_210_degrees); orientationWidget[15] = (ImageView) findViewById(R.id.widget_225_degrees); orientationWidget[16] = (ImageView) findViewById(R.id.widget_240_degrees); orientationWidget[17] = (ImageView) findViewById(R.id.widget_255_degrees); orientationWidget[18] = (ImageView) findViewById(R.id.widget_270_degrees); orientationWidget[19] = (ImageView) findViewById(R.id.widget_285_degrees); orientationWidget[20] = (ImageView) findViewById(R.id.widget_300_degrees); orientationWidget[21] = (ImageView) findViewById(R.id.widget_315_degrees); orientationWidget[22] = (ImageView) findViewById(R.id.widget_330_degrees); orientationWidget[23] = (ImageView) findViewById(R.id.widget_345_degrees); // Initially hide all the widgets. for (ImageView tack : orientationWidget) { tack.setAlpha(0.0f); tack.setVisibility(INVISIBLE);
151
} // The value (radius) 40 is arbitrary, but small enough to work for the // smallest sized virtual joystick. Once the layout is set a value is // calculated based on the size of the virtual joystick. magnitudeText.setTranslationX((float) (40 * Math.cos((90 + contactTheta) * Math.PI / 180.0))); magnitudeText.setTranslationY((float) (40 * Math.sin((90 + contactTheta) * Math.PI / 180.0))); // Hide the intensity circle. animateIntensityCircle(0); // Initially the orientationWidgets should point to 0 degrees. contactTheta = 0; animateOrientationWidgets(); currentRotationRange = (ImageView) findViewById(R.id.top_angle_slice); previousRotationRange = (ImageView) findViewById(R.id.mid_angle_slice); // Hide the slices/arcs used during the turn-in-place mode. currentRotationRange.setAlpha(0.0f); previousRotationRange.setAlpha(0.0f); lastVelocityDivet = (ImageView) findViewById(R.id.previous_velocity_divet); contactUpLocation = new Point(0, 0); holonomic = false; for (ImageView tack : orientationWidget) { tack.setVisibility(INVISIBLE); } } /** * Update the virtual joystick to indicate a contact down has occurred. */ private void onContactDown() { // The divets should be completely opaque indicating // the virtual joystick is active. thumbDivet.setAlpha(1.0f); magnitudeText.setAlpha(1.0f); // Previous contact location need not be shown any more. lastVelocityDivet.setAlpha(0.0f); // Restore the orientation tacks. for (ImageView tack : orientationWidget) { tack.setVisibility(VISIBLE); } publishVelocity = true; } /** * Updates the virtual joystick layout based on the location of the contact. * Generates the velocity messages. Switches in and out of turn-in-place. * * @param x The x coordinates of the contact relative to the parent container. * * @param y The y coordinates of the contact relative to the parent container. * */ private void onContactMove(float x, float y) { // Get the coordinates of the contact relative to the center of the main // layout. float thumbDivetX = x - joystickRadius; float thumbDivetY = y - joystickRadius; // Convert the coordinates from Cartesian to Polar.
152
contactTheta = (float) (Math.atan2(thumbDivetY, thumbDivetX) * 180 / Math.PI + 90); contactRadius = (float) Math.sqrt(thumbDivetX * thumbDivetX + thumbDivetY * thumbDivetY) * normalizingMultiplier; // Calculate the distance (0 to 1) from the center divet to the contact // point. normalizedMagnitude = (contactRadius - deadZoneRatio) / (1 - deadZoneRatio); // Perform bounds checking. if (contactRadius >= 1f) { // Since the contact is outside the outer ring, reset the coordinate for // the thumb divet to the on the outer ring. thumbDivetX /= contactRadius; thumbDivetY /= contactRadius; // The magnitude should not exceed 1. normalizedMagnitude = 1f; contactRadius = 1f; } else if (contactRadius < deadZoneRatio) { // Since the contact is inside the dead zone snap the thumb divet to the // dead zone. It should stay there till the contact gets outside the // deadzone area. thumbDivetX = 0; thumbDivetY = 0; // Prevent normalizedMagnitude going negative inside the deadzone. normalizedMagnitude = 0f; } // Magnetize! // If the contact is not snapped to the x axis. if (!magnetizedXAxis) { // Check if the contact should be snapped to either axis. if ((contactTheta + 360) % 90 < magnetTheta) { // If the current angle is within MAGNET_THETA degrees + 0, 90, 180, or // 270 then subtract the additional degrees so that the current theta is // 0, 90, 180, or 270. contactTheta -= ((contactTheta + 360) % 90); } else if ((contactTheta + 360) % 90 > (90 - magnetTheta)) { // If the current angle is within MAGNET_THETA degrees - 0, 90, 180, or // 270 then add the additional degrees so that the current theta is 0, // 90, 180, or 270. contactTheta += (90 - ((contactTheta + 360) % 90)); } // Indicate that the contact has been snapped to the x-axis. if (floatCompare(contactTheta, 90) || floatCompare(contactTheta, 270)) { magnetizedXAxis = true; } } else { // Use a wider range to keep the contact snapped in. if (differenceBetweenAngles((contactTheta + 360) % 360, 90) < POST_LOCK_MAGNET_THETA) { contactTheta = 90; } else if (differenceBetweenAngles((contactTheta + 360) % 360, 270) < POST_LOCK_MAGNET_THETA) { contactTheta = 270; } // Indicate that the contact is not snapped to the x-axis. else { magnetizedXAxis = false; }
153
} // Update the size and location (scale and rotation) of various elements. animateIntensityCircle(contactRadius); animateOrientationWidgets(); updateThumbDivet(thumbDivetX, thumbDivetY); updateMagnitudeText(); // Publish the velocities. if (holonomic) { publishVelocity(normalizedMagnitude * Math.cos(contactTheta * Math.PI / 180.0), normalizedMagnitude * Math.sin(contactTheta * Math.PI / 180.0), 0); } else { publishVelocity(normalizedMagnitude * Math.cos(contactTheta * Math.PI / 180.0), 0, normalizedMagnitude * Math.sin(contactTheta * Math.PI / 180.0)); } // Check if the turn-in-place mode needs to be activated/deactivated. updateTurnInPlaceMode(); } /** * Enable/Disable turn-in-place mode. */ private void updateTurnInPlaceMode() { if (!turnInPlaceMode) { if (floatCompare(contactTheta, 270)) { // If the user is turning left and the turn-in-place mode is not active // then activate it for a left turn. turnInPlaceMode = true; rightTurnOffset = 0; } else if (floatCompare(contactTheta, 90)) { // If the user is turning right and the turn-in-place mode is not active // then activate it for a right turn. turnInPlaceMode = true; rightTurnOffset = 15; } else { // Nothing to do while not in turn-in-place mode and not at 270/90. return; } // Initiate the turn-in-place mode but wait some time before changing the // images. This is to avoid the users getting seizures because of the // quick changes every time they cross 270 or 90. initiateTurnInPlace(); // Start a timer and if the user is still turning in place when the timer // is up, then visually indicate entering turn-in-place mode. new Timer().schedule(new TimerTask() { @Override public void run() { post(new Runnable() { @Override public void run() { if (turnInPlaceMode) { currentRotationRange.setAlpha(1.0f); previousRotationRange.setAlpha(1.0f); intensity.setAlpha(0.2f); } } });
154
postInvalidate(); } }, TURN_IN_PLACE_CONFIRMATION_DELAY); } else if (!(floatCompare(contactTheta, 270) || floatCompare(contactTheta, 90))) { // If the user was in turn-in-place mode and is now no longer on the x // axis, then exit turn-in-place mode. endTurnInPlaceRotation(); } } /** * The divets and the ring are made transparent to reflect that the virtual * joystick is no longer active. The intensity circle is slowly scaled to 0. */ private void onContactUp() { // TODO(munjaldesai): The 1000 should eventually be replaced with a number // that reflects the physical characteristics of the motor controller along // with the latency associated with the connection. animateIntensityCircle(0, (long) (normalizedMagnitude * 1000)); magnitudeText.setAlpha(0.4f); // Place the lastVelocityDivet at the location of the last known contact. lastVelocityDivet.setTranslationX(thumbDivet.getTranslationX()); lastVelocityDivet.setTranslationY(thumbDivet.getTranslationY()); lastVelocityDivet.setAlpha(0.4f); contactUpLocation.x = (int) (thumbDivet.getTranslationX()); contactUpLocation.y = (int) (thumbDivet.getTranslationY()); // Move the thumb divet back to the center. updateThumbDivet(0, 0); // Reset the pointer id. pointerId = INVALID_POINTER_ID; // The robot should stop moving. publishVelocity(0, 0, 0); // Stop publishing the velocity since the contact is no longer on the // screen. publishVelocity = false; // Publish one last message to make sure the robot stops. if(currentVelocityCommand != null){ publisher.publish(currentVelocityCommand); } // Turn-in-place should not be active anymore. endTurnInPlaceRotation(); // Hide the orientation tacks. for (ImageView tack : orientationWidget) { tack.setVisibility(INVISIBLE); } } /** * Publish the velocity as a ROS Twist message. * * @param linearVelocityX The normalized linear velocity (-1 to 1). * * @param angularVelocityZ The normalized angular velocity (-1 to 1). * */ private void publishVelocity(double linearVelocityX, double linearVelocityY, double angularVelocityZ) { if (currentVelocityCommand == null){
155
Toast.makeText(getContext(), "Virtual Joystick connection could not be initialized", Toast.LENGTH_SHORT).show(); }else{ currentVelocityCommand.getLinear().setX(linearVelocityX); currentVelocityCommand.getLinear().setY(-linearVelocityY); currentVelocityCommand.getLinear().setZ(0); currentVelocityCommand.getAngular().setX(0); currentVelocityCommand.getAngular().setY(0); currentVelocityCommand.getAngular().setZ(-angularVelocityZ); } } /** * Called each time turn-in-place mode is initiated. */ private void initiateTurnInPlace() { // Record the orientation when the turn-in-place was initiated. turnInPlaceStartTheta = (currentOrientation + 360) % 360; RotateAnimation rotateAnim; rotateAnim = new RotateAnimation(rightTurnOffset, rightTurnOffset, joystickRadius, joystickRadius); rotateAnim.setInterpolator(new LinearInterpolator()); rotateAnim.setDuration(0); rotateAnim.setFillAfter(true); currentRotationRange.startAnimation(rotateAnim); rotateAnim = new RotateAnimation(15, 15, joystickRadius, joystickRadius); rotateAnim.setInterpolator(new LinearInterpolator()); rotateAnim.setDuration(0); rotateAnim.setFillAfter(true); previousRotationRange.startAnimation(rotateAnim); } /** * Update the linear velocity text view. */ private void updateMagnitudeText() { // Dont update when the user is turning in place. if (!turnInPlaceMode) { magnitudeText.setText(String.valueOf((int) (normalizedMagnitude * 100)) + " %"); magnitudeText.setTranslationX((float) (parentSize / 4 * Math.cos((90 + contactTheta) * Math.PI / 180.0))); magnitudeText.setTranslationY((float) (parentSize / 4 * Math.sin((90 + contactTheta) * Math.PI / 180.0))); } } /** * Based on the difference between the current orientation and the orientation * when the turn-in-place mode was initiated, update the visuals. */ private void updateTurnInPlaceRotation() { final float currentTheta = (currentOrientation + 360) % 360; float offsetTheta; // Calculate the difference between the orientations. offsetTheta = (turnInPlaceStartTheta - currentTheta + 360) % 360; offsetTheta = 360 - offsetTheta;
156
// Show the current rotation amount. magnitudeText.setText(String.valueOf((int) offsetTheta)); // Calculate theta in increments of 15 degrees. (0-14 => 0, 15-29=>15, etc). offsetTheta = (int) (offsetTheta - (offsetTheta % 15)); // Rotate the 2 arcs based on the offset in orientation. RotateAnimation rotateAnim; rotateAnim = new RotateAnimation(offsetTheta + rightTurnOffset, offsetTheta + rightTurnOffset, joystickRadius, joystickRadius); rotateAnim.setInterpolator(new LinearInterpolator()); rotateAnim.setDuration(0); rotateAnim.setFillAfter(true); currentRotationRange.startAnimation(rotateAnim); rotateAnim = new RotateAnimation(offsetTheta + 15, offsetTheta + 15, joystickRadius, joystickRadius); rotateAnim.setInterpolator(new LinearInterpolator()); rotateAnim.setDuration(0); rotateAnim.setFillAfter(true); previousRotationRange.startAnimation(rotateAnim); } /** * Moves the {@link #thumbDivet} to the specified coordinates (under the * contact) and also orients it so that is facing the direction opposite to * the center of the {@link #mainLayout}. * * @param x The x coordinate relative to the center of the {@link #mainLayout} * * @param y The Y coordinate relative to the center of the {@link #mainLayout} * */ private void updateThumbDivet(float x, float y) { // Offset the specified coordinates to ensure that the center of the thumb // divet is under the thumb. thumbDivet.setTranslationX(-THUMB_DIVET_RADIUS); thumbDivet.setTranslationY(-THUMB_DIVET_RADIUS); // Set the orientation. This must be done before translation. thumbDivet.setRotation(contactTheta); thumbDivet.setTranslationX(x); thumbDivet.setTranslationY(y); } /** * Comparing 2 float values. * * @param v1 * @param v2 * @return True if v1 and v2 and within {@value #FLOAT_EPSILON} of each other. False otherwise. * */ private boolean floatCompare(float v1, float v2) { if (Math.abs(v1 - v2) < FLOAT_EPSILON) { return true; } else { return false; } }
157
private boolean inLastContactRange(float x, float y) { if (Math.sqrt((x - contactUpLocation.x - joystickRadius) * (x - contactUpLocation.x - joystickRadius) + (y - contactUpLocation.y joystickRadius) * (y - contactUpLocation.y - joystickRadius)) < THUMB_DIVET_RADIUS) { return true; } return false; } @Override public GraphName getDefaultNodeName() { return GraphName.of("android_honeycomb_mr2/virtual_joystick_view"); } @Override public void onStart(ConnectedNode connectedNode) { publisher = connectedNode.newPublisher("~cmd_vel", geometry_msgs.Twist._TYPE); currentVelocityCommand = publisher.newMessage(); Subscriber<nav_msgs.Odometry> subscriber = connectedNode.newSubscriber("odom", nav_msgs.Odometry._TYPE); subscriber.addMessageListener(this); publisherTimer = new Timer(); publisherTimer.schedule(new TimerTask() { @Override public void run() { if (publishVelocity) { if(currentVelocityCommand != null){ publisher.publish(currentVelocityCommand); } } } }, 0, 80); } @Override public void onShutdown(Node node) { } @Override public void onShutdownComplete(Node node) { publisherTimer.cancel(); publisherTimer.purge(); } @Override public void onError(Node node, Throwable throwable) { } }
158
FECHA Y FIRMA
FECHA : 15 Octubre 2012 Madrid
FIRMA. Francisco Javier Mata Sanz


Aslab D 2012 012

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Aslab D 2012 012

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDAD POLITCNICA DE MADRID

DEPARTAMENTO DE AUTOMTICA INGENIERA ELECTRNICA

Divisin de Ingeniera de Sistemas y Automtica (DISAM)

ARI Android Robot Interface

Android Robot Interface

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

El que ha comenzado bien, est a la mitad de la obra. Q UINTO H ORACIO F LACO

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

D OCUMENTO I. M EMORIA l NDICE

III. Cdigo fuente

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

D OCUMENTO I. M EMORIA l NDICE

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

D OCUMENTO I. M EMORIA l NDICE

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

D OCUMENTO I. M EMORIA l NDICE DE FIGURAS

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

Autonomous Systems Laboratory, ASLab

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

Descripcin funcional del robot

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

Captulo 2 ESTADO DEL ARTE

I. M EMORIA l 2. ESTADO DEL ARTE

I. M EMORIA l 2. ESTADO DEL ARTE

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

I. M EMORIA l 2. ESTADO DEL ARTE

Figura 6. Android 2.0 Eclair

I. M EMORIA l 2. ESTADO DEL ARTE

Figura 8. Android 2.3 Gingerbread

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

I. M EMORIA l 2. ESTADO DEL ARTE

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

I. M EMORIA l 2. ESTADO DEL ARTE

I. M EMORIA l 2. ESTADO DEL ARTE

Parmetros de servidor. Sistemas de prueba.

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

I. M EMORIA l 2. ESTADO DEL ARTE

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

I. M EMORIA l 2. ESTADO DEL ARTE

Sistemas distribuidos de componentes

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

I. M EMORIA l 2. ESTADO DEL ARTE

Propiedades de los sistemas distribuidos

I. M EMORIA l 2. ESTADO DEL ARTE

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

Captulo 3 ENTORNO DE DESARROLLO

I. M EMORIA l 3. ENTORNO DE DESARROLLO

I. M EMORIA l 3. ENTORNO DE DESARROLLO

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

I. M EMORIA l 3. ENTORNO DE DESARROLLO

Plataforma de desarrollo Eclipse

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

I. M EMORIA l 3. ENTORNO DE DESARROLLO

ANDROID ROBOT INTERFACE Francisco Javier Mata Sanz

Captulo 4 ARQUITECTURA DE SISTEMA

Arquitectura del sistema Higgs