On Wednesday 19 December 2007 16:38, Tiago Gusmão wrote: > LeeE wrote: > > 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 > > I've tested it and it seems the input oscillates and can even > change sign very briefly, you need to pause right after reloading > the AP to be able to spot it. Because the filtered output will > restart at zero, it will be able to quickly go negative and then > will take quite some time to return to normal values. So while > this is AP's fault, it's not because of the filter. > > Anyway, AP reloading isn't something we expect users to mess > with, so i wouldn't bother much with it. > > And from what i've seen in the code, reloading is reliable in the > sense that it really creates new instances of the objects, so > there are no stale values. > > BTW, it was really nice to see the TSR2 fly KSFO -> KSCK over > those hills, good work :) > > Cheers, > Tiago
Hi Tiago, thanks for looking into it. On the TSR2 some of the controllers are very 'tightly' tuned and close to oscillating, and can become unstable at very high speeds. This is largely a nature-of-the-beast type problem - it's a relatively high mass aircraft with small wings and with the elevators(elevons) set close to the wing, giving a small moment arm. At the same time though, they need a lot of authority. The way to get around that would be to run the controllers at a higher rate, which would give them a higher resolution, but I decided to peg them all at 20Hz so that they would work on relatively modest h/w. The controllers are therefore very sensitive and can 'kick', hence the use of filters. Now that I know about the problem, and it really is only a problem while you're tuning the controllers, I know what to look out for. Heh - I first spotted it while I was tuning controllers, which means that you end up re-loading the autopilot a lot, and I spent a long time trying to tune the oscillations out before I noticed that the oscillations didn't start until I reloaded the autopilot - doh! I'll continue monitoring it and it'll be interesting to see if anyone else sees it. 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
