Raspberry Pi Balloon Goes Too High, Goes Boom, But Survives
Some people like to get high on a Wednesday afternoon. [Kevin Hubbard] of Black Mesa Labs likes to get really high. Even higher than intended: last month, he flew a helium balloon powered by a Raspberry Pi to 103,000 feet. It was only supposed to go to 90,000, but a fault in the code for the controller meant that it went higher, burst and plunged to the ground. All thanks to an extra hash mark in his code.
[Kevin] was part of a team called the Balloongineers who are competing in the Global Space Balloon Challenge, a project to simultaneously fly balloons from multiple locations. The Balloongineers entry was called HAB1, built around a Raspberry Pi, an FPGA watchdog system, a uBlox GPS and an Iridium satellite modem. The idea was that their balloon would zoom up to 90,000 feet, where it would release some helium gas, hover, and move eastwards with the prevailing winds. reporting back via satellite as it went. Unfortunately, something went wrong. The balloon didn’t report back properly, and kept on rising, eventually reaching over 100,000 feet, where it burst and fell to earth.
[Kevin] thought all was lost, including the expensive satellite modem that HAB1 used. But the next day, his balloon sent him an email, reporting that it was hale and hearty at an altitude of 300 feet. After recovery, he analyzed HAB1, and figured out what had happened: a single mistyped hash mark had caused the system to lock up when it tried to open the vent to release the gas.
What saved the rig was the foresight [Kevin] had in building it. Although the system didn’t work fully as planned, the FPGA watchdog (nicknamed the Lizard Brain) eventually noticed that the main computer was locked up, and rebooted it, enabling the system to report back to [Kevin]. An additional recovery mode woke the system once an hour sent a location and went back to sleep, which allowed the small battery to keep powering the system until it could get a signal out the morning after. That’s a smart piece of design in a system that allowed them to recover the hardware, even though the main objective of hovering at 90,000 feet wasn’t achieved.
[Kevin] ends his writeup of the flight with a few notes that any engineer would be wise to consider. Primary among these is his decision to have the system check very rarely for manual overrides over the satellite connection. He decided to do this to save money: checking for messages on Iridium costs a certain amount each time you do it. If he had checked more frequently, he might have been able to fix the problem earlier by venting the helium manually, leading to a more controlled descent and recovery. In any project, a failure can only be useful if you can figure out what the problem was, gathering as much information as possible to help you avoid it next time.
Filed under: Raspberry Pi
from Hackaday http://ift.tt/273UZZM
via IFTTT
