10*N Rocket Launch Control System

Hi @lydara,

  Thanks for the update. I had been wondering about a mechanism to detect someone trying to override the safety key with a metal object, but my aim was to capture your present system intentions, so I just tried to find a circuit that fitted the evidence presented to me.

At the back of my mind, I have the impression the 'OEM' is aimed at one or two rockets, and this 'New' system' is simple and  appropriate for say 1-5 rockets, but expanding it to 20 or more is going to be increasingly difficult, due to both the number of wires, and that as the number of rockets increases, the length of at least some of the wires must increase as the corresponding number of people increase.

Also, I am thinking of the schematics and other comments you showed, including desire to have more than one set of equipment for other groups to use.

So my first question is 'Do you intend to develop a more sophisticated system?'

I don't know if I gave the wrong impression, but I think the underlying ideas of using microcontrollers (Arduinos or equivalent) and multiplexed controls are well worth pursuing to enable you to cope with 20 or more remote controls ... I didn't check the 'fine' details but I certainly felt they were heading in good direction. My concern was that whilst these complex circuits would enable the scouts to feel they were participating, they should not be part of the essential safety system. Hence the suggestion of separating the safety critical parts first, and then adding sophistication, whilst clearly maintaining the safety critical core.

I thought the essence of the safety critical core should be at least two 'essential switches' (where switch is any reasonable means of breaking the electrical circuit, could be a relay or a plug), in series, and that these two 'essential switches' should be controlled by different people. Thus, it should be impossible for a rocket to be ignited as a result of single equipment fault or a single 'Responsible for Safety' person making an error.

These two 'essential switches' should be 'simple' (i.e. not involving computer or other complex circuits) and operable during the entire firing sequence. This does not preclude other measures, such as a timing window control, or manual switches on the Pad box, but these measures should be additional and independent of the 'essential switches'.

-----------

Are your intending to develop the more sophisticated ideas you presented previously?

If you are, I have some ideas as to how this might proceed to reduce the number and complexity of long wiring snakes .. of course, you may well have thought of the same or better ideas.

I look forward to hearing more.

Best wishes,

Dave

@davee Indeed, the OEM controllers are as I like to call them, "a loose mess" designed for a single person to launch a single rocket.  That's good for "backyard" rocketeers' personal usage, but you see how it has problems scaling up/out.  Even for single rockets, just search the Internet and you will find _many_ people building their own launch controllers--to increase the safety distance from launch pads to personnel (often even going with poorly implemented wireless).

The proposed launch control system is designed from the start for the scale up/out case!  I started with simpler electronics for it, but then I too had so many wires to drag out from the launch pads to the RSO and to the LCOs.  So I introduced the Arduinos and the RS485/Modbus to reduce cabling between the launch pads and the RSO.  I really wanted to keep the LCO controls simple analog extensions from the RSO.  However then I was again, looking at so many wires--and a possibility of problems carrying the signals reliably from the farthest LCO to the RSO.  So I decided to embed not a full Arduino but a simpler register chip into the LCOPanels. 

Another good thing about consolidating the primary signalling into chips and fewer wires, there are now "extra" wires available between the boxes for added "analog" or "out-of-band" power & alerting!  This is what allows the RSOBox's Master Arm key to turn off the igniter power bus in the distant PadBoxes--the RSOBox itself is providing the power to the relay coil--with no "complicated" chips required.  Similarly there is a wire from box to box for powering an alert buzzer--indicating for all to hear any attempt to "pick" an LCO's safety key jack, or a welded relay that leaves power on igniter leads, or other serious faults!  This alert is a simple analog device, yet the "complicated" chips also listen in to this wire--allowing an auxiliary handling of the fault condition by the chips and program logic (such as locking out the offending channel or powering down completely).

There _are_ limits to any system.  For the proposed system, the overview drawing shows 20 rockets--but only 10 LCO stations.  As NAR Safety Code only allows 10 rockets to be launched simultaneously (we choose not to move the launch pads 600 feet away from these young Cub Scouts), we can only launch 10 at a time.  So while everyone will wire and mount their rockets all at once, the RSO will bring Scouts just ten-at-a-time to the LCO stations.  After the first ten launch, then they will swap places to allow the next ten Scouts to come to the LCO stations and launch.  Once everyone's rockets have flown and landed, then the RSO will let everyone onto the range field to find and retrieve all rockets at once.  This "bank" control idea is known and discussed by NAR officials for handling large group launches in manageable chunks.

Hi @lydara,

Thanks for the update of details.

I had a go at drawing some of the ideas I discussed previously .. I have used KiCad, but as will be obvious, it is only a rough 'back of the envelope' concept sketch to illustrate a few ideas. (Component values, etc. have not been properly selected.)

I am hoping the ideas are sufficiently close to where you would like to go .. and maybe already have.

I have aimed to show the whole system ... from battery (top left), to igniters (far right side), PAD box (top 1/3rd), RSO Box (Middle - near bottom), Launch Buttons/boxes (bottom), and (my addition) A_RSO Box (bottom left).

For 'Launch supervision/safety', I have assumed both an RSO who is charge of the RSO box, and an additional supervisory person 'Assistant RSO' who holds a small control box, A_RSO Box. The system ensures power can only be fed to the rocket igniters if both the RSO and the Assistant RSO are simultaneously operating the controls of their respective boxes.

The RSO and A_RSO boxes are both assumed to include a key/token switch/plug and 'dead-mans handle' type switch, in series. For drawing simplicity, the RSO Box and the A_RSO box on the drawing shows only a single switch each (labelled A_RSO_pwr and RSO_pwr), but each should be taken to represent the electrical equivalent of two plugs/switches in series.

Thus from a 'human' control perspective, two 'highly-responsible' persons (designated RSO and A_RSO) must simultaneously approve arming the launch buttons, and each must present their respective key/plug/token, and each must hold their respective 'dead-man's handle' in the 'arm' state. (I have included LEDs to indicate the respective function is receiving power, and a second LED to show that the 'Arm' state is being asserted.)

The aim of having the A_RSO and respective box, was to ensure two levels of isolation, before considering the Scouts' Launch controls. Thus, I suggest the the Launch controls can be made simpler, as they are no longer required for 'basic safety'. That is they could be a 'simple' button switch, possibly with a flip cover to give a more 'authentic' appearance. They would not need to have a removeable plug for safety. (Obviously, the last statements are only my 'humble opinion' and you may disagree.) 

------------------

The RSO Box has second switch labelled 'Timer_pwr'. This is intended to represent an automated timer, and possibly any other supplementary safety system, which must also approve arming of the launch system, simultaneously with the A_RSO and RSO manual controls. As this is a third 'approval', it should not be necessary for this system to meet a high integrity level, as the manual controls should already meet the safety requirements, and this function cannot override a 'disarm' from either A_RSO or RSO. Instead, it is principally a convenience addition.The timer implementation may use 'complex' components, such as a microcontroller.

--------------------

Discussion in this thread, combined with another thread, has stated that the maximum power demand for 10 rockets being fired simultaneously, would be 12V at 2A/rocket for say two seconds .. i.e. 12v at 20A for 2 seconds.

(Incidentally, you mentioned truck battery in another thread. The 'starting battery' for a small petrol car might be rated at 12V at 50Amp-hours, so could happily supply 20A for around 25 hours ... a couple of seconds will not be noticed! At a guess, it might weigh 50 pounds, which may be more of a factor. I don't know about motor bikes, but I would expect them to be smaller. The other annoyance is car lead-acid batteries are not keen on being unused .. so you may need to think about charging them through the winter ... or buying new ones more frequently ...!

May be better to look for much smaller versions of lead-acid with gel electolyte ... might need 2 x 6V, but they are fairly cheap and a more appropriate weight and size. I am assuming son et lumiere, etc. systems might provide their own power source.)

The 2 second time is too short to cause significant heating difficulties, but clearly voltage drop due to resistance of wires, contacts, etc should be minimised to ensure the system will reliably deliver 12V to the igniters. Hence, my sketch shows a scheme in which the igniter current flow passes from the PAD Box to the igniters, without passing through the cables to/from the RSO box. This is achieved  by means of relays K1, K2 and K3, whose states reflect the switch states A_RSO_pwr, RSO_pwr and Timer_pwr respectively.

Relays K1, K2 and K3 form a series power chain for the igniter power. Hence, should one of K1 or K2 fail in the 'closed' state, then the other will continue to provide the safety function. K3 for the timer is kept independent, so should it, or its control fail, the basic safety chain is unaffected.

In addition, a switch (possibly key activated) S2 on the Pad Box provides a simple means of ensuring the battery is disconnected. If this switch is keyed, it may be advisable to add an additional 'panic off' switch in series, so that anyone can perform an emergency disconnect. I would expect SW2 to be open at all times that there are people close to the rockets. However, the RSO can disconnect 99% of the PAD box from the battery, without leaving the comparative safety of the RSO Box area.

---------------------

This conceptual drawing shows 4 BANKs of igniters (BANK A, BANK B, BANK C and BANK D), with only 3 three igniters in each Bank. From previous discussions, it is assumed that each Bank would contain 10 rockets. Similarly, only 4 Launch Buttons are shown, but the 'real system' would expand to 10 Launch Buttons if there are 10 rockets per Bank,  the expansion being a 'Copy and Paste' operation. 

Similarly, if desired, more than 4 Banks could readily be incorporated.

----------------------

To ensure power is only sent the rockets in a single bank, for a single 'countdown', the relays K4, K5, K6 and K7 are directly selected by a rotary switch on the RSO Box panel, such that only one will be activated.

Not shown, but probably advisable, would to make each of these four relays 'double pole', where the second pole could be used as a monitor, in the event that one became 'stuck' in the activated state.

Although, the safety requirements only allow 10 rockets to be fired at one 'moment', if in spite of all the checks etc, one of these relays was closed at the wrong time, the 'worst result' would be firing of an extra bank at the same time. This should not cause any injuries, etc., and is very unlikely to occur.

----------------------

Thus reviewing so far, to connect a bank of igniters (say BANK A, and igniter IG_A1 in particular), to the +12V terminal of the battery, it is neccesay for Fuse F1 to be intact, and Switch SW2, Relays K1, K2, K3, K4 all to be closed.

However, to actually fire the rocket, in addition the above list, it is also neccesary to complete the circuit back to the 0V terminal of the battery. This can be achieved with an 'open-drain FET circuit' being driven appropriately when the Scout presses the corresponding Launch button. For drawing convenience this was shown as a 74AUC2G07, but in reality a higher current device capable of passing 2A with only a small voltage drop is required. I haven't done a proper search, but such devices, probably in a 'several per pack' should be available. (They are used in cars, etc. amongst other applications.)

----------------------

In recognition that you have already done a lot of research, and to simplify my diagram, I have shown the connectivity between the Launch buttons and the igniter drivers just discussed, as simple boxes labelled multiplexer and demultiplexer, with single lines for the connections. Obviously, that is hiding a lot of detail, but:

1. This side of the switching can be relatively low integrity, as the 'safety precautions' to ensure can only be ignited when everyone is at a sfe distance is built into RSO + A_RSO system.
2. This mux/demux scheme might only need 3/4 cores for each cable, including control power. This should reduce wiring problems and enable longer cables to ensure everyone is kept at a 'safe' distance when the rockets are being fired.
3. A further option, not shown, is the demultiplexer could be expanded to drive only the bank selected by the rotary switch. Then even if a relay in K4, K5, K6 or K7 got stuck, the extra rockets would not be ignited.
4. I have shown the Launch buttons as coming out on separate cables. Each cable might only need 2 cores. Alternately, you could consider building a simple mux/demux into each one and connecting them as a daisy chain. I am not sure that would be worthwhile, but it is a possibility to consider.

------------------

I hope that makes sense .. please query anything that doesn't .. and let me know if it is of interest or not.

If it is of interest, I should be able to look at the Mux/demux and so on a little more if it helps.

Best wishes and please let me know how you get on.

Dave