The Up Front Video
True Story Follows
So I’ve been spending some time on the weekends over the past few months working on an autopilot blimp module. You can some of my earlier attempts that demonstrate a work in progress, and since then I’ve actually conducted two other different flight tests. I ended up not directly blogging about the previous two flight tests because on the surface they actually looked worse than the first attempt, but behind the scenes and in the abstract, the failed tests were actually progressive steps to where I am now. To boil it down, here’s my lessons learned distilled:
- Flight 1: yawing to waypoints works correctly, discovered a few obvious bugs, thrust control needed a complete re-work
- Flight 2: bugs fixed, new thrust control fails miserably as I learn the hard way that my sensor input is nowhere near accurate or timely enough, I need to merge my GPS and accelerometer inputs to get better position and velocity values
- Flight 3: Oh, I computed my rotation matrix incorrectly. I need to fix that. Also, I didn’t know I could get velocity directly from the GPS
- Flight 4: Here we are now. Things work. Sort of.
Not presented was my blimp’s attempt at hovering. An imperfect downward angle created reverse thrust that was amplified by an attempt to pitch up, which resulted in downward pitch because of the reverse velocity. Initially I thought it was going to be back to the drawing board, but after a few seconds of recovery I learned that my “hover” was good enough to be a “sort of stay in one general area” sort of feature.
The real problem then is the hardcore reverse velocity, which I’ll need to dig into more, but my current theory is that some of the safety thresholds I have in place to avoid random jittering that directly correlate with noisy sensor inputs need to be removed. For example, as it stands, the blimp will view acceleration values within some range of actual target acceleration are actually acceptable. But as a result, no corrections happen for a case like this.
Improved Waypoint Navigation
On the verge of packing up and going home, we went ahead and did a waypoint navigation test. The bottles of champagne that we had at the ready in case of success had already been stowed. The intent, of course, was to conduct a dramatically successful test flight and then slam the champaign bottles against the blimp, give a few high fives, and then drive around the area in our cars and peel out at every possible opportunity. Nevertheless, we attempted waypoint navigation.
Surprisingly at this point, things mostly worked, with the exception of some obvious misbehavior on part of the blimp algorithm’s decisions. But, the blimp was successfully navigating waypoints, however imperfectly.
The largest problem appears to be that thrust control is completely decoupled from the tail elevator and even the forces generated by the airframe design. Namely, the lift generated by the blimp as a result of its own pitch and forward velocity were completely unaccounted for. As a result, upward forces were applied to reach a target altitude while the tail elevator was simultaneously directing the blimp to pitch up. Now the blimp was generating too much upward force while the forward momentum was significantly dampened. From here the blimp would correct itself and level off, but now the problem was bound to be re-introduced as the blimp needed to lower itself from an altitude that at this point was too high.
The first conclusion I reached was to apply metaphorical duct tape; if the blimp’s pitch has reached some maximum pitch and its angular velocity is continuing to pitch up, I should no longer apply any upward force from the motors, and I should even dampen the upward force. In theory then, this would cause the blimp to operate within reasonable bounds that wouldn’t create over-corrective reactions.
But, more fundamentally, the problem was that the tail elevator and the thrust vector should work in conjunction with each other. It is far more efficient to maintain a thrust vector parallel to the blimp’s direction of travel when possible, and only manipulate the thrust vector when the elevators have maxed out their range of motion. This insight was the direct formulation of Larry, the blimp man. The current algorithm I came up with to influence thrust was based on a problem in the first flight where power to the motors was cut off because a target forward velocity had already been reached, and as a result the tail rudder and elevators may no longer apply sufficient pitch or yaw force because the velocity may be too low. This can be addressed with a simple minimum threshold for forward force.