(If you see an image in this post, click it. If you regret it I’ll refund you the price of admission.)

If you’ve been following along you’ll know that the goal of this project was to achieve a world first accomplishment of fully spherical panoramic imagery of a (small) section of our planet as seen from the stratosphere. In addition to imagery I also wanted to put together a video of the whole flight. The video didn’t quite happen as I hoped. Some of the obstacles were too large to overcome using the hardware that I sent up. I’ll hopefully cover those obstacles in this post.

Where to start?

The Beginning

Let’s cover the evolution of the project. The basics have already been covered and you can refresh yourself by reading them again.
Operation StratoSphere – Overview and History
Go ahead, I’ll wait.

Ok, let’s proceed. I started with just one camera and one homemade cube. With the goal being a fully spherical image I had to get creative to use one camera and treat it as if it were six. I made a frame with a guide for the box to go in, then took the whole silly unstable contraption out to the backyard. The guide was there to keep me from moving the cube too drastically from its starting point. I set it in picture every n seconds mode and let it run. After a few frames were captured I picked the cube up, rotated it so that the camera had coverage on another face, and put it back in the guide. Repeat for all six faces.

Some notes on the following links: They all utilize a panorama viewer I put together. I make no claims that it will work (except to say that it does for me). You click and drag to pan the image. On browsers that support it it will use WebGL for rendering, otherwise it will use canvas. Again, on browsers that support it it will allow you to press F to toggle in and out of fullscreen. If your browser doesn’t support this mode, press F11 (or your platform’s equivalent) to cause your browser to fill as much of the screen as possible. The experience is much better when it’s filling the screen.

That ended up giving the following result. It’s not stitched together well and it definitely isn’t pretty, but there are no holes in the image which means there is full (but not necessarily ideal) coverage. The project was feasible!

After that came a lot of research into balloons, stitching better, and building many many boxes to house the cameras. And of course, stitching more images.

Here we have me just holding the box up in the street and rotating it to point the camera in all six directions. Visible also is a little miscreant (my son) trying to chase me into the street.

This one was taken from my parents’ roof with a single camera at the end of a pool cleaning pole.

Through much cajoling, begging, and borrowing I was able to acquire a total of four cameras. I put them all in one of my boxes, grabbed my homemade test tripod, and went searching for a suitable spot to test from. With this example we have something a little different. First, here’s a static image like the previous links have been.

With this test, however, I wasn’t just goofing around and further proving to myself that yes, I can stitch images together! No, this time I was doing a full video test. Let’s see how that turned out, shall we? Please note, this link will not work in a web browser that can’t playback webm video. I have tested and verified that it works on the latest Firefox and Chrome browsers, but will fail in Internet Explorer.

Now we’re getting somewhere! That rather obvious black gap is the two missing cameras. Don’t worry, we’ll fill that in.

One issue that I haven’t addressed yet (really, I haven’t touched on any of them, yet) is that of rotation. As nice as it would be, that camera isn’t going to be stable. Let’s see how it feels when we just view an uncorrected rotating video. Also, all six cameras have been acquired for this test.

It kind of sucks to have to chase the view around, doesn’t it? And that’s just rotating around a nice axis. It’s even worse when it rotates around a non-vertical axis as you can’t pan to follow so easily.

The issues

So, I’ve already pointed out one issue. The camera rotation (for sake of conversation, I’m treating the whole cube as a single camera. It just makes explanations a bit less tedious), that is. If you were looking closely you may have seen another issue. Rotation is our first issue.

Exposure. In the last video it’s pretty obvious that there are some major quality issues going on. Go ahead an watch it again. This time I want you to not pan the view and just pay attention to just right of dead center. You’ll see that that area comes to a corner pointing down. (The cameras are at angles as I’m suspending the box by a corner.) As the camera rotates around that particular face (all faces, really. But we’re concentrating on one for the moment.) is looking at the sun, then as it continues around looking directly opposite the sun, then back around. As it does the camera software tries to adjust the exposure to keep the scene visible. This results in that face not matching the exposure values of its neighbors and during and just after it’s had the sun in view it’s left under exposed as it tried to accommodate the very bright sun. For this test I tried to correct it in post production but you can’t find detail that’s been lost.

Synchronization. Since we’re not dealing with a static scene (we have clouds moving, the balloon ascending/descending, camera rotation, etc) we have to to use images that were taken at the same moment in time and location in space if we want a good stitched result. This means we have to have some method of synchronizing our videos.

The solutions

Exposure. This is the easiest one to explain in that all I have to say is I can’t fix it. Not with the hardware I used. The firmware on the cameras used doesn’t provide a mean to fix the exposure value, so, for this iteration, it just has to be dealt with.

Synchronization. This one didn’t turn out to be too bad. Shortly before the balloon is launched I turn on all of the camera. They don’t all turn on and start recording at the same time, however. So I can’t just assume that 2 minutes into one puts the balloon at the same location as 2 minutes into another.

I tossed around various ideas to solve this problem. Initially I was thinking maybe enclose the payload in a box and flash a flash bulb in the box then synchronize the cameras based on the video. Or a blinking LED in front of each camera. These may have worked but were over-complicated. I wanted something fast or, preferably, something passive.

The way I synchronized early video attempts (such as for the basketball court video) was to bang a rock against a metal pole after the cameras have already started recording. Then, I would look at the audio stream for each camera and find where the sharp impact occurred and use that as the basis for a series of deltas between each video and one common. This worked but wasn’t very accurate. Also, what if I forget to have a sharp impact noise when launching? Further, when a camera hits 4 gigabytes in the video it’s recording it stops recording to that file and starts a new file. In practice this doesn’t transition losslessly and, therefore, I can’t use the sharp impact from the first 45 minutes to help synchronize the second or third 45 minutes of the flight.

What I ended up going with for the footage you haven’t seen yet (muhaha) is to use a tool called Audacity. Audacity is free, open source, cross-platform software for recording and editing sounds.

Here’s the basic process:
Step 1. Dump the audio from the individual videos.

ffmpeg -i input.mp4 output.wav

Step 2. Load the resulting wave files into Audacity.

Step 3. Split that stereo track and drop one channel. For what we’re going to do it’s just taking up space.

Step 4. Find a common pattern.

Step 5. Choose one waveform to align to. I use the one that has my chosen feature closest to the start as it makes all the deltas go in just one direction. You can choose whichever you want.
Step 6. Use the time shift tool and the zoom tool to align the wave forms for all of the other channels with the chosen one.

Step 7. Save the Audacity project and open it with a text editor. It’s a simple XML format. What we’re looking for is the offset attribute on the wavetrack tag. Record this value for each channel.

Now you have a list of offsets that you can use to translate one moment in time on one video to the same moment in all other videos. In the following image you can see how I’m using my offsets to take the time of 609 seconds in video 4 and find where that same time is in the others.

At this point it’s a matter of feeding into ffmpeg to extract a frame (for a static image) or several frames (for a video).

Run those six commands and you’ll have six images from the same point in time and space ready to start stitching.

Rotation. This one is a bit tricky and I tried coming up with some super techy solutions to solve it. I wrote a rudimentary computer vision application that would try to extract the rotation data from a video. The intent was to maybe play it back in reverse on the controls of the viewer to try to counteract the rotation. In practice it didn’t work so well. It wasn’t extremely accurate and it suffered from a lot of drift. It also wasn’t very smooth. The smoothness was mainly my fault. I wasn’t interpolating between counteractions. If anyone is interested in seeing the viewer with counteraction shoot me a message and I’ll see if I still have it.

Nonetheless, the work did occur and I do have something to show for it. Here’s a video with a line being drawn indicating the software’s guess of the direction and exaggerated magnitude of the rotation.

Direct YouTube link in case the embed doesn’t work

In order to fully explain how I finally managed to remove the effects of rotation we must first dive into the stitching process.

Stitching

At this point we’ve got enough data that we can dump frames. Let’s just concentrate on one frame for the time being. (One frame from each of the six cameras, that is.)

They look like this (Image link is to a gallery):

We need to get those images stitched into one larger image. To do so, we’ll use a tool called Hugin and several tools from the Hugin installation to help automate parts of it. Hugin is an open source utility that makes use of several panorama creation tools.

When the images are loaded into Hugin it will ask for some information about the lenses used. These cameras use a full frame fisheye lens with a hfov of 170 degrees. 170 degrees horizontally only gives us about 127.5 degrees vertically, which isn’t a whole lot of overlap. To try to maximize overlap I rotated each camera 90 degrees off from its neighbor in the payload box. The more overlap the better as fisheye lenses (especially cheap ones) tend to lose a lot due to blurring and chromatic aberration at the edges.

Next we need to find common points among images that overlap. Attempting to do so with the automatic control point finder tends to not have very good results. With my data set it usually doesn’t find any control points. (Hugin devs out there, does the control point finder remap to remove distortion before attempting to find control points if it knows the fov and lens types? If not, I think it might be useful, even if it is mostly naive.)

Here’s a screenshot of manual control point placement across two images.

This process contains a biiiiit of tedium.

Once we have all of the images (or as many as we can get) connect with control points we can ask the program to optimize some parameters. We have a spherical image when all images are accounted for. Hugin’s tools will look at how the control points are related to each other and try to find a transformation that fits them to a surface in which they all make sense. It will return a deviation value that we can use to determine how well it did at aligning our images. There’s a lot to this process and I won’t get into it all. It involves placing control points, fine tuning control points, optimizing the image, looking for major stitch issues, checking control point distances, removing bad control points, optimizing some more. Rinse and repeat until it starts to come out good. As I hinted at with the overlap stuff above, we’re not dealing with the most optimal of source data here.

There are some other factors that come into play with panorama stitching. You want to avoid placing control points on objects that move between images taken. Typical panoramas are done with one camera being rotated after each photo is taken. Objects that move between photos taken that have control points on them will severely hinder the stitching process.

You also want to avoid placing control points on objects at largely different distances from the lens. Don’t mix control points between objects a couple feet away and a hundred feet away as the optimizer won’t be able to make them fit to one transform. I’m able to mostly ignore this issue at very high altitudes as everything is so far away that the difference between the closer and the further objects is so slight that it doesn’t do much to negatively impact the optimization. Of course, that means I don’t allow any control points to be placed on anything attached to the camera payload, including the parachute and the balloon.

In order to place control points you have to have common features. That’s why you need the overlap between images. The more overlap the better the result. In the sample images above we have one image, the fourth, that isn’t able to be connected to any of the others. And it’s not because there’s no overlap. There are three issues with the fourth image that presents us from finding control points in it.

First, it’s just starting to rotate from the black of space into looking at a bit of the ground. That means it was brightening the image to compensate for the lack of anything to look at and it’s over exposed the ground. The detail has been lost due to this.

Second, it’s looking mostly at black space and the balloon. Since we can’t place control points on the balloon and there are no features in the black space to find commonality with in other images we can’t actually place any control points.

Third, it’s the sun coming in at a very shallow angle causing it have some really bad lens flare and highlighting imperfections in and dirt on the lens. If there was anything to look at past the lens flare it would be masked rather badly by the glare.

So, all that together means we can’t use this image for this panorama. After creating the panorama we have the following image to look at (I cheated a bit for this one and tried to correct the over exposure in the fifth image and I also manually leveled the horizon):

How can we fix that hole? Well, we’ve already established that the cameras are rotating. At this altitude another few seconds won’t make much difference in how the scene looks below, so what we can do is wait a few ticks for the cameras that didn’t have good imagery to come to an angle that allows them to see something that we can stitch from. Namely, the ground. Then what we can do is merge the two Hugin project files and have good controls points all around for this altitude and probably a good range of the high altitude imagery.

I did just that. Several times, actually. I was trying to get the best control point data that I could as, as you’ll recall, the goal of this project isn’t just static imagery. Without further ado, I give you the best single frame I was able to create from an altitude of 96 thousand feet. Definitely click this one.

Rotation Removal

By this point we know how to create panoramic images, we even have a control point and optimization parameters template. Next involves hundreds of hours of creating hundreds of frames of stitched images. One pano frame comes from six camera images. After hundreds of gigabytes and hundreds of CPU hours I finally have 4437 frames stitched from 26,622 source images. Finally, we can make a video. But, there’s still one major problem. That’s right, the rotation.

Here’s what that video looks like:

Direct YouTube link in case the embed doesn’t work

For an idea of how poorly behaved that is in the panorama viewer, see the following link:

So, we still have to correct it. Remember before I said I manually straightened the horizon for the static shots? Well, I can’t exactly do that for all 4437 images. Rather, I guess I could but I certainly don’t want to. Not only would I have to straighten each one to the best of my ability but I’d have to make sure it’s pointed in the right direction so as to be made into a video properly without the center point jumping all over. What to do?

Well, included in the Hugin panorama tools is a program called cpfind. This program didn’t work very well when we asked it to find control points between the six images of one frame. But what if you compared two sequential stitched images? I bet we’d get a lot better results as they’re mostly the same image. Let’s try.

First, we create and save a Hugin project, cpfind-test.pto, containing two sequential stitched images.

Then we run cpfind against it with the

--linearmatch

parameter, which tells it to do linear image matching. That is, only match each image in the project against its immediate successor.

Let’s open the resulting project in Hugin and look at the control points.

Okay, that looks pretty good. It did find some points on the balloon itself, and on the lens and dust flares, but that’s okay. For this round we don’t care. We just want a good representation of what it would take to align one image to another. Since they’re so close together in time (and space!), about 33 milliseconds apart, we should be able to align them so that they’re almost identical.

We run another optimize pass, this time using position, incremental from anchor as what to optimize. When we look in the GL viewer and toggle back and forth between the two images we see that they have, in fact, been lined up quite nicely. This would be difficult to show in screenshots, so you’ll have to trust me. Also, we could get them to line up a bit better if we fine-tune all control points through the menu, but that’s not super important for this step.

Now that we have a good idea of how the images are related to each other, we can manually correct the horizon and it will cascade to the rest of the images. (In this case, to the second and only other image)

All that’s left is to have it save out the remapped images and we’ll have two images that are mostly pointing in the same direction and with a mostly straight horizon. Now all that’s left is to create a Hugin project file containing all of the images we want to make a video from and do the same process. It’s best to do as much of this outside of Hugin as you can as it starts to get real slow when dealing with hundreds/thousands of images.

Do note that this won’t fully remove our wavy horizon issue as all it really is is a form of dead reckoning. That is, the position of any one image is only guessed at by using the known position of the previous image. Which itself was guessed at. The errors accumulate the further down the guessing chain you go. But, for my data set, it was enough to get me close enough to run the next step. Before we go there, though, here’s an example of what the output looks at at this stage.

Okay, so we still have a bit of a wavy horizon. But, not to worry, we can do something I thought was a bit clever. Let’s take all of the new images we created, that mostly corrected images, and put them in a new Hugin project. Then, let’s run cpfind against them, again asking to only compare one image to the next, not to all. Now, we can’t just leave it at that as it’s still finding control points on the lens flare and on the balloon. These control points will mess with the alignment in a major way and prevent us from ever getting a clean horizon.

So, let’s write some Python. You Python writers out there, please forgive me. This is probably my second Python script ever and I’m sure I did everything wrong. At least it works.
cleancp.py

What this script does is look at the control points defined in a Hugin project file and remove every control point that exists in the upper half of the image. With a little bit of thought the reason should be clear. Just in case, I’ll explain. We are up so high that there is nothing above us but the balloon and the sun. All of the interesting (read, control point material) stuff is below us. We aren’t up so high that the horizon is too far off from the center of the image. So, if we were to remove all found control points above the middle line we should be left with control points on valid, and more importantly, stationary, imagery. Another quick pass (overnight) of the optimizer against the full data set and we have a project file that we can go in and manually line up the horizon on. This will cascade down the chain and every image should come out nicely straightened.

My first test resulted in a file I called ‘sexyhorizon’ because it worked so well. Here it is:

I have one last stitched video to show before I jump into some miscellaneous stuff. This is a video of the apex of the flight. Taken at 96,382.88 feet this video shows the balloon reach its largest diameter, than burst. The first link is in realtime, the second is at half realtime.

Miscellaneous

It’s been a long road. This project has been two years in the making. It has involved thousands of dollars, hundreds of hours spent learning (stitching, python, electronics design, embedded programming, social interacting, ffmpeg incantations), amateur radio exam cramming, bleeding, social interacting, and many other things. I definitely stepped out of my comfort zone and tried new things and learned a ton.

I’m about 99% satisfied with the results and have a ton more footage that I can process if I find the desire.

Some more goodies below. First, the balloon at about 1.4 miles above the ground, or 7.5k feet.

Next, about 2k feet lower, at 1 mile up.

Then, about 12 seconds before impact with the ground, at about 300 feet.

Okay, another video. This one is all six cameras as they saw the end of the descent and subsequent impact with the ground. (If you watch the bottom middle camera when it comes to a rest on the ground you can see how it adjusts the exposure to bring out the detail in the dark scene.)

Direct YouTube link in case the embed doesn’t work

And, lastly, here’s a video showing the balloon burst as seen by all three upward facing cameras.

Direct YouTube link in case the embed doesn’t work

Acknowledgements

This project was mostly me, but there are some people I do want to thank publicly.

My wife, Jennifer, and my son, Perrin. My time is your time, now. (Until the next project comes along!)
My brother, Jordan. Thanks for your early payload brainstorming, and your REI yardsale voodoo that acquired two of the cameras. Also, thanks for retrieving the first balloon from that tree.
John, a longtime friend. Thank you for helping this project reach its goal. Without your help this project might have not been finished anytime near when it was.
Team Prometheus’ Monroe and Stewart. Thanks for your assistance with the last two launches, and for supplying the hydrogen.
Steve, Ben, Ryan. Thanks for helping out.
To everyone else involved, thanks.

We spent the night before the launch making sure everything was ready. As stated above, we labeled each camera. Each memory card was also labeled to correspond to the camera it went in. The cards were all formatted and the cameras were all setup to start recording video when they turned on. Batteries were charged and payload layout was finalized.

Then, bed.

We woke up and gathered the supplies and hit the road for Burnet TX. We were to meet Monroe and Stewart from Team Prometheus in Burnet for the launch. About halfway there it occurred to me to ask if anyone had grabbed the balloon. No. Fortunately, the other half of the launch crew at my house hadn’t left yet and they were able to grab the balloon and bring it with them.

We met up with Monroe and Stewart at Storms Restaurant for some breakfast and then headed to the park where we’d be launching from. We stood around chatting until the balloon arrived then started positioning equipment for the launch.

The payload ended up weighing about four pounds and consisted of six GoPro HD Hero cameras, one MT-AIO APRS GPS tracker, one custom made sensor pod (temp, humidity, location), and two LiPo batteries. The balloon used to carry the payload was a 1200 gram job from Kaymont.

A 1200 gram balloon is rather large and unwieldy to begin with. It was made more challenging by being a rather windy day. We ended up having to zip-tie two bedsheets and drape them over the balloon in order to hold it out of the wind while we filled it up.

About halfway through filling the balloon the hydrogen tank ran out. Fortunately, Burnet is where the hydrogen was originally sourced. Even more fortunate is that the gas supplier was only about a quarter mile from the park. A fresh hydrogen tank was acquired and we had resumed filling in under 30 minutes.

After the balloon was brought up to ~10 lb of free lift I checked the payload line to ensure everything was securely fastened and powered on the cameras. I ensured each camera beeped at me when turned on which indicated that they had started recording.

It was too windy to do a graceful launch. As I was feeding the line through my hands to grab the payload for launch the wind took the balloon and ran with it. The string whipped through my right index finger and left a long burn on the inside of the second and third joints. Since I was bent over clutching my hand I didn’t observe the balloon until several seconds after launch.

The balloon described a rather low initial trajectory as the wind was blowing north faster than it was ascending. While it was caught in this wind the payload was being given a vigorous shake about. Eventually it got out of this turbulent air and enjoyed a much smoother ascent.

Goodbyes and thank yous were expressed, then the chase team (myself, my brother, my father, and my brother’s wife) set out east for I-35, then north for the Salado area. The predictions we’d run had put the landing point in that area. We were hoping for a quick retrieval but things went a bit awry.

On its way up the transmitter had a 30 minute gap where it didn’t report anything. At 80k ft it gave a location update then went silent. We were up near Salado and communicating with a separate ground crew trying to figure out what happened or where it might be. We continued east from I-35 and ended up in the town of Holland.

I pulled into a parking spot near the civic center and went inside to ask if there was somewhere in the tiny town that I could find a wifi connection as I wasn’t receiving a data signal on my phone. There was only one person inside. She was getting what looked like Christmas decorations ready. I introduced myself and when she returned the same she introduced herself as the mayor of Holland, Mae Smith. I gave her a brief rundown of what we were doing and she directed us to the local school district.

At Holland High School we were given a table to work on and a computer to use in the computer lab. Keith Cabaniss, the teacher presiding while we were there, was more than helpful and we’re very grateful for his assistance. Kudos to all of the staff we interacted with while we tried to avoid disrupting active learning sessions.

We ran a few more predictions with hypotheses that we were able to form based on the patchy data we’d received from the balloon. We determined a search grid and, having printed out some maps, proceeded to wander most of the south-eastern quadrant of Bell County. After an hour of farmland and old barns we stopped and had a conversation with a man on a riding lawnmower. He directed us north to Little River-Academy to speak to a man named Ronnie White. Turns out, Ronnie White is the mayor of Little River-Academy. I spoke with the second mayor of the day and left my number in case someone in the area found the payload.

We then went home. At this point I had given the payload up as lost and was just hoping that someone would find it on their land and give me a call. We hung out and did family stuff for the rest of the day.

Around midnight I was getting ready to go to bed and on a whim I decided to check one more time for an update. There was one! About 6 hours prior it had sent 4 or 5 more packets. It was reporting itself on the ground in a field near Salado. I was tempted to drive up and get it right away, but prudence suggested otherwise. I was too exhausted and it would have been difficult to search for it in the dark.

0600. I wake up and go in to get my brother. We get dressed and hit the road. 0700 found us parked on the side of the road peering over a fence to see if we could spot the chute or the box. We drove to a house adjacent to the field and knocked. When nobody answered we drove back, hopped the fence, and walked straight to where the last report placed the payload. It was exactly where it had said it was. We took some photos, then marched back out.

Success!

When we got back I tore down the payload and took many pictures so as to have a record to use to try to determine what went wrong with the tracker. Everything looked intact, aside from one camera that had been knocked into the payload box on what we assumed was impact with the field. Subsequent examination of the video showed this to be the case.

Next post will detail the image stitching process and show the first hard results. For now, I’ll leave you with two really cool videos.

The first is the balloon burst at 96k feet as viewed from all three balloon-facing cameras.

Next we have the point of impact on the ground as seen by all six cameras.

Launch Day

On November 3rd, 2012, 3 coworkers and I set out to launch my second balloon in preparation for the final launch. The mission for this balloon was to test some anti-fog techniques and to give my so-called ‘Sensor Pod’ a test run. We hooked up with Monroe and Stewart from Team Prometheus at a nice park in San Saba, Texas.

Launch occurred at about 1215 GMT-6 from the middle of a baseball field. Assembling the payload line, filling the balloon, and launch all went off without a hitch. (Except for the misplacement of one Leatherman tool. Sorry Stewart!)

Within a few seconds after releasing the balloon we got confirmation that the APRS packets were being picked up by the online APRS network. We then packed up and drove into town to find the public library. We hopped on their wifi and monitored the health of the balloon and made plans on how to proceed. We elected to get lunch and then start chasing it.

The chase was mostly uneventful. First we determined where we should go based on our new prediction. The balloon wasn’t ascending as fast as our previous predictions were run with, so we had to re-predict. We determined that Gatesville, TX was a good point at which to reassess.

Lunch ran a bit long, so by the time we were about 20 miles outside of Gatesville we started receiving phone calls stating that it appeared to be on the ground and asking if we’d retrieved it. This was also about the time we started to get a useful data connection on our phones, so we started looking at where it was. It appeared to be in or very near to a pond.

We drove as close as we could and asked one of the families in the last house on the road if they could give us some guidance. After examining the map they directed us to the landowners at a nearby house. We gained permission to go on the land and proceeded to hike in toward the pond.

After ensuring the the car wouldn’t start a grass fire we set off to retrieve the payload. We had to traverse a number of barbed wire fences and dodge numerous cow pies along the way. Eventually we could observe a berm in the near distance and assumed that to be the berm containing the pond. From the top of the berm we could look down and into a small pond. A quick scan showed no sign of the payload _in_ the pond. A small sigh of relief later we spotted the parachute at the opposite side and on the top of the berm. The payload was further down the water-side slope of the berm, about 8-10 feet from the water.

It appeared that the payload was traveling northeast and struck the southwest facing downward inner slope of the berm. It caught in the grass and pulled the parachute down. Recovering it was a small matter of walking over and collecting the whole chain.

After recovering the payload box I pressed the camera buttons to see if they would turn off or on. They both turned on and immediately went into recording mode. A few minutes later they both beeped the low battery signal and turned off, which indicated to me that the batteries had drained to the point of turning off the cameras. Much better than my previous flight where the camera shut off with a still mostly full battery.

I opened the box and turned off the sensor pod and the APRS transmitter. I gathered the the payload chain into the chute and we turned around to hike out. After that it was just a matter of driving home and then looking at the data.

As you can see in this map of the predicted path overlaid with the actual path the balloon behaved as expected. It went long due to not providing enough lift, but the prediction gave us a good idea of which direction to go in anticipation of the landing.

Results

My sensor pod performed mostly as I desired. It did restart itself 257 times. I’m not sure if that’s a mechanical issue or what. The data didn’t seem to suffer too much for it, though. The disappointing thing was the GPS. I thought I had used a GPS module that worked up to the altitudes the payload would be hitting, but the one I used (D2523T from SparkFun) capped out at 40k ft. The left about 63k ft unaccounted for. I’ll be trying to get my backup module integrated before the next launch

The cameras performed very well. I had one facing up-ish and one facing down-ish. The top camera got a lot of sky and sun footage but nothing very interesting. The downward facing camera, however, got a ton of great shots of the landscape, the horizon, and very interesting cloud formations. Condensation wasn’t too much of an issue. What little did form actually dissipated before too long. The only downside was that, due to the slow ascent rate, the cameras stopped recording before getting the landing or even the burst of the balloon. (Which wouldn’t have been fun to watch anyway, as the top camera couldn’t even see the balloon)

Overall, the mission was a success. Questions raised by the first launch were mostly answered by this launch and some assumptions were validated. I hope to have some video available for viewing soon. In the meantime, enjoy these two extracted cloud shots and the images below of the launch and recovery.

Big thanks to Ben, Steve, Ryan, Monroe, and Stewart for their assistance.

Operation StratoSphere – Launch 2 Photo Album

Above our heads at all times there are many satellites orbiting our planet. They all serve or did serve some purpose. Some of those satellites are operated by NOAA and are used to watch the weather patterns on Earth. Many of the NOAA satellites transmit images of what they see using a system called Automatic Picture Transmission. They broadcast on the 137 mHz band and there are currently 4 that still broadcast APT data. In September of 2012 I built an antenna to attempt to use my radio as a receiver of these images. You can check out some of the stages of the build process in the album below.

The signal coming from one of these satellites is circularly polarized, which is what this antenna is built to receive. It’s not the greatest build, but it is serviceable. This antenna is supposed to have good omnidirectional coverage from the ground up from horizon to horizon. In practice, my build doesn’t fare so well.

I mounted the antenna in my attic and used a SDR (Software Defined Radio) setup that I have to track down the satellite signals. As I stated before, this antenna doesn’t perform extremely well. I was, however, able to get some halfway recognizable images out of it. Without further ado, here they are.

Somewhere in the middle of 2010 I came across a video on Vimeo that was shot using two GoPro HD cameras. The cameras were attached to a styrofoam cooler and the cooler was attached to a weather balloon. The balloon reached 80,000 feet and the cameras took beautiful HD footage of the entire trip.

For several years before that I had played with creating panoramic images by stitching together multiple pictures. For example, here are some less than stellar panoramas from a trip to Tucson, AZ in 2004.

Not too long before seeing that video I had come across http://lucid.it, a site that demonstrates panoramic video playback. Picture a video player that allowed you to look in any direction in the scene while the video is playing.

It didn’t take long for me to consider how awesome it would be to have a fully spherical 360×180 degree panoramic video of a balloon flight to ~100,000 feet. I promptly started researching and trying to recruit assistance. If you’re curious about those first couple months of research, you can read through the Wave discussions in the following archives (some of the links therein may no longer function properly) :

• Planning
• Concerns
• Tidbits from EOSS
• Equipment
• How Tos

After a lot of research and learning I decided I needed to stop reading and start doing. You can only learn so much about swimming before you get to a point where you have to get your feet wet.

I went to a local craft store and bought several pieces of foamcore in order to start prototyping some payload containers. I also purchased a GoPro HD camera for use in testing the prototypes. The first pass on creating a payload container involved laying out a model, basically an unfolded cube, then cutting it out. The joints were done by cutting two 45 degree cuts through to the opposite side’s paper backing, but not through the backing. This allowed a cube to be folded around the 90 degree corners I’d cut. One face of the cube was cut out separately as a lid was needed and I figured it’d be nicer to not have it flapping around or bearing weight while connected through just one fragile joint.

[Show as slideshow]

Using the box I created I was able to approximate a six camera setup by making a rigid frame for the box to fit into. I would then take one picture, rotate the box to another camera’s location and take another picture. Rinse and repeat. The first test’s result can be seen below. Click and drag the mouse to rotate the view. If the viewer doesn’t work, try going to its other home.

The prototype box went through three versions before getting the result I have today. Over the course of the previous two years I have acquired through purchases, gifts, and bribery, five more GoPro cameras. I now have a full cube’s worth and have a box design I’m mostly happy with.

[Show as slideshow]

That’s all for now. I’ll post later on the current state of the project.