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
