Paso 27: Foucault, la oscilación y el péndulo

En el año 1851, León Foucault instaló un péndulo de la cúpula del Panteón de París para demostrar los efectos de rotación de la Tierra y de la fuerza de Coriolis.

Casi un siglo y medio más tarde, modestos estudiantes de ingeniería de la Universidad de Quilmes, colgaron de la base inferior de un puente grúa, un péndulo muy similar para demostrar todo lo contrario: que el control de posición del puente ayuda a eliminar las oscilaciones del péndulo durante la actuación del sistema.

Para lograrlo y verificar que el sistema responde a las restricciones del diseño, se diseñó un circuito para sensar el ángulo de oscilación de las cargas, en el que la pieza clave es el sensor de aceleración o inclinación MMA7260QT de Motorola.

Dado que el péndulo oscila en el plano x-y, éste sensor de 3 ejes es ideal para éste propósito. Además cuenta con una buena sensibilidad de respuesta para el rango de 1.5g y una excelente resolución para el rango de sensado previsto de +/- 20º.

Para más información sobre el sensor, la hoja de datos puede decargarse desde aquí.
Si, además, te interesa la literatura Umberto Eco escribió El péndulo de Foucault.

Paso 26: Mejoras en la respuesta del control

Se hicieron algunas correcciones sobre el algoritmo de control y probaron nuevas ganancias de realimentación en el esquema LQR, que resultaron en una mejora sustancial en la respuesta de la planta al seguimiento de referencias de posición.

En la figura 1, se muestran las curvas de referencia de posición y la posición medida del puente grúa. La figura 2 muestra la respuesta de la planta en velocidad (estimada) respecto de la referencia de velocidad, en la que aún se puede ver un desempeño pobre cuya causa podría estar dada por errores en los parámetros del modelo.

fig. 1 fig.2

La figura 3, muestra la señal de actuación respecto de la velocidad desarrollada por el puente. También en éste caso, la actuación sigue siendo ruidosa debido al mismo motivo formulado anteriormente.

fig.3

Además, ya se instalaron los finales de carrera para el movimiento del carro montacargas.

Paso 25: No podían faltar los videos

La cosa camina, y camina así...

Paso 24: La criatura vive!

El momento que tanto esperamos y para el cual estamos trabajando, finalmente ha llegado y de un modo extrañamente calmo.

Los últimos días han tenido cierta intensidad en nuestra actividad, con la intención de finalizar definitivamente los detalles que corresponden a la estructura del puente grúa. En la lista de actividades pendientes aún quedan:

• Instalar los 4 finales de carrera.
• Instalar el pivot para la barra y la barra del péndulo.
• Armar, probar e instalar el sensor de inclinación.
• Instalar la cadena portacable del puente.
• Armar e instalar el gabinete para las fuentes de alimentación y placas electrónicas.
• Armar, probar e instalar el puente H para el segundo motor (IGNIS MR8-78).
• Conectar el segundo encoder a la interfaz optoacoplada.
  
• Cablear la estructura.
• Ajustar el eje del motor IGNIS MR5-90 a la caja reductora o reemplazar el sistema actual de ajuste.
  
• Alguna otra cosa que siempre falta.
  

A pesar de la lista todavía extensa de tareas, la planta se encuentra en una etapa lo suficientemente avanzada como para hacer las primeras pruebas de control. En éste sentido, se ha implementado como ley de control un sistema por realimentación de estados óptimo con observador, para estimar los estados de la posición y velocidad angular del péndulo y la velocidad lineal del puente. Entre la lista de tareas tenemos por hacer:

• Estimar los parámetros del modelo para mejorar el observador y el control.
• Implementar control LQR con acción integral.
• Implementar rutina para realizar un homming del puente y montacargas para corregir errores de posición.
• Agregar algunos estados faltantes en la máquina de estados en el módulo de control.
• Implementar de ser posible una interfaz para ver las curvas del proceso en pantalla.
• Alguna otra.

Los esquemas de control implementados con realimentación de estados y realimentado mediante el uso de un observador de orden completo se pueden ver más abajo. Además, se incluyen las gráficas obtenidas en el primer ensayo de control realizado sobre la planta real. Los parámetros de control estuvieron fundados sobre los parámetros establecidos para el modelo simulado. Como se puede evidenciar, existe una pequeña desviación entre el modelo y la planta, nada que no pueda solucionarse.

 

Paso 23: El eje postergado

Del papel al metal, del metal a la herramienta, de la herramienta a la forma. Con el segundo eje de movimiento instalado completamos el armado de la estructura que fue concebida para éste proyecto.

En las imágenes que se presentan a continuación, se pueden ver los detalles de su construcción.

Paso 22: Envuelto para regalo

Nos aproximamos a la conclusión de algunas etapas del proyecto y, por ende, es menester ordenar las ideas, agrupar conceptos y rectificar esquemas incorrectos. De ésta forma, se definirán el sistema mecánico, como una de las tareas de mayor dificultad, y el desarrollo del software, principalmente la rutinas de ejecución del control.

Hasta hace unas semanas contábamos con una serie de funciones que trabajaban de manera individual, pero que resultaron útiles para verificar diversas aspectos como la comunicación serial, interfaz con la placa adquisidora, ejecución de los lazos de control, etc. Sin embargo, llegamos al estado en que todos estos bloques inconexos deben estar enlazados entre si para conformar el programa final y se facilite la tarea de puesta punto antes de la presentación.

Inicialmente, para los primeros ensayos, contábamos con algunas instrucciones que recibían parámetros de configuración y estado. A medida que el soft crecía en funcionalidad, se debían pasar un mayor número de parámetros o la repetida compilación del programa afectando un conjunto limitado de variables y macros. Ésta dificultad desencadenó la necesidad de emplear una herramienta más versátil y que nos permita armar una interfaz simple con el usuario para la configuración del sistema completo.

El camino nos llevó hasta ncurses y los resultados hasta el momento han sido satisfactorios. Hemos logrado interactuar de manera sencilla con la planta, modificando los parámetros deseados y ejecutando las rutinas principales del sistema.

Una captura de pantalla muestra el aspecto que tiene la interfaz de usuario:

Enfocados sobre los detalles del software, hemos establecido dos ámbitos sobre los que se fundaron todos los componentes empleados.

El primero, definido en el espacio del kernel y con el soporte de RTAI, se trata de un módulo cargable destinado a la ejecución de una tarea de tiempo real denominada Despachador, que Se implementó como una máquina de estados, encargada de establecer el modo de trabajo del sistema. La tarea recibe tres parámetros desde el proceso usuario por medio de un FIFO: Modo, Frecuencia y Comando; destinados al modo de trabajo, frecuencia del PWM y comando de operación, respectivamente.

En detalle podemos decir que la tarea de tiempo real realiza las siguientes operaciones:

- Bucle principal: selecciona la accion a realizar dependiendo del modo de trabajo seleccionado por el usuario.

* Modo Libre: Funciona a lazo abierto y sirve para determinar si comunicación y drivers funcionan correctamente.

* Modo Control: Es el modo principal donde queda definido el sistema de control.

* Modo Calibración: Realizar ajustes de cero y ganancia para posición lineal y angular de los sensores.

* Modo Espera: Queda a la espera de una nueva acción a ejecutar y depende del modo de trabajo seleccionado.

Además, cuenta con las siguientes rutinas:

- Comunicación: módulo que permite la comunicación half-duplex entre la PC y el uC, para todos los modos de trabajo.

- Actuación: Dependiente del motor y determina las referencias, ciclos de trabajo de los pwm y otros datos a determinar.

- Sensado: Destinado a la captura de los pulsos de los encoders e inclinómetro.



En segundo lugar, quedó definido en el espacio de usuario el proceso encargado de realizar la interfaz con el operador. Presenta un menu de configuracion, comandos y visualizacion de datos (posicion, angulo, velocidad, estado de la comunicación, etc). Inicialmente el usuario elige el modo de trabajo deseado (libre, controlador, calibrador), luego la frecuencia de los PWM de una lista de opciones que dispone el uC y finalmente, el menú de comandos. Éste último menú permite por un lado, mediante las teclas 4, 6 y 1 hacer avanzar, retroceder y deterner el puente, por el otro, muestra en pantalla la configuración de trabajo y los datos recibidos desde la planta.

Paso 21: Ejemplos de aplicación 2º Parte - Atmega16

Otro de los aspectos que concierne al desarrollo de nuestro proyecto final de carrera, tiene que ver con el microcontrolador de Atmel, Atmega16.

Éste microcontrolador de 8 bits, presenta una serie de características que lo hacen especialmente funcional con nuestros requerimientos. La principal deficiencia que nos presenta el hardware disponible, es el escaso número de entradas y salidas discretas de la placa adquisidora para poder realizar el ciclo de control de manera integral en la PC.

Por éste motivo, el microcontrolador Atmega16 nos permite, por un lado, establecer la comunicación con la PC por medio de RS-232, y por el otro, realizar una interfaz apropiada para la salida de 2 canales PWM en un amplio rango de frecuencias. También, en caso de ser necesario, se encargará de detectar los pulsos de los 2 encoders montados sobre la estructura.

A continuación publicamos dos ejemplos de aplicación, realizados durante la fase de diseño para probar los módulos de salida PWM y de comunicación por medio de la USART.

El entorno de desarrollo elegido es WinAVR , el compilador GNU GCC y la librería de C para AVR avr-libc. Si bien los ejemplos están pensados para Atmega16, también pueden aplicarse a otros modelos de la familia, como Atmega32, Atmega8, etc. por medio de modificaciones menores.

PWM.c (con interrupciones)

#include <avr/io.h>
#include <avr/boot.h>
#include <avr/interrupt.h>
#include <avr/signal.h>
#include <avr\sfr_defs.h>

enum { UP, DOWN };

INTERRUPT (SIG_OVERFLOW0) /*SIG_OUTPUT_COMPARE0*/
{
static unsigned char direction;
static unsigned char pwm;

switch (direction)
{
case UP:
if (++pwm == 255)
direction = DOWN;
break;

case DOWN:
if (--pwm == 0)
direction = UP;
break;
}

OCR0 = pwm;
return (0);
}


int main (void)
{
/* Define PB3 como salida PWM (pin 4)*/
DDRB = (1 <<3);

TCCR0 = (0 << FOC0)|(1 << WGM00)|(1 << COM01)|(0 << COM00)|(1 << WGM01)|(1 << CS02)|(0 << CS01)|(0 << CS00);

/* valor de comparacion inicial */
OCR0 = 0;

TIMSK = (1 << TOIE0);
sei();

for (;;)

return (0);
}

RS232.c (Envía y recibe caracteres por polling)

#include <avr/io.h>
#include <avr/boot.h>
#include <avr/interrupt.h>
#include <avr/signal.h>
#include <avr\sfr_defs.h>

#define FOSC 1000000 // clock en Hz

/* prototipos de funcion */
void  bucle (void);
void  uart_enviar(unsigned char *, unsigned char);
unsigned char  uart_recibir(void);

/* variables globales */
unsigned int cuenta;


int main (void)
{

UBRRH=0x00;
UBRRL=0x0C;     //Baud rate = 4800
UCSRA=0x00;

UCSRB=0x18;     //TXEN=1 y RXEN=1 (Habilitacion Transmision y Recepcion)

UCSRC=0x86;     //1 bit Stop. 8 bits por Caracter

bucle();
}

void uart_enviar (unsigned char *dato, unsigned char cant_dato)
{
unsigned char i;

for(i = 0; i < cant_dato; i++)
{
 UDR = *(dato+i);
 while(!(UCSRA & (1<<TXC)));
 UCSRA=0x40;
}

}


unsigned char uart_recibir(void)
{

while( !( UCSRA & ( 1 << RXC) ) );

return UDR;
}


void bucle(void)
{
unsigned char rx;
unsigned char *cadena = "Tx y Rx Test\n";

cuenta = 0;

while(1)
{
 rx = uart_recibir();

 uart_enviar(cadena, strlen(cadena) );
}
}

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.