NOTE: This blog is inactive. Visit the new official HAPP website at www.happresearch.com... Home-brewed spaceships! This blog chronicles development of a stabilized camera/video platform for photography at high altitudes over 30 kilometers / 100,000 ft. The platform will be lifted by a weather balloon and autonomously stabilized using a cold gas reaction control system (RCS).
Recently I set up a proper website for the HAPP project and I'm transitioning the blog over to the new host at Squarespace. Come check it out!
As a final sign-off from this location at Google's Blogger, I'd like to give a geographical breakdown of my readers here over the 22 months that this blog has existed (22 months to the day in fact!)
I've had a total of 66,587 visitors. As usual, most visitors are from the USA. The last time I posted stats we were at 35,000 visitors, and the #2 location was France. This time Canada steps up to join its North American neighbor. O Canada! The UK only lags by a rounding error.
I still have a few posts to write regarding the HAPP's systems and construction; for example, the sensor and camera suites, and the ground side of the satellite communication system. Nevertheless, I thought I'd catch you up on the first two test missions, HAPP-T1 and HAPP-T2.
Neither one involved free flight. In fact, HAPP-T1 never left the ground. Let's step through the purpose of each test and the results.
HAPP-T1 was a live test of satellite telemetry in the field. Basically, I sat the HAPP core sans aeroshell in a grassy snowy area with good sky exposure, and we verified (1) downlink of GPS positional data and spacecraft status, and (2) uplink of commands. James monitored the server-side action from mission control in Austin (sadly, not Houston) while I handled ground operations in Ann Arbor. The HAPP ran exclusively on internal power.
HAPP-T1 was a resounding success and produced data as shown in the image below. If you look closely at the numbers labeled "Payload" you can see the GPS coordinates being received by mission control. The red pin on the map is the location. The data payload from the satellite also contains various status codes and information such as vertical velocity and heading. We'll cover that in a future post.
Mission HAPP-T1: Success
So, onward to mission HAPP-T2. The goal of this mission was to shake down the balloon system and perform a tethered flight, thereby demonstrating all the functionality of a full mission while constraining the HAPP below a certain fixed altitude, in this case about 250 meters. Everything about this mission was live: Ground crew operations and staging, balloon inflation procedures, HAPP assembly and startup procedures, launch, ascent, communications, video, cutdown from the balloon, parachute deployment, and recovery.
This was my first time to inflate a large balloon, and fortunately I had an outstanding group of ground crew volunteers helping to wrangle the thing. Thanks guys!
I'll let the mission video speak for itself:
OK so what just happened?
Problem 1:
Well, obviously we didn't fly very high, and therefore we didn't get to test the Earth Landing System, a.k.a the parachutes. Everything worked great up through launch. The HAPP started to ascend, and then at an altitude of about 3 or 4 meters there was a gunshot sound - the cutdown pyros severed the connection between the balloon and the HAPP. The Flight Controller computer decided to abort the mission!
I had to get home and check the computer log to understand what happened. It turns out that the FC performed correctly. The software has a geofencing feature that terminates the mission if the HAPP drifts out of a pre-defined geographical zone. I forgot to check the software settings, and the latitude geofence was set to 42.398 degrees north, which is a bit north of Kalamazoo, Michigan - a value chosen earlier in development for no particular reason other than it looked a bit farther north than my home town of Ann Arbor. Who knew that our launch site for HAPP-T2 at a park near Ann Arbor was at 42.399 degrees north? As soon as the HAPP became airborne, the FC detected a geofence violation and aborted the flight.
This issue won't reoccur as I have now modified the FC sotfware to perform a geofence check during prelaunch procedures. If we're outside the geofence, the FC will go into an error mode and won't let us launch.
Although we were unable to witness the glory of the HAPP descending under its three huge parachutes à la Apollo, we were able to confirm almost everything else (Note: As an homage to NASA, the HAPP chutes utilize the Apollo red and white color scheme). In particular, the calculations were spot on for the amount of helium required to achieve the desired lift. The balloon harness and tether system also performed well.
One thing I could not confirm were flight dynamics. The mission software was configured to let the HAPP fall from 250 meters altitude for a few seconds before blowing the chutes. Inertial data from the HAPP's IMU could then be used after the flight to calculate acceleration, which in turn enables calculation of the aerodynamic drag coefficient or Cd. Knowing Cd, I can predict various things like the freefall speeds at different altitudes and anticipated shock forces when parachutes open. I had also hoped to confirm aerodynamic stability - see my old issues with the center of gravity. Those issues are solved on paper (well, in the CAD model at least) but I'd like to confirm with a physical test.
Problem 2:
When the FC aborted the mission, it also should have blown the parachutes. The chutes would not have done much good from an altitude of 3 meters - no time to inflate before ground impact - but they should have blown nonetheless.
It turns out that the FC did fire the parachute pyros. However, the steel ram pin that's supposed to puncture the liquid CO2 canister did not fully penetrate the canister. This is the first failure I have had of the ELS, including all of the early prototypes. This system has been highly reliable. I'm not sure what happened but I suspect I loaded the pyros with a short charge of black powder. I'll check carefully in the future. I'll also swap out the fire pin for a new one with a sharper tip. You can see the pin if you zoom in on the center of this photo; it's centered inside the steel spring.
Problem 2 is slightly concerning to me, but given the past reliability of the system, I'm not going to lose sleep over it. Not to mention, I calculate the terminal free fall velocity at low altitude without chutes to be around 40 kph / 25 mph, so the HAPP will likely survive a total chute failure. Heck, in HAPP-T2 the ground impact speed was around 28 kph, and there was almost no damage. By design, the HAPP is essentially a big, hollow, flying wing.
Overall, I judge HAPP-T2 to be an 80% success.
The Good News:
The HAPP structure performed in an exemplary manner during HAPP-T2 and the subsequent ground impact. My original design spec called for crash resistance from a free fall drop height of at least 1 meter onto a hard surface. In T2 the HAPP fell from 3-4 meters onto hard packed dirt. The aeroshell flexed as designed and did not suffer any damage. The internal structure and custom-molded crash pad also performed well with only slight damage to the structure in two locations.
Location 1 was the bottom of the structure where the tank deck is bonded to the central strut with specialty epoxy and small L-brackets, all made of carbon fiber (see my previous post for details about the construction). The epoxy bonds fractured before the carbon fiber components - as intended - and in this picture you can see my fingers in the resulting gap between the brackets and the now free-floating tank deck. A little fresh epoxy in the gap and the repair was complete.
Had the tank deck been fixed to the brackets with bolts, one of the carbon fiber components almost surely would have failed, and the repair would have been quite expensive, possibly requiring CNC machining of a new tank deck (see video of machining in previous post). Bonding was a good choice.
Damage location 1
Damage location 2 was the joint between one of the aerodynamic strakes and the ELS deck, as shown below. In the picture I've gone ahead and snapped the remaining good bond between the strake and central strut so I can chip away all the old epoxy and make clean new bonds.
Damage location 2
This repair was also pretty easy, but I had to break out my old assembly jigs to ensure the strake was aligned correctly when bonding. As described in a previous post, I 3D-printed various assembly jigs way back when I first built this version of the structure - glad I kept them around!
3D-printed jigs held in place with clamps;
very useful for alignment when bonding
carbon fiber pieces with epoxy
OK, this post was a bit lengthy, but hopefully you enjoyed the walk through missions HAPP-T1 and T2. I was hoping to avoid a T3 - see the previous post describing costs for the balloons and helium! - but I'm going to repeat the last mission. I simply don't want to release the HAPP for a full mission without validating the parachutes and flight dynamics.
Stay tuned - we're just waiting on a break from the crappy weather during a typical Michigan winter!
In the previous post I talked about balloon technology. Here I'll describe how we attach the HAPP to the balloon. To set the stage, recall that we are attaching a 10 kilogram / 22 pound load to a piece of thinly stretched latex rubber and we require it to survive turbulent winds and the like as it ascends to the target altitude of 30 kilometers / 100,000 feet.
My finished solution looks like this, with the balloon neck looped through a steel ring and clamped off with carbon fiber plates and steel screws:
Hang loose, dude
A quick search of other people's hobby balloon projects reveals the "standard" method of tying off using rubber bands and electrical tape. Follow the link and check out the pictures. This solution is not going to be capable of handling our loads; we need something more robust.
My idea was to use the steel ring in lieu of a loop of string formed from the tether itself. This prevents the abrasive Kevlar string from cutting through the latex. And to resist the pull-out force, I clamped the balloon neck back over onto itself using hand-cut carbon fiber (scraps from construction of the HAPP structure!) as pressure plates.
To enhance the grip of the plates onto the rubber while avoiding sharp, lacerating edges, I lightly scored the inner mating surfaces of the plates with a Dremel rotary tool. See frame (3) in the composite image below. After tightening the screws, this baby is going nowhere. I haven't actually done the test, but I'm pretty sure the rubber will shred before the steel ring slips out of this assembly.
Clockwise from top right:
(1) Balloon neck, (2) Neck being folded,
(3) Serrated inner surface of carbon fiber plate,
(4) Assembled harness with steel ring
One advantage of using the steel ring is that we can accommodate two different setups quite easily. The main setup is, of course, for flying the HAPP, with a single tether line attached to the craft. See the left frame below. You can also see a small generic fishing swivel I spliced in-line to decouple any rotations of the balloon and avoid transmitting them to the HAPP. No sense in making the stabilization jets work any harder than they need to - we do have a limited supply of gas! This swivel has a rating of 600 pounds which is almost 30X the static system weight, providing a comfortable safety factor even under extreme dynamic loading.
The alternative setup is for low-altitude test flights where the system remains tethered to the ground while still allowing the HAPP to hang freely below the balloon. See the right frame. In a tethered test we have three long lines running to tie-downs on the ground to prevent the balloon from moving around in any winds. See the video of the first test flight. I used three of these large kite reels to stow the ground lines.
In both cases we can use small screw-lock caribiners to connect to the steel ring for quick assembly / disassembly during testing. On flight day we can eliminate these carabiners and simply tie the single main tether directly to the steel ring for additional weight savings.
Left pane: Normal flight configuration
Right pane: With 3 ground tethers for test flights
What about all those knots tied in the kevlar lines? They're technically hitch knots. I like the Grapple Hitch for a variety of reasons, including its security under load or not, its adjustability, and the ease of untying.
Finally, let's look at the attachment to the HAPP itself. The main tether is fairly long at 5 meters. Why 5? I chose this length to achieve a nice slow natural oscillation of the HAPP. From the formula for a simple pendulum you can show that the period of back-and-forth swinging will be about 4.5 seconds (the reality is a bit more complex as this system is actually a compound pendulum - you can verify the details :-).
The thether is tied off to the machined aluminum tether ring on the HAPP. In-line with the tether are the doubly-redundant cutdown pyros. I also tied a small opaque cap to the tether. This cap is placed over a small photoresistor that's affixed to the HAPP. During normal flight the photoresistor does not sense any light and we can be sure the HAPP is still attached to the tether. When the pyros fire and the HAPP falls away, we will get a positive signal that separation is complete. More on this in a future post discussing the HAPP's sensor suite.
String A ties to the HAPP tether ring in the
right frame. Cap B goes over a photoresistor
which is not yet present at B in the right pane.
Blue cylinders are the cutdown pyros.
OK, that's it for the harness and tether. Thanks for hanging around!
The last few posts have covered electronics. In this post I'll go back to the mechanical side and describe exactly how we use a weather balloon to fly a 10 kilogram / 22 pound “spacecraft” off into the great blue yonder.
First let's discuss the balloon. Weather balloons are typically made from natural latex rubber. Literally, this is the material they extract from trees by pounding spigots into the trunks with hammers. While you might think there are suitable synthetic alternatives, the reality is that natural rubber has some unique performance properties, in particular its hyperelasticity - good for a stretchy balloon.
Balloons come in a variety of standard sizes which are categorized by the mass of rubber used to form the balloon, such as 100 grams, 600 grams, 1000 grams, and so on. Which size to use? The engineering trade-offs basically entail balancing four things: How high we want to go, how fast we want to ascend, ensuring the balloon eventually bursts from expansion in thin air, and the weight (and cost) of lifting a heavier balloon.
For the HAPP, we want to lift 10 kilograms to 30,000 meters / 100,000 feet, so we need 10 kilograms of lift, right? Nope. The balloon itself has mass, as does the bridle and tether connecting the HAPP to the balloon. Furthermore, we don't want to merely balance all the gross weight with lift; we need some net positive lift to ensure we ascend at a reasonable rate. Too fast and the balloon will generate turbulence behind it as it rams through the air, leading to a very bouncy flight - the opposite of what we're trying to achieve with a jet stabilized photography platform! Too slow and the HAPP will drift far downrange in the wind before it reaches the target altitude (and the onboard batteries may expire as well). Based on experience from other balloonists, it appears that the sweet spot is about 3 to 4 meters per second of vertical velocity.
Of course I verified the math by hand, but you can use a variety of online calculators to show that we need about 13,000 liters / 460 cubic feet of helium at standard temperature and pressure to provide the requisite lift. Using the 139 cubic foot aluminum pressure tanks that my local welding supply store uses for helium, this equates to about three and a half tanks. It also equates to a sphere of helium about 3 meters / 9 feet in diameter at STP, just like this:
1200 gram balloon inflated with about
13,000 liters / 460 cubic feet of helium
during the first HAPP test flight
A hint if you wish to try the calculations yourself: The ideal gas law and Archimedes' Principle are your friend, as is knowledge of the relative molecular weights of helium and air (mostly nitrogen). And don't forget about the coefficient of drag on the balloon. Bonus points if you show your work :-)
Three of the four 139 cubit foot tanks
provided by my local gas supplier, loaded
into my SUV so you can gauge the size.
Not tiny, but they're aluminum and light.
If we use a tiny balloon, say 200 grams, it will burst before it stretches to 3 meters in diameter as we inflate it on the ground. If we use any size other than the smallest balloons, say 600 grams, we can inject sufficient helium to achieve liftoff. However, there won't be much room left for the balloon to stretch as it expands in the thin air at high altitude. It will burst before reaching our target altitude.
So we should just use a ginormous balloon and be done with it, right? Nope again. An excessively large balloon may not burst before it stops rising, resulting in what is affectionately known as a floater. Floaters are bad because they can do things like circumnavigate the globe before the latex finally degrades in the ultraviolet rays of sunlight. Note that the HAPP guards against this possibility by using doubly redundant pyrotechnic devices to sever the balloon tether after time and / or distance limits have been exceeded. At that point the payload is gone and the balloon will resume ascending until it eventually bursts (and even if it didn't, the North Koreans would likely be less upset with a simple balloon floating overhead as opposed to a high-tech capsule laden with cameras and satellite communication devices!)
Fortunately, the largest balloon size easily available for general purpose, 3000 grams, appears to be about right. That's what we'll use for the main mission. They're also quite expensive, almost $400 apiece. Here are the two I've ordered:
Two 3000 gram latex weather balloons
from the good folks at Scientific Sales
To conserve funds, we'll use smaller ones such as this 1200 gram balloon for initial flight testing (still $115 each!).
While we're discussing money, I should also note that a 139 cubic foot cylinder of helium costs $144 to fill where I live, so four cylinders ring up at $576. That means a full mission flight will cost almost $1000 for the balloon and helium alone, with any test flights, hopefully only one or two, costing somewhat less. Crikey! Well, in for a penny, in for a pound I suppose...
OK, with the balloon selection and helium calculations out of the way, in the next post I'll talk about attaching the HAPP to the balloon.
And now to explain the Flight Controller (FC) computer, here’s
the first guest post on this blog featuring James, the mastermind behind the FC.
James is a friend from high school who now lives in Austin and has joined the
HAPP campaign during the past several months as we attempt to bring this
project to fruition. James is also a “real” software developer, not a pretender
like me, and not only has he expanded what I thought possible on this project, he’s
also accelerated the whole project significantly.
I'll let James take it from here!
==============================
In the last HAPP blog update, Chris provided details about
the Autopilot (AP). This post will provide some background on the Flight
Controller (FC), the companion computer onboard the craft.
Determining GPS coordinates, altitude, speed (horizontal and vertical), and heading
Transmit GPS data plus other flight data of interest to the ground via satellite
Receive ground commands, if needed, via satellite (normally the HAPP is autonomous)
Process all flight data and commands and decide what actions to take, such as firing pyros to cut the umbilical with the balloon or pyros to deploy the parachutes
Monitor the AP status and abort the mission if the AP stops responding normally (recall that the AP is listening similarly to the FC and can also terminate the mission independently if needed)
Electronics:
Like the AP, the FC is an Arduino Mega with two custom shields. There
were more than a few revisions prior to the delivery of final product for the
launch. My professional background resides entirely in the software realm. I’ve
writtenC-based firmware for embedded devices but I’ve never done much of the
electronics work myself. This project was a great bit of fun and provided me a
chance to stock up a full lab of gear (a desoldering gun is essential) and
components for future projects as well.
I began with the usual breadboard prototype, then moved it
to a more solid structure (protoboard) that required some light soldering. During
this breadboarding phase, I worked out the beginnings of the FC Arduino Sketch
that would serve as the scaffolding for the FC logic. I also mocked up a dummy
AP Sketch that did nothing but communicate on the I2C bus. You could type in state transitions manually
and see the status codes flow to the FC. Once satisfied that I understood how
each peripheral would work, I spent a considerable amount of time on electronics
revisions. Each involved multiple SKUs of the same component from manufacturers.
Some with built-in antenna, some without. Some with different form factors,
others with different voltage requirements. We finally settled on the smallest
available of each component that would suit our needs.
The first unit is still in use and is my go-to development
unit here in Austin. It features built-in antennae for GPS and satellite
communications and is very portable, which is good when you have to sit outdoors
to test satellite communication. The craft-ready revision has small coaxial connectors
(SMA) for external antennae. Those antennae sit on the upper ELS deck, which is exposed to the sky, thereby avoiding the Faraday cage effect caused by the carbon fiber shell of
the craft.
Unit #1 for development purposes.
Unit #2, which is on the HAPP, has a cleaner layout.
Unit #2 installed on the HAPP
as flight hardware
Autopilot (AP) on the left and
Flight Controller (FC) on the right,
as installed on the Electronics Deck
The electronics of the FC are much simpler when compared to
the AP. We have a single I2C device to
communicate with – the AP. We have two
serial devices (GPS, Satellite) and a single SPI device (microSD). The Arduino Mega is equipped with four serial
ports, three of which are available via the Arduino header pins where we have
access to the transmit (TX) and receive (RX) pins of each (the first serial
port is accessible through the onboard USB connector and is used to program the
Arduino and serves as a debug port).
Future electronics enhancements might include the addition of
another temperature sensor for redundancy (the AP has one) as well as a traditional
GSM cellular communication channel for more frequent and higher volumes of data
while the craft is at low altitude. This could aid in recovery efforts should
we lose satellite communication. Chris
added this commercial, off-the-shelf tracking device from SPOT as a backup in the meantime.
Software:
The FC sketch has an initialization phase where it confirms
that the peripherals are in working order. It opens two log files on the
microSD card, one for general log data and another for CSV-formatted GPS data
for later viewing in a tool of your choice.
Once setup succeeds and the FC reaches a state called PRELAUNCH_AWAIT_FCAP_HANDSHAKE,
we await communication with the AP before handing off flight control to the FC
logic.
The main microcontroller loop of the FC code services the GPS
peripheral. For simplicity, we chose to stick with a serial interface for our
chosen chip, the MAX-M8Q from u-blox. I found a high-altitude capable variant
mounted to a breakout board by Uputronics out of the UK. Note that most civilian receivers will cease functioning around 18,000 meters / 60,000 feet. To track the HAPP up to 30,000 meters / 100,000 feet, selection of the right GPS receiver is critical.
GPS chips are constantly
sending data to the communication bus. If you don’t devote time to servicing
that stream of data, you risk losing characters and your GPS location fixes are
in jeopardy. The cadence of the fix message is approximately one per second –
more than enough for our positioning needs as GPS data is not involved in any
kind of real-time steering of the craft. There is another class of GPS chips
that provides higher accuracy and higher fix frequency. Coupled with predictive
algorithms, that’s what your Tesla or military drones use for navigational
guidance.
While GPS fixes are being assembled, the FC sketch yields
time to a common worker function. It is
in that worker function where the FC does its work. That outline is:
Ask the AP for its state
Sync onboard clock with GPS satellite time
Log positional and operational data
Evaluate states for flight control logic (the secret sauce)
Repeat ...
Chris wrote logic that reacts to the navigational input from
the fix data. He reacts to flight data
related to positioning, velocity and heading. He can respond to questions like
Are we well outside of the bounds of the expected flight plan? Yes? ABORT! (There is a good story here from the first flight test. I’ll let Chris post about that later...)
Are we descending unexpectedly? Yes? ABORT!
Did we go supersonic on descent? Yes? Cool! Tell us about it.
Did we lose contact with the AP? Yes? ABORT!
More …
I should note here that the FC has multiple digital output
pins available via a header soldered to top Arduino shield. This is similar to an identical one on the
AP. The redundant pins allow either the
AP or the FC to issue critical abort control messages to the craft – fire the
pyros to cute down the balloon, release the chutes, etc.
Our satellite modem is able to send messages approximately
every 30 seconds. So, while we are
constantly collecting flight data, we can only send data to our application
server twice per minute. Once the FC logic detects that it is time to tell the
ground (that’s us!) about the craft’s current state, it assembles a formatted
payload and hands it off to the modem where some internal retry logic then
attempts to acquire a satellite signal and send the data. These messages are
called Mobile Originated messages (MO). It is also at this point where the
modem can tell the craft about any pending commands sent from the ground. These
are called mobile terminated (MT) messages. At present, we only issue a single
command which tells the craft to enter the EXECUTE_ABORT state immediately –
think BIG RED BUTTON. We did, however,
design it to be a general-purpose command control feature where we can set the
AP or the FC to any state desired.
While the satellite modem is attempting to communicate, it
hogs the microcontroller’s time awaiting a response. That is bad because we
need to service the incoming GPS data and we need to service our own
operational flight logic. To solve that, the library we use to talk to the
modem allows us to provide a callback function so that it can yield time back
to us. It is the same exact function that our GPS loop uses to process normal
flight data. So now we have two entry points
into that single function – our GPS working loop and the callback from the
satellite library. That can be bad. Such
code is said to be re-entrant since there are multiple processes or process
threads accessing the function at the same time. It doesn’t have to be bad, but
our satellite library allocates memory in such a way that we’d be clobbering
variables set by the other callers. To solve that, our sketch uses a semaphore
to gate access to the non-reentrant parts of the library.
During nominal operation, the FC will remain busy getting a
GPS fix, providing navigation data to the flight logic handler, logging data to
the microSD, sending data to ground control, and receiving messages from
ground. It does this in a tight, highly-optimized loop from mission start to
finish.
In an upcoming post, I will detail the software we call the
HAPP application server. We have servers
in the cloud (because of course) where we coordinate all of the messages and
present data logically (missions, messages, craft, etc.) for ground crew and observers. It has a web site as well as an API for use
by a dedicated mobile application currently in development by some amazing volunteers at Menlo Innovations in Ann Arbor, Michigan.
In my last post I described the overall electronics architecture. In this post I'll give some details about one of the two Arduino-based computers: The Autopilot Computer, a.k.a. the AP.
Autopilot Computer based on an Arduino Mega
with two custom-fabricated shields
To review from the last post, I'm using two computers primarily to achieve redundancy for certain safety-related functions, namely the abilities to cut down the HAPP from the balloon and to deploy the parachutes. A side benefit is that I can dedicate one of the computers to the time-sensitive task of stabilizing the HAPP with gas jets. That's the job of the AP computer.
In a future post I'll describe the full job of the Flight Controller (FC) computer. For now simply note that the AP & FC constantly talk back and forth, checking up on mutual status. If either computer fails to answer, the other assumes a problem and terminates the flight, bringing the HAPP down safely.
The full list of hardware integrated into the AP looks like this:
Inertial measurement unit or IMU. Detects linear accelerations and angular rates of rotation so the computer knows how the HAPP is oriented in space. Based on this information, the AP fires appropriate jets to stabilize the HAPP. I'm using a Bosch BNO055 running on the AP's I2C bus.
Altimeter / Barometer. This is a backup for the GPS embedded into the FC computer. This altimeter is not as accurate as GPS-derived altitude, but at least we'll have approximate data stored on the AP for post-flight analysis if anything goes wrong with the FC. I'm using an MPL3115A2 running on the AP's I2C bus.
Digital thermometer. A Maxim DS18B20. While not used for any decision-making logic on flight day, why not take the opportunity to grab some environmental data? This sensor runs on a "One Wire" bus.
Micro SD card reader/writer. An Adafruit breakout board for logging data that can be used for post-flight analysis. Runs on the SDI bus.
I2C hot-swappable buffer. An Analog Devices ADuM1250 running on the I2C bus. This little beauty is necessary for communicating with the FC. The two computers run off of separate power buses and do not share a common ground. In addition, the AP has several other devices on its I2C bus, and the FC would bring down the AP’s bus if it was wired in common and then lost power (try it if you don't believe me).
Audible buzzer. A bit old school, but pretty useful for confirming certain things when the HAPP is fully assembled and we can't see the AP. It's one I had laying around from the old beginner's kit for Arduino that I bought about 18 months ago at the outset of the HAPP project.
Bluetooth chipset. An Adafruit Bluefruit LE SPI Friend running on the SPI bus. Very useful for communicating with my iPhone during ground testing and pre-flight checks. I can send commands and receive data. Not useful once the HAPP is airborne and out of range!
General purpose Input/Outputs for various HAPP hardware: The 12 jet control valves, the manifold pressure transducer, 4 status indicator LEDs, and pyros for the balloon cutdown (see this) and parachute deployment (see this).
Adruino. The basis of the AP architecture. I'm using an Arduino Mega.
That's three I2C bus devices, two SPI bus devices, a One Wire bus device, 19 GPIO devices, and of course serial bus communications when the AP is plugged into my PC for programming. That Arduino is pretty busy!
I tied it all together with a collection of prototype shield boards, header pins, and connectors for some of the GPIOs.
Finally, to enable Bluetooth communications with my iPhone, I utilized once again the handy Arduino Manager from Fabrizio Boco. This little app makes it super easy to set up custom interface screens on a mobile device like this:
Yes, the "abort" button is locked out with
yellow hashes because I have fat fingers.
I'm not planning to publicly blog about the AP code development (can't give away all my beauty secrets :-) but I'm happy to answer questions via the comment section or by email. For now I'll simply refer you to some posts detailing development of the autopilot controls, located here and here. Those give an overview of the control strategy I've implemented on the AP computer.
Finally, I should note that as of a few months ago I'd never soldered a circuit board in my life. This project has given me an opportunity to gain yet another skill: Electronics prototyping. If an old mechanical engineer with large hands can learn to solder surface-mount components, then anyone can. Go grab some circuit components and have fun!
During the past few months I've been iterating furiously on designs for the electronics system. Undoubtedly this would have gone faster had I not been learning on the fly about prototyping for modern electronics. Until the past couple of months, I had never built up a circuit board or soldered surface mount components. Now I've got a dozen custom boards with different levels of quality and functionality sitting in a cardboard box (plus a few good ones installed on the HAPP!).
In this post I'll outline the HAPP's electrical system architecture. In later posts I'll fill in the details about some of the more interesting bits.
First is the design philosophy. The electronics system must fulfill the following requirements:
Autonomy. The HAPP must be able to conduct flight missions safely without any communication from mission control on the ground. This might entail aborting the mission if needed to ensure safety of the HAPP and of people and objects on the ground.
Redundancy. With regard to safety-critical systems, the HAPP should not have any single points of failure. These systems are (1) pyrotechnic cutdown from the balloon; (2) pyrotechnic deployment of parachutes; and (3) ability to dump any remaining pressurized gas for the jet stabilization system. In particular, the first item is required by FAA regulations as per e-CFR 14.2.101.35(a).
Telemetry. The system should provide mission control with real-time data about the HAPP's position and flight status. This is important for being able to locate and recover the HAPP after landing. It's also important for providing flight information to Air Traffic Control as per e-CFR 14.2.101.37 & .39.
Modularity. The system should be fairly easy to install and disassemble for testing and serviceability.
Let's check out the overall architecture and then walk through some of the pieces individually.
HAPP Electronics Schema
The schematic is divided into five light-colored areas that roughly correspond to independent power zones, each powered by its own LiPo batteries. This may seem overly complex, but it's largely driven by the requirement for redundancy. The worst case scenario is losing control of the HAPP before cutdown from the balloon and before deployment of the parachutes. This could happen if the computer dies due to the LiPo battery running down. To protect against this possibility, the HAPP uses two computers: the Autopilot (AP) and the Flight Controller (FC), each on their own 9 volt power supply.
Furthermore, the AP and FC are in communication via their I2C busses, a common way to share information between microcontrollers. The AP and FC constantly query each other and listen for a response. If one computer stops responding, the other triggers an abort, which consists of immediately firing the cutdown pyros, firing the parachute pyros, and opening the jet valves to dump any remaining high-pressure gas. This gives full redundancy for the computers and their power supplies. The AP and FC each have some distinct duties - the AP performs the jet stabilization, while the FC handles collection of GPS data and transmission to earth via satellite link - but either computer can execute an abort.
Additionally, the FC will trigger an abort if it detects any one of a variety of problems, such as drifting out of range, staying aloft longer than expected (possible if the balloon has a small leak - it won't rise to burst altitude), or receiving an abort command from mission control on the ground.
But what if the pyros fail? To safeguard against this, the HAPP has duplicate pyros for cutdown and chute deployment for a total of 4 pyrotechnic devices. In addition, each pyro is energized by two separate solid state relays or SSRs (I’m using MOSFETS; can't energize pyros directly from data pins on the computers because the pyro igniters draw high current when they fire). Finally, the SSRs are powered from a bus that is energized by the two LiPo batteries powering the computers; if either LiPo goes down, the bus will remain energized by the other. There is no single point of failure in this setup. Failure of the cutdown or chute systems would require losing two of something: Both power sources, or two MOSFETs, or two pyro igniters.
You can also see that the cameras are separated into two power zones. The first zone consists of three GoPro Hero Session 5 cameras in parallel on a 6 volt bus (given the length of wires between battery and cameras, the cameras are happier with a 6 volt regulator instead of the nominal 5V). The second zone contains only the Garmin VIRB 360 camera. While all the cameras could theoretically run off the same 5-6V power bus, splitting them into two zones gives some redundancy: Even if one zone dies, we should be able to record something from the remaining zone. It also allows me to position the batteries independently as ballast to balance the flight dynamics. Balance has been a big issue in the past; see this old post.
In all power zones, the nominal 11.1 volts from the 3S-LiPo packs are either stepped up or down to appropriate voltages (3S refers to the number of standard 3.7 volt cells wired in series; in our case 3x 3.7V = 11.1V. Click here for a LiPo primer.) Step down conversion is accomplished with UBECs, or "universal battery elimination circuits." These are common in the hobby world of radio controlled airplanes and are readily available. "Elimination" refers to the fact that we don't need a separate battery that outputs 5V or 9V or whatever we need for a specific electronic component; we can simply use the main LiPo and branch an appropriate UBEC off of the main line. Step-up conversion is accomplished with this adjustable DC-DC converter.
As for the LiPo batteries, they are sized to allow each power zone to run for 3 hours, considering the current draw of the attached devices. Simulations indicate that the mission flight will require about 2 hours up to apogee and about 13 minutes down to chute deployment altitude, with a few extra minutes to land by parachute. By the way, the flight path simulations look like this after you throw them into Google Earth. This is approximately the view we can expect on mission day - except in 360!
With the schematic described above, the electrical system satisfies the requirements of autonomy, redundancy, and telemetry, all in accordance with FAA regulations. I believe this system architecture exceeds most hobby balloon projects in its robustness and reliability.
As for my final requirement of modularity, I'll demonstrate it with some photos of the actual system in an upcoming post.
I haven't made much progress on the HAPP project during the last few weeks, and intentionally so: I decided to road trip from Michigan to Nashville and witness the total solar eclipse on August 21, 2017.
Although I wasn't able to get the HAPP in the air for the eclipse (how awesome would it have been to capture 360 video of an eclipse from high above the stratosphere!) I did manage to bring a telescope and my camera gear. The result is the following 4K time lapse video. It runs at 450X speed and compresses a 3-hour event into less than 30 seconds.
The road trip only took a few days but it took a couple of weeks to process the video. Due to thermals in the the hot summer air, the images jitter and pulsate from frame to frame. The effect was bad enough that I couldn't run automatic stabilization on the video in post processing. Instead I had the pleasure of aligning almost 800 frames of video by hand. Not for the faint of heart!
Even after hand-centering the frames, the picture still warps and magnifies unevenly. Interestingly, the image gets more stable leading up to and immediately following the totality phase. This is because the air became noticeably cooler and still as the light of the sun diminished.
Hope you enjoy the video.
Bonus:
Here are a couple of nice stills. In the second image you can see mountains on the rim of the moon behind the bright "Bailey's Beads" on the left hand side and also some solar flares peeking out on the right.
Previously I posted about the 360-degree camera I plan to use for mission flights. Back then I was using a Nikon KeyMission 360, which was state of the art in 2016. Unfortunately, I was never happy with the performance, and I've been searching for a better solution ever since.
I tried a constellation of six GoPro cameras, the footage from which I stitched into a 360 video in post-production using Autopano Video software. In theory this approach offers the best possible image quality. In practice it had a couple of fatal issues. First, as small as the GoPro HERO5 Session cameras are at 74 grams each, the six cameras together were too heavy, which means the HAPP would not attain its target altitude of greater than 30Km / 100K ft. Second, the HAPP structure has too much flexibility, and when I placed the cameras all around, they vibrated out of sync. This means I could not generate a clean stitch for the 360 video.
Enter the Garmin VIRB 360. This little monster is lighter and more capable than the KeyMission 360. As of July 2017, it's the most capable prosumer 360 camera vailable. Total weight of mount and camera (including the custom-machined aluminum portion shown below) went from 340 grams with the KeyMission to 208 grams with the VIRB. The VIRB shoots at 30 frames per second, not 24 fps, giving smoother video. Furthermore, the VIRB shoots in 5.7K resolution, not 4K, resulting in a superior image, especially after applying stabilization in post-production.
Here's a computer rendering I made after drawing the VIRB in my CAD software. All components must be modeled in CAD so I can use the model for accurate simulation of flight dynamics. This is much cheaper than crashing a few prototypes. While a simple block model would be sufficient for the dynamics, why stop there? Might as well make the rendering look sweet...
My VIRB 360 arrived yesterday, and what better way to celebrate than to strap it right onto the back of my DJI Mavic Pro drone (a.k.a. the HAPP chase plane) and send it up for a little test drive? Video is a little shaky as the drone is small and vibrates quite a bit. We'll get a smoother ride on the HAPP.
Check out the 360 video on YouTube and notice the heads-up display with live flight data. You might need to open the video link in YouTube for the 360 to render correctly (click here). Also be sure to select 4K video resolution at the bottom right of your YouTube player for the best experience. Enjoy!
Previously I posted the first two out of three videos showing how I manufacture large carbon fiber aeroshells. Here's the final video, which reveals the carbon fiber layup and vacuum infusion process. These videos run at 40X normal speed and show well over 100 hours of work in just a few minutes.
A few final comments on the aeroshells:
Most of the materials for the plug, mold, and part are from the terrific team at Fibreglast. Their service is fast, the quality of materials is high, and their selection is large, with almost every tool and material necessary for the entire production process.
The final layup I used for the composite material consists of "2.5" layers. The outer layer (A surface) is this patterned honeycomb fabric chosen for its awesome looks. The inner layer (B surface) is this standard 3K 2x2 twill weave. The "half layer" consists of a few strips of this 3K twill tape.
The resin is this special 2-part epoxy resin. I chose it due its viscosity and pot life (good for vacuum infusion), clear color (not the yellowish tint of many epoxies), and UV inhibition (the HAPP will get blasted by high-altitude sunlight).
I don't know if you think these videos make the process look easy or not. What they don't show are all the mistakes and do-overs I needed until I landed on the final process and material selection. I made several shells that were too heavy, too thin, or incompletely infused with resin. Carbon fiber material is not cheap, and these mistakes were costly in terms of money and time. Prior to the HAPP project I had zero experience working with carbon fiber so I had to take some lessons from the School of Hard Knocks.
Just keep in mind that I had to repeat what you see in the videos for the lower aeroshell as well!
OK, here are all three videos in order from last to first. Enjoy!
