On Thursday, December 20, 2012 22:22:19 Clement de l'Hamaide wrote:
> 1 )
> I'm really interested by your work about OpenRTI / HLA. I've added the RTI
> support in the download_and_compile.sh brisa script's in order to make it
> more "user-friendly" to use and participate to the development. I compile
> SG and FG with -DENABLE_RTI=ON since some weeks but today FG compilation
> crashed with this option :/ Here is the compilation log :
> http://pastebin.com/HnPSfyzs
> OpenRTI and SG compilation are fine. I've deleted my OpenRTI/FG/SG build dir
> but the issue still here. Do you have a solution ?
Remind me to look at that past the Christmas days please.

> 2)
> I'd be really happy to use/test HLA unfortunately I haven't found recent
> documentation about it. I know about the wiki page
> http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)
> but this page is not up to date. Looking at your source code it seems that
> --hla=bi,<hz>,<federateType>,<federationName>,<profile> is no longer the
> correct way to activate HLA, but more --hla --federation=???? Are you able
> to tell me/us the current state of your work : Is it currently working ?
> can we test ? how can we test ? what are the possible argument ? what is
> your dev plan (current step, next step) ? Have we need to be connected to
> an HLA server ? Can you explain a litttle bit how it works at architecture
> level ? (Is it a centralized server routing every packet between user ?
> similar to FGMS network ?)
Documentation is flying around a lot. General ones and probably stuff that is 
too far away to be directly useful. Simgears hla classes should abstract us 
away from some of these details. I am not exactly convinced that this library 
is the best design so far, but at least it currently provides something to 
conveniently access that standard apis. And this should shield away the most 
popular problems with high algorithmic complexity. The same goes for the rti 
library below.
I am regularily running with this enabled. Also testing a lot here. Currenty 
cleaning out a lot of proof of concept stuff that lingers around on my local 

You still can use the the --hla= commands, but there is a shortcut --hla-local 
which optimizes away a lot of successive ,,, in the command line that I 
usually had. So, --hla-local=rti://localhost/FlightGear is a shortcut for a 
longer --hla= line.

Steps are currently to clean out my disk and provide what is there.
What will come in the shorter term is a standalone viewer that can sit on any 
of the configured views. There are beginnings of that checked in but there is a 
lot more in preparation.
The fgai is just a brief sketch chat could be done in that corner. It already 
contains most if what is needed in complex infrastructure. You can inject 
vehicles and you can now get ground queries.
I am for a long time running here also a brief python script which does about 
the same than fgai. While a scripting language is not fast enough to drive a 
lot of ai traffic, it is rather nice to do only a few such objects without much 
Whatever happens here, if you are really driving a lot of ai models it 
requires a huge amount of thoughts to get that scalable. Updates to specific 
models as well as specific parts of those need to be updated in an sparse and 
intelligent way to make this somehow work. This includes the basic part of the 
fgai implementation which aims to have steady and differentiable movements. 
This is at this time not made use of so much, but the classes that I called 
something like *Physics* in there are mostly there to make sure that all 
components can see and even extrapolate the same steady movements than the 
originating component does. There is also infrastructure there to play some 
tricks with timing so that nobody needs to wait for ai traffic updates to 
- they should just already be there.
There is also a small gatweay application translating between the old 
multiplayer and hla that might go into the utils directory past the next 

So, I was pushed to put this code in the public, even if I personally think 
that there are still too much opportunities to break stuff. Well, with break I 
do not mean that it does not run or compile. With break I mean that people 
just put something together that works either for their private needs and they 
do not care further, or break in the sense that if you would know the bigger 
picture it would already be very clear that this cannot scale for the kind of 
use that will most probably happen in the not so distant future.
I can really observe this in the scene and model area. I have really seen 
incredibly fast osg applications with stable framerates and nifty looking 
models. But the way we use osg and put together models leaves osg and below 
that the driver only little chance to be fast. Which leaves only little 
headroom for sensible further development.
Getting back to components: Latencies are a critical part of running in 
multiple threads/applications. This is not a particular problem of hla, this 
is a generic problem when running real time applications in parallel. I know a 
lot of really smart people who can even understand complex environments very 
well, but have no clue about the problems introduced by round trips. Seen 
this, this is the reason why I started that hla stuff, since this provides a 
framework which supports and even encourages a programming model that is able 
to hide latencies as good as possible. Anyway, there is a chance that you even 
use this api in a way that really hurts in this corner. And this is actually 
the really bad thing I want to avoid: If you are the first component that does 
not get that right you might just notice little to nothing - especially if you 
are running on extrem fast hardware. But when the next kind of problem is 
introduced this really starts to hurt more and more. And most people do not 
have any chance to see what happens and why.
So please talk to me if you want to extend something there.

> 3)
> I've worked on a project called "FGAIS" who is certainly related to your
> recent "fgai" tools. FGAIS is a modified FGMS server who inject live
> traffic (in real time from real life) into client session. In this way
> clients can see aircrafts in the FG sky like he could see them by his
> windows. For this I've contacted planefinder.net and they agreed to provide
> their data (only ADS-B). The source code is also ready to implement ship
> AI. Currently FGAIS work nice only for 1 client (if a second client come on
> the server I have a SegFault... I don't know why :/ ) You can find the
> source code here : https://gitorious.org/~f-jjth/fgms/f-jjths-fgms-0-x This
> modified FGMS server (called FGAIS project) needs SG. You just need to
> compile it and connect to him with FG client in an active area (LFPO, EDDF,
> KSFO...) and you will see a dozens of aircraft in your "MP list" : it's
> live traffic You are free to use any a part of this project if you are
> interested in it. Some links below :
> Source code : https://gitorious.org/~f-jjth/fgms/f-jjths-fgms-0-x
> Wiki page : http://wiki.flightgear.org/FGAIS
> Forum thread : http://www.flightgear.org/forums/viewtopic.php?f=23&t=17803
> Provider : http://planefinder.net/
> Since FG is now in a frozen state / debug period the 3) is not important for
> now but I'm interested to know your opinion about this project. Talking
> with Hooray on the forum I'm aware that RTI/HLA should be much better for
> this use.
I have not looked into this particular project. The basic idea to have an 
external component that drives ai traffic, or at least a thread that does the 
same is a good one I think.
For the long term I do not care about the multiplayer protocol since it has 
severe limitations that would require a very similar solution that one the 
OpenRTI implementation does. For the short term, I am not sure if we are 
already at the point where I can just switch over. Therefore this bridge 
component bridging the mp protocol with hla.
For the ADS-B traffic, packing this into a module that you can attach to your 
simulation instead of an artificial traffic component is an nice addition. 
people told about flightradar24, this Idea came up pretty fast. But personally 
I probably never do this. Because you can try to interact with those guys, but 
they will never interact with you, which makes you never get a landing slot 
for you simulated aircraft instance on KSFO I think. May be it's nice to 
watch? Instead of TV? ... not seriously :)
The benefit of a more modular approach is what you told also, you can use this 
if you like but you are not required to.

Ok, the mail is aready too long. Sorry about that!

Merry Christmas


LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
Flightgear-devel mailing list

Reply via email to