LeeE wrote:
> On Tuesday 18 December 2007 22:52, Tiago Gusmão wrote:
>> LeeE wrote:
>>> Hi all,
>>>
>>> I've noticed recently that after re-loading an autopilot the
>>> filters that are being used seem to be getting a bit
>>> 'confused'. I spotted it when I was comparing the unfiltered
>>> input with the filtered output and saw that the input was
>>> stable to 2 decimal places but the filtered output seemed to be
>>> oscillating very quickly up to the first decimal place.
>>>
>>> I don't know if this happens with all filter types - all the
>>> ones I've been using are noise-spike types.
>>>
>>> LeeE
>> Are you sure it's oscillating instead of just catching up with
>> the current input? anyway, you can try to enable debug on that
>> filter and show us some values.
>>
>> In the meantime i've had my own problem with the AP (now solved,
>> don't use alpha=0 or you will get a NaN that will bring FG to a
>> halt if tied to the controls)
>> but i found some things that don't make much sense to me
>>
>> xmlauto.cxx, line 798, FGXMLAutopilot::reinit:
>>
>> -why is build() called there? it's already called inside init()
>>
>> -maybe my C++ is a little forgotten, but don't we need to delete
>> the objects contained in components() ?
>>
>> Cheers,
>> Tiago
>
> Hi Tiago,
>
> I'm not absolutely sure it's oscillating - it's changing too fast to
> actually see the numbers to be sure - but the visual pattern - that
> is, the apparent 'shape' that you can see suggests it is rapidly
> switching between two values, which change more slowly, over time,
> as the input changes.
>
> Like I said, I compared the un-filtered input with the filtered
> output and while the input could be stable to 2 decimal places the
> filtered output could be changing at the first decimal place i.e.
> the output was varying more than the input by a factor of up to
> 100, so it's not a case of the filter trying to catch up.
>
> The effect is that it is oscillating because it's vastly
> overshooting it's target in both directions.
>
> LeeE
I wasn't able to reproduce, i tried with
<filter>
<name>test filter</name>
<debug>true</debug>
<type>noise-spike</type>
<input>/controls/flight/elevator</input>
<output>/controls/flight/filtered-elevator</output>
<max-rate-of-change>0.1</max-rate-of-change>
</filter>
Also my "paper simulations" seemed ok.
Could you post your filter?
Anyway, the current behavior of resetting the filtered output to zero
doesn't seem very good, i think starting at the current input would be
best.
Cheers,
Tiago
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
