DISEÑO E IMPLEMENT ACIÓN DEL SISTEMA DE …

209

Revista Ingenierías, Universidad de Medellín volumen 6, No. 11, pp. 209-221 - ISSN 1692-3324 - Julio-diciembre de 2007/236p. Medellín, Colombia

Revista Ingenierías Universidad de Medellín

DISEÑO E IMPLEMENTACIÓN DEL SISTEMADE COMUNICACIONES BASADO EN CAN

PARA LA AVIÓNICA EN UN VEHÍCULO AÉREOAUTÓNOMO NO TRIPULADO

Jairo Miguel Vergara Díaz*Andrés Yovanny Agudelo Toro**

Recibido: 17/04/2007Aceptado: 02/05/2007

Resumen

La necesidad de diseñar el sistema de comunicaciones para la aviónica de un minihelicóptero robot basada en la arquitectura distribuida CAN es la propuesta pre-sentada. El sistema de comunicaciones involucra los aspectos de hardware y soft-ware necesarios para permitir el intercambio de datos sobre una red o bus deaviónica desde los sensores y/o hacia los actuadores con el computador central ocomputador de vuelo. La principal característica de la arquitectura es que permiteescalabilidad en la agregación de nuevos dispositivos, garantizando los requerimien-tos temporales necesarios para la adquisición de datos. Se presentan resultados deintercambio de datos sobre la red de aviónica mostrando las frecuencias de opera-ción alcanzadas.

Palabras claveAviónica, CAN, Control, UAV.

* Ingeniero en Instrumentación y Control, especialista en Teleinformática y magíster en Ingeniería Informática, profesor de

tiempo completo, programa de Ingeniería de Sistemas, Universidad de Medellín, e-mail: [email protected]

** Ingeniero de Sistemas, Asistente de investigación, Universidad Eafit, e-mail: [email protected]

210

Universidad de Medellín, Medellín-Colombia.

DESIGN AND IMPLEMENTATION OF ACOMMUNICATION SYSTEM BASED ON CAN FOR

AVIONICS IN A ROBOT MINI-HELICOPTERAbstractThis paper presents the design of the internal communication system foravionics of a robot mini-helicopter based on the CAN distributedarchitecture. The communication system involves several hardware andsoftware aspects related to data exchange on avionics bus fromsensors and actuators with the f light computer. The main characteristicof the architecture is scalability in the addition of new devices,maintaining time requirements for data acquisition. Results of dataexchange on the avionics network showing the reached operating updaterates for each node are shown.

Key WordsAvionics, CAN, Control, UAV.

Jairo Miguel Vergara Díaz, Andrés Yovanny Agudelo Toro

211

INTRODUCCIÓN

Este trabajo presenta el diseño de un modelopara el sistema de comunicaciones de la aviónicapara un vehículo aéreo autónomo (UAV) no tri-pulado denominado COLIBRÍ (Vélez, 2005). Elsistema de comunicaciones está basado en unaarquitectura distribuida CAN (Controller AreaNetwork (Etschberger, 2001)), enfocada en losconceptos de integración, escalabilidad (adiciónsimple de nuevos dispositivos) y cumplimientode estrictos requerimientos temporales. Con elsistema de comunicaciones se busca integrar unconjunto de dispositivos en una sola red, de talforma que pueda establecerse comunicación delos mismos con el computador de vuelo. Los com-ponentes del sistema son en su mayoría disposi-tivos COTS (commercial off-the-shelf). Éstos in-cluyen una unidad de medición inercial (InertialMeasurement Unit o IMU), un magnetómetro,un GPS, un altímetro barométrico y un sonar.Este sistema se ensambló en una caja de aviónicahecha en aluminio de 10x30x18cm la cual seadaptó a los trenes de aterrizaje de un mini-he-licóptero.

Los aspectos de hardware presentados en este ar-tículo involucran elementos como el diseño de lainterfaz CAN para los nodos. Esta interfaz prestala función de tomar la información entregada porlos sensores y transmitirla sobre la red de aviónicahacia el computador de vuelo. Otro elemento dehardware presentado es el diseño de la interfazCAN a través del puerto paralelo (interfaz parale-lo-CAN) para la lectura/escritura de informacióndesde el computador de vuelo hacia los nodos dela red de aviónica.

Los aspectos de software presentados involucranla plataforma de simulación y monitoreo, y algu-nos detalles sobre el sistema de procesamiento dedatos. El computador de vuelo hace uso del siste-ma operativo de tiempo real QNX, especializadopara ejecución de tareas en tiempo real.

Al final de este trabajo, para validar la efectivi-dad de esta arquitectura, se presentan resulta-dos del intercambio de datos entre los nodos yel computador de vuelo, teniendo en cuenta lasfrecuencias en las que éstos operan. Se dan,además, las ventajas de esta arquitectura sobrearquitecturas comúnmente utilizadas para estetipo de aplicaciones (RS-232, RS-485). Se mues-tran lecturas de las mediciones entregadas porla caja de aviónica, tales como velocidades an-gulares y aceleraciones en los ejes (IMU) y elrumbo o heading (magnetómetro). Se presta es-pecial atención a la IMU, pues ésta demandamayores frecuencias de muestreo en el sistemade aviónica (Dittrich, 2002).

DISEÑO DEL SISTEMA DECOMUNICACIONES

Se describe el diseño del sistema de comunicacio-nes en tres partes. La primera parte da la descrip-ción de los sensores seleccionados para laimplementación de la aviónica, en la cual cadasensor es un nodo independiente en la red CAN.Los nodos tienen una interfaz CAN para la comu-nicación de datos con el computador de vuelo através del bus de aviónica.

La segunda parte describe el diseño de la interfazCAN para el computador de vuelo a través delpuerto paralelo, la cual permite el intercambio dedatos entre el mismo y cualquier nodo CAN co-nectado al bus de aviónica.

La tercera parte describe la integración y el mode-lo general de comunicaciones.

Sensores

Para la recolección de datos del entorno del vehí-culo se utilizan sensores, los cuales dependen de lavariable específica que se quiere medir. En el casode la IMU, ésta pertenece al grupo de sensores denavegación y actitud. El control de actitud es uno

Diseño e implementación del sistema de comunicaciones basado en can para la aviónica en un vehículo aéreo...


212


de los más importantes, dadas las característicasdinámicas y aerodinámicas de un helicóptero(Johnson, 1980; Padfield, 1999; Mettler 2002). Parapercibir la actitud de un helicóptero se usan va-rios tipos de sensores: acelerómetros (para mediraceleraciones en los tres ejes) y giróscopos (paramedir velocidades angulares (Corbasí, 1998)), losque conforman la IMU. Mediante una técnica deestimación de variables de estado llamada filtrode Kalman (Rogers, 2000; Myungsoo 1999), sepueden encontrar las variables de estados adicio-nales para conocer la actitud del helicóptero. Aeste procedimiento de estimación también se suma

otro sensor llamado GPS (sistema basado en saté-lites que permite obtener la latitud, la longitud yla altura). Al sistema completo se le conoce comoNIU (Navigation Inertial Unit) (Rogers, 2000) oINS (Inertial Navigation System). Con la adicióndel GPS (Kaplan, 1996) y el magnetómetro se pue-de navegar en tres dimensiones (Corbasí, 1998).La altitud se mide mediante un altímetrobarométrico.

Todos los sensores y actuadores que están conecta-dos a la red CAN tienen un hardware asociadoencargado de la transmisión y recepción de datossobre la red CAN (ver figura 1).

Figura 1: Interfaz CAN para nodos y actuadores.

El microcontrolador PIC18F258 es el encargadode recibir las señales del sensor de acuerdo con eltipo de señal o interfaz que utilice (análoga, digitalo RS-232) y entregar los datos a través de la redCAN.

Diseño de la IMU

Para realizar la medición de las aceleraciones elPIC18F258 utiliza un temporizador La IMU tie-ne la tarea de realizar la mediciones de veloci-dad angular en los ángulos de pitch, roll y yaw(cabeceo, alabeo y guiñada), además de la me-diciones de aceleración en los ejes X, Y y Z. En

la IMU diseñada, el procesador que recibe lasseñales que provienen de los tres acelerómetrosy de los tres giróscopos es también unmicrocontrolador PIC18F258; la razón de utili-zar el PIC18F258 se debe a que éste posee unmódulo CAN integrado.

La ubicación de los sensores para la medición enel eje respectivo es un factor clave, el diseño seestableció formando un cubo, en el cual cada unode sus lados permite alojar ciertos componentesde la IMU. Los giróscopos tienen un rango demedición de 300 grados/seg y los acelerómetrosde 10 g. (Ver figura 2)


213

Figura 2: Diseño 3D final de la IMU

Sistema de posicionamiento global � GPS

Navegar es poder determinar en todo momentola posición, la velocidad y la actitud. Para el casode un UAV, el GPS este es un elemento indispen-sable y la integración entre las mediciones entre-gadas por la IMU y el GPS permiten que la nave-gación sea realizable. El GPS utilizado tiene las si-guientes características: 17 g de peso, 11 mm x 71mm de área, recepción de un máximo de 17 saté-lites, 2 puertos seriales para comunicación y co-rrección diferencial para disminución del error(ver figura 3).

Figura 3: GPS Ublox.

Medición de alturas

En un UAV es necesaria la medición de grandes ybajas altitudes. La medición de baja altitud es útil

para los estados de despegue y aterrizaje; en estecaso se utiliza un sonar altímetro (figura 4.a). Lasmediciones de gran altitud (sobre el nivel del mar)son útiles en el vuelo por encima de los dos me-tros; para ello se utiliza un altímetro barométrico(figura 4.b)

Figura 4: a. Sonar altímetro

Figura 4: b. Altímetro barométrico

Magnetómetro

El magnetómetro o brújula digital (ver figura 5)es un elemento indispensable y necesario para laorientación del UAV. Con este sensor es posibleconocer los grados de orientación (yaw), que tieneel vehículo con respecto al norte magnético, ade-más de mediciones auxiliares que este dispositivoentrega como el pitch y roll.



214


Figura 5: Magnetómetro

Diseño de la interfaz can para el computadorde vuelo

El sensor COTS de velocidad angular escogido esel ADXRS300 de la compañía. Para la recolecciónde la información proveniente desde los sensoresy para el envío de información hacia los actuadorespor parte del computador de vuelo, es necesariauna interfaz CAN que permita la conexión al busde aviónica donde se encuentran conectados to-dos los dispositivos (sensores y/o actuadores). Exis-ten opciones comerciales de interfaces CAN parabus PCI, PCMCIA y arquitectura PC-104, las cua-les tienen una restricción bastante fuerte debidoal consumo de corriente, elemento que afecta deforma sustancial el tiempo de autonomía de vue-lo para el helicóptero, el cual se alimenta pormedio de baterías. Se decidió hacer la interfaz através del puerto paralelo en el modo ECP+EPPque sigue el estándar IEEE 1284 implementadoen 1994, el cual permite obtener un ancho debanda del orden de 500KBps hasta 2MBps, ga-rantizando que no se generen cuellos de botella apartir del ancho de banda requerido para el busCAN que es de 1 Mbps (125KBps).

El diseño de la interfaz se basa en unmicrocontrolador PIC18F258 que se encarga derecibir datos enviados por el computador de vue-lo a través del puerto paralelo y enviarlos sobre la

red CAN para el caso de transmisiones (haciaactuadores) desde el computador de vuelo; el otrocaso es en el que el PIC18F258 recibe datos (desdesensores) a través de la red CAN y los transfiere alcomputador de vuelo por el puerto paralelo parael caso de lecturas.

El consumo de corriente máxima en la interfazCAN del computador de vuelo diseñada es de 100mA, lo cual va a favor del tiempo de autonomíade vuelo y en comparación a una interfaz comer-cial donde el consumo promedio es de 700 mA.La figura 6 ilustra el circuito impreso de la interfazCAN para el computador de vuelo.

Figura 6: Diseño impreso de la interfaz CANpara el computador de vuelo.

Modelo del sistema de comunicaciones

El modelo del sistema de comunicaciones se basaen la conexión del computador de vuelo al bus deaviónica por medio de la interfaz CAN a travésdel puerto paralelo, con lo cual es posible inter-cambiar datos con cualquier nodo CAN conecta-do al bus.

En el modelo del sistema de comunicaciones seutilizaron identificadores de 11 bits para todos losnodos de la red CAN.

CAN es un protocolo de comunicaciones basadoen una arquitectura de bus para la transferencia


215

de mensajes en ambientes distribuidos. Entre susfortalezas está el permitir una arquitectura multi-maestro capaz de proveer características de res-puesta en tiempo real, tolerancia a fallas en larecepción de mensajes y el mal funcionamientode los nodos. Originalmente el CAN fue conce-bido para aplicaciones en el área automotriz, perorápidamente emigró hacia áreas como el controly la automatización industrial, donde los busesde campo (field bus) proveen recursos deconectividad e integración de dispositivos de igualo distinta tecnología.

CAN está estructurado de acuerdo con el modeloOSI en una arquitectura de dos niveles (capa físi-ca y capa de enlace de datos). Distintas opcionesestán disponibles para la capa de aplicación como:CiA CAN Aplication Layer, CANOpen, SDS(Smart Distributed System), DeviceNet y CANKingdom [3]. La capa física se basa en dos líneas:CANL y CANH, por las cuales viajan los datosbajo un esquema de líneas balanceadas o diferen-ciales. La capa de enlace de datos (DLL) está estan-darizada por ISO 11898. Los servicios de la DLL

en un nodo CAN son implementados por las sub-capas de control de enlace lógico (LLC) y de con-trol de acceso al medio (MAC), respectivamente.La subcapa LLC provee las funciones de filtro deaceptación (son aceptados solo los mensajes cuyosidentificadores han sido previamente programa-dos), notificación de sobrecarga y manejo del proce-so de recuperación de errores. La subcapa MACes responsable del empaquetamiento/desempa-quetamiento de los datos, codificación de las tra-mas, manejo de acceso al medio, detección de error,señalización de error y serialización/deserializaciónde datos (Etschberger, 2001). Un factor importan-te con el uso de CAN es el hecho de poder manipu-lar los errores sobre el medio y así tener mayor cer-teza sobre la información que se intercambia entrelos nodos y el computador de vuelo.

En la figura 7 se aprecia la interconexión de todoslos dispositivos (sensores/actuadores) que confor-man la aviónica del UAV a través de la red CAN,además se ilustra la conexión inalámbrica 802.11bhacia la estación en tierra y líneas de alimenta-ción de voltaje.

Figura 7: Modelo general del sistema de comunicaciones.



216


PLATAFORMA DE SIMULACIÓN YMONITOREO

Las redes CAN se utilizan en áreas del control yautomatización industrial como redes Se requirióde una plataforma apropiada para la simulación yel monitoreo de las señales provenientes de lossensores. La plataforma debía ser fácilmentereconfigurable para diversas pruebas de hardwarey de software. Se seleccionó Matlab/Simulink puespermite integrar fácilmente el control con la lec-tura de sensores y los actuadores. Simulink agilizael desarrollo de prototipos y su simulación en tiem-po real es una de las características más atractivas.La integración de la plataforma con el target (equi-po de cómputo que ejecutará la lectura de sensores,control y actuación) se logra con Real-timeworkshop de Simulink. Se escogió QNX 6.3 comoel sistema operativo para la ejecución debido a suscaracterísticas de tiempo real. Un producto co-mercial (RT-LAB) y una plataforma propia han

sido usados para la generación automática de có-digo y la transferencia al target.

Para la comunicación con el target se usaron tec-nologías estándares como Ethernet, 802.11b y losprotocolos UDP/IP y TCP/IP para transferenciade código y monitoreo. El helicóptero, por ejem-plo, está equipado con un puente inalámbrico802.11b. Una WLAN ad-hoc se forma con la com-putadora de vuelo del helicóptero y uno o máscomputadores portátiles que desempeñan el pa-pel de estación de tierra o estaciones de supervi-sión. En pruebas de laboratorio se puede usar unared LAN.

Una sesión normal con la plataforma de simula-ción incluye: ajustar un modelo de Simulink paralas pruebas deseadas, generar código, transferirloautomáticamente al target, ejecutar, conectar ymonitorear. Esto último puede hacerse con gráfi-cas de variables vs. tiempo, un panel de vuelo oun ambiente de realidad virtual (ver figura 8).

Figura 8: Estación en tierra


217

La telemetría durante el vuelo es de gran impor-tancia debido a que las pruebas de vuelo requie-ren una vista actualizada del estado del helicóp-tero. Un blockset de Simulink fue diseñado parasatisfacer esta necesidad. El módulo tomaparámetros del modelo en ejecución y los envíapor la red en paquetes UDP. Se eligió UDP debi-do a que los paquetes de los datos son enviadossin importar la pérdida de los mismos. Esta ca-racterística es deseable para comunicaciones entiempo real.

ARQUITECTURA RS-232 VS CAN

El esquema que presentan la gran mayoría de lossistemas de aviónica actuales para UAV�s es un sis-tema de comunicaciones centralizado basado enRS-232 (Kahn, 2001), lo que genera grandes pro-blemas de escalabilidad en la agregación de nue-vos sensores, como: sensor de presión atmosféri-ca, sensor de temperatura para el tubo de escapedel vehículo, sensor de temperatura para el mo-tor del vehículo, sensor para el nivel del combusti-ble, cámara, etc. Estos podrían ser más, depen-diendo de los propósitos que se definan para eluso del vehículo. Existe una gran limitante para elcomputador de vuelo en cuanto al número deinterfaces RS-232 disponibles, lo cual en los siste-mas de hardware computacional actuales es bas-tante limitado. Para una arquitectura PC-104 co-múnmente usada en UAV podrían ser tres o cua-tro interfaces, y la posibilidad de agregar másinterfaces tendría graves repercusiones tanto enel nivel de procesamiento como en el nivel deconsumo de potencia, factor clave para el tiem-po de vuelo en un UAV. En nuestro caso, se bus-có diseñar un bus de aviónica utilizando la arqui-tectura distribuida CAN que pudiera integrartodos los elementos (sensores y actuadores) delvehículo, garantizando la posibilidad de agregarnuevos componentes de una manera fácil y sinafectar los requerimientos de hardware en el ni-vel de interfaces disponibles.

Otro gran problema tiene que ver con las restric-ciones de tiempo inherentes que posee el medio ouna interfaz RS-232. En los mejores casos, la velo-cidad de transmisión es 57.600bps 0 115.200bps,lo que conlleva a altos niveles de procesamientoen el computador de vuelo para obtener los resul-tados esperados en términos de las acciones decontrol a tomar. Esto no da lugar al mejoramien-to de las frecuencias de muestreo que son necesa-rias por algunos algoritmos de control que seimplementan sobre el computador de vuelo y quepueden proporcionan un mejor funcionamientoen la navegación para el UAV. El modelo RS-485es una arquitectura distribuida y permite obtenergrandes distancias entre los puntos de conexión onodos, pero ésta utiliza el mismo ancho de bandadel RS-232 y no posee las ventajas que proveeCAN. Con una red CAN, el ancho de banda quese puede obtener es de 1Mbps, y con ello se abrela alternativa de poder agregar carga de datos so-bre el medio, teniendo la posibilidad de garanti-zar los requerimientos temporales del vehículo deacuerdo con el sensor o actuador utilizado.

VALIDACIÓN DE LOSREQUERIMIENTOS TEMPORALES

El sistema de software que se ejecuta en el compu-tador a bordo se encarga de ejercer el control so-bre el helicóptero y enviar/recibir informaciónde la estación en tierra (computador portátil). Seestablecen, entonces, cinco tareas básicas: controly filtrado, lectura de sensores, actuación, envío dedatos a la estación en tierra y recepción de coman-dos de la estación de tierra. La ejecución de estastareas se hace a través de un hilo independientepor cada una. El uso de hilos garantiza una mejordistribución de la capacidad de procesamiento yla asignación de los tiempos necesarios para laentrada y salida de datos. El sistema operativo seencarga de repartir los tiempos por tarea. El con-trol y el filtrado se ejecutan entre 50 y 100 Hz. Lalectura de todos los sensores se hace a 250 Hz,aproximadamente.



218


La lectura de datos de los diferentes sensores (no-dos CAN) se realiza de la siguiente manera: cadanodo sensor envía continuamente la informaciónal nodo conectado al computador a bordo; unavez allí, la información es transmitida al computa-dor y ordenada para el procesamiento; cada sensorenvía a frecuencias diferentes; el hilo de lecturaidentifica de qué sensor proviene la informacióny la entrega al módulo de filtrado/control.

Tabla 1: Frecuencias de lecturas obtenidas.

En la tabla 1 se pueden apreciar las frecuenciasobtenidas para los diferentes sensores del UAV.Estas son comparables con las frecuencias co-múnmente utilizadas (Kahn, 2001) descritas enla tabla 2.

Tabla 2: Frecuencias de lecturas típicas.

Lectura típica de los sensores en mensajes por segundo. Cadamensaje contiene dos o tres variables de acuerdo con el sensor.La frecuencia total de lectura para este caso es 260.93 Hz.

Sensor FrecuenciaIMU Acelerómetros 94.73 Hz

IMU Giróscopos 95.12 Hz

Magnetómetro 21.66 Hz

Heading 20.22 Hz

GPS X/VX 6.52 Hz

GPS Y/VY 6.26 Hz

GPS Z/VZ 6.13 Hz

La frecuencia total de lectura para este caso es 255 Hz.

Sensor Frecuencia

IMU Acelerómetros 100 HzIMU Giróscopos 100 Hz

Magnetómetro 20 Hz

Heading 20 Hz

GPS X/VX 5 Hz

GPS Y/VY 5 Hz

GPS Z/VZ 5 Hz

Figura 9: Lectura de acelerómetros


219

Figura 10: Lectura de giróscopos

En las figuras 9 a 11 se muestran diferentes lectu-ras de señales de sensores (IMU y magnetómetro)tomadas por el computador.

La figura 9 muestra el registro de los datos paralas aceleraciones en los ejes X, Y y Z; para éstas seagitó la caja en el eje Z, X, y luego Y, respectiva-mente. La figura 10 muestra las velocidades an-gulares p, q y r. La figura 11 muestra el cabeceo,alabeo y guiñada. Todas las mediciones fueron al-macenadas con las frecuencias mostradas en latabla 1. Los datos fueron registrados con la co-nexión del sistema completo (caja de aviónica/computador de vuelo/estación en tierra). Figura 11: Lectura de magnetómetro.



220


Los estímulos se aplicaron de tal manera que seafectó cada variable de forma independiente parauna mejor visualización.

CONCLUSIONES

La idea de desarrollar un sistema de comunica-ciones basado en la arquitectura distribuidaCAN para un UAV fue terminada completamen-te, y la escogencia de la arquitectura distribuidaCAN fue un acierto, ya que sus característicaspermiten llegar a aplicaciones como la de unbus de aviónica. La adición de dispositivossensores y/o actuadores para el UAV es una rea-lidad tangible.

La adición de nuevos nodos sensores y/oactuadores al bus de aviónica está contempla-da en el diseño hardware/software, y así seposibilita el intercambio de información en-tre el computador de vuelo y un nodo CANcualquiera.

Para cada nodo se calculó el tiempo de lectura dedatos y se obtuvieron las frecuencias de operación.Con ello se realizó la validación de los requeri-mientos temporales para el intercambio de datoscon el computador de vuelo.

La figura 12 muestra el diseño definitivo de la cajade aviónica, ensamblada conjuntamente con elmini-helicóptero.

Figura 12: Mini-helicóptero con la caja deaviónica.

BIBLIOGRAFÍA

CORBASÍ, A. Sistema de navegación. McGraw Hill, 1998.

DITTRICH, Joerg S. Design and integration of an unmanned aerial vehicle navigation system. Thesis the Master of Science inAerospace Engineering, 2002.

ETSCHBERGER, Konrad. Controller area network- basics, protocols, chips and applications. IXXAT AutomationGmbH, 2001.

HELFRICK, A. Principles of avionics. Avionics Communications, 2002.

JOHNSON, W. Helicopter theory. Dover, 1980.

KAHN D., Aaron. The desing and development of a modular avionics system. Thesis the Master of Science in AerospaceEngineering, 2001.

KAPLAN, E. Understanding GPS principles and applications. Artech House, 1996.

METTLER, B.; TISCHLER, M. B.; KANADE, T. System identification modeling of a small-scale unmanned rotorcraft forflight control design. American Helicopter Society Journal, Vol. 47, No. 1, pp. 50-63, 2002.

MYUNGSOO, J. State estimation via sensor modeling for helicopter control using and indirect kalman filter. Proceedings IEEE

International Conference, 1999.


221

PADFIELD, G. D. Helicopter flight dynamics: the theory and application of flying qualities and simulation modelling. AIAA

Education Series, pp. 514, 1999.

ROGERS, R. Applied mathematics in integrated navigation systems. Education Series AIAA, 2000.

VÉLEZ, C. M.; AGUDELO, A. Multirate control of an unmanned aerial vehicle. WSEAS Transactions on Circuits and Systems,

Vol. 4, No.11, ISSN 11092734, pp. 1628-1634, 2005.



Documents

DISEÑO E IMPLEMENT ACIÓN DEL SISTEMA DE …