Hans-Georg Wunder wrote:
Jeff McBride wrote:
The patch committed by Erik:
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19&r2=1.20&cvsroot=FlightGear-0.9
should fix this. This is what would happen when you set
delta_u_n = u_max - u_n_1 :
Jeff McBride wrote:
The patch committed by Erik:
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19&r2=1.20&cvsroot=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.
Roy Vegard Ovesen wrote:
On Thursday 29 September 2005 13:51, Hans-Georg Wunder wrote:
Time, reference,input,output
09:10:00,0,0,0
09:10:01,0.6,0,-0.4999 Jump into saturation. Thats OK.
Only a P-Part, no I-Part
09:10:02,0.6,0,-0.4999
snip!
09:10:13,0.6,0,-0.4
On Thursday 29 September 2005 13:51, Hans-Georg Wunder wrote:
> Time, reference,input,output
> 09:10:00,0,0,0
> 09:10:01,0.6,0,-0.4999 Jump into saturation. Thats OK.
> Only a P-Part, no I-Part
> 09:10:02,0.6,0,-0.4999
snip!
> 09:10:13,0.6,0,-0.4999
>
> The patch committed by Erik:
>
> http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Autopilot/xmlauto.cxx.diff?r1=1.19&r2=1.20&cvsroot=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.
I hope, this description is not to long, but I think it is very
important to have a working controller code
First the test results, at the end you will find the test decription for
the test controller and a little nasal script for logging.
o Behaviour with delta_u_n = 0 and an input jump func
Roy Vegard Ovesen 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
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 Er
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
Hans-Georg Wunder wrote:
It would be great, if you also test the code.
This PID code has been working well (and untouched for quite some time
now.) What bug/problem are we trying to fix here?
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanf
It would be great, if you also test the code.
Hans-Georg
Jeff McBride wrote:
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 o
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.
I th
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
I seem to recall Erik commited a change to the autopilot code in the
last week or so. Does that fix something? Did that introduce a new
problem? This is pretty subtle, complex code so people shouldn't be
messing with it too much unless they are really sure they know what's
going on with it.
Hello Jeff,
I found the same bug some days ago and I reported it here on the lists.
Your solution was also my first approach, but it did not work for the
Integrator-part. The value ep_n is wrong for the next cycle.
But after a looot of testing I found this solution:
// Integr
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.:
-
16 matches
Mail list logo
