Hi Torsten,
One thing I noticed recently (but this could have been in the code for a
while) is that if a <reference> is a hard coded <value> instead of a
<property> then if the autopilot definition is reloaded (something you might
do often when tuning the autopilot) the value nodes can get mismapped to
other nodes. I took a brief look at the code and noticed there had been
some parser changes, but didn't unwind deep enough to get to the bottom of
this.
As a practical explanation of what I'm seeing: let's assume the first stage
of the heading controller is to drive the heading-bug-error property to
zero. The reference in this case is always going to be zero since the error
term is computed inside the C/C++ code. In the same autopilot xml file the
altitude controller has a reference of "target-altitude" which is a
property. Let's say that is set to 3500 and I'm flying nicely. After
reloading the autopilot, these can get mixed up and all of the sudden the
heading controller is trying to drive the heading-bug-error to 3500 (the
altitude) and this of course can never happen so the aircraft enters a
perpetual circling pattern.
The problem seems to be pretty deep in the parser which seems to have been
rewritten a bit with some new subobjects, but I wasn't able to unravel the
problem in the time I had available to look into it. :-(
Thanks,
Curt.
On Fri, Nov 27, 2009 at 9:24 AM, Torsten Dreyer <tors...@t3r.de> wrote:
> Hi,
>
> I have just commited some changes to the xml autopilot. Along with a tiny
> bugfix comes a new feature which now allows more than one <autopilot>
> definition in the aircraft's -set.xml.
> You may now do something like this:
> <sim>
> <systems>
> <autopilot>
> <path>Aircraft/Hansajet/Systems/Hansajet-flightdirector.xml</path>
> </autopilot>
> <autopilot>
> <path>Aircraft/Hansajet/Systems/Hansajet-autopilot.xml</path>
> </autopilot>
> <autopilot>
> <path>Aircraft/Hansajet/Systems/Hansajet-digitalfilters.xml</path>
> </autopilot>
> </systems>
> </sim>
>
> Each <autopilot> element creates a new instance of the well known
> FGXMLAutopilot class which is added to a newly created SGSubsystemGroup.
> This
> subsystem group is added to the subsytem manager instead of the previous
> single instance of the autopilot.
>
> The idea behind this change is to be able to keep sophisticated autopilot
> configurations maintainable.
>
> No functional changes should happen to existing autopilots.
>
> Torsten
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
