Top-posting because I don't want to snip any of this message and going to the bottom would need a lot of scrolling.
Many thanks for looking into both of my wish-list items Roy. I'll try the pass-through filter patch over the next few days and report back on it. As you say, it will be simpler and less expensive than using a full controller for a servo but in conjunction with the <enabled> tag it also opens up possibilities for cheaply re-routing data. As an added bonus, it can also be used for simulating failures too. Re changing the controller gain via a property tree node, I agree that the second format is more consistent but it would break existing autopilots. Would it be difficult to implement an alternate tag name for a property tree node controlled gain value and keep the existing <Kp> tag unchanged so that _either_ <Kp> or <new_tag> could be used? That way the consistent format could be used without breaking existing stuff. Incidentally, I hit this gain problem today - I got a pitch-hold controller working that handles take off rotation reasonably well, at around 140kts, without too much wobbling about but it starts oscillating once I've got up to around 500kts:( If I back off the gain to stop the oscillation at high speeds it doesn't have enough control to prevent over-rotation at take off. Heh - while tuning the pitch-hold controller for rotation I was using runway 17 at KEDW - I set the target speed for 135-140 kts, the target pitch I wanted (in this case 9 deg), engaged pitch-hold, released the brakes and then engaged speed-with-throttle. The length of 17 at KEDW gives you enough time for a few tweaks & reloads before you run out of runway. I used to be able to use the sea for this sort of stuff but it's too wet now ;) LeeE On Tuesday 05 February 2008 19:20, Roy Vegard Ovesen wrote: > On Tuesday 05 February 2008, LeeE wrote: > > Thanks for the updates to xmlauto.cxx. > > > > As well as fixing the reload bug in cvs, the enabled tag for > > the filters is very useful. > > > > Would it be possible to add a null filter type i.e. a filter > > that acts as a simple pass-though? > > Try the attached diff. This adds a new filter type named pass. It > only needs an input and an output. Something like this: > > <filter> > <name>pass-through-filter</name> > <debug>false</debug> > <type>pass</type> > > <input>/instrumentation/airspeed-indicator/indicated-speed-kt</in >put> <output>/autopilot/KAP140/settings/airspeed-kt</output> > </filter> > > > The reason I think this would be useful is that it would > > provide a very low-cost method of re-routing control inputs > > between different sub-systems and controllers - the sort of > > stuff you really need to do in Fly-By-Wire/Flight Control > > Systems. > > > > Also on my wish-list for this area would be the ability to > > change some of the pid controller parameters 'in-flight' > > without having to re-load the A/P e.g. reducing elevator > > control gain as airspeed increases. Because the > > resolution/frequency of the controllers is effectively limited > > by the frame-rate there can be practical difficulties in tuning > > a controller to work optimally over wide ranges such as you'd > > get with most of the fast jets - typically ~120-150kts during > > approach and landing up to 700kts (AFAIK YASim doesn't do > > supersonic so I don't try to seriously tune for the supersonic > > regime). > > Thats an interesting thought. We could do soething like this: > > <config> > <Kp > prop="/autopilot/KAP140/settings/controller01-gain">10.0</Kp> ... > > for the parameters that are to be exposed on the property tree. > Any parameter without the prop attribute gets a constant value as > before. Nasal can be used to change the value of the exposed > parameters. > > Another method could be: > > <config> > <Kp> > <prop>/autopilot/KAP140/settings/controller01-gain</prop> > <value>10.0</value> > </Kp> > ... > > which is consistent with how it's done for the input to the PID > controllers, but this will break all autopilots. > > > Just for info, while re-working the YF-23 I've been playing > > with using closed feedback loop pid controllers as flight > > surface and engine control drivers/servos with some good > > results:) > > > > The config below is what I'm using as an elevator input > > driver/servo (there's also an identical controller for > > elevator-trim input, aileron input, rudder input and throttle & > > reheat control inputs) and so far it's working pretty well > > here. > > > > <pid-controller> > > <name>Ruddervator Surface Driver</name> > > <debug>false</debug> > > <enable> > > <prop>/autopilot/FCS/locks/elevator</prop> > > <value>true</value> > > </enable> > > <input> > > <prop>/autopilot/FCS/controls/flight/elevator-norm</prop> > > </input> > > <reference> > > <prop>/autopilot/FCS/internal/target-elevator-norm</prop> > > </reference> > > <output> > > <prop>/autopilot/FCS/controls/flight/elevator-norm</prop> > > </output> > > <config> > > <Ts>0.05</Ts> > > <Kp>0.45</Kp> > > <beta>0.00001</beta> > > <alpha>0.1</alpha> > > <gamma>0.0</gamma> > > <Ti>0.05</Ti> > > <Td>0.0</Td> > > <u_min>-1.0</u_min> > > <u_max>1.0</u_max> > > </config> > > </pid-controller> > > Of course now you can do that with a filter, which should be > simpler an less expensive. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
