4 Estructura del sistema

Capítulo 4: Estructura del sistema
4.1 Introducción
En el presente capítulo trataré la estructura general que sigue el sistema
diseñado así como el funcionamiento que sigue como conjunto y por partes.
Una descripción más profunda de la estructura del código y de la utilidad de las
funciones y variables más importantes se tratará en los capítulos 7 y 8 de este
documento.
4.2 Módulos diferenciados del sistema
En la medida de lo posible, y con el fin de simplificar el diseño y la
depuración del sistema, se ha tratado de modular el sistema de forma óptima.
En este apartado se describirán los distintos módulos, sus características y
funciones principales y la forma de actuar unos sobre otros.
El sistema proyectado se puede dividir en tres grandes bloques que se
pueden tratar por separado. Por un lado está el bloque que trata los aspectos
1
relacionados con el manejo de la información enviada por la IMU hacia la
unidad Viper. En este bloque se da solución a:
-
Configuración
del
puerto
serie
para
el
establecimiento
de
la
comunicación entre cada unidad Viper y la IMU asociada.
-
Recepción, almacenamiento en una cola circular, posterior extracción y
tratamiento de los datos enviados periódicamente por el puerto serie
procedentes de la IMU.
-
Reseteo de la IMU cuando sea requerido por el sistema, usando para
ello una trama establecida para tal fin por el fabricante.
Por otro lado, existe un segundo bloque del sistema en el que se
encuentran los aspectos relacionados con la comunicación Ethernet que existe
entre las dos unidades de medida. Tanto al principio como al finalizar cualquier
experimento realizado con el sistema, se necesita establecer una comunicación
UDP entre las dos unidades de medida. Debido a esta necesidad se ha
diseñado un protocolo de comunicaciones para sincronizar ambas unidades
entre sí. Esto ha supuesto el desarrollo de una máquina de estados que
gestionara la comunicación, así como la estructura de los mensajes
intercambiados entre las unidades.
El tercer y último bloque del sistema trata y da solución a los aspectos
del sistema que tengan que ver con la transmisión desde el servidor central
hacia ambas unidades Viper de su configuración y modo de funcionamiento.
También tratará sobre el almacenamiento en las unidades de los resultados de
los experimentos y del envío de éstos al servidor central.
4.3 Configuración del sistema
Al ejecutar el sistema, antes de mostrar nada por pantalla, se cargará la
configuración asignada. Ésta configuración estará almacenada en un archivo
de texto que habrá sido enviada a la unidad Viper desde el servidor central. En
2
un apartado posterior se describirá en profundidad la estructura del archivo de
configuración. La razón de por qué se necesita cargar la configuración es
sencilla; se necesita que el software diseñado sea el mismo para las dos
unidades de medida diferentes RMU y PMU, por lo que se hace obligatorio
almacenar ciertos datos de configuración en cada unidad para diferenciar una
de otra. Los datos a configurar en cada unidad son:
-
Dirección IP local de la unidad Viper
-
Dirección IP remota de la otra unidad Viper
-
Dirección IP remota del servidor central
-
Puerto UDP a usar en las comunicaciones Ethernet
-
Puerto serie a usar en la comunicación serie con la IMU
-
Modo de funcionamiento. Indica si se trata de unidad de medida móvil
(PMU) o unidad de medida de referencia (RMU)
-
Modo de trabajo. Indica si estamos en modo depuración o no del
sistema.
El archivo de configuración se almacena localmente en la unidad Viper.
Es por esto por lo que se hace necesaria la inclusión de una memoria no volátil
que permita guardar estos datos. Como se comentó en el capítulo 3, el
computador empotrado elegido posee 32 Mbytes de memoria tipo flash. A esta
memoria se puede acceder desde el sistema operativo, ya que se almacena en
una carpeta llamada “Flashdisk” situada en el directorio raíz del sistema.
Además de la necesaria lectura del fichero de configuración almacenado
en la memoria por parte del sistema, también será necesario poder escribir
sobre la memoria. Esto se debe a que una vez finalizados los experimentos, el
sistema salva en un archivo de resultados los datos finales y los posibles
errores y alarmas surgidos durante el proceso de medida. Al igual que el
archivo de configuración, el archivo de datos final será comentado ampliamente
en un capítulo posterior.
3
4.4 Formato de tramas enviadas y recibidas por la IMU
La mayor parte de la comunicación serie existente entre la unidad Viper
y la IMU se dará en sentido IMU-Viper. Es en éste sentido en el que se
transmitirán las tramas que la IMU envía periódicamente y que el computador
empotrado interpretará de forma oportuna. Sin embargo existe un caso en el
que la comunicación se realiza en sentido Viper-IMU. Será cuando se necesite
reiniciar la IMU, para lo cual el computador envía una trama de reinicio a la IMU
que previamente ha sido definida por el fabricante y que la IMU sabe interpretar
correctamente. A continuación se describen las tramas enviadas y recibidas por
la IMU a través de su interfaz serie.
4.4.1 Trama recibida por la IMU: Trama de restart
Como se comentó en el capítulo 2, las unidades RMU y PMU necesitan
de un alineamiento inicial que será ordenado mediante una trama de caracteres
ASCII transmitida por el puerto serie. La etapa de alineamiento durará 5
minutos. La trama de Restart tiene la siguiente estructura:
$PIXSE,CONFIG,RESET_*57<CR><LF>
La trama de Restart es definida por iXSea en la documentación facilitada
sobre la unidad AIRINS.
La función de reinicio que provoca el envío de esta trama por parte de la
unidad Viper es de vital importancia en el funcionamiento del sistema, ya que
es el primer paso para realizar cualquier experimento con el sistema global de
medida, y sin el cual no puede comenzar a medirse las posiciones.
4.4.2 Trama enviada por la IMU: Trama de datos
Los datos posicionales que son medidos por los giroscopios y
acelerómetros instalados en el interior de la IMU son enviados hacia la unidad
4
Viper para su proceso encapsulados en una trama transmitida mediante la
interfaz serie que comunica la IMU con el computador empotrado.
Durante todo el proceso de realización del proyecto, se ha pasado por la
utilización de 3 versiones distintas del protocolo de salida de la unidad de
medida inercial. A medida que iban surgiendo problemas y se encontraban sus
soluciones se idearon nuevas versiones del protocolo que hicieron más fácil el
trabajo, redujeron la carga computacional lo máximo posible y aumentaron la
robustez del mismo.
En un principio se pensó en un protocolo ASCII, que consistía en una
trama de caracteres que contenía los tres ángulos de Euler y el tiempo
asociado a éstos en una cadena de caracteres. Ello conllevaba un posterior
tratamiento de esos caracteres por parte del computador, ya que era necesario
interpretarlos y pasarlos a formato binario para realizar los cálculos necesarios
en cada experimento. Esto, unido a que la IMU envía 100 tramas por segundo
nos hizo pensar que la carga computacional necesaria para la interpretación de
los ángulos y el tiempo asociado a éstos sería excesiva para el tipo de
computador destinado a esta tarea. Así pues se decidió cambiar del protocolo
ASCII a una segunda versión que ya enviaba los campos de datos
directamente en binario. Una vez que se mandó la petición del nuevo protocolo
al fabricante de la IMU y que éste respondió con la nueva versión, todo el
código se hizo aprovechando esta característica del protocolo. El nuevo
protocolo consistía en una trama binaria de 23 bytes que contenía varios
campos de datos, entre los que estaban los tres ángulos de Euler, el tiempo,
así como el estado de la unidad y el código de redundancia. Pero éste no fue el
protocolo que usa la versión definitiva del software. Una vez que casi todo el
código estaba escrito y se estaban realizando la depuración y las primeras
pruebas reales se pensó de nuevo en un cambio del protocolo. Debido a la
necesidad de solventar un problema de indeterminación de los ángulos de
Euler que la IMU mandaba, se hizo necesario cambiar de los 3 ángulos de
Euler que hasta entonces se utilizaban, a los cuatro cuaterniones que a partir
de ahora se iban a utilizar. Esto provocó no pocos cambios en el código del
sistema, ya que implicaba un cambio en la longitud y estructura de la trama de
5
datos. Se tuvo que modificar varias variables y funciones dedicadas al
tratamiento de la información contenida en las tramas de datos, además de la
inclusión de una nueva función que implementara los cálculos necesarios para
pasar de cuaterniones a los ángulos de Euler.
A continuación se describen brevemente cada uno de los 3 protocolos
usados, la descripción de los campos de las tramas y los formatos usados en
cada uno de ellos.
• 1ª VERSION: Protocolo HRPT
La unidad de medida inercial nos enviaba en esta versión, con una
frecuencia de 100 Hz, los tres ángulos de Euler y el tiempo asociado a ellos,
además de otros datos relativos al estado de la unidad y un código de
comprobación de errores. Todos estos datos eran enviados por la IMU a través
de un protocolo ASCII dedicado llamado “HRPT”. Se trataba de una trama
ASCII de hasta 53 caracteres. El problema que tenía esta primera versión del
protocolo era que, debido a que los datos llegaban a la unidad Viper en forma
de caracteres ASCII, la computadora debía realizar la labor de pasar esos
datos a binario para poder tratarlos y realizar los cálculos necesarios con ellos.
Esta tarea suponía una carga computacional demasiado pesada para un
computador de estas características. La trama estaba estructurada de la
siguiente manera:
Mensaje:
$HRPT,hhmmss.sss,hhh.hhh,rrr.rrr,ppp.ppp,HHHHHH*hh<CR><LF>
Donde:
$HRPT
Es la cabecera
hhmmss.sss
Es el tiempo de los ángulos, en horas, minutos,
segundos y milisegundos
hhh.hhh
Es el ángulo Heading, en grados (0-360°)
rrr.rrr
Es el ángulo Roll en grados, positivos cuando
se levanta la izquierda (+/- 180 °)
6
ppp.ppp
Es el ángulo Pitch en grados, positivo cuando el
morro desciende (+/- 90°)
HHHHHHHH
32 bits menos significativos de los 64 bits que
describen el estado de la unidad (PHINS
*hh
Status)
Es el Código de redundancia (Checksum) de
tipo NMEA
• 2ª VERSION: Protocolo HRP Bin
En esta segunda versión del protocolo, la unidad de medida inercial nos
enviaba con una frecuencia de 100 Hz, al igual que en la versión anterior, los
tres ángulos de Euler y el tiempo asociado a ellos, además de otros datos
relativos al estado de la unidad y un código de comprobación de errores. La
diferencia radicaba en que ahora todos estos datos eran enviados por la IMU a
través de un protocolo binario dedicado llamado “HRP Bin”. Al tratarse de datos
en binario, se reducía con ello en gran medida la carga computacional que
debía soportar la unidad Viper, consiguiendo de esta forma solucionar el
problema aparecido con la primera versión del protocolo. Se trataba de una
trama binaria de 23 bytes estructurada de la siguiente manera:
Mensaje:
<Sinc><C0><C1>…..<C7>
Campo 0 Byte 0
0x24
Byte de sincronización
Campo 1 Bytes 1 a 4
PHINS
32 bits menos significativos de los 64
Status
bits que describen el estado de la
unidad.
Campo 3 Bytes 5 a 8
Heading
32 Bits con formato en coma flotante, en
radianes (0 a 2*PI)
Campo 4 Bytes 9 a 12 Roll
32 Bits con formato en coma flotante, en
radianes (± PI)
Campo 5 Bytes 13
a Pitch
32 Bits con formato en coma flotante, en
7
16
radianes (± PI/2)
Campo 6 Bytes 17 a 20 Time
5 Bits entero: Hora
6 Bits entero: Minutos
6 Bits entero: Segundos
10 Bits entero: Milisegundos
5 Bits : 00000
Campo 7 Bytes 21 a 22 CRC
Código
de
redudancia
cíclica
(Checksum)
• 3ª VERSION: Protocolo Qnb Bin
En la tercera y definitiva versión del protocolo, la unidad de medida
inercial nos envía con una frecuencia de 100 Hz los cuatro cuaterniones que
describen la posición y el tiempo asociado a ellos, además de otros datos
relativos al estado de la unidad y un código de comprobación de errores. Todos
estos datos son enviados por la IMU a través de un protocolo binario dedicado
llamado “Qnb Bin”. El uso de cuaterniones en lugar de los ángulos de Euler
estuvo motivado por la necesidad de evitar un tipo de indeterminación que
aparecía con la segunda versión del protocolo. Quedando definitivamente una
trama binaria de 27 bytes estructurada de la siguiente manera:
Mensaje:
<Sinc><C0><C1>…..<C8>
Campo 0 Byte 0
0x24
Byte de sincronización
Campo 1 Bytes 1 a 4
PHINS
32 bits menos significativos de los 64
Status
bits que describen el estado de la
unidad.
Campo 3 Bytes 5 a 8
Qnb 0
32 Bits con formato en coma flotante
Campo 4 Bytes 9 a 12 Qnb 1
32 Bits con formato en coma flotante
Campo 5 Bytes 13 a 16 Qnb 2
32 Bits con formato en coma flotante
Campo 6 Bytes 17 a 20 Qnb3
32 Bits con formato en coma flotante
8
Campo 7 Bytes 21 a 24 Time
5 Bits entero: Hora
6 Bits entero: Minutos
6 Bits entero: Segundos
10 Bits entero: Milisegundos
5 Bits : 00000
Campo 8 Bytes 25 a 26 CRC
Código
de
redudancia
cíclica
(Checksum)
4.5 Comunicación Ethernet
En este apartado describiré las comunicaciones Ethernet que se
establecen entre las dos unidades de medida. Este tipo de conexiones se
realizan usando las conexiones de red de las que disponen las unidades Viper
incluidas en el interior de las dos unidades de medida.
El sistema prevé dos tipos de comunicaciones Ethernet: una conexión
UDP usada para comunicar y sincronizar las dos unidades de medida entre sí,
y una conexión TCP usada para comunicar las dos unidades de medida con el
servidor central. A continuación se verá con más detalle:
4.5.1 Conexión TCP
Debido a la necesidad de usar un protocolo orientado a conexión en las
comunicaciones entre las unidades de medida y el servidor central, se optó por
una conexión TCP.
Esta comunicación es usada por el sistema para realizar las
transferencias del archivo de configuración y el archivo de experimentos desde
el servidor central a las unidades de medida. Estos dos archivos son
necesarios para el correcto funcionamiento de las dos unidades de medida.
También es usada para transferir el archivo de datos hacia el servidor central
9
desde la unidad de medida PMU una vez que ésta haya terminado de realizar
todas las medidas y cálculos necesarios en cada experimento.
El envío y recepción de los distintos archivos a través de la conexión
TCP establecida está gestionado por la parte del sistema ejecutada en el
servidor central. Al usuario se le presentará una interfaz clara y despejada en la
que habrá dos parte bien diferenciadas: una dedicada a la transferencia de
archivos con la unidad de medida móvil PMU, desde la que se podrá mandar
los archivos de configuración y de experimentos hacia la unidad de medida y
desde la que se podrá descargar el archivo de resultados al servidor central. La
segunda mitad de la interfaz estará dedicada a la unidad de medida de
referencia RMU y sólo tiene disponible la opción de mandar hacia ella el
archivo de configuración, ya que esta unidad no necesita el archivo de
experimentos ni generará archivo de resultados.
Figura 4.1 Interfaz del servidor central.
Una vez escogida la acción que se desea realizar mediante un cuadro
de diálogo el operario podrá elegir el archivo de configuración o experimentos a
mandar o la ruta en la que descargar el archivo de resultados.
10
Figura 4.2 Cuadro de dialogo usado para mandar fichero
4.5.2 Conexión UDP
Una acción necesaria para el correcto funcionamiento del sistema de
medida es la sincronización entre ambas unidades de medida en las etapas de
alineación de éstas, al inicio del trayecto y al final del mismo. Para poder llevar
a cabo esta sincronización es imprescindible comunicar las dos unidades, y
esto se hace a través de las unidades Viper que portan en su interior. Cada vez
que se necesite sincronizar, será necesario conectar las dos unidades de
medida mediante un cable de red por el que se establecerá una comunicación
UDP encargada de transportar los mensajes UDP necesarios. En el posterior
capítulo 7 se describirá este protocolo de comunicación y los paquetes UDP
enviados y recibidos.
Realizar
la
comunicación
UDP
usando
las
clases
CSocket
proporcionadas por la API de Windows no es tarea sencilla, ya que el sistema
Windows CE 5.0 que hace de sistema operativo para la unidad Viper y sobre el
11
que funciona el software diseñado, no realiza correctamente el mapeo de
mensajes entre el propio sistema operativo y el software. Aunque se recibían
datos UDP, el sistema operativo no notificaba su llegada, por lo que el sistema
seguía esperando indefinidamente la llegada de los paquetes. Los problemas
que esto causó y la solución adoptada serán tratados en el capítulo 7.
12