Simulink Based Autopilot

[Felthamg]

Hey Everyone,

I've been frequenting this site lately because I've become very interested in UAV autopilots. I'm working on full-blown simulations for a Boeing 747 using MATLABS Simulink software and I've been looking into using Simulink as the basis for a UAV autopilot. I can code but it seems to me that Simulink would be a lot nicer for higher level design.

I've come across a few articles about using Simulink for UAV autopilots but most of them are 5-6 pages AIAA.pdf's from a master students work.

Does anyone know of any Simulink based autopilots that I could look at? When I finally get my project started I'll be sure to make a build log so everyone here can enjoy the fruits of my labor.

thanks everyone

-Graham

[matttay]

I think it depends how far you want to take it. If you just want a few PID loops then simulink is probably a really good way to start. If you want to add in GPS, navigating between waypoints, maps, etc, then you've quickly stepped out of simulink's area of expertise, and you'll have your hands tied compared to general purpose language.

I've built a desktop autopilot in c# using 64-bit doubles for everything. I built a PID class in about 40 lines of code, and a generic class for filtering floats (and GPS coords). Those both get used a lot.

I've attached the source of the autopilot and waypoint sequencer in c# if you are interested. It's probably just 250 lines of (non commented) code though it relies on a range of other libs I've written. It's part of a larger effort that hooks into FlightGear for verification, and I'm porting it to a PDA that lives in my airplane to control things.

[Felthamg]

Thank you Mattay,

I was wondering how to deal with GPS and such in Simulink. A bunch more questions come to mind though. You said you wrote a simple PID loop in C, how do you adjust the gains? The cool thing about simulink is that you can connect the PID blocks to a full 6dof simulation of the aircraft for PID tuning. Another thing I was thinking about is incorperating adaptive gain. I'm sure this is all possible in C but it really helps to "see" everything connected and Simulink is really good at that.

I've come across "kalman filters" alot in my reading with regards to signal interpretation. Did you write a kalman filter in C? I know Simulink comes with a Kalman filter block ready to use.

Another one of my problems is that I'm not an electrical engineer, so device interfacing (GPS/Interial etc) is difficult, neither am I a computer engineer so the detailed code sometimes gets me stuck. The biggest problem for me is finding a place to start. If I were to code this from scratch in C or C++ is there a good place to start? (besides C or C++ turtorials, I am familiar with these languages).

thanks!

[CrapouilloO]

Hi Felthamg ! (sorry I don't speak English very well)

For my ending study project I did my own XUFO/quadricopter. It's not totally an UAV project but nearly b/c it shall stabilize by himself w/o moving. The flying platform contains all sensors (gyro, acc, ..), actuators (4 motors) and 2 microcontrolers (dsPIC). Micro shall read sensors and send to PC (currently with UART/RS232). PC shall compute the stabilization and send the PWM values to drive motors. I want two feedback loops : - the first at 1KHz for observing and controling motor currents; - the second at 50Hz for stabilizing the platform.

I do not use Simulink but I use Scicos (which does the same thing but in free). My XUFO is still in progress (not finished !). But I can tell you that you can only make feedback loop in Scicos at 50Hz with a low/old PC with RS232 (a friend of mine succeeded at 300Hz in another kind of project with USB). 50Hz is very few to make a good feedback loop for motor currents, you will never be able to control perfectly with a PC (for ie. b/c communication delays). This job must be done by microncontrolers. 50Hz is enough sufficient to control the platform in real time (I think a human when controlling his own RC helicopter must work at this speed, doesn't he ?).

My Scicos regulator application is mainly constituted of PIDs. This is fast enough to compute for 50Hz real time processes with a PC. And because it is not obvious to determine PID coefficients for motors directly in the microncontroler (black box), I made in Scicos the 2 feedback loops, I observe the plots in scopes and I change coef values (I hope that these coefs will work when embedded). For the motor current loop, I will automatically generate C code for my microcontrolers thanks the SynDEx (free) software. SynDEx is a software ables to get in input a Scicos schema blocks (version 4.0 only) and a definition of the archietcture (here: 2 dsPIC that communicate together (w/o the PC)). SynDEx will find the blocks that can be computed in a parallel way and when need to communicate to send/recevive data. In output it generates pseudo code for each microncontroler. You have to translate this pseudo code in C or assembly language. You have to discrete signals. You can google "dsPIC simulink" for alternative ways

With Scicos you can build new blocks. I did mine like read/write in serial port for PC/dsPIC communication (I have not GPS), USB joystick or FireWire camera.

In conclusion it's great to build real time regulator applications with a such great GUI like Simulink/Scicos (with scopes). But it is very low (it's depends on what you define 'real time': 50Hz vs 1KHz) and generated code can be too big for microncontrolers but with SynDEx you can decreases the size and parallelize the regulator algorithm.

[matttay]

Thank you Mattay,

I was wondering how to deal with GPS and such in Simulink. A bunch more questions come to mind though. You said you wrote a simple PID loop in C, how do you adjust the gains? The cool thing about simulink is that you can connect the PID blocks to a full 6dof simulation of the aircraft for PID tuning. Another thing I was thinking about is incorperating adaptive gain. I'm sure this is all possible in C but it really helps to "see" everything connected and Simulink is really good at that.

I've come across "kalman filters" alot in my reading with regards to signal interpretation. Did you write a kalman filter in C? I know Simulink comes with a Kalman filter block ready to use.

Another one of my problems is that I'm not an electrical engineer, so device interfacing (GPS/Interial etc) is difficult, neither am I a computer engineer so the detailed code sometimes gets me stuck. The biggest problem for me is finding a place to start. If I were to code this from scratch in C or C++ is there a good place to start? (besides C or C++ turtorials, I am familiar with these languages).

thanks!

Per your PM, the PID code is attached. Note this is in c#...the meat of what you want to see is the function called Update:


public double Update(double setPoint, double actualPosition)
{
double drive, error, dError, pTerm, iTerm, dTerm;

error = setPoint - actualPosition;
IError += error;

pTerm = error * pGain;
iTerm = IError * iGain;
dTerm = dGain * (error - LastError);

if (iTerm > iMax)
iTerm = iMax;
if (iTerm < -iMax)
iTerm = -iMax;

drive = pTerm + iTerm + dTerm;

if (drive > DriveLimit)
drive = DriveLimit;
if (drive < -DriveLimit)
drive = -DriveLimit;

LastError = error;

return drive;

}

The way this code is called is somethign like:

altitude = ReadAltitudeADC();
drive = Update(desiredAltitude, altitude);

If you look in the autopilot code, you see the PID is instantiated for the Altitude, Pitch, Heading, Roll and CrossTrack. Each of these use the same PID code. The values for the PID are part of the declaration of the PID:

static public PID AltPID = new PID(0.0035, 0.007, 0, 0.2, 0.02);

The above creates the altitude PID with gains for P,I and D of 0.0035, 0.007 and 0. The 0.2 is a clamp to ensure the output of the PID never goes outside of +/- 0.2, and the 0.02 is a limit to the integrator to help prevent wind up.

If I wanted to change the P gain on the fly, for example, you'd call:

AltPID.Adjust(0.001);

You mentioned cycling through a set of different gains to see the response. The easiest way to achieve this would be to start a new thread that adjusted the altitude set point and altitude gain every minute.

void AdjustAltGainPID()
{
for (int i=0; i<10; i++)
{
AltPID.Adjust( 0.1 + i/10);
HoldAlt = 50 + i * 10;
System.Threading.Thread.Sleep(60000);
}
}

Every minute (60K milliseconds) this thread would change the gain of the AltPID (from 0.1, 0.2, 0.3, etc) and also change the setpoint of the autopilot hold altitude, from 50, to 60, to 70, etc.

Inside the Autopilot code you see a function called Update which is called every 100 mS. Inside there is the code:

ElevatorHistory.Add(AltPID.Update(HoldAlt, Sensors.Altitude) + PitchGyroPID.Update(pitchAngle, Sensors.PitchAngle) + Ail2ElevGain * Math.Abs(bankAngle) / 150);
cs.ElevatorDrive = ElevGain * ElevatorHistory.AverageOverLast(3);

Here we see the various PIDs summed together to arrive at a value for the elevator (altitude from pressure sensor, the pitch gyro and a bit based on the bank angle). That sum is then stuck in a short 16 sample HISTORY of elevator samples. The elevator is then averaged over the last 3 samples.

You asked about Kalman. I haven't seen a need for it yet on planes that can be flown by humans. I suspect there is a class of inherently UNstable airframes that do need it, but that's not what I'm after.

As to where to start, it depends on what part is interesting to you. Do you love to tinker and learn the details or do you just want to fly courses? If the latter, then buy something off-the-shelf. These things are a huge time sink. If the former, then keep the scope small and reasonable at first. Focus on level flight. Then a controlled bank. Then a controlled heading. I think too many jump with every single optimization that they can think off, and a year later they find themselves still screwing around with level shifter circuits.

You can track my efforts and approach in the link below. I really am impressed with the way c# has worked on a PDA. There's some detailed timing analysis in a post that can verify that. Try c#, it's an amazing language. And a dirt-cheap PDA is an amazing computing platform. 500 MHz CPU, QVGA display, radio, GPS, acclerometer, 100 grams...and you can find them for $150 often on ebay. Next year's PDA will have gyros, 800 MHz CPUs, floating point, 3.6Mbps radios.

http://www.rcgroups.com/forums/showthread.php?t=843174

[Felthamg]

Thanks Mattay, this is really helping me. Naturally I have more questions.

I went through your code for your alittude hold. I'm currently developing my own alititude hold code. I have a few reference textbooks on altitude hold here, most of them use laplace transforms to analyze the PID control and aircraft response however the basic concepts of control are still the same. I've noticed a large difference in your method of height control than that presented in most of the books i've seen. I put together two pictures (in paint, so they are not superb) on the two methods; yours and the one I am considering.

Your method:

second picture attached.

The method I am considering:

first picture attached.

In your method you apply PID control to both the pitch angle and the altitude. The drives from both these PID controls are added along with a correction for bank angle and that results in your elevator drive. This implies knowledge of both wanted height AND wanted pitch angle.

In the other method only the wanted height must be specified. The error in height is then converted into an appropriate pitch angle that acts to correct this height error, the conversion equation is determined from the equations of motion. A PID control is applied to the pitch angle and the result is the elevator drive.

I find this method to be more intuitive, only a knowledge of wanted height must be specified and then the control system figures out the appropriate pitch angle and the PID loop keeps the pitch angle constant. With your method you need to specify the pitch angle, but how do you specify this? Furthermore, i dont see how adding the drive from the height and pitch results in the elevator drive.

I understand that speed control is also important in a full altitude control system, however that is not under discussion here.

as reference, the method I have been discussing is presented in Bernard Etkin's book "Dynamics of Flight: Stability and Control".

[Felthamg]

A thought just came to me.

In my previous discussion I was considering the "cruise" portion of a flightplan, where the desired height was obtained and the aircraft was commanded to remain there and cruise along a desired heading. However, for the ascent portion of the flightplan the method I suggested would not work based on height error alone. I was going to include a seperate control system to deal with glide slope/flare and I realize now that you probably require a knowledge of the desired pitch angle to achieve this.

Did you try and combine both systems into one?

[matttay]

If you look at the few lines above the summation in the source, you'll see a section of code prefaced with the comment "define the target pitch angle"

In that section, you see the pitch angle is clamped at +/7 degrees, and is a function of the altitude error. So, even though it looks parallel in the summation, it's a bit more like the serial drawing when you consider the pitch angle is derived from alt error. Thus, the actually drawing is a third picture where the alt PID can drive the elevator directly and yet still influence the pitch.

Note that at 15 m/s cruise, the +/-7 degree clamp is about a 110 m/minute rise or sink rate. Independently, the alt error can additionally influence that. Not sure if that's a good thing, I'll think about that some more.

I tried really hard to base the altitude just on the pressure sensor. No luck. The airplane would start porpoising, yet when I looked through the logs the barometric altitude showed very minor variation--almost level flight. So I spent a fair bit of time thinking there was a bug, and dumping more and more log info, only to realize that if I'd looked at the gyro on the first flight that I would have seen the same behavior and would have realized it was critical to level flight.

Do you run windows? You can download a free version of MS Visual Studio Express Edition that shoudl be able to buidl the desktop version of the autopilot, and combined with flight gear simulator (also free), you can tweak as much as you want. Let me know and I'll clean some stuff up. The flight gear simulator was written by a guy whos often on (COlson), and it would let you readily try autopilot strategies for everything from 747s down to RC.

[Felthamg]

That would be super Matttay,

I have visual studio 2005 and 2008, haven't installed them yet. Would you recommend either one? If you could send me that stuff I would really appreciate it.

Looking at your code is helpful but without all the libraries,headerfiles, and other code its sometimes frustrating to piece together how someone has done something. I'm reserved from asking you for your entire project code. I dont want to seem like I'm stealing it, i just really really want to learn from it. My friend let me see his new HTC touch and the method you are proposing seems to make more sense to me day by day.

I plan to start a build log or update my work on my website I'm developing and would be happy to share anything with you along the way.

thanks again.

[matttay]

Install visual studio 2008. You will be amazed with intellisense how much clearer everything becomes when you can hover over lines of code and see comments.

If you send me your email via PM, I'll get something to you by end of weekend.

The HTC Touch Diamond has accelerometers, and I've written code to check the bandwidth and it's workable. Other PDAs have 3D compass. Can't wait till they arrive together. I haven't flown my touch diamond yet, but at 100g, it's quite a drop from my current 200g PDA.

[Felthamg]

Hey Matttay,

I would PM you these questions (that appear unrelated to the discussion topic of simulink) however I think its better if we do it here so that all can learn.

I have some questions now about your method for the lateral autopilot (having covered the longitudinal autopilot in my last post with accompanied diagrams).

Again I have a reference method to compare (from the same book as before).

In your method you are using the ailerons to control the heading. The method you use to compute the ailerondrive is a sum of the PID drive's from the bank angle error and the heading error (first picture attached). The bank error is calculated from the heading error.

In my refrenence method the heading error (as a yaw angle) is first computed. This is converted to a desired bank angle, the bank angle error is then converted to a desired roll rate, the error of the roll rate is applied to a PID control and the output of this is the aileron drive. However, this is not the entire lateral control but only half of it. The other portion of the lateral control consists of a yaw damper that controls the rudder (damps out dutch roll). Note: all the "conversions" in the diagram are mathematical expressions derived from the equations of motion.

my questions:

1. How did you determine your method for computing ailerondrive? is it experimental or did you derive it analytically?

2. when computing the desired bank angle you multiply the heading error by 0.3, how did you determine this value?

3. I cannot find any rudder control in your autopilot (or maybe I'm just blind or you named it something different). Without rudder control how did you damp the dutch roll mode (or is it even important?).

4. how did you incorperate coordination in your turns? I've read a total of 4 methods, the simpliest probably being the use of sideslip feedback.

thanks!

[matttay]

All good questions.

Note in the source I use the following terminology, which might not be standard (I tried). To me, Bearing is the direction you want to be going, and Heading is the direction you are going. Heading is always expressed absolutely, from 0..360. Bearing is always expressed relative to your current path. So, if you determine your bearing is -10 degrees, then that means you want to turn left.

How much you turn left is a function of your cross track error. Cross track error is a measure from your desired path. I convert cross track error to an adjustment of the bearing. If I'm to the right of my desire path, the I change my bearing target to aim a bit left of the target. As you can see, this is reflected in the xtrackHeadingAdjust var and it's clamped to +/- 10 degrees. Note that without cross track error, you tend to always approach your waypoint from teh downwind direction. Cross track keeps you approaching from teh expected direction even on long treks in higher wind.

Once we know our bearing, then we just have to decide how much we want to roll to reach that bearing. That decision is made in the targetBankAngle calculation. It's a linear adjustment off of our bearing. So, roughly, if our bearing is - 3 degrees, (that is, we want to turn left just a bit), then the target bank angle is about 0.3 * 3 = 0.9 degrees. This has been determined emperically. The cool thing is that you can try it in big planes and little planes in the simulator and see if it matters.

Note in the PID constants, the heading PID P value is 0.001, and the roll PID value is 0.05, so effectively the aileron PID is determined almost exclusively by roll. And the roll is a function of our current and desired roll.

The attached drawing hopefully makes this clearer. Consider example 1, where we are on our desired path. Heading is about 10 degrees (and is determined by our location one second ago), and our bearing is 0. In other words, we're happy with current heading. (note heading can only be determined every second due to the GPS rate, but in the Sensors source the rate of turn is used to estimate the position every 100 mS. You can see the green dots in the jpg I posted in the other thread and you'll see the estimates are pretty darn good).

In example #2, we have a small cross track error, so we adjust our bearing to aim a bit left of the waypoint.

In example #3, we have a larger cross track error, so we adjust our bearing to aim much more left of the waypoint.

I don't worry about coordination. My easystar only has a rudder, but I treat it as aileron. When you "ride along" and watch the autopilot control the flight simulator (for which I do drive the ailerons), it doesn't look at all odd the motions that it's going through as you watch out the window. My understanding is that coordination is something humans like to feel when riding in an airplane. But without human riders...

[matttay]

By the way, I took another look at the elevator loop and here's what I ended up with:

// Define the target pitch angle
double targetPitchAngle = (HoldAlt - Sensors.Altitude_m) / 10;
if (targetPitchAngle > 7)
targetPitchAngle = 7;
else if (targetPitchAngle < -7)
targetPitchAngle = -7;

// Compute elevator position
ElevatorHistory.Add( PitchGyroPID.Update(targetPitchAngle, Sensors.PitchAngle_deg) + (1-Math.Cos(Sensors.BankAngle_deg * Math.PI/180)));
cs.ElevatorDrive = ElevGain * ElevatorHistory.AverageOverLast(3);

This is more in line with your serial drawing in that there's no alt error term directly driving elevator. The alt error drive pitch.

I also changed the feedforward on the elevator adjustment based on bank. It was a linear function of bank. It's now a function of the cosine of the bank angle.

So, now a 10 degree bank kicks in about 0.02 to the elevator, and a 45 degree bank kicks in about 0.30. It's a more violent turn, that's for sure, the alt loss is much improved in the sim.

[brnjones]

You could use Simulink with the xPC or other embedded targets. Check out the lower right hand corner.

http://www.mathworks.com/products/product_listing/index.html

I dont have any experience using these, but I was looking into them with similar desires for using simulink to build an autopilot. I think using these DSP targets would be adequate for RC autopilots, but it looks expensive...

[Felthamg]

Matttay,

after looking at your new elevator control (picture attached to visualize it) I agree that it resembles my intial system much more closely and makes a whole lot more sense.

However, there are still questions that I hope you have answers to.

I was wondering why the elevator drive was partially a function of the bank angle so I did a bit of analysis with some force diagrams. It appears that there are two distinct methods of altitude hold during a bank(turn). Elevator or Speed control.

During a bank, the vertical lift is decreased and the aircraft develops a vertical velocity (downward) to increase the angle of attack of the wings, thus increasing the total lift and balancing the vertical forces once again. However, now the aircraft has a vertical velocity downward and therefore loses altitude. You can correct this by deflecting the elevator, causing the aircraft to pitch up (increasing AoA of wings = increase lift) OR by increasing the airspeed (increasing thrust, increases airspeed, increases lift through dynamic pressure). All good thus far.

HOWEVER,

If you look at your method for determing elevator drive you've obviously opted for elevator control over speed control for altitude hold. There is just one problem. Lets say your aircraft is at your desired altitude, so alt error is zero and the portion of elevator drive that's computed from altitude error is zero. Lets also say your aircraft is in level flight and the pitch angle is zero. Now, you enter a bank and deflect the elevator to compensate (remember this causes the aircraft to pitch up). But there is no altitude error so that part of the control system wants the pitch angle to remain zero , but the aircraft has pitched! there is now an error in pitch angle and the aircraft attempts to deflect the elevator in the opposite direction to pitch DOWN the aircraft.

All in all, the two components of elevator drive fight each other during a bank (turn). How did you overcome this? which component is more important? Why not just use speed control for altitude hold during a bank and this whole problem would dissapear?

I am unsure how large your altitude errors are during a turn (in simulation) but this may be a factor causing the errors. Perhaps disabling the altitude error branch during a turn and then re-enabling during level flight would improve the situation.

[Felthamg]

This post is unrelated to my last one but is related to our discussion on your methods for lateral control (ailerondrive).

First of all, thank you for your explanation of cross track error, bearing, heading and how that all factors into your lateral control.

I'm rechecking your method of calculating ailerondrive and there is still one thing bugging me.

with reference to my drawing before on how you calculate ailerondrive, it is calculated by a summation of pure bearing error (PID) and bank angle (or roll rate , I'm not sure which) error (PID).

Both of these components that contribute to ailerondrive are calculated from bearing. The required bank angle (or roll rate) is calcuated directly from bearing by:

bank angle = 0.3*bearing

and the other component is just bearing itself. Both of these factor in cross track error.

My problem is that I dont see the difference between these two components, they both rely solely on bearing to calculate an ailerondrive. Why not just lump these two together with modified constants? It seems redundant to include the same effect twice.

(oh, and please let me know if its bank angle or roll rate that you are measuring and comparing to).

thanks.

[matttay]

Re: elevator

The turns are very sharp, and of short duration, so throttle compensation isn't practical.

A ~35 degree turn will cause the wings to loose ~20% of their lift. Since you know that will happen, why not pre-compensate and nudge the elevator up a bit? Especially if it gives you a better response?

In the attached plot, there are 3 traces, at differing levels of coupling between the bank angle and elevator. In the 0.05 case, there is minimal coupling. You'll note the blue alt drops almost 30 meters.

In the case of the gain = 2, you'll note we zoom upwards about 30 meters. In other words, too much coupling.

In the case of gain = 1, you'll note a very modest drop in altitude. So it is indeed beneficial.

One other way to address this is to crank the D gain to help the loop fight any disturbances. However, there's an upper bound on the D, and that is set by the noise in the gyro and altimeter. If you crank that too high, then the servos spend their time creaking and ticking and raising the current drain (and getting warm). So there are good reasons for keeping D dialed down.

[matttay]

(oh, and please let me know if its bank angle or roll rate that you are measuring and comparing to).

thanks.

I've revised the diagram again, and made some simplifications and additions. We shoudl discuss from this version to ensure we're discussion current info.

[Felthamg]

Re: elevator

The turns are very sharp, and of short duration, so throttle compensation isn't practical.

A ~35 degree turn will cause the wings to loose ~20% of their lift. Since you know that will happen, why not pre-compensate and nudge the elevator up a bit? Especially if it gives you a better response?

...

In the case of gain = 1, you'll note a very modest drop in altitude. So it is indeed beneficial.



I've been analyzing your graph of the aircraft response for Ail2Elev=1. The results are promising. I expected the altitude error and bank angle control branches to fight each other for the control of the elevator, but in this implementation they compliment each other due to the initial loss of altitude right after banking.

I have some concerns and some ideas.

1. The aircraft banks to ~40deg quickly and because the elevator response lags the aircraft drops 10meters suddenly. I've been thinking of methods to remove this sudden drop in altitude.

In your implementation you use the sensor bank readings to "compensate" for the turning maneuver by deflecting the elevator. However, if you were to use the desired bank angle as determined by the autopilot instead you could "feed forward" the virtual bank angle before it occurs. I've drawn the implementation in the drawing you have provided of your autopilot. You command the lateral autopilot to bank to a desired angle of 40 degrees, the lateral control loop will do its thing, deflecting the ailerons and achieving this goal. By using the bank angle sensors you are adding a time lag to the longitudinal autopilot, the actual bank has to occur before the longitudinal autopilot controlling the elevator reacts. However you already "know" that you are going to bank beforehand, before the lateral autopilot starts deflecting the ailerons. Why not use this prior knowledge to remove the time lag from the longitudinal autopilot controlling the elevators. I'm unsure of the response, the aircraft might pitch up too soon, or perhaps the elevator deflection will coincide nicely with the banking, removing the initial 10meter drop in altitude. I am curious to see the results!

The only problem will this implementation is that NOW the altitude error and bank angle branches will fight for elevator control. Because there is no initial loss in altitude the altitude error branch wants the pitch to remain zero (or constant at some value). Because the aircraft is banking this branch will want the pitch to remain at some different value (pitch up).

the only way I can think of to solve this is disabling the altitude error branch during turning maneuvers.

If this makes any sense I am really curious to see the response to this implementation, perhaps if you could modify your autopilot slightly and run the same simulation as before with the resultant graphs. If this does not make sense, please point out the flaws !

thanks!

(oh btw, your revised autopilot makes a lot more sense to me, looks great!)

[jlcortex]

Hi,

i can see you are no controling thrust,

I have making some similar testing with matlab-flighgear (connected by UDP also)

each of my waypoint have position (lat and long) altitude and airspeed, so i am controling throttle also, my experience is than to control elevator and throttle at the same time is very critical due pids oscilations but it seems to work ok with a bit of tuning, my system is very critical because i am testing it with 6x time aceleration and only 30 hz for control loops, is is only 5 hz in "simulation time" for all controlled variables.


i am not working in my matlab autopilot since 2 weeks but my last goal was to land in the center of the track, it is very easy in "manual" mode but very dificult for my autopilot!!!


I have test two modes:

THROTTLE CONTROL BASED ON ALTITUDE:

elevator = PID (measured_pitch - target_pitch) / target_pitch = PID (measured_airspeed - target_airspeed)
throttle = PID (measured_altitude - target_altitude)

problems observed: poor control of altitude during approach but very smooth flying

THROTTLE CONTROL BASED ON AIRSPEED:

elevator = PID (measured_pitch - target_pitch) / target_pitch = PID (measured_altitude - target_altitude)
throttle = PID (measured_airspeed - target_airspeed)

problems observed: too much speed during approach, autopilot try to tracking a descendent line and it make the airplane to get a lot of speed.
a lot of oscilations problems with pids at high speed due not linear behavior of airplane-controls.

I have been testing a control based on potencial energy (altitude+airspeed) but no conclusion about this


other problems observed: in my tests, Autopilot used to give a bit of throttle to control altitude target, in my 5 hz control loop is is fatal due engine torque, it could be interesting to implement a torque compensation.

Jose Luis
i attach my matlab autopilot: http://www.nmine.com/uav/flightgear-matlab.htm