Ambiente de experimentación remota de robótica móvilrevistavinculos.udistrital.edu.co/files/2012/12/ambientede... · da “Protocolo de petición/respuesta”. Los clientes interactúan

REVISTA VINCULOS VOL 8 • NúmERO 1 • ENERO - JUNIO 2011

3030

I + D

Ambiente de experimentación remota de robótica móvil

Remote experimentation environment of mobile robotics

Eric Rodríguez*

Édgar Altamirano**

Arnulfo Catalán***

Fecha de recepción: 25 de abril del 2011Fecha de aceptación: 16 de junio del 2011

Resumen

La enseñanza de diferentes disciplinas técnicas y científicas requiere de la reali-zación de experimentos para consolidar los conceptos teóricos vistos en las aulas. El entorno tecnológico que ofrece Internet, en conjunto con el ámbito educativo, se han combinado en las instituciones educativas para brindarles a los estudiantes nuevas formas de aprender y acceso a infraestructuras remo-tas para realizar experimentos. En este documento se presenta la propuesta de un ambiente de experimentación remota para mejorar el aprendizaje de materias experimentales, como es el caso de la robótica móvil. Los experimentos que se pueden rea-lizar con esta herramienta consisten en probar diferentes estra-tegias para realizar el recorrido de un laberinto desde un punto inicial a uno final con la ayuda de los sensores infrarrojos del robot y mediante un algoritmo de control hecho en Java. El sis-tema le brinda al usuario información del ambiente remoto por medio de imágenes y datos con los que se puede observar los resultados de la tarea que se va a realizar.

Palabras clave: laboratorio virtual, robótica móvil, educación a distancia.

* Unidad Académica de Ingeniería, de la Universidad Autónoma de Guerrero Av. Lázaro Cárdenas S/N, Ciudad Uni-versitaria. Chilpancingo, Guerrero, México. Teléfono: 01 (747) 47 2-79-43. Correo electrónico: [email protected]

** Unidad Académica de Matemáticas, de la Universidad Autónoma de Guerrero Av. Lázaro Cárdenas S/N, Ciudad Uni-versitaria. Chilpancingo, Guerrero, México. Teléfono: 01 (747) 47 2-79-43. Correo electrónico: [email protected].

*** Unidad Académica de Ingeniería, de la Universidad Autónoma de Guerrero Av. Lázaro Cárdenas S/N, Ciudad Uni-versitaria. Chilpancingo, Guerrero, México. Teléfono: 01 (747) 47 2-79-43. Correo electrónico: [email protected].

l o sE N E R O - J U N I O D E 2 0 1 1 V O L U M E N 8 N Ú M E R O 1

ucnív

3131REVISTA VINCULOS VOL 8 • NúmERO 1 • ENERO - JUNIO 2011


ucnívERIC ROdRígUEz édgAR ALTAmIRANO ARNULFO CATALáN

Introducción

Las prácticas de laboratorio constituyen un elemento importante del proceso de forma-ción de profesionales en diferentes programas educativos, en el cual, unidas a las sesiones de introducción de conceptos teóricos y a la re-solución de ejercicios, conforman las distintas etapas por las cuales un estudiante adquiere las competencias necesarias para desempe-ñarse en el campo profesional. En la actuali-dad, en la parte correspondiente al trabajo ex-perimental, la incursión de las tecnologías de la información y la comunicación (TIC) han revolucionado este proceso de formación en las instituciones educativas, debido a que mu-chas de ellas están entrando en una etapa en la que buena parte de las actividades propias de la vida estudiantil se desarrollan a distan-cia accediendo a páginas web.

La estructuración de la información, median-te la transmisión interactiva de audio, video

y datos por medio de Internet han conducido al desarrollo de laboratorios virtuales como entornos de experimentación en los cuales los usuarios pueden interactuar sobre una serie de componentes gráficos, cada uno re-presentando un elemento importante del ex-perimento por realizar. Con la creación de es-tos entornos de formación virtual, es posible cubrir los problemas de experimentación que se presentan en algunas instituciones educa-tivas, lo que les permite afrontar de manera eficiente la formación de nuevos ingenieros e investigadores. Además, los laboratorios vir-tuales pueden adoptar procesos de enseñan-za aprendizaje a distancia a la medida del alumno –a su tiempo, a su interés específi-co y a su forma de aprender–, adicionalmen-te, permiten el acceso a cualquier hora y des-de cualquier lugar, mediante el uso de una computadora y acceso a Internet. Por esto, la realización de un laboratorio remoto resulta una aportación importante como herramien-ta educativa.

Abstract The teaching of scientific and technical disciplines required

for conducting experiments to consolidate the theoretical con-ceptsseen in the classroom. The technological environment of the Internet in conjunction with Education, have been com-bined intoeducational institutions to give students new ways of learningand remote access to infrastructure to conduct ex-periments. This document presents the proposal of a remote experimentation environment to enhance learning experimen-talmaterials, as is the case of mobile robotics. Experiments can be performed with this tool are to test different strategies for the path of a maze from a starting point to an end with the help of the infrared sensors of the robot and control algorithm using a Java based. The system gives the user information travéspor remoteenvironment through images and data that you can see the results of the task being performed.

Key words: virtual laboratory, mobile robotics, distance

education.

I + D

3232

I + D A m b i e n t e d e e x p e r i m e n t a c i ó n r e m o t a . . .


Tabla 1. Principales ventajas y desventajas de cada tipo de laboratorio

TIPO DE LABORATORIO

VEnTAJAS DESVEnTAJAS

Tradicional Datos reales.

Interacción con equipo real.

Trabajo colaborativo.

Interacción con el instructor

Restricción de tiempo y lugar.

Horarios estrictos.

Equipo costoso.

Requiere supervisión.

Simulado Ideal para compren-der conceptos.

No hay restricción de tiempo ni lugar.

Es un medio in-teractivo.

Datos ideales.

Falta de colaboración.

No hay inte-racción con un equipo real.

Remoto Interacción con equipo real.

Datos reales.

No hay restricción de tiempo ni de lugar.

Costo medio.

Presencia virtual.

Retardos de tiempo.

Tipos de laboratorios

Actualmente, la gran mayoría de las insti-tuciones de educación cuentan con espacios bien definidos para la experimentación de ciertas disciplinas, otras más han aprovecha-do los recursos tecnológicos que tienen a su alcance para desarrollar otro tipo de labora-torios donde se pueden realizar experimen-tos, ya sea de manera simulada o remota. En general, existen tres tipos de laboratorios: tradicionales, simulados y remotos. Un la-boratorio tradicional ha sido el lugar de tra-bajo donde los estudiantes y los profesores pueden comprobar mediante la experimen-tación los conocimientos teóricos adquiridos en clase y así lograr un aprendizaje signifi-cativo. La principal ventaja de estos es que el alumno interactúa directamente con el ex-

perimento, lo que le permite aplicar las ha-bilidades cognitivas y desarrollar nuevas competencias. Sin embargo, este tipo de la-boratorios también presentan ciertos incon-venientes que tienen que ver con la dispo-nibilidad de horario, cantidad de equipo y recurso humano.

Un laboratorio virtual basado en Internet provee acceso a uno o múltiples usuarios para realizar experimentos, ya sea de manera simulada o remota (Moreno, 2001). Un labo-ratorio virtual simulado es una herramienta de software que recrea el comportamiento de un fenómeno o modelo físico de manera in-teractiva por medio de la computadora, este tipo de herramientas dependen únicamente de los recursos propios de un servidor como el acceso a bases de datos. Un laboratorio virtual remoto permite operar remotamente


ucnív



ucnív

cierto equipo y requiere de un servidor que dé acceso a dichos equipos. La tabla 1 mues-tra las principales ventajas y desventajas de los tres tipos de laboratorios.

En este documento, se aborda el diseño y de-sarrollo de un laboratorio remoto de robó-tica móvil, para su construcción, un mode-lo de teleoperación ha sido utilizado como se muestra en la figura 1 (Khamis, 2003). Este modelo se basa en un simple protocolo co-múnmente usado en computación distribui-da “Protocolo de petición/respuesta”. Los

clientes interactúan con el sistema utilizando un visualizador de Internet para hacer sus peticiones. Estas peticiones son traducidas a simples peticiones HTTP, que son respondi-das por el servidor web. El servidor envía es-tas peticiones convirtiéndolas en peticiones de control de alto nivel que son recibidas por el controlador del robot, el cual, a su vez, las envía al robot como peticiones de bajo nivel para realizar la tarea requerida. La retroali-mentación es necesaria para enviar al usua-rio información sobre el ambiente remoto del robot y las consecuencias de sus comandos.

Figura 1. Arquitectura básica de un laboratorio virtual de experimentación remota

Fuente: http://www.ehu.es/ikastorratza/3_alea/laboratorios.pdf

Diseño e implementación del laboratorio

En este proyecto de investigación, el labora-torio remoto se construyó bajo una arquitec-tura genérica: cliente/servidor para controlar el robot usando el protocolo estándar TCP/IP basado en sockets. Para el desarrollo de la

aplicación se utilizó Java, como lenguaje de programación, de lo que se obtuvo como re-sultado un sistema independiente de la pla-taforma y orientado a objetos. Esto significa que el usuario puede trabajar con cualquier sistema operativo y ser capaz de acceder a la página del laboratorio para interactuar con el robot. La aplicación se compone principal-mente de los siguientes módulos:

ERIC ROdRígUEz édgAR ALTAmIRANO ARNULFO CATALáN

I + D

3434



• Cliente

- Autentificación - Interfaz de usuario

• Servidor - Retroalimentación - Control del robot

El cliente

El módulo del cliente se implementó por me-dio de un Apple de Java,1 el cual es cargado en una terminal remota mediante un nave-gador web, esto le permite al usuario inte-ractuar con el robot. Una vez realizada la co-nexión, el usuario cuenta con un periodo determinado para probar su algoritmo de control y concluir el experimento, esto le da oportunidad a otros usuarios de hacer uso del laboratorio virtual.

Módulo de autentificación

Se decidió utilizar Apache Tomcat para alo-jar las páginas que dan acceso al laboratorio virtual por lo que esta parte del proyecto se basa más en la configuración que en la pro-gramación. Para poder realizar la tarea de autentificación de usuarios válidos y hacer uso del laboratorio virtual fue necesario edi-tar los descriptores XML, tanto del servidor Tomcat, para decidir el método de autentifi-cación que se va a utilizar, como de la apli-cación web, para decidir qué recursos serían los protegidos.

Para acceder a la página del laboratorio vir-tual, se utilizó un mecanismo de autentifi-cación HTTP basada en formularios, imple-mentada por el servidor web, en el que se solicita el nombre de usuario y la contrase-

1 Los Applets son aplicaciones Java que se ejecutan den-tro de un navegador Web (generalmente, como parte de una página Web) (Eckel, 2002).

ña. Si los datos son válidos se pasaría al re-curso protegido, si no se mostrará una pági-na de error.

Figura 2. Interfaz de usuario del laboratorio de experimentación remoto

Fuente:http://www.ehu.es/ikastorratza/3_alea/laboratorios.pdf

El panel de usuario

Es la parte del cliente del sistema desarrolla-do y consta de dieciocho clases. La clase prin-cipal es llamada panel usuario que extiende de Applet. En esta clase se hace la instancia de los objetos de los que consta la aplicación. En el método init() del Applet, se añaden el panel de video, el panel de lectura de sensores, el panel de control del robot, el panel de progra-mación, el panel de resultados y el panel de estado como se muestra en la figura 2.

El usuario por medio de un navegador puede acceder a los servicios de la interfaz mediante el protocolo HTTP (protocolo de transferencia de hipertexto) para establecer una conexión con el servidor. El acceso de los usuarios al la-boratorio remoto lo hacen por medio de un Applet que provee información gráfica, tex-tual y visual del ambiente remoto en los dife-rentes paneles que componen la interfaz.

Una parte importante de este proyecto fue proporcionar al usuario retroalimentación vi-sual del ambiente remoto. Para realizar esta


ucnív



ucnív

tarea, se instaló una webcam sobre el área de trabajo del robot con la que se obtiene una vi-sión global del entorno en el que se moverá el robot, como se muestra en la figura 3.

Para la realización de los experimentos, se utilizó una cámara Quickcam pro for Note-books de Logitech, ya que está bien sopor-tada en el sistema operativo Linux que se encuentra instalado en el servidor en el que se aloja la aplicación. Los controladores ne-cesarios se pueden obtener de Luc Saillard. Free phillips usb webcam drivers for linux. Las imágenes son adquiridas por la webcam usando video4linux y son recibidas y pro-cesadas por un servidor de video. El servi-dor de video utilizado es Camserv (J. Travis. Camserv software) que está implementado en lenguaje de programación C y es com-pletamente libre y gratuito. Se desarrolló un applet de Java, como se muestra en la figura 4, para mostrar las imágenes en el panel de video de la interfaz del usuario.

El ambiente del robot Khepera es un laberin-to configurable utilizado para probar la in-teligencia del robot y funcionalidad del sis-tema. Las paredes del laberinto son bloques de madera de 2,5 cm de alto por 11,5 cm de largo con lo que se pueden lograr corredores de 10 x 10 cm, espacio suficiente para que el khepera pueda moverse con libertad. Excep-to por las paredes externas, todos los bloques

internos que forman las paredes son movi-bles, de forma que se puede cambiar fácil-mente el diseño del laberinto.

El robot Khepera cuenta con un anillo de ocho sensores infrarrojos. El panel de sen-sores muestra la lectura de estos en formato numérico, mientras se ejecuta el programa de control, su valor se actualiza continuamente mientras el robot se mueve dentro del labe-rinto y es desplegado cerca de su respectiva posición, como se muestra en la figura5. Es-tos componentes son capaces de detectar un obstáculo dentro de un rango aproximado de 50 mm. Los valores varían en un rango de 0 a 1024 unidades (Team. Khepera User Manual, Version 1.1, 2002) donde el primer valor indi-ca que ningún objeto ha sido detectado y el segundo indica el máximo valor de proximi-dad a un objeto, esto significa que el valor de los sensores es inversamente proporcional a la distancia con el objeto.El panel de sensores despliega en la inter-faz del cliente lo que el robot percibe de su entorno mientras se ejecuta el programa de control. En este panel también se muestra la velocidad de las ruedas del robot que varía en el rango de 1 a 9. La velocidad está dada en pulsos/10 m que corresponde a 0,8 cm/seg en la mínima velocidad y 7,2 cm/seg en la máxima velocidad. La figura 6 muestra el diagrama de flujo de las lecturas de los sen-sores de proximidad y de la velocidad del robot.

Figura 3. Vista global del entorno de trabajo


I + D

3636



Figura 4. Diagrama de flujo del Applet de video, la imagen es actualizada cada 10 m

El panel de control incluye los botones nece-sarios para interactuar con la aplicación. Al-gunos de ellos abren ventanas que le permi-ten al usuario manipular de manera directa el robot, escribir y enviar un programa para controlar el robot y observar un laberinto vir-tual, los demás botones le permiten al usua-rio iniciar o detener el programa en cualquier instante de tiempo.

El botón laberinto del panel de control abre una ventana que muestra gráficamente el di-señó de un laberinto virtual, similar al que se encuentra en el espacio de trabajo remo-to del robot, figura 7. En esta ventana se es-pecifican las coordenadas tanto del punto de inicio como de la meta, se calcula la trayecto-ria óptima que debe seguir el robot entre estos dos puntos y el tiempo estimado para ir de un punto a otro. Los datos del laberinto virtual, diseño y valores son cargados al momento de

abrir esta ventana, desde una base de datos que se encuentra al lado del servidor.

El botón de posicionamiento abre una venta-na que muestra los botones que le permiten al usuario controlar el robot de manera re-mota, con la idea de dirigirlo a la posición de inicio que se muestra en la ventana del labe-rinto virtual. Esto le permite al sistema medir los parámetros de tiempo y control, en com-paración con los establecidos en esa ventana. Cada uno de los botones de la ventana de po-sicionamiento, mostrados en la figura 8, acti-va un programa del lado del servidor, a fin de enviar los comandos necesarios al robot, para su control, mediante el puerto serial. El programa finaliza automáticamente al con-cluir la tarea requerida.

La ventana de programación está compues-ta por un editor de texto en el cual el usua-


ucnív



ucnív

rio puede escribir el conjunto de instruccio-nes de programación automática, es decir, el algoritmo de control que va a ser enviado y ejecutado por el robot. Se utiliza un área de texto para desplegar los posibles errores que se generen en el proceso de compilación del programa y un botón que tiene la función de enviar el código escrito hacia el servidor. La figura 9 muestra la ventana de programación

que incluye el código necesario para que el usuario comience a escribir su programa de control. Una vez que el usuario ha terminado de escribir su programa en el editor de texto, este se envía al servidor por medio del bo-tón “enviar programa”, en el que se guarda en un directorio predeterminado con el nom-bre de “Usuario.java” y se inicia el proceso de compilación.

Figura 5. Lectura de los sensores del robotFuente: elaboración propia.

Figura 6. Diagrama de flujo para la lectura de los sensores y actuadores del robot

Fuente: elaboración propia.

Si el programa está libre de errores, la venta-na de programación se cierra y se habilita el botón “iniciar programa “en la interfaz del usuario, de lo contrario, el servidor captura y envía al cliente, mediante el socket el posible

error de sintaxis que es desplegado en el área de texto que se encuentra en la parte inferior de la ventana de programación, lo que indi-ca el tipo de error y el número de línea en el que se está generando ese error. La figura 10


I + D

3838



muestra el diagrama de flujo del proceso de envío y la compilación del programa escrito por el usuario.

En el panel de resultados, se muestran los parámetros iniciales definidos en el panel de dibujo y los resultados obtenidos al ejecutar-se el programa de control escrito por el usua-rio. Los primeros se refieren a las coordena-das de la posición inicial a partir del cual se van a medir los parámetros de tiempo y con-trol, las coordenadas de la meta y el tiempo estimado para ir de un punto a otro. Los de-más resultados son calculados mientras el robot ejecuta los comandos enviados por el programa del usuario mientras se mueve en su ambiente de trabajo.

Los valores inicio y meta están relacionados con las coordenadas del punto de partida del robot dentro del laberinto y las coordena-das del punto que debe encontrar mientras se está ejecutando el algoritmo de control. El robot cumple con el objetivo del experimento cuando los sensores infrarrojos detectan una fuente de iluminación ubicada en la misma posición que el punto meta. Los dos prime-ros valores de la segunda columna, las veces que el robot tocó pared y el número de ve-ces que el robot se atoró se determinan mien-tras el algoritmo de control mueve el robot dentro de su entorno, el primero de ellos es-tima el número de veces que el robot choca contra cualquiera de las paredes del laberin-to basándose en la información obtenida por los sensores de proximidad. Se considera que el robot tocó una de las paredes cuando cual-quiera de sus sensores alcanza el máximo va-lor de proximidad a un objeto.

Para estimar el segundo valor de la colum-na, la cantidad de veces que el robot se atoró, se tomó en cuenta el tiempo que el robot se detiene por más de 5 segundos, mientras el

programa de control continuó ejecutándose; si esto sucede, una rutina del sistema mue-ve el robot para continuar con el algoritmo de control. El tercer valor, número de ajus-tes, se refiere al número de correcciones que el usuario ha hecho a su programa, este va-lor se incrementa cada vez que el programa de control del usuario es detenido y reenvia-do al servidor.

En la tercera columna se muestra el valor del tiempo estimado que el robot debe tar-dar en realizar la tarea de ir de la posición

Figura 7. Ventana del laberinto virtual

Fuente: elaboración propia

Figura 8. Botones de posicionamiento del robot


ucnív



ucnív

de inicio a la meta a una velocidad prome-dio. El segundo valor, tiempo de recorrido, mide el tiempo que el robot está haciendo para encontrar la meta mientras se ejecuta el programa de control. El tercer valor se refie-re al tiempo total acumulado que requirió el usuario en realizar el experimento. La medi-

Figura 9. Interfaz de la ventana de programación

Figura 10. Diagrama de flujo del proceso de compilación del programa de control


ción de estos parámetros se relacionan con los conceptos de sensores, control y programa-ción de robots, mediante el uso de técnicas de inteligencia artificial que un usuario del laboratorio virtual debe conocer para que su aprendizaje sea significativo.

Fuente: elaboración propia


I + D

4040



Figura 11. Panel de resultados del experimento

El servidor

El servidor se implementa como una aplica-ción que administra la conexión con el clien-te mediante el uso de TCP (Transport Control Protocol) basada en Sockets y está formada por dieciséis clases, entre las cuales se en-cuentra la clase servidor que está corriendo en espera de una conexión. Las peticiones hechas por los usuarios son recibidas, pro-cesadas y ejecutadas por esta aplicación, en-viando la respuesta correspondiente al clien-te para desplegarla en la interfaz de usuario.

Del lado del servidor se compila y se ejecu-ta el programa Controlador enviado por el usuario. El código le indica al robot, median-te el puerto serial de la computadora, cómo moverse dentro de su entorno basándose en la información que recibe de sus senso-res. Para la realización de esta etapa, se de-sarrolló un módulo de control que es utiliza-do para ejecutar el programa realizado por el usuario y la comunicación con el robot.Para la realización del módulo de control, se utilizaron dos hilos, el primero de ellos es un hilo de control encargado de actualizar cons-tantemente la información de los sensores


del robot y enviar los comandos de opera-ción a los actuadores por medio del puerto serial. El segundo hilo es responsable de en-viar las lecturas de los sensores y actuadores al cliente por medio del socket. La clase Pro-ceso es la responsable de iniciar y finalizar los hilos de procesamiento involucrados y de terminar el ciclo de vida de los objetos que componen el sistema.

El robot Khepera, utilizado en este proyecto, puede trabajar de dos formas diferentes, de manera autónoma (el programa de control se baja al procesador del robot) o por medio de una conexión al puerto serial de una compu-tadora que es donde se ejecuta el programa de control. Para la implementación de este proyecto se utilizó la segunda opción.En este modo el robot Khepera utiliza un protocolo de comunicación, basado en co-mandos y respuestas en código ASCII. Los comandos enviados al robot inician con una letra mayúscula, seguida por el parámetro requerido y finaliza con un retorno de carro representado por el carácter {. La respuesta del robot inicia con la letra minúscula corres-pondiente al comando enviado, seguida de los datos por transmitir y un retorno de ca-


ucnív



ucnív

rro. Por ejemplo, el comando para leer los sensores de proximidad del robot Khepera es el siguiente: N{. La respuesta del robot es re-gresada como una cadena de caracteres que debe ser procesada para determinar los valo-res numéricos de cada uno de los sensores de proximidad: n,0,59, 1023, 1023, 78, 0, 0 ,0{.Dado que este tipo de comunicación entre el robot y la computadora implica abrir una conexión con el puerto serial de la compu-tadora, enviar el comando, recibir una cade-na de caracteres como respuesta y procesar esta respuesta implica varias líneas de códi-go, se desarrolló una clase llamada Control Class que facilita la tarea de programación a los usuarios.

En esta clase se encapsulan los métodos para controlar el robot de una manera sencilla. Es-tos métodos están relacionados con la obten-ción del valor de proximidad de los sensores infrarrojos, la especificación de la velocidad de las ruedas del robot, así como el control de giros.

El constructor de la clase Control crea una instancia de la clase COM Serial que provee una interface con el puerto serial de la com-putadora, por medio de la cual el robot se co-munica con el algoritmo de control. Para el desarrollo de este proyecto, se utilizó el puer-to de comunicación serial estándar RS232 a una velocidad de 19200 baudios, 8 bits de da-tos, 1 bit de inicio, 2 bits de alto, sin paridad, así como se especifica en el manual de usua-rio del robot Khepera (Team. Khepera User Manual, Version 1.1, 2002). Para esto, se utili-zó el API (Application Programming Interfa-ce) de comunicación RXTX (Trent Jarvi, s.f.), que es una librería que provee comunicación con el puerto serial y paralelo para el paque-te de desarrollo de Java (JDK por sus siglas en inglés).

Conclusiones

Este laboratorio de experimentación remo-ta virtual de robótica móvil se diseñó como una herramienta educativa complementaria a la materia de robótica móvil para la realiza-ción de experimentos con un robot real, rela-cionados con aspectos de sensores, control y programación. Este laboratorio les facilita a los usuarios interactuar con un robot que se encuentra localizado en un ambiente remoto enfrentándolos a diversas complejidades que involucra un ambiente no simulado.

El sistema le brinda al usuario información del ambiente remoto mediante imágenes y datos con los que se pueda observar los re-sultados de la tarea por realizar. Los experi-mentos que se pueden realizar con esta he-rramienta consisten en probar diferentes estrategias de control para salir de un labe-rinto con la ayuda de los sensores infrarrojos del robot y mediante un algoritmo de control hecho en Java.

La ventaja de utilizar Java como lenguaje de programación es que el laboratorio virtual puede ser ejecutado en cualquier platafor-ma para la que exista una implementación de la máquina virtual Java. En la actualidad, existe multitud de implementaciones de di-cha máquina virtual, lo que nos permite que la aplicación pueda ser considerada como multiplataforma, permitiéndose la ejecución, por ejemplo, tanto en plataformas Windows como en entornos Linux. Sin embargo, cabe aclarar que los usuarios del laboratorio de-ben tener conocimientos sólidos de este len-guaje para la programación de los algoritmos de control, lo que implica una limitante.El hecho de que el programa de control en-viado por el usuario se ejecute en el servi-dor permite que el tamaño del algoritmo de control no esté restringido por el tamaño de la memoria y del procesador instalado en el


I + D

4242



robot. Además, el hecho de que se utilice un lenguaje de alto nivel permite escribir y de-purar con mayor facilidad el programa de control.

Las principales aportaciones de este trabajo son el desarrollo de un ambiente de opera-ción remota para un robot Khepera que debe resolver el problema de un laberinto, la me-dición de los parámetros de tiempo y control de la tarea realizada que proporcionan una idea del desempeño del algoritmo, la obten-ción de la trayectoria óptima y el tiempo de recorrido entre el punto de inicio y la meta, la flexibilidad para trabajar con diferentes esce-narios y la facilidad para incrementar de ma-nera muy simple el número y el tipo de expe-rimentos a realizar.

Trabajo futuro

Existen diferentes líneas de trabajo de gran interés para la continuación de la presente investigación, entre las que cabe mencionar las siguientes:

Realizar pruebas con los usuarios finales del sistema, utilizando diferentes algoritmos de control para comprobar la aceptación y la funcionalidad de la herramienta.

Integrar el laboratorio remoto a un curso de robótica para realizar experimentación con un robot móvil que ayude a lograr un enten-dimiento más profundo de la materia.

Integración del laboratorio virtual remoto a un tutor inteligente para proporcionarles a los estudiantes retroalimentación inmedia-ta sobre el desempeño del experimento, me-diante la evaluación y diagnóstico de este tu-tor, contribuyendo así al mejoramiento del proceso de aprendizaje del estudiante.Proporcionar retroalimentación visual de forma gráfica, de manera que se puedan mo-

ver al mismo tiempo el robot real en el am-biente remoto y el robot simulado en el labe-rinto virtual.

Integrar otros parámetros de evaluación que ayuden a mejorar la evaluación del desem-peño de experimentos como el número de veces que el robot ha pasado por un mismo lugar y la estimación de la trayectoria segui-da por el robot con la idea de compararla con la trayectoria óptima.

Incluir en la página del laboratorio remoto un enlace de ayudas que le permitan al estu-diante mejorar la eficiencia y el desempeño del experimento.

Integración de un simulador del laboratorio virtual remoto en el que los estudiantes pue-dan probar sus algoritmos de control antes de que sean enviados al robot real con la idea de hacer un uso eficiente de la herramienta.Este laboratorio remoto puede servir como base para el desarrollo de diferentes experi-mentos de robótica móvil, equipando al ro-bot con accesorios y diferente tipo de sen-sores que le ayuden a obtener un mejor conocimiento de su entorno desarrollando así tareas más complejas.

Referencias

Eckel, B. (2002). Piensa en Java (2ª ed.). Ciu-dad: Prentice Hall.

Khamis, A. M. (2003). Interacción remota con robots móviles basada en Internet. PhD the-sis, Universidad Carlos III de Madrid.

K-Team (2002, mar.). Khepera User Manual, Version 1.1. Preverenges Switzerland: KTeam, S.A., Ch de Vassuet, CP 111 1028.

Moreno, J. (2001). Un nuevo enfoque metodoló-gico para la enseñanza a distancia de asig-naturas experimentales: Análisis, diseño y desarrollo de un laboratorio virtual remoto


ucnív



ucnív

para el estudio de la automática a través de internet. PhD thesis, Universidad Nacio-nal de Educación a Distancia (UNED).

Saillard, L. Free phillips usb webcam drivers for linux. Recuperado en mayo del 2006 de: http://www.saillard.org/linux/pwc.

Travis, J. Camserv software. Recuperado en mayo del 2006 de: http://cserv.source-forge.net.

Trent Jarvi (2007). Api de comunicación para el puerto serial hecho en Java. Recupe-rado en mayo del 2006 de: http://users.frii.com/jarvi/rxtx/license.html.


Documents

Ambiente de experimentación remota de robótica móvilrevistavinculos.udistrital.edu.co/files/2012/12/ambientede... · da “Protocolo de petición/respuesta”. Los clientes interactúan