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

269 lines
8.1 KiB
C++
Raw Normal View History

Add support for sending out a requested aircraft weight to an external FDM via the "pipe" interface.
2003-11-10 21:56:32 +00:00
// ExternalPipe.cxx -- a "pipe" interface to an external flight dynamics model
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
//
// Written by Curtis Olson, started March 2003.
//
// Copyright (C) 2003 Curtis L. Olson - curt@flightgear.org
//
// 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
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
//
// $Id$
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
MingW 0.92 fixes
2003-06-08 12:01:43 +00:00
#ifdef HAVE_MKFIFO
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 <sys/types.h> // mkfifo() open() umask()
# include <sys/stat.h> // mkfifo() open() umask()
# include <fcntl.h> // open()
# include <unistd.h> // unlink()
#endif
#include <simgear/debug/logstream.hxx>
#include <simgear/io/lowlevel.hxx> // endian tests
#include <Main/fg_props.hxx>
#include <Network/native_ctrls.hxx>
#include <Network/native_fdm.hxx>
#include "ExternalPipe.hxx"
FGExternalPipe::FGExternalPipe( double dt, string name ) {
valid = true;
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
last_weight = 0.0;
last_cg_offset = -9999.9;
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
Ooops, I added another item to what I write to the buffer, but forgot to make it big enough to hold the new item. This was manifesting itself as a crash on reset (if the ExternalPipe FDM was being used.)
2003-08-01 17:06:11 +00:00
buf = new char[sizeof(char) + sizeof(int) + sizeof(ctrls)];
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
MingW 0.92 fixes
2003-06-08 12:01:43 +00:00
#ifdef HAVE_MKFIFO
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
fifo_name_1 = name + "1";
fifo_name_2 = name + "2";
SG_LOG( SG_IO, SG_ALERT, "ExternalPipe Inited with " << name );
// Make the named pipe
umask(0);
int result;
result = mkfifo( fifo_name_1.c_str(), 0644 );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Unable to create named pipe: "
<< fifo_name_1 );
valid = false;
}
result = mkfifo( fifo_name_2.c_str(), 0644 );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Unable to create named pipe: "
<< fifo_name_2 );
valid = false;
}
pd1 = open( fifo_name_1.c_str(), O_RDWR );
if ( pd1 == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Unable to open named pipe: " << fifo_name_1 );
valid = false;
}
pd2 = open( fifo_name_2.c_str(), O_RDWR );
if ( pd2 == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Unable to open named pipe: " << fifo_name_2 );
valid = false;
}
#endif
}
FGExternalPipe::~FGExternalPipe() {
delete [] buf;
Don't remove the named pipe on a "Reset" or position change (i.e. when FGExternalPipe is destructed.) This leaves the name pipe hanging around even after flightgear exits, but assuming we put the files in /tmp that shouldn't be a big deal.
2003-03-03 17:48:09 +00:00
SG_LOG( SG_IO, SG_INFO, "Closing up the ExternalPipe." );
MingW 0.92 fixes
2003-06-08 12:01:43 +00:00
#ifdef HAVE_MKFIFO
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
// close
int result;
result = close( pd1 );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Unable to close named pipe: "
<< fifo_name_1 );
}
result = close( pd2 );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Unable to close named pipe: "
<< fifo_name_2 );
}
#endif
}
// Initialize the ExternalPipe flight model, dt is the time increment
// for each subsequent iteration through the EOM
void FGExternalPipe::init() {
// Explicitly call the superclass's
// init method first.
common_init();
double lon = fgGetDouble( "/sim/presets/longitude-deg" );
double lat = fgGetDouble( "/sim/presets/latitude-deg" );
double alt = fgGetDouble( "/sim/presets/altitude-ft" );
double ground = fgGetDouble( "/environment/ground-elevation-m" );
double heading = fgGetDouble("/sim/presets/heading-deg");
double speed = fgGetDouble( "/sim/presets/airspeed-kt" );
Add support for sending out a requested aircraft weight to an external FDM via the "pipe" interface.
2003-11-10 21:56:32 +00:00
double weight = fgGetDouble( "/sim/aircraft-weight-lbs" );
Add support for passing a CG offset (in inches) to an external FDM.
2003-11-13 03:10:09 +00:00
double cg_offset = fgGetDouble( "/sim/aircraft-cg-offset-inches" );
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
MingW 0.92 fixes
2003-06-08 12:01:43 +00:00
#ifdef HAVE_MKFIFO
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
char cmd[256];
int result;
sprintf( cmd, "1longitude-deg=%.8f", lon );
Remove std::
2003-03-04 00:25:35 +00:00
result = write( pd1, cmd, strlen(cmd) );
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
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
sprintf( cmd, "1latitude-deg=%.8f", lat );
result = ::write( pd1, cmd, strlen(cmd) );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
sprintf( cmd, "1altitude-ft=%.8f", alt );
Remove std::
2003-03-04 00:25:35 +00:00
result = write( pd1, cmd, strlen(cmd) );
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
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
sprintf( cmd, "1ground-m=%.8f", ground );
Remove std::
2003-03-04 00:25:35 +00:00
result = write( pd1, cmd, strlen(cmd) );
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
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
sprintf( cmd, "1speed-kts=%.8f", speed );
Remove std::
2003-03-04 00:25:35 +00:00
result = write( pd1, cmd, strlen(cmd) );
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
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
sprintf( cmd, "1heading-deg=%.8f", heading );
Remove std::
2003-03-04 00:25:35 +00:00
result = write( pd1, cmd, strlen(cmd) );
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
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
Add support for sending out a requested aircraft weight to an external FDM via the "pipe" interface.
2003-11-10 21:56:32 +00:00
if ( weight > 1000.0 ) {
sprintf( cmd, "1aircraft-weight-lbs=%.2f", weight );
result = write( pd1, cmd, strlen(cmd) );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
}
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
last_weight = weight;
Add support for sending out a requested aircraft weight to an external FDM via the "pipe" interface.
2003-11-10 21:56:32 +00:00
Add support for passing a CG offset (in inches) to an external FDM.
2003-11-13 03:10:09 +00:00
if ( cg_offset > -5.0 || cg_offset < 5.0 ) {
sprintf( cmd, "1aircraft-cg-offset-inches=%.2f", cg_offset );
result = write( pd1, cmd, strlen(cmd) );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
}
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
last_cg_offset = cg_offset;
Add support for passing a CG offset (in inches) to an external FDM.
2003-11-13 03:10:09 +00:00
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
SG_LOG( SG_IO, SG_INFO, "before sending reset command." );
if( fgGetBool("/sim/presets/onground") ) {
sprintf( cmd, "1reset=ground" );
} else {
sprintf( cmd, "1reset=air" );
}
Remove std::
2003-03-04 00:25:35 +00:00
result = write( pd1, cmd, strlen(cmd) );
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
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
SG_LOG( SG_IO, SG_INFO, "Remote FDM init() finished." );
#endif
}
// Run an iteration of the EOM.
void FGExternalPipe::update( double dt ) {
MingW 0.92 fixes
2003-06-08 12:01:43 +00:00
#ifdef HAVE_MKFIFO
Don't remove the named pipe on a "Reset" or position change (i.e. when FGExternalPipe is destructed.) This leaves the name pipe hanging around even after flightgear exits, but assuming we put the files in /tmp that shouldn't be a big deal.
2003-03-03 17:48:09 +00:00
// SG_LOG( SG_IO, SG_INFO, "Start FGExternalPipe::udpate()" );
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
int length;
int result;
Add support for sending out a requested aircraft weight to an external FDM via the "pipe" interface.
2003-11-10 21:56:32 +00:00
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
if ( is_suspended() ) {
return;
}
A small optimization, pass the number of iterations to the remote end and have it do all the work, rather than calling the remote end "iteration" number of times.
2003-03-03 04:59:41 +00:00
int iterations = _calc_multiloop(dt);
Add support for sending out a requested aircraft weight to an external FDM via the "pipe" interface.
2003-11-10 21:56:32 +00:00
double weight = fgGetDouble( "/sim/aircraft-weight-lbs" );
static double last_weight = 0.0;
if ( fabs( weight - last_weight ) > 0.01 ) {
char cmd[256];
sprintf( cmd, "1aircraft-weight-lbs=%.2f", weight );
result = write( pd1, cmd, strlen(cmd) );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
}
last_weight = weight;
Add support for passing a CG offset (in inches) to an external FDM.
2003-11-13 03:10:09 +00:00
double cg_offset = fgGetDouble( "/sim/aircraft-cg-offset-inches" );
if ( fabs( cg_offset - last_cg_offset ) > 0.01 ) {
char cmd[256];
sprintf( cmd, "1aircraft-cg-offset-inches=%.2f", cg_offset );
result = write( pd1, cmd, strlen(cmd) );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << fifo_name_1 );
}
}
last_cg_offset = cg_offset;
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
// Send control positions to remote fdm
length = sizeof(ctrls);
Curt: I have added a fledgling replay system that records flight data and control positions during the flight. I have added an internal command called "replay" which will trigger a replay of the entire saved flight data set. This could be bound to a keyboard or menu command, in fact this entire module is screaming for someone to build a gui to control playback speed, amount of playback, etc. This is the initial version so there are kinks that still need to be worked out, please be patient.
2003-07-17 18:24:17 +00:00
FGProps2NetCtrls( &ctrls, true, false );
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
char *ptr = buf;
A small optimization, pass the number of iterations to the remote end and have it do all the work, rather than calling the remote end "iteration" number of times.
2003-03-03 04:59:41 +00:00
*ptr = '2';
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
ptr++;
A small optimization, pass the number of iterations to the remote end and have it do all the work, rather than calling the remote end "iteration" number of times.
2003-03-03 04:59:41 +00:00
*((int *)ptr) = iterations;
ptr += sizeof(int);
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
memcpy( ptr, (char *)(&ctrls), length );
Clean up some debugging output.
2004-04-02 16:17:08 +00:00
// cout << "writing control structure to remote fdm." << endl;
Remove std::
2003-03-04 00:25:35 +00:00
result = write( pd1, buf, length + 1 );
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
if ( result == -1 ) {
A small optimization, pass the number of iterations to the remote end and have it do all the work, rather than calling the remote end "iteration" number of times.
2003-03-03 04:59:41 +00:00
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: "
<< fifo_name_1 );
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
} else {
Clean up some debugging output.
2004-04-02 16:17:08 +00:00
// cout << " write successful = " << length + 1 << endl;
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
}
Add support for sending out a requested aircraft weight to an external FDM via the "pipe" interface.
2003-11-10 21:56:32 +00:00
// Read fdm values
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
length = sizeof(fdm);
Clean up some debugging output.
2004-04-02 16:17:08 +00:00
// cout << "about to read fdm data from remote fdm." << endl;
Remove std::
2003-03-04 00:25:35 +00:00
result = read( pd2, (char *)(& fdm), length );
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
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Read error from named pipe: "
<< fifo_name_2 );
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
} else {
Clean up some debugging output.
2004-04-02 16:17:08 +00:00
// cout << " read successful." << endl;
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
}
FGNetFDM2Props( &fdm, false );
#endif
}
Copy permalink