nueva página del texto (beta)
Español (pdf)
Artículo en XML
Referencias del artículo
Traducción automática
Enviar artículo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
Introducción
En la vida diaria el hardware y el software juegan un papel importante, debido a que permiten el desarrollo y la implementación de la tecnología que satisfacen las necesidades de los seres humanos. En muchas ocasiones solo se asocia la palabra hardware a una computadora que puede ejecutar diversas aplicaciones mediante el uso de software, sin embargo, la mayoría de la gente hace uso del hardware, denominado como el conjunto de elementos físicos o materiales en aparatos electrónicos. Por ejemplo, un automóvil puede tener varios recursos de hardware como los microprocesadores para controlar algunas funciones, tales como: sincronizar el motor, los frenos, la transmisión, el sistema de seguridad, el aire acondicionado, etcétera. Por lo tanto, un auto tiene integrado recursos de hardware y de software que permiten su funcionamiento mediante alguna tarjeta electrónica con un fin especifico, conocido como sistema embebido.
Sistemas embebidos
Los sistemas embebidos también son llamados empotrados o embarcados. Según Sánchez et al. (2015) existen diversas definiciones, entre ellas se encuentra un sistema integrado que se basa en un microprocesador y está construido para controlar algunas funciones (Heath, 2003). Noergaard (2013) menciona que a diferencia de una computadora, un sistema embebido no está diseñado para ser programado por el usuario final. Por otro lado, en Kleidermacher et al. (2012) a diferencia de computadora, un sistema embebido es un sistema integrado, es decir, un sistema computacional aplicado. En Abbott (2013) se define como un sistema electrónico que contiene al menos un microprocesador y un software para realizar alguna función integrada en la entidad más grande. Alva & Alcorta (2020) lo definen como un dispositivo que tiene una computadora dentro de él, pero el usuario de este dispositivo no necesariamente sabe que es una computadora. Finalmente, en Pont (2014) lo propone como un sistema electrónico con capacidad de cómputo diseñado para realizar una o varias funciones específicas. Las características principales de un sistema embebido según Alva et al. (2020) es que son específicos en hardware y con funcionalidad de software; es un sistema integrado y diseñado para realizar funciones específicas. Asimismo, están integrados por microcontroladores (Apaza, 2010), microprocesadores (Valdivieso & Solís, 2018), circuitos integrados digitales que contienen compuertas lógicas programables llamado FPGA por sus siglas en inglés field programmable gate array (Chan & Mourad, 2008), procesadores digitales de señales (Lapsley et al., 1996), tarjetas embebidas de uso comercial, o sistemas embebidos construidos o incluso una combinación de ellos. Sin embargo, a pesar de tener aplicaciones con FPGA’s (Hsu et al., 2011; 2013) procesadores digitales de señales (Chih et al, 2009; Yung et al., 2013), microcontroladores y microprocesadores (Hongjun & Byung, 2014; Hedjar & Bounkhel, 2014), entre otros. En algunos casos se recurre al desarrollo de sistemas embebidos mediante tarjetas electrónicas de fabricación propia, debido a que son diseñadas con base en requerimientos específicos para realizar prototipados rápidos con el fin de adecuarlas a un fin en común mediante un entorno de desarrollo integrado (IDE). En este caso, un IDE permite programar un microprocesador o un microprocesador para definir la aplicación del sistema embebido e incluso desarrollar una interfaz de usuario, que son aplicados en la electrónica, las comunicaciones, el control automático, la robótica, la mecatrónica, entre otras (Sánchez et al., 2018). La principal ventaja es que el sistema embebido puede rediseñarse, reconfigurarse e incluso readaptarse para otras funciones en comparación con las tarjetas embebidas de algunas marcas como Arduino (Arduino, 2022), Rasberry (Rasberry, 2022), National Instruments (National Instruments, 2022), entre otras.
En este trabajo se consideran las características de los sistemas embebidos para la integración de un servomecanismo con fines educativos para implementar técnicas de control mediante la instrumentación (Bräunl, 2006; Flores et al., 2016). El Control Automático (Control Automático, 2022) tiene como objetivo lograr la operación de procesos mediante la instrumentación según las especificaciones de funcionamiento, ello, con la menor supervisión humana posible a pesar de los errores o las perturbaciones. El área de control está presente en la industria, la robótica y gran variedad de sistemas que resuelven tareas específicas y problemas abiertos (Siegwart & Nourbakhsh, 2004), donde se busca controlar variables de posición, temperatura, presión y velocidad, entre otras, mediante computadoras, sensores, actuadores, instrumentación y sistemas embebidos (Dorf & Bishop, 2001; Bolton, 2001).
Seleccionar un sistema embebido para un objetivo específico no es una tarea sencilla, ya que de ese sistema dependerán las necesidades y requerimientos para la aplicación a desarrollar (Dorf & Bishop, 2001; Ogata, 2010). Por ende, en el desarrollo de una tarjeta embebida de elaboración propia se buscan técnicas de integración rápida. Para esto se recurre al uso de técnicas como hardware-in-the-loop (HIL) y prototipado de control rápido (Flores et al., 2016) que ayudan a recortar el tiempo de diseño y reducir los costos de desarrollo, lo que permite validar al modelo, los algoritmos de control y software sin comprometer el proceso en sí. De esta manera, las técnicas aplicadas requieren de la instrumentación mediante el uso de indicadores, transmisores, actuadores y transductores, los cuales ayudan a integrar un sistema embebido como el ejemplo presentado a continuación.
Sistema embebido para un servomecanismo con desempeño en tiempo real para el control automático
Hoy en día, los trabajos de investigación y procesos industriales requieren de la instrumentación para llevar a cabo sistemas de control. Por tal motivo, los sistemas embebidos son usados para el desarrollo donde se considera la integración de transductores, actuadores, acondicionamiento de señal, circuitos para adquisición de datos y análisis de datos, etapa de control y de potencia, convertidores analógico-digital, software, entre otros. El sistema embebido presentado es usado para el desarrollo de un servomecanismo en control automático con características de bajo costo (Linux) y con desempeño en tiempo real (González et al., 2019). El servomecanismo es diseñado e implementado con un microcontrolador PIC, con entradas emitidas desde la comunicación USB (bus universal en serie) y las salidas para el control de giro de un servomotor, la modulación de ancho de pulso (PWM) y el amplificador de corriente; además, tiene funcionalidad con programas como Matlab y Scilab (Scilab Enterprises, 2022) con una computadora en tiempo real.
El sistema es integrado y diseñado para realizar funciones específicas de la teoría del control, es decir, pueden desarrollarse diversas estrategias de control mediante el uso de diagramas de bloques, permitiendo tener una interfaz de usuario mediante los programas mencionados, los cuales facilitan la programación, configuración y control. Debido a que la mayoría de las computadoras actualmente tienen un puerto USB, esto permite el uso de dispositivos de adquisición de datos sin la necesidad de insertarlos en una ranura para placa base, es decir, el servomecanismo experimental usa el puerto USB de alta velocidad de 480 Mb/s que permite una frecuencia de muestreo de hasta 0.5 milisegundos. La Figura 1 muestra la arquitectura del sistema con tres elementos: Hardware (la placa del servomecanismo de control), el protocolo de comunicación (la interfaz de hardware para transcripción de datos del puerto paralelo mejorado (Enhanced Parallel Port, EPP) a USB) y el software dado en tiempo real con dos opciones, la primera con Linux mediante RTAI, Scilab/Xcos, controlador y QrtaiLab; y la segunda mediante Windows, QUARC y Matlab-Simulink.
Hardware
El servomecanismo es diseñado para implementar estrategias de control y está integrado mediante un motor de corriente directa (DC), un decodificador incremental óptico, la tarjeta embebida que contiene un microcontrolador con interfaz periférica (PIC), un microcontrolador de comunicación USB de alta velocidad, un aislador magnetorresistivo digital, un amplificador galvánico analógico y un puente H; y una fuente de alimentación. Dentro del PIC es implementado un amplificador de corriente con el puente H usando el lazo de corriente, donde l+as ganancias pueden ser ajustadas en tiempo real a través QrtaiLab (Holger, 2010) o Simulink (The Math Works, 2012), según sea el caso. En la Figura 2 se muestra la integración del sistema embebido, que en conjunto con los demás componentes integra un servomecanismo con fines educativos para el aprendizaje de control. El firmware es el programa dentro del dSPIC30f4012 y realiza cinco tareas: Inicializa los periféricos dSPIC30f4012 utilizados para controlar el motor DC, el convertidor AD para medir la corriente en el puente H, el módulo QEI para leer el decodificador óptico incremental y el módulo PWM para controlar el puente H; realiza el lazo de control de corriente en un controlador proporcional integral interno; actualiza la posición del decodificador en el vector de datos; actualiza el valor de salida PWM del vector de datos; y finalmente, transfiere los datos desde/hacia el vector de datos a través de INT1 e INT2 sin interrumpir las rutinas de servicio.
El objetivo principal al seleccionar los componentes del sistema es tener la menor cantidad de componentes posible para obtener así el bajo costo (mediante software libre), además del alto rendimiento y la facilidad de reparación. Se puede observar que todos los circuitos integrados (IC) tienen una configuración doble en línea (Dual In Line, DIP) insertados en bases soldadas que se pueden cambiar con facilidad permitiendo la interconexión necesaria. El dSPIC30f4012 es seleccionado, ya que este PIC tiene módulos específicos para aplicaciones de control de motores, además de una interfaz de codificador en cuadratura (QEI) y una modulación de ancho de pulso (PWM). La frecuencia del PWM es de 20.317 KHz evitando ruidos audibles en el motor y está determinada por el microcontrolador. El convertidor analógico digital (ADC) cuenta con 10 bits y es capaz de medir el voltaje proporcional a la corriente generada en el puente H, que es usada como señal de realimentación para el amplificador de corriente. Los circuitos integrados digitales y analógicos de aislamiento, permiten proteger de la etapa del amplificador de potencia a la etapa de procesamiento digital. La interfaz USB USB2LPT utiliza el chip Cypress CY-68013 EZ-USB de alta velocidad a 480 Mb/s (Haftmann, 2022). El chip Cypress mediante el conector USB-LPT permite utilizar el servomecanismo con una interfaz USB. Por otro lado, el decodificador incremental óptico usado es el modelo US-Digital E-6 2500 que permite el conteo de 10000 pulsos por revolución. Finalmente, el motor corriente directa es de escobillas de doble eje modelo Dynetic System 509051 como se muestra en la Figura 3.
Protocolo de comunicación
Para obtener la interfaz USB se recurre al uso de hardware descrito por la especificación EPP. La especificación EPP permite realizar ciclos de lectura/escritura de direcciones y datos, donde el protocolo de comunicación se realiza por el hardware en lugar del software. La computadora actúa como maestro y el dSPic30f4012 como esclavo. Por lo tanto, un ciclo de lectura transferirá información del dSPIC30f4021 a la computadora. El ciclo de escritura envía la información desde la computadora al dSPIC30f4012. El firmware es el programa dentro del dSPIC30f4012 que realiza las siguientes tareas: Inicializa los periféricos dSPIC30f4012 utilizados para controlar el motor y el convertidor analógico-digital para medir la corriente en el puente H; el módulo QEI lee el decodificador óptico incremental y el módulo PWM impulsa el puente H, que realiza el lazo de corriente y actualiza la posición del decodificador, asimismo el valor de salida del PWM; finalmente, es capaz de transferir los datos desde y hacia el vector de datos a través de diversas rutinas de interrupción desde las terminales INT1 e INT2 del microcontrolador.
La computadora actuará como maestro y el dSPic30f4012 como esclavo. Por lo tanto, un ciclo de lectura transferirá información desde el dSPIC30f4021 a la PC. Un ciclo de escritura transferirá información desde la PC al dSPIC30f4012. La Figura 4 muestra la estructura del intercambio de datos básico donde la computadora realizará otros ciclos de direcciones y se utilizarán para sincronizar el intercambio de datos.
Software
El sistema embebido permite la conexión del servomecanismo con el uso de software libre, gratuito y de código abierto utilizando el sistema operativo Lubuntu 14.04, y RTAI 4.1 con kernel 3.81.6. RTAI, que es una extensión en tiempo real para Linux. Consiste principalmente en una extensión para el kernel de Linux que introduce una capa de abstracción de hardware y una variedad de servicios para facilitar la programación. XCos es un modelador gráfico y simulador para sistemas dinámicos que permite la posibilidad de compilar dichos modelos en código ejecutable. Los bloques XCos para el servomecanismo se crean utilizando HART Toolbox Versión 3.23 (Holger, 2022) y la interfaz de usuario utiliza QRtaiLab 2.3 (Holger, 2010), basado en QT que es una plataforma de desarrollo para desarrollar interfaces gráficas.
La conexión desde Matlab-Simulink se basa en un núcleo en tiempo real y se requiere el uso de QUARC que permite la producción y creación rápida de prototipos. QUARC puede ser integrado con Simulink.
Asímismo, QUARC tiene una gama de características que permiten el rendimiento en tiempo real aceptando el ajuste de parámetros en línea directamente desde el diagrama en Simulink, también se pueden obtener resultados y gráficas de los experimentos en tiempo real y permite realizar varios experimentos simultáneamente, realiza la generación de código a partir de un solo diagrama en Simulink, entre otras (Quanser, 2022a; 2022b, 2022c); (Quanser Consulting, 2011). La arquitectura requiere los controladores la interfaz USB2LPT (versión 1.7) que es conectada al puerto USB para realizar la comunicación entre el subsistema del kernel USB utilizando el chip FX2LP alcanzando una velocidad de transferencia máxima de 480 Mb/s (Haftmann, 2022).
La arquitectura de Linux agrupa los controladores de dispositivos en tres categorías: Controladores de bloque, carácter y red. La interfaz USB2LPT (versión 1.7) es un dispositivo de caracteres. Una vez anclado a un puerto USB que realiza la comunicación entre el subsistema del kernel USB y el estándar IEEE 1284-1994 (puerto paralelo) implementado mediante el chip FX2LP (Cypress Semiconductor) alcanzando una velocidad de transferencia máxima de 480 Mb/s.
La Figura 5 muestra el diagrama de bloques del controlador implementado para USB2LPT. Cuando el controlador se carga en la memoria, la función usb2lpt_init() lo registra en el subsistema del kernel USB. La función usb2lpt_probe() se ejecuta cuando el hardware USB2LPT está anclado a un puerto USB del ordenador. Con este se obtiene información sobre interfaces de hardware y puntos finales y se registra el dispositivo. Luego, la información se almacena en una estructura interna que representa el dispositivo. La función usb2lpt_open() abre la interfaz USB usb2lpt_close(), lo libera; usb2lpt_read() y usb2lpt_write() contienen el código para ensamblar URB para enviar, recibir y copiar información hacia y desde el programa de usuario. Estas funciones tienen sus punteros en la estructura file_operatives y forman la interfaz con el usuario. En ese sentido, el usuario ve al controlador como un archivo especial, al que se accede desde una aplicación utilizando primitivas del sistema como abrir(), cerrar(), leer() y escribir(). La función usb2lpt_disconnect() se llama cuando el dispositivo no está anclado al USB. Libera el registro del dispositivo realizado por usb2lpt_probe(). Por último, usb2lpt_cleanup() libera el registro del controlador en el subsistema del kernel USB realizado por usb2lpt_init() cuando el módulo se descarga del sistema.
El controlador se implementa como un módulo del kernel de Linux. La compilación debe realizarse con la misma versión del compilador utilizada para el kernel RTAI. Incluir una licencia dual BSD/GPL evita que el kernel se contamine y evita advertencias en el registro del sistema. La carga y descarga del módulo se puede realizar con los programas insmod y rmmod. El estado de la carga se verifica con lsmod. Una vez cargado, el archivo especial del controlador sigue las mismas reglas de seguridad que los archivos normales e inicialmente sólo el usuario root ha concedido acceso. El acceso normal a usuarios y grupos se carga utilizando chmod 777 <ruta del archivo>. También se puede ejecutar la aplicación que utiliza el controlador como usuario root.
La interfaz empleada en Scilab para utilizar el controlador desarrollado anteriormente es un bloque de funciones XCos. El bloque representa una capa de abstracción compuesta en su base por la interfaz más compleja de la aplicación controladora en tiempo real para interactuar a bajo nivel con el hardware.
Una función escrita en C permite la gestión de la información transportada desde y hacia el servomecanismo, y una función de interfaz escrita en lenguaje Scilab en la parte superior encargada de lidiar con la apariencia y el comportamiento del bloque durante la simulación. El bloque resultante (Bloque 4 tipo lenguaje C) tiene seis entradas de señal, una entrada de activación y cuatro salidas de señal. Las entradas de señal permiten sintonizar, encender o apagar el bucle de corriente de bajo nivel PI y recibir la señal de referencia actual. La entrada de activación permite sincronizar el bloque con la simulación en tiempo real. Las salidas, por otro lado, corresponden a los conteos del codificador de cuadratura, la velocidad estimada usando un filtro digital de paso alto, la corriente medida y la señal PWM aplicada al motor de CD. El bloque de virtualización se puede simplificar en un super bloque para operar solo con las entradas y salidas de interés, por ejemplo, la señal de entrada de corriente de referencia (tau) y la señal de salida de velocidad (vel) como se muestra en la Figura 6.
Aplicación con la tarjeta embebida para el control del sistema rueda-bola
El servomecanismo ha sido empleado por alumnos de Licenciatura y Maestría de las áreas de Control Automático, Electrónica, Mecatrónica, Industrial, entre otros. Donde la interfaz es a través de los programas Matlab y Scilab mediante los diagramas de bloques que representan una abstracción compuesta en su base por la interfaz de aplicación del controlador en tiempo real más compleja para interactuar a bajo nivel con el hardware; un programa computacional escrito en C que permite la gestión de la información transportada desde y hacia el servomecanismo, y una función de interfaz en Simulink y en Scilab. El bloque resultante tiene seis entradas de señal, una entrada de activación y cuatro salidas de señal. Las entradas de señal permiten que el lazo de corriente de bajo nivel permita sintonizar cualquier controlador desarrollado, además que encienda o apague y reciba la señal de referencia de corriente durante el uso de la plataforma. La entrada de activación permite sincronizar el bloque con la simulación en tiempo real. Las salidas, por otro lado, corresponden a los recuentos del decodificador, la velocidad estimada utilizando un filtro, la corriente medida y la señal PWM del motor. El bloque que integra a estas partes puede ser insertado en un super bloque para operar al sistema con las entradas y salidas de interés, por ejemplo, la señal de entrada de corriente de referencia y la señal de salida de velocidad (Figura 7).
El servomecanismo ha ayudado a implementar y desarrollar diversos controladores como el proporcional (P), proporcional integral (PI), proporcional derivativo (PD), proporcional integral derivativo (PID), óptimos, robustos, basados en retardos, digitales, entre otros. De la misma forma, ha permitido el desarrollo de algunas estrategias de control y también con péndulos. Actualmente se desarrolla el control de un sistema rueda-bola para mantener en equilibrio la pelota mediante el procesamiento de imágenes en tiempo real como se muestra en la Figura 8.
El modelo del sistema rueda-bola (Ho et al., 2009) es representado en la Figura 9 y se obtiene matemáticamente a partir de la formulación Euler-Lagrange. Asumiendo que la fricción en el sistema es suficiente para evitar que la pelota se deslice, la pelota siempre está en contacto con la rueda, la forma de la ecuación Euler-Lagrange es la siguiente:
La función Lagrangiana se define como:
Donde T es la energía cinética y V es la energía potencial.
Para las coordenadas del sistema tenemos a q como:
definiendo a θ 1 como el desplazamiento angular entre el eje y, y la línea que pasa por el centro de la bola y la rueda; y θ 2 es definida como desplazamiento angular de la rueda.
Q está dado por
La ecuación que expresa la energía cinética de la bola es la siguiente:
Donde:
m b = |
masa de la bola |
r r = |
radio de la rueda |
r b = |
radio de la bola |
θ 3 = |
desplazamiento angular del centro de la bola respecto al eje vertical del mismo, y el momento de inercia I b esta dado como: |
Mientras que la energía cinética de la rueda se representa como:
donde I r es el momento de inercia de la rueda. Por lo tanto, obteniendo la sumatoria de las energías cinéticas se tiene:
Por otro lado, debido a que θ 3 no es medible y como se está analizando respecto al contacto entre los puntos Cb y Cr se obtiene la siguiente condición de cómo se comporta el movimiento al girar la bola:
sustituyendo θ 3 en la ecuación de la energía cinética tenemos como resultado lo siguiente:
Así la energía potencial V es determinada como:
Por lo que, el Lagrangiano es determinado como:
Obteniendo la derivada parcial respecto a θ 1 el Lagrangiano se tiene:
Expandiendo la ecuación 13 se tiene:
Y obteniendo la derivada:
Agrupando términos se tiene:
Así queda demostrada la ecuación 13, ahora obteniendo la derivada respecto al tiempo se tiene:
Aplicando ahora las derivadas parciales respecto a θ 2 se tiene:
De forma análoga como se obtuvo la ecuación 15 y 16, se obtiene la ecuación 18 y 19, presentadas a continuación:
Finalmente, las funciones dinámicas son las siguientes:
Definiendo para el sistema rueda-bola los estados:
De la ecuación 20 despejamos
De la ecuación 21 despejamos
Sin embargo, el sistema dado por las ecuaciones (24) y (25) es no lineal, por lo tanto, linealizando el sistema (Nise, 2004) y asumiendo que θ 1 es pequeña, se sustituye la ecuación 24 en la ecuación 21 y se obtiene:
Similarmente, se reemplaza la ecuación 25 en la ecuación 20, también se asume que θ 1 es pequeña, se obtiene:
Así es posible definir la matriz A para el sistema rueda-bola:
De forma análoga es definida la matriz de entrada B:
Para la matriz de salida C, se define de la siguiente manera:
Se define de esta manera debido a que el único punto de interés para el control del sistema es el punto de contacto entre la bola y la rueda. Obteniendo finalmente el siguiente sistema en variables de estados:
El controlador implementado es sintonizado mediante el método de Ackerman considerando los siguientes parámetros del sistema con base en la construcción física donde
Cabe mencionar que se emplea una cámara ZED como sensor de realimentación para el sistema rueda bola, donde por medio del procesamiento de imágenes es detectada en todo tiempo la bola. Mediante la segmentación en blanco y negro, además de estimar el área de la bola especifica de 3 cm de radio y estimando un área con base en el centroide de la bola, como se muestra en la Figura 10. Ahí se observa la bola en azul claro cuando es detectada, y el circulo situado en la chumacera sirve como marco de referencia para la medición del ángulo de la bola sobre la rueda. Finalmente, todo lo detectado por la cámara que no cumpla con el área o el perímetro determinado para la bola es marcado en color verde.
Figura 10 Adquisición de datos mediante el procesamiento de imágenes de la bola mediante la cámara ZED en tiempo real
Finalmente, en la Figura 11 se presenta la señal de salida del sistema rueda-bola que simboliza la posición angular de la bola para la asignación de polos mediante el método de Ackerman (negro), por otro lado, se muestra la señal de respuesta para el control de la bola mediante un controlador difuso. Como puede observarse el control lleva a cabo la tarea de mantener en equilibrio a la bola sobre la rueda, sin embargo, el controlador difuso muestra una respuesta más rápida.
Por otro lado, en las Figuras 12 y 13 se muestran las señales de error de ángulo y la señal de control del motor que lleva a cabo con éxito el sistema rueda-bola para el controlador basado en asignación de polos (negro) y el controlador difuso (rojo). De acuerdo con los resultados antes mostrados, el desempeño del servomecanismo desarrollado mediante la tarjeta embebida se considera que tiene un razonable rendimiento para propósitos de aplicaciones de control e instrumentación aplicada para la enseñanza y se puede obtener la misma versatilidad en cuanto a la implementación de ambos algoritmos de control.
De acuerdo con los resultados, ambos controladores cumplen el objetivo de llevar a cabo el control de equilibrio de la bola mediante el servomecanismo que es integrado por la tarjeta embebida desarrollada. Respecto al tema de control, el controlador difuso (o de lógica difusa) y el controlador basado en asignación de polos tienen diferentes enfoques y características que los hacen más adecuados para distintas aplicaciones.
Algunas de las ventajas del controlador difuso frente a uno basado en asignación de polos se enfocan en el tema del manejo de la incertidumbre, es decir, el controlador difuso es especialmente útil en sistemas con incertidumbre, ya que no requiere un modelo matemático preciso. La lógica difusa puede manejar entradas ambiguas o imprecisas, lo que lo hace ideal para sistemas donde es difícil obtener un modelo exacto. En cuanto al control por asignación de polos, este controlador depende de un modelo matemático preciso y se basa en la ubicación de los polos del sistema para lograr el desempeño deseado. Esto puede ser limitante en sistemas con incertidumbre significativa.
Respecto al ámbito de la simplicidad y flexibilidad en el diseño, el controlador difuso ofrece una mayor flexibilidad, ya que el diseño de las reglas difusas puede basarse en el conocimiento experto o en la experiencia práctica sin necesidad de un modelo matemático complejo. Esto simplifica el diseño del controlador en sistemas complejos. En contraste, el controlador basado en asignación de polos requiere un conocimiento detallado del modelo del sistema, lo que puede complicar el diseño en sistemas complejos o en aquellos donde los parámetros pueden variar.
En cuanto a adaptabilidad el controlador difuso puede adaptarse mejor a cambios en el sistema o en su entorno, ya que las reglas difusas pueden modificarse o ajustarse más fácilmente. Es más adecuado para aplicaciones donde el sistema varía con el tiempo o donde las condiciones operativas no son constantes. En cambio, el controlador basado en asignación de polos, una vez diseñado, el controlador basado en asignación de polos no es tan flexible para adaptarse a cambios en el sistema sin rediseñar el controlador.
Finalmente, con base en el tema de robustez, el controlador difuso tiende a ser más robusto frente a variaciones y perturbaciones no modeladas debido a su capacidad para manejar la incertidumbre y trabajar con información parcial o inexacta. Por su parte, el controlador basado en asignación de polos puede ser menos robusto si el modelo del sistema no es exacto o si hay perturbaciones significativas, lo que podría requerir ajustes finos o un diseño más complejo para mantener la estabilidad. En resumen, la elección entre un controlador difuso y uno basado en asignación de polos dependerá del tipo de sistema que se desea controlar y de la naturaleza de la información disponible sobre el sistema.
Conclusiones
En este trabajo se presentó el desarrollo de un sistema embebido aplicado para el desarrollo de un servomecanismo de prototipaje rápido para experimentos de control del sistema rueda-bola mediante la instrumentación, la programación específica y el uso de Matlab. En el caso de software libre se reducen los costos asociados a las licencias. El uso de la tarjeta embebida permite el uso de QUARC usando la computadora como interfaz sin necesidad de una computadora externa integrada, al tiempo que garantiza un rendimiento en tiempo real, y la interfaz de programación gráfica de alto nivel basada en Simulink.
Ante los resultados obtenidos se puede decir que la tarjeta de adquision de datos permite lograr el objetivo de control del sistema rueda-bola mediante la arquitectura diseñada, el hardware, el protocolo de comunicación y el software presentado, obteniendo resultados fiables a nivel experimental y en aspectos como bajo costo, confiable y robusto, además de poder conectarla mediante cualquier puerto USB obteniendo resultados en tiempo real.
Puede concluirse que la implementación y el uso de los sistemas embebidos de manera libre tienen la ventaja de ser diseñados e implementados con hardware y software específico, asimismo con funciones específicas. Está integrado por un microcontrolador, es de bajo costo, adaptable a otras funciones y aplicable para el desarrollo de prácticas y de experimentos en cursos de Control, Robótica, Mecatrónica, entre otros.
Finalmente, el servomecanismo permite validar y desarrollar prototipos aplicados al control, la instrumentación e incluso a la robótica, que permiten aplicar experimentos en tiempo real. Actualmente, se trabaja en el desarrollo de una tarjeta embebida con interfaz USB 3.0 y se implementan otros sistemas robóticos debido a la fácil adaptabilidad, flexibilidad y a que la tarjeta embebida está abierta para poder implementar otras aplicaciones.
