Multiple engine options

[ermarch]

For FlightGear it starts to become common to have an aircraft with multiple engine options selectable at runtime.
Therefore I was considering adding an enabled/serviceable boolean which declares whether an engine/thruster combination should use fuel and return calculated forces and moments or not. I think I would want to leave the rest as is: e.g. all defined engines go to a running state at the the startup procedure which means that engine selection can take place after engine run up.

Does anybody have any objections or thoughts on this?

[seanmcleod]

Doesn't the propulsion\cutoff_cmd property give you the required level of control in terms of fuel use and thrust/force/moment?

[ermarch]

Problem with that is (I think) that it then requires a full startup procedure to switch engines. Which could take tens of seconds to complete.

[bcoconni]

Which could take tens of seconds to complete.

Why is that so ? There is the method FGPropulsion::GetSteadyState that is used for trimming that converges extremely fast.

jsbsim/src/models/FGPropulsion.cpp

Lines 264 to 310 in 6461c86

	bool FGPropulsion::GetSteadyState(void)
	{
	double currentThrust = 0, lastThrust = -1;
	int steady_count = 0, j = 0;
	bool steady = false;
	bool TrimMode = FDMExec->GetTrimStatus();
	double TimeStep = FDMExec->GetDeltaT();
	vForces.InitMatrix();
	vMoments.InitMatrix();
	if (!FGModel::Run(false)) {
	FDMExec->SetTrimStatus(true);
	// This is a time marching algorithm so it needs a non-zero time step to
	// reach a steady state.
	in.TotalDeltaT = 0.5;
	for (auto& engine: Engines) {
	steady=false;
	steady_count=0;
	j=0;
	while (!steady && j < 6000) {
	engine->Calculate();
	lastThrust = currentThrust;
	currentThrust = engine->GetThrust();
	if (fabs(lastThrust-currentThrust) < 0.0001) {
	steady_count++;
	if (steady_count > 120) {
	steady=true;
	}
	} else {
	steady_count=0;
	}
	j++;
	}
	vForces += engine->GetBodyForces(); // sum body frame forces
	vMoments += engine->GetMoments(); // sum body frame moments
	}
	FDMExec->SetTrimStatus(TrimMode);
	in.TotalDeltaT = TimeStep;
	return false;
	} else {
	return true;
	}
	}

[ermarch]

Is there a way to trigger that function from a FlightGear aircraft configuration file?
e.g. could I toggle a property to initiate it?

[bcoconni]

Not at the moment, but this could be added quite easily. I guess some investigations need to be conducted to find the proper way of using this method from within FlightGear.

[seanmcleod]

But that's real life right? If the engine is really cut-off, otherwise if you don't want the start up time then you would need to leave the engine in idle.

[ermarch]

But then it still consumes fuel.
I envision a user sitting on the runway with a running engine changing it's mind and selecting another aircraft option. In such a case it would be really convenient to be able to instantly switch from one engine to the other.

[seanmcleod]

But then it still consumes fuel.

Yes, an idle engine will consume some amount of fuel. Again that's reality.

I guess I'm confused, isn't the aim to model reality in terms of aircraft with multiple engines and/or engine types?

So for example say I'm modelling some e-vtol aircraft which has say 4 electric engines (with virtually zero start-up time) and say 1 piston engine for cruise which has some start-up time on the order of 10s etc.

Then surely in terms of modelling the system you would then either choose to use the cut-off option or the idle option, and JSBSim would model both options fairly realistically?

would be really convenient to be able to instantly switch from one engine to the other.

Not sure I'm really understanding your aim. Convenient in terms of JSBSim/FlightGear user, or the convenience of having JSBSim realistically model the actual configuration?

[bcoconni]

I may be misunderstanding the problem but it seems that FlightGear users are using a complex solution to (what seems to be) a simple problem. Why wouldn't they reload the entire JSBSim model when the engine option is changed ? JSBSim loads its model quite fast and there is no reason why FlightGear couldn't be modified to allow reloading JSBSim models from within FlightGear I guess ? Kind of a hot reboot.

[ermarch]

If that would be possible then FlightGear would be able to change to any other aircraft type in-sim. Which it can't due to historical reasons.

[seanmcleod]

Kind of a hot reboot.

Yep, that was what I was thinking of. So when the user decides to change the engine FlightGear takes a snapshot of the current FDM in terms of the minimal state required for the reboot, e.g. attitude, position, [p,q,r], [u,v,w], control positions.

Then it loads the new model with the different engine model and uses the recorded minimal state above as the initial conditions for this new instance.

As part of the initial conditions the engine(s) can be specified to be running, i.e. no need for some multi-second engine startup procedure delay.

Now this won't be 100% perfect in the sense that the recorded throttle position will result in a different thrust when switching from say the 160HP engine to the 180HP engine, but generally the aircraft state will be fairly close, the user would need to account for the slightly different thrust.

The other thing I guess that could be substantially different is the overall mass and cg. For example if the user had been flying a 747 for a couple of hours and then decided to switch engines the new model will load with the default fuel mass and cg. If FlightGear really wanted to handle this case I guess they could record the state of the fuel tanks etc. and restore those when launching the newly engined version.

[ermarch]

If you could make this work: perfect.
I think a lot of FlightGear developers would me grateful.

[seanmcleod]

There is nothing really to be done by JSBSim, it provides for the setting of all the initial conditions. The control positions don't have an initial condition (ic/) property, but FlightGear can set them immediately after loading the initial conditions.

   @property ic/lat-gc-deg (read/write) Latitude initial condition in degrees
   @property ic/long-gc-deg (read/write) Longitude initial condition in degrees
   @property ic/h-sl-ft (read/write) Height above sea level initial condition in feet

   @property ic/theta-deg (read/write) Pitch angle initial condition in degrees
   @property ic/phi-deg (read/write) Roll angle initial condition in degrees
   @property ic/psi-true-deg (read/write) Heading angle initial condition in degrees

   @property ic/u-fps (read/write) Body frame x-axis velocity initial condition in feet/second
   @property ic/v-fps (read/write) Body frame y-axis velocity initial condition in feet/second
   @property ic/w-fps (read/write) Body frame z-axis velocity initial condition in feet/second

   @property ic/p-rad_sec (read/write) Roll rate initial condition in radians/second
   @property ic/q-rad_sec (read/write) Pitch rate initial condition in radians/second
   @property ic/r-rad_sec (read/write) Yaw rate initial condition in radians/second

So it's up to the FlightGear developers (those writing the FlightGear source as opposed to FlightGear aircraft developers) to make use of this approach.

[seanmcleod]

Hmm, does at first glance seem like a fairly hacky solution.

Share a link to the commit in your fork, when I take a look I only see a commit from 15 days ago to do with Aeromatic.

Are you talking about the aircraft now being defined with multiple engine options under <propulsion> and then using a holding property on each one?

jsbsim/aircraft/c172p/c172p.xml

Lines 201 to 219 in 6461c86

	<propulsion>
	<engine file="eng_io320">
	<feed>0</feed>
	<feed>1</feed>
	<thruster file="prop_75in2f">
	<location unit="IN">
	<x> -37.7 </x>
	<y> 0 </y>
	<z> 26.6 </z>
	</location>
	<orient unit="DEG">
	<roll> 0.0 </roll>
	<pitch> 0.0 </pitch>
	<yaw> 0.0 </yaw>
	</orient>
	<sense> 1 </sense>
	<p_factor> 5 </p_factor>
	</thruster>
	</engine>

[ermarch]

I did not push it to any branch yet, but here is the patch:
ermarch@2f8fa38

Yes, the idea is to define multiple engine/propulsion definitions in the FDM configuration and use the hold property for each of them to select only one.

[seanmcleod]

Hmm, isn't this approach going to be problematic?

So if I've got a B747 with say both GE and PW engines then we'll have engine[0-7], with either [0-3] or [4-7] with hold = true.

So what do gauges or anyone else who wants to query the 'current' engine(s) do in terms of property lookups? For example, from the 737 cruise script:

        <property>propulsion/engine[0]/n2</property>
        <property>propulsion/engine[1]/n2</property>
        <property>propulsion/engine[0]/thrust-lbs</property>
        <property>propulsion/engine[1]/thrust-lbs</property>

And existing code/script that sets engines running?

    <event name="Set engines running">
      <condition> simulation/sim-time-sec le 0.1 </condition>
      <set name="propulsion/engine[0]/set-running" value="1"/>
      <set name="propulsion/engine[1]/set-running" value="1"/>

You can specify -1 in the initial conditions file for example to start all engines running, so in the 747 example all 8 would be started. But if a user didn't specify -1 but rather an explicit set then not all 8 engines would be started.

And is this going to work with throttle inputs?

  ThrottlePos = in.ThrottlePos[EngineNumber];

What happens with the trim routines?

If you were going to go down this route it sounds like what you really need is some symbolic link feature in the property tree.

[ermarch]

Swappable engine sets. That's a tempting idea but requires some more careful thinking, especially if it has to be backwards compatible.

This problem could be solved for FlightGear using property-rules and an engine router model. But for other projects it may be better to create a full JSBSim solution.

[ermarch]

After rethinking what you said and what I really want to achieve I've come to the conclusion I was too focused on solving the problem the way others already had implemented it in their aircraft configuration.

I guess I really wanted to solve the problem that having multiple JSBSim configuration files with different engine specifications would mean that changes to the aerodynamics sections would be a nightmare to keep synchronized. Or so I thought. It turns out you could easily include a separate aerodynamic file from multiple configuration files. Same goes for ground reactions and external reactions.

I'll experiment a bit more to see how this works out.