PDA

View Full Version : question about a launcher


dovaka
07-23-2005, 10:14 AM
ive been toying around with the idea of using my laptop and some electronics that stay at the pad to make a launcher that could handle multiple rockets but could also go great distances from the pad if need be
but what i was wondering about is if this violates the safety code its one of those things that isnt really black and white to me

"Ignition System. I will launch my rockets with an electrical launch system and electrical motor igniters. My launch system will have a safety interlock in series with the launch switch, and will use a launch switch that returns to the "off" position when released. "

the system im designing has several safety features built into it and it returns to the off position once you stop pushing the launch key it even will shut it self down if it loses communication with the computer so i think its within the code but i figured i would ask some other people first

CPMcGraw
07-23-2005, 02:30 PM
ive been toying around with the idea of using my laptop and some electronics that stay at the pad to make a launcher...

...the system im designing has several safety features built into it and it returns to the off position once you stop pushing the launch key it even will shut it self down if it loses communication with the computer so i think its within the code but i figured i would ask some other people first

It can be done... Just ask the boys and girls at that large space camp in Florida called NASA...

Keep in mind... computers don't do things the way WE do things. If the computer gets hung doing something else, or if something else running doesn't behave corectly, that "ON" signal can still get sent, or not shut off, whether you press the button or release the button...

I'd stay away from Micro$oft Window$... Use either an embedded RTOS or a stripped down Linux, with only those packages you need actually running.

Test and retest thoroughly before comitting to an actual flight configuration. Know the quirks and bugs before you trust it for a (public) launch.

dovaka
07-27-2005, 12:52 AM
thanks for the input
to let you know my friend and i are working on this together its been months of talking about it and now were about ready to start a prototype were going to use a old laptop i have and this is all its going to be used for and it will also be running freebsd just because both of use like coding in linux better anyway and i dont have to deal with all of the junk of MS
and dont worry there will be alot of testing before it makes it out to the field but once its done ill post some pictures and probablly a schematic ill also most likly provide the software for free under the gpl

CPMcGraw
07-27-2005, 09:29 AM
... going to use a old laptop i have...this is all its going to be used for... it will also be running freebsd just because both of use like coding in linux better anyway and i dont have to deal with all of the junk of MS ...there will be alot of testing before it makes it out to the field...

Some suggestions...

Don't rely on a single-point signal (one signal line as the only trigger). Use a multiple-point triggering system, where you need three or more signals that have to arrive at the same time, or which remain active for a given period of time, or which provide a specific pattern of signal, before the ignition occurs. Each signal point needs to be under software control, and should be sent independently from each other (three or more software "threads" running, each sending the signal).

The idea is to make the final combined signal something that would not routinely occur, or even occur by accident. Even a brief glitch in the signal can cause an unexpected condition. Just look at the shuttle's first attempt two weeks ago. Bad signals in the tank wiring caused a no-go condition that was never fully traced out. At least that situation caused a scrub, and not an unplanned ignition.

I'd also suggest a balanced-pair of wires for each signal being sent, with the appropriate driver-receiver chip at the ends. If you use three or four signals, you might be able to use Cat-5E patch cables for the signals. Also, keep the ignition power (and the power wiring) separate and distant from the signal lines. Use plenty of power lock-out switches between the pad and the launch control location, with those "Remove Before Flight" flags in plain sight. Have your "pad crew" remove the pins according to a checklist starting at the pad and working back. The last flag-pin at the computer location completes the arming of the circuit, after the crew has cleared the pad area.

JRThro
07-27-2005, 05:28 PM
Some suggestions...

Don't rely on a single-point signal (one signal line as the only trigger). Use a multiple-point triggering system, where you need three or more signals that have to arrive at the same time, or which remain active for a given period of time, or which provide a specific pattern of signal, before the ignition occurs. Each signal point needs to be under software control, and should be sent independently from each other (three or more software "threads" running, each sending the signal).

The idea is to make the final combined signal something that would not routinely occur, or even occur by accident. Even a brief glitch in the signal can cause an unexpected condition. Just look at the shuttle's first attempt two weeks ago. Bad signals in the tank wiring caused a no-go condition that was never fully traced out. At least that situation caused a scrub, and not an unplanned ignition.


Or have the 3 signal lines act as inputs to 3 separate counters, and require 3 different specific numbers of pulses to be counted within 3 different specific time intervals in order to confirm that a 'launch' command was indeed given.

There are all sorts of ways to make sure that you really meant to launch.