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

280 lines
8 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()
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
# include <errno.h> // perror()
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 <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"
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
static const int MAX_BUF = 32768;
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
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
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
buf = new char[MAX_BUF];
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 );
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
perror( "ExternalPipe()" );
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
}
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 );
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
perror( "ExternalPipe()" );
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
}
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 );
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
perror( "~FGExternalPipe()" );
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
}
result = close( pd2 );
if ( result == -1 ) {
SG_LOG( SG_IO, SG_ALERT, "Unable to close named pipe: "
<< fifo_name_2 );
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
perror( "~FGExternalPipe()" );
}
#endif
}
static int write_fifo( char cmd_type, int pd, char *cmd, int len ) {
#ifdef HAVE_MKFIFO
char *buf = new char[len + 3];
// write 2 byte command length + command type + command
char hi = (len + 1) / 256;
char lo = (len + 1) - (hi * 256);
buf[0] = hi;
buf[1] = lo;
buf[2] = cmd_type;
// strncpy( buf + 3, cmd, len );
memcpy( buf + 3, cmd, len );
if ( cmd_type == '1' ) {
// cout << "writing '" << cmd << "'" << endl;
} else if ( cmd_type == '2' ) {
// cout << "writing controls packet" << endl;
} else {
// cout << "writing unknown command?" << endl;
}
// for ( int i = 0; i < len + 3; ++i ) {
// cout << " " << (int)buf[i];
// }
// cout << endl;
int result = ::write( pd, buf, len + 3 );
if ( result == -1 ) {
perror( "write_fifo()" );
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << pd );
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
}
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
// cout << "wrote " << len + 3 << " bytes." << endl;
delete [] buf;
return result;
#else
return 0;
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
#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;
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "longitude-deg=%.8f", lon );
result = write_fifo( '1', 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
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "latitude-deg=%.8f", lat );
result = write_fifo( '1', 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
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "altitude-ft=%.8f", alt );
result = write_fifo( '1', 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
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "ground-m=%.8f", ground );
result = write_fifo( '1', 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
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "speed-kts=%.8f", speed );
result = write_fifo( '1', 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
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "heading-deg=%.8f", heading );
result = write_fifo( '1', 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
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 ) {
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "aircraft-weight-lbs=%.2f", weight );
result = write_fifo( '1', pd1, cmd, strlen(cmd) );
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
}
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 ) {
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "aircraft-cg-offset-inches=%.2f", cg_offset );
result = write_fifo( '1', pd1, cmd, strlen(cmd) );
Add support for passing a CG offset (in inches) to an external FDM.
2003-11-13 03:10:09 +00:00
}
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") ) {
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "reset=ground" );
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
} else {
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
sprintf( cmd, "reset=air" );
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
}
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
result = write_fifo( '1', 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
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 ) {
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
char cmd[256];
sprintf( cmd, "aircraft-weight-lbs=%.2f", weight );
result = write_fifo( '1', pd1, cmd, strlen(cmd) );
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
}
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 ) {
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
char cmd[256];
sprintf( cmd, "aircraft-cg-offset-inches=%.2f", cg_offset );
result = write_fifo( '1', pd1, cmd, strlen(cmd) );
Add support for passing a CG offset (in inches) to an external FDM.
2003-11-13 03:10:09 +00:00
}
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
*((int *)ptr) = iterations;
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
// cout << "iterations = " << iterations << endl;
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 += 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 );
Change the message passing structure just a bit in order to remove a possible time dependency ambiguity on the remote end.
2004-04-20 22:53:38 +00:00
// cout << "writing control structure, size = "
// << length + sizeof(int) << endl;
result = write_fifo( '2', pd1, buf, length + 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
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