Bugs: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 363: Line 363:
legality and the practicality of performing instrument approaches
legality and the practicality of performing instrument approaches
under such conditions.
under such conditions.
In version 0.9.10 runway lights are turned on automatically in day time if visibility is low.
Though I agree, that pilot controlled lights could be a nice feature, but it's not a bug, it's wish list entry, I suppose.


==== Holes in the ground. ====
==== Holes in the ground. ====

Revision as of 22:14, 13 June 2007

Known Bugs

This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.

Incorrect altimetry.

There is evidently at least one serious misconception in the code that calculates atmospheric pressure, altimeter settings, et cetera. This can be easily demonstrated:

Park at or near the threshold of runway 33 at Aspen (KASE). Under standard conditions, observe that the altimeter reads 7820 feet MSL, as it should.

Use the Weather : Weather Conditions dialog popup to look at the ground-level altimeter setting (QNH). This is bottom row in the "Alt (inHg)" column of the popup. Verify that it is 29.92.

Now use the dialog box to change this property. Change it to 30.92, a one-inch difference.

Go to your altimeter instrument and enter the new altimeter setting in the Kollsman window. Ideally, this should cause the instrument to read the correct altitude once again, namely 7820 feet MSL.

However, due to bugs, it is likely that you will observe something closer to 8120. This means the airplane is 300 feet lower than the altimeter says it is.

In case it wasn't obvious, when flying around near Aspen, being 300 feet lower than you think you are can be very bad for your health.

The absolutely correct formulas for computing the altimeter setting are derived and explained on the jsd altimetry page.

A patch to fix the altimeter has been offered.

Altimetry misnomers and misconceptions.

Both the Weather Conditions popup and the atis.cxx code rely on the "pressure-sea-level-inhg" property and use it in ways that the altimeter setting should be used.

For some people this may be merely a misnomer, but for others it is clearly a misconception, as recent events have shown.

The fact is, the altimeter setting is not the same thing as the pressure at sea level (Psl), especially when the airmass has a non-standard temperature profile. The altimeter setting is something else; it is properly called the altimeter setting. It is also properly called the QNH, although private pilots who fly only in the US may be unfamiliar with the QNH terminology.

In the Remarks section of a METAR, you can sometimes find the Reduced Sea Level Pressure, which is unfortunately denoted SLP. This METAR SLP serves the same function as the altimeter setting. Despite its name, the METAR SLP is not equal to the honest-to-goodness pressure at honest-to-goodness sea level (Psl), as discussed in more detail on jsd altimetry page.

There needs to be a facility whereby routines that need the altimeter setting can obtain the altimeter setting.

Correct altimetry formulas may be found on the jsd altimetry page.

Existing code sometimes treads the "pressure-sea-level-inhg" property as if it were Psl, and sometimes as if it were METAR SLP. All this needs to be vetted.

Newton's laws violated by environment.cxx

Consider the following results of an experiment using fgfs:

 alt:  662  mM: 0.0288  P: 99000.8462  T: 286.8563  rho: 1.1975
 alt: 3462  mM: 0.0288  P: 89341.6721  T: 281.3920  rho: 1.1009
 
 alt:  662  mM: 0.0289  P: 99000.8422  T: 256.9910  rho: 1.3404
 alt: 3462  mM: 0.0289  P: 89341.6740  T: 252.0956  rho: 1.2333

The first pair of lines represent before and after a simple flight from one airport to another, with a net gain in altitude of 2800 feet, under standard conditions. So far so good.

The second pair of lines represent exactly the same flight, except that the ambient temperature was 30 degrees colder than before. You can see that the density (rho) is greater, in accordance with the ideal gas law.

The problem is that the delta_P is exactly the same for the two flights. This is a problem because P is connected to the weight of the air column. If the air is 12% denser, the laws of physics require it to have a 12% steeper pressure gradient dP/dh ... but alas this is not observed.

This incorrect pressure profile P(h) has many consequences affecting engine performance, airfoil performance, altimetry, et cetera.

Z-buffer burn-through.

Sometimes distant objects can be seen through nearer objects that are not supposed to be transparent. For example: Runway lights sometimes burn through a solid cloud layer. Also runway lights sometimes burn through aircraft structure. Some instruments burn through the yoke.

It seems that so-called "2D" objects in the background are likely to burn through "3D" objects in the foreground. This is particularly noticeable in aircraft that have a mixture of 2D and 3D instruments.

The position in space of the offending objects is OK, as you can verify by shifting your PoV to get a little bit of a side view. The obvious hypothesis is that the Z-order is being mishandled in a Z-buffer somewhere.

Memory leak.

The simulator will gobble up about 3 gigabytes of virtual memory overnight, while paused. Without the leak, the memory footprint would be less than 300 meg. The difference between 300 meg and 3 gig is quite significant on machines that have only 1 or 2 gig of main memory.

A rather steady leak of 2 meg per minute is observed during pause, no matter whether the aircraft is aloft or parked on the ground. Vastly less leakage (two orders of magnitude less, possibly zero) is observed when the simulator is not paused, and the aircraft is simply sitting on the ground with the parking brake set.

This bug has been observed in multiple versions of fgfs, including one compiled back in May, 2006 as well as the most current CVS version.

This is 100% reproducible with a ATI RV350 [Mobility Radeon 9600 M10] chipset and the ati-fglrx driver. The leak is observed whether or not OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.

Numerous bugs in ATIS feature.

1) The ATIS is supposed to change whenever there is a significant change in the weather. The comments mention this, but the code makes no attempt to implement this.

2) The code assumes that ATIS is prepared on the hour. In practice this is virtually never the case; a new ATIS is prepared hourly, but not on the hour. Also this assumption is inconsistent with ATIS changes based on the weather.

3) The code attempts to issue a station identifier, but none is heard.

4) Multiple departures from standard phraseology.

5) The volume is too low; ATIS is not readable over engine noise. This defeats much of the purpose of ATIS. The volume does not respond to the /instrumentation/comm[N]/volume property.

6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.

x) Et cetera.

A patch to fix a few dozen ATIS bugs is available, but has not been incorporated into FG CVS.

Problems with --altitude option.

When the aircraft is initialzed aloft using the command-line --altitude=6000 option, 0.9.10 is observed to put up a blank screen (no scenery, no panel) and to spew on the console page after page like this:

 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
        nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..
 altitude         = -1.69132e-41
 sea level radius = -6.54575e-42
 latitude         = 6.9874e-316
 longitude        = 6.79737e-313
 OpenAL error (AL_INVALID_VALUE): set_pitch
 OpenAL error (AL_INVALID_VALUE): set_volume

Multiple bugs in the location-in-air popup.

The location-in-air popup turns off the magnetos and extends the landing gear. Some pilots and flight instructors deem this to be undesirable behavior, especially if all they are trying to do is relocate from one airborne position to another.

Similarly, it strongly perturbs the throttle setting, aileron trim, elevator trim, rudder trim, view angles, PoV position, and who-knows-what else. Again, people who know about airplanes consider this to be undesirable behavior.

There is also a tendency to place the aircraft into dangerous unusual attitudes, and other bugs too numerous to mention.

Evidently, though, there is at least one person who likes things the way they are. Code that would have fixed these bugs was rejected. Neither specific nor constructive criticism of the code was offered. For details see the flightgear-devel mailing list archives.

Nearest fix.

Did you know that there are 8 different BRAVO intersections in the database?

Until now there was no support in the code for this; all but one of the entries was thrown away at the lowest level. There is a comment in the code saying that fixing this is on the TODO list.

As for navaids (as opposed to waypoints), the low-level code already provides support for ambiguous IDs, but the information is not being used very wisely by the higher layers.

Code to fix these problems was offered to the community. So far it has been completely ignored.

HSI instrument failure.

If you use the "heading indicator" checkbox on the "instrument failure" popup to command a failure, it has no effect on the HSI instrument used by many aircraft in the simulator fleet.

This is because of wrong code in hsi.xml.

Backend code to handle this correctly exists, but has apparently never been used. It needs one small fix, followed by recompilation. A patchset to take care of all this was offered to the community, but has not been incorporated.

Flux gate not really a flux gate.

In the Instrumentation director, there are three heading-related .cxx files.

  • heading_indicator.cxx : vacuum driven, with drift
  • heading_indicator_dg.cxx : electrically driven, with drift
  • heading_indicator_fg.cxx : electrically driven, no drift

The "fg" in "heading_indicator_fg" is documented to stand for "flux gate", as if the heading were slaved to a flux-gate compass ... but the code does not implement any such thing. All it really does is initialize the indicated heading to the correct magnetic heading value, and then implement a no-drift policy. This is incorrect behavior, as can be seen by flying to an area where the magnetic variation is different from what it was at the start of the flight. A true slaved heading indicator would gradually accommodate the new magvar.

The correct behavior ought to be easy to implement.

Weird noises during initialization.

It is observed that sometimes while the simulator is starting up, before things are fully operational, weird noises are produced. For example, in the c182rg, gear-in-transit noises are produced for several seconds before the first display becomes visible. (According to a dump of the relevant variables, there is no evidence that the gear is actually in transit, and no reason why it should be.)

Code to fix this was submitted. So far it has been ignored.

Weird displays during fullscreen initialization.

If the --enable-fullscreen command-line option is used, the window is enlarged to full-screen size at a time when initialization is only half-complete. From this time until the end of initialization, the display contains weird combinations of leftover graphic objects and other junk.

This is observed no matter whether the splash-screen feature is enabled or disabled.

Fullscreen window sometimes misplaced.

About 20% of the time, when the --enable-fullscreen command-line option is used, it opens a window of the correct size, but badly misplaced relative to the screen, such that only one half or one quarter of the window is on-screen.

Navigation databases out-of-date

The database of navigation waypoints and fixes has an internal date of early 2005. It is missing quite a few useful fixes. The FAA has defined quite a few new approaches in recent years, and has revised others.

An updated version, based on a pull of the much more current x-plane database, was made available. So far it has been ignored.

Similar remarks apply to the navaids database.

Ident from phantom DME.

In the real world, some VOR stations and even some localizers have a colocated DME station ... but there are plenty that don't.

The DME has its own Morse ident, with a distinctive higher pitch.

In the simulator, due to a bug in the code, all stations transmit the DME Morse ident ... even stations where no DME is present.

The code in navradio.cxx finds the nearest VOR or LOC on the frequency, and checks to see if it is in range. It also asks for the "nearest" DME on the frequency, but makes no attempt to check that it is in range. To say the same thing the other way, there is no attempt to check that the aircraft is within the service volume of the DME. Since there is almost always a DME /somewhere/ on the frequency, the has_dme variable will always be set true.

For a demonstration of this bug, park at KAOO airport and tune up the AOO VOR (which has no DME). Or park at almost any airport and tune up the localizer (since relatively few localizers have DME).


Airport lighting in poor weather.

The code in tileentry.cxx turns on airport lights according to the position of the sun relative to the horizon. One consequence is that the lights are off during the day.

In real life, there are many circumstances where airport lights, including approach lights, are turned on during the day. At tower airports, the lights are turned on during bad weather -- including weather that is only slightly bad -- and also turned on if requested by the pilot. For details, see [FAA Order 7110.65p].

At non-towered airports, the lights are usually pilot-controlled, via radio.

The absence of lighting during daytime in poor weather detracts significantly from the realism, because it affects both the legality and the practicality of performing instrument approaches under such conditions.

In version 0.9.10 runway lights are turned on automatically in day time if visibility is low. Though I agree, that pilot controlled lights could be a nice feature, but it's not a bug, it's wish list entry, I suppose.

Holes in the ground.

Ever since the first win32-build of FG-OSG, there are at least two huge ground scenery holes in the the Rhine/Main/Neckar-region in Germany. The first one gapes at the place which was formerly known as the city of Mannheim (near the airport EDFM, which is still there), the second one has swallowed up a big piece of Frankfurt am Main (near EDDF) and surrounding land.

First posted to the flightgear-devel list in November, 2006.

Mixture versus Altitude.

It is observed in the default c172p and in the c182 that at high altitude airports (e.g. KGCN or KASE), to obtain max static RPM, it suffices to move the mixture control only a few mm aft of the full-forward (full-rich) position.

This is unrealistic. In a real aircraft under such conditions, it would be necessary to pull the mixture control back about an inch to obtain max RPM.

It's hard to say whether the carburetor is underreacting to the altitude, or overreacting to the mixture control.

EGT reads high.

It is observed in the default c172p and in the c182 that the EGT reads toward the high end of the scale under all conditions, including idle. This is unrealistic.

Also, the EGT reads off-scale high under high-power conditions.

Flags missing from instruments.

Some of the standard instruments lack status flags. For example, the GS needle goes to mid-scale if there is no valid signal. That'll kill you for sure. Reportedly the hi-res instruments implement flags, but the lo-res ones don't. Many aircraft are using the lo-res instruments.

Either the aircraft should be upgraded to use instruments that display flags, or the instruments should be upgraded to be display flags.

Problems with --model-hz option.

Specifying the --model-hz=10 command-line option results in the following mess:

 Model Author:  Unknown
 Creation Date: 2002-01-01
 Description:   Cessna C-182RG
Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml
 Sorry, wdot doesn't appear to be trimmable
Trim Failed
 Trim Results: 
      Angle of Attack:   7.50  wdot:  3.21e+01 Tolerance: 1e-03  Failed
             Throttle:   0.50  udot:  0.00e+00 Tolerance: 1e-03  Passed
           Pitch Trim:   0.00  qdot: -5.44e-11 Tolerance: 1e-04  Passed
 Model Author:  Unknown
 Creation Date: 2002-01-01
 Description:   Cessna C-182RG
altitude         = -1.18461e-41
sea level radius = -4.87596e-42
latitude         = 6.98923e-316
longitude        = 6.79738e-313
altitude         = -1.18461e-41
sea level radius = -4.87596e-42
latitude         = 6.98923e-316
longitude        = 6.79738e-313
altitude         = -1.18461e-41
sea level radius = -4.87596e-42
latitude         = 6.98923e-316
longitude        = 6.79738e-313
WWarning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
    [many repeats]
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
altitude         = 9
sea level radius = 4.62829e-268
latitude         = 1.52075e-314
longitude        = -0.0967923
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
        nan nan nan -inf inf -inf segment ignored..
altitude         = -1.18461e-41
sea level radius = -4.87596e-42
latitude         = 6.98923e-316
longitude        = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
        nan nan nan -inf inf -inf segment ignored..
altitude         = -1.18461e-41
sea level radius = -4.87596e-42
latitude         = 6.98923e-316
longitude        = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
        nan nan nan -inf inf -inf segment ignored..
altitude         = -1.18461e-41
sea level radius = -4.87596e-42
latitude         = 6.98923e-316
longitude        = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
        nan nan nan -inf inf -inf segment ignored..
altitude         = -1.18461e-41
sea level radius = -4.87596e-42
latitude         = 6.98923e-316
longitude        = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
        nan nan nan -inf inf -inf segment ignored..
altitude         = nan
sea level radius = nan
latitude         = nan
longitude        = nan

and so forth.

  • Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.

CPU hogging.

The fsgs program will happily eat up >98% of the cpu cycles, even when the simulator is paused. That seems excessive, particularly during pause. This is on a 2GHz machine with hardware acceleration. As a point of reference, glxgears uses only a fraction of one percent of the cpu.

  • This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)

Out-of-bounds array reference in JSBSim

This is in the interpolation table code.

This bug has been fixed in the [SF CVS] version of JSBSim.

Memory leak in JSBSim

This is in the "message" handling code.

This bug has been fixed in the [SF CVS] version of JSBSim.

Glideslope service volume.

The code in navradio.cxx appears to assume the glideslope service volume is the same as the localizer service volume. This is quite unrealistic.

Extended service volume.

In some parts of the world, 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 was ignoring the service volume information in the database and wrongly assuming the default values applied everywhere. Code to fix the range-related part of the problem has been offered but not yet incorporated.

Other service volume issues.

The code in navradio.cxx 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.

A patch to fix this (along with the ESV issue) has been offered, but ignored.

There are also azimuthal issues with the /glideslope/ service volume. This has not yet been patched.

Menu buttons having a get-together.

This concerns "radio buttons" on menus, such as on the location-in-air popup and elsewhere. By definition, it should be impossible to have more than one radio button pushed down at a time. However, illegal situations of this sort can be created using a click-and-drag gesture. Aim at a radio button, hold the mouse-button down, and drag ... as if you wanted to drag the radio button to a new location. This allows you to set a radio button without the others being unset. If you persist, you can have every one of the buttons in the pushed-down state at the same time.

Before you say, "well, don't do that then" or "garbage in, garbage out", let me point out that it is possible for a pilot to inadvertently make a tiny dragging gesture when intending only a click. Also, when the desired button is in the pushed-down state, it is easy to not notice that other buttons are in the undesired state.

Altimeter setting unreadable.

The standard altimeter (used by the default c172p aircraft and many others) had been using an unhappy hodgepodge of layers. The analog Kollsman window was unusable, because it was unlabeled, and the digital altimeter setting was unusable, especially at altitudes near 2500 feet, partly from being behind the needle. On a real altimeter, things are positioned so that cannot happen.

Fixing this requires using a more suitable font, moving the digits over, and getting rid of conflicting extraneous markings.

A patch to implement this fix has been offered.

Memory mismanagement in subsystem_mgr.

It is bad luck to apply "delete" to an object that was not created with "new" ... as in line 219 of subsystem_mgr.cxx

A patch is available, but has not been incorporated.

Yet more memory mismanagement.

When FG is trying to exit, it is very likely to abort with a message such as

 *** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***

There are at least three different instances of this bug, each producing a different traceback. Here is one such traceback:

  1. 0 0xb7573947 in raise () from /lib/tls/libc.so.6
  2. 1 0xb75750c9 in abort () from /lib/tls/libc.so.6
  3. 2 0xb75a908a in __libc_message () from /lib/tls/libc.so.6
  4. 3 0xb75b094f in _int_free () from /lib/tls/libc.so.6
  5. 4 0xb75b09f2 in free () from /lib/tls/libc.so.6
  6. 5 0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6
  7. 6 0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766
  8. 7 0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93
  9. 8 0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93
  10. 9 0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105
  11. 10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237
  12. 11 0xb75764f0 in exit () from /lib/tls/libc.so.6
  13. 12 0x080919c7 in fgExit (status=0) at util.cxx:120
  14. 13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224

Missing Features and Traps for the Unwary

Version number, please.

It would be helpful to have an easy, documented way to ascertain the version number. A --version option on the command line would be nice. Maybe also a help::about menu item, for use while fgfs is already running.

One could imagine that info about key libraries would also be helpful.

Rabbits extinct.

In the real world, many airports have sequenced flashers (aka the rabbit) as part of the approach-light system.

In the FlightGear world, the sequenced flashers are inoperative everywhere. Grepping through the code suggests that no attempt has been made to implement this.

No comm volume control.

In many aircraft including the default c172p, the comm radios have no volume control knob. In other aircraft including the pa24-250, there is such a knob, but it apparently isn't clickable and apparently doesn't do anything.

In contrast, the SenecaII exemplifies the desired behavior: the knob rotates when clicked and correctly controls the /instrumentation/comm[N]/volume property. (This alas has no effect on the volume of ATIS audio, but that must be considered an ATIS bug not a Seneca bug.)

Incomplete Scenery.

Installing scenery from the Stockill Database without installing the shared models, will get you messages such as the following:

 Failed to open file .../data/Models/fgfsdb/localizer.xml
 Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml
 Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml
 Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml
 Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml
 Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml

You might get only a few such messages, or you might get screenful after screenful.

So, make sure you download all scenery files that are needed for fgfs.

This obviously counts as a trap for the unwary.

- This is patently not a bug and should be moved to a "tips" section or similar. The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...

ASOS and AWOS are AWOL.

At many non-tower airports (and even some tower airports) there is automatic weather reporting of some kind.

It ought to be straightforward to implement this, as a slight variation on the existing ATIS feature.

Roundoff problems with textranslate step and scroll.

The textranslate animation is delightful for 3D animation of mechanical drum-type displays as on old-fashioned odometers and Hobbs meters.

It is not, however, a convenient way to implement digital readouts. It works OK for integers, but the code in apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the ".1" in 122.1 MHz, particularly when the scroll-value is zero.

  • One workaround is to stick to integers, e.g. integer kHz

rather than fractional MHz.

  • Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.
  • A final option (with CVS) is to use the bias tag to let the code know how to

handle round-off. Use a bias value of 1/2 your smallest step value, and use the same bias value on all digits.

What we really need is a whole new support routine for dealing with 3D digital displays, something at least as nice as the support for 2D instruments.

Broken startup banner.

On startup, the simulator prints Author: Unknown and prints a bogus Date.

The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.

Fixed Bugs

If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).

Wild accelerations at low speeds.

Improper inclinometer ball indications have been observed:

  • When parked, the ball was pegged to one side.
  • When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.

This was observed in the c182 model and in the default c172 model.

Tracing indicates that the problem is not within the slip_skid_ball.cxx code, but rather upstream of there, in the flight dynamics. Tracing shows that the y-accel-fps_sec values are wildly fluctuating in direction, and enormous in magnitude.

Additional evidence pointing to the FDM comes from the fact that the problem is observed with JSBSim and not with larcsim (although larcsim has other problems, such as drifting slowly sideways while parked).

This is important from a procedures training point of view. If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi. In a real aircraft, a pilot who found the inclinometer pegged would cancel the flight before even starting the engine.

Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:

  • velocities/vdot-fps
  • velocities/a-pilot-y-ft sec2
  • velocities/n-pilot-y-norm
  • This bug has been fixed.

Misdirected diagnostic in JSBSim.cxx

The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout. This made both the log and the console record hard to interpret.

  • This bug has been fixed.

Linux and perhaps Windows crashes when specifiying --lon or --lat

The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.

Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)

  • This bug has not been observed in 0.9.10.

0.9.5 - 0.9.8 - Windows - Crash on start reporting "Could not gen source"

Any further reports or stacktraces on this bug would be appreciated. Workround: Launch two copies of FGFS in quick succession: one should work. You may need three. Update your sound card drivers.

  • This bug has been fixed in 0.9.8a

0.9.7 - ? Linux - Joystick crash with correct config files

Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.

  • This bug has been fixed.

See Also

Individual Aircraft

Bugs associated with a particular aircraft should be listed on the aircraft's ToDo page, not here.

OpenSceneGraph

There is a separate page for issues related to OpenSceneGraph.