Helicopteros Radio Control - RC - Radiocontrol

Como me sobra algo de material de mi otro hobby, estoy planteandome construir un dispositivo que registre, analice y grabe las vibraciones del helicóptero durante el vuelo. Esta función ya la realizan algunoS dispositivos FBL como el vstabi, pero por desgracia no esta implementada en otros dispositivos de menor precio o más extendidos. Conocer las vibraciones existentes en el heli no es imprescindible, pero puede servir para mejorar el ajuste.
Para el diseño del dispositivo, parto de varias premisas, que necesariamente deben cumplirse para que valga la pena hacerlo.
1) precio.
El coste del dispositivo debe ser bajo. Alrededor de los 20-30€ máximo. Para qué queremos ensamblar un dispositivo de 90€? Para eso nos gastamos la pasta en un vstabi.....
2) construcción compacta, modular y de bajo peso. Emplear módulos preensamblados facilitara el montaje para aquellos que estén interesados en hacerlo y no estén muy duchos en la soldadura de componentes SMD o en el grabado de PCB's
3) consumo bajo. La alimentación debe ser compatible con los voltajes entregados por el bec, y el consumo del dispositivo debe ser despreciable.

Como captador, voy a emplear un acelerometro de 3 ejes, en principio usare un ADXL335 que tengo por casa y que es bastante económico para realizar las primeras pruebas, y asegurarme que esta dentro de rango. Los datos obtenidos tengo la intención de grabarlos en una microsd. Lo que aún no he decidido es si el procesado de los datos lo haré en el dispositivo o en un software a tal efecto para el pc. Sobre la marcha lo decidiré. En este momento ya estoy preparando el primer prototipo para ponerlo en un viejo 450 sport que tengo aparcado y hacer las primeras pruebas, y este finde ya querría estar haciendo las primeras capturas. Si a alguien le interesa el proyecto y quiere aportar alguna idea, estaré encantado de escucharle.

P.D hay que ver las cosas que se le ocurren a uno cuando hace mal tiempo.....

Interesante proyecto, aunque yo tengo el vstabi pero lo seguiré de cerca, suerte y saludos.

me uno al tema tambien, es interesante. aunque me imagino que va a ser dificil luego valorar los resultados para poder localizar de donde vienen las vibraciones
saludos

Interesante proyecto.
Me quedo a seguirlo.

Bien. Pues el primer prototipo ya es parcialmente funcional. El acelerometro genera un tren de datos analógico, entre los 0 y 3 voltios, proporcional a la aceleración provocada en cada eje. Los 0 g corresponden a 1,5 voltios aprox. De lo que he visto en el hilo del vstabi, las capturas del Analizador de espectro generan picos inferiores a 1 KHz. El datasheet del adxl335 establece que el dispositivo tiene ancho de banda de 1,6 khz para los ejes x e y, así pues el procedimiento consiste en capturar un tren de datos de duración limitada ( yo voy a capturar 10 seg de datos inicialmente, después lo modificare según la memoria RAM disponible) y a continuación mediante una transformada de Fourier pasarla al dominio de frecuencia. De esta forma veremos un pico de mayor amplitud en la frecuencia principal y picos de menor amplitud en las frecuencias secundarias.  Como no se sí voy a disponer de suficiente memoria en el controlador para esto, voy a reducirlo todo a la mínima expresión, mandaré los datos a través del puerto serie, para verlo en el ordenata y después reseteamos y reiniciamos ciclo. Estoy puliendo el tema para empezar primero con un solo canal y después veré si puedo implementar más.
El objetivo de este "brico" no es usarlo para un heli grande que tenemos montado full equip. Esto se orienta más a un 450 que tienes con un tarot zyx que se vuelve medio loco y no sabes ni por donde van los tiros.

Rociero, me comentas que tienes un vstabi. Puedes pasarme alguna captura del análisis de vibraciones.?
En cuanto al análisis de los resultados, las vibraciones originadas por los elementos móviles del helicóptero van a tener frecuencias proporcionales a sus velocidades de rotación. Así pues una vibración generada en el rotor de cola va a tener una frecuencia superior a una vibración generada en el rotor principal. Pongo un ejemplo para ilustrar el tema: el eje doblado de un rotor principal rodando a 2500 rpm genera una vibración senoidal o cuasi senoidal de 2500/60= 41 hz que estaría dentro del rango del ancho de banda del acelerometro. Un motor de 3900kv  rodando a 45000 rpm generara una señal de 45000/60=750 hz que en teoría estaría dentro del ancho de banda del acelerometro. Con la cola, coronas y similares podemos hacer un cálculo similar. Pero la gracia de esto sería disponer de potencia sufuciente para usar los tres canales simultáneos, para discriminar mediante el desfase de la vibración en cada plano. Otro ejemplo: si el eje de cola esta doblado o las palas de cola no están equilibradas, generarán una vibración que tendrá su máximo de amplitud en el plano vertical longitudinal, y mínima en el horizontal.

ahora no estoy en casa y no tengo ninguna, pero en el hilo del vstabi tienes unas cuantas de los compañeros, este enlace te da directo a una de ellas, saludos.
 
http://www.helicopterosrc.net/index.php?topic=7135.msg280961#msg280961 (http://www.helicopterosrc.net/index.php?topic=7135.msg280961#msg280961)

Yo no solo me centraría en los helis.
Para los multicópteros, en las que las vibraciones afectan directamente al vuelo pero sobre todo a la estabilización de los gimbal, haciendo que las grabaciónes tengan vibraciones y jello, lo veo extremadamente últi.
Análisis de vibraciones en los helis lo tienen vstabi y los SK720 de Skookum, pero en los multis creo que ninguna controladora tiene análisis de vibraciones.

Ok gracias.

Interesante proyecto, y coincido con HiNote, podría usarse también para los multi.
¿Finalmente te decides por almacenar en memoria interna o en sd? Lo primero puede limitar un poco el tiempo y frecuencias de análisis.
Sería interesante saber a qué velocidad se mueve el rotor (o motor), bien con un "sensor de reflexión" o un sensor hall.
¿Que micro tienes pensado usar?

Bueno, un helicóptero tiene un análisis relativamente sencillo, puesto que las principales fuentes de vibración son dos y están en planos perpendiculares. Pero un multirrotor tiene más fuentes de vibración. Si miramos desde el gimbal, tenemos tantos focos como rotores tengamos, y todas ellas situadas en el mismo plano, por lo que son indistinguibles, salvo que midamos cada rotor individual. A ello hay que añadir las vibraciones estructurales del propio gimbal y las aceleraciones generadas durante el desplazamiento. Y ese es un análisis complejo. Es más práctico ubicar un acelerometro en la base del propio gimbal y que interactue con su controladora para cancelar vibraciones parásitas, o usar una cámara con cancelación de vibraciones. De todas formas cuando disponga de una unidad plenamente operativa, puedo llevarla al campo de vuelo y ponerla en el multi de HiNote, y ver que capturamos. A partir de ahí intentamos evolucionar.
Con respecto a la memoria, mi intención es grabar los datos en una microSd. A lo que me refiero en mi anterior post es que puede que la RAM del controlador no me permita mantener la captura, calcular la trasformada y volcar en una Sd. Aún no he calculado el consumo de memoria. Si queremos mantener el precio bajó, no podemos irnos a cortex ni a nada que no puedas montar en casa. Un placa del tamaño de la que lleva el tarot zyx con un atmega 324p o un 328p con un zócalo para una microsd más los componentes SMD mínimos para que runee se puede grabar en Itead por cuatro perras, y los SMD soldarlos en casa, aunque soldar el acelerometro ya es harina de otro costal, y si no tienes estación de aire es más difícil; aunque también se puede pillar montado en una plaquita y te ahorras la faena. El montaje que estoy probando sale por unos 24 o 28 pavos. Una de las premisas del proyecto es que se pudiera hacer en casa y no fuera caro. De momento voy intentarlo con estos controladores y si veo que  me falta chicha pues buscare algo más gordo.
Respecto a la velocidad del rotor, ya se que velocidad tengo, puesto que en mi heli el motor va gobernado desde el variador, así que conozco las revoluciones. Pero si quisiera medirlas usaría un sensor de fase que es menos engorroso. De todas formas tampoco se le puede pedir más a este proyecto, como decía la idea es barato y casero. Si queremos más chicha hay que meter más pasta, y probablemente no sea casero,con lo que limitaríamos el acceso a aquellos que quisieran hacérselo. Mi idea es una vez este operativo liberar el esquema de montaje y el programa del controlador en este foro, para que aquel que este interesado pueda montarlo.   

Interesante proyecto tío, lo seguiré de cerca...

Yo soy del mundo PIC y desconozco un poco los atmega, peroun micro es un micro. Si tienes algo para hacer las primeras pruebas, seríagenial ver lo que sale y después ver qué habría que retocar.
Inicialmente creo que estaría bien usar todo el ancho de banda del adxl, lo queimplicaría leer a cerca de 5khz (Nyquist era demasiado optimista). Los PICsuelen tener referencias de tensión internas a 1.24, 2.048 y 4.096V, si losatmega también lo tienen se aprovecharía mejor el rango dinámico del adc siañadir nada externo.
No sé si merece la pena mantener dos (o tres si se adquiere el eje Z) bufferespara calcular las ffts y calcular (con cualquiera de los overlaps) si no se vaa realizar nada en tiempo real, solo monitorizar. Quizás sea mas sencillohacerlo a posteriori.
Respecto a la velocidad del rotor, la puedes llevar “gobernada”, pero si hacescambios de rpm, a la hora de analizar los datos, no tendrás una referencia de RPM-vibracionesa lo largo del tiempo. Un sensor de fase es precisamente eso, un sensor Hall.Yo uso un SR341RT en un proyecto, SOT23 y va genial. Si hubiera que fabricarPCBs, yo las encargo “fuera” y salen muy bien.<o:p></o:p>

Hola.  Mi intención es cambiar la tensión de referencia del ADC a 3 volt. como muy bien has indicado, puesto que si se dispone de la opción. El Atmel permite modificar la tensión de referencia entre 0 y pico hasta los 5 ( realmente hasta Vcc). En principio, la primera intención es monitorizar. El objetivo de usar los tres ejes es ubicar en el espacio el plano de la vibración mediante la superposición de los valores fft en los tres ejes. Aunque como decía antes el análisis de un heli es muy sencillo. La idea es intentar complicar las prestaciones conforme vayamos logrando objetivos. También pienso como tu que Nyqist es escaso (sólo hay que ver la escasa resolución de los cd's de audio actuales) pero hasta que no vea de que dispongo no me complicare mucho la vida y muestreare a 2F o 3F como mucho. Eso supone para los ejes x e y entre 3000 y 4500 Hz. El eje z tiene una resolución inferior.
En cuanto al sensor, en su día hice unas pruebas con sensores de Hall, de hecho tengo por casa cuatro o cinco con sus respectivos imanes. Pero poner un imán de neodimio en una corona ( por ejemplo ) que gira a 2000 o 3000 supone poner un segundo para equilibrar y ser preciso en el montaje para no generar más vibraciones ( ya lo he probado ) y tener que volver a hacer el trabajo cuando la petes en un aporrizaje. Cuando me refería a sensor de fase me refería a esto

(http://imageshack.us/a/img22/8554/atdf.jpg)

Este dispositivo se conecta en dos fases del motor, y aprovecha que dos de las fases están excitadas mientras la tercera se induce por los imanes del motor para generar una señal proporcional a la velocidad del motor. Estos dispositivos son los que usan los gobernors de los helis, y el sensor de hobbywing cuesta 4€ si no me equivoco. Es menos rollo de instalar.
Si no tengo que salir de viaje esta noche, voy a empezar a hacer ya pruebas. Para ello voy a emplear un generador de señal de frecuencia controlada. Capturare 10" de señal haré la FFT y a través del puerto serie veré los valores en el PC. Para hacer las mediciones en más de un eje simultáneamente, es posible que se tengan que almacenar en una memoria externa al micro, y realizar los cálculos a posteriori. De esta forma no sobrecargamos el buffer del micro. Pero como digo voy a ir por partes, explorando las posibilidades del micro antes de plantearme nuevas complicaciones. Voy despacio porque como ya he comentado en algún post, yo soy químico, y no me dedico profesionalmente a esto de la electrónica, y que estudie electrónica industrial hace un porrón de años, cuando el Z80 era lo último de último. ( ya soy mayorcito jijijijiji) 
En cuanto a grabar PCB's, aunque tengo una isoladora casera de UV hecha con leds y regulada en PWM con un micro, led a led, para grabar placas hasta  un tamaño de DIN A4, los últimos los he grabado en Itead studio, después de mandarles los gerbers generados desde eagle. Esta gente están en China, pero en dos semanas te ponen las placas en casa a un precio razonable. Y las últimas que me mandaron estaban cojonudas de calidad. El inconveniente es que tienes que grabar un mínimo de placas. Pero en el piso donde vivo no puedo hacer demasiadas guarrerias.... La MDR no me deja. Así que más práctico mandarlo hacer.
Si esta noche me pongo con las pruebas, subiré ya las primeras fotos y capturas de datos.
Un saludo.

Quiza te ayude el proyecto 3Digi, que es un vstabi DIY y tienes ejemplos de hw y sw. Todo en Deutsch, para darle mas emocion.

http://3digi.wikidot.com/ (http://3digi.wikidot.com/)

Lo que decias de ejemplos de lo que hace vstabi lo tienes en la guia

http://www.vstabi.info/en/node/385 (http://www.vstabi.info/en/node/385)

 Suerte!

Muchas gracias por el aporte. El proyecto 3digi es muy interesante. Usan un atmega 644p que es igual a los que yo me planteo pero con mas memoria y más RAM. También es un buen candidato.
Un saludo.

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.

(http://imageshack.us/a/img855/7205/o1jm.jpg)

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.


(http://imageshack.us/a/img571/1529/3sii.jpg)


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.

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

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 (http://www.helicopterosrc.net/richedit/smileys/YahooIM/9.gif)  ). 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.

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

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:

(http://imagizer.imageshack.us/v2/800x600q90/818/n8z9.jpg)

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.

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.
 

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!

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?.

(http://imagizer.imageshack.us/v2/320x240q90/c/585/s97c.jpg)




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

(http://imagizer.imageshack.us/v2/640x480q90/856/hccy.jpg)



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

Un saludo.

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://mbed.org/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/)
http://forum.arduino.cc/index.php/topic,99708.0.html (http://forum.arduino.cc/index.php/topic,99708.0.html)

Voy a mirar el Cortes que mencionas.

Saludos