Synchronous communication interface with LockStep

[kaklik]

The actual implementation is limited by the update rate of the property tree available through the FG generic protocol. Unfortunately, the update rate is limited by the FPS rate of the graphics engine.

The graphics engine is unable to output regularly sampled data, the implementation is therefore limited to use no lockstep mode.

The FlightGear supports several other communication interfaces. The most promising is probably the HLA.

[kaklik]

The one the most straightforward possible solution could be running the FDM externally (JSBsim, Yasim, Gazebo, etc..) and connecting it to FlightGear. The FlightGear has already support for that.

The main question is how all that glue-together, without the creation of FDM-specific codes for interfacing the different FDMs with PX4. (This is the one reason why the current implementation of PX4-FlightGear-Bridge uses FDM-neutral PropertyTree interface).

[slimonslimon]

@Jaeyoung-Lim @lum-supakorn - I think, that the best method for connecting FG and PX4 is to create a "module" in FG, which will be exactly locked with FG FPS will communicate with PX4, and can do lockstep (FG is the single thread). This bridge can be removed. But I don't know, how to write a "module" into FG. Do you have some experience with this?

(But when I started with connecting FG and PX4 I found "generic protocols" and I was happy that I can communicate with FG without understanding and changing its source code....)

[lum-supakorn]

@slimonslimon I do not have any experience working with either JSBSim or FG, but I'm looking to help. We should keep each other up to date.

[Jaeyoung-Lim]

@slimonslimon @lum-supakorn @kaklik

I have been looking into this too, and IMHO I think a better direction is to use FightGear as a visualizer and interface PX4 directly with JSBSim using the MAVLink HIL messages.

• We need to be able to speed up the simulation faster than real time for CI tests, therefore, we should not rely on rendering rates
• Once we rely on rendering rates, we cannot run the simulation in headless mode which is quite valuable
• With this architectural decision we keep the possibility of using a better visualizer / renderer than flight gear for future applications

This is inline with what GE Aviation has integrated into PX4 and have presented it in the PX4 dev summit: https://sched.co/cjNx

[kaklik]

Hi @Jaeyoung-Lim

what GE has integrated

GE - denotes for what?

[Jaeyoung-Lim]

@kaklik Updated my comments and links

[slimonslimon]

@Jaeyoung-Lim super!, thanks for your short and clear remarks.

[kaklik]

I had seen the presentation from GE Aviation. I do not know if there are some sources for example which they presented. But I think that implementation do not help us very well. It is because they are focused only on JSBsim, which is a data-driven simulation engine (Well they generated virtual Wind-tunnel data by OpenVSP). Is there somebody who tried to make the FDM model in JSBsim? I tried it several times and I could say it is rather complicated, compared to YASim or Gazebo (especially in cases at the beginning of new air-frame development where real parts are not available yet). But also I think the correct development way is to make the simplified Gazebo/Yasim model and after that go to a more realistic but, empirically adjusted JSBsim model.

Therefore we need an opportunity to seamlessly simulate the same vehicle (with different FDMs) in the same environment by multiple simulation engines (Gazebo, YASim, JSBsim, etc.). If I sort that engines by the currently or implementation limited achievable FDM realism from best to worst, this list should look like:

1. JSBsim, XPlane (Data-driven simulation. e.g. lookup tables)
2. YASim (Aerodynamically, explicit simulation)
3. Gazebo, AirSim (Simplified aerodynamic in favor of less computational demand or focus to visual attractivity)

Unfortunately, I do not see any easy solution for that, because the YASim, for example, does not have a standard communication interface, which allows it to run in as "external FDM". This is a point why @slimonslimon noted that we should interface by some protocol directly to FG, where the YASim and JSBsim interface is solved. Another option is to interface each FDM engine to PX4 separately by a different interface. But I do not know how it should be maintained in the long-term.

[Jaeyoung-Lim]

@kaklik I have added a parallel workstream of enabling lockstep by directly integrating into jsbsim in https://github.com/PX4/Firmware/pull/15748

@lum-supakorn FYI

[slimonslimon]

Well done @Jaeyoung-Lim!

[kaklik]

To summarise the actual situation; there exist two main FlightGear relevant FDM engines, which both the current implementation of PX4-FlightGear-Bridge is able to interact.

• YASim - currently embedded in FlightGear source code But has advantage of very easy desing of FDM of new airframes.
• JSBSim - which could be now able to be run separately by PX4-jsbsim-bridge

Running YASim embedded in FlightGear is currently, the only way to simulate the YASim model is controlled by PX4 Firmware. This use case does not allow the use of "lockstep" by principle. It is because the FDM cycle is coupled to framerate in FlightGear. There would be a game-changing feature, if someone separate the YASim source code into a standalone application like JSBSim. That version of YASim should be interfaced with PX4 by something like PX4-YASim-bridge.