-
Hello again, I'm trying to find the trim states of my x8 UAV, I stumbled upon #802 and the TrimEnvelope.py script for doing so. I replaced the aircraft name with mine, I also replaced everything that needed to be replaced to conform to my UAV : However, when I run the script I got the following error messages flooding the terminal :
I verified if the .csv file existed well, I went to the fdm file of the x8 to check if it is properly logging and everything seems correct. Am I doing something wrong ? |
Beta Was this translation helpful? Give feedback.
Replies: 29 comments 29 replies
-
This is the only reference to jsbsim/src/input_output/FGOutputTextFile.cpp Lines 84 to 95 in b2172a4 |
Beta Was this translation helpful? Give feedback.
-
No it could also fail to open the file if for example it was locked, or it's file permissions were such that the process trying to open the file doesn't have permission etc. So some previous run could've created it, but possibly some process now has it locked, or the file permissions have been changed, or the python process is being run as some other user without permissions etc. There are a lot of reasons why a process can fail to open or create a file. |
Beta Was this translation helpful? Give feedback.
-
I've never noticed this error before. I haven't tried to specifically reproduce your issue, I'm also running Windows. |
Beta Was this translation helpful? Give feedback.
-
So what happens if you delete the .csv file and then run |
Beta Was this translation helpful? Give feedback.
-
Hmm, I wonder if what is happening is that during each loop when jsbsim/examples/python/TrimEnvelope.py Lines 53 to 72 in b2172a4 I presume you don't see this error when running So my guess is it gets created and populated during the first iteration of the loop and then fails to re-open/overwrite the file on the subsequent iterations. |
Beta Was this translation helpful? Give feedback.
-
Doesn't really make a difference other than getting rid of the error message in the console output. Even if the file was re-created on each iteration of the loop you would still be in the same boat as in only getting a single run's worth of data in the .CSV. Currently you're only getting the 1st run, if the file was re-created each time then you'd only get the last run. |
Beta Was this translation helpful? Give feedback.
-
Nope, no need to read anything from any .CSV file in order to perform a trim operation. Did you see something in the JSBSim documentation or the source code that made you think that the trim operation made use of previously stored data in an output .CSV file? Think about, you get to specify exactly what appears in the .CSV file via the output element, so what happens if I simply want to log the aircraft's altitude in the .CSV file. How would that help the trim routine? |
Beta Was this translation helpful? Give feedback.
-
Yep. |
Beta Was this translation helpful? Give feedback.
-
Hello again, Here is the snippet of the script where I specify the initial conditions etc... : # Set engines running
fdm['propulsion/engine/set-running'] = 1
# Set alpha range for trim solutions
fdm['aero/alpha-max-rad'] = math.radians(15)
fdm['aero/alpha-min-rad'] = math.radians(-5)
# Trim results
results = []
# Iterate over a range of speeds and for each speed a range of flight path angles (gamma)
# and check whether a trim point is possible
for speed in range(50, 130, 10):
for gamma in range(-10, 10, 1):
fdm['ic/h-sl-ft'] = 1960
fdm['ic/vc-kts'] = speed
fdm['ic/gamma-deg'] = gamma
# Initialize the aircraft with initial conditions
fdm.run_ic()
# Trim
try:
fdm['simulation/do_simple_trim'] = 1
results.append((fdm['velocities/vc-kts'], fdm['aero/alpha-deg'], gamma, fdm['fcs/throttle-cmd-norm']))
except RuntimeError as e:
# The trim cannot succeed. Just make sure that the raised exception
# is due to the trim failure otherwise rethrow.
if e.args[0] != 'Trim Failed':
raise |
Beta Was this translation helpful? Give feedback.
-
Couple more things to have the engine running for a piston engine, not sure if this is the completely minimal set. But these are the changes I made to get the script to produce output for the C-172p. AIRCRAFT_NAME="C172p"
fdm['fcs/mixture-cmd-norm'] = 1.0
fdm['propulsion/magneto_cmd'] = 3
fdm['propulsion/starter_cmd'] = 1
for speed in range(50, 130, 10):
for gamma in range(-10, 10, 1):
fdm['ic/h-sl-ft'] = 1960
ax.set_xlim(40, 140) Which produces the following. |
Beta Was this translation helpful? Give feedback.
-
Looking at existing scripts and looking at the source code. |
Beta Was this translation helpful? Give feedback.
-
You haven't shown which aircraft model you're loading. Are you sure it's the Here is my diff, just excluding the x-axis limit change. And if you are definitely loading the |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Correct, you can't just set the throttle and airspeed and assume the aircraft will be in trim if you have a trim point for that airspeed and throttle. All the control surfaces need to be in the required position that the trim routine calculated was needed for all of them. You can see clearly from your graph of pitch rate for example that the aircraft isn't in trim, there is an immediate pitch rate spike, if the aircraft was in trim then pitch rate, roll rate etc. would be 0. Plus in addition to ALL control surfaces having to be in a particular position you also need the aircraft to be in the correct attitude as well. For example you mention one particular solution at 100KIAS with AoA = 0.3843 and level flight, i.e. In general, if you want to start off a flight in trim, then use a script, or python code to set your general initial conditions, i.e. altitude, airspeed etc. and gamma (flight path angle) and then invoke JSBSim's trim routine. Assuming it can find a trim point for your initial conditions then when the trim routine returns the aircraft will be in trim. Now to set some expectations, it won't remain in trim forever. First off the trim is calculated based on the current weight and cg at the time the trim routine is called, so as the aircraft burns fuel the weight and cg will change, so the aircraft's controls won't match the required positions to keep the aircraft in trim for the new weight and cg. You need to either re-trim periodically, or write an auto-pilot to keep it in trim. Or there is a property you can set, something like However, even in this case, given enough time you will still see some slight drift from trim based on the floating point resolution and the error margins the trim routine uses. |
Beta Was this translation helpful? Give feedback.
-
Depends, if you call the JSBSim trim routine you don't need to specify the pitch attitude, it will calculate it and set it. If you're trying to manually set up the aircraft in trim based on a pre-computed trim solution then yes you would set it as part of the initial conditions. Now don't forget, this is just 1 part of the attitude that may need to be non-zero. For example comment out this line: #jsbsim.FGJSBBase().debug_lvl = 0 And then you'll see some output from the trim routine, e.g. Full Trim
Trim successful
Trim Results:
Angle of Attack: 11.90 wdot: -4.15e-05 Tolerance: 1e-03 Passed
Throttle: 0.94 udot: 8.98e-04 Tolerance: 1e-03 Passed
Pitch Trim: -0.19 qdot: -3.12e-07 Tolerance: 1e-04 Passed
Roll Angle: 0.16 vdot: -1.08e-05 Tolerance: 1e-03 Passed
Ailerons: 0.20 pdot: -1.85e-06 Tolerance: 1e-04 Passed
Rudder: -0.06 rdot: -4.51e-18 Tolerance: 1e-04 Passed Now note that the roll angle isn't 0, and also note the aileron and rudder control positions required for trim, they're not all 0. |
Beta Was this translation helpful? Give feedback.
-
Look closely at the trim output example above, and note that there isn't mention of Then take a look at the FCS in <flight_control name="FCS: c172">
<channel name="Pitch">
<summer name="Pitch Trim Sum">
<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>
<gain>0.01745</gain>
<range>
<min>-28</min>
<max>23</max>
</range>
<output>fcs/elevator-pos-rad</output>
</aerosurface_scale> And from the trim and FCS source code. jsbsim/src/initialization/FGTrim.cpp Line 810 in 398c07c jsbsim/src/initialization/FGTrim.cpp Line 196 in 398c07c Line 402 in 4f8d48f Line 713 in 77d2df2 So in summary, the trim routine doesn't set the elevator position via |
Beta Was this translation helpful? Give feedback.
-
Because you're confused by what And as per my previous comment it's the value for |
Beta Was this translation helpful? Give feedback.
-
This is what I see. In other words the same throttle value except for some potential rounding/truncation issue to 2 decimal places in the trim output. |
Beta Was this translation helpful? Give feedback.
-
I see the same issue as you do for that set of initial conditions. |
Beta Was this translation helpful? Give feedback.
-
See my comment further up regarding what the trim routine does with regards to aileron and rudder control. |
Beta Was this translation helpful? Give feedback.
-
Okay I've figured out the issue. Take a look at jsbsim/src/initialization/FGTrimAxis.cpp Lines 272 to 287 in 398c07c Note the fdmex->GetFCS()->SetThrottleCmd(i, tMin + control_value * (tMax-tMin)); Now for some engines, e.g. the turbine engine used by the 737 model However for the specific piston engine used by the C172p. Lines 23 to 24 in 398c07c Now when the trim results are printed the I'll look into possibly changing the value that is printed by the trim routine to avoid this confusion. |
Beta Was this translation helpful? Give feedback.
-
Ok so I spent some time looking at the trim source code The trim mode is jsbsim/src/initialization/FGTrim.cpp Lines 801 to 815 in 398c07c The jsbsim/src/initialization/FGTrim.cpp Lines 252 to 261 in 398c07c When I check the jsbsim/src/initialization/FGTrim.cpp Lines 561 to 567 in 398c07c This jsbsim/src/initialization/FGTrimAxis.cpp Lines 245 to 249 in 398c07c And this jsbsim/src/initialization/FGTrimAxis.cpp Lines 224 to 241 in 398c07c Indeed, as you mentionned, nothing is set on jsbsim/aircraft/c172p/c172p.xml Lines 273 to 291 in 398c07c Can you confirm everything I've wrote ? It's a bit hard for me to understand such a big code base :'). |
Beta Was this translation helpful? Give feedback.
-
Looks good, just made a minor edit to change |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Remember what I mentioned yesterday in this thread.
Now take a look at your graphs, I presume the x-axis are the number of Now also look at the scale on the y-axis, based on auto-scaling I'm assuming. Pitch and roll attitude stays within what less than 0.01, actually, no labels on the axes so I'm not sure if these are degrees or radians. And there is a slight turn, i.e. heading, but even that is less than a degree (radians?) over 27min? And again, over a 27min period the change in airspeed is 0.07kt! With a change in altitude of ~25m or ~25ft again over 27mins. |
Beta Was this translation helpful? Give feedback.
-
Alright so now I'll try making this work on my x8 UAV fdm. The trim routine either failed for the required speed and gamma or returned Here are the differences that I identified between the c172p case and my x8 :
So, following the c172p, I changed my x8 fdm : <flight_control name="x8">
<channel name="Pitch">
<summer name="fcs/pitch-sum">
<description>Just clips the elevator cmd signal (-1/+1), the x8 has no trim tab</description>
<input>fcs/elevator-cmd-norm</input>
<clipto>
<min>-1</min>
<max>1</max>
</clipto>
</summer>
<!-- Gain set to convert control deflection to radians -->
<aerosurface_scale name="fcs/elevator-control">
<description>Mapping to the maximum elevator deflection</description>
<input>fcs/pitch-sum</input>
<range>
<min>-30</min>
<max>+30</max>
</range>
<gain>0.01745</gain>
</aerosurface_scale>
<actuator name="fcs/elevator-actuator">
<description>Converting the actuator command to a control surface movement</description>
<input>fcs/elevator-control</input>
<!-- <lag>60</lag>
<bias>0.002</bias> -->
<clipto>
<!-- +/- 30 degs -->
<min>-0.52</min>
<max>0.52</max>
</clipto>
<output>fcs/elevator-pos-rad</output>
</actuator>
</channel> to this : <flight_control name="x8">
<channel name="Pitch">
<summer name="fcs/pitch-trim-sum">
<description>Just clips the elevator cmd signal (-1/+1), the x8 has no trim tab</description>
<input>fcs/elevator-cmd-norm</input>
<input>fcs/pitch-trim-cmd-norm</input>
<clipto>
<min>-1</min>
<max>1</max>
</clipto>
</summer>
<!-- Gain set to convert control deflection to radians -->
<aerosurface_scale name="fcs/elevator-control">
<description>Mapping to the maximum elevator deflection</description>
<input>fcs/pitch-trim-sum</input>
<range>
<min>-30</min>
<max>+30</max>
</range>
<gain>0.01745</gain>
</aerosurface_scale>
<actuator name="fcs/elevator-actuator">
<description>Converting the actuator command to a control surface movement</description>
<input>fcs/elevator-control</input>
<!-- <lag>60</lag>
<bias>0.002</bias> -->
<clipto>
<!-- +/- 30 degs -->
<min>-0.52</min>
<max>0.52</max>
</clipto>
<output>fcs/elevator-pos-rad</output>
</actuator>
</channel> This change makes the trim routine find trim points and draw a graph : I'm all happy and decide to check the behaviour of the trimmed flight for
And when I plot the flight data : I have what seems to be a good looking curve, but look at the axes, everything is so small. I think it has something to do with the changes I made in the fdm.xml, since I tested forcing (in the fdm.run() while loop) Can you explain why these fdm changes break the scales (but not the trim calculations) ? Edit : I'm dumb the trim worked out well, I didn't pay attention to the plot's axis scales. |
Beta Was this translation helpful? Give feedback.
-
I don't follow why that's an issue, surely you would be happier with such small values for things like pitch rate etc., e.g. |
Beta Was this translation helpful? Give feedback.
-
Is not just a matter of not reading the graph correctly? Given the So |
Beta Was this translation helpful? Give feedback.
-
@Dobid one more thing: when you plot trajectories in the XYZ-space, make sure you have the same scale for all three axes in order to have a real feeling of the flight path |
Beta Was this translation helpful? Give feedback.
Alright so now I'll try making this work on my x8 UAV fdm. The trim routine either failed for the required speed and gamma or returned
Sorry, qdot doesn't appear to be trimmable
Here are the differences that I identified between the c172p case and my x8 :
pitch-trim-cmd-norm
in the FCS of the x8 either : that would certainly be a problem, considering thetFull
trim mode requires atPitchTrim
control state for theQdot
axis :jsbsim/src/initialization/FGTrim.cpp
Lines 801 to 815 in 398c07c