Entorno avanzado de simulación y experimentación de UAVs en

Capítulo 8
Conclusiones y trabajo futuro
8.1.
Conclusiones
Las siguientes son las conclusiones obtenidas a lo largo de la realización del proyecto:
Se ha desarrollado de manera exitosa un entorno de tiempo real que permite trabajar bajo
el mismo esquema con simulaciones de modelos y datos obtenidos de experimentos reales.
La posibilidad de representar los datos de la simulación y los datos experimentales en paralelo,
hace a esta herramienta muy útil a la hora de establecer comparaciones.
La interfaz gráca creada representa de manera clara el movimiento de los objetos, facilitando
el análisis del comportamiento.
La posibilidad de representar datos guardados en modo oine seleccionando sólo aquellos
tramos de interés, añade versatilidad a la herramienta.
El procedimiento para la obtención de código ejecutable en tiempo real se realiza de forma
sencilla y sistemática con las herramientas que dispone MATLAB para tal n. Sin embargo,
el proceso no es automático, por lo que se requiere que se genere de nuevo el código cada vez
que se realice un cambio en el modelo.
Mediante la incorporación del mando RC al entorno de simulación, es posible entrenar a
pilotos con modelos matemáticos que previamente hayan sido ajustados para representar al
prototipo real.
8.2.
Trabajo futuro
Las aplicaciónes generadas con RTW para ejecutar en tiempo real se basan en el siguiente
esquema:
119
8.2. Trabajo futuro
120
main() {
Initialization (including installation of rt_OneStep as an interrupt service routine for a real-time clock)
Initialize and start timer hardware
Enable interrupts
While(not Error)&(time < final time)
Background task (rt_OneStep)
EndWhile
Disable interrupts (Disable rt_OneStep from executing)
Complete any background tasks
Shutdown
}
rt_OneStep() {
Check for interrupt overflow or other error
Enable "rt_OneStep" (timer) interrupt
ModelStep (Time step combines output, logging and update)
}
El programa principal, después de la inicialización, entra en un bucle innito a la espera de interrupciones. Estas interrupciones ocurren cada tiempo de muestreo especicado en el modelo. En
la rutina de interrupción rt_OneStep, se llaman diferentes funciones que se encargan de calcular
salidas (mdlOutputs ), actualizar estados (mdlUpdate ), calcular derivadas (mdlDerivates ), etc.
Al compilar un modelo, RTW genera el código C de las funciones mdlOutputs, mdlUpdate, etc.
traduciendo el diagrama de bloques. La estructura principal del programa esta implementada en
un chero fuente de RTW que es independiente al modelo pero depende del tipo de target. Este
chero fuente se incluye en la compilación y se enlaza junto con el código generado para formar la
aplicación completa.
1
Si se compila un modelo seleccionando la opción para un target genérico , en la información de
compilación se puede ver que se utilizan los siguientes cheros:
Generados por RTW: modelo.c, modelo_data.c, rt_nonnite.c
Librerías de RTW: rt_logging.c, grt_main.c, rt_sim.c
El chero modelo.c es el que contiene todo el código traducido del modelo por RTW, mientras
que grt_main.c es el que contiene la estructura principal del programa. Al ser un target genérico,
grt_main.c sirve como plantilla para crear aplicaciones para diferentes sistemas operativos en
2
tiempo real .
No ocurre lo mismo si se utiliza xPC target. Al compilar un modelo para xPC se utilizan los
siguientes:
Generados por RTW: modelo.c, modelo_capi.c, modelo_data.c, rt_nonnite.c
Librerías de RTW: rt_logging.c, rt_logging_mmi.c, rtw_modelmap_utils.c, xpctarget.c, xpcim-
ports.c, xpcPCFunctions.c
La estructura principal del programa no se encuentra en ninguno de los cheros anteriores. Esto
puede deberse a que el kernel de xPC está pensado para ejecutar exclusivamente aplicaciones
1 GRT target o Generic Real-Time
2 también conocidos como RTOS.
target.
8.2. Trabajo futuro
121
generadas con Simulink, por lo que la estructura principal está predeterminada internamente. Al
no tratarse de un RTOS convencional como, por ejemplo, RTLinux o QNX, no se pueden controlar
aspectos relacionados con el kernel de tiempo real puesto que no se disponen de llamadas al sistema
operativo. Sin embargo, se disponen de algunas funciones del kernel denidas en xpcimports.c que
se pueden usar en cualquier aplicación para crear drivers especícos. Estas funciones se mencionan
a continuación.
Port I/O
ˆ
xpcInpB, xpcInpW, xpcInpDW -> I/O port input functions for byte, word, and double
word accesses
ˆ
xpcOutpB, xpcOutpW, xpcOutpDW -> I/O port output functions for byte, word, and
double word accesses
PCI Conguration Information
ˆ
xpcGetPCIDeviceInfo -> Return information for PCI device
ˆ
xpcShowPCIDeviceInfo -> Display contents of PCIDevice structure
Physical Memory
ˆ
xpcAllocPhysicalMemory -> Allocate physical memory
ˆ
xpcFreePhysicalMemory -> Free physical memory
ˆ
xpcReserveMemoryRegion -> Return virtual address that corresponds to physical address and mark region as readable/writable
Time
ˆ
xpcGetElapsedTime -> Return time since system boot
ˆ
xpcSubtractTime -> Return dierence between two times
Miscellaneous
ˆ
xpcBusyWait -> Wait for specied length of time in seconds
ˆ
xpcIsModelInit -> Return target application load state
En [20], se puede encontrar una modicación de la plantilla grt_main.c y otros cheros relacionados
con RTW para que se pueda disponer de QNX como target. Asimismo, en [21], se pueden encontrar
los archivos necesarios para RTW que permiten disponer de RTLinux como target. Observando el
código en ambos casos, se puede comprobar que las modicaciones incluyen llamadas al sistema
8.2. Trabajo futuro
122
3 que permiten interaccionar con el kernel de tiempo
operativo o el uso de herramientas POSIX
real.
Teniendo en cuenta todo lo anterior, se proponen las siguientes líneas de extensión de este
proyecto:
1. Análisis detallado del código para QNX target y RTLinux target con el n de comprender
mejor su funcionamiento y las posibilidades de interacción de una aplicación cualquiera con
diferentes RTOS.
2. Desarrollo de una interfaz entre Simulink y los RTOS equivalente a los bloques To xPC
Target y From xPC Target, que permita el envío y recepción de información de la aplicación
en tiempo real mediante una conexión TCP/IP.
3. Modicación del entorno para poder utilizar diferentes RTOS, eliminando así la dependencia
exclusiva de xPC target.
3 POSIX
es el acrónimo en inglés de Interfaz de Sistema Operativo Portátil basado en UNIX.