On Wednesday 19 December 2007 12:56, Tiago Gusmão wrote: > 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
Hi Tiago, have a look at the 'Target Pitch Filter' in the BAC-TSR2 autopilot - I saw the problem with that filter. The filename is: Aircraft/BAC-TSR2/Systems/BAC-TSR2-autopilot.xml LeeE ------------------------------------------------------------------------- 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
