SITL : - Aircraft starts below terrain!

Hello all,

I am around the corner for delivering an upgrade for SITL with FlightGear/Jsbsim for ArduPlane. The upgrade is added channels for the Rascal base model with moving control surfaces during the SITL simulation or by rc # PWM commands from MavProxy.

This feature will help to create VTOL and Tilt-rotor flight models within FlightGear/JsbSim with the aid of the visuals…

Now let’s get to the problem: Everything works as desired, except for one glitch. The aircraft refuses to recognize the terrain and ends up starting below it!

I think it is to do with the fact that I am launching the simulation with a less standard “-I 1” flag -C -v ArduPlane -f jsbsim:Rascal110 -j4 -L KSFO -w --console -I 1

If I do not use the “-I 1” flag, the terrain “becomes active” and the aircraft stays over it, but then the aircraft’s control surfaces do not receive the RC signals from MavProxy and animate as desired.

I am not really understanding the influence of this -I (instance) flag in the whole thing. It is for launching multiple aircraft within SITL and shifts the TCP ports for Mavlink by an increment of 10 in the below communication architecture (apparently wrong per the developers but it is the closest thing to what I think is happening).

The instance flag also somehow positively addresses my need of creating moving control surfaces and getting visual responses to my addiction RC channels… why? Not sure…

By the way, PX4 group seems to have a working solution for this (Rascal flying with movable surfaces within SITL) but their internals are complicated to understand…

So I need a hand of help. Why does terrain data become useless with the -I 1 flag although the terrain is visible and the ground elevation reads correctly within FlightGear? I think something gets messed up within Jsbsim…or somehow terrain becomes disabled in simulations with multiple intances(?)

By the way,I launch FlightGear in the standard way:

–native-fdm=socket,in,10,5503,udp ^
–fdm=external ^
–fg-aircraft=%AUTOTESTDIR% ^
–aircraft=Rascal110-jsbsim ^

The only modification I have in the Rascal jsbsim flight model is that I added the following output protocol in the Rascal.xml file:

<output name=“localhost” type=“FLIGHTGEAR” protocol=“udp” port=“5503” rate=“10”/>

is it possible that the extra line from Jsbsim to Flightgear through Udp 5503 port is breaking the existing line between Arduplane and Flightgear?

@stephendade, any ideas?

I would appreciate a committed hand of assistance so that I can go ahead and make a full request for these upgrades…


I guess Jsbsim and Flightgear are not as popular as Gazebo or RealFlight, often answering my own questions about them…

For my original question above I was able to implement a work around in the Jsbsim model of the aircraft adding the following lines to the nasal code:

asl_ft = getprop("/position/altitude-ft");
ground_ft = getprop("/position/ground-elev-ft");

if (asl_ft < ground_ft) {
    asl_ft = asl_ft+ground_ft;
    setprop("/position/altitude-ft",  asl_ft);

What this does is to check whether the absolute altitude is correctly communicated to Flightgear. If it is not, then it adds the ground altitude to the absolute altitude. The issue arises when the aircraft is still on the ground prior to takeoff. After the takeoff, it looks like the height adjustment is not accessed. It is a work around, not a solution to the problem…

Hi. I am having trouble getting jsbsim with SITL to work. Not sure what went wrong. I followed the steps in:
I am using WSL and there was no problem building jsbsim.
What I did, in 1 terminal run flight gear. 2nd terminal running sitl and jsbsim command. I tried using your command -C -v ArduPlane -f jsbsim:Rascal110 -j4 -L KSFO -w --console
and the command in ardupilot -v ArduPlane -f jsbsim:Rascal --console --map

Every time mavproxy console loads, I got a message “link 1 down” and no aircraft is loaded. The Rascal folder is in tools/autotest/aircraft

I search about this matter and from this thread, the link 1 down might due to jsbsim was not shut down properly; but then i think they have included the kill task in

Since I saw your post and it seems that jsbsim is working for you, maybe you can suggest some workaround for me. I also tried in cygwin, the same problem occurred.