Analizador de vibraciones.

[donrodrigo]

Bueno, pues esto parece que va encajando. Ya tenemos captura y conversión, incluso con monitorizacion en tiempo real, para un canal. Así que vamos a avanzar.
Este es el material que estoy usando.



Por cierto a ver si algún moderador puede redimensionar la foto, porque desde el ipad tengo algún problemilla con la aplicación de imageshack.
A la izquierda vemos el acelerometro. Se puede comprar tal y como viene en la foto por 9€, y evitamos tener que soldarlo. Los condensatas que he marcado conforman un filtro pasabajos para cada eje, limitando el ancho de banda de la señal de salida. Por defecto todos los ensambladores montan 100nF. Esto corresponde a una frecuencia de corte de 50hz con una pendiente de -3dB. Este valor es demasiado bajo para nuestras intenciones. Si eliminamos estos condensadores aumentamos el ancho de banda, pero a cambio tendremos ruido de alta frecuencia. Por este motivo los vamos a sustituir por otros de 4,7 nF; con lo que conseguiremos un ancho de banda de algo más de 1,1 KHz, más que suficiente para nuestros propósitos. Este cambio puede hacerse perfectamente con un soldador doméstico, por ejemplo yo uso el 14ST de 11W de BJC, algo de flux y unas pinzas de punta fina.
A la derecha vemos un arduino pro mini, alrededor de los 14 €, que en este caso puede adaptarse perfectamente a nuestros propósitos : tamaño muy reducido, 16 MHz de frecuencia de trabajo, bajo precio y ya viene montado. En caso de que la RAM sea insuficiente ya tendríamos que acudir a un micro más grande, pero yo voy a intentar hacerlo en este por simplificar. Como veis los tamaños son muy comedidos. Falta el módulo para la microsd, que no tengo por aquí ninguna foto. Cuando llegue a casa ( estoy de viaje ) iré añadiendo más detalles. Falta en la foto el cableado, que incluye un estabilizador de tensión de 3,3 Volt en SMD, que va a proporcionar la alimentación del acelerometro y la tensión de referencia para el puerto ADC del micro. Luego todo esto se mete dentro de un termorretractil y se le pone cinta de doble cara, y lo pegamos al heli. Un cable tipo servo al bec y a volar.

Bueno, pues edito para añadir una foto del slot para microsd transflash.





Se comunica vía SPI con el micro. Aún no se sí se podrá meter tanta cosa, mañana cuando vuelva a casa seguiré con las pruebas e iré puliendo más el tema. Como se ve en la foto el tamaño es también muy reducido. De este módulo no tengo precio actualizado, creo que en su día me costo 8 o 9 pavos. No recuerdo exactamente, pero no creo que se vaya mucho más allá. También se podría pillar el zócalo y hacer algún apaño pero montado así queda más limpio. Una vez conectadas las tres piezas se pliegan en un sándwich para que ocupe el mínimo espacio posible, y se enfundan en un termorretractil, dejando la apertura para la microsd a la vista. También hay que dejar algunos pines para comunicación serie con el pc mediante un adaptador USB-FTDI o similar. Cuando haga el ensamblado definitivo subiré algunas fotos del engendro. 
Otra opción que me he planteado es usar una eeprom externa en vez de una microsd. El bus I2C consume menos recursos y es más rápido. Lo que haríamos es grabar los valores de amplitud para cada frecuencia en la eeprom externa, y descargarlos al conectar al pc. Sobre la marcha iremos adaptando el proyecto a las capacidades.


Un saludo.

[rociero]

Que rapidez, pues está cogiendo muy buena pinta....y además muy económico, saludos.

[donrodrigo]

Wenas. Pues aunque estoy algo liadillo con el curro y con el X5 que estoy retocando una miajilla, ya dispongo de un prototipo semifuncional. Trabaja en dos modos, seleccionables mediante un jumper.
a) modo captura. Lee los datos desde el acelerometro, y los almacena en una eeprom 24FC1025 de microchip, de coste mas economico ( cuesta unos 4€ o menos) que una microsd y su lector, y mas sencillo de implementar a efectos de firmware. La captura se realiza durante un ciclo de tiempo limitado y a continuación queda en espera, para evitar que se llene la eeprom y se generen errores.
b) Modo lectura. Se conecta mediante un cable fdti o un dispositivo ftdi al puerto serie del micro, y queda a la espera de recibir un comando que inicia la descarga. Este comando lo envía la aplicación del pc, que se encarga de realizar el calculo de la FFT y presentar un gráfico con los resultados. De esta forma descargamos al micro, con la idea de poder meter mas funciones mas adelante.

De momento y mientras va evolucionando esto, estoy realizando pruebas en un solo eje. Mas adelante veré si vale la pena implementar un eje mas, o si vcapturo algún dato mas que sea de interés, como por ejemplo las vueltas del motor o la tensión de las celdas de la batería. Para un 3S aun hay capacidad para leer las tres celdas.
En este momento estoy trabajando en la app para el pc. Esto es lo que mas me cuesta puesto que no soy programador, asi que estoy usando processing que me resulta mas asequible ( aunque he hecho algo con visual studio, la api de windows me resulta bastante indigesta, y mas aun cuando uso linux en mi pc   ). Despues exportaré una app y a correr. Si alguno de los multiples informaticos del foro tiene el gusto de hacer algo mas profesional, gustosamente le mandaré el primer ejemplar plenamente funcional para que desarrolle un soft al gusto.
Un saludo.

[Spare]

Empezar por un solo eje me parece bien para empezar.
¿has pensado en emplear memorias flash serie SPI en vez de I2C? Por unos 5-8€ nos ponemos en 8Mbytes con velocidades de decenas de ns.
Yo hasta ahora hacía todo en labview (licencia en el curro), pero processing parece que da bastante juego y es gratuito.

[donrodrigo]

Empezar por un solo eje me parece bien para empezar.
¿has pensado en emplear memorias flash serie SPI en vez de I2C? Por unos 5-8€ nos ponemos en 8Mbytes con velocidades de decenas de ns.
Yo hasta ahora hacía todo en labview (licencia en el curro), pero processing parece que da bastante juego y es gratuito.

La verdad es que si lo he pensado, pero he puesto lo que había por casa. Esto es un hobby, no me dedico a esto, así que voy aprovechando lo que me va sobrando de otros proyectos. :D
Un saludo

[donrodrigo]

Aunque llevo algunos dias liado con el curro (que no nos falte), el X5 que he tenido que arreglar y el brico de la fuente ( a ver si subo las fotos ya acabada);  he estado trasteando con este proyecto. Tras verificar que es perfectamente viable, he pensado en  añadir mas funcionalidades puesto que montar un dispositivo solo para medir las vibraciones me parece poco. Asi que he estado pensando en ir mas allá, mediante una plataforma mas potente. Concretamente un cortex m4. Concretamente el  MK20DX128VLH5. He seleccionado este dispositivo por dos razones: primero el precio de las plataformas premontadas ( por ejemplo la teensy 3.0) que sale por unos 19$ ( unos 14€ mas portes), lo que nos permite disponer de una potencia superior por el mismo precio sin tener que hacer ni una soldadura. La segunda razon es que me dejaron uno para probarlo y me lo he quedado jijijijiji.
En fin este es el dispositivo:



Como veis el tamaño sigue siendo muy reducido. Y ya de golpe disponemos de posibilidades de para monitorizar la tensión individual de cada celda de una 6S sin añadir nada mas que un conector para ella, o incluso un sensor para la temperatura de la batería.   Ire añadiendo mas actualizaciones conforme avance el tema.
Un saludo.

[donrodrigo]

Bueno despues de ver que el MK20DX128VLH5 solo admite entradas analogicas hasta los 3.3V, he optado por usar el MK20DX256VLH7, ensamblado por unos 19.80 $ en la plataforma Teensy 3.1. Este micro sale por unos céntimos mas que el anterior, y tiene la ventaja de que las entradas analógicas admiten hasta 5V, con lo que las lecturas de las celdas de las baterías se pueden hacer de forma directa, sin usar divisores de tensión, y la frecuencia de reloj del micro se eleva hasta los 76MHz. En este momento no tengo ninguno en casa, así que he pedido uno puesto que me interesa mucho desarrollar este proyecto. Mientras tanto trabajare con el que tengo puesto que el código es 100% compatible, con lo que simplemente tendría que recompilar y ya esta.
Puesto que disponemos de suficiente potencia, estoy planteando lecturas de vibraciones, tensión de las celdas, temperatura de la batería (mediante una sonda que adheriremos a la batería mediante velcro), amperaje de descarga de baterias ( asi sabremos si las C's son reales), y podriamos añadir RPM's del motor ( cuando vea que clase de señal entrega el sensor). Si a alguien se le ocurre algo mas se aceptan sugerencias.
Un saludo.
 

[HiNote]

A mi se me ocurre mirar también el voltaje de la electrónica, para saber si es estable durante el vuelo y que no haya caídas.

Otra cosa posible a añadir es llevar un registro de la rssi de los receptores que dispongan de esta salida...

Así de pronto es lo que se me viene a la cabeza.

[donrodrigo]

A mi se me ocurre mirar también el voltaje de la electrónica, para saber si es estable durante el vuelo y que no haya caídas.

Otra cosa posible a añadir es llevar un registro de la rssi de los receptores que dispongan de esta salida...

Así de pronto es lo que se me viene a la cabeza.

Oído cocina!

[Spare]

Esto se pone interesante.

Yo estaba trabajando en un circuito similar pero con un PIC (porque es lo que conozco y tengo en casa), y mi idea era monitorizar las aceleraciones (vibraciones), gyroscopo, tension de bateria y de electronica, temperatura de bateria, ESC y motor, corriente de descarga, RPM y estado de los canales del RX (leyendo el sbus de los rx futaba), aunque anda aun un poco verde porque creo que voy a hacer cambios.
Creo que la temperatura del ESC y motor son interesantes

[donrodrigo]

Esto se pone interesante.

Yo estaba trabajando en un circuito similar pero con un PIC (porque es lo que conozco y tengo en casa), y mi idea era monitorizar las aceleraciones (vibraciones), gyroscopo, tension de bateria y de electronica, temperatura de bateria, ESC y motor, corriente de descarga, RPM y estado de los canales del RX (leyendo el sbus de los rx futaba), aunque anda aun un poco verde porque creo que voy a hacer cambios.
Creo que la temperatura del ESC y motor son interesantes

La temperatura del esc tambien pensaba en meterla, es sencilla mediante un TMP36 como el que he usado en el brico de la fuente. Este mismo sensor lo podemos usar para la bateria. De hecho los sensores que vienen en los cargadores de baterias para medir la temperatura son de este tipo puesto que son muy sencillos de implementar. Pero medir la temperatura del motor se hace algo mas impreciso puesto que tienes que hacerlo indirectamente, sin contacto. Habia pensado en medirla mediante un sensor de temperatura sin contacto ( por IR ) tipo el MLX90614. Lo que pasa es que ese sensor ya se va a los 13 o 15 pavos ( mas o menos ). Que te estabas planteando tu para el motor?.






En el tema de la calidad de la señal del receptor, no dispongo de ningun receptor con salida RSSI, y la verdad es que tampoco me apetece abrir alguno de mis futaba RS6208SB para pinchar en el chip y sacar señal. No son precisamente baratos. Asi que no se que tipo de señal es : analogica, PWM .... ¿has tenido ocasion de comprobarlo? Si lees el canal s-bus obtienes datos de la calidad de la señal del receptor o solo los paquetes enviados a los servos? No he tenido la ocasión de experimentar con esto. 
Con los PIC sintiendolo mucho no puedo ayudarte. Me forme con los  ATMEL ( por razones que no vienen a cuento ;:D ) y llevo un tiempo estudiando los Cortex, que me parecen una pasada ( es curioso, cuando yo estudiaba el Z80 era una pasada jijijijiji). Para la corriente de descarga estoy viendo un sensor de corriente en serie, con capacidad hasta 180A, que creo que son mas que suficientes para nuestros helis. Concretamente este





Tampoco es precisamente barato, pero me parecec una solucion mas precisa y segura que una shunt.

Un saludo.

[Spare]

Yo empecé hace ya años con los pics, y he seguido con ellos. He tanteado los arduino pero hay algo en el entorno de programacion que no me hace ver las cosas claras (quizas por estar acostumbrado a lo otro), y no me han aportado nada que no tuviera (echo en falfa periféricos, como bus can). Pero en cualquier caso, traducir programas de un entorno a otro es, por lo general, sencillo. Los cortex.... quizas sea una buena oportunidad para conocerlos, nunca me limito a lo que tengo.
Para la temperatura de esc y baterias estaba usando un LM35, mas que nada porque tenía en casa), aunque tenía algun otro como reserva, el tmp36 entre ellos). Para el motor había pensado en el tmp006, similar al mlx pero en smd de 1,6x1,6mm. Necesita ceirtos calculos para optener la temperatura y ajustar la emisividad del objeto que se mide. Pero pensando un poco, los motores de los helis son outrunners, por lo que los bobinados por donde circula la corriente están bien anclados al soporte del motor (lo que atornillamos), por lo que midiendo la temperatura aquí creo que vamos servidos.

La calidad de la señal creo que va a ser mas complicado si no tenemos una salida específica. Por el SBUS sale una trama de datos con el estado de los servos, si se ha perdido algun paquete y poco mas. acabo de recibir un  R6303SB, pero aun no he podido hacer pruebas con el. Pongo dos enlaces para que veas como va:
http://mbed.org/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/
http://forum.arduino.cc/index.php/topic,99708.0.html

Voy a mirar el Cortes que mencionas.

Saludos