[Flightgear-devel] Re: Bypass FG Physics and Draw
Does this mean that we would have the ability to save and load flight data so as to reproduce, say, a taxi, take off, pattern and landing at KSFO or another airport automatically (i.e., as a demo or as a training exercise). Perhaps a short flight around the SF area also showing off the new scenery? Could we ship such flights around scenic areas (Mount Ranier, Crater Lake, the Grand Canyon) for new users in the base package or as downloadables off of flightgear.org? How big would such files be? How much data needs to be kept, how much can be calculated on the fly? Do weather conditions need to be saved also? Would flights around scenic areas be done better as flight plans with waypoints or tied into this new playback method somehow? Can this playback tool be used as a training method for new simulator pilots? If we are not saving a real recorded flight, perhaps we can use a similar method to extract either entire flights or the last XX number of seconds of a flight to save to disk for later replay? MS FlightSimulator has an extensive tutorial that involves pre-saved flights which the users can break into at certain points in the flights. How difficult would it be to add something similar to FG and where would one begin (if no one is already working on something like this). Thanks! Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Bypass FG Physics and Draw PicturesfromReal Data?
I wish I could be software skilled enought to run the Synthetic Primary
Flight Gear Display on a Linux Plateform. Because to be honest, I'm not very
proud to board a High Quality 3D Synthetic Primary Flight Display on windows
system :-( So, I keep Curt's explaination in a safe place.
David Calkins Program's can be found under CVS source\examples\netfdm. I
think it should macth you need pretty well, with some adaptation (data
reading from a file needs to be implemented).
Attitude provider : I was thinking to a cheap MEM's IMU. As it's still $2k
or so, I will use my in live GPS data output to guess the A/C attitude. Up
to now, my algorithm gives pretty good results for 4Hz GPS output data
stream. Unfortunately, my GPS output is only 1 Hz and it gives poor results,
so I guess I have to work a little bit more on the algo.
Attitude, Altitude and Position data are sent to Flight Gear using the
SharedMem.dll. A friend wrote me this peace of code. From, what I
understood the ShareMem.dll is loaded in memory and used by both FG and my
{Attitude, Altitude and Position} feeder program. Then, I use two
functions, one that writes in the ShareMem.dll (the feeder program), the
orther which reads data from it (FG). I think the Linux equivalent has been
deeply explained by Curt ;-)
All GPS/IMU data can, for sure, be recorded in a file for later playback on
Flight Gear. I've not implemented it, but I think it could be done easely
(and quickly by a software skilled person ;-)
- Original Message -
From: Curtis L. Olson [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Monday, August 23, 2004 4:25 AM
Subject: Re: [Flightgear-devel] Re: Bypass FG Physics and Draw
PicturesfromReal Data?
Matthew Churchill wrote:
this is exciting, this sounds close to providing the ability to playback
real flights that I'm looking for to go with the flight recorder I'm
attempting to make.
please excuse the deluge of questions.
what is david calkins program ?
what kind of device is an attitude provider ? and what format is the data
provided to flightgear in ?
can attitude data be stored in a file ?
what is the sharemem.dll ? and what is the linux equivalent ?
has anyone got a sample of this combined attitude and position data ?
I'd love to try this out
It should be pretty straightforward to use FG to playback a real
flight. With FG you can slave multiple instances to one master instance
of FG in real time. Slaving a copy of FG to a recorded data stream
should be also very similar.
For anyone trying to sync multiple copies of flightgear and get silky
smooth frame rates, or anyone trying to get silky smooth frame rates in
a single copy of FG the following is some important information I
learned the hard way...
If you want smooth rendering, you need to do a couple things. First,
make sure that your copy of FG can render a sustained consistant frame
rate. One *good* option is to sync to the vertical refresh signal on
your monitor. With linux/nvidia there is an environemental variable you
need to set to activate this feature (see readme that comes with the
driver.) For other cards or platforms, there may be some different
mechanism. Secondly, there is a tool that FG gives you to throttle
frame rates to a maximum value. Set the property
/sim/frame-rate-throttle to some value that is a multiple of your
monitor's refresh rate, but is fast enough for your machine to keep up
with consistently. From the command line or your ~/.fgfsrc you could do
this:
--prop:/sim/frame-rate-throttle-hz=30
Just to convince yourself this is working, you might want to try
something like:
--prop:/sim/frame-rate-throttle-hz=5
This will limit your maximum frame rate to the specified hertz (if your
machine can go that fast.) The internal FG mechanism to do this is a
simple busy/wait loop so you don't gain any CPU cycles with this, but
you do get pretty accurate timing.
Getting the rendering speed consistent is one side of the coin. The
other is that you need to feed the data input stream at the same
consistent rate. This can be hard to control if you are communicating
over the network.
Consider this: here in the USA our monitors really like to run at 60 hz
(or 72 or 75.) I usually run them at 60hz because that's easier to keep
up with for FG rendering. For one particular example, I was stepping FG
down to 30hz. I was trying to feed FG from another application running
on the same machine. This was a really low cpu-usage process so I was
using timer interrupts to wakeup every 33ms and send the data over the
network. I was about to congratulate myself on my own cleverness, but I
was continually nagged by much choppier rendering than I thought I
should be seeing. Something wasn't right. It just so happened that
someone had an oscilliscope they could connect in to one of the
interfaces and see exactly how fast my data feeding program was
[Flightgear-devel] Back online
Hi, everyone -- I'm back from a flying family vacation to Nova Scotia (13.8 hours flight time, including taxiing). It doesn't look like too much happened over the past week while I was gone, but if I missed anything directed at me in my quick scan of my inbox, please feel free to repost. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] STL string and lowercase
Does anyone know a good algorithm to take an STL string to lower case? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] STL string and lowercase
Jon Berndt writes:
Does anyone know a good algorithm to take an STL string to lower case?
**untested**
char *strlwr (char * a)
{
char *ret = a;
while (*a != '\0')
{
if (isupper (*a))
*a = tolower (*a);
++a;
}
return ret;
}
my_str = strlwr(my_str.c_str());
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] STL string and lowercase
On Mon, 23 Aug 2004 20:20:25 -0500, Jon wrote in message [EMAIL PROTECTED]: Does anyone know a good algorithm to take an STL string to lower case? ..' tolower '? Looks like a C type thing to me. There's also ' tr ', is possibly ported to Wintendo or useable thru Cygwin or somesuch. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] STL string and lowercase
Jon Berndt writes: Does anyone know a good algorithm to take an STL string to lower case? **untested** Thanks, Norman: I finally got some time to look around. I found this web page, http://www.msoe.edu/eecs/cese/resources/stl/string.htm with this text: transform: This STL algorithm (from the algorithm library) is a little tricky, but simple uses are easy. For example, we can iterate through the characters in a string, modifying them in some way, and returning the modified characters back to their original positions. In this case, we set the result iterator to specify the beginning of the string. A common application is to convert a string to upper or lower case. string str22 = This IS a MiXed CaSE stRINg; transform (str22.begin(),str22.end(), str22.begin(), tolower); cout [ str22 ] endl; // the output is: [this is a mixed case string] Note that the result iterator must specify a destination that is large enough to accept all the modified values; here it is not a problem, since we're putting them back in the same positions. The tolower function (along with toupper, isdigit, and other useful stuff) is in the cctype library; for more general case conversions, take a look at the locale library, which is beyond the scope of the present discussion. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
