Board index FlightGear Development Aircraft

FMC

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

FMC

Postby PilotDjim » Wed Feb 24, 2016 6:26 pm

Hello Fellow Pilots!

I am here today proposing this one question which would change our virtual piloting careers and experiences; developing FMCs in Flightgear. Making them more realistic so they work and overall improving enjoyment. Who is up for developing FMCs for the best planes out there: The 748, 777 (Not a bad FMC), A330, A340 and so on...?

KOL/G-XKOL/172/Djim/Jim
Chances Are, I'm Eating Cheese In A 747.
Heathrow Spotter.
Find Me On Mumble And The Community - KOL24M/G-XKOL/LAX24M
Head Of Marketing/Pilot/Route Management At LucasAir.
Visit LucasAir:http://lucasair.tk/
User avatar
PilotDjim
 
Posts: 49
Joined: Fri Jan 01, 2016 3:19 pm
Location: EGLL - West London
Callsign: J-IMMY
Version: 2016.1.1
OS: Windows 7 Ultimate

Re: FMC

Postby Hooray » Wed Feb 24, 2016 8:13 pm

The real issue here is at least two-fold: re-creating all visual aspects of the corresponding front-end (e.g. CDU/MCDU) - for that, Nasal scripting and Canvas can help:

http://wiki.flightgear.org/Nasal
http://wiki.flightgear.org/Canvas

Richard has created MFD framework for his f15, it's internally using Nasal and Canvas - and imagery/symbols are usually created by Inkscape vector images (SVGs).

The Canvas system itself also supports raster images, so that it is possible to create arbitrarily complex avionics.

The real challenge is the degree of systems modeling needed - most aircraft, and in fact, most FDMs, do not provide the kind of data to make a functional FMS/FMC - thinking in terms of VNAV: http://wiki.flightgear.org/Implementing ... FlightGear

So, developing a full FMC/FMS will require very different knowledge, data, experience and skills - i.e. the VNAV part has much to do with FDMs, flight envelopes than the M/CDU part, which is more about simulating the front-end.

For that, reusing Richard's MFD framework would make sense - ideally, by coming up with a M/CDU framework on top of that, by inheriting a child class and adding pages/modes as needed.

For the VNAV part, there is quite of data and features missing still.

On the other hand, you only need to look at efforts like the spaceshuttle to see that dedicated people can make tons of progress in a really short timeframe.
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: FMC

Postby legoboyvdlp » Wed Feb 24, 2016 8:14 pm

Since the A330 FMC is 95%, and artix is working on it, PLEASE DO NOT TOUCH IT

Sincerely,
Jonathan
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: FMC

Postby Hooray » Wed Feb 24, 2016 8:17 pm

Like I said, people should be really prepared to differentiate between the FMS (flight management computer), and the FMS (flight management system) and the CDU/MCDU (control display unit).

You can definitely work on the FMC and the CDU (front-end) at the same time - I just think that people are mixing up the terms here.
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: FMC

Postby alge » Wed Feb 24, 2016 9:39 pm

differentiate between the FMS (flight management computer), and the FMS (flight management system)


Neat typo. ^_^

On a serious note, I wish we could share more of our development on these things. Having lots of logic for route management and performance data and autopilot stuff re-implemented in every new "realistic" plane kinda sucks. It would be nice if we could build up the built-in system that covers 90% of the cases and any specialization can be handled by refining the built-in system. Adding a new aircraft should be throw up a couple of displays and live with the built-in default ND and MFD in the first iteration, and then progressively refine it to match the real deal.
alge
 
Posts: 77
Joined: Thu Aug 30, 2012 1:45 am

Re: FMC

Postby Hooray » Wed Feb 24, 2016 9:52 pm

I agree completely - but for that, people need to stop working on aircraft specific stuff that only resides in their own aircraft folders - they really need to start thinking in terms of frameworks with common functionality - it is definitely possible, the ND framework started out as something highly specific to the 747 and supporting only single instance - meanwhile, it got slightly extended to also support multiple instances and other aircraft/styles.

However, that kind of work is tedious and boring - and unnecessary if people started to think in terms of building blocks and frameworks before writing any code.

For example, the underlying "low-level" building blocks would obviously be Nasal and Canvas, but 90% of these displays could simply use a MFD framework, and a CDU/MCD, PFD or ND could thus be inherited from such a MFD framework.

Most of the existing ND stuff would need to be rewritten to support this this kind of setup, but it's relatively straightforward in comparison to most other Canvas-based MFDs we are seeing these days.

The current practice of only coming up highly aircraft specific instruments/avionics, simply means that people don't collaborate beyond their "own" aircraft/use case. However, that does not necessarily need to be/remain the case.

There are several possibilities to make that happen - either by introducing layered systems in scripting space, or by extending the underlying C++ code to introduce these concepts in the form of encapsulated Canvas elements that can be extended/customized in scripting space.

Personally, I have to the conclusion, that this is the only way forward to allow aircraft developers to develop such instruments without having to be proficient in object-oriented programming, which is why I think that support for custom elements needs to be added, so that people can create their own Canvas "elements" in the form of a "mfd", "cdu", "pfd" or "nd" - with inheritance taking place at the property-level (analogous to how effects support inheritance) - and in fact, TheTom already implemented Canvas-styling using property inheritance: http://wiki.flightgear.org/Canvas_Devel ... FlightGear


Absent that, there will continue to be awesome aircraft with great avionics, like the Avidyne Entegra R9, that will not be useful outside the original aircraft: http://wiki.flightgear.org/Avidyne_Entegra_R9

Subject: extra500 - Avidyne Entegra 9 IFD - approach
D-Leon wrote:NOTE: This sounds like a reusable framework but the encapsulation isn't as far and its optimised for the internal need.
There are some calls going over parents where no interface is "rechable" or defined.



PS: Sorry about the typo :D
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: FMC

Postby CaptB » Thu Feb 25, 2016 11:55 am

It all makes sense. It would be helpful if someone would bootstrap such a framework. Having something there may create enough intertia to have people join the effort, otherwise there's simply no such project and I suppose some aircraft developers would rather do something of their own, at their own pace instead of waiting for such framework to maybe materialise one of these days.
Ongoing projects(3D modelling): A320, MD-11, A350, B767
FG767: https://fg767.wordpress.com/
CaptB
 
Posts: 685
Joined: Thu May 23, 2013 7:36 pm
Callsign: EKCH_AP
IRC name: CaptB
Version: next
OS: Xubuntu

Re: FMC

Postby Thorsten » Thu Feb 25, 2016 2:50 pm

and unnecessary if people started to think in terms of building blocks and frameworks before writing any code.


That's not very likely in the (quite normal) use case that someone simultaneously has to learn how the avionics in question works and how canvas works. :-)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: FMC

Postby Richard » Thu Feb 25, 2016 4:43 pm

Thorsten wrote in Thu Feb 25, 2016 2:50 pm:
and unnecessary if people started to think in terms of building blocks and frameworks before writing any code.


That's not very likely in the (quite normal) use case that someone simultaneously has to learn how the avionics in question works and how canvas works


My experience is that lots of projects fail because they take the thinking of building blocks and frameworks before writing any code. The challenge with writing any avionics is generally understanding what the avionics does and how to code it. Something like an FMC is fiendishly complex, often comes with different customer configurations, differs between aircraft variants as well as types.

If I were writing an FMC I'd probably look at all of the ones already coded; discuss with the author and come up with a plan for making it work for more than one aircraft.

Common code and building blocks is almost the Holy Grail of software development.

The way it's done on the Shuttle is much more like real life; as the displays are just displays generally interfacing to systems that do the work. This is a much better approach than coding the display logic and the rest of the logic in the same place. It's also quite similar to how it is in the Shuttle, and one of my rules is to model the real world as it is as that removes a layer of adaptation.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: FMC

Postby Hooray » Thu Feb 25, 2016 4:53 pm

Thorsten (was writing this while Richard responded), I agree - but it seems to have more to do with someone's programming background, i.e. not just "coding", but "software engineering" in the sense of coming up with reusable designs and components - Nasal is just the language, and once you know how to structure code using functions, vectors, hashes and higher level data structures, you can definitely use that without having to be an expert in Canvas or avionics - basically you need to look at your own code and determine if a feature is specific to the instrument, to the kind of avionics (MFD) or if it is aircraft specific - at that point, experienced programmers can tell where to put the code, and how to parameterize it so that it can be reused elsewhere.

Next, one would look at repeated patterns (think for animation handling) and encapsulate such details.

I think it is kinda what the extra500 guys have been doing, but they stopped once their work worked for multiple instances of the MFD on their aircraft - as we can seen in Richard's f15 code, it is definitely possible to go one step further, i.e. come up with a framework that is agnostic to the type of avionics, and even aircraft.

Higher level frameworks would then be built on top of such a MFD framework, whereas common functionality would be moved to the MFD framework itself (think animation logic/heuristics).

This kind of design and partioning makes it possible to easily update all child classes of a MFD, so that native Canvas features are automatically used by those, without having to be manually updated.

But for that, you need to understand not only data structures and algorithms, but also how to create components without adding implicit dependencies, i.e. decoupled modules.

Having a background in design patterns and object-oriented programming sure helps, even without people having to use any of this knowledge - but it helps with the thinking required.

Just look at our discussions on using "hashes" (in the C struct sense) in the AW code, and named parameters in function calls - it took a while to bring the point across, but you ultimately agreed that it would help with the coding. Equally, I probably attempted to demonstrate the benefits of "classes" in non-performance critical AW code a dozen times, but you really only began using, and writing, object oriented code when you were exposed to the concept of inheritance via Tim's effects framework, i.e. property-level inheritance.

Ultimately, you are now in a much better position to judge if/when and where/how certain programming styles may be helpful, and you can reuse those ideas even without having to actually do OOP.

Assuming that Richard's exposure to Nasal and Canvas also started with the f15, I think it is pretty clear that it is more about having a fairly solid general background (and experience) in software engineering than familiarity with Nasal/Canvas per se.

Looking back at how we "refactored" the ND code, it's actually not using any fancy design patterns or classes, it's just dealing with a bunch of symbols that are animated using timers and listeners.

A reusable MFD framework would ideally come up with building blocks in the form of:
    - MFDDevice
    - MFDScreen
    - MFDPage
    - MFDPageMode
    - MFDPageElement
    - MFDPageElementUpdateHandler
    - MFDPageElementAnimation

And it would be continuously reviewed/augmented based on coming up with child-frameworks for different purposes (CDU, ND, PFD, EFB), so that common functionality would "move up" within the chain of frameworks, whereas device specific stuff would reside in the corresponding child class.

Equally, that is how different aircraft developers would conduct their development, by looking at features they need and determining upfront if those are specific to the instrument or the aircraft - or shared between different kind of MFDs, and then add this at the corresponding layer.

So it's not rocket science, it's just a different way of thinking and more tedious, because you cannot just add new features anywhere, but need to find the appropriate place first.

http://wiki.flightgear.org/Canvas_MFD_Framework

But anything dealing with "animating" Canvas elements, would best be encapsulated, so that it can easily use C++ hooks later on: http://wiki.flightgear.org/Canvas_Animation_Framework

Looking at the previous posting, this sums up the whole motivation pretty well, i.e. behind having "frameworks": http://wiki.flightgear.org/Howto:Coding ... _Framework


We did once try to come up with a CDU framework: http://wiki.flightgear.org/A_standard_C ... FlightGear

None of this may seem relevant at first, but it may become obvious once people try to use their avionics in conjunction with multiplayer (think dual-pilot/multi-crew, and/or multi-instance setups (FSWeekend, LinuxTag) with several screens/computers inter-linked - at that point, you need to have frameworks with interfacing boundaries in place, so that only relevant state needs to be propagated, replicated/synchronized.

And this are not the only features that would show restrictions in any non-framework centric approach, e.g. look at the replay system (flight recorder) and/or the tutorials system - as long as there are clear interfacing boundaries in place, it would even be possible to instantiate a MFD, add it to a GUI dialog and use that for training/familiarization purposes (think tutorials).

Which is how this was possible (these are independent instances, i.e. not linked to the actual main aircraft, but can be hooked up to arbitrary properties, including AI aircraft):
Image
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: FMC

Postby Thorsten » Thu Feb 25, 2016 7:05 pm

as we can seen in Richard's f15 code, it is definitely possible to go one step further, i.e. come up with a framework that is agnostic to the type of avionics, and even aircraft.


... and as you probably can't see but I can see all too clearly, it's only in hindsight that one discovers how one should have really factored it.

The thing with the Shuttle is that you can't really factorize in terms of 'pages' for instance, because from the point of view of the edgekey navigation system that's shared with the F-15, all the 21 DPS pages are just one single page - the DPS submenu. Whereas the whole DPS selection logic is its own beast, grafted onto the edgekey structure.

Aka, the usual state of affairs is that you think before what a good assembly of building bocks is, then you code, and then you see that it doesn't fit. It's only after you've done it that you have the information how it should be re-factored, and it's only after you've done a second aircraft with the same structure that you have a picture of shared commons (or not).

It's all too often that building something from common blocks runs into dead ends which you can't extend, so you discover you would have been better off with a custom job.

Case in point - there have been some attempts at generalized electrical systems for aircraft, and I'd consider pretty much all of them I have seen completely inadequate for what I wanted to achieve.

It's not that we wouldn't see the benefit of factorizable code (at least I do), but it's often that the cost-benefit analysis doesn't go through.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: FMC

Postby Octal450 » Fri Feb 26, 2016 2:29 am

Well, the only good FMC in FlightGear is the one in artix's A330. The rest are very simple, and have no functional point yet.
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: FMC

Postby Thorsten » Fri Feb 26, 2016 7:12 am

Well, the only good FMC in FlightGear is the one in artix's A330.


I do beg to differ.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: FMC

Postby Hooray » Fri Feb 26, 2016 12:22 pm

Actually, while the shuttle may easily have one of the most completely modeled flight management systems, it is pre-80s and not an airliner - as such, there really isn't that much that it would have in common with the kind of CDUs commonly seen on airliners these days.

Equally, that is the reason why an airliner-centric MFD framework would not be too useful for modeling such spaceshuttle avionics - however, the spaceshuttle MFD code could definitely help establish such a MFD framework, i.e. one that could be used by airliners, and possibly other spacecraft.

But that requires a continuous review of code added, i.e. in terms of how repetitive certain code blocks are and where they should be added (thinking in terms of layers).

Like both of you said, we cannot expect people to code frameworks from scratch without an actual use-case, but we can definitely encourage a layered design where common functionality would be moved out into building blocks that end up becoming reusable modules.

Like Richard said, the main thing to make that happen is having multiple use-cases -ideally, very different ones, and then refactor/unify the code accordingly, so that similar functionality (think animations, instrument modes, pages, page items, state machine handling) would be "extracted" and turned into components.

And ideally, such components would not be specific to the MFD framework - but could be also used without it.

But for that kind of programming, you need to have the corresponding background and experience (the language really doesn't matter all that much), and you need to understand data structures, algorithms and the limitations of those.


Richard does have some ideas related to creating reusable Nasal components without introducing major dependencies/design assumptions, so it will be interesting if any of this should materialize.

But it really is a completely different way of thinking, i.e. where you are treating things in a MPI fashion than OOP necessarily
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: FMC

Postby Thorsten » Fri Feb 26, 2016 1:03 pm

Actually, while the shuttle may easily have one of the most completely modeled flight management systems, it is pre-80s and not an airliner - as such, there really isn't that much that it would have in common with the kind of CDUs commonly seen on airliners these days.


...except all that's underneath the CRT displays, because neither systems management nor GNC tasks have changed much since then. And except the basic fact that it's based on bringing things on screens.

I mean, you're contradicting yourself now. You were the one looking for common elements. But okay, this whole debate is rapidly getting unproductive, so I'm off to writing some docking code.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Next

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 15 guests