Re: [Flightgear-devel] Bug in moving-average filter?
On Sunday 25 Sep 2005 09:12, Roy Vegard Ovesen wrote: On Wednesday 21 September 2005 15:23, Lee Elliott wrote: The agl data can be pretty spiky due to terrain/scenery artifacts and 3d buildings/structures and using a moving average filter here reduces the influence of the spikes they produce.. Have you tried the noise-spike filter? Yep - that was the first thing that came to mind but I still had problems when flying over buildings and the occasional terrain intersection. It's mostly because I wanted to use high gains and output values and while the noise-spike filter seems to clip the value at the set limit the initial rate of change in the data is unaffected and the following 2nd stage PID controller still seems to see a spike. I also hit a problem using a moving-average filter on the nav1 heading error data and found that there seemed to be a permanent offset in the output. Re-loading the autopilot seemed to fix the offset and the filter then worked normally. I guessed that the problem might have been been due to the filter starting to run before the nav1 data was ready so I stuck a simple noise-spike filter in front of the moving-average filter and this seemed to cure it. This is in the MiG-15bis that I've just e-mailed to Curt. I've also tried a couple of other things in the MiG15's A/P - I've used common 2nd stage controllers for most of the altitude and heading mode 1st stage controllers. Apart from reducing the number of controllers, it seems to improve the transitions between different modes. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Saturday 17 Sep 2005 15:43, Paul Kahler wrote:
On Fri, 2005-09-16 at 04:41 +0100, Lee Elliott wrote:
Hello List,
I think there's a small bug in the moving-average filter in
...
xmlauto.cxx
else if (filterType == movingAverage)
{
output.push_front(output[0] +
(input[0] - input.back()) /
(samples - 1));
unsigned int i;
for ( i = 0; i output_list.size(); ++i ) {
output_list[i]-setDoubleValue( output[0] );
}
output.resize(1);
}
I'm not trying to flame, but why would you be using a moving
average filter? That's the most complicated filter I've ever
seen - it calls other functions! I always liked the simplicity
of a low pass filter:
output += (measurement - output) * gain;
Using floats, doubles, or fixed point of course.
No need to call a function either, just in-line it where you
need it. Want fast convergence on startup? Just sweep the gain
from 1.0 down to whatever the steady state value needs to be.
I bet this is nothing new - it's probably in the code under
else if (filterType == IIRfilter) or something.
So why do people use moving average filters? Why does FGFS?
Thanks,
Paul
I'm trying them to smooth the input data for agl and nav1 holds.
The agl data can be pretty spiky due to terrain/scenery
artifacts and 3d buildings/structures and using a moving average
filter here reduces the influence of the spikes they produce..
I'm also trying a moving-average filter to smooth the nav1 data
at extreme range where the 'signal' is intermittent.
...and talking of agl... I've noticed that the default keyboard
command for engaging terrain-following (Ctrl-t)
sets /autopilot/locks/altitude to 'terrain-follow' but the
autopilot settings dialogue sets it to 'agl-hold'
Either one is fine... ;)
I also noticed that the agl ladder in the hud now seems to start
with the correct offset, so that it reads zero ft at the
starting airport, but then tracks the altitude ladder - starting
at zero feet alt results in them reading identically. I haven't
checked this with different aircraft yet but I'm just going to
do a quick check through my cvs archives.
LeeE
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Fri, 2005-09-16 at 04:41 +0100, Lee Elliott wrote:
Hello List,
I think there's a small bug in the moving-average filter in
...
xmlauto.cxx
else if (filterType == movingAverage)
{
output.push_front(output[0] +
(input[0] - input.back()) /
(samples - 1));
unsigned int i;
for ( i = 0; i output_list.size(); ++i ) {
output_list[i]-setDoubleValue( output[0] );
}
output.resize(1);
}
I'm not trying to flame, but why would you be using a moving average
filter? That's the most complicated filter I've ever seen - it calls
other functions! I always liked the simplicity of a low pass filter:
output += (measurement - output) * gain;
Using floats, doubles, or fixed point of course.
No need to call a function either, just in-line it where you need it.
Want fast convergence on startup? Just sweep the gain from 1.0 down to
whatever the steady state value needs to be. I bet this is nothing new -
it's probably in the code under else if (filterType == IIRfilter) or
something.
So why do people use moving average filters? Why does FGFS?
Thanks,
Paul
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Saturday 17 September 2005 16:43, Paul Kahler wrote: I'm not trying to flame, but why would you be using a moving average filter? That's the most complicated filter I've ever seen - it calls other functions! It calls some of the methods of the deque datatype. I'm sorry! That's the implementation my limited skills came up with. I chose 4 filters from one of my textbooks: Exponential, Double Exponential, Moving Average and Noise Spike. That's what the author of the textbook called them. Both of the exponential filters are IIR filters. I always liked the simplicity of a low pass filter: output += (measurement - output) * gain; Using floats, doubles, or fixed point of course. You are welcome to add this filter (or any other filter that you think might be usefull) to the already existing filters. No need to call a function either, just in-line it where you need it. Want fast convergence on startup? Just sweep the gain from 1.0 down to whatever the steady state value needs to be. I bet this is nothing new - it's probably in the code under else if (filterType == IIRfilter) or something. So why do people use moving average filters? The Scientist and Engineer's Guide to Digital Signal Processing says about the moving average filter that it is the most common filter in DSP, because it's easy to understand and use. It's optimal for reducing random noise, while retaining a sharp step response. http://www.dspguide.com Why does FGFS? The best I can think of is why not? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re:[Flightgear-devel] Bug in moving-average filter?
Lee Elliot: Hello List, I think there's a small bug in the moving-average filter in xmlauto.cxx I noticed that the output from it was always out a bit and checking with a calculator showed that it seemed to be dividing by the number of samples + 1 instead of just the number of samples. subtracting 1 from 'samples' in line 702 seems to fix the problem and as 'samples' doesn't seem to be used elsewhere I think it's safe. Possibly implies that the number of samples may be one less than specified but I'm not familiar enough with c++ to spot it. You are right. I would suggest resizing input[] to (samples + 1) instead. Change lines 654 and 661 to: input.resize(samples + 1, 0.0); That way we average over the number of samples as configured. Can anyone commit this?! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
Done ... Roy Vegard Ovesen wrote: Lee Elliot: Hello List, I think there's a small bug in the moving-average filter in xmlauto.cxx I noticed that the output from it was always out a bit and checking with a calculator showed that it seemed to be dividing by the number of samples + 1 instead of just the number of samples. subtracting 1 from 'samples' in line 702 seems to fix the problem and as 'samples' doesn't seem to be used elsewhere I think it's safe. Possibly implies that the number of samples may be one less than specified but I'm not familiar enough with c++ to spot it. You are right. I would suggest resizing input[] to (samples + 1) instead. Change lines 654 and 661 to: input.resize(samples + 1, 0.0); That way we average over the number of samples as configured. Can anyone commit this?! -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Friday 16 Sep 2005 21:11, Roy Vegard Ovesen wrote: Lee Elliot: Hello List, I think there's a small bug in the moving-average filter in xmlauto.cxx I noticed that the output from it was always out a bit and checking with a calculator showed that it seemed to be dividing by the number of samples + 1 instead of just the number of samples. subtracting 1 from 'samples' in line 702 seems to fix the problem and as 'samples' doesn't seem to be used elsewhere I think it's safe. Possibly implies that the number of samples may be one less than specified but I'm not familiar enough with c++ to spot it. You are right. I would suggest resizing input[] to (samples + 1) instead. Change lines 654 and 661 to: input.resize(samples + 1, 0.0); That way we average over the number of samples as configured. Can anyone commit this?! the 'fix' in line 702 didn't feel right to me... ...better fixed up-stream. :) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Bug in moving-average filter?
Hello List,
I think there's a small bug in the moving-average filter in
xmlauto.cxx
I noticed that the output from it was always out a bit and
checking with a calculator showed that it seemed to be dividing
by the number of samples + 1 instead of just the number of
samples.
subtracting 1 from 'samples' in line 702 seems to fix the problem
and as 'samples' doesn't seem to be used elsewhere I think it's
safe. Possibly implies that the number of samples may be one
less than specified but I'm not familiar enough with c++ to spot
it. The amended code segment is pasted below.
else if (filterType == movingAverage)
{
output.push_front(output[0] +
(input[0] - input.back()) /
(samples - 1));
unsigned int i;
for ( i = 0; i output_list.size(); ++i ) {
output_list[i]-setDoubleValue( output[0] );
}
output.resize(1);
}
note the line break due to wrap just in front the amended code.
LeeE
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
