RE: [certi-dev] FlightGear simulation latency

[Gotthard, Petr]

Hi Martin,

I copy-pasted your questions in this single e-mail:

> I suspect that the general technique is to send a packet which
includes
> positional data as well as velocities and forces plus a time stamp and
> to let the reciever extrapolate how the vehicle would move at
timestamp
> + dt. I know, this might fail for aircraft which are turning extremely
> fast, but it might be a reasonable start. If I remember correctly,
even
> the current FlightGear MultiPlayer protocol is using such technique -
> in order to work around network latency and drop-outs. I'm certain
that
> our CERTI folks also have a few comments to add.
> 
> I have to admit that I neither managed to understand where you're
> picking up the positional data of the local instance to be fed into
the
> Federation nor that I understood how you're feeding remote aircraft
> into the local instance. Ok, I didn't try too hard, but I think I'll
> manage to get there.
> Getting faster acces to these resource might help as well and if you
> don't object, I'll get in touch with the respective subsystem
> maintainers and try to direct their toughts to you.

The FlightGear's HLA replaces only the send/receive functions. The
remote HLA aircraft is fed back using the native FGAIMultiplayer class,
which also does a simple dead reckoning as you have mentioned.

The FlightGear's HLA however does not (yet) correctly calculate the
timestamps and packet lag, so the dead reckoning may be degraded. I'll
try to investigate how to do the time-stamping in a HLA/FOM standard
compliant way.

> I just realized that there are a couple of nice papers on adaptive
> dead-reckoning on The Net - this one being an example:
> 
>   http://ducati.doc.ntu.ac.uk/uksim/journal/issue-1/Lee-Turner/B-
> S%20Lee.pdf
> 
> Yet I found very little mentioning of such an approach for HLA - do
HLA
> folks avoid dead-reckoning for design reasons ?

Interesting paper. The described algorithm applies different techniques
and sends different updates to different peer nodes. I think this is not
possible with HLA because the updates are performed by RTI, which knows
nothing about the transmitted values.

> I just found out that using the RPR FOM (--hla=[...],RPR,RPR-FOM-
> v1.0.fed)
> induces just a fraction of the latency compared to using the ASN FOM
> (--hla=[...],ASN,AviationSimNet-v3.1.fed). In consequence, using the
> RPR FOM results in a latency which is similar to that of FlightGear's
> native MultiPlayer protocol.

Brilliant! I tell you why: The RPR FOM has entries for velocity and
acceleration, while the ASN does not. The native dead reckoning
algorithm thus works only for the RPR FOM, what makes the latency
similar to the native MultiPlayer.

It's funny: The RPR FOM has velocity and acceleration values but does
not have flaps, lights or landing gear indication. The ASN has the
indicators, but does not have velocity and acceleration.


Best regards,
Petr