documento de proyecto de grado arquitectura web para
TRANSCRIPT
Documento de Proyecto de Grado
Arquitectura Web para Control de Robots Lego Mindstorms EV3
Samuel Baquero Merchán
Profesor Asesor: Mario Fernando De la Rosa Rosero
Departamento de Ingeniería de Sistemas y Computación Universidad de los Andes
Junio de 2019
2
Contenido
0 Resumen ................................................................................................................ 4
1 Introducción ............................................................................................................ 5
2 Descripción General ............................................................................................... 7
2.1 Objetivos .................................................................................................. 7
2.2 Antecedentes ........................................................................................... 7
2.3 Identificación del problema y de su importancia ...................................... 9
3 Diseño y especificaciones .................................................................................... 10
3.1 Definición del problema.......................................................................... 10
3.2 Especificaciones .................................................................................... 10
3.3 Restricciones .......................................................................................... 11
4 Desarrollo del diseño ............................................................................................ 13
4.1 Alternativas de diseño ............................................................................ 19
5 Implementación de la solución ............................................................................. 21
5.1 Descripción de la implementación ......................................................... 28
5.1 Resultados esperados ........................................................................... 29
6 Validación ............................................................................................................. 31
6.1 Interfaz Cliente Web ............................................................................... 31
6.2 Métodos ................................................................................................. 33
6.3 Validación de resultados ........................................................................ 34
7 Conclusiones ........................................................................................................ 37
7.1 Discusión ................................................................................................ 37
7.2 Trabajo futuro ......................................................................................... 37
8 Bibliografía ............................................................................................................ 39
9 Anexos .................................................................................................................. 40
Anexo A. Instalación de la arquitectura ............................................................. 40
Anexo B. Instalación del servidor NodeJS ........................................................ 42
Anexo C. Conexión del Robot LegoMindstorms EV3 utilizando Bluetooth ....... 43
3
Tabla de Figuras
Ilustración 1 Diagrama de Componentes - Servidor Java ................................................................ 13
Ilustración 2 Diagrama de Clases UML - Servidor Java ................................................................... 14
Ilustración 3 Diagrama de Despliegue – Servidor y Cliente .............................................................. 18
Ilustración 4 Diagrama de componentes de la solución – Servidor Java ......................................... 21
Ilustración 5 Diagrama de clases de la solución -Servidor Java ....................................................... 22
Ilustración 6 Diagrama de Despliegue de la Solución – Servidor y Cliente ...................................... 23
Ilustración 7 EV3 Vista frontal ........................................................................................................... 24
Ilustración 8 EV3 Vista superior ........................................................................................................ 25
Ilustración 9 EV3 Vista lateral izquierda ............................................................................................ 25
Ilustración 10 EV3 Vista trasera ........................................................................................................ 26
Ilustración 11 EV3 Vista lateral derecha ........................................................................................... 26
Ilustración 12 EV3 Vista inferior ........................................................................................................ 27
Ilustración 13 Cliente - consola de comandos .................................................................................. 31
Ilustración 14 Cliente – Contexto ...................................................................................................... 32
Ilustración 15 Cliente – Consola ........................................................................................................ 32
Ilustración 16 Cliente - Simulador 2D ................................................................................................ 33
Ilustración 17 Cliente - Sensores ...................................................................................................... 33
Ilustración 18 Resultados de pruebas de “Lighthouse” ..................................................................... 35
Ilustración 19 Métrica de “Lighthouse” .............................................................................................. 36
4
0 RESUMEN
Este proyecto busca hacer disponible un robot de la familia Lego Mindstorms EV3 a través de la Web a múltiples usuarios. El aprendizaje y trabajo en robótica puede verse afectado por el acceso limitado a los robots, por esto, se ha decidido construir una arquitectura web que facilite el acceso a una versión virtual del robot móvil a través de un simulador y desde cualquier navegador web conectado a internet. Adicionalmente, se busca una integración del robot real con ruedas que permita ejecutar las mismas secuencias de comandos disponibles en el simulador.
Al realizar una arquitectura web se cubrieron varios puntos importantes para este desarrollo, la posibilidad de trabajar con grupos grandes de personas y un único robot Mindstorms EV3, entre 6 y 20 personas; el acceso a la herramienta desde cualquier parte incluso si no se tiene un robot físico real; la oportunidad de modificar la plataforma para futuros desarrollos como por ejemplo subirla a un servicio Cloud.
El proyecto de arquitectura cumple con los estándares para una arquitectura web en cuanto a atributos de calidad y la ejecución de comandos tanto en un ambiente virtual como con un robot físico Mindstorms EV3 con ruedas conectado a través de bluetooth. Se realizaron pruebas satisfactorias de la arquitectura Web de su ambiente simulado y de la conexión con el robot físico.
5
1 INTRODUCCIÓN
En las últimas dos décadas el crecimiento de la robótica aplicada y la programación en el área de enseñanza se ha extendido desde las ingenierías hasta los colegios, creando ambientes de programación, robótica e incluso enseñanza de ciencias y humanidades a través de tecnologías; los rangos de edades de las personas varían desde la primera infancia hasta últimos años de colegio.
El objetivo general de la enseñanza a través de robots ha sido aumentar la visibilidad de las ingenierías en los jóvenes y niños, mostrar la importancia de estos estudios y reducir los estigmas relacionados con el nivel de matemáticas y materias afines que exige la ingeniería. Los estudios han revolucionado la interacción hombre máquina desarrollando modelos de programación orientada a bloques que simplifican y reducen la curva de aprendizaje de la robótica llevada a tecnologías móviles para celulares y tabletas por los mismos distribuidores de los robots para cubrir la mayor cantidad posible de usuarios.
Las clases enfocadas a robótica aún tienen una percepción de dificultad no solo en temas de currículum sino también en cuanto a implementación, organización y adquisición de los robots; bajo esta premisa se busca que los profesores puedan acceder a una plataforma flexible que les permita trabajar con los recursos que tengan a la mano y en sus laboratorios (computadores, redes LAN, dispositivos móviles, robots), y que sobre cada uno de estos componentes se comporte de manera similar, provea los mismos servicios y tenga las mismas funcionalidades; así, tanto profesores como alumnos solo tiene que aprender a usar 1 plataforma y ya pueden acceder a ella desde su celular, su computador o cualquier otro dispositivo con el que deseen trabajar.
Los robots de LEGO® han protagonizado innumerables trabajos en el área de aprendizaje a través de robots, debido a que los estudiantes pueden armar, crear y modificar su propio robot se han introducido en las aulas de clases de colegios y en múltiples estudios sobre interacción humano-máquina. Por esto, son buenos candidatos para realizar proyectos con jóvenes y niños sin conocimiento previo en programación o robótica; además de proveer interfaces de comunicación para programadores de diferentes lenguajes, estos robots permiten la ejecución remota de programas y una comunicación directa con cualquier sistema que se conecte a ellos.
Con base en lo anterior, se construyó el proyecto de extensión de la arquitectura web para el laboratorio remoto de la Universidad de los Andes que busca expandir los servicios ya existentes y exponer nuevas funcionalidades para la plataforma que permitan a los estudiantes futuros el uso del laboratorio de manera remota y a los programadores exponer nuevas funcionalidades de manera sencilla.
Un laboratorio de robótica remoto permite extender el alcance de los métodos clásicos de enseñanza de la robótica y permite a los estudiantes o investigadores interactuar con los robots, ya sea para ejecutar sus propios programas o para correr rutinas y simulaciones con la facilidad de realizarlas desde cualquier dispositivo con conexión a red, no necesariamente Internet, en el que se pueda instalar alguna de las aplicaciones de usuario final o desde un navegador web.
El usuario debe poder generar simulaciones en el ambiente web, visualizarlas y luego ejecutarlas en el ambiente real del laboratorio; adicionalmente, el usuario podrá ver y utilizar los sensores del robot dentro de las rutinas creadas para el simulador. El simulador debe soportar más de un usuario virtual simultáneo y uno solo trabajando en el ambiente real.
Manejar tecnologías de punta que estén lejos de volverse obsoletas permite a futuros programadores modificar y renovar las arquitecturas utilizando las librerías y componentes del momento con la menor cantidad de cambios de versiones.
Se busca complementar y actualizar el trabajo del laboratorio remoto, con la posibilidad de crear simulaciones previas a la ejecución de programas sobre los robots en el ambiente del laboratorio. Para este fin se han levantado requerimientos adicionales para la arquitectura y se eligieron nuevas
6
tecnologías de punta, con el fin de permitir a los usuarios remotos trabajar con los robots disponibles en el laboratorio y que las tecnologías no se vuelvan obsoletas demasiado pronto.
La extensión de la arquitectura web permite a los usuarios trabajar con los robots de manera remota utilizando herramientas visuales que representan el estado del robot, sus sensores y posición en el espacio del laboratorio; así como crear y ejecutar rutinas creadas por el mismo en dos ambientes separados, primero en una simulación y luego en el laboratorio. Adicionalmente, permite a los desarrolladores siguientes, extender y agregar servicios que requieran interacción con el robot; además de proveer una arquitectura Web sólida y portable que funcione en navegadores en computadores personales (desktop).
El documento tiene la siguiente estructura: En el capítulo 2 se presentan los objetivos y los trabajos relacionados del proyecto. Luego continua el capítulo de Diseño y Especificaciones. Se realizó una etapa inicial de diseño arquitectural planteada en el capítulo 4 donde se estudiaron diferentes tecnologías y se adecuó una arquitectura inicial a las restricciones del proyecto. El capítulo 5 presenta el proceso de implementación de la solución y los cambios realizados al diseño a lo largo del transcurso del proyecto. El capítulo 6 presenta la validación del producto en cuanto a calidad, funcionamiento y validación del cliente. El último capítulo está dedicado a las conclusiones del proyecto y posibles trabajos futuros donde se discuten proyecciones interesantes a futuro.
7
2 DESCRIPCIÓN GENERAL
2.1 Objetivos
El objetivo principal del proyecto es ofrecer una arquitectura Web que permita definir comandos de movimiento y comandos de sensores a un robot Lego Mindstorms EV3 utilizando las últimas tecnologías de desarrollo en plataforma Web.
Los objetivos específicos que se buscan en este proyecto son,
1. Definición y construcción de un modelo de robot diferencial con 2 ruedas usando el Kit Lego Mindstorms EV3.
2. Integración de un simulador virtual consistente con el modelo real del robot.
3. Soporte y comunicación de los sensores del robot Lego Mindstorms EV3 y utilización de estos en las interacciones creadas por el usuario.
4. Definición de servicios de movimiento y propuesta de nuevos servicios en la arquitectura; establecer reglas para modificabilidad y portabilidad del proyecto.
5. Definición e implementación de primitivas de comunicación que permitan al momento el manejo y la visualización del estado del robot.
6. Ejecución en ambiente real, a través de la plataforma se puede pasar un programa del simulador a una ejecución real.
7. Múltiples usuarios, permitir que la ejecución del simulador esté disponible a más de un usuario.
2.2 Antecedentes
o Arquitecturas web y móvil para robots EV3® LEGO® MINDSTORMS® [2] [11]
Existen dos arquitecturas en la universidad relacionadas con el laboratorio de Robótica Remoto, la primera permite la comunicación de un usuario con un robot EV3® LEGO® MINDSTORMS® alojado en el laboratorio de robótica de la universidad; a través de primitivas preestablecidas, el usuario es capaz de mover el robot y de activar ciertas funcionalidades, como giros y activación de motores; ambas arquitecturas proveen servicios básicos a clientes diferentes con estructuras de “Back-End” similares, donde se implementa ejecución de código java sobre el robot y una cámara IP alojada en el laboratorio.
Esta primera arquitectura funciona a través de una página web siguiendo el estilo arquitectural Data-Flow y el patrón de diseño de la arquitectura SOA soportado sobre un cliente-servidor; se puede extender su definición a un tercer componente físico e independiente quien ejecuta los programas escritos en JAVA, así podemos decir que es un patrón cliente-servidor-robot.
El diseño de los servicios y del API siguen el estándar REST, según el cual están organizados en POST, GET, PUT, DELETE; se construyó un HttpRequestHandler sobre java, con el fin de centralizar el manejo de la comunicación con el cliente y facilitar los factores de modificabilidad y legibilidad del código del servidor; no se encontró la definición de recursos por URI o una aplicación con múltiples páginas que justifique la utilización de REST como ruta a la información o como manejo del contexto y navegación del usuario en la página.
Los protocolos de comunicación establecidos en la documentación muestran un servidor HttpServer que expone una API de servicios Java SE y haciendo uso de Https a través de internet. Para la
8
conexión entre el servidor intermedio y el robot se encontró especificado un mediador escrito en java alojado en el servidor quien establece una comunicación con el robot EV3® a través de bluetooth.
Sin embargo, podemos precisar la comunicación entre el servidor y el robot; el mediador de LEJOS utiliza cualquier conexión de red con el robot EV3® para enviar, ejecutar archivos y comandos sobre este a través de una red PAN (Personal Area Network) a través de Bluetooth donde éste se configura como punto de acceso o punto central de conexión de la topología (Star topology) [12].
El computador del servidor intermedio se conecta a través de un adaptador de red Bluetooth como cliente y deja la conexión abierta para que el servidor pueda enviar información; la comunicación entre el programa de java y el robot EV3® requiere un reemplazo del firmware instalado en el robot. Para ambas arquitecturas se utilizó el proyecto LeJOS EV3® que permite crear programas en java y ejecutarlos en el robot, en este caso el proyecto sirve de conexión entre las acciones de los servicios web y el robot.
La segunda arquitectura existente para robots EV3 creada en el laboratorio de la universidad es para dispositivos móviles, sigue el mismo estilo y patrón de la arquitectura web antes mencionada; sin embargo, el cliente ya no es un navegador web sino una aplicación Android (Java) nativa, no se encontró el API mínimo nivel en las configuraciones del proyecto ni en la documentación de este; la aplicación funciona desde un Android Oreo 8.1 (27).
La arquitectura móvil propuesta utilizó adicionalmente una cámara IP instalada en el laboratorio COLIVRÍ de la Universidad; esta cámara se conecta directamente con el dispositivo Android, no se encuentra la cantidad de posibles usuarios que pueden consumir el servicio de Streaming a través de la cámara simultáneamente, pero se realizaron pruebas funcionales utilizando la cámara web.
El servidor intermedio para ambas arquitecturas tiene un sistema operativo (OS) Windows 10 y el programa corre sobre la máquina virtual de Java (JVM); para pruebas recientes de las arquitecturas se ha utilizado un adaptador USB 4.0 Bluetooth que permite encontrar al robot y conectarse a la red PAN. El sensor Bluetooth corre utilizando los drivers básicos de Bluetooth de Windows 10 y no los provistos por el dispositivo USB.
Ninguno de los dos servidores contiene una base de datos o un manejo claro de los usuarios, cada cliente final modifica el estado del servidor que afecta al resto de clientes y su estado no persiste en algún documento, por lo que se puede deducir que al reiniciar el servidor todos los clientes van a iniciar desde 0. La cantidad de clientes está limitada a los que puedan interactuar con el robot de forma simultánea.
o Lab-Open Roberta [6]
“Free, drag-and-drop, cloud-based programming platform” [6], según la definición de su propia página web, es un simulador web para programación visual con bloques (NEPO) estilo Blockly de google, que permite visualizar la ejecución de programas en robots EV3 y NXT de LEGO® utilizando servicios Cloud. Adicionalmente permite la descarga del código fuente en java generado por el simulador, soporta gran variedad de modelos de robots EV3 y NXT y permite la conexión de un robot vía WIFI a través de una red local.
Esta plataforma nació basada en la necesidad de eliminar las dificultades técnicas que los laboratorios de robótica exigen a los profesores y asistentes que los manejan, bajo sus reportes consideran que mantener software y computadores es la tarea con la que menos están a gusto y lo que menos los motiva a utilizar los ambientes de robótica educacional.
Este proyecto introduce el uso de Cloud para soportar su laboratorio de robótica, bajo la premisa que puede utilizarse desde cualquier dispositivo con una conexión a internet y donde solo es necesario configurar la conexión con el robot, que, para algunos (como los EV3) es posible a través de Wifi; la plataforma queda entonces disponible para cualquier sistema operativo que soporte un navegador web y una conexión a internet.
9
NEPO, diseñado por ellos, es un lenguaje de programación visual que utiliza bloques para construir rutinas y/o subrutinas de código; el lenguaje es “Procedual based on Java” pero puede compilar actualmente para 16 robots diferentes, entre ellos NXT y EV3 (Lejos 0.9.1 y anteriores).
Cuentan con un simulador web donde se puede visualizar un ambiente 2D que permite ejecutar los programas antes de pasarlos al robot y adicionalmente cuenta con un visor de código generado por el programa en NEPO, este visor muestra código escrito en JAVA y permite descargarlo para su posterior utilización en robots.
La arquitectura subyacente a la página web utiliza un servidor intermedio para traducir los bloques a código hasta llegar al robot; en la parte del cliente, los bloques están definidos sobre el DOM basados en archivos XML, cuando se genera un programa y se envía al servidor, se transforma utilizando JAXB y AST, con base en estos árboles compilan una versión de código final utilizando Lejos en el caso de los robots EV3 y luego se envía al robot o se guarda en la página para su uso futuro.
Para el acceso a los sensores y el hardware del robot, utilizan un HAL (Hardware Abstraction Layer).
o Otras referencias y trabajos similares
El trabajo en simuladores para robótica no orientados a educación es amplio, la mayoría empaquetados como software descargable para correr en una máquina local [9,10,7]; de pago [9,10] u “open source” [7].
Casos como el de RAVE provienen de proyectos realizados en universidades como parte de investigación en robótica y en particular este está enfocado en la estructuración de un simulador que soporte múltiples robots y se utiliza para “motion planning” y recae fuertemente en un sistema de físicas que maneja el flujo de movimiento basado en información de la geometría del modelo del robot para sus análisis.
Tanto Virtual Robotics Toolkit como RVW son plataformas de pago enfocadas en simulación de robots estilo LEGO EV3, sin embargo, la primera está abandonada por Microsoft, es de pago y permite trabajar con cualquier tipo de robot creado para LEGO® MINDSTORMS® utilizando su ambiente de programación por bloques mientras que RVW es una plataforma de simulación de pago, que permite que los estudiantes que no tienen robots programen sobre ellos, y utiliza modelos reales de robots VEX®, LEGO® y TETRIX®.
La información sobre su implementación y funcionamiento general no está disponible debido a las restricciones de licencias de derechos de autor y el limitado acceso a una prueba gratuita de software.
2.3 Identificación del problema y de su importancia
Los grupos de trabajo a los que está orientado este proyecto no siempre tienen acceso a suficientes robots EV3 para trabajar simultáneamente en cursos o competencias de robótica, lo que demora la interacción, las pruebas y el desarrollo de experimentos; causando un rechazo en los ambientes educativos que contienen múltiples usuarios y que no tienen la capacidad de adquisición de suficientes robots.
10
3 DISEÑO Y ESPECIFICACIONES
3.1 Definición del problema
El problema que resuelve este proyecto es la definición de una arquitectura Web que permite a un grupo de estudiantes y profesores, interactuar con un robot Lego Mindstorms EV3 a través de un navegador. Esta arquitectura permite la interacción de múltiples usuarios con el robot, abriendo la posibilidad de su utilización en grupos de estudiantes grandes. La interacción se da a través de un simulador Web que permite la ejecución de comandos a una versión virtual del robot construido y al robot real.
La población objetivo o usuario final de la arquitectura, son todos aquellos alumnos y profesores que van a interactuar en un futuro con la aplicación.
3.2 Especificaciones
En desarrollo de software se expresan las funcionalidades y el comportamiento esperado de la interacción con los usuarios a través de sus requerimientos. Para esta sección se listarán los requerimientos iniciales establecidos por el grupo de trabajo para el software después de la exposición de antecedentes y antes de la primera fase de diseño.
Requerimientos Funcionales
ID Nombre Descripción
RF01 Conexión a un robot La arquitectura debe poder conectarse a un robot LEGO® MINDSTORMS® EV3 a través de alguno de los recursos de conexión que este ofrece
RF02 Simulador LEGO EV3 La arquitectura permitirá visualizar un robot LEGO® MINDSTORMS® EV3 en un ambiente virtual en 2D
RF03 Simulador por usuario La arquitectura permitirá que cada usuario conectado ejecute una simulación propia
RF04 Cambio de ambiente La arquitectura permitirá al usuario cambiar entre la ejecución del ambiente virtual y el robot real
RF05 Envío de comando La arquitectura permitirá enviar comandos de movimiento al robot LEGO® MINDSTORMS® EV3
RF06 Configuración del robot La arquitectura permitirá definir opciones de configuración para el robot real que también se vean reflejadas en el virtual
RF07 Ejecución de múltiples comandos
La arquitectura debe soportar la ejecución de múltiples comandos simultáneamente
RF08 Uso de sensores de distancia y contacto
La arquitectura debe permitir interactuar con los sensores a través de comandos
RF09 Lectura de sensores de distancia y contacto
La arquitectura debe permitir leer los resultados de la toma de datos de los sensores del robot real
11
RF10 Simulación de sensores de color
La arquitectura debe permitir leer el resultado de la toma de datos de los sensores de color del robot virtual
Requerimientos No Funcionales
RN01 Comunicación segura
La arquitectura permitirá realizar conexiones con protocolos de comunicación segura
RN02 Funcionalidades accesibles
La arquitectura debe permitir el rápido acceso a las funcionalidades en sus plataformas de interacción con el usuario (menos de 3 clics por funcionalidad)
RN03 Multiplataforma La arquitectura debe permitir el uso de sus funcionalidades desde cualquiera de los dispositivos objetivos
RN04 Tiempo de respuesta
La arquitectura debe poder responder a cualquier funcionalidad dentro de los primeros 2 segundos
RN05 Escalabilidad La arquitectura debe permitir escalar vertical y horizontalmente
RN05 Portabilidad La arquitectura debe poder conectarse con otros sistemas a través de protocolos seguros
RN06 Modificabilidad La arquitectura debe ser modularizada para permitir nuevos desarrollos e integración de nuevos sistemas a esta
Soluciones aproximadas
Arquitectura y protocolos de comunicación: es solución aproximada aquella que cumpla con los requerimientos funcionales expresados en secciones anteriores hasta el punto de su ejecución efectiva; es aceptable que no se integre una comunicación bidireccional completa que permita reflejar todos los sucesos dentro de la aplicación al usuario final, así como errores excepcionales o no previstos ni tiempo real efectivo en todas las funcionalidades.
Lenguaje de comandos: es solución aproximada aquel lenguaje de comandos que permita transmitir al robot real y al simulador virtual las directivas de movimiento de acuerdo con los parámetros y el funcionamiento definidos en la sección de diseño, sin embargo, el lenguaje no va a ser orientado al usuario final dado el alcance de este proyecto y su nivel de aceptación recae en la capacidad de reemplazar este lenguaje por uno que se adapte a las necesidades del proyecto.
Simulador: es solución aproximada el simulador que cubra las directivas de movimiento definidas en el diseño y que permita la simulación virtual de un tipo de sensores, el nivel de aceptación se logra cuando el sensor elegido recrea el funcionamiento de su versión real en el ambiente virtual y el simulador permite visualizar las funciones de movimiento definidas en el diseño.
Movimiento del robot real: es solución aproximada aquella que mantenga la precisión del movimiento del robot real dentro de un rango del 5% del movimiento teórico, así, el nivel de aceptación en precisión del movimiento es de 95%.
3.3 Restricciones
- El simulador 2D debe representar un área de trabajo similar a la disponible en el laboratorio y en el alcance de su comunicación. El área de trabajo definida es de 9m2 (3m ancho x 3m largo).
- La conexión al robot tiene una restricción de menos de 10 m de distancia para ser estable.
12
- Solo se utilizará un robot real con la arquitectura que debe estar disponible para todos los clientes.
- La arquitectura debe poder montarse y probarse en un solo computador en el laboratorio.
- La arquitectura debe funcionar con un modelo de robot construido a partir de un set LEGO® MINDSTORMS® EV3.
- La duración de la batería del robot está limitada por la utilización de 6 baterías AA.
- La librería que realiza la conexión con el robot está escrita para java.
- El robot requiere de un firmware específico para su comunicación con la librería de java.
- El lenguaje de comandos no va a estar orientado a la población objetivo (estudiantes).
- La arquitectura debe poder ser desplegada en la mayor cantidad de dispositivos finales.
13
4 DESARROLLO DEL DISEÑO
El diseño de la arquitectura de software está basado en dos estilos arquitecturales orientados a soportar los dos enfoques de interacción con el robot. La programación y los comandos del usuario al robot se realizan a través de un patrón Cliente-Servidor con un componente añadido, el robot, dado que hace parte de la infraestructura. Por otro lado, el robot es capaz de responder a sus interacciones con el entorno por medio de sensores, por lo que se diseñan algunos servicios orientados a un patrón publish-subscriber, donde los clientes se suscriben a un recurso que les brinda información sobre el robot conectado.
El propósito de la arquitectura es unificar los servicios expuestos a los clientes, por lo que la componente central es una aplicación web (servidor) que controla los pedidos de llegan a través de Http y los envía al robot físico o al simulador; así mismo, el componente web está encargado de ofrecer los servicios para el usuario final y que funcionen de manera uniforme con el robot real ycon el robot del simulador.
Para el manejo de la “lógica” de la aplicación se han destinado dos componentes más y dos servicios de infraestructura adicionales; para la parte de simulación se construirá un componente que permita visualizar gráficamente el funcionamiento de un programa (comandos) ejecutado en el robot, por otra parte, el robot consta de un mediador que, utilizando las librerías de leJOS (API en java), es capaz de darle instrucciones al robot EV3 a través de una interfaz alojada en el firmware del robot. El último componente adicional es una cámara IP alojada en el laboratorio que permite el uso remoto de éste, en el siguiente diagrama de componentes se muestran todas las relaciones entre los antes mencionados:
Ilustración 1 Diagrama de Componentes - Servidor Java
Los tres componentes principales del servidor son WebApp, leJOS EV3 mediator y EV3 Simulator. Para la construcción del proyecto se ha destinado otro paquete que representa el modelo del Robot físico y una representación virtual de este; para efectos y alcance práctico de nuestro proyecto, este componente únicamente trabajará un modelo Lego Mindstorms EV3 pero se dejará abierta la implementación de más robots; la virtualización nos permite cerrar la brecha entre el ambiente real y el simulador para que sean los más parecido posible.
En cuanto al resto de componentes; la base del servidor (WebApp) está constituida por tres clases: HttpServer, RequestHandler y RobotCommander; el simulador consta de tres: SimulationCore, VirtualModel y VirtualEV3; finalmente, el componente del EV3 físico cuenta con el mediador de leJOS. Tanto el EV3 como el VirtualEV3 implementan una interfaz que define los servicios ya que es necesario que compartan las mismas funcionalidades a este nivel; algo similar ocurre con los
14
modelos del Robot solo que en cuestiones de código se decidió realizar una virtualización del robot para el simulador.
A continuación, una explicación corta de cada clase, y un diagrama de clases UML:
Ilustración 2 Diagrama de Clases UML - Servidor Java
Componente WebApp
Http Server
Encargado de iniciar el servidor y los sockets con los clientes, delega su trabajo al RequestHandler que procesa cada solicitud y de acuerdo con la estructura recibida ejecuta un servicio del API; su funcionalidad principal es de comunicación con el cliente y es donde reside la exposición de servicios REST(API). Es la clase principal del proyecto y el inicio de la ejecución de éste.
Request Handler
Su funcionalidad principal es recibir solicitudes (requests) REST; es la parte inicial de la API, revisa permisos de acceso, control de destinos de recursos, valida la metadata de los request (headers, connection data); adicionalmente construye las respuestas del servidor al cliente.
Robot Commander
Es el encargado de manejar los ambientes de ejecución, la creación inicial del mediador de comunicación con el robot físico y todos los requests posteriores a éste. Se utiliza para crear un ambiente virtual para el usuario y de definir los componentes virtualizados según el modelo físico.
15
Componente Simulador
Simulation Core
La clase principal de la simulación es la encargada de toda la virtualización de los ambientes reales, por lo que maneja modelos y representaciones de objetos en formato svg, es quién dicta como se pintan los elementos de la simulación en cada momento y la reacción del robot virtual a su entorno; delega al Virtual EV3 todas las tareas que requieren simular hardware como sensores y movimiento de motores.
Simulated EV3
Representación virtual del robot EV3, se encarga de virtualizar los servicios de la API de leJOS y los
parámetros del modelo del robot.
Virtual Model
Es la representación virtual del modelo físico del robot y sus componentes, dicta que sensores se
utilizan y permite mantener la correlación con el modelo físico.
Componente EV3
Robot EV3
El robot EV3 es el mediador entre el servidor y el robot, encargado de ejecutar comandos simples sobre éste, recibir datos de los sensores y comunicarlos a las capas superiores y de la concatenación de rutinas del servidor, expone los servicios de bajo nivel e implementa la misma interfaz que su homólogo virtual, sin embargo, extiende de un modelo no virtual, que encaja con los componentes físicos instalados en el robot y que pueden comunicarse con leJOS.
Cliente web
El cliente web está diseñado utilizando los principios de diseño establecidos por Reactjs. Siguiendo la división por componentes, cada requerimiento funcional del lado del cliente está expresado en uno y solo un componente lo que permite la modificabilidad de la página web a largo plazo.
La composición de funcionalidades también provee ciertas funcionalidades y optimizaciones consideradas por esta fase de diseño que permiten cubrir atributos de calidad, mencionaré lagunas a continuación.
Modificabilidad
Dado que cada componente se encarga de una funcionalidad, es posible conectar, desconectar, mover, reemplazar o reescribir componentes según las necesidades del programador; ya sea por cambiar el flujo de información, cambiar de lugar un componente para satisfacer algún requerimiento no funcional o simplemente por reducir la complejidad de la interfaz gráfica.
Pintado selectivo
La estructura interna de Reactjs permite pintar únicamente los componentes cuya información cambia, por lo que evita gastar recursos actualizando constantemente todo el árbol de componentes. Dado que, dentro de nuestro diseño, cada componente representa una funcionalidad, se puede
16
utilizar el intercambio de información entre el back-end para optimizar la actualización de los componentes y reducir posibles GUI Lags desde el diseño.
Esto resulta especialmente útil cuando se trata de un simulador que debe ejecutar cambios en la interfaz que reflejen el movimiento de un objeto real en el tiempo, dado que solo se van a renderizar los componentes que pertenezcan a este escenario y no toda la aplicación.
Javascript
Reactjs está escrito sobre Javascript, lenguaje de programación interpretado que es un dialecto de ECMAScript y, aunque se define como un lenguaje orientado a objetos, es posible utilizar otros paradigmas de programación como la programación funcional.
Actualmente Javascript permite el uso del estándar ECMAScript 6, que permite extensiones del lenguaje orientado a programación funcional y cambios en la sintaxis que aumentan la legibilidad del código. Algunos de estos cambios interesantes para este proyecto es el uso de las expresiones lambda que facilitan el manejo del contexto de una aplicación y permiten el flujo de información dentro de esta; la introducción de variables como “let” que permiten definir variables locales para un contexto definido y que reducen la posibilidad de introducción de errores (bugs) no intencionales.
El objetivo de utilizar javascript para el front-end es la capacidad de crear un transpilador del lenguaje elegido para comandos que los transforme de lenguaje textual a un lenguaje que pueda ser interpretado por el back-end en java.
Diseño del lenguaje de comandos
En proyectos anteriores se definieron dos tipos de comando, uno simple y uno compuesto, los comandos simples expresaban instrucciones atómicas y estáticas como moverse adelante por una cantidad de tiempo predeterminada, rotar el robot por el mismo tiempo entre otros. Los comandos complejos amplían la configuración del usuario permitiéndole definir una cantidad de tiempo por la cuál el robot va a realizar alguna de las acciones.
Para este proyecto se pretende extender de estas directivas bases y definir un conjunto amplio de nuevos comandos que permitan la configuración extensiva del movimiento del robot; para esto se integró en las antiguas funcionalidades la posibilidad de comandar al robot dada una medida fundamental de la dimensión física de su movimiento. Por ejemplo, para el movimiento adelante y atrás su parámetro va a estar en una medida de distancia, en este caso centímetros y para una rotación su parámetro va a estar en grados.
El lenguaje de comandos para este proyecto tiene un alcance limitado; dado que no cumple con los requisitos de legibilidad para la población objetivo del proyecto, se ha definido un límite que permita la modificabilidad posterior del mismo. Se construirá un lenguaje descriptivo similar al pseudocódigo que no sea Turing completo pero que permita modificarse en el futuro y se integrará con el servidor de back-end para reducir los cambios enfocados hacia el usuario final.
Se ha diseñado un transpilador que permita escribir en pseudocódigo y se transfiera como comandos atómicos al servidor para su posterior ejecución; dado que este lenguaje por comandos está diseñado para ser escrito seguido y no línea por línea, se ha definido como separador de bloques de código el carácter espacio. A continuación, se muestra una tabla que especifica las directivas diseñadas:
Directiva Parámetro(s) Descripción Ejemplo
move / mv Distancia (cm) Movimiento descrito en centímetros que permite números reales y que cambia de dirección dependiendo del signo
move 10
mv -30
17
forward Distancia (cm) Movimiento del robot hacia adelante que permite números reales y que no cambia de dirección
forward 10
backward Distancia (cm) Movimiento del robot hacia atrás que permite números reales y que no cambia de dirección
backward 10
turn / t Distancia (grados)
Rotación del robot descrita en grados que permite números reales y que cambia de dirección con el signo, positivo siendo al contrario de las manecillas del reloj
turn 90
t -90
left Distancia (grados)
Rotación del robot descrita en grados que permite números reales y que cambia de dirección con el signo, positivo siendo a la izquierda
left 360
right Distancia (grados)
Rotación del robot descrita en grados que permite números reales y que cambia de dirección con el signo, positivo siendo hacia la derecha del robot
right 180
repeat / do / times
Contador (#), lista de comandos ({})
Directiva que permite la ejecución de una lista de comandos un número dado de repeticiones, el contador debe ser un número entero positivo y la lista de comandos debe estar encerrada entre corchetes {}
repeat 4 { forward 10 turn 90 }
condition / if
Condición(), lista de comandos a ejecutar ({})
Un condicional que ejecuta una lista de acciones si se cumple su condición. La condición está encerrada en paréntesis y se compone de una variable apuntadora a un sensor, un condicional y un comparador. La lista de comandos debe estar encerrada en corchetes {}
if ( COLOR_SENSOR1 == RED ) { turn 180 forward 10 }
Despliegue de la Aplicación
El despliegue de la aplicación, debido a las restricciones de diseño, debe tener en un área cercana el servidor principal y el robot físico, estos dos están conectados a través de una red de área personal (PAN) que utiliza bluetooth y depende del hardware que tenga la máquina donde está desplegado; para esta red de área personal, se requiere un adaptador de red sobre el puerto de bluetooth y se recomienda la utilización de los drivers de Microsoft que vienen instalados con el SO Windows 10 incluso si la tarjeta de red del equipo no cuenta con bluetooth y se utiliza un adaptador externo (i.e. USB).
El resto de infraestructura se despliega a través de internet utilizando los protocolos Http e IP, sobre el primero se establece la comunicación con la página web y con las aplicaciones móviles, mientras que la comunicación con la cámara es directamente a través del protocolo IP; a continuación, se muestra el diagrama de despliegue correspondiente a la arquitectura.
18
Diseño del controlador del robot real
Ilustración 3 Diagrama de Despliegue – Servidor y Cliente
19
El controlador de movimiento del robot se debe ajustar a la librería utilizada para interactuar con los motores del EV3, esta librería ofrece dos métodos de interacción con estos mecanismos, encender la rotación de un motor o moverlo hasta cierto ángulo. Dado que la rotación por ángulos está diseñada para movimientos de objetos y no de ruedas (ej. Brazos) se utilizaron los métodos de inicio y fin de rotación de los motores para implementar las directivas de movimiento.
El proceso consiste en calcular el tiempo de ejecución de un movimiento, iniciar los motores indicados en la dirección indicada para el movimiento y finalmente frenar todos los motores después del tiempo transcurrido. Esta tarea debe ejecutarse en un hilo de ejecución alterno para no bloquear la interacción de los clientes con el servidor.
4.1 Alternativas de diseño
Servidor basado en otro lenguaje de programación como Python, Javascript o Scala; la idea de utilizar alternativas de lenguajes que permitan utilizar el paradigma de programación funcional es integrar de manera sencilla un compilador que, en un futuro, se encarga de la ejecución de los programas en el robot; un elemento menor de utilizar lenguajes semi-tipados y/o interpretados es disminuir la complejidad del desarrollo a lo largo de toda la plataforma, dado que en la solución final se manejan 2 lenguajes de programación completamente distintos (java, javascript).
Cliente basado en Angularjs, dado que es un reconocido framework para el desarrollo de aplicaciones web y puede cubrir los principales requerimientos funcionales de la arquitectura, además, se acopla a cualquier modelo MVC y tiene incluidas herramientas para facilitar la creación de formularios y de manejo del estado del usuario con deeplinking (routing) para el renderizado.
WebSockets sobre servicios, una alternativa de comunicación a las aplicaciones REST utilizando https, varios de nuestros requerimientos funcionales están orientados a la transmisión de información en tiempo real, los principales atributos del software requieren constante comunicación entre el servidor y el cliente y en algunos casos implementaciones de visualizaciones en tiempo real. Por esto, se ha propuesto la alternativa de utilizar websockets para la comunicación bidireccional utilizando el protocolo “ws” y un back-end orientado a servicios.
El back-end orientado a servicios, la propuesta adicional es utilizar un recurso similar a Data-on-the-wire de Meteorjs, que nos permita mantener a nuestros clientes actualizados constantemente de la ejecución de sus simulaciones y del estado del robot real y delegar estas tareas de alto impacto en rendimiento al servidor mientras el cliente se encarga únicamente de renderizar. Sin embargo, no se utiliza Meteorjs dado que el backend está escrito en Java y para utilizar sus funcionalidades al máximo (Optimistic-Rendering) se debe incluir el framework en ambos ambientes.
Soluciones elegidas
El servidor de back-end se realizó en Java, debido a que contiene la librería más completa del firmware de terceros (LejosEV3) utilizado para proyectos anteriores, aunque la utilización de un lenguaje funcional y unificado para toda la arquitectura es un incentivo para los requerimientos no funcionales, las opciones que provee la librería escrita en Java hacen posible un amplio margen de desarrollos alrededor de la arquitectura y es la librería menos limitante en cuanto a funcionalidades.
Para el cliente se eligió Reactjs, dado que Angularjs maneja un método de renderizado desde el servidor (SSR- server side rendering) y debido a nuestras funcionalidades en tiempo real requerimos un framework orientado a renderizar desde el cliente (CSR-client side rendering). Adicionalmente, Angularjs tiene la capacidad óptima de manejar el estado de un usuario a través de grandes aplicaciones con múltiples páginas, sin embargo, nuestra aplicación es de página única y aún no tiene manejo de usuarios por registro.
Para el protocolo de comunicación se eligió la arquitectura utilizando WebSockets y servicios, la estructura de REST define que para recurso de información se debe establecer una URI única que
20
permita al usuario acceder a ella en cualquier momento; nuestra aplicación es de página única y no requiere de ningún recurso de información guardado (Base de Datos) para funcionar. Además, Https no tiene comunicación bidireccional por lo que no permite realizar con facilidad las funcionalidades en tiempo real.
21
5 IMPLEMENTACIÓN DE LA SOLUCIÓN
Arquitectura final
A través del desarrollo de esta arquitectura, se han realizado varios cambios importantes para satisfacer los requerimientos funcionales y no funcionales, dado que dentro de la metodología está la etapa de rediseño, es de esperar que la entrega final difiera en ciertos aspectos del diseño original. Las funcionalidades se mantienen idénticas, sin embargo, todos los modelos conceptuales de una arquitectura de software han sido modificados manteniendo el orden, los paradigmas y las buenas prácticas de desarrollo.
Componentes
Se integró al diseño inicial una vista de los componentes del cliente web, debido a que dentro del cliente existen dos partes importantes relacionadas con la lógica de negocio; la primera siendo el transpilador de comandos y la segunda el socket.io, encargado de manejar la comunicación bidireccional con el servidor. La sección de presentación muestra la división de los componentes a gran escala de React, más adelante se encuentra una definición de la estructura subyacente al cliente completo.
Ilustración 4 Diagrama de componentes de la solución – Servidor Java
Clases
El modelo inicial de clases pasó por dos fases de rediseño que implican cambios estructurales de fondo y que requieren un nuevo paquete de clases para mantener la consistencia y la modificabilidad del software (DTO Package).
En la primera fase de rediseño, al momento de incluir la parte final del simulador, se reestructuró el flujo de información y control de las clases del simulador, ya que debe estar disponible para múltiples clientes, el manejo de estas clases se delegó a quién tiene la información de la conexión de los Websockets y, tal como aparece en el modelo, únicamente se transfiere la instancia del simulador entre las diferentes clases de control.
En la segunda fase de rediseño, al momento de conectar los sensores con las funcionalidades en tiempo real de los dos ambientes de desarrollo, se añadieron dos clases que extienden de Runnable y que se encargan de verificar el estado de los sensores. Estas clases corren en otro hilo de ejecución y no bloquean el hilo principal del servidor, permitiendo que múltiples simulaciones estén en ejecución simultáneamente y al mismo tiempo más de un observador sobre el estado del robot real.
22
Ilustración 5 Diagrama de clases de la solución -Servidor Java
Despliegue de la aplicación
La estructura del despliegue de la aplicación ahora incluye otro servidor intermedio adicional, según la figura siguiente, un servidor nodejs escrito completamente en Javascript y que puede ser alojado en una máquina diferente al servidor de Java dependiendo de los requisitos del usuario. La arquitectura final utiliza Client-side-rendering (CSR) y Data-on-the-wire (DOTW), conceptos explicados anteriormente en la fase de diseño.
CSR implica que el servidor que realiza la lógica no conoce nada de lo que ocurre en el lado del cliente, el diseño de varias arquitecturas incluye el cliente completo dentro de la estructura del proyecto original que luego se encarga de servir este grupo de archivos al momento de recibir una petición http. Sin embargo, dado que el servidor intermedio está basado en WebSockets y que está intrínsecamente relacionado con la lógica del negocio, se decidió añadir un servidor adicional en Nodejs que se encargué de servir el cliente al momento de ser llamado.
DOTW soporta la justificación anterior, dado que el canal de comunicación con el servidor de java es únicamente de datos e independiente del cliente, es apenas suficiente tener un servidor adicional. La independencia entre estos dos servidores permite que se pueda conectar cualquier tipo de cliente en cualquier plataforma que soporte WebSockets y da una gran ventaja a la portabilidad del proyecto.
23
Ilustración 6 Diagrama de Despliegue de la Solución – Servidor y Cliente
Modelo Físico Robot Diferencial 2 Ruedas
Se construyó un nuevo modelo de robot siguiendo un modelo educacional llamado Enterprise [13], el cual permite la integración de todos los sensores disponibles utilizando las partes disponibles en el laboratorio. Esto incluye la utilización de un sensor de distancia, uno de contacto y dos sensores de color que observan el suelo; dos motores ubicados en el centro del robot que controlan cada uno una rueda lateral.
Se realizó una única modificación al modelo original en las ruedas traseras, debido a que nuestro robot va a rotar, la posición de las ruedas traseras dificultaba el movimiento ya que estas no rotan; se diseñó una rueda pequeña giratoria, sin embargo, esta rueda no presenta el grado de libertad necesario y no se cuenta con la experiencia para diseñar una nueva ya que las propuestas hacían que los sensores de color entraran en contacto con el piso, lo cual puede dañarlos.
24
A continuación, las seis vistas del robot final:
En la vista frontal se encuentran los sensores de contacto (izquierda) y de distancia o infrarrojo (derecha) además de la parte superior de los sensores de color ubicados en la parte de abajo. También se encuentran las conexiones al “Brick” del robot, que es la parte principal, estos puertos numerados del 1 al 4 se utilizan para los sensores y para este robot están configurados de la siguiente manera:
Número del puerto Sensor
S1 Infrarrojo
S2 Color 1
S3 Color 2
S4 Contacto
Ilustración 7 EV3 Vista frontal
En la vista superior se puede observar el “Brick” Ev3 que es la pieza fundamental del robot y se pueden observar la posición de las ruedas con respecto al centro de masa de este, ya que están
25
ubicadas en la parte delantera debajo de los sensores de contacto y de distancia. En la vista lateral izquierda también se pueden ver estas distancias.
Ilustración 8 EV3 Vista superior
El robot mide en su totalidad 16.8 cm de largo, 15cm de ancho y 9.8 cm de alto en sus medidas mas extensas. Las ruedas se encuentran a 7.13 cm del eje central que cruza a lo largo del robot y a 2.4 cm del eje central que lo atraviesa a lo ancho.
Ilustración 9 EV3 Vista lateral izquierda
En la vista trasera se pueden observar las dos conexiones entre los motores de las ruedas frontales y el “Brick” El motor derecho está conectado al puerto B y el izquierdo al puerto C. También se muestra la rueda trasera implementada para este trabajo.
26
Ilustración 10 EV3 Vista trasera
En la vista lateral derecha se ven los puertos USB y microSD del “Brick” EV3, en la microSD se encuentra instalado el firmware lejos EV3 0.9.1 y el puerto USB admite conexión a un computador o a un adaptador para Wifi.
Ilustración 11 EV3 Vista lateral derecha
27
En la vista inferior del robot se pueden observar los dos motores de las ruedas delanteras, la posición de la rueda trasera y el frente de los dos sensores de color.
Controlador del robot real
Dado que en el diseño se planteó una solución de movimiento en función de mantener los motores encendidos por cierta cantidad de tiempo, se desarrollaron dos métodos dependientes del modelo que se encargan del movimiento del robot a partir de constantes y del input del usuario.
La primera fórmula comprende el movimiento recto que permite al robot moverse una distancia dada, a una velocidad definida en función de los parámetros del modelo del robot:
Entradas:
- v: velocidad en grados por segundo (medida estándar de los EV3)
- d: distancia en centímetros que se debe mover el robot.
Constantes del robot:
- W: diámetro de la rueda del robot en centímetros (Constante del modelo utilizado: 4.3 cm)
𝑀𝑖𝑙𝑙𝑖𝑠𝑒𝑐𝑜𝑛𝑑𝑠𝑂𝑓𝑀𝑜𝑣𝑒𝑚𝑒𝑛𝑡 = (
𝑑𝑊 ∗ 𝜋
) ∗ 360
𝑣∗ 1000
Este resultado se debe aplicar a cada uno de los motores del robot para controlar el movimiento de cada rueda.
La segunda fórmula cubre las rotaciones sobre el plano del robot, tiene una constante adicional ya que el movimiento de las ruedas depende de la distancia entre ellas y depende de la fórmula anterior; se utilizó la fórmula anterior así que se calculó la distancia que debía moverse cada rueda para cubrir
Ilustración 12 EV3 Vista inferior
28
la rotación y se insertó en la fórmula anterior (se presenta la fórmula después de simplificar las constantes de cambio de variable):
- v: velocidad en grados por segundo
- g: grados de rotación del robot
Constantes del robot:
- W: diámetro de la rueda en centímetros (Constante del modelo utilizado: 4.3 cm)
- T: Track Measure, distancia entre las dos ruedas del robot medida en centímetros ( Constante utilizada 17.5 cm)
𝐷𝑒𝑔𝑟𝑒𝑒𝑠𝑇𝑜𝑀𝑖𝑙𝑙𝑖𝑠𝑒𝑐𝑜𝑛𝑑𝑠 = (
𝑇 ∗ 𝑔𝑊
)
𝑣∗ 1000
Las rotaciones se realizan alrededor de un eje de rotación ubicado en la mitad de las ruedas, para esto, el resultado de la fórmula anterior se aplica a cada uno de los motores invirtiendo el sentido de su rotación.
5.1 Descripción de la implementación
Metodología
Se siguió un principio de diseño (Design Thinking) acelerado, para el diseño de interfaces y de todo el front-end; este diseño se aplicó durante el cambio a nuevas tecnologías y estableció los lineamientos para el desarrollo de los componentes adicionales.
Para el cambio en las arquitecturas se realizó un estudio arquitectural para determinar los cambios requeridos en la parte antigua y cómo los desarrollos impactaron en la estructura ya existente, manteniendo los estándares de calidad y restricciones de uso levantadas sobre el análisis inicial; sobre este estudio se desarrolló el cambio a nuevas tecnologías donde se incluyen los mejores candidatos que se acoplaron al estudio.
Se utilizó una metodología ágil basada en la entrega rápida de funcionalidades que agreguen valor al proyecto, que sean útiles y funcionales; donde la capacidad de decisión sobre las tecnologías o métodos a utilizar esté de acuerdo con las necesidades de los requerimientos dentro de un marco teórico que permita su desarrollo.
Dos metodologías posibles son LEAN y XP ambas basadas en la entrega de requerimientos simples y granulares; que permiten separar el desarrollo total en pequeñas partes que, en orden cronológico se realizarán en base al listado anterior de objetivos. Finalmente se utilizó la metodología XP para un proyecto dividido en Sprints semanales de acuerdo con el tiempo y las reuniones semanales con el usuario final.
Etapas de Desarrollo
El desarrollo de la plataforma se realizó en tres etapas, diseño, desarrollo y recolección de datos con usuarios.
Etapa de Diseño
Esta etapa (Design Thinking) y los estudios arquitecturales se realizaron en las primeras semanas antes y recién empezado el proyecto; esto estableció los lineamientos para el desarrollo de todo el proyecto.
29
Etapa de Desarrollo
Esta etapa se dividió en 3 Sprints de 3 semanas donde se distribuyeron las fases de desarrollo de una aplicación utilizando la metodología XP, simplificada para una sola persona para permitir entregar requerimientos lo más rápido posible. Cada uno de estos Sprints incluye tres secciones: rediseño de ser necesario, desarrollo de funcionalidades y entrega a un cliente final.
Primer Sprint
En el primer sprint se encargó de la renovación de la arquitectura web, construcción del nuevo cliente utilizando tecnologías actualizadas no obsoletas (Reactjs) y de su integración con el servidor intermedio en java, dentro de esta actualización se construyeron e integraron todos los elementos nuevos de la arquitectura que cumplen las funcionalidades ya existentes, se cambia la estructura de clases y el flujo de información.
Segundo Sprint
Para esta iteración se definen las primitivas de dirección como servicios, se crea el transpilador que integra el lenguaje de comandos y se realizan los cambios en back-end para soportarlos; se diseñan e implementan los nuevos comandos de rutina y se integra el iterador por cantidad de veces al lenguaje de comandos.
En el lado del servidor se crean las fórmulas para los movimientos del robot y se integran nuevos componentes al cliente: el apartado de configuración y la lista de comandos.
Tercer Sprint
Esta iteración está dedicada a la creación del simulador web para el robot EV3 y al cambio de protocolos de comunicación a WebSockets (wss), se incluyen los componentes del simulador en el cliente web, se agregan también utilidades como, una consola de comandos y un apartado para los sensores del robot real y virtual, se modifica la interfaz para cumplir los requisitos de usabilidad y se cambia la paleta de colores.
Por el lado del servidor, se cambia la API Rest por un controlador de conexiones por WebSockets con un agregado de manejo de clientes, se agregan las clases que controlan el estado de los sensores y se conectan con los posibles clientes, se termina de implementar el publish subscriber para estas funcionalidades.
Etapa Final
La recolección de datos se realizó en 1 o dos semanas, dependiendo de la disponibilidad de los usuarios a los que se les quiera pedir prueba de la aplicación. Sin embargo, por tiempo y disponibilidad, únicamente se realizaron pruebas con alumnos cercanos al proyecto y al laboratorio de la universidad, las pruebas eran validadas finalmente con el usuario final.
Finalmente, en las últimas semanas se realizaron los análisis de resultados, la calibración del simulador, las pruebas de movimiento del robot y la preparación para la presentación final del proyecto.
5.1 Resultados esperados
Se espera integrar estándares de modificabilidad de software al proyecto y extender las nuevas funcionalidades antes mencionadas, sobre una arquitectura web que permita la interacción con los robots en RT (menos de 500 ms) y que sea altamente modificable y portable.
30
El usuario podrá entonces, definir rutinas de ejecución para el robot, simularlas en un entorno virtual a través de la plataforma web y finalmente, ejecutarlas en el ambiente real del laboratorio ayudado de las herramientas de visualización de los sensores y la cámara web.
Inicialmente el simulador estará disponible para web; pero cabe la posibilidad y el alcance de desarrollarlo para dispositivos móviles; sin embargo, esto se deja abierto debido a la complejidad de aprendizaje de la parte del servidor.
Los resultados esperados del movimiento del robot real deben estar dentro del 5% del comando teórico ejecutado, es decir, para un movimiento recto de 90 centímetros se espera que el robot, al final de su ejecución, se encuentre entre 85.5 cm y 94.5 cm del punto inicial. Ya que el movimiento del robot virtual es perfecto y no tiene errores de cálculo o de ambiente, se decidió minimizar el error en el camino real para hacerlos similares en lo posible.
31
6 VALIDACIÓN
6.1 Interfaz Cliente Web
El cliente web es el medio de interacción del usuario con los robots Lego Mindstorms EV3 y con el simulador 2D. Para esto se ha dividido en dos componentes principales:
Comandos, variables de contexto y consola.
El primer componente está enfocado en la interacción usuario robot, la sección de comandos, permite dar comandos al robot EV3 y da funcionalidades de ejecución sobre las listas de comandos ya escritas como ejecutar todos los anteriores, únicamente los seleccionados o eliminarlos.
Ilustración 13 Cliente - consola de comandos
En la sección de contexto se muestran las variables que se pueden utilizar para interactuar con los sensores del robot, y se puede configurar el uso de la aplicación. En esta sección se puede cambiar entre la ejecución de comandos en el ambiente real y en el ambiente virtual, adicionalmente se puede modificar la velocidad a la que se mueven los motores que esta expresada en grados (°) por segundo (medida utilizada por LeJOS)
32
Ilustración 14 Cliente – Contexto
La consola permite la lectura de errores en los comandos que se intentan ejecutar pero que fallan, para efectos de este proyecto únicamente se valida los comandos ejecutados.
Ilustración 15 Cliente – Consola
La segunda sección muestra la retroalimentación del simulador y la lectura de los sensores del robot real y virtual.
La primera sección contiene el simulador, el robot está representado en gris y está sobre un terreno pre preparado especial para la realización de las mediciones de la sección de validación.
33
Ilustración 16 Cliente - Simulador 2D
La sección de sensores permite ver que ocurre con los sensores del robot real y virtual al momento de ejecutar los comandos que permiten adquirir una lectura de estos.
Ilustración 17 Cliente - Sensores
6.2 Métodos
34
Pruebas de movimiento
Se realizaron mediciones de precisión y exactitud sobre grupos de resultados de la ejecución de algunos comandos asociados al movimiento del robot. Las dos primeras mediciones son el movimiento recto (adelante y atrás) y la rotación (giro del robot en un eje); se realizaron 10 ejecuciones variando la cantidad de movimiento del robot, se eligieron 4 cantidades para cada una de las dos variables.
Se espera de estas pruebas encontrar las medidas de precisión y exactitud de la muestra, utilizando la desviación estándar y la medida del error determinado relativo; utilizando la desviación estándar se encuentra un intervalo de confianza que muestra, con un 99.7% de probabilidad, entre que rango de distancias se va a encontrar el robot luego de la ejecución de uno de estos comandos, el error determinado relativo es una medida porcentual que muestra la distancia de la medida real al valor teórico.
Cada prueba se inició con el robot en un nivel de batería entre el 70 y el 90%, se estableció la medida de movimiento como la diferencia del punto inicial al punto final de la base de la ruedas del robot, las mediciones del movimiento recto se realizaron en cm y la de rotación en grados; se inició la fase de pruebas ubicando el robot en el punto inicial y ejecutando uno de los comandos definidos en la arquitectura desde un cliente web utilizando el parámetro de movimiento definido para la prueba (ej.: forward 30).
Pruebas de conexión del cliente
Dado que uno de los requisitos de la arquitectura en la plataforma web, se realizaron pruebas sobre la página utilizando las herramientas de Audit de Google Chrome, la prueba se realizó únicamente para equipos desktop ya que la página está diseñada específicamente para estos.
El Audit de Google Chrome describe 3 medidas de calidad del software:
Performance, que mide la capacidad de respuesta y carga inicial de la aplicación; dentro de las medidas de velocidad interesantes para este proyecto se encuentran Time to interactive y Estimated input latency, que muestran el tiempo en el que se demora la aplicación en ofrecer interactividad al usuario y la latencia esperada de sus peticiones; sin embargo, este análisis muestra medidas adicionales como el primer pintado de la aplicación y el primer instante en que la página no requiere CPU.
Accessibility, establece oportunidades de mejora con respecto al alcance de la interacción de la aplicación con respecto a usuarios con discapacidades y que faciliten el acceso a otros softwares de ayuda como lectores de pantalla.
Best Practices, otorga un puntaje respecto a las buenas prácticas de programación web destacando vulnerabilidades, manejo de errores, protocolos y tecnologías obsoletas; puede detectar errores menores de seguridad como peticiones a distintas fuentes de datos o servidores.
6.3 Validación de resultados
Se realizaron dos grupos de pruebas para validar el funcionamiento de la arquitectura, la primera, esta orientada al movimiento del robot y verifica que tan preciso es en la ejecución de movimientos de translación y rotación utilizando los comandos provistos anteriormente. La segunda prueba se realizó alrededor del cliente web, se ejecutaron pruebas sobre la página web utilizando la herramienta de verificación de Google incluida en el navegador Chrome.
Pruebas de movimiento
Movimiento recto: las pruebas de movimiento recto se realizaron en 4 escenarios variando cada 30 cm el movimiento del robot desde 30cm hasta 120cm, para cada grupo de datos se tiene la
35
desviación estándar y el error determinado relativo, sobre la desviación estándar se muestra un análisis estadístico que determina la probabilidad de que un movimiento de este tipo se encuentre dentro de un intervalo:
Distancia (cm)
Desviación Estándar Error determinado relativo (%)
Intervalo de confianza (99%)
30 0.14 0.06 [29.56,30.4]
60 0.1 0.006 [59.7,60.31]
90 0.2 0.062 [89.34,90.55]
120 0.46 0.0375 [118.58,121.33]
Todos los valores del error determinado relativo se encuentran por debajo del 1% se puede decir que la precisión del movimiento es de más del 99% para líneas rectas (Exactitud).
Rotación del robot: para la rotación del robot se eligieron 4 escenarios con variación de 90 grados cada uno con respecto al anterior desde 90 hasta 360 grados y se obtuvieron los mismos datos del análisis anterior:
Distancia (°) Desviación Estándar Error determinado relativo Intervalo de confianza (95%)
90 1.39 2.98 [88.51,96.85]
180 2.84 3.94 [178.56,195.63]
270 2.97 4 [271.88,289.72]
360 3.13 4.33 [366.2,385]
Todos los errores relativos son menores a 5% así que se puede decir que el movimiento de rotación tiene una precisión de más del 95% del movimiento original.
Pruebas sobre el cliente web
Ilustración 18 Resultados de pruebas de “Lighthouse”
La parte web de esta arquitectura cumple con los requisitos de rendimiento para aplicaciones de escritorio y utilizando un buscador web moderno. A continuación, se muestran las métricas de las cuales se habló anteriormente que soportan la idea de que la página cumple con el rendimiento adecuado.
36
Ilustración 19 Métrica de “Lighthouse”
Sobre accesibilidad los resultados resaltados por la aplicación solo se encontró una oportunidad de mejora, que fue añadir una descripción a cada input de la página web para que los lectores de pantalla puedan asociar cada uno de estos inputs correctamente. Sin embargo, en la aplicación cada uno de los campos de entrada tiene su propia descripción excepto la entrada de los comandos, sin embargo, este campo tiene una descripción que puede ser encontrada por los lectores de pantalla.
Sobre buenas prácticas se encontraron dos oportunidades de mejoras, la primera relacionada con el uso de HTTP1 y no HTTP2, sin embargo y debido a que la mayoría del contenido del ODM es generado por librerías de terceros, es complicado arreglarlo sin poder realizar un cambio masivo en la aplicación. La segunda oportunidad de mejora es la utilización de un controlador estático para realizar el cambio de datos en la zona que tiene scroll lateral, por la misma razón anterior no corregirá esta oportunidad de mejora.
37
7 CONCLUSIONES
7.1 Discusión
La arquitectura mejorada cumple con los atributos de calidad esperados e incluye nuevos paradigmas, protocolos de comunicación y módulos que van a permitir el futuro desarrollo de la aplicación; su estructura de doble servidor y conectividad múltiple permite cumplir con los objetivos de negocio de la segunda entrega de esta serie de proyectos. Toda funcionalidad implementada tiene los recursos para crear extensiones que provean nuevas funcionalidades o mayor control y configuración sobre los ambientes y el robot que la incluyen.
El simulador trabaja sobre un modelo virtual de un escenario y no contiene hasta el momento un motor de físicas, por lo que es posible que las simulaciones sobre sensores sean muy simples y no incluyan interacción con objetos reales. Las instrucciones sobre el ambiente virtual son exactas y por los tanto siempre va a ejecutar las maniobras teóricas, los resultados del proyecto muestran que se logró una precisión de más del 95% en el movimiento y una exactitud dentro de los parámetros de aceptabilidad; sin embargo, se podían mejorar las métricas a través de un estudio exhaustivo del movimiento del robot.
Tanto el simulador como el ambiente real tiene conectados los modelos de sensores del robot, pero, debido a la falta de motor de físicas y a la variación extrema de los datos recolectados por el robot real, no se pudo implementar completamente la funcionalidad de estos; sin embargo, se han dejado las bases para un estudio preciso sobre el comportamiento de los sensores reales y sobre el manejo de estos en la parte virtual.
El lenguaje de comandos utilizado y presentado como resultado, demostró cumplir con los requisitos mínimos de ejecución de primitivas de movimiento, resta para trabajo futuro, el desarrollo de un lenguaje de programación Turing completo para asegurar la funcionalidad del robot. Se encontró que el lenguaje de comandos es altamente modificable para primitivas básicas y se pueden añadir de manera sencilla mientras no requieran de un estado de la ejecución (ej.: loops).
El manejo del movimiento del robot se realiza a través de un análisis y conversión de los parámetros del usuario que lo discrimina por comandos, se encontró que al realizar rutinas con movimientos muy cortos el robot es obligado a prender y apagar sus motores constantemente, lo cual puede dañarlos o en el mejor de los casos aumentar el uso de la batería.
La conexión a través de una red de área personal de bluetooth se presenta inestable y con un grupo de errores de comunicación que no se logró reproducir. Se recomienda la adición de un dispositivo de red wifi al robot que le permita conectarse vía IPv4 al computador de comandos.
A su vez, el uso de 6 baterías AAA tiene un ciclo de prueba de menos de 4 horas al momento de realizar ejecuciones de programas constantes. El modelo de robot no permite el uso de una sola batería recargable y por lo tanto el trabajo realizado en torno al robot real debe tener en cuenta, para futuros trabajos, la cantidad de batería consumida tanto por los motores como por los sensores.
7.2 Trabajo futuro
Este proyecto es el segundo paso para la construcción de una arquitectura para laboratorios de robótica móvil online, así que las oportunidades para desarrollar nuevas funcionalidades son inmensas; nombraré algunas que sean de interés hasta el momento:
- Agregar un módulo que permita la configuración del modelo del robot, que integre, identifique y sea capaz de realizar trabajos diferentes utilizando todos los motores y sensores disponibles y que pueda guardar las constantes requeridas para los diferentes movimientos.
38
- Implementación e integración de un lenguaje de programación, desde la fase de diseño proponer un nuevo lenguaje de programación que pueda ser utilizado abiertamente por todos los proyectos de robótica en el alcance de este proyecto y orientado al público objetivo de éste (ej. GoogleBlocks).
- Cambio a Cloud Computing, dado que estar arquitectura únicamente requiere una conexión a un robot que se puede realizar a través de un plugin en el navegador, se pueden migrar todos sus componentes a Cloud Computing para elevar el alcance y disponibilidad del proyecto.
- Integrar un motor de físicas al simulador, permitir al modelo virtual del robot interactuar con objetos de su alrededor, definir modelos y comportamientos visuales de los sensores en tiempo real.
- Integrar un ambiente 3D al simulador, permitir al usuario seleccionar un robot de un banco de modelos o diseñar el suyo propio, cambiar el terreno de simulación y ejecutar los resultados de un programa en este ambiente.
- Extender las funcionalidades de esta arquitectura a robots estáticos que requieren otras directivas de movimiento.
39
8 BIBLIOGRAFÍA
[1] M. S. d. S. Lopes, I. P. Gomes, R. M. P. Trindade, A. F. da Silva and A. C. d. C. Lima, "Web Environment for Programming and Control of a Mobile Robot in a Remote Laboratory," in IEEE Transactions on Learning Technologies, vol. 10, no. 4, pp. 526-531, Oct.-Dec. 1 2017. doi: 10.1109/TLT.2016.2627565 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7740908&isnumber=8207712 Consultado en 25 feb. 2019
[2] Cabello, E. A. (2018). Definición de una Arquitectura para la Creación de Aplicaciones Web integrando Robots Lego EV3. Documento de Proyecto de Grado – Universidad de los Andes, Colombia, 2018.
[3] Berberian, P. (2018). How video streaming works on the web: An introduction. URL: https://medium.com/canal-tech/how-video-streaming-works-on-the-web-an-introduction-7919739f7e1 Consultado en 27 feb. 2019
[4] ev3dev Home. (2018). URL: https://www.ev3dev.org/ Consultado en 12 feb. 2019
[5] Java SE Desktop Technologies - Java Media Framework API (JMF). (2018). URL: https://www.oracle.com/technetwork/java/javase/index-jsp-140239.html Consultado en 12 feb. 2019
[6] Ketterl, M.; Jost, B.; Leimbach, T.; Budde, R.: "Open Roberta - a Web Based Approach Visually Program Real Educational Robots", Die Zeitschrift Learning und Medien (LOM), der Staats- und Universitätsbibliothek - Aarhus, ISSN: 1903-248X [7] Burfoot, J. (2019). EV3 Simulator using RobotC: First glance at QEV3BotSim. URL: http://www.legoengineering.com/ev3-simulator-using-robotc-first-glance-at-qev3botsim/ Consultado en 19 feb. 2019
[7] Dixon, K., Dolan, J., Huang, W., Paredis, C., & Khosla, P. (2019). RAVE: A Real and Virtual Environment for Multiple Mobile Robot Systems. Institute for Complex Engineered Systems Carnegie Mellon University.
[8] Erdmann, R. (2019). Open Roberta Wiki - Open Roberta Wiki - Fraunhofer IAIS Confluence. URL: https://jira.iais.fraunhofer.de/wiki/display/ORInfo/Open+Roberta+Wiki
[9] Overview | Virtual Robotics Toolkit. (2019). URL: https://www.virtualroboticstoolkit.com/discover Consultado en 16 abr. 2019
[10] Robot Virtual Worlds | ROBOTC | VEX & NXT Simulator. (2019). URL: http://www.robotvirtualworlds.com/ Consultado en 19 feb. 2019
[11] Alvarado Ceron, Pablo Alejandro (2019). Definición de una Arquitectura Móvil integrando Robots Mindstorms EV3. Documento de Proyecto de Grado – Universidad de los Andes, Colombia, 2018.
[12] Nieto, Juan Iván; Candolfi, Norma; Michel Macarty, José Antonio; Jimíenez, Elitania (2009). Bluetooth Performance Analysis in Wireless Personal Area Networks. UABC, Facultad de Ingeniería-Ensenada, B.C. México.
[13] Seshan, A. Enterprise [Ebook] (1st ed.). URL: http://ev3lessons.com/RobotDesigns/instructions/Enterprise.pdf Consultado en 30 mar. 2019
40
9 ANEXOS
Anexo A. Instalación de la arquitectura
La arquitectura se compone de dos proyectos, uno realizado en JavaEE y otro en NodeJs, a continuación, la guía de instalación y requisitos de cada uno.
Servidor WebSockets JavaEE (Java 1.8)
Requisitos
Java JDK 1.8.0
Java EE IDE - Eclipse Photon (4.8.0)
Plugins
Asegurarse de tener instalados los “plugins” de eclipse para Maven y para leJOS EV3, ya que son necesarios para el funcionamiento del proyecto.
Nombre Versión Id Proveedor
leJOS EV3 plugin
0.9.1.201511161011 org.lejos.ev3.ldt.feature.feature.group The leJOS Team
m2e - Maven Integration for Eclipse
1.9.0.20180606-2036
org.eclipse.m2e.feature.feature.group Eclipse.org - m2e
Ejecución del servidor
Sobre el proyecto de eclipse asegurarse de ejecutar un “Maven build…” con los parámetros “clean install” como se muestra en la siguiente imagen:
41
Siguiente a esto ya se puede realizar la ejecución a partir del archivo WebSocketsServer del paquete httpServer en el cual se encuentra el servidor.
42
Anexo B. Instalación del servidor NodeJS Servidor NodeJS Para el servidor de Front-end se utilizó Npm, que es un conjunto de herramientas para programación utilizando javascript, entre estas nos permite desplegar un servidor NodeJs con facilidad. Requisitos Npm (6.7.0 +) disponible en https://www.npmjs.com/ Instalación Una vez instalado Npm y descargado el proyecto web, situarse dentro de la carpeta “webclient”, editar o crear el archivo de configuración “.env” con un editor de texto. Acá se encuentra la dirección Ipv4 a la cuál el cliente va a buscar al servidor de Java previamente mencionado, junto con el protocolo y el puerto de comunicación, este archivo luce algo así y no está incluido en el repositorio web por razones de seguridad.
Y se debe ubicar en esta carpeta debajo de “webclient” o la carpeta base del proyecto.
En la imagen anterior se puede observar una carpeta de node_modules, en esta se guardan todas las librerías de terceros y tampoco está incluida en el repositorio por lo que se debe instalar. Instalación Para la instalación se debe acceder a la carpeta de webclient a través de una consola de comandos y ejecutar el comando “npm install”.
Ejecución Para ejecutar el servidor basta con lanzar el comando “npm start” desde la carpeta base del proyecto, lo cuál desplegará el servidor en el puerto 3000. El despliegue puede tardar unos minutos y al finalizar, abrirá una página en el navegador predeterminado de la máquina donde se puede observar el cliente.
43
Anexo C. Conexión del Robot LegoMindstorms EV3 utilizando Bluetooth
Dentro del menú de LeJOS, se debe configurar una red de área personal PAN desde el menú de red. La red se encuentra bien configurada en el momento en el que la página principal aparece la ip por defecto 10.0.0.1.
A continuación, se debe conectar por bluetooth a través del computador, al robot que tiene LeJOS EV3 instalado. Después de que la conexión sea exitosa, se debe conectar al dispositivo a través de un punto de acceso.
El tutorial con el que se logró la conexión al robot EV3 a través de bluetooth está disponible en la siguiente dirección “https://sourceforge.net/p/lejos/wiki/Configuring%20Bluetooth%20PAN/”.