Hi, 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 disk. 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 worries. 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 arrive - 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 release. 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. Having 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 Mathias ------------------------------------------------------------------------------ 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 http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
