Board index FlightGear Development Nasal

787 MFD Vertical Profile Nasal (prev. Calculating Elevation)

Nasal is the scripting language of FlightGear.

787 MFD Vertical Profile Nasal (prev. Calculating Elevation)

Postby omega95 » Fri Feb 03, 2012 8:31 am

How do we calculate elevations of ground ahead of us, say an average every mile for the next 100 miles? I know that skyop has done this for the moving map in the A330-300, but then that's not released, so I can't have a look at that.

And other than that, where is the distance between waypoints stored? It'd also be really awesome if someone can tell me which file makes the calculations for the map (Equipment > Map)

Thanks a lot.
Last edited by omega95 on Fri Feb 03, 2012 1:28 pm, edited 1 time in total.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Calculating Elevation and Distance between waypoints

Postby Thorsten » Fri Feb 03, 2012 8:45 am

This is from Local Weather's compat_layer.nas and returns terrain elevation in ft for given (latitude,longitude).

Code: Select all
var get_elevation = func (lat, lon) {

var info = geodinfo(lat, lon);
   if (info != nil) {var elevation = info[0] * local_weather.m_to_ft;}
   else {var elevation = -1.0; }

return elevation;
}


You'd use basic trigonometry to calculate the projected (lat,lon) along your given heading (don't bother with spherical trigonometry, for 100 miles the corrections are tiny) and embed that into a loop.

Some points worth noting:

* you can't get terrain elevation for terrain which isn't yet loaded, and that depends on visibility range, so you can't sample 100 miles ahead unless your visibility is ~170 km - which a default Flightgear core doesn't support, it limits you to 120 km.

* geodinfo(); by nature returns elevation in m, not in ft.

* even if it is now much faster than it used to be, geodinfo() is still slow. Don't ever use this in a per-frame loop to get all points you want at once (I have seen a moving map doing precisely that which had a truly lousy framerate). Get one data point per frame and if you're through your ray, sample from the beginning. You can easily maintain an elevation map of 4000 points that way at almost no framerate cost, because terrain elevation doesn't ever change from frame to frame.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Calculating Elevation and Distance between waypoints

Postby jeep » Fri Feb 03, 2012 8:59 am

i think you can download a343 here http://gitorious.org/airbus-aircraft/a343/trees/master (click on Download master as tar.gz)
jeep
 
Posts: 73
Joined: Mon Feb 14, 2011 10:37 am

Re: Calculating Elevation and Distance between waypoints

Postby omega95 » Fri Feb 03, 2012 10:25 am

First of all, thanks a lot Thorsten.

Thorsten wrote in Fri Feb 03, 2012 8:45 am:* even if it is now much faster than it used to be, geodinfo() is still slow. Don't ever use this in a per-frame loop to get all points you want at once (I have seen a moving map doing precisely that which had a truly lousy framerate). Get one data point per frame and if you're through your ray, sample from the beginning. You can easily maintain an elevation map of 4000 points that way at almost no framerate cost, because terrain elevation doesn't ever change from frame to frame.


I don't think I understood that correctly. Did you mean to get 1 every frame and then just move that elevation variable back and then get the next one, instead of getting all every frame?

And btw, do you know how to get the TCAS and wxradar to work? It doesn't seem to be working for me.

Thank you.

EDIT :

Code: Select all
info[0] * local_weather.m_to_ft;


Is that part of the code to convert meters to feet?
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Calculating Elevation and Distance between waypoints

Postby Thorsten » Fri Feb 03, 2012 10:51 am

Did you mean to get 1 every frame and then just move that elevation variable back and then get the next one, instead of getting all every frame?


Say I want to have 100 elevation points along my current course in 1 km spacing. In an aircraft-centered Cartesian system, the first point is (0, 1000.0) (which I can then transform to (lat,lon) to call the routine), the second point is (1,2000.0) and so on. I get the first point in frame 1. In frame 2, I know that I no longer know the elevation of (0,1000) but (0, 1000.0 - groundspeed_ms * dt) where dt is the frame duration and groundspeed_ms is the ground speed in meters per second - this is *much* cheaper to compute than re-sample (0,1000.0), so I can get my second point in frame 2 at (0,2000 - groundspeed_ms * dt) if you really want to keep the same offset.

Given that even at Mach 1 you just move 330 m/s, which with a halfway decent framerate translates into 11 m/frame, and given that terrain doesn't change elevation that rapidly, you might as well sample the second point at (0,2000) and not bother about the movement until you have sampled all 100 points 100 frames later.

So yes, just get one or two per frame and handle the rest Nasal-internally if needed.

And btw, do you know how to get the TCAS and wxradar to work? It doesn't seem to be working for me.


I'm not really into instruments, but I think the Concorde had a working TCAS at some point (?). It'd be surprised if wxradar works - giving our way of creating clouds, it'd need to show a few thousand dots which might kill framerate very efficiently. Also, cloud position info isn't actually in the property tree, but mostly inside the shader codes, getting it out might not be very efficient either.

Code: Select all
local_weather.m_to_ft


is a number - use Wikipedia to look it up.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Calculating Elevation and Distance between waypoints

Postby Hooray » Fri Feb 03, 2012 11:03 am

I guess we could look into generalizing your split frame loops implementation and move it into the $FG_ROOT/Nasal directory, so that people can easily create their own split frame loops?
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Calculating Elevation and Distance between waypoints

Postby omega95 » Fri Feb 03, 2012 11:09 am

Code: Select all
var x = poslon * 60;
var y = poslat * 60;

var xoffset = me.loopnum * math.sin(heading);
var yoffset = me.loopnum * math.cos(heading);

# Calculate elevations for the next 50 nautical miles (only 1 mile every frame)

setprop("/controls/navigation/vert-profile/nm" ~ me.loopnum, get_elevation((y + yoffset) / 60, (x + xoffset) / 60));


Poslat is our latitude and Poslon is our longitude.

Now, me.loopnum starts from 1 and goes on till 50 (not 100 nm) and the resets. Advances 1 every frame basically, so with this, it calculates only 1 point every frame and with a normal fps of about 40 to 60 fps, it shouldn't be that much noticeable as you're not going to move so much in a sec (each point gives elevation for 1 nm).

What do you think?
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Calculating Elevation and Distance between waypoints

Postby Hooray » Fri Feb 03, 2012 11:18 am

Thorsten wrote:It'd be surprised if wxradar works - giving our way of creating clouds


Agreed, but thinking about it: It might be possible to work around this by modifying Stuart's "add-cloud" fgcommand to simultaneously record some meta information for each instantiated cloud that could then be processed by the wxradar subsystem to create a reasonable radar picture.

That would probably be a matter of mapping cloud position (lat,lon,alt) and cloud type (3D dimensions) to an appropriate radar pixel type.

Once a certain "density" of pixels is reached, the pixels would be rendered to the radar texture.
While that would be somewhat of a "hack", it should work to make wxradar work with your local weather system.

Am I missing anything?
I am going to get in touch with Stuart (clouds maintainer) and ThorstenB (wxradar) to get some additional feedback.
Last edited by Hooray on Fri Feb 10, 2012 4:00 pm, edited 1 time in total.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Calculating Elevation and Distance between waypoints

Postby omega95 » Fri Feb 03, 2012 11:57 am

Finished the code and did some quick textranslate animations... Started at Sao Paulo (cuz I know this place has a few mountains close to the airport) and initialized the nav mode in the MFD. Here're the vertical profile so far, it refreshes every second or something when you move and doesn't cause any noticeable impact on the FPS. :D

Image

Btw, why did the function return -1 from 25 to 50 nm? When I turn the plane around, those work fine...
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Calculating Elevation and Distance between waypoints

Postby Hooray » Fri Feb 03, 2012 1:29 pm



That's pretty neat. This sort of display is called a VSD (Vertical Situation Display):
http://www.boeing.com/commercial/aeroma ... 0/vsd.html
http://hoeprr.home.xs4all.nl/DreamHC/Do ... iefing.pdf
http://www.smartcockpit.com/data/pdfs/f ... Safety.pdf
http://human-factors.arc.nasa.gov/publi ... Aero98.pdf


You are actually proving me wrong by coming up with this display: A couple of years ago, I claimed that creating such displays from Nasal space wouldn't be possible: viewtopic.php?f=14&t=12499&p=134913&hilit=vsd#p134913

Also, 5 years ago, this was discussed over at the atlas tracker here: http://sourceforge.net/tracker/?func=de ... tid=359456

Normally, you would query a terrain corridor with a certain "safety width" to do this type of thing, not just a straight line.
Also, the geodinfo() calls seem to be fairly safe to be called from a background/worker thread, i.e. if you are interested in higher resolution queries.



omega95 wrote:And other than that, where is the distance between waypoints stored?

For active routes this should be stored in the property tree under autopilot/route-manager.
For example, the HUD shows the remaining distance to the next waypoint.

omega95 wrote:It'd also be really awesome if someone can tell me which file makes the calculations for the map (Equipment > Map)

http://gitorious.org/fg/flightgear/blob ... Widget.cxx
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 787 MFD Vertical Profile Nasal (prev. Calculating Elevat

Postby omega95 » Fri Feb 03, 2012 1:33 pm

I created a new line that shows the descent/climb slope in the vertical profile. Here's the code:

Code: Select all
var verticalspeedfps = getprop("/velocities/vertical-speed-fps");
var groundspeedfps = getprop("/velocities/groundspeed-kt") * 1.68780986;

var indaltitude = getprop("instrumentation/altimeter/indicated-altitude-ft");

var slope = (57.2957795 * math.atan2(groundspeedfps, 0 - verticalspeedfps)) - 90;
setprop("/controls/navigation/descent-slope", slope);

var linelength = 0;

var convfactor = 1500; # Testing this value (seems to work fine)

var xavail = 50; # The box shows elevations upto 50 nm

# I'll have to do some weird calculations to keep the descent slope inside the vertical profile box

# Climbing

if (slope > 0)
{

var yavail = 40000 - indaltitude; # yavail is in feet

} else { # Descending

var yavail = indaltitude;

}

if (yavail < math.abs(convfactor * 50 * (math.sin(slope / 57.2957795) / math.cos(slope / 57.2957795)))) { # The end of the line does not go on till the end of teh space given.

linelength = (yavail / convfactor) / math.sin(slope / 57.2957795);

} else { # Here, it does

linelength = 50 / math.cos(slope / 57.2957795);

}

setprop("/controls/navigation/descent-line-length", math.abs(linelength));


The bottom half of it is to create a virtual box to keep the line inside. A textranslate animation controls the length of the line. :wink:

Image

Image

Now, I need to place markers showing the vnav altitudes set for the waypoints coming up... How do I calculate the distance between 2 waypoints (somewhere in between) so I can place them out?

@Hooray : I know that most modern glass cockpits have the vertical profile in the MFD, so how do we generalize this when it's done?

EDIT : After looking at some more pictures of real VSDs (thanks for telling me what it is), this looks kind of... pixelated. And I just thought of an awesome idea to make it look better (basically, less pixelation) without compromizing framerate at all! As we're doing 1 point per frame, the quality doesn't really affect framerate. I'll do some work on it and get back.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: 787 MFD Vertical Profile Nasal (prev. Calculating Elevat

Postby Hooray » Fri Feb 03, 2012 1:46 pm

That's looking more and more promising.

I wouldn't worry about generalizing things too early, though.
Currently, you still seem to be adding some features.
But once things are finished, I can have a look so that the code is turned into an instrument that can be easily used by aircraft developers.
One thing to keep in mind here is that a modern multi-crew cockpit may need to be able to run several instances of such a display, possibly also using differently configured ranges.

Basically, it would be good for people to simply load the instrument and the associated Nasal code, so that things work.

So it would be good not to hard-code the property paths, but rather use an index here:
For example /instrumentation/vsd[0] /instrumentation/vsd[1]

Also, the underlying Nasal code could cache the geodinfo() calls, so that both instruments can use the same cache and don't need to run redundant terrain queries. In other words: if 2 VSD are running with identical range settings, there shouldn't be any unnecessary terrain queries at all.

This can be accomplished by using memoization, i.e. by only doing a geodinfo(lat,lon) call if there were not previously any queries done with the same coordinates (which would be saved in a hash or vector then).

From a feature point of view, there are actually some cool things you could add to this, such as:
  • making colors configurable (altitude constraints, danger altitude)
  • use an average altitude for a configurable corridor width
  • optionally display symbols for AI/MP traffic (vertical TCAS view)
  • show route manager information (waypoints, level off altitudes)

Also, testing should probably be done in some really mountainous terrain such as KRNO or LOWI.


How do I calculate the distance between 2 waypoints (somewhere in between)

That's easy: there are helper functions for this available in $FG_ROOT/Nasal/geo.nas:
http://gitorious.org/fg/fgdata/blobs/ma ... al/geo.nas
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 787 MFD Vertical Profile Nasal (prev. Calculating Elevat

Postby omega95 » Fri Feb 03, 2012 1:59 pm

Hooray wrote in Fri Feb 03, 2012 1:46 pm:So it would be good not to hard-code the property paths, but rather use an index here:
For example /instrumentation/vsd[0] /instrumentation/vsd[1]


Well, I'm not really sure about what you're talking about here... I mean the VSA would be same in all instances/displays in the aircraft, wouldn't it?

And, atm the VSD is combined with the ND, so after I finish with this, I'll upload everything and probably you can generalize it? (I have no idea how to)

Hooray wrote in Fri Feb 03, 2012 1:46 pm:From a feature point of view, there are actually some cool things you could add to this, such as:

making colors configurable (altitude constraints, danger altitude)
use an average altitude for a configurable corridor width
optionally display symbols for AI/MP traffic (vertical TCAS view)
show route manager information (waypoints, level off altitudes)


1. Colors Configurable : I'm working on that > Using Emissions according to different altitudes comparing with your altitude.

2. I didn't understand that, can you elaborate? :|

3. That'd be awesome! But first, I need to try to get a tcas (horizontal) to look into.

4. That was the actual purpose of this Vertical profile :wink: , I'll work on it as soon as I complete the VSD.

EDIT : Lol, I'm really glad that I decided to give a shot at nasal. :mrgreen:
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: 787 MFD Vertical Profile Nasal (prev. Calculating Elevat

Postby Hooray » Fri Feb 03, 2012 2:16 pm

Having more than one VSD in a cockpit means that each VSD may have different settings.
For example, the copilots VSD range may be set to 50 nm, while the captain's VSD range may be set to 100 nm.
Basically, this means that several instances of the same instrument may need to work with different data at run time.

Just imagine a traditional ND or PFD/AI: There are pilot-specific settings available, which do not usually affect the other pilot.
Thus, using a dedicated location in the property tree ensures that each "version" (instance actually) of the instrument can work with its own "private settings".

If your VSD implementation is already part of the ND, then, I'd assume each ND has already its own VSD, too - right?
Browsing the property tree, you should see your VSD-specific properties show up in dedicated sub branches of each ND, right?


Regarding the corridor: Sampling a straight line from the aircraft doesn't really cater for safety requirements.

In other words, the aircraft is unlikely to actually "fly that particular straight line". That's why avionics use an averaged altitude (Minimum Safe Altitude actually) based on a "corridor" ahead of the aircraft.
Say, you'd define the corridor to be 0.5-1 nm wide, that would mean that the avionics would query the MSA for that corridor, and show the LOWEST altitude for that corridor.
Yes, that means more terrain sampling - so you may want to disregard this for the moment. But that's actually how it works in real life. The links I posted previously go into much greater detail, if you are interested in this.

Regarding TCAS, for your instrument you don't actually need to instantiate an actual TCAS at all. In its simplest form, you could simply "cheat" and directly process the properties under /ai/models, where you can find all AI and multiplayer aircraft. So, your Nasal script can iterate over this list and dynamically add symbols for those aircraft next to you.
A while ago, I wrote a short tutorial on this, and added it to the wiki: http://wiki.flightgear.org/Howto:_Worki ... properties
Last edited by Hooray on Fri Feb 03, 2012 2:34 pm, edited 1 time in total.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 787 MFD Vertical Profile Nasal (prev. Calculating Elevat

Postby omega95 » Fri Feb 03, 2012 2:19 pm

I did some work to increase the resolution but now, I have another problem. In the code, I increment the nm value by 0.5 every loop, but at some places, why does it end up as 0.49999999999999 instead of 0.5? That doesn't let the animation work in those areas. :(

Here's a screenshot of what I'm talking about.

Image
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Next

Return to Nasal

Who is online

Users browsing this forum: No registered users and 6 guests