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