Improving glider realism

[B21]

Just to confirm the NASAL code by Hooray for TE compensation works like a charm *except* I had to correct an error in my formula: TE reading = (h2-h1)/t + (v2^2 - v1^2) / (19.62*t) .

[Hooray]

Here's, a slightly downstripped/reduced version of the same script, you may want to set the debug_enabled variable to check if the numbers are correct (or just check /instrumentation/te-vario using the property browser).

Code: Select all

##
# only actually call the function once the signal is sent (nasal directory is initialized)

_setlistener("/sim/signals/nasal-dir-initialized", func {
  var debug_enabled = 0;
 
  ## helpers
  #
  var FT2M=0.30480;
  var KT2MPS=1852/3600;
  var square=func(x) return x*x;
  var get_delta=func (current,previous) {return (current-previous);} 
  var state = {new:func {return{parents:[state]};},altitude_m:0,airspeed_mps:0,timestamp:0};
 
  var update_state = func {
     var s = state.new();
     s.altitude_m=getprop("/position/altitude-ft")*FT2M;
    s.airspeed_mps=getprop("/velocities/airspeed-kt")*KT2MPS;
    s.timestamp=systime();
    return s;
 }
 ##
 # debug info
 var s_dump = func(s) {
   print(s.timestamp," ", s.altitude_m, " ", s.airspeed_mps);
 }
 
 var tvario = {   
  new: func {return {parents:[tvario]};},
  state:{previous:,current:},
  init: func {state.previous=state.new(); state.current=state.new();}, 
  update:func {
   if (debug_enabled) print("\nUpdating TEV:");
   state.current = update_state();   
   if (debug_enabled) {
    s_dump(state.current);
    s_dump(state.previous);
   }
   var delta_t = get_delta(state.current.timestamp, state.previous.timestamp);
   # TE reading = (h2-h1)/t + (v2^2 - v1^2) / 19.62*t 
   if (debug_enabled) print("delta_t:",delta_t);
   var uncompensated = get_delta(state.current.altitude_m,state.previous.altitude_m) / delta_t;
   if (debug_enabled) print(" uncompensated:",uncompensated);
   var adjustment = get_delta(square(state.current.airspeed_mps),square(state.previous.airspeed_mps)) / (19.62 * delta_t);
   if (debug_enabled) print("  adjustment:",adjustment,"\n");
   var te_reading = uncompensated + adjustment;
   if (debug_enabled) print ("   te_reading:",te_reading);
   
   setprop("/instrumentation/te-vario/te-reading-mps",te_reading);   
   state.previous = state.current; # save current state for next call
   settimer(func me.update(), 1/2); # update rate: twice per second
  }
 };
 
 var tv = tvario.new();
 tv.init();
 tv.update();
});

FYI the 'delay' factor for instruments (i.e. particularly the vario) is something that has to be explicitly designed for (the 'instantaneous' vario reading could have spikes for any reason, depending on how the variables it's depending upon are implemented). E.g. in FSX the windspeed shifts in gusts are instantaneous, which would drive a vario with a simple formula bonkers. For the flight model this is rarely an issue because 'spikes' can be very short and the mass of the aircraft features in the formula somewhere and ths damps out the inputs. In an instrument though, you could see spikey needle movements. The general technique is to use a formula like "TE_needle = TE_needle * 0.9 + te_reading-mps * 0.1".

There are also various types of filters (lowpass/highpass) supported by FG, some of which are also available or even implemented using Nasal, so that's another way to design for such requirements.

I'll be able to plug this stuff together soon but I'm still at the very basics of understanding the FG config.

Is there anything in particular, that you need help with?

[bassmannate]

I was playing around with weather settings today while flying around LOWI and set the wind to blow from the north expecting to be able to turn left from take off and catch some ridge lift. Double checked the wind sock to make sure the wind was going where I thought it was. Went to where I thought the lift should be and instead found some HORRENDOUS sink!

So, I figured I had just gotten turned around and went to the other side of the valley and found plenty of lift. Flew around for a while and then landed. When I got down, I found the wind sock still blowing the direction I thought it was to begin with. The lift was on the BACK side of the mountains! Has anyone noticed this before? Is this just a bug with manual weather settings? I have been flying with real weather fetch until today and it seemed to be providing lift where I expected it to be.

I am using a CVS version that's about a week old.

[bassmannate]

Here's, a slightly downstripped/reduced version of the same script, you may want to set the debug_enabled variable to check if the numbers are correct (or just check /instrumentation/te-vario using the property browser).

Code: Select all

##
# only actually call the function once the signal is sent (nasal directory is initialized)

_setlistener("/sim/signals/nasal-dir-initialized", func {
  var debug_enabled = 0;
 
  ## helpers
  #
  var FT2M=0.30480;
  var KT2MPS=1852/3600;
  var square=func(x) return x*x;
  var get_delta=func (current,previous) {return (current-previous);} 
  var state = {new:func {return{parents:[state]};},altitude_m:0,airspeed_mps:0,timestamp:0};
 
  var update_state = func {
     var s = state.new();
     s.altitude_m=getprop("/position/altitude-ft")*FT2M;
    s.airspeed_mps=getprop("/velocities/airspeed-kt")*KT2MPS;
    s.timestamp=systime();
    return s;
 }
 ##
 # debug info
 var s_dump = func(s) {
   print(s.timestamp," ", s.altitude_m, " ", s.airspeed_mps);
 }
 
 var tvario = {   
  new: func {return {parents:[tvario]};},
  state:{previous:,current:},
  init: func {state.previous=state.new(); state.current=state.new();}, 
  update:func {
   if (debug_enabled) print("\nUpdating TEV:");
   state.current = update_state();   
   if (debug_enabled) {
    s_dump(state.current);
    s_dump(state.previous);
   }
   var delta_t = get_delta(state.current.timestamp, state.previous.timestamp);
   # TE reading = (h2-h1)/t + (v2^2 - v1^2) / 19.62*t 
   if (debug_enabled) print("delta_t:",delta_t);
   var uncompensated = get_delta(state.current.altitude_m,state.previous.altitude_m) / delta_t;
   if (debug_enabled) print(" uncompensated:",uncompensated);
   var adjustment = get_delta(square(state.current.airspeed_mps),square(state.previous.airspeed_mps)) / (19.62 * delta_t);
   if (debug_enabled) print("  adjustment:",adjustment,"\n");
   var te_reading = uncompensated + adjustment;
   if (debug_enabled) print ("   te_reading:",te_reading);
   
   setprop("/instrumentation/te-vario/te-reading-mps",te_reading);   
   state.previous = state.current; # save current state for next call
   settimer(func me.update(), 1/2); # update rate: twice per second
  }
 };
 
 var tv = tvario.new();
 tv.init();
 tv.update();
});

FYI the 'delay' factor for instruments (i.e. particularly the vario) is something that has to be explicitly designed for (the 'instantaneous' vario reading could have spikes for any reason, depending on how the variables it's depending upon are implemented). E.g. in FSX the windspeed shifts in gusts are instantaneous, which would drive a vario with a simple formula bonkers. For the flight model this is rarely an issue because 'spikes' can be very short and the mass of the aircraft features in the formula somewhere and ths damps out the inputs. In an instrument though, you could see spikey needle movements. The general technique is to use a formula like "TE_needle = TE_needle * 0.9 + te_reading-mps * 0.1".

There are also various types of filters (lowpass/highpass) supported by FG, some of which are also available or even implemented using Nasal, so that's another way to design for such requirements.

I'll be able to plug this stuff together soon but I'm still at the very basics of understanding the FG config.

Is there anything in particular, that you need help with?

I've been messing around with the TE vario script a bit and it works great. How would one implement either method of damping to keep the needle from constantly moving around?

[bassmannate]

I was playing around with weather settings today while flying around LOWI and set the wind to blow from the north expecting to be able to turn left from take off and catch some ridge lift. Double checked the wind sock to make sure the wind was going where I thought it was. Went to where I thought the lift should be and instead found some HORRENDOUS sink!

So, I figured I had just gotten turned around and went to the other side of the valley and found plenty of lift. Flew around for a while and then landed. When I got down, I found the wind sock still blowing the direction I thought it was to begin with. The lift was on the BACK side of the mountains! Has anyone noticed this before? Is this just a bug with manual weather settings? I have been flying with real weather fetch until today and it seemed to be providing lift where I expected it to be.

I am using a CVS version that's about a week old.

I'm still experiencing this. Anyone else notice? I'm getting LOADS of sink on the side that I'm expecting LOADS of LIFT. Am I just not understanding the physics correctly? The way I understand it is that wind blows over a ridge. the lift should be on the side of the ridge that the wind hits. There should be sink on the BACK side of that ridge/hill. Right? Or am I just completely wrong and this is being simulated properly?

[B21]

you are correct - sounds like something could be broken here - the lift is simply on the side of the hill the wind hits (assuming there isn't *another* bigger hill a short distance upwind (~2km) that is making overwhelming sink). I haven't tried the ridgelift in FG tho.

B21

[HHS]

You should mention it on the deve-list!

The ridge-lift will be one of the new and nice features which impvoves realism on FGFS in the next release, so it would be sad, if this is broken and wrong there....

[Torsten]

The ridge lift computations are based on this paper:
http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html
Last time I checked, it worked correctly and as expected. If you find anything misbehaving, please provide a reproducable scenario, especially
- wind setup (speed and direction on ground and at altitude)
- where (position with altitude) does this occour

Greetings and happy new year

Torsten

[WooT]

I have just checked it, and yes, it seems something has reversed the way it should work...

I will try to look into it.

[HHS]

I have just checked it, and yes, it seems something has reversed the way it should work...

I will try to look into it.

Thanks! Hopefully you get managed it before this sunday, as this is dead line for FGFS 2.0.0.
And it would be more than embarrassing if a new and outstanding feature is broken!!

[WooT]

ok, I have been checking what happens, the fix is easy.

probe 0 is under the plane. probe 4 should be downwind, probes 1,2 and 3 should be upwind.
the probes are reversed due to a little mistake when someone changed how the probe calculations are made.

in ridge_lift.cxx, line 174 is now :

Code: Select all

double ground_wind_from_rad = _surface_wind_from_deg_node->getDoubleValue() * SG_DEGREES_TO_RADIANS + SG_PI;

this should be :

Code: Select all

double ground_wind_from_rad = _surface_wind_from_deg_node->getDoubleValue() * SG_DEGREES_TO_RADIANS;

I'm trying to find someone on irc with commit rights, if I don't find, I'll send it to the dev list.

Thank you for pointing it out !

[WooT]

fixed, and commited by Torsten. Thank you.

I tested it my side and for me it looked good.
If you guys have a moment to confirm that it works as expected, it would be nice

[digriz]

fixed, and commited by Torsten. Thank you.

I tested it my side and for me it looked good.
If you guys have a moment to confirm that it works as expected, it would be nice

I just tried it out with the latest CVS and it seems to me that it works as it should again.
Had a nice round-trip from LOWI to Achensee with the ask21 and ridge-lift brought me up to nearly 8000 ft.

Thank you very much for fixing the bug!

Regards,
digriz.

[ksupilot]

Getting back into flight gear again, and gliders have always been my favorite to fly. How is glider realism in 2.0? Also, has any of the work mentioned in this thread reflected in Flight Gear 2.0?

[WooT]

How is glider realism in 2.0?

So far I would say it is very basic, but some sights let me think it might change soon :

2.0 included the ridge lift simulation, and terrain turbulence was also added some time ago ( was it already in 1.9 ? I don't remember ).

Some major work is beeing done by Thorsten, in the large scope of weather simulation, but some parts of his work are very interesting for glider simulation, I am thinking specially of thermal simulation and local wind conditions. You can read this ( long ! ) thread for more information : http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358. Note that this is now part of CVS, still a lot of work to be done but really very promising !

In my opinion, there is also a big lack in the FDMs that are available for glider simulation. Neither jsbsim or yasim provide a way to simulate local variations of lift/windspeed across the glider wing scale, such a feature would add a lot to thermal/ridge flying feeling. So far the airmass is considered uniform all over the aircraft.
Creating a FDM or modifying those that already exist is far beyond my capacities...

At a more modest scale, I added a new glider to the FG fleet, it is the Schleicher ASK13, available in CVS or here : http://www.flightgear.org/forums/viewtopic.php?f=4&t=7531