You can check out the flight demo in the video below:
True Story Follows
So you can check out how progress has been coming along over time by checking out my last flight test. The long story short is that we got teamed with Iceman, we ended up making contact with multiple bogeys 2 miles out at our 2’o clock. We started pursuit, but then Iceman ended up taking forever to take the shot. He never took the shot and we ended up in his jetwash, so then the blimp lost power but we still did a few barrel rolls all over the place. This is all to say that YouTube shut my video down for copyright infringement when I tried to overlay the Top Gun soundtrack.
But here we are now, and at this point I was mentally prepared at least another remaining issue to prevent the autopilot from flying correctly. However, the flight controller at this point was sufficient to successfully navigate incoming waypoints and to stay in on general area during flight.
Adjustments From Previous Flight
Incremental Thrust Adjustments
Last flight, hover failed miserably. After reviewing flight footage from my previous flight, I noticed that when I initiated the hover command, it took the blimp a sluggishly long amount of time to adjust its thrust to begin vertical acceleration. This obvious problem was indicative of why thrust adjustments in general in the vertical and horizontal plane didn’t really work. The algorithm in place was written with the intent of being able to make miniscule adjustments to be able to apply the perfect amount of force to reach a certain state of equilibrium, but all I was really doing here was making the response time entirely too long which is analagous to driving drunk. I removed this logic, and the changes in force to the blimp’s motor became far more reasonable.
Ground Speed vs Air Speed
Another big problem we noticed during testing was that cases existed where the blimp would not yaw appropriately even though it was attempting to. The tail fins would be turned to the max, but the blimp had no power to turn. I wasn’t sure why this would be the case since the blimp was still moving at a solid 5 miles per hour, but Larry pointed out that the blimp was being carried by the wind. This made me realize the important distinction in flight between ground speed and air speed. Air speed, as measured through something like a pitot tube, does not account for the wind at all (i.e. a gust of wind against your aircraft would give higher velocity measurements, where your ground speed will have slowed or remain unchanged). But in all reality, ground speed is irrelevant to an aircraft. So if the wind was moving at 5 miles per hour and carrying the blimp down wind, then I could quite possibly have an airspeed of 0 which would cause the blimp to have no power through its rotors. All this is to say that I added motor differential logic so that yawing to the right increased the output from the left motor and vice versa for the right motor. This ensured that there was always power no matter what, and this is something I should have been doing regardless in order to take advantage of the blimp’s flight characteristics.
Finally, we noticed deadband values that we needed to get rid of. Basically, I need to bring the motor’s thrust up to 10% before they start spinning at all, and therefore any logic that’s operating in the 0 to 10% range of motor output is accomplishing nothing. In pragmatic terms this is just adding to the sluggish behavior of the aircraft that we needed to get rid of. So, we changed the interpolation range of motor output to operate between 10% and 100% of motor output. This was surely a good change.
What Did Not Go Well
Absence of a PID Controller
During much of the process of developing this autopilot, I’ve had a few people on the streets mention to me, “oh that’s really cool, did you have trouble fine tuning your PID values?” And I’m all, “what’s a PID value?” And they’re all, “oh…uh…nevermind, I’m sure your aircraft will fly just fine.” And then they vanish into the night.
It turns out that PID controllers are quite important, and I knew nothing about them until recently. I have a bunch of fairly complicated logic to determine output thrust values, but it turns out that the problem I had set out to solve already has a canonical solution by using a generic PID controller. The idea, in short, is that a PID controller is meant to solve the problem of how much output should be applied to make my sensor inputs match a target value (i.e., I need to apply some unknown force in order to reach a target velocity). The thing that clarified this for me was understanding that a PID controller is not something specific to a quadcopter or even an aircraft, but it’s an abstract concept in control theory. The absence of a PID controller is quite obvious if you review my flight footage. You might notice that the blimp’s velocity oscillates a decent bit. Apparently it’s impossible to eliminate the oscillation completely, so the simple fact that it exists is a sign of progress, but a PID controller’s effect is that it will dampen the oscillation to nearly 0 error. So I’ll probably re-implement my thrust control algorithm, and hopefully we’ll end up with a dramatically more stable aircraft next flight.
Tuning Flight Settings
If you check out the flight footage, you’ll also notice that the blimp ended up having to double back a few times in order to “reach” a waypoint. I can make this a non-issue by tuning some constants I have defined so that the acceptable reach distance of a waypoint is increased so I can loosen the accuracy requirement.
In the same way, I can fine tune a few other coefficients that determine flight behavior.
Right now I’m using an XBee Pro to provide a point to point wireless serial connection. It’s advertised to still work without direct line of sight, but my flight tests clearly show that this isn’t necessarily the case. This isn’t a problem per se because the aircraft should still be able to operate and navigate existing waypoints without a solid connection. In the flight video, you can see that in the event of lost communication, the blimp will cut power to its motors and pitch down. So this surfaces 2 changes I need to make:
Probably the most obvious change I need to make is that I need to continue navigating waypoints in the event of lost communications or at least return to home. My initial thought process here was that we wanted to optimize for not losing the aircraft in the first place, so I didn’t want a worst case scenario where my autopilot was incorrectly flying the blimp upward, we lose communications, and the blimp flies off into the night and lands somewhere in Africa after it runs out of battery. This wasn’t necessarily an incorrect behavior because up to this point I haven’t even validated that the flight controller works, so it was really a problem that I’d intended to defer on from the get-go.
The second change I’d like to make is to actually control the blimp over the internets. Interestingly, in the course of working on this project, new hardware has hit the streets that would trivialize this problem. Internet control would eliminate range as a problem (in practical terms), and it would dramatically increase the throughput of data I could send to and from the blimp. This isn’t a problem yet, but it does enable some interesting projects (i.e. broadcast a video feed to or from the blimp).