Re: [Flightgear-devel] autopilot controller filter weirdness
On Sunday 13 January 2008 05:14, Ron Jensen wrote: On Sat, 2008-01-12 at 21:22 +, LeeE wrote: Oops - forgot to mention also that with '--log-level=info' the 'Processing registration HA-LHA with callsign MAH096/5' type messages still seem to be continuously output. Is this right? It makes the output from --log-level=info pretty useless because everything else is scrolled away - I use a 2k line scroll buffer but even so, anything from start-up is very quickly lost. LeeE add --prop:/sim/traffic-manager/enabled=0 to the command line. This is output from the traffic-manager. Ron Thanks Ron, I guessed it was from the traffic manager - it just seemed odd that the same output and values were being constantly repeated. LeeE - 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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Sunday 13 January 2008 06:46, K. Hoercher wrote: On Sat, Jan 12, 2008 at 09:22:15PM +, LeeE wrote: On Saturday 12 January 2008 21:12, LeeE wrote: On Saturday 12 January 2008 15:28, Curtis Olson wrote: On Jan 11, 2008 7:09 PM, LeeE wrote: From just a quick check, removing the explicit call to build() after init() in reinit() seems to work here:) New configs seems to be read in ok when the autopilot is updated via the menu - I deliberately drove an controller into oscillating and backed it back out again. Didn't notice the filter output 'oscillating' either. That was just a few minutes check though - bit short of time atm. Can some other people try the same change in xmlauto.xml (comment out/remove the call to build() at line 801) and confirm it's ok? I'd like to confirm. I had been learning/tuning/messing around with some autopilot here too. Before I could come down to a firm conclusion I seemed to have odd effects on reloading changed configurations, like apparently fighting of different controllers. When I noticed your observation here, I successfully tried the suggested commenting out (cvs of 28122007) and at least now the stuff seems to work and does also pick up changed configurations when reloading. It makes the output from --log-level=info pretty useless because everything else is scrolled away - I use a 2k line scroll buffer but even so, anything from start-up is very quickly lost. LeeE You could single out the logging class (seemingly only at runtime) by manipulating /sim/logging/classes. On a side note: I don't think the usage of SG_ALL for a couple of SG_LOG statements is a desired one. They pretty much defy that filtering out especially at higher debug levels. Imho SG_ALL is not (or should not be) a valid class for SG_LOG but a mere convenience on the logging output side of things. regards K. Hoercher Thanks for confirming - this bug has been troubling me for some time:) As this bug, and it's associated fix, will only have an effect when the autopilot is reloaded i.e. when reinit() is called, it won't have any effect in normal operation and existing autopilot controllers etc. should continue to function exactly as before. In view of this, and if no one else can find any problems with it, could this fix be applied? It's likely that some people will be developing aircraft against SG/FG v1.0 (plib) so it should probably be applied to that branch as well, in readiness for the next update to v1.0. LeeE - 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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Jan 11, 2008 7:09 PM, LeeE wrote: Spoke too soon - I thought I'd update SG FG from cvs before trying this and now FG won't get past the 'loading scenery objects' phase. My understanding is that OSG 2.2.0 and earlier has some bugs that cause problems with the new OSG random objects code. Using OSG 2.3.1 or newer should fix the problem for you, otherwise there is an environment variable you can set, but you'll have to dig the archives to find it, I don't recall what it is off the top of my head. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - 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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Saturday 12 January 2008 15:28, Curtis Olson wrote: On Jan 11, 2008 7:09 PM, LeeE wrote: Spoke too soon - I thought I'd update SG FG from cvs before trying this and now FG won't get past the 'loading scenery objects' phase. My understanding is that OSG 2.2.0 and earlier has some bugs that cause problems with the new OSG random objects code. Using OSG 2.3.1 or newer should fix the problem for you, otherwise there is an environment variable you can set, but you'll have to dig the archives to find it, I don't recall what it is off the top of my head. Regards, Curt. Doh! - didn't think of that. From just a quick check, removing the explicit call to build() after init() in reinit() seems to work here:) New configs seems to be read in ok when the autopilot is updated via the menu - I deliberately drove an controller into oscillating and backed it back out again. Didn't notice the filter output 'oscillating' either. That was just a few minutes check though - bit short of time atm. Can some other people try the same change in xmlauto.xml (comment out/remove the call to build() at line 801) and confirm it's ok? LeeE - 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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Saturday 12 January 2008 21:12, LeeE wrote: On Saturday 12 January 2008 15:28, Curtis Olson wrote: On Jan 11, 2008 7:09 PM, LeeE wrote: Spoke too soon - I thought I'd update SG FG from cvs before trying this and now FG won't get past the 'loading scenery objects' phase. My understanding is that OSG 2.2.0 and earlier has some bugs that cause problems with the new OSG random objects code. Using OSG 2.3.1 or newer should fix the problem for you, otherwise there is an environment variable you can set, but you'll have to dig the archives to find it, I don't recall what it is off the top of my head. Regards, Curt. Doh! - didn't think of that. From just a quick check, removing the explicit call to build() after init() in reinit() seems to work here:) New configs seems to be read in ok when the autopilot is updated via the menu - I deliberately drove an controller into oscillating and backed it back out again. Didn't notice the filter output 'oscillating' either. That was just a few minutes check though - bit short of time atm. Can some other people try the same change in xmlauto.xml (comment out/remove the call to build() at line 801) and confirm it's ok? LeeE Oops - forgot to mention also that with '--log-level=info' the 'Processing registration HA-LHA with callsign MAH096/5' type messages still seem to be continuously output. Is this right? It makes the output from --log-level=info pretty useless because everything else is scrolled away - I use a 2k line scroll buffer but even so, anything from start-up is very quickly lost. LeeE - 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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Sat, 2008-01-12 at 21:22 +, LeeE wrote: Oops - forgot to mention also that with '--log-level=info' the 'Processing registration HA-LHA with callsign MAH096/5' type messages still seem to be continuously output. Is this right? It makes the output from --log-level=info pretty useless because everything else is scrolled away - I use a 2k line scroll buffer but even so, anything from start-up is very quickly lost. LeeE add --prop:/sim/traffic-manager/enabled=0 to the command line. This is output from the traffic-manager. Ron - 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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Sat, Jan 12, 2008 at 09:22:15PM +, LeeE wrote: On Saturday 12 January 2008 21:12, LeeE wrote: On Saturday 12 January 2008 15:28, Curtis Olson wrote: On Jan 11, 2008 7:09 PM, LeeE wrote: From just a quick check, removing the explicit call to build() after init() in reinit() seems to work here:) New configs seems to be read in ok when the autopilot is updated via the menu - I deliberately drove an controller into oscillating and backed it back out again. Didn't notice the filter output 'oscillating' either. That was just a few minutes check though - bit short of time atm. Can some other people try the same change in xmlauto.xml (comment out/remove the call to build() at line 801) and confirm it's ok? I'd like to confirm. I had been learning/tuning/messing around with some autopilot here too. Before I could come down to a firm conclusion I seemed to have odd effects on reloading changed configurations, like apparently fighting of different controllers. When I noticed your observation here, I successfully tried the suggested commenting out (cvs of 28122007) and at least now the stuff seems to work and does also pick up changed configurations when reloading. It makes the output from --log-level=info pretty useless because everything else is scrolled away - I use a 2k line scroll buffer but even so, anything from start-up is very quickly lost. LeeE You could single out the logging class (seemingly only at runtime) by manipulating /sim/logging/classes. On a side note: I don't think the usage of SG_ALL for a couple of SG_LOG statements is a desired one. They pretty much defy that filtering out especially at higher debug levels. Imho SG_ALL is not (or should not be) a valid class for SG_LOG but a mere convenience on the logging output side of things. regards K. Hoercher - 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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Jan 11, 2008 3:14 PM, Roy Vegard Ovesen wrote:
On Friday 11 January 2008, LeeE wrote:
I've had a look at the relevant code but as I'm not up on c++ I'm
not sure about what I'm looking at but at lines 798-802 there's:
void FGXMLAutopilot::reinit() {
components.clear();
init();
build();
}
I could find init() build() and thought that components.clear()
must be what removes old instances and must be a more generic
function. However, when I grepped through the SimGear FlightGear
source the only occurrence I could find of this function was at
that single point in xmlauto.cxx. I then searched for
components.clear() in C/C++ reference manuals on the web and didn't
find anything there either. Perhaps I just wasn't looking in the
right place though.
In any case, it seems strange to me that if components.clear() is a
generic function, it's only used in this one place in the entire
SG/FG source.
Actually it's only the clear() part that it generic. clear() is a method
of
the vector template.
I might be barking up the wrong tree entirely here, but I can't see
what else might be causing the behaviour I'm seeing.
Try commenting out the call to build() from the code that you quoted
above.
build() is called inside init(), so there should be no need to call it
again
after init().
I suspect the build() is there so you can change the autopilot config file
while flying and reload it. That way you don't need to restart the sim to
fiddle with the gains.
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
-
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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Friday 11 January 2008, Curtis Olson wrote: On Jan 11, 2008 3:14 PM, Roy Vegard Ovesen wrote: Try commenting out the call to build() from the code that you quoted above. build() is called inside init(), so there should be no need to call it again after init(). I suspect the build() is there so you can change the autopilot config file while flying and reload it. That way you don't need to restart the sim to fiddle with the gains. Curt. Yes, but there is no need to call build() two times in order to reload. I did a simple test revealing that after an autopilot reload, components contained twice as many elements as before the reaload. As would be expected by calling build() twice. I firmly belive that the call to build() in FGXMLAutopilot.reinit() should be removed. -- Roy Vegard Ovesen - 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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Friday 11 January 2008 21:50, Curtis Olson wrote:
On Jan 11, 2008 3:14 PM, Roy Vegard Ovesen wrote:
On Friday 11 January 2008, LeeE wrote:
I've had a look at the relevant code but as I'm not up on c++
I'm not sure about what I'm looking at but at lines 798-802
there's:
void FGXMLAutopilot::reinit() {
components.clear();
init();
build();
}
I could find init() build() and thought that
components.clear() must be what removes old instances and
must be a more generic function. However, when I grepped
through the SimGear FlightGear source the only occurrence I
could find of this function was at that single point in
xmlauto.cxx. I then searched for components.clear() in C/C++
reference manuals on the web and didn't find anything there
either. Perhaps I just wasn't looking in the right place
though.
In any case, it seems strange to me that if
components.clear() is a generic function, it's only used in
this one place in the entire SG/FG source.
Actually it's only the clear() part that it generic. clear()
is a method of
the vector template.
I might be barking up the wrong tree entirely here, but I
can't see what else might be causing the behaviour I'm
seeing.
Try commenting out the call to build() from the code that you
quoted above.
build() is called inside init(), so there should be no need to
call it again
after init().
I suspect the build() is there so you can change the autopilot
config file while flying and reload it. That way you don't need
to restart the sim to fiddle with the gains.
Curt.
I'll give what Roy suggests a try - build() is called from within
init() and build() creates new controller, predictor and filter
nodes (if I'm interpreting it correctly). If it's being called
twice, after clear() then it might explain something.
No problem to give it a try - I'll post back after re-compiling.
LeeE
-
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
Re: [Flightgear-devel] autopilot controller filter weirdness
On Friday 11 January 2008 23:49, LeeE wrote:
On Friday 11 January 2008 21:50, Curtis Olson wrote:
On Jan 11, 2008 3:14 PM, Roy Vegard Ovesen wrote:
On Friday 11 January 2008, LeeE wrote:
I've had a look at the relevant code but as I'm not up on
c++ I'm not sure about what I'm looking at but at lines
798-802 there's:
void FGXMLAutopilot::reinit() {
components.clear();
init();
build();
}
I could find init() build() and thought that
components.clear() must be what removes old instances and
must be a more generic function. However, when I grepped
through the SimGear FlightGear source the only occurrence
I could find of this function was at that single point in
xmlauto.cxx. I then searched for components.clear() in
C/C++ reference manuals on the web and didn't find anything
there either. Perhaps I just wasn't looking in the right
place though.
In any case, it seems strange to me that if
components.clear() is a generic function, it's only used in
this one place in the entire SG/FG source.
Actually it's only the clear() part that it generic.
clear() is a method of
the vector template.
I might be barking up the wrong tree entirely here, but I
can't see what else might be causing the behaviour I'm
seeing.
Try commenting out the call to build() from the code that you
quoted above.
build() is called inside init(), so there should be no need
to call it again
after init().
I suspect the build() is there so you can change the autopilot
config file while flying and reload it. That way you don't
need to restart the sim to fiddle with the gains.
Curt.
I'll give what Roy suggests a try - build() is called from within
init() and build() creates new controller, predictor and filter
nodes (if I'm interpreting it correctly). If it's being called
twice, after clear() then it might explain something.
No problem to give it a try - I'll post back after re-compiling.
LeeE
Spoke too soon - I thought I'd update SG FG from cvs before trying
this and now FG won't get past the 'loading scenery objects' phase.
Setting --log-level=info seems to show FG looping while displaying
lots of:
Processing registration HA-LHA with callsign MAH096/5
type messages, which seem to be repeated over over.
It'll have to wait until the morning now:(
LeeE
-
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
