Right now we have limits built into the altitude hold modules. For instance, for the C172, I don't want to command a climb if the speed is less that 70 kts. So I take the target climb rate and tail that off to zero as the speed goes down to 70. It's a hack I know, but it seems to help. Is there a better way to do that anyway given a "generic" pid algorithm? Would we want to build in hooks to the "generic" pid algorithm so we can set up these sorts of limits?
I don't think this should be part of the PID algorithm. I think we should use your hack and apply it to the setpoint to the v/s or pitch. This means that we need some sort of if ... then functionality. I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc.
As I understand it, the autothrottle predicts the airspeed 10 seconds ahead of time, and uses that as the input.
I didn't know this, but it seems to me that this strategy is something that some autopilot designer has found out that this would be a good thing. If I were to design a autothrottle, knowing nothing about past autothrottle experience, I would use the current airspeed as input.
Would the differential component of the PID algorithm be able to account for this?
That might just do the trick.
Would we want some code someplace that puts the predicted speed into the property tree for the generic pid algorithm to use, or would we want to build in some sort of property prediction ability into the pid algorithm (in case the 'd' component doesn't quite do what we want?)
I think a hack is the way to go, and if we can use Nasal to do it we can implement this hack, the one-eighty-hack and any other hack that we might need.
By the way, did you get my reply with answers and the updated PID algorithm?? I'm not sure I got through your spam-filter.
-- Roy Vegard Ovesen
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
