Monday, October 2, 2017

Electronics: System architecture overview

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
  • 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 & .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 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 by two separate micro LiPo batteries. There is no single point of failure in this setup - it has complete redundancy.

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.

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.

No comments:

Post a Comment