FireHero: Raspberry Pi Controlled Pyrotechnics

To put on a live pyrotechnic show at a music festival, [Chris] built the FireHero 3. The result is remotely controlled flames shooting up to 100 feet in the air.

The system is controlled by a Raspberry Pi and an Arduino. A server runs on the Pi and allows a remote computer to control the system. The Pi sends commands over serial to the Arduino, which switches solid state relays that actuate the valves.

There’s also some built in safety features: the system won’t boot unless you have the right key and RFID tag, and there are pressure transducers and temperature sensors to ensure the system is operating safely. A CO2 actuated valve can quickly stop fuel flow in an emergency.

Vaporized propane creates the fireballs. The vapor is created by heating the supply tank in a hot water bath. An accumulation tank stores the vapor and custom built manifolds distribute it to the various flame cannons. At each cannon, a silicon nitride hot surface igniter (HSI) is used to ignite the flames once the valve is opened.

Very bad ass. One of the first posts here that has compelled me to leave a comment.

The response times of the effect are very impressive. Unfortunately, the build page is really light on how he’s processing the guitar’s input to determine which valves to fire. (Perhaps I just need to read his entire blog…)

The attention to detail and multilevel automated safety/shutdowns definitely demands some praise. Generally speaking, I don’t get to see many hobby/enthusiast builds that even come close to this level of planning/execution. His implementation is certainly much more suited to use in a public venue than a lot of other nifty (and what should be inherently safer) builds I’ve seen.

My only comment of note (suggestion, not a criticism) would be to include valves for each output on the manifolds as this would allow for quick reconfigurations. The current design demands plugs for any unused ports but with valves and leashed caps, with seals, changing the number of outputs would be far easier. Oh, and you wouldn’t need to depressurize the entire system just to add/remove one output. Obviously, this isn’t a flaw, just something that comes to mind when checking out this sweet build.

Maybe I’m a crank, but I wouldn’t run a safety-critical system on anything that wasn’t an RTOS, and the idea of having an arduino board floating around in there too gives me a little bit of the heebie-jeebies!

The Arduino is just a micro with a fancy boot loader. Enable the watchdog timer and use fail safe (normally closed) valves, etc and you’ll be fine. I’ve built out an engine break-in/test system with LabView and MSP430s. The key is to use interrupts to prioritize the safety control aspect over all else in the micro (and the rest of the apps, of course). Beyond this, he’s using regulators that should reduce the chance of a flame making its way into the main tanks (not 100% certain on this point) but I imagine one could find flashback arrestors specifically for propane… A Google search shows options for propane.

It wouldn’t be too hard to setup a master cutoff with an RC filter that uses pulses from the Arduino to keep a line high and keep a valve open. You could also make use of discreet logic to listen for a dead man switch and a heartbeat from the Pi…

As this is a system that is being interacted with and monitored, it’s not all that likely you’d see a catastrophic failure…

Just a quick point on the chance of flames flashing back into the tank…

There isn’t one. To burn, you need between 2-10% propane to air by volume. The tanks are filled with something in the range of 99.9% propane. I’d be comfortable standing next to it with a spark-plug set up inside. There’s no way for it to combust, and hence there’s no need for a flashback arrester.

Propane tank explosions do happen, but they are universally the result of a BLEVE, which happens when the tank gets too hot, too fast and the pressure release valve can’t keep up or the tank mechanically fails.

An RTOS won’t do you any more good than an Arduino if a cable comes disconnected or the power fails. Mechanical systems at the point of danger, designed to fail in a safe condition, will always beat remote electronic controls. He mentions using those in the description.

Personally, I wouldn’t trust a safety-critical system that *needs* an RTOS to be safe.

Well Put.
I agree completely this system works and his fail safes are mentioned and documented as well as the rest of the project is.
The main advantage of an RTOS is doing time critical scheduling and interrupts which as mentioned before the timing of the system and the response is impeccable.

.. to follow up on that, a safe system is one that drops into a safe condition the instant anything unexpected happens. The electrical control system’s job is to lift that system out of the ‘known to be safe’ condition and into a ‘not as safe, but not causing any trouble at the moment’ condition.

An RTOS might do a better job of keeping the system from dropping into safe mode unexpectedly, but the ‘safety’ part should always require layers of systems getting “it’s okay, keep going” signals before anything potentially unsafe can happen.

The control computer(s) talk to the Pi over regular Ethernet. The Pi runs a multithreaded server that sends commands to the Arduino at 1MHz serial.

The Arduino controls the solid state relays that drive the effects. A separate computer uses the Arduino’s Ethernet connection to get information about the actual state of the hardware within the system.

So what we’re looking at is separation of concerns between high-level “what effects do I want?” logic and low-level “how much current is running through relay N?” logic, with independent reporting at both levels.

As for why he used that particular design, I’d guess it’s easier to control the effects by spawning a new thread for each cue that comes in.. timing, sequencing, which ports need to open and at which levels, when they need to close, all that stuff. It’s an interactive system, so the effects aren’t just preprogrammed, and trying to handle multiple randomly-arriving requests in a single thread is a bear.

Moving the hardware-level control off to another system probably makes it easier to use things like hardware interrupts for things that would require the system to shut down. It may also be as simple as pin count.. the Mega has more I/O pins than a Pi.

im guessing that,
and maybe a memory leak somewhere in the system could affect values…
or some other weird bug, with this setup, one CPU is running the show
and the other is sending debug data BACK,
when convienent, through a seperate channel

the instant one glitches,
the script on the desktop would catch the data mismatch and
shut it down

Ok, so I read it again, and I can only assume it’s because the Arduino has analog-input capability. I still wonder if the Pi can be removed. There is a control PC in the mix too, so why not have that PC send commands to Arduino via Ethernet?

It used to be that projects on Hack a Day were not complete if they didn’t include an Arduino (no matter how simple). Are we entering a time when every project *must* have a Raspberry Pi? (Or a Raspberry Pi *and* an Arduino).