Servers by jDrones

SITL : sim_vehicle.py - 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

sim_vehicle.py -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…

Thanks

Servers by jDrones