HITL & X-plane 11 & QGroundControl

@Jaeyoung-Lim I hate to piggyback on an old thread but can you explain where the idea of

comes from? Xplane allows you to set the udp rate higher and I was able to get 100+ fps and udp rate of ~70Hz on my moderate spec desktop using the Ardupilot SITL implementation. When I rolled back to an older version of QGC and PX4 the HITL simulation seemed to be working on initial glances. So was it deprecated from lack of use or is there something else I’m misunderstanding?


Xplane allows you to set the udp rate higher and I was able to get 100+ fps and udp rate of ~70Hz on my moderate spec desktop using the Ardupilot SITL implementation.

I am not sure if you are implying that the faster UDP rate speeds up the physics, but I was under the impression that Xplane physics is locked in with the rendering rate. (Please let me know if I misunderstood what Xplane is doing). Therefore you will not be able to simulate something significantly faster than 60 FPS. If you managed to get 100+FPS I guess that is close to the limit you will be getting.

To give you context, lockstep based simulators such as Gazebo / jmavsim / jsbsim do not require any rendering, therefore you can simulate with any realtime factor. For example you can run a 250Hz lockstep simulation 30 times realtime in gazebo, so in reality the simulation is being run at 7500Hz. These have separate clients that are used for rendering that are decoupled from the physics.

This is not possible with freerunning or rendering dependent simulators such as flightgear / airsim that PX4 supports.

So was it deprecated from lack of use or is there something else I’m misunderstanding?

If there is a use case with Xplane, certainly we would be interested in bringing back. However, with the limited granularity of the physics I don’t think this would be a framework we would use for software verification / testing.

@Jaeyoung-Lim I appreciate the clarification! I do believe you’re correct about the physics being locked with rendering rate, but it’s hard to say since it’s closed source. I assume speeding up the UDP rate, is only replicating the last known frame when it’s higher then frame rate, but I haven’t seen any documentation. I’'ll post here if I find any more information on the subject. The main benefit for us with Xplane is more advanced physics simulation. The ability to build more granular models with Plane Maker is useful. Comparatively the physics in Gazebo aren’t as advanced for flight dynamics and we don’t need more robotics orientated sensors like Cameras or LIdar for simulation.

@laelliott Have you considered using jsbsim? For this reason we added support for jsbsim with PX4 HITL/SITL

I have not, but I’ll take a closer look. On initial glance it might have what we want. I think in my head I conflated Jsbsim and jmavsim as the same and skipped over it on accident

I’ll add a bit more info here in case someone finds this later.
Lowering graphical settings I got XPlane to report a stable fps ~130 fps using an i7 and 1080ti in Ubuntu 18.

Jaeyoung-Lim is correct though, Xplane’s physics are locked to the fps and there appears to be no way to speed it up. Quote from manual X-Plane 11 Desktop Manual | X-Plane

The simulator’s performance is measured in frames per second (FPS, or frame rate). This is how many times per second the X‑Plane physics and rendering code (currently more than 700,000 lines of code!) can be run. Each time the computer runs through the program it advances the aircraft and recalculates the images that are seen (cloud formations, scenery, aircraft instruments, other aircraft, etc.)…The faster a computer can run X‑Plane the more realistic and rewarding the simulation will be

@Jaeyoung-Lim I took a closer look at JSBSim this afternoon. Is it HITL or SITL? The readme says it’s an integration of the PX4 mavlink HIL interface. But everything launched and the instructions on the devguide indicated it’s a sitl simulation. Can you switch between the two? If so how? Happy to update documentation if there’s a need for it.

@laelliott HITL and SITL in PX4 essentially use the same interface (HIL_* mavlink message): Simulation | PX4 User Guide

For the jsbsim bridge, what was missing was the configuration, and not the implementation. I tried to resolve this for HIL with Enable Hardware-In-The-Loop simulation for JSBSim by Jaeyoung-Lim · Pull Request #28 · Auterion/px4-jsbsim-bridge · GitHub, but I have not been able to extensively test it yet

I don’t know what the other author was doing, but we did the same thing for an internal tool ourselves, and have released it in compliance with GPLv3.

This is VERY alpha, and may need help, but if you still need a MAV to XPlane bridge, here you go.

You will need to compile it with qmake yourself.


Any updates on this one? A use-case for X-Plane with hardware autopilot is if you are developing a new aircraft and you would like to simulate its physics. X-Plane’s blade element theory implementation is perfect for this. What are your plans about add serial port support to the bridge?

Re-adding serial port support is not a priority because the original bridge works for serial operations, at least according to the testers I was able to reach.

I have been able to get it working with our large drone prototype in X-Plane and demonstrated the resilience of PX4 on large drones, even able to make landings in high winds.

I think the interface of the bridge could use some refinement, and I’m happy to take pull requests.

Sorry notifications have not been working for me.

Hello! I am trying to use your bridge version, can you explain how to launch it?
I have install PX4
XPlane and QGC and the idea is connect them together it sitl
I have set UDP ports in XPlane but it doesnt see any PX4 data after I have launch your QT application