Paso 21: Ejemplos de aplicación - RTAI

Nos quedaba pendiente la publicación de algunos códigos como ejemplo de una aplicación RTAI. Si bien es una aproximación dado que aún estamos realizando diversas pruebas sobre el software y la electrónica, creemos que es una manera útil de ir mostrando los progresos del proyecto.

En éste caso, presentamos un ejemplo de una tarea de tiempo real, ejecutada como parte de un módulo del kernel, y un proceso usuario que muestra datos en pantalla. La tarea se encarga de muestrear cada 50 useg, las entradas discretas de la placa adquisidora. En el puerto, está conectado un encoder incremental de cuadratura y el algoritmo implementado determina si se debe incrementar o decrementar un pulso en el acumulador.

A continuación, se detallan los archivos empleados con algunos comentarios incluidos en el código.

Makefile

-------------------------------------------------------------------
obj-m    := ktest_encoder.o

KDIR    := /lib/modules/$(shell uname -r)/build
PWD     := $(shell pwd)
EXTRA_CFLAGS := -I/usr/realtime/include -I/usr/include/ -ffast-math -mhard-float

default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
gcc -o utest_encoder utest_encoder.c
-------------------------------------------------------------------

.runinfo

-------------------------------------------------------------------
latency:ksched+fifos:push ktest_encoder;./utest_encoder;popall:control_c
 -------------------------------------------------------------------

ktest_encoder.c

-------------------------------------------------------------------
/*
Archivo: ktest_encoder.c

COPYRIGHT (C) 2007-2008 Elias S. Fliger (elias.s.f@gmail.com)
This library is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License as published
by the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License
along with this library; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA.
*/
/*----------------------------------------------------------
Descripción:
Se ejecuta 1 tarea denominada ENCODER.
Lee los canales A y B (chA y chB) y almacena los valores actuales
y anteriores del encoder en los vectores A y B para incrementar
o decrementar la variable x que especifica la posicion angular del motor.
----------------------------------------------------------*/
/* includes*/
#include <linux>
#include <linux>
#include <asm.h>
#include <math.h>
#include <rtai.h>
#include <rtai_sched.h>
#include <rtai_fifos.h>
/* defines*/
#define TICK_PERIOD 50000                        //50 useg de periodo
#define TASK_PRIORITY 0
#define STACK_SIZE 10000
#define FIFO 0

#define BASEPORT 0x300                            //Dirección Base de la placa adquisidora

/* globals */
static RT_TASK rt_task3;

/********************************************************
*    FUNCION:        encoder
*
*    Descripcion:        Tarea de lectura del encoder.
*
*    Esta rutina lee los canales IN0 e IN1 (pin31 y 30) como canales A y B, respectivamente.
*    Compara el estado de cada canal cada 50 useg ya que no posee interrupciones y
*    luego incrementa o decrementa el acumulador de pulsos.
*********************************************************/
static void encoder(int t)
{
unsigned char chA=0, chB=0, entrada=0;        //canales A y B , mas la mascara del puerto de entradas discretas
unsigned int A[2] = {0,0};                        //Vector para comparar el valor actual y anterior del canal A
unsigned int B[2] = {0,0};                        //Idem
int x=0;                                            //Acumulador de pulsos

entrada=inb( BASEPORT);
chA = entrada & 0x01;                            //Lee IN 0 - Pin 31
chB = entrada & 0x02;                            //Lee IN 1 - Pin 30
A[0] = ( unsigned int )chA;                    //Inicializa canales de entrada
B[0] = ( unsigned int )chB;

rtf_reset(FIFO);


while(1)
{

entrada=inb( BASEPORT);

chA = entrada & 0x01;
chB = entrada & 0x02;
chB = chB/2;

A[1] = ( unsigned int )chA;
B[1] = ( unsigned int )chB;

if((A[1] & B[1]))                            //Ejecutar solo si A[1] = B[1] = 1
{
if( ((A[1]^A[0]) | (B[1]^B[0])) )    //si hubo cambio de estado para A o B,  Incr o Decr
             {
  if((A[1]^B[0])) x++;                // Si A[1] xor B[0] = 1 incrementa
  else
                     {
                     if(x>0) x--;                        // De otra forma decrementa
                     else x=0;
                     }
             }
     }

A[0]=A[1];                                    //Actualiza valores
B[0]=B[1];

rtf_put(FIFO, &x, sizeof(x));            //Coloca en el FIFO para Proceso usuario

rt_task_wait_period();
}

}

/********************************************************
*    FUNCION:        init_module
*
*    Descripcion:        Inicializa el modulo.
*
*    Inicializa tarea de tiempo real, establece modo periódico,
*    crea FIFO e inicia temporizador.
*********************************************************/
int init_module(void)
{
RTIME tick_period;

rt_set_periodic_mode();

rt_task_init(&rt_task3, encoder, 1, STACK_SIZE, TASK_PRIORITY, 0, 0);
//tarea, funcion,valor inicial, tamaño stack, prioridad, usa FPU, usa Signal Handler.

rtf_create(FIFO, 10);

tick_period = start_rt_timer(nano2count(TICK_PERIOD));

rt_task_make_periodic(&rt_task3, rt_get_time() + tick_period, tick_period);

return 0;
}

/********************************************************
*    FUNCION:        cleanup_module
*
*    Descripcion:        Libera el modulo.
*
*    Detiene temporizador, destruye FIFO y elimina tarea de tiempo real.
*********************************************************/
void cleanup_module(void)
{
stop_rt_timer();

rt_busy_sleep(10000000);
//recomendado

rtf_destroy(FIFO);
rt_task_delete(&rt_task3);
return;
}

MODULE_AUTHOR("Elias S. Fliger, ");
MODULE_DESCRIPTION("Proyecto BORA - RT test encoder - UNQ");
MODULE_LICENSE("GPL");
 -------------------------------------------------------------------

utest_encoder.c

-------------------------------------------------------------------
/*
Archivo: utest_encoder.c

COPYRIGHT (C) 2007-2008 Elias S. Fliger (elias.s.f@gmail.com)
This library is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License as published
by the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License
along with this library; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA.
*/

/*----------------------------------------------------------
Descripción:
El proceso solo recibe el valor del acumulador de pulsos
obtenido en el modulo ktest_encoder y lo muestra en pantalla.
Ejecutar ./utest_encoder
----------------------------------------------------------*/
/* includes*/
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/* defines*/
#define BASEPORT 0x300
//direccion base de la placa de adquisicion

static int end;
static void endme(int dummy)
{
end=1;
}


int main(int argc, char * argv[])
{
int fifo;
int Contador;

if ((fifo = open("/dev/rtf0", O_RDONLY))
 -------------------------------------------------------------------

Paso 20: Estado del arte de la electrónica

El estado general del proyecto, desde el punto de vista electrónico, es avanzado con tendencia a definitivo.

Hemos planteado una serie de interfaces de adaptación y optoaislación, más un driver o controlador para el motor (IGNIS MR5-90).

- Optoacopladores: Tenemos 16 entradas/salidas discretas para varios destinos:

- 2 encoders de 3 salidas
- 4 finales de carrera
- 1 relé
- 1 electroimán
- 4 PWM
- 4 direcciones

- Adaptador: Dividimos la salida del DB-37, de la placa adquisidora ADQ12-B, en 3 salidas con las tierras separadas:

- Salidas discretas
- Entradas discretas
- Entradas analógicas

- Puente H: Implementamos esquema sencillo de un Puente H basado en el L298. Los resultados fueron aceptables bajo condiciones nominales de funcionamiento del motor. Sin embargo, para una mayor exigencia de consumo, el L298 pasó a convertirse en una especie de incienso electrónico.

La experiencia nos enseñó que los disipadores de temperatura, los fusibles y protecciones adicionales como el sensado de la corriente consumida por el motor, son una buena herramienta para evitar situaciones nefastas.

A continuación, mostramos algunos circuitos esquemáticos y diseño de los circuitos impresos.

Placa de optoaislación terminada.

Detalle de la cara superior de la placa optoaisladora.


Placa adaptadora de DB-37 a DB-9.

Circuito esquemático del puente H.


Detalle de la cara inferior y superior del circuito impreso para el puente H.

Paso 19: Ahora tiene otro color

Finalmente, el martes pasado adquirimos la fuente switching de 24V y 4.2A, suficientes para alimentar al motor con los 24V nominales especificado en la hoja de datos.

Destacamos nuevamente que las pruebas fueron hechas a lazo abierto, con el único objetivo de contrastar el modelo matemático a los datos arrojados por la planta. Con ésta misma idea, obtuvimos las curvas anteriores (paso 18 y 18 bis) que fueron dispares, especialmente en el primer caso, aunque permitieron exponer algunos defectos mecánicos que se resolvieron a tiempo.

Además, ajustamos las curvas manualmente para determinar qué parámetro tiene mayor efecto sobre el modelo y cómo éste afecta al error entre modelo y planta. De ésta forma, encontramos que la masa inercial del motor-polea es la constante que más influyó para adaptar el modelo teórico al sistema real.

La tabla muestra la variación de Jmp para cada sentido:

retroceso | avance

Prueba 1 = 7.30e-5 | Prueba 2 = 7.50e-5

Prueba 3 = 7.00e-5 | Prueba 4 = 7.50e-5

Prueba 5 = 7.37e-5 | Prueba 6 = 7.60e-5

Prueba 7 = 7.37e-5 | Prueba 8 = 7.55e-5

El ensayo del sistema con 24V ha sido más alentador de lo esperado ya que obtuvimos, experimentalmente, algunos valores teóricos planteados en un marco netamente optimista. Sin embargo, aún hay diferencias significativas entre el movimiento de avance y de retroceso, como se puede ver en las figuras a continuación:

Aquí se puede ver un defecto en el movimiento del puente grúa, provocado por un desajuste del eje del motor. En la figura 10 se destaca éste error del resto de las pruebas realizadas en retroceso

Se repitió el error de la prueba 3, ocasionando un desvío en la posición del puente durante las primeras 50 muestras del ensayo.

En conclusión, se obtuvieron respuestas homogéneas para cada sentido de movimiento con escasa dispersión en el principal parámetro de ajuste, salvo para las pruebas 3 y 6.

Quedan pendientes algunos detalles mecánicos que, por el momento, provocan las diferencias entre avance y retroceso.

Por último, la velocidad promedio del puente grúa es de unos 36cm/seg (levemente superior al calculado teóricamente) y tiempo de recorrido de 4,6 seg aproximadamente.

Paso 18 bis: Nuevos resultados

En el comentario anterior detallamos algunas causas que provocaron resultados pobres durante la adquisición de la posición del puente grúa.

Luego de revisarlas y de ajustar el sistema, obtuvimos las siguientes curvas en las que comparamos la salida del modelo lineal de la planta con los datos obtenidos.

Prueba 1: Ajuste del prisionero, tensado de la correa y eliminación de la rueda central inferior del puente.
Prueba 2: sentido de retroceso con ajuste de rueda inferior, puede verse cómo empeora la respuesta de la planta.
Planta 3: sentido de avance nuevamente. Eliminación de la rueda inferior y ajuste excesivo de la correa.

Prueba 4: Sentido de avance con ajustes optimizados.

Paso 18: Resultados que esperamos

Llegamos al momento de realizar la primera prueba para determinar qué tan alejados estamos de la realidad o no. A continuación, se muestran algunas curvas en las que se contrastan los resultados teóricos contra los experimentales para el sistema a lazo abierto y respuesta al escalón unitario.

Como podrá verse, los resultados no son muy homogeneos debido a alguna de las posibles causas: la principal, debido a un desajuste del prisionero en el eje del motor. La segunda, debido a falta de tension en la correa que tracciona al puente y en ningun caso logramos medir el rango completo de recorrido debido al resbalamiento del prisionero.

Además, los resultados preliminares arrojaron una velocidad el carro promedio ha sido de 8 cm/seg, debido a que el motor del puente está siendo alimentado (por el momento) con 12V en lugar de los 24V nominales.

Pulsando en cada imagen se podrá ver la gráfica en mayor tamaño.

Paso 17: Algunas fotos olvidadas

Encontramos entre toda la selva dispersa de archivos y carpetas del proyecto, que poco a poco vamos desmalezando, una serie de fotos de la estructura y de las cuales exponemos algunas para demostrar la existencia de nuestro trabajo.

La mayoria de estas fotos corresponden al ensamblado del puente grúa, la reducción y la polea; que se realizó por el mes de septiembre de 2007. Algunos detalles fueron acabados, mientras que aún resta solucionar la integración del motor para el desplazamiento del montacargas, la colocación de la bandeja porta cables, etc. Asuntos relacionados, específicamente, con el segundo eje de la planta.


Montacargas y sistema de guiado por medio de rodamientos lineales, formando el puente grúa en sí.

Sistema de reducción, donde se puede apreciar el montaje del motor sobre un portarodamientos deslizante. Este conjunto permite tensar la correa dentada de la reducción.


Detalles del extremo posterior de la estructura, donde se encuentra la polea donde calzará la correa dentada para la tracción del puente.

Vista inferior del puente, en el que se aprecian el puente grúa con la reducción detrás. En el techo, una desamparada boca de luz que espera paciente la instalación de un plafón.

Primer plano de la cara opuesta de la reducción.

Como se puede ver, el trabajo ha sido intenso y muy demandante, sobre todo en tiempo, ya que el 90% de las piezas fueron fabricadas por nosotros mismos. A pesar de ello, el resultado final fue lo suficientemente bueno para ser empleado en el proyecto.

Pinout db37 de la placa ADQ12B

Como es costumbre, siempre olvido en alguna parte el pinout de la placa. A propósito, acabo de encontrar en la página de Comedi el driver para la placa adquisidora ADQ12B de Microaxial. Será cuestión de probarla...

Paso 16: Modelo matemático de la planta*

1 Introducción
El objetivo de éste apartado es el desarrollo, análisis y posterior simulación del modelo matemático del sistema. Para ello, debemos contar con un planteo lo más riguroso posible de la planta real, pero sin caer en un esquema que resulte complejo de implementar más adelante.

Por éste motivo, se toma el conjunto de ecuaciones que describen la dinámica del sistema para linealizarlas y aplicar herramientas de estudio para sistemas lineales, como la ubicación de los ceros y polos, calcular ancho de banda, ganancia de contínua, tiempo de subida y tiempo de establecimiento.

Finalmente, se contraponen la simulación del modelo lineal al modelo no lineal, con el objeto de verificar la linealización de las ecuaciones para pequeñas oscilaciones del péndulo.


1.1 Modelo Matemático
Por razones de espacio y tiempo, no detallaremos todos los pasos dados para hallar el modelo lineal invariante en el tiempo del sistema, sino que nos limitaremos a expresar el modelo matemático en espacio de estados. Cuando tengamos una versión definitiva del documento, publicaremos el texto completo.

Las variables de estados quedan expresadas como,


Modelo lineal e invariante en el tiempo definido como,


1.2 Características del sistema lineal a lazo abierto
A partir del modelo desarrollado, es preciso simular el comportamiento de la planta, con el fin de verificar que las ecuaciones que la describen son coherentes con la realidad.

Inicialmente, el estudio se basa en la dinámica de la planta a lazo abierto ya que la ubicación de sus polos y ceros en el plano complejo implican un ancho de banda, ganancia de continua, error de régimen permanente y demás características, que definirán el tipo de estrategia de control a emplear.

A continuación puede verse la simulación implementada en Simulink


1.3 Parámetros de simulación
Las constantes que se emplean en el modelo de la sección 1.1, especifican las matrices A, B y C de la ecuación de estados. Se deberá tener en cuenta que muchos de los valores expuestos aquí son arbitrarios y su único fin es el delograr una primera aproximación al sistema físico construido.

Va=24 Vcc Tensión nominal
mc=1.5 kg Masa carga
mt=20 kg Masa carro principal
R=0.065 m Radio polea
Jmp=5e-5 kg·m2 Inercia motor-reductor-polea
n=35.55 Reducción
L=1.2 m Longitud de la barra
Tm=0.16 seg Constante de tiempo motor-reductor-polea
Ra=3 ohm Resistencia armadura
K=0.03 Nm/A Constante par motor

Numéricamente,


1.3.1 Ancho de banda
Otra propiedad importante de la respuesta transitoria del sistema está dada por el ancho de banda. Con éste índice podemos saber qué frecuencias se filtrarán, como así también tener una noción de la sensibilidad de la planta a la variación de sus parámetros ([Kuo96], p.544).



-------------------------------------------------------------------------------------------------------------------------------------------
* Versión reducida e incompleta

Paso 15: El nombre de la Bestia

Todo proyecto, por inútil o preciado que sea, merece una etiqueta, un nombre que lo distinga, que permita identificarlo y decir: ¡Ahí está la cosa!. Hasta el momento, nos hemos referido al proyecto como Proyecto, con P mayúscula, y eso lo hacía algo del montón a pesar de considerarlo un bien invaluable desde hace más de un año (sí, más de un año).

Es así como, sin demasiadas discusiones ni intervenciones, hemos dado en llamar al Proyecto como BORA. Entonces sí, ahora podemos señalarlo e identificarlo por sobre el resto de los proyectitos que pululan por ahí, con algo de recelo y un poco más de orgullo.

Poniéndonos serios, BORA es un acrónimo que define los pilares fundamentales de nuestro trabajo final de carrera, y con ello nos referimos a "Control de Oscilaciones Bidimensional en Tiempo Real por Visión Artificial".

En el transcurso de los próximos días y semanas, iremos publicando información que abarcará los temas que definen al proyecto con el objetivo de servir como guía a futuros proyectos relacionados con el nuestro.

En caso de que les interese un novedoso fondo de pantalla, aquí dejamos uno para su deleite.

Paso 14: Avances estructurales. Diseños, cálculos y pruebas.

En este último mes hemos estado sumergidos en desarrollos teóricos en las áreas de Control y Mecánica del sistema. Partiendo de diseños físicos de la estructura y obteniendo numérica y experimentalmente diversos valores de interés, comenzó la primera etapa de identificación de la planta. Abordaremos este tema más en detalle en las sucesivas publicaciones, pero a modo introductorio puede mencionarse que, del resultado de la aplicación de diferentes leyes de la física clásica para la translación y rotación de un cuerpo (conocidas como Ecuaciones Mecánicas) y mediante el estudio del comportamiento eléctrico de los motores (Ecuaciones Eléctricas), se obtuvo el primer modelo del sistema. Este mismo fue sometido a simulación a lazo abierto y se han sacado las primeras conclusiones.
En cuanto a los avances mecánicos, se efectuaron refuerzos mediante la fabricación de cuatro escuadras que fueron montadas en cada extremo de la estructura de perfiles reduciendo así notablemente las oscilaciones. Para su sujeción, fue empleada la misma metodología que se venía utilizando, piezas deslizantes de juego reducido por las ranuras de los perfiles, que poseen la cualidad de aumentar el cuerpo del material para la sujeción y facilitar el armado.

Tras largas deliberaciones sobre cual sería el sistema de tracción más eficiente a emplear y que cumpla con los requisitos ya mencionados aquí, nos hemos decidido por utilizar, para ambos movimientos, transmisión por correa dentada. En particular, paso 8M (un diente cada 8mm).

En cuanto al sistema de deslizamiento, para el movimiento longitudinal (aquel que transporta el puente), se fabricaron seis ruedas de Grilon acanaladas cuyo diseño hizo hincapié en que, al rolar, se evitasen acuñamientos entre la rueda y la guía, y se reduzcan movimientos axiales indeseados. Finalmente, estas piezas harán que el conjunto se desplace sobre cuatro barras de acero inoxidable como se muestra en la foto. El motivo de la elección de este material para emplearlo como guía es sencillo de deducir. Debíamos utilizar uno tal que no presente impurezas en su superficie que generen un coeficiente de roce elevado. Su costo es considerablemente reducido si se lo ha de comparar con una barra de acero templada y rectificada. Para su sujeción, fabricamos dos piezas por barra que fueron colocadas en los extremos y, mediante piezas deslizantes, fijadas a la perfilería.

Para los diseños del puente, hemos adquirido recientemente dos placas de aluminio de 15mm de espesor, en las cuales serán fijadas el sistema de ruedas acanaladas. Con una disposición de dos ruedas superiores y una inferior por lado, donde cada una ha sido montada sobre un eje y rodamiento. A modo de visualizar su terminación y rodadura, hemos montado el conjunto sobre un modelo en madera. Esta experiencia nos permitió considerar diversos factores desconocidos hasta el momento. Evaluamos medidas finales, escuadras y flexiones, entre otras cosas.

Pero quizás, el ensayo más importante para el equipo, fue una prueba de pesos. Nuestra inquietud era saber en la práctica, si nuestros motores serían capaces de mover el puente proyectado. Conocíamos mediante cálculos teóricos, el peso aproximado de éste dependiendo de los materiales que se emplearían y las dimensiones de cada uno, logrando un peso total del puente de 20Kg aproximadamente. Debido al hecho de que el motor a emplear para el movimiento longitudinal posee un número de vueltas superior al máximo permisible que consideraremos, será necesario fabricar una caja de transmisión con dos finalidades pre-establecidas: Disminuir la velocidad de desplazamiento del puente y aumentar el torque motor en el eje de la polea responsable del movimiento. Los detalles de ésta caja, que actualmente se encuentra bajo construcción, serán dados oportunamente. Lo que queremos denotar aquí es que se logrará una velocidad máxima de desplazamiento del puente de 300 mm por segundo (con el motor girando a su velocidad nominal de 90 RPM), y obteniéndose una fuerza de empuje tangencial de 5,5 Kg.

Volviendo a la experiencia de los pesos, mediante esta se comprobó que aplicándole una fuerza en el sentido del movimiento de 3,5 Kg, era capaz de desplazar un puente de 32,4 Kg (un 62% más que el hallado con una fuerza menor a la calculada).

Como se mencionó, nos encontramos desarrollando las dos cajas de transmisión del proyecto, como así también la estructura final del puente, es decir todo lo que concierne a las guías, soportes y el carro de desplazamiento transversal. Además, continuamos efectuando simulaciones en pc del comportamiento del conjunto buscando, de alguna manera, darnos seguridad en nuestros diseños e implementar un sistema de control adecuado.

Paso 13: Sobre el control, los controladores y lo controlado

Cuando empezamos éste proyecto habíamos dado por descartado el uso de PCs para realizar el control de la planta o sistema. Sin embargo, luego de haber analizado repetidas veces la arquitectura de control empleando microcontroladores, nos encontramos con severas limitaciones de cálculo, por lo que pensamos en otras variantes al esquema propuesto inicialmente.

En el comentario anterior (Paso 12), hicimos una reseña de los tres sistemas operativos de tiempo real que teníamos a disposición y cuál terminamos adoptando. A continuación, damos un breve repaso por los distintos temas que abarcamos hasta la fecha.

Tiempo Real
La búsqueda fue orientándonos a una herramienta de código abierto u open source, de tiempo real, con buena y accesible documentación, etc. Hasta que dimos con RTAI (Interface de Aplicación de Tiempo Real) y comenzamos a investigarlo y experimentar exhaustivamente, con algunos muy buenos resultados.

Dado que contamos con escasa (nula) experiencia con Linux, buscamos versiones booteables o LiveCDs que incluyan RTAI para evitar la recompilación del kernel y aprender comandos básicos de Linux evitando su instalación definitiva en la máquina.

Una de las mejores versiones que encontramos fue una distribución Knoppix 5.0 con RTAI 3.4 y kernel 2.6.17, que incluye la biblioteca Comedi y varios ejemplos de aplicación. Ésta se puede encontrar en PmWiki y en http://www-lar.deis.unibo.it/people/gpalli/files/rtai_knoppix.iso

Cuando cumplimos unas cuantas horas de vuelo, probando y errando, instalamos el sistema operativo y comenzamos el desarrollo del control, o los primeros esbozos.

Un esquema de la arquitectura de control se puede ver a continuación, donde una computadora realizará el control propiamente dicho, mientras la otra captura las imágenes de video y envía, por el puerto serial, la posición estimada de los objetos bajo la plataforma.

Fig. 1: Esquema de control en Tiempo Real con RTAI.

Placa Adquisidora
El control por sí mismo no tiene sentido si carece de comunicación con el exterior. Para ello es necesario la placa adquisidora, que se encarga de obtener la señal de los sensores y enviar órdenes a los actuadores, para que la acción tenga efecto.

En nuestro caso, nos conformamos con una placa adquisidora de origen nacional, marca microAXIAL, modelo ADQ12-B.

Entre sus características, podemos contar con:

- Conversor de 12 bits.
- 16 canales desbalanceados y 8 diferenciales, 10 useg de conversión.
- 8 salidas y 5 entradas digitales.
- Contador de 16 bits y Pacer de 32 bits.
- 2 entradas de interrupciones enmascarables.

Lamentablemente, los recursos disponibles impiden tener un driver para ésta placa que sea compatible con RTAI, por lo que habrá que diseñar uno a partir de la biblioteca ofrecida por Comedi (Linux Control and Measurement Device Interface).

Aun así y a fin de evitar semejante embrollo, desarrollamos todos los ejemplos iniciales con la dirección de memoria del puerto a la que apunta la placa, a través de las funciones outb() e inb().

Programación
La mejor forma que encontramos para aproximarnos a la estrategia de control final, fue desmenuzando las diferentes tareas a ejecutar por el controlador en:

Salidas Discretas: PWM y pulsos.
Entradas Analógicas: Posición angular.
Entradas Discretas: Encoders.
Control.
Comunicación.

Hasta el momento, los resultados obtenidos con RTAI nos permiten tener, cómodamente, un período de interrupciones de 100 useg (10 KHz), aunque puede ser reducido aún más.

Otras pruebas en las que funcionaron tres tareas de tiempo real en un mismo módulo, arrojaron un tiempo mínimo de interrupciones de 40 useg (25 Khz).

Ahora podemos enfocarnos en el diseño definitivo del control mientras terminamos de construir los carros que van montados sobre la estructura y que conforman la planta, o el sistema, a controlar.

Paso 12: Algunos cambios y comentarios previos

Comprendemos que la página ha tenido escasa actualización desde marzo pero el proyecto en los últimos dos meses ha ido consumiendo cada vez más tiempo hasta abarcar el 90% de nuestro día aprovechable.

Sin embargo no son pocas las cosas que han sucedido, y ello tiene que ver con cambios sustanciales en el desarrollo del trabajo y las ideas que tenemos al respecto.

En primer lugar, desde principios de marzo sumamos la fuerza de un tercer integrante: Fabián Andrés Dipane.

Una sesión con el equipo completo.

Con él vamos a tener un importante aporte en el diseño y construcción de la mecánica del sistema, como así también en la electronica y programación que falta terminar. Próximamente, Fabián irá agregando comentarios a la página explicando detalles sobre el proyecto.

En segundo lugar, nuestra idea de emplear microcontroladores de 8 bits fue reemplazada por el uso de un Sistema Operativo en Tiempo Real (RTOS, en inglés) junto a una placa adquisidora de marca nacional. Las principales implicaciones de éste cambio tuvieron que ver con el estudio y familiarización con el nuevo sistema operativo, además de un comprensión intensiva y extensiva de los paquetes de tiempo real existentes.

De ésta forma, buena parte de febrero se invirtió en la búsqueda y selección del sistema operativo en cuestión. De allí surgieron 3 variantes posibles:

- QNX
- RTLinux
- RTAI

Finalmente, encontramos en RTAI la opción más sólida al poder acceder a una herramienta en constante desarrollo y, sobre todo, GRATUITA. Además, cuenta con RTAI-Lab, un paquete para desarrollar controles con diagramas de bloque sin tener que salir del ambiente Linux.

Con todo ésto en mente, los dos meses que siguieron a febrero fueron destinados casi por completo a la finalización de la estructura de la planta y al estudio de RTAI como plataforma de programación.

Paso 11: Estructura de Perfiles de Aluminio Terminada

En una entrada anterior, les comentamos sobre el viaje realizado a la ciudad de Rosario con el objeto de adquirir los perfiles de aluminio que se emplearían para confeccionar la estructura. Sobre ella se montarán los rieles para el desplazamiento lineal del conjunto, transmisiones, motores, actuadores y cámaras. Mencionamos además, ideas de costos en comparación con materiales importados y manifestamos también ventajas y desventajas. Ahora bien, lo que quizás no teníamos en cuenta a la hora de emplear este tipo de materiales, sería el costo de los accesorios para su ensamble. Para dar una idea estimativa, entre uniones, escuadras, tornillería, zócalos, patas y tapas, el precio igualaría el monto de los 18 mts de perfiles. El problema era claro, y la solución también, fabricar nuestras propias uniones y accesorios.

Surgieron varios diseños, sin embargo no lográbamos aquel que cumpla con ciertos requisitos propuestos, fue entonces cuando hallamos el sistema definitivo. La idea tomaba como base la confección de piezas capaces de deslizar sin juego en las ranuras de los perfiles y que unas a otras (empleando tornillería allen por su grado de apriete), habrían de combinarse de manera de obtener uniones firmes, que mantengan escuadrado al conjunto, cuidando en todo momento un buen nivel de terminación.

Fue así que, en la segunda semana de Febrero, comenzó la confección de las mismas. Sobre un total de 48 piezas fabricadas, 6 procesos de mecanizado en torno, limadora, agujereadora radial, lijadora banda y convencional, sierras y Blasting y 54hs de construcción, finalizó ésta etapa con resultados por demás exitosos.

Sin considerar los perfiles, la estructura cuenta con un total de 80 piezas, cada una de ellas enumeradas por conjuntos para obtener un correcto y fácil ensamble. Para dar por acabada ésta etapa, deberán de construirse por estos días, 4 escuadras y 8 piezas para su sujeción.

A continuación les mostraremos distintas imágenes de algunos procesos empleados:

Torneado: Partiendo de una varilla roscada, se efectuó el frenteado del plano a emplear, para luego, con una mecha de centro y la contrapunta, realizar el agujero guía de mecha.

Posteriormente se hizo un orificio de 50mm de profundidad con una mecha de 6,75mm para, finalmente, roscar en 5/16". Esta pieza una vez terminada se alojará dentro del perfil previamente roscado y será utilizada para la unión de dos piezas.

Limado: Tras la adquisición de una barra de hierro de 1" por 1/2", se empleó la limadora para su desbaste y la confección del destalonado necesario para obtener un tipo de pieza que deslice, sin juego, por las ranuras de los perfiles de aluminio. El proceso consistía en rebajar la cara mayor 7mm, luego realizar trazados a lo largo de la barra y finalmente efectuar los rebajes donde alojarán, una vez terminadas y montadas las piezas, las cabezas de los tornillos de sujeción. El inconveniente a la hora de emplear este tipo de máquina es la necesidad de obtener un adecuado paralelismo entre la herramienta y la pieza.

Una vez que se obtuvo la pieza, la misma fue marcada y agujereada en dos etapas en una máquina radial. La primera parte consiste en la realización del orificio pasante de los tornillos, y en la segunda parte, confeccionar el alojamiento de las cabezas de los mismos. Finalmente la pieza fue cortada para obtener de ella las uniones. Además, para un número más pequeño de partes, fue necesario una tercera etapa de agujereado y posterior roscado.

La imágen siguiente muestra el sistema de unión y su cuidada terminación:

Y he aquí la estructura montada:

La estructura de perfiles cuenta con un largo propuesto de 2,10 mts, ancho 1,57 mts y alto 1,28 mts (dependiendo de la regulación de altura de las patas). Estas dimensiones no son arbitrarias, ya que lo que realmente nos interesa, son las medidas efectivas de desplazamiento (2 x 1,5 x 1,2). Como se ha mencionado, por estos días estaremos construyendo las escuadras restantes, como así también el sistema de desplazamiento lineal. Mientras tanto, el equipo se encuentra investigando diferentes entornos de tiempo real para el manejo del movimiento planar.