Board index FlightGear Development Aircraft

A new nasal CDU (with "assembly" instr.) and new 787 update

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

A new nasal CDU (with "assembly" instr.) and new 787 update

Postby omega95 » Mon Jan 23, 2012 2:27 am

Alright, first of all, I've been developing a new cockpit and new systems (atm, finished hydraulics, heating, pneumatics and fuels systems < I mean it, you better start turning on equipment cooling if you don't want your hyd or fuel pumps to overheat and fault) and I just completed a new CDU for the aircraft. I'm not really that good with nasal but I used all I know to make it and it's really quite functional.

I'll have to take a break from FlightGear to study for finals (starting in a week! :shock: ) so I though I could leave the CDU to anyone interested in using it... As for the 787, I'll continue it later. (look at the bottom for a pic)

CDU

I'm just uploading the nasal file, so you'll have to make the model yourself. If you don't know how to display 3D text, take a look at some examples from the OSGText folder in the 747-400, or wait for the new 787

DOWNLOAD : http://www.mediafire.com/?0cn50qn7z1ueg3v

This CDU is really simple but also really functional, all the buttons on it take you somewhere / do something. You start up with the IDENT page which just shows you the aircraft, the engines and callsign. Then it has a button/menu to the INDEX.

Note that you have to change the aircraft and engines from the nasal file, search for 787 and RR Trent_1000 in the file and change them.

In the Index page, you have menu links to IDENT, RADIOS, DEP / ARR, ROUTE, TAKEOFF and APPROACH. (Just this for now, I'll update this when I add more)

RADIOS

This page shows all your radio frequencies. Typing the frequency on the keypad and pressing on where you want it to be (only Standby) replaces that value with what you just typed. To swap active and standby, press the active frequency.

DEP / ARR

You can type in your departure airport, runway, destination, runway and flight number here. There's a 'FLIGHT LOG' in the menu here and pressing it will take you to the flight log page. There's also a 'ROUTE' menu here which takes you to the route page and every page has an 'INDEX' menu so you can go back.

FLIGHT LOG

This would be especially good for VA pilots, you can track your fuel consumed and flight time here, and there's also a START / RESET menu to reset the log for a new flight.

Image

TAKE OFF and APPROACH

These pages aren't really complete, atm they just show some values I defined. I'll replace them with formulas to calculate the values by itself, but I'll have to make that computer in the EFB anyway, so I'll just write this script in the EFB and write it into a prop which the CDU calls.

ROUTE

So far, this is the like the most awesome thing in this CDU...

You can enter waypoints (add to the end by clicking on the EXEC/ENTER button on the keypad, insert waypoints by typing them and pressing on the waypoint you want to insert them above, REMOVE waypoints by pressing REMOVE and selecting the WP to remove, CLEAR the route, ACTIVATE the route and JUMP TO a certain waypoint by pressing JUMP TO (only visible when the route is active) and the wp to jump to...

The advantage of this route display over the old CDU's is the ability to display routes in multiple pages, not just the last waypoints. When you exceed 4 waypoints, a new route page is created and a next button appears. If you go to that page, a back button appears for you to come back too. This allows you to edit ALL the waypoints. :)

Oh, and there's also a marker to show the current waypoint, which you can change using the JUMP TO function.

Aaaand, you can also set VNAV altitudes for each waypoint by either entering the alt and pressing on the right side button (next to the wp) or adding the WP like eg. 'KSFO@3500'.

The 787 will feature a completely functional automatic VNAV to give this feature some company. :P

Image

> shows active waypoint

The current implementation of this is in a "software CDU", the 787's CDU that appears on the MFDs, so the keypad is touchscreen and so are the menu items, but you can easily implement this for a "hardware CDU" by asking the pick functions in the model as follows :
MENU (l1 to l7 and r1 to r7)
NUMPAD (cdu0 to cdu9, cdu. and cdu@)
ALPHAPAD (a to z, clr, del and exec)

Set these values to the '/controls/cdu/keypress' property.

And, I know this one doesn't have any meny buttons (above the keypad) but it's really easy to add them, model them and ask their pick animations to set the '/controls/cdu/display/page' prop to the pages defined in the nasal file.

Enjoy :D

P.S. An idea of what's coming up for the new 787 cockpit

Image

All models were created by me in ac3d and textures with GIMP and the amazing A/O baker in blender.

EDIT : Almost forgot this...

The following are the display props to be used with OSGText or whatever method you're using to create your CDU screen.

Page Name : /controls/cdu/display/page
Input Field : /controls/cdu/input

Menu Items
L1 LABEL : /controls/cdu/display/l1-label
L1 VALUE : /controls/cdu/display/l1
L2 LABEL : /controls/cdu/display/l2-label
L2 VALUE : /controls/cdu/display/l2
L3 LABEL : /controls/cdu/display/l3-label
L3 VALUE : /controls/cdu/display/l3
L4 LABEL : /controls/cdu/display/l4-label
L4 VALUE : /controls/cdu/display/l4
L5 LABEL : /controls/cdu/display/l5-label
L5 VALUE : /controls/cdu/display/l5
L6 LABEL : /controls/cdu/display/l6-label
L6 VALUE : /controls/cdu/display/l6
L7 LABEL : /controls/cdu/display/l7-label
L7 VALUE : /controls/cdu/display/l7
R1 LABEL : /controls/cdu/display/r1-label
R1 VALUE : /controls/cdu/display/r1
R2 LABEL : /controls/cdu/display/r2-label
R2 VALUE : /controls/cdu/display/r2
R3 LABEL : /controls/cdu/display/r3-label
R3 VALUE : /controls/cdu/display/r3
R4 LABEL : /controls/cdu/display/r4-label
R4 VALUE : /controls/cdu/display/r4
R5 LABEL : /controls/cdu/display/r5-label
R5 VALUE : /controls/cdu/display/r5
R6 LABEL : /controls/cdu/display/r6-label
R6 VALUE : /controls/cdu/display/r6
R7 LABEL : /controls/cdu/display/r7-label
R7 VALUE : /controls/cdu/display/r7
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: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby Hooray » Mon Jan 23, 2012 7:53 am

While this is great, we are unfortunately approaching a situation where we are having too many different CDU implementations - at the moment, there are least 4-5 different projects, that I am aware of:


All of them implemented in Nasal. What we really need is someone to examine all versions and see if/how they could be combined/unified and integrated, so that we end up with a single version that is well understood, can be well documented and well-maintained, usable by all aircraft developers.


http://www.mail-archive.com/flightgear- ... 32302.html
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: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby Johan G » Mon Jan 23, 2012 1:12 pm

Hooray wrote in Mon Jan 23, 2012 7:53 am:What we really need is someone to examine all versions and see if/how they could be combined/unified and integrated, so that we end up with a single version that is well understood, can be well documented and well-maintained, usable by all aircraft developers.

Keep in mind that there's differences, both in functionality, used terminology and appearance, between different aircraft producers and even aircraft models. That being said I do understand the importance of at least some kind of unification.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby Hooray » Mon Jan 23, 2012 1:39 pm

Yes, obviously ... I did keep that mind. But there's a fair share of common features required for pretty much any CDU/MCDU, especially these SHARED low level requirements are largely identical among these FMS front ends.

For example, this includes instantiating an addressable "screen region" and providing hooks to write alphanumeric text to it, as well as dealing with events, i.e. for key handling.

So, ideally, we could come up with a layered design where generic CDU components could be identified to allow people instantiating and parametrizing CDU-related components.
Nasal's OOP support is powerful enough to allow people to override such features easily.
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: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby omega95 » Mon Jan 23, 2012 3:11 pm

Note that I didn't release a whole CDU but the core only.

You'll have to design the body, screen text placements and stuff on your own. The same cdu has been used in 2 different forms so far - the 787's MFD-CDU and Hardware CDU. The MFD-CDU is larger and touchscreen while the other isn't.

And then, like what Johan said, CDUs are different for different aircraft. Skyop's CRJ CDU is made especially for that aircraft, the Generic Boeing one's fine for 747, 757, 767 and 777s but then there're some differences in the 787 one too.
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: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby Hooray » Tue Jan 24, 2012 6:36 pm

I perfectly understand ... still ;-) the differences we are talking about here are best addressed by parametrization during instantiation, rather than by duplicating redundant code.

Besides, given that you seem to be looking for people to adopt your new work, it might be a good idea to add your screen shots and your text to the upcoming newsletter here: http://wiki.flightgear.org/Next_newsletter

Let me know if you need help doing that.
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: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby scotth1 » Thu Jan 26, 2012 4:01 am

Actually in real-life there are only like 3 different FMS/FMC/CDU implementations;
* Thales
* Honeywell
* Smiths Industries (now GE Aviation)
and the same units from one manufacturer are often used in different aircraft (eg: A320, MD-11, 757 and 767 all use the same Honeywell FMS)
The majority of the database format is covered by an ARINC standard (can't remember it's number off the top of my head).

I think it is OK to have different initial implementations, I would suggest all the versions we have at the moment have different ways of implementing different functionality. We could say this is exploring the problem-space.

But we are getting closer to building up a set of requirements that could be built into a common set of instruments and functions... I have a few ideas in the back of my mind, when I get some spare time I might try to write them down..

I would say that there are two distinct streams;
1. the first is the physical representation of a keypad, screen etc, this is either the traditional LED grid screen, some specialised function keys and general letter/number keypad, the second type of physical representation is the newer LCD monitor type, such as used on 787 and A380 and a few others. This includes page flow, text management and key management.
2. The second stream is the back-end processes of the FMS, calculating flight plans, lateral/vertical guidance and interfacing with the route manager and autopilot.


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

Re: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby Johan G » Thu Jan 26, 2012 10:44 am

scotth1 wrote in Thu Jan 26, 2012 4:01 am:Actually in real-life there are only like 3 different FMS/FMC/CDU implementations;
* Thales
* Honeywell
* Smiths Industries (now GE Aviation)
and the same units from one manufacturer are often used in different aircraft (eg: A320, MD-11, 757 and 767 all use the same Honeywell FMS)

That's true only for the big airliners. For smaller aircraft (like biz-jets, turboprops and military trainers) one also has to consider other manufacturers like
* Barco
* Esterline
* Universal Avionics Systems

Apart from that I think I agree with you.

It seems that you, Hooray and omega95 are thinking of one "framework" of sorts for connecting a 3D model of the CDU to the property tree, and another framework for it's internal software, both with provisions for customising. That would be great! (I should take myself time to start tweaking aircraft.)

(Together with the property tree and the airport and navaid databases, the two "streams" you mention seems to be similar to the model-view-controller concept I have heard about.)
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby Hooray » Thu Jan 26, 2012 10:59 am

Well, even if you were to find 100 different manufacturers of CDUs, FMCs and FMS there'd still be a great deal of shared functionality and shared requirements, i.e. things that would be identical among ALL implementations, such as addressing a 2D screen region, rendering formatted text at certain coordinates, responding to key events, querying a navigational datatbase, making certain geospatial calculations.

So, yes, the idea is to come up with a list of these shared requirements and find the greatest common denominator for each component so that a set of layered frameworks can be created, to enable users to reuse code as much as possible, while still being able to customize and parametrize functionality as required.

Some things are currently not yet possible/feasible to do from scripting space (i.e. they require new scripting hooks) , but there are many things that are quite possible already and which should eventually be standardized, i.e. by coming up with a dedicated Nasal module that handles all details and which can be reused by aircraft developers easily.

If we had an active Nasal maintainer, we would probably already have such a module, but absent a Nasal maintainer, we need to come up with our own module by getting all people to communicate their requirements, so that the existing designs can be reviewed and improved eventually.
This is more complex work than coming up with some workaround from scratch, but it's more worthwhile in the long run.

In many aspects, FlightGear follows implicitly the MVC pattern already - simply because of the property tree, which already causes a separation of concerns to a certain degree.
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: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby Hooray » Thu Feb 02, 2012 5:07 pm

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

Awexomely Optimizing the nasal CDU

Postby awexome » Fri Mar 23, 2012 6:11 am

Hello --

just to give an update from my research complex.

Good news: the new approach being applied to optimize the CDU code appears to be working; based on very recent test of a few pages. In particular, the new data concepts being implemented, which is key to the new approach, is working well.

This development means that it becomes a lot easier to create CDU pages with little concern about the related processing. Because the previous method of forming and coding pages is still valid, tech- and non-tech users and devs now have a broader choice of how to push down information. One 'look-ahead' will be to make it even 'quicker' and easier for non-techs by providing a xml-based gui as an interface for designing (structure and data) cdu pages (that gui-styler and new AP dialog may have a wider use after all :).

The code blocks below illustrate the new simplicity and ease of making pages. Bear in mind that I remain in 'aggressive learning mode' and welcome relevant and criticism of the methods and approaches being used.

The fist block is an example of the new data structure for pages. It is simple, structured and works!. It gets better and simpler when there is very similar data; for example when resetting and clearing all inputs and display fields.

Code: Select all
IDENT1_Hash = {
   "l1-label" : "Model",       "r1-label" : "Engines",
   "l1" : "Boeing 787-8",       "r1" : "RR Trent_1000",
   "r2-label" : "Callsign",    "r2" : getprop("/sim/multiplay/callsign"),
   "l7" : "INDEX"
};

INDEX1_Hash = {
   "l1" : "",             "r1" : "",
   "l2" : "",             "r2" : "",
   "l3" : "NAVAIDS",       "r3" : "HOLD CONFIG",
   "l4" : "VNAV CONFIG",  "r4" : "EFB INPUT",
   "l5" : "FBW CONFIG",    "r5" : "RADIOS",
   "l6" : "DEP / ARR",     "r6" : "FLIGHTPLAN",
   "l7" : "T/O PERF",       "r7" : "APP PERF"
};


By taking out the data components from the flow control, it is now much easier to look at the control and decision processes; very important for adding new functions, making upgrade .. (and OMG ... debugging.. and more debugging little typos). This is illustrated in the next block showing the very visibly simple look (and feel) of the control processes for the IDENT and INDEX pages using the data illustrated above.

Code: Select all
##############################

if (page == "IDENT") {
   IDENT_Page(); # displays CDU items
   
#### Menu Presses
   if (keypress == "l7") {
      page = "INDEX";
      keypress = "";
   }
} # IDENT

##############################

elsif (page == "INDEX") {
   INDEX_Page(); # displays CDU items
   
#### Menu Presses
   foreach (var KY; keys(INDEX2_Hash)) {   
      if (keypress == KY) {
         page = INDEX2_Hash[KY];
         keypress = "";
      }
   }
} # INDEX


As the two examples show, the processes and control differ for varying pages, but implementaion is very flexible. In some pages with highly varying data sets and particular prcocesses for each data field, the control code was least modified -- pending next stage of optimizations.

There are likely various positive implications, including more efficient use of memory resources and processor cycles. There is much room for improvement on these issues, e.g. dynamic update timing, event-driven update, keypress listeners, etc.

While I am still working to quickly out a usable update, contributions of data (and where possible processing algorithms and code) related to new cdu pages are welcome. It will be nice to have and updated version with new pages and functionality.

Cheers to you all,
yours awexome-ly.
:)
When one thinks, one looks up to the skies.
I inspire, think, and seek the skies ------- mijiny <aka awexome[2138]>
awexome
 
Posts: 111
Joined: Sat Jan 21, 2012 12:24 pm
Location: GMT
Callsign: SHA7
Version: GIT
OS: GNU

Re: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby Hooray » Fri Mar 23, 2012 8:35 pm

That looks useful, it's good seeing someone working on this, so your work is definitely appreciated!

Code: Select all
elsif (page == "INDEX") {
   INDEX_Page(); #


You can directly use a hash lookup by linking page name and callback:

Code: Select all
 var pages = {INDEX:Index_Page, Foo:Foo_Page };


Next, you could use a hash lookup to call the correct callback automatically:

Code: Select all
 var pages = {INDEX:Index_Page, Foo:Foo_Page };
 var page ="INDEX";

 var activate_page = func(page) {
  if (contains(pages,page)) pages[page]();
  else print("Error no matching page found for:", page);
 }
 
 activate_page(page);


You can probably remove some more redundant stuff by using a real state machine instead of all the nested conditional blocks.
Also, the hashes that you have come up with are strictly declarative now - so they could just well be moved to XML space (using the helpers in io.nas: read_properties() and write_properties) - that would allow people to define new CDU pages using XML, and even add embedded XML code, too.

You might want to consider using gitorious or codepad so that we can take a look at your code.

Thanks again for working on this!
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: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby awexome » Wed Mar 28, 2012 5:53 am

Hello AviaTux,

here is a quick progress report. The work on the 787-8 cdu code has led to more than 25+ percent reduction in code lines. This has positive implications for future maintenance, code analysis and development. Awesome :)
More topping! More pages have been added to the evolved cdu. The functionality and response tests continues.

Thank you for your support.

awexome.
When one thinks, one looks up to the skies.
I inspire, think, and seek the skies ------- mijiny <aka awexome[2138]>
awexome
 
Posts: 111
Joined: Sat Jan 21, 2012 12:24 pm
Location: GMT
Callsign: SHA7
Version: GIT
OS: GNU

Re: A new nasal CDU (with "assembly" instr.) and new 787 upd

Postby awexome » Fri Apr 06, 2012 3:30 pm

Hi all,

Could someone commit the upgraded cdu to the main git repo. I am still having problems with my gitorious install.


awexome
When one thinks, one looks up to the skies.
I inspire, think, and seek the skies ------- mijiny <aka awexome[2138]>
awexome
 
Posts: 111
Joined: Sat Jan 21, 2012 12:24 pm
Location: GMT
Callsign: SHA7
Version: GIT
OS: GNU


Return to Aircraft

Who is online

Users browsing this forum: No registered users and 11 guests