258 robotica educativa con etoys by I Romodana

Robótica Educativa con Etoys Lic. Gonzalo Zabala

Ricardo Morán

Sebastián Blanco

Centro de Altos Estudios en Tecnología Informática Universidad Abierta Interamericana Buenos Aires, Argentina

gonzalo.zabala@vaneduc.edu.ar

richi.moran@gmail.com sebastiangabrielblanco@gmail.com

Resumen Los cambios que se han producido dentro de los últimos 50 años en todos los aspectos de nuestra sociedad han sido muy significativos y profundos. Muchos de ellos son producto de un desarrollo tecnológico acelerado, que ha modificado, entre otras cosas, las relaciones sociales, las formas de comunicación y el mundo del trabajo. Sin embargo, las instituciones educativas no han logrado llevar a la tecnología a sus aulas con la misma velocidad, tanto en el uso de recursos tecnológicos para la educación, como en la enseñanza de tecnología. Una metáfora habitual y clara sobre este aspecto es pensar qué ocurriría si transportáramos a un cirujano de fines del siglo XIX a fines del siglo XX. Seguramente sería imposible para él ejercer su tarea, dado que la tecnología se ha hecho presente de manera formidable dentro de los quirófanos. Pero si analizamos el mismo suceso con un docente, es probable que pueda dar clases con los mismos recursos que utilizaba hace 100 años. El presente artículo tiene como objetivo presentar una propuesta vinculada a la enseñanza de tecnología mediante el uso de la robótica. Consiste en un conjunto de desarrollos que hemos realizado en el Centro de Altos Estudios en Tecnología Informática (CAETI) de la Universidad Abierta Interamericana (UAI), en el marco de un proyecto vinculado a la creación de plataformas de software para la enseñanza de robótica en escuelas primarias y medias, sobre diversos tipos de hardware populares en el mercado.

1) ¿Por qué enseñar robótica en las escuelas? Así como la sociedad ha sufrido cambios profundos de la mano del desarrollo científico y tecnológico de la humanidad, la institución escolar se ve en estos momentos apremiada por adaptarse a estos cambios para no desaparecer, vacía de objetivos y de significado. Como apunta Jaques Delors “*…+ ya no basta con que cada individuo acumule al comienzo de su vida una reserva de conocimientos a la que podrá recurrir después sin limites. Sobre todo, debe estar en condiciones de aprovechar y utilizar durante toda la vida cada oportunidad que se le presente de 1

actualizar, profundizar y enriquecer ese primer saber y de adaptarse a un mundo en permanente cambio” [1]. Por lo tanto, en este siglo que comienza, se nos presentan a los educadores un conjunto de desafíos vinculados al uso de las nuevas tecnologías en la educación y a la educación tecnológica, que debemos enmarcar dentro de las nuevas corrientes educativas. Probablemente, el primer salto significativo de presencia tecnológica en las aulas ha sido la inclusión de computadoras en la enseñanza. Desde el surgimiento de las primeras home computers, hemos intentado hacer un uso interesante y pedagógico de ellas dentro del aula, con resultados muy dispares. Uno de los problemas que se nos ha presentado, es el uso no transversal de esta tecnología. Hemos enseñado informática por la informática misma durante muchos años, sin hacer un uso integral de la herramienta, como se utiliza en la vida cotidiana. Esto trajo aparejado un apropiamiento de esta tecnología por parte de un subconjunto pequeño de docentes y alumnos, en general con más aptitud y placer por el uso de las computadoras. Sólo con la presencia de Internet en las escuelas se ha comenzado a revertir esta situación, aunque a nuestro entender, aún no se ha hecho un verdadero aprovechamiento del recurso. Como dijo Alan Kay, “poner simplemente computadoras en las aulas sin crear un rico ambiente de aprendizaje es inútil – peor que inútil, porque es una distracción. Hace parecer que algo bueno está sucediendo cuando en realidad no está pasando nada de nada” *2+ A partir de esta presencia informática en las aulas, la tecnología en la educación se volcó pura y exclusivamente al ámbito digital. Han desaparecido laboratorios de física, experiencias vivas de ciencias naturales, y otro tipo de prácticas, detrás de programas de simulación o mundos físicos virtuales. Y el problema se profundiza dado que también el juego cotidiano de los niños se ha volcado al mundo digital. Por razones económicas, espaciales y otras, hemos llevado a nuestros chicos a “La Matrix”. De esta manera, las nuevas generaciones están perdiendo ciertas capacidades cognitivas vinculadas a la experimentación física, el ensayo y el error, el manejo y comprensión de las infinitas variables de valores continuos que nos presenta el mundo real. Un ejemplo: hay muchísimos simuladores de robots en el mercado, pero en ninguno de ellos el comportamiento de los robots se modifica por falta de energía, ni hay suciedad en el piso, ni las condiciones de luz cambian aleatoriamente. El mundo simulado es infinitamente más amable que el real. Por otra parte, la arquitectura de las computadoras de escritorio no alienta el trabajo en equipo. Muchas instituciones se jactan de tener una computadora por alumno, lo que profundiza el trabajo individualista, que no es lo mismo que el trabajo individualizado. El surgimiento reciente de los dispositivos móviles, como las tablets y las netbooks, abren la posibilidad de un trabajo en equipo mediante el uso de estas herramientas. Pero hasta que no se desarrolle software adecuado a este fin, el uso de las computadoras seguirá teñido de un uso esencialmente individual. Por lo tanto, si queremos insertar la enseñanza de tecnología dentro del marco propuesto por Delors y su equipo para la educación del siglo XXI, debemos encontrar recursos que permitan que nuestros alumnos aprendan haciendo, aprendan a convivir y aprendan a ser de una forma integral. 2

Por los motivos que hemos presentado anteriormente, consideramos que la robótica es una disciplina que permite vencer cada una de estas dificultades, unido a la profunda atracción y motivación que genera en los alumnos este tipo de materiales educativos. De acuerdo a la teoría del construccionismo de Seymour Papert, es muy importante establecer un método de “aprender haciendo” [3]. Esto significa fomentar la creatividad en los estudiantes: permitirles hacer cosas significativas para ellos mismos como construir robots, desarrollar programas, escribir cuentos, y componer música entre otras cosas. La esencia de tales actividades es permitir a los alumnos usar el conocimiento en lugar de simplemente reproducirlo, poniéndolos en el papel principal de la experiencia y fomentándolo a tomar el mando de su propio proceso de aprendizaje. En síntesis, ubicar a los niños en el mismo vínculo con el universo que tuvieron cuando fueron bebés, y que por alguna extraña razón la escuela les ha anulado. Por otro lado, enseñar robótica en un ambiente apropiado ayuda al estudiante a construir y explorar sus propias representaciones de algunos fenómenos de la naturaleza, lo cual le facilita la adquisición de conocimiento acerca de los mismos. La robótica está naturalmente muy relacionada con diversas disciplinas científicas como la lógica, la matemática, la física, la inteligencia artificial, la biología, la medicina y la nanotecnología. Pero también es posible, gracias a la versatilidad que nos presentan los kits educativos de robótica, desarrollar artefactos vinculados con las disciplinas más diversas como música, plástica, educación física, historia, geografía, literatura y otros. Es decir, con la construcción de robots podemos representar diversos artefactos tecnológicos que están vinculados a cada una de las disciplinas, como instrumentos musicales, pantógrafos, catapultas, telescopios, poniendo el recurso al servicio de diversos temas de la currícula. Finalmente, en la construcción y programación de un robot tenemos un conjunto de desafíos diversos que necesariamente deben encararse en equipo. El armado, la programación, el ordenamiento y cuidado de los materiales, la escritura del documento de trabajo, exigen la participación coordinada de un equipo, con roles diferenciados pero integrados entre sí, lo que da sentido a un verdadero esquema de trabajo en grupo. En el ejercicio rotativo de los roles, los alumnos irán aprendiendo diversas habilidades que luego se traspolarán a otros ámbitos.

2) Plataformas de software para la enseñanza de robótica A pesar de que existen varias herramientas para la enseñanza de la robótica, la mayoría padece alguno de los siguientes problemas: o son demasiado complicadas y poco intuitivas para estudiantes que no poseen profundos conocimientos de electrónica y programación, o son tan simples que no representan ningún desafío para ellos.

Otro problema que ocurre cuando se intenta enseñar robótica en las escuelas es el alto costo de los recursos necesarios. En general, los países en vías de desarrollo no pueden permitirse invertir tanto dinero en robots y ambientes de trabajo. Por estos motivos es que hemos decidido desarrollar un conjunto de plataformas basándonos en Squeak y Etoys para la programación de diversas arquitecturas de hardware: Robosapien v2 I-Sobot Lego Dacta Control Lab Lego Mindstorms Lego Nxt Edukits Arduino

Aunque algunos de estos kits pueden resultar caros, fue necesario hacer un balance entre costo, calidad y valor pedagógico. El objetivo de este proyecto es poder proveer a los docentes y alumnos un conjunto de etoys abiertos y libres que permitan programar en forma sencilla y atractiva los robots de estas plataformas. Siendo Etoys un eje fundamental en el proyecto OLPC, consideramos que nuestro aporte puede sumar contenido didáctico a dicho proyecto. A continuación presentaremos cuatro de los desarrollos realizados.

3) Lego Nxt a. Descripción Los kits de robótica de Lego permiten una rápida introducción a la robótica. Han sido usados con éxito en varios países durante los últimos diez años y combinan perfectamente con la filosofía de Squeak Etoys. Estos kits ofrecen muchas posibilidades y son muy poderosos. Muchos robots distintos pueden ser construidos sin tener experiencia en electrónica ni mecánica, y la gran cantidad de sensores disponibles así como la posibilidad de comunicación inalámbrica permite el desarrollo de proyectos muy interesantes. b. Características de Lego Nxt Lego Nxt trae ventajas con respecto a sus antecesores, destacándose las siguientes: Comunicación bidireccional vía Bluetooth: permite un mayor alcance y facilita el control del robot desde la computadora en tiempo real (por medio de Direct Commands) así como la transmisión desde el Nxt hacia la computadora de los datos de los sensores. 4

Motores servo: incorporan encoders que miden ángulo de rotación, permitiendo el control del motor con gran precisión. Nuevos sensores: (ultrasónico, sonido, tacto, luz, rotación, etc.) Con la posibilidad de añadir sensores de creación propia gracias a que la información del hardware se encuentra disponible.

c. SqueakNxt: Etoys y Lego Nxt El proyecto de control de robots del kit Lego Nxt fue llamado SqueakNxt. Dado que los robots podrían llegar a ser utilizados para variedad de tareas (no necesariamente educativas) fue desarrollado en primer término un modelo de programación utilizado como núcleo para luego construir el Etoy. d. Descripción del núcleo Un robot de Lego Nxt está compuesto por un ladrillo principal que representa el “cerebro” del robot y un conjunto de motores y sensores. Estos últimos permiten al robot estar conciente de su ambiente y actuar en el mismo. El modelo de programación fue basado en esta composición, por lo que básicamente está compuesto por las siguientes clases: LegoNxt – Representa el robot en sí mismo e incluye el protocolo para conectarlo a un puerto serie Bluetooh, acceder al nivel de la batería, reproducir sonidos, y ejecutar programas. Port – Representa un puerto en el cual puedan ser enchufados dispositivos como motores o sensores. Su única responsabilidad es hacer de intermediario entre el robot y los dispositivos. NxtMotor – Representa un motor e incluye el protocolo para modificar la velocidad, acceder a la rotación, y diferentes formas de frenado (en un caso bloqueando el motor y en otro dejándolo libre). LightSensor – Representa un sensor de luz e incluye el protocolo para acceder a su valor actual y setear el sensor como “activo” o “inactivo”. En el primer caso, el sensor prende una pequeña lámpara en el frente que le permite percibir su reflejo. En el segundo la lámpara está apagada por lo cual percibe la luz del ambiente. SwitchSensor – Representa un sensor de tacto y su protocolo simplemente permite acceder al valor (si está presionado o no). UltrasonicSensor – Representa un sensor ultrasónico y, como el sensor de tacto, sólo incluye el protocolo necesario para acceder a su valor. SoundSensor – Representa un sensor de sonido e incluye el protocolo para acceder a su valor y para setear el sensor como audible o inaudible.

Estas son las clases básicas necesarias para utilizar el software. Se intentó mantener la simplicidad para que utilizar el núcleo para aplicaciones más complejas fuera lo más sencillo posible. 5

e. Descripción del Etoy

Ilustración 1 - Un LegoNxt con dos motores y dos sensores

Dado que se espera que la interfaz con Etoys pueda ser utilizada por los alumnos para programar los robots, ésta debe ser lo más intuitiva posible. Por esta razón se decidió mantener la equivalencia entre los objetos reales y los virtuales, y se construyó una representación gráfica para cada objeto del modelo antes mencionado. Esta representación gráfica permite mandar mensajes de la forma más directa posible haciendo uso de mecanismos típicos de Etoys como el Viewer. Por otro lado, el uso de los objetos fue diseñado para ser lo más cercano posible al uso de los objetos reales. Por ejemplo, para enchufar un motor o un sensor al robot el usuario necesita conseguir uno del catálogo de objetos de Squeak y soltarlo cerca del puerto correspondiente en el LegoNxt. El cable que enchufa el dispositivo al puerto también tiene una representación gráfica que se hizo usando Connectors de Ned Konz. f.

Problemas durante el desarrollo

El primer problema se trató del desarrollo del protocolo de comunicación con el robot por medio de puertos serie Bluetooth. Afortunadamente, para esta versión de kits, Lego publicó documentación muy detallada referida a los protocolos de comunicación por comandos directos, por lo que no fue demasiado complicado superar el problema. Por otro lado, gracias a que Squeak soporta el uso de puertos serie la programación resultó muy sencilla. El segundo problema se relaciona con la administración de puertos de Windows y con la máquina virtual de Squeak. Resulta que, por un lado, la máquina virtual de Squeak no acepta puertos serie mayores al 10. Aunque este problema tiene un arreglo trivial, es necesario esperar que la comunidad lo adopte. Mientras tanto, hay que utilizar puertos menores al décimo. Sin embargo, fue descubierto un problema de Windows: el mismo no libera correctamente los puertos que ya no están en uso. Entonces, si los primeros 10 puertos están ocupados Windows asigna al robot el primer puerto desocupado, el 11 este caso, y Squeak ya no lo acepta. Para resolver este problema 6

fue necesario averiguar como modificar el registro de Windows para liberar los puertos manualmente. Más tarde se desarrolló una sencilla aplicación para automatizar el proceso. El tercer problema resultó ser la performance. Controlar los robots no resulta demasiado problemático hasta que se necesita utilizar los valores de los sensores. Los mismos deben ser chequeados constantemente en un proceso concurrente que termina ralentizando Squeak. Para solucionar esto se decidió desarrollar una librería en C++ y vincular la misma con Squeak. La librería, entonces, pasó a contener toda la parte de comunicación con el robot y solucionó el problema de performance. El último problema, que actualmente está en proceso de ser solucionado, está relacionado con una de las características esenciales de SqueakNxt: el control de los robots en tiempo real. Por un lado, este modo de comunicación permite una interacción entre la computadora y el robot que está vedada a los usuarios del software original de Lego. Con SqueakNxt es posible vincular cualquier objeto gráfico de Etoys (rectángulos, círculos, dibujos hechos por el usuario, etc.) con objetos reales como motores o sensores. Sin embargo, esta ventaja trae el siguiente problema: la programación de tareas autónomas no triviales resulta muy difícil (en algunos casos imposible) debido a la acumulación de retardo que conlleva la comunicación entre el robot y la computadora. Esto significa que, si se intenta hacer una plataforma integral para controlar robots de LegoNxt no es suficiente con un modo de comunicación directo y en tiempo real. Por el contrario, es necesario agregar una forma de programar los robots de manera que sean independientes de la computadora. En este momento, se está desarrollando un compilador que permita traducir los programas hechos en Etoys a instrucciones ejecutables por el ladrillo principal del Lego Nxt. Esto posibilitará construir un programa, bajarlo al robot y ejecutarlo sin control directo por la computadora, lo cual solucionaría el problema.

4) Fútbol de Robots con el simulador de la FIRA El fútbol de robots ha sido elegido porque es una actividad lúdica que congrega a investigadores de todo el mundo y es una buena excusa para introducirse en temas clásicos de robótica situada: Percepción del Ambiente, Autonomía, Navegación, Inteligencia Artificial, Comportamiento Colaborativo y Respuestas en tiempo real. La categoría de fútbol de robots simulado posee 2 elementos importantes para llevar a cabo un partido: 



El simulador RobotSoccer de la categoría SimuroSot de la FIRA: es un software que representa virtualmente un partido de fútbol de robots. Permite cargar equipos programados en C++ o Lingo. El proxy: es una dll desarrollada en C++ por la Universidad del Comahue. Se carga en el simulador como si fuera un equipo y actúa como intermediario entre el simulador y cualquier plataforma de software. 7

Su funcionamiento es el siguiente: codifica los datos del ambiente (posición y rotación de los robots, posición de la pelota, estado de juego, etc.) en un string de acuerdo a un protocolo determinado; los envía por un socket y luego espera recibir, también codificado en un string, la nueva velocidad a aplicar en las ruedas de los robots. El mensaje que recibe el proxy está en formato de texto ASCII, números separados por espacios. En este caso el mensaje consta de una sola línea con la velocidad en cada rueda de cada robot. El orden de los números es la velocidad en la rueda izquierda y la velocidad en la rueda derecha de los jugadores propios del 1 al 5. Los datos se toman de un archivo guardado en “C:\Strategy\Blue” si se tratara del equipo azul y “C:\Strategy\Yellow” si se tratara del equipo amarillo. El archivo debería contener simplemente tres líneas: 1. 2. 3.

La ip de la máquina donde se ejecuta el equipo. El número de puerto por donde se enviará la información del ambiente. El número de puerto por donde se esperará recibir la velocidad de las ruedas.

La configuración por defecto para trabajar en forma local sería la siguiente: 127.0.0.1 6364 6363 Esto se realizó para ejecutar el simulador y el equipo en máquinas distintas, proporcionando ventajas en velocidad de ejecución y seguridad (ningún equipo puede tener acceso “malicioso” a la porción de memoria del simulador). La categoría de fútbol de robots físico también posee 2 elementos importantes para funcionar:  

Un dispositivo que capte imágenes asociado a un sistema de procesamiento de imágenes que se comunique con las máquinas cliente. Robots reales con parches identificables.

Para poder realizar partidos de fútbol de robots con equipos propios tanto físicos como simulados se desarrolló un framework open-source que se describirá a continuación: El framework de desarrollo de equipos se realizó íntegramente en Squeak y fue donde se hizo mayor hincapié en el proceso de desarrollo. El modelo se basó en 4 conceptos esenciales: un environment, un equipo, un servidor de video y un servidor de robots. El environment simplemente representa el ambiente de juego y por lo tanto tiene todas las variables pertinentes. El equipo es el encargado de decidir las acciones (velocidad de las ruedas de cada robot) para un determinado environment. El servidor de video y el servidor de robots representan la capa de 8

comunicación: son los encargados de comunicarse con el “mundo exterior” y actualizar las variables del environment y mandar la nueva velocidad a los robots. Estos 4 conceptos se implementaron en las siguientes clases: RSEnvironment, RSTeam, RSVideoServer y RSRobotServer. El equipo, el servidor de video y el servidor de robots son independientes uno de otro y permiten la utilización del mismo framework para el desarrollo de equipos tanto de fútbol físico como de simulado. Por otro lado, la clase principal del modelo que vincula todos estos conceptos se denominó RSGame y representa un partido de fútbol de robots. Permite controlar el estado del partido así como conectar y desconectar equipos, servidores de video y servidores de robots. Finalmente, para representar las entidades inherentes al fútbol de robots (los robots, la pelota, etc.) se implementaron las clases adecuadas: RSRobot, RSOpponentRobot y RSBall. A continuación se describirá más detalladamente cada clase del modelo: RSGame Representa un partido de fútbol de robots. Variables de instancia:      

numberOfRobots – la cantidad de robots de cada equipo (se asume igual para ambos). videoServer – el servidor de video elegido y conectado por el usuario. robotServer – el servidor de robots elegido y conectado por el usuario. rsEnvironment – el environment actual. team: el equipo elegido y desarrollado por el usuario. process – el proceso encargado de recibir los datos, procesarlos y enviar una respuesta.

Métodos de instancia: o #videoServer: – carga el valor de la variable videoServer. o #robotServer: – carga el valor de la variable robotServer. o #initializeEnvironment – carga el valor de la variable rsEnvironment dependiendo del team que se haya seleccionado. o #team: – carga el valor de la variable team y luego se manda el mensaje #initializeEnvironment. o #disconnectVideoServer – desconecta el servidor de video. o #disconnectRobotServer – desconecta el servidor de robots. o #disconnectTeam – desconecta el equipo. o #disconnectAll – desconecta todo. o #start – inicia el partido o lo continúa si estaba pausado. o #pause – detiene el partido en el punto de ejecución actual permitiendo continuarlo más tarde. o #stop – finaliza el partido. 9

RSVideoServer Tiene la responsabilidad de conseguir la información del ambiente. Se decidió definirla como clase abstracta para que sus subclases implementen la forma de comunicación con distintos tipos de servidores de video (por ej. el proxy en caso de fútbol simulado, el software “Doraemon” en caso de fútbol físico, etc.). La creación de una subclase es muy simple: sólo requiere que se sobrescriban dos métodos: #storeDataOn: que debe guardar los datos en un environment que se pasa como parámetro; y el método de clase #fromUser que debe responder una nueva instancia basándose en el ingreso de datos del usuario (por ejemplo el puerto del que se espera recibir los datos del proxy en caso de fútbol simulado).

RSRobotServer Es responsable de enviar la nueva velocidad de las ruedas a un conjunto de robots. Se definió como clase abstracta para que sus subclases implementen la forma de comunicación con distintos tipos de robots (por ej. robots que se comunican por radio para el caso de fútbol físico o simplemente el proxy para el caso del fútbol simulado). La implementación de una subclase es muy simple: sólo requiere que se sobrescriban dos métodos: #sendMovesOf: que debe enviar la velocidad de las ruedas de una colección de robots que se pasa como parámetro; y el método de clase #fromUser que debe responder una nueva instancia basándose en el ingreso de datos del usuario (por ejemplo la ip y el puerto por el que se enviarán los datos al proxy en caso de fútbol simulado).

RSTeam Representa un equipo y es el responsable de definir las acciones (velocidad de cada robot) para un environment determinado. Se decidió implementarla como clase abstracta para permitir que distintos equipos convivan en la misma imagen. La implementación de una subclase requiere sólo la sobreescritura del método #strategyFor: que recibe como parámetro un environment. En la mayoría de los casos, las subclases necesitarán especializar el comportamiento de los robots o del environment (por ejemplo para añadir primitivas de navegación). Para solucionar esto se añadieron los métodos de clase #myBall, #myEnvironment, #myOpponent y #myRobot que deben devolver la clase de la que se deben crear las instancias de cada objeto.

RSEnvironment 10

Representa el ambiente de juego y es responsable de tener toda la información del juego disponible para que el equipo decida la estrategia. La información necesaria incluye las siguientes variables:     

home – una colección de robots de nuestro equipo. opponent – una colección de robots del equipo contrario. currentBall – la pelota actual. fieldBounds – un rectángulo que representa los bordes de la cancha. goalBounds – un rectángulo que representa los bordes de los arcos.

Para facilitar la programación de equipos, el environment también se encarga de invertir la cancha si el equipo propio está del lado izquierdo. De esta forma sólo hay que programar equipos para el lado derecho (en caso del fútbol simulado para el equipo azul) y funcionan igual para ambos lados.

RSRobot Representa un robot de nuestro equipo y tiene las siguientes variables de instancia:     

rsEnvironment – el environment al cual pertenece. rotation – el ángulo de rotación. position – un punto que indica su posición en la cancha. velocityLeft – la velocidad de la rueda izquierda. velocityRight – la velocidad de la rueda derecha.

RSOpponentRobot Representa un robot del equipo contrario y tiene las siguientes variables de instancia:  

rotation – el ángulo de rotación. position – un punto que indica su posición en la cancha.

RSBall Representa una pelota y tiene las siguientes variables de instancia: 

position – un punto que indica su posición en la cancha.

Para las competencias de fútbol de robots simulado se implementó una subclase de RSVideoServer que escucha la información enviada por el proxy. Esta clase se denominó RSSimulatedVideoServer. 11

De la misma forma, se desarrolló una subclase de RSRobotServer para las competencias de fútbol simulado que envía las velocidades de los robots al proxy. Esta clase se denominó RSSimulatedRobotServer. Finalmente, el framework contiene también un equipo de ejemplo con primitivas de navegación básicas que marca las pautas básicas a seguir para el desarrollo de un equipo efectivo. También se desarrolló en Squeak un visor (viewer) de partidos que proporciona una ventaja significativa con respecto a usar sólo el simulador. El Viewer es una herramienta gráfica que permite:   

ver y controlar el partido en tiempo real. conectar y desconectar independientemente equipos, servidores de vídeo y servidores de robots y también ver qué está conectado actualmente. pausar el partido y cambiar la estrategia (o el código de la estrategia que se está ejecutando) de acuerdo al comportamiento (deseado o no) que se observe en los robots.

Finalmente y, quizá sea el aspecto más útil, se añadió la posibilidad de extender el viewer por medio de plugins según las necesidades del usuario. Por ejemplo, se desarrolló un plugin que muestra gráficamente la predicción de la pelota.

Ilustración 2 - Plugin del predictor de la pelota

El viewer se hizo utilizando la interfaz gráfica de Squeak: Morphic. Las clases que lo componen son las siguientes: 12

RSViewerMorph Es el Morph principal encargado de la interacción con el usuario. Tiene los controles para empezar, pausar y terminar el partido así como para conectar y desconectar el servidor de video, el servidor de robots y el equipo (por separado e independiente cada uno de ellos). También se encarga de listar los plugins disponibles.

RSBoardMorph Es el Morph que se encarga de mostrar el partido. Tiene una imagen de la cancha y es el encargado de hacer las conversiones entre las unidades de medida que se utilicen (pulgadas en el caso del simulado) y píxeles.

RSRobotMorph Es el Morph que representa los robots. Si se hace clic encima muestra un inspector del robot.

RSBallMorph Es el Morph que representa la pelota. Si se hace clic encima muestra un inspector de la pelota.

RSViewerPlugin No es un Morph. Es una clase abstracta que define la interfaz de los plugins que permiten extender el Viewer. Cuando se crea un RSViewerPlugin se le pasa como parámetro de inicialización la instancia de RSBoardMorph actual. Sobre la misma éste actúa como se requiera (por ej. dibujando las posiciones futuras de la pelota como se mostró más arriba). Posee un método #step que deben especializar las subclases y una variable de instancia “isActive” que funciona como flag para activar o desactivar el plugin (el RSViewerMorph luego utiliza esta variable para decidir si mandar el mensaje #step cada un intervalo de 50 milisegundos o no). Para controlar las opciones del plugin, y como cada plugin tiene una función diferente y por lo tanto opciones diferentes, es necesario que cada subclase sobrescriba el método #menu que debe responder un Morph que funcione como menú de controles del plugin (por lo general siempre debe estar el botón “Activar/Desactivar” que debería poner en true o false la variable “isActive”). 13

El RSViewerMorph utiliza este método para listar y agregar los menús de todas las subclases de RSViewerPlugin permitiendo al usuario interactuar con los mismos.

Diagrama de clases del framework

5) Edukit a. Descripción Edukit es un desarrollo de la Universidad Abierta Interamericana (UAI) usada para el dictado de cursos introductorios a la programación. Se trata de una placa electrónica de bajo costo con entradas y salidas y conexión por puerto paralelo. Permite trabajar con variedad de motores y sensores. Comparando con otros kits, las ventajas de Edukit son su bajo costo (lo cual lo convierte en la mejor elección para las escuelas menos privilegiadas) y la posibilidad de trabajar con motores y 14

sensores más sofisticados. Sin embargo, requiere cierto conocimiento básico de electrónica para poder utilizarlo en su máximo potencial.

Ilustración 3 - Edukit

b. Etoys y Edukit Para utilizar Edukit con Etoys se desarrollaron dos proyectos. Inicialmente se desarrolló un Etoy para representar el puerto paralelo y controlar cada pin en forma directa. Luego se desarrolló un Etoy especial para controlar el Edukit. A continuación se describirán más detalladamente ambos proyectos. c. Etoy puerto paralelo

Ilustración 4 - Etoy del puerto paralelo

El Etoy para controlar el puerto paralelo de forma genérica es un proyecto muy sencillo que hace uso del proyecto IOST1 de Germán Viscuso para acceder al puerto paralelo. Básicamente se trata de una representación gráfica de los 25 pines del puerto paralelo permitiendo controlar el valor de cada uno de forma directa, ya sea haciendo clic en el mismo o accediendo por medio del viewer (para programar scripts). d. Etoy Edukit

http://www.smalltalking.net/Goodies

Ilustración 5 - Etoy Edukit

El Etoy específico para Edukit es un poco más complejo y permite un control más sencillo de la placa. Está basado en el proyecto anterior pero tanto su funcionamiento interno como su representación visual es específica del Edukit. Usando este proyecto se puede trabajar de una forma mucho más transparente porque todos los componentes útiles de la placa (borneras, leds, etc.) están representados gráficamente y son accesibles y programables por medio de Etoys. e. Ejemplo de proyectos A continuación se presentarán algunos ejemplos de maquetas realizadas por los alumnos de la universidad usando la interfaz de puerto paralelo. 1.

Brazo robótico: Un brazo robótico con movimientos pre-armados capaz de escribir en un teclado.

Ilustración 6 - Brazo robótico con Edukit

Grúa mecanizada: Una clásica grúa de puerto para el desembarco de mercaderías.

Ilustración 7 - Grúa mecanizada con Edukit

Casa inteligente: Una casa inteligente con luces y puertas automatizadas.

Ilustración 8 - Casa inteligente con Edukit

6) SqueakWiimote a. Descripción SqueakWiimote es un proyecto que pretende hacer de interfaz entre Squeak Etoys y el famoso Joystick de la consola Nintendo Wii, el wiimote. Este joystick permite detectar los movimientos que hace el usuario con la mano así como apuntar a objetos en la pantalla. Vinculando el wiimote a Etoys podemos, entonces, programar guiones que interactúen con el usuario de manera gestual. Por ejemplo, un sencillo juego de pong con dos wiimotes donde cada uno controla una paleta.

b. Características del wiimote Dado que el joystick de la Wii se ha hecho muy famoso en estos últimos tiempos no tiene ningún sentido explayarse demasiado en esta sección. Sin embargo, se describirán brevemente sus características más importantes. 1. Detección de movimiento: El wiimote usa acelerómetros para aproximar la orientación del joystick en 3 ejes, permitiéndonos acceder a los valores en grados de las variables pitch, roll y yaw.

Ilustración 9 - Información otorgada por el Wiimote

2. Sensor infrarrojo: El wiimote también posee una cámara infrarroja que permite (usando una barra de leds similar al de la wii) determinar el lugar al que está apuntando y ayuda a aproximar la orientación en el tercer eje. Esta cámara también puede ser utilizada en sentido inverso: dejando el wiimote en un soporte fijo y moviendo algún tipo de puntero 18

infrarrojo. Johnny Chung Lee ha explotado esta característica para hacer varios proyectos interesantes2.

c. Usando el wiimote para controlar robots Debido a que todos los proyectos de control de robots usan Etoys como base, su vinculación con SqueakWiimote es trivial. Así, es posible usar el wiimote para controlar cualquier tipo de robot de formas muy variadas. Por ejemplo: 1. Grúa: Una grúa robótica desarrollada con la interfaz de puerto paralelo descrita anteriormente puede manipularse fácilmente con movimientos de la mano.

Ilustración 10 - Grúa controlada por Wiimote

Podemos encontrar estos proyectos en: http://johnnylee.net/projects/wii/

Ilustraci贸n 11 - Ejemplo de guiones vinculando Wiimote con Edukit

2. Robosapien: Usando dos wiimotes pueden controlarse brazos, piernas, cabeza o cualquier otra parte del cuerpo de un Robosapien.

Ilustraci贸n 12 - Robosapiens

Ilustración 13 - Etoy Robosapien junto con etoy Wiimote

3. Auto robot: Teniendo un auto robot con ruedas diferenciales3, se pueden usar dos wiimotes para controlar cada rueda por separado; o usar los valores de pitch y roll para definir cuánto se mueve el robot hacia delante y cuánto gira, respectivamente.

Se llama así a un robot con dos ruedas, una a la izquierda y otra a la derecha, cada una con un motor independiente.

Ilustración 14 - Wiimote con LegoNxt

4. Auto robot con cámara: También puede utilizarse la cámara infrarroja del wiimote para controlar robots. De esta manera, podemos detectar la posición de uno o varios (hasta 4, de hecho) leds infrarrojos. Armando una sencilla vincha con un led infrarrojo en el medio y colocando el wiimote en una base fija que apunte directo hacia nosotros podemos usar la 22

diferencia de posición del led con respecto del centro de la pantalla para determinar las velocidades de los motores y simular un control por movimientos de la cabeza. Si al robot le añadimos una cámara inalámbrica y lo manejamos remotamente sólo mirando lo que el robot “ve”, se logra un efecto de inmersión muy interesante.

Ilustración 15 - Control de robot inmersivo

Ilustración 16 - ER1 con Wiimote

7) Conclusiones Consideramos que Squeak Etoys y la robótica son perfectos aliados para propósitos educativos ya que intersectan el mundo real con el mundo virtual a fin de crear un ambiente propicio para el aprendizaje. Dado que el proyecto todavía se encuentra en su primera etapa, todavía no ha sido probado completamente con estudiantes. Sin embargo, se lo ha introducido a estudiantes en conferencias y exposiciones a lo largo de Argentina teniendo buenos resultados y demostrando que los chicos, especialmente los más jóvenes, se sienten muy atraídos por los robots. Enseñar robótica es un buen pretexto para situar al estudiante en el rol de inventor usando su propia creatividad. Cuando los estudiantes tienen la chance de ser creadores los trabajos resultantes suelen ser impresionantes. Como dijo Jean Piaget, “el fin principal de la educación en las escuelas es crear hombres y mujeres que sean capaces de hacer cosas nuevas, no simplemente repetir lo que otras generaciones han hecho; hombres y mujeres que sean creativos, ingeniosos y descubridores, que puedan criticar y verificar, y no sólo aceptar, lo que les ofrecen” [4]. El sistema educativo como está establecido en la mayoría de los países restringe la imaginación y creatividad natural de los estudiantes jóvenes. Es necesario promover alternativas a la manera 24

tradicional de enseñar y aprender. El uso apropiado de tecnologías como computadoras o robots puede ser el primer paso hacia una revolución educativa a favor del desarrollo humano integral. Aunque queda mucho por hacer, la existencia de proyectos como OLPC y Etoys, junto con el surgimiento de diversas plataformas de hardware de robótica muestran que todavía hay interesantes caminos por recorrer.

8) Referencias *1+ Jaques Delors, In’am y otros. “La educación encierra un tesoro”. México : Correo de la UNESCO, 1996 302 p. Informe a la UNESCO de la Comisión Internacional sobre la educación en el siglo XXI, presidida por Jacques Delors. [2] “The Dynabook Revisited - A Conversation with Alan Kay”, Interview in The Book & The Computer, 2002. [3] Seymour Papert y Idit Harel, “Constructionism”, Ablex Publishing Corporation, 1991. *4+ Jean Piaget quoted in “Education for Democracy, Proceedings from the Cambridge School Conference on Progressive Education”, eds. Kathe Jervis and Arthur Tobier, 1988.