Re: [Flightgear-devel] Re: OT: FYI, mac os x developers,
On 11/12/05, Arthur Wiebe [EMAIL PROTECTED] wrote: Yeah, oops what's wrong with topposting? ;) Ok, I'm sorry to extend a very off-topic discussion, but here I go anyway... This one is a little lost on me. I understand why quoting whole messages, and using HTML or various encoding schemes can be a nuisance, but to me it is easier to write and read replies at the top of the old message. I suppose if you are looking back in an archive, it might make more sense to read oldest to newest from top to bottom. But that seems like a pretty easy adjustment. So what is the argument here against topposting? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] PropertyList over network
Hello All, I am considering using a property tree similar to that in Flightgear for a UAV ground control application, and I have a question for the developers on the list. Has anyone ever looked into creating a system to share a common property tree between two computers over a network connection? E.g. when a property is changed at one end it is updated at the other end as well. Do you think that this could be done efficiently? Has anyone written code to do it? Thanks, -Jeff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear as a real time synthetic view
On 10/29/05, Curtis L. Olson [EMAIL PROTECTED] wrote: There is a neat flightgear connection here which I've probably mentioned before, but would like to mention again (with pictures.) http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ This is a manually flown UAV (also pictured on the same page.) It has an onboard camera angled 45 degrees down. It also has a gps/imu sending data to the ground via a radio modem, so we can feed that into flightgear and show a live synthetic view from the aircraft perspective. We can angle the flightgear view 45 degrees down and it matches pretty darn close with the real camera view. We had a guy create a small chunk of photo real scenery for the area so it's really neat to see the synthetic and video views match tree for tree, road for road, building for building. Regards, Curt. The synthetic view looks nice. How hard was it to set that up in flight gear? -Jeff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug
The patch committed by Erik: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19r2=1.20cvsroot=FlightGear-0.9 should fix this. This is what would happen when you set delta_u_n = u_max - u_n_1 : delta_u_n (u_max - u_n_1) 0.6 (0.5 - 0.0) : true delta_u_n = u_max - u_n_1 = 0.5 - 0.0 = 0.5 u_n = u_n_1 + delta_u_n = 0.0 + 0.5 = 0.5 and at the next time step let's assume that delta_u_n But consider this scenario for next step: Assume Kp = 1. This means that the previous error e_n_1 = 0.6. Say the new error e_n = 0.5. delta_u_n = Kp(e_n - e_n_1) = -0.1 Now, this new delta when aplied to the saturated output will be: u_n = 0.5 - 0.1 = 0.4 ; The correct proportional component of the output should be 0.5 In the ideal scenario, the delta_u_n = -0.1 would be applied to u_n=0.6 to yield 0.5, but because of the saturation, the P component becomes offset. This offset will be compensated for by the I component after some time, but it shouldn't have to be. As I said before, I think the best solution is to track the true PID output (in this case 0.6) while outputing the saturated value and disable the integral component (with either a hard or soft limit) when the controller is saturated. Hans-Georg's suggested scaling of ep_n essentially fixes the problem. The one technical problem I have come to see with this approach is that it assumes that the entire output movement into saturation is due to the P part: ep_n = ep_n*u_max/(delta_u_n+u_n) This says that, for example, if the output only moved by half of the calculated increase because of saturation, we should change the current proportional position (saved in ep_n_1)to half its calculated value. This basically works because any large movements in one step are likely to be dominated by P, and in most (if not all) cases the error generated when the output moves back out of saturation is small and quickly compensated by the I part. I believe this is why the output of his latest test run using his fix returns to 0.0019 or 0.00175 after the reference is returned to 0, rather than returning to exactly u_n=0. Clearly this error is small and will not represent a proplem in this case. -Jeff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
See below... On 9/28/05, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: On Wednesday 28 September 2005 21:03, Hans-Georg Wunder wrote: The original problem is, when there is an input change from 0 to u_max/kp, the output value is zero. This is wrong. It has to be u_max. The fix from Erik was also my first approach. But it does not solve the problem. Under some circumstances the controller stays in saturation for ever. If you tune the PID controller to be a P only controller (Ti=inf, Td=0) then this can happen because of steady state error that can not be reduced by a P only controller. Maybe I did not stress this enough in my last post on this subject: But in some cases, such as when Kp*e is greater than u_max-u_n, the output is not changed. It isn't that the proportional output is not enough to get rid of the error, it is that the proportional output is being ignored because it would put the output past the user set limit. The correct behaviour should be to move the output to the user limit. The velocity form of the PID controller should _not_ be used as a P only controller! I found a site with a good explanation of the PID equation: http://bestune.50megs.com/typeABC.htm Good site! The guys at BESTune claims that the type C controller is the best. I suggest that you try setting beta = 0 to make you controllers type C. I'm sorry but I'm very sceptical to your idea of altering ep_n and ed_n on saturation. I can see your problem with it. In fact, I think it may be technically wrong because it assumes that the proportional component is the only thing contributing to the saturation of the controller. But something must be done to correctly handle saturation. One possibility would be to internally track the actual PID output when it goes past saturation (but limit the output value). This does not provide any anti-windup protection though, so some kind of anti-windup would need to be added. One method I have found referenced at several sites uses the amount of saturation as a feedback to the integral term: v_n : PID calculated output u_n : Control output (u_n = v_n except in saturation, when it equals u_max or u_min) s_n : saturation (s_n = u_n - v_n) Then the integral contribution would be I = Ki*e_n + Ks*s_n (Ks defines how tightly windup is controlled). Roy Vegard Ovesen -Jeff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
Ahh, yes. I see your point. Since the change in output is based on change in error (not current error), if the amount of output shift is altered but the last error (ep_n_1) is not the two will effectively become out of sync. In fact, the same thing must have been happening when delta_u_n was being set to 0 when saturation occurred. But, the integral component should correct for this after a little bit. I am not convinced that you need to adjust edf_n, or that you should. IMHO, there is no reason that the rate of change information cannot be used when the controller is in saturation, and there is no way for the derivative error to wind-up. But I agree with your scaling of ep_n to match the change in output. Good call. It looks like Erik did commit a patch, and it looks like it does not include your adjustment to ep_n. So, it is still broken (though, I think it may be an improvement). I don't currently have a linux box to compile FG on, and I have not tackled the problem of compiling on Visual Studio, so I am unable to test this code at the moment (though I will have a linux box for development soon!). I appreciate all the development everyone has done, as I have found FG to be a great tool for both work and play. Hopefully I can find some way to contribute myself in the near future. -Jeff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] PID Controller Bug?
I have been playing around with the autopilot this evening, and
noticed something that seems to me to be broken.
I ran into a problem where I would see a really large change in output
(delta_u_n) but the output would not change (yes, this probably also
means my gains need some adjusting), e.g.:
- From debug output ---
Updating Yaw Stabilization
input = 119.876 ref = 0.000610361
ep_n = -119.875 ep_n_1 = -118.088 e_n = -119.875 ed_n = -119.876 delta_u_n =
-2.96522
P:-0.268029 I:-2.69719 D:0
min saturation
output = 0.982904
---
So I checked the code in xmlauto.cxx and found that yes, these lines
were responsible for zeroing delta_u_n:
- From xmlauto.cxx
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout min saturation endl;
}
-
Perhaps I am not understanding this correctly (this PID controller is
not like any I have seen before), but it seems to me that it should
read:
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = u_max - u_n_1; // --- CHANGED
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = u_min - u_n_1 // -- CHANGED
if ( debug ) cout min saturation endl;
}
-Jeff
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
