PyCon 2014: 25 Days Out. Independently Validate the Autopilot Controls


For anyone keeping up with our progress on the blimp so far, things have been coming along quite well.  So well, in fact, that I seem to have inspired a group of fine modern gentlemen to pursue the art that is the dirigible.  Just check out this text between my brother-in-law and me today:



As of yesterday, our current status with the blimp is that we could manually control it by interpreting commands from an XBox controller, encoding the commands to bytes, sending those bytes across a wireless serial connection, de-serialize the commands, convert the commands into messages for the rotor control, and then execute the rotor control commands.  As you might imagine, the resulting responsiveness is not very impressive.  However, this is to be expected and is okay for our concerns.  The end goal is to make the onboard processor on the blimp make all of the decisions and communicate internally to the motors.



Code Architecture

To catch anyone up with how we went about creating the architecture for our code base, I created separate classes that communicate with each other like so:Screen Shot 2014-03-17 at 11.12.25 PM


You’ll notice that the class that deals with XBox control input does not directly communicate with the motor controller.  This was done intentionally so that we could independently validate the motor control when using enumerated data types like “pitch up with X intensity” or “yaw left with X intensity”.  Now, when programming the autopilot algorithm, we can do a lot of independent work without actually having to connect everything to the blimp because we can trust that yaw, pitch, and speed controls all work properly.  So now if we want to build our autopilot algorithm, we just need to ensure that the outputs are the same data types as the above Manual Control Manager class.  So now we want to make something like this:

Screen Shot 2014-03-17 at 11.20.11 PM

Previously, I’ve been working indoors and haven’t had a chance to really validate GPS yet.  So today I was finally able to do that since I was working out of my brother-in-law’s apartment:



Without mocking anything out, the user interface worked properly and loaded the correct map from Google maps:



I spent the day writing the autopilot algorithm, which was surprisingly simple and only came out to roughly 150 lines.  Normally with any sort of aircraft, we would need to worry about pitch, roll, and yaw:

Screen Shot 2014-03-17 at 11.30.00 PM


However, since the blimp has a particularly low center of gravity, it will automatically always normalize to an upright position, and we don’t need to worry about roll.  Therefore, for the autopilot algorithm, we really only need to worry about pitch and yaw.

The Autopilot Algorithm

We deal with yaw by taking the current GPS and compare that to the target GPS.  Using some basic trigonometry, we can obtain the target heading that we want.  Now we can use our compass sensor to get the current heading.  Compare the current sensor heading to the target heading and send instructions to either yaw left or right, and pass an intensity that corresponds to how hard we want to turn (this value can be proportional to the distance between the current and targeting heading).


We deal with pitch in a similar manner by comparing the current altitude with the target altitude.  The target altitude is determined by user input, and instead of passing mounds of controller data, the user instead can just hit the up arrow on the XBox control a few times to increase the target altitude.  The onboard controller can do the rest of the work to pitch up accordingly.  The current altitude is determined by the onboard altimeter.  Take the difference between the current altitude and the target altitude, and this gives us our altitude delta.  Now we can do some basic trigonometry again to determine a target pitch.  However, we need a value for delta X.  In my case, I just used an arbitrary value of 50 feet.  This means that the autopilot algorithm will attempt to reach the target altitude in 50 feet.


Now we have the target pitch.  Compare that against the current pitch using the onboard accelerometer sensor.  Given the difference between the current pitch and target pitch, we now instruct the motor controller that we need to pitch up or down, and pass an intensity proportional to the distance between the two.  I also established upper and lower bounds for a max and minimum pitch so as to prevent the blimp from going all crazy.  Currently, I just set this to 30 degrees and -30 degrees, respectively.

Testing the Autopilot Controls

Now, instead of testing all of this right away directly on the blimp, we can do most of this without attaching everything.  So I set everything up here.  For starters, we need to remember that we’re dealing with a robot, and therefore the robot can become self-aware and turn against us at any moment.  Therefore, for safety measures, we only give the robot power using a 6 foot power cord, as you can see below.



So we can demonstrate everything with this setup:



The below video demonstrates automated pitch control.  Although yaw was also included with the autopilot algorithm, I couldn’t physically demonstrate that since the tail fins weren’t connected:

In the video, the first thing I do is hit the up arrow a few times on the XBox controller to indicate to the controller that I want to increase the target altitude. It responds by trying to pitch up. Now when I adjust the pitch of the gondola manually into the same possible achievable positions in flight, it responds by obtaining a new target pitch and adjusting the motors accordingly.

Note that it takes a bit for the thrust vector to pitch upward in this case.  This is intentional.  What’s not seen is that the tail elevator which would be taking action if it were connected.  Before relying on the rotors’ thrust vector to control pitch, we first adjust the tail elevator.  Once that has achieved its absolute maximum or minimum position, we then signal the thrust vector to adjust.

The only thing not directly controlled by the autopilot is speed.  Rather than make the speed proportional to the joystick input from the XBox, in this case I just made it possible for the operator to increment or decrement the speed by tapping the left or right buttons on the XBox controller:

If everything works as planned, then I should be able to just plug everything into the blimp, and it all works.  If that happens I don’t know what I’ll do with the remainder of my day…