Reusing the flight recorder subsystem for property synchronization purposes

From FlightGear wiki
Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.

It would also be nice to support recording/replaying of arbitrary/custom properties.

We already have a similar solution for multiplayer mode. If the replay system recorded the same properties configured in the "aircraft-set.xml" (the "generic" int/float/string properties), it would mean a nice improvement. It would also have other advantages, such as allowing simple tests of an aircraft's multiplayer configuration.[1]

It should be possible to join some of the multiplayer and replay code. The replay system could use the existing encoder of the multiplay manager to generate the data packets - but then record them locally instead of transmitting them via UDP. During replay, these packets could then also be decoded by existing multiplayer code. Might be worth a thought, if someone wanted to dig in this area.[2]

  1. ThorstenB (Mar 31st, 2011). Re: [Flightgear-devel] Replay system.
  2. ThorstenB (Apr 2nd, 2011). Re: [Flightgear-devel] Replay system.

Problem

AndersG implemented the whole Dual Control system in scripting space - it would be possible to support the whole thing in a "global" fashion with a handful of minor additions, mainly based on looking at related subsystems, e.g. the "instant replay" (flight recorder) feature - and hooking that up to the multiplayer system by XDR-encoding the corresponding properties. The main thing that aircraft developers would still have to do is to create a corresponding "flightrecorder" configuration for their aircraft/cockpit to encode the transmission/update semantics accordingly. This could be handled by using XML attributes which are parsed by C++ code to automatically register the corresponding XDR helpers. [1]

under the hood, it is mainly about formaliing state management - which is overlapping with the way the flight recorder has to work, but also the MP protocol. To some degree, you can model this analogous to entities (objects) with varying access specifiers (think public, protected and private state). private state would only ever be mutated by the locally running fgfs instance, while public/protected state would need to be channeled through a wrapper. You are right that the MP protocol is not sufficiently flexible for this in its current form, but the way AndersG has implemented the Dual Control system, it is piggy-backed on top of a transport mechanism using "string" properties, which are used as the transport mechanism for "I/O channels" on top of Nasal data. Like you say, HLA should make these things much easier. However, let's be honest: any aircraft that 1) supports multiplayer and 2) supports the flight recorder/replay feature and 3) distributed setups (like those at FSWeekend/LinuxTag), could /in theory/ also support "Dual Control" - certainly once/if the underlying systems are merged. The building blocks to make something like this possible are already there - the difficult stuff is convincing aircraft developers (like yourself) to adopt the corresponding systems (multiplayer and the flight recorder). So the whole "global" thing would be possible to pull off, but it should not be done using Nasal and the existing MP system. In the case of the shuttle, or even just complex airliners, formalizing data dependencies (switch states, annunicator states etc), that would be tons of work to do manually, given the plethora of switches and state indicators - which is why I am not convinced that this should be done manually, but done semi-automatically by annotating properties (and possibly even branches of properties in the tree). A while ago, I did experiment with replicating a Canvas-based PFD/ND display in another fgfs instance using the "brute force" approach - i.e. copying the whole property branch of the corresponding Canvas via telnet and patching it up via Nasal subsequently, the whole thing was not very elegant, but it actually worked. So I do understand how difficult this is, as well as the limitations of the current system - however, if aircraft/cockpit developers had a handful of property attributes to differentiate between different kinds of simulator state (local/remote vs. switches vs. displays), it would be possible to pull this off, pretty much by using the existing technology stack - the main limitation would be bandwidth then, i.e. you would have to be on the same LAN as the other instances, because it simply isn't feasible to replicate a PFD/ND using low-level calls (primitives) - instead, the whole instrument logic would need to be running in each fgfs instance, with only events being propagated accordingly - i.e .in a master/slave fashion.[2]

Background

The flight recorder subsystem is the best candidate for implementing "multi-pilot" functionality in a global/general fashion, without being specific to any particular aircraft - and it also is the most likely platform for implementing multi-instance state replication, i.e. setups like those commonly seen during FSWeekend/LinuxTag, where multiple computers running fgfs may be linked together to create a single immersive environment. [3]

Our best chance of getting "global multi-pilot support" is implementing flight recorder support, i.e. as per $FG_ROOT/Docs/README.flightrecorder While that will not immediately get you this features, it is the most solid platform/framework we currently have in place to implement this feature, because it delegates state management to the corresponding aircraft developer. At that point, you really only need to file feature requests to extend the flight recorder subsystem so that it can serialie properties to/from XDR types (which are already used by the multiplayer system), and a few more state change directives would be useful ("update-on-change", "update-on-write", "update-at-XX-hz" - which is touching on the HLA effort, but the flight recorder subsystem would remain the most suitable platform for implementing this feature in a generic fashion, so that aircraft developers would only need to update their flight recorder configuration file to configure which properties are relevant, as well as their mutability (i.e. state being read-only/writeable etc) [4]

Proof of Concept

Note  For now, this is merely untested pseudo code to demonstrate how to load the flight recorder configuration for an AI model from $FG_AIRCRAFT
var ai_aircraft = "c172p";
var fgroot = getprop("/sim/fg-root");
var set_filename = fgroot ~ "/" ai_aircraft ~"-set.xml";
var set_blob = io.read_properties(filename);
var flightrecorder_config = set_blob.getValues() ["flight-recorder"];
debug.dump(flightrecorder_config);

References

References
  1. Hooray (Dec 29th, 2015). Re: Global Feature Suggestion for FlightGear: Cockpit Sharin.
  2. Hooray (Dec 29th, 2015). Re: Global Feature Suggestion for FlightGear: Cockpit Sharin.
  3. Hooray (Feb 8th, 2016). Re: Global Feature.
  4. Hooray (Feb 8th, 2016). Re: Global Feature.