Data Distribution Services support
|This article is a stub. You can help the wiki by|
The new Data Distribution System layer makes it much easier to attach and remove display systems. Just hook it up in the same network and configure it to use DDS.
Only a single data provider (server) connection is necessary to hook up 1, 2, 10 or 100 visual systems since it is a one-to-many protocol.
In 03/2021, Erik added a first stab at supporting CycloneDDS } support in next (FlightGear commit 5786d402725328d7c9913d361632854b5afb1124): https://github.com/eclipse-cyclonedds/cyclonedds
- Auto configuring within a LAN.
- Auto connecting and disconnecting.
- Platform and computer language agnostic:
- Instead to a one-on-one connection you get a one-to-many connection.
One thing which is important to keep in mind: DDS works on fixed structures so it is not possible to access individual property-nodes within FlightGear (which can be done when using the telnet/props or generic protocols). Future versions could adopt Google Protocol Buffers for dynamically allocating structures from IDL configurations.
If there is data missing in any of those net_* structs then it could be an option to add another structure to fill the gap.
What does this mean ?
You now can connect to FlightGear from Java and Python and get the same data as in C and C++
- Use your Raspberry Pi to display some cockpit instruments.
- Controlling the main system from a cell-phone
If you set up a system with multiple PC's driving multiple displays you can add, and remove, display stations on the fly.
How to run it
Just like using sockets but without the need to specify an IP-adress or port number:
fgfs --native-fdm=dds,out,60 fgfs --native-ctrls=dds,in,10
See for more information (needs to be updated for DDS support): Property Tree/Sockets
It is in its early stages right now but Erik included a small command line utility to log some FDM values like:
- altitude from a
DDS connection as an example. 
For details, take a look at flightgear/flightgear/next//examples/dds
As of 04/2021, Erik has implemented an initial implementation of a property server using Data Distribution Service. And he has also taken the time to implement it like he once envisioned the remote property tree.
The idea is as follows:
You request a property path, the server responds with the property value and a property index.
Successive requests now can use the index to access the property removing the need to send the full property path every request saving both bandwidth and lookup time. After thinking about this a bit more Erik suggested that a future revision will have a different scheme:
- Request the ID of the property you are interested in.
- You get an answer with the property value and ID for that property.
- From now on the server pushes an updated value for that particular property ID whenever the property value changes.
When set up properly, DDS will keep the changed properties in its cache for clients to read when they have time for it.
So no need to do successive requests anymore. Just wait and watch out for updates.
As an example, there is the fg_dds_prop utility in flightgear/flightgear/next/src/Network/DDS/fg_dds_prop.cpp which can be used to either request a property path or a known property ID.
And there is flightgear/flightgear/next/src/Network/DDS/fg_dds_log.cpp which is able to log all DDS samples passing over the DDS network layer, including the new property sample format.
To access properties from a running version of FlightGear, use the following command line parameter:
All this is 'next' only.