There is a Flightgear property called /sim/hitches/winch/automatic-release-angle-deg that can be used to simulate a safety feature built into modern gliders. If the cable angle gets too great during a winch launch, the hook will automatically release the cable. This usually happens when the glider gets almost on top of the winch at the top of the launch without releasing the cable.
Unfortunately winch launching has two separate implementations, one in Nasal for JSBSim, and another one in C++ for YASIM. The YASIM one does not implement this property so I wrote a patch to add this.
As discussed on the mailing list, make this more consistent with JSBsim.
We could still define common locations for these values as well, but
waiting on positive answer to that discussion on the ML.
when active does not touch the way the YASim jet calculates fuel flow, but separates out the afterburning component of thrust, calculates the TSFC of that component and uses the same method of fuel flow calculation for the afterburning component then adds it to the existing fuel flow
When inactive (atsfc doesn't exist or is zero) it just behaves exactly as before
I finally got around to testing this small patch thoroughly, and I'm satisfied that it doesn't affect anything else & works across many different versions (i've been testing it with current as it has changed over the last 7 months)
* Fixed the initial conditions settings (geodetic altitude is now correctly computed).
* FGLGear reports the time at which it detected a violent ground hit (aka crash)
* Doc update of the kinematic component
* TurboProp code cleanup with the removal of lots of obsolete/no-op members.
* Fixed the trim on ground algorithm. Now JSBSim aircrafts should no longer be 'dropped' on the runway at start.
* Removed a correction on the propeller induced velocity that was giving erratic results when the aircraft aero velocity is very small.
* Various source comments updates.
I didn’t know about this feature when doing the original CMake files,
we can use this to target header-file includes more precisely.
(Probably more cases exist that can be changed from global to target-
specific includes)
- because uiuc_warning_error always called exit(-1), it can be marked
no return, so Clang realises that when it’s used in the ‘else’
side of a parsing test, uninitialised variables in the enclosing
call site are safe.
(Requires Simgear update to define SG_NO_RETURN helper)
- consistent with pause (freeze), /sim/speed-up is now applied to the
dt value for all subsystems, not just the FDM and some instruments.
For example AI traffic can now be sped-up or slowed down.
- requires both an FGData and Simgear update.
* The Pitot angle can now be tweaked with the <pitot_angle> tag in the <metrics> block.
* The refuel rate is now configurable with the <refuel-rate> tag in the <propulsion> block.
* Fixed C++11 compliance. JSBSim can now be compiled with a C++11 compiler.
* Avoid a spurious mass report to be issued when resetting.
* Fixed the moments computation. Previously they were computed with the previous time step CG position.
* Fixed a bug where the CG update was delayed to the next time step when point masses location were modified via the FCS.
- Ability to modify the location of external forces via the property tree
- Ability to specify manually the inertia matrix of "point masses"
- Improvements of the water injection feature in the turbine code
write the vertical flight path to /orientation/path-deg
zero means level flight, positive angles climb
Also use SGD_DEGREES_TO_RADIANS (and vice versa) for double computations
instead of the float constants
Change the drag coefficient for fuselages along the Y and Z axes
(i.e. perpendicular to the fuselage's main axis) to use a fixed
value of 0.5. (The value can still be adjusted using the fuselage's
"cy" and "cz" XML attributes.)
For the Y-axis and Z-axis drag on fuselages, YASim originally used
a drag coefficient equal to:
(solver drag factor) * (fuselage length/width ratio)
This value turns out to be way too small for well-streamlined
aircraft, even those with long, narrow fuselages, and especially
so for those with short, stubby fuselages. Such fuselages are
streamlined in the X direction, but not along Y or Z.
0.5 is only a ballpark estimate, but it's reasonably close for the
common case of a fairly long fuselage with a round cross section. For
flat-sided fuselages, a larger value should be used, up to a maximum
of 2 for a slab-sided block. For short fuselages, the value should be
reduced to account for end effects. The fuselage's "cy" and "cz" XML
attributes can be modified to make such adjustments.
This fix won't affect straight flight much, but it should have a strong
impact on some maneuvers. For example, it will make slips more
effective and may make knife-edge flight easier on aerobatic aircraft
which should be capable of it.
Only aircraft which specify version="YASIM_VERSION_32" or newer are
affected.
This commit is in prepartion for the following commit, which is a bug fix for
Issue 1463 (YASim underestimates off-axis forces on fuselages).
Previously the solver would adjust the drag factor for all of an Airplane's
non-Wing Surfaces in one pass, with no attempt to distinguish Fuselage Surfaces
from the Surfaces for Gear and Weights. This makes it difficult to modify how
fuselage drag is calculated while leaving unaffected the drag for landing gear
and external weights.
Now the solver adjusts the drag for an Airplane's fuselages, landing gear, and
external weights in three separate passes. To do this, each Fuselage now has a
list of its Surfaces. The fuselage pass simply iterates through the list of
Fuselages, running through each Fuselage's list of Surfaces.
The Airplane's list of non-Wing Surfaces, "_surfs", is no longer used here, but
there may still be uses of it elsewhere.
Correct handling of fuselage's "midpoint" XML attribute so that the midpoint's
location matches the point assumed by all aircraft developers and YASim docs.
This means the fuselage won't be generated "back-to-front".
Also correct the variation of diameter for tapered fuselages so that both ends
of the fuselage narrow from the midpoint to the endpoints.
Before this, one end was narrowing from the endpoint to the midpoint, the
opposite of what was expected.
These changes affect both weight distribution and the distribution of lateral
aerodynamic forces.
user attribute "version" of the airplane element of the YASim config file
to define the version this config uses.
Example:
<airplane mass="1344" version="YASIM_VERSION_CURRENT">
Initially, the following can be used:
YASIM_VERSION_ORIGINAL - The original version of YASim as implemented up to
FlightGear 3.0.0
YASIM_VERSION_32 - The version of YASim implemented in FlightGear 3.2.x
(and the development version 3.1.x)
YASIM_VERSION_CURRENT - The current and latest version of YASim.
This is too destructive for many established things, so revert it.
Instead, make the FDM shell save /fdm state on postinit(), and
restore it on re-init (which reposition invokes).
Adds $FG_ROOT/Aircraft/Generic/JSBSim/{Engines,Systems} to the JSBSim
engines and system search paths. Internally JSBSim already searches
$aircraft_dir/Engines and $aircraft_dir/Systems.
A file in $aircraft_dir/{Engines,Systems} have higher priority than one
in the shared directories.
add checks against buffer overruns
CVE-2012-2091 mentions various buffer overruns in simgear and
flightgear. This patch addresses this issue in Rotor::getValueforFGSet().
From: Tom Callaway
As part of this, kill off the evil global FDM state, and avoid us
copying FGInterfaces (which is bad since it contains TiedProperties
and an FGGroundCache, neither of which are especially keen on being
copied). Will probably disable copy/assignment on TiedProperties in
a future commit.
"speed-up" can now also be used for slow-motion (i.e. 0.5 / 0.25 / ...)
or fractional speeds (3.141...). This was already working for instruments
(for replay) before, now it's also considered by FDM simulation.
The property /fdm/jsbsim/propulsion/engine/prop-induced-velocity_fps
gives wrong answers, and can become NaN under certain conditions. When thrust is
negative and forward velocity is small we can take the square root of a negative
number. This could occur, for example, when using reverse thrusters on landing.
The value comes out much too high when alpha is near 180, such as taxing with a
tail wind.
are the accelerations (forces) as felt from the pilot's perspective. This
combines the accelerations due to change in velocity vector and gravity.
Previosly the gravity part was right, but the body accelerations were being
transformed incorrectly. The error was very subtle and basically amounted to
the fact that inverting an axis of a vector before transforming it is not
equivalent to transforming the vector and then inverting that axis.
After this fix, pilot accelerations + gyro + gps can be fed into an external
kalman filter and it will converge properly (extra confirmation that there
was a problem and this fix corrects it.)
Replace SG_GENERAL by more specific log classes in many places.
Allow "," to separate logging classes (using "|" is odd on the
command-line).
Also add new option to make logging more useful for developers.
You can use:
--log-level=debug --log-class=environment
to only get environment debug messages, or
--log-level=debug --log-class=sound,ai
to only get debug messages related to the sound or AI subsystem.
1. The atmospheric properties of FG are not yet initialized when
JSBSim is initialized.
-> patch is quite basic and there may exist smarter ways to initialize
properly the environment before the FDM.
2. The Euler angles were initialized after the velocities.
3. The glide slope and rate of climb were ignored. Fixes all FDMs (YASim,
UIUC, JSBSim, etc.)
4. Some properties were instructed to re-use their previous value while
they should not.
5. Some bugs existed in JSBSim trim code. -> This bug has already been
fixed in JSBSim but the corresponding patch has not yet been applied to FG.
coordinated with and approved by Andy.
The lattice(x,y) arguments were being "WRAP()'d" but the WRAP() function
didn't make sense. Instead it was forcing the value to zero if it was
greater than the wrap limit. This was creating large areas of constant
values in the perlin noise maps which resulted in a "constant" turbulence
vector over time -- which is just weird.
Andy couldn't see any reason why the values should be wrapped and couldn't
remember any reason why the WRAP() function was set up like it was.
Andy wanted me to make sure and mention that he was INSANE when he wrote that
code (but now he's sane ... err, mostly.)
The internal solver of YASim which computes drag and lift
coefficients now actually uses the values configured in
the XML input file for approach fuel, cruise fuel and cruise
glide angle.
