-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Synchronous communication interface with LockStep #8
Comments
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). |
@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....) |
@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. |
@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.
This is inline with what GE Aviation has integrated into PX4 and have presented it in the PX4 dev summit: https://sched.co/cjNx |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@Jaeyoung-Lim super!, thanks for your short and clear remarks. |
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). 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:
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. |
@kaklik I have added a parallel workstream of enabling lockstep by directly integrating into jsbsim in PX4/PX4-Autopilot#15748 @lum-supakorn FYI |
Well done @Jaeyoung-Lim! |
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.
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. |
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.
The text was updated successfully, but these errors were encountered: