Pegasus I: IoT Command and Control

One of the biggest problems with High Altitude Balloons (HAB) is the retrieval of the payload after the flight. This can be a problem for a number of reasons. “Typical” flights have sensors and some on-board way to capture the data plus some form of GPS transmitter such as SPOT GPS or a HAM Radio system using a special frequency (“APRS”). Then, you add a balloon, a parachute and launch. You probably ran some predictions using available online applications to determine where the balloon will burst and where it will land. All that is great as long as the predictions are good and the payload doesn’t land in a lake or in a forest preserve.

For our flight we decided to try to get around the issues of not really knowing where the payload will land. Step 1: Instead of relying on the bursting of the balloon to start the descent, our payload had a mechanical release which will let go of the balloon upon command. This meant we could decide when to come down. If the balloon position is getting too far away or if it is heading anywhere we don’t want, we can send the command to come down early. Now, this only solves part of the problem since the slow ride down under a parachute still can take the payload a long way. Step 2: We went for a “HALO” High Altitude Low Open drop. Attached to the payload are two things for descent: a drogue chute that keeps the payload upright for most of the ride down and a main chute to provide a soft landing. The drogue isn’t very big so it doesn’t slow the drop as much as the main parachute so there’s still a real possibility of destruction when it lands crashes. The main chute is in a box on the payload which we can deploy on command or (just in case we don’t send the command) the on-board processor will release it if the altitude is too low.

The combination of these two capabilities means we can watch the payload and telemetry and make a decision on roughly where to land. Depending on the altitude, it still takes 10-15 minutes to descend low enough to deploy the chute BUT that is much faster than an hour or so under a large chute the whole way down.

Below you can see the payload box. The tube in the center is the balloon release. A line from the balloon goes into the tube and around a simple lever. Pull the lever (or have a servo do it) and the payload comes down. The container on top-back part of the payload is where the main chute is packed. The drogue chute is then connected to the lid of the parachute box and then to the top of the main chute. Here again, you pull a lever and the lid releases and the drogue chute pulls the main chute out. The metal tabs you see on the corners are where the main parachute shroud lines are tied. There’s two more in the back that you can’t see in the picture.
WP_20150127_001

Here’s a diagram of the balloon release:
balloon-release

Mechanically, it all worked as we designed (and hoped). However, being our first flight, we’re obviously not skilled in the art of packing a parachute properly. When the main chute was released, it was tangled and the more the drogue chute pulled, the more the main chute remained in a ball. Thankfully, the drogue and main chute acted as streamers and slowed the payload down enough to survive the landing impact – all still works. Now we have some experience and hopefully, the next flight will see a successful parachute deployment.

To sum up, we decided the “IoT Command and Control” portion of our Internet of Things (IoT) experiment would include the rather large actions of balloon release and parachute deployment. Each of these actions could be initiated by on-board intelligence if the processor determines a problem situation. For example, the balloon will release if the flight time exceeds a preset duration. BTW, that countdown only begins after the balloon is launched and the payload “arms” itself. As for the parachute, I mentioned before that if the payload detects falling AND the altitude is below a preset limit then the main chute will be deployed. Some other side commands allow us to change the behavior of the payload and to use new values for what I mentioned as preset limits. For example, the preset limit for flight duration was coded/configured to be 2 hours. After that the balloon is released automatically. After the balloon was launched I reset the maximum duration to be 1 1/2 hours just to be safe. The commands are simple strings of characters that are parsed for information. Once the parsing happens and the information validated, the command is acknowledged back through the system and executed.

1 thought on “Pegasus I: IoT Command and Control”

  1. So glad you found Pegasus and had a successful flight. I attended your lecture at TechReady 20 and was checking in through out launch day. Truly a wonderful demonstration of how to apply current technology in a functional architecture.

Comments are closed.