Hola Raúl,
A lo mejor no eras tú el que se ha explicado mal si no yo, que no lo entendí bien. De todas formas, me llamaba la atención ese protocolo de encendido del cohete. Como no se hablaba para nada de lecturas si no de un temporizador y unos leds pues me resultaba algo chocante. El proceso ideal sería tal y como te lo he descrito en mi anterior post:
1) Puesta en marcha del ordenador de abordo y comprobación de que todos los parámetros son correctos. Ajuste de algunos de ellos: presión barométrica, etc.... La cantidad y complejidad de datos que se pueden parametrizar depende de la carga útil ("Payload") a transportar. Cuanto más carga útil se pueda transportar en el cohete, mayores serán los circuitos que se puedan instalar y, por lo tanto, más datos se podrán obtener. La transmisión de datos entre el cohete y la consola puede ser mediante cable o WiFi o una combinación de ambos.
2) Secuencia de encendido del cohete. Primero, señal acústica avisando de la inminencia del encendido y un tiempo después el encendido del motor. Tiene que haber un mecanismo de autodestrucción en caso de salida de trayectoria o de riesgo para las personas. Esto ya os lo explicaré en otra ocasión.
En cuanto al sistema de paracaídas.¿Porqué dos paracaídas? ¿Se separa el cohete en piezas?. A pesar de esto te puedo decir que lo que se extrae es un paracaídas pequeño (lo llamamos "pilotillo") que, al desplegarse, extrae el paracaídas principal. Esto se hace así en todos los deportes con paracaídas: pilotillo y principal.
Y los ignitores "caseros" funcionan de maravilla. Me imagino que ya habreis hecho vuestros deberes y buscado por Internet. De todas forma, eh aquí un link http://shadow.yak.net/131
Un saludo

Hola:

Por lo que sé, parece ser que los ordenadores de a bordo de los cohetes no tienen ningún control sobre la ignición principal. Como mucho sobre siguientes etapas. De esta manera, el control es total y absoluto desde la cónsola de control en tierra.

Por otro lado, ahí va mi propuesta sobre un ordenador de a bordo. ARM7CortexM3, como el STM32 a 72MHz o el nuevo AT91SAM3 a 96MHz. Conector MiniUSB para descarga de datos y carga de la LiPol de alimentación. Un acelerómetro de tres ejes en un sólo integrado, a ser posible con salida analógica conectada directamente a los ADC's de 12 bits de los micros anteriormente comentados. Tres giróscopos analógicos de buena sensibilidad, igualmente conectados a dichos sensores. Una memoria SPI tipo MX25C4XXX de 1MByte o similar, y un módulo MRJ24F40 (o cómo se llame) de Microchip para comunicaciones a 2.4 GHz, que serviría a la vez de comunicaciones con tierra y como baliza localizadora. Conector de expansión para poder conectar otros periféricos como un GPS (mejor de los que tienen salida a 4Hz -Sirf III?- en lugar de la típica de 1Hz) y PWM, además de tres o cuatro entradas analógicas. Todo montado sobre una placa a cuatro capas, SMD, y en tiradas, pues seguramente a más de uno le interesaría para otras cosas tipo Mikrokopter. La cosa se podría quedar muy reducida de espacio y peso, con prestaciones más que memorables, potencia de cálculo a raudales, sobre todo con el AT91a 96MHz (los STM son a 72 creo), y muy atractivo como equipo al tener periféricos interesantes para muchas de las aplicaciones de robótica.

¿Que os parece?

El funcionamiento habitual consiste en ir midiendo a todo el rato la señal de los acelerómetros, filtrarla, y al detectar que ésta sube por encima de un nivel, empezar a descargar los datos a la memoria, pues sería el inicio del vuelo. Dado que se almacenarían bastantes muestras en RAM, permitiría tener los datos de los milisegundos anteriores al arranque, e ir integrando hasta el aterrizaje. Esto permitiría eyectar el parcaídas en el momento más interesante, bien en el apogeo, bien a determinada altura del suelo, para así evitar que el viento desplace mucho la carga de pago del punto de lanzamiento.

Con semejante potencia de cálculo, el lazo se podría cerrar cada milisegundo, y de esta manera hacer un control directo sobre las superfícies de control sin usar el clásico PWM de los servos, atacando directamente a los motores. Además, si todo se diseña correctamente, también se podría añadir control de ignición de más etapas, así como otro tipo de medidas y sistemas de control para motores híbridos o de propelente líquido (peróxido de hidroógeno con alcohol o sin plomo + catalizador).

Por mi parte ofrezco asesoramiento en el HW, además de algo de ayuda en la parte SW, pero no prometo nada debido a que tengo mucha faena pendiente con otro 'proyecto' más 'ilusionante' que tengo al caer, a medias con 'la parienta'.

Yo más que unas comunicaciones a 2.4GHz las pondría en la banda de 865MHz o 433MHz, ambas son bandas libres de comunicaciones y en ellas influye menos la humedad del ambiente que en la de 2.4GHz.

Incluso si queréis transmitir imágenes podríais usar la de 1.2GHz.

S2

Ranganok Schahzaman

¡Pero si con un móvil baratucho vale! Y sino mirad: http://space.1337arts.com/ " onclick="window.open(this.href);return false;

P.D. Es un poco en modo off-topic, pero también viene al caso :p

¡Pero si con un móvil baratucho vale! Y sino mirad: http://space.1337arts.com/ " onclick="window.open(this.href);return false;

P.D. Es un poco en modo off-topic, pero también viene al caso :p

Seguramente pero con un móvil estas poniendo peso que no vas a usar.

S2

Ranganok Schahzaman