Feeding FlightGear data through the Protocol Pipe

[Jon S. Berndt]

I am using JSBSim on a major aerospace program, and have recently gotten to
the point where using FlightGear to visualize the real-time flight
performance of the vehicle has been very beneficial. Since I am running
scripted flights in JSBSim with some code modifications that have not made
it into the JSBSim codebase, my best option is to drive FlightGear over a
socket interface. This is done using FlightGear's net_fdm interface,
implemented on the JSBSim side by Bertrand (if I recall correctly).

I've discovered, though, that there are some things I cannot do using that
approach. I would like to be able to move the control surfaces on the 3D
model of our vehicle, but they are not conventional surfaces and must be
addressed specifically. I can't find a way to make that work using the
net_fdm interface.

After a little bit of digging, I found the README.protocol file. I'm not
sure if that's what I want, or not, but it seems promising. As I understand
it, one may define in an XML file a set of data to be shipped to (or from)
FlightGear using named properties. I suppose there would have to be a
corresponding capability on the JSBSim side, using the same data structures.
Is there enough documentation somewhere that would permit the implementation
of such a capability on the JSBSim side?

Alternatively, it might be possible for me to use the existing control
surface variables in the net_fdm structure to send the needed data to
FlightGear, but the parameters would need to be manipulated on the
FlightGear side and then distributed to specific named properties
representing the control surfaces in the 3D model. Does that seem possible?

Thanks for your input.

Jon

[Erik Hofman]

Hi Jon,

Post by Jon S. Berndt
After a little bit of digging, I found the README.protocol file. I'm not
sure if that's what I want, or not, but it seems promising. As I understand
it, one may define in an XML file a set of data to be shipped to (or from)
FlightGear using named properties. I suppose there would have to be a
corresponding capability on the JSBSim side, using the same data structures.
Is there enough documentation somewhere that would permit the implementation
of such a capability on the JSBSim side?

I'm the one that started the generic protocol so I have a bit of
knowledge about it. In the mean time it has been much improved but it
turned out to become a nifty piece of code.

The FGProtocol derived class can be found in
FlightGear/src/Network/generic.[ch]xx

I do not think you really need the FGProtocol for JSBSim so copying
those two files and calling it from somewhere and combining it with
FGfdmSocket might be easy enough.

However, the generic protocol is designed to adapt to the client side
requirements so if you prefer to implement an ASCII or binary protocol
at the JSBSim end then your could still use the generic protocol at the
FlightGear side to communicate. It's just a matter of defining the
packet layout in an XML file.

Erik

[Anders Gidenstam]

Post by Jon S. Berndt
I am using JSBSim on a major aerospace program, and have recently gotten to
the point where using FlightGear to visualize the real-time flight
performance of the vehicle has been very beneficial. Since I am running
scripted flights in JSBSim with some code modifications that have not made
it into the JSBSim codebase, my best option is to drive FlightGear over a
socket interface. This is done using FlightGear's net_fdm interface,
implemented on the JSBSim side by Bertrand (if I recall correctly).
I've discovered, though, that there are some things I cannot do using that
approach. I would like to be able to move the control surfaces on the 3D
model of our vehicle, but they are not conventional surfaces and must be
addressed specifically. I can't find a way to make that work using the
net_fdm interface.
After a little bit of digging, I found the README.protocol file. I'm not
sure if that's what I want, or not, but it seems promising. As I understand
it, one may define in an XML file a set of data to be shipped to (or from)
FlightGear using named properties. I suppose there would have to be a
corresponding capability on the JSBSim side, using the same data structures.
Is there enough documentation somewhere that would permit the implementation
of such a capability on the JSBSim side?
Alternatively, it might be possible for me to use the existing control
surface variables in the net_fdm structure to send the needed data to
FlightGear, but the parameters would need to be manipulated on the
FlightGear side and then distributed to specific named properties
representing the control surfaces in the 3D model. Does that seem possible?
Thanks for your input.

Hi Jon,

There is a 3rd option too - and that is if we enhance JSBSim to output FG
multiplayer packets - that would allow FG to visualize several JSBSim runs
at the same time and you have access to a larger (but fixed) set of
possible properties to send.

Cheers,

Anders

[Jon S. Berndt]

Post by Erik Hofman
Hi Jon,
There is a 3rd option too - and that is if we enhance JSBSim to output
FG multiplayer packets - that would allow FG to visualize several
JSBSim runs at the same time and you have access to a larger (but
fixed) set of possible properties to send.
Cheers,
Anders

That raises some interesting possibilities - very interesting.

I guess, reading all this, that my interest is in being able to drive
FlightGear visuals (and 3D model[s]) from JSBSim. I can currently do that
using the net_fdm capability from JSBSim to FlightGear, but that doesn't
give me the ability to set arbitrary properties (for the 3D model) on the
FlightGear side. So, being able to duplicate the net_fdm capability using a
configurable "property sender" (from JSBSim to FlightGear) would be good. It
sounds like that could maybe be done using the configurable Protocol method,
or using the multiplayer capability. Which one would be easier to accomplish
in the near term, and would both of those be likely equally effective?

Jon

[Erik Hofman]

Post by Jon S. Berndt
I guess, reading all this, that my interest is in being able to drive
FlightGear visuals (and 3D model[s]) from JSBSim. I can currently do that
using the net_fdm capability from JSBSim to FlightGear, but that doesn't
give me the ability to set arbitrary properties (for the 3D model) on the
FlightGear side. So, being able to duplicate the net_fdm capability using a
configurable "property sender" (from JSBSim to FlightGear) would be good. It
sounds like that could maybe be done using the configurable Protocol method,
or using the multiplayer capability. Which one would be easier to accomplish
in the near term, and would both of those be likely equally effective?

The multiplayer protocol has the advantage of many-to-many
communications. I'm not very familiar with it's internals.

For one-to-one communication setting up the generic protocol
configuration file and extending the current net_fdm packet should be
quite simple.

Erik

[Erik Hofman]

Post by Erik Hofman
For one-to-one communication setting up the generic protocol
configuration file and extending the current net_fdm packet should be
quite simple.

.. although looking at the structure it might require some more
properties to be tied to variables within FlightGear.

Erik

[Jon S. Berndt]

Post by Erik Hofman
.. although looking at the structure it might require some more
properties to be tied to variables within FlightGear.
Erik

Would it be possible to use net_fdm to send named properties over to
FlightGear?

Jon

[Anders Gidenstam]

Post by Jon S. Berndt
Would it be possible to use net_fdm to send named properties over to
FlightGear?

IIRC net_fdm is just a fixed format packet. Changing that would be a major
change and would need measures to preserve backwards compatibility.

The quickest way to your goal with least (if any) source changes would be
to switch to a generic protocol - with a JSBSim output specification you
should be able to stream a comma separated list of states (rows) to FG.
You then set up the generic protocol for FG to take each element in the
rows and put it in the right FG property.

This way the set of properties to transfer would be defined by XML files
both on the JSBSim and on the FG side.


Cheers,

Anders

[Curtis Olson]

Hi Jon,

For what it's worth, the "ExternalPipe" fdm was setup to cover much of the
areas you have touched on. It's probably not exactly what you want but
here was some of my logic in how/why I setup it up the way I did.

- Using a network interface adds some indeterminism ... sometimes
network packets are delayed or stack up depending on what is going on with
the machine so there isn't a guaranteed lockstep relationship between the
simulator the the flight dynamics.
- Usually the network interface is good, but I observed times when it
had extra delays in packets getting where they needed to go.
- As an alternative, I setup a pair of "named pipes". Pipes are a unix
construct, they look like a file to the program, but what you write into
them is collected and held for some other application to read out.
Unfortunately these are not supported in windows. Pipes are single
direction, thus the need for two of them for bi-directional communication.
A pipe is really simple: you open it up like any other file, and one
process writes into it; the other process reads from it. In between the OS
can buffer some amount of information until the reader grabs it. You can
use blocking reads (carefully) to ensure FlightGear and your external FDM
run in exact lockstep.
- Pipes imply both processes will run on the same machine, a network
interface would allow the processes to live on separate machines.
- The ExternalPipe interface supports a flexible property interface, so
the external FDM process can send any name/value pairs it wishes to send
and the interface will dutifully copy them into the FlightGear property
tree. The FDM side can also send a list of property names it would like to
receive in reply and the interface will dutifully send them over the
outgoing pipe every frame. This was a nice addition, and there is plenty
of bandwidth through a named pipe to do this in clear text, even with a lot
of extra property values.

History: I used this as part of a project I did with ATC flight sim. They
had their own proprietary flight dynamics applications that modeled
specific aircraft in the code itself. These models had all the necessary
source documentation and flight test data to satisfy FAA certification
testing requirements of the final simulator. In addition, this external
code modelled many of the aircraft systems for one of their high end sims.
This required the ability to be flexible in what values were sent back and
forth and enabled me to drive some instrument gauges directly from the
external code.

Regards,

Curt.

Post by Anders Gidenstam

Post by Jon S. Berndt
Would it be possible to use net_fdm to send named properties over to
FlightGear?

IIRC net_fdm is just a fixed format packet. Changing that would be a major
change and would need measures to preserve backwards compatibility.
The quickest way to your goal with least (if any) source changes would be
to switch to a generic protocol - with a JSBSim output specification you
should be able to stream a comma separated list of states (rows) to FG.
You then set up the generic protocol for FG to take each element in the
rows and put it in the right FG property.
This way the set of properties to transfer would be defined by XML files
both on the JSBSim and on the FG side.
Cheers,
Anders
--
---------------------------------------------------------------------------
Anders Gidenstam
WWW: http://gitorious.org/anders-hangar
http://www.gidenstam.org/FlightGear/
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[geneb]

Post by Curtis Olson
- As an alternative, I setup a pair of "named pipes". Pipes are a unix
construct, they look like a file to the program, but what you write into
them is collected and held for some other application to read out.
Unfortunately these are not supported in windows. Pipes are single

*coughs*
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365590%28v=vs.85%29.aspx

Curt, does the named pipe mechanism support "give me this property value",
"set this property value" calls, or is it something that has to be set up
when the system is started? (so you can't change what you get/set on the
fly)

(sorry for the hijack!)

g.

[Curtis Olson]

Hi Gene,

Post by geneb
*coughs*
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365590%28v=vs.85%29.aspx

Hmmm, learn something new every day ...

Post by geneb
Curt, does the named pipe mechanism support "give me this property value",
"set this property value" calls, or is it something that has to be set up
when the system is started? (so you can't change what you get/set on the
fly)

The named pipe mechanism simply provides a "file" like interface that one
process opens and writes to, and another process opens and reads from.
It's up to the writer and reader to exchange information they would
understand.

So all the property value exchange and requests are handled at a higher
level. The ExternalPipe FDM is an example, but probably would need
substantial mods before Jon would be happy with it.

Curt.

[geneb]

Post by Curtis Olson

Post by geneb
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365590%28v=vs.85%29.aspx

Hmmm, learn something new every day ...

\o/

Post by Curtis Olson
The named pipe mechanism simply provides a "file" like interface that one
process opens and writes to, and another process opens and reads from.
It's up to the writer and reader to exchange information they would
understand.

So in order to implement a generic getter/setter, a custom variant of
ExternalPipe FDM would need to be written?

tnx.

[Curtis Olson]

Post by geneb
So in order to implement a generic getter/setter, a custom variant of
ExternalPipe FDM would need to be written?

What I wrote originally was focused on a specific need for a specific
application so it has some non-generic code in there. It assumes a bit of
a specific initialization sequence with the external FDM.

If it was me and I was doing this again, I'd definitely start with
ExternalPipe FDM and try to make that work, maybe extend it's capabilities
a little bit if need be. That may not be needed, but then again sometimes
Jon has a very specialized or advanced application in mind.

I wrote that code in 2003 and this is the first time anyone has asked about
it or asked about doing something similar so I'm sure if we stopped and put
on our thinking caps we could come up with something simpler/better or more
modern or more cool? Or maybe we decide what is there now will work
perfectly?

I'd lobby for not making substantial structural changes to ExternalFDM in
order to preserve the potential upgrade compatibility with the original
project I wrote the code for.

Best regards,

Curt.

[geneb]

Post by Curtis Olson

Post by geneb
So in order to implement a generic getter/setter, a custom variant of
ExternalPipe FDM would need to be written?

I'd lobby for not making substantial structural changes to ExternalFDM in
order to preserve the potential upgrade compatibility with the original
project I wrote the code for.

I would agree. Somthing that takes the pipe communication of what
ExternalFDM does and go from there. It would be nice for example to feed
view data from castAR or an Occulus Rift without having to tear into the
main code base. I'd like to see an FSUIPC-like interface as well, but
that would require the generic getter/setter I mentioned earlier.

g.

[Erik Hofman]

Post by Erik Hofman
Hi Jon,
For what it's worth, the "ExternalPipe" fdm was setup to cover much of
the areas you have touched on. It's probably not exactly what you want
but here was some of my logic in how/why I setup it up the way I did.

Maybe this should be integrated in the Network code? It is already used
to handle network packets and serial port connections for example.

Erik

[Erik Hofman]

Post by Anders Gidenstam

Post by Jon S. Berndt
Would it be possible to use net_fdm to send named properties over to
FlightGear?

IIRC net_fdm is just a fixed format packet. Changing that would be a major
change and would need measures to preserve backwards compatibility.

My idea was to copy the net_fdm code at the JSBSim side and extend it
with the necessary extra properties (probably calling it something else)
and use the generic protocol to handle the new packet format.

Thinking about it, maybe JSBSim could make two connections, one sending
the net_fdm packets and one sending the extra information (and using the
generic protocol within FlightGear). I know FlightGear would be able to
handle two streams.

Erik

[Curtis Olson]

I have done things like that in the past as well ... send values in unused
channels and then have a bit of nasal code on the flightgear side that
pulls out those values and copies them where I really wanted them to go.
I'd have to check but some of those default structures might have a few
slots for unspecified data values exactly for this purpose.

Regards,

Curt.

Actually, there may be an even easier way to do this for my situation. I
can send through the existing net fdm structure the needed values within
the variables designated for normal aerosurfaces. On the flightgear side, I
would then need to copy these values from the aerosurfaces to the specific
named properties representing aerosurfaces in my 3D model. Is that
something that a nasal script could do?
Jon
----- Reply message -----
To: "FlightGear developers discussions" <
Subject: [Flightgear-devel] Feeding FlightGear data through the Protocol
Pipe
Date: Wed, Jan 29, 2014 11:13 AM
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Bruce Jackson]

Post by Anders Gidenstam

Post by Jon S. Berndt
Would it be possible to use net_fdm to send named properties over to
FlightGear?

IIRC net_fdm is just a fixed format packet. Changing that would be a major
change and would need measures to preserve backwards compatibility.
The quickest way to your goal with least (if any) source changes would be
to switch to a generic protocol - with a JSBSim output specification you
should be able to stream a comma separated list of states (rows) to FG.
You then set up the generic protocol for FG to take each element in the
rows and put it in the right FG property.
This way the set of properties to transfer would be defined by XML files
both on the JSBSim and on the FG side.

Jon,

That's how we're driving FG for the same project you're working on: custom protocol.

We've made up an arbitrary property tree hierarchy and are shoveling control deflections and other bits into those properties; on the other end, we're using those properties to drive a custom HUD, and I guess Gene H's 3D model is doing the same thing for control deflections.

In our custom protocol XML file, items like this appear:

<!-- Upper left body flap deflection -->
<chunk>
<name>ulbf-pos-norm</name>
<node>/surface-positions/ulbf-pos-norm</node>
<type>double</type>
</chunk>

and

<!-- Outer glideslope flight path angle, deg -->
<chunk>
<name>ogs-gamm-deg-hud</name>
<node>fcs/ogs-gamma-deg-hud</node>
<type>double</type>
</chunk>

The first chunk is used by the 3D model, and the second by my custom HUD (which required a custom HUD.xml file and some mods to HUD.cpp)

To hook up the surface deflections, a custom XML file for the aircraft that included things like:

<PropertyList>
<path>DC.ac</path> <!-- this is the exterior geometry file -->
<animation>
<type>rotate</type>
<object-name>ul</object-name> <!-- I expect this matches some geometry structure name in the .ac file -->
<property>/surface-positions/ulbf-pos-norm</property> <!-- matches protocol property list tree -->
<offset-deg>0</offset-deg>
<center>
<x-m>12.052</x-m>
<y-m>-1.402</y-m>
<z-m> 3.576</z-m>
</center>
<axis> <!-- I assume this is the rotation axis -->
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
.
.
.
</PropertyList>

Give me a call or text and I can try to share the details.

-- Bruce

[Bertrand Coconnier]

Post by Jon S. Berndt
I am using JSBSim on a major aerospace program, and have recently gotten to
the point where using FlightGear to visualize the real-time flight
performance of the vehicle has been very beneficial. Since I am running
scripted flights in JSBSim with some code modifications that have not made
it into the JSBSim codebase, my best option is to drive FlightGear over a
socket interface. This is done using FlightGear's net_fdm interface,
implemented on the JSBSim side by Bertrand (if I recall correctly).

I am afraid this is not correct :-) I might have modified occasionally some
bits of code in net_fdm but I am not the author of that interface in JSBSim.

Bertrand.