I've noticed quite a lot of debate about tuning PID loops. I think I might be able to help since I've got 40 years experience designing autopilots for air vehicle flight control and navigation. I could give general advice on the best ways of using the P, I and D terms for both primary stability and navigation loops. With more info on the application aircraft I could probably come up with suggestions on which gains to use along with trial valuesI think a combination of flight trials and PC-based control system analysis is likely to produce a better result than trials alone.Any takers?
I have pre-designed various flight control PID loops and expressed the PID gains as functions of "important" stability derivatives. To apply my algorithms, I therefore need to know the stability derivatives for the relevant aircraft. If stability derivatives are already available, that would be perfect. If not, I can work from either
That's interesting. So you think you can get me close with only a detailed description and photos of the airframe? What dimensions do you need?
Flight-testing PID loops is par for the course around here. I don't think many people simulate. However, a switch to swap the airplane to full manual control is also par for the course around here, so you needn't worry about crashing people's aircraft by giving them PID values. If someone does crash with your PID help, that's pretty much on them.
Following my offer of help in tuning PID loops, Michael Smith posted a couple of very sensible questions:-
Q1. What inputs would need to be supplied by anyone wanting to take up my offer?
A1. I have pre-designed various flight control PID loops and expressed the PID gains as functions of "important" stability derivatives. To apply my algorithms, I therefore need to know the stability derivatives for the relevant aircraft. If stability derivatives are already available, that would be perfect. If not, I can work from either dimensioned 3-view drawings or 3-view photos together with information on length and span.
Q2. How dfo we keep the aircraft in one piece while performing basic tuning?
A2. I need to devote more thought to this. Obviously, if users are well-resourced and have as 6DOF model of the aircraft, they can simulation-test the PID gains. If PID loops are to be flight-tested straight out-of-the-box, I could probably work up some fail-safe test procedures. This would represent quite a lot of work but it would be worthwhile if there was enough demand.
static void update_crosstrack(void) { // Crosstrack Error
// ----------------
if (abs(wrap_180(target_bearing - crosstrack_bearing)) < 4500) { // If we are too far off or too close we don't do track following
crosstrack_error = sin(radians((target_bearing - crosstrack_bearing) / (float)100)) * (float)wp_distance; // Meters we are off track line
nav_bearing += constrain(crosstrack_error * g.crosstrack_gain, -g.crosstrack_entry_angle.get(), g.crosstrack_entry_angle.get());
nav_bearing = wrap_360(nav_bearing);
}
}
I'm using ardupilot mega. I do not believe it has a PID filter for xtrack, it merely takes the distance of the plane from the track and calculates an angle from that (for example, 1 degree per meter is the default.)
I think there was a big bug fix in the nav stuff for apm that isn't released yet. I will check out the latest code from subversion and try it.
I think in order to meet my goal of proper autonomous landing in reasonable crosswinds, I will have to do some coding myself. I don't believe there is any rudder-to-heading control in the current APM code. I also think an Xtrack PID will be required, as well as possibly some dead reckoning support for the GPS.
Currently, airspeed is estimated from throttle in APM, if there is no airspeed indicator attached. This means that if I try to glide very fast, I get some wobbliness. I assume the opposite goes for slow flight.
I might end up coding the nav stuff from the ground up. For now, I think I have to help myself.
I'd like to help but first I need to understand a bit more about your setup. Does it go something like this:-
Xtrack=>Xtrack PID=>(heading)=>Nav roll PID =>(roll)=>servo roll PID =>(aileron)?
If not, then what?
At the risk of deflecting you from your current endeavours, if your ultimate aim is autonomous landing, you presumably would like wings-level on landing in a Xwind so had you considered a X-track PID feeding a rudder from heading PID? This, of course depends on whether the rudder fron heading PID is supported.
Regarding wind estimation, my feeling is that with the right combination of disturbance rejection and integrators you shouldn't need it to null Xtrack error but I'll need to get a bit further with your setup before I can be certain.
Regarding your query about an airspeed sensor. PID gains generally vary with speed so that it would be good to have so long as the speed variation of PID gains is supported.
From my understanding, it will never fly the centerline of the runway in a crosswind without some kind of wind estimation. That wind estimation would have to come from comparing airspeed and heading (which is NOT available with only gps, you have to have airspeed and compass) to ground speed and ground track (which are available from gps.)
Is that true? Does the APM code have the capability to estimate wind?
I've yet to find a combination of nav roll PID and xtrack gain that puts my plane "on rails." When I set it to fly the length of the 1200' runway in a crosswind, it will invariably fly 10-20 meters downwind of the centerline. If I adjust the gains so that it flies closer than that, it starts weaving whenever its flying upwind and its ground speed is slow.
I don't yet have the magnetometer or airspeed sensors. Will the situation improve when I add them? I can't see a wind-estimation algorithm working well without knowing the airplane's heading or airspeed.
My current goal is to get an autonomous landing. My runway is only approximately 8-12 meters wide, and the edges aren't super-forgiving. There's usually a 2-5 knot crosswind component here.
Comments
That's interesting. So you think you can get me close with only a detailed description and photos of the airframe? What dimensions do you need?
Flight-testing PID loops is par for the course around here. I don't think many people simulate. However, a switch to swap the airplane to full manual control is also par for the course around here, so you needn't worry about crashing people's aircraft by giving them PID values. If someone does crash with your PID help, that's pretty much on them.
Following my offer of help in tuning PID loops, Michael Smith posted a couple of very sensible questions:-
Q1. What inputs would need to be supplied by anyone wanting to take up my offer?
A1. I have pre-designed various flight control PID loops and expressed the PID gains as functions of "important" stability derivatives. To apply my algorithms, I therefore need to know the stability derivatives for the relevant aircraft. If stability derivatives are already available, that would be perfect. If not, I can work from either dimensioned 3-view drawings or 3-view photos together with information on length and span.
Q2. How dfo we keep the aircraft in one piece while performing basic tuning?
A2. I need to devote more thought to this. Obviously, if users are well-resourced and have as 6DOF model of the aircraft, they can simulation-test the PID gains. If PID loops are to be flight-tested straight out-of-the-box, I could probably work up some fail-safe test procedures. This would represent quite a lot of work but it would be worthwhile if there was enough demand.
Hope all this helps a bit.....
This is what's done for crosstrack in APM:
static void update_crosstrack(void)
{
// Crosstrack Error
// ----------------
if (abs(wrap_180(target_bearing - crosstrack_bearing)) < 4500) { // If we are too far off or too close we don't do track following
crosstrack_error = sin(radians((target_bearing - crosstrack_bearing) / (float)100)) * (float)wp_distance; // Meters we are off track line
nav_bearing += constrain(crosstrack_error * g.crosstrack_gain, -g.crosstrack_entry_angle.get(), g.crosstrack_entry_angle.get());
nav_bearing = wrap_360(nav_bearing);
}
}
I'm using ardupilot mega. I do not believe it has a PID filter for xtrack, it merely takes the distance of the plane from the track and calculates an angle from that (for example, 1 degree per meter is the default.)
I think there was a big bug fix in the nav stuff for apm that isn't released yet. I will check out the latest code from subversion and try it.
I think in order to meet my goal of proper autonomous landing in reasonable crosswinds, I will have to do some coding myself. I don't believe there is any rudder-to-heading control in the current APM code. I also think an Xtrack PID will be required, as well as possibly some dead reckoning support for the GPS.
Currently, airspeed is estimated from throttle in APM, if there is no airspeed indicator attached. This means that if I try to glide very fast, I get some wobbliness. I assume the opposite goes for slow flight.
I might end up coding the nav stuff from the ground up. For now, I think I have to help myself.
Jonathan
I'd like to help but first I need to understand a bit more about your setup. Does it go something like this:-
Xtrack=>Xtrack PID=>(heading)=>Nav roll PID =>(roll)=>servo roll PID =>(aileron)?
If not, then what?
At the risk of deflecting you from your current endeavours, if your ultimate aim is autonomous landing, you presumably would like wings-level on landing in a Xwind so had you considered a X-track PID feeding a rudder from heading PID? This, of course depends on whether the rudder fron heading PID is supported.
Regarding wind estimation, my feeling is that with the right combination of disturbance rejection and integrators you shouldn't need it to null Xtrack error but I'll need to get a bit further with your setup before I can be certain.
Regarding your query about an airspeed sensor. PID gains generally vary with speed so that it would be good to have so long as the speed variation of PID gains is supported.
From my understanding, it will never fly the centerline of the runway in a crosswind without some kind of wind estimation. That wind estimation would have to come from comparing airspeed and heading (which is NOT available with only gps, you have to have airspeed and compass) to ground speed and ground track (which are available from gps.)
Is that true? Does the APM code have the capability to estimate wind?
Jonathon,
From systoms you indicate, it seems as though your inner loop may be fine (servo-loop), but your outer-loop (nav loop) is the one that needs work.
What would you suggest in this case: the quad oscillates increasingly around the loiter point:
http://diydrones.com/forum/topics/2nd-crash-on-2-0-37?commentId=705...
It's using the default ArduCopter 2.0.37 PID values. Is the P value much too high or something? I'm not sure how it can overshoot more each time.
I should also note that my plane flies great in FBW mode.
I've yet to find a combination of nav roll PID and xtrack gain that puts my plane "on rails." When I set it to fly the length of the 1200' runway in a crosswind, it will invariably fly 10-20 meters downwind of the centerline. If I adjust the gains so that it flies closer than that, it starts weaving whenever its flying upwind and its ground speed is slow.
I don't yet have the magnetometer or airspeed sensors. Will the situation improve when I add them? I can't see a wind-estimation algorithm working well without knowing the airplane's heading or airspeed.
My current goal is to get an autonomous landing. My runway is only approximately 8-12 meters wide, and the edges aren't super-forgiving. There's usually a 2-5 knot crosswind component here.
-
1
-
2
of 2 Next