Empezamos una serie destinadas a ver cómo realizar mecanismos de control automáticos en un procesador como Arduino. En esta entrada veremos qué es controlar un sistema. En las próximas veremos el control todo y nada, hasta terminar en el control PID.
No cabe duda que uno de los procesadores como Arduino es controlar sistemas de forma automática. Pero en primer lugar ¿Qué es un controlador? ¿Qué controlador puedo usar? ¿Cómo se implementa un controlador?
Si buscáis encontraréis un montón de información al respecto, libros y libros de cientos de hojas llenos de ecuaciones. Pero el propósito de estas entradas es explicarlo de forma sencilla (o intentarlo), sin usar ni una fórmula (casi ninguna) y sin excesivos formalismos matemáticos.
Por supuesto que no pretende ser un texto riguroso, ya que el campo es enorme (de hecho, eran dos asignaturas enteras y una especialidad en la carrera de ingeniería). Si queréis más detalles podéis apoyaros en la abundante bibliografía disponible.
Aquí intentaremos hacer algo que no es tan frecuente de encontrar, dar una visión intuitiva de la teoría de control y de la motivación que hay detrás, de forma que sea fácilmente entendible, y sin tener que usar transformadas de Laplace, lugares de las raíces, diagramas de Bode, ni teoremas de Nyquist.
Así que empezamos preguntándonos.
¿Qué es el sistema a controlar?
Un sistema es una representación simplificada de la realidad que abstraemos para poder trabajar con él, porque la realidad es demasiado compleja para trabajar con ella como un todo. Normalmente representa una parte de la realidad que “aislamos mentalmente” (aunque también puede ser totalmente inventado).
Un sistema puede ser casi cualquier cosa. La climatización de un edificio, el sistema de tracción de un coche, el equipo de bombeo de un depósito, un avión, una nave espacial, un robot… hasta el sistema digestivo de un pato. Cualquier cosa, puede ser un sistema para ti.
Un sistema, al que normalmente llamaremos planta, tiene una o varias entradas que representan acciones sobre las que podemos actuar. También tiene una o varias salidas que son los parámetros que son observables y medibles. En general un sistema tiene muchas entradas y salidas, pero normalmente lo vamos a simplificar a las más importantes.
Nuestra planta, además, tiene un cierto comportamiento. Es decir, realizar una acción tendrá una determinada consecuencia sobre sus salidas. Por supuesto, el comportamiento puede ser todo lo complicado que puedas imaginar. Puede ser no lineal, tener inercias, incluso retrasos puros (un tiempo entre que aplicas la acción y el sistema “se entera”), efectos entre varias entradas.
El comportamiento de la planta también se puede abstraer y modelizar de forma simplificada, en lo que conocemos como función de trasferencia. Y lo podemos representar, por ejemplo, mediante una ecuación, un diagrama de bloques, una representación gráfica o frecuencial, entre otras.
Para hacerlo más “divertido” nuestra planta puede tener perturbaciones, es decir, modificaciones en el entorno que modifican su comportamiento. Por ejemplo, en el edificio la temperatura exterior va a cambiar, en el coche puedes subir o bajar una cuesta, y en el embalse puede ponerse a llover.
En resumen,
Un sistema es un modelo de una porción del universo, que tiene entradas y salidas, cuya relación entre estas sigue un determinado comportamiento y que está sometido a posibles perturbaciones
Y eso lo representamos así (y nos quedamos “tan panchos”).
¿Qué es un controlador?
El controlador es un elemento que interponemos antes de las entradas de nuestra planta para actuar sobre ellas con objeto de conseguir que la salida tenga unas determinadas características.
Por ejemplo, quieres controlar la temperatura de un edificio actuando sobre la caldera, la velocidad del coche actuando sobre el motor, o el nivel del depósito actuando sobre el bombeo.
Lógicamente, la entrada sobre la que vamos a actuar debe tener una influencia en la salida que queremos controlar. Si estoy controlando una variable que es totalmente independiente de lo que estoy midiendo ¡ya le puedo dar ya, que no voy a hacer nada!
El controlador puede ser desde una persona, hasta un sistema analógico, o un sistema digital. En sistemas automáticos lógicamente nos referimos a algún tipo de máquina que la controle el sistema de forma autónoma sin intervención manual.
El controlador, representado junto al sistema, quedaría así.
¿Qué características queremos de la salida?
La primera y más evidente es que la salida tenga un valor determinado que denominaremos consigna. Por ejemplo, quiero que la temperatura sea de 24ºC, que el coche vaya a 80km/h, o que el nivel del agua de un embalse sea 175m.
Por supuesto, la consigna no tiene que ser la misma siempre. Yo puedo querer que la temperatura sea 17ºC durante la noche y 24ºC el resto, que el coche pase a 50km/h al pasar por una travesía, o querer vaciar a 160m embalse porque tengo que suministrar agua potable a la red.
Pero, además de la consigna, hay otras características deseadas para la salida. En general, voy a querer que la salida sea estable a largo plazo, que converja al valor de la consigna, que el tiempo de respuesta sea rápido, que no oscile, que no sobre pase el valor de consigna en ningún momento.
Y como no podría ser de otra forma, o esto sería demasiado fácil, no voy a poder tenerlas todas a la vez, así que tendré que llegar a un compromiso entre todas. Aunque, llegado el caso puede, que esté dispuesto a sacrificar unas respecto a otras.
Por ejemplo, quizás no te importa que la temperatura de un edificio alcance brevemente 24.5ºC, si así el tiempo de respuesta es menor. Pero si a 180m de agua el embalse se rompe, inundando un pueblo y matando a cientos de personas y perritos, quizás no sea tolerable el sobrepasamiento y prefieras lento pero seguro.
Por tanto, las características deseadas para la salida depende totalmente de tu sistema y de lo que quieras hacer, y por tanto el controlador que tienes que emplear.
¿Qué es un bucle cerrado?
Es una forma muy bonita de denominar a una cosa muy evidente. Para que un controlador funcione tiene que tener realimentación. ¿Y eso que es? Pues básicamente que el controlador tiene que poder “ver” la salida que intenta controlar directa o indirectamente.
Sin realimentación, un controlador no es un controlador, es más bien una “declaración de buenas intenciones a ciegas”. Imagínate que tienes que controlar una variable, dando a una palanca, y no sabes lo que mide la variable. Pues nada, ¡ojos cerrados, palanca en medio y que sea lo que Dios quiera!
Bien, tenemos claro que para controlar una salida tenemos que poder medirla. Así que cogemos la salida y la comparamos con la consigna para ver el error que tenemos. Empleamos este error como entrada de nuestro controlador. Esto lo representamos así.
El error entre la medición y la consigna puede ser bien porque aún no hemos conseguido que la salida alcance a la consigna, o porque nos han cambiado la consigna.
En el fondo es bastante intuitivo, tiene lógica ¿no? Entonces ¿porque tanto interés en el bucle cerrado? ¿se modifica mucho el sistema por tener esa rama de feedback de la salida a la entrada? Pues sí, pueden pasar todo tipo de cosas muy interesantes (y algunas bastante horribles).
Con realimentación el sistema global (controlador + planta) se comporta de forma totalmente distinta. La salida puede desde tender plácida y obedientemente a la consigna, a ponerse a oscilar como una loca hasta que rompa algo.
Y la diferencia entre una salida (éxito absoluto en tu sistema de control) y la otra (rotura, despido, y posible destrucción del universo) depende totalmente del control que diseñes ¿¡a que mola!?
La versión intuitiva del controlador
¿Entonces, que narices es un controlador? Un controlador eres tú (de hecho, tú cerebro un controlador excelente), que se ha despertado en medio de una sala vacía. Delante tuyo tienes una mesa con una palanca analógica que admite cualquier valor entre 0 y 100, y en la pared dos enormes displays, uno azul y uno rojo.
Lo único que sabes es que la palanca que tienes delante controla, en cierta forma, el sistema de climatización de un edificio. El número azul es la consigna, es decir, la temperatura que tu jefe te pide que tenga el edificio. Y en el valor rojo la temperatura real medida en este momento.
No sabes absolutamente nada más. No sabes si es un edificio grande o pequeño, cómo está aislado, ni la temperatura exterior, si es invierno, que hora es, si está nublado, si alguien te abre de golpe todas las ventanas, si acaban de entrar 100 personas o si el edificio se ha quedado vacío.
Tampoco sabes que efecto tiene la palanca en la temperatura del edificio. No sabes si poner la palanca en medio recorrido va a encender el equivalente de dos cerillas, y la temperatura apenas va a cambiar. O si por el contrario tienes dos reactores de nave espacial, y a media palanca vas a calcinar a todo el mundo.
En resumen, vamos a asumir que no tienes nada de información a priori sobre la planta. Lo único que vamos a avisar es que tu sistema de calefacción es suficiente para alcanzar la consigna, al menos en funcionamiento “normal”. Porque si tu actuador no tiene potencia, poco podemos hacer para controlar el sistema.
Está claro que si la pantalla roja (medición) estuviera apagada sería mucho peor. Si sólo supieras que quieren 24ºC, pero ni en que temperatura están, ni cómo es la planta, ni el efecto que tiene tu palanca… lo que decíamos antes, sin realimentación sólo podrás actuar a ciegas y cruzar los dedos.
La cosa cambia si se enciende la pantalla roja. Ahora, por lo menos, puedes comparar medición y consigna (lo que hemos llamado error) e igual hasta podemos hacer algo. ¿Podrías controlar la temperatura, con esta información? Desde luego que sí y eso es, precisamente, un controlador.
¿Cómo vas a mover la palanca, en función de lo que ves en ambas pantallas? ¿Mucho, poco? Esa es la parte de diseño del controlador, determinar la respuesta que va a realizar en la palanca (actuador) a medida que los valores de las pantallas varían.
¿Qué posibles estrategias podemos aplicar para el diseño del controlador? Muchísimas. En la próxima entrada veremos una de las más sencillas e intuitivas, el control-todo nada con histéresis. En la siguiente veremos una aproximación intuitiva al controlador PID, uno de los controladores más empleados en el ámbito industrial.
Descarga el código
Todo el código de esta entrada está disponible para su descarga en Github. 