How to Launch a Rocket to Space: Inside BURPG Part 2

This week saw the beginning of the test campaign, as as anyone in aerospace (or engineering in general) knows, the first tests don't go as planned. Or at all. Like what happened this weekend. Due to a few issues, it was decided to postpone the test and recollect ourselves to make sure that it is done right the first time. Because we expect to hit growing pains early on, we build in a buffer weeks at the beginning. So the delay doesn't set us behind schedule overall. Click through the steps to see the progress that has been made, and check out some of the cool new things we built.

Our Rocket Mavericks campaign is still going on:

Like us on Facebook and follow us on Twitter for updates, photos, and videos

And our new website is coming along!

One of the issues that postponed the tests involved the Mk. IIb, which is our sub-scale test engine to test our thrust vectoring system. When the threaded rods that clamp the entire engine together were ordered, rods that were weaker than specified were accidentally chosen. They would have broken when the tank was at 900 PSI, which when we operate at 700 PSI and do tank tests at 800 PSI, the safety margin is unacceptably low. We might have gone through with a single cold flow test this weekend with the weak rods, which would have been safe, but the engine would not have been safe for a second test afterward. The cold flow test is just filling the engine with oxidizer, and venting it as if we were firing. The idea behind this is to test all the systems without the extra risk imposed by adding fire to the mix. It also puts the engine under much less mechanical strain.

We are ordering new rods, and will re-assmble the Mk. IIb with them. So the rods were really more of a minor hiccup than a detrimental issue. The rest of the Mk. IIb is going along as planned, including the design of the nozzles for normal burns and thrust vector tests, fuel grain casting, and modifications to the test stand used last year for the Mk. IV.

This week also saw the integration of the ground support board, Hyperion, with the custom ground control software. This went pretty well, and no issues were found that we couldn't figure out. The ground support computer, located at the test stand with Hyperion, is an Intel NUC; a pretty cool little device. The NUC runs the server software, serving as data storage and a communications point between Hyperion and the computer running the control GUI at the base camp.

However, the electronics were not free from their own set of issues that came up along the way. Hyperion is the only board undergoing heavy prototyping work, since it is the only one needed in the immediate future. One design error was found in the switching regulator, where an internal trace was creating a feedback loop, causing the output voltage to be about a half volt high, and be slightly input voltage dependent. This is being fixed by utilizing FCU, the old ground support board, for its switching regulator until a rev. B of Hyperion is designed.

Hyperion also suffered some (read: a lot) of damage while being worked on as part of the prototyping. A handling accident led to 12 volts being shorted to one channel on the MCU (which proceeded to stop functioning) and then a second accident with a multimeter led to 12 volts being shorted to everything else on the board that wasn't already broken ( -sigh- ). We plan for such eventualities, and have a second board and all the components required to build another one. These two accidents occurred at the last minute, and were not fixable in time to have the test this past weekend.

So the plan is this: assemble the extra Hyperion board, using the power regulator from FCU to replace the faulty one on Hyperion. This will get us through the start of the Mk. IIb testing. In the mean time, begin designing a rev. B of Hyperion to fix the power supply issue, and have it ready for the Mk. V testing. Do all the prototyping to Hyperion #2, so that when the rev. B board is built, we will just program and go. This will decrease the likelihood of breaking the board accidentally.

Going along with the Greek mythology theme for the electronics and software (Gaia is the GUI, Olympus is our on site server, Hyperion is ground control, Kronos is the flight computer, and Hermes is the engine controller) the rack case holding all the ground support electronics (Hyperion and the computer serving as Olympus) is called the G.O.D Box, for ground operation devices box. The box was assembled this past week, and came out pretty well. Many of the required cables were also made. This was the work I was in charge of.

The box has two removable side covers. One remains on and sealed during testing, and is used to access the electronics. The other serves to cover and protect the connector panel during transport. During use, the connector panel is exposed, so environment-proof connectors and switches were used. The panel is also sealed on all sides. The electronics require ventilation, so two computer fans were added, one blowing in and the other out, with filters installed.

The cabling is also intensive in design, as shielded cable was used for all data cables. There are over 30 cables leaving the G.O.D box when all hooked up, including servo control, raw data, and communication lines. This totals about 150 separate lines of data, power, and controls

Last year, the test stand used aluminum pipe as the frame, and it worked... but was a pain to set up and disassemble. Because of the size of this year's rocket, and the sheer number of tanks we need to bring with us, we decided to build ourselves a mobile test trailer. The rocket is suspended from a top plate, attached to an I-beam. The I-beam can be hydraulically raised and lowered, and locks in the vertical position. All the tanks are strapped in place. The test stand also interfaces with the existing concrete base at the test site, so the trailer does't take the full torque of the rocket firing.