orión interfaz hombre máquina para el sistema móvil de detección y

orión interfaz hombre máquina para el sistema móvil de detección y
ORIÓN
INTERFAZ HOMBRE MÁQUINA PARA EL SISTEMA MÓVIL DE
DETECCIÓN Y LOCALIZACIÓN DE MINAS ANTIPERSONALES
ÚRSULA.
DANIEL GARCIA TRONCOSO
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA ELECTRÓNICA
BOGOTA D.C.
ORIÓN
INTERFAZ HOMBRE MÁQUINA PARA EL SISTEMA MÓVIL DE
DETECCIÓN Y LOCALIZACIÓN DE MINAS ANTIPERSONALES
ÚRSULA.
DANIEL GARCIA TRONCOSO
Trabajo de grado presentado como
requisito parcial para optar al título de
Ingeniero Electrónico.
Director:
Carlos Alberto Parra R. Ph.D.
Ingeniero Electrónico.
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE ELECTRÓNICA
BOGOTÁ D.C.
2004
2
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA ELECTRÓNICA
RECTOR MAGNIFICO: R.P. GERARDO REMOLINA S.J.
DECANO ACADÉMICO: Ing. ROBERTO ENRIQUE MONTOYA VILLA
DECANO DEL MEDIO UNIVERSITARIO: R.P. ANTONIO JOSÉ SARMIENTO NOVA S.J.
DIRECTOR DE CARRERA: Ing. JUAN CARLOS GIRALDO CARVAJAL
DIRECTOR DEL PROYECTO: Ing. CARLOS ALBERTO PARRA R. Ph.D.
3
ARTICULO 23 DE LA RESOLUCIÓN No. 13 DE JUNIO DE 1946
"La universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus
proyectos de grado.
Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque los
trabajos no contengan ataques o polémicas puramente personales. Antes bien, que se vea en
ellos el anhelo de buscar la verdad y la justicia".
4
TABLA DE CONTENIDO
1.
2.
INTRODUCCIÓN
11
MARCO TEÓRICO
13
2.1
SISTEMAS DE ADQUISICIÓN DE DATOS, SUPERVISIÓN Y CONTROL.
15
3. ESPECIFICACIONES
17
3.1
DESCRIPCIÓN GENERAL
17
3.2
DIAGRAMA DE BLOQUES
20
4. DESARROLLO
21
4.1
DISEÑO DE SISTEMAS DE TIEMPO REAL.
22
4.2
REQUERIMIENTOS DEL SISTEMA.
23
4.2.1
Requerimientos funcionales.
24
4.2.2
Requerimientos no funcionales.
27
4.3
DISEÑO ESPECÍFICO DEL SISTEMA ORIÓN.
29
4.4
CLASE ÚRSULA O BÚFER CENTRAL.
31
4.4.1
Estructura TValores.
32
4.4.2
Estructura TDirectiva.
35
4.4.3
Estructura TRangos.
37
4.4.4
Estructura TMapa.
38
4.4.5
Clase TComPort.
39
4.4.6
Clase TIniFile.
42
4.4.7
Variables del búfer central
44
4.4.8
Funciones de la clase Úrsula.
45
4.5
CLASE DM – CONEXIÓN CON LA BASE DE DATOS.
47
4.5.1
Diseño de base de datos.
48
4.5.2
Implementación de la base de datos en Orión.
50
4.6
CLASE DMJOYSTICK.
52
4.7
LIBRERÍA IO.DLL
53
4.8
DISEÑO DE NAVEGACIÓN E INTERFAZ DEL SISTEMA.
55
4.9
FORMULARIO PRINCIPAL O MAIN FORM.
57
4.9.1
Menú Configuración.
58
4.9.2
Menú Acciones.
61
4.9.3
Menú Consulta
61
4.10 FORMULARIO TELECOMANDO
65
4.10.1 Frame Control Principal.
68
4.10.2 Frame Batería
70
4.10.3 Frame Detector
70
4.10.4 Frame Temperatura
71
4.10.5
Frame Ultrasonido
72
4.10.6
Frame Brújula, Pitch y Roll
72
4.10.7 Frame Velocidad.
74
4.10.8 Frame Mapa
74
4.10.9
Frame Control Manual.
76
5
4.10.10
Frame Manejo de Directivas.
4.11 ADMINISTRACIÓN DE PROCESOS.
4.11.1 Proceso de Comunicación – Sincronización Orión Úrsula.
4.11.2 Actualización de Instrumentos.
4.11.3 Proceso de registro en la base de datos.
5. PRUEBAS Y ANÁLISIS DE RESULTADOS
5.1
COMUNICACIÓN PC – PC CON CABLE SERIAL CRUZADO.
5.2
COMUNICACIÓN PC – MOVIL CON CABLE SERIAL CRUZADO.
5.3
COMUNICACIÓN PC – MOVIL CON MÓDULOS INALÁMBRICOS
5.4
ALMACENAMIENTO EN BASE DE DATOS.
5.5
CONSTRUCCIÓN VIRTUAL DE TERRENO.
5.6
MANIPULACIÓN POR GAME CONTROLLER O SISTEMAS
JOYSTICK.
6. CONCLUSIONES
7. BIBLIOGRAFÍA
8. ANEXOS
ANEXO A: CÓDIGO DE ORIÓN.
ANEXO B: CÓDIGO DE PROGRAMAS AUXILIARES.
ANEXO C: MODICON MODBUS PROTOCOL REFERENCE GUIDE.
ANEXO D: MANUAL DE USUARIO.
79
80
81
90
91
92
92
96
98
102
103
DE
104
105
108
109
110
111
112
113
6
INDICE DE FIGURAS
Figura 1. Esquema Jerárquico del Sistema Úrsula.
18
Figura 2. Diagrama General de Bloques para el Sistema Orión
20
Figura 3. Arquitectura de un sistema de supervisión modificado para Orión – Úrsula.
23
Figura 4. Diagrama Detallado de Bloques para el Sistema Orión.
30
Figura 5. Definición de la Clase TUrsula.
31
Figura 6. Definición de Estructura TValores.
32
Figura 7. Definición de Estructura TBrazo.
34
Figura 8. Definición de Estructura TDirectiva.
36
Figura 9. Definición de Estructura TRangos.
37
Figura 10. Definición de Estructura TMapa.
39
Figura 11. Almacenamiento de los datos en el archivo orion.ini.
43
Figura 12. Diagrama Entidad Relación de la Base de Datos para Orión.
49
Figura 13. Jerarquía del Advantage TDataSet.
50
Figura 14. Formulario principal o Main Form.
58
Figura 15. Funciones del Menú Configuración.
59
Figura 16. Formulario de Configuraciones de Rangos.
59
Figura 17. Formulario Configuración de Puerto.
60
Figura 18. Funciones del menú Acciones.
61
Figura 19. Funciones del menú Consulta.
61
Figura 20. Formulario Gestión de Sesiones.
62
Figura 21.Ventana de diálogo Guardar como de la Gestión de Sesiones.
63
Figura 22. Formulario Telecomando.
66
Figura 23. Frame Control Principal
68
Figura 24. Frame Batería.
70
Figura 25. Frame Detector
70
Figura 26. Frame Temperatura.
71
Figura 27. Frame Ultrasonido.
72
Figura 28. Frame Brújula Pitch y Roll.
72
Figura 29. Frame Velocidad.
74
Figura 30. Frame Mapa
74
7
Figura 31. Solicitud de parámetros del mapa.
75
Figura 32. Frame Control Manual.
76
Figura 33. Frame Manejo de Directivas.
79
Figura 34. Relación Esclavo Maestro - Ciclo de Consulta Respuesta.
82
Figura 35. Orden de Trama para paquete de consulta 16
87
Figura 36. Orden de Trama para paquete de consulta 4
88
Figura 37. Orden de Trama para paquete de respuesta 16
88
Figura 38. Orden de trama para paquete de respuesta 4
89
Figura 39. Barra de estado Formulario Telecomando.
91
Figura 40. Programa Auxiliar Rigel.
93
Figura 41. Programa Auxiliar Betelgeuse.
94
Figura 42. Paquetes Exitosos por Paquete Perdido
100
Figura 43. Número de Paquetes Perdidos Consecutivos
101
8
INDICE DE TABLAS
Tabla 1. Mapa de memoria de Úrsula para los parámetros de escritura.
19
Tabla 2. Mapa de Úrsula de memoria para los parámetros de lectura.
19
Tabla 3. Definición de directivas para el robot.
37
Tabla 4. Descripción de campos de la tabla session.
48
Tabla 5. Descripción de campos de tabla tramas.
49
Tabla 6. Configuración del teclado y joystick para control manual.
78
Tabla 7. Trama general de un paquete Modbus modo RTU.
83
9
ÍNDICE DE ANEXOS
ANEXO A: CÓDIGO DE ORIÓN.
ANEXO B: CÓDIGO DE PROGRAMAS AUXILIARES.
ANEXO C: MODICON MODBUS PROTOCOL REFERENCE GUIDE.
ANEXO D: MANUAL DEL USUARIO.
10
1. INTRODUCCIÓN.
En algunas labores, un robot móvil debe ejecutar tareas en entornos hostiles o insalubres
para el hombre, como en el caso de la desactivación de explosivos, el trabajo en zonas con
alta radiactividad, en ejecución de la operación de mantenimiento dentro de estaciones
generadoras de energía o simplemente en regiones inaccesibles para el hombre como lo son
el fondo marino o el espacio. La ejecución de estas tareas puede requerir realizar
operaciones más o menos complejas, todas orientadas a ejecutar la misión principal para la
que fue diseñada el robot; por ejemplo, exploración o reconocimiento de regiones, las
cuales son difíciles de implementar en un controlador típico de robots que esté diseñado
para operar de forma autónoma. En esos casos, una posible solución para el problema
consiste en implementar un sistema orientado a tele-operación o tele-manipulación. Tal es
el caso de un robot aplicado al desminado, pues es necesario poder controlar todos los
parámetros del mismo, haciendo esta operación mediante una interfaz operada a distancia.
El robot tiene que cubrir la localización, detección y desactivación de minas antipersonales
por ser uno de los componentes centrales de la actividad en contra de las minas. Hablando
en sentido amplio, dentro de esta operación se incluyen la investigación previa, mapeo y
marcado del campo minado, así como el retiro total de las minas enterradas. Todo está
enmarcado dentro de lo que se conoce como “desminado”.
Aunque las operaciones de desminado llevadas a cabo con estándares internacionales son
costosas, estudios recientes han mostrado que no sólo permiten la recuperación social de las
11
comunidades afectadas, sino que pueden ser justificadas sobre la base de un análisis
puramente económico de costo-beneficio.
En la Universidad Javeriana el grupo de investigación SIRP (Sistemas Inteligentes,
Robótica y Percepción), se ha encargado de desarrollar un proyecto de robótica, llamado
“ÚRSULA” SISTEMA MÓVIL DE DETECCIÓN Y LOCALIZACIÓN DE MINAS
ANTIPERSONALES, donde se ha implementado un robot móvil.
El trabajo presentado en este reporte realiza un aporte al proyecto “ÚRSULA” en el cual se
desarrolló un sistema interfaz Hombre-Máquina para la tele-operación del robot, llamado
“Orión”, superando la interfaz implementada originalmente en varios aspectos que se
desarrollarán más adelante. Esta interfaz, está funcionando sobre la estación de base que es
el puesto de mando del robot.
En este documento se describe el desarrollo de la interfaz hombre-máquina desarrollada
como parte del proyecto de robot para la detección de minas anti-personales, esta interfaz
es un complemento importante del proyecto de robótica móvil Úrsula. A su vez, se
describe el proceso metodológico para hacer el desarrollo de la interfaz. Por otro lado en el
documento se definen los requerimientos del móvil para delimitar el alcance del proyecto,
luego se realiza una descripción detallada de cada uno de los módulos implementados,
sustentados por los diferentes métodos de desarrollo de software utilizados. Por último se
describen las pruebas realizadas con las respectivas conclusiones obtenidas del proyecto.
12
2. MARCO TEÓRICO.
Los PC en la actualidad se utilizan como centros o soportes de control, en un sin número de
sistemas, que pueden ir desde manufacturas muy complejas a máquinas de uso doméstico.
Estas computadoras interactúan directamente con dispositivos periféricos de hardware, que
como en el caso de este proyecto, están conectados a puertos de comunicación principales.
Estos sistemas son llamados sistemas de tiempo real y hacen parte importante en la
estructura completa del proyecto de detección de minas y deben principalmente tener la
capacidad de reaccionar a los eventos que los sistemas de hardware generan.
Los sistemas de tiempo real son un poco diferentes a otros tipos de software como los
utilizados en sistemas financieros, aplicaciones cliente servidor, objetos distribuidos, etc.
Su funcionamiento correcto depende de las respuestas del mismo en un intervalo de tiempo
especificado (normalmente corto) y se definen de la siguiente manera: “Un sistema de
tiempo real es un sistema de software donde el funcionamiento correcto del sistema
depende de los resultados producidos por el sistema y del tiempo en el cual se producen
estos resultados. Un sistema de tiempo real “suave” es un sistema cuya operación se
degrada si los resultados no se producen de acuerdo con los requerimientos de tiempo
especificados. Un sistema de tiempo real “duro” es un sistema cuya operación es
incorrecta si los resultados no se producen de acuerdo con las especificación de tiempo”1.
1
Ian Somersville. Ingeniaría de Software. Addison Weley. 6 edición.
13
Otra manera de ver un sistema de software de tiempo real, es a través de sus estímulos y
respuestas, las características de las reacciones de las mismas, las respuestas asociadas y el
tiempo en que estas ocurren o deben ocurrir. Los estímulos son principalmente de dos
clases:
•
Estímulos Periódicos: Estos ocurren en un intervalo de tiempo predecible (muy
usados en muestreo) para este caso en la comunicación con el robot, por ejemplo si
se están examinando los datos de un sensor cada determinado tiempo.
•
Estímulos Aperiódicos: Ocurren de forma irregular, normalmente están conectados
al sistema por un mecanismo de interrupción de la computadora, muy útil en los
sistemas de lectura de puertos o validando la finalización de tareas encomendadas al
sistema.
Un sistema de tiempo real tiene que responder a estímulos que ocurren en diferentes
momentos, por lo tanto, su arquitectura se debe organizar para que el control se transfiera al
controlador apropiado de manera que el estímulo sea atendido tan pronto como éste se
reciba. Esto no es práctico en los programas secuenciales. Por lo tanto, los sistemas de
tiempo real normalmente se diseñan como un conjunto de procesos cooperativos
concurrentes y una gran parte del desarrollo de este tipo de sistemas es la administración de
estos procesos.
14
2.1 SISTEMAS
DE ADQUISICIÓN DE DATOS, SUPERVISIÓN Y
CONTROL.
Existen varios modelos genéricos para el diseño de sistemas de tiempo real, cada uno
enfocado específicamente a una función en particular: supervisión, adquisición de datos,
órdenes y control.
Los sistemas de adquisición de datos son una clase particular de sistemas de tiempo real,
que se basan por lo general, en un modelo basado en una arquitectura genérica. Estos
sistemas recolectan datos de los sensores para su procesamiento y análisis subsecuentes.
Para el caso de Úrsula los sensores son reemplazados por el sistema de comunicación,
conectado al robot, en otras palabras se define el proceso de comunicación con el robot
como el proceso de lectura de sensores.
Orión no solamente se encarga de leer, procesar y mostrar los datos que Úrsula le envía,
adicionalmente le devuelve parámetros y ordenes para que Úrsula actúe, esta también es
una clase particular de los sistemas de tiempo real, llamados sistema de supervisión y
control. Este modelo verifica los sensores que proveen información del entorno del sistema
y toma acciones dependiendo de la lectura del sensor.
Como se ve, el sistema Orión es un poco la mezcla de estos dos modelos, adquiere
constantemente los datos de los sensores del robot, envía parámetros de orden y control del
usuario desde la consola de telecomando y, por último, tiene la opción de conectarse a un
15
motor de base de datos para almacenar el valor de las variables de estado del robot en
intervalos de tiempo definidos.
16
3. ESPECIFICACIONES.
El sistema Orión necesita de un computador personal con las siguientes características
mínimas:
•
Sistema x86, tarjeta Board principal con puerto serial, usando protocolo RS232 y un
puerto paralelo, adicionalmente puerto USB para conexión opcional del Game
Controller.
•
Velocidad del procesador Mínima: 300Mhz. (Recomendado 550Mhz.)
•
Memoria RAM: 64Mb. (Recomendado 128Mb.)
•
Sistema Operativo mínimo: Windows 98®. (Recomendado Windows 2000/XP®).
•
Resolución de pantalla mínima. 1024 x 768 píxeles.
•
Calidad del Color mínima: 16 bits.
3.1 DESCRIPCIÓN GENERAL
Úrsula es un sistema basado en una plataforma móvil que contiene hardware de bajo nivel,
estando conformado también por actuadores y sensores. En el sistema del robot se ha
definido una arquitectura distribuida y jerárquica. Esto implica que cada uno de los
procesos principales tiene un módulo controlador asignado que comparte información con
el nivel inmediatamente superior (procesador central). El procesador central es el encargado
de tomar las decisiones con base en la información entregada por cada eslabón. (Ver figura
1).
17
Figura 1. Esquema Jerárquico del Sistema Úrsula.
El procesador central entrega toda la información al nivel supervisor, en este caso la
interfaz Orión ubicada en la estación remota, la que ejecuta los comandos asignados por
dicho nivel.2 Lo anterior define la relación Esclavo-Maestro y tele-operado con cierta
autonomía, que Úrsula y Orión tendrán.
El conjunto de actuadores y sensores montados sobre el robot determinaron algunas partes
del diseño de un búfer central, las más importantes, ya que estas serán consultadas por los
diferentes módulos conectados en el sistema Orión. Adicionalmente los sistemas de
comunicaciones y protocolos establecidos de conexión permitierón definir la forma en que
los datos serán manejados y cómo se interpretarán los valores que envía Orión y Úrsula.
2
SISTEMA MÓVIL PARA LA DETECCIÓN Y LOCALIZACIÓN DE MINAS ANTIPERSONALES.
Camilo Campo, Javier Coronado, Javier Rizo. Pontificia Universidad Javeriana, 2002
18
Para que los sistemas mantuvieran coherencia se diseño con base en el mapa de memoria
que usa el Robot, los mapas para manejar sus eslabones y que se describe a continuación:
Dirección
Datos
Datos
Hexa Decimal
1F
31
Estado de Caja
Intensidad de Motores
21
33
Azimut del Brazo
Altitud del Brazo
23
35
Manipulador del Brazo
Grado Extra
25
37
Directiva de Ctrl y Dir
Valor Directiva
27
39
Directiva de Azimut
Valor Directiva
29
41
Directiva de Altitud
Valor Directiva
2B
43
Directiva de Manipulador
Valor Directiva
2D
45
Directiva de Extra
Valor Directiva
2F
47
Reservado
Reservado
31
49
Reservado
Reservado
33
51
Reservado
Reservado
35
53
Reservado
Reservado
37
55
Reservado
Reservado
Tabla 1. Mapa de memoria de Úrsula para los parámetros de escritura.
Dirección
Datos
Datos
Hexa Decimal
52
82
Curso o Brújula
Curso o Brújula
54
84
Pitch
Roll
56
86
Temperatura Motor
Temperatura Ambiente
58
88
Velocidad
Velocidad
5A
90
Recorrido(m) del Motor Der Recorrido(cm) del Motor Der
5C
92
Recorrido(mm) del Motor Der Recorrido(m) del Motor Izq
5E
94
Recorrido(cm) del Motor Izq Recorrido(mm) del Motor Izq
60
96
Detector del Metales
Ultrasonido 1
62
98
Ultrasonido 2
Ultrasonido 3
64
100
Ultrasonido 4
Reservado
66
102
Reservado
Reservado
68
104
Reservado
Reservado
6A
106
Reservado
Reservado
Tabla 2. Mapa de Úrsula de Memoria para los parámetros de lectura.
Básicamente Orión tiene que escribir o leer en las direcciones de memoria preestablecidas,
sincronizarse con el búfer y entregar la información necesaria a los módulos que la
soliciten.
19
3.2 DIAGRAMA DE BLOQUES
Figura 2. Diagrama general de bloques para el sistema Orión
Como se aprecia en el diagrama de bloques de la figura 2, se adoptó el módulo de sistema
de tiempo real, definido específicamente con el modelo de adquisición de datos,
supervisión y control. El búfer general se encarga de mantener la información del estado de
Úrsula, el cual reparte todos los datos y guarda los solicitados desde cualquier módulo, sin
importar lo que demoren los demás procesos. El búfer central siempre tendrá la
información del estado del robot y estará dispuesto a entregar o recibir información desde y
hacia cualquier módulo. De está forma se garantiza que los tiempos de respuesta sean
rápidos y la información se pueda repartir sin ningún contratiempo. Se implemento una
metodología de exclusión mútua para prevenir que los procesos accedan al mismo elemento
del búfer.
20
4. DESARROLLO.
El sistema Orión fué desarrollado en la plataforma Windows, versión XP (Build 2600,
Service Pack 1), en Lenguaje C++, con el entorno Builder C++
TM
, Versión 6 (Build
10.157) Enterprise Suite de Borland® Software Corporation. Este entorno amplió las
posibilidades de utilizar diferentes controles que ayudaron en el desarrollo del sistema.
Adicionalmente el lenguaje permite el desarrollo de software con estructura de objetos
ayudando en la fácil implementación del búfer central. Sin embargo, durante el desarrollo
se encontraron ciertos inconvenientes; al realizar la implementación de controles (clases o
estructuras) ya desarrollados para el lenguaje elegido, su primitivo desarrollo ocasionaba
continuas fallas y alta complejidad en la configuración. Builder C++™ es un lenguaje muy
utilizado en desarrollos académicos y de investigación, por no ser un lenguaje fuertemente
“tipado”, es decir, que no tiene muchos tipos definidos, mejorando su manipulación y
permitiendo acceso a los datos de forma precisa; por otra parte, se usa en el desarrollo de
sistemas operativos o soluciones que trabajan directamente con partes o puertos del
hardware. Sin embargo en el ámbito comercial de desarrollo de software no es muy
utilizado, a diferencia de su hermano Delphi™ (herramienta desarrollada también por
Borland® Corporation), que maneja lenguaje Pascal. Esta herramienta tiene gran
disponibilidad en muchos controles adicionales que solucionan gran parte de los problemas
que se tienen planteados como requerimientos del robot. Durante el desarrollo, este fue un
punto para tener en cuenta, sobre todo en el manejo del puerto de comunicaciones, ya que
los controles encontrados para Builder C++™ eran muy primitivos y con alta complejidad
en la implementación. Finalmente se
21
4.1 DISEÑO DE SISTEMAS DE TIEMPO REAL.
Durante el proceso de diseño se debe tener en cuenta cuáles capacidades del sistema se
implementarán en el software y cuáles en el hardware. Las restricciones de tiempo u otros
requerimientos implican que alguna funciones del sistema, tenga que implementarse
utilizando hardware diseñado especialmente. Este es el primer paso en el diseño del
sistema, definir el propósito específico del software de tiempo real.
Una vez que se ha establecido una arquitectura del proceso y se ha decidido la política de
planeación, es necesario llevar a cabo evaluaciones y simulaciones para verificar que el
sistema cumple con sus restricciones de tiempo. La arquitectura del proceso, la política de
calendarización, el sistema ejecutivo o todos en su conjunto tienen que rediseñarse para
mejorar el desempeño del sistema.
Como ya se ha mencionado, los sistemas de tiempo real tienen que responder a los eventos
que ocurren en intervalos irregulares. Estos eventos a menudo provocan que el sistema pase
a diferentes estados.
Después de analizar los diferentes tipos de software de tiempo real, mencionados
anteriormente, se generó una arquitectura modificada de un sistema de supervisión,
aplicada a todo el sistema de detección de minas antipersonales (ver figura 3).
22
Figura 3. Arquitectura de un sistema de supervisión modificado para Orión – Úrsula.
Los procesos de los sensores y de los actuadores se encuentran en el robot y el sistema de
transmisión y recepción se encarga de conectar Úrsula con Orión, el sistema, responsable
de procesar los datos, toma los mismos del búfer, los procesa y los pasa a un proceso de
despliegue para sacarlos a la consola de telecomando. A su vez, este se encarga de entregar
las órdenes de esta misma consola, colocarlas en el buffer diseñado para la aplicación y
luego enviarlas al robot, por medio del proceso de transmisión, para que este aplique las
órdenes especificadas.
4.2 REQUERIMIENTOS DEL SISTEMA.
El primer paso para el desarrollo de Orión, es la definición de requerimientos, realizado por
parte del grupo de investigación y desarrollador de Úrsula, definiendo los parámetros que
23
deben ser enviados y recibidos por el robot, tipo de conexión, protocolo de comunicaciones,
etc.
El grupo de investigación y desarrollador de Úrsula, definió los parámetros que deben ser
enviados y recibidos por el robot, tipo de conexión, protocolo de comunicaciones, etc.
Estos están determinados por los desarrollos realizados y los que se tienen para un futuro.
En la descripción general se presentaron casi todas las condiciones que el robot necesita
para una correcta comunicación, solo se deben que agregar las condiciones propias de
Orión, para esto se agrupan los requerimientos del sistema en funcionales, no funcionales y
de interfaz, como lo sugiere el estándar IEEE/ANSI 830-19933.
4.2.1 Requerimientos funcionales.
Los requerimientos funcionales de un sistema, describen la funcionalidad o los servicios
que se espera que esté proveerá. El robot utiliza un protocolo especial de comunicación,
este protocolo incluye el uso de dos módems inalámbricos para el enlace de radio
frecuencia con Orión. El protocolo se construyó sobre la interfaz RS-232, usando el puerto
serial del computador y del microcontrolador. Los módems están ubicados uno en el
computador donde se debe encontrar la Interfaz y otro sobre el Robot y están debidamente
adaptados a los niveles de voltaje que se manejan en cada lugar. Es decir, el MODEM de la
3
Thayer, R. H. y Dorfman, M. (1997). Software Requirements Engineering. IEEE Computer Society Press.
(Cap 5).
24
estación base tiene un regulador y un adaptador de señales de voltaje ICL232 para convertir
las señales de la interfaz 232 en voltajes TTL. En cambio, el MODEM ubicado en el móvil,
se alimenta directamente y no requiere de adaptador de señales pues estas provienen
directamente del microcontrolador. Los MODEMS utilizados son los LINX SC-PA
trabajando a una frecuencia de 916 MHz.
El enlace inalámbrico impone una limitación al hacer el canal bidireccional “half duplex”.
Esto implica manejar unas señales de control en cada una de las estaciones para indicarle a
los transmisores si deben transmitir o recibir. Estas señales se implementan de manera
bastante simple en la plataforma, pues el procesador central se encarga de generarlas. Sin
embargo, es en la estación base, donde debe encontrarse la Interfaz Orión, es necesario usar
el puerto paralelo del computador para sincronizar el módulo de RF4. De esta manera se
presenta el primer requerimiento funcional.
1. Orión debe ser capaz de utilizar los puertos Serial (RS232) y paralelo, del
computador para manipular los módems, implementados en Úrsula y así poder
recibir y transmitir los datos de las posiciones de memoria establecidas
anteriormente, mínimo 4 veces por segundo.
La supervisión del robot es un factor fundamental en la manipulación del sistema móvil, el
operador debe tener constante información acerca del estado del robot y de sus eslabones,
para tomar soluciones correctivas o buscar un comportamiento específico. Es importante
4
SISTEMA MÓVIL PARA LA DETECCIÓN Y LOCALIZACIÓN DE MINAS ANTIPERSONALES.
Camilo Campo, Javier Coronado, Javier Rizo. Pontificia Universidad Javeriana, 2002
25
recordar que el operador no debe tener una capacitación especializada, para realizar la labor
con el robot.
2. Orión debe ser capaz de presentar de una manera visual todos los datos enviados
por Úrsula, conectando estos a controles gráficos, que relacionen los estados de los
sensores y los controles de dirección y movilización del brazo, de tal manera que
sea fácil para el operador tomar decisiones de manipulación, corrección y control.
Úrsula debe hacer seguimientos de los datos trasmitidos en intervalos específicos de
tiempo, para realizar estudios posteriores de comportamiento y posibilidades de evolución
con nuevos sensores o actuadores.
3. Orión debe ser capaz de almacenar los datos que recibe y envía, en algún tipo de
registro, base de datos, etc., para posteriores consultas y análisis. Los datos deben
ser manipulables y exportables en algún tipo de formato de hoja de cálculo, base de
datos, archivo plano, etc.
Uno de los grandes problemas del robot es la interpretación del terreno, el robot puede
tomar datos acerca de su inclinación, desplazamiento con respecto a un punto inicial, entre
otros y necesita que estos datos sean interpretados por el operador, para obtener ubicación
espacial y movilizarse con mayor facilidad, minimizando las posibilidades de error.
4. Orión debe interpretar los datos de inclinación (Pitch y Roll), con los indicadores de
desplazamiento del robot para ilustrar de una forma clara, el esquema del terreno,
indicando secciones, ya conocidas y zonas peligrosas.
26
En la búsqueda de una mayor adaptación del hombre a la teleoperación, éste ha diseñado
dispositivos que facilitan de manera natural, la migración de órdenes y decisiones desde el
operador al robot, como los Joystick, game controller, etc.
5. Orión aceptará conexiones con aparatos de uso manual, como Joysitck, Game
Controllers o Gamepad, por puertos que pueda reconocer fácilmente el Sistema
Operativo y permitir al operador manipular Úrsula de manera más natural.
4.2.2 Requerimientos No Funcionales.
Los requerimientos no funcionales, son aquellos que no se refieren directamente a las
funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste. De
tal manera que el primer y más importante requerimiento no funcional de Orión es la
respuesta en el tiempo.
1. Orión debe estar en la capacidad de procesar los datos enviados por el robot y
mantener una comunicación constante, rápidamente, es decir en términos de
décimas de segundo. Debe mantener los controles gráficos actualizados en un orden
de tiempo similar, refrescando pantallas y minimizando el tiempo de respuesta al
usuario.
27
La búsqueda y exploración de un terreno puede durar varias horas, por lo tanto el sistema
no solo debe tener una rápida reacción y comunicación con el robot, sino que debe
mantenerla.
2. Es necesario que Orión mantenga un alto grado de fiabilidad y estabilidad, sin
presentar pérdidas de información, ni caídas inesperadas, el tiempo de fallas
promedio debe ser menor del 2%, adicionalmente debe tener la capacidad de
sincronizarse rápidamente con el robot, en caso de perder la conexión, minimizando
el porcentaje de eventos que provocan fallas, garantizando así robustez.
Aunque el tipo de información almacenada no es de gran tamaño, si lo es el número de
veces que se registra estos datos, por lo tanto se debe garantizar que esta información se
pueda almacenar.
3. La base de datos que maneja el sistema Orión debe tener la capacidad de almacenar
un número muy alto de registros, ya que las grabaciones se hacen en intervalos de
tiempo muy pequeños (décimas de segundos), sin embargo la pérdida de algunos de
estos registros no es crítica, ya que muchos serán muy parecidos o si no iguales.
El robot detector de minas antipersonales es un proyecto en constante evolución y la
interfaz tiene que alinearse a estos parámetros de crecimiento, el robot puede tener nuevas
demandas y estas podrán ser cubiertas con nuevos recursos y controles.
28
4. El diseño del sistema interfaz debe cumplir con características de escalabilidad,
garantizando el crecimiento de las capacidades del sistema, agregando nuevos
módulos que cubran las nuevas necesidades del Robot.
4.3 DISEÑO ESPECÍFICO DEL SISTEMA ORIÓN.
Una vez obtenidos y organizados los requerimientos del Robot y de la interfaz, se debe
diseñar los bloques específicos del proyecto. Como se mencionó y justificó anteriormente
el modelo más acorde al sistema de teleoperación es el software de tiempo real. Este tipo de
sistemas, difiere de los otros procesos de diseño de software, en que los tiempos de
respuesta del sistema, se deben considerar al inicio del proceso.
Para tener un criterio válido y obtener un diseño acorde a los requerimientos de este
proyecto, se siguieron los siguientes pasos:
1. Identificación de estímulos que el sistema debía procesar y sus respectivas
respuestas, incluyendo agrupación de estos.
2. Para cada uno de esos estímulos y respuestas se identificaron las restricciones de
tiempo que se tienen.
3. Se asociaron procesos a cada clase de estímulos y respuestas, con el objetivo de
distribuir el sistema.
4. Se diseñó un sistema de planeación para asegurar que los procesos se inician en un
tiempo determinado, garantizando el funcionamiento completo de la interfaz.
29
5. Se generaron algunos algoritmos asociados a los procesos, con el fin de tener una
medida de procesamiento requerida en cantidad de recursos y tiempos.
Obteniendo el resultado, presentado en la figura 4.
Figura 4. Diagrama Detallado de Bloques para el Sistema Orión.
30
4.4 CLASE ÚRSULA O BÚFER CENTRAL.
Como se presentó en el capítulo anterior, el módulo principal de Orión es el búfer central,
implementado en una clase llamada TUrsula, definida de la siguiente manera:
Figura 5. Definición de la Clase TUrsula.
Esta clase tiene varias subestructuras definidas para complementar la información que debe
guardar, adicionalmente tiene definidas 2 funciones privadas y 6 públicas diferentes a la
constructora y destructora. Cada estructura se encarga de mantener relación con cada uno
de los módulos que de ella se conectan, algunas trabajan juntas para atender o recibir
31
peticiones de los módulos del sistema. Todas las definiciones de las estructuras incluyendo
la misma definición de la clase se encuentran en el archivo UnitUrsula.h
4.4.1 Estructura TValores.
La estructura TValores contiene los datos que el robot envía y recibe en la trama de
comunicaciones y que se enlazan directamente con algún comportamiento directo del
Robot, básicamente cubre todas las posiciones de memoria que se vieron anteriormente, por
lo tanto si se quisiera agregar un sensor o un eslabón, se agregaría a esta estructura.
Figura 6. Definición de Estructura TValores.
Casi todas las variables dentro de la estructura, son números de diferentes tipos, algunas
son subestructuras definidas para mantener los datos relacionados a una parte del robot
concentradas, adicionalmente esto permite agregar datos que sean solicitados por el robot,
sin generar traumatismos, ni desorden. A continuación se explicará, cual es la función que
tiene cada una de las variables dentro de la estructura:
32
•
Curso: Tipo Entero. Guarda el valor de la brújula, puede tomar valores enteros
entre 0 y 360, con un rango interpretado de -180 a 180 grados; 1 por cada grado.
•
Pitch: Tipo Entero. Guarda el valor de inclinación frontal, puede tomar valores
enteros entre 0 y 180, con un rango interpretado de -90 y 90; 1 por cada grado.
•
Roll: Tipo Entero. Guarda el valor de la inclinación lateral, puede tomar valores
enteros entre 0 y 180, con un rango interpretado de -90 y 90; 1 por cada grado.
•
TempMotor: Tipo Entero. Guarda el valor de la temperatura del motor, 1 por cada
grado centígradoy los límites de interpreación son configurables (predeterminados 2º, 80º centígrados).
•
TempAmbiente: Tipo Entero. Guarda el valor de temperatura ambiente indicado
por el Robot, 1 unidad por cada grado centígrado y los limites de interpretación son
configurables (predeterminados -2º, 80º centígrados).
•
Velocidad: Tipo Entero sin Signo. Guarda el valor determinado por el robot como
velocidad, acepta valores ente 0 y 65025, cada unidad representa 1 mm/s.
•
X: Tipo Entero Largo sin Signo. Guarda el valor de la longitud absoluta recorrido
por el motor de Ruedas Derecho, acepta valores entre 0 y 16’581.375, cada unidad
equivale a 1 mm de recorrido.
•
Y: Tipo Entero Largo sin Signo. Guarda el valor de la longitud absoluta recorrido
por el motor de Ruedas Izquierdo, acepta valores entre 0 y 16’581.375, cada unidad
equivale a 1 mm de recorrido.
33
•
Dirección: Tipo Entero. Guarda el estado de dirección del robot, es equivalente a
una caja de un carro, solo puede tener 4 valores válidos, definidos en el encabezado
del archivo donde se define la clase (UnitUrsula.h):
•
URS_CENTER
0
: Valor para Neutro.
URS_UP
2
: Valor para Adelante.
URS_DOWN
4
: Valor para retroceder.
URS_LEFT
8
: Valor para Girar a la Izquierda.
URS_RIGHT
16 : Valor para Girar a la Derecha.
Detector: Tipo Entero. Guarda el valor de intensidad del detector de Metales, puede
contener valores entre 0 y 255, interpretados en el rango de 0 a 100%, es decir 0 es
no metal (0%) y según los incrementos al valor máximo 255 (100%). El límite o
porcentaje de tolerancia se define en la configuración de Orión y es calibrada por el
experto
•
Brazo: Tipo TBrazo. Guarda los valores de inclinación del brazo y sus diferentes
grados de libertad, el Tipo Brazo se define así:
Figura 7. Definición de Estructura TBrazo.
34
Donde los grados de libertad son de tipo Entero, pueden tener valores entre 0 y 255,
pero cada uno de ellos tiene definidos sus propios rangos así:
Azimut (-90º, 90º centígrados), Altitud (-45º,
45º), Manipulador (-90º,90º
centígrados), Selector (para futuras evoluciones). La Variable selector de tipo
Entero, guarda el control que se encuentra activo, más adelante en la teleoperación
del robot se presenta cómo solo se manipula un Brazo a la vez y está variable
determina cuál.
•
Ultrasonido: Vector Tipo Entero. Este vector guarda los valores de los detectores
de ultrasonido para objetos, el tamaño del vector depende del número de
ultrasonidos instalados, para este caso 4; puede aceptar valores entre 0 y 255,
interpretados en un rango de 0 a 100%.
•
Batería: Tipo Real. Esta variable acumula el valor de energía estimada de la
batería, este parámetro NO es enviado por el robot (corrección futura en Úrsula),
por el contrario es la única variable de estado calculada con respecto al tiempo que
Orión este conectado con Úrsula, suponiendo una duración de la batería de 2 horas.
•
Aceleración. Tipo Real. Esta variable guarda la cantidad de aceleración (voltaje)
que debe aplicarse en los motores, esta variable acepta valores entre 0 y 100,
interpretados en un rango de 0 a 100%.
4.4.2 Estructura TDirectiva.
Esta estructura se diseñó para manejar las directivas del sistema, se colocó por aparte para
aplicarla en un vector, de esta manera se pueden agregar tantos tipos de directivas como
Úrsula lo exija.
35
Figura 8. Definición de Estructura TDirectiva.
•
Valor. Tipo Entero: Esta variable determina el valor que debe tener la directiva
para aplicar, este valor es 0 de tal manera que cuando Orión se sincronice con
Úrsula, esta no se aplicará.
•
Codigo. Tipo Entero: Esta variable guarda el código con que Úrsula reconoce la
directiva que se va aplicar.
Actualmente las directivas definidas en Orión, son las mismas que Úrsula usaba en el
primer desarrollo de SCAN5, las directivas son instrucciones muy puntuales que el robot
tiene pregrabadas y que ejecuta de forma ordenada, actualmente están reservadas en el
mapa de memoria de datos (ver Descripción General), 5 Tipos de directivas simultáneas y
fueron implementadas las 4 primeras en el software (ver tabla 3).
5
SISTEMA MÓVIL PARA LA DETECCIÓN Y LOCALIZACIÓN DE MINAS ANTIPERSONALES.
Camilo Campo, Javier Coronado, Javier Rizo. Pontificia Universidad Javeriana, 2002
36
Tipo de Directiva
Dirección y control
Azimut
Altitud
Manipulador
Directiva
Avanzar
Retroceder
Girar CCW*
Girar CW*
Posición
Modo Automático
Escanéo
Brazo Mitad
Posición
Brazo Mitad
Max Arriba
Max Abajo
No Definido
Valor
Decímetros
Decímetros
Grados
Grados
Grados
Ninguno
Ninguno
Ninguno
Grados
Ninguno
Ninguno
Ninguno
Ninguno
*CCW: en sentido antihoraio CW: en sentido horario
Tabla 3. Definición de Directivas para el Robot.
La quinta directiva está reservada para futuras implementaciones.
4.4.3 Estructura TRangos.
Esta estructura guarda los límites Inferiores y Superiores de algunos sensores, para la
configuración de los controles visuales que permiten al usuario saber el estado de los
mismos.
Figura 9. Definición de Estructura TRangos.
Estos datos se definieron en una estructura separada para permitir agregar límites a otros
controles que pueden ir apareciendo o algunos existentes que lo requieran. Contiene las
siguientes variables:
37
•
TmpInfMot. Tipo Entero: Usada como límite Inferior de medición para la
temperatura de los motores.
•
TmpSupMot: Tipo Entero: Usada como límite Superior de medición para la
temperatura de los motores.
•
TmpInfAmb. Tipo Entero: Usada como límite Inferior de medición para la
temperatura del Ambiente.
•
UltraInf. Tipo Entero: Usada como límite Inferior de medición para la distancia
registrada por los Ultrasonidos.
•
UltraSup. Tipo Entero: Usada como límite Superior de medición para la distancia
registrada por los Ultrasonidos.
•
UltraTol. Tipo Entero: Usada como punto de tolerancia para determinar que un
objeto se encuentra muy cerca, generando un cambio de color en el aspecto visual.
•
DetectTol. Tipo Entero: Usada como punto de tolerancia para determinar que el
nivel de metal encontrado por el detector es muy alto.
4.4.4 Estructura TMapa.
Esta estructura se diseñó para manejar los datos de ubicación del robot, en un mapa de 2
dimensiones implementado en el formulario telecomando (ver sección Frame Mapa –
Formulario Telecomando). Esta estructura tiene un funcionamiento similar al de la
estructura valores, solo que este no se sincroniza con el módulo de comunicaciones, por el
contrario se alimenta del mismo búfer y solo se activa cuando el interruptor de mapeo en la
ventana telecomando está ON.
38
Figura 10. Definición de Estructura TMapa.
Básicamente la estructura guarda los datos que usarán las funciones del control del dibujo
en la ventana Telecomando, calculados a partir de los datos en la variable Valores del
búfer.
•
x_0, y_0, z_0. Tipo Real: Guarda las coordenadas iniciales o anteriores del robot en
el llamado inmediatamente anterior.
•
x_1, y_1, z_1. Tipo Real: Guarda las coordenadas actuales del robot como punto
final de la línea de construcción, este valor es calculado con la variable phi.
•
phi. Tipo Real: Guarda el ángulo de movimiento de la brújula, ayudando a calcular
el punto de escritura siguiente.
•
lado. Tipo Real: Guarda la proporción del tamaño que debe imprimirse debido al
tamaño total del mapa solicitado al usuario en el inicio del mapeo.
•
Inclinación. Tipo Real: Usada para calcular el ángulo de inclinación del robot para
saber el valor de la coordenada Z y con ello dibujar el color correspondiente.
4.4.5 Clase TComPort.
39
Posiblemente esta sea la estructura más complicada de todo el búfer, de hecho no es una
estructura, es una Clase, una de las más importantes y de mayor cuidado, ya que es la
encargada de conectar el búfer central con el búfer del puerto serial del Computador.
Esta clase no fue diseñada durante el desarrollo de Orión, pertenece a la librería
COMPORT versión 2.64 desarrollado por Dejan Crnila6 para Builder C++™ 6. Esta
herramienta es un componente de comunicación serial de libre distribución (Freewere) y
tiene implementados los controles necesarios para una simple conexión. Adicional a la
clase
principal
TComPort,
esta
librería tiene
también otros controles
como:
ComDataPacket, ComComboBox, ComRadio Group, ComLed, ComTerminal, todos
controles gráficos para conectarse a la clase principal TComPort, sin embargo no se usó
ninguno de ellos, únicamente se incluyó la librería para definir conexión al puerto en el
búfer central.
TComPort es un componente de fácil manejo para comunicarse con dispositivos externos
conectados al puerto RS232 del computador, como módems, lectores de códigos de barras,
PBX, entre otros. Introduce bastantes propiedades para una detallada configuración del
puerto serial, numerosos métodos de escritura y lectura del puerto y eventos para
monitoreo. Tiene operaciones de lectura y escritura que pueden ser sincrónicos y
asincrónicos. Las propiedades derivadas más importantes de la clase y usadas en Orión,
son:
6
Dejan Crnila – Estudiante de ciencias de la computación en la Universidad de Liubliana – Eslovenia.
40
•
BaudRate: Propiedad que representa la velocidad con la cual los caracteres serán
enviados o recibidos por la conexión RS232. Sus valores son de tipo enumerado
están definidos así:
type TBaudRate = (brCustom, br110, br300, br600, br1200, br2400, br4800,
br9600,br14400, br19200, br38400, br56000, br57600, br115200);
•
Connected: determina si el puerto se encuentra abierto o no, si se aplica un valor
verdadero en la propiedad o un valor falso. Es equivalente a usar los métodos Open
y Close, sin embargo cualquier aplicación puede verificar si el puerto está abierto o
no.
•
DataBits: Define el numero de bits en los bytes trasmitidos y recibidos. También es
un tipo de datos enumerado y se define:
type TDataBits = (dbFive, dbSix, dbSeven, dbEight);
•
FlowControl: Propiedad que define el tipo de Control de flujo que se aplica en el
puerto, es un concepto de prevención del búfer del puerto, para evitar que los bytes
recibidos lleguen más rápido que los procesados. Existen básicamente 2 tipos de
control de flujo, de Hardware y Software.
•
Parity: propiedad que permite activar o desactivar la paridad de chequeo,
corrección de error y tipo de paridad.
•
Port: Especifica el número de puerto serial que se usará. Es de tipo String y su
sintaxis es la siguiente: ‘COM<número de puerto>’, si el puerto es cambiado
durante la sesión, el antiguo puerto es cerrado y el nuevo puerto es abierto. También
se puede llamar el procedimiento EnumComPorts () para listar el número de puertos
seriales del computador.
41
•
StopBits: define el número de bits de parada por caracter. Es una variable de tipo
Enumerado y puede tener uno de los siguientes Valores:
type TStopBits = (sbOneStopBit, sbOne5StopBits, sbTwoStopBits);
Los métodos derivados, en orden alfabético, más importantes son:
•
ClearBuffer (Input, Output): El llamado de este método limpia la entrada y/o la
salida del búfer. Tiene como parámetros valores de tipo Boolean, para la entrada y
la salida.
•
Close: Cierra la conexión del puerto serial.
•
Read (Buffer; Count): Integer: Esta función lee un número (count) determinado de
bytes y lo escribe en buffer, variable de tipo string o vector de caracteres. Retorna el
número de bytes que realmente leyó.
•
Write (Buffer; Count): Integer: Esta función escribe desde la variable buffer, el
número de bytes especificado en count, sobre el búfer de salida del puerto. Retorna
el número de bytes que realmente escribió.
4.4.6 Clase TIniFile.
Esta clase está definida en el búfer para conectarse al archivo inicial de Orión y guardar en
este, los valores ya configurados de la estructura Rangos y la configuración de la clase
Port. Este archivo se encuentra en el mismo directorio del archivo ejecutable orion.exe y se
llama orion.ini.
42
TIniFile es capaz de guardar y recuperar de una aplicación específica información y
parámetros de configuración de un archivo INI estándar. Un archivo INI almacena la
información en grupos lógicos, llamados “secciones”, dentro de estas secciones, los datos
son almacenados en campos nombrados y tienen la siguiente estructura:
<nombre del campo> = <valor>
Para el archivo INI de esta aplicación solo se tienen 3 secciones, Puerto, Rangos y Joystick,
almacenados como lo indica la figura 11.
Figura 11. Almacenamiento de los datos en el archivo orion.ini.
Adicionalmente al método constructor de la clase, TIniFIle tiene los siguientes métodos
usados en el proyecto:
43
•
ReadInteger (section, ident, default) Integer: Esta función lee y retorna un valor
entero desde el archivo INI, en la sección determinada en section. La variable ident
determina el campo de la sección que necesita ser devuelto. El parámetro default es
el valor que devuelve la función, si la sección no existe, el campo no existe o no se
ha asignado valor a ese campo.
•
ReadString (section, ident, default) AnsiString: Esta función lee y retorna un valor
String desde el archivo INI, en la sección determinada en section. La variable ident
determina el campo de la sección que necesita ser devuelto. El parámetro default es
el valor que devuelve la función, si la sección no existe, el campo no existe o no se
ha asignado valor a ese campo.
•
WriteInteger (section, ident, value). Esta función escribe el valor determinado en
value, en el archivo INI, dentro de la sección section y el campo ident. En caso de
no encontrar la sección o el campo, la función los crea.
•
WriteString (section, ident, value). Esta función escribe el string determinado en
value, en el archivo INI, dentro de la sección section y el campo ident. En caso de
no encontrar la sección o el campo, la función los crea.
4.4.7 Variables del Búfer Central
Adicionalmente a las estructuras que maneja la clase Úrsula, existen variables públicas que
se usan de manera global para determinar parámetros o estados del Robot.
44
•
Encendido. Tipo Entero: Variable que determina si el Robot se encuentra
conectado o no.
•
Status. Tipo Entero: Variable encarga de identificar el tipo de paquete que se está
trasmitiendo o recibiendo.
•
Perdidos. Tipo Entero: Variable que acumula el número de paquetes perdidos en la
transmisión, si esta variable supera un cierto número definido, cambia el estado del
robot a Apagado.
4.4.8 Funciones de la clase Úrsula.
Para la funcionalidad del búfer central, se definieron varios procedimientos ligados a la
clase, unas públicas y otras privadas. Las funciones privadas se desarrollaron únicamente
para los procedimientos de comunicación serial y construcción de paquetes de transmisión.
Primero se explicarán las funciones públicas y luego se continúa hacia adentro explicando
las restantes.
ª TUrsula ( ): función constructora de la clase, no solamente se encarga de crearla,
adicionalmente, construye las clases tipo TComPort y TIniFile, descargando los
datos del archivo de configuración orion.ini sobre la estructura Rangos y
configuración de la clase ComPort.
ª void ActualizaControles ( ): función encargada de conectar los controles del
formulario de telecomando y las estructuras de la clase Úrsula; evalúa si los
paquetes perdidos permiten una conexión estable. Esta función se verá con
45
profundidad en el capítulo de Administración de Procesos – Actualización de
Instrumentos.
ª void Barrido ( ): función destinada a realizar un barrido automático con la altitud
del brazo, esta función luego se implementó como directiva.
ª void GetData ( ): posiblemente la función más compleja del búfer central, es la
encargada de construir los paquetes de comunicación con los datos que la estructura
valores tiene en ese instante de tiempo, luego envía ese paquete al puerto serial,
conmutando el puerto paralelo para activar las antenas de transmisión, luego recibe
el paquete respuesta y lo evalúa para determinar que tipo de paquete envía en el
siguiente llamado. Todo este proceso se desarrollará con mayor profundidad en la
sección Proceso de Comunicaciones – Administración de procesos.
ª void InitUrsula ( ): inicializa todos los datos del búfer y lo coloca en un estado
inicial de apagado.
ª void MapaReset ( ): inicializa todos los datos de la estructura mapa, usado al
comienzo del mapeo y cuando este termina.
ª void SaveRanges ( ): función dedicada a guardar los datos de las estructuras
ComPort y los rangos de los controladores de datos visuales ABAKUS.
Las funciones privadas de la clase son usadas únicamente por la función GetData:
ª void PaqueteModBus (char Paquete [], short Funcion): este procedimiento
construye un paquete de datos tipo modbus sobre la variable paquete, el tipo de
paquete se determina por la variable Funcion. La definición de protocolo y tipo de
46
paquetes se verán con profundidad en la sección Proceso de Comunicaciones –
Administración de procesos.
ª void ModBusCRC (char Paquete [] ): esta función se encarga de añadir el carácter
de CRC o chequeo que maneja el protocolo ModBus.
4.5 CLASE DM – CONEXIÓN CON LA BASE DE DATOS.
Para seguir con la sección de Almacenamiento y Comunicación, se implementó la clase
TDM, que determina la conexión a la base de datos. La clase DM (Data Module) es un
contenedor centralizado de controles no visuales dentro del proyecto, se utiliza para
contener ventanas de apertura de archivos, listas de imágenes, timers, conexiones a bases de
datos, etc. En este caso se almacenaron 4 clases para el manejo de la base de datos.
Para la conexión a la base de datos se eligió el motor de base de datos ADVANTAGE, la
clase TDataSet de Advantage, es un kit de desarrollo específicamente creado para eliminar
la dependencia del uso de BDE (Borland Database Engine) y dbExpress para bases de datos
Access. Usando esta clase, los desarrolladores pueden programar siempre utilizando
estándares para el manejo de tablas, consultas, procedimientos y métodos almacenados.
Desarrollado por Extended Systems. Inc., Advantage TDataSet es un motor de base de
datos muy usado en Estado Unidos y quiere abrirse a otros mercados, por este motivo y
siendo otra de las grandes ventajas, tiene un licenciamiento gratuito para uso monousuario.
47
Su funcionalidad ya probada por algunas empresas de desarrollo de software colombianas7,
garantiza un muy buen rendimiento en la implementación del proyecto.
Para manejar el almacenamiento de los datos, se implementó el concepto de sesiones, es
decir cada vez que el operario decida guardar los movimientos y estados del robot, creará
una sesión nueva y esta empieza a almacenarse en la base de datos, cada sesión debe tener
un nombre característico que luego usará para recuperar la información y exportarla a una
hoja de calculo de Microsoft Excel®. La manipulabilidad del sistema estaba determinada
por los requerimientos del sistema, por lo tanto se usa el formato de Microsoft Excel®, ya
que es la hoja de cálculo personal más usada en el mundo.
4.5.1 Diseño de base de datos.
Para el manejo de sesiones se diseñaron 2 tablas, una que guarda el encabezado o nombre
de sesión y otra que almacena los datos de las estructuras descritas en el búfer Central, estas
son las tabla session y tramas (ver tabla 4 y tabla 5), cuyo diagrama entidad - relación se ve
en la figura 12.
Tabla session
Nombre
session_id
Tipo
Descripción
Autonumérico Identifica de manera única la session en la base de datos.
title
Carácter
date
Fecha/hora
Almacena el nombre de la session, para que el usuario pueda identificarla.
Almacena la fecha y hora de grabación de la sesión.
Tabla 4. Descripción de campos de la tabla session.
7
Lector Systems Ltda. Implementación en software de tipo jurídico y de estudio de seguridad.
48
Tabla tramas
Nombre
Tipo
Descripción
session_id
Autonumérico
timestamp
Fecha/hora
curso
Entero
Almacena el valor de la brujula.
pitch
Entero
Almacena el valor de inclinación frontal del Robot.
roll
Entero
Almacena el valor de inclinación lateral del Robot.
tempMotor
Entero
Almacena el valor de temperatura de motor del Robot.
tempAmbiente
Entero
Almacena el valor indicado por el termometro ambiental.
velocidad
Entero
Almacena el valor de la velocidad indicado por el Robot.
x
Entero
Almacena el número de millimetros absolutos recorrido por el motor derecho.
y
Entero
Almacena el número de millimetros absolutos recorrido por el motor Izquierdo.
detector
Entero
Almacena el valor actual indicado por el detector de metales.
ultra1
Entero
Almacena el valor actual de ultrasonido # 1.
ultra2
Entero
Almacena el valor actual de ultrasonido # 2.
ultra3
Entero
Almacena el valor actual de ultrasonido # 3.
ultra4
Entero
Almacena el valor actual de ultrasonido # 4.
Identifica cada registro con la session correspondiente.
Almacena el instante de tiempo en que se registra el dato.
Tabla 5. Descripción de campos de tabla tramas.
Figura 12. Diagrama Entidad Relación de la Base de Datos para Orión.
49
4.5.2 Implementación de la Base de Datos en Orión.
Una vez diseñada y construida la base de datos con las herramientas del Advantage Data
Arrquitect y Advantage Data Manager, se diseñaron las tablas dentro del DM, para esto
Extended Systems desarrolló componentes de conexión a la base de datos, tablas o
consultas para los entornos de desarrollo Delphi, Kylix y C++ Builder ™. La jerarquía del
componente se grafica de la figura 13.
Figura 13. Jerarquía del Advantage TDataSet.8
La siguiente es la descripción de las clases definidas en el DM:
8
Advantage TDataSet Descendant for Delphi/Kylix/C++ Builder - Getting Started Guide, Septimbre de 2003.
50
•
TAdsConnection *AdsCon: clase que conecta la base de datos y los controles de
tabla, en este se configuran, el Path donde se encuentra la base de datos, tipo de
conexión, Username y Password. También se pueden definir otros parámetros
adicionales más específicos que se identificaron como estándar ya que el sistema no
requiere configuraciones especiales. El tipo de conección ADS quedó definido
como LOCAL.
•
TAdsTable *tblSession: control que representa la tabla session dentro del programa,
se configura enlazando el parámetro AdsConnection con AdsCon y en la propiedad
TableName se define session.
•
TAdsTable *tblTrama: control que representa la tabla trama dentro del programa,
se configura enlazando el parámetro AdsConnection con AdsCon y en la propiedad
TableName se define tramas.
•
TDataSource *srcSession: este control se usa en el formulario de exportación de
datos para conectar la grilla y visualizar las sesiones previamente guardas, pero esto
se verá con más detalle en el módulo de entorno al usuario.
La única función creada diferente a la constructora es:
•
void DataModuleCreate ( TObject *Sender): esta función se encarga de definir el
path de la base de datos, extrayendo esta del path del proyecto.
51
Las conexiones con la base de datos solamente ocurren cuando se habilita el interruptor de
grabación en el formulario de Telecomando, en ese momento se hace activa la conexión a
la tabla de tramas y se comienza a almacenar.
4.6 CLASE DMJOYSTICK.
Esta clase se basa en el mismo principio de la clase anterior, tambien es un Data Module,
con las mismas características del implementado para la conexión a la base de datos, pero
con un solo control especial. El objetivo principal de está clase es conectar los instrumentos
actuadores del sistema a un Joystick Standard conectado al sistema operativo, para esto se
usa el componente Joystick 1.2 desarrollado por Winsoft Ltd.9, en su versión trial. Esta
versión está disponible para entornos de desarrollo Delphi 5,6 y 7 y C++ Builder 4,5 y 6.
Su ventaja principal es que está basado en Joystick Estándar API de Windows, permitiendo
utilizar un controlador de juego que sea reconocido por el sistema operativo. Para el
desarrollo de Orión se utilizó el Game Controller para PC, GENIUS MaxFire G-08XU,
con 8 Botones y conector USB.
Esta estructura solo se crea o activa si el operador lo establece en el formulario de
Configuración de Controles del menú principal. Este controlador solamente tiene definidas
2 funciones principales:
9
Winsoft Ltd. http://www.winsoft.sk.
52
•
void Joystick1ButtonDown ( TObject *Sender, TButtons Changed, TButtons
Pressed, int X, int Y): Este evento se ejecuta cuando cualquiera de los 4 primeros
botones es presionado, la variable Pressed contiene el botón que se presionó y en la
función se determina la acción correspondiente, en la sección Formulario
Telecomando – Frame Control Manual se define la relación Botón – Actuador.
•
void Joystick1Move ( TObject *Sender, TButtons Changed, TButtons Pressed, int
X, int Y): Este evento se ejecuta cuando es movido cualquiera de los ejes del Game
Controller, las variables X y Y, determinan cuanto se movieron cualquier de los ejes
y la función determina la acción correspondiente, en la sección Formulario
Telecomando – Frame Control Manual se define la relación Eje – Actuador.
4.7 LIBRERÍA IO.DLL
Por último, lo único que queda por definir en la sección de almacenamiento y
comunicación es la conexión con el puerto paralelo, como se presentó en los requerimientos
del sistema, los dispositivos de conexión inalámbrica necesitan 2 pines que conmutan la
funcionalidad del canal, debido a su característica half duplex, por ello se usa el puerto
paralelo, escribiendo 2 números en el puerto y en caso de tener inactivo se envía el 0, a
diferencia del puerto serial el paralelo es mucho más fácil de manejar.
53
IO.DLL es la librería inventada por Fred Bulback en el año de 2002, disponible
gratuitamente en Geek HideOut10, esta tiene un conjunto muy útil de comandos y funciones
compatibles con Windows® 95/98/ME y NT/2000/XP, sin necesidad de escribir en código
Assembler o que interactúe con los controladores a nivel de Kernel, de esta forma se
aseguró el funcionamiento de Orión en cualquier sistema operativo Windows®. Esta
librería está disponible para Visual C++, Borland C++, Delphi o Visual Basic. De esta
librería solamente se implementó la siguiente función:
•
void PortOut (short int Port, char Data): esta función tiene la propiedad de colocar
el byte Data, en el puerto paralelo, la salida del puerto se determina por la variable
Port, equivalente al número de puerto que usa el sistema operativo, para el caso del
sistema Windows el puerto LPT1 equivale a 888 o 0x0378, que se puede comprobar
en la configuración de recursos de las propiedades del sistema.
Esta función es utilizada antes de usar la clase TComPort en el búfer central, de la
siguiente manera:
# 0: Inhabilita los módulos de transmisión.
# 1: Configura los módulos de comunicación en transmisión.
# 2: Configura los módulos de comunicación en recepción.
Teniendo en cuenta que la velocidad con que se activan esos pines es inmediata, con
respecto a la conmutación de los módulos, que necesitan 8 ms como mínimo para cambiar
10
http://www.geekhideout.com/iodll.shtml. Geek Hideout – Programming to the Metal.
54
de un estado a otro y poder transmitir con éxito11. Para ello se usa la función Sleep que
retarda la ejecución del programa unos milisegundos, su sintaxis es:
void Sleep(unsigned milliseconds).
Ya una vez definidos todas las herramientas de almacenamiento y Comunicación, se puede
describir el entorno y la interfaz con el usuarioy cómo ésta interactúa con lo componentes
descritos anteriormente.
4.8 DISEÑO DE NAVEGACIÓN E INTERFAZ DEL SISTEMA.
Para que el sistema Orión tenga éxito, es importante contar con un buen diseño de la
interfaz de usuario. En el mejor de los casos, una interfaz difícil de utilizar provocará que
los usuarios cometan muchos errores. En el peor de los casos, los usuarios simplemente se
rehusarán a utilizar el sistema de software sin tomar en cuenta su funcionalidad. Si la
información se presenta de una forma confusa o engañosa, los usuarios no comprenderán el
significado de de la información, algo que puede llegar a ser realmente crítico en este
proyecto, sobre todo porque puede provocar que se genere una serie de acciones que causen
fallas en el sistema o la misma pérdida del robot.
Actualmente, la gran población citadina tienen acceso a una computadora personal, estas
computadoras proveen una GUI (interfaz gráfica de usuario) que permite el despliegue en
color de alta resolución e interacción utilizando tanto el ratón como el teclado, sin embargo
11
SC-PA SERIES TRANSCEIVER MODULE DESIGN GUIDE – Linx Technologies. Página 2.
55
con Orión se tiene que ir un poco más allá, se debe recordar que uno de los requerimientos
es la manipulación de ciertos controles principales con un joystick o Game controller.
La GUI que se debe que diseñar o implementar debe tener las siguientes características
principales, dada la particularidad de este proyecto y de la aplicación realizada en robótica
móvil:
1. Debe ser relativamente fácil de aprender y utilizar. Los usuarios sin experiencia en
computación deben aprender a utilizar la interfaz después de una sesión breve de
capacitación.
2. Para interactuar con el sistema, los usuarios deben contar con pantallas múltiples
(ventanas). Es muy importante ir de una tarea a otra sin perder de vista la
información generada.
3. Es posible interactuar rápidamente y tener acceso inmediato a cualquier punto de la
pantalla.
En una interfaz como la que tiene el sistema Orión, las personas pueden olvidar
rápidamente y cometer varios errores, ya que se encuentran bombardeados de mucha
información y están bajo presión. Para esto Shneiderman12 propuso una lista de principios
de diseño de interfaz de usuario, para aprovechar las habilidades humanas:
•
Familiaridad del Usuario: La interfaz debe utilizar términos y conceptos que se
toman de la experiencia de las personas que más utilizan el sistema.
12
SHNEIDERMAN, B. (1998). Designing the User Interface, 3rd edn. Addison-Wesley.
56
•
Consistencia: Siempre que sea posible, la interfaz debe ser consistente en el sentido
de que las operaciones comparables se activan de la misma forma.
•
Mínima Sorpresa: el comportamiento del sistema no debe provocar sorpresa a los
usuarios, las acciones comparables deben tener efectos comparables.
•
Recuperabilidad: La interfaz debe incluir mecanismos para permitir a los usuarios
recuperarse de los errores.
•
Guía al usuario: Cuando los errores ocurren, la interfaz debe proveer
retroalimentación significativa y características de ayuda sensible al contexto.
•
Diversidad de Usuarios: La interfaz debe proveer características de interacción
apropiada para los diferentes tipos de usuarios del sistema.
4.9 FORMULARIO PRINCIPAL O MAIN FORM.
Teniendo en cuenta estos parámetros y también, sabiendo la escalabilidad que debe tener el
sistema se diseñó un esquema de formulario principal (main form). Este se encarga de
llamar a los demás formularios en caso de necesitar alguna función específica. El operador
básicamente puede realizar 3 acciones: Configuración, consulta o exportación y
Teleoperación.
Todos se distribuyeron en los menús principales Configuración, Acciones y Consulta. El
menú adicional Acerca de es solo informativo. Una vez se ejecuta el programa conduce al
menú principal (ver figura 14).
57
Figura 14. Formulario principal o Main Form.
4.9.1 Menú Configuración.
El menú configuración se encarga de ejecutar funciones de configuración del puerto y de
los rangos de variación de los instrumentos gráficos usados para describir los datos del
Robot. El menú Configuración tiene 3 funciones como se ve en la figura 15.
58
Figura 15. Funciones del Menú Configuración.
Configurar controles (Ver figura 16) se encarga de modificar todos los parámetros que usa
el formulario de telecomando, basado en los rangos que pueden manejar los sensores y
actuadores del robot.
Figura 16. Formulario de Configuraciones de Rangos.
Este formulario se llama frmConfig y básicamente lee del archivo ini los datos de
configuración inicial, por medio de la clase TIniFile implementada en el búfer central,
luego guarda esta información en la estructura rangos para que cuando se cargue el
formulario de telecomando, los rangos de los instrumentos, sean adecuados y coherentes
con los datos que está enviando el robot, adicionalmente le indica al formulario
Telecomando que puede o no activar el DM del Joystick.
59
La siguiente opción del menú Configuración es configurar puerto (Ver figura 17).
Figura 17. Formulario Configuración de Puerto.
El nombre del formulario es frmSettings y se encarga de administrar los parámetros del
puerto serial, en sus aspectos básicos. Estos parámetros se cargan y se guardan en el
archivo ini del programa y luego son asignados a la clase TComPort del búfer Central,
encargada de manejar el puerto serial como se vió en el capítulo anterior. Este formulario
también configura el número de paquetes perdidos máximo que debe tener la conexión para
considerarse perdida.
Por último se tiene la función salir, que como su nombre lo dice, detiene la ejecución del
sistema Orión. Esta operación solo se ejecuta con aprobación de la ventana de
confirmación, aplicando el principio de Recuperabilidad que se mencionó en el diseño de
interfaz del sistema.
60
4.9.2 Menú Acciones.
Este menú se encarga de agrupar las funciones que mantienen algún tipo de acción directa
sobre el robot.
Figura 18. Funciones del menú Acciones.
En este momento solo está configurada la función Telecomando, encargada de activar el
formulario de telecomando para la manipulación del sistema móvil, este menú se desarrolló
teniendo en cuenta evoluciones futuras, uno de los requerimientos principales del grupo de
desarrollo de Úrsula. En la siguiente sección se mencionará el desarrollo del formulario
Telecomando, ya que es el más complejo del proyecto.
4.9.3 Menú Consulta
Este menú agrupa todas las funciones de consulta y exportación de datos, muestra de
informes, etc.
Figura 19. Funciones del menú Consulta.
Actualmente solo se desarrollaron la gestión de sesiones, pero para futuras
implementaciones se pueden agregar otro tipo de opciones como análisis de tendencias,
gráficos, etc. Gestión de sesiones, activa el formulario de sesiones, llamado
61
SessionMgmtDlg (Figura 20). Este formulario se encarga de manipular y exportar las
sesiones previamente guardadas en el formulario Telecomando.
Figura 20. Formulario Gestión de Sesiones.
Una vez activado el formulario, el sistema carga las sesiones que se encuentran en la base
de datos y las almacena en la grilla de “sesiones guardadas”. El formulario permite
exportar, editar o borrar una sesión según el comportamiento sobre la grilla:
•
Exportar Sesión: realizando doble click en la sesión correspondiente, el sistema
confirmara el deseo de exportar la sesión llamada “nombre de la sesión”, luego de
afirmar la exportación, aparecerá un cuadro de dialogo guardar como (Figura 21),
para que el usuario elija el lugar donde guardará el archivo de Excel con la
62
información correspondiente a la sesión. Posteriormente el usuario podrá manipular
los datos como se solicitó en los requerimientos del sistema.
Figura 21.Ventana de diálogo Guardar como de la Gestión de Sesiones.
Luego el sistema confirma el éxito de la exportación de datos al archivo de Excel.
El archivo de Excel guarda el registro de datos de la correspondiente sesión en una
única hoja de cálculo, almacenando los valores que la estructura valores del búfer
central, contiene en el momento en que el timer se ejecuta. Los datos almacenados
en su orden son:
63
1. Curso.
2. Pitch.
3. Roll.
4. Temperatura de Motor.
5. Temperatura Ambiente.
6. Velocidad.
7. Valor de X.
8. Valor de Y.
9. Nivel Detector.
10. Ultrasonido 1.
11. Ultrasonido 2.
12. Ultrasonido 3.
13. Ultrasonido 4.
En la primera columna del archivo se guarda el momento (fecha y hora), extraída
del computador donde se está ejecutando el sistema Orión. La tasa de grabación es
igual a la tasa de transmisión con el robot, por lo tanto se debe tener en cuenta los
tiempos de grabación, en la sección de administración de procesos, se verá como
grabar los datos en intervalos de tiempo específicos.
•
Editar Registro: Para editar el nombre de una sesión, simplemente se selecciona la
sesión que se quiere editar, luego se presiona la tecla F2 y se realiza la edición, el
símbolo lateral izquierdo se convertirá de
a
, indicando que se realizó una
modificación del registro y solo será aplicado a la base de datos una vez el símbolo
retorne a su imagen original, esto se logra moviéndose hacia arriba o hacia abajo
dentro de la grilla. Una vez eso suceda el registro queda editado.
•
Eliminar Registro: Para eliminar un registro, simplemente se selecciona de la grilla
y se presiona de forma combinada las teclas <CTRL> y <SUPR> o para teclados en
inglés <CTRL> y <DEL>.
64
Para salir del formulario de gestión de sesiones y volver al menú principal, simplemente se
hace click sobre el botón OK.
El sistema permite guardar cuantas sesiones se necesiten, mientras exista espacio en disco
duro, los espacios de grabación también pueden ser muy extensos, sin embargo en el
momento de superar 4 horas y media, se aproxima a 65500 registros y se debe recordar que
Excel, solo puede manejar 65532 filas en su programa, por lo tanto se tendrían
inconvenientes. Para esto se pueden aplicar 2 soluciones; si la sesión de grabación supera
las 4 horas se hacen múltiples sesiones y luego se analizan de forma independiente, pero si
se requiere analizar todo el tiempo grabado, se exporta la sesión y luego se carga en otro
motor de base de datos como Access, teniendo en cuenta que usan el formato de archivos
planos separados por tabuladores, este formato busca darle uso universal a los datos
exportados desde la IHM Orión.
Luego de analizar los diferentes menús del formulario principal, se puede determinar que el
sistema queda abierto a futuros desarrollos, garantizando posibilidades de organizar y
clasificar no solo las funciones existentes, si no también las que se piensan desarrollar en un
futuro.
4.10 FORMULARIO TELECOMANDO
Es el formulario más complejo de todo el sistema, su objetivo principal es controlar,
supervisar, administrar y generar información del móvil y el operador. No solo activa los
65
parámetros de sincronización del búfer con los puertos, evalúa condiciones de estado del
robot, conecta al usuario con el robot de manera visual, identificando situaciones de riesgo.
Es el encargado de convertir todo el proceso digital de tele-operación en lenguaje humano y
activa la teleoperación a través de controles de juego o Joystick.
Figura 22. Formulario Telecomando.
Como se puede observar en la Figura 22, el formulario consta de varios controles o
instrumentos visuales que ayudan al operador a estar al tanto del estado del robot. Los
controles implementados pertenecen a un paquete de instrumentos gráficos llamados
66
Abakus VCL versión 2.5.0.4, desarrollados por A.Baecker Hard & Software13; esta
versión trial del paquete incluye diferentes tipos de instrumentos para diferentes versiones
de entornos de desarrollo, por obvias razones se usó la creada para C++ Builder 6 ™.
Cuando se activa el formulario, el sistema crea el búfer central, este a su vez carga las
estructuras de rango y configuración del puerto serial, desde archivo orion.ini con la clase
TIniFile, por último activa el puerto serial asignado. Por su parte, el formulario
telecomando asigna los respectivos rangos a los controles visuales e inicializa los valores
del búfer central y los instrumentos, si es necesario, activa el formulario DMJoystick para
manipulación del operador con Controladores de Juego.
El formulario telecomando tiene divididas sus secciones con frames, cada uno de ellos tiene
funciones específicas y ubican al operador en un tipo de sensor o actuador específico. Los
despliegues analógicos continuos dan al usuario una sensación del valor relativo, por lo
tanto se trató de utilizar al máximo este tipo de instrumentos, la información que casi no
cambia se puede representar textualmente, ocupa menos espacio pero no se puede leer en
una sola pasada. La información en relieve y que representa la sensación del dato a mostrar
ayuda a una rápida comprensión de la pantalla, sobretodo cuando se entregan al operador
muchos datos al mismo tiempo y este tiene que tomar decisiones rápidamente.
El color puede mejorar la interfaz de usuario ayudando a los usuarios a comprender y
manejar la complejidad. Sin embargo, es muy fácil utilizar el color de forma errónea para
13
A.Baecker Hard & Software. Hauptstr. 137. 63773 Goldbach. Germany. http:\\www.AbakusVCL.com.de
67
crear interfaz de usuario poco atractivas y propensas a errores. Como principio general, los
diseñadores de interfaz de usuario son conservadores en la utilización del color para los
despliegues de información. Shneiderman14 propone lineamientos claves para la utilización
efectiva del color en la interfaz de usuario. Las más representativas aplicadas en Orión son:
•
Limitar el número de colores utilizados y ser conservador al momento de utilizarlos.
•
Utilizar un cambio de color para mostrar un cambio en el estado del sistema.
•
Utilizar el código de colores para apoyar la tarea que los usuarios están tratando de
llevar a cabo.
•
Utilizar el código de colores de una forma consciente y consistente.
•
Ser cuidadoso al usar pares de colores.
A continuación se realizará una descripción de cada uno de los frames del formulario.
4.10.1 Frame Control Principal.
Figura 23. Frame Control Principal
14
SHNEIDERMAN, B. (1998). Designing the User Interface, 3rd edn. Addison-Wesley.
68
Este módulo se encarga de activar o desactivar funciones importantes de la interfaz,
contiene 3 interruptores y un LED de estado, el interruptor más grande controla la conexión
de Orión con Úrsula, activa el timer encargado de sincronizar todas las funciones del búfer
central con los demás módulos, en intervalos de tiempo específicos, entre otros envía y
recibe datos por el puerto serial, actualiza los valores de los instrumentos con los datos que
el búfer central “recogió” del puerto serial; el segundo interruptor, activa el sistema de
mapeo gráfico, este sistema requiere de unos parámetros de configuración que son
solicitados en el instante en que este se activa el interruptor; por último el tercer interruptor
solicita un nombre de sesión y comienza a registrar los valores del búfer central en la base
de datos. El LED de estado puede tener 3 aspectos
•
Apagado: el sistema Orión no está enviando paquetes a Úrsula, el interruptor
principal está OFF.
•
Conectado: El sistema Orión está enviando y recibiendo paquetes a Úrsula, el
número consecutivo de paquetes perdidos es menor a 10.
•
Desconectado: El sistema Orión no encuentra Úrsula, de forma intermitente
manifiesta que el número consecutivo de paquetes perdidos es superior a 10 e
inferior al límite establecido en el formulario de configuración.
Los intervalos de sincronización los determina el timer del formulario, como se verá en este
capítulo.
69
4.10.2 Frame Batería
Figura 24. Frame Batería.
La barra indica la cantidad aproximada de energía que tiene el móvil, este parámetro
actualmente no se mide en el robot, se calcula con base al tiempo que Orión y Úrsula duran
conectados. Este dato se maneja en porcentaje y se inicializa en el momento de activar el
formulario telecomando desde el menú principal, la tasa de consumo se divide en dos tipos,
cuando está en movimiento y solamente cuando está conectado pero quieto. En movimiento
la batería del robot dura 2 horas y si se encuentra encendido pero no está en movimiento
100 horas, según las pruebas realizadas por el grupo de desarrollo de Úrsula.
4.10.3 Frame Detector
Figura 25. Frame Detector
70
Este frame contiene un control de tipo barra igual al usado en frame batería, el valor
registrado es leído por el detector y enviado en la trama de comunicaciones (ver capítulo
Administración de Procesos – Proceso de Comunicaciones), la trama envía un valor entre 0
255 y se realiza la respectiva conversión para pasarlo a porcentaje. El valor de tolerancia es
asignado en el formulario de configuración de controles, del menú principal, si este valor de
tolerancia es superado, el robot se detiene y cambia el color del indicador a Rojo.
4.10.4 Frame Temperatura
Figura 26. Frame Temperatura.
Este frame se encarga de ilustrar las medidas de los termómetros instalados en Úrsula, sus
rangos máximos y mínimos se pueden ajustar en el formulario configurar controles. La
trama usa 1 byte para cada registro de temperatura, la relación de información es uno a uno,
con una diferencia de -2 grados centígrados, por lo tanto los rangos de valores posibles
trasmitidos son de -2 ºC a 253 ºC.
71
4.10.5 Frame Ultrasonido
Figura 27. Frame Ultrasonido.
Los indicadores del frame ultrasonido, presentan en cm la distancia marcada de un objeto
cercano, los rangos de estos instrumentos se configuran en el formulario configurar
controles. Este rango define la relación del byte que llega en la trama, para cada
ultrasonido, con respecto al máximo y mínimo configurado, de tal manera que si los rangos
son 0 y 80 cms, el dato en la trama indica que 255 es 80 cms.
4.10.6 Frame Brújula, Pitch y Roll
Figura 28. Frame Brújula Pitch y Roll.
72
Este frame maneja 3 datos diferentes al mismo tiempo, con un mismo instrumento, primero
el parámetro que se conoce en la trama como curso, se aplica a la sección azul es la
interpretación gráfica de la brújula, sus parámetros se alinean al sistema Cardinal y la
representación en la trama está dada en 2 bytes. La relación de datos es 1 a 1, es decir dato
por grado centígrado, desde -180º a 180 º (de South – West – North – East – South), son
necesarios 2 bytes ya que solo se puede representar 255º con uno solo.
El segundo parámetro que se visualiza es la inclinación frontal o Pitch, luego de ser medida
por el robot se envía en la trama con un byte, la relación de datos también es 1 por grado,
con un desplazamiento de -90º y un valor máximo de 90º, es decir, el byte de la trama no
puede tener un valor superior a 180 que será interpretado por Orión como 90º. Este valor
será representado en la parte central del instrumento, la franja verde indica el nivel de
terreno y las divisiones grises representan inclinaciones de 2 grados.
El tercer parámetro que maneja el instrumento es la inclinación lateral o Roll, este dato
también está representado en la trama con 1 byte y la relación de dato también es de 1 por
grado con el mismo desplazamiento del anterior -90º y 90º. Adicionalmente a la
herramienta gráfica del centro del instrumento, el Roll se ve representado en la zona
vinotinto inferior, ilustrando el número de grados de inclinación lateral. Las subdivisiones
representan pasos de 5 grados.
Los 3 parámetros descritos anteriormente se ilustran numéricamente en los campos laterales
del instrumento.
73
4.10.7 Frame Velocidad.
Figura 29. Frame Velocidad.
El parámetro de velocidad no es un valor calculado por el sistema Orión, este lo determina
el robot y lo envía en la trama de comunicaciones, usando 2 bytesy cada unidad representa
un milímetro por segundo, es decir se pueden representar con los 2 bytes 65536 mm/seg.
4.10.8 Frame Mapa
Figura 30. Frame Mapa
Este es el frame más interesante del formulario y del proyecto. Como se vio en el frame de
control principal, existe un switch o interruptor que activa el funcionamiento del mapa.
74
Una vez activado el sistema de mapeo, el programa solicita al operador los datos de inicio
básicos con el siguiente formulario:
Figura 31. Solicitud de parámetros del mapa.
Estos parámetros determinan la escala de impresión en el mapa del frame mapa, la
dimensión del sitio es el valor máximo de terreno que se va a barrer en metros, esto
determina el tamaño que debe tener el símbolo que representa Úrsula, este sistema usa los
mismos códigos de color de la cartografía de mapas, en cuanto a la representación de la
altura, en intervalos de grados de 0.5 metros como se puede ver en la figura 30. Nivel
inicial es el parámetro que elige el operador para iniciar el dibujo según su propia
perspectiva del terreno, es decir si se esta en la cima de una colina, lo iniciará en el nivel
más alto de esta manera se podrá aprovechar al máximo la gama de colores. La posición
inicial es simplemente la esquina inferior que elige para barrer el terreno, ya que puede
hacerlo de izquierda a derecha o viceversa.
Luego el sistema toma los valores del búfer central para calcular las posiciones en el mapa,
registra la posición inmediatamente anterior, el movimiento de los motores, la variación de
la brújula y la inclinación frontal o pitch y así calcula las coordenadas X y Y de dibujo y el
color. El botón que se encuentra en el costado derecho es usado para borrar el tablero.
75
El mapeo del terreno se realiza con la misma frecuencia con la que se realiza la
actualización de controles y la lectura de datos del búfer.
4.10.9 Frame Control Manual.
Figura 32. Frame Control Manual.
Una vez recibida la información de estado del robot, el frame de control manual permite
manipular el robot en sus funciones más básicas, movimiento de la plataforma móvil y
movimiento del brazo. Como se ve en la figura 32, el control manual se divide en 2
secciones principales, las relacionadas con el movimiento de la plataforma (Aceleración y
Caja) y las relacionadas con el brazo detector (Altitud Azimut Manipulador).
El Movimiento de la plataforma es muy simple, en el búfer existe una variable que registra
el valor de la “caja”, este es interpretado en el robot como polarización en los 2 motores de
tracción, esta variable puede tomar 5 estados posibles:
76
•
Neutro: Estado en que la plataforma móvil está detenida, no se aplica voltaje en los
motores.
•
Adelante: Estado de movimiento frontal, la polaridad del voltaje en el motor
derecho se aplica igual que en el izquierdo y la intensidad se determina por el valor
del indicador Aceleración.
•
Retroceder. Estado de movimiento opuesto, la polaridad del voltaje aplicado en los
motores es igual en ambos pero inverso al aplicado en el estado anterior, la
intensidad se determina por el valor del indicador Aceleración.
•
Derecha. Estado de movimiento a la derecha, la polaridad del voltaje aplicado en el
motor derecho es inverso al del izquierdo, generando un movimiento rotacional en
la plataforma hacia la derecha, la intensidad del voltaje es máxima y se omite el
valor de la aceleración.
•
Izquierda. Estado de movimiento a la izquierda, la polaridad del voltaje aplicado es
el motor derecho es inverso al izquierdo en turnos diferentes al aplicado en el estado
anterior, generando un movimiento rotacional en la plataforma hacia la izquierda, la
intensidad del voltaje es máxima y se omite el valor de la aceleración.
El movimiento del brazo está distribuido en los 3 indicadores izquierdos que aparecen en el
frame de control manual, cada uno está relacionado con los ejes del brazo y cada eje tiene
sus variaciones en diferentes rangos, Altitud de -45ºC a 45ºC, Azimut de -90ºC a 90ºC y
Brazo manipulador del detector de -90ºC a 90ºC.
77
El movimiento de cada eje y de la aceleración es turnado, no está activo para los cuatro
indicadores al tiempo, es decir, el movimiento de la plataforma y el brazo no es simultáneo
desde el control manual, está circunstancia permite una óptima utilización del joystick para
usar solamente 4 botones que también están implementados en 4 botones del teclado.
La configuración de movimiento desde el teclado y el joystick para control manual se
define en la tabla 6.
Función
Caja en Estado Neutro
Caja en Estado Adelante
Caja en Estado Retroceder
Caja en Estado Derecha
Caja en Estado Izquierda
Seleccionar Aceleración Eje
Aumentar valor Eje o Aceleración
Disminuir valor Eje o Aceleración
Teclado
5 numpad
8 numpad
2 numpad
6 numpad
4 numpad
tecla Q
tecla A
tecla Z
Joystick
Botón 1
Eje Y - Adelante
Eje Y - Atrás
Eje X - Derecha
Eje X - Izquierda
Botón 3
Botón 4
Botón 2
Tabla 6. Configuración del teclado y Joystick para Control Manual.
El botón de selección activa de manera secuencial el eje que se va a mover o el indicador de
aceleración para incrementar o disminuir la intensidad del voltaje aplicado.
Estos parámetros actuadores son enviados en la trama de comunicaciones, con 6 bytes que
tienen asignados, para cada uno de los siguientes datos del búfer central dentro de la
estructura Valores: Dirección, Aceleración, Brazo Azimut, Brazo Altitud, Brazo
Manipulador, Brazo Extra (no implementado en el Robot ni en el formulario, pero si en
proceso de comunicación y en el mapa de memoria). Todo los datos tienen relación 1 a 1
con las variables del búfer, para la dirección se definieron constantes que se vieron en el
capítulo Clase Úrsula.
78
4.10.10
Frame Manejo de Directivas.
Figura 33. Frame Manejo de Directivas.
Este frame de control especial, soporta al frame anterior con respecto a la manipulación de
la plataforma (Ver Figura 33). El robot tiene definidas varias directivas que se vieron en el
capítulo Clase Úrsula – Estructura TDirectivas (Tabla 3). Este módulo permite registrarlas
en el momento que se presiona el botón enviar, se escriben código y valor de cada una de
las 4 directivas, en los respectivos bytes asignados en la siguiente trama que se transmita al
robot. Esta instrucción se repite hasta que el robot envíe un paquete de aceptación (ver
detalle Capítulo Administración de Procesos – Proceso de Comunicación).
La directiva de manipulador, todavía no está definida por el grupo de trabajo del robot,
como se explicó en los capítulos anteriores, una vez el grupo la defina, solamente se
agregan a la lista de directivas del ComboBox correspondiente ya que toda la
implementación en el proceso de comunicaciones y actualización de controles está
realizada.
La única parte importante que no se ha descrito en el formulario Telecomando es el Timer,
pero este ser manejará con detalle en el siguiente Capítulo.
79
4.11 ADMINISTRACIÓN DE PROCESOS.
Ya definidas todas las herramientas, clases, estructuras, variables y formularios del sistema
Interfaz Hombre – Maquina Orión, solo queda definir el “libreto”, cuando se deben realizar
los diferentes procesos, ya que el manejo de tiempos es crítico en este Proyecto. En el
desarrollo actual de Orión existen 2 estados o acciones principales que un operador puede
realizar: configuración o consulta y Teleoperación.
Para la configuración o consulta existen los formularios respectivos, explicados
anteriormente, todos funcionan de manera independiente y el sistema no permite que se
ejecuten 2 acciones al mismo tiempo, ej: si el operador está consultando una sesión
previamente guardada, no podrá configurar los instrumentos o los parámetros del puerto de
comunicaciones y viceversa. Así mismo no podrá activar el formulario telecomando, todo
debe estar definido para que el operador pueda disponerse a tele-operar el robot.
Cuando se activa el formulario Telecomando, el sistema crea el búfer central, este a su vez
carga las estructuras de rango y configuración del puerto serial, desde archivo orion.ini con
la clase TIniFile, por último activa el puerto serial asignado. Por su parte el formulario
telecomando asigna los respectivos rangos a los controles visuales e inicializa los valores
del búfer central y los instrumentos, si es necesario, activa el formulario DMJoystick para
manipulación del operador con Controladores de Juego.
80
En este instante, todo queda listo para iniciar una sincronización con el robot. El búfer
central debe realizar de manera sincronizada y repetitiva varios procesos para atender al
robot y al operador, por ello se implementó un timer en el formulario Telecomando, que se
activa una vez cambie de estado el interruptor Encendido del frame Control Principal. Este
timer está configurado para ejecutarse cada 250 ms (ver Requerimientos del sistema) y es el
encargado de ejecutar los procesos globales que conectan al búfer central con los demás
módulos del sistema, en su orden los procesos que se ejecutan son:
1. Proceso de Comunicación
2. Actualización de Instrumentos.
3. Proceso de Registro en la Base de Datos.
4.11.1 Proceso de Comunicación – Sincronización Orión Úrsula.
Este proceso se encarga de sincronizar el búfer central con Úrsula, enviando y recibiendo
datos por el puerto de comunicaciones. Para ello Úrsula tiene implementada una función
pública llamada GetData, mencionada en la definición de la clase Úrsula.
Para poder comunicar la interfaz con la plataforma, no solo se debe garantizar el
funcionamiento del canal, adicionalmente se debe acordar un lenguaje o protocolo común,
para así interpretar lo mensajes que se envían mutuamente. Para ello el grupo de robótica
encargado del desarrollo e implementación de Úrsula, definió usar el protocolo de
comunicaciones Modbus Protocol, desarrollado por Modicon Inc.
81
Este protocolo define tipos de mensajes y respuestas de estos independientemente de la red
de comunicación que se use. El protocolo Modbus aplica básicamente el principio de
relación Maestro – Esclavo, que se implementó en Orión-Úrsula. Este principio se
implementa en la generación de ciclo de consulta – Respuesta.
Figura 34. Relación Esclavo Maestro - Ciclo de Consulta Respuesta.15
El paquete Consulta tiene un código que le indica al esclavo cuál es la función que debe
realizar con los datos enviados, luego el esclavo envía un paquete respuesta con el mismo
código confirmando la correcta interpretación del paquete consulta y enviando datos si es
necesario. Si ocurre un error en la transmisión, los códigos de las funciones no son iguales
y por lo tanto el proceso vuelve a iniciarse.
15
Modicon Modbus Protocol Referente Guide, junio de 1996.
82
Existen 2 modos de transmisión serial: ASCII y RTU (Remote Terminal Unit). La elección
del modo se basa en el tipo de datos que se van a transmitir, también en aspectos como
parámetros de configuración del canal serial (Baud Rate, Paridad, etc.). El modo y los
parámetros de configuración serial deben ser iguales para todos los dispositivos que estén
conectados al canal de comunicación.
Para la comunicación Orión – Úrsula se implementó el protocolo Modbus Modo RTU, ya
que es un protocolo avanzado y la transmisión de nuestros datos se basa en números, dentro
de bytes y no en caracteres como ocurriría con el modo ASCII.
En el RTU Mode, los paquetes comienzan y terminan con intervalos de silencio, luego el
primer campo enviado es la dirección del dispositivo que debe aplicar la función, luego
envío el código de la función que el dispositivo debe implementar, ahora siguen los datos
que debe usar para ejecutar la función y por último 2 bytes de verificación de error.
Tabla 7. Trama General de un Paquete Modbus modo RTU.16
El valor de los Bytes de verificación son el resultado de una función recursiva calculada a
partir del contenido del paquete, el resultado de 16 bits se escribe primero el byte Low y
por último el byte Hi del calculo del CRC.
16
Modicon Modbus Protocol Referente Guide, junio de 1996.
83
Dadas las condiciones del canal y la capacidad de procesamiento de la plataforma, no solo
se implementó el sistema de encabezado de silencio y el CRC, sino que se modificó el
protocolo Modbus modo RTU por 3 banderas de inicio (63 – 51 – 23) y fin (23 – 51 – 63),
así para reconocer un paquete que se encuentre en el canal, en lugar de los 4 tiempos de
silencio, Orión buscará 3 banderas definidas en su orden, luego la dirección o código del
robot, que para este caso es 01 ya que no hay más robot implementados, luego el código de
la función que quiero que ejecute y los datos respectivos, al final coloca la misma bandera
pero en sentido inverso.
Modbus tiene definidos 24 funciones para sus diferentes dispositivos, para el sistema
Hombre – Máquina solamente se usaron 2:
•
16 (10 Hex) Preset Multiple Registers: Esta función obliga al sistema esclavo, en
este caso la plataforma móvil, a escribir en un rango de memoria especificado, los
datos que están en el paquete. Esta función requiere un tipo de paquete respuesta
con la dirección donde escribió y el número de registros que escribió.
•
04 Read Input Registers: Esta función solicita del sistema esclavo los datos de un
rango de memoria especificado. El paquete respuesta 04 tiene el número de
registros leídos - enviados y a continuación todos los datos correspondientes a estos.
Para identificar y construir los paquetes dentro del sistema Orión, se le definieron números
que luego son usados para construirlos con la función PaqueteModbus:
84
161: Paquete función 16 de consulta.
162: Paquete función 16 de respuesta.
41: Paquete función 4 de consulta.
42: Paquete función 4 de respuesta.
La función GetData realiza un ciclo consulta-respuesta por cada llamado, el búfer central
tiene una variable que indica el tipo de función que debe usar, 16 o 4. Se habilitan los
puertos paralelo y serial, se esperan los tiempos determinados para garantizar una óptima
conmutación de los transmisores, luego se construye el tipo de paquete con la función
PaqueteModbus y se envía por el puerto serial, ahora el programa ajusta el puerto paralelo
para conmutar el módulo de transmisión a recepción y empieza a leer carácter a carácter
todo lo que llegue al búfer, durante 100 intentos. Si encuentra la 1ra bandera (63), se
dispone a buscar la segunda (51), una vez encontradas se dispone a esperar la tercera (23),
en caso de no encontrar la bandera adecuada en el momento indicado vuelve y comienza,
una vez completados los 100 intentos, sin encontrar las 3 banderas del paquete, sale de la
función y considera el paquete enviado como paquete perdido. Ya se vio anteriormente que
al completar un número determinado de paquetes perdidos seguidos, el sistema de
telecomando desactiva el timer para que esté no sigua administrando y solicitando los
diferentes procesos.
Luego de encontrar las 3 banderas, el procedimiento GetData se dispone a leer el código de
la función que trae el paquete y debe ser igual al código enviado anteriormente, si no lo es,
sale de la función y lo considera un paquete perdido. Según el código de función que
identifique, guarda en un búfer temporal el número de datos exactos que debería traer un
85
paquete de ese tipo (4 bytes para un paquete 162 y 31 bytes para un paquete 42). Luego
verifica que inmediatamente después lleguen las 3 banderas del protocolo en orden inverso,
en caso de no suceder así, descarta la información en el búfer temporal y lo considera un
paquete perdido.
Una vez superadas todas las pruebas de verificación, si el paquete recibido es de tipo 42,
saca los datos del búfer temporal y los escribe en el búfer Central, si por el contrario es de
tipo 162 simplemente avisa al búfer central que la transmisión fue exitosa.
La relación de tramas y datos en las variables se definen en la función PaqueteModBus. En
esta función se verifica el tipo de paquete solicitado y se construye la trama correspondiente
en el orden descrito en las Figuras 35, 36, 37 y 38.
86
Función Posición en Paquete
16
Paquete[0]
Paquete[1]
Paquete[2]
Paquete[3]
Paquete[4]
Paquete[5]
Paquete[6]
Paquete[7]
Paquete[8]
Paquete[9]
Paquete[10]
Paquete[11]
Paquete[12]
Paquete[13]
Paquete[14]
Paquete[15]
Paquete[16]
Paquete[17]
Paquete[18]
Paquete[19]
Paquete[20]
Paquete[21]
Paquete[22]
Paquete[23]
Paquete[24]
Paquete[25]
Paquete[26]
Paquete[27]
Paquete[28]
Paquete[29]
Paquete[30]
Paquete[31]
Paquete[32]
Paquete[33]
Paquete[34]
Paquete[35]
Paquete[36]
Paquete[37]
Paquete[38]
Paquete[40]
Valor
Bandera A
Bandera B
Bandera C
Función
Dirección de Memoria
Número de Registros a Escribir
Número de Bytes a Escribir
C aja (Valores.Direccion)
Aceleración (Valores.Aceleración)
Azimut (Valores.Brazo.Azimut)
Altitud (Valores.Brazo.Altitud)
Manipulador (Valores.Brazo.Manipulador)
Extra (Valores.Brazo.Extra)
Directiva de C ontrol
Valor Directiva
Directiva de Azimut
Valor Directiva
Directiva de Altitud
Valor Directiva
Directiva Manipulador
Valor Directiva
Directiva Extra
Valor Directiva
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Bandera C
Bandera B
Bandera A
Fin de C adena '\0' (no se envía)
Tamaño del Paquete (usado por GetData)
Figura 35. Orden de Trama para paquete de consulta 16
El campo de índice 40, registra el tamaño que tiene el paquete, este valor no se envía por el
búfer del puerto serial, solamente es usado en la función GetData cuando el código
implementa el sistema de CRC, por medio de la función ModBusCRC. En la figura 36 se
describe el paquete de consulta para función número 4.
87
Función
4
Posición en Paquete
Paquete[0]
Paquete[1]
Paquete[2]
Paquete[3]
Paquete[4]
Paquete[5]
Paquete[6]
Paquete[7]
Paquete[8]
Paquete[9]
Paquete[10]
Paquete[11]
Paquete[40]
Valor
Bandera A
Bandera B
Bandera C
Función
Dirección de Memoria inicial
Numero de Registros Consultados
Bandera C
Bandera B
Bandera A
Fin de Cadena '\0' (No se envía)
Tamaño del Paquete (usado por GetData)
Figura 36. Orden de Trama para paquete de consulta 4
Así mismo como el sistema crea los paquetes consulta para enviarlos al robot, este
construye los paquetes respuesta que Orión interpreta con el siguiente criterio:
Función
16
Posición en Paquete
Paquete[0]
Paquete[1]
Paquete[2]
Paquete[3]
Paquete[4]
Paquete[5]
Paquete[6]
Paquete[7]
Paquete[8]
Paquete[9]
Paquete[10]
Paquete[11]
Paquete[40]
Valor
Bandera A
Bandera B
Bandera C
Función
Dirección de Memoria inicial donde se escribió
Numero de Registros Exitosamente Escritos
Bandera C
Bandera B
Bandera A
Fin de Cadena '\0' (No se envía)
Tamaño del Paquete (usado por GetData)
Figura 37. Orden de Trama para paquete de respuesta 16
88
Función
4
Posición en Paquete
Paquete[0]
Paquete[1]
Paquete[2]
Paquete[3]
Paquete[4]
Paquete[5]
Paquete[6]
Paquete[7]
Paquete[8]
Paquete[9]
Paquete[10]
Paquete[11]
Paquete[12]
Paquete[13]
Paquete[14]
Paquete[15]
Paquete[16]
Paquete[17]
Paquete[18]
Paquete[19]
Paquete[20]
Paquete[21]
Paquete[22]
Paquete[23]
Paquete[24]
Paquete[25]
Paquete[26]
Paquete[27]
Paquete[28]
Paquete[29]
Paquete[30]
Paquete[31]
Paquete[32]
Paquete[33]
Paquete[34]
Paquete[35]
Paquete[36]
Paquete[37]
Paquete[38]
Paquete[40]
Valor
Bandera A
Bandera B
Bandera C
Función
Número de bytes
Curso
Pitch
Roll
Temperatura Motor
Temperatura Ambiente
Velocidad
X (distancia recorrida por el motor derecho en
metros, centimetros, milimetros)
Y (distancia recorrida por el motor izquierdo en
Metros, centimetros, milimetros)
Detector de Metales
Ultrasonido 1
Ultrasonido 2
Ultrasonido 3
Ultrasonido 4
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Reservado
Bandera C
Bandera B
Bandera A
Fin de Linea '\0' (no se envía)
Tamaño del Paquete (usado por GetData)
Figura 38. Orden de trama para paquete de respuesta 4
Como se puede ver en las gráficas, existen campos en la trama reservados para futuros
desarrollos, sin embargo, si estos campos se agotaran, el protocolo ModBus permite
incrementar el tamaño de estos paquetes sin ningún traumatismo. Posiblemente en el futuro
para próximos desarrollos se pueden implementar nuevos tipos de paquetes ModBus.
89
4.11.2 Actualización de Instrumentos.
Después de cargar el búfer central con la información de los sensores del robot, el sistema
tiene que actualizar los valores de los instrumentos para visualizar los datos correctamente.
Adicional a una simple actualización, se tienen que dibujar las gráficas calculadas sobre el
mapa en caso de que este se encuentre activo. Los cálculos de límites y proporciones
manejados en los instrumentos, fueron calculados el momento de sincronizar los datos del
búfer central con el robot, por lo tanto este proceso transcribe los valores del búfer a los
instrumentos.
Parte de la actualización del sistema está en verificar el estado del robot, número de
paquetes perdidos, etc. Verificando el número límite configurado en el búfer, este proceso
evalúa el número de paquetes perdidos para cambiar o no el estado del interruptor general y
los colores o intermitencia del LED. Actualiza el mensaje de la barra de estatus para
orientar al operador en el estado del robot y en el número de paquetes perdidos en el
momento (Figura 39). Luego se dispone a calcular las coordenadas X y Y del mapa para
realizar el dibujo y la coordenada Z para elegir el color. Para esto, toma los valores de
Curso, Pitch y X (distancia recorrida por el motor), guarda las coordenadas anteriores para
luego calcular el rango que debe tener para generar la marca del robot sobre el mapa,
adicionalmente verifica el estado del detector para saber si dibuja una mina (roja) y detiene
el robot en caso de superar la tolerancia previamente configurada por el usuario.
90
Figura 39. Barra de estado Formulario Telecomando.
4.11.3 Proceso de registro en la base de datos.
Este proceso es muy similar al anterior, en lugar de escribir los datos del búfer en los
respectivos instrumentos, los registra en la tabla tramas definida en la estructura DM para la
conexión de base de datos (Ver Sección Clase DM – Base de datos).
Esta función no requiere ningún tipo de cálculo adicional y no verifica en ningún sentido el
estado del robot, solamente si está activado el interruptor de grabación del frame control
principal, se registraran los datos y las variables que pertenecen al búfer central, en el orden
definido en la sección Menú consulta – Formulario Principal.
Cada uno de los procesos atiende labores diferentes para cada uno de los módulos con lo
que se conecta el búfer central, para no tener problemas con los tiempos de respuesta, el
proceso de actualización del formulario telecomando, no retiene la ejecución del sistema
Orión, es decir, una vez ejecutado el proceso de actualizar controles, el sistema libera el
control del programa para que los cálculos realizados en el mapeo, no retarden la siguiente
solicitud de comunicación de la interfaz a la plataforma móvil y así el búfer central atiende
a cada uno de los módulos de forma independiente.
91
5. PRUEBAS Y ANÁLISIS DE RESULTADOS.
Para el desarrollo de este proyecto se realizaron 3 tipos de pruebas, enfocadas
principalmente a la evolución de la comunicación y sincronización de Orión con Úrsula.
También se realizaron pruebas para el manejo de la base de datos, el sistema de mapeo y
manejo de dispositivos ergonómicos.
5.1 COMUNICACIÓN PC – PC CON CABLE SERIAL CRUZADO.
El requerimiento determinante en el desarrollo del proyecto es el tiempo de respuesta, la
coordinación de la interfaz y la plataforma móvil dependía de los consumos de tiempo en el
proceso de comunicación. Para la implementación del control de comunicación serial se
desarrollaron 2 programas auxiliares Rigel y Betelgeuse.
Rigel es un programa cuya función es enviar tipos de paquetes por el puerto serial, con el
protocolo ModBus. Al igual que Orión, Rigel usa la clase TComPort (Ver sección Clase
TComPort) para Builder C++™ 6. Las funciones de construcción de paquete que están
implementadas en la interfaz, se desarrollaron en el programa auxiliar, con los tipos de
paquetes definidos con el grupo de investigación SIRP. (Ver figura 40)
92
Figura 40. Programa Auxiliar Rigel.
Adicionalmente, Rigel tiene la posibilidad de enviar este tipo de paquetes en diferentes
intervalos de tiempo. En la caja de texto “enviar cada” se escriben los tiempos de espera en
milisegundos. El Botón enviar activa la transmisión y el mismo botón la detiene. El código
del programa puede verse en el CD Anexo.
Betelgeuse es un programa más complejo, también implementa la Clase TComPort
utilizada por los otros 2 programas anteriores, pero este programa auxiliar funciona como
receptor y generador de paquetes Modbus. Interpreta el tipo de función y emite los
paquetes respuesta ModBus correspondientes. La solicitud puede generarse por Orión o
Rigel, es decir, actúa como simulador de Úrsula en otro computador. El programa tiene un
gran tablero que visualiza paquetes recibidos por el puerto (Ver Figura 41)
93
Figura 41. Programa Auxiliar Betelgeuse.
El sistema detecta las banderas de inicio y fin e interpreta el tipo de paquete y si es correcto
lo visualiza en la ventana del formulario, si el botón de chequeo “Hexa” está activo el
paquete de se presenta en hexagesimal separando byte a byte por un punto (.), pero si por el
contrario el botón de chequeo no está activo la información del paquete aparece en decimal,
también separados por coma (,).
Igual al anterior programa, Betelgeuse permite configurar el tiempo de captura y respuesta
de paquetes esclavos; permite configurar el número de bytes que se leen del búfer de
entrada y puede mostrar los datos en forma decimal o hexadecimal.
94
Se realizaron varias pruebas con los programas auxiliares y los primeros desarrollos de
Orión. El montaje se realizó con 2 computadores personales conectados por el puerto serial
con cable cruzado, simulando un canal de comunicación sin ruidos. El computador maestro
tenía procesador PENTIUM® III de 500 Mhz con 256 Mb en RAM, sistema operativo
Windows XP Pro. El computador esclavo tenía un procesador PENTIUM® I MMX de 200
Mhz con 64 MB en RAM, sistema operativo Windows® 98 SE. Las versiones preliminares
de Rigel y Betelgeuse se comunicaban entre si con pequeños paquetes de datos, en esta
primera etapa de pruebas se llegaron a las siguientes conclusiones:
•
El búfer del puerto almacena los bytes que recibe para luego ser retirados por el
programa receptor, sin embargo, si se solicitan más datos de los que el búfer tiene,
este rellena la solicitud con basura.
•
Si la solicitud del programa para retirar un número determinado de bytes sucede en
tiempo no sincronizado (el envío fue realizado posteriormente), algunos datos
pueden ser incorrectos, por lo tanto se tomó la decisión de analizar byte a byte antes
de retirar paquetes completos de información. Esto se ve en el proceso de
comunicación, en la función GetData, donde primero se retiran los byte del búfer
uno por uno, se verifican si son banderas y luego sí se procede a retirar un número
determinado de bytes según el tipo de función recibida.
•
El cable, no permite el ingreso de ruido externo, sin embargo, entre envío y envío se
podían meter ciertos bytes errados, la trama de datos que Rigel enviaba era
consistente, es decir no se insertaban bytes de ruido dentro de la trama. La lectura
consecutiva de bytes era segura por lo tanto el análisis de estos podía ser secuencial
95
y en caso de no ser adecuado el byte recibido, la secuencia de análisis de paquete
volvía a empezar.
•
Una vez los programas auxiliares se comunicaban entre si enviándose paquetes de
consulta y respuesta ModBus, la pérdida de estos era mínima (1 de cada 40 envíos n
promedio). La integridad de los datos era del 97%.
•
Se iniciaron los envíos de paquetes cada 250 ms, sin ningún problema en la
integridad de los datos, esta frecuencia de envío fue aumentando sin ningún
inconveniente hasta llegar a 20 ciclos consulta – respuesta por segundo, es decir
cada 50 ms, en este punto el número de paquetes perdidos aumento (1 de cada 8
envíos promedio), disminuyendo la integridad de los datos en un 88%, considerando
esta la frecuencia límite de transmisión con cable cruzado. Con estas frecuencias de
envío de paquetes los problemas de procesamiento se deben tener en cuenta, dado
que el timer realizaba la solicitud de transmisión siguiente cuando la anterior
todavía no terminaba, esto generaba un conflicto en el programa y lo terminaba.
5.2 COMUNICACIÓN
PC
–
MOVIL
CON
CABLE
SERIAL
CRUZADO.
Luego de las pruebas realizadas de computador a computador y una vez terminado el
módulo de comunicaciones de Orión, se realizaron pruebas con el módulo de recepción de
Úrsula y el cable serial cruzado. El objetivo principal de estas pruebas es observar la
capacidad de sincronización del sistema maestro con el esclavo, por el momento el
96
microcontrolador enviaba datos ficticios por el cable para que Orión, registre en el búfer
central y de este a los instrumentos en el formulario telecomando.
Después de realizar estas pruebas las conclusiones no variaron mucho de las obtenidas
anteriormente. El simulador instalado en el PC esclavo tiene un comportamiento similar al
obtenido en las pruebas con el procesador del robot. Las únicas conclusiones diferentes
obtenidas en este tipo de pruebas fueron:
•
Si se desconecta el robot del cable y se conecta de nuevo la sincronización no se
restablece. Se debe reiniciar el procesamiento en la plataforma móvil, para volver a
sincronizar la comunicación.
•
A diferencia del simulador Betelgeuse, Úrsula funciona por interrupción en el
puerto, ayudando a la respuesta inmediata del móvil a la estación base. Sin
embargo, los valores máximos de frecuencia obtenidos en los tipos de pruebas
pasados no cambiaron fuertemente, para mantener una conexión estable se podían
realizar como máximo, 15 ciclos de consulta – respuesta por segundo.
•
El número de paquetes perdidos consecutivos no era mayor a 4 y en promedio había
un paquete perdido cada 37 ciclos consulta – respuesta a una tasa de transmisión de
4 ciclos por segundo. Sin embargo el control de paquetes implementado en las
funciones de GetData no permitían que esas pérdidas fueran visibles al usuario.
97
5.3 COMUNICACIÓN
PC
–
MOVIL
CON
MÓDULOS
INALÁMBRICOS
Para terminar de ajustar los procesos de comunicación que se implementaron en la interfaz,
se realizaron pruebas de comunicación entre el computador personal donde se encuentra
Orión y el procesador que se implementará en la nueva versión de Úrsula, usando los
módulos inalámbricos (ver Requerimientos Funcionales). Un factor que no se había
evaluado en las pruebas anteriores es el del puerto paralelo y los tiempos de conmutación
de los módulos inalámbricos. Estos tiempos se manejaban en las funciones de
comunicación con el puerto, usando la función Sleep (ver Librería IO.dll), pero al liberar
los cuellos de botella en el búfer central, estos tiempos debían aumentar, ya que el paquete
estaría listo para transmitir antes de que el módulo se ajustara a modo transmisión. Estos
problemas se solucionaron tomando medidas de voltaje sobre el puerto y sobre los módulos
de transmisión, estableciendo el tiempo necesario para que la transmisión del ciclo
consulta-respuesta fuera exitosa. Estos cambios se realizaron tanto en el desarrollo de la
interfaz como en el robot, logrando resultados satisfactorios con los requerimientos.
•
Los tiempos de sincronización de la interfaz y el robot son muy pequeños (menor a
1 seg). La integridad de los datos es bastante buena, con 4 ciclos por segundo, el
número máximo de paquetes perdidos consecutivos llegaba a 6. sin embargo el
límite de frecuencia máxima se reduce, ya que el crecimiento de paquetes perdidos
por frecuencia es mayor al de las pruebas anteriores. Básicamente este
comportamiento se produce por el nuevo factor del puerto paralelo y un haz de
98
ruido que emiten los módulos durante los intervalos de conmutación. Sin embargo
para el cumplimiento de los requerimientos del sistema es correcto.
•
Para el sistema Orión es completamente transparente si la conexión física del
computador es alambrica o inalámbrica. No se realizaron cambios significativos en
la estructura de las funciones, lo único que variaba por prueba eran los tiempos de
espera en los puertos paralelos, pero una vez ajustados estos tiempos, la
comunicación fue bastante estable. Se perdía en promedio 1 paquete cada 30
exitosos a 4 ciclos consulta – respuesta por segundo.
•
La
recuperabilidad
de
la
comunicación
por
parte
del
robot
mejoró
considerablemente, si perdía la comunicación entre el robot y la interfaz, este podía
recuperarse rápidamente, esto debido a la conexión del módulo del transmisión
inalámbrica constante, a diferencia del cable cruzado, una vez el cable era
desconectado, no se podía sincronizar hasta reiniciar el robot de nuevo. Orión
siempre tuvo características excelentes de recuperabilidad en la comunicación.
En la figuras 42 y 43 se pueden ver las gráficas que visualizan el análisis de las propiedades
de la comunicación entre el robot y la interfaz
El primer análisis se realiza con el número de paquetes exitosos por uno perdido, en
diferentes frecuencias de solicitud de ciclo consulta – respuesta, para los 3 tipos de pruebas.
99
Figura 42. Paquetes Exitosos por Paquete Perdido
Como se puede observar en la figura, la caída de paquetes exitosos en la prueba tipo tres es
bastante critico, para 20 ciclos consulta – respuesta por segundo la integridad del canal a
caído a un 75%, sin poder garantizar una confiable sincronización entre el robot y la
interfaz. Sin embargo, para la transmisión que solicitaron en los requerimientos (4 ciclos
por segundo), la integridad del canal es muy buena y se puede garantizar una optima
teleoperación de la plataforma móvil.
También se hizo un análisis del número máximo de paquetes perdidos consecutivos que se
extraviaban en la transmisión, para hallar un límite adecuado y generar los avisos
respectivos.
100
Figura 43. Número de Paquetes Perdidos Consecutivos
En la figura se observa claramente que el crecimiento de paquetes perdidos en las pruebas
de tipo 3 es mayor que el de los demás tipos, adicionalmente es el único que supera los 10
paquetes perdidos, para transmisiones de cada 50 ms. Como se puede ver si en el análisis de
trasmisiones para 250 ms (requerimiento Úrsula), el promedio de paquetes perdidos
consecutivos es 8 no superando los 10, determinando el límite máximo de paquetes
perdidos para considerar perdida la comunicación con la plataforma movil, como se vio en
el Formulario Telecomando – Sección Frame Control Principal.
101
5.4 ALMACENAMIENTO EN BASE DE DATOS.
Se realizaron un conjunto de pruebas adicionales para medir la funcionalidad de otros
módulos, este es el caso de la estructura DM para la base de datos Advantage. Durante más
de una hora se permitió a Orión almacenar 15000 registros de datos aproximadamente
recogidos en el búfer central, para verificar la estabilidad del programa y de la base
almacenando grandes cantidades de información.
Estas pruebas buscaban garantizar la robustez de la base de datos y la capacidad del sistema
para almacenar la información y realizar tareas de comunicación y sincronización, es decir,
para el sistema Orión, el proceso de almacenamiento debe ser transparente.
Luego de las pruebas se obtuvieron resultados satisfactorios, no solo los registros se
guardaron correctamente, la capacidad del motor de base de datos fue consistente con las
referencias inicialmente adquiridas por referencias de otros usuarios. Se grabaron varias
sesiones de 30 minutos cada una, en pruebas tipo 1 (PC-PC con cable cruzado), sin dejar de
registrar ningún intervalo, en caso de tener un paquete perdido, la base registró el dato que
el búfer tenía en el estado inmediatamente anterior.
Los resultados permiten concluir que el motor de base de datos Advantage garantiza el
funcionamiento y el correcto cumplimiento de los requerimientos inicialmente planteados
por parte de la Interfaz.
102
5.5 CONSTRUCCIÓN VIRTUAL DE TERRENO.
Para determinar el funcionamiento del sistema de construcción virtual del terreno, se
realizaron pruebas simuladas con datos forzados en el búfer central. Estas pruebas tienen
como objetivo evaluar la relación gráfica de colores con niveles de terreno y el concepto de
abstracción del terreno que puede tener el operador de la interfaz.
Los resultados generaron algunos ajustes mínimos en las proporciones de cambio de color,
es decir, el cambio de color por variaciones de 5 m en sentido vertical, cambio a 50 cm,
durante las primeras pruebas el color dibujado en el mapa, variaba cada cambio vertical de
5 m, como tenía 7 rangos de color, podía moverse en una colina de 40 m de altura. Ahora
esos cambios de sección se producen cada 50 cm de variación vertical calculado con los
valores del pitch y el avance horizontal, el punto de dibujo cambia de color al cambiar al
rango más cercano superior o inferior.
La altura y la condición espacial del móvil está determinadas por sus sensores y actuadores,
estos son puntuales y se encuentran ubicados dentro de la estructura del robot, por lo tanto
la apreciación de la información entregada debe representarse en un objeto circular y no en
uno cuadrado, como se implementó inicialmente en el desarrollo de Orión, mejorando la
interpretación visual por parte del operador.
En las primeras pruebas realizadas el mapa se borraba e inicializaba su punto de dibujo,
cuando el interruptor de mapeo se apagaba, pero se vio la necesidad de implementar un
103
botón para el borrado del mapa sin iniciar el punto de dibujo, este sistema de borrado se
puede aplicar en cualquier momento durante el funcionamiento del mapeo.
5.6 MANIPULACIÓN POR GAME CONTROLLER O SISTEMAS DE
JOYSTICK.
Por último la evaluación que determina el completo funcionamiento de Orión y el
cumplimiento de los requerimientos inicialmente establecidos, está enfocada a la respuesta
del sistema de control por medio del Joystick o Game Controller.
Como se explicó durante el capítulo de desarrollo, el Joystick predeterminado en el sistema
operativo se conecta a los botones implementados en el formulario Telecomando, estos
simplemente ejecutan la acción que tenían configurados en la tabla.6.
Se realizaron pruebas de manipulación para determinar el orden adecuado de los botones y
las funciones asociadas a estos. Estos resultados establecieron los parámetros explicados en
el capítulo de Desarrollo – Frame Control Manual.
104
6. CONCLUSIONES
La detección de minas antipersonales es un problema complejo y una labor de gran
dificultad. Los factores necesarios para tener en cuenta son muchos y esto indica que el
campo de investigación está abierto. El sistema conjunto Orión – Úrsula no puede
solucionar por completo este problema, es tan solo un prototipo que indica una dirección
para una investigación que contemple los demás factores como complejidad del terreno,
sistema de detonación, etc. El logro principal de Orión es facilitar las investigaciones
realizadas en este campo, ser una herramienta para la evolución del robot y en consecuencia
para la solución del problema planteado.
El sistema interfaz hombre-máquina Orión es totalmente robusto, modular y escalable,
permite una fácil y poco traumática modificación para módulos nuevos. Es completamente
reproducible para múltiples robots e inclusive el uso del protocolo modbus permitiría
transmisión simultánea a varios móviles. La sintaxis implementada en el código es clara y
simple, un desarrollador puede interpretar de manera simple la estructura del software y
agregar o modificar fácilmente los objetos, funciones y propiedades del mismo.
La interpretación gráfica de la interfaz es agradable y realiza un gran aporte en el proyecto,
minimizando el conocimiento mínimo requerido por el operador. Las herramientas gráficas
ajustadas para el sistema permiten una interpretación natural, debido a su forma y color.
Los textos, mensajes e instrumentos son consistentes en todos los módulos de Orión,
105
manteniendo contacto atractivo para el operador y evitando posibles errores de
manipulación, cumpliendo con todos los lineamientos teóricos propuestos.
Todo el desarrollo de Orión se realizó a un muy bajo costo, con controles o clases gratuitas
y públicas, que garantizaron estabilidad y robustez. La compatibilidad del entorno de
desarrollo con estas herramientas generó una cantidad de posibilidades que se adaptarán en
el futuro. Adicionalmente el sistema puede asimilar herramientas de alto costo o con mayor
complejidad, debido a su modularidad y forma de implementación. Orión es un software
completamente independiente, no requiere de instalaciones adicionales ni licencias costosas
de otros programas como Matlab, Labview, etc. Las herramientas utilizadas son de uso
gratuito o de uso temporal, minimizando los requerimientos técnicos que tenía la Interfaz
anterior.
La construcción virtual del terreno permite al operador hacerse una idea del mismo así este
no pueda tener contacto visual directo o su posición de teleoperación no sea la mas
adecuada. Este es un gran aporte al sistema completo, el análisis realizado es análogo en el
sentido mismo de la ilustración, no es una simple cuadrícula coloreada, es un sistema de
construcción gráfico mucho más cercano a la realidad del terreno.
El sistema de almacenamiento es completo, sin embargo es escalable y permite
implementar nuevas funciones de grabación o control, como el manejo de usuarios,
almacenamiento de valores para nuevos sensores, etc. Los datos se guardan con absoluta
integridad y el sistema garantiza que la continuidad de los datos se almacene sin afectar los
demás módulos ejecutados.
106
El sistema permite manipulación por medio de controles físicos especiales o ergonómicos.
Estos pueden conectarse al sistema por diversos puertos y para el sistema Orión es
indiferente. Los controles ergonómicos permiten un mayor control sobre el móvil y
combinado con la interpretación natural que la interfaz provee, Orión se convierte en un
sistema de adaptación y control muy superior a su antecesor.
107
7. BIBLIOGRAFÍA
1. A.Baecker
Hard
&
Software.
Hauptstr.
137.
63773
Goldbach.
Germany.
http://www.AbakusVCL.com.de
2. Advantage TDataSet Descendant for Delphi/Kylix/C++ Builder - Getting Started
Guide, Septimbre de 2003
3. Camilo Campo, Javier Coronado, Javier Rizo. SISTEMA MÓVIL PARA LA
DETECCIÓN Y LOCALIZACIÓN DE MINAS ANTIPERSONALES. Pontificia
Universidad Javeriana, 2002
4. Dejan Crnila – ComPort v 2.6 - Estudiante de ciencias de la computación en la
Universidad de Liubliana – Eslovenia.
5. Ian Somersville. Ingeniaría de Software. Addison Weley. 6 edición.
6. Modicon Modbus Protocol Referente Guide, junio de 1996.
7. SHNEIDERMAN, B. (1998). Designing the User Interface, 3rd edn. Addison-Wesley.
8. Thayer, R. H. y Dorfman, M. (1997). Software Requirements Engineering. IEEE
Computer Society Press. (Cap 5).
9. Winsoft Ltd. http://www.winsoft.sk.
108
8. ANEXOS
109
ANEXO A: CODIGO DE ORIÓN.
Para ver fuentes del programa, por favor consultar el CD adjunto
110
ANEXO B: CÓDIGO DE PROGRAMAS AUXILIARES.
Para ver fuentes de programas auxiliares, por favor consultar el CD adjunto
111
ANEXO C: MODICON MODBUS PROTOCOL REFERENCE
GUIDE.
Para ver la guía de referencia, por favor consultar el CD adjunto
112
ANEXO D: MANUAL DE USUARIO.
113
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising