PyCon 2014: 28 days out

While I’ve been trying to blog about interesting technical things I’ve learned over the course of finalizing the blimp project I’ve been working on in preparation for PyCon 2K14, the individual components are for more interesting when given the context behind why I’m writing certain pieces of code.

The absolute biggest challenge to this whole project is how difficult it is to go about testing a dirigible.  When prepped for flight, they are very large and far more logistically challenging than, say, a quadcopter.  More importantly, the lifting gas just to fill up a blimp of the size I’m working with is about $140 using helium and about $25 using hydrogen.  Thus, I’d taken a number of measures to make the entire project more testable in order to gradually and systemically tackle the problems of autonomous flight.

When initially scoping this project, the most probable challenge to assume would be how to go about developing an autopilot algorithm to fly a blimp.  As a spoiler alert, this is probably the absolute easiest aspect of the whole system.  The bigger challenge is to ensure that all of the components involved work in harmony.  For me, this meant reading from an XBox remote controller, a client-side XBee communications module, a controller (blimp-side) XBee communications module, multi-threading multiple logical processes with shared resources. encoding and decoding a live video feed, developing an efficient communications protocol between the client and controller, reading from sensors (GPS, altitude, battery voltage, pitch, roll, and azimuth), linking remote input actions with real world responses, and writing to several different motors.

The very last piece in the process is to send appropriate logical instructions to the PWM motors.  If everything else works well, this would be like programming an object to move across the screen through waypoints.  So in order to get to that state, I needed to be able to test all of the previous individual components.  To make this a lot easier, I borrowed a quadcopter from Aericam.  The results of the initial platform are showed below:


This was actually the second flight.  The first flight ended in a lot of smoke and burns to the carpet before a premature end to the flight about 3 seconds in.  The aftermath can be seen below:

carpet_damage

 

This of course made me second guess my advocacy of hydrogen for this particular dirigible.

So after that failure, I realized that I’d underestimated the importance of center of gravity.  Rather than try to take on and solve that problem, to which I’m likely not well suited, I was confident that the work done thus far had at least validated that I could work all of the distributed pieces of the design in concert. That video at least demonstrated that I could interpret the commands from an XBox remote, send encoded bytes across a wireless serial connection, interpret the commands on one thread in another machine, and send corresponding commands to the motors in the quadcopter.

IMG_0040

The other important piece that had been separately validated involved collecting sensor data.  Altitude, pitch, roll, and yaw could be verified independently which I also wrote about.  The only thing that needed a little more work involved validating the GPS.  I first tried walking the board outside and logging all of the information from the GPS sensor.

Screen Shot 2014-03-14 at 11.27.30 PM

However, the logs indicated that the GPS sensor never actually got a fix on a satellite. I surmised that this was because I didn’t have a clear view of the Southern skies and I later validated the GPS separately.  With all of this data, I was able to create a user interface with a map view where a user could click on destination locations, and a live video feed with a heads up display that showed all of the sensor data:

IMG_4475

Without an abundance of time left to finalize the whole project, I went ahead and moved forward with testing on the actual blimp I have. Although helium is currently in short supply, I was lucky to quickly find Ron from SF Balloon Magic that was able to sell a container:

ron

The first thing I noticed was the sticker that indicated that the gas was luxuriously inert, unlike the hydrogen I’d bought previously that I’d ended up using to fill up a plethora of Valentine’s Day Balloons last year.

photo (2)

My initial plan was to use half of the tank on one fill up to test hovering the blimp inside the office and subsequently use the rest of the tank to test an outdoor flight, which wasn’t the most ideal scenario.  Since Hearsay Social’s workspace is inside an office building, I wouldn’t be able to store the blimp filled or take it outside from indoors. I’m also living in an apartment, so that didn’t offer any better solutions.  I ended up reaching out to Larry from EBlimp.com, the best RC blimp maker, where I’d initially bought the blimp from.  He’s now within reasonable driving distance, so I headed down and met up with him today.

awesome

IMG_0001

IMG_0002

IMG_0050

Larry has a 35 foot blimp in his warehouse. NBD or anything.

The plan was still to test hovering first with a filled helium balloon, which should be a fairly simple task. Before wasting any of the gas, we filled the blimp with air from a shop vacuum to find and patch any small leaks.
IMG_0039
Unfortunately, I didn’t move as absolutely fast as I wanted, and in setting up in San Diego I encountered a few software problems I hadn’t dealt with yet. While I was confident in the individual components so far, I hadn’t yet tested GPS in concert with everything else. GPS coordinates require much finer precision than anything else I’m working with, and therefore they needed to be transmitted as doubles instead of short integers, a difference of 8 bytes and 2 bytes, respectively. As a result there was a particular low level case I hadn’t accounted for which I adjusted after a decent bit of troubleshooting.

IMG_0032
In order to connect everything easier, I’d also transitioned away from using a full-blown, ridiculous monitor to SSH’ing into a static IP from a direct crossover connection from my laptop. But alas, upon another reboot of Ubuntu, I ended up losing the static IP and thus forcing me to bring back a large, ridiculous monitor, which required a trip to the store to buy a VGA cable we didn’t have.

Finally, I felt it necessary to refactor some previous code since I was transitioning back to manually testing servo control.  Previously, I’d tied the commands from the XBox controller directly to rotor actions.  However, in order to make things more modular and give me the ability to essentially mock out autopilot testing for later on, I instead added an abstraction layer in between the XBox commands and the motor control by subclassing the class responsible for the autopilot algorithm and made a new ManualControl class (to be more clear, I created an abstract class that both classes then inherited from).  I’d just recently set up a framework wherein the autopilot algorithm would be responsible for determining what action to take next (i.e. pitch up, yaw right with X level of intensity) without any direct access to the motors themselves.  The autopilot will instead just send the appropriate messages to another service that’s responsible for adjusting the motor signals to obey the commands received.  In this way, I can test a lot of code up front by making another class that sends those same commands by converting input from the Xbox controller.

I finished up the day with removing the onboard controller from the quadcopter and wiring it to the blimp gondola.

IMG_0042 IMG_0043 IMG_0044   

Still to come this weekend:  hover inside the warehouse and subsequently fly the blimp outdoors with the autopilot algorithm.  

In other great news, last Friday a US court ruled against the FAA in regulating drones for commercial use below 400 feet!