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 running
> ... I was shocked that it was doing 25hz (or one data output every 40ms
> even though my timer was set to wake up every 33ms.) A 25hz input
> stream combined with a 30hz renderer just can't provide jitter free
> video output, in fact it's pretty horrible.
>
> Upon further investigation I discovered that the underlying linux CPU
> scheduler runs at 100hz (20ms cpu scheduler interrupt rate.) This is
> hard coded into the kernel and at one time represented a good balance
> between not burning too much CPU with excessive context switching, yet
> switching processes often enough so that they didn't become too
> unresponsive.
>
> Apparently the linux timer interrupt system only checks for a timer
> interrupt during a context switch (or every 20ms.) So I requested a
> 33ms wakeup ... after the first 20ms context switch, the timer hadn't
> expired yet, and the system wouldn't check again for another 20ms ... so
> I was getting 40ms interrupt times when I asked for 33ms... Actually
> you get 40ms interrupts if you ask for anything > 20ms or <= 40ms.
> Frustrating! I actually tried playing with the system cpu scheduler
> rate and recompiling my kernel and never got the results I was hoping for.
>
> This message is starting to get a little long and tedious, but my point
> here is that for smooth frame rates: (1) you need to draw the scene at
> a consistant rate (and I mean a consistant frame rate, not a variable
> rate faster than movie frame rates, but that's another tedious
> discussion for another time.) And (2) you need to feed your
> position/orientation updates at that exact same rate (and my example was
> to show why that's not always easy.) :-)
>
> What I ended up doing on the Linux platform was to keep the two
> applications running on the same machine, but communicate between them
> using a named pipe. Each application blocks waiting for input from the
> other side of the pipe, so you aren't held hostage to your OS's CPU
> scheduling/timing interrupt voodoo. FG acts in sort of a "master" or
> "commander" roll. The other application which feeds the data waits for
> a request and immediate responds with the result. This way FG runs
> essentially at full speed and isn't hindered by blocking on the other
> application's output (because even though it does block, it get's a
> reply back immediately to unblock it.) The other application blocks on
> FG's output which means it sit's idle (not burning any CPU) until a
> request/command comes in on the pipe. Of course you have to make sure
> your communication is all sequenced perfectly or you risk a dead lock
> scenario.
>
> Hopefully this message doesn't read too much like a computer science
> operating systems class, but any similarities you do see are
> intentional. :-)
>
> Windows doesn't have a real concept of "pipes" in it's underlying
> kernel, especially "real time" pipes which can't be faked with a
> temporary file, so shared memory is another solution for getting two
> applications to talk to each other. I'm sure that's where the
> "sharemem.dll" comes into play.
>
> Regards,
>
> Curt.
>
> --
> Curtis Olson http://www.flightgear.org/~curt
> HumanFIRST Program http://www.humanfirst.umn.edu/
> FlightGear Project http://www.flightgear.org
> Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
>
>
> _______________________________________________
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
