Control por modelo interno: contraejemplos (cuando NO funciona bien)

Antonio Sala, UPV

Dificultad: *** ,       Relevancia: ,      Duración: 08:00

*Accede pulsando el enlace a la [ Colección completa] de vídeos docentes y materiales asociados.

Resumen:

Este vídeo presenta ejemplos de código donde no funciona el control por modelo interno.

Primero, se aborda el caso de un proceso inestable. Si se ejecuta el código de los ejemplos del vídeo [imcml1], se alcanza el modelo deseado entre referencia y salida pero hay una cancelación polo-cero inestable entre regulador y planta que hace que la respuesta ante perturbaciones a la entrada del proceso tienda a infinito. Esto no es ninguna sorpresa, dado que está previsto por la teoría. Esa inestabilidad ante perturbación a la entrada de $(1-M)\cdot G$ no es un problema ”numérico” de simulación: es intrínseco a la filosofía de disen~o y simulando minreal((1-M)*G) tampoco funciona, ni lo haría en un experimento real.

El segundo ejemplo es un proceso $G(s)=10∕(s+0.004)∕(0.05s+1)$. El proceso es estable, por lo que la teoría del IMC no predice ningún problema a priori. No obstante, la cancelación polo-cero casi en el límite de la estabilidad produce una respuesta ante perturbaciones a la entrada de la planta que tarda 600 veces más que la respuesta ante referencia. Ello no suele ser aceptable en la mayor parte de las aplicaciones.

El límite de la idea de este segundo ejemplo es un proceso con integrador puro (inestabilidad marginal $1∕s$) en el cual el IMC tampoco funcionará. Un ejemplo de ese tipo aparece en el vídeo [imcex3]... en dicho vídeo se usa un ”S-IMC” que es una modificación que, pese a su nombre con el acrónimo IMC, realmente abandona la filosofía IMC en procesos con polos muy lentos (teoría en vídeo [simcteo]).

Un caso de IMC en tiempo discreto y análisis de este tipo de problemas debidos a la cancelación se aborda en el vídeo [cancobsctr], aunque su visualización se aconseja sólo si ya te son familiares los conceptos de controlabilidad y observabilidad en representación interna.

Aparte de estos casos “extremos”, el IMC (y, realmente, cualquier controlador) demasiado “enérgico” tendrá problemas de amplificación de ruido o saturación que pueden desaconsejar un disen~o “teóricamente correcto” en determinada aplicación, ver vídeo [imc4ca2].