So, since I completed the maiden voyages of the
UCLA AIAA blimp project, I've been hard at work designing an autopilot for the UCLA AIAA Autonomous UAV project.
It was slowgoing, and it's only recently that I've made some progress. In fact, we've developed the skeleton for the prototype version of the autopilot. Demonstration images will be forthcoming as we develop the control logic and fine-tune the control systems.
IntroductionOur autopilot makes extensive use of
PID (proportional, integration, and derivative) controllers. A [haphazard] method of multiple loop closure was used to develop the control systems. PID loops were used on many of the primary aircraft state elements (e.g. yaw rate, pitch rate and angle, altitude). These loops fed into commands for the aileron, elevator, rudder, and throttle.
The autopilot was designed in Simulink with the aid of the
Aerosim Blockset. This third-party blockset for Simulink provides six-degree-of-freedom models for aircraft dynamics, including provisions for modeling the dynamics of piston engines. It also comes with demo models and programs showcasing how to use the blockset.
Current SituationCurrently, the autopilot is capable of responding to commands changing the airplane's bank angle and altitude. In other words, we are capable (in theory) of responding to commands to change heading and altitude. These are the basic elements--as far as I can tell, anyway--required to perform the waypoint navigation tasks required for the AUAV contest we are currently registered for.
Setting up Aerosim to model our airplane turned out to be quite difficult. The chief difficulty lay in the fact that there was little data for us to use to model the engine and propeller. Fortunately, a makeshift solution was provided with the software. One of the demo aircraft included with the blockset was the
Aerosonde, a UAV remarkably similar to the one we designed. The engines were of comparable size, as well. But from what I read of the design, the engine used in this aircraft was heavily modified. Thus, using the data for this engine will most definitely throw off any performance results using the Aerosim model. It was decided to use these data, however, for the purposes of enabling the design of the autopilot.
In developing the controls, I made extensive use of a set of notes from an MIT course on aircraft dynamics and controls. Jon provided those, so he has the citation. They were very helpful in understanding what I was looking to do with each control system. Implementing a prototype lateral (heading) controller proved to be rather straightforward. On the other hand, longitudinal (pitch and altitude) control turned out to be much more difficult. Given a fixed throttle, the elevator had trouble maintaining an altitude alone. I was forced to add into the altitude control system (contrary to the notes I was using) a throttle element. This allowed the control system to modify the throttle setting to a more "manageable" level at which the elevator could effectively contribute to maintaining level flight. Unfortunately, motor dynamics are slow, which causes the model to take a longer time to respond to altitude commands (compared to the heading commands).
Next, we'll think about how we can issue speed hold commands that do not conflict with the altitude control such that the airplane is destabilized. We'll also look, as mentioned earlier, at developing the control logic that will be used to generate the appropriate commands. For example, when issuing a heading change command, we may want to have the aircraft respond by going through differently sized incremental heading changes depending on how large the difference between current and desired heading is.
The responses are rather sensitive, however. We need to do some detailed analysis of the system to see where it fails. We would also like to find out its responses to some complex signals that are more representative of what we would ask it to do. Concurrently, I suppose, we will have to develop the control logic determining the commands issued to the autopilot. The end product, ideally, will be an interface for inputting a set of GPS coordinates and altitudes which will be translated into commands such that the autopilot can navigate a set of waypoints. If it works in simulation, we'll go out and test it. We're still waiting on the sensor fusion, though, so flight testing is still a long ways away.
But speaking of testing....Jon and I have both purchased an
Easy Star. I'm expecting mine--the kit version, actually--this week. Ideally, it would be a good platform on which to mount the prototyped version of our electronics and control systems. We could then go out to a large park (possibly the RC airfield in Van Nuys) and test out our integrated systems. In the end, though, we'll have to test it in the contest airplane, and that'll be a whole different ballgame. I'll need to get a better feel for the tuning of our control system before we do that.
Anyway, I'm rather proud of what we've accomplished so far. It's a whole lot more than a lot of students at UCLA ever set out to do in college. I'll be a little more relieved if we see some positive, concrete results, though. But we have some hurdles to jump before we reach that point. Building the contest plane, for example. There are some manufacturing and design problems that cropped up there...but those shall wait for another post. Wish us luck!
The airplane starts at the red circle and attempts to reach the black diamond. As you can see, it misses the waypoint and gets confused; subsequently, it begins to circle about that point in an attempt to reach it.
