This past weekend I continued work with Larry Fleming, renowned as the best RC Blimp manufacturer and operator in the world, to test fly my current implementation of an autopilot for a blimp. My previous flight test is documented here There’s still some remaining work to be done to label the project as complete or even good, but we’re still taking an iterative approach and testing one change at a time. Here’s the breakdown of some of the new features implemented and what’s left to be done:
What Went Well
PID Control Implemented
In the process of writing an autopilot from scratch, I eventually stumbled upon the canonical solutions to some of the problems I’ve been facing. Namely, my implementation to apply force to reach a target velocity resulted in oscillation. This, as it turns out, is inevitable and should therefore be taken as an indicator of progress. But to then mitigate the oscillation requires a PID controller. I talked about what this is briefly in my last post, but the bigger point here is that it actually worked. If you compare the take-off / hover from this flight and compare to my last attempt at hovering, you’ll notice a much cleaner version (there’s still more cleanup to do thought).
Motor Differential for Yaw Control
In my previous post I’d mentioned that motor differentials had been implemented in order to provide yaw correction. This presents an obvious problem if the motors are vectored. When the motors are pointed downward, the differential will apply a rolling force rather than a yawing force. This by itself is still reasonable because a rolling action will help to correct the aircraft’s azimuth, but this also means that additional vertical forces are applied which will increase the aircraft’s altitude.
I addressed this by busting out the old algebra pen and starting writing all over the walls just like in “A Beautiful Mind” starring Russel Crowe. The algorithm will now constrain vertical forces to remain constant and allow for the two motors to produce the same amount of force based on their summation. For each motor, the ratio between the vertical and horizontal force also remains constant. However, the horizontal force applied in order to yaw is free to change. Therefore, we can truly take advantage of an autopilot where a computer is in control and make calculations that a human cannot.
What Did Not Go Well
The last test environment was quite windy, which was inconvenient in terms of admiring how amazing the autopilot was, but it was a great opportunity to underscore the current faults. Namely, the blimp is flying so inefficient that it cannot even overcome upstream winds. The airframe itself is fully capable of handling winds well into the 20 miles per hour range, but the autopilot is not maximizing the aircraft’s potential. As it stands the collaboration between the tail elevator and the thrust vector is not as it should be, and after reviewing the flight footage this appears to be the last remaining significant issue.
Consider the effort put forth while swimming: if you tread water with your legs and maintain a vertical posture, it becomes quite tiresome to keep your head above water. However, if you were to swim horizontally underwater, it’s little effort to ascend or descend by pitching your body appropriately. In the same way, I’m maintaining altitude with the blimp by applying vertical forces with the motor before maximizing the vertical forces I could be applying with the tail elevator, which would allow me to take advantage of the flight dynamics of the blimp. More lift is generated from the airframe than from raw vertical motor power.
The current problems with the lack of said optimized elevator control are quite clear. For starters, the vertical force I’m applying is detracting from forward force since the motor output is maxed and the thrust vector is forced down instead of parallel with the ground. This is preventing the blimp from overcoming upstream winds. The hover is also not as stable because the blimp is effectively heavier, and the thrust vector needs to work harder to try to balance the aircraft.
Just to illustrate the difference in power with the elevator raised, you might actually notice in one of the flight videos, the blimp accidentally ascended up to 37 meters in altitude before Larr-Dawg took over when I believe the target altitude was only 30 meters. During this test I’d just fixed the elevators to an upward position for hover only.
During my initial implementation of the autopilot, there were some problems I’d deferred on solving for the sake of simplicity before having the ability to conduct a flight test. One such problem was that the blimp’s target velocity is a function of the distance to the current waypoint without respect to the direction of the aircraft. So for example, if the target waypoint is 100 meters away and directly behind the blimp, the blimp will still shoot for a maximum speed even though it will make a 180 degree turn. This is obviously inefficient, especially when motor differential logic is now in effect to still power through turns. This isn’t a huge problem for waypoint navigation, but if the blimp is hovering I believe this is creating instability in the horizontal plane. The fix here is fairly simple: multiply the target forward velocity by the cosine of the angle between the current heading and the target heading.
If you’ve ever seen the movie “Blade Runner,” it’s going to be a lot like that. Get your mind right.