Launch Controller Using Raspberry Pi?

Advertise with us
Shop deals on ebay
The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
John Kemker

John Kemker

Well-Known Member
TRF Supporter
Joined
Aug 25, 2019
Messages
6,150
Reaction score
4,338
Just received in the mail a 4 Relay Array Module. It has four 250V AC @ 10A/30V DC @ 10A relays controlled through optoisolators. I was thinking that using a Pi and some Python code, I could control 4 pads with 4 GPIO ports. Adding more modules means more pads. If I use a Pi-Zero/W, then the Pi could act as a web server and I could control it with a tablet at the launch control table. Of course, SSL and password protection would be used to keep someone from hijacking the launch controller, but a cable out to the launch pad wouldn't be necessary if the WiFi range on the Pi and the tablet is far enough for safe distance.

Any comments/ideas/suggestions/etc are welcome.

https://github.com/kemkerj3/PiLauncher
 
I think it’s a great application to get running. I had been playing with an ESP8266 WiFi module that has limited I/O, but enough to drive a similar 4-relay module. It was all controlled via a web page app on my iPad or phone.

I think your idea of using a Pi Zero W is a good idea as it has plenty of digital I/O and it also has Bluetooth, as well as the WiFi. The only issue that I have with the Pi boards is the lack of analog inputs if you wanted to implement simple continuity sensing as well, although you could do that with digital inputs, too.

It is secure using the WiFi, but might be limited in range. For low and mid power launching distances it would probably be fine, but for high power pad distances it might be unreliable, unless you were able to implement higher gain external antennas. However, with your background in amateur radio, that might be relatively easy.

Good luck with the development of this. I look forward to seeing a working system.
 
Last edited:
Remember, there needs to be a removable safety device (i.e. keyswitch) that disconnects power to the igniters, and that the action of the firing must be "momentary". I've had a number of people ask me if they could use the Eggtimer Quantum or WiFI Switch as a launch controller... my general answer is that it was not designed nor is intended for that use.
 
It could work. I have done a few projects. It will take a buddy board of some sort.
 
John Kemker said:
If I use a Pi-Zero/W, then the Pi could act as a web server and I could control it with a tablet at the launch control table. Of course, SSL and password protection would be used to keep someone from hijacking the launch controller, but a cable out to the launch pad wouldn't be necessary if the WiFi range on the Pi and the tablet is far enough for safe distance.

Any comments/ideas/suggestions/etc are welcome.

https://github.com/kemkerj3/PiLauncher
Click to expand...

Cool project John! I'm a big fan of the Pi's. FYI you don't require a Pi-Zero/W for wifi, the 3 and 4 models also have wifi chipsets.

I'll keep track of your github project.
 
Thanks, guys!

Chuck, you mentioned a buddy board. What sort of buddy board are you thinking?

Launch disconnect. That's going to be the big issue, right there. How to ensure that the relay module and RPi don't trigger a launch when not desired.

Momentary is easy. Set GPIO pin HIGH, sleep for 5 seconds (variable delay, selectable before launch), set GPIO pin LOW. Max delay 10 seconds? Can anyone think of a reason to hold the button down longer than 10?
 
John Kemker said:
Momentary is easy. Set GPIO pin HIGH, sleep for 5 seconds (variable delay, selectable before launch), set GPIO pin LOW. Max delay 10 seconds? Can anyone think of a reason to hold the button down longer than 10?
Click to expand...
The momentary requirement is on the button pushing side. As is the requirement for a removable safety interlock in series with that switch. But a timeout on the pad side is a very good idea since you might never receive the command to turn off.

As for timing, NFPA 1127 requires that the system (igniter, etc.) be designed to achieve lift-off within 3 seconds. A timeout greater than that would appear to be an admission that you don't intend to comply with that requirement.

At the very least you must include a pad side safe/arm switch that disconnects the output from the firing circuit. This protects the user from circuit faults and crazy LCOs. Or at least gives them a head start.

You will also want to examine that great big pile of software running on the RPi (any process that is running) because it is SOUP. (A NASA acronym I found recently for Software of Uncertain Pedigree.) What does it do? Can it fiddle with your GPIOs?
 
So, max delay between setting pin HIGH and pin returning to LOW should be 3 seconds. Pad side safe/arm is in the output of the battery. Right now, I have a SPST switch on one side of the battery. I can change that to a DPST keyswitch to cover both positive and negative rails out of the main battery.

I'll have to do some research on Raspbian and what I can do to reduce how much is running on the Pi. I should be able to turn off anything not required to run the web server and the Python app.
 
John Kemker said:
Pad side safe/arm is in the output of the battery. Right now, I have a SPST switch on one side of the battery. I can change that to a DPST keyswitch to cover both positive and negative rails out of the main battery.
Click to expand...

Use one DPDT per pad so that each user has control of their pad. Disconnects igniter from the firing circuit and presents it with a short.
 
UhClem said:
....<snipped for brevity>...As for timing, NFPA 1127 requires that the system (igniter, etc.) be designed to achieve lift-off within 3 seconds. A timeout greater than that would appear to be an admission that you don't intend to comply with that requirement.....<snipped for brevity>...
Click to expand...
This is the kind of loosely written rule or interpretation that is driving so many of us nuts. Does a 'design requirement for lift-off within 3 seconds' directly imply that a you can't push the button down longer for 3 seconds? Does a circuit, that is designed to fire the ignitor within 3 seconds, but stays energized for 5 seconds, willfully violate the 1127 rule? When the LCO holds the button down for longer than 3 seconds, is that then a violation of that rule? Who decides these things when the code is ambiguous?

At what point does reasonable interpretation cease to matter and only the letter of the code, interpreted as narrowly as possible, take over? I understand Dave's interpretation, it's the ambiguity of the code that is so irksome. The lack of a definition of the word 'inhibit' is obviously a good example.


Tony
 
Last edited:
UhClem said:
Use one DPDT per pad so that each user has control of their pad. Disconnects igniter from the firing circuit and presents it with a short.
Click to expand...
Okay. That sounds very doable, with an overall deactivation switch for the entire rack. That way, someone has to arm the entire pad and not just a single rocket in order to launch.

I say this, because I can see a situation where an individual pad is armed as the user leaves. An LCO looks out at the pad and doesn't see another user bending down connecting clips to their rocket. Theirs doesn't fire, but the one next to them does. With an overall rack keyswitch, that's less likely.
 
Some thoughts and/or suggestions:
1) Add another relay for arming. This is connected in series with the 4 firing relays. I know a rocketeer who knows the sound of a K motor coming to pressure from close up, because a relay on the controller got stuck (welded contacts). With a second relay, this is less likely.
2) Add a buzzer right at the output of the arming relay. If the relay is on, for whatever reason (regular operation, stuck relay or SW bug), the buzzer will warn anybody in the vicinity.
3) More of a personal preference: Make it easy to connect and disconnect the pad wires from the relay box. It is admittedly redundant to your DPDT switch, but the visual feedback of a disconnected wire is much more explicit, especially for other people who might not be familiar with your design.
4) Test the design for what happens during boot or brown out conditions. For example, what happens if the igniter on channel 1 requires too much current for the battery to deliver? This might cause the system to hang in a high current state, or, if it causes a reboot, another rocket might launch unexpectedly later.

Reinhard
 
Reinhard, thank you VERY much for your suggestions! Every single one of them is solid. The physical connection to the relay box makes tons of sense not just for safety reasons, but for portage/storage/maintenance reasons, also. Easily replaceable wires make so much more sense than permanent/semi-permanent wires. If a wire goes bad, spares can be kept handy.
 
Toggle switches on each line. Extra relays adds unreliability. Key switch on battery feed does the same thing with less chance of contact welding.

Reinhard, you're welcome to look at the schematic and branch the project, if you've got a better idea. We'll look at it and make a decision after comparing the two.
 
manixFan said:
This is the kind of loosely written rule or interpretation that is driving so many of us nuts. Does a 'design requirement for lift-off within 3 seconds' directly imply that a you can't push the button down longer for 3 seconds? Does a circuit, that is designed to fire the ignitor within 3 seconds, but stays energized for 5 seconds, willfully violate the 1127 rule? When the LCO holds the button down for longer than 3 seconds, is that then a violation of that rule? Who decides these things when the code is ambiguous?

At what point does reasonable interpretation cease to matter and only the letter of the code, interpreted as narrowly as possible, take over? I understand Dave's interpretation, it's the ambiguity of the code that is so irksome. The lack of a definition of the word 'inhibit' is obviously a good example.


Tony
Click to expand...

Please, feel free to login at NFPA and make suggestions to improve the wording. That’s how it improves. Also, anybody can ask for clarifications of the NFPA requirements. I don’t know exactly how that works; I presume NFPA staff refers questions to the technical committee which then is forced to consider how others might interpret the wording. Again, I think that’s a way to improve the requirements.

By the way, I contacted the person who changed the wording to inhibit and he said that (at least originally) it meant physically disconnected.
 
John Kemker said:
Just received in the mail a 4 Relay Array Module. It has four 250V AC @ 10A/30V DC @ 10A relays controlled through optoisolators. I was thinking that using a Pi and some Python code, I could control 4 pads with 4 GPIO ports. Adding more modules means more pads. If I use a Pi-Zero/W, then the Pi could act as a web server and I could control it with a tablet at the launch control table. Of course, SSL and password protection would be used to keep someone from hijacking the launch controller, but a cable out to the launch pad wouldn't be necessary if the WiFi range on the Pi and the tablet is far enough for safe distance.

Any comments/ideas/suggestions/etc are welcome.

https://github.com/kemkerj3/PiLauncher
Click to expand...

I wrote a python program in 2009 to control a launch system, it was written using 2.x ran on a PC and interface via a serial com port. The launch system (not the program) got kind of popular, and the project just stalled. It used dialog boxes and pull down menus in Python. I could donate it if you want.

DF
 
kc9qzf said:
I wrote a python program in 2009 to control a launch system, it was written using 2.x ran on a PC and interface via a serial com port. The launch system (not the program) got kind of popular, and the project just stalled. It used dialog boxes and pull down menus in Python. I could donate it if you want.

DF
Click to expand...
Daniel, thank you very much! Would you mind uploading it to the github repository?
 
Comments:

It wasn't at all clear which schematic capture program you are using. I took a chance and it turned out to be gschem so I could view them. But not everyone can so put it into a more portable format like pdf so the average person can see it.

The optically isolated inputs of that relay module are wasted here. And may still be a problem. I can't find a schematic but it seems likely that the RPiW must sink current from a LED and diode connected to Vcc. Which means that when the GPIO is high (3.3V) there is still voltage across the LED. Just not quite as much. With a 2S LiPo it is possible that the LED will still be on at reduced current. Open collector/drain outputs would be preferred. (Setting the GPIO to input doesn't count. There are diode equivalents to Vcc that should not be forward biased.)

Never ever connect USB and the 2S LiPo at the same time.

Rather than pull relay power (up to 450mA) through a trace/fuse of unknown size on the RPi PCB, tap off at the source. (Both Vcc and GND)

The voltage regulator on the RPiW is rated for up to 5.5V input which a 2S LiPo will violate.

The relays are likely a weak point and should be replaceable without too much effort. I like automotive relays and sockets.
 
John Kemker said:
Daniel, thank you very much! Would you mind uploading it to the github repository?
Click to expand...
Well... I am not so sure how I would go about uploading this to github, however I have attached the python code in a zip file attached to this response.
DF
 

Attachments

  • PC_Launcher.zip
    8.4 KB · Views: 16
Steve Shannon said:
By the way, I contacted the person who changed the wording to inhibit and he said that (at least originally) it meant physically disconnected.
Click to expand...
Precision of language is important when writing specifications. IMHO (I'm a professional space avionics designer), no one would ever assume that the word "inhibit" meant "physically disconnected." Was there a change from "physically disconnected" to "inhibit" in the NFPA, and if so, what was the purpose of the change?
 
Open source (GPL) Java code for the Altus Metrum TeleLaunch wireless launcher is on this page: https://altusmetrum.org/AltOS/ Look for the "source snapshot" links. The launcher functionality is integrated into the overall device code tree so you'll have to explore a bit. Their stuff is usually very solid. The hardware designs are also open source.
 
mikec said:
Was there a change from "physically disconnected" to "inhibit" in the NFPA, and if so, what was the purpose of the change?
Click to expand...
No. Prior to 2012 onboard systems weren't mentioned at all. See the 2012 Report on Proposals and Report on Comments.
 
UhClem said:
Comments:

It wasn't at all clear which schematic capture program you are using. I took a chance and it turned out to be gschem so I could view them. But not everyone can so put it into a more portable format like pdf so the average person can see it.

The optically isolated inputs of that relay module are wasted here. And may still be a problem. I can't find a schematic but it seems likely that the RPiW must sink current from a LED and diode connected to Vcc. Which means that when the GPIO is high (3.3V) there is still voltage across the LED. Just not quite as much. With a 2S LiPo it is possible that the LED will still be on at reduced current. Open collector/drain outputs would be preferred. (Setting the GPIO to input doesn't count. There are diode equivalents to Vcc that should not be forward biased.)

Never ever connect USB and the 2S LiPo at the same time.

Rather than pull relay power (up to 450mA) through a trace/fuse of unknown size on the RPi PCB, tap off at the source. (Both Vcc and GND)

The voltage regulator on the RPiW is rated for up to 5.5V input which a 2S LiPo will violate.

The relays are likely a weak point and should be replaceable without too much effort. I like automotive relays and sockets.
Click to expand...
Took a bit to digest everything here.

1) Why are optoisolators wasted? From what I've read and already am aware of, current surges back to the RPi from the relay energizing are what the optoisolators are for. Is this not a concern?
2) Don't know what LEDs you're talking about. There are four SMT LEDs on the relay board. I've not energized the board to tell what their purpose is.
3) Wasn't planning on using USB to power anything.
4) Providing Vcc and GND to the relay board through an external battery is still being considered. Need to figure out how to connect the external battery.
5) The board is inexpensive. Replacing the whole board is feasible instead of sockets, etc.
 
UhClem said:
The momentary requirement is on the button pushing side. As is the requirement for a removable safety interlock in series with that switch. But a timeout on the pad side is a very good idea since you might never receive the command to turn off.

As for timing, NFPA 1127 requires that the system (igniter, etc.) be designed to achieve lift-off within 3 seconds. A timeout greater than that would appear to be an admission that you don't intend to comply with that requirement.

At the very least you must include a pad side safe/arm switch that disconnects the output from the firing circuit. This protects the user from circuit faults and crazy LCOs. Or at least gives them a head start.

You will also want to examine that great big pile of software running on the RPi (any process that is running) because it is SOUP. (A NASA acronym I found recently for Software of Uncertain Pedigree.) What does it do? Can it fiddle with your GPIOs?
Click to expand...
I think the 3 second time is the time between pressing the ingition button and something happening. I have seen a lot of designs where the ignition button is pressed to start a "count-down". In this case something might come about between pressing the ignition and the action that might not be reversible. For most standard launchers, the ignition button pressing is immediate action and is active as long as the ignition button is being pressed. It clearly does NOT mean you can only press for up to 3 seconds, nor does it include the pressure-up of the motor after ignition is activated.
As far as relay or smart launchers go, the pad box (the server) should reset after a maximum of some time if communications is lost with the controller (the client).
 
kc9qzf said:
I think the 3 second time is the time between pressing the ingition button and something happening. I have seen a lot of designs where the ignition button is pressed to start a "count-down". In this case something might come about between pressing the ignition and the action that might not be reversible. For most standard launchers, the ignition button pressing is immediate action and is active as long as the ignition button is being pressed. It clearly does NOT mean you can only press for up to 3 seconds, nor does it include the pressure-up of the motor after ignition is activated.
As far as relay or smart launchers go, the pad box (the server) should reset after a maximum of some time if communications is lost with the controller (the client).
Click to expand...

The system must be designed and used such that the rocket lifts off within three seconds of the launch system actuation (pushing the button) and the launch switch must return to off when (meaning as soon as in my interpretation) it’s released. The point is that if something happens, like a launch pad tipping over, you want to let go of the push button and not have the sequence continue.
 
John Kemker said:
Took a bit to digest everything here.

1) Why are optoisolators wasted? From what I've read and already am aware of, current surges back to the RPi from the relay energizing are what the optoisolators are for. Is this not a concern?
2) Don't know what LEDs you're talking about. There are four SMT LEDs on the relay board. I've not energized the board to tell what their purpose is.
3) Wasn't planning on using USB to power anything.
4) Providing Vcc and GND to the relay board through an external battery is still being considered. Need to figure out how to connect the external battery.
5) The board is inexpensive. Replacing the whole board is feasible instead of sockets, etc.
Click to expand...
1) They aren't isolating anything since Vcc and ground are identical on both sides. It would work better if you drove the BJT coil driver directly. A diode across the relay coil solves all inductive kickback (V = L di/dt) problems and the board already has those to protect the BJTs. (I found a schematic that someone drew which may or may not match the board you have.)

2) All optoisolators are built around LEDs.
4) You do not need an extra battery for the relays, just take care in connecting them to the 5V power supply.
5) Replacing that board is more expensive than an automotive relay. ($2.55 each at All Electronics. Cheaper in quantity.)
 

Similar threads

curtisheisey
Yet another, another wireless launch controller ... this one with remote camera control
Replies
2
Views
532
curtisheisey
curtisheisey
COSTransplant
Free ESTES Electron Beam Launch Controllers -- New and Used -- Assortment
Replies
5
Views
691
PaddyDaddy
P
HyperSpeed
Building a Lap Timer using Garage Door Sensors
Replies
4
Views
567
tHoagland
T
Voyager1
Sold 8-Channel Wireless/Cabled Launch Control System (Re-listed)
Replies
0
Views
686
Voyager1
Voyager1
Voyager1
Sold 8-Channel Wireless/Cabled Launch Control System
Replies
5
Views
1K
Voyager1
Voyager1

Latest posts

Back
Top