Board index FlightGear Development Documentation

FlightGear high-level components

Discussion of the FlightGear documentation, how it can be improved and coordination of people working on it.

FlightGear high-level components

Postby eusebiu » Mon Dec 23, 2013 10:49 am

Hello,
I've created a high level components block diagram and I wanted to know if I am missing something...
https://skydrive.live.com/?cid=a7ab3515 ... MxsFobKW7U
Thanks!
Eusebiu
eusebiu
 
Posts: 15
Joined: Tue May 18, 2010 6:43 am

Re: FlightGear high-level components

Postby islandmonkey » Mon Dec 23, 2013 10:59 am

Some things -
  • We currently use the PUI (PLIB) for the GUI system which in turn uses GLUT. As far I'm concerned we don't use pure GLUT.
  • The FlightGear backend - if you wish to put it that way, is called SimGear, not SimEngine.
  • I would argue that FGData depends on FG, rather than the other way around. I dunno, someone may say otherwise.
User avatar
islandmonkey
 
Posts: 786
Joined: Mon Jan 30, 2012 9:51 pm
Location: EGCN (uni), EGHI (home)
Callsign: G-MNKY
OS: Ubuntu 20.04

Re: FlightGear high-level components

Postby eusebiu » Mon Dec 23, 2013 11:20 am

Hello,

Thanks for the quick answer!

So, you think it is better this way? https://skydrive.live.com/?cid=A7AB3515 ... 212048&v=3

Thanks!
eusebiu
 
Posts: 15
Joined: Tue May 18, 2010 6:43 am

Re: FlightGear high-level components

Postby Hooray » Mon Dec 23, 2013 12:08 pm

this looks really good, and I think we really need this sort of documentation - preferably as a vector image that we can upload to the wiki or even commit to the repo.
there are some inaccuracies, and I have some ideas for improvements - but overall, it's really a good start.
For example, I would connect different components and layers using arrows, to explain their purpose, such as "Sound", "flight dynamics", "graphics".
Also, I would differentiate between runtime/data dependencies like fgdata and built-in library/build-time dependencies.
I also wouldn't necessarily add other tools next to fgfs - most of them don't directly depend on FG dependencies.
My suggestion would be to rework things a bit and come up with multiple SVGs that we can turn into a slide show (or PDF) - that way, we can visualize things step-by-step, while also encouraging other people to get involved maintaining this in the future.
If we could pull that off, it could be really useful for getting people up to scratch with FG from a conceptual point of view.
At some point, I would also want to see important components covered, like the property tree for example.

PS: FlightGear definitely depends on FGData, FGData in turn does not depend on FlightGear - but obviously they're both really only useful in combination, but FGData without FG can be used by other programs to some extent, while FG without FGData is basically useless.
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: FlightGear high-level components

Postby eusebiu » Mon Dec 23, 2013 1:41 pm

Hello,

I have created this diagram using Visio and I guess I will have to port it to some other format/tool - if you say SVGs, then maybe we can use Inkscape (which is free).
This diagram (as it's name states) should contain only the high-level components, and if there are no other major components, we can leave it as it is.

Now, for the fgfs component a diagram has to be created but unfortunately I am not that experienced in FlightGear to start creating it. Therefore, I would need someone's help to describe the relations between the different entities within fgfs (AI, FDM, Autopilot, GUI, etc.). Without this help, it will take me a little more time to read the code and create the fgfs component diagram.

Thanks!
eusebiu
 
Posts: 15
Joined: Tue May 18, 2010 6:43 am

Re: FlightGear high-level components

Postby Hooray » Mon Dec 23, 2013 4:55 pm

"component" is a pretty generic term - some of the things in the diagram could be said to be "components", such as FDMs like JSBSim or YASim - others are dependencies, i.e. libraries needed to built FlightGear, but not necessarily relevant to end users - this applies to things like plib, OpenAL, OSG etc - these are basically lower level layers of a "pyramid", with FlightGear being at the very top of it.

So it really all boils down to your goals here, and your target audience - identifying "components" means that you need to determine first some sort of classification scheme. Your "OS Layer" would be at the bottom of the pyramid - and libraries like OSG, OpenAL etc would be somewhere in the middle - with SG/FG being at the top.
You could also say that boost is a part of the "framework" layer - because it's used by SimGear and FlightGear.

Otherwise, there are too many concepts mixed here.
Overall, I suggest to split the whole thing up and turn it into a multi-page slide show, that way you can introduce things one by one.
Inkscape sounds like a good choice to me.

Now, for the fgfs component a diagram has to be created but unfortunately I am not that experienced in FlightGear to start creating it. Therefore, I would need someone's help to describe the relations between the different entities within fgfs (AI, FDM, Autopilot, GUI, etc.). Without this help, it will take me a little more time to read the code and create the fgfs component diagram.

don't worry about that, we can provide more pointers, help and support than you can handle :lol:
So the main things would be:

  • FligthGear entry point (main) in bootstrap.cxx http://wiki.flightgear.org/FlightGear-P ... f_Interest
  • FlightGear initialization (command line processing, options, translations)
  • FlightGear main loop
  • FlightGear subsystems (AI, AP, FDM, Nasal, GUI etc) see fg_init.cxx
  • pseudo subsystems (code not yet using SGSubsystem)
  • reset/re-init
  • termination/shutdown
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: FlightGear high-level components

Postby eusebiu » Mon Dec 23, 2013 8:26 pm

Hello Hooray,

I understand your point of splitting the diagram but I think FlightGear needs a "big picture" also and this means mixing concepts - this big picture can be read by end-users and by developers also.
I like your idea of FG Depencencies and FG Components and I've created a color code for each of them - https://skydrive.live.com/?cid=A7AB3515 ... 212050&v=3 (one can find the SVG file in the same folder).

Now, if someone is interested in the design of a specific component then (s)he can dig deeper to the next level.
For an end-user/developer which is interested in the flight part then (s)he will have to get into the fgfs and it's subsystems.
For an end-user/developer which is interested in the gear (simulation/graphics/sound) part then (s)he will have to get into the SimGear/plib/OSG diagrams.

Honestly, right now I am more interested in the flight part and that's why I will continue to explore this area and create the (functional) diagram for fgfs (JSBSim has a class diagram in it's manual).

Thanks!
eusebiu
 
Posts: 15
Joined: Tue May 18, 2010 6:43 am

Re: FlightGear high-level components

Postby Hooray » Mon Dec 23, 2013 11:52 pm

you can use doxygen to get up to date class information, see: http://jsbsim.sourceforge.net/JSBSim/inherits.html
I still think that you may need to come up with a scheme to classify "components", not just color-codes - because things are conceptually different.
For example, a "component" isn't necessarily a dependency or a subsystem (and vice versa).
so there's some clearly overlapping areas here - i.e. if you were to remove those FDM components, it would be basically all about software architecture, i.e. libraries/dependencies.
To be honest, FDMs in general are not anything special in FG, they're also just subsystems - like the AP, AI traffic, Nasal etc.
So maybe you choice is colored by your own interests currently ?

If you are into FDM development, JSBSim is a great choice, there's plenty of good docs and a very active developer community.

EDIT: Also see: viewtopic.php?f=45&t=21164#p192569
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: FlightGear high-level components

Postby Hooray » Sat Mar 08, 2014 4:21 pm

I was going to post your diagrams in another thread, but they no longer seem to be available ?
Could you upload these diagrams to the wiki ?
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: FlightGear high-level components

Postby eusebiu » Sat Mar 08, 2014 5:34 pm

It seems Skydrive is now OneDrive...
Link is https://onedrive.live.com/embed?cid=A7A ... YldFIeBVGI
eusebiu
 
Posts: 15
Joined: Tue May 18, 2010 6:43 am

Re: FlightGear high-level components

Postby Hooray » Sat Mar 08, 2014 5:58 pm

Okay, thanks for posting a working link. When/if you are going to update this, here are few suggestions:

  • FDMs will actually USE SimGear normally, so they're not on the same level
  • thus, I would introduce a "Subsystem" layer on top of SimGear
  • FDMs should be part of this subsystem layer (JSBSim, YaSim, property tree (and listeners), events, instrumentation, Autopilot, Input (Joysticks), I/O (networking) etc
  • some subsystems are "FDM coupled", i.e. run at higher rates than others, it would make sense to highlight this, i.e. using a different color and some comments: viewtopic.php?f=49&t=22341&p=202876#p202876
  • FDM coupled systems are: fdm/flight, instrumentation, systems, autopilot, xml-proprules
  • FGData: add Aircraft/Scenery/Sounds/Scripts
  • BTW: it's OpenGL (not "Open GL")

I would not necessarily add "FlightGear Tools" to the diagram, most tools do not really use the established FG architecture, but rather use copy&paste to duplicate code, so there's not such an explicit separation in place here

If you are interested in working on a few more diagrams, I can provide all the info necessary to describe the FG initialization process, and/or other important subsystems like for example Nasal (scripting) - also it would probably make sense to separately document the way FDMs are integrated, as per: viewtopic.php?f=49&t=22341&p=202876#p202876

It would be great if you could upload your diagram to the wiki and add it here: http://wiki.flightgear.org/index.php?ti ... &section=7
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


Return to Documentation

Who is online

Users browsing this forum: No registered users and 3 guests