jsbsim-team / jsbsim Goto Github PK

The "starter", "cutoff" and "seized" engine properties are not exposed
to JSBSim tree. The ones under "/engines/engine[*]" of FlightGear are
boolean and do not accept other data types.

This means if engine control system is written in JSBSim, it has no
clean way of outputting to those properties, especially because JSBSim
can not output bools.

I have to rely on external logic to convert those values and pass them
to FlightGear properties, which makes the engine control code fragile.

In Class FGColumnVector3, in the function of Overload constant equal sign whitch it uses "==" to judge double, I think this is not right.

We need diagrams of the up-to-date class hierarchy in JSBSim.
If someone did ever generate in the past a set of documentation files (Doxigen?), this is a good chance to revamp the procedure.
Class hierarchy graphics will go into the Programmer's Manual as well.

Intro

In addition to the discussion that is on going on PR #38, @djlinse made some comments on the original PR #33. But since PR #33 is closed, I have created this new issue and copied Dennis' comments here so that we can keep track of the discussion.

Below are Dennis' comments (I fixed the layout a bit. Especially the URL which was not interpreted as a link by GitHub)

Discussion

1. As far as I've been able to tell (and I may be wrong!), the equations are only valid until the boundary of the troposphere and tropopause, i.e. 11000km/36089 feet. They appear to be Eqn 17, the "Simpler Method of Calculation..." for density altitude given in the extended discussion (with multiple examples/calculators) found here: https://wahiduddin.net/calc/density_altitude.htm

Note that the Standard Atmosphere is dry air, i.e. 0% humidity.

As FGStandardAtmosphere goes all of the way up to 86km, this addition should either complete the calculations correctly for all altitudes, or clearly note where they are valid and where they aren't valid.

2. Even if correct, I would suggest that the constants (518.xxx, etc.) be written as constants (with units as a comment), otherwise they are just magic numbers. Preferably with a reference to textbook or maybe the Standard Atmosphere document itself.

3. Is PressureAltitude the correct altitude to use here? Even if it is identical to altitude in the current code, that may not always be the case.

4. Code structure-wise, I wonder if a "better" way to implement the Density altitude would not be to override the GetDensityAltitude() method from FGAtmosphere, but rather use the already existing DensityAltitude variable, and have the base class Calculate() method call

DensityAltitude = CalculateDensityAltitude(altitude);

instead of just setting it to DensityAltitude = altitude. The base class would then have a virtual method

virtual double CalculateDensityAltitude(const double altitude) {return altitude;}

And similarly for pressure altitude.

Sean's new function would then be CalculateDensityAltitude() with the altitude passed in ("solving" the pressure altitude question). And the getter functionality would just be getting the current density altitude, as is typically expected for getter functions.

If you don't want to make this change, then at least set the DensityAltitude variable.

I have a multi-engine aircraft and I was trying to script a throttle increase for all engines in a script. So I tried the following:

    <event name="Increase Throttle">
      <description>Increase throttle to max</description>
      <condition> simulation/sim-time-sec >= 1.0 </condition>
      <set name="fcs/throttle-cmd-norm[-1]" value="1" type="FG_RAMP" tc="2" />
    </event>

However that results in an exception being thrown:

throw string("unterminated index (looking for ']')");

If I refer to all the engines individually then the script works as expected, e.g.

    <event name="Increase Throttle">
      <description>Increase throttle to max</description>
      <condition> simulation/sim-time-sec >= 1.0 </condition>
      <set name="fcs/throttle-cmd-norm[0]" value="1" type="FG_RAMP" tc="2" />
      <set name="fcs/throttle-cmd-norm[1]" value="1" type="FG_RAMP" tc="2" />
    </event>

Now FGFCS::SetThrottleCmd() has explicit code to handle an index of -1.

void FGFCS::SetThrottleCmd(int engineNum, double setting)
{
  if (engineNum < (int)ThrottlePos.size()) {
    if (engineNum < 0) {
      for (unsigned int ctr=0; ctr<ThrottleCmd.size(); ctr++)
        ThrottleCmd[ctr] = setting;
    } else {
      ThrottleCmd[engineNum] = setting;
    }

However it looks as if the parsing code used by the script while processing <set> elements doesn't support negative index values.

/**
 * Parse the optional integer index for a path component.
 *
 * Index: "[" [0-9]+ "]"
 */
static inline int
parse_index (const string &path, int &i)
{
  int index = 0;

  if (path[i] != '[')
    return 0;
  else
    i++;

  for (int max = (int)path.size(); i < max; i++) {
    if (isdigit(path[i])) {
      index = (index * 10) + (path[i] - '0');
    } else if (path[i] == ']') {
      i++;
      return index;
    } else {
      break;
    }
  }

  throw string("unterminated index (looking for ']')");
}

Is this limitation an oversight/bug or is this by design in terms of script events explicitly not supporting negative indices?

Hi yall, I'm one of the c172p contributors with quite a few hours in real c172's and trying to get it closer to the real thing.

One issue I noted was that the peak power is quite a ways away from where it "ought" to be according to the lycoming o320 / o360 power curves. From the bug I opened on the c172p project:

Hi! I might be entirely wrong, but it seems like our Cessna has a wrong "best power" lean settings compared to the Lycoming manuals. From their charts it looks we should get "max power" at about 130F rich of peak EGT, while my experiments in the sim give me max power at around 250F rich of peak EGT. The sim also seems to be losing power faster than my (anecdotal) real life experience of leaning the C172.

Trying to fully understand the calculations in FGPiston isn't very easy, but I think I may have figured out why this is: The Mixture_Efficiency_Correlation table seems to be centered on 12.6, which is where gasoline piston engines get their most power. I think it should have been centered on 14.7, which is where the fuel burns the best. With the old code, I was getting peak power at ~10 AFR. When trying to crudely just shift the table so that it's centered at 14.7, I'm now getting peak power at ~12AFR (as expected), and the EGT for peak power is indead ~150 degrees F less than it's peak at 14.7 AFR. "Peak economy" also suddenly makes sense, previously flying at 15AFR gave way too little power.

Now there's a lot of calculations and constants in the code that I don't understand, so I might be totally off, and I won't be sad if you tell me I'm wrong. If it's possible to tweak the parameters to our c127p so that it matches real life better with the current code then that's fine. I just can't find those parameters and the simplest way to make it match my understanding better is to center the MEC at 14.7. (Aka 0.068)

I've crudely painted in the power curve I'm getting today (ish) vs what we should be seeing (ish) here:

This is tested using flightgear next 64f3c1, which is a week old and right after @bcoconni synced jsbsim in.

I'm with the University of Minnesota's UAV Research Lab. I'm modifying Flight Gear's Rascal model to fly with altered properties derived from an OpenVSP simulation. When running JSBSim, it looks like everything goes well until we reach the aerodynamics section of the aircraft xml file, showing "FATAL ERROR: JSBSim terminated with an unknown exception." I'm fairly sure there's something I'm missing while creating the tables, because it will parse when I replace the tables with the value of 1.

As a side note, the breakpoints used in the aerodynamic tables are velocities in meters per second. Is there a way to use those units in JSB, or must I adjust before creating the aircraft file?

Any help is appreciated!

Best,

Louis Mueller

RascalModel.zip

@bcoconni @agodemar If I'm a random JSBSim user and not familiar with our CI setup the info you see on the Releases section can be confusing/misleading.

In particular it currently states:

bcoconni released this 19 days ago · 67 commits to master since this release 
JSBSim-trusty-v2018a 
 e5cc599 

So to me this implies that the release is built using code that is 67 commits behind the head of the master branch. Plus the hash listed on the left e5cc599 also doesn't refer to the latest commit to the head of the master branch.

I downloaded JSBSim.exe to confirm my understanding that it should match the latest commit based on our CI setup of pushing the latest build to the Release.

C:\Users\Sean\Downloads>.\JSBSim.exe

  JSBSim version 1.0.0 [build 179/commit 93f89276968a223aa0bc8e3e34fc9f32f70f1fd3] Jun 18 2018 15:26:06

  Usage: jsbsim [script file name] [output file names] <options>

And sure enough due to the very useful addition of the commit hash as part of the version info I can see that this executable has been built using the latest commit from yesterday, i.e. it isn't 67 commits behind the master branch.

If we don't want the misleading info does this mean we need to publish a new Release for every commit? And can this be automated as part of the CI process, with some complication I'm guessing in terms of coordinating the two CI builds?

We should define our set of coding style rules and apply them consistently throughout the sources. This implies a code review, better if with automatic tools.

Something along the lines of this guide by Google might work.

Ideas?

I have manually deleted a bunch of older releases. At the moment we have only the release tagged 1.0.0-152. We should decide our release policy and automate it via Travis and AppVeyor.

Tentative proposal:

1. Make a new release every time we have a new commit. Delete the previous one (or keep only the current and the previous one).
2. Make a new release every time a given flag is set (in the commit text or elsewhere). Delete the previous one (or keep only the current and the previous one).
3. Make a new release every 6 months. Delete the previous one (or keep only the current and the previous one).

Ideas?

Since around FG 2018.1, "atmosphere/P-sl-psf" seems to no longer reflect weather changes.

I had been using it in a hack to keep abrupt jumps in atmo pressure from disturbing my autopilot (as discussed in this thread: https://sourceforge.net/p/flightgear/mailman/message/36299722/), but now I had to throw on more epicycles, see history of the channel "Aero/atmosphere kludge" in this file:

https://gitlab.com/mdanil/Tu-144/blob/master/Tu-144-jsbsim/functions.xml

We could provide users with the results of our automatic build. The binaries could be downloaded via the "Release" section of this GitHub repository. Having both Linux and Windows binaries (x64) would be nice.

There is a number of outdated files or redundant data currently in the code base.

Files to delete

• .cvsignore since we are no longer using CVS
• JSBSim.cbx since Borland C++ builderX is abandoned
• JSBSim.vcproj since we are no longer working Microsoft Visual Studio earlier than 2015

Redundant files

• INSTALL which contains information redundant with README.md

Unless someone objects I will remove them from the code base

Since JSBSim has moved to CMake and having realized that the autotools no longer work, I guess we no longer need to maintain them. To make things clean I suggest to delete all the obsolete files in JSBSim main directory.

Regarding Visual Studio, Microsoft has included CMake to VS2017 and everything builds like a breeze. So according to @bcoconni suggestion we should drop VS support at some point and just keep CMake alone.

Is there a good reason why we should not deprecate a Python version which will not be supported in the future?

This test fails while comparing the initial condition specified for phi in reset00.xml and the value returned from fdm['ic/phi-deg'] for the mk82_script.xml.

In script mk82_script.xml: phi should be 0.000000 but found 90.000000

The initial conditions in reset00.xml are:

<phi unit="DEG">         0.0000  </phi>
<theta unit="DEG">       90.0000  </theta>
<psi unit="DEG">         0.0000  </psi>

Placing a breakpoint in the python test these are the results when inspecting the 3 attitude angles:

fdm['ic/phi-deg']  90.0  
fdm['ic/psi-deg']  0.0  
fdm['ic/theta-deg']  90.0

I then set a breakpoint in FGInitialCondition::Load_v1() with JSBSim executing the mk82_script.xml.

After reading in the XML elements phi, theta and psi:

vOrient - {0.00000000000000000, 1.5707963267948966, 0.00000000000000000}

Which is as expected. The Euler angles from vOrient are then converted into a Quarternion.

orientation = FGQuaternion(vOrient);

orientation - 
data: {0.707, 0.000, 0.707, 0.000}
mCacheValid: false  
mEulerAngles: {0.000, -0.000, 0.000}

Now I execute the following in the debugger:

orientation.GetEulerDeg(ePhi)  90.000000000000000
orientation.GetEulerDeg(eTht)  90.000000000000000
orientation.GetEulerDeg(ePsi)  90.000000000000000

And orientation now:

orientation - 
data: {0.707, 0.000, 0.707, 0.000}
mCacheValid: true  
mEulerAngles: {1.5708, 1.5708, 1.5708}

So a couple of questions.

Why the apparent difference between the test passing on Linux (as per Travis logs) and failing on Windows?

Why the difference between the Python results for the attitude angles and the results I get in the debugger from C++ with all 3 now 90 degrees?

Is this a singularity case? But even so why the differences?

We can provide JSBSim bindings to other languages, such as

• Python
• Matlab
• Java
• Julia

The bindings would come as Application Programming Interfaces (APIs), that is, wrapper libraries that bridge between a set of selected internal JSBSim C++ functions/data structures and other programming languages. This enhancemnt would expand the usability of our software.

I am aware of automatic workflows, driven by Python scripts, that produce bindings for different languages. The automation is based on functions and class attributes in the C++ library. As an example,

• here is TiGL software by the German DLR
• here is TiGL folder where bindings are stored
• here is the binding generator software

edit by @bcoconni: Added Julia to the list.

The documentation for setting up a SITL simulation using ArduPilot (ArduPlane) and JSBSim, found at

http://ardupilot.org/dev/docs/setting-up-sitl-on-linux.html#setting-up-sitl-on-linux

points to the following version of JSBSim:

www.github.com/tridge/jsbsim (updated last Feb 2016)

and only has minor modifications (includes a stepping function) to

www.github.com/arktools/jsbsim (updated last Dec 2012)

Any advice on how to use the latest JSBSim to use with ArduPilot? Any advice is appreciated.

edit: and a quick link to the file that "communicates" with JSBSim

https://github.com/ArduPilot/ardupilot/blob/master/libraries/SITL/SIM_JSBSim.cpp

I have an aircraft with 2 engines and I wanted both engines to be started by the initialization file. Looking at FGInitialCondition.h I saw the following comment:

// - running (-1 for all engines, 0 for no engines, 1 ... n for specific engines)

So I added a running element to my initialization file.

<running> -1 </running>

However neither of the engines are started.

I then also noticed that the code in FGInitialCondition.cpp looks for multiple running elements, and based on the comment above - 1 … n for specific engines I tried the following based on the comment regarding 0 and 1.

<running> 1 </running>
<running> 2 </running>

However that only results in engine 1 being started and engine 0 isn't started. Engines are 0 based, from FGFDMExec.cpp

  for (unsigned int n=0; n < propulsion->GetNumEngines(); ++n) {
    if (IC->IsEngineRunning(n)) {
      try {
        propulsion->InitRunning(n);
      } catch (const string& str) {

So looking at the code in FGInitialCondition.cpp.

  // Check to see if any engines are specified to be initialized in a running state
  Element* running_elements = document->FindElement("running");
  while (running_elements) {
    enginesRunning |= 1 << int(running_elements->GetDataAsNumber());
    running_elements = document->FindNextElement("running");
  }

I then tried the following which now does start both engines (0 and 1).

<running> 0 </running>
<running> 1 </running>

So assuming that the engine indices to the running elements should be 0 based then the comment in FGInitialCondition.h needs to be updated.

// 0 for no engines, 1 ... n for specific engines)

And the code needs to be fixed to properly handle the -1 option.

I'm happy to make the fixes, but before I do I just wanted to double-check whether the engine indices in the running elements should be 0 or 1 based.

The Jupyter notebooks that we want to use to narrate workflows with JSBSim are located in jsbsim/doc subfolder, e.g. in jsbsim/doc/basic we have 01_JSBSim_Setup.ipynb.

Jupyter is launched from command line as follows:

$ jupyter notebook

Then, through the browser, the user navigates the .ipynb notebook files and opens one of her choice. When the notebook is run the Python kernel should be able to find all the classes located in jsbsim/tests, e.g. JSBSim_utils.py.

I am writing a Python (3.6) application which wraps an instance of JSBSim.

I would like to retrieve a list containing the simulation property catalog, and am trying to use the wrapper method query_property_catalog(self, check) for this. This method accepts one arg, check: str.

However, calling this method with any string (empty or non-empty) raises a TypeError with the following trace:

Traceback (most recent call last):
  File "~/dev/gym-jsbsim/test/query_props_minimal_example.py", line 11, in <module>
    properties = fdm.query_property_catalog('ic/')
  File "jsbsim.pyx", line 512, in jsbsim.FGFDMExec.query_property_catalog
  File "stringsource", line 15, in string.from_py.__pyx_convert_string_from_py_std__in_string
TypeError: expected bytes, str found

Trying to call the function with a bytes object of a string encoded in UTF-8 raises the error TypeError: a bytes-like object is required, not 'str'.

I found a similar issue in another project which suggested the problem may be related to string encoding changes Python 3.6.

Here is a minimal example which reproduces the issue:

import jsbsim

fdm = jsbsim.FGFDMExec(root_dir="/your/root/dir/jsbsim-code")
fdm.load_model('c172x')
fdm.load_ic('reset00', useStoredPath=True)
fdm.run_ic()

# empty string raises TypeError: expected bytes, str found
properties = fdm.query_property_catalog('')
# non-empty string raises same
properties = fdm.query_property_catalog('ic/')
# byte encoding of empty string raises TypeError: a bytes-like object is required, not 'str'
properties = fdm.query_property_catalog(''.encode('utf-8'))

I cannot find any usage of query_property_catalog() in the existing Python tests.

I am on Ubuntu 18.04 using Python 3.6, Cython 0.28.3, JSBSim built from cc9beb7 and the JSBSim Python3 library installed from release python3-JSBSim_1.0.0-184.trusty.amd64.deb.

Considering the relevance of the Boost libraries in the C++ community, and considering the amount of functionalities it provides, are there good reasons why we should not depend on them?

Hi,

I have noticed that the following functions would be very useful to have for system development, especially navigation system:

• floatng point equivalent of . For now I have snippets like this to make up for it:

    <product>
     <fraction>
      <product>
       <p>example/input</p>
       <v>0.5</v><!-- reciprocal second arg of mod -->
      <product>
     </fraction>
     <v>2.0</v><!-- second arg of mod -->
    </product>

• sawtooth from -180 to +180 degrees like geo.normdeg180() from FlightGear: http://wiki.flightgear.org/Nasal_library/geo . Without it I ended up with this black magic in many places:

    <difference>
     <product>
      <fraction>
       <product>
        <sum>
         <p>example/input</p>
         <v>180.0</v>
         <product>
          <lt>
           <p>example/input</p>
           <v>0.0</v>
          </lt>
          <v>-360.0</v>
         </product>
        </sum>
        <!-- = 1/360 -->
        <v>0.00277777777777777777</v>
       </product>
      </fraction>
      <v>360.0</v>
     </product>
     <v>180.0</v>
     <product>
      <lt>
       <p>example/input</p>
       <v>0.0</v>
      </lt>
      <v>-360.0</v>
     </product>
    </difference>

• sawtooth from 0 to 360 degrees like FlightGear's geo.normdeg(), which is like floating point modulo by 360, except it should be shifted by 360 for negative input:

    <sum>
     <product>
      <fraction>
       <product>
        <p>example/input</p>
        <v>0.00277777777777777777</v><!-- = 1/360 -->
       </product>
      </fraction>
      <v>360.0</v>
     </product>
     <product>
      <lt>
       <p>example/input</p>
       <v>0.0</v>
      </lt>
      <v>360.0</v>
     </product>
    </sum>

Kind regards,
Mike

Heads up

The sources are here: https://github.com/JSBSim-Team/jsbsim-reference-manual

The rendered website is here: https://jsbsim-team.github.io/jsbsim-reference-manual

Hello and thanks for the great project. Unfortunately I am falling at the first hurdle: I cannot run any simulations.

$ JSBSim --aircraft=ball --initfile==reset00

JSBSim Flight Dynamics Model v1.0 May 30 2018 09:53:30
            [JSBSim-ML v2.0]

JSBSim startup beginning ...

Could not open file: Path "aircraft/ball/ball.xml"
  JSBSim failed to open the configuration file: Path "aircraft/ball/ball.xml"
  JSBSim could not be started

I have tried sudo privileges and specifying the root dir:

$ JSBSim --aircraft=ball --initfile==reset00 --root=~/Apps/jsbsim-code/
...
JSBSim failed to open the configuration file: Path "~/Apps/jsbsim-code/aircraft/ball/ball.xml"
...

Despite the fact that the files are clearly there in the specified root:

$ ls ~/Apps/jsbsim-code/aircraft/ball/
ball.xml  INSTALL  reset00_v2.xml  reset00.xml  reset01_v2.xml  reset01.xml

Same story for other aircraft (X15, 737). I am running a fresh install of Ubuntu 18.04. JSBSim was built and installed as per the repo instructions from latest commit b4dd258, with the DINSTALL_PYTHON_MODULE=ON flag. All tests run successfully (which means the simulations run perfectly happy from Python, so I am at a bit of a loss). Many thanks in advance for any help!

I'd like to be able to pip install the JSBSim python module.

In particular I've been trying to install it as part of an Azure Notebooks which is a Linux based container.

It appears that the only methods they support for installing additional Python modules is via either pip install or conda install.

Installing Python Packages to Azure Notebooks

I had tried via shell access to download the .deb and unpackage the .so file into the notebook directory since that had worked in the past for me on Windows, i.e. simply having the .pyd in the same directory as the notebook. But it didn't work. Also tried copying it to a couple of other locations without success.

And lastly I tried installing the .deb package using dpkg but that requires root\sudo which isn't supported in Azure Notebooks.

So I think the ideal would be to have a Wheel .whl file available that can be used by pip install?

Establish a set of Jupyter notebooks to show how JSBSim can be used for engineering simulations. The notebooks will be based on JSBSim interface for Python 3, i.e. the same that we use for unit testing.
Here's a list of fundamental tasks:

• Establish a folder to collect all notebooks. Subfolders are encouraged in order to explore with ease both input and output files.
• Draft a list of examples covering as many use cases as possible.
• Enjoy the results of each single example!

Here I collect the main points of a previous discussion in a closed PR #72 .

The idea
The idea comes from this research article demonstrating how JSBSim can be used to run flight simulations in presence of a gust field pre-calculated with OpenFOAM. This is what I do:

• The chosen aircraft model is flown through a volumetric CFD mesh. Each node in the grid owns three cartesian components of the local wind.
• At each step of the FDM propagation, JSBSim sends the aircraft actual position (lat, lon, agl-altitude) to an external server application on an output TCP socket.
• JSBSim blocks time propagation and waits for server reply.
• The server reads and transforms the received geographic position in a triplet of Cartesian coordinates then accesses the velocity field associated to the mesh and calculates the local wind velocity by interpolation.
• The server sends back on the same socket (in that case) the wind velocity.
• JSBSim sets the new values of the properties: atmosphere/wind-north-fps, atmosphere/wind-east-fps, and atmosphere/wind-down-fps.
• The FDM propagation continues.

Configuration
The O/I can be configured via the <output/> and <input/> tags as follows:

<!-- e.g. in file scripts/C1723.xml -->
<output name="localhost" type="SOCKET" port="1138" rate="20" file="unitconversions.xml">
  <property> position/lat-gc-deg </property>
  <property> position/long-gc-deg </property>
  <property apply="convert-ft-To-m" caption="position/h-agl-meters"> position/h-agl-ft </property>
</output>
<input type="SOCKET" port="1139" />

Strategy

The server application (OpenFOAM server) should do most of the work. By design, the OpenFOAM server has to manage asynchronously several running instances of JSBSim (e.g. hundreds, or thousands) providing them the wind data according to aircraft positions in the flow field.

On the initial iteration of the sim loop the JSBSim input socket doesn't have an incoming connection yet, it's still waiting for a connection. So it doesn't block in this case it simply returns.

Then at the end of the first iteration of the sim loop the output socket sends the initial aircraft state to the OpenFOAM server. The OpenFOAM server on receiving this initial incoming connection now knows the IP address of JSBSim and so it then creates a connection to the input socket (with some configured port number, i.e. 1139) that is waiting for connections. And it sends back it's first set of wind velocities.

So now on the next iteration of the sim loop the input socket will be connected and it will issue a blocking read to retrieve the OpenFOAM set commands for the wind velocities etc. and will process them and return allowing the sim loop to now continue in lock-step with the OpenFOAM server.

Issue
Glancing at the socket code a bit it looks like currently for the input socket case the socket passed to the accept() API is set to non-blocking, so it won't block waiting for a connection. The socket passed to the recv() API is also set to non-blocking after a successful accept().

For the OpenFOAM case/example it is not critical that the very first sim loop iteration needs data from the OpenFOAM server.

There may be some cases where it is critical that JSBSim has to receive the input data from the external server on the very first simulation loop iteration. To handle that case we could potentially have multiple flags for the input socket which specify blocking versus non-blocking for the accept() and the recv() calls independently.

So for the OpenFOAM example one would leave the accept() as non-blocking but set recv() blocking. For another server where the initial data is critical one would set both accept() and recv() to blocking. In which case JSBSim would start up but block until the external server connected and sent the first packet.

The set_debug_level(level) method is intended to allow control of JSBSim output. Setting to level=0 "...requests JSBSim not to output any messages whatsoever" (FDFDMExec docs).

When using an output socket for visualising JSBSim with FlightGear, several messages print to console even with set_debug_level(0). Here is a minimal example using the Python API:

import jsbsim
import os


# init JSBSim and load basic config
root_dir = "/your/root/dir"
fdm = jsbsim.FGFDMExec(root_dir=root_dir)
fdm.set_debug_level(0)
fdm.load_model('c172x')
fdm.load_ic('reset00', useStoredPath=True)

# set socket output using preconfigured flightgear.xml file
output_file = "data_output/flightgear.xml"
output_config_path = os.path.join(root_dir, output_file)
fdm.set_output_directive(output_config_path)

fdm.run_ic()

This prints two distinct messages:

Creating UDP socket on port 5550
Successfully connected to socket for output ...

This vehicle has 6 bogeys, but the current
version of FlightGear's FGNetFDM only supports 3 bogeys.
Only the first 3 bogeys will be used.

Any reset of the simulation to initial conditions (e.g. fdm.reset_to_initial_conditions(0)) will cause a repeat of these messages. The first message appears to originate from FGfdmSocket and the second from FGOutputFG. I regret I don't know C++.

In my use case I am running many trials in JSBSim, so the above behaviour results in my console becoming unusable as it is spammed with tens of thousands of lines!

It would be great if these outputs and related messages could be suppressed, for example by making them check the debug level before printing. Perhaps more generally, it would be nice if there was a way suppress all JSBSim output entirely from the Python API (since even set_debug_level(0) will still miss some JSBSim launching text and various warnings).

##In these months I am working at FIAT G91-R1B in FGFS in collaboration with Massimiliano and the friends and former pilots of the G91 group of FB.

I am currently learning to use JSBSim as deeply as possible while removing all the NASAL code I can delete. The reason is that I would like to have a prevailing code in JSBSim that being a data-driven language fits better in my working method (I often use simulation programs like Open-modelics and I myself worked many years ago in the development of a CSMP interpreter in APL).

Obviously in the Flightgear group the collaboration is very poor as few people have a deeper knowledge of JSBSim, many of them think that JSBsim is very heavy in execution.

I am currently working in the electrical system which is starting to work well, and it seems to me that it clearly demonstrates the advantages of using JSBSim in place of NASAL (I am replacing the NASAL code I had written in the previous months with JSBSim). In fact, using a script language like NASAL (but it would be the same thing with Python and Java) it is necessary a continuous use of events and timers, this makes the system weighed as these processes pass through the operating system and the virtual machine. Moreover, NASAL tasks can not define shared variables as they are all separate processes. This requires using external calls to an object called a "property tree". In JSBSim the situation seems to me much better and so it seems to me natural to write in JSBSim everything related to on-board systems (The G91 was conceived in the mid-50s' and therefore many systems are analog).

Sorry for the introduction a bit 'long, but now I pass to more specific questions:

1#. According to your knowledge of the code JSBSim does an optimization of block processing by performing, for each step, only the blocks that have had at least one input modified with respect to the previous step? (It was on of the most powerful optimization criteria I had developed for the interpreter CSMP in APL)?
2#. There are logical blocks (I have only seen the switch), such as a JK flip-flop, (although these days I saw that it is possible to emulate it with a switch used in sample-hold mode ...), but his presence would simplify the code and improve his reading.
#3. I'm using the useful function execrate = "n" where n is a number of intervals between one execution and another of a channel. But I noticed a boring bug, that is, if there is a time-dependent block inside its value dt is not modified (should be multiplied by the execrate value present in the block) so as to make this function transparent and therefore be able to vary execrate without having to intervene in the code. On the contrary, it would be interesting to have a variable execrate depending on some event, since certain blocks must be executed frequently only in certain phases of the flight.
#4. For the performance of JSBSim I can not complain because it is actually very fast and therefore consumes little CPU, but currently the tasks that I give are not many, I would like to know if someone has analyzed the performance problem with more depth, to understand the better optimization criteria.
#5.In Flightgear JSBSim runs in the same system thread, but being a separate application, with its own data that are exchanged only through a specialized process ... it would be very interesting to be able to run it on a separate thread, in order to use a different CPU . At this point the extended use, I would say aggressive, of JSBSim in Flightgear would be very interesting.

Thank you for your cooperation, greetings to the whole group that manages this wonderful program.

When building tests based on Python 3 we have this error now.

Currently, our AppVeyor builds fail due to the fact that build execution times reach the maximum allowed time of 60 minutes for a free plan. The long build time is probably due to the Python integration tests. On Travis the build time is far less: 4 different builds in 45 min (including tests), more or less.

I propose, for the moment, to disable Python tests on AppVeyor, to make sure that our builds terminate gracefully with a deploy of the artifacts in our Release area on GitHub.

Hi, I would like to start some JATO (solid fuel) engines I made for the G91-R1B in Flightgear. If I start the engines by setting the parameter in a NASAL program:

setprop("controls/engines/engine[1]/throttle", 1);

Is all ok, the engine start and end the propulsion when finish the solid propellant.

But i I try by this command in JSBSim code:

        <switch name="fcs/throttle-cmd-norm[1]">
            <default value="0"/>
            <test logic = "AND" value = "1">
                systems/jato/ignition-on == 1
                systems/jato/rocket_number_1 == 1
            </test>
        </switch>

Where:
systems/jato/ignition-on == 1
This is the flag that activates the ignition of the engine from the panel in the cabin. This flag lasts a couple of seconds because, as in reality, the solid fuel engine is started by means of an electro-activated pyrotechnic ignition device.
The:
systems/jato/rocket_number_1 == 1
is the flag that guarantees to start only that specific motor (in G91 there were 4 JATO of 1000 lib)

Honestly I do not understand where I'm wrong, can you help me?
Thank for the collaboration :)

@algefaen wrote:

Hehe, nope, still very strange. If I'm on the ground and have a gentle crosswind from the left and give full power, it lifts the nose gear entirely off the ground and rests against the tail. If the crosswind is from the right, it pushes the nose to the ground, and even managed to lift one of the main gears. It seemed to cause some weird slipping effect in the air as well. This P-factor-effect of crosswind component that affects the pitch axis seems entirely out of whack. I'm guessing there's an oversight in JSBSim where they use the angle between "air flowing through the propeller vector" vs "propeller vector" and don't account for the amplitudes - a tiny crosswind of 3kts should have almost no effect, but it does.

@bcoconni wrote:

It does not come as a surprise to me since the P-factor effect in JSBSim is using the tangent of the angle which, as we all know, is infinite when then angle is equal to 90°. I guess we can use the sinus of the angle instead but I would prefer to discuss the details on the JSBSim project page

FGPropeller.cpp (lines 254 - )

   // P-factor is simulated by a shift of the acting location of the thrust.
   // The shift is a multiple of the angle between the propeller shaft axis
   // and the relative wind that goes through the propeller disk.
   if (P_Factor > 0.0001) {
     double tangentialVel = localAeroVel.Magnitude(eV, eW);
 
     if (tangentialVel > 0.0001) {
       double angle = atan2(tangentialVel, localAeroVel(eU));
       double factor = Sense * P_Factor * angle / tangentialVel;
       SetActingLocationY( GetLocationY() + factor * localAeroVel(eW));
       SetActingLocationZ( GetLocationZ() + factor * localAeroVel(eV));
     }
  }

As much as I can understand, the
angle = atan2(tangentialVel, localAeroVel(eU))
is a kind of generalized AoA (in a plane rotated around the U direction)
(correct?)

The Y-axis lever arm for the P_factor
factor * localAeroVel(eW)
with
factor = Sense * P_Factor * angle / tangentialVel
comes down to
Y-lever arm = Sense * P_Factor * angle * localAeroVel(eW) / tangentialVel

In this case (stopped aircraft with pure crosswind),
localAeroVel(eW) / tangentialVel = 1,
angle = Pi/2
Is it too much, and enough to give this exaggerated pitch moment? Possible, the angle factor in flight is normally less than 0.3 rd.
Anyway, not a mathematical divergence (like tg(Pi/2)).

There is normally a U-velocity contribution to the P_factor effect (for obvious reasons). This might be a a way to cancel it when stopped on the ground, but what factor? A reduced (dimensionless) speed? Proportional or with saturation?

In "normal" operation (flight), angle is small ==> the Y-lever arm proportionality with angle seems correct.
In a simplified calculation (I don't know if it applies with your code), I found a sin(AoA) proportionality but for this issue it would change Pi / 2 for 1 (not enough for this issue).

All of this for what it's worth and if it can help, but I've probably not seen something.

If the two-dimension calculation is too complicated, taking only the (usual, which gives a yawing contribution) pitch AoA cause is much easier. That might be sufficient for most conditions when this effect is felt.
My current understanding (to be confirmed) is that a proportionality to aircraft sin(AoA), RPM and velocity would be a good enough approximation (neglecting the difference in blade AoA due to this asymmetric flight).
But this would change the code, uneasy to be compatible with the already done aircraft.

fcs/{left,right}-brake-cmd-norm drive the brake groups directly. And
they are command properties, written to by FlightGear controls. That
means there is no way to model brake serviceability and brake
regulator/antiskid entirely in JSBSim without relying on external
logic and fragile hacks.

Case in point: in Tu-144 I had to make external aliases
fcs/{left,right}-brake-inp-norm for FlightGear controls, and overwrite
the -cmd- props with the tag of the brake logic's final
function, because it somehow refused to work if I put it directly in
its name="" instead.

On FlightGear mailing list I was suggested to take -brake-cmd-norm as
input in some function and also put of the same function
there. That would probably work, but it is unobvious to whoever might
discover this code later. Moroever it can break if something in the
way properties are handled changes.

Looking at the ISO C++ Standard current status and considering the support of major compilers to the various standards, a question comes naturally: Shall we consider adopting the newest, consolidated, C++ features?

For those who have not set up their Cython LD_LIBRARY_PATH but otherwise follow the directions on the build page, all the tests will mysteriously fail with missing module 'jsbsim' etc. I fixed this on my machine with a prefix environment variable such as

LD_LIBRARY_PATH="/home/xxxxxx/Documents/GitHub/jsbsim-code/build/src/" ctest -j6

or

LD_LIBRARY_PATH="/usr/local/lib/" ctest -j6 

after I had done make install. Of course, all the tests then passed!

It took me quite a bit of googling and messing around to figure this out, so I thought it might be helpful to save others the trouble by mentioning an appropriate fix in the build doc.

Whilst JSBSim itself is LGPL 2.1, the python files in the tests folder are marked "version 3." Because these versions are quite different, it means that some developers will have to remove these files to avoid license issues. It might be worth a comment about this in the License section of the top-level README to help people avoid license accidents.

Is there a better way to program repetitive chains of functions than
simply copypasting?

For example, here I had to do a lot of copypasta for each pump and valve, and
now if I decide to fix something I will have to do it all over again:

https://gitlab.com/mdanil/Tu-144/blob/master/Tu-144-jsbsim/propulsion/fuel.xml

And is there a way to include a system passing some XML entities to
it in the tag? The way I have to handle repetitive
systems now is creating multiple files and editing the entities
manually, which is tedious and error prone, like:

https://gitlab.com/mdanil/Tu-144/blob/master/Tu-144-jsbsim/propulsion/RD-36-51A_0.xml
https://gitlab.com/mdanil/Tu-144/blob/master/Tu-144-jsbsim/propulsion/RD-36-51A_1.xml
https://gitlab.com/mdanil/Tu-144/blob/master/Tu-144-jsbsim/propulsion/RD-36-51A_2.xml
https://gitlab.com/mdanil/Tu-144/blob/master/Tu-144-jsbsim/propulsion/RD-36-51A_3.xml

I have been looking for the proper XML way on and off, and realised I
don't even know what question to search to get info about how the
'something="something"' part of XML tags is related to entities.

Hi,

Sorry, I'm not sure that the subject of my question is a bug (hard to believe after such a long time), but I don't know where to place it. The problem seems so simple that I don't know where to look at.
Prior to disturbing you, I've posted in the FG forum (Development ‹ Aircraft ‹ Flight dynamics model) to insure that I was not doing a mistake but I've had no response.
https://forum.flightgear.org/viewtopic.php?f=49&t=34376

In the propeller file, the
<p_factor> number </p_factor>
seems having no effect, even at high RPM and AoA angles. (I've done tests on two different single-engine aircraft, having different propeller files)

I've tried p_factor values up to 10000, which should give a very exaggerated yaw effect, at no avail.

An excerpt of my test file (c172p):
(attention: the c172p already has a spiralling propwash effect, which preferably should be zeroed to isolate this P-Factor effect. Property: /fdm/jsbsim/aero/coefficient/spiral-propwash-coeff = )

File excerpt:

<propeller name="NACA 640 (5868-9) 76-inch 20deg Two-Blade Propeller" version="1.01">

<ixx> 1.67 </ixx>
<diameter unit="IN"> 76.0 </diameter>
<numblades> 2 </numblades>
<p_factor> 60 </p_factor>

<table name="C_THRUST" type="internal">
    <tableData>
        0      0.1040
        0.1    0.1040
        (etc...)
    </tableData>
</table>

<table name="C_POWER" type="internal">
    <tableData>
        0      0.0660
        0.1    0.0650
        (etc...
    </tableData>
</table>

</propeller>

I could not find a property which would enable me to check the effect in-sim.

I tried understanding it by doing the math calculation (based on velocity-vector additions) simplified for a pure-AoA aircraft disorientation but, very possibly due to my more than basic knowledge of C++, I couldn't understand the FGPropeller.cpp code at SF.net (lines 254-).
The only thing that is clear for me: "the effect is simulated by a shift of the acting location of the thrust".
After that, I think it should be proportional to the aircraft velocity, propeller RPM, AoA (small angle approximation).

Thank you if you can help, and sorry if that's my fault.

Daniel Dubreuil

There has been several occurrences of a failure of TestInputSocket during the builds made by Travis CI (builds 58.1, 59.1, 60.1 have failed but 62.1 and 57.x have succeeded).

• The source code tested by TestInputSocket has not been modified by the commits that triggered the builds mentioned above so these builds were expected to succeed.
• The failures only occurred when the test was run by Python 2.7 (the same tests succeeded when they were run by Python 3.6)

My experience while running TestInputSocket is that these failures are due to a race condition. The test is using 2 threads:

1. The first thread runs a JSBSim instance
2. The second thread runs a telnet instance

The test consists in checking that the 2 threads are capable of exchanging information via a socket.

Despite the usage of 2 threads, this tests is not really based on multithreading due to Python GIL. Despite the GIL, some thread synchronization incantations are needed to get the expected result. This synchronization seems to randomly fail with Python 2.7.

With the recent checkins to support Python 3 I'm now able to build the Python module and also run the Python tests using VS2017 and it's CMake support.

However all the Python tests currently fail due to an issue with the cleanup mechanism used in the Python tests.

Basically the Sandbox class executes shutil.rmtree() to cleanup the temporary sandbox directory. However this fails since there are still files open, e.g. output.csv so it fails on Windows with a message that it can't delete the file since a process has the file open.

If I tell shutil.rmtree() to ignore errors then the test passes.

These 2 lines should also probably be swapped around in JSBSimTestCase.tearDown() otherwise it may fail on Windows even if there are no open files inside the sandbox directory.

self.sandbox.erase()
os.chdir(self.currentdir)

So we'll need to come up with a reliable mechanism on Windows to cleanup the temporary sandbox directory.

I've discovered a weird behavior, for which unfortunately I (currently) have no solution to propose. I'm afraid it will not be easy.

Conditions:

• Aircraft at rest on the runway, brakes (or parking brake) "ON",
• Pure crosswind (bearing close to + / - 90 deg from the nose, from left or right). 3kt may be enough, 10 - 15 kt worsens the effect. Possibly enough to lift the nose gear up.

Observations:
Cmalpha oscillates, instead of being positive steady for a front wind, or negative but steady for a rear wind. The values of cmalpha do not seem significant, nothing happens if they are steady.
EDIT:
(C172P)
Oscillations also appear if I cancel Cmalpha (<value>0 in the FDM). Maybe in a narrower angle range, +/-1 deg around crosswind.
I observed that Cmadot took high values (+4000, -1000). Then, I canceled Cmadot too, and the oscillations were still here. Even with only 3 kt crosswind.
Of course, I checked that Cmalpha and Cmadot values were 0 as expected in the jsbsim/aero/coefficient Properties for the last test.
/EDIT

Aircraft tested: (engine stopped)
C172P,
SenecaII PA34,
DR400-JSBSim,
Boeing 707 Lake of Constance.

Even with engine stopped, for several aircraft with propeller or a jet aircraft ==> the p-factor is not the cause.

Dany

At the moment, the JSBSim Python module is using underscore separating convention for methods name whereas the C++ code using CamelCase.
For example, the C++ method FGFDMExec::LoadModel is named FGFDMExec.load_model in the Python module.

The plan would be to move all the Python methods name to CamelCase convention just as the C++ code for consistency.

@seanmcleod and @WillemEerland since you have reported to have successfully built and used the Python module, would that change be acceptable to you ?

In fixing issue 75 which related to an issue with Python 3 string incompatibility with query_property_catalog() I tested get_property_catalog() and noticed that it crashes the process.

Internally get_property_catalog() calls query_property_catalog().

    def get_property_catalog(self, check):
        """
        Retrieves the property catalog as a dictionary.
        """
        catalog = {}
        for item in self.query_property_catalog(check):
            catalog[item] = self.get_property_value(item)
        return catalog

The issue is that the property names returned by query_property_catalog() have a read-write status string appended to them, e.g. 'ic/vc-kts (RW)'.

And the call to get_property_value() crashes if this read-write status string is included, e.g.

fdm.get_property_value('ic/vc-kts')
0.0
fdm.get_property_value('ic/vc-kts (RW)')
--crash

So we need to remove the read-write status before calling get_property_value().

@bcoconni Opening a new issue as requested. More information following when I have access to MacOS.

OK thanks for the report. It seems that TestInputSocket fails for a reason different from a race condition on your system. Could you open a separate issue to address this topic ?

And in the meantime could you please check that the following lines of Python code raise a socket.error exception on your platform as well ?

import telnetlib
telnetlib.Telnet("localhost", 1137, 2.0)

It should be smooth enough for Windows users to build the Python/Cython part of JSBSim that produces tests. Instructions for those who have Anaconda or similar environments installed would be nice.

I think that the file AUTHORS, besides the more specific references to the creator and architect JSB, should contain a plain list of names (and GitHub IDs if applicable). This might be enough to acknowledge the various contributions to the software library. Emails or addresses risk to become outdated with time.

Ideas?