For any newcomers to the posts I’ve been writing about regarding my blimp project, I’ve been working on an onboard controller for a semi-autonomous blimp. A talk about the project was accepted to PyCon 2K14, and I’ve been working since December to really bring everything together in time to present on April 12th.
All in all, things have been going very well, thanks in large part to the generous assistance from Larry Fleming, owner of EBlimp.com: The Home of Remote Control Blimps and the original designer and manufacturer of the blimp I was working with. Having an extremely competent hardware person present made my work far less stressful, and his insight was otherwise invaluable for some of the decision-making that went into the autopilot module.
As of last week there were two major flaws with the autopilot algorithm:
- Altitude was measured using temperature, pressure, and humidity, and therefore its reading would fluctuate with gusts of wind.
- As those readings fluctuated, the blimp would adjust to the new reading by pitching up and down seemingly at random.
- The blimp would attempt to yaw left or right based on its azimuth position. Since there are no directly opposing forces to the yaw action and velocity is constant, you can imagine that the blimp would repeatedly overshoot its intended direction.
- Also, the sides of the blimp looked really boring.
To address the altitude problem, I instead read from the GPS to read altitude. The idea, which I didn’t get a chance to actually validate, was that the GPS would give more consistent data without fluctuations and cause the problem with pitching.
To address the yawing problem, I had to basically establish target rotational velocities rather than a target azimuth. Previously, yawing left or right would be determined based on the target azimuth in relation to the current azimuth. Either turn left or right. The intensity of the turn, or how much we should tilt the tail rudder, was directly proportional to the distance between the current azimuth and the target azimuth.
The new algorithm would repeat the same steps above, but instead of establishing a yaw action of left or right with an associated intensity, we would establish a negative or positive target rotational velocity. Additionally, I started to keep track of the current rotational velocity every tick. Now if we compare the current rotational velocity to the target rotational velocity, we can now apply a corresponding force through the tail rudder to accelerate or decelerate accordingly.
If you imagine this concept in action, the blimp would now turn left or right to reach a new azimuth, but as it approaches that azimuth, it would now apply a counter force as well. The video below demonstrates this. Sort of. Actually not at all. It’s really hard to tell what’s going on. The wind is acting really bananas.
The most challenging part of the project at this stage is how to go about testing everything. To physically test all parts of the blimp, we need to be outdoors to be able to read from the GPS, we need to fill the blimp with about $100 of helium, and we need room to test. To find ample space we walked down the street a ways to an empty region. The testing conditions were absolutely awful. Or they were absolutely perfect…depending on how you look at it.
The wind was particularly harsh on the day of test. This creates a double-edged sword. Validating the blimp with no wind is fairly simple but also means that we don’t know if it will work in harsher conditions. But under harsher conditions when things don’t work perfectly, it’s harder to isolate what the problems are. A brief clip of the test flight, before we got too distracted to care about filming, can be seen below:
At some point in the flight, one of the rotors broke because a loose wire got caught in it. Whether that happened at the beginning or the end, I’m not sure. But if it did happen toward the beginning, that would explain why it had difficulty overcoming the wind. Otherwise, we still had some problems dealing with pitch against the wind, but yawing seemed to work as intended even in the harsh wind conditions.
What Still Needs to Happen
I’m not sure that using the GPS to measure altitude made a positive impact. Two things come to mind to try and deal with the issue:
- Instead of trusting every single value read from the altimeter, maintain a rolling average of the last 4 or 5 reads (or some number). This, of course, would lower response time a little bit, but might be acceptable
- To establish a target pitch angle, I’m using basic trigonometry and creating an arbitrary value for length (height is the altitude delta between target and current). I defined this as a constant of 50 meters. I could increase this value (just double it for instance) such that the blimp would take longer to gain altitude, but it wouldn’t pitch so erratically
A clear lesson from all of the work done is to test every component of everything. In this scenario, it makes the work much easier if as many components as possible can be tested abstractly and independently without having to launch a drone in the sky to validate it.
Otherwise, if you want to get arbitrarily pumped about blimps and early 20th century dirigibles, check out the slideshow I put together from pictures and clips taken during the project: