|
From: Curtis O. <cur...@fl...> - 2014-01-29 16:28:29
|
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.
On Wed, Jan 29, 2014 at 10:02 AM, Anders Gidenstam <and...@gi...
> wrote:
> On Wed, 29 Jan 2014, Jon S. Berndt wrote:
>
> > 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
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
|