Questions about general process of the simulation

[DreamerSurpass]

I use JSBSim inside a large simulation program, and I have written the copy_inputs_to_jsbsim and copy_outputs_from_jsbsim. I wonder which variables are usually used as inputs? I use aileron_cmd, rudder_cmd, elevator_cmd and throttle_cmd as inputs. What else should I use?

Reference Manual said that throttle_cmd should be set (0.0, 1.0), but the pace changes slowly when I set to 1.0, and I found that larger throttle value will also run. So if I want to speed up quickly, should I set a larger value to throttle_cmd?

The basic process code is shown below.

setPath();
loadModel();
setIC();
runIC();
while (getsimTime() < test_time)
{
    ...
    setAction(throttle_cmd, ele_cmd, ail_cmd, rud_cmd); // copy_inputs_to_jsbsim
    refreshState(&state); // copy_outputs_from_jsbsim
    ...
}

Any ideas would be appreciated.

[seanmcleod]

You haven't provided much information regarding the type of aircraft being used, and how they're being used.

So in general you would copy whatever inputs a pilot would use, so in addition to the ones you listed it would typically include things like flap selection, gear selection, brakes etc. But as I said it really depends on the aircraft type, e.g. maybe you're only using aircraft with fixed gear, then there is no need input the gear selection. Plus, maybe your simulation only ever flies the aircraft up and away so no need for flaps selection or brakes.

Rather provide more background information on what you're doing and what you're trying to achieve. We're not mind readers.

but the pace changes slowly when I set to 1.0...

Again, not enough context. Slowly relative to what? Do you know the specific aircraft type and you know it should accelerate faster than it is in JSBSim? Or do you want to provide some sort of 'slew' mechanism to unrealistically get the aircraft up to some operating speed?

[DreamerSurpass]

I use F-16 aircraft. My goal is to simulate close air combat process, and my simulation doesn't involve takeoff, landing or other process, which means at the beginning I set the airplane at a certain altitude(like 20000ft) , give it a certain velocity(like 600 ft/s) and do trim, then I use the four inputs I mentioned above to change the position and attitude of the aircraft, all phases of the simulation take place in the air.

Slowly relative to what? Do you know the specific aircraft type and you know it should accelerate faster than it is in JSBSim?

I‘m afraid it's just my understanding that the speed will change faster if I set max throttle cmd. Thanks for your reply.

[seanmcleod]

Then the only other potential input I can think of off-hand would be a speed-brake input.

[DreamerSurpass]

Alright, thanks again.

[DreamerSurpass]

Excuse me, I have a new problem. After I choose the airplane(like f16) and during the simulation set the throttle_cmd to 1.0 and ele_cmd to -1.0(the aircraft will pull the somersault). I found if only change the initial attitude psi angle, then after long time simulation(like 150s or longer), the altitude and velocity or other states seems have a big difference.

In my mind, changing the initial Psi(0deg, 90deg, 180deg) will change the course of the airplane only and not influence the Vt or height during simulation. Why does this happen? Is it due to the simulation error?

[seanmcleod]

So are you saying that if you set the initial $\psi$ to (000, 090, 180) and then perform a trim that some of these result in stable flight for much longer than 150s where as others diverge a lot from trim?

[DreamerSurpass]

That's not what I want to say.
I set the initial $\psi$ to (0, 90, 180) respectively and perform a trim. Then during the simulation I set the throttle cmd to 1.0 and elevator cmd to -1.0 (so the airplane will perform somersault maneuver, not take stable flight). And I record the output of several different $\psi$ initial simulations for much longer than 150s. The final ouptut shows the different altitude, vt-fps.

In a word, I just change the initial $\psi$ and run multiple simulations(not stable flight, but take the same fcs input). The altitude or velocity at the same time in the output(like 300s) are different. In my mind, they should be the same as others.

[DreamerSurpass]

Below is the simulation altitude curve. We can see after long time altitude is different.

[seanmcleod]

Try and remove the FCS from the equation and see if you see similar results. Simplest approach would be to say use the A-4 aircraft model in the JSBSim repo which doesn't have an FCS with FBW command laws etc.

[DreamerSurpass]

Do you mean remove the fcs input and take stable flight? If not add control surface input, I will get similar results,(the altitude and velocity will remain stable), but my intention is to maneuver the aircraft.

I found that initial position(lon, lat) also influence the result curve, sometimes it will not divergent and in the majority situation it will divergent at time 150. Maybe there are some simluation error at this time.
Coordinate system problem also puzzles me a lot. I set a reference point on the horizon and record the location both in local_horizontal_frame and ECI frame. But the track seems different. Is this due to the scale of frame? (I have verified the correctness of the transformation matrix) I think the curves should have the same shape in different coordinate frame.

Left curve is drawn in ECI frame, right is in local frame.

[seanmcleod]

Do you mean remove the fcs input and take stable flight?

No, I meant take the complicated FBW command law implementation out of the equation, e.g. in the F-16 stick input commands a particular g rather than simply commanding a particular elevator deflection.

So I was suggesting that you use the A-4 which has a basic direct connection FCS, i.e. like in a Cessna, stick command is mapped to a particular control surface angle. And then perform your same test, i.e. trim and then apply full throttle and full back stick to start your loops.

[DreamerSurpass]

Well I have tried to use A-4 and performed the same test, the outputs were consistent. But I still don't understant why command a particular control surface deflection in F-16 will go wrong.

I meant take the complicated FBW command law implementation out of the equation, e.g. in the F-16 stick input commands a particular g rather than simply commanding a particular elevator deflection.

You meant use particular overload as input and self write the transform module to transform the overload signal to control surface deflection? It seems more complex. Or you meant directly use g to control airplane? But I didn't see the interface corresponding to command overload, and if I have to pilot the airplane, finally I have to call SetDeCmd() ... these functions, there seems to be no essential difference.

[DreamerSurpass]

Or another question. I get input signal from joystick. Is it proper to assign these inputs to setDeCmd(value), setThrottleCmd(value) etc these functions? If not, what property should I assign to in JSBSim?

[seanmcleod]

Also for some background on F-16 FCS issues we've looked into in the past - #814

[seanmcleod]

....the outputs were consistent.

Just to be 100% clear. So the A-4's outputs with the same control inputs but different starting $\psi$ values were consistent with each other, i.e. no difference in output. As opposed to the A-4's outputs being consistent with the F-16's output where you see a variation in output depending on the starting $\psi$?

You meant use particular overload as input and self write the transform module to transform the overload signal to control surface deflection?

No, I meant that by switching to an aircraft like the A-4 you remove the whole FBW command law implementation that you see in the F-16's FCS section. Have you compared the FCS sections of the A-4 with the F-16?

And if you saw the same issue with the A-4 then it means that it isn't an issue with the FCS implementation that someone created, but possibly an issue with the core EOM (Equations Of Motion) in JSBSim. You can then focus further investigation into the relevant portion of code.

So let's take the A-4's FCS section dealing with pitch. It's really trivial, it basically scales the pilot's input of the longitudinal inceptor modelled by the property fcs/elevator-cmd-norm which is set via setDeCmd(value) to an angular deflection of the elevator.

So [-1, +1] elevator command norm scaled to [-0.35, +0.30] radians for fcs/elevator-pos-rad.

jsbsim/aircraft/A4/A4.xml

Lines 202 to 217 in 02b4e25

	<input>fcs/elevator-cmd-norm</input>
	<input>fcs/pitch-trim-cmd-norm</input>
	<clipto>
	<min> -1 </min>
	<max> 1 </max>
	</clipto>
	</summer>
	<aerosurface_scale name="Elevator Control">
	<input>fcs/pitch-trim-sum</input>
	<range>
	<min> -0.35 </min>
	<max> 0.30 </max>
	</range>
	<output>fcs/elevator-pos-rad</output>
	</aerosurface_scale>

Now compare that to the F-16's FCS, it's a lot more complicated. Follow how the property fcs/elevator-cmd-norm eventually results in an elevator deflection.

That's because the pilot's input fcs/elevator-cmd-norm doesn't simply get scaled to an elevator deflection. In this case it's taken as a g-command input and the FCS via a PID controller and additional logic calculates what position to set the elevator to achieve (if it can, and if it hasn't hit a protection limit etc.) the pilot's command.

Did you look at discussion #814 to see how even starting off in a straight and level trim the FCS has issues maintaining that?

[DreamerSurpass]

So the A-4's outputs with the same control inputs but different starting values were consistent with each other, i.e. no difference in output.

Yes, A-4's outputs with the same control inputs but different starting values are totally identical.

Have you compared the FCS sections of the A-4 with the F-16?

Yes, I have seen the FCS section in xml file of the A-4 and the F-16. The module in F16 is more complex and has other properties(like alpha、overload) and PID controller involved in the calculation. So the elevator_cmd is not proportional to the actual elevator_position.

So my question now is, if I get input signal from joystick. Is it proper to assign these inputs to setDeCmd(value), setThrottleCmd(value) etc these functions to simulate flying an airplane?

[seanmcleod]

So my question now is, if I get input signal from joystick. Is it proper to assign these inputs to setDeCmd(value), setThrottleCmd(value) etc these functions to simulate flying an airplane?

Yes your current assignment is correct.

Just mentally remember that in the case of an aircraft like the F-16 with a FBW command law that the names DeCmd and fcs/elevator-cmd-norm are misleading, you're not actually commanding a direct elevator position, they are really the FBW command inputs, which can vary from FBW command law to command law, e.g. it could be a g-command, or a pitch-rate-command, or an alpha-command or some combination, e.g. c-star-command which the Airbus airliners use which is a combination of g and pitch-rate, and the input can even change when hitting safety limits, e.g. it switches transparently from say c-star-command to alpha-command when nearing the stall etc.

[DreamerSurpass]

Thanks for your patience. I see what you mean.

it could be a g-command, or a pitch-rate-command, or an alpha-command or some combination, e.g. c-star-command.

So have these command law been implemented in XML file?

Did you look at discussion #814 to see how even starting off in a straight and level trim the FCS has issues maintaining that?

I have seen this discussion. I used your code in python and reproduce the divergence result. But it's weired, I did the same thing in C++ and get the normal result.

#include <FGFDMExec.h>
#include <models/FGAuxiliary.h>
#include <initialization/FGInitialCondition.h>
#include <models/FGFCS.h>
#include <models/propulsion/FGEngine.h>
#include <models/FGPropulsion.h>
#include <models/FGAccelerations.h>
#include <FGJSBBase.h>
#include <cstdlib>

using namespace JSBSim;

int main()
{
	FGFDMExec* jsb = new FGFDMExec();

	jsb->SetAircraftPath(SGPath("E:\\jsbsim-code\\aircraft"));
	jsb->SetEnginePath(SGPath("E:\\jsbsim-code\\engine"));
	jsb->SetSystemsPath(SGPath("E:\\jsbsim-code\\systems"));
	jsb->Setdt(0.02);
	jsb->SetOutputDirectives(SGPath("E:\\jsbsim-code\\f16output.xml"));
	jsb->LoadModel("f16");

	shared_ptr<FGInitialCondition> IC = jsb->GetIC();

	IC->SetVcalibratedKtsIC(335);

	IC->SetLongitudeDegIC(0);
	IC->SetLatitudeDegIC(0);
	IC->SetAltitudeAGLFtIC(20000);

	IC->SetPhiDegIC(0);
	IC->SetThetaDegIC(0);
	IC->SetPsiDegIC(0);

	jsb->RunIC();
	jsb->SetDebugLevel(0);
	jsb->DoTrim(1);
	
	shared_ptr<FGFCS> fcs = jsb->GetFCS();
	fcs->SetCBrake(0);
	fcs->SetLBrake(0);
	fcs->SetRBrake(0);
	
	shared_ptr<FGPropulsion> prop = jsb->GetPropulsion();
	shared_ptr<FGEngine> engine = prop->GetEngine(0);
	prop->SetActiveEngine(0);
	prop->SetStarter(1);
	engine->SetStarter(true);
	engine->SetRunning(true);

	while (jsb->GetSimTime() <= 300)
	{
		jsb->Run();
	}
}

The gamma and phi curve is shown in the figure.

Did you look at discussion #814 to see how even starting off in a straight and level trim the FCS has issues maintaining that?

Does this mean that I may have to adjust the control module parameters in xml file myself sometimes?

[seanmcleod]

So have these command law been implemented in XML file?

Some JSBSim users for some JSBSim aircraft models have implemented these sorts of FBW command laws in the FDM's XML file. Also remember not every JSBSim aircraft model exists in the JSBSim repo.

But it's weired, I did the same thing in C++ and get the normal result.

Hmm, having a quick initial glance I see at least 1 difference between the C++ version you coded up and the Python version.

jsb->Setdt(0.02);

I don't explicitly set it in my Python example, which means the Python version is using the default of dt = 0.00833, i.e. 120Hz and your C++ example is using a larger timestep.

Does this mean that I may have to adjust the control module parameters in xml file myself sometimes?

Yes, you can't assume that every FCS implementation in the JSBSim repo is perfect.

Now it also depends how the model is being used in terms of whether these sorts of imperfections are an issue or not. If you have a human pilot actually flying the aircraft model then they will often cancel out any of these sorts of imperfections, e.g. as I mentioned in the other discussion a pilot would notice a slight roll and correct it periodically.

[DreamerSurpass]

I don't explicitly set it in my Python example, which means the Python version is using the default of dt = 0.00833, i.e. 120Hz and your C++ example is using a larger timestep.

Emmm, this does not seem to be the fundamental problem.

If you have a human pilot actually flying the aircraft model then they will often cancel out any of these sorts of imperfections, e.g. as I mentioned in the other discussion a pilot would notice a slight roll and correct it periodically.

Got it. Thank you again. It helps me a lot.

[seanmcleod]

Emmm, this does not seem to be the fundamental problem.

"does not..." - so if you remove the call to set dt to 0.02 in your C++ example do you see the same output as the Python version?

[DreamerSurpass]

Nope, the output is still normal and no divergence appears.

[seanmcleod]

Hmm, would be interesting/useful to figure out the difference between the C++ and Python versions.