Técnicas de control a través de red inalámbrica de vehículo basado en péndulo invertido

T´ ECNICAS DE CONTROL A TRAV´ ES DE RED INAL ´ AMBRICA DE VEH´ ICULO BASADO EN P´ ENDULO INVERTIDO J. Arriaga, P. Mill´an, I. Jurado, C. Vivas y F.R. Rubio Departamento de Ingenier´ıa de Sistemas y Autom´atica, Universidad de Sevilla, Espa˜na arriaga,pmillan,ijurado,viv[email protected] y [email protected] Resumen Este trabajo presenta la aplicaci´on de una t´ecnica de control robusto H∞en el contexto de sistemas controlados a trav´es de redes (NCS). La aplicaci´on se lleva a cabo sobre un Veh´ıculo personal basado en P´endulo Invertido (PPCar) que se controla remotamente a trav´es de una red de comunicaciones inal´ambrica tipo Bluetooth. El trabajo realiza un estudio comparativo del comportamiento de esta t´ecnica de control frente a un control cl´asico LQR, presentando resultados experimentales que ponen de manifiesto las dificultades intr´ınsecas de control a trav´es de redes. Palabras clave: P´endulo Invertido, Control a trav´es de redes, Control Robusto. 1. INTRODUCCI ´ ON Esta ´ultima d´ecada ha sido testigo de un notable desarrollo de las tecnolog´ıas de comunicaci´on inal´ambricas, que han motivado la aparici´on de una amplia variedad de aplicaciones en multitud de disciplinas. La ingenier´ıa de control no es ajena a estos desarrollos y podemos observar c´omo en los ´ultimos tiempos son cada vez m´as frecuentes los trabajos y sesiones t´ecnicas especializadas dedicadas al control de sistemas din´amicos a trav´es de redes de comunicaciones, o NCS (Networked Control Systems) en su denominaci´on anglosajona. Los sistemas NCS son aquellos en los cuales los diferentes elementos del lazo de control (sensores, controladores y actuadores) se encuentran f´ısicamente distribuidos y unidos a una red de comunicaciones de prop´osito general, compartiendo ancho de banda con otras aplicaciones, no necesariamente relacionadas con el control. El empleo de tecnolog´ıas de control a trav´es de redes de comunicaciones presenta m´ultiples ventajas respecto a los sistemas tradicionales, como son arquitecturas m´as flexibles, reducci´on de costes de instalaci´on y mantenimiento, posibilidades de control remoto de dispositivos m´oviles mediante enlaces inal´ambricos, etc. Consecuentemente, las tecnolog´ıas NCS encuentran aplicaci´on en la actualidad en campos tan variados como el control de tr´afico en autov´ıas [9] o intervenciones quir´urgicas remotas [8]. Sin embargo el uso de redes de comunicaci´on no dedicadas, en contraste con los tradicionales enlaces de comunicaciones independientes dedicados a control, introduce una serie de interesantes desaf´ıos desde el punto de vista del dise˜no de controladores, protocolos de comunicaciones, arquitecturas de control, y en general todos los elementos asociados al lazo de control. El control NCS surge as´ı como una disciplina h´ıbrida de las, hoy d´ıa bien establecidas, teor´ıa de control autom´atico y tecnolog´ıa de telecomunicaciones. Tradicionalmente la teor´ıa de control se ocupa de sistemas din´amicos interconectados a trav´es de enlaces de comunicaciones ideales (instant´aneos, sin p´erdidas, etc), mientras que la tecnolog´ıa de telecomunicaciones se ocupa de la transmisi´on de informaci´on sobre canales imperfectos. Una combinaci´on de ambos marcos es necesario para modelar apropiadamente un sistema NCS. El presente trabajo trata de poner manifiesto algunas de las peculiaridades asociadas a los sistemas de control NCS, presentando un an´alisis comparativo sobre resultados experimentales del comportamiento del comportamiento de una t´ecnica de control cl´asico frente a t´ecnicas espec´ıficas NCS. Concretamente, se plantea el control de un Veh´ıculo personal basado en P´endulo Invertido (PPCar) a trav´es de una red de comunicaciones inal´ambrica tipo Bluetooth. El sistema es especialmente apropiado para ejemplificar los problemas asociados al control NCS, debido a que se trata de un sistema de din´amica inestable relativamente simple, aunque f´acil de estabilizar si se aplican las hip´otesis del control cl´asico. La dificultad de control se pone de manifiesto en este trabajo al comparar el comportamiento de un control cl´asico LQR dise˜nado bajo la hip´otesis de enlace de comunicaciones perfecto frente a una t´ecnica de control H∞adaptado a las condiciones de tiempo de muestreo variable y p´erdida de informaci´on asociado a sistemas NCS. El art´ıculo se ha estructurado del siguiente modo: En primer lugar, en la secci´on 2, se describen los aspectos m´as relevantes de las arquitectura hardware y software del sistema PPCar. A continuaci´on, la secci´on 3 describe el modelo din´amico no lineal del sistema que se emplear´a para el dise˜no de controladores. En la secci´on 4 se describen las estrategias de control local LQR y control NCS H∞que se ensayan en este trabajo. Para finalizar, la secci´on 5 describe los resultados experimentales obtenidos y realiza una breve discusi´on de los mismos. 2. DESCRIPCI ´ ON DEL SISTEMA Se ha trabajado con un veh´ıculo personal basado en p´endulo invertido, el PPCar -Personal Pendulum Car-, descrito en [5]. Dicho veh´ıculo, destinado al transporte de personas, est´a montado sobre dos ruedas paralelas donde el p´endulo est´a constituido por la persona que est´a sobre el veh´ıculo, que se apoya sobre una barra de control. En la fig. 1 se representa un esquema del veh´ıculo. El movimiento de avance est´a provocado por la inclinaci´on de la persona con respecto a la posici´on de equilibrio, la verticalidad. De hecho, los controladores calculados para lograr la verticalidad se han dise˜nado teniendo en cuenta tan s´olo el movimiento en l´ınea recta del veh´ıculo, mientras que el movimiento de rotaci´on es controlado directamente por el piloto mediante un dispositivo el´ectrico ubicado en el pu˜no. En los trabajos anteriores con este veh´ıculo, se trabaj´o siempre utilizando como n´ucleo del sistema un microcontrolador ubicado en el propio veh´ıculo, que recog´ıa la informaci´on de los sensores y a partir de dicha informaci´on calculaba las acciones de control. Adicionalmente, el microcontrolador se comunicaba con una estaci´on base (un PC) mediante un software dise˜nado a tal efecto que permit´ıa ajustar los par´ametros de los controladores en l´ınea y capturar informaci´on relevante. Sin embargo, en este trabajo el microcontrolador ha quedado como simple int´erprete de ´ordenes: al PC le sigue llegando la informaci´on, pero es ´este (mediante un nuevo software) que calcula las acciones de control. El PC transmite las consignas al microcontrolador, que se limita a transferirlas a los motores. De hecho, si se dispusiera de sensores externos para obtener el estado del sistema, podr´ıamos enviar directamente las consignas a la controladora de los motores sin necesidad de intervenci´on del microcontrolador. Figura 1: Esquema del veh´ıculo 2.1. ARQUITECTURA HARDWARE La plataforma donde debe montarse el piloto va sostenida por el eje de las ruedas, de radio 17.5 cm, cada una de ellas conectada a un motor alimentado a 24 V y capaces de llegar a 240 rpm. Figura 2: Diagrama de bloques del sistema La fig. 2 representa un diagrama de bloques del conjunto. El n´ucleo del sistema es un microcontrolador de 8 bits de bajo coste, el modelo Atmega128 de Atmel, que se comunica con los distintos perif´ericos a trav´es de diferentes puertos. El microcontrolador lleva incorporado un reloj interno de 16 Mhz, lo que ha permitido en trabajos anteriores utilizar tiempos de muestreo de decenas de milisegundos. Al microcontrolador se conectan: Dos encoders, uno por cada rueda. Se emplean para medir las velocidades de ambas. Un sensor de inclinaci´on MicroStrain, que incorpora preprocesamiento de se˜nal basada en filtro de Kalman. Un sensor para indicar la consigna de giro, ordenada por el piloto a trav´es de un pu˜no con resistencia variable. Una controladora conectada a los dos motores, Roboteq AX1550, se comunica con el con- trolador a trav´es de una de las dos UARTs que posee. Finalmente, un radio-m´odem bluetooth HandyPort HPS-120 que trabaja en la banda de 2.4 Ghz, se conecta al microcontrolador a trav´es de la segunda UART y al PC en el otro extremo mediante el puerto serie (tambi´en con interfaz RS-232). Una caja de control conectada tanto a la controladora de los motores como al microcontrolador y que tiene la potestad de detener la acci´on de ambos. El equipo PC de la estaci´on base es un Pentium IV a 2.80 Ghz de frecuencia de reloj con 512 MB de memoria RAM. La controladora AX1550 permite obviar el problema de la alimentaci´on de los motores: recibe las consignas del microcontrolador y se ocupa de mantener la consigna a ambos motores. En la fig. 3 se ilustra la arquitectura completa del sistema. Figura 3: Arquitectura del sistema 2.2. SOFTWARE DEL MICROCONTROLADOR El software para el microcontrolador se ha basado en el sistema operativo para sistemas embebidos TinyOS, programando en lenguaje nescC. Se parti´o de la base del trabajo original reutilizando gran parte del c´odigo. TinyOS es un software de c´odigo abierto con una estructura de m´odulos jer´arquica que permite al programador abstraerse del hardware, as´ı como reutilizar c´odigo de manera sencilla. NesC permite desarrollar programas compactos que consuman poca memoria, basados en un n´ucleo multihilo con dos tipos de estructuras: tareas y eventos. Para poder tener un sistema de control en tiempo real se program´o un reloj de tiempo real de 10ms de per´ıodo que dota al sistema de una base de tiempo para poder realizar las tareas necesarias. Para las comunicaciones por puerto serie, tanto para lectura de datos de los sensores como para la comunicaci´on con el PC, se han utilizado interrupciones. Para el desarrollo del software empleado se aprovech´o el desarrollo original; tal y como estaba previsto, la estructura basada en m´odulos facilit´o enormemente la reprogramaci´on al abstraernos del nivel de hardware. De este modo, empleamos los m´odulos de convertidor anal´ogico/digital, puerto serie, encoder y temporizaci´on. 2.3. SOFTWARE DE PLATAFORMA PC Como ya se ha mencionado, la comunicaci´on entre microcontrolador y PC se lleva a cabo mediante comunicaci´on inal´ambrica siguiendo el protocolo Bluetooth en su versi´on 1.1 (norma IEEE 802.15.1-2002); sin embargo, al estar conectado ese m´odem al puerto serie, el programador trabaja directamente sobre el interfaz RFCOMM. La capa de control y adaptaci´on del enlace l´ogico (L2CAP) y la capa f´ısica quedan abstraidas del programador. La tasa de bits (configurable) elegida fue de 19200 bits/s. Se estudi´o la posibilidad de emplear TCP/IP sobre PPP, sin embargo eso hubiera implicado la instalaci´on de dichos protocolos en el sistema operativo TinyOS y hubiera complicado innecesariamente el sistema: en su lugar, creamos un protocolo simple de comunicaci´on que no posee control de flujo ni de errores (aunque s´ı detecci´on de ´estos). El protocolo implementado consta de tres tipos de PDUs: las tramas de conexi´on, las de asentimiento y las de datos. PDU de conexi´on: son tramas simples, de un s´olo octeto, cuyo objetivo es arrancar o detener el veh´ıculo; debido a su naturaleza cr´ıtica son las ´unicas que requieren asentimiento. PDU de asentimiento: s´olo se utilizan en respuesta a las anteriores. Tambi´en de un s´olo octeto. PDU de datos: compuestas por una cabecera, un pie, un n´umero par de octetos de informaci´on (si hace falta se a˜nade un octeto nulo al final para lograr un n´umero par) y dos octetos de checksum. El software instalado en la estaci´on base (PC) se desarroll´o en C empleando el entorno de desarrollo Dev-C++. Para la comunicaci´on con el puer- to serie se utiliz´o la biblioteca LnxComm [3], que permite de forma sencilla la programaci´on multiplataforma (windows o *NIX) del puerto serie abstrayendo al programador de las particularidades del sistema operativo. El programa consta de dos hilos, el de recepci´on de datos (prioritario) y el de generaci´on de consignas: el hilo de recepci´on controla el flujo del programa, escuchando el puerto serie a la espera de una trama de datos; al recibirla, cede brevemente el control del flujo al hilo de generaci´on de consignas para que, a partir de la informaci´on que acaba de recoger (y procesar), pueda calcular y enviar la se˜nal de control de vuelta al veh´ıculo. Para la creaci´on de los hilos y la sincronizaci´on entre ´estos se emple´o el sistema de eventos de Win32; se plantea la conveniencia de emplear hilos POSIX para asegurar la portabilidad del c´odigo a plataformas *NIX. Ambos hilos comparten informaci´on a trav´es de una estructura de tipo CARRO, que contiene informaci´on sobre el puerto l´ogico que soporta la conexi´on, el estado actual del veh´ıculo y la consigna que se env´ıa. Dicha estructura puede ser ampliada de acuerdo con las necesidades del momento con estados (y consignas) anteriores o futuras. El programa recibe la informaci´on y env´ıa la orden de control de forma cont´ınua hasta que se cumple un m´aximo de iteraciones preestablecido o bien hasta que el operador de la estaci´on base decida terminar. Cuando eso ocurre, se almacena en un fichero de registro toda la informaci´on obtenida (instante de tiempo en que se recogen muestras, contenido de ´estas, se˜nal de control enviada) en un formato adecuado para su lectura y procesamiento con software espec´ıfico (MATLAB, Octave). Es importante resaltar el hecho de que no existe temporizaci´on en la plataforma PC: s´olo el microcontrolador lleva su propio temporizador que cada 10 ms (un ciclo de reloj) recaba datos, y cada cier- to n´umero de ciclos env´ıa informaci´on. En el desarrollo del software de control y monitorizaci´on tan s´olo hemos de preocuparnos de que el programa reciba la informaci´on y procese y env´ıe la respuesta lo antes posible: el microcontrolador aplicar´a la se˜nal de control de forma as´ıncrona. Si una de las tramas llega con errores, se desecha y se espera a la siguiente; puesto que el tiempo es cr´ıtico en nuestro sistema, no podemos permitirnos pedir y esperar un reenv´ıo. El programa incorpora un mecanismo de seguridad de tal forma que si llega un n´umero determinado (y configurable) de tramas err´oneas, se detiene el veh´ıculo y se corta la conexi´on. El programa incluye una funci´on “controlador” que devuelve una se˜nal de control entera a partir de los datos que obtiene; dichos datos, que conforman el estado y est´an almacenados en la estructura de tipo CARRO, son empleados para calcular la se˜nal de control. Si se desea programar un nuevo controlador, es tan sencillo como implementarlo en dicha funci´on. 3. OBTENCI ´ ON DEL MODELO DIN ´ AMICO DEL SISTEMA En esta secci´on se detalla el proceso de obtenci´on del modelo matem´atico del sistema. En la fig. 1 se ha representado el subsistema constituido por el p´endulo invertido sobre plataforma m´ovil. Del balance de fuerzas sobre el eje horizontal, se obtienen la ecuaci´on (1). (M+m)¨x+Ml¨ θcosθ −Ml ˙ θ2sinθ =F(1) donde: M = 70 Kg, masa del p´endulo (incluyendo al piloto). l = 1m, longitud del brazo del p´endulo. m = 35 Kg, masa del carro. g = 9.81 m/s2, aceleraci´on de la gravedad. F = fuerza aplicada por los motores sobre el carro. x= desplazamiento lineal del carro. θ= ´angulo de inclinaci´on del p´endulo. Del balance de momentos se obtiene la ecuaci´on (2). ¨xMlcosθ +Ml2¨ θ−Mglsinθ = 0 (2) Combinando las ecuaciones anteriores pueden despejarse las segundas derivadas de la posici´on y la inclinaci´on. Resulta sencillo comprobar que este sistema tiene dos equilibrios, el estable (´angulo de inclinaci´on 180o), y el inestable (´angulo 0o), que corresponde al p´endulo en posici´on vertical. Si se linealiza en torno al punto de equilibrio inestable, se obtiene el siguiente sistema descrito ya en espacio de estados:   ˙ θ ¨ θ ¨x  =  0 1 0 (M+m)g ml 0 0 −Mg m0 0    θ ˙ θ ˙x  +  0 −1 ml 1 m  F(3) 3.1. MODELADO DE LA RED A la hora de dise˜nar cualquier controlador a trav´es de la red, resulta imprescindible conocer el retraso de la red. A lo largo de varias pruebas, se han recabado datos de tiempos de propagaci´on de paquetes simples (un octeto) a trav´es de la red. Programamos el PC y el veh´ıculo para enviar y recibir paquetes de forma instant´anea, con el menor procesamiento posible. Se hizo un m´ınimo de 200 env´ıos y recepciones para cada una de las bater´ıas de pruebas, en las que el veh´ıculo fue desplazado para simular distintas posiciones con o sin visi´on directa. Finalmente se almacen´o un total de 2500 muestras de tiempos; comoquiera que en ese tiempo se incluyen tanto el env´ıo como el asentimiento, hubo que dividir cada una de esas medidas por la mitad. As´ımismo, hubo que restarle el tiempo de env´ıo asociado al r´egimen binario. Una vez procesados, los datos arrojaron los siguientes resultados: Valor medio: 23.34 ms. Desviaci´on t´ıpica: 1.8662. Valor m´ınimo del retraso: 18 ms. Paquetes perdidos: 0.04 La figura fig:retrasos muestra c´omo los datos siguen una distribuci´on normal con la media y la distribuci´on t´ıpica calculada. 5 10 15 20 25 30 35 40 45 50 Distribucion de los retrasos de la red Retraso (ms) Figura 4: Distribuci´on de los retardos en la red 4. DISE ˜ NO DE CONTROLADORES Para poner de manifiesto las peculiaridades de control a trav´es de redes, se plantea en este trabajo una comparaci´on del comportamiento un control cl´asico LQR, dise˜nado para el PPCar bajo la hip´otesis de enlace perfecto de comunicaciones frente a un control robusto H∞que si tiene en cuenta aspectos propios de NCS, tal como tiempos de muestreo no uniformes y eventuales p´erdidas de paquetes de informaci´on. Se describe a continuaci´on el procedimiento de dise˜no de cada una de estas t´ecnicas de control. 4.1. DISE ˜ NO DE CONTROLADOR LOCAL El controlador LQR es un control por realimentaci´on de estados de la forma: u=−Kx (4) donde la se˜nal de control u, y la constante de realimentaci´on Kse obtiene a partir de un problema de minimizaci´on del funcional de costes J, definido en (5). J=Z∞ 0 (x0Qx +u0Ru)dt.(5) Las matrices Q y R penalizan respectivamente el error del estado y el esfuerzo de control. La soluci´on del problema LQR para el sistema (3) obtiene el siguiente controlador: u=F=−Kx =−K1θ−K2˙ θ−K3˙x(6) donde los par´ametros K var´ıan en funci´on de los par´ametros de las matrices Q y R. En este caso, con el objetivo de comparar un controlador cl´asico dise˜nado sin tener en cuenta la red de comunicaciones, se adopta el dise˜no recogido en [5]: Q=  100 0 0 0 100 0 0 0 1  R= 0,1,(7) lo que nos lleva a la siguiente soluci´on: K1= 2070 K2= 385 K3= 3,2.(8) La fig. 5 muestra el buen comportamiento del controlador LQR obtenido en simulaciones de control local. Anteriores experiencias aplicando este control en el microcontrolador dieron lugar a resultados coherentes con la simulaci´on. Figura 5: Simulaci´on del controlador LQR 4.2. DISE ˜ NO BASADO EN RED DE UN CONTROLADOR ROBUSTO H∞ En esta secci´on se describe el proceso de dise˜no y aplicaci´on al de un controlador robusto H∞basado en red, propuesto en [6]. En la secci´on 4.2.1, se detalla el modelado de sistemas para el dise˜no del controlador, y se enuncian las hip´otesis fundamentales. En la secci´on 4.2.2 se detalla el procedimiento de dise˜no del controlador. Por ´ultimo en la secci´on 4.2.3, se resuelve el problema de control para el caso del PPcar. 4.2.1. Modelado para el control En esta secci´on se va a considerar un sistema con incertidumbres param´etricas de la forma: ˙x(t)=[A+4A(t)]x(t)+[B+4B(t)]u(t) + Bww(t) (9) x(t0) = x0 z(t) = Cx(t) + Du(t) donde x(t)∈Rnxn,u(t)∈Rm,z(t)∈Rqson el vector de estados, la se˜nal de control y la salida controlada respectivamente. x0∈Rndenota la condici´on inicial; A,B,Bw,CyDson matrices constantes de dimensiones apropiadas y 4A(t) y 4B(t) son las incertidumbres param´etricas, que satisfacen: [4A(t)4B(t)] = GF(t)[EaEb],(10) donde G,EayEbson matrices constantes de dimensiones apropiadas y F(t) es una matriz desconocida variable en el tiempo, que es medible en el sentido de Lebesque en ty satisface FT(t)F(t)≤ I. Por otra parte w(t)∈L2[t0,∞) denota a las perturbaciones externas. La presencia de una red entre el controlador y la planta causa a menudo retrasos de transmisi´on y p´erdida de datos que pueden degradar el comportamiento en bucle cerrado del sistema [7]. En presencia de una red de control, bajo ley de control lineal, el sistema (9) se puede escribir de la siguiente forma: ˙x(t)=[A+4A(t)]x(t)+[B+4B(t)]u(t) + Bww(t) (11) z(t) = Cx(t) + Du(t), t ∈[ikh+τk, ik+1h+τk+1) u(t+) = Kx(t−τk), t ∈ikh+τk, k = 1,2, ... donde h es el periodo de muestreo, ik(k= 1,2,3, ...) son enteros tal que {i1, i2, i3} ⊂ {1,2,3, ...}. Por otra parte τkdenota el retraso temporal desde el instante ikhcuando el sensor muestrea la planta hasta el instante en el que el actuador aplica la se˜nal de control correspondiente. Se asume que u(t) = 0 hasta que la primera se˜nal de control alcanza la planta. Obviamente se tiene que S∞ k=1[ikh+τk, ik+1h+τk+1) = [t0,∞), t0⩾0. Es importante remarcar que {i1, i2, i3, ...}es un subconjunto de {1,2,3, ...}. No se requiere por tanto la condici´on ik+1 > ik. Cuando i1, i2, i3= 1,2,3, ... significa que no se han producido p´erdidas de paquetes durante la trasmisi´on. Si ik+1 =ik+ 1 esto implica necesariamente que h+τk+1 > τk, caso que incluye como condiciones particulares τk= ˆτyτk< h, con ˆτconstante. A continuaci´on se enuncian las dos hip´otesis en las que se basa el desarrollo posterior: Hip´otesis 1. El sensor es peri´odico, mientras que el controlador y el actuador se ejecutan tan pronto como disponen de una nueva se˜nal (basados en eventos). Hip´otesis 2. Existen dos constantes η > 0 y τm> 0 tal que: (ik+1 −ik)h+τk+1 ⩽η, k = 1,2, ... (12) τm⩽τk, k = 1,2, ... (13) donde η⩽τm. Bajo la Hip´otesis 2, el sistema (11) puede ser escrito de forma equivalente como sigue: ˙x(t)=[A+4A(t)]x(t) + [B+4B(t)] ×Kx(ikh) + Bww(t),(14) x(t) = Φ(t, t0−η)x(t0−η) . =φ(t), t ∈[t0−η, t0],(15) z(t) = Cx(t) + DKx(ikh), t∈[ikh+τk, ik+1h+τk+1) (16) donde Φ(t, t0−η) es una soluci´on de ˙ Φ(t, t0−η) = [A+4A(t)]Φ(t, t0−η), t∈[t0−η, t0]. Definici´on. El sistema (14)-(16) es exponencialmente estable y robusto con norma H∞acotada por γsi se cumplen las siguientes condiciones: 1. El sistema (14)-(16) con w(t)≡0 es exponencialmente estable de manera robusta, es decir, existen unas constantes α > 0 y β > 0 tal que kx(t)k ≤ α supt0−η≤s≤t0kΦ(s)ke−βt, t≥t0, para todas las incertidumbres admisibles 4A(t) y 4B(t). 2. Bajo condiciones iniciales nulas, la salida controlada z(t) satisface kz(t)k2≤γkw(t)k2para toda perturbaci´on w(t)∈L2[0,∞). 4.2.2. Dise˜no del controlador robusto A continuaci´on se enuncia un teorema que permite dise˜nar, teniendo en cuenta la red de comunicaciones, el controlador Kdel sistema resolviendo un sistema de LMIs. Teorema 1 [6]: Dados los escalares ρl(l= 1,2,3,4), τm,ηyγ, si existen matrices ˜ Pk(k= 1,2,3), ˜ Tj>0, ˜ Rj>0 (j= 1,2), una matriz no singular Xy cualesquiera matrices ˜ Ni˜ Si (i= 1,2,3,4) de dimensiones apropiadas, as´ı como un escalar µ > 0 tal que: µΦ11 ∗ Φ21 Φ22 ¶<0 (17) µ˜ P1˜ P2 ˜ PT 2˜ P3¶>0 (18) donde Φ11 =    Σ11 ∗∗∗ Σ21 Σ22 ∗ ∗ Σ31 Σ32 Σ33 ∗ Σ41 Σ42 Σ43 Σ44     Φ21 =         τ0˜ P30−τ0˜ P3τ0˜ PT 2 η˜ NT 1η˜ NT 2η˜ NT 3η˜ NT 4 δ˜ ST 1δ˜ ST 2δ˜ ST 3δ˜ ST 4 CXTDY 0 0 −BT w−ρ2BT w−ρ3BT w−ρ4BT w EaXTEbY0 0         Φ22 =diag(−τ0˜ T2−η˜ R1−δ˜ R2−I −γ2I−µI) Σ11 =˜ P2+˜ PT 2+˜ T1+τ0˜ T2+˜ N1 +˜ NT 1−AXT−XAT+µGGT, Σ21 =˜ N2−˜ NT 1+˜ ST 1−ρ2AXT −YTBT+µρ2GGT, Σ31 =˜ N3−˜ PT 2−˜ ST 1−ρ3AXT+µρ3GGT, Σ41 =X−˜ N4−˜ PT 1−ρ4AXT+µρ4GGT, Σ22 =−˜ N2−˜ NT 2+˜ S2+˜ ST 2−ρ2BY −ρ2BTYT+µρ2 2GGT, Σ32 =−˜ N3+˜ S3−˜ ST 2−ρ3BY +µρ3ρ2GGT, Σ42 =−˜ N4+˜ S4+ρ2X−ρ4BY +µρ4ρ2GGT, Σ43 =−˜ S4+ρ3X+µρ4ρ3GGT, Σ44 =ρ4X+ρ4XT+η˜ R1+ 2, δ ˜ R2+µρ2 4GGT, entonces, bajo el controlador u(t) = Kx(t), con K=Y X−T, el sistema (11) con una red de control satisfaciendo la Hip´otesis 2 es exponencialmente estable y robusto con norma H∞acotada por γ. Demostraci´on: La demostraci´on del Teorema 1 se encuentra desarrollada en detalle en [6]. 4.2.3. Aplicaci´on del controlador al PPcar El sistema bajo estudio, descrito por (3), puede escribirse directamente en la forma (9) con s´olo definir de forma adecuada las matrices ∆A, ∆B yBw, seg´un las perturbaciones e incertidumbres que deseen incluirse. En este estudio, se va a considerar incertidumbre en la masa del piloto M, que se denotar´a por ∆M. Como perturbaci´on principal se va a considerar el viento, que influye sobre el carro y el piloto. Esto se puede modelar como una fuerza resultante Wdel perfil de viento, que se repartir´a entre la base del carro con un porcentaje cmy el centro de gravedad del p´endulo en un porcentaje cM. La fig. 6 ilustra este fen´omeno. De Figura 6: Viento incidiendo sobre el veh´ıculo esta forma se obtiene: ∆A=  0 0 0 ∆Mg ml 0 0 −∆Mg m0 0   ∆B=  0 0 0   Bw=  0 cM ml −cm ml cm l  W Para una incertidumbre de ∆M= 1Kg, se obtiene, resolviendo el problema de LMI planteado en el Teorema 2, el siguiente controlador: K1= 1550 K2= 412 K3= 53 (19) 5. PRUEBAS Y RESULTADOS Tras las simulaciones, se llevaron a cabo dos pruebas reales con el veh´ıculo: en ambas, el objetivo fue, partiendo de unas condiciones de contorno, estudiar el comportamiento de ambos controladores tratando de estabilizar el sistema. Es importante advertir que nuestro modelo matem´atico adolece de una grav´ısima debilidad: no modela adecuadamente el efecto del piloto. ´ Este ejerce un par de fuerzas sobre la base y el p´endulo, haciendo que su comportamiento sea impredecible; es por eso que tendemos a considerarlo como una perturbaci´on, y ser´a la resistencia frente a la perturbaci´on la que nos informe de la bondad de nuestro control. La primera prueba se llev´o a cabo programando en la aplicaci´on de PC un control por realimentaci´on por espacio de estados: concretamente, el LQR ya expuesto. Puede apreciarse que la perturbaci´on hace imposible estabilizar el sistema: al mantener la consigna durante 30 ms en lugar de los 10 ms del control local, ´esta no puede reaccionar lo suficientemente r´apido a los cambios en el sistema. El sistema no se inestabiliza, pero tampoco logra alcanzar el reposo que marcar´ıa la estabilidad asint´otica. La segunda prueba consisti´o en la programaci´on, tambi´en por realimentaci´on del espacio de estados, del controlador H∞mediante LMI ya calculado. 0 5 10 15 −0.15 −0.1 −0.05 0 0.05 0.1 Estabilizacion del pendulo frente a perturbaciones tiempo (s) inclinacion (rad) LQR LMI Figura 7: Estabilizaci´on del p´endulo La comparaci´on entre ambas curvas (LQR en l´ınea punteada, LMI con l´ınea cont´ınua) muestra c´omo el controlador H∞logra estabilizar el sistema de forma m´as r´apida, siendo mucho menos sensible a las perturbaciones. Comoquiera que las perturbaciones son consustanciales al sistema, debido a la inevitable acci´on del piloto, el controlador resulta mucho m´as conveniente. Naturalmente, los retardos asociados a la red inal´ambrica son los que convierten en cr´ıticas las perturbaciones, ya que el sistema no es capaz de reaccionar a ´estas con tanta rapidez como en el caso del control local. Agradecimientos Los autores agradecen a CICYT por financiar este trabajo bajo el proyecto DPI2007-64697. Referencias [1] Astr¨om, K.J., Furuta, K., (1996) “Swingingup a pendulum by energy control”, Proc. IFAC Congress, pp. 37-95. [2] Clark, M.A., Field, J.B., McMahon, S.G., Philps, P.S., Cazzolatto, B.S., (2005) “Edgar, a self-balancing scooter”, Project Final Report. University of Adelaide, Australia [3] Pujaico F., “LnxComm, Linux Communication: Tutorial y Gu´ıa de Referencia” [4] Rubio, F.R., L´opez, M.J., “Control adaptativo y robusto” (2006), Universidad de Sevilla [5] Viguria, A., Prieto, M., Fiacchini, M., Cano, R., Rubio, F.R., Aracil, J., Canudas-de-Wit, C., (2006) “Desarrollo y experimentaci´on de un veh´ıculo basado en p´endulo invertido (PP- Car)”, Revista Iberoamericana de Autom´atica e Inform´atica Indistrial. Vol. 3, Num. 4, pp. 54-66, [6] Yue, Dong and Han, Qing-Long and Lam, James, (2005) “Network-based robust H∞control of systems with uncertainty”, Automatica. Vol. 41, Num. 6, pp. 999-1007, [7] ,Zhang, W. and Branicky, MS and Phillips, SM, “Stability of networked control systems” (2001) Control Systems Magazine, IEEE. Vol. 21, Num. 1, pp. 84-99, [8] C. Meng, T. Wang, W. Chou, S. Luan, Y. Zhang, and Z. Tian, “Remote surgery case: Robot-assisted teleneurosurgery”,in IEEE Int. Conf. Robot. and Auto. (ICRA’04), Apr. 2004, vol. 1, pp. 819–823. [9] P. Seiler and R. Sengupta, “Analysis of communication losses in vehicle control problems”,in Proc. 2001 Amer. Contr. Conf., Jun. 2001, vol. 2, pp. 1491–1496.