I started this blog yesterday, but in truth I've been working on the HAPP project for a few months and I've made some real progress. I'm just catching up with the blogging :-)

So I'll start off where I began the real work: The control system. Before thinking about hardware and software, I figured I'd need a firm grasp on the controls theory needed to fly the HAPP autonomously. It would be nice to use an existing open-source flight controller like this, but as I'm going to use something like 12 gas jets instead of 4 propellers on a drone, I assumed that rolling my own controller would not be much worse than trying to modify an existing one. Plus, I'm just a roll-your-own kind of guy...

For those who care, I've posted a short bibliography here that contains some books and articles that I found particularly useful. It was a great refresher course as I hadn't really thought deeply about controls theory since grad school back in the early 1990s. Even then I never had the chance to study spacecraft dynamics and control, so some topics were new to me. Real controls gurus may roll their eyes at the material in this post, but it was my first time through some of it and I had fun learning. So there!

First up were dynamics and kinematics. For aircraft and spacecraft, we typically want to model both the translational motion (trajectory) and the orientation (attitude), and we have to keep track of our frame of reference (kinematics) - relative to the craft, to the ground, or to elsewhere. For the HAPP, I really don't care where it comes down, even if it blows 50 miles away from the launch site. In addition, it would take an entirely different strategy to actively "fly" it back home, and then we'd be talking about designing some sort of high altitude glider like this (nice job guys!). For those reasons I chose to neglect translational motion and simply focus on getting a nice, stable attitude for the cameras. Let the winds carry it where they may... we'll find it with GPS tracking.

Knowing that I'd eventually want to implement the control system in a simulation before investing time to create real hardware and software, I modeled the rotational dynamics and kinematics in Simulink. I had to purchase the MATLAB/Simulink suite as I've not needed them since grad school. Needless to say, they've evolved a bit since the early 90s... a couple of all-nighters doing tutorials over the weekend and I was ready to rock. This book was a huge help. It's the best reference I've seen for getting up to speed quickly in Simulink.

I spent a few hours implementing the model based on the outline in this paper. The model utilizes quaternion-based kinematics, which are a nice way to describe rotations in three axes. Quaternions are computationally friendly compared with the alternatives like Euler angles and Direction Cosine Matrices (which is why, as I learned, that quaternion-based models are also used for 3D graphics).

Once everything was running smoothly, I discovered that for $45 I can purchase an aerospace blockset for Simulink that has the same math conveniently available in a pick-and-place modeling block. So we'll just write my efforts off as an edifying exercise and a nice double-check on the maths :-/

With the model in place, what about the controls strategy? The general class of problem we're trying to solve is called a two-point boundary value, minimal time, optimal control problem. That's a fancy-pants way of saying that the HAPP is in one position, possibly spinning with some angular velocity, and we want to return it to a target attitude with zero spin. Furthermore, we want to do it as quickly as possible. In other words, we want it to stabilize its position and spin so we get nice clean video.

It turns out the optimal control law for this class of problem is known as a bang-bang controller. It starts by turning on the jets in one direction to counteract the spin and begin moving the HAPP into the desired attitude. Then, at a certain point, the jets fire in the opposite direction to slow it down and "land" it in the target attitude with zero spin.

To use a car analogy, it's similar to the following problem: How do you get a car from point A to point B in the least amount of time, with the condition that it must stop at point B without over-shooting? Answer: Stomp on the gas pedal all the way (bang!), accelerating as fast as possible. Then, at a certain point, stomp on the brakes as hard as you can (bang!). The trick is to determine that certain point.

Propeller-driven drones typically utilize a PID controller which can vary the speed of each propeller within some range from zero to max. That's a different type of controller - it's not all-or-nothing; it's not bang-bang. For cold-gas jets, typically they are turned on and off with solenoid valves, and therefore are either firing at 100% or not firing at all. There are proportional valves available but we don't need them - we actually want the simple on/off solenoids to implement the bang-bang controller. This is exactly the type of controller used in the autopilot for NASA's Apollo Lunar Lander back in the 1960s (try your hand at landing the Eagle manually here!).

That "certain point" is called a switching curve. Why is it a curve? Well, start by making a graph with the rotational position on the x-axis, and the rotational or angular velocity on the y-axis. This is a phase-plane diagram. Given the physical properties of the HAPP (specifically the inertia tensor and the moment produced by the jets), it can only move in certain trajectories on the phase plane when we apply a moment by firing the jets. We want to drive the HAPP to the origin of this graph - zero angular velocity, and zero angular position versus the target. It turns out there is a parabolic curve through the origin that the HAPP can "follow" back to zero by firing its jets continuously. Being on this curve is like being in the stomp-the-brakes phase from the car analogy. But to reach this curve and stomp the brakes, we first have to fire jets in the direction opposite from the braking one. Putting it all together, we fire jets in one direction until we reach the switching curve, and then we switch and fire jets in the opposite direction until we reach zero spin/zero position error.

After some math and a little sketching, I generated the switching curves and was ready to build the controller in Simulink. You might notice two sets of curves in the picture: red and green. What's that all about? The two switching curves are separated by a deadband to prevent an over-active controller that essentially fires jets almost all the time. I'll leave it to you to read up on that topic.

Next time: Implementing the controller in Simulink...