Integración de un laboratorio remoto de robótica dentro de la plataforma ILabVir

Integraci´on de un laboratorio remoto de rob´otica dentro de la plataforma ILabVir Roberto Carlini Director: Josep Fern`andez 16 de julio de 2015 E. T. I. S. Facultad de Inform´atica de Barcelona (UPC) ´ Indice ´ Indice 1 1. Prefacio 4 1.1. Origen del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Motivaci´on ............................ 4 1.2.1. Motivaci´on personal . . . . . . . . . . . . . . . . . . . 6 2. Introducci´ on 7 2.1. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . 7 3. Especificaci´ on 8 3.1. Requisitos............................. 8 3.1.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . 8 3.1.2. Requisitos no funcionales . . . . . . . . . . . . . . . . 8 3.2. Casosdeuso ........................... 9 3.2.1. Casos de uso del administrador . . . . . . . . . . . . . 9 3.2.2. Casos de uso del profesor . . . . . . . . . . . . . . . . 11 3.2.3. Casos de uso de alumno . . . . . . . . . . . . . . . . . 14 4. An´ alisis tecnol´ ogico y estado del arte 17 4.1. Interacci´on local con el robot . . . . . . . . . . . . . . . . . . 17 4.1.1. Bluetooth......................... 19 4.2. Interacci´on remota con el robot . . . . . . . . . . . . . . . . . 20 1 4.3. Interacci´on entre el robot y la plataforma Moodle . . . . . . . 21 4.3.1. LTI ............................ 23 4.4. Streaming de v´ıdeo . . . . . . . . . . . . . . . . . . . . . . . . 27 4.5. Editor enriquecido . . . . . . . . . . . . . . . . . . . . . . . . 29 4.6. Lenguajes ............................. 29 4.6.1. Java............................ 29 4.6.2. Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . 29 4.6.3. PHP............................ 30 4.6.4. HTML........................... 30 4.6.5. CSS ............................ 30 4.6.6. JavaScript......................... 31 4.6.7. JQuery .......................... 31 4.7. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . 32 4.7.1. BricxCC.......................... 32 4.7.2. Eclipse........................... 33 4.7.3. NetBeans ......................... 34 5. Arquitectura y dise˜ no 35 5.1. Librer´ıa puente y servicio web . . . . . . . . . . . . . . . . . . 36 5.1.1. Diagrama de clases . . . . . . . . . . . . . . . . . . . . 36 5.1.2. Descripci´on de las clases . . . . . . . . . . . . . . . . . 36 5.2. M´oduloLTI............................ 37 5.2.1. Diagrama de clases . . . . . . . . . . . . . . . . . . . . 37 5.2.2. Descripci´on de las clases . . . . . . . . . . . . . . . . . 37 5.2.3. Diagramas de secuencia . . . . . . . . . . . . . . . . . 38 2 5.2.4. Estructura de pantallas . . . . . . . . . . . . . . . . . 43 6. Implementaci´ on 45 6.1. Librer´ıa de interacci´on con el robot NXT . . . . . . . . . . . 45 6.2. Servicioweb............................ 50 6.3. Prototipo de pruebas . . . . . . . . . . . . . . . . . . . . . . . 51 6.4. ServicioLTI............................ 54 7. Pruebas 57 8. Planificaci´ on y costes 60 8.1. Planificaci´on ........................... 60 8.2. Planificaci´on y costes . . . . . . . . . . . . . . . . . . . . . . . 61 8.2.1. Planificaci´on . . . . . . . . . . . . . . . . . . . . . . . 61 8.2.2. Costes indirectos . . . . . . . . . . . . . . . . . . . . . 62 8.2.3. Costes directos y total . . . . . . . . . . . . . . . . . . 63 9. Conclusiones 64 9.1. Mejoras y trabajo futuro . . . . . . . . . . . . . . . . . . . . . 65 Referencias 67 Anexos 68 I. Modificaci´on Yawcam . . . . . . . . . . . . . . . . . . . . . . 68 II. RegistroLTI ........................... 70 3 1. Prefacio 1.1. Origen del proyecto Este PFC se inscribe dentro de iLabVir, un proyecto de investigaci´on y de innovaci´on educativa en el que participa la UPC. Este proyecto tiene como finalidad el desarrollo de una plataforma de interoperabilidad para el fomento, difusi´on, explotaci´on y gesti´on de laboratorios virtuales y remotos para la realizaci´on de pr´acticas reales a distancia y experimentos online, con acceso remoto a trav´es de Internet, de materias cient´ıficas y tecnol´ogicas. En concreto, iLabVir pretende implementar una plataforma que permita integrar diferentes tipos de laboratorios virtuales y remotos, con independencia de la tecnolog´ıa empleada por cada uno de ellos, as´ı como posibilitar su incorporaci´on dentro de una plataforma de e-learning como, por ejemplo, Moodle. 1.2. Motivaci´on La irrupci´on de las nuevas tecnolog´ıas de la informaci´on y la comunicaci´on (TIC) est´a provocando cambios muy importantes en nuestra sociedad, los cuales afectan a ´ambitos tan diversos como el laboral, el social, el del ocio, el cultural o el educativo. En la actualidad, estas tecnolog´ıas son un elemento de desarrollo y de transformaci´on social y econ´omica tan relevante como lo fueron en su ´epoca la rueda, la imprenta o la m´aquina de vapor. En el ´ambito universitario, en la educaci´on secundaria, en la formaci´on profesional y en la educaci´on a distancia, la ense˜nanza de las materias cient´ıficas y tecnol´ogicas debe conjugar de manera equilibrada la cimentaci´on cient´ıfico necesaria para comprender los fen´omenos y las aplicaciones b´asicas, el conocimiento de las soluciones t´ecnicas en una gama amplia de aplicaciones, y finalmente, la experimentaci´on pr´actica que permitan al alumnado, de forma adecuada, la adquisici´on de las competencias b´asicas. Dada la importancia que, para la formaci´on acad´emica de los alumnos, tiene la realizaci´on de experimentos y pr´acticas en estas materias, hay que potenciar la formaci´on pr´actica y buscar nuevas formas de acceso a los recursos que ofrecen los laboratorios de experimentaci´on y los talleres de pr´acticas. Sin embargo, en la concepci´on tradicional, la implantaci´on y el uso de los laboratorios docentes y de las aulas-taller en los centros educativos est´an 4 limitados y condicionados por factores econ´omicos, espaciales y temporales: Factores econ´ omicos El elevado coste que representa la adquisici´on y mantenimiento de equipamiento dificulta enormemente la renovaci´on y la ampliaci´on de los laboratorios y aulas-taller. Factores espaciales La masificaci´on y la falta de espacio en los centros educativos impide disponer de suficientes laboratorios y aulas-taller. Factores temporales El horario de acceso a los laboratorios y en las aulastaller est´a restringido a determinadas horas dentro del horario escolar y con la presencia de profesorado responsable. Por lo tanto, permanece cerrado y infrautilizado durante bastante tiempo. Todos estos factores constituyen una enorme barrera que impide un uso m´as racional, amplio y flexible de los recursos existentes en los centros educativos para la formaci´on pr´actica. Sin embargo, este obst´aculo se puede reducir notablemente usando nuevos recursos innovadores, como las diversas variantes de Laboratorios Virtuales (monol´ıticos, distribuidos o h´ıbridos, se trata, b´asicamente, de aplicaciones y sistemas de simulaci´on) y de Laboratorios Remotos. En estos ´ultimos, se accede a trav´es de Internet a un sistema f´ısico real para su manipulaci´on directa o experimentaci´on en tiempo real. Figura 1: Esquema simplificado de un laboratorio remoto Los laboratorios virtuales y remotos pretenden contribuir positivamente, y de una manera activa, en el aprendizaje de materias cient´ıficas y tecnol´ogicas de la ESO y del bachillerato (tecnolog´ıas, electrotecnia, tecnolog´ıa electr´onica, tecnolog´ıa industrial, f´ısica, ciencias experimentales,...), de la formaci´on profesional y ocupacional, de la formaci´on a distancia y de la formaci´on continua empresarial. Asimismo, permiten que instituciones y centros educativos de Catalu˜na (y tambi´en del resto del estado espa˜nol) puedan llevar a cabo determinadas 5 pr´acticas reales y experimentos online con acceso remoto mediante Internet, muchos de los cuales no son posibles de realizar actualmente en los centros educativos por falta de equipamiento espec´ıfico. Tambi´en se pone al alcance de los centros de ense˜nanza, los docentes y los estudiantes un valioso recurso tecnol´ogicamente avanzado, con un gran potencial de futuro, que integra plenamente las TIC. Por lo tanto, sus aplicaciones en la ense˜nanza de materias cient´ıficas y tecnol´ogicas, y en diferentes niveles educativos, son numerosas. Y la contribuci´on esperada muy v´alida y eficaz, dado que permite aumentar el nivel de acceso a la realizaci´on de pr´acticas y experimentos con un menor coste de gesti´on, personal, mantenimiento y desplazamientos, ofrece un recurso complementario ´util e innovador, y fomenta el uso de las TIC. 1.2.1. Motivaci´ on personal En cuanto a la motivaci´on a nivel personal, creo que este proyecto resulta interesante por diversos motivos. El primero, porque es el desarrollo de una aplicaci´on full stack, esto es, que abarca todos los niveles, desde el m´as bajo, que ser´ıa el robot, hasta el m´as alto, que ser´ıa la interfaz de usuario a trav´es de la plataforma de aprendizaje. Tambi´en soy consciente del riesgo que supone siempre este tipo de aplicaciones y, sobre todo, el ser desarrolladas por una sola persona. Como segundo motivo, est´an las tecnolog´ıas involucradas. Estoy interesado tanto en los robots NXT como en las plataformas de aprendizaje y las posibilidades que presentan. Y finalmente, la vertiente m´as social del proyecto, el hecho de que al poner un laboratorio en internet supone ampliar las posibilidades de acceso al conocimiento. 6 2. Introducci´on 2.1. Objetivos del proyecto El presente proyecto consiste en la implementaci´on e integraci´on de un laboratorio remoto de rob´otica integrado en una plataforma de aprendizaje online (iLabVir/Moodle). Se desea poder realizar las mismas pr´acticas que actualmente se realizan en el laboratorio, de forma remota. Dichas pr´acticas se realizan ejecutando c´odigo NXC sobre robots Mindstorm NXT en entornos Windows XP. Dados estos prerrequistos, se desarrollar´a una soluci´on que permita hacer uso de los recursos ya existentes para realizar pr´acticas remotamente. Entrando en detalle, los objetivos ser´ıan los siguientes: Encontrar o implementar un m´etodo para compilar c´odigo NXC y ejecutarlo en un robot, recogiendo el output de texto, tanto mensajes del compilador como mensajes de la ejecuci´on. Retransmitir el v´ıdeo de lo que sucede en el laboratorio cuando se lanza una ejecuci´on. Implementar un m´odulo de pr´actica para la plataforma de aprendizaje Moodle, que integre los objetivos anteriores, permitiendo realizar una pr´actica remotamente. 2.2. Alcance del proyecto Aunque inicialmente la intenci´on del proyecto era la integraci´on dentro de la plataforma iLabVir, debido a problemas t´ecnicos se limit´o a la integraci´on en la plataforma Moodle, plataforma base del proyecto iLabVir. De esta forma, una vez solventados los mencionados problemas t´ecnicos, la integraci´on dentro de iLabVir resultar´ıa sencilla. Por tanto el alcance del proyecto se limita a la implementaci´on de una versi´on inicial del laboratorio remoto de rob´otica, en la que ser´a posible ejecutar c´odigo y ver el resultado de dicha ejecuci´on, y la integraci´on de dicho laboratorio en la plataforma Moodle. 7 3. Especificaci´on 3.1. Requisitos 3.1.1. Requisitos funcionales Gestionar pr´acticas de laboratorio, esto es, crear, modificar y eliminar pr´acticas. Realizar una pr´actica determinada mediante el desarrollo, compilaci´on y ejecuci´on de c´odigo en el navegador. Revisi´on del resultado de la ejecuci´on, tanto en forma de texto (traza) como en v´ıdeo. Entregar el resultado final para una revisi´on posterior. Revisar las pr´acticas entregadas, pudiendo ejecutarlas y evaluarlas. 3.1.2. Requisitos no funcionales Modularidad El sistema debe asegurar la independencia del sistema del laboratorio con respecto a la plataforma de ense˜nanza en l´ınea. Escalabilidad El sistema debe permitir tanto m´ultiples clientes desde la plataforma de ense˜nanza como m´ultiples bancos de trabajo. Seguridad El sistema debe asegurar que la identidad de los actores no puede ser suplantada, en la medida de lo posible. 8 Ejecutar c´ odigo mediante un fichero Descripci´ on El usuario desea ejecutar c´odigo enviado por fichero. Actor Alumno Precondici´ on El usuario est´a autenticado como alumno en un Moodle autorizado y se encuentra en la vista principal de la pr´actica. Postcondici´ on El sistema muestra al usuario el resultado de la ejecuci´on del c´odigo. Flujo principal 1. El usuario selecciona el fichero de c´odigo a enviar. 2. El usuario selecciona la opci´on de enviar fichero de c´odigo. 3. El sistema ejecuta el c´odigo y le muestra el resultado al usuario. Visualizar el resultado (texto) Descripci´ on El usuario desea analizar el resultado en formato texto de la ejecuci´on del c´odigo. Actor Alumno Precondici´ on El usuario est´a autenticado como alumno en un Moodle autorizado, se encuentra en la vista principal de la pr´actica y ha selecciona la ejecuci´on de c´odigo. Postcondici´ on El sistema muestra al usuario la salida de texto de la ejecuci´on del c´odigo. Flujo principal 1. El sistema muestra al usuario la salida de texto de la ejecuci´on del c´odigo. Visualizar el resultado (streaming de v´ ıdeo) Descripci´ on El usuario desea analizar visualmente el resultado de la ejecuci´on del c´odigo. Actor Alumno Precondici´ on El usuario est´a autenticado como alumno en un Moodle autorizado, se encuentra en la vista principal de la pr´actica y ha selecciona la ejecuci´on de c´odigo. Postcondici´ on El sistema muestra al usuario el resultado de la ejecuci´on del c´odigo. Flujo principal 1. El sistema retransmite lo que ocurre en el laboratorio durante la ejecuci´on. 15 Enviar c´ odigo final a evaluar Descripci´ on El usuario desea enviar el c´odigo final a evaluar. Actor Alumno Precondici´ on El usuario est´a autenticado como alumno en un Moodle autorizado y se encuentra en la vista principal de la pr´actica. Postcondici´ on El sistema confirma el registro del c´odigo como final. Flujo principal 1. El usuario introduce el c´odigo, ya sea a trav´es del editor o mediante fichero. 2. El usuario selecciona la opci´on de enviar para evaluar. 3. El sistema confirma el registro del c´odigo como versi´on a evaluar. 16 4. An´alisis tecnol´ogico y estado del arte 4.1. Interacci´on local con el robot Antes de entrar a evaluar las tecnolog´ıas disponibles, es necesario realizar un an´alisis de los robots LEGO Mindstorms NXT y su estado actual LEGO Mindstorms NXT es un kit de robots programables lanzados por LEGO en 2006 que ven´ıan a reemplazar al kit de primera generaci´on de LEGO Mindstorms. Este nuevo kit inclu´ıa un bloque que controlaba el sistema, un conjunto de sensores y motores y varios componentes LEGO de la serie Technic para poder montar sistemas mec´anicos. Figura 5: Imagen del kit LEGO Mindstorms NXT Existen dos generaciones de LEGO Mindstorms NXT, la segunda lanzada en 2009, y desde 2013 han sido sustituidos por un nuevo robot Mindstorms, el EV3. En el laboratorio se trabaja con robots NXT de segunda generaci´on. La instalaci´on del software necesario para manejar los robots es sencilla. En el kit viene un CD con los drivers necesarios y el programa NXT-G, un entorno gr´afico de programaci´on mediante bloques que permite construir algoritmos para ser ejecutados por el robot. Los diferentes bloques represen17 tan tanto estructuras l´ogicas como dispositivos f´ısicos, como los sensores, los motores o la pantalla del robot NXT. Figura 6: Captura del entorno NXT-G Por otro lado, la herramienta usada en el laboratorio es BricxCC, un IDE que permite escribir, compilar y ejecutar programas sobre un robot NXT. Adem´as, tiene una serie de utilidades que permiten la interacci´on con el robot de independientemente del IDE1. Next Byte Codes (NBC) y Not eXactly C (NXC) son dos lenguajes libres que pueden usarse para programar robots NXT en BricxCC. NBC es un lenguaje con sintaxis de ensamblador y NXC es un lenguaje de alto nivel, similar a C, construido sobre el compilador NBC. NXC es uno de los lenguajes de programaci´on para NXT m´as extendidos, usado incluso para programar videojuegos dentro de un brick de NXT. De entre las distintas utilidades para NXT que existen, sobresalen dadas nuestras necesidades dos de ellas: NeXTTool Es un programa de l´ınea de comandos de Windows que permite hablar con el robot NXT. Es compatible con una amplia variedad de acciones, como por ejemplo descargar el firmware NXT, descargar 1http://bricxcc.sourceforge.net/utilities.html 18 y cargar archivos desde y hacia el NXT, comprobar el nivel de la bater´ıa, la reproducci´on de archivos de sonido y melod´ıa, tocando tonos, listando todos los archivos en el NXT, y la entrada de la lectura y valores de salida. Compilador NBC Es un programa de l´ınea de comandos que compila c´odigo NXC o NBC en programas que se pueden ejecutar sobre el firmware est´andar del NXT o sobre el firmware mejorado. El compilador NBC permite tanto guardar la salida del compilador en un archivo como subirlo al NXT para su ejecuci´on. A pesar de que las funcionalidades se superponen entre las dos herramientas, el compilador NBC es la ´unica herramienta que permite la compilaci´on de c´odigo NXC fuera del entorno de BricxCC. Por tanto, en cuanto a programas de consola, la primera elecci´on es el compilador NBC. Existen herramientas para compilar y ejecutar c´odigo en otros lenguajes, como java (leJOS NXT) o C#, pero por desgracia no se han encontrado ning´un compilador en forma de librer´ıa para NXC (el IDE BricxCC permite compilar el c´odigo dentro de la plataforma; se examin´o la posibilidad de extraer esta funcionalidad o usarla de forma independiente, pero al estar implementado en Delphi, un lenguaje de programaci´on con el que no estoy familiarizado, no consegu´ı llevarlo a cabo). Por tanto ´unica opci´on disponible es implementar un wrapper alrededor del compilador NBC para poder usarlo como una API. Aunque la fiabilidad de esta herramienta deja un poco que desear, al ser la ´unica opci´on viable, es la escogida, a´un siendo conscientes de que no es la m´as elegante. 4.1.1. Bluetooth Menci´on aparte merece la conexi´on Bluetooth. Durante la evaluaci´on de la interacci´on por Bluetooth se comprob´o que, al menos en el entorno donde se desarroll´o este PFC, la configuraci´on necesaria para poder usar la conexi´on Bluetooth es complicada y a´un as´ı no garantiza una conexi´on estable. El problema reside en que cuando intentamos conectar por Bluetooth, siempre sale el mensaje “Line is busy” En primera instancia, parec´ıa que el problema resid´ıa en el driver por defecto de Windows XP, de hecho, BricxCC recomienda instalar los dri19 vers Fantom2. Seguimos las instrucciones, instalamos el driver, pero sigue sucediendo lo mismo. Buscando m´as soluciones, parece que hay ciertos drivers Bluetooth concretos que permiten que funcione bien3. Al parecer, solo las versiones 1.4.x.x y 5.0.x.x de los drivers Bluetooth de Widcomm funcionan correctamente. Estos drivers est´an descatalogados, pero a´un se pueden encontrar en las redes P2P. Despu´es de varias tentativas, se consigue instalar una versi´on que funciona. 4.2. Interacci´on remota con el robot La interacci´on entre Moodle y el laboratorio de rob´otica se realizar´a mediante un servicio web. Un servicio web es una tecnolog´ıa que, mediante un conjunto de protocolos y est´andares, permite el intercambio de datos entre aplicaciones de software. Estas aplicaciones pueden estar desarrolladas en distintos lenguajes de programaci´on y ejecutadas en distintas plataformas. Existen varios est´andares de intercambio de datos, rese˜naremos los m´as relevantes: SOAP (Simple Object Access Protocol) es un protocolo est´andar que define c´omo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. RPC (Remote Procedure Call) es un protocolo de comunicaci´on entre procesos que permite a un programa llamar a una funci´on o m´etodo de otro programa. Tanto XML-RPC como JSON-RPC son versiones simples del protocolo, definiendo un reducido set de tipos b´asicos con los cuales representar datos. REST (Representational State Transfer) originalmente se refer´ıa a un conjunto de principios de arquitectura, aunque en la actualidad se usa en el sentido m´as amplio para describir cualquier interfaz entre sistemas que utilice directamente HTTP para obtener datos o indicar la ejecuci´on de operaciones sobre los datos, en cualquier formato (XML, JSON, etc) sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes, como por ejemplo SOAP. De entre las opciones disponibles, se escogi´o REST por su simplicidad 2http://bricxcc.sourceforge.net/NXTFantomDriverHelp.pdf 3http://nxtemplar.blogspot.com.es/2006/10/bluetooth-nxt-robotics-studio.html 20 (frente a SOAP), el desacoplamiento (frente a RPC) y ser uno de los est´andares m´as extendidos actualmente. 4.3. Interacci´on entre el robot y la plataforma Moodle Antes de entrar en particular a examinar las opciones en cuanto al m´odulo, realizaremos una peque˜na descripci´on de Moodle, plataforma hacia la que se orienta el proyecto. Moodle es una plataforma de aprendizaje de distribuci´on libre, que ayuda a los educadores a crear comunidades de aprendizaje en l´ınea. Este tipo de plataformas tecnol´ogicas tambi´en se conocen como LMS (Learning Management System). Estas herramientas son de gran utilidad en el ´ambito educacional, ya que permiten a los profesores la gesti´on de cursos virtuales para sus alumnos (educaci´on a distancia o e-learning), o la utilizaci´on de un espacio en l´ınea que d´e apoyo a la presencialidad (aprendizaje semipresencial, blended learning o b-learning). Moodle promueve una pedagog´ıa constructivista social (colaboraci´on, actividades, reflexi´on cr´ıtica, etc.). Su arquitectura y herramientas son apropiadas para clases en l´ınea, as´ı como tambi´en para complementar el aprendizaje presencial Dentro de Moodle podemos distinguir, entre otros, tres roles principales con distintas responsabilidades y funciones: Administrador Es responsable de la instalaci´on, puesta en marcha y mantenimiento del Moodle. Se encarga de crear las categor´ıas y cursos que ser´an visibles en la plataforma, as´ı como del aspecto y funcionalidades de la misma. Profesor Genera el contenido del curso. Define e inserta los recursos que considere necesarios para el ´optimo aprendizaje de su asignatura. Plantear actividades variadas que posibiliten la participaci´on y el aprendizaje activo del alumnado. Acompa˜nar y evaluar a sus estudiantes a trav´es de las herramientas de comunicaci´on y las actividades de evaluaci´on que proporciona la plataforma. 21 Alumno Consulta contenidos a trav´es de los materiales y recursos facilitados por el docente (archivos, enlaces web, v´ıdeos...) Realiza actividades por medio de los foros, cuestionarios, subida de archivos, wikis... Interactuar con los compa˜neros y docentes haciendo uso de los foros y chats. A parte de la administraci´on del propio sitio, de los usuarios y de los cursos, Moodle tambi´en ofrece un conjunto de actividades y recursos predefinidos (bloques) para los cursos, como pueden ser los foros, wikis, tareas, cuestionarios, etc. Tambi´en permite a˜nadir nuevos tipos de bloques, en el caso de que los gen´ericos no se ajustaran a un tipo de actividad o recurso. Dado que queremos integrar el laboratorio en esta plataforma de ense˜nanza online, de nuevo se nos presentan dos opciones: Implementar un tipo nuevo de actividad de Moodle. Aprovechar uno de los tipos preexistentes y adaptarlo a nuestras necesidades. La primera opci´on presentaba como ventajas el hecho de ajustar bien el comportamiento de la actividad a nuestras necesidades, frente a los inconvenientes de la curva de aprendizaje necesaria para implementar dicha actividad y el hecho de que esta actividad no ser´ıa compatible con otras plataformas, por lo que deber´ıa ser reimplementada si se quisiera usar. Examinando esta posibilidad, se vio que la curva de aprendizaje era un coste bastante alto, por lo que se evaluaron otras posibilidades. Para la segunda opci´on, de entre las actividades existentes nos centraremos en la actividad Herramienta externa. Esta actividad permite insertar como una actividad una herramienta externa un recurso que cumpla el est´andar LTI desde otra web. Esta opci´on vence una de las desventajas de la anterior, ya que varias plataformas de aprendizaje tanto aceptan como implementan el est´andar LTI. Sigue existiendo el inconveniente con respecto al aprendizaje, pero es menor, ya que hay librer´ıas que implementan el est´andar de forma transparente. 22 4.3.1. LTI El est´andar LTI (Learning Tools Interoperability) es un est´andar creado por IMS Global Learning Consortium4. Sus objetivos son: Proporcionar un modelo de implementaci´on sencilla consistente en una URL, una clave y un token secreto que el administrador LMS o el instructor del curso puedan usar en la plataforma de aprendizaje. Definir un protocolo para el lanzamiento de una aplicaci´on externa a la plataforma, de forma que soporte un inicio de sesi´on ´unico y que conserve el contexto de aprendizaje y los roles dentro de ese contexto. Hacer que los enlaces a aplicaciones externas sean portables mediante la definici´on de elementos de datos que se pueden incrustar en IMS Common Cartridges5(otro est´andar de IMS que no abordaremos en el presente documento). Conceptos b´ asicos El flujo de trabajo b´asico para utilizar LTI se inicia cuando el instructor o administrador LMS accede a una herramienta de aprendizaje externa alojada. El administrador de la herramienta proporciona al administrador o al instructor una URL, una clave y un token secreto para la herramienta. Para el caso de uso del Instructor, por lo general, se a˜nade la herramienta LTI a la estructura del curso como un enlace a un recurso mediante el panel de control de la plataforma de aprendizaje. El instructor introduce la URL, el token secreto y la clave como metadatos del enlace al recurso. Cuando los estudiantes seleccionan la herramienta, la plataforma de aprendizaje utiliza la URL, el token secreto y la clave para transferir de forma transparente al estudiante a la herramienta externa en un iframe o una nueva ventana del navegador. Para el caso de uso de administrador, por lo general, a˜naden una “herramienta virtual” a la plataforma de aprendizaje, introduciendo la direcci´on URL, el token secreto y la clave. Una vez hecho esto, los instructores simplemente ven la herramienta LTI reci´en configurada como otra herramienta o actividad, que puede ser usada como un recurso m´as en su estructura del curso. Es posible que ni instructores ni estudiantes sean conscientes de que 4http://www.imsglobal.org/ 5http://www.imsglobal.org/cc/ 23 la herramienta que est´an utilizando est´an ejecut´andose fuera de la plataforma. Ellos simplemente seleccionan y utilizan la herramienta como cualquier otra herramienta interna. En ambos casos, la herramienta externa recibe una solicitud de lanzamiento que incluye la identidad del usuario, informaci´on de los cursos, informaci´on de funciones, la clave y la firma. La informaci´on de lanzamiento se env´ıa mediante un formulario HTTP generado en el navegador del usuario con los elementos de datos LTI en campos de formulario ocultos y autom´aticamente enviados a la herramienta externa mediante JavaScript. Los datos en el formulario HTTP se firman con el est´andar de seguridad OAuth6por lo que la herramienta externa puede estar segura de que los datos de lanzamiento no se modificaron entre el momento en que la plataforma genera y firma los datos y el momento en que la herramienta recibe esos datos. Una vez recibida la solicitud del lanzamiento, la herramienta puede optar por redirigir el navegador del usuario a otra URL o puede generar directamente el contenido solicitado. Figura 7: Esquema de interacci´on de LTI 6www.oauth.net 24 4.6.6. JavaScript Javascript es un lenguaje de scripting basado en el concepto de prototipos (herencia por delegaci´on), implementado originariamente para Netscape Communications Corporation, y que deriv´o en el est´andar ECMAScript. Se conoce sobre todo por su use en p´aginas web, pero tambi´en se utiliza en otras aplicaciones. A pesar de su nombre, Javascript no deriva del lenguaje de programaci´on Java, pero ambos comparten una sintaxis similar inspirada en el lenguaje C. Sem´anticamente, Javascript est´a m´as pr´oximo a lenguajes como Self o ActionScript (basado tambi´en en ECMASCRIPT). Esta tecnolog´ıa nos permite actualizar contenidos de la web sin tener que recargar la p´agina. 4.6.7. JQuery JQuery es una librer´ıa de JavaScript creada para simplificar la manera de interactuar con los objetos HTML. Mediante JQuery es posible manejar eventos, desarrollar animaciones, etc. de manera sencilla. JQuery es la librer´ıa de Javascript m´as usada. 31 4.7. Herramientas de desarrollo 4.7.1. BricxCC Bricx Command Center (BricxCC) es un entorno de desarrollo integrado (IDE, de sus siglas en ingl´es) multiplataforma para programar robots LEGO Mindstorms de cualquier generaci´on, incluyendo los de tercera generaci´on EV3. BricxCC incluye soporte para programar en Not eXactly C (NXC) y Next Byte Codes (NBC), entre otras opciones. BricxCC est´a implementado en Delphi y el c´odigo fuente licenciado bajo la Mozilla Public Licence, siendo por tanto de libre modificaci´on, distribuci´on y uso, incluso con fines comerciales. Figura 9: BricxCC IDE 32 4.7.2. Eclipse Eclipse es uno de los entornos de desarrollo integrado (IDE) multiplataforma m´as famosos, siendo la principal opci´on, junto a NetBeans, para programar en Java. Gracias a un sistema de plugins que le dota de una gran flexibilidad, se puede usar para programar en otros lenguajes o para a˜nadir funcionalidades que permitan programar mejor en funci´on del entorno, para aplicaciones web o de escritorio, por ejemplo. Escrito principalmente en Java, est´a licenciado bajo la Eclipse Public License, siendo por tanto de libre modificaci´on, distribuci´on y uso, incluso con fines comerciales. En este proyecto se ha usado para programar las partes en Java, esto es, la librer´ıa de interacci´on con el robot y el servicio web REST. Figura 10: Eclipse IDE 33 4.7.3. NetBeans NetBeans es el entorno de desarrollo integrado (IDE) multiplataforma oficial de Java, siendo desarrollado y mantenido por Oracle Sun. Orientado principalmente a Java, tambi´en soporta otros lenguajes, en particular PHP, C/C++ y HTML5. De forma similar a Eclipse, NetBeans tiene un sistema de m´odulos que permite ajustarlo a la tarea que se quiere llevar a cabo, ya sea mediante m´odulos oficiales o m´odulos desarrollados por terceros. Escrito en Java, se licenci´o inicialmente bajo la est´a licenciado bajo la Common Development and Distribution License (CDDL) de Sun. Posteriormente, se convirti´o a licencia dual al ofrecer tambi´en licenciar bajo la GNU General Public License v2 (GPL-2). Esto permite escoger entre la CDDL, una licencia que permite la libre modificaci´on, distribuci´on y uso, incluso con fines comerciales, y la GPL-2, una licencia m´as restrictiva, pues fuerza a liberar el c´odigo y licenciar los trabajos derivados bajo la misma licencia. En este proyecto se ha usado para programar las partes en PHP, esto es, el m´odulo LTI. Figura 11: NetBeans IDE 34 5. Arquitectura y dise˜no La arquitectura constar´a de las siguientes partes: Robot NXT La pr´actica se realizar´a sobre este robot. Se conectar´a con la librer´ıa puente mediante cable USB o Bluetooth. Librer´ ıa puente Realiza todas las tareas relativas al robot, esto es, compila y carga el c´odigo, lanza la ejecuci´on de ´este, registra los mensajes y los posibles errores de compilaci´on o ejecuci´on. Servicio web Permite la interacci´on entre la librer´ıa puente y el servicio LTI. Modulo LTI Capa adicional que permite el acceso a las pr´acticas desde cualquier plataforma de ense˜nanza en l´ınea que cumpla este est´andar. Plataforma Moodle Es la plataforma que gestiona todo lo referente a los cursos. Debe permitir la creaci´on de una actividad que interact´ue con el servicio LTI. Figura 12: Diagrama de clases de la librer´ıa puente 35 5.1. Librer´ıa puente y servicio web 5.1.1. Diagrama de clases A continuaci´on se muestran la clases implicadas en la librer´ıa puente y el servicio web. Figura 13: Definici´on de clases 5.1.2. Descripci´ on de las clases Status: Es una enumeraci´on que permite codificar los diferentes estados finales de un resultado. Valores: COMPILATION ERROR Ha ocurrido un error de compilaci´on. DOWNLOAD ERROR No se ha podido transferir el programa al robot. SUCCESS El programa se ha podido compilar o compilar, transferir y ejecutar con ´exito. IO EXCEPTION Ha ocurrido un error de I/O durante la ejecuci´on del proceso de compilaci´on y transferencia. INTERRUPTED EXCEPTION La ejecuci´on del proceso de compilaci´on y transferencia ha sido interrumpida. Result: Esta clase contiene toda la informaci´on referente al resultado de una acci´on de la librer´ıa. Atributos: 36 status El estatus de final de la ejecuci´on. info Output de texto de la ejecuci´on. exitVal Valor de salida de la ejecuci´on. NXTBridge: Esta clase contiene las funciones necesarias para interactuar con el robot. RobolabREST: Esta clase se encarga de ofrecer los m´etodos REST necesarios para interactuar con el robot. 5.2. M´odulo LTI En esta secci´on se detallar´a el dise˜no de pantallas y de base de datos del m´odulo LTI. Para simplificar el desarrollo, se unificaron los actores Administrador y Profesor en uno solo, de manera que se dise˜nar´an ambos casos de uso para un usuario con rol profesor. Los casos de uso de Alumno se dise˜nar´an para el rol de estudiante. 5.2.1. Diagrama de clases Figura 14: Estructura de la base de datos de pr´acticas 5.2.2. Descripci´ on de las clases Exercise: Representa la especificaci´on del ejercicio, esto es, toda la informaci´on relativa a un ejercicio o pr´actica Atributos: id Identificador de la pr´actica. consumer key Clave que identifica al consumidor. 37 resource id Identificador ´unico (propio del consumidor) del recurso que accede al servicio LTI. title T´ıtulo de la pr´actica. description Descripci´on o enunciado de la pr´actica. sample code C´odigo fuente de muestra de la pr´actica, si lo tiene. owner Identificador del usuario que cre´o la pr´actica. visible Determina si la pr´actica est´a disponible o no. created Fecha en la que la pr´actica fue creada. modified Fecha en la que la pr´actica fue modificada por ´ultima vez. Atributos: Submission: id Identificador de la entrega. exercise Identificador de la pr´actica. user Identificador del usuario que hace la entrega. code C´odigo enviado a trav´es del editor de texto. code file C´odigo entregado mediante un fichero. evaluation Evaluaci´on asignada por el profesor una vez revisada la entrega. created Fecha en la que la pr´actica fue creada. modified Fecha en la que la pr´actica fue modificada por ´ultima vez. 5.2.3. Diagramas de secuencia Para crear una pr´actica, el usuario administrador debe crear un bloque de tipo ’herramienta externa’ e introducir los datos necesarios. El m´as importante es la clave de consumidor, que identifica a la plataforma dentro del m´odulo LTI. Una vez creado el bloque, Moodle enviar´a la clave de consumidor y el identificador de recurso, que es el identificador ´unico del bloque en esta instancia de Moodle, al m´odulo LTI, que crear´a una pr´actica nueva. Figura 15: Secuencia para caso de uso: Crear pr´actica Una vez que una pr´actica se ha creado, siempre que el administrador 38 acceda a ese bloque, podr´a editarlo y guardar las modificaciones. Para eso es necesaria la informaci´on de identificaci´on (clave de consumidor, identificador de recurso) y la informaci´on nueva de la pr´actica Figura 16: Secuencia para caso de uso: Editar y guardar pr´actica Para eliminar una pr´actica, sencillamente se elimina el bloque de Moodle. Figura 17: Secuencia para caso de uso: Eliminar pr´actica Al acceder a una pr´actica como profesor, las credenciales del usuario ser´an enviadas al m´odulo, para que este pueda mostrar la vista asociada al profesor, donde podr´a ver las pr´acticas entregadas, ejecutarlas y evaluarlas. Figura 18: Secuencia para caso de uso: Acceder a pr´actica (Profesor) 39 Las pr´acticas entregadas se mostrar´an como un listado con informaci´on relativa a cada una de ellas y la evaluaci´on asignada. Figura 19: Secuencia para caso de uso: Ver pr´acticas entregadas Al seleccionar una pr´actica entregada, el profesor puede querer ejecutarla. Para eso, el m´odulo LTI mostrar´a la vista de ejecuci´on con la informaci´on de la pr´actica entregada. Figura 20: Secuencia para caso de uso: Ver informaci´on de una pr´actica Desde la vista de ejecuci´on, el profesor enviar´a el c´odigo entregado para que se ejecute, examinando el resultado de la ejecuci´on. Figura 21: Secuencia para caso de uso: Ejecutar una pr´actica Desde la vista de ejecuci´on, el profesor podr´a evaluar la pr´actica entregada. 40 7Runtime rt = Runtime.getRuntime(); 8try { 9System.out.println(Arrays.toString(command)); 10 11 Process pr = rt.exec(command); 12 13 // any error message? 14 StreamGobbler errorGobbler = new StreamGobbler(pr.getErrorStream()); 15 16 // any output? 17 StreamGobbler outputGobbler = new StreamGobbler(pr.getInputStream()); 18 19 // kick them off 20 errorGobbler.start(); 21 outputGobbler.start(); 22 23 res.exitVal = pr.waitFor(); 24 25 if (!errorGobbler.isEmpty()) { 26 res.info = errorGobbler.getContent(); 27 res.status = Status.COMPILATION_ERROR; 28 29 }else { 30 String content = outputGobbler.getContent(); 31 res.info = content; 32 if (content.contains(DOWNLOAD_FAILED_MSG)) { 33 res.status = Status.DOWNLOAD_FAILED; 34 }else { 35 res.status = Status.SUCCESS; 36 } 37 } 38 39 }catch (IOException e) { 40 res.info = e.getMessage(); 41 res.status = Status.IO_EXCEPTION; 42 43 }catch (InterruptedException e) { 44 res.info = e.getMessage(); 45 res.status = Status.INTERRUPTED_EXCEPTION; 46 } 47 48 return res; 49 } Una vez descritas las piezas necesarias, las combinaremos para poder realizar las dos acciones principales de la librer´ıa: 47 Compilar La funci´on para compilar requiere como entrada un c´odigo en forma de texto y devolver´a el resultado encapsulado en un objeto Result. 1public static Result compile(String nxtCode) { 2 3try { 4File temp = codeToFile(nxtCode); 5String path = temp.getAbsolutePath(); 6Result res = launchCommand(new String[]{NBC_CMD, path}); 7temp.deleteOnExit(); 8return res; 9 10 }catch (IOException e) { 11 Result res = new Result(); 12 res.status = Status.IO_EXCEPTION; 13 res.info = e.getMessage(); 14 return res; 15 } 16 } Compilar y ejecutar La funci´on para compilar y ejecutar requiere como entrada un c´odigo en forma de texto y el alias de la conexi´on. Dichos alias son el input para la opci´on ’-S’ del comando nbc, en este caso, ’usb’ para usar la conexi´on por cable, ’BTH’ para usar la conexi´on bluetooth. Devolver´a el resultado encapsulado en un objeto Result. 1 2static String usbAlias = "usb"; 3static String bluetoothAlias = "BTH"; 4 5private static final String RESOURCE_OPT = "-S="; 6private static final String RUN_OPT = "-r"; 7 8public static Result run(String nxtCode, String alias) { 9try { 10 File temp = codeToFile(nxtCode); 11 String path = temp.getAbsolutePath(); 12 Result res = launchCommand(new String[]{NBC_CMD, RESOURCE_OPT + alias, RUN_OPT, path}); 13 temp.deleteOnExit(); 14 return res; 15 16 }catch (IOException e) { 17 Result res = new Result(); 18 res.status = Status.IO_EXCEPTION; 19 res.info = e.getMessage(); 20 return res; 48 21 } 22 } El output a˜nadido al objeto Result es solo la traza de consola de la herramienta nbc. A esa traza habr´ıa que a˜nadir los posibles mensajes que enviara el programa desde el c´odigo ejecutado en el robot NXT. Para ello usar´ıamos la siguiente pieza de c´odigo, que nos permite escuchar un puerto COM determinado a la espera de dichos mensajes: 1class SerialPortReader implements SerialPortEventListener { 2 3SerialPort serialPort; 4StringBuilder messages = new StringBuilder(); 5 6public SerialPortReader(SerialPort serialPort) { 7this.serialPort = serialPort; 8} 9 10 public void serialEvent(SerialPortEvent event) { 11 12 if (event.isRXCHAR() && event.getEventValue() > 0) {// If data is available 13 14 // Read data 15 try { 16 byte buffer[] = serialPort.readBytes(); 17 messages.append(new String(buffer)); 18 19 }catch (SerialPortException ex) { 20 System.out.println(ex); 21 } 22 23 }else { 24 // Do nothing 25 } 26 } 27 28 public String getMessages() { 29 return messages.toString(); 30 } 31 32 public void clearMessages() { 33 messages.setLength(0); 34 } 35 } 49 6.2. Servicio web La implementaci´on del servicio web REST resulta muy sencilla, gracias al uso de las anotaciones. Sencillamente se crean los m´etodos necesarios para cada punto de entrada y se anotan adecuadamente: Compilar 1@GET 2@Path("/compile/") 3@Produces("application/json") 4public Response compileGET(@QueryParam("data") String data) { 5return compilePOST(data); 6} 7 8@POST 9@Path("/compile/") 10 @Produces("application/json") 11 public Response compilePOST(@QueryParam("data") String data) { 12 13 Result res = NXTInterface.compile(data); 14 15 return Response.status(200) 16 .header("Access-Control-Allow-Origin", "*") 17 .entity(res) 18 .build(); 19 } Compilar y ejecutar 1 2boolean BTMode = false; 3 4@GET 5@Path("/run/") 6@Produces("application/json") 7public Response runGET(@QueryParam("data") String data) { 8return runPOST(data); 9} 10 11 @POST 12 @Path("/run/") 13 @Produces("application/json") 14 public Response runPOST(@QueryParam("data") String data) { 50 15 16 Result res; 17 if (BTMode) { 18 res = NXTInterface.runBT(data); 19 20 }else { 21 res = NXTInterface.run(data); 22 } 23 24 return Response.status(200) 25 .header("Access-Control-Allow-Origin","*") 26 .entity(res) 27 .build(); 28 } Rese˜nar´e a continuaci´on las anotaciones usadas y la funci´on de cada una de ellas: @Path Esta etiqueta permite definir la URI a la que responde el m´etodo. @GET/@POST Estas dos etiquetas indican el tipo de petici´on http que aceptan. @Produces Esta etiqueta indica el tipo de datos de respuesta, en este caso, JSON. Por otro lado, es importante mencionar la cabecera “Access-ControlAllow-Origin”. Esta cabecera permite acceder al servicio desde cualquier ubicaci´on, rodeando una medida de seguridad usada en lenguajes de script de cliente, como javascript o actionscript. Si fuera necesario, se podr´ıa ajustar el comportamiento para hacer un uso correcto de esta medidas de seguridad. 6.3. Prototipo de pruebas Con el objetivo de poder comprobar que la interfaz REST funcionaba apropiadamente, se implement´o un prototipo sencillo para poder compilar y ejecutar c´odigo desde el navegador. Para ello, se utiliz´o el servidor de streaming integrado en Yawcam. La aplicaci´on de Yawcam permite editar el contenido de la p´agina principal que muestra el servidor. Sin embargo, las posibilidades de edici´on son muy justas, as´ı que es mejor editar el fichero de la p´agina principal directamente. En el home del usuario, Yawcam crea un directorio ’.yawcam’, donde se encuentran todos los ficheros que el servidor muestra. En concreto, dentro 51 del directorio se encuentra el directorio ’stream’, que es donde el servidor busca la p´agina principal y por tanto contiene los ficheros html que habr´a que manipular. En principio, el fichero template js.html, que es el fichero de muestra para reproducir el stream via javascript, solo contiene el c´odigo para mostrar el stream de v´ıdeo, lo cual nos resulta muy ´util. Lo ´unico que hace falta a˜nadir, pues, es: El editor de texto. Los botones de compilar y ejecutar. El espacio para mostrar la respuesta de la compilaci´on/ejecuci´on. El c´odigo javascript que recoger´a el texto del editor y lo enviar´a al servicio REST. A su vez, mostrar´a la respuesta del servicio REST en el espacio preparado para mostrarla. A continuaci´on mostrar´e dos fragmentos de c´odigo que a˜naden cada uno de estos elementos. La l´ınea 2 del siguiente fragmento de c´odigo importa la librer´ıa necesaria para el editor enriquecido. De la 4 para adelante, se definen las funciones necesarias para acceder al servicio REST. 1 2<script src= " http: // cdn.jsdelivr.net/ ace /1.1.8/ min/ ace.js" type= " text / javascript " charset=" utf-8 " ></ script> 3 4<script> 5function compile () { 6sendCode("compile"); 7} 8 9function run () { 10 sendCode("run"); 11 } 12 13 function sendCode ( entryPoint ) { 14 var code =editor.getValue (); 15 16 var client =new XMLHttpRequest(); 17 client.open("GET","http://localhost:8080/ robolab-rs / robolab / service /" + entryPoint + "? data= " +code); 52 18 client.onreadystatechange =function() { 19 if (client.readyState == 4) { 20 if ( client.status == 200) { 21 var info =JSON.parse ( client.responseText ); 22 document.getElementById('status'). innerHTML =info.status; 23 document.getElementById('trace '). innerHTML =info.info.replace(/\n/g,"<br> "); 24 // alert ( info.status ); 25 }else { 26 alert (" Error ! AJAX response status is " + client.status + ". Maybe the service is down..."); 27 } 28 } 29 }; 30 client.send (); 31 } 32 </script> 33 </head> En el segundo fragmento de c´odigo se define la estructura del prototipo. En concreto: L´ ınea 2 T´ıtulo de la p´agina. L´ ınea 5 Contenedor para el editor enriquecido. L´ ınea 5-14 C´odigo de muestra. L´ ınea 16 Reproductor del stream. L´ ınea 17-20 Botones para compilar y ejecutar. L´ ınea 22-26 Espacio para escribir la respuesta de la ejecuci´on/compilaci´on. L´ ınea 37-41 Inicializaci´on del editor enriquecido. 1 2<h2>Robolab</h2> 3 4<div id='container '> 5<div id="editor">task main () 6{ 7OnFwd ( OUT_A , 25) ; 8OnFwd ( OUT_C , 75) ; 9Wait (4000) ; 10 Off ( OUT_C ); 53 11 OnRev ( OUT_A , 50) ; 12 Wait (4000) ; 13 Off ( OUT_AC ); 14 }</div> 15 <div id="imgLyr"> 16 <img id="camImg" src=" img / loading.jpg " onMouseOver="javascript:fixMenuColPos(this); showAllMenuCols ();" onMouseOut=" javascript:hideAllMenuLayers();" onLoad=" javascript:updateID (); startPoll ()" onError=" javascript:showErrorImage()" width=@WIDTH height=@HEIGHT style=" border: 1px solid # @BORDERCOL;"> 17 <div id='submit_div '> 18 <input type= "button" value=" Compile code " onclick=" compile ();"> 19 <input type= "button" value=" Compile and run code" onclick= " run ();"> 20 </ div> 21 <div> 22 <p>Status: <span id= 'status'></span>< p> 23 </ div> 24 </ div> 25 </ div> 26 <p>Trace: <br /> <span id= 'trace '></span>< p> 27 28 <script> 29 var editor =ace.edit("editor"); 30 editor.setTheme ("ace / theme / monokai "); 31 editor.getSession () . setMode (" ace/ mode / c_cpp "); 32 </script> 6.4. Servicio LTI Para implementar el servicio LTI hemos usado la librer´ıa para LTI implementada por Stephen Vickers10. Se ha estructurado el c´odigo de la siguiente manera: launch.php Este fichero contendr´a el c´odigo para validar la conexi´on y extraer la informaci´on referente a ella, redireccionando a index.php si la conexi´on es v´alida. index.php Este fichero contendr´a la parte principal de la estructura de la p´agina. En funci´on del tipo de usuario, mostrar´a diferentes contenidos. 10http://www.spvsoftwareproducts.com/ 54 lib.php Este fichero contendr´a todas las funciones necesarias para manejar el contenido. config.php Este fichero contendr´a la informaci´on de configuraci´on, como por ejemplo, la informaci´on necesaria para conectar con la base de datos. Al acceder a la p´agina launch.php, se comprobar´a que las credenciales aportadas son las correctas, es decir, que la clave y el secreto aportadas por la petici´on han sido dados de alta en el servicio LTI (ver II) y que son correctos. En caso de ser correctos, se almacena cierta informaci´on en la sesi´on, para que en pasos posteriores sea f´acilmente accesible, y se redirige a la p´agina principal, index.php. Al acceder a index.php, se determina si el usuario que hace la petici´on es un profesor o un alumno. En el caso de ser un alumno, se le muestra la vista del alumno. Esta vista, basada en el prototipo, contiene el t´ıtulo y la descripci´on del ejercicio, el editor para el c´odigo con el c´odigo de muestra, si existe, botones para compilar, para compilar y ejecutar y para entregar, un espacio para el streaming de v´ıdeo procedente del laboratorio y un espacio para la traza. Figura 28: Vista de alumno En el caso de ser un profesor, se le muestra la vista de profesor. Esta vista permite editar el ejercicio vinculado al recurso, es decir, el t´ıtulo, la 55 descripci´on y el c´odigo de muestra del ejercicio, y ver la lista de ejercicios entregados. Para cada ejercicio entregado, se muestra el identificador del alumno, la valoraci´on de la entrega y un link para poder probarlo. Este link redirigir´a al profesor a la vista de ejecuci´on de la entrega, insertando el c´odigo entregado en el editor del c´odigo. De esta manera, podr´a ejecutar el c´odigo y comprobar que funciona seg´un lo esperado. Figura 29: Vista de profesor 56 A continuaci´on se detalla el coste de cada elemento y su coste estimado en funci´on del n´umero de horas dedicadas al proyecto: Material Gasto Coste estimado Amortizaci´on Toshiba Satellite U300 799€23,04€ Amortizaci´on Samsung T220HD 2,08€ € Amortizaci´on LEGO Mindstorms NXT 280€ € 10,07€ Servidor virtual privado 109€/a˜no 18,86€ Licencia Windows XP (OEM Portatil) 0€0€ Conexi´on internet 30€/mes 67,5€ Electricidad port´atil 0,127186€/kWh 3,61€ Electricidad NXT (pack 20 pilas AA) 10€9€ Total 66,65€ 8.2.3. Costes directos y total Para calcular el coste de actividad del proyecto y el total, plantearemos 3 marcos diferentes con precios por hora orientativos: Marco Precio/hora Coste directo Coste total Compaginaci´on con los estudios (becario) 6€2130€2186,65 Salario de un programador junior 15€5325€5391,65€ Contrataci´on de una empresa 40€14200€14266,65 63 9. Conclusiones Este proyecto se ha alargado m´as de lo planeado, en mi opini´on debido a costes ocultos. No pod´ıamos prever de antemano que, por un lado, no hubiera una librer´ıa que permitiera compilar y ejecutar el c´odigo NXC, que la comunicaci´on con el robot NXT fuera tan complicada y el Bluetooth tan inestable. Por otro lado, tampoco supimos prever que la implementaci´on de un m´odulo para Moodle requiriera un buen conocimiento previo de la plataforma. La soluci´on del m´odulo LTI evit´o este problema, pero a´un as´ı comport´o explorar una tecnolog´ıa no prevista, con el riesgo a˜nadido que supon´ıa. En mi opini´on, este proyecto podr´ıa haber sido divido en dos, abordando en m´as profundidad ambas partes: Implementaci´on de una librer´ıa de compilaci´on y ejecuci´on de c´odigo NXC y comunicaci´on con el robot NXT Implementaci´on del m´odulo de Moodle o del m´odulo LTI Otra cuesti´on importante es el hecho de trabajar con robots que est´an pr´acticamente obsoletos. Probablemente si se realizaran las pr´acticas con robots m´as modernos, la labor de interacci´on con el robot ser´ıa m´as sencilla (aunque, al ser los LEGO Mindstorms una tecnolog´ıa rob´otica para amateurs, no hay ninguna garant´ıa a priori de ello). Por otro lado, es muy interesante disponer de la posibilidad de programar y ejecutar c´odigo sobre un robot real. A´un con todos los inconvenientes que un simulador no tendr´ıa (mantenimiento, reset del estado, etc.), creo que el feedback y las sensaciones son totalmente distintas, positivas en general. Los inconvenientes plantean una serie de retos muy interesantes a su vez, como implementar una rutina de reset del robot (¿tal vez una espec´ıfica para cada pr´actica? ¿podr´ıa ser una gen´erica?) o averiguar c´omo determinar que la ejecuci´on del c´odigo ha terminado (o debiera haber terminado). Esto es s´olo a nivel de laboratorio. En cuanto al lado LTI/Moodle, este sector ha avanzado mucho en los ´ultimos a˜nos, extendi´endose el uso de plataformas de ense˜nanza online a pr´acticamente todas las instituciones de ense˜nanza, ya sea como forma de gesti´on interna de los cursos o como cursos puramente online, abiertos a internet. Las posibilidades que brindan las plataformas de ense˜nanza online son inmensas y, a su vez, extraer y gestionar todo ese potencial, me parece un trabajo impresionante. El est´andar LTI es un avance en cuanto a ese potencial. La reutilizaci´on de recursos es 64 muy importante dado el creciente ecosistema relativo a estas plataformas y LTI me parece un est´andar bien pensado, empezando por el hecho de ser agn´ostico en cuanto a la plataforma. A su vez, este tipo de tecnolog´ıas siempre presentan varios problemas clave, como la asincron´ıa y la concurrencia, planteando nuevos retos con respecto al proyecto, como c´omo se gestionan los accesos concurrentes o c´omo se asignan los recursos existentes (robots). A nivel personal este proyecto me ha permitido introducirme en el mundo de la rob´otica amateur. Las posibilidades que brinda el kit de LEGO Mindstorm NXT son muy grandes, tanto a nivel de construcci´on como a nivel de programaci´on, gracias a todo el ecosistema de lenguajes y aplicaciones para NXT. Tambi´en haber descubierto el est´andar LTI, el cual me parece una gran iniciativa, ha sido una parte muy satisfactoria del proyecto. Encuentro muy importante que existan este tipo de iniciativas, permitiendo la interconexi´on y la reutilizaci´on de recursos. 9.1. Mejoras y trabajo futuro Han quedado en el aire varios objetivos: La comunicaci´on Bluetooth funciona, pero requiere trabajo de estabilizaci´on de la comunicaci´on. Se ha implementado un m´etodo para recibir mensajes del programa que se ejecuta en el robot pero falta integrarlo correctamente en la librer´ıa. La gesti´on de las pr´acticas es rudimentaria. Ser´ıa interesante poder reutilizar las pr´acticas, por ejemplo. (Esto deber´ıa gestionarse a trav´es de la plataforma iLabVir). Y han surgido varias mejoras: Implementar una rutina de reset del robot, ya sea gen´erica, ya sea espec´ıfica para cada configuraci´on. Implementar un m´etodo para determinar si una ejecuci´on ha acabado (¿un wrapper para el c´odigo enviado que emita un mensaje?) o deber´ıa haber acabado (¿un timer?). Mejorar el dise˜no y la usabilidad de las p´aginas del m´odulo LTI. Sustituir la c´amara web por una c´amara IP 65 Determinar como compila el c´odigo el IDE BricxCC e incorporarlo a la librer´ıa. 66 Referencias http://bricxcc.sourceforge.net/ http://bricxcc.sourceforge.net/NXTFantomDriverHelp.pdf https://code.google.com/p/java-simple-serial-connector/ http://www.eng.buffalo.edu/ colinlea/Bluetooth With NXT.pdf http://www.vogella.com/tutorials/REST/article.html https://en.wikipedia.org/wiki/Comparison of JavaScript-based source code editors http://www.yawcam.com/ http://ace.c9.io/ http://www.imsglobal.org/lti http://www.imsglobal.org/LTI/v1p1/ltiIMGv1p1.html http://ltiapps.net/workshop/ http://projects.oscelot.org/gf/project/php-basic-lti/ http://www.spvsoftwareproducts.com/php/rating/ https://github.com/Harvard-ATG/workshop-lti-basic 67 Anexos I. Modificaci´on Yawcam Durante el desarrollo descubr´ı un problema relativo al servidor de streaming de Yawcam. En el caso de que quisiera tener el servidor de streaming en una m´aquina y el prototipo o el m´odulo LTI en otra, es decir, si la p´agina web que muestra el v´ıdeo est´a en una m´aquina diferente de la del servidor de streaming, daba problemas por la pol´ıtica del mismo origen (same-origin policy) del navegador. La pol´ıtica del mismo origen es una importante medida de seguridad implementada en los navegadores web desde hace mucho tiempo. B´asicamente consiste en permitir que un script contenido en una p´agina web acceda a datos de otra p´agina solo en el caso de que ambas p´aginas tengan el mismo origen. Esta pol´ıtica previene que un script malicioso proveniente de una p´agina acceda a informaci´on sensible de otra a trav´es del DOM (Document Object Model). Existen varias formas de relajar esta pol´ıtica. En nuestro caso, la opci´on que m´as se ajusta a lo que necesitamos es el intercambio de recurso de origen cruzado (Cross-Origin Resource Sharing). Este est´andar extiende HTTP a˜nadiendo una nueva cabecera de origen a la petici´on y una nueva cabecera Access-Control-Allow-Origin a la respuesta. Esto permite al servidor a˜nadir una lista de los or´ıgenes que pueden pedir una fichero (o incluso usar un comod´ın, el asterisco, para permitir peticiones desde cualquier p´agina). La soluci´on m´as sencilla y r´apida que encontr´e fue decompilar el c´odigo de Yawcam, que result´o ser java, buscar la clase o clases responsables de escribir los headers y parchearlas. En este caso, hab´ıa una sola clase responsable de ello, WebServerThread, que es la que se encarga de manejar cada una de las conexiones al servidor. Busqu´e todos los puntos en los que escribe los headers de la respuesta (hay varios, el c´odigo no es de los mejores) y a˜nad´ı la l´ınea que permite peticiones espec´ıficamente desde el servidor remoto. A continuaci´on muestro un extracto del c´odigo, a modo de ejemplo: 1sendHttpOkHeader(true); 2 3this.size = wappage.length(); 4this.out.print("Access-Control-Allow-Origin: http://playground.atuin.es" +this.br); 5this.out.print("Content-Length:" +this.size + this.br); 68 6this.out.print("Content-Type: " + contentType + this.br); 7this.out.print("Mime-Type: " + contentType + this.br + this.br); 8 9this.out.print(wappage); 10 11 this.out.flush(); 12 this.out.close(); 13 this.socket.close(); 69 II. Registro LTI Para controlar el acceso a una herramienta LTI se usa el protocolo OAuth11. Dicho protocolo requiere una clave y un secreto compartido para firmar los mensajes. La clave es transmitida con cada mensaje, as´ı como la firma OAuth generada basada en la clave. Por lo tanto, es necesario, como m´ınimo, disponer de un par clave/secreto para poder usar una herramienta LTI. Para eso, el m´odulo LTI dispone de una p´agina muy sencilla de administraci´on, en la que un administrador del m´odulo LTI puede dar de alta un par clave/secreto. Adicionalmente, se pueden definir otros criterios de filtrado, como el origen de la petici´on o una fecha de expiraci´on del par clave/secreto. Es responsabilidad del administrador del m´odulo LTI comunicar el par clave/secreto al administrador de la herramienta consumidora, en este caso la plataforma de aprendizaje, de manera que pueda usarlo para acceder al m´odulo LTI. Figura 30: Administraci´on del m´odulo LTI 11http://www.oauth.net 70