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

573 lines
18 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.
//
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$
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
MingW 0.92 fixes
2003-06-08 12:01:43 +00:00
#ifdef HAVE_MKFIFO
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 <sys/types.h> // mkfifo() umask()
# include <sys/stat.h> // mkfifo() 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 <unistd.h> // unlink()
#endif
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.
Include <iostream> and using declarations as needed. SimGear no longer includes iostream and avoids using declarations in header files, so various fixups are needed.
2008-06-02 21:07:35 +00:00
#include <iostream> // for cout, endl
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
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/debug/logstream.hxx>
#include <simgear/io/lowlevel.hxx> // endian tests
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 <simgear/misc/strutils.hxx> // split()
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 <Main/fg_props.hxx>
#include <Network/native_ctrls.hxx>
#include <Network/native_fdm.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 <Scenery/scenery.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
#include "ExternalPipe.hxx"
Include <iostream> and using declarations as needed. SimGear no longer includes iostream and avoids using declarations in header files, so various fixups are needed.
2008-06-02 21:07:35 +00:00
using std::cout;
using std::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
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;
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::FGExternalPipe( double dt, string 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
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
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
// clear property request list
property_names.clear();
nodes.clear();
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
}
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
pd1 = fopen( fifo_name_1.c_str(), "w" );
if ( pd1 == NULL ) {
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_ALERT, "Unable to open named pipe: " << fifo_name_1 );
valid = false;
}
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
pd2 = fopen( fifo_name_2.c_str(), "r" );
if ( pd2 == NULL ) {
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_ALERT, "Unable to open named pipe: " << fifo_name_2 );
valid = false;
}
#endif
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 = protocol;
if ( _protocol != "binary" && _protocol != "property" ) {
SG_LOG( SG_IO, SG_ALERT, "Constructor(): Unknown ExternalPipe protocol."
<< " Must be 'binary' or 'property'."
<< " (assuming binary)" );
_protocol = "binary";
}
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() {
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;
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
result = fclose( pd1 );
if ( result ) {
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_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
}
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
result = fclose( pd2 );
if ( result ) {
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_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
}
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
static int write_binary( char cmd_type, FILE *pd, char *cmd, int len ) {
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
#ifdef HAVE_MKFIFO
char *buf = new char[len + 3];
// write 2 byte command length + command type + command
Fix a "signededness" error.
2005-02-15 18:07:06 +00:00
unsigned char hi = (len + 1) / 256;
unsigned char lo = (len + 1) - (hi * 256);
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
// cout << "len = " << len << " hi = " << (int)hi << " lo = "
// << (int)lo << endl;
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[0] = hi;
buf[1] = lo;
buf[2] = cmd_type;
memcpy( buf + 3, cmd, len );
if ( cmd_type == '1' ) {
Slightly more user friendly output.
2005-08-23 21:36:05 +00:00
cout << "writing ";
cout << (int)hi << " ";
cout << (int)lo << " '";
for ( int i = 2; i < len + 3; ++i ) {
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
cout << buf[i];
}
cout << "' (" << cmd << ")" << endl;
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
} else if ( cmd_type == '2' ) {
Remove some old debugging output.
2005-08-22 23:47:17 +00:00
// cout << "writing controls packet" << endl;
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
} else {
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
cout << "writing unknown command?" << endl;
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
}
// for ( int i = 0; i < len + 3; ++i ) {
// cout << " " << (int)buf[i];
// }
// cout << endl;
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
int result = fwrite( buf, len + 3, 1, pd );
if ( result != 1 ) {
perror( "write_binary()" );
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
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
}
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
static int write_property( FILE *pd, char *cmd ) {
int len = strlen(cmd);
#ifdef HAVE_MKFIFO
char *buf = new char[len + 1];
memcpy( buf, cmd, len );
buf[len] = '\n';
int result = fwrite( buf, len + 1, 1, pd );
if ( result == len + 1 ) {
perror( "write_property()" );
SG_LOG( SG_IO, SG_ALERT, "Write error to named pipe: " << pd );
}
// cout << "wrote " << len + 1 << " bytes." << endl;
delete [] buf;
return result;
#else
return 0;
#endif
}
// Wrapper for the ExternalPipe flight model initialization. dt is
// the time increment for each subsequent iteration through the EOM
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
void FGExternalPipe::init() {
// Explicitly call the superclass's
// init method first.
common_init();
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
if ( _protocol == "binary" ) {
init_binary();
} else if ( _protocol == "property" ) {
init_property();
} else {
SG_LOG( SG_IO, SG_ALERT, "Init(): Unknown ExternalPipe protocol."
<< " Must be 'binary' or 'property'."
<< " (assuming binary)" );
}
}
// Initialize the ExternalPipe flight model using the binary protocol,
// dt is the time increment for each subsequent iteration through the
// EOM
void FGExternalPipe::init_binary() {
cout << "init_binary()" << 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
double lon = fgGetDouble( "/sim/presets/longitude-deg" );
double lat = fgGetDouble( "/sim/presets/latitude-deg" );
double alt = fgGetDouble( "/sim/presets/altitude-ft" );
Mathias Frhlich: I have prepared a patch that: - Introduces a FGTileMgr::scenery_available method which asks the tilemanager if scenery for a given range around a lat/lon pair is already loaded and make use of that method at some -9999 meter checks. - Introduces a FGScenery::get_elevation_m method which queries the altitude at a given position. In constrast to the groundcache functions this is the best choice if you ask for one *single* altitude value. Make use of that thing in AI/ATC classes and for the current views ground level. At the current views part the groundcache is reused if possible. - The computation of the 'current groundlevel' is no longer done on the tilemanagers update since the required functions are now better seperated. Alltogether it eliminates somehow redundant terrain level computations which are now superseeded by that more finegrained functions and the existence of the groundcache. Additionally it introduces an api to commonly required functions which was very complex to do prevously.
2005-08-14 12:57:12 +00:00
double ground = get_Runway_altitude_m();
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
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
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 );
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
result = write_binary( '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 );
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
result = write_binary( '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 );
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
result = write_binary( '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 );
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
result = write_binary( '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 );
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
result = write_binary( '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 );
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
result = write_binary( '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 );
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
result = write_binary( '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 );
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
result = write_binary( '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
Clean up some sound buffer allocation/deallocation issues.
2004-05-10 21:24:30 +00:00
SG_LOG( SG_IO, SG_ALERT, "before sending reset command." );
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( 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
}
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
result = write_binary( '1', pd1, cmd, strlen(cmd) );
fflush( pd1 );
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
Clean up some sound buffer allocation/deallocation issues.
2004-05-10 21:24:30 +00:00
SG_LOG( SG_IO, SG_ALERT, "Remote FDM init() finished." );
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 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
// Initialize the ExternalPipe flight model using the property
// protocol, dt is the time increment for each subsequent iteration
// through the EOM
void FGExternalPipe::init_property() {
cout << "init_property()" << endl;
double lon = fgGetDouble( "/sim/presets/longitude-deg" );
double lat = fgGetDouble( "/sim/presets/latitude-deg" );
double alt = fgGetDouble( "/sim/presets/altitude-ft" );
Mathias Frhlich: I have prepared a patch that: - Introduces a FGTileMgr::scenery_available method which asks the tilemanager if scenery for a given range around a lat/lon pair is already loaded and make use of that method at some -9999 meter checks. - Introduces a FGScenery::get_elevation_m method which queries the altitude at a given position. In constrast to the groundcache functions this is the best choice if you ask for one *single* altitude value. Make use of that thing in AI/ATC classes and for the current views ground level. At the current views part the groundcache is reused if possible. - The computation of the 'current groundlevel' is no longer done on the tilemanagers update since the required functions are now better seperated. Alltogether it eliminates somehow redundant terrain level computations which are now superseeded by that more finegrained functions and the existence of the groundcache. Additionally it introduces an api to commonly required functions which was very complex to do prevously.
2005-08-14 12:57:12 +00:00
double ground = get_Runway_altitude_m();
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
double heading = fgGetDouble("/sim/presets/heading-deg");
double speed = fgGetDouble( "/sim/presets/airspeed-kt" );
double weight = fgGetDouble( "/sim/aircraft-weight-lbs" );
double cg_offset = fgGetDouble( "/sim/aircraft-cg-offset-inches" );
char cmd[256];
int result;
sprintf( cmd, "init longitude-deg=%.8f", lon );
result = write_property( pd1, cmd );
sprintf( cmd, "init latitude-deg=%.8f", lat );
result = write_property( pd1, cmd );
sprintf( cmd, "init altitude-ft=%.8f", alt );
result = write_property( pd1, cmd );
sprintf( cmd, "init ground-m=%.8f", ground );
result = write_property( pd1, cmd );
sprintf( cmd, "init speed-kts=%.8f", speed );
result = write_property( pd1, cmd );
sprintf( cmd, "init heading-deg=%.8f", heading );
result = write_property( pd1, cmd );
if ( weight > 1000.0 ) {
sprintf( cmd, "init aircraft-weight-lbs=%.2f", weight );
result = write_property( pd1, cmd );
}
last_weight = weight;
if ( cg_offset > -5.0 || cg_offset < 5.0 ) {
sprintf( cmd, "init aircraft-cg-offset-inches=%.2f", cg_offset );
result = write_property( pd1, cmd );
}
last_cg_offset = cg_offset;
SG_LOG( SG_IO, SG_ALERT, "before sending reset command." );
if( fgGetBool("/sim/presets/onground") ) {
sprintf( cmd, "reset ground" );
} else {
sprintf( cmd, "reset air" );
}
result = write_property( pd1, cmd );
fflush( pd1 );
SG_LOG( SG_IO, SG_ALERT, "Remote FDM init() finished." );
}
// Wrapper for the ExternalPipe update routines. dt is the time
// increment for each subsequent iteration through the EOM
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
void FGExternalPipe::update( double dt ) {
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
if ( _protocol == "binary" ) {
update_binary(dt);
} else if ( _protocol == "property" ) {
update_property(dt);
} else {
SG_LOG( SG_IO, SG_ALERT, "Init(): Unknown ExternalPipe protocol."
<< " Must be 'binary' or 'property'."
<< " (assuming binary)" );
}
}
// Run an iteration of the EOM.
void FGExternalPipe::update_binary( double dt ) {
MingW 0.92 fixes
2003-06-08 12:01:43 +00:00
#ifdef HAVE_MKFIFO
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
SG_LOG( SG_IO, SG_INFO, "Start FGExternalPipe::udpate_binary()" );
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
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 );
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
result = write_binary( '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 );
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
result = write_binary( '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 );
Remove some old debugging output.
2005-08-22 23:47:17 +00:00
// cout << "writing control structure, size = "
// << length + sizeof(int) << endl;
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
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
result = write_binary( '2', pd1, buf, length + sizeof(int) );
fflush( pd1 );
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);
Remove some old debugging output.
2005-08-22 23:47:17 +00:00
// cout << "about to read fdm data from remote fdm." << endl;
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
result = fread( (char *)(& fdm), length, 1, pd2 );
Fix a misuse of a return value that lead to an error message being displayed when one shouldn't have been.
2005-06-14 17:53:40 +00:00
if ( result != 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
SG_LOG( SG_IO, SG_ALERT, "Read error from named pipe: "
Fix a misuse of a return value that lead to an error message being displayed when one shouldn't have been.
2005-06-14 17:53:40 +00:00
<< fifo_name_2 << " expected 1 item, but got " << result );
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 {
Remove some old debugging output.
2005-08-22 23:47:17 +00:00
// cout << " read successful." << endl;
Minor clean up.
2005-08-23 21:02:44 +00:00
FGNetFDM2Props( &fdm, 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
}
#endif
}
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
// Process remote FDM "set" commands
static void process_set_command( const string_list &tokens ) {
if ( tokens[1] == "geodetic_position" ) {
double lat_rad = atof( tokens[2].c_str() );
double lon_rad = atof( tokens[3].c_str() );
double alt_m = atof( tokens[4].c_str() );
cur_fdm_state->_updateGeodeticPosition( lat_rad, lon_rad,
alt_m * SG_METER_TO_FEET );
Mathias Frhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
double agl_m = alt_m - cur_fdm_state->get_Runway_altitude_m();
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
cur_fdm_state->_set_Altitude_AGL( agl_m * SG_METER_TO_FEET );
} else if ( tokens[1] == "euler_angles" ) {
double phi_rad = atof( tokens[2].c_str() );
double theta_rad = atof( tokens[3].c_str() );
double psi_rad = atof( tokens[4].c_str() );
cur_fdm_state->_set_Euler_Angles( phi_rad, theta_rad, psi_rad );
} else if ( tokens[1] == "euler_rates" ) {
double phidot = atof( tokens[2].c_str() );
double thetadot = atof( tokens[3].c_str() );
double psidot = atof( tokens[4].c_str() );
cur_fdm_state->_set_Euler_Rates( phidot, thetadot, psidot );
} else if ( tokens[1] == "alpha" ) {
cur_fdm_state->_set_Alpha( atof(tokens[2].c_str()) );
} else if ( tokens[1] == "beta" ) {
cur_fdm_state->_set_Beta( atof(tokens[2].c_str()) );
#if 0
cur_fdm_state->_set_V_calibrated_kts( net->vcas );
cur_fdm_state->_set_Climb_Rate( net->climb_rate );
cur_fdm_state->_set_Velocities_Local( net->v_north,
net->v_east,
net->v_down );
cur_fdm_state->_set_Velocities_Wind_Body( net->v_wind_body_north,
net->v_wind_body_east,
net->v_wind_body_down );
cur_fdm_state->_set_Accels_Pilot_Body( net->A_X_pilot,
net->A_Y_pilot,
net->A_Z_pilot );
#endif
} else {
fgSetString( tokens[1].c_str(), tokens[2].c_str() );
}
}
// Run an iteration of the EOM.
void FGExternalPipe::update_property( double dt ) {
// cout << "update_property()" << endl;
#ifdef HAVE_MKFIFO
// SG_LOG( SG_IO, SG_INFO, "Start FGExternalPipe::udpate()" );
int result;
char cmd[256];
if ( is_suspended() ) {
return;
}
int iterations = _calc_multiloop(dt);
double weight = fgGetDouble( "/sim/aircraft-weight-lbs" );
static double last_weight = 0.0;
if ( fabs( weight - last_weight ) > 0.01 ) {
sprintf( cmd, "init aircraft-weight-lbs=%.2f", weight );
result = write_property( pd1, cmd );
}
last_weight = weight;
double cg_offset = fgGetDouble( "/sim/aircraft-cg-offset-inches" );
if ( fabs( cg_offset - last_cg_offset ) > 0.01 ) {
sprintf( cmd, "init aircraft-cg-offset-inches=%.2f", cg_offset );
result = write_property( pd1, cmd );
}
last_cg_offset = cg_offset;
// Send requested property values to fdm
for ( unsigned int i = 0; i < nodes.size(); i++ ) {
sprintf( cmd, "set %s %s", property_names[i].c_str(),
nodes[i]->getStringValue() );
// cout << " sending " << cmd << endl;
result = write_property( pd1, cmd );
}
sprintf( cmd, "update %d", iterations );
write_property( pd1, cmd );
fflush( pd1 );
// Read FDM response
// cout << "ready to read fdm response" << endl;
bool done = false;
while ( !done ) {
if ( fgets( cmd, 256, pd2 ) == NULL ) {
cout << "Error reading data" << endl;
} else {
// cout << " read " << strlen(cmd) << " bytes" << endl;
Tidy up for a source code "snapshot" release.
2008-10-30 18:35:44 +00:00
// cout << cmd << endl;
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
}
// chop trailing newline
cmd[strlen(cmd)-1] = '\0';
// cout << cmd << endl;
string_list tokens = simgear::strutils::split( cmd, " " );
if ( tokens[0] == "request" ) {
// save the long form name
property_names.push_back( tokens[1] );
// now do the property name lookup and cache the pointer
SGPropertyNode *node = fgGetNode( tokens[1].c_str() );
if ( node == NULL ) {
// node doesn't exist so create with requested type
node = fgGetNode( tokens[1].c_str(), true );
if ( tokens[2] == "bool" ) {
node->setBoolValue(true);
} else if ( tokens[2] == "int" ) {
node->setIntValue(0);
} else if ( tokens[2] == "double" ) {
node->setDoubleValue(0.0);
} else if ( tokens[2] == "string" ) {
node->setStringValue("");
} else {
cout << "Unknown data type: " << tokens[2]
<< " for " << tokens[1] << endl;
}
}
nodes.push_back( node );
} else if ( tokens[0] == "set" ) {
process_set_command( tokens );
} else if ( tokens[0] == "update" ) {
done = true;
} else {
cout << "unknown command = " << cmd << endl;
}
}
#endif
}
Copy permalink