Board index FlightGear Development Aircraft Cockpit development

ND prototype (not even in Git, yet)

Discussion about creating 2d and 3d cockpits.

ND prototype (not even in Git, yet)

Postby zakalawe » Sat Jun 18, 2011 6:03 pm

Image

I've forked the wxradar code to provide a basic, currently Boeing-style, navigation display layer. Specifically, the idea is the provide all the parts that can't easily be done using XML animations. Right now it's Boeing style, but my plan is to add enough config options, to fake the equivalent Airbus, Garmin and Primus displays - probably not perfectly, but still a nice step forwards I think.

What works - showing stations, airports, tuned navaids, route path and waypoints, and traffic (using ThorstenB's TCAS code from the wxradar). Once I get that finished, my plan is to add separate 'instruments', i.e textures, for terrain (TERR) and get wxradar working again to show actual weather.

Won't be in Git until after 2.4.0 is branched, however!
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: ND prototype (not even in Git, yet)

Postby Gijs » Sat Jun 18, 2011 6:31 pm

Wow, that looks awesome! Finally we can get all (or at least a lot of) the goodies modern airlines have to offer! :)
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9384
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: ND prototype (not even in Git, yet)

Postby Sealbhach » Sat Jun 18, 2011 8:27 pm

This looks brilliant! Is there much of a framerate hit at the moment?

.
Sealbhach
 
Posts: 942
Joined: Wed Jun 30, 2010 9:17 am

Re: ND prototype (not even in Git, yet)

Postby scotth1 » Tue Jun 21, 2011 9:35 am

Fantastic!

I've written a lot of Nasal code to get only half of that functionality on the A380.....

One thing I would add is that the existing waypoints don't seem to contain enough information, I've written some more Nasal classes to handle SID/STAR/IAP, Top of Climb and Top of Descent pseudo waypoints and Altitude constraints versus FMS calculated altitudes etc.



S.
scotth1
 
Posts: 231
Joined: Thu Jan 01, 2009 3:27 am
Location: Australia
Callsign: VH-SHA
Version: Git next
OS: Linux 3.4.11

Re: ND prototype (not even in Git, yet)

Postby zakalawe » Tue Jun 21, 2011 11:48 am

scotth1 wrote in Tue Jun 21, 2011 9:35 am:One thing I would add is that the existing waypoints don't seem to contain enough information, I've written some more Nasal classes to handle SID/STAR/IAP, Top of Climb and Top of Descent pseudo waypoints and Altitude constraints versus FMS calculated altitudes etc.

Right, and that's the next question - I don't want to hard-code that kind of logic in C++, if I can avoid it - but we need to work out a way for Nasal to set the values into the route-manager or GPS data, so the ND can pick it up - especially all the cruise/phase-of-flight/altitude/energy stuff. I apologise for being lazy, but can you remind me where the relevant Nasal code is? Then we can have a discussion (possibly involving some other people) about which parts can be in C++, and some standard locations the ND can look for Nasal-computed value, and so on.

BTW, I'm lacking a good set of photos of the Airbus displays - the sooner I know what I need to cover, the happier I'll be - do you know of any suitable resources?
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: ND prototype (not even in Git, yet)

Postby scotth1 » Tue Jun 21, 2011 2:12 pm

I've sent you a PM about this.

As a starting point for discussion, the fmsWP class I have looks like;

var fmsWP = {
new : func {
var me = {parents:[fmsWP]};

me.wp_name = ""; # fix, navaid or pseudo waypoint name
me.wp_parent_name = ""; # if a SID/STAR WP then the SID/STAR name, or AIRWAY name
me.wp_type = "FIX"; # FIX, NAVAID, Termination Point, transition wp, Final Fix, Appr Fix, RWY transition, SID/STAR WP
me.fly_type = "FlyOver"; # flyOver, flyBy, Hold, (not used)
me.action = "DIRECT"; # direct, trk, intercept, vectors (not used)
me.wp_lat = 0.0; # latitude
me.wp_lon = 0.0; # longitude
me.alt_cstr = 0; # alt constraint from db or calculated altitude in ft
me.alt_cstr_ind = 0; # if the alt is a programmed constraint or just calculated (as part of STAR)
me.spd_csrt = 0; # spd constraint in kts or zero
me.hdg_radial = 0.0; # either heading/track or radial
me.leg_distance = 0; # NM for this leg
me.leg_bearing = 0.0; # deg bearing for this leg
return me;
},
}


S.
scotth1
 
Posts: 231
Joined: Thu Jan 01, 2009 3:27 am
Location: Australia
Callsign: VH-SHA
Version: Git next
OS: Linux 3.4.11

Re: ND prototype (not even in Git, yet)

Postby skyop » Fri Jun 24, 2011 4:19 am

Excellent job, James! It's great to see all of this coming together. You will find them in the CRJ700 and A320 the day those new instruments make their way into Git. :)
Aircraft: [ CRJ700-family | DC-10-30 ] Scenery: [ KBFL ]
skyop
 
Posts: 3047
Joined: Mon Jun 14, 2010 12:40 am
Location: Austin, Texas, USA
IRC name: skyop
Version: next
OS: Fedora 23/Windows 10

Re: ND prototype (not even in Git, yet)

Postby Hooray » Wed Aug 31, 2011 12:41 pm

zakalawe wrote:I've forked the wxradar code to provide a basic, currently Boeing-style, navigation display layer. Specifically, the idea is the provide all the parts that can't easily be done using XML animations. Right now it's Boeing style, but my plan is to add enough config options, to fake the equivalent Airbus, Garmin and Primus displays - probably not perfectly, but still a nice step forwards I think.


This does indeed look very promising!


zakalawe wrote:What works - showing stations, airports, tuned navaids, route path and waypoints, and traffic (using ThorstenB's TCAS code from the wxradar). Once I get that finished, my plan is to add separate 'instruments', i.e textures, for terrain (TERR) and get wxradar working again to show actual weather.


Yes, it would really be great if each "layer" (so to speak) could be enabled/disabled by setting a property and dynamically customized by a number of configuration properties that can be controlled from Nasal.

zakalawe wrote:Right, and that's the next question - I don't want to hard-code that kind of logic in C++, if I can avoid it - but we need to work out a way for Nasal to set the values into the route-manager or GPS data, so the ND can pick it up - especially all the cruise/phase-of-flight/altitude/energy stuff.


I really agree that these things don't belong into the C++ code. It would be great if the underlying C++ code would just become sort of a controller that can be highly customized from Nasal.

zakalawe wrote:Then we can have a discussion (possibly involving some other people) about which parts can be in C++, and some standard locations the ND can look for Nasal-computed value, and so on.


FWIW, you may find this interesting: I have been working a bit with the ARNIC661/j661 stuff lately and there we have a feature where we can ask an instrument to render a symbol at at certain geographic position (lat/lon, alt), i.e. the translation to screen/texture coordinates is implicitly done by the server - the client side (i.e. the Nasal script) doesn't even care about screen or texture coordinates (in fact it doesn't even know about them), it just sends a message to the CDS asking it to render a certain symbol (i.e. a VOR symbol) at certain geographic coordinates.

OTOH, things like changing the resolution/range of the display are internally handled by the CDS (server).

If this approach could be duplicated in the underlying C++ controller in FlightGear we would have a very powerful and flexible foundation for creating pretty much arbitrary displays, not just in C++ but also directly from Nasal, just setting a bunch of properties in the property tree for rendering symbols to a texture would be very easy to do, and all the hard and time-critical stuff would be done in C++ space.

Most positions available in the property tree (AI traffic, multiplayer etc) could be directly retrieved by a Nasal script and sent to a configurable branch in the property tree, along with a configurable texture/image to be used for each element.

The displays you are creating right now could in fact leverage such a wrapper module.

Displaying meta information such as altitude, speeds or time could be achieved by supporting a "tag" node for each symbol that maps to the OSG-Text animation that is already supported by other parts of OSG.

This would make it possible to set a bunch of properties (position, altitude, image) and then set the text (style, size, font) to be used separately.

In the FlightGear context that would mean that we need some type of RTT-capable texture controller that has a number of registered listeners for sending such "messages" to the C++ controller using the property tree.
Pretty much like you mentioned previously when you were talking about "control properties" for customizing the appearance of the display.

In ARINC 661 we also have the option of chosing between two different types of map representations: horizontal and vertical maps.

This means that the CDS internally translates geographic coordinates such as (lat/lon/alt) to either a horizontal view or a vertical view.

This is for example used for VSDs (Vertical Situation Displays):

Image


http://www.b737.org.uk/images/vsd.jpg
http://www.b737.org.uk/navigation.htm#V ... on_Display
http://www.vitzethum.de/displays/gallery/index.html

zakalawe wrote:BTW, I'm lacking a good set of photos of the Airbus displays - the sooner I know what I need to cover, the happier I'll be - do you know of any suitable resources?


There's a some fairly detailed info available here (including drawings and pictures of Airbus NDs):
http://www.airbusdriver.net/EFIS5.pdf
http://www.captainpilot.com/files/AIRBUS/A320_meta.pdf
http://www.smartcockpit.com/data/pdfs/p ... _Guide.pdf
http://a320.zakadum.ru/FCTM2010.pdf
http://www.smartcockpit.com/data/pdfs/p ... Pilots.pdf
http://airalph.free.fr/Manuel-A320.PDF
http://www.avdyne.com/airbus_training/22zAutoflt.pdf
http://chihchin.sg1002.myweb.hinet.net/ ... 0Notes.pdf
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: ND prototype (not even in Git, yet)

Postby g.hekt » Tue Sep 13, 2011 11:27 am

Wow! This is amazing! I really hope to see it soon in action. Good luck!
Music @ http://www.soundcloud.com/georghekt
Albums on iTunes, junodownload & such
free downloads @ http://www.stigaemusic.com
Flying in South-East Europe with a HondaJet/Citation X
User avatar
g.hekt
 
Posts: 26
Joined: Tue Mar 08, 2011 10:13 am
Location: Berlin
Callsign: LZ-STZ
Version: 2
OS: Mac OS X


Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 1 guest