Menu
▾
▴
flightgear-devel
|
From: Thomas <t.f...@bi...> - 2007-02-08 15:59:43
|
Hi, I hit on a strange problem when using the --flight-plan commandline option with the default c172. All controls are working except the ailerons, which makes flying around a bit challenging... ;-) command line: fgfs --airport=EDDT --runway=26L --flight-plan=EDDT-EDDC.plan EDDT-EDDC.plan: GERGA TUVAK GORIG BESKO LUROS EBASA KOBUS GARKI Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 |
|
From: gh.robin <gh....@la...> - 2007-02-08 17:36:09
|
On Thu 8 February 2007 11:13, Thomas F=F6rster wrote: > Hi, > > I hit on a strange problem when using the --flight-plan commandline option > with the default c172. All controls are working except the ailerons, which > makes flying around a bit challenging... ;-) > > command line: fgfs --airport=3DEDDT --runway=3D26L --flight-plan=3DEDDT-E= DDC.plan > > EDDT-EDDC.plan: > > GERGA > TUVAK > GORIG > BESKO > LUROS > EBASA > KOBUS > GARKI > > > Thomas If it is FG cvs with OSG, it is not a surprise to me, i told before on seve= ral=20 topics regarding autopilot, that it is not working.=20 Nobody but Lee answered to confirm that it is not working. =2D-=20 G=E9rard |
|
From: Thomas <t.f...@bi...> - 2007-02-08 21:06:10
|
Am Donnerstag 08 Februar 2007 18:35 schrieb gh.robin: > On Thu 8 February 2007 11:13, Thomas F=F6rster wrote: > ... > If it is FG cvs with OSG, it is not a surprise to me, i told before on > several topics regarding autopilot, that it is not working. > Nobody but Lee answered to confirm that it is not working. No, this was with the 0.9.10 release. The c172 starts with waypoint mode=20 enabled if --flight-plan is given, but the autopilot (the one in the plane)= =20 switched off. Switching off waypoint mode with F6 gives back full controls.= =20 Looks like an interference of the generalized FG autopilot and the c172 one. Thomas =2D-=20 PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 |
|
From: John D. <sf...@av...> - 2007-02-08 17:59:29
|
On 02/08/2007 12:35 PM, gh.robin wrote: > If it is FG cvs with OSG, it is not a surprise to me, i told before on several > topics regarding autopilot, that it is not working. > Nobody but Lee answered to confirm that it is not working. The default c172p in the current CVS is messed up in ways that have nothing to do with the autopilot I routinely observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph. I wish I could find a real-life C172 with that kind of performance. |
|
From: polly <li...@bi...> - 2007-02-08 18:13:33
|
On Thu, 08 Feb 2007 12:59:02 -0500, John Denker <sf...@av...> wrote: > I routinely observe 135 Kias at 2850 RPM in level flight at 1000 MSL, > using only 13 gph. Is it possible that post-OSG all fdm's are snappier ? I've no hard evidence but I seem to be able to overspeed the c310-ifr much more easily sine I got an OSG build; no complaints, it's a lot easier to follow the LLZ lately too. -- <=> |
|
From: Martin S. <Mar...@mg...> - 2007-02-08 22:10:15
|
"gh.robin" wrote: > On Thu 8 February 2007 11:13, Thomas F?rster wrote: > > I hit on a strange problem when using the --flight-plan commandline option > > with the default c172. All controls are working except the ailerons, which > > makes flying around a bit challenging... ;-) > If it is FG cvs with OSG, it is not a surprise to me, i told before on several > topics regarding autopilot, that it is not working. If you would not notoriously combine such "bug reports" with senseless allegations then people probably would take your reports more seriously, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: gh.robin <gh....@la...> - 2007-02-08 23:21:55
|
On Thu 8 February 2007 23:09, Martin Spott wrote: > "gh.robin" wrote: > > On Thu 8 February 2007 11:13, Thomas F?rster wrote: > > > I hit on a strange problem when using the --flight-plan commandline > > > option with the default c172. All controls are working except the > > > ailerons, which makes flying around a bit challenging... ;-) > > > > If it is FG cvs with OSG, it is not a surprise to me, i told before on > > several topics regarding autopilot, that it is not working. > > If you would not notoriously combine such "bug reports" with senseless > allegations then people probably would take your reports more > seriously, > > Martin. Martin,=20 Nice your answer , what would have more, to take that information seriously= ? just, remember, from Lee =3D=3D> I experienced similar problems a few days ago - some of the AP controllers seemed to be working from start-up but others didn't. Re-setting the AP controllers via the debug menu appeared to kick them into life after start-up. I also had problems with some AP controllers seeming not to work after I removed other unrelated redundant controllers but didn't have enough time to look further into it or establish any consistency. from me =3D=3D> The CVS FlightGear and Simgear dated "2007-12-27" built, gives an Autopil= ot=20 working The CVS FlightGear and Simgear dated "2007-12-27 12:00" built, gives an=20 Autopilot destroyed. =2E............................................ if we reload the autopilot config with menu/debug We get the autopilot working heading and altitude<=3D=3D That information from me was only to help to improve FG cvs with OSG , if y= ou=20 do want it .........i don't mind i have solved that bug with a specific=20 trick on my side. Anyhow If you want more, i can give you the size and the color of my shirt. Regards =2D-=20 G=E9rard |
|
From: leee <le...@sp...> - 2007-02-09 00:25:40
|
On Thursday 08 February 2007 23:22, gh.robin wrote: > On Thu 8 February 2007 23:09, Martin Spott wrote: > > "gh.robin" wrote: > > > On Thu 8 February 2007 11:13, Thomas F?rster wrote: > > > > I hit on a strange problem when using the --flight-plan commandline > > > > option with the default c172. All controls are working except the > > > > ailerons, which makes flying around a bit challenging... ;-) > > > > > > If it is FG cvs with OSG, it is not a surprise to me, i told before on > > > several topics regarding autopilot, that it is not working. > > > > If you would not notoriously combine such "bug reports" with senseless > > allegations then people probably would take your reports more > > seriously, > > > > Martin. > > Martin, > > Nice your answer , what would have more, to take that information seriously > ? > > just, remember, > > from Lee ==> > I experienced similar problems a few days ago - some of the AP controllers > seemed to be working from start-up but others didn't. Re-setting the AP > controllers via the debug menu appeared to kick them into life after > start-up. I also had problems with some AP controllers seeming not to > work after I removed other unrelated redundant controllers but didn't have > enough time to look further into it or establish any consistency. > > > from me ==> > The CVS FlightGear and Simgear dated "2007-12-27" built, gives an > Autopilot working > The CVS FlightGear and Simgear dated "2007-12-27 12:00" built, gives an > Autopilot destroyed. > > > ............................................. > if we reload the autopilot config with menu/debug > We get the autopilot working heading and altitude<== > > > That information from me was only to help to improve FG cvs with OSG , if > you do want it .........i don't mind i have solved that bug with a > specific trick on my side. > > Anyhow If you want more, i can give you the size and the color of my > shirt. > > Regards Just checked again, with current cvs osg/simgear/flightgear, and I still got the same problems. As before, re-setting the A/P via the menu seems to kick everything into life. There also seems to be a random element to this problem - in half a dozeeen tests, most of the time it was the same controllers that seemed not to be working but in two tests there seemed to be a couple of additional ones that didn't want to play. LeeE |
|
From: Durk T. <d.t...@xs...> - 2007-02-09 00:47:20
|
leee wrote: > On Thursday 08 February 2007 23:22, gh.robin wrote: > > Just checked again, with current cvs osg/simgear/flightgear, and I still got > the same problems. As before, re-setting the A/P via the menu seems to kick > everything into life. There also seems to be a random element to this > problem - in half a dozeeen tests, most of the time it was the same > controllers that seemed not to be working but in two tests there seemed to be > a couple of additional ones that didn't want to play. > > I have read the original report, and remember that the moment the autopilot seemed to stop working was one where I had committed a bunch of AI related changes, which actually have nothing to do with the autopilot. The changes in this particular commit were affecting the core of FlightGear a bit more than usual, because I modified the initialization procedure of the TrafficManager system, which required code changes in Main/fg_init.cxx. There is a possibility that something has gone wrong here; either a) the new initialization procedure has a memory error that corrupts the initialization of the autopilot; or b) the new initialization procedure introduces a timing error, so that parts of the autopilot are never initialized. Normally, I would have run a few tests in order to falsify my hypotheses, but as I'm currently away from home, I can't do that. If anybody wants to look into this, please do so. Otherwise, it has to wait until after I get back home, I'm afraid. Cheers, Durk However, |
|
From: Dave P. <ski...@mi...> - 2007-02-09 01:58:13
|
On Fri, 2007-02-09 at 00:25 +0000, leee wrote: > Just checked again, with current cvs osg/simgear/flightgear, and I still got > the same problems. As before, re-setting the A/P via the menu seems to kick > everything into life. There also seems to be a random element to this > problem - in half a dozeeen tests, most of the time it was the same > controllers that seemed not to be working but in two tests there seemed to be > a couple of additional ones that didn't want to play. > The power check I added to kap140.nas moves the call to initialize the autopilot (apInit) to inside the apPower loop. apPower is called by a setlistener that monitors power="/systems/electrical/outputs/autopilot to makes sure there is power to the autopilot before starting the power monitor apPower to prevent a "nil used in numeric context" nasal error. So, those reporting this behavior, please look at the Log Window; after the description. There should be two lines: Initializing Nasal Electrical System power up If "power up" is not there, then apPower has not been called and apInit has not been called, and the state of the various locks is unknown. This would indicate a problem with the setlistener. If it is there, my changes are not causing this problem. -- Dave Perry <ski...@mi...> |
|
From: leee <le...@sp...> - 2007-02-09 17:11:08
|
On Friday 09 February 2007 01:54, Dave Perry wrote: > On Fri, 2007-02-09 at 00:25 +0000, leee wrote: > > Just checked again, with current cvs osg/simgear/flightgear, and I still > > got the same problems. As before, re-setting the A/P via the menu seems > > to kick everything into life. There also seems to be a random element to > > this problem - in half a dozeeen tests, most of the time it was the same > > controllers that seemed not to be working but in two tests there seemed > > to be a couple of additional ones that didn't want to play. > > The power check I added to kap140.nas moves the call to initialize the > autopilot (apInit) to inside the apPower loop. apPower is called by a > setlistener that monitors power="/systems/electrical/outputs/autopilot > to makes sure there is power to the autopilot before starting the power > monitor apPower to prevent a "nil used in numeric context" nasal > error. > > So, those reporting this behavior, please look at the Log Window; after > the description. There should be two lines: > > Initializing Nasal Electrical System > power up > > If "power up" is not there, then apPower has not been called and apInit > has not been called, and the state of the various locks is unknown. This > would indicate a problem with the setlistener. If it is there, my > changes are not causing this problem. Hmm... all I see here is Reading xml electrical system model from /usr/local/share/FlightGear/Aircraft/SU-37/Systems/SU-37-electrical.xml I don't know how this might relate to the Nasal power system but I was beginning to suspect some sort of timing problem. LeeE |
|
From: Roy V. O. <roy...@ha...> - 2007-02-09 17:07:48
|
On Friday 09 February 2007 02:54, Dave Perry wrote: > On Fri, 2007-02-09 at 00:25 +0000, leee wrote: > > Just checked again, with current cvs osg/simgear/flightgear, and I still > > got the same problems. As before, re-setting the A/P via the menu seems > > to kick everything into life. There also seems to be a random element = to > > this problem - in half a dozeeen tests, most of the time it was the same > > controllers that seemed not to be working but in two tests there seemed > > to be a couple of additional ones that didn't want to play. > > The power check I added to kap140.nas moves the call to initialize the > autopilot (apInit) to inside the apPower loop. apPower is called by a > setlistener that monitors power=3D"/systems/electrical/outputs/autopilot > to makes sure there is power to the autopilot before starting the power > monitor apPower to prevent a "nil used in numeric context" nasal > error. I believe that the problem G=E9rard and Lee has seen is not specific to the= =20 KAP140 autopilot. apInit in kap140.nas _only_ initializes the properties th= at=20 belong to the KAP140 autopilot. The initialization that Durk is talking abo= ut=20 is certainly not the same as apInit. So far I have been unable to reproduce this. Lee and G=E9rard, could you please tell us what aircraft you are seeing thi= s=20 with. Is it aircraft that use the generic autopilot and/or aircraft that us= e=20 a customized autopilot? =2D-=20 Roy Vegard Ovesen |
|
From: leee <le...@sp...> - 2007-02-09 17:24:16
|
On Friday 09 February 2007 17:07, Roy Vegard Ovesen wrote: > On Friday 09 February 2007 02:54, Dave Perry wrote: > > On Fri, 2007-02-09 at 00:25 +0000, leee wrote: > > > Just checked again, with current cvs osg/simgear/flightgear, and I > > > still got the same problems. As before, re-setting the A/P via the > > > menu seems to kick everything into life. There also seems to be a > > > random element to this problem - in half a dozeeen tests, most of the > > > time it was the same controllers that seemed not to be working but in > > > two tests there seemed to be a couple of additional ones that didn't > > > want to play. > > > > The power check I added to kap140.nas moves the call to initialize the > > autopilot (apInit) to inside the apPower loop. apPower is called by a > > setlistener that monitors power=3D"/systems/electrical/outputs/autopilot > > to makes sure there is power to the autopilot before starting the power > > monitor apPower to prevent a "nil used in numeric context" nasal > > error. > > I believe that the problem G=E9rard and Lee has seen is not specific to t= he > KAP140 autopilot. apInit in kap140.nas _only_ initializes the properties > that belong to the KAP140 autopilot. The initialization that Durk is > talking about is certainly not the same as apInit. > > So far I have been unable to reproduce this. > > Lee and G=E9rard, could you please tell us what aircraft you are seeing t= his > with. Is it aircraft that use the generic autopilot and/or aircraft that > use a customized autopilot? Hi Roy, I am getting this with the SU-37 and I believe the version in cvs displays = the=20 problems. This is a pretty complex A/P setup with cascading up to three=20 levels and it also includes filters to un-tie some tied nodes so that I cou= ld=20 use listeners on the preperties. There are also still some redundant=20 controllers in there as well, just to confuse matters further. At one point, while I was tidying up the redundant stuff, I found that when= I=20 removed a couple of unused controllers it seemed to cause a couple of used= =20 controllers to stop working. I monitor the cvs logs and hadn't noticed=20 anything obvious come through that might have caused this and in the end I= =20 couldn't make much sense of it. LeeE |
|
From: Roy V. O. <roy...@ha...> - 2007-02-09 18:15:04
|
On Friday 09 February 2007 18:24, leee wrote: > > Hi Roy, > > I am getting this with the SU-37 and I believe the version in cvs displays > the problems. This is a pretty complex A/P setup with cascading up to > three levels and it also includes filters to un-tie some tied nodes so that > I could use listeners on the preperties. There are also still some > redundant controllers in there as well, just to confuse matters further. Could you be more specific? Witch of the 21 pid controllers are not working in the SU-37 autopilot? Also could you tell me how to use the autopilot(s) in the SU-37? From the readme I gathered that it can be cotrolled from the mini-panel, but I'm unable to get the mini-panel to show, I tried "c" but that didn't seem to work. -- Roy Vegard Ovesen |
|
From: leee <le...@sp...> - 2007-02-09 18:56:37
|
On Friday 09 February 2007 18:14, Roy Vegard Ovesen wrote:
> On Friday 09 February 2007 18:24, leee wrote:
> > Hi Roy,
> >
> > I am getting this with the SU-37 and I believe the version in cvs
> > displays the problems. This is a pretty complex A/P setup with cascading
> > up to three levels and it also includes filters to un-tie some tied nodes
> > so that I could use listeners on the preperties. There are also still
> > some redundant controllers in there as well, just to confuse matters
> > further.
>
> Could you be more specific? Witch of the 21 pid controllers are not working
> in the SU-37 autopilot?
>
> Also could you tell me how to use the autopilot(s) in the SU-37? From the
> readme I gathered that it can be cotrolled from the mini-panel, but I'm
> unable to get the mini-panel to show, I tried "c" but that didn't seem to
> work.
I can't remember exactly which controllers were playing up but there did seem
to be a random element to it.
For the pitch modes the structure is
Pitch-hold
Climb-hold
Altitude-hold
AGL-hold.
The Altitude & AGL controllers set a target climb rate which is input to the
Climb controller. The climb controller outputs a target pitch angle which is
then used by the pitch controller to drive the elevon pitch component.
At the start of an auto take-off, just the pitch-hold is used to handle the
ground run and rotation. Once a set altitude is reached the climb-hold is
engaged to achieve a set climb-rate and finally, the altitude hold is
engaged.
During this sequence I've seen occasions where each of the controllers has
appeared to fail, e.g. sometimes the initial pitch hold just doesn't happen
and there's no rotation, sometimes the climb rate isn't effective and
sometimes the altitude hold is ignored. The locks all appear ok but the
output from the controller isn't updated. If leave the aircraft to continue
it's climb (on climb-hold) after the altitude hold hasn't worked and then
reset the A/P via the menu all the controllers then seem to kick in and, if I
can recover from the spin, the A/P seems to work ok.
Sometimes, if the altitude hold hasn't worked, the agl hold does.
Similarly, if I simply reset the A/P before starting then everything
subsequently works ok.
I found similar problems with the roll modes but there's only two stages of
cascading there.
The mini-panel 2d panel needs to be enabled by hitting 'shift-p' and then 's'
to toggle into the mini-panel. I find here that I need to switch the old hud
off (cycle by hitting 'h') to see the instruments - there seems to be some
interaction between the hud display and the 2d instruments.
There's a key to the A/P modes in the aircraft help menu but basically, if
someting is coloured green you can click it to toggle it.
This was all very experimental, from my point of view, hence everything's not
very well organised atm.
LeeE
|
|
From: gh.robin <gh....@la...> - 2007-02-09 18:27:03
|
On Fri 9 February 2007 18:07, Roy Vegard Ovesen wrote: > On Friday 09 February 2007 02:54, Dave Perry wrote: > > I believe that the problem G=E9rard and Lee has seen is not specific to t= he > KAP140 autopilot. apInit in kap140.nas _only_ initializes the properties > that belong to the KAP140 autopilot. The initialization that Durk is > talking about is certainly not the same as apInit. > > So far I have been unable to reproduce this. > > Lee and G=E9rard, could you please tell us what aircraft you are seeing t= his > with. Is it aircraft that use the generic autopilot and/or aircraft that > use a customized autopilot? Hello Roy , Every Aircraft which basicaly use the Generic autopilot (no KAP140 or else). I tested it with a lot of the nice aircraft from Lee which do not work and among the others examples the dc3 Autopilot is right with Altitude but crazy with Heading. Like i noticed before, if during the flight if i try to get an autopilot w= ith=20 heading , i reload /menu/bug/autopilot and i get the autopilot working. Some others like a4f , f16, gives the same errors (heading bug) , in addit= ion=20 to the fact that the generic autopilot.xml does not suit to high speed=20 aircraft (F18 autopilot.xml from Mathias is better to test it). I have noticed it with every aircraft of my hangar, but that is an "other=20 story" :) Anyhow the remarks from Durk could be dug again (i have tried to find anyth= ing=20 wrong without any success) , because, his own update dated "2007-12-27 12:0= 0"=20 was made only to cvs with OSG And remember =3D> cvs pre osg with plib is perfectly working regarding=20 autopilot. Regards =2D-=20 G=E9rard |
|
From: Roy V. O. <roy...@ha...> - 2007-02-09 19:04:39
|
On Friday 09 February 2007 19:26, gh.robin wrote: > Hello Roy , > Every Aircraft which basicaly use the Generic autopilot (no KAP140 or > else). > > I tested it with a lot of the nice aircraft from Lee which do not work > and among the others examples > the dc3 Autopilot is right with Altitude but crazy with Heading. I just tried the dc3. Heading hold is working "perfectly". Could there be something on your and Lee's system that is causing this? I=20 tried the first time you reported this issue, and was unable to reproduce=20 what you saw then too. Are anyone else on this list seeing the problems that Lee and G=E9rard are= =20 seeing? > > Like i noticed before, if during the flight if i try to get an autopilot > with heading , i reload /menu/bug/autopilot and i get the autopilot > working. Could you check the property browser before and after you reload the=20 autopilot? Look at the /autopilot/new-config dir. Are all the controllers=20 there prior to reloading the autopilot? (In the cd3 I see two=20 pi-simple-controllers and sixteen pid-controllers.) =2D-=20 Roy Vegard Ovesen |
|
From: gh.robin <gh....@la...> - 2007-02-10 00:08:14
|
On Fri 9 February 2007 20:04, Roy Vegard Ovesen wrote: > > Could you check the property browser before and after you reload the > autopilot? Look at the /autopilot/new-config dir. Are all the controllers > there prior to reloading the autopilot? (In the cd3 I see two > pi-simple-controllers and sixteen pid-controllers.) Hello Roy, I do not notice any differences regarding /autopilot/new-config dir betwee= n =20 first load values (after FG loaded) and after reload autopilot. i get two pi-simple-controllers and sixteen pid-controllers. =2D-=20 G=E9rard |
|
From: Roy V. O. <roy...@ha...> - 2007-02-10 09:53:17
|
On Saturday 10 February 2007 01:08, gh.robin wrote: > Hello Roy, > I do not notice any differences regarding /autopilot/new-config dir > between first load values (after FG loaded) and after reload autopilot. > > i get two pi-simple-controllers and sixteen pid-controllers. OK, you said that the heading hold in the dc3 was "crazy". The dc3 uses the generic autopilot, then all aircraft using the generic autopilot should experience the same crazieness in heading hold mode. Could you try activating the debug option of the two pid-controllers that are used in heading hold mode? Open data/Aircraft/Generic/generic-autopilot.xml and set the debug flag to true for the controllers named "Heading Bug Hold (DG based) Stage 1", and "Heading Bug Hold (DG based) Stage 2". When you activate the heading hold mode you should get debug messages from those two controllers on the console. This is what I get when I'm in a left turn chasing the heading bug in the dc3 (# My comments): Updating Heading Bug Hold (DG based) Stage 1 Ts 0.0416667 input = -50.076 ref = 0 # We are -50.076 degrees from our desired heading. ep_n = 50.076 ep_n_1 = 50.1743 e_n = 50.076 ed_n = 50.076 Tf = 1e-06 edf_n = 50.076 delta_u_n = -0.110384 P:0.0982607 I:-0.20865 D:5.29441e-06 min saturation output = -20 # The controller has commanded a 20 degree left bank. Updating Heading Bug Hold (DG based) Stage 2 Ts 0.0416667 input = -16.6732 ref = -20 # We are currently at 16.6732 degrees left bank. ep_n = -3.32684 ep_n_1 = -3.34097 e_n = -3.32684 ed_n = 16.6732 Tf = 1e-06 edf_n = 16.6732 delta_u_n = 2.75638e-05 P:0.00141368 I:-0.00138618 D:6.68812e-08 output = -0.00296141 # This is the commanded aileron, a tiny bit of left aileron makes sense. # 0.03 seconds later: Updating Heading Bug Hold (DG based) Stage 1 Ts 0.0333333 input = -49.9996 ref = 0 ep_n = 49.9996 ep_n_1 = 50.076 e_n = 49.9996 ed_n = 49.9996 Tf = 1e-06 edf_n = 49.9996 delta_u_n = -0.09026 P:0.0764119 I:-0.166665 D:-6.55459e-06 min saturation output = -20 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.0333333 input = -16.6844 ref = -20 ep_n = -3.31557 ep_n_1 = -3.32684 e_n = -3.31557 ed_n = 16.6844 Tf = 1e-06 edf_n = 16.6844 delta_u_n = 2.10212e-05 P:0.0011263 I:-0.00110519 D:-8.62141e-08 output = -0.00294038 As you can see the inputs and outputs to/from these controllers look reasonable. Are you getting crazy inputs and outputs when you try the same? And are you getting sane inputs and outputs after a autopilot reload? If you are getting crazy inputs and outputs, you should run fgfs in a debugger like ddd and step through the FGPIDController::update() method in source/src/Autopilot/xmlauto.cxx to see what is going on. -- Roy Vegard Ovesen |
|
From: John D. <sf...@av...> - 2007-02-10 17:48:24
|
In some parts of the world, (including the southwest US), a goodly fraction of the localizers have an expanded service volume (ESV), often quite a bit larger than the standard service volume you see in the AIM. The code in navradio.cxx has been ignoring the service volume information in the database and wrongly assuming the default values applied everywhere. A patch to fix the range-related part of the problem can be found at: http://www.av8n.com/fly/fgfs/service-volume.diff ... but alas there are other service volume issues. The code has no understanding of how azimuth affects the localizer. There is more to the story than reception *range*. It is perfectly possible to be outside the LOC service volume for reasons having to do with azimuth, not range. Good ident will be heard, but false localizer courses will cause serious trouble for the unwary pilot. Similar remarks apply to false glide slopes. The patch does not address these non-range issue. The code would need to be significantly restructured to deal with this. |
|
From: John D. <sf...@av...> - 2007-02-12 02:27:28
|
From http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs 1 Known Bugs 1.1 Incorrect altimetry. 1.2 Altimetry misnomers and misconceptions. 1.3 Z-buffer burn-through. 1.4 Memory leak. 1.5 Numerous bugs in ATIS feature. 1.6 Problems with --altitude option. 1.7 Multiple bugs in the location-in-air popup. 1.8 Nearest fix. 1.9 HSI instrument failure. 1.10 Flux gate not really a flux gate. 1.11 Weird noises during initialization. 1.12 Weird displays during fullscreen initialization. 1.13 Fullscreen window sometimes misplaced. 1.14 Navigation databases out-of-date 1.15 Ident from phantom DME. 1.16 Wild accelerations at low speeds. 1.17 Airport lighting in poor weather. 1.18 Holes in the ground. 1.19 Mixture versus Altitude. 1.20 EGT reads high. 1.21 Flags missing from instruments. 1.22 Problems with --model-hz option. 1.23 CPU hogging. 1.24 Misdirected diagnostic in JSBSim.cxx 1.25 Glideslope service volume. 1.26 Extended service volume. 1.27 Other service volume issues. 1.28 Radio buttons having a get-together. 1.29 Altimeter setting unreadable. 1.30 Broken startup banner. 2 Missing Features and Traps for the Unwary 2.1 Version number, please. 2.2 Rabbits extinct. 2.3 No comm volume control. 2.4 Incompatible Scenery. 2.5 ASOS and AWOS are AWOL. 2.6 Roundoff problems with textranslate step and scroll. 3 Fixed Bugs 4 See Also 4.1 Individual Aircraft 4.2 OpenSceneGraph For details on each of these items, see http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs |
|
From: Jon S. B. <js...@ha...> - 2007-02-12 02:31:53
|
> 1.24 Misdirected diagnostic in JSBSim.cxx Was the fix for this applied to JSBSim.cxx in JSBSim CVS, too? Jon |
|
From: Ron J. <wi...@je...> - 2007-03-31 23:50:22
|
On Sun, 2007-02-11 at 20:27 -0600, Jon S. Berndt wrote:
> > 1.24 Misdirected diagnostic in JSBSim.cxx
>
> Was the fix for this applied to JSBSim.cxx in JSBSim CVS, too?
>
> Jon
The wiki [1] says this bug is fixed in JSBSim, however that is not true.
CVS for flightgear [2] matches CVS for JSBSim [3] and both still contain
the code for dumping the error code to cout.
I don't speak C++, but would this patch be an acceptable fix?
Index: JSBSim.cxx
===================================================================
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/JSBSim.cxx,v
retrieving revision 1.41
diff -u -r1.41 JSBSim.cxx
--- JSBSim.cxx 19 Mar 2007 16:37:36 -0000 1.41
+++ JSBSim.cxx 31 Mar 2007 23:48:55 -0000
@@ -425,10 +425,14 @@
if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
"FGInterface is being called without scenery below the aircraft!");
- cout << "altitude = " << alt << endl;
- cout << "sea level radius = " << slr << endl;
- cout << "latitude = " << lat << endl;
- cout << "longitude = " << lon << endl;
+ SG_LOG(SG_FLIGHT, SG_WARN,
+ "altitude = " << alt);
+ SG_LOG(SG_FLIGHT, SG_WARN,
+ "sea level radius = " << slr);
+ SG_LOG(SG_FLIGHT, SG_WARN,
+ "latitude = " << lat);
+ SG_LOG(SG_FLIGHT, SG_WARN,
+ "longitude = " << lon);
//return;
}
[1] http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs#Misdirected_diagnostic_in_JSBSim.cxx
[2] http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/source/src/FDM/JSBSim/JSBSim.cxx?annotate=1.41 lines 428-431
[3] http://jsbsim.cvs.sourceforge.net/jsbsim/JSBSim/src/JSBSim.cxx?revision=1.13&view=markup lines 428-431
|
|
From: Jon S. B. <js...@ha...> - 2007-04-01 01:24:02
|
Does this patch work with JSBSim.cxx in FlightGear? If it does, then I don't
have a problem with including it in JSBSim.cxx in JSBSim CVS.
Jon
> -----Original Message-----
> From: fli...@li...
> [mailto:fli...@li...]On Behalf Of Ron
> Jensen
> Sent: Saturday, March 31, 2007 6:51 PM
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] JSBSim bug (was) weekly bug roundup
>
>
> On Sun, 2007-02-11 at 20:27 -0600, Jon S. Berndt wrote:
> > > 1.24 Misdirected diagnostic in JSBSim.cxx
> >
> > Was the fix for this applied to JSBSim.cxx in JSBSim CVS, too?
> >
> > Jon
>
> The wiki [1] says this bug is fixed in JSBSim, however that is not true.
> CVS for flightgear [2] matches CVS for JSBSim [3] and both still contain
> the code for dumping the error code to cout.
>
> I don't speak C++, but would this patch be an acceptable fix?
>
> Index: JSBSim.cxx
> ===================================================================
> RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/JSBSim.cxx,v
> retrieving revision 1.41
> diff -u -r1.41 JSBSim.cxx
> --- JSBSim.cxx 19 Mar 2007 16:37:36 -0000 1.41
> +++ JSBSim.cxx 31 Mar 2007 23:48:55 -0000
> @@ -425,10 +425,14 @@
> if (!cache_ok) {
> SG_LOG(SG_FLIGHT, SG_WARN,
> "FGInterface is being called without scenery below
> the aircraft!");
> - cout << "altitude = " << alt << endl;
> - cout << "sea level radius = " << slr << endl;
> - cout << "latitude = " << lat << endl;
> - cout << "longitude = " << lon << endl;
> + SG_LOG(SG_FLIGHT, SG_WARN,
> + "altitude = " << alt);
> + SG_LOG(SG_FLIGHT, SG_WARN,
> + "sea level radius = " << slr);
> + SG_LOG(SG_FLIGHT, SG_WARN,
> + "latitude = " << lat);
> + SG_LOG(SG_FLIGHT, SG_WARN,
> + "longitude = " << lon);
> //return;
> }
>
>
>
>
> [1]
> http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs#Mi
sdirected_diagnostic_in_JSBSim.cxx
[2]
http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/source/src/FDM/JSBSim/JS
BSim.cxx?annotate=1.41 lines 428-431
[3]
http://jsbsim.cvs.sourceforge.net/jsbsim/JSBSim/src/JSBSim.cxx?revision=1.13
&view=markup lines 428-431
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Fli...@li...
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
|
|
From: Ron J. <wi...@je...> - 2007-04-01 04:18:35
|
Jon,
In simple testing (taking off in my F4E, rolling inverted, and slamming
into the ground) this patch suppresses the messages as desired unless
"--loglevel=warn" is set. So yes, this patch seems to work with
FlightGear.
Perhaps someone could apply this to CVS in FlightGear as well?
Thanks,
Ron
On Sat, 2007-03-31 at 20:24 -0500, Jon S. Berndt wrote:
> Does this patch work with JSBSim.cxx in FlightGear? If it does, then I don't
> have a problem with including it in JSBSim.cxx in JSBSim CVS.
>
> Jon
>
>
> > -----Original Message-----
> > From: fli...@li...
> > [mailto:fli...@li...]On Behalf Of Ron
> > Jensen
> > Sent: Saturday, March 31, 2007 6:51 PM
> > To: FlightGear developers discussions
> > Subject: Re: [Flightgear-devel] JSBSim bug (was) weekly bug roundup
> >
> >
> > On Sun, 2007-02-11 at 20:27 -0600, Jon S. Berndt wrote:
> > > > 1.24 Misdirected diagnostic in JSBSim.cxx
> > >
> > > Was the fix for this applied to JSBSim.cxx in JSBSim CVS, too?
> > >
> > > Jon
> >
> > The wiki [1] says this bug is fixed in JSBSim, however that is not true.
> > CVS for flightgear [2] matches CVS for JSBSim [3] and both still contain
> > the code for dumping the error code to cout.
> >
> > I don't speak C++, but would this patch be an acceptable fix?
> >
> > Index: JSBSim.cxx
> > ===================================================================
> > RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/JSBSim.cxx,v
> > retrieving revision 1.41
> > diff -u -r1.41 JSBSim.cxx
> > --- JSBSim.cxx 19 Mar 2007 16:37:36 -0000 1.41
> > +++ JSBSim.cxx 31 Mar 2007 23:48:55 -0000
> > @@ -425,10 +425,14 @@
> > if (!cache_ok) {
> > SG_LOG(SG_FLIGHT, SG_WARN,
> > "FGInterface is being called without scenery below
> > the aircraft!");
> > - cout << "altitude = " << alt << endl;
> > - cout << "sea level radius = " << slr << endl;
> > - cout << "latitude = " << lat << endl;
> > - cout << "longitude = " << lon << endl;
> > + SG_LOG(SG_FLIGHT, SG_WARN,
> > + "altitude = " << alt);
> > + SG_LOG(SG_FLIGHT, SG_WARN,
> > + "sea level radius = " << slr);
> > + SG_LOG(SG_FLIGHT, SG_WARN,
> > + "latitude = " << lat);
> > + SG_LOG(SG_FLIGHT, SG_WARN,
> > + "longitude = " << lon);
> > //return;
> > }
> >
> >
> >
> >
> > [1] http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs#Misdirected_diagnostic_in_JSBSim.cxx
> > [2] http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/source/src/FDM/JSBSim/JSBSim.cxx?annotate=1.41 lines 428-431
> > [3] http://jsbsim.cvs.sourceforge.net/jsbsim/JSBSim/src/JSBSim.cxx?revision=1.13&view=markup lines 428-431
|
Thanks for helping keep SourceForge clean.
X