fly/flightgear
1
0
Fork 0
Code Activity
flightgear/src/FDM/ExternalPipe/ExternalPipe.hxx

83 lines
2.1 KiB
C++
Raw Normal View History

First stab at a "named pipe" interface to an external FDM. Compared to the ExternalNet interface: - allows a much more closely coupled execution. A remote network FDM will run at it's own rate, and maybe a particular data packets will come, maybe it won't. This makes it very hard to control timing and keep the animation smooth. There are also cpu scheduling issues with running multiple processes on a single machine. The linux scheduler by default runs at 100hz. If an FDM process uses a sleep/alarm system to avoid wasting CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This makes it *impossible* to serve a display system running at 60hz without dropping frames. - the downside is that the FDM process must now run on the same machine as the master flightgear process.
2003-03-03 04:30:16 +00:00
// ExternalPipe.hxx -- a "pipe" interface to an external flight dynamics model
//
// Written by Curtis Olson, started March 2003.
//
Fix my mailing address by replacing it with my web page.
2004-11-19 22:10:41 +00:00
// Copyright (C) 2003 Curtis L. Olson - http://www.flightgear.org/~curt
First stab at a "named pipe" interface to an external FDM. Compared to the ExternalNet interface: - allows a much more closely coupled execution. A remote network FDM will run at it's own rate, and maybe a particular data packets will come, maybe it won't. This makes it very hard to control timing and keep the animation smooth. There are also cpu scheduling issues with running multiple processes on a single machine. The linux scheduler by default runs at 100hz. If an FDM process uses a sleep/alarm system to avoid wasting CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This makes it *impossible* to serve a display system running at 60hz without dropping frames. - the downside is that the FDM process must now run on the same machine as the master flightgear process.
2003-03-03 04:30:16 +00:00
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
new FSF address
2006-02-21 01:16:04 +00:00
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
First stab at a "named pipe" interface to an external FDM. Compared to the ExternalNet interface: - allows a much more closely coupled execution. A remote network FDM will run at it's own rate, and maybe a particular data packets will come, maybe it won't. This makes it very hard to control timing and keep the animation smooth. There are also cpu scheduling issues with running multiple processes on a single machine. The linux scheduler by default runs at 100hz. If an FDM process uses a sleep/alarm system to avoid wasting CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This makes it *impossible* to serve a display system running at 60hz without dropping frames. - the downside is that the FDM process must now run on the same machine as the master flightgear process.
2003-03-03 04:30:16 +00:00
//
// $Id$
#ifndef _EXTERNAL_PIPE_HXX
#define _EXTERNAL_PIPE_HXX
This is a work in progress. I am extending the "ExternalPipe" protocol to have a "property" mode as well as the original "binary" mode. The property mode will allow the remote module to request any set of properties, and it will send those properties each frame. The remote module can reply with a list of arbitrary property name/value pairs to update on the FlightGear side. This is a first stab, so it's not the cleanest, most well concieved code, but it allows an external module (communicating via a pipe) to have a huge amount of flexibility in the data in can access and update.
2005-04-19 01:44:56 +00:00
#include <stdio.h> // FILE*, fopen(), fread(), fwrite(), et. al.
First stab at a "named pipe" interface to an external FDM. Compared to the ExternalNet interface: - allows a much more closely coupled execution. A remote network FDM will run at it's own rate, and maybe a particular data packets will come, maybe it won't. This makes it very hard to control timing and keep the animation smooth. There are also cpu scheduling issues with running multiple processes on a single machine. The linux scheduler by default runs at 100hz. If an FDM process uses a sleep/alarm system to avoid wasting CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This makes it *impossible* to serve a display system running at 60hz without dropping frames. - the downside is that the FDM process must now run on the same machine as the master flightgear process.
2003-03-03 04:30:16 +00:00
#include <simgear/timing/timestamp.hxx> // fine grained timing measurements
#include <Network/net_ctrls.hxx>
#include <Network/net_fdm.hxx>
make headers include headers they depend on, don't rely on the c(xx) file to do that. (This is a requirement for header precompiling.)
2006-04-17 13:19:53 +00:00
#include <FDM/flight.hxx>
First stab at a "named pipe" interface to an external FDM. Compared to the ExternalNet interface: - allows a much more closely coupled execution. A remote network FDM will run at it's own rate, and maybe a particular data packets will come, maybe it won't. This makes it very hard to control timing and keep the animation smooth. There are also cpu scheduling issues with running multiple processes on a single machine. The linux scheduler by default runs at 100hz. If an FDM process uses a sleep/alarm system to avoid wasting CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This makes it *impossible* to serve a display system running at 60hz without dropping frames. - the downside is that the FDM process must now run on the same machine as the master flightgear process.
2003-03-03 04:30:16 +00:00
class FGExternalPipe: public FGInterface {
private:
bool valid;
string fifo_name_1;
string fifo_name_2;
This is a work in progress. I am extending the "ExternalPipe" protocol to have a "property" mode as well as the original "binary" mode. The property mode will allow the remote module to request any set of properties, and it will send those properties each frame. The remote module can reply with a list of arbitrary property name/value pairs to update on the FlightGear side. This is a first stab, so it's not the cleanest, most well concieved code, but it allows an external module (communicating via a pipe) to have a huge amount of flexibility in the data in can access and update.
2005-04-19 01:44:56 +00:00
FILE *pd1;
FILE *pd2;
string _protocol;
First stab at a "named pipe" interface to an external FDM. Compared to the ExternalNet interface: - allows a much more closely coupled execution. A remote network FDM will run at it's own rate, and maybe a particular data packets will come, maybe it won't. This makes it very hard to control timing and keep the animation smooth. There are also cpu scheduling issues with running multiple processes on a single machine. The linux scheduler by default runs at 100hz. If an FDM process uses a sleep/alarm system to avoid wasting CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This makes it *impossible* to serve a display system running at 60hz without dropping frames. - the downside is that the FDM process must now run on the same machine as the master flightgear process.
2003-03-03 04:30:16 +00:00
FGNetCtrls ctrls;
FGNetFDM fdm;
char *buf;
Clean up various compiler warnings that have crept into the code. This by no means get's them all, but it's a start.
2004-04-01 15:27:53 +00:00
double last_weight;
double last_cg_offset;
This is a work in progress. I am extending the "ExternalPipe" protocol to have a "property" mode as well as the original "binary" mode. The property mode will allow the remote module to request any set of properties, and it will send those properties each frame. The remote module can reply with a list of arbitrary property name/value pairs to update on the FlightGear side. This is a first stab, so it's not the cleanest, most well concieved code, but it allows an external module (communicating via a pipe) to have a huge amount of flexibility in the data in can access and update.
2005-04-19 01:44:56 +00:00
vector <string> property_names;
fix another crash on exit by finally converting the rest of unguarded SGPropertyNode to guarded ones. This is also done for JSBSim/JSBSim.hxx, for which JSB had given explicit permission a while ago. I postponed that back then, but now is the time.
2006-06-11 10:21:10 +00:00
vector <SGPropertyNode_ptr> nodes;
This is a work in progress. I am extending the "ExternalPipe" protocol to have a "property" mode as well as the original "binary" mode. The property mode will allow the remote module to request any set of properties, and it will send those properties each frame. The remote module can reply with a list of arbitrary property name/value pairs to update on the FlightGear side. This is a first stab, so it's not the cleanest, most well concieved code, but it allows an external module (communicating via a pipe) to have a huge amount of flexibility in the data in can access and update.
2005-04-19 01:44:56 +00:00
// Protocol specific init routines
void init_binary();
void init_property();
// Protocol specific update routines
void update_binary( double dt );
void update_property( double dt );
First stab at a "named pipe" interface to an external FDM. Compared to the ExternalNet interface: - allows a much more closely coupled execution. A remote network FDM will run at it's own rate, and maybe a particular data packets will come, maybe it won't. This makes it very hard to control timing and keep the animation smooth. There are also cpu scheduling issues with running multiple processes on a single machine. The linux scheduler by default runs at 100hz. If an FDM process uses a sleep/alarm system to avoid wasting CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This makes it *impossible* to serve a display system running at 60hz without dropping frames. - the downside is that the FDM process must now run on the same machine as the master flightgear process.
2003-03-03 04:30:16 +00:00
public:
// Constructor
This is a work in progress. I am extending the "ExternalPipe" protocol to have a "property" mode as well as the original "binary" mode. The property mode will allow the remote module to request any set of properties, and it will send those properties each frame. The remote module can reply with a list of arbitrary property name/value pairs to update on the FlightGear side. This is a first stab, so it's not the cleanest, most well concieved code, but it allows an external module (communicating via a pipe) to have a huge amount of flexibility in the data in can access and update.
2005-04-19 01:44:56 +00:00
FGExternalPipe( double dt, string fifo_name, string protocol );
First stab at a "named pipe" interface to an external FDM. Compared to the ExternalNet interface: - allows a much more closely coupled execution. A remote network FDM will run at it's own rate, and maybe a particular data packets will come, maybe it won't. This makes it very hard to control timing and keep the animation smooth. There are also cpu scheduling issues with running multiple processes on a single machine. The linux scheduler by default runs at 100hz. If an FDM process uses a sleep/alarm system to avoid wasting CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This makes it *impossible* to serve a display system running at 60hz without dropping frames. - the downside is that the FDM process must now run on the same machine as the master flightgear process.
2003-03-03 04:30:16 +00:00
// Destructor
~FGExternalPipe();
// Reset flight params to a specific position
void init();
// update the fdm
void update( double dt );
};
#endif // _EXTERNAL_PIPE_HXX
Copy permalink