Embed Size (px)
Citation preview
AMBIENTE PROTOTIPO PARA TELEOPERACION DE ROBOTS
JUAN DIEGO BOTIVA LEON
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERIA
DEPARTAMENTO DE SISTEMAS Y COMPUTACION
GRUPO DE INFORMÁTICA GRAFICA
BOGOTA D.C.
SEPTIEMBRE DE 2004
AMBIENTE PROTOTIPO PARA TELEOPERACION DE ROBOTS
JUAN DIEGO BOTIVA LEON
Tesis para optar al título de
Ingeniero de Sistemas y Computación
Profesor Asesor
PABLO ALEJANDRO FIGUEROA FORERO
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERIA
DEPARTAMENTO DE SISTEMAS Y COMPUTACION
GRUPO DE INFORMÁTICA GRAFICA
BOGOTA D.C.
SEPTIEMBRE DE 2004
A mis padres Sergio y Mª. Constanza,
mis hermanos Andrés y Mª. Alejandra,
y a Sandra
AGRADECIMIENTOS
Agradezco a todos los que de una u otra forma me ayudaron en el desarrollo de este
trabajo.
En especial a mis padres y a mis hermanos por su apoyo y motivación, siempre les estaré
agradecido.
A Sandra, por su cariño, apoyo y ánimo constantes.
A mi asesor Pablo Figueroa por su guía y valiosos aportes y a mi asesor de Ciclo
Terminal 1, Fernando De la Rosa.
TABLA DE CONTENIDO
1. INTRODUCCION ........................................................................................................ 1
1.1. OBJETIVO GENERAL....................................................................................... 2
1.2. OBJETIVOS ESPECIFICOS............................................................................... 2
1.3. PLAN DEL DOCUMENTO................................................................................ 3
2. MARCO TEORICO...................................................................................................... 5
2.1. TELEOPERACION............................................................................................. 5
2.1.1. Definición ................................................................................................ 5
2.1.2. Problemas de la Teleoperación ................................................................ 7
2.1.2.1. Retardos en la Comunicación ................................................... 7
2.1.2.2. Pérdida del Enlace de Comunicación ....................................... 8
2.1.2.3. Factor Humano.......................................................................... 8
2.1.2.4. Confiabilidad............................................................................. 8
2.1.3. Control Colaborativo ............................................................................... 9
3. TRABAJOS RELACIONADOS ................................................................................ 10
3.1. SISTEMAS DE TELEOPERACION ACTUALES .......................................... 10
3.1.1. Standardized Teleoperation System (STS) ............................................ 10
3.1.2. TELEDRIVE.......................................................................................... 11
3.1.3. Advanced Teleoperation Interfaces ....................................................... 12
3.2. PROYECTOS DE TELEOPERACION CON EL LEGO RCX........................ 13
3.2.1. Proyecto Red Rover Goes to Mars......................................................... 13
3.3. ALCANCE DEL PRESENTE TRABAJO ........................................................ 14
4. DESCRIPCION DEL SISTEMA ............................................................................... 16
4.1. HARDWARE .................................................................................................... 17
4.1.1. Lego Robotics Invention System 2.0 ..................................................... 17
4.1.2. Construcción del Robot Móvil............................................................... 19
4.2. SOFTWARE...................................................................................................... 23
4.2.1. leJOS...................................................................................................... 23
4.2.1.1. Memoria.................................................................................. 25
4.2.1.2. Hilos........................................................................................ 25
4.2.1.3. Arreglos................................................................................... 26
4.2.1.4. Modelo de Eventos ................................................................. 26
4.2.1.5. Excepciones ............................................................................ 26
4.2.1.6. Recolección de Basura............................................................ 27
4.2.2. API de leJOS.......................................................................................... 27
4.2.2.1. Salida....................................................................................... 27
4.2.2.2. Entrada .................................................................................... 28
4.2.2.3. Botones del RCX .................................................................... 28
4.2.2.4. Batería ..................................................................................... 29
4.2.2.5. LCD......................................................................................... 29
4.2.2.6. Parlante ................................................................................... 29
4.2.2.7. Comunicación IR .................................................................... 29
4.2.3. Modificaciones Realizadas a leJOS....................................................... 31
4.2.4. Respuesta del Sistema a Problemas de Teleoperación .......................... 32
4.2.5. Diseño de la Primera Versión del Sistema............................................. 33
4.2.5.1. Diagrama de Clases Aplicación del PC .................................. 34
4.2.5.2. Diagrama de Clases Aplicación del RCX............................... 40
4.2.5.3. Diagramas de Secuencia ......................................................... 43
4.2.6. Diseño de la Segunda Versión del Sistema............................................ 47
4.2.6.1. Diagrama de Clases Aplicación del PC .................................. 48
4.2.6.2. Diagrama de Clases Aplicación del RCX............................... 52
4.2.6.3. Diagramas de Secuencia ......................................................... 55
4.3. AMBIENTE....................................................................................................... 59
4.4. LIMITANTES.................................................................................................... 60
4.4.1. Memoria del RCX.................................................................................. 60
4.4.2. Medio de Comunicación PC – RCX...................................................... 60
5. PRUEBAS DEL SISTEMA........................................................................................ 62
6. CONCLUSIONES Y TRABAJO FUTURO .............................................................. 69
7. REFERENCIAS.......................................................................................................... 71
8. APENDICE A............................................................................................................. 74
1
1. INTRODUCCION
La robótica es un área con un potencial enorme, que ha contribuido en las últimas
décadas en un variado conjunto de operaciones como manufactura, construcción,
demolición, vigilancia, entre otros.
Una de las grandes ventajas que ha introducido la robótica, es que ha permitido que el
hombre llegue a lugares donde, por distancia o por seguridad no puede ir. Podemos tomar
como ejemplos el Mobot Ch-KhV [12] que trabajó en la planta de energía nuclear de
Chernobil luego del desastre, y el Soujurner [13], un vehículo que fue enviado hasta
Marte para hacer diferentes análisis sobre la superficie. Estos robots no eran totalmente
autónomos. Para que estos robots pudieran desarrollar su labor, necesitaban de la
asistencia de un humano.
Otros campos en los que este tipo de robots controlados a distancia se utilizan son: la
detección de minas antipersonales y de otros tipos (terrestres y submarinas), desarme
remoto de artefactos explosivos, vigilancia y exploración, entre otros. Como se puede
ver, las aplicaciones son muchas y muy variadas; desafortunadamente, estos robots y los
sistemas que los controlar son muy costosos para llegar a ser usados en cantidad
considerable en Colombia.
Actualmente en Internet se encuentran muchos sitios que ofrecen la oportunidad de
controlar un robot desde el lugar en que se encuentre la persona conectada, estos sitios
son muy interesantes, ya que acercan a las personas comunes a la robótica, sin embargo,
estos sistemas no evolucionan para convertirse en algo útil para el sector productivo.
2
La motivación de este trabajo es explorar los problemas inherentes a un sistema de
teleoperación, mediante la implementación de un prototipo sobre una plataforma
comercial. Es nuestro objetivo que nuestras conclusiones sean útiles en el contexto
industrial colombiano y en la Universidad.
1.1. OBJETIVO GENERAL
El objetivo general de este trabajo es diseñar un prototipo de un ambiente de
teleoperación de robots, con tecnologías libre y hardware de bajo costo, que
eventualmente pase de ser un prototipo a un sistema con opciones de uso reales.
1.2. OBJETIVOS ESPECIFICOS
Dentro del marco del objetivo general de este trabajo, los objetivos específicos que se
esperan lograr son los siguientes:
• Adquirir conocimiento en el área de robótica y en especial de teleoperación, como
está el estado del arte, que problemas y retos enfrenta y que se ha hecho por
solucionarlos.
• Adquirir conocimiento en las tecnologías libres disponibles para el desarrollo del
prototipo.
• Afianzar los conocimientos adquiridos en diferentes cursos vistos en la
Universidad, con un problema real.
3
• Diseñar una solución que sea lo más independiente posible de la tarea que el robot
desempeñe, con el fin de que la mayor parte del sistema sea reutilizable en otras
actividades.
• Desarrollar un piloto que permita poner a prueba las diferentes características del
prototipo.
1.3. PLAN DEL DOCUMENTO
La estructura del presente documento es la siguiente:
En el segundo capítulo, se explican algunos conceptos necesarios para la comprensión de
este trabajo. Se inicia con el concepto de teleoperación, requerimientos y problemas
relativos a ésta y finalmente se expone el concepto de control colaborativo, que se
pretende sea involucrado poco a poco en la evolución futura de este trabajo.
En el tercer capítulo, se mencionan algunos trabajos recientes relacionados con
teleoperación con el fin de poner al lector en contexto con el estado del arte en la materia.
Se inicia mostrando sistemas de teleoperación actuales y luego aquellos que se basan en
el Lego RCX. No se mencionan trabajos hechos en la Universidad, debido a su
antigüedad y poca relación con el que se desea desarrollar.
En el cuarto capítulo, se hace una descripción general del sistema que se ha desarrollado.
Se comienza presentando el hardware utilizado y sus características, y se explica cómo se
llegó al diseño actual del robot. A continuación, se describen las características del
software que funciona como máquina virtual en el controlador del robot, su API y las
modificaciones que se le debieron hacer para usarlo en teleoperación. Dentro de ésta
sección, se hace la descripción detallada del diseño del sistema en sus dos versiones, se
incluye el diagrama de clases y un diagrama de secuencia para ilustrar el funcionamiento
4
en condiciones normales de operación. Por último se describe cómo es el ambiente en el
que opera el robot y las limitantes de hardware/software del sistema.
En el quinto capítulo, se exponen las pruebas realizadas al sistema y se incluyen
imágenes de la demostración ejecutada.
Se incluye un apéndice con las instrucciones de armado del robot. Cabe anotar que se
usaron partes adicionales al Robotics Invention System 2.0 y un sensor fue
proporcionado por la Universidad.
5
2. MARCO TEORICO
2.1. TELEOPERACION
2.1.1. Definición
Teleoperar un dispositivo significa operarlo a distancia, permite sentir y actuar en una
ubicación remota. [2] considera que la teleoperación no es solo el control directo (sin
funciones autónomas) sino que comprende un espectro más amplio desde el control
manual hasta el de supervisión. Un sistema de teleoperación puede emplear control
continuo/directo, control intermitente/supervisión o cualquier punto intermedio. El tipo
de control puede variar sobre el tiempo o en función de la situación y puede ser
compartido/intercambiado entre el operador y el robot remoto.
El marco de trabajo básico de teleoperación según [2] es el siguiente: Un operador
humano trabaja en una estación de control, generando comandos a través de dispositivos
de entrada/control y recibiendo retroalimentación en monitores. El vehículo remoto, que
ejecuta los comandos del operador, está equipado con sensores, actuadores, y
frecuentemente algún nivel de autonomía. El operador y el vehículo están separados por
una barrera (ambiente, distancia, tiempo, etc.) e intercambian información a través de un
enlace de comunicaciones (figura 1).
6
Figura 1. Marco de Trabajo de Teleoperación
Tomada de [2]
En el caso de teleoperación de vehículos o robots móviles, ésta tiene requerimientos
adicionales que la distinguen del simple control remoto y de otros tipos de teleoperación
(telemanipulación). Los requerimientos son:
• Navegación confiable: El robot debe saber con exactitud donde se encuentra en
el espacio.
• Generación de comandos de movimiento eficiente: El robot, dado un comando
de movimiento, debe ser preciso en sus movimientos para que la posición final
sea la esperada.
• Interpretación precisa de los datos de los sensores: Si no se interpreta de
manera correcta la información proveniente de los sensores, se pueden tomar
decisiones erradas por parte del robot o del operador.
7
2.1.2. Problemas de la Teleoperación
A continuación se describen brevemente algunos de los problemas y desafíos relativos a
la teleoperación y las soluciones que se han llevado a cabo para resolverlos o mitigarlos.
2.1.2.1. Retardos en la Comunicación
Este es uno de los problemas más cruciales. Debido a que el dispositivo controlado y el
operador no se encuentran en el mismo ambiente, debe haber un enlace de
comunicaciones, que muy probablemente introduzca retardos en el envío de órdenes y
recepción de retroalimentación. Los retardos se pueden incrementar por factores tan
diversos como clima (afectando la confiabilidad del enlace de comunicación),
inestabilidad del sistema del dispositivo controlado o de la estación de control.
El retardo puede ser de dos tipos: fijo o variable. En el retardo fijo, el tiempo de retraso
entre el envío y la recepción de órdenes o retroalimentación es siempre el mismo, en el
retardo variable no hay certeza con respecto al tiempo de retraso y puede que no haya
retraso del todo (no hay retardo) o el retraso sea muy grande.
Como solución a este problema, se utilizan visualizaciones predictivas. Estas consisten en
el uso de realidad virtual para darle al operador una retroalimentación en tiempo real de
las órdenes que éste da, tanto en visualización (el dispositivo ubicado en el ambiente
virtual se antepone a la visualización del robot real) como en fuerzas (force feedback,
resultante de la interacción del dispositivo virtual con el ambiente virtual), antes de ser
enviadas al dispositivo real, en caso de que las acciones del dispositivo virtual sean
consideradas satisfactorias, se enviarán las ordenes al robot real.
8
2.1.2.2. Pérdida del Enlace de Comunicación
Se puede perder el contacto entre el dispositivo controlado y la estación de control por
obstrucciones, posición y/o distancia entre ellos. Esto está fuertemente relacionado a las
limitaciones inherentes al medio de comunicación (infrarrojos, radio, etc.). Por ejemplo,
en el caso de utilizar infrarrojos, la potencia de los emisores puede restringir las
condiciones a que debe haber línea de visión entre el emisor y el receptor.
2.1.2.3. Factor Humano
El operador por diversas razones (poco entrenamiento, cansancio, mala interpretación de
los sensores, etc.), puede juzgar mal y dar una orden errónea. Si el dispositivo controlado
se encuentra en un ambiente peligroso (no seguro), esto puede llegar a afectar seriamente
la estabilidad del sistema completo y la integridad del dispositivo.
A pesar de esto, operador humano sigue jugando un papel muy importante, ya que cuenta
con capacidades que aún una máquina no puede lograr, la solución que se le da a este
inconveniente es asistir al humano en las tareas que más se le dificultan y que de esta
forma se dedique a las que realmente requieren de su intervención. Este es un poco el
enfoque del Control Colaborativo de [2], expuesto más adelante.
2.1.2.4. Confiabilidad
El dispositivo controlado en si, puede introducir errores en el sistema debido a su
construcción, sensores descalibrados, problemas en la alimentación de poder, etc. Las
condiciones del ambiente de operación pueden también tener consecuencias en la
operación del sistema.
Para anticiparse a las consecuencias que esto pueda tener, se realizan simulaciones de una
operación o un conjunto de estas en ambientes de realidad virtual, en donde se puede ver
9
la respuesta del dispositivo a las órdenes y al ambiente (asumiendo que el modelo del
dispositivo refleja fielmente el comportamiento real del mismo).
2.1.3. Control Colaborativo
Un nuevo modelo de teleoperación propuesto por [2] es el Control Colaborativo. En este
modelo, un humano y un robot colaboran para desempeñar tareas y alcanzar metas
comunes. En vez de un humano siempre estando completamente “en control”, el robot
esta más en igualdad y puede tratar al humano como una fuente limitada de planeación e
información, tal como otros módulos del sistema.
Una consecuencia importante de este modelo es que el robot puede decidir como usar el
consejo humano: seguirlo cuando este disponible y es relevante; para modificarlo (o
incluso ignorarlo) cuando sea inapropiado o inseguro. De esta forma, si el robot está
operando autónomamente y tiene problemas, puede preguntarle al operador “Que debo
hacer?” Si el humano está en capacidad de responder (y puede hacerlo pronto), entonces
se hará lo que diga. Sin embargo si la respuesta llega tarde (debido a un retardo en la
comunicación) o es insegura, entonces el robot puede ver el consejo con escepticismo y
buscar aclaración (“esta seguro?”), reformular la pregunta (“Que otras opciones
diferentes tengo?”) o negociar (“puedo hacerlo de otra forma?”).
Esto no significa que el robot se convierta en el “amo” del sistema, éste aun sigue una
estrategia de alto nivel establecida por el humano. Sin embargo el robot tiene más
libertad en la ejecución y es capaz de funcionar mejor si el operador está distraído, no
está atento o no está disponible. Como resultado, la teleoperación se vuelve más
adaptable, más flexible y permite acomodar mejor diferentes niveles de autonomía,
interacción y capacidades humanas.
10
3. TRABAJOS RELACIONADOS
A continuación se mencionan algunos de los sistemas de teleoperación de vehículos
disponibles en la actualidad, tanto comerciales como proyectos de investigación y libres,
con el fin de contextualizar al lector en el estado del arte del campo.
3.1. SISTEMAS DE TELEOPERACION ACTUALES
3.1.1. Standardized Teleoperation System (STS) [19]
Este sistema fue desarrollado originalmente por Omnitech Robotics International LLC,
para el Unmanned Ground Vehicles/Systems Joint Program Office de Estados Unidos, la
Marina y la Armada del mismo país. Está formado por componentes modulares para
convertir cualquier vehículo a control remoto, control teleoperado o control
semiautónomo. Puede controlar el encendido y apagado del motor, acelerador, luces,
frenos, dirección, caja de cambios y el manipulador que pueda tener el vehículo (pala,
cuchilla, etc.) .
11
Figura 2. Standardized Teleoperation System (STS)
Tomada de [19]
Este sistema se ha utilizado en aplicaciones tanto militares como comerciales. La
aplicación militar más frecuente es la detección y remoción de minas y la comercial es la
manipulación de material peligroso pesado.
3.1.2. TELEDRIVE [20]
Este proyecto del Laboratorio de Automóviles de la Universidad de Zaragoza, España,
tiene el objetivo de desarrollar un sistema completo de teleoperación de vehículos. Está
actualmente en desarrollo y participan varias empresas comerciales de España, Italia y
Francia. Tiene como principales características la integración de interfaces
multisensoriales (replicación de la dinámica del vehículo), técnicas avanzadas e
visualización (para introducir información adicional en la visualización) y teleoperación
multioperador (manejo simultaneo, supervisión, etc.).
El sistema está conformado por:
• Una estación de control multisensorial, la cual genera estímulos visuales,
auditivos y cinéticos.
• Un salón de muestra para pasajeros virtuales, el cual genera estímulos visuales,
auditivos y cinéticos.
12
• Una estación de supervisión multisensorial, la cual genera estímulos visuales,
auditivos y cinéticos (dependiendo de la aplicación específica).
• Un vehículo operado remotamente (adaptación de uno comercial) adecuado para
la aplicación especifica del proyecto.
• Enlaces de comunicación (RF, Internet y/o GPRS) entre el vehículo y las
estaciones del operador/supervisor/salón de muestra y el sistema global de
control.
Los campos de aplicación potenciales del proyecto son:
• Entretenimiento y diversión: visitas a ruinas submarinas, observación de fauna o
conducción remota.
• Educación: Información visual complementada con realidad aumentada.
• Intervenciones remotas en ambientes peligrosos: plantas nucleares, lugares de
desecho de residuos, etc.
• Actividades subterráneas/submarinas: minería, reparación, mantenimiento, etc.
• Herramienta de propósito general para proyectos de investigación en telepresencia
y teleoperación.
3.1.3. Advanced Teleoperation Interfaces [21]
Es un proyecto de la misma persona que propuso el Control Colaborativo, mencionado
anteriormente, en el Robotics Institute de la universidad de Carnegie Mellon, junto con el
Instituto Federal de Tecnología de Suiza. Consiste en el diseño de varias herramientas
que hagan de la teleoperación algo más accesible para usuarios novatos como para
expertos, mediante el empleo del Control Colaborativo.
Dentro de las herramientas se destacan:
13
• PdaDriver: interfase basada en PocketPC para la teleoperación de vehículos.
• WebDriver: interfase basada en Web para la teleoperación de vehículos.
• GestureDriver: interfase basada en HOT (Human Oriented Tracking), una librería
que ubica la cabeza y las manos de un humano usando cámaras de video
estereoscópicas para interpretar gestos basada en un vocabulario establecido.
3.2. PROYECTOS DE TELEOPERACION CON EL LEGO RCX
3.2.1. Proyecto Red Rover Goes to Mars [22]
Es un proyecto de The Planet Society (fundada por Carl Sagan), con el apoyo de The
LEGO Group, que tiene el objetivo de que cualquier persona con acceso a Internet, viva
la experiencia de explorar un planeta desconocido a través de los ojos de un robot móvil.
Consiste de varias “estaciones” que recrean una zona del ambiente marciano y que
permiten al usuario teleoperar un robot, moviéndolo en cuatro direcciones y tener
retroalimentación a través de una cámara que tiene equipada el robot o una cámara
externa. Las estaciones son mantenidas por diferentes universidades de los Estados
Unidos y Europa. En esta investigación se utilizo la estación MARS STATION South
Pole2 [23], alojada en Marshall University, en Huntington, West Virginia, USA.
14
Figura 3. Panel de Control de Red Rover Goes to Mars
Tomada de [23]
Figura 4. Uno de los robots de Red Rover Goes to Mars en su ambiente.
Tomada de [22]
3.3. ALCANCE DEL PRESENTE TRABAJO
Debido a las limitaciones de tiempo y costo, y a que el interés de este trabajo es
comprender los problemas de las aplicaciones de teleoperación, el ambiente que se
desarrolló presenta las siguientes limitaciones:
15
• Rango de Operación: El rango de operación del robot está limitado debido a que
el medio de transmisión es infrarrojo, con un alcance máximo de 10 metros
aproximadamente.
• Controlador del Robot: El hardware que controla el robot presenta limitaciones
en cuanto al número se sensores (3) y actuadotes (3), y no se cuenta con una
cámara para retroalimentar al operador. Solo se dispone de dos motores, un sensor
de rotación, un sensor de luz y dos sensores de contacto.
• Retroalimentación: El operador recibe retroalimentación visual (no
multisensorial) a través del monitor de la estación de control, en esta
retroalimentación no hay video ni imágenes.
• Interface: Se dispone de una interfaz de teleoperación que es una aplicación con
interfaz gráfica que corre en un computador (PC o Mac) y que se controla con
ratón y teclado, no se dispone de interfaz gestual o con joystick o que corra en
dispositivos móviles o por Web.
• Operadores: Solo un operador puede estar usando el sistema a la vez.
16
4. DESCRIPCION DEL SISTEMA
El problema que se planea resolver consiste en el diseño e implementación de un
ambiente prototipo para la teleoperación de robots, basado en la propuesta de control
colaborativo hecha por Fong [2]. Igualmente se pondrá a prueba el diseño del sistema
para determinar que tan bien se comporta frente a los problemas de teleoperación.
Se utilizará un robot móvil como el dispositivo controlado. Como tarea para probar la
funcionalidad del sistema se operará el robot en un ambiente desconocido para el
operador (con ciertas condiciones) y tratar de reconstruir parcialmente ese ambiente con
la información de los sensores.
El sistema tendrá varios niveles de autonomía (operador, estación de control y robot) En
caso de detectar una situación anormal, el robot avisa al operador de lo acontecido.
La tarea que va a desempañar el robot, y el sistema en general, es la de reconocer ciertos
elementos en un ambiente construido para tal fin. Más adelante se dan los detalles del
ambiente y su construcción.
A continuación se detallan los recursos de hardware y software usados en el desarrollo
del sistema, así como el sistema en si.
17
4.1. HARDWARE
4.1.1. Lego Robotics Invention System 2.0
Este kit se utilizó para construir un robot móvil como dispositivo controlado. Consiste en
un conjunto de 700 de piezas de Lego, junto con un microcomputador programable
(RCX) y un puerto infrarrojo USB para transmisión de datos entre el RCX y un PC o
Mac, además, incluye 2 motores, 2 sensores de contacto y 1 sensor de luz, etc. A
continuación se detallan las características del RCX 2.0.
El RCX 2.0 es un microcomputador basado en el Renesas (antes Hitachi) H8/3292,
trabaja a 16 MHz, tiene 16K de ROM y 32K de RAM externa. Tiene 3 entradas y tres
salidas, LCD, puerto infrarrojo y generador de tonos. Funciona con 6 pilas de 1.5 voltios
(AA).
El puerto infrarrojo se usa para descargar programas al RCX y para enviarle comandos, el
RCX puede a su vez enviar información de retroalimentación. Esto permite tener una
lógica más poderosa en el computador anfitrión y que la que se programe en el RCX se
limite a seguir instrucciones de movimiento o decisiones sencillas.
Para permitir la interacción del RCX con el entorno, se utilizan las entradas y salidas de
este. Las salidas permiten accionar motores, encender luces, entre otras. Las entradas
permiten el uso de diferentes sensores. Los sensores incluidos en el kit son:
• Luz: Permiten detectar la intensidad de luz.
• Contacto: Permite saber si hay contacto con otro objeto.
18
Adicionalmente, se encuentran disponibles los siguientes sensores:
• Temperatura: Permite leer la temperatura.
• Rotación: Permite leer la velocidad de rotación de un elemento.
Las interfaces análogas de propósito general permiten conectar una gran variedad de
sensores al RCX, su papel es convertir la salida de estos sensores, a valores que puedan
ser leídos por el RCX.
La limitación de tres entradas y tres salidas puede ser eliminada al usar multiplexores que
se pueden adquirir o ser fabricados por uno mismo.
Para programar el RCX existen diferentes alternativas desde el software incluido con el
RCX, hasta reemplazos de firmware que permiten usar lenguajes existentes (con algunas
modificaciones y restricciones) como C, C++, Java, Perl y Visual Basic, entre otros.
Figura 5: Lego RCX 2.0
Tomada de [15]
19
Figura 6: Lego RCX 2.0 con Motores Figura 7: Lego RCX 2.0 con Sensores Tomada de [15] Tomada de [15]
4.1.2. Construcción del Robot Móvil
Antes del primer prototipo usado en la solución del problema, se construyeron dos
prototipos de robots móviles (que se denominarán A y B, figuras 8 y 9 respectivamente)
para probar el kit RIS 2.0 de Lego.
En todos los prototipos se buscó que el puerto infrarrojo del RCX quedara inclinado hacia
arriba con el fin de poder establecer comunicación si éste se encontraba apuntando en
dirección opuesta al puerto infrarrojo del computador, esto resultó efectivo cuando había
algún elemento frente al puerto del RCX, que reflejara los rayos infrarrojos hacia el
puerto del PC.
El primero de los prototipos usaba tracción sobre bandas (oruga), una vez terminado se
detectó que al ordenarle seguir una trayectoria en línea recta se desviaba de esta por dos
motivos: el primero es que los motores están diseñados para girar mejor en una dirección
particular y los motores en este robot giran en direcciones opuestas y el segundo es que
los motores no son completamente idénticos y esto se ve más cuando están sometidos a
una gran carga, como lo es mover la banda de tracción (oruga); por no contar con
20
sensores de rotación para hacer que los motores giraran a la misma velocidad, se decidió
utilizar como alternativa los dos sensores de contacto para que los ejes de las ruedas los
activaran cada media rotación (ver figura 10).
Aunque la trayectoria mejoraba bastante, el robot seguía desviándose principalmente por
que en algún momento uno de los sensores no se activaba. Para las rotaciones se encontró
que detectar media rotación no era útil ya que media rotación del piñón que impulsa la
banda (oruga) representaba alrededor de 7 centímetros de avance, lo que es demasiado
para poder realizar un giro de 90 grados con un buen grado de exactitud. Otro
inconveniente que se presentó con este prototipo era que al rotar, había mucho
deslizamiento entre la banda de tracción y el suelo, lo que hacia contar media rotación del
eje del piñón aún más inútil.
El segundo prototipo usaba cuatro ruedas donde el par de cada lado era impulsado por un
motor, también utilizaba los sensores de contacto y, aunque la trayectoria era casi recta,
presentaba el mismo problema de deslizamiento al rotar y los 90 grados tampoco se
podían hacer con exactitud. Como no era posible medir distancias relevantes de avance
con los sensores de contacto (solo tramos de aproximadamente 7 centímetros), se
incorporó un sensor de luz que detectara en el suelo una línea negra donde el robot debía
detenerse, al hacer esto se encontró que los sensores de contacto para las rotaciones
dejaban de funcionar correctamente debido a que, el estar interrogando continuamente al
sensor de luz, hacía que no se detectara a tiempo la activación de los sensores de contacto
y se perdiera este evento.
21
Figura 8: Prototipo A Figura 9: Prototipo B
Figura 10: Detalle de los sensores de contacto para detectar rotación
A partir de lo aprendido con los dos prototipos anteriores, se decidió buscar y utilizar
sensores de rotación para contar el número de rotaciones de cada una de las ruedas y de
esta forma, mantener el robot en una trayectoria lo más recta posible e igualmente hacer
posible que el robot rotara lo más cercano a los 90 grados. Finalmente, solo fue posible
incorporar al robot un sensor de rotación proporcionado por la universidad. Para poder
cumplir con el objetivo de mantener trayectorias rectas y de hacer rotaciones más
precisas con un solo sensor de rotación, fue necesario utilizar un diferencial (ver figura
11), lo que hizo posible que las ruedas roten a la misma velocidad, pero imposibilitó el
medir distancias. Cabe anotar que con un solo sensor de rotación es posible que el robot
gire 90 grados, pero no es posible lograr que las ruedas giren a la misma velocidad en
sentidos contrarios durante la rotación, por lo que no se garantiza que el robot gire sobre
su eje y es posible que se desvíe de la trayectoria esperada durante la rotación, sin
embargo, se hizo todo lo posible para minimizar la fricción de los engranajes y que de
esta forma la ruedas rotaran los más parejo posible.
22
Figura 11: Ensamblaje del Diferencial Usado en el Robot
Tomada de [1]
Con el fin de evitar el deslizamiento de las ruedas, se decidió que el robot solo tuviera
dos ruedas con tracción, ubicadas en la mitad de los costados laterales del robot, y un par
de llantas pequeñas de apoyo atrás que giran 360 grados. Para saber cuando detenerse, el
robot está equipado con un sensor de contacto apuntado hacia el suelo que se activa al
pasar el robot sobre una marca cuadrada ubicada en el suelo levantada unos 7 milímetros
del resto del suelo. Al escoger la tarea con la que se probaría el sistema, se decidió
incorporar un segundo sensor de contacto esta vez apuntado hacia el frente para detectar
obstáculos al avance del robot, igualmente se incorporó un sensor de luz al lado del
primer sensor de contacto, apuntado igualmente hacia abajo para detectar el color de la
marca sobre la que el robot se detuvo. Para superar la limitante de solo tres puertos de
entrada del Lego RCX, se conectaron los dos sensores de contacto al mismo puerto,
activándose este último cuando cualquiera de los dos sensores de contacto se active. Para
diferenciar entre una marca debajo del robot y un obstáculo en frente de éste, se usa el
sensor de luz, si debajo del robot el suelo es blanco (no hay marcas) significa que hay un
obstáculo en frente, cualquier otro color significa que hay una marca debajo del robot.
En la figura 12 se puede observar el diseño final del robot utilizado. Las instrucciones de
armado, paso a paso, se encuentran en el Apéndice A: INSTRUCCIONES DE ARMADO
DEL ROBOT.
23
Figura 12. El Robot visto desde varios ángulos.
4.2. SOFTWARE
4.2.1. leJOS
El microcomputador del robot (RCX) será programado en Java, para esto se usará leJOS,
un reemplazo de firmware (código de programa almacenado en ROM, aunque en el RCX
es RAM) para el RCX que implementa una máquina virtual Java reducida. Se escogió
leJOS ya que permite programar el robot en java, un lenguaje bien conocido por el
desarrollador, y por contar con un API muy completo que facilito enfocarse en el
problema a resolver. El robot se comunicará con la estación remota a través de un puerto
infrarrojo usando una adaptación de las clases de comunicación habituales de java,
24
proporcionadas por leJOS. A continuación se presenta los aspectos relevantes para el
desarrollo del sistema, de la descripción realizada por [1] de leJOS.
Inicialmente se creó TinyVM, una máquina virtual Java escrita en C para el RCX, junto
con software para descargar programas al RCX. También incluía un encadenador escrito
en Java. Ocupaba alrededor de 10K en el RCX, quedando cerca de 16K disponibles para
programas y datos. Las principales características son:
• Multitarea preventiva
• Excepciones
• Sincronización
• Arreglos, incluyendo arreglos multidimensionales
• Recursión
• Acceso a los botones del RCX
• Incluye un emulador
El proyecto de TinyVM se dividió y surgió leJOS. Las características adicionales a
TinyVM son:
• Operaciones de punto flotante
• Constantes de caracteres (String)
• Provee la clase java.lang.Math
leJOS se puede comparar con el Java 2 SDK de Sun Microsystems, ambos constan de una
máquina virtual Java (JVM) , un compilador (leJOS usa el mismo compilador de J2SE,
25
javac) y un API, que es un conjunto de clases que pueden usar los programadores que
proveen funcionalidades avanzadas.
La JVM es el firmware que reemplaza al estándar de Lego. Esta debe ser descargada al
RCX para que éste ejecute programas Java, ya que sabe interpretar el bytecode y se
comunica con la ROM del RCX para hacer lo que uno desea. La especificación de la
JVM de leJOS para el RCX se describe a continuación.
4.2.1.1. Memoria
El RCX tiene 32KB de memoria, de los cuales 4KB están fuera de alcance por ser de uso
exclusivo de la ROM, esto deja 28KB libres. leJOS ocupa 16KB, esto deja cerca de
12KB para los programas del usuario.
Figura 13. Mapa de memoria de la JVM de leJOS
Tomada de [1]
4.2.1.2. Hilos
El esquema de hilos de ejecución (threads) de leJOS es muy completo, permitiendo
sincronización e interrupción. Los hilos son controlados por un hilo planificador, que
permite que un hilo tome control del procesador durante un número determinado de
26
instrucciones (128 instrucciones en la última versión de leJOS). El planificador es muy
sencillo, mantiene una lista de los hilos actuales y cambia del hilo actual al siguiente
usando una función nativa escrita en C. En teoría, leJOS permite hasta 255 hilos
simultáneos, sin embargo, con las limitaciones de memoria del RCX, se debe mantener el
número de hilos en los estrictamente necesarios (alrededor de 5 si se monitorean los tres
sensores).
4.2.1.3. Arreglos
leJOS permite usar arreglos, incluyendo arreglos multidimensionales. Estos son muy
útiles en el caso de la navegación, para crear una grilla bidimensional y poder hacer un
seguimiento de la navegación. Aunque los arreglos multidimensionales son soportados,
hay que tener en cuenta las limitaciones de recursos del RCX.
4.2.1.4. Modelo de Eventos
leJOS es capaz de usar el modelo de eventos de Java, que incluye Listeners y Event
Sources. En el API de leJOS hay tres objetos que usan Listeners: Timer (TimerListener),
Button (ButtonListener) y Sensor (SensorListener). Este modelo permite un código
limpio, fácil de entender cuando se requiere que el RCX espere a que ocurra un evento.
En el modelo de eventos, un objeto actúa como un Event Source (fuente de eventos),
como un sensor. Al inicio de la ejecución del programa, uno o más objetos se registran
con el sensor para escuchar eventos. Cuando un evento ocurre todos los Listeners son
notificados del evento.
4.2.1.5. Excepciones
El manejo de excepciones ha sido incluido en leJOS. La ventaja del manejo de
excepciones es que separa la lógica regular del programa del código de chequeo de
27
errores. Los programas Java muestran un stack trace que facilita localizar el error en caso
de una excepción que no fue atrapada. En el caso de leJOS, cuando una excepción no es
atrapada por el programa, el RCX emite un sonido y muestra en el LCD un índice del
método que falló y el índice de la clase modulo 10. Para identificar la fuente del error se
hace un volcado de la imagen que se transfirió al RCX.
4.2.1.6. Recolección de Basura
leJOS en la actualidad no tiene recolección de basura (garbage collection). Debido a esto
se debe ser cuidadoso y reutilizar objetos en vez de crear nuevos. La última versión de
leJOS provee un mecanismo de reciclaje, con clases que hacen la reutilización posible de
una manera ordenada, sin dificultar el entendimiento del código.
4.2.2. API de leJOS
El paquete josx.platform.rcx, que hace parte del API de leJOS, es el encargado de
proveer acceso al RCX.
4.2.2.1. Salida
Los tres puertos de salida (A, B y C) pueden ser controlados con leJOS. En el caso de los
motores, estos pueden ser activados para moverse hacia adelante (método forward()),
hacia atrás (método backward()) o cambiar de dirección (método
reverseDirection()). Para parar los motores hay dos métodos: el primero es detener
el motor y aplicar una fuerza para mantenerlo bloqueado (breaking, con el método
stop()), la segunda es detener el motor sin aplicar fuerza y dejar que siga rotando hasta
que pare (coasting, con el método flt()). La potencia del motor también puede ser
ajustada con leJOS (con el método setPower(int)). Todo esto se hace con la clase
28
Motor, la cual tiene tres atributos estáticos (A, B y C) que son instancias de esta misma
clase, y que corresponden a los tres puertos de salida del RCX.
4.2.2.2. Entrada
Para cada puerto de entrada, debe especificarse el tipo y el modo
(setTypeAndMode(int,int)). El tipo de entrada (sensor) incluye el de los sensores Lego
estándar: luz, tacto, rotación y temperatura. El tipo de entrada se puede seleccionar
también como raw, de esta forma no se interpreta la entrada y se obtienen valores entre 0
y 1023. El modo especifica el tipo de recolección de datos que hará el RCX (los datos se
obtienen con readValue()), por ejemplo, la información del sensor de temperatura se
puede obtener en grados Celsius o en grados Fahrenheit. Esto se hace con la clase
Sensor, que al igual que Motor, tiene tres atributos estáticos (S1, S2 y S3) que son
instancias de Sensor. Si se desea que se notifique al haber algún cambio en la lectura del
sensor, se debe implementar la interfaz SensorListener (que solo define el método
stateChanged, a ser llamado al haber algún cambio y que recibe el sensor en el que
ocurrió el cambio, el valor anterior y el nuevo valor) y agregarla al correspondiente
sensor (método addSensorListener(SensorListener)). Antes de poder leer datos de
un sensor, este debe activarse para que reciba alimentación del RCX (con el método
activate()), también se puede especificar un valor anterior en el sensor, en especial
para el sensor de rotación para inicializarlo en cero sin importar la posición en que se
encuentre (con el método setPreviousValue(int))
4.2.2.3. Botones del RCX
Todos los botones, excepto el de encendido (On-Off) pueden ser reprogramados en
leJOS, gracias a que cuenta con el modelo de eventos.
29
4.2.2.4. Batería
leJOS permite determinar la carga de las baterías del RCX. Se obtiene un valor que es el
voltaje de las baterías, usando el método getVoltageMilliVolt().
4.2.2.5. LCD
Con leJOS es posible encender y apagar cualquier segmento del LCD del RCX, incluye
además un conjunto completo de letras arábigas, que resulta útil para presentar
información de depuración.
4.2.2.6. Parlante
Se puede usar leJOS para reproducir sonidos predefinidos del RCX. También permite
tener control total sobre la frecuencia y duración.
4.2.2.7. Comunicación IR
Los paquetes java.io y josx.rcxcomm de leJOS proveen los Streams estándar de Java
para enviar datos primitivos (byte, boolean, char, float, int y short) del PC al RCX, o del
RCX al PC, cualquiera puede iniciar la comunicación. Estos streams están soportados por
LLC (Low-level comms), un protocolo desarrollado por el grupo LEGO3 en DTU-IAU,
que garantiza entrega confiable mediante sumas de verificación, acks (confirmaciones) y
números de secuencia de un bit.
Las aplicaciones de usuario cuentan con un conjunto de clases que ofrecen métodos de
comunicación de alto nivel, las más utilizadas son DataOutputStream y
DataInputStream, que permiten la transmisión de tipos de datos primitivos de Java
(byte, boolean, char, float, int y short). Estas clases están soportadas a su vez por las
30
clases OutputStream e InputStream en el PC y RCXOutputStream e RCXInputStream
en el RCX, que ofrecen métodos para la transmisión de bytes. Para establecer la conexión
y poder usar estás clases, se utiliza la clase RCXPort, ya que esta es quien las instancia.
El protocolo LLC está implementado en las clases LLCHandler y LLCReliableHandler.
La primera trabaja con paquetes y acks (confirmaciones). La segunda garantiza entrega
confiable mediante el uso de sumas de verificación, acks (confirmaciones) y números de
secuencia de un bit. En el RCX el paso de los paquetes de LLC, desde LLCHandler hasta
el hardware, se hace a través de código nativo (escrito en C), utilizando la clase LLC. En
el caso del PC se hace a través de la clase Tower.
Figura 14. Comunicación RCX – PC con leJOS
Segmentos tomados de [6]
A continuación se detallan las clases que deben ser usadas por las aplicaciones de
usuario, con el fin de establecer comunicación entre dos RCXs p entre un RCX y un PC:
31
• RCXPort
Implementa manejo de streams de entrada/salida y buffer de entrada, utilizando
un manejador de paquetes. Se asegura de que todos los paquetes lleguen, si la
torre de comunicación no esta en el rango de alcance, la comunicación se
reintenta hasta volver a estar la torre en el rango de alcance y completar con éxito
la transferencia.
• DataOutputStream
Codifica varios tipos de datos en bytes y los envía a través de un stream de salida
de datos. El método que se utilizó de esta clase fue:
void writeInt ( int v ) Escribe un int al stream subyacente como un valor de 4 bytes.
• DataInputStream
Recibe bytes en un stream de entrada de datos y los codifica en uno de varios
tipos de datos. El método que se utilizó de esta clase fue:
int readInt ( )
Lee un int del stream subyacente.
4.2.3. Modificaciones Realizadas a leJOS
Con el fin de que el sistema pudiera enfrentar los problemas inherentes a la comunicación
en teleoperación, como pérdida del enlace de comunicación y retardos en la
comunicación, se hizo necesario modificar las clases LLCReliableHandler y
RCXAbstractPort, ya que estas permitían especificar un time-out de lectura, pero no de
32
escritura (se reintentaba el envío hasta tener éxito) y este último es indispensable para
poder detectar que se perdió la comunicación o que un retardo es demasiado largo.
Se agregaron los atributos enteros attempts y ackTimeOut a la clase
LLCReliableHandler, con sus correspondientes métodos de set y get, que son llamados
desde RCXAbstractPort por unos métodos con el mismo nombre, y estos a su vez son
llamados por el usuario en su programa (usando la clase RCXPort). El atributo attempts
especifica cuantas veces se debe intentar enviar un dato antes de generar una excepción
(IOException), el atributo ackTimeOut especifica cuantos milisegundos se debe esperar
por una respuesta de confirmación (acknowledge) de la recepción del dato, antes de
volver a intentar o de generar una excepción si era el último intento.
Estos cambios se hicieron públicos a la comunidad a través de la lista de discusión de
leJOS, ya que se consideró que podían ser de utilidad para otras personas y podrían ser
incluidos en una próxima versión de leJOS.
4.2.4. Respuesta del Sistema a Problemas de Teleoperación
Para enfrentar el problema de los retardos y la pérdida del enlace de comunicación, el
programa de control del robot dispone de un buffer en el que almacena secuencialmente
las órdenes que debe ejecutar y otro buffer donde almacena las lecturas de los sensores.
Luego de recibir una serie de órdenes, el robot comenzará a ejecutarlas una por una
enviando una confirmación de éxito al finalizar una exitosamente. En caso de no haber
comunicación (ya sea que no hay enlace o existe un retardo muy grande), las lecturas de
los sensores y las confirmaciones de éxito, serán almacenadas en el buffer y enviadas
cuando se reestablezca el enlace de comunicación.
Al aplicar el modelo de Control Colaborativo en el desarrollo de este sistema, se logran
minimizar los problemas relacionados con el factor humano al prescindir del operador en
los casos en que sus decisiones puedan comprometer la estabilidad e integridad del
33
sistema, además de los casos en que por fallas de comunicación u otras circunstancias, el
operador no esté disponible.
4.2.5. Diseño de la Primera Versión del Sistema
La primera versión soporta cuatro modos: directo, cola de comandos, autónomo RCX y
autónomo PC.
El modo directo cosiste en que el operador le envía comandos al robot y a medida que el
robot los recibe, los ejecuta; el operador debe esperar la finalización del comando que se
está ejecutando antes de enviar uno nuevo. El modo cola de comandos consiste en que el
operador define un conjunto de comandos, los cuales son enviados al RCX y
posteriormente éste los ejecuta y va enviando la respuesta de cada uno a medida que
termina su ejecución. En el modo autónomo RCX, el programa en el RCX decide los
comandos a ejecutar y envía solo las respuestas al PC. En el modo autónomo PC, el PC
decide el comando a ejecutar, lo envía al RCX y cuando recibe la respuesta del comando
por parte del RCX, decide el siguiente comando y así sucesivamente hasta que determina
que terminó la tarea.
Los comandos son representados por identificadores, atributos estáticos enteros
almacenados bajo un nombre fácil de entender en una clase aparte, igual que las
respuestas a los comandos. Tanto la clase de constantes de comandos como la de
respuestas a estos, son idénticas tanto en el PC como en el RCX.
El diseño de esta primera versión responde a la necesidad de separar la lógica de la tarea
a realizar, del resto del sistema, aunque algunos comandos, como el de la carga de la
batería y la memoria libre quedaron dentro de la clase de comunicaciones. Sin embargo,
un cambio en la tarea puede representar cambios significativos si por ejemplo el robot
deja de ser un robot móvil a ser un manipulador.
34
4.2.5.1. Diagrama de Clases Aplicación del PC
<<ex
cept
ion
>>B
lock
edPa
thEx
cept
ion
Com
man
d
<<cr
eate
>>+C
omm
and(
bVal
ue:b
yte)
:Com
man
d+g
etC
omm
and(
):Byt
e+s
etS
ent()
:voi
d+w
asS
ent()
:boo
lean
+set
Exe
cute
d():v
oid
+was
Exe
cute
d():b
oole
an
Com
mun
icat
ionE
vent
<<cr
eate
>>+C
omm
unic
atio
nEve
nt(s
ourc
e:O
bjec
t,bS
tate
:boo
lean
):Com
mun
icat
ionE
vent
<<cr
eate
>>+C
omm
unic
atio
nEve
nt(s
ourc
e:O
bjec
t,iD
ata:
int):
Com
mun
icat
ionE
vent
+con
nect
ionL
ost()
:boo
lean
+con
nect
ionR
esto
red(
):boo
lean
+get
Rec
eive
dDat
a():i
nt
<<in
terfa
ce>>
Com
mun
icat
ionE
vent
List
ener
<<>>
+dat
aRec
eive
d(ce
:Com
mun
icat
ionE
vent
):voi
d<<
>>+c
onne
ctio
nLos
t(ce:
Com
mun
icat
ionE
vent
):voi
d<<
>>+c
onne
ctio
nRee
stab
lishe
d(ce
:Com
mun
icat
ionE
vent
):voi
d
Envi
ronm
ent
-inst
ance
:Env
ironm
ent=
nul
l
<<cr
eate
>>-E
nviro
nmen
t():E
nviro
nmen
t+ g
etIn
stan
ce():
Env
ironm
ent
+clo
ne():
Obj
ect
+che
ckM
oveR
obot
Forw
ard(
):voi
d+c
heck
Mov
eRob
otB
ackw
ard(
):voi
d+m
oveR
obot
Forw
ard(
):voi
d+m
oveR
obot
Bac
kwar
d():v
oid
+mov
eRob
otLe
ft():v
oid
+mov
eRob
otR
ight
():v
oid
+mar
kFou
nd(m
Col
or:in
t):vo
id+o
bsta
cleF
ound
():v
oid
+che
ckM
oveV
irtua
lRob
otFo
rwar
d():v
oid
+che
ckM
oveV
irtua
lRob
otB
ackw
ard(
):voi
d+m
oveV
irtua
lRob
otFo
rwar
d():v
oid
+mov
eVirt
ualR
obot
Bac
kwar
d():v
oid
+mov
eVirt
ualR
obot
Left(
):voi
d+m
oveV
irtua
lRob
otR
ight
():v
oid
+get
Rob
otH
eadi
ng():
int
+get
Env
ironm
ent()
:Lin
kedL
ist
<<in
terfa
ce>>
Envi
ronm
entP
ositi
on
Envi
ronm
entR
econ
stru
ct
-inst
ance
:Env
ironm
entR
econ
stru
ct=
null
<<cr
eate
>>-E
nviro
nmen
tRec
onst
ruct
():E
nviro
nmen
tRec
onst
ruct
+ get
Inst
ance
():E
nviro
nmen
tRec
onst
ruct
+rec
onst
ruct
():vo
id+u
pdat
e(o:
Obs
erva
ble,
arg:
Obj
ect):
void
IOM
anag
er
-inst
ance
:IOM
anag
er=
null
-com
mun
icat
ionL
iste
ners
:Vec
tor=
nul
l
<<cr
eate
>>-IO
Man
ager
():IO
Man
ager
+ get
Inst
ance
():IO
Man
ager
+clo
ne():
Obj
ect
+sta
rt():v
oid
+sen
dDat
a(da
ta:b
yte)
:voi
d+r
ecei
veD
ata(
):int
+act
ionP
erfo
rmed
(e:A
ctio
nEve
nt):v
oid
+add
Com
mun
icat
ionE
vent
List
ener
(cel
:Com
mun
icat
ionE
vent
List
ener
):voi
d+r
emov
eCom
mun
icat
ionE
vent
List
ener
(cel
:Com
mun
icat
ionE
vent
List
ener
):voi
d-fi
reD
ataR
ecei
vedE
vent
(ce:
Com
mun
icat
ionE
vent
):voi
d-fi
reC
onne
ctio
nEve
nt(c
e:C
omm
unic
atio
nEve
nt):v
oid
Mar
k
<<cr
eate
>>+M
ark(
mC
olor
:int):
Mar
k+s
etC
olor
(mC
olor
:int):
void
+get
Col
or()
:int
Mob
ileR
obot
Com
man
ds
+BE
GIN
:byt
e= 0
+RE
SE
T:by
te=
1+S
TOP:
byte
= 2
+HA
LT:b
yte=
3+F
OR
WA
RD
:byt
e= 4
+BA
CK
WA
RD
:byt
e= 5
+LE
FT:b
yte=
6+R
IGH
T:by
te=
7+R
EA
D_S
EN
SO
R:b
yte=
8+C
HE
CK
_CO
MM
:byt
e= 9
+BA
TTE
RY:
byte
= 10
+ME
MO
RY:
byte
= 11
+SE
T_M
OD
E:by
te=
12+I
NIT
:byt
e= 1
3+K
ILL:
byte
= 14
Mob
ileR
obot
Con
trol
ler
-inst
ance
:Mob
ileR
obot
Con
trolle
r= n
ull
<<cr
eate
>>-M
obile
Rob
otC
ontro
ller()
:Mob
ileR
obot
Con
trolle
r+ g
etIn
stan
ce():
Mob
ileR
obot
Con
trolle
r+c
lone
():O
bjec
t+i
nit()
:voi
d+k
ill():v
oid
+set
Dire
ctM
ode(
):voi
d+s
etQ
ueue
Mod
e():v
oid
+set
PC
Aut
oMod
e():v
oid
+set
RC
XA
utoM
ode(
):voi
d+g
etM
ode(
):byt
e+b
egin
():vo
id+r
eset
():vo
id+a
ddFo
rwar
dCom
man
d():v
oid
+add
Bac
kwar
dCom
man
d():v
oid
+add
Sto
pCom
man
d():v
oid
+add
LeftC
omm
and(
):voi
d+a
ddR
ight
Com
man
d():v
oid
+add
Rea
dSen
sorC
omm
and(
):voi
d+c
lear
Com
man
ds()
:voi
d+s
endC
omm
ands
():vo
id+g
etC
omm
ands
():L
inke
dLis
t+m
oveF
orw
ard(
):voi
d+m
oveB
ackw
ard(
):voi
d+s
top(
):voi
d+m
oveL
eft()
:voi
d+m
oveR
ight
():vo
id+r
eadS
enso
r():v
oid
+get
Bat
tery
Cha
rge(
):voi
d+g
etC
harg
e():i
nt+g
etFr
eeM
emor
y():v
oid
+get
Mem
ory(
):int
+con
nect
ionA
live(
):boo
lean
-sen
dCom
man
d(co
mm
and:
byte
):voi
d+d
ataR
ecei
ved(
ce:C
omm
unic
atio
nEve
nt):v
oid
+con
nect
ionL
ost(c
e:C
omm
unic
atio
nEve
nt):v
oid
+con
nect
ionR
eest
ablis
hed(
ce:C
omm
unic
atio
nEve
nt):v
oid
Mob
ileR
obot
Res
pons
es
+CO
MM
_OK:
int=
0+O
BS
TAC
LE:in
t= 1
+SE
NS
OR
_RE
AD
:int=
2+C
HA
RG
E:in
t= 3
+FR
EE
_ME
M:in
t= 4
+SU
CC
ES
S_F
OR
WA
RD:
byte
= 5
+SU
CC
ES
S_B
AC
KW
AR
D:by
te=
6+S
UC
CE
SS
_LE
FT:b
yte=
7+S
UC
CE
SS
_RIG
HT:
byte
= 8
+SU
CC
ES
S_S
TOP:
byte
= 9
Path
+HO
RIZ
ON
TAL:
int=
0+V
ER
TIC
AL:
int=
1
<<cr
eate
>>+P
ath(
pOrie
ntat
ion:
int,p
Blo
cked
:boo
lean
):Pat
h+s
etO
rient
atio
n(pO
rient
atio
n:in
t):vo
id+g
etO
rient
atio
n():i
nt+s
etB
lock
ed(p
Blo
cked
:boo
lean
):voi
d+i
sBlo
cked
():bo
olea
n
<<ex
cept
ion
>>Po
sitio
nOut
OfB
ound
sExc
eptio
n
<<ex
cept
ion
>>R
CXO
utO
fRan
geEx
cept
ion
Rob
ot
+NO
RTH
:int=
0+S
OU
TH:in
t= 1
+EA
ST:
int=
2+W
ES
T:in
t= 3
<<cr
eate
>>+R
obot
(pH
eadi
ng:in
t,xP:
int,y
P:in
t):R
obot
+get
X():i
nt+s
etX(
xP:in
t):vo
id+g
etY(
):int
+set
Y(yP
:int):
void
+set
Hea
ding
(pH
eadi
ng:in
t):vo
id+g
etH
eadi
ng():
int
Rob
otM
ode
+DIR
EC
T:by
te=
0+Q
UE
UE:
byte
= 1
+PC
_AU
TO:b
yte=
2+R
CX
_AU
TO:b
yte=
3
+get
Mod
e():b
yte
+set
Mod
e(m
ode:
byte
):voi
d
<<in
terfa
ce>>
Obs
erve
r
+upd
ate(
o:O
bser
vabl
e,ar
g:O
bjec
t):vo
id
Obs
erva
ble
+set
Cha
nged
():vo
id+n
otify
Obs
erve
rs():
void
posi
tions
-1.
.*
is m
ade
of
envi
ronm
ent
-ch
ecks
<<re
aliz
e>>
robo
tCon
trolle
r-
uses
envi
ronm
ent
-
chec
ks a
nd u
pdat
es
io-send
s da
ta th
roug
h
<<re
aliz
e>>
<<re
aliz
e>>
robo
t-
hold
s
virtu
alR
obot
-
hold
s
com
man
ds+
*st
ores
uses
uses
fires
wai
ts fo
r
1..*
quer
ies
sets
and
que
ries
<<re
aliz
e>>
notif
ies
chan
ges
to
thro
ws
thro
ws
35
El objetivo de estas clases permitir la ejecución de los diferentes comandos soportados
por el robot, y dar retroalimentación al operador sobre los mismos, esto soportado por
una clase de comunicación con el robot que envía datos y espera la recepción de los
mismos desde éste (IOManager). Otro objetivo es modelar el ambiente en el que se
encuentre el robot para que el operador tenga una visión aproximada de éste y pueda
tomar mejores decisiones en cuanto a los siguientes comandos.
A continuación se describe cada una de las clases que hace parte de la aplicación del PC:
Clase IOManager
Esta clase es la encargada de la entrada/salida entre el PC y el RCX. Ofrece un método
para enviar un dato entero al RCX y para recibir un dato igualmente entero en un
momento específico (cuando el cliente de la clase lo requiera). Esta clase usa el patrón
singleton por accesibilidad y para mantener una sola instancia y así evitar conflictos de
acceso al hardware. Para usar esta clase, además de usar el método estático de acceso a la
instancia getInstance(), la clase cliente debe implementar la interfaz
CommunicationEventListener y registrarse con IOManager como tal, para ser
notificada al llegar un dato del RCX o cuando se pierde o reestablece la comunicación
con éste.
Esta clase tiene una clase embebida o interna (inner class) llamada ReceptionThread, la
cual es un thread que esta en continua espera de datos del RCX, al llegar un dato, se
notifica a los CommunicationEventListeners registrados para que hagan el
procesamiento pertinente y en caso de requerir más datos, llamen el método
receiveData() de IOManager, para recibir un dato, éste método solo funciona cuando la
clase cliente está siendo notificada, de lo contrario, lanza IOException para evitar entrar
en conflicto con el thread de recepción, lo que podría generar resultados inesperados.
Esta clase es independiente de la tarea que el robot y el sistema desempeñen.
36
Interfaz CommunicationEventListener
Esta interfaz define los métodos requeridos para que una clase pueda usar IOManager, y
sea notificada cuando lleguen datos del RCX o ha habido algún cambio en la
comunicación (se ha perdido o reestablecido)
Esta clase es independiente de la tarea.
Clase CommunicationEvent
Representa un evento de comunicación con el RCX, que puede ser la llegada de un dato
desde el RCX, la perdida de comunicación con el mismo o el reestablecimiento de ésta.
Se envía una instancia de esta clase a los CommunicationEventListeners registrados
con IOManager, con los detalles del evento, para notificarlos.
Esta clase es independiente de la tarea.
Clase RobotMode
Almacena el modo de operación actual del robot, y define las respectivas constantes.
Soporta los cuatro modos mencionados anteriormente: directo, cola de comandos,
autónomo RCX y autónomo PC.
Esta clase es independiente de la tarea, mientras que los modos soportados sean
suficientes para el desarrollo de ésta, de no ser así, debe modificarse para agregar nuevos
modos.
37
Clase Command
Representa un comando a almacenar en la cola de comandos cuando el modo de
operación es el de cola de comandos. Un comando tiene tres posibles estados: no
enviado, enviado y no ejecutado y ejecutado.
Esta clase es independiente de la tarea ya que solo almacena el identificador del
comando, que puede ser cualquiera, sin importar a que tarea pertenezca.
Clase MobileRobotController
Esta clase es la encargada del control del robot y el RCX, ofrece métodos para mover el
robot hacia adelante y hacia atrás, girar el robot 90° a la derecha y a la izquierda,
detenerse, leer el sensor del robot, obtener la carga actual de las baterías y la cantidad de
memoria libre en el RCX. También ofrece métodos para poner los comandos anteriores
en la cola de comandos y luego enviarlos (modo cola de comandos), excepto los dos
últimos. Por último ofrece los métodos para iniciar el modo autónomo RCX y autónomo
PC.
Esta clase es dependiente de la tarea, ya que ofrece los métodos específicos para la tarea
que se escogió, en caso de cambiar la tarea, se debe cambiar toda la clase. A partir de esta
clase, todas las que siguen son dependientes de la tarea.
Clase MobileRobotCommands
Almacena las constantes correspondientes a los comandos que puede ejecutar el robot,
para accederlas estáticamente, sin conocer su valor.
38
Clase MobileRobotResponses
Almacena las constantes correspondientes a las respuestas a los comandos que son
enviadas desde el RCX, para accederlas estáticamente, sin conocer su valor.
Clase Environment
Esta clase modela el ambiente que el robot esta reconociendo, como un arreglo
bidimensional en el que puede haber marcas o caminos. Igualmente almacena la
ubicación y orientación del robot y de un robot virtual que se mueve cuando se añade otro
comando a la cola de comandos (en modo cola de comados), para poder determinar la
posición final del robot al ejecutar todos los comandos antes de que estos sean
ejecutados por el robot.
Clase Robot
Representa al robot en el ambiente, almacena sus coordenadas bidimensionales y su
orientación, junto con las constantes pertinentes.
Interfaz EnvironmentPosition
Modela una posición en el ambiente, que puede ser alguna de las dos clases que siguen a
continuación, las cuales la implementan.
39
Clase Mark
Representa una marca en el ambiente, color es almacenado con la lectura del sensor
hecha sobre la marca.
Clase Path
Representa un camino o trayectoria horizontal o vertical entre dos marcas vecinas.
También guarda información de si el camino está despejado o hay algún obstáculo en él.
Clase EnvironmentReconstruct
Esta clase, basada en la información que obtiene del ambiente (clase Environment,
donde esta registrada como Observer, patrón tomado de [17]), decide de manera
autónoma (modo autónomo PC) el siguiente comando a enviar al robot.
40
4.2.5.2. Diagrama de Clases Aplicación del RCX
IOManager
<< create >>+IOManager(robot:Robot):IOManager+sendData(data: ): -sendResponses():
MobileRobot
-atNorth:= true-vertHeading:= true-turn:= false-read:= false-ROTATION:= 187
<< create >>+MobileRobot():MobileRobot+start(): +stateChanged(aSource: ,aOldValue: ,aNewValue: ): +setCommand(command: ): +addCommand(command: ): +begin(): +nextCommand(): +getSensorRead(): +main(args: ):
MobileRobotCommands
+BEGIN:= 0+RESET:= 1+STOP:= 2+HALT:= 3+FORWARD:= 4+BACKWARD:= 5+LEFT:= 6+RIGHT:= 7+READ_SENSOR:= 8+CHECK_COMM:= 9+BATTERY:= 10+MEMORY:= 11+SET_MODE:= 12+INIT:= 13+KILL:= 14
MobileRobotResponses
+COMM_OK:= 0+OBSTACLE:= 1+SENSOR_READ:= 2+CHARGE:= 3+FREE_MEM:= 4+SUCCESS_FORWARD:= 5+SUCCESS_BACKWARD:= 6+SUCCESS_LEFT:= 7+SUCCESS_RIGHT:= 8+SUCCESS_STOP:= 9
Queue
<< create >>+Queue(size: ):Queue+enqueue(element: ): +empty(): +iterate(): +dequeue(): +hasNext(): +isEmpty():
<< interface >>Robot
<< >>+setCommand(command: ): << >>+addCommand(command: ): << >>+begin():
RobotMode
+DIRECT:= 0+QUEUE:= 1+PC_AUTO:= 2+RCX_AUTO:= 3
+getMode(): +setMode(mode: ):
io-
sends data through
responses-
stores responses in
commands-
stores commands in
robot-notifies
<< realize >>
sets and queries
queries
uses uses
41
El objetivo de estas clases es ofrecer todos los comandos que soporta el robot y manejar
la entrada/salida hacia y desde el PC (IOManager), junto el buffer requerido en caso de
perder comunicación con el PC, el cual almacena las respuestas de los diferentes
comandos ejecutados hasta que pueden enviarse al PC al reestablecer la comunicación
con éste.
A continuación se describe cada una de las clases que hace parte de la aplicación del PC:
Clase IOManager
Esta clase es la encargada de la entrada/salida entre el PC y el RCX. Ofrece un método
para enviar un dato entero al PC. Esta clase usa el patrón singleton por accesibilidad y
para mantener una sola instancia y así evitar conflictos de acceso al hardware. Para usar
esta clase, además de usar el método estático de acceso a la instancia getInstance(), la
clase cliente debe implementar la interfaz Robot y registrarse con IOManager, para que al
llegar un dato del PC, que es un nuevo comando, la clase cliente inicie su ejecución
(modo directo) o lo almacene en la cola de comandos (modo cola de comandos).
En caso de perderse la comunicación con el PC, ésta clase puede almacenar las respuestas
de los comandos que estaban ejecutándose en cola, para ser enviadas al reestablecerse la
comunicación.
Esta clase tiene una clase embebida o interna (inner class) llamada ReceptionThread, la
cual es un thread que esta en continua espera de datos del PC, al llegar un dato, se
notifica al Robot registrado para que haga el procesamiento pertinente.
Esta clase es independiente de la tarea que el robot y el sistema desempeñen.
42
Interfaz Robot
Esta interfaz define los métodos requeridos para que una clase pueda usar IOManager, y
sea notificada cuando lleguen datos del PC.
Esta clase es independiente de la tarea.
Clase MobileRobot
Esta clase sabe ejecutar los diferentes comandos soportados por el robot, usando el API
de leJOS para acceder al RCX. También maneja la cola de comandos, cuando se está en
modo cola de comandos.
Clase RobotMode
Almacena el modo de operación actual del robot, y define las respectivas constantes.
Soporta los cuatro modos mencionados anteriormente: directo, cola de comandos,
autónomo RCX y autónomo PC.
Esta clase es independiente de la tarea, mientras que los modos soportados sean
suficientes para el desarrollo de ésta, de no ser así, debe modificarse para agregar nuevos
modos.
Clase MobileRobotCommands
Almacena las constantes correspondientes a los comandos que puede ejecutar el robot,
para accederlas estáticamente, sin conocer su valor.
43
Clase MobileRobotResponses
Almacena las constantes correspondientes a las respuestas a los comandos que son
enviadas desde el RCX, para accederlas estáticamente, sin conocer su valor.
Clase Queue
Implementa una cola de enteros.
4.2.5.3. Diagramas de Secuencia
El siguiente es un diagrama de secuencia de todo el proceso de ejecución de un comando,
en el caso normal de operación. Está dividido en tres partes: la primera va desde la acción
del operador sobre la interfaz grafica, hasta que el comando es enviado al RCX, la
segunda comprende la recepción y ejecución del comando en el RCX y el envió de la
respuesta, la ultima parte es la recepción y procesamiento de la respuesta en el PC y la
retroalimentación al operador. El comando que se escogió fue el de movimiento hacia
adelante, suponiendo que no ocurren errores de comunicación y que no se encuentran
obstáculos.
En la primera parte se realiza una verificación en el ambiente simulado por el PC, antes
de enviar el comando al RCX, para comprobar que el movimiento es posible en el
ambiente real (esto significa que no hay obstáculos y que el robot no se encuentra en el
límite del ambiente). En la segunda parte, luego de recibir el comando, se puede observar
el ciclo (loop) que comprende la ejecución del movimiento hacia delante en trayectoria
recta: se activan los dos motores y en caso de que alguno avance más rápido que el otro,
se desactiva hasta que el otro lo iguale y esto se repite hasta que el robot se detenga en la
siguiente marca, para luego enviar el resultado de éxito al PC. En la tercera parte, se
recibe el comando y se actualiza el ambiente y su visualización.
44
robo
tCon
trolle
r:Mob
ileR
obot
Con
trolle
rG
UI
envi
ronm
ent:E
nviro
nmen
tro
bot:R
obot
posi
tions
[x][y
]:Pat
hio
:IOM
anag
erou
t:Dat
aOut
putS
tream
:m
oveF
orw
ard(
)
:ch
eckM
oveR
obot
Forw
ard(
)
:h:
=get
Hea
ding
()
head
ing
:
: :=
getX
()
x:
: :=
getY
()
y:
:x:
=isB
lock
ed()
:bl
ocke
d
:ch
ecke
d
:se
ndD
ata(
FOR
WA
RD
)
:
:
:w
riteB
yte(
4)
:
45
receive:ReceptionThread in:DataInputStream robot:MobileRobot Thread S1:Sensor A:Motor C:Motorio:IOManager out:DataOutputStream
Loop
S3:Sensor
: readByte()
: data
: setCommand(FORWARD)
:
: yield()
: setPreviousValue(0)
:
:
: forward()
:
: forward()
:
: readValue()
: value
: flt()
:
: readValue()
: value
: forward()
:
: readValue()
: value
: flt()
:
: readValue()
: value
: forward()
:
: yield()
: stateChanged(S1,old,new)
:
: sendData(SUCCESS_FORWARD)
: sendData(5)
:
:
:
: yield()
: readValue()
: value
46
in:D
ataI
nput
Stre
amio
:IOM
anag
erre
ceiv
e:R
ecep
tionT
hrea
d
ce:C
omm
unic
atio
nEve
nt
robo
t:Mob
ileR
obot
Con
trolle
ren
viro
nmen
t:Env
ironm
ent
robo
t:Rob
ot
posi
tions
[x][y
]:Pat
h
GU
I
:re
adB
yte(
)
:5
:ne
w C
omm
unic
atio
nEve
nt(d
ata)
:fir
eDat
aRec
eive
dEve
nt(c
e)
:
:da
taR
ecei
ved(
ce)
:m
oveR
obot
Forw
ard(
)
:x:
=get
Rec
eive
dDat
a()
:5
:x:
=get
Hea
ding
()
:he
adin
g
:se
tX(x
)
:x
:se
tY(x
)
:y
:ne
w P
ath(
head
ing,
fals
e)
:
:
:
:
:up
date
()
:
47
4.2.6. Diseño de la Segunda Versión del Sistema
La segunda versión soporta los mismos cuatro modos: directo, cola de comandos,
autónomo RCX y autónomo PC. En este diseño, la lógica de la tarea quedo
completamente separada de la parte de comunicaciones.
En esta versión se utilizó el patrón Command, descrito por [17], con el fin de poder
agregar posteriormente nuevos comandos, minimizando los cambios a realizar en otras
clases (solo se tendría que modificar el administrador de comandos, o CommandManager
como lo llama [17]). Para la implementación, se utilizó también el patrón Factory de
[17], para instanciar los comandos.
Los identificadores que representan los comandos y sus respuestas ahora son generados
dinámicamente, al instanciar el comando. La clase CommandRegistry es la encargada de
esta función.
Se creó un paquete llamado common, que es común tanto a la aplicación del PC como a la
del RCX, en este paquete se encuentra ahora la clase que maneja el modo de operación
del robot (RobotMode), junto con las clases que definen la raíz de la jerarquía de
comandos (Command y AbstractCommand) y la clase que asigna dinámicamente los
identificadores de comando y de respuesta (CommandRegistry).
48
4.2.6.1. Diagrama de Clases Aplicación del PC
Abs
trac
tPC
Com
man
d
+exe
cute
():v
oid
+res
pons
eRec
eive
d(re
spon
se:in
t):bo
olea
n+r
epla
cesC
urre
ntC
omm
and(
):boo
lean
+dep
ends
OnS
enso
r():b
oole
an
Blo
cked
Path
Exce
ptio
n
+toS
tring
():S
tring
+get
Mes
sage
():S
tring
Com
mun
icat
ionE
vent
<<cr
eate
>>+C
omm
unic
atio
nEve
nt(s
ourc
e:O
bjec
t,bS
tate
:boo
lean
):Com
mun
icat
ionE
vent
<<cr
eate
>>+C
omm
unic
atio
nEve
nt(s
ourc
e:O
bjec
t,iD
ata:
int):
Com
mun
icat
ionE
vent
+con
nect
ionL
ost()
:boo
lean
+con
nect
ionR
esto
red(
):boo
lean
+get
Rec
eive
dDat
a():i
nt
Com
mun
icat
ionE
vent
List
ener
+dat
aRec
eive
d(ce
:Com
mun
icat
ionE
vent
):voi
d+c
onne
ctio
nLos
t(ce:
Com
mun
icat
ionE
vent
):voi
d+c
onne
ctio
nRee
stab
lishe
d(ce
:Com
mun
icat
ionE
vent
):voi
d
Envi
ronm
ent
-inst
ance
:Env
ironm
ent=
nul
l
<<cr
eate
>>-E
nviro
nmen
t():E
nviro
nmen
t+ g
etIn
stan
ce()
:Env
ironm
ent
+clo
ne():
Obj
ect
+che
ckM
oveR
obot
Forw
ard(
):voi
d+c
heck
Mov
eRob
otB
ackw
ard(
):voi
d+m
oveR
obot
Forw
ard(
):voi
d+m
oveR
obot
Bac
kwar
d():v
oid
+tur
nRob
otLe
ft():v
oid
+tur
nRob
otR
ight
():v
oid
+mar
kFou
nd(m
Col
or:in
t):vo
id+o
bsta
cleF
ound
():vo
id+c
heck
Mov
eVirt
ualR
obot
Forw
ard(
):voi
d+c
heck
Mov
eVirt
ualR
obot
Bac
kwar
d():v
oid
+mov
eVirt
ualR
obot
Forw
ard(
):voi
d+m
oveV
irtua
lRob
otB
ackw
ard(
):voi
d+t
urnV
irtua
lRob
otLe
ft():v
oid
+tur
nVirt
ualR
obot
Rig
ht()
:voi
d+g
etR
obot
Hea
ding
():in
t+g
etE
nviro
nmen
t():L
inke
dLis
t
Envi
ronm
entP
ositi
on
Envi
ronm
entR
econ
stru
ct
-inst
ance
:Env
ironm
entR
econ
stru
ct=
null
<<cr
eate
>>-E
nviro
nmen
tRec
onst
ruct
():E
nviro
nmen
tRec
onst
ruct
+ get
Inst
ance
():E
nviro
nmen
tRec
onst
ruct
+rec
onst
ruct
():vo
id+u
pdat
e(o:
Obs
erva
ble,
arg:
Obj
ect):
void
IOM
anag
er
-inst
ance
:IOM
anag
er=
null
-com
mun
icat
ionL
iste
ners
:Vec
tor=
nul
l
<<cr
eate
>>-IO
Man
ager
():IO
Man
ager
+ get
Inst
ance
():IO
Man
ager
+clo
ne():
Obj
ect
+sta
rt():v
oid
+sen
dDat
a(da
ta:in
t):vo
id+r
ecei
veD
ata(
):int
+act
ionP
erfo
rmed
(e:A
ctio
nEve
nt):v
oid
+add
Com
mun
icat
ionE
vent
List
ener
(cel
:Com
mun
icat
ionE
vent
List
ener
):voi
d+r
emov
eCom
mun
icat
ionE
vent
List
ener
(cel
:Com
mun
icat
ionE
vent
List
ener
):voi
d-fi
reD
ataR
ecei
vedE
vent
(ce:
Com
mun
icat
ionE
vent
):voi
d-fi
reC
onne
ctio
nEve
nt(c
e:C
omm
unic
atio
nEve
nt):v
oid
Mar
k
<<cr
eate
>>+M
ark(
mC
olor
:int):
Mar
k+s
etC
olor
(mC
olor
:int):
void
+get
Col
or():
int
Path
+HO
RIZ
ON
TAL:
int=
0+V
ER
TIC
AL:
int=
1
<<cr
eate
>>+P
ath(
pOrie
ntat
ion:
int,p
Blo
cked
:boo
lean
):Pat
h+s
etO
rient
atio
n(pO
rient
atio
n:in
t):vo
id+g
etO
rient
atio
n():i
nt+s
etB
lock
ed(p
Blo
cked
:boo
lean
):voi
d+i
sBlo
cked
():bo
olea
n
PCB
ackw
ardC
omm
and
<<cr
eate
>>+P
CB
ackw
ardC
omm
and(
):PC
Bac
kwar
dCom
man
d+r
espo
nseR
ecei
ved(
resp
onse
:int):
bool
ean
PCB
atte
ryC
omm
and
<<cr
eate
>>+P
CB
atte
ryC
omm
and(
):PC
Bat
tery
Com
man
d+r
espo
nseR
ecei
ved(
resp
onse
:int):
bool
ean
PCB
egin
Com
man
d
<<cr
eate
>>+P
CB
egin
Com
man
d():P
CB
egin
Com
man
d
PCC
omm
andF
acto
ry
-inst
ance
:PC
Com
man
dFac
tory
= nu
ll-fo
rwar
dCom
man
d:C
omm
and=
nul
l-b
ackw
ardC
omm
and:
Com
man
d= n
ull
-leftC
omm
and:
Com
man
d= n
ull
-righ
tCom
man
d:C
omm
and=
nul
l-re
adS
enso
rCom
man
d:C
omm
and=
nul
l-s
topC
omm
and:
Com
man
d= n
ull
-hal
tCom
man
d:C
omm
and=
nul
l-b
atte
ryC
omm
and:
Com
man
d= n
ull
-mem
oryC
omm
and:
Com
man
d= n
ull
-che
ckC
omm
Com
man
d:C
omm
and=
nul
l-s
etM
odeC
omm
and:
Com
man
d= n
ull
-beg
inC
omm
and:
Com
man
d= n
ull
<<cr
eate
>>-P
CC
omm
andF
acto
ry()
:PC
Com
man
dFac
tory
+ get
Inst
ance
():P
CC
omm
andF
acto
ry+c
lone
():O
bjec
t+g
etFo
rwar
dCom
man
d():C
omm
and
+get
Bac
kwar
dCom
man
d():C
omm
and
+get
LeftC
omm
and(
):Com
man
d+g
etR
ight
Com
man
d():C
omm
and
+get
Rea
dSen
sorC
omm
and(
):Com
man
d+g
etS
topC
omm
and(
):Com
man
d+g
etH
altC
omm
and(
):Com
man
d+g
etB
atte
ryC
omm
and(
):Com
man
d+g
etM
emor
yCom
man
d():C
omm
and
+get
Che
ckC
omm
Com
man
d():C
omm
and
+get
Set
Mod
eCom
man
d():C
omm
and
+get
Beg
inC
omm
and(
):Com
man
d
PCFo
rwar
dCom
man
d
<<cr
eate
>>+P
CFo
rwar
dCom
man
d():P
CFo
rwar
dCom
man
d+r
espo
nseR
ecei
ved(
resp
onse
:int):
bool
ean
PCH
altC
omm
and
<<cr
eate
>>+P
CH
altC
omm
and(
):PC
Hal
tCom
man
d
PCLe
ftCom
man
d
<<cr
eate
>>+P
CLe
ftCom
man
d():P
CLe
ftCom
man
d+r
espo
nseR
ecei
ved(
resp
onse
:int):
bool
ean
PCM
emor
yCom
man
d
<<cr
eate
>>+P
CM
emor
yCom
man
d():P
CM
emor
yCom
man
d+r
espo
nseR
ecei
ved(
resp
onse
:int):
bool
ean
PCR
eadS
enso
rCom
man
d
<<cr
eate
>>+P
CR
eadS
enso
rCom
man
d():P
CR
eadS
enso
rCom
man
d+r
espo
nseR
ecei
ved(
resp
onse
:int):
bool
ean
PCR
ight
Com
man
d
<<cr
eate
>>+P
CR
ight
Com
man
d():P
CR
ight
Com
man
d+r
espo
nseR
ecei
ved(
resp
onse
:int):
bool
ean
PCSe
tMod
eCom
man
d
<<cr
eate
>>+P
CS
etM
odeC
omm
and(
):PC
Set
Mod
eCom
man
d+e
xecu
te():
void
PCSt
opC
omm
and
<<cr
eate
>>+P
CS
topC
omm
and(
):PC
Sto
pCom
man
d+r
espo
nseR
ecei
ved(
resp
onse
:int):
bool
ean
Posi
tionO
utO
fBou
ndsE
xcep
tion
+toS
tring
():S
tring
+get
Mes
sage
():S
tring
Que
uedC
omm
and
<<cr
eate
>>+Q
ueue
dCom
man
d(co
mm
and:
Com
man
d):Q
ueue
dCom
man
d+g
etC
omm
and(
):Com
man
d+s
etS
ent()
:voi
d+w
asS
ent()
:boo
lean
+set
Exe
cute
d():v
oid
+was
Exe
cute
d():b
oole
an
RC
XOut
OfR
ange
Exce
ptio
n
+toS
tring
():S
tring
+get
Mes
sage
():S
tring
Rob
ot
+NO
RTH
:int=
0+S
OU
TH:in
t= 1
+EA
ST:
int=
2+W
ES
T:in
t= 3
<<cr
eate
>>+R
obot
(pH
eadi
ng:in
t,xP:
int,y
P:in
t):R
obot
+get
X():i
nt+s
etX(
xP:in
t):vo
id+g
etY(
):int
+set
Y(yP
:int):
void
+set
Hea
ding
(pH
eadi
ng:in
t):vo
id+g
etH
eadi
ng()
:int
Rob
otC
ontr
olle
r
-inst
ance
:Rob
otC
ontro
ller=
nul
l
<<cr
eate
>>-R
obot
Con
trolle
r():R
obot
Con
trolle
r+ g
etIn
stan
ce()
:Rob
otC
ontro
ller
+clo
ne():
Obj
ect
+ini
t():v
oid
+kill
():vo
id+s
etD
irect
Mod
e():v
oid
+set
Que
ueM
ode(
):voi
d+s
etP
CA
utoM
ode(
):voi
d+s
etR
CX
Aut
oMod
e():v
oid
+get
Mod
e():i
nt+b
egin
():v
oid
+res
et()
:voi
d+c
lear
Com
man
ds():
void
+sen
dCom
man
ds():
void
+get
Com
man
ds()
:Lin
kedL
ist
+mov
eFor
war
d():v
oid
+mov
eBac
kwar
d():v
oid
+sto
p():v
oid
+tur
nLef
t():v
oid
+tur
nRig
ht()
:voi
d+r
eadS
enso
r():v
oid
+get
Bat
tery
Cha
rge(
):voi
d+s
etC
harg
e(ch
arge
:int):
void
+get
Cha
rge(
):int
+get
Free
Mem
ory(
):voi
d+s
etM
emor
y(m
emor
y:in
t):vo
id+g
etM
emor
y():i
nt+c
onne
ctio
nAliv
e():b
oole
an+d
ataR
ecei
ved(
ce:C
omm
unic
atio
nEve
nt):v
oid
+con
nect
ionL
ost(c
e:C
omm
unic
atio
nEve
nt):v
oid
+con
nect
ionR
eest
ablis
hed(
ce:C
omm
unic
atio
nEve
nt):v
oid
Abs
trac
tCom
man
d(fr
om c
omm
on)
<<cr
eate
>>+A
bstra
ctC
omm
and(
):Abs
tract
Com
man
d+g
etId
():in
t
<<in
terfa
ce>>
Com
man
d(fr
om c
omm
on)
+exe
cute
():v
oid
+get
Id():
int
+res
pons
eRec
eive
d(re
spon
se:in
t):bo
olea
n+r
epla
cesC
urre
ntC
omm
and(
):boo
lean
Com
man
dReg
istr
y(fr
om c
omm
on)
-inst
ance
:Com
man
dReg
istry
= nu
ll
<<cr
eate
>>-C
omm
andR
egis
try():
Com
man
dReg
istry
+ get
Inst
ance
():C
omm
andR
egis
try+g
etC
omm
andI
d():i
nt+g
etR
espo
nseI
d():i
nt
Rob
otM
ode
(from
com
mon
)
+DIR
EC
T:in
t= 1
+QU
EU
E:in
t= 2
+PC
_AU
TO:in
t= 3
+RC
X_A
UTO
:int=
4-m
ode:
int=
DIR
EC
T
+get
Mod
e():i
nt+s
etM
ode(
mod
e:in
t):vo
id
crea
tes
an in
stan
ce o
f all
com
man
ds
envi
ronm
ent
-ch
ecks
<<re
aliz
e>>
<<re
aliz
e>>
robo
t-
hold
s
virtu
alR
obot
-
hold
s
robo
tCon
trolle
r-
uses
io-star
ts re
ceiv
ing
thre
ad o
f
envi
ronm
ent
-
com
man
dFac
tory
-
requ
ests
com
man
ds fr
om
<<re
aliz
e>>
com
man
d-
hold
s
avai
labl
eCom
man
ds-1.
.*st
ores
<<re
aliz
e>>
fires
wai
ts fo
r
thro
ws
quer
ies
quer
ies
sets
thro
ws
posi
tions
-
1..*
is m
ade
of
uses
usesno
tifie
s
com
man
ds-
*st
ores
49
Las siguientes clases e interfaces son iguales a las correspondientes en la primera versión
del sistema, y su detalle puede verse en la sección 4.2.5.1.:
• Clase IOManager
• Interfaz CommunicationEventListener
• Clase CommunicationEvent
• Clase RobotMode
• Clase Environment
• Clase Robot
• Interfaz EnvironmentPosition
• Clase Mark
• Clase Path
• Clase EnvironmentReconstruct
Clase QueuedCommand
Esta clase es igual a la clase Command, de la primera versión del sistema, la cual
representa un comando a almacenar en la cola de comandos cuando el modo de operación
es el de cola de comandos.
Clase RobotController
Esta clase es igual a la clase MobileRobotController de la primera versión del sistema,
con la diferencia que ahora usa el patrón Command de [17] para el manejo de los
distintos comandos.
Esta clase es dependiente de la tarea, ya que ofrece los métodos específicos para la tarea
que se escogió, en caso de cambiar la tarea, se debe cambiar toda la clase. La ventaja de
esta clase con respecto a la de la primera versión es que es más fácil incorporarle
50
comandos nuevos. A partir de esta clase, todas las que siguen son dependientes de la
tarea.
Clase PCCommandFactory
Esta clase se encarga de crear y almacenar la instancia de cada uno de los diferentes
comandos disponibles en el sistema.
Clase CommandRegistry
Esta clase se encarga de generar en ejecución los identificadores de comando y respuesta,
para cada uno de los comandos disponibles en el sistema.
Interfaz Command
Esta interfaz representa un comando tanto del RCX como del PC, define el método a
llamar para ejecutar el comando (execute()), un método que devuelve el identificador
de comando asociado (getId()), un método para notificar al comando en el PC que llegó
respuesta por parte del RCX (responseReceived(int)) y un método que dice si el
comando reemplaza al que está actualmente en ejecución, o si se puede ejecutar al mismo
tiempo (replacesCurrentCommand()).
Clase Abstracta AbstractCommand
Implementa el método getId() de la interfaz Command y el constructor que usarán todos
los comandos tanto en el RCX como en el PC, excepto el comando de movimiento hacia
adelante.
51
Clase Abstracta AbstractPCCommand
Extiende la clase abstracta AbstractCommand, e implementa los métodos restantes de la
interfaz Command, para su uso en el PC. Los comandos que extienden esta clase abstracta
y que son los diferentes comandos que ofrece el sistema son:
• PCBackwardCommand
• PCBatteryCommand
• PCBeginCommand
• PCForwardCommand1
• PCHaltCommand
• PCLeftCommand
• PCMemoryCommand
• PCReadSensorCommand
• PCRightCommand
• PCSetModeCommand
• PCStopCommand
1 La clase PCForwardCommand hace override del constructor implementado en AbstractCommand, debido a que utiliza dos identificadores de respuesta.
52
4.2.6.2. Diagrama de Clases Aplicación del RCX
Abs
trac
tRC
XCom
man
d
<<cr
eate
>>+A
bstra
ctR
CX
Com
man
d():A
bstra
ctR
CX
Com
man
d+e
xecu
te()
:voi
d+r
epla
cesC
urre
ntC
omm
and(
):boo
lean
+res
pons
eRec
eive
d(re
spon
se:in
t):bo
olea
n
IOM
anag
er
-inst
ance
:IOM
anag
er=
null
<<cr
eate
>>-IO
Man
ager
():IO
Man
ager
+ get
Inst
ance
():IO
Man
ager
+set
Rob
otFo
rNot
ifica
tion(
robo
t:Rob
ot):v
oid
+sen
dDat
a(da
ta:in
t):vo
id+r
ecei
veD
ata(
):int
-sen
dRes
pons
es()
:voi
d
Mob
ileR
obot
-inst
ance
:Mob
ileR
obot
= nu
ll-c
omm
and:
int=
-1-a
tNor
th:b
oole
an=
true
-ver
tHea
ding
:boo
lean
= tru
e-tu
rn:b
oole
an=
fals
e-re
ad:b
oole
an=
fals
e
<<cr
eate
>>-M
obile
Rob
ot():
Mob
ileR
obot
+get
Inst
ance
():M
obile
Rob
ot+s
tart(
):voi
d+s
tate
Cha
nged
(aS
ourc
e:S
enso
r,aO
ldV
alue
:int,a
New
Val
ue:in
t):vo
id+s
etC
omm
and(
com
man
d:in
t):vo
id+a
ddC
omm
and(
com
man
d:in
t):vo
id+b
egin
():v
oid
+nex
tCom
man
d():v
oid
+mai
n(ar
gs:S
tring
[]):v
oid
RC
XBac
kwar
dCom
man
d
<<cr
eate
>>+R
CX
Bac
kwar
dCom
man
d():R
CX
Bac
kwar
dCom
man
d+e
xecu
te()
:voi
d+t
erm
inat
eExe
cutio
n():v
oid
+sen
dRes
pons
e():v
oid
+rep
lace
sCur
rent
Com
man
d():b
oole
an
RC
XBat
tery
Com
man
d
<<cr
eate
>>+R
CX
Bat
tery
Com
man
d():R
CX
Bat
tery
Com
man
d+e
xecu
te()
:voi
d
RC
XBeg
inC
omm
and
<<cr
eate
>>+R
CX
Beg
inC
omm
and(
):RC
XB
egin
Com
man
d+e
xecu
te():
void
RC
XCom
man
dFac
tory
-forw
ardC
omm
and:
Com
man
d= n
ew R
CX
Forw
ardC
omm
and
( )-b
ackw
ardC
omm
and:
Com
man
d= n
ew R
CX
Bac
kwar
dCom
man
d ( )
-leftC
omm
and:
Com
man
d= n
ew R
CX
LeftC
omm
and
( )-ri
ghtC
omm
and:
Com
man
d= n
ew R
CX
Rig
htC
omm
and
( )-re
adS
enso
rCom
man
d:C
omm
and=
new
RC
XR
eadS
enso
rCom
man
d ( )
-sto
pCom
man
d:C
omm
and=
new
RC
XS
topC
omm
and
( )-h
altC
omm
and:
Com
man
d= n
ew R
CX
Hal
tCom
man
d ( )
-bat
tery
Com
man
d:C
omm
and=
new
RC
XB
atte
ryC
omm
and
( )-m
emor
yCom
man
d:C
omm
and=
new
RC
XM
emor
yCom
man
d ( )
-che
ckC
omm
Com
man
d:C
omm
and=
new
RC
XC
heck
Com
mC
omm
and
( )-s
etM
odeC
omm
and:
Com
man
d= n
ew R
CX
Set
Mod
eCom
man
d ( )
-beg
inC
omm
and:
Com
man
d= n
ew R
CX
Beg
inC
omm
and
( )
<<cr
eate
>>-R
CX
Com
man
dFac
tory
():R
CX
Com
man
dFac
tory
+get
Forw
ardC
omm
and(
):Com
man
d+g
etB
ackw
ardC
omm
and(
):Com
man
d+g
etLe
ftCom
man
d():C
omm
and
+get
Rig
htC
omm
and(
):Com
man
d+g
etR
eadS
enso
rCom
man
d():C
omm
and
+get
Sto
pCom
man
d():C
omm
and
+get
Hal
tCom
man
d():C
omm
and
+get
Bat
tery
Com
man
d():C
omm
and
+get
Mem
oryC
omm
and(
):Com
man
d+g
etC
heck
Com
mC
omm
and(
):Com
man
d+g
etS
etM
odeC
omm
and(
):Com
man
d+g
etB
egin
Com
man
d():C
omm
and
RC
XFor
war
dCom
man
d
<<cr
eate
>>+R
CX
Forw
ardC
omm
and(
):RC
XFo
rwar
dCom
man
d+e
xecu
te()
:voi
d+t
erm
inat
eExe
cutio
n():v
oid
+sen
dRes
pons
e(su
cces
s:bo
olea
n):v
oid
+rep
lace
sCur
rent
Com
man
d():b
oole
an
RC
XHal
tCom
man
d
<<cr
eate
>>+R
CX
Hal
tCom
man
d():R
CX
Hal
tCom
man
d+e
xecu
te()
:voi
d+r
epla
cesC
urre
ntC
omm
and(
):boo
lean
RC
XLef
tCom
man
d
-RO
TATI
ON
:int=
180
<<cr
eate
>>+R
CX
LeftC
omm
and(
):RC
XLe
ftCom
man
d+e
xecu
te():
void
+rep
lace
sCur
rent
Com
man
d():b
oole
an
RC
XMem
oryC
omm
and
<<cr
eate
>>+R
CX
Mem
oryC
omm
and(
):RC
XM
emor
yCom
man
d+e
xecu
te()
:voi
d+r
epla
cesC
urre
ntC
omm
and(
):boo
lean
RC
XRea
dSen
sorC
omm
and
<<cr
eate
>>+R
CX
Rea
dSen
sorC
omm
and(
):RC
XR
eadS
enso
rCom
man
d+e
xecu
te():
void
+rep
lace
sCur
rent
Com
man
d():b
oole
an
RC
XRig
htC
omm
and
-RO
TATI
ON
:int=
180
<<cr
eate
>>+R
CX
Rig
htC
omm
and(
):RC
XR
ight
Com
man
d+e
xecu
te():
void
+rep
lace
sCur
rent
Com
man
d():b
oole
an
RC
XSet
Mod
eCom
man
d
<<cr
eate
>>+R
CX
Set
Mod
eCom
man
d():R
CX
Set
Mod
eCom
man
d+e
xecu
te()
:voi
d+r
epla
cesC
urre
ntC
omm
and(
):boo
lean
RC
XSto
pCom
man
d
<<cr
eate
>>+R
CX
Sto
pCom
man
d():R
CX
Sto
pCom
man
d+e
xecu
te()
:voi
d+r
epla
cesC
urre
ntC
omm
and(
):boo
lean
<<in
terfa
ce>>
Rob
ot
<<>>
+set
Com
man
d(co
mm
and:
int):
void
<<>>
+add
Com
man
d(co
mm
and:
int):
void
<<>>
+beg
in()
:voi
d
Rob
otM
ode
(from
com
mon
)
+DIR
EC
T:in
t= 1
+QU
EU
E:in
t= 2
+PC
_AU
TO:in
t= 3
+RC
X_A
UTO
:int=
4-m
ode:
int=
DIR
EC
T
+get
Mod
e():i
nt+s
etM
ode(
mod
e:in
t):vo
id
Abs
trac
tCom
man
d(fr
om c
omm
on)
<<cr
eate
>>+A
bstra
ctC
omm
and(
):Abs
tract
Com
man
d+g
etId
():in
t
<<in
terfa
ce>>
Com
man
d(fr
om c
omm
on)
<<>>
+exe
cute
():v
oid
<<>>
+get
Id()
:int
<<>>
+res
pons
eRec
eive
d(re
spon
se:in
t):bo
olea
n<<
>>+r
epla
cesC
urre
ntC
omm
and(
):boo
lean
Com
man
dReg
istr
y(fr
om c
omm
on)
-inst
ance
:Com
man
dReg
istry
= nu
ll
<<cr
eate
>>-C
omm
andR
egis
try()
:Com
man
dReg
istry
+ get
Inst
ance
():C
omm
andR
egis
try+g
etC
omm
andI
d():i
nt+g
etR
espo
nseI
d():i
nt
crea
tes
an in
stan
ce o
f all
com
man
ds
Que
ue(fr
om rc
x::u
til)
<<cr
eate
>>+Q
ueue
(siz
e:in
t):Q
ueue
+enq
ueue
(ele
men
t:int
):voi
d+e
mpt
y():v
oid
+ite
rate
():vo
id+d
eque
ue():
int
+has
Nex
t():b
oole
an+i
sEm
pty(
):boo
lean
robo
t-
<<re
aliz
e>>
avai
labl
eCom
man
ds-
1..*
<<re
aliz
e>>
uses
uses
sets
quer
ies
quer
ies
requ
ests
com
man
ds fr
om
all c
omm
and
send
s da
ta th
roug
h
stor
es re
spon
ses
id's
in
stor
es c
omm
ands
id's
in
53
Las siguientes clases e interfaces son iguales a las correspondientes en la primera versión
del sistema, y su detalle puede verse en la sección 4.2.5.2.:
• Clase IOManager
• Interfaz Robot
• Clase RobotMode
Clase MobileRobot
Esta clase es igual a la de la primera versión del sistema, con la diferencia que ahora usa
el patrón Command de [17] para el manejo de los distintos comandos.
Esta clase es dependiente de la tarea, ya que ofrece incluye la lógica específica para la
tarea que se escogió, en caso de cambiar la tarea, se debe cambiar toda la clase. La
ventaja de esta clase con respecto a la de la primera versión es que es más fácil
incorporarle comandos nuevos para la misma tarea.
Clase RCXCommandFactory
Esta clase se encarga de crear y almacenar la instancia de cada uno de los diferentes
comandos disponibles en el sistema.
Clase CommandRegistry
Esta clase se encarga de generar en ejecución los identificadores de comando y respuesta,
para cada uno de los comandos disponibles en el sistema.
54
Interfaz Command
Esta interfaz representa un comando tanto del RCX como del PC, define el método a
llamar para ejecutar el comando (execute()), un método que devuelve el identificador
de comando asociado (getId()), un método para notificar al comando en el PC que llegó
respuesta por parte del RCX (responseReceived(int), que no se usa en el RCX) y un
método que dice si el comando reemplaza al que está actualmente en ejecución, o si se
puede ejecutar al mismo tiempo (replacesCurrentCommand()).
Clase Abstracta AbstractCommand
Implementa el método getId() de la interfaz Command y el constructor que usarán todos
los comandos tanto en el RCX como en el PC, excepto el comando de movimiento hacia
adelante.
Clase Abstracta AbstractRCXCommand
Extiende la clase abstracta AbstractCommand, e implementa los métodos restantes de la
interfaz Command, para su uso en el RCX. Los comandos que extienden esta clase
abstracta y que son los diferentes comandos que ofrece el sistema son:
• RCXBackwardCommand
• RCXBatteryCommand
• RCXBeginCommand
• RCXForwardCommand
• RCXHaltCommand
• RCXLeftCommand
• RCXMemoryCommand
• RCXReadSensorCommand
55
• RCXRightCommand
• RCXSetModeCommand
• RCXStopCommand
NOTA: La clase RCXForwardCommand hace override del constructor implementado en
AbstractCommand, debido a que utiliza dos identificadores de respuesta.
Clase Queue
Implementa una cola de enteros.
4.2.6.3. Diagramas de Secuencia
El siguiente es un diagrama de secuencia de todo el proceso de ejecución de un comando,
en el caso normal de operación. Está dividido en tres partes: la primera va desde la acción
del operador sobre la interfaz grafica, hasta que el comando es enviado al RCX, la
segunda comprende la recepción y ejecución del comando en el RCX y el envió de la
respuesta, la ultima parte es la recepción y procesamiento de la respuesta en el PC y la
retroalimentación al operador. Se escogió el mismo comando de movimiento hacia
adelante, para que el lector pueda contrastar mejor los dos diseños.
La diferencia de estos diagramas, con respecto a los del primer diseño, es la utilización de
los patrones Command y Factory, de [17], la verificación previa al envío al RCX y el
ciclo de ejecución del movimiento hacia delante, siguen siendo iguales.
La ventaja del patrón Command, como puede observarse, es que una sola clase está
encargada exclusivamente de la recepción del comando, ejecución del movimiento hacia
delante y envío de respuesta en el RCX (RCXForwardCommand), y del envío del comando,
recepción y procesamiento de la respuesta en el PC (PCForwardCommand).
56
GU
Iro
botC
ontro
ller:R
obot
Con
trolle
ren
viro
nmen
t:Env
ironm
ent
robo
t:Rob
otpo
sitio
ns[x
][y]:P
ath
com
man
dFac
tory
:PC
Com
man
dFac
tory
forw
ardC
omm
and:
PCFo
rwar
dCom
man
d
com
man
dReg
istry
:Com
man
dReg
istry
:Rob
otM
ode
io:IO
Man
ager
out:D
ataO
utpu
tStre
am
:m
oveF
orw
ard(
)
:ch
eckM
oveR
obot
Forw
ard(
)
:h:
=get
Hea
ding
()
:he
adin
g
:x:
=get
X()
:x
:y:
=get
Y()
:y
: :=
isBl
ocke
d()
:bl
ocke
d
:
: :=
getF
orw
ardC
omm
and(
)
:fo
rwar
dCom
man
d
:ne
w
:
:ex
ecut
e()
: :=
getR
espo
nseI
d()
:re
spon
seId
: :=
getM
ode(
)
:m
ode
:
:
:se
ndD
ata(
id)
:
:w
riteI
nt(id
)
:
57
receive:ReceptionThread in:DataInputStream :RobotMode robot:MobileRobot Thread forwardCommand:RCXForwardCommand A:Motor C:Motor S1:Sensor S3:Sensorio:IOManager out:DataOutputStream
Loop
: readInt()
: data
: :=getMode()
: mode
: setCommand(data)
:
: yield()
:
: execute()
: forward()
:
: forward()
: setPreviousValue(0)
:
:
: readValue()
: value
: flt()
:
: readValue()
: value
: forward()
:
: readValue()
: value
: flt()
:
: readValue()
: value
: forward()
:
: yield()
: stateChanged(S1,old,new)
: terminateExecution()
:
:
: readValue()
execute() returns :
: value
: sendResponse(true)
: sendData(response)
: writeInt(response)
:
:
: yield()
:
: yield()
58
rece
ive:
Rec
eptio
nThr
ead
in:D
ataI
nput
Stre
amio
:IOM
anag
er
ce:C
omm
unic
atio
nEve
nt
robo
tCon
trolle
r:Rob
otC
ontro
ller
forw
ardC
omm
and:
PC
Forw
ardC
omm
and
envi
ronm
ent:E
nviro
nmen
tro
bot:R
obot
posi
tions
[x][y
]:Pat
h
GU
I
:re
adIn
t()
:da
ta
:fir
eDat
aRec
eive
dEve
nt(c
e)
:ne
w C
omm
unic
atio
nEve
nt(d
ata)
:
:da
taR
ecei
ved(
ce)
: :=
getR
ecei
vedD
ata(
)
:da
ta
: :=
resp
onse
Rec
eive
d(da
ta)
:m
oveR
obot
Forw
ard(
)
: :=
getH
eadi
ng()
:he
adin
g
:se
tX(x
)
:
:se
tY(x
)
:
:ne
w P
ath(
head
ing,
fals
e) :
:
:
:
:
:up
date
()
:
59
4.3. AMBIENTE
El ambiente en el que operará el robot será construido y será desconocido para el
operador, lo único que sabe el operador es que en el ambiente hay marcas equidistantes.
La función del operador será reconstruir el ambiente, cuidando la integridad del robot con
la ayuda de la lógica de la estación remota (control colaborativo). Dentro del ambiente
habrá marcas sobresalientes en el suelo rodeadas de un color en particular, que le
permitirán al robot saber donde termina los diferentes tramos establecidos que puede
recorrer y el color determinará que tan seguro es esa parte del ambiente, al llegar a estas
marcas, el robot, basado en las órdenes recibidas y el nivel de seguridad, deberá rotar,
enviar la lectura actual de los sensores, detenerse y esperar nuevas órdenes, etc. En el
ambiente podrá haber obstáculos que el operador no conoce y el robot deberá detectarlos
y reportar al operador de su hallazgo.
Debido a las limitaciones del RCX en cuanto al número de sensores que soporta (3), se
decidió utilizar un sensor de contacto para las marcas, que está conectado al mismo
puerto que el sensor de obstáculos, que también es de contacto en el momento de que
cualquiera de estos sensores se active, se activará y utilizará el sensor de luz para saber si
lo que activo el puerto fue un obstáculo (esto se sabrá porque alrededor del obstáculo y en
general donde no hay marcas el suelo será blanco) o una marca (en este caso, se enviará
la lectura del sensor de luz y ésta determinará de qué color es el suelo y su nivel de
seguridad
60
4.4. LIMITANTES
4.4.1. Memoria del RCX
La memoria disponible para programas de usuario usando leJOS es de 12 Kb, en estos,
además de almacenar el código ejecutable (bytecode) del programa, se almacenan todas
las variables que son creadas en ejecución y todas las estructuras necesarias para la
ejecución del programa, como por ejemplo, la pila de ejecución (stack). Además, leJOS
no tiene recolección de basura, por lo que la memoria utilizada en variables u objetos que
se creen en ejecución, no puede ser recuperada.
Lo anterior limita el tamaño de los programas, las variables y objetos que se declaren en
él (todas las variables usadas en el sistema son globales a la clase donde se usan), el
número de threads concurrentes que se pueden tener y el tamaño de las estructuras de
datos como arreglos.
Esto fue una gran limitante para el desarrollo de la aplicación ya que en varias ocasiones
el RCX se quedaba sin memoria y era necesario revisar el código fuente al mismo tiempo
que se utilizaba el LCD del RCX en ejecución, para ver la cantidad de memoria libre en
él en cada momento, y así poder detectar posibles fallas en la programación que
aumentaran la memoria en uso. Esto sucedió más que todo en la versión 2 del sistema,
debido al aumento considerable en el número de clases. A pesar de esto, se logró reducir
el consumo de memoria en ejecución con la ayuda del Asesor y la aplicación funcionó
satisfactoriamente.
4.4.2. Medio de Comunicación PC – RCX
La limitante del medio infrarrojo es que debe haber línea de visión entre el emisor y el
receptor para que haya comunicación, o al menos debe haber un objeto en el que los
61
rayos puedan rebotar hacia el receptor. Esto mantuvo la distancia entre el RCX y el PC a
un máximo de 5 metros, con paredes alrededor. Una posible solución para extender el
rango de recepción del RCX podría ser utilizar una extensión del cable USB del sensor
infrarrojo del PC, considerando que el puerto USB al que se conecta debe tener
alimentación propia y la extensión debe contar con un núcleo de ferrita para minimizar
interferencias.
62
5. PRUEBAS DEL SISTEMA
Para las pruebas del sistema se construyó un ambiente de 5 x 5 marcas, con cartulina
blanca como base. Las marcas se hicieron con palos de balso cortados a una altura de
7mm., aproximadamente. Para los colores de las marcas se utilizó papel iris y se cortó de
tal manera que cubriera la marca de madera.
Se encontró que el sensor de luz no diferenciaba entre los colores verde, amarillo y rojo,
por lo que se decidió utilizar únicamente marcas de color verde y negro, las cuales si
puede distinguir el sensor de luz de Lego.
Igualmente se encontró que la iluminación del ambiente alteraba las lecturas del sensor
de luz, a pesar de que este se encuentra casi en el centro, debajo del robot y al estar sobre
una marca, ésta ultima queda a escasos milímetros del sensor. Por lo tanto es necesario
calibrar el sensor previamente a usar el robot en un ambiente con condiciones de
iluminación diferentes.
63
Figura 15. Ambiente de Prueba Visto Desde Arriba
Para ambas versiones del sistema, las pruebas consistieron de cuatro partes, que
corresponden a los cuatro modos soportados por el sistema. En cada una de estas partes
se buscó, entre otras cosas, poner a prueba la respuesta del sistema al problema de la
pérdida de comunicación. El comportamiento que se esperaba era que si se perdía la
comunicación, la aplicación notificara al operador de este hecho y no le permitiera
ingresar más comandos hasta que se reestableciera la comunicación, si el robot debía
enviar algo al PC, se debía dar cuenta que no había comunicación y almacenaría lo que
iba a enviar en el buffer hasta reestablecer la comunicación, al suceder esto, el robot
enviaría todo lo que estuviera en el buffer de manera automática y el PC lo procesaría
como era debido.
Con estas pruebas también se quería poner a prueba la autonomía de la aplicación del
RCX y del PC, en los correspondientes modos (Autónomo RCX y Autónomo PC). Si se
daba la orden de iniciar el modo Autónomo RCX, la aplicación en el RCX debía decidir
cual debía ser el siguiente comando a ejecutar para recorrer el ambiente en una
trayectoria de norte a sur y de oeste a este, enviando al PC un mensaje que le notificaba
64
que había ejecutado con éxito un determinado comando, la aplicación del PC debía
retroalimentar al operador acerca de lo que había hecho el robot. En el caso de dar la
orden de iniciar el modo Autónomo PC, la aplicación del PC era quien debía decidir el
siguiente comando a ejecutar, basado en su conocimiento del ambiente (lo puede hacer
más fácilmente ya que conoce su ubicación y orientación, el RCX no, por lo que este
último debía guardar algo de historia de sus movimientos en su respectivo modo
autónomo) para decidir el siguiente comando a ejecutar y poder así enviar una respuesta
al terminar de ejecutarlo. Para el modo Autónomo RCX, se deben ubicar obstáculos en
los límites del ambiente, ya que el RCX no conoce las dimensiones de éste.
Durante las pruebas se presentó un problema que obligó a asistir al robot durante las
rotaciones. Esto sucedió debido a que el suelo donde se instaló el ambiente no era
totalmente liso y tenía protuberancias que hacían que el robot no pudiera avanzar al
quedar este bloqueado por la marca sobre la que se encontraba (al quedar ésta más alta y
por lo tanto por encima del sensor), y depresiones en las que una o ambas de las ruedas
perdían tracción y hacían que el robot se desviara, más que todo en las curvas. En pruebas
anteriores (en un suelo más liso), se logró que el robot recorriera más de la mitad del
ambiente sin requerir asistencia para corregir su curso.
La disposición del ambiente (al no tener objetos circundantes que reflejaran) y las
condiciones de iluminación (luz blanca muy intensa), hicieron que en algunos momentos
no fuera posible la comunicación entre el PC y el RCX, y fuera necesario mantener el
puerto infrarrojo del PC apuntado siempre al puerto infrarrojo del RCX. En pruebas
anteriores, con paredes circundantes y luz más tenue, se logró siempre comunicación
entre el PC y el RCX y viceversa, dejando el sensor en el suelo apuntado hacia el
ambiente y con las paredes al fondo y a los lados.
Para poner en funcionamiento el sistema, se debe tener instalado lo siguiente, verificando
que las variables de entorno se definan correctamente (los instaladores se incluyen en el
CD adjunto):
65
1. Máquina virtual de Java (versión usada: 1.4.2_04).
2. Apache Ant (versión usada: 1.6.1).
3. Controlador (Driver) del Transmisor Infrarrojo de Lego.
Los pasos a seguir para la ejecución son:
1. Conectar el Transmisor Infrarrojo de Lego a un puerto USB auto alimentado.
2. Copiar al disco duro del computador, el directorio APT del CD.
3. Definir la variable de entorno LEJOS_HOME y apuntarla al subdirectorio leJOS,
dentro de APT.
4. Ejecutar la tarea firmware de Ant, para transferir leJOS al RCX.
5. Ejecutar la tarea download de Ant, para compilar, encadenar y descargar el
programa al RCX.
6. Ejecutar la tarea start de Ant, o presionar el botón “Run” del RCX para ejecutar
el programa en el RCX.
7. Ejecutar la tarea run de Ant para compilar y ejecutar el programa en el PC.
66
La interfaz gráfica de la aplicación se muestra a continuación:
Figura 16. Interfaz Gráfica de la Aplicación del PC
Los diferentes componentes de la interfaz gráfica son:
1. Panel de Reconstrucción del Ambiente: En éste, el operador tiene una visión de
lo que el robot ha logrado reconocer del ambiente, en la tarea que desarrolló el
robot, se pueden distinguir marcas (con su color), caminos (bloqueados o libres) y
la posición y orientación del robot. El panel está identificado en la figura con rojo.
2. Panel de Modo de Control: En éste, el operador escoge entre los cuatro posibles
modos de operación, si escoge los modos PC Auto o RCX Auto, el sistema le
pedirá una confirmación y procederá a iniciar dicho modo. El panel está
identificado en la figura con amarillo.
67
3. Panel de Estado del Robot: En este panel el operador puede ver el estado del
robot en lo que se refiere a enlace de comunicación, carga de la batería y cantidad
de memoria libre. Se dispone de un botón para actualizar los valores cuando el
operador lo requiera. El panel está identificado en la figura con naranja.
4. Panel de Comandos: En este panel se encuentran los botones para los distintos
comandos de movimientos y sensores (adelante, atrás, girar a izquierda y derecha,
detenerse y leer el sensor de luz). Si el sistema se encuentra en modo Directo, el
comando será enviado y ejecutado inmediatamente por el RCX, si el modo es
Cola de Comandos, el comando se almacenará y posteriormente se enviará con
los demás comandos almacenados al RCX para su ejecución. El panel está
identificado en la figura con verde.
5. Panel de Cola de Comandos: En este panel se muestran los comandos que están
almacenados actualmente si las letras de un comando están en rojo, significa que
el comando no ha sido enviado al RCX, si están en amarillo, significa que el
comando ha sido enviado al RCX pero no se ha ejecutado, si están en verde,
significa que el comando ya se ejecutó. Se dispone de un botón para enviar los
comandos al RCX, otro para comenzar la ejecución de los mismos, y un último
para borrar los comandos que se encuentren almacenados. El panel está
identificado en la figura con azul.
68
Figura 17. Componentes de la Interfaz Gráfica de la Aplicación del PC
69
6. CONCLUSIONES Y TRABAJO FUTURO
La teleoperación de robots es un campo con muchas aplicaciones en áreas como
producción, vigilancia, manipulación, entretenimiento, entre muchas otras,
desafortunadamente, no se ha hecho la suficiente investigación en la Universidad y la que
se ha hecho no ha tenido continuidad y por lo tanto no ha resultado útil. Se espera que se
siga con el desarrollo de este trabajo por parte de otros estudiantes con el fin de llegar a
hacer un aporte por parte de la Universidad al país.
El desarrollo del sistema permitió enfrentarse a los problemas de concurrencia, vistos de
una manera muy teórica en los cursos relacionados, en una aplicación real, con varios
hilos de ejecución simultáneos en más de una máquina (PC y RCX). Fue muy interesante
y formativo abordar estos problemas y darles solución.
La principal limitante fue la memoria del RCX, mencionada anteriormente, lo que retraso
considerablemente el desarrollo. Para futuros trabajos sobre este sistema, se sugiere
integrar más de un RCX en el robot, con el fin poder tener una lógica más robusta y mas
entradas (sensores) y salidas (motores).
Se observó que no se ha usado leJOS en otros proyectos similares, ya que se debieron
hacer algunos cambios para poder afrontar de manera adecuada los problemas de
comunicación que se pueden presentar en la teleoperación. Se espera que al hacer
públicos estos cambios sean integrados en una futura versión de leJOS y que el origen de
estos motive a otros a desarrollar trabajos similares.
70
Se espera que a partir de este trabajo, se siga investigando en el área de robótica y en
especial en la de teleoperación, ya que de esta investigación pueden resultar ideas más
concretas que pueden beneficiar de algún modo al sector productivo colombiano, entre
otros, con herramientas libres como lo son java y leJOS.
El siguiente paso en el desarrollo de este trabajo es extender la distancia entre el operador
y el robot, usando Internet como medio de comunicación. Se puede comenzar por utilizar
RMI para utilizar el código existente, luego pasar a una interfaz Web (usando servlets o
EJBs) para finalmente llegar a controlar el robot desde dispositivos móviles (con
interfaces WML o J2ME), se debe tener en cuenta que los problemas relacionados con
teleoperación mencionados se presentarían a dos niveles: el primero es la actual
comunicación vía infrarrojos entre el RCX y el PC y el segundo sería la comunicación
entre el PC y el dispositivo del operador (móvil o fijo), que sería por Internet, usando los
protocolos HTTP, HTTPS, RTP o alguno creado para este trabajo en particular. Además
de esto, es importante probar el sistema con otras tareas, para así demostrar las
verdaderas capacidades y posibles usos reales del sistema.
Se considera que el Lego RCX 2.0 puede utilizarse en la solución de problemas de la vida
real, sin la necesidad de adquirir hardware a altos costos, ya que se comprobó que,
usando leJOS, la interacción con el PC es muy sencilla. Se puede aumentar la robustez
del software agregando más de un RCX al robot (como se sugirió anteriormente) y
reemplazando las piezas plásticas de lego por partes metálicas hechas a la medida (no
tienen que ser como las de lego, solo se utiliza el RCX como dispositivo de control de
bajo costo, con varias posibilidades para ser programado, como java, c, c++, etc.).
El Control Colaborativo resulta ser una gran alternativa para reducir la carga en el
operador y permitir que éste se dedique a los aspectos realmente relevantes y que
requieran de su intervención, dejando que el dispositivo controlado u otro intermedio se
dediquen a los demás aspectos y de esta forma se aumenta la estabilidad y robustez del
sistema.
71
7. REFERENCIAS
[1] Bagnall, Brian. (2002). Core LEGO MINDSTORMS Programming: Unleash the
Power of the Java Platform. Prentice Hall.
[2] Fong, Terrence. (2001). Collaborative Control: A Robot-Centric Model for Vehicle
Teleoperation. Pittsburgh, Pennsylvania. Carnegie Mellon University
[3] Fiorini, Paolo & Oboe, Roberto. (1997). Internet-Based Telerobotics: Problems and
Approaches. Pasadena, California. CiteSeer.
[4] RFC 1889. (1986). RTP: A Transport Protocol for Real-Time Applications.
Schulzrinne, et al. Recuperado el 23 de Septiembre de 2003, de
http://www.faqs.org/rfcs/rfc1889.html
[5] MindStorms RCX Sensor Input Page. Recuperado el 23 de Septiembre de 2003, de
http://www.plazaearth.com/usr/gasperi/lego.htm
[6] LEGO.com Mindstorms RIS Highlights. Recuperado el 23 de Septiembre de 2003, de
http://mindstorms.lego.com/eng/products/ris/rishighlights.asp
[7] The leJOS Tutorial: A practical guide for developers. Recuperado el 23 de
Septiembre de 2003, de http://mp.scholz.bei.t-online.de/lejos/tutorial/index.html
72
[8] LeJOS. Recuperado el 23 de Septiembre de 2003, de
http://dudley.wellesley.edu/~anderson/robots/lejos/
[9] Using leJOS. Recuperado el 23 de Septiembre de 2003, de http://www.informatik.fh-
muenchen.de/~schieder/usinglejos/
[10] MindStorms RCX Sensor Input Page. Recuperado el 14 de Octubre de 2003, de
http://www.plazaearth.com/usr/gasperi/lego.htm
[11] Boulette's Robotics page. Recuperado el 14 de Octubre de 2003, de
http://www.restena.lu/convict/Jeunes/RoboticsIntro.htm
[12] Department of Automatic Systems and Robotics @ BMSTU RISM – Rusia
[13] JPL @ NASA – USA
[14] Ivanisevic, I. and Lumelsky, V. (1998) Operating in Configuration Space
Significantly Improves Human Performance in Teleoperation. Robotics Lab,
University of Wisconsin-Madison.
[15] The LEGO Group, (2000) LEGO MindStorms RIS 2.0 Constructopedia
[16] Crosbie, Mark. LEGO Differential Drive. Recuperado el 4 de Marzo de 2004, de
http://www.mastincrosbie.com/mark/lego/diffdrive.html
[17] Grand, Mark. (1998). Patterns in Java, Volume 1, A Catalog of Reusable Design
Patterns Illustrated with UML. John Wiley & Sons.
[18] Scholz, Matthias Paul. Bagnal, Brian y Griffiths, Lawrie. (2003). The leJOS
Tutorial, A practical guide for developers. Recuperado el 13 de Mayo de 2003 de:
http://lejos.sourceforge.net/tutorial/
73
[19] Omnitech Robotics International, LLC. (2001). Standardized Teleoperation System
(STS) Datasheet.
[20] TELEDRIVE Project Page. (2003). Recuperado el 18 de Mayo de 2004 de:
http://www.cps.unizar.es/~laimuz/teledrive/Home.html
[21] Fong, Terrence. (2002). Advanced Teleoperation Interfaces Project Briefing.
Recuperado el 18 de Mayo de 2004 de: http://vrai-group.epfl.ch/projects/ati/
[22] Red Rover Goes to Mars Project Page. Recuperado el 18 de Mayo de 2004 de:
http://redrovergoestomars.org/
[23] MARS STATION South Pole2. Recuperado el 18 de Mayo de 2004 de:
http://lego.marshall.edu/Marsprof.htm
[24] MLCad. http://www.lm-software.com/mlcad/e_main.htm
[25] LPub. http://www.kclague.net/LPub/
[26] L3P. http://www.hassings.dk/l3/l3p.html
[27] POV-Ray. http://www.povray.org/
[28] leJOS. http://lejos.sourceforge.net/
[29] Java. http://java.sun.com/j2se/
74
8. APENDICE A
INSTRUCCIONES DE ARMADO DEL ROBOT
A continuación se encuentran los pasos para armar el robot usado en este trabajo, en cada
paso se enumeran las partes necesarias para completar dicho paso, algunas no hacen parte
del Robotics Invention System 2.0, y fueron tomadas de otros sets de Lego, el sensor de
rotación fue proporcionado por la Universidad. El modelo del robot se creó usado
MLCad [24], las instrucciones de armado fueron generadas con LPub [25] y las imágenes
se generaron con L3P [26] y POV-Ray [27].
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
