Board index FlightGear Development Weather

Improving glider realism

Everything related to weather simulation, visuals should be discussed in the shader subforum.

Re: Improving glider realism

Postby WooT » Sat May 29, 2010 12:30 pm

I have implemented a new variometer for gliders.

As discussed before, in this thread, one of the things missing in FG for better glider realism, is total energy compensated variometers.

I choosed the ilec-sc7, because it is very popular, easy to use, and well featured.
It is available in the fgdata GIT repo ( git://gitorious.org/fg/fgdata.git ), you can find it in Instruments-3d/glider/vario/ilec-sc7/
If you wish to use this vario in your glider, you will have to put the xml in your model , include the .nas in your set.xml, and modify your sound.xml. See the README_install file for instructions about sound implementation.

Image

As you can see on the picture, the classic vario ( top left ) shows a positive reading, because I was pulling on the stick to slow down.
The ilec-sc7, compensated for total energy, shows a negative value, this is my actual sink rate in the air mass.

I based my work on the code by Hooray here :http://www.flightgear.org/forums/viewtopic.php?f=6&t=4706&st=0&sk=t&sd=a&start=15#p35604, ( please Hooray tell me if it is ok ! )
and modified it to suit the ilec-sc7 features :

Image

** The top most switch is the audio mode : OFF is no audio, MUT is only positive audio indication, and ON is both positive and negative audio indication.
** The VOL knob on the right is for audio volume.
** The temp/batt switch is not implemented, the real one is used to display outside temperature and battery charge.
** The bottom switch labelled "1-S-3" is for setting the filter lenght. The ilec-sc7 has a built in filter to smooth the needle reading. "1" will smooth the output over a 1 second delay, while "3" does the same over 3 seconds, in this case the output delay is close to a classic vane vario.
** The digital numbers are displaying the average sink/lift rate over 30 seconds. This is quite useful to determine if a thermal is worth climbing until the top, in comparison with the average lift found on a flight.

The real manual for the ilec-sc7 is available here : http://www.ilec-gmbh.com/manuals/sc7.pdf

I equiped the ASK13 with the new vario, I found it works great and makes thermal flying in Thorsten's local weather much more efficient. ( see viewtopic.php?f=5&t=7358&start=90#p78565 for details ).
You can find the updated ASK13 in the git repo.

Please note that my implementation of the 1-3 seconds filter is not very realistic, in the sense that it is FPS dependant. I'm not comfortable enough with nasal scripting yet to find a more accurate solution, but based on empiric tests in flight, the result seems satisfying for thermal flight decision taking, the switch allowing yo choose between a fast or a slower needle response.

The screenshots here are in a new glider I am working on, the Centrair Pegase. Given Thorsten's work , I have a feeling we will soon have a great environment for soaring, so I thought it deserves a better race class glider :) More news soon !
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 4:09 pm

Re: Improving glider realism

Postby Hooray » Wed Jun 09, 2010 11:52 am

WooT wrote:Please note that my implementation of the 1-3 seconds filter is not very realistic, in the sense that it is FPS dependant. I'm not comfortable enough with nasal scripting yet to find a more accurate solution, but based on empiric tests in flight, the result seems satisfying for thermal flight decision taking, the switch allowing yo choose between a fast or a slower needle response.


I have not yet looked at your code, but there are several properties in the property tree under /sim/time for "timing purposes", you may want to take a look at $FG_ROOT/gui/dialogs/timeofday.xml

Also, there is the systime() function available in Nasal itself to get accurate timing information.
Let me know if you need help using this information to improve your instrument.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Improving glider realism

Postby WooT » Wed Jun 09, 2010 12:20 pm

Well, the problem is a bit more complex , and comes from my implementation of the fliter, rather than from the timing methods I used.

What I did is simply : needle-position = old-needle-position + ( 1-fliter ) * new-value + filter * new-value

The scripts does this at a fixed rate ( 20 Hz ) , so, the smaller the filter is, the longer it takes to smooth reading.
The values of 20 HZ and the filter values were set by experimenting, and in the end, the result works as one would expect from a vario with a 1 - 3 sec filter.

What I meant is that my implementation doesn't take time into account, other than the frequency at which the script runs.

Implementing an accurate time filter would require to use a totally different algorithm, but despite my reading on the subject, I did not manage to do that, the math being a bit above what my brain could process at this point...
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 4:09 pm

Re: Improving glider realism

Postby Hooray » Wed Jun 09, 2010 12:28 pm

okay, I see - what I was understanding is that you were using the fps counter to obtain timing information, never mind!
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Improving glider realism

Postby Thorsten » Sat Jun 19, 2010 7:38 am

Thanks to Hooray who recently provided me with a pre-compiled GIT binary, I have now finally had the occasion to test-fly the Glider's Sky weather tile. I did so in the French Alps, starting from Grenoble, flying southward.

It sounds a bit odd to say this, because I coded it (but then, I did so without opportunity to test, which was weird in itself) - but I think it's a pretty fantastic experience - that was one of the most memorable flights I have done in Flightgear.

Basically, a lot of real-life problems and situations is there already.

I started from Grenoble at about 16:45 local time - with good cloud development, cloud base about 1000 m above the valley floor. I dragged the conditions slider a good bit towards 'rough day' (i.e. narrow, strong thermals) since the ASK-13 can actually fly rather slow and fly tight turns.

Despite having promising clouds nearby, I did not manage to get on the way in the first two tries and had to return to the airfield. Basically, one doesn't know in advance how good the conditions beneath a cloud will be. Furthermore, due to the wasp-waisted geometry, the thermals are rather narrow at winch launch altitude, so they are easy to miss, difficult to center, and if the lift is large, so is the sink surrounding it.

On the third try, I found a good cloud getting me up to 1100 m above airfield altitude (I tend to set my altitude to zero at the airfield, so all altitudes quoted are above Grenoble). With the current system, the wind does not move the thermal, so one has to account for this and continuously re-center the thermal. This can be seen as a bug, but in some sense also as a feature, because that is more or less what one would have to do if we had thermals leaning in the wind. Once close to cloud base, riding the thermals is much easier, as they are considerably wider and I cloud quickly get on my way from there.

Due to the altitude determination of the clouds, there was some 700-800 m leeway to climb above the clouds in the valley when catching a thermal with a base on higher terrain. But that's tricky - one has to fine the right stepping stone into the higher altitudes, but the base of the thermal of really high clouds may be unreachable from the lower valley thermals. I tried two times to get east into the mountains proper, but did not succeed (I did manage on a shorter flight the day before, and that was really exciting - catching a thermal close to a cliff, carefully working my way upward from there...).

I then continued south into rising terrain. Again, since the cloudbase follows to some degree, I was ultimately able to get all the way up to 2100 m in several steps, which allowed me to cross the mountain range southward toward Veynes. This has all the excitement of the real thing - the question 'will I make it?' as one approaches the pass height, the danger of falling into a sink in the lee of a ridge, the opportunity to ride weak ridge lift (just to reduce sinkrate as I pushed forward), then the relief as it became apparent I had indeed crossed and the terrain was falling before my eyes.

Shortly before Veynes, I was entertaining the idea of catching another thermal and push all the way to Gap - however by that time, it was already evening (after 19:15 local time) and the available lift was already considerably reduced. I had bad luck with two clouds I tried, and then decided to play it safe and land in a field next to a village.

Basically, a lot of the decision-making I remember from my few real flights in the mountains is there.

I wonder what people would want me to improve at this point. What is on the agenda is dynamics - the evolution and decay of thermals, as well as wind drift. But that's hellishly difficult, especially if you think of mountains.

Another thing that came to my mind was a problem I had with ridge lift. I figured out the hard way that it only works properly when one kills the windspeed reduction in the boundary layer, because one approaches so close to the mountain to ride the ridge. But that means that the bounday layer is also not there for landing - while usually one can align the nose of the aircraft with the runway on the final 20 m of descent, with the boundary layer absent this never happens - which is a bit weird. I've thought about taking over the whole windfield in Nasal and then making this more sophisticated - basically the boundary layer would be effective below the median altitude of the terrain, but absent above - so one could have the usual slowdown of wind close to the ground when landing on the valley floor, but good ridge lift above on the high slopes.

Are there similar small points which one could easily address? With WooT's detailed model of the thermal, we also have a lot of control over shape parameters, which is not fully exploited as of now, so there are lots of knobs to fine-tune the experience, the problem is just that someone needs to let me know which direction to turn them.
Thorsten
 
Posts: 10638
Joined: Mon Nov 02, 2009 8:33 am

Previous

Return to Weather

Who is online

Users browsing this forum: No registered users and 0 guests