Aeromatic alpha value output #436
Comments
|
@kwanzapili Thanks for the bug report. Just to clarify things: when you are referring to |
|
Sorry for the lapse in responding. I mean the Aeromatic CLI that you get from compiling the JSBSim tar ball ( |
|
@ermarch This is an issue linked with aeromatic++. Could you please review it ? |
|
A quick test makes me believe this is an issue with delta wings. The error arises from the fact that the lift table will have a non ascending alpha scale. <function name="aero/force/Lift_alpha">
<description>Lift due to alpha</description>
<product>
<property>aero/qbar-psf</property>
<property>metrics/Sw-sqft</property>
<table>
<independentVar lookup="row">aero/alpha-rad</independentVar>
<tableData>
-1.61 -0.7635
0.00 0.2586
1.21 1.0221
1.22 0.7429
1.57 0.0000
</tableData>
</table>
</product>
</function>But I will need to take a closer look at why this happens, and how to resolve it. |
|
@kwanzapili the fix is now in the |
|
Well, actually the automatic build has succeeded so you can download the executables for Windows from our rolling release JSBSim-1.2.0.dev1-502-setup.exe. Please test and let us know if that fixes the issue you have reported. |
|
I noticed the failure, but also concluded that it would be unrelated. Thanks fro applying the patch. |
|
Thanks a lot. This is with a stall speed of 120 knots (200 knots would be well above VR for this aircraft). The alpha table looks misaligned as before: <function name="aero/force/Lift_alpha">
<description>Lift due to alpha</description>
<product>
<property>aero/qbar-psf</property>
<property>metrics/Sw-sqft</property>
<table>
<independentVar lookup="row">aero/alpha-rad</independentVar>
<tableData>
-1.57 0.0000
-1.22 -0.5302
-1.05 -0.7143
-0.88 -0.8248
-1.08 -0.3866
-1.90 -0.9665
0.00 0.3272
1.42 1.2936
0.60 0.7138
0.88 1.1752
1.05 1.0177
1.22 0.7554
1.57 0.0000
</tableData>
</table>
</product>
</function>
Unless, I am missing something, I think this is where we were before? |
|
This sound like AeromatiC++ wasn't built from the latest code. This is how the table should look like if i use the vulcan configuration you provided earlier (with a stall speed of 130kts): <function name="aero/force/Lift_alpha">
<description>Lift due to alpha</description>
<product>
<property>aero/qbar-psf</property>
<property>metrics/Sw-sqft</property>
<table>
<independentVar lookup="row">aero/alpha-rad</independentVar>
<tableData>
-1.57 0.0000
-1.22 -0.5427
-1.05 -0.7312
-0.88 -0.8443
-0.48 -0.2785
0.00 0.1304
0.55 1.0221
0.62 0.2394
0.88 1.1557
1.05 1.0008
1.22 0.7429
1.57 0.0000
</tableData>
</table>
</product>
</function> |
Did the archive contained the folder |
|
I have downloaded and recompiled the source, and this time I get no errors. The source I got yesterday had the samples directory you mention. Perhaps it was simply a timing issue. I've not actually examined the output in detail, but I can see that the alpha values are now properly aligned. One question I had asked before was why it does not generate the engine file? It asks if the plane has a reverser, then does nothing more on engines. Thanks a lot. |
It should, but after testing it I see it doesn't. For none of the configurations I tested. |
…roblem mentioned in issue JSBSim-Team#436
|
I'll have to look at the TFS problem. For the alpha table: If you think you've got a better match from elsewhere then by all means replace the one generated by AeromatiC++. AeromatiC++ is design to provide a first, working, setup from a small number of inputs. It tries to be as accurate as possible with those input but it will always be limited in it's accuracy. |
|
The NaN's turn out to be generated by using an incomplete parameter file (it was created when not all parameters where processed). I've included a new configuration file for the Vulcan which solves this: |
|
Thanks a lot, that's great. One final observation which might be completely useless, but might be helpful for someone who encounters the same issue. When the plane is on the ground at standstill, JSBsim sometimes randomly assigns an alpha degree of ~178 - 180. Otherwise it assigns an alpha close to 0. I have found that if the alpha lift coefficient is set to zero when alpha is ~180, then alpha will stay at that value whatever throttle is applied. The result is that the plane will never gain enough speed and never lift off. This happens for settings such as: Now if we add a non-zero alpha coefficient above 90 degrees, JSBsim will magically reset the alpha to something nearer 0 if the plane begins to move. Then everything should work as expected. For example, if we add a line:
Perhaps this is a situation peculiar to me. It took me a while to figure out the issue and the workaround I devised. |
|
@kwanzapili in terms of the alpha value I was recently taking a look in that section of the code. jsbsim/src/models/FGAuxiliary.cpp Lines 151 to 169 in 375f5be So on each simulation step alpha is initialized to 0 and then only if So the entries you have in a Cl vs alpha table really shouldn't make a direct difference. The only thing I can think of is that you have some drag table which results in massive drag with large alpha values which prevents the aircraft from accelerating so that the velocity UVW stays very small. |
|
Thanks for the insight. The thing that really puzzles me is that on startup, alpha-deg = 178.64 and alpha-rad = 3.1177. These are not reset to 0 until I manage to change the velocity somewhat. if alpha is initialized to 0, then somewhere else it is set to 178 again. That is the mystery I cannot understand. An additional aspect is that alpha might revert to 178 on landing and when the velocity drops to 0. But these occurrences appear random. You are correct about the drag. I had to eliminate much of it and I finally settled on the table below. As you can see, I have had to use negative drag for alpha above 90 (I know this is naughty, but that is the easiest way I could overcome the high alpha problem). |
|
Plot/log the
Also plot/log the throttle command, thrust force and the aerodynamic forces, to see which one is blowing up in order to prevent the aircraft gaining enough speed. Take a look at #455 to see an example of the forces logged etc. |
|
I'd not sure about what the UVW velocities, so I had a look at u-aero-fps etc and the alpha values are startup. The data shows the following pattern (full data set attached): You will notice, it rises sharply from -1.5 too 160 degrees, where it settles down. This happens without me doing anything. So it is purely JSBsim assigning random number to alpha. It seems to like numbers around -1.5 to 0 degrees and 160 to 180 degrees. As I said before, it I can coax the plane into sufficient motion, then alpha will trend towards 0.Now one import of this is that I must never use aero/alphadot-rad_sec to calculate Lift due to alpha rate, for if I did, then the plane will get into horrendous oscillations on the ground as if it was in an earthquake. So my wild guess is something is seriously wrong with the way alpha is computed at startup. My workaround was merely masking the problem at high alpha. One other major puzzle I have is why my pitch is set to -2 at startup even with the controls centered? It also happens in level flight. Could you please point me to the potential causes? Thanks. |
JSBSim definitely doesn't assign random values to alpha. >>> math.degrees(math.atan2(0.0251, -0.0709))
160.50503155537436So the question is what is causing these velocities.
So this is the model simply sitting at rest on the ground when you start JSBSim? What aircraft model is this? I asked earlier if there is any wind configured? My guess based on your data and description so far and based on an issue from a while ago is that maybe it's similia to this issue - #89 |
|
Sorry I should have mentioned that I am modelling a Vulcan which was the reason I used Aeromatic to get some initial parameters. I use the JSBSim Atmosphere model by setting the parameter I was aware of the issue of sudden jumps when the plane is at standstill with the brakes on, having experienced it before with a different plane. For this plane I use QBarUW with formula involving alpha. This has largely resolved that issue except where aero/alphadot-rad_sec is involved. |
|
Are you using JSBSim stand-alone or are you using it in conjunction with FlightGear? JSBSim doesn't 'just decide` on wind conditions, any wind needs to be set, it defaults to no wind, hence my questions about wind being set. |
|
I should have mentioned I always go through FlightGear with JSBsim as the FDM. On the weather conditions, I set nothing at all personally. All I have set is: time of day, season, real weather, basic weather. Beyond that I leave it to the FDM. When testing I use the same airport and runway, but I can see that the weather does change because the side winds can be very different on different runs (even within 5 minutes). I know this because I need different rudder settings to keep the plane in a straight line. |
|
Could you post the aircraft configuration you are using? When I run a modified version of the Vulcan using AeromatiC++ I get some strange output and it looks like it still doesn't handle delta wings really well. This, for example, could explain the random feeling of the problem: |
JSBSim as the FDM doesn't have a high-level option/facility to set things like weather. It only has lower-level options for wind to be specified and/or a turbulence model. By default there is no wind and no turbulence. So FlightGear must be setting the wind etc. So just to confirm, if you set FlightGear to the equivalent of no weather and no turbulence do you still see these issues? |
In terms of the difference between the UVW velocities, i.e.
versus
The properties with // Combine the wind speed with aircraft speed to obtain wind relative speed
vAeroUVW = in.vUVW - in.Tl2b * in.TotalWindNED;So if your aircraft is sitting still on the ground with the brakes on, and assuming no bouncing around, then the |
|
I have finally realised how to set the wind (silly me) and the experiment I ran appears to confirm that the alpha is highly sensitive to the wind direction but perhaps not the speed. What I did was:
The results are shown below: I make the following observations:
I have attached the configuration I currently use. The coefficients were initially based on Aeromatic output, but I had to change a few drastically in order to get stable flights. For instance, I had to increase the coefficient for pitch damp 10-fold (based on a wild guess). |
Remember I showed the code used by JSBSim to calculate alpha. So it simply depends on alpha = atan2(vAeroUVW(eW), vAeroUVW(eU));And this calculation is only performed if the following conditions are true, otherwise alpha is set to 0. if ( Vt > 0.001 )
if ( mUW >= 1E-6 )
Note size of these conditions, in your results above you only display 2-decimal places. So even if your results show 0.00 for U and W that doesn't mean they aren't still big enough to be used to calculate alpha.
This must be FlightGear's weather system ramping the wind down.
Again, JSBSim isn't implementing some sort of 'free-fall behaviour', it's simply using the formula listed above based on the U and W velocities. Which in your case with the aircraft at rest on the ground then the values for alpha that you see and it's rate of change is simply based on the wind vector that FlightGear is feeding into JSBSim. For example here is a photo I took of the alpha and beta vanes that were used on the first FTI system I worked on. While standing on the ground if there was a light breeze from behind the aircraft for example then the alpha vane would rotate to 180 degrees etc.
|
|
Thanks for the clarifications. If I have understood the issue a bit, then I might conclude:
If this is true, then it confirms my original suggestion of using negative drag at the start when alpha > 90. Alpha will revert to < 90 once the plane has enough motion. Why not just set alpha to zero until the plane begins to move? |
|
Sure in general alpha can vary between -180 to +180 degrees. But that doesn't mean you have to have data for things like Cl vs alpha across the complete 360 degree range. For example level-D airline flight simulators don't bother with Cl vs alpha across the full 360 degree range, typically they only have data for just past the stall. |
Do not set v ourselves, the caller does that. This fixes the second problem mentioned in issue #436
I'm submitting a ...
Describe the issue
What is the current behavior?
I used the parameters used in the attached file "vulcan.log" and the output is shown in "vulcan.txt". See the first function in the "LIFT" axis.
The program outputs the following error when run;
I am not sure what stall speed it expects. I have tried entering nothing and other reasonable values without any better luck.
What is the expected behavior?
In Aeromatic v1.1.5, we had the offer to generate propulsion and other system tiles. This seems to have be omitted in v1.1.6.
The alpha lift behaviour seems to be similar to issue #400 that I had reported before.
What is the motivation / use case for changing the behavior?
Simply revert to prior features.
Please tell us about your environment:
Other information
Refer to issue #400 for some prior problems with the output.
vulcan.log
vulcan.txt
The text was updated successfully, but these errors were encountered: