The Journey to PyCon 2014: Part I

True Story Follows

I was at work eating lunch, minding my own business, when Chase Seibert just walks up to me and literally backhands me in the face with a metaphorical gauntlet, encouraging me to take on the challenge of submitting a proposal for PyCon 2014.  The relevant work in this case is to present an ongoing project of mine in which I’m building an autonomous blimp, mainly for the purpose of aerial photography.

blimp_pic

 

Since I have a decent amount of work ahead of me, I thought it best to try and document my progress in what will hopefully be an epic saga filled with technical information and dramatic plot twists.

Where the Project Stands Now

Since I’ve taken up working at Hearsay Social, I really haven’t dedicated much time or effort to side projects since there are plenty of fun and challenging problems to work on at real work, and therefore the blimp has taken to the back-burner for the last few months.  Additionally, a new problem has risen in that in order for this to be a presentable project at PyCon, it would probably need to be written at least primarily with python.  But alas, right now I’ve got a distributed system that uses C++ on the onboard controller and C# on the client application, and no python.  Finally, the overhead involved with setting up the hardware required coupled with the cost of purchasing and storing lifting gas (which gets expensive quite quick) is a huge deterrent to sufficient testing.

 

Next Steps

In order to progress in the right direction, I’m taking a step back and doing some design changes.  First off, my onboard controller is a Roboard RB-110 which runs either Windows XP or Linux.  I initially just installed Windows XP because I didn’t want to deal with much of a hassle with the amount of peripherals I was hooking up, but it’s been fairly problematic as on onboard controller with basic problems like error messages popping up that require clicking through upon initial bootup…not good to require a mouse and monitor on the robot to get it started.

I’ll also be re-writing as much as I can in python.  If speed is an issue with the hardware, then I’ll use C++ for the necessary drivers and then wrap those with python logic.  For the client computer, I currently have some application code written in C# (again constraining me to a windows computer).  I initially made this decision because of the ease of use setting up a graphical user interface, but after a little bit of research I’ve decided that I’ll use PyGTK and Glade to create a new GUI, and from there it will probably make the rest of the application quicker to finish and easier to maintain.

Finally, there comes the problem of testing a huge blimp filled with expensive helium or hydrogen outside with an autopilot algorithm when we have no idea yet if it even works.  Logic of the autopilot algorithm aside, I need to test to ensure that I’m reading sensors properly and responding appropriately based off of their readings.  In having this issue hanging over my head, I’ve been wishing that I had a multicopter as an intermediate step.  Thankfully, I reached out to Jason Lamb at AeriCam, and I was able to get my paws on a multicopter where I can use the same hardware drivers and apply different logic to achieve the same result of an autonomous drone.

IMG_0005 IMG_0002

From here, what I plan to build is a semi-autonomous drone in which the logic for controlling the aircraft will be housed entirely onboard.  A client application will be able to view relevant sensor data (i.e. altitude), and send general commands to the drone and the “thinking” will be handed off from there.  The drone will be capable of carrying a Canon Camera which interfaces with the Canon SDK to take pictures via USB and stream a live video feed back to the user.  All data will be transmitted through the XBee RF modules (which I had working line of sight at about 57 kbps), eliminating the conventional method of drone piloting with two different connections between video and control.  The drone should be capable of navigating a set of waypoints, hovering, and reaching and maintaing target altitudes.  If all of these things can be done, then it will be trivial to add additional features like maintaining a particular flight pattern (a few different flight patterns may be useful for filming).

I plan to make the first big push on the multicopter this coming weekend.

Hardware List