[Flightgear-devel] New Architecture for Flightgear
Hi, Some discussions have already taken place on JSBsim devel mailing list regards communication between modules of flightgear. My thoughts are that flightgear divides naturally into four major sub-system modules: a) FDM (jsbsim is already standalone) b) cockpit input and output (ie joysticks/pedals/throttles/switches etc and displays/lights etc) c) external view (with all the graphics rendering for forward/back/sides etc) d) motion system (probably not many users!) The main issue is inter-processor communication between modules ie between modules multi-threaded on multi-processor computers,between modules in processes on same computer,between modules in processes on networked computers. I have been looking at the idea of using some database containing the property lists which would be read and updated asynchronously by the various modules at whatever frame rate is suitable for the module (not necessarily its internal framerate) My first thought was LDAP, although using a directory service as a database is often frowned upon! I am familiar with OpenLDAP and it looks like an LDAP schema can be derived fairly easily from the property list or better still from the XML schema (maybe programs exist to do this already?). There may be problems with data rates etc so maybe it will need MySQL or somesuch but that seems an overkill for the functionality needed. The advantages of the database are that proprietry (ie FG/jsbsim) protocols are not needed as standards already exist and multi-process (many to one and one to many) synchronisation etc is already built in to the database API. Also there are the search facilities and other directory and database functions that can be made use of. Also I have had a look at native XML databases and although it is nice to be able to write/read and search directly in XML, if they are based on JAVA (such as Opensource Xindice), they are pitifully slow compared with what is required (there is some interesting work published on the Web comparing native XML data base with MySQL with all its problems of representing the XML data). We can experiment on various communication ideas without restructuring flightgear by simply running three instance (forget motion system for now!). One instance running FDM with no panel display and no outside view, second instance running no FDM or view and only panel, and third instance running no FDM or panel and only outside view. An advantage of this modularisation and inter-process communication is that as flightgear is multi-platform we can select the optimum platform for each module even utilising RTOS where needed or maybe specialist graphics engines. If anyone has any comments and other ideas etc I would be very interested. cheers Jim - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Hi Jim, Jim Campbell wrote: Some discussions have already taken place on JSBsim devel mailing list regards communication between modules of flightgear. Indeed, the idea of cutting FlightGear into modules is not a new one and has been floating around way before this nice new arcitecture paper came up that everybody takes as a reference. Using some sort of networked database is a nice start and definitely honours the idea of portability - yet I don't see such thing that is capable of handling data at a rate that meets the requirements of FlightGear. OpenLDAP as well as MySQL are very bad at handling a high rate of concurrent read/write requests - they miss the target by a huge distance, they both are faaar to complex (even MySQL :-) for such a task. Personally I think some thing like distributed shared memory might fill the gap. I've been doing some literature research on this topic several years ago, the idea looks pretty promising and different OpenSource implementations already have been around by that time - but I would not like to be the one to debug such a tricky beast :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Martin Spott wrote: Hi Jim, Jim Campbell wrote: Some discussions have already taken place on JSBsim devel mailing list regards communication between modules of flightgear. Indeed, the idea of cutting FlightGear into modules is not a new one and has been floating around way before this nice new arcitecture paper came up that everybody takes as a reference. Using some sort of networked database is a nice start and definitely honours the idea of portability - yet I don't see such thing that is capable of handling data at a rate that meets the requirements of FlightGear. OpenLDAP as well as MySQL are very bad at handling a high rate of concurrent read/write requests - they miss the target by a huge distance, they both are faaar to complex (even MySQL :-) for such a task. Personally I think some thing like distributed shared memory might fill the gap. I've been doing some literature research on this topic several years ago, the idea looks pretty promising and different OpenSource implementations already have been around by that time - but I would not like to be the one to debug such a tricky beast :-) Cheers, Martin. One should not forget that FG has allready some networking capacity. This alone has allready allowed ppl to split fdm and rendering on several machines. Perhaps there is something to reuse here. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Harald JOHNSEN schreef: Martin Spott wrote: Hi Jim, Jim Campbell wrote: Some discussions have already taken place on JSBsim devel mailing list regards communication between modules of flightgear. Indeed, the idea of cutting FlightGear into modules is not a new one and has been floating around way before this nice new arcitecture paper came up that everybody takes as a reference. Using some sort of networked database is a nice start and definitely honours the idea of portability - yet I don't see such thing that is capable of handling data at a rate that meets the requirements of FlightGear. OpenLDAP as well as MySQL are very bad at handling a high rate of concurrent read/write requests - they miss the target by a huge distance, they both are faaar to complex (even MySQL :-) for such a task. Personally I think some thing like distributed shared memory might fill the gap. I've been doing some literature research on this topic several years ago, the idea looks pretty promising and different OpenSource implementations already have been around by that time - but I would not like to be the one to debug such a tricky beast :-) Cheers, Martin. One should not forget that FG has allready some networking capacity. This alone has allready allowed ppl to split fdm and rendering on several machines. Perhaps there is something to reuse here. Harald. Real-world flight simulation systems, as used in flight training devices, have been using this tactic for decades. A flight simulator as supplied by a commercial producer of training devices, has been split into a set of large functional blocks, each of them consisting of different modules: * Flight dynamics block -- consists of a set of systems that handle everything related to the aircraft's aerodynamic profile and the forces acting upon it. It does know nothing about scenery (aside from terrain elevation data, to detect ground movement), and knows nothing about the aircraft's systems. The only thing it knows about the aircraft is basically a 3D model with aerodynamic description, the position of the A/C's control surfaces and other extensions (landing gear, doors, spoilers), and the user-induced forces on the aircraft (engine thrust). It does a very good job at handling flight dynamics, and is fitted with a heavy CPU. Mathematical power is more important here than memory. * Systems block -- keeps track of everything happening inside the aircraft. From the engines to the air conditioning, everything that can't be connected as real avionics is simulated inside this unit. Most of the aircraft-specific descriptions are found here. * Visual system -- The visual system only needs to receive position and orientation data, and possibly the first and second derivative of it. From that it renders the (usually multichannel) outside view for projection onto the simulator's front screen. All of the scenery data is stored here. These three functional big blocks communicate over a high-speed network. Mostly, the units are built in dual-redundant sets to cope with eventual failure. Most of the cockpit systems in a real simulator consist of real avionics. ARINC buses connect the real aircraft avionics (like the FMC, RMU's, and most of the display systems) to the simulator as if they connected to an actual aircraft. The simulator's systems block takes the place of the aircraft's IRS, GNS, ADC, VOR and other navigation systems. Splitting up FlightGear into multiple functional units is something I'm really voting for. Especially, when you use a well-defined interface for every module. That way you can create a plugin-driven system that is easily extended upon, and could easily be split up physically using multiple machines across a network. I'm more into developing glass cockpits myself, but I'm also interested in creating a complete full-mission flight simulation suite. Especially since that would attract commercial funders (aviation industry companies like CAE, FlightSafety and Boeing) and possibly achieve FAA certification. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Harald JOHNSEN wrote: One should not forget that FG has allready some networking capacity. This alone has allready allowed ppl to split fdm and rendering on several machines. Perhaps there is something to reuse here. Well, we've been driving two 'external' displays on last years LinuxTag exhibition using the 'generic' protocol. We were surprised to encounter a significant performance hit on the master machine serving two clients at 20 Hz. Throttling the thing down to 10 Hz made the whole setup flyable again. Yet this might look different if such master does nothing but FDM output via network, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Martin Spott schreef: Well, we've been driving two 'external' displays on last years LinuxTag exhibition using the 'generic' protocol. We were surprised to encounter a significant performance hit on the master machine serving two clients at 20 Hz. Throttling the thing down to 10 Hz made the whole setup flyable again. Yet this might look different if such master does nothing but FDM output via network, Martin. Keep in mind that the Generic protocol is one of the most inefficient for real-time data communication, as it communicates via plain text. If you want something that goes over 100Hz, you need to think of a binary system. For an FDM connecting to a visual system it's basically nothing more than 18 floating point values (x,y,z, rotation xyz and first and second order derivatives for smoothing) resulting in a 72-byte data packet, which is doable. To put it into perspective, the same 18 values would take up at least 200 bytes (characters), not counting newlines and frame separators, as each floating point would need at least 10 characters to be represented at least a bit accurately, and still you have to cope with international issues (comma vs. decimal point) when you're using the generic protocol. Plus a terrible loss in resolution as the max. resolution for a plain text channel can be at most to the 10th decimal place (at least, in standard format) where a double floating point can carry much more accurate data. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin Spott wrote: Personally I think some thing like distributed shared memory might fill the gap. I've been doing some literature research on this topic several years ago, the idea looks pretty promising and different OpenSource implementations already have been around by that time - but I would not like to be the one to debug such a tricky beast :-) A pretty easy and fast implementation could be based on one of the new single threaded, event based HTTP servers like LigHTTPD. The property tree would map nicely to URL space, the data could be stored in memory, by a simple custom handler module. This would take care of concurrency issues and be very fast as HTTP is a simple protocol. Server push could take care of listeners, but obviously tied properties would have to go. But the latter have been a source of problems for modelers anyway, since one cannot attach listeners to them. I wonder if their performance benefit is really worth the hassle. And it would provide HTTP access to properties for free, allowing to dump the correspondent code in FG :) Nine -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGR0Od1QuEJQQMVrgRCBplAKCHzW5h+6LiVWcefbdSFp6YxeN+sACfbHsz f3TynbUWntduxHFugDOwa4s= =Xw/z -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
