Re: [certi-dev] FlightGear simulation latency

[Martin Spott]

Hi Eric,

Eric Noulard wrote:

> By the way, Martin, how do you measure the latency with FilghtGear?

Oh, I'm using a rather simplistic approach by comparing two views on
the same aircraft visually, using outside views and a stopwatch  :-)

To be precise, I'm running two instances planeA and planeB of
FlightGear plus the RTIG on the local host. Now I'm configuring
FlightGear's views in a way that the 'master' instance which is running
planeA internally as well as the 'slave' instance (via HLA) both show
the same view on planeA.

In order to set a visual 'marker', I'm taxiing a Cessna 172 along some
runway and then I'm hitting a key to toggle full brakes - which lets
the Cessna on the 'master' view rotate around its pitch axis (nose
down) instantaneously. As a reference I'm taking the moment when the
nose gear compression has reached its maximum (to allow dead-reckoning
to gain some influence). With the current setup (RPR FOM), the period
from hitting the brakes until the nose gear has reached maximum
compression is large compared to the HLA/MultiPlayer latency. Now I
just have to measure the time until the aircraft on the 'slave' view
fulfills the same movement.

I know, this setup doesn't meet typical requirements for scientific
data aquisition, the method is prone to errors, but the net results are
still pretty good - especially given the alternatives:
1.) Using a simple boolean value as a marker, setting it on the
'master' and measuring the time until the change becomes visible on the
slave would be an option. But this doesn't buy us a lot because it
would circumvent dead-reckoning techniques - which are highly
appreciated.
2.) Using the setup as described above (Cessna taxiing, hitting full
brakes), configuring both master and slave to write pitch values of
planeA out via network socket at a high rate. This would, itself,
induce error due to the fact that writing the data out at a high rate
slows the simulation down to a noticeable extent and therefore doesn't
yield 'better' results compared to the simplistic approach which I'm
currently using ....

Cheers,
        Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------