Electronics: Autopilot Computer (AP)

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!

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 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.