Re: [Flightgear-devel] Heads up: AI/ATC interactions
2011/4/30 Durk Talsma > > > http://www.dropbox.com/gallery/7455889/1/GroundNetVisualizations?h=190860 > > cheers, > Durk > Very impressive! I do some work with marshallers and markings, and it is a dream to see groundnet in FG not only taxidraw. -- --- WBR, Vadym. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Hi All, On 12 Apr 2011, at 23:28, Bertrand Coconnier wrote: >> > > This looks very exciting ! > Just a quick progress report: This morning, I managed to perform my first ATC controlled taxi to the runway at EHAM, including navigating through a number of situations where "my" user controlled aircraft succesfully interacted with the AI system (i.e. me getting hold position instructions due to other aircraft being near, or other aircraft getting hold position instructions because I was near). Although this part of the AI / ATC system is intrinsically non-graphic, I did have some success in piecing together a visualization system that outlines the route that each active AI aircraft is taking. I've put together a quick 'n' dirty gallery with some images. Everything's still in a rather rough shape, and ATC guidance essentially stops right before takeoff, but nevertheless, my progress is a lot quicker than I had anticipated. http://www.dropbox.com/gallery/7455889/1/GroundNetVisualizations?h=190860 cheers, Durk -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Hi, On Thursday, April 14, 2011 06:07:18 cas...@mminternet.com wrote: > Agree with the first part about hacking, but disagree with the second idea > of "cost" > > HLA is a follow-on to DIS and SimNet developed by DARPA and would require > either an extensive rewrite of FG to be HLA (Stanag 4603) > compliant or a wrapper function, In addition, there is a thing called > Run-Time Infrastructure (RTI) that handles the federates interfaces [...] > Maybe something along the lines of an "HLA-lite". From Durk's suggestion, > and the excerpt above it sounds like the multiplayer server might function > in the manner of an RTI for a limited set of object model types ( unless > we want to include submarines, tanks, bad guys, etc, etc... ;-) ) What you cited above is something that an RTI should implement in the end to be maximum scalable. But, you can implement an rti with just fewer of these options working. Much more than the above, the spatial indices implemented in the rti regions will be a huge benefit, since you will only recieve the messages that are relevant near the region of your interrest. Also the way an rti provides time management and time stamped messages, is benefitial. This enables hard syncronized hla federates, exchanging data at relatively high rates with the least possible communication latency. Regarding the ongoing threading discussion and the amount of cores an avarage cpu has today, an rti will provide a way to implement components of the simulation in a single threaded way, living in its own process. This can be done while still having a deterministic and tight coupling with other federates simulating in the same federation. This kind of coupling is required for example for a good simulation of glider towing for example. > However, a quick search indicates there is an open source HLA on > sourceforge License is Apache License V2.0, no idea how that compare to > GPL or LGPL, but might be worth a look-see. Whatever, it is going to take > time and effort (cost) to make FG compliant amd/or turn the multi-player > server into an RTI clone or "play-alike". And perhaps it would add a bit > of formalism to the FG development track. :-) There is also one, at http://developer.berlios.de/projects/openrti/ Which is subject to envolve. But appart from that, the API is standardized by an IEEE standard and used with commertial simulation systems as well. Simgear also already has some rti abstraction library that should help to implement hla federates. Flightgear git already has an alternative multiplayer implementation in place that uses hla. But that is only thought as a proof of concept. The next step is probably to provide a seperate hla federate that runs the ai traffic and feeds that into an rti federation. All I did here started using the above hla implementation. So this one already works for this kind of stuff. So, there is already something in place, and I think that its definitely worth keeping that in mind. Greetings Mathias -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Hi, On Wednesday, April 13, 2011 11:52:30 Durk Talsma wrote: > Oh, and just hitting the "send" button a little too early, I had wanted to > add that Martin Spott pointed me that the possibilities of using the new > HLA layer for this purpose. I'm currently not familiar with HLA myself to > comment on that though, so I'm just passing this on. Ack. That is actually my next thing to try. Currently my time went into a hla/rti that is actually easy to use. Something that in the easiest case is not even noticable that it runs below. So there is some work left on that topic. It took me longer than expected. Actually my personal factor of about 2 for underestimating programming effort showed up again :) Major benefits would be to move the AI code out of the main loop - may be even into a seperate process/thread. Also runnig one instance of tha AI traffic for installations like we used to have at the linux tag booth would be a major advantage there. So, yes, building up something here ... Greetings Mathias -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Thanks for the links Torsten, I need to upgrade from git 2.2 release to current to play with this, I have spend the last few hours since your post digging into HLA. As there is so much on the move here I was unaware of, best for now i confine myself to a routine to parse ads-b data. Harry On Thu, Apr 14, 2011 at 3:38 PM, Torsten Dreyer wrote: > > HLA is a follow-on to DIS and SimNet developed by DARPA and would require > > either an extensive rewrite of FG to be HLA (Stanag 4603) > > compliant or a wrapper function, In addition, there is a thing called > > Run-Time Infrastructure (RTI) that handles the federates interfaces > > Matthias Fröhlich added HLA/RTI support last year in these commits: > > http://gitorious.org/fg/flightgear/commit/70dd6279a742030271b5b0927501f59bc9aecb98 > > http://gitorious.org/fg/simgear/commit/44ff23b227dcc1f3efbd10a4df4d8b723165c11c > > I hope we have some time to test it during this year's LinuxTag... > > Torsten > > > -- > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
> HLA is a follow-on to DIS and SimNet developed by DARPA and would require > either an extensive rewrite of FG to be HLA (Stanag 4603) > compliant or a wrapper function, In addition, there is a thing called > Run-Time Infrastructure (RTI) that handles the federates interfaces Matthias Fröhlich added HLA/RTI support last year in these commits: http://gitorious.org/fg/flightgear/commit/70dd6279a742030271b5b0927501f59bc9aecb98 http://gitorious.org/fg/simgear/commit/44ff23b227dcc1f3efbd10a4df4d8b723165c11c I hope we have some time to test it during this year's LinuxTag... Torsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Unfortunately introducing real world AI is not only awkward from the maintainability with different sources point of view. Its best kept as separate from FG as possible in my view. It clashes with scheduled AI aircraft, in that they can appear twice and cant do as good a job in the sim environment as the existing scheduled AI, in that the updates are to slow and must be interpolated to generate a smooth stream, and more so the coverage is not complete. Here the ADSB is 50 feet up the mast and only 7KM from the airport but still only gets reliable signal for aircraft at about 100 feet above the runway. The AIS receiver has the same problem in that when following the main route through the straits here ships are lost for a while when passing behind an island. I share my AIS and ADSB data with aishub and adsbhub and in return receive all data they collect, I see the same problems in EU data, EHAM for instance is the same as here in Bali, aeroplanes drop off the stream once they are on final into Schipol and just "appear" shortly after take off. I did see a project using aishub data to feed one of the MSFS variants, so i guess they would allow us to use it in the same way. I know as long as I feed my of air stream I am free to do what ever i want with the data aishub send me. In short it sounds great but it gets rather messy and complex very quickly. And there can be a lot of data to sort and filter out only what raw data is needing to be processed before display. Previously Durk mentioned in a post (18 months ago maybe) his thoughts of running the AI as a separate process, from this I had a tinker with the multiplayer code. In my case the master machine does not generate the window views. I found by adding a routine to echo the data received from the MP server to the slaves, It worked fine, one data stream to the MP server, only one instance on the MP server from me, and MP aircraft all appeared on the slaves. Recently I decided to go further with the ADSB data based on the MP server code by Oliver to do the job but have put it aside as it compiles on my old Suse 11.1 machine but not the new Ubuntu 10.4 installations. A picky new complier i think but I don't understand it well enough to sort it out. Now I am not a programmer of any kind and thus really cant assist those who are, I cant offer comment on HLA and how to implement things, I would only put forward that if the AI is merely socketed to slave machines, those who want to do more, can do their own thing with an external process using the socket IO. Or preferably work in together and produce a FG util to do the job. The external process would be the place to sift the combined data, then apply HLA or similar to generate just those targets required to feed to FG. I think, from the FG coding perspective, no more than options along the lines of generate AI to socket only, generate and display AI and display external AI from socket, is more than adequate for multi pc display setups and feeding in external sources without any hacking. I don't know enough about the options but would the existing multiplayer format be the one to use? Harry On Thu, Apr 14, 2011 at 11:07 AM, wrote: > > Harry Campigli wrote: > > > >> I also have a sim built of multiple machines and would add support to > Johns > >> comments about a socket to feed or maybe even just sync AI to other > machines. > > > > >> The other consideration possibility is allowing for a mechanism in > future > >> feeding external live AI sources, for instance I have an adsb receiver > and > >> would like to fit in real world air traffic from the receiver data > stream, > >> supported with the local off air comms. > > > > As mentioned above, feeding aircraft, ships, railways and whatever else > from various sources will render the system unmaintainable (at least in > the long run) if clear abstraction layers are not being considered and > it also won't facilitate the task of interfacing FlightGear to other sim > networks in the future. > > > > I've been mentioning HLA because it's the tool precisely made for this > sort of interfacing complex simulation setups together. It provides > nifty features like, just one prominent example, time-stamping (or time > management in general): Pre-calculate the route of an aircraft carrier, > feed it to multiple sims in advance and the ship will show up on every > of the participating machines exactly at the desired position exactly in > the desired moment. > > This is not a feature to be hacked into FG as an add-on, no, HLA is > bringing this to you at no additional cost. Think of the same for AI > aircraft or cloud positions. > > > > Agree with the first part about hacking, but disagree with the second idea > of "cost" > > HLA is a follow-on to DIS and SimNet developed by DARPA and would require > either an extensive rewrite of FG to be HLA (Stanag 4603) > compliant or a wrapper function, In addition, there is a thing called > Run-Time Infrastruct
Re: [Flightgear-devel] Heads up: AI/ATC interactions
cas...@mminternet.com wrote: > However, a quick search indicates there is an open source HLA on sourceforge > License is Apache License V2.0, no idea how that compare to GPL or LGPL, > but might be worth a look-see. Whatever, it is going to take time and > effort (cost) to make FG compliant [...] Apparently your quick search was a little bit _too_ quick to catch what's already in place at FlightGear, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
> Harry Campigli wrote: > >> I also have a sim built of multiple machines and would add support to Johns >> comments about a socket to feed or maybe even just sync AI to other machines. > >> The other consideration possibility is allowing for a mechanism in future >> feeding external live AI sources, for instance I have an adsb receiver and >> would like to fit in real world air traffic from the receiver data stream, >> supported with the local off air comms. > > As mentioned above, feeding aircraft, ships, railways and whatever else from various sources will render the system unmaintainable (at least in the long run) if clear abstraction layers are not being considered and it also won't facilitate the task of interfacing FlightGear to other sim networks in the future. > > I've been mentioning HLA because it's the tool precisely made for this sort of interfacing complex simulation setups together. It provides nifty features like, just one prominent example, time-stamping (or time management in general): Pre-calculate the route of an aircraft carrier, feed it to multiple sims in advance and the ship will show up on every of the participating machines exactly at the desired position exactly in the desired moment. > This is not a feature to be hacked into FG as an add-on, no, HLA is bringing this to you at no additional cost. Think of the same for AI aircraft or cloud positions. > Agree with the first part about hacking, but disagree with the second idea of "cost" HLA is a follow-on to DIS and SimNet developed by DARPA and would require either an extensive rewrite of FG to be HLA (Stanag 4603) compliant or a wrapper function, In addition, there is a thing called Run-Time Infrastructure (RTI) that handles the federates interfaces Excerpt from an old MIT/Mitre paper on the topic: 4.2.2 RTI Transportation Requirements One design goal for the RTI is for the implementation to be independent of communication infrastructure. While the initial implementation is focussed on supporting an IP-multicast network environment, it is clear that as the RTI matures it should support other environments. Two such environments to consider are ATM (without IP) and shared (or reflective) memory systems. ATM is a rapidly maturing technology that can provide high bandwidth, but presents a very different notion of multicast than IP. Shared memory systems can achieve very high effective bandwidth between tightly coupled systems, but limits the geographic range that such a system can span. To address these example communication systems, and to enable the exploitation of other systems, the RTI depends upon an abstraction of "distributed simulation services." These services include: * Best-effort point-to-point messaging. [e.g., UDP/IP]. * Best-effort point-to-multipoint messaging. [e.g., UDP/IP]. * Reliable point-to-point messaging. Message service built on [e.g., TCP/IP]. * Reliable point-to-multipoint messaging. [RMP] * Reliable point-to-point stream. [e.g., TCP/IP]. * Fragmentation/reassembly of large messages. [e.g., >65k bytes] * Get number of multicast groups available. * Join a multicast group. * Leave a multicast group. * Resource reservation. [e.g., RSVP API.] * Scope. Specify the extent of distribution of a message. [e.g., IP time-to-live] * Priority. Set priority for message delivery. [e.g., ATM cell priority] * Map name to address. > I think it's worth to keep this in mind, > Maybe something along the lines of an "HLA-lite". From Durk's suggestion, and the excerpt above it sounds like the multiplayer server might function in the manner of an RTI for a limited set of object model types ( unless we want to include submarines, tanks, bad guys, etc, etc... ;-) ) However, a quick search indicates there is an open source HLA on sourceforge License is Apache License V2.0, no idea how that compare to GPL or LGPL, but might be worth a look-see. Whatever, it is going to take time and effort (cost) to make FG compliant amd/or turn the multi-player server into an RTI clone or "play-alike". And perhaps it would add a bit of formalism to the FG development track. :-) John > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > > -- Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel >
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Harry Campigli wrote: > I also have a sim built of multiple machines and would add support to Johns > comments about a socket to feed or maybe even just sync AI to other > machines. Folks, just from a design point of view: The more custom shortcut's are being added now, the more burdensome it will become later to add more versatility to the overall infrastructure for keeping either more viz machines or more and different feeds (see below) in sync. Obviously this is not my own finding, it's general knowledge and has been proven in many, many design excercises. > The other consideration possibility is allowing for a mechanism in future > feeding external live AI sources, for instance I have an adsb receiver and > would like to fit in real world air traffic from the receiver data stream, > supported with the local off air comms. As mentioned above, feeding aircraft, ships, railways and whatever else from various sources will render the system unmaintainable (at least in the long run) if clear abstraction layers are not being considered and it also won't facilitate the task of interfacing FlightGear to other sim networks in the future. I've been mentioning HLA because it's the tool precisely made for this sort of interfacing complex simulation setups together. It provides nifty features like, just one prominent example, time-stamping (or time management in general): Pre-calculate the route of an aircraft carrier, feed it to multiple sims in advance and the ship will show up on every of the participating machines exactly at the desired position exactly in the desired moment. This is not a feature to be hacked into FG as an add-on, no, HLA is bringing this to you at no additional cost. Think of the same for AI aircraft or cloud positions. I think it's worth to keep this in mind, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Hi Durk, I also have a sim built of multiple machines and would add support to Johns comments about a socket to feed or maybe even just sync AI to other machines. The other consideration possibility is allowing for a mechanism in future feeding external live AI sources, for instance I have an adsb receiver and would like to fit in real world air traffic from the receiver data stream, supported with the local off air comms. I did butcher together a module to feed AI to multiple machines a year or two ago but found it ground to a halt with busy airports like EHAM. Regards Harry On Wed, Apr 13, 2011 at 4:52 PM, Durk Talsma wrote: > > On 12 Apr 2011, at 23:58, cas...@mminternet.com wrote: > > > Hi Durk, > > > > Just a thought... > > > > Is it possible to design/redesign the AI stuff so that it propogates > > across multiple computers or cores via some IPC process -- most likely > > sockets. Shared memory would be ideal, but not sure how MS or Mac would > > handle that. > > > > Oh, and just hitting the "send" button a little too early, I had wanted to > add that Martin Spott pointed me that the possibilities of using the new HLA > layer for this purpose. I'm currently not familiar with HLA myself to > comment on that though, so I'm just passing this on. > > Cheers, > Durk > > > > -- > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
On 12 Apr 2011, at 23:58, cas...@mminternet.com wrote: > Hi Durk, > > Just a thought... > > Is it possible to design/redesign the AI stuff so that it propogates > across multiple computers or cores via some IPC process -- most likely > sockets. Shared memory would be ideal, but not sure how MS or Mac would > handle that. > Oh, and just hitting the "send" button a little too early, I had wanted to add that Martin Spott pointed me that the possibilities of using the new HLA layer for this purpose. I'm currently not familiar with HLA myself to comment on that though, so I'm just passing this on. Cheers, Durk -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Hi John, On 12 Apr 2011, at 23:58, cas...@mminternet.com wrote: > Hi Durk, > > Just a thought... > > Is it possible to design/redesign the AI stuff so that it propogates > across multiple computers or cores via some IPC process -- most likely > sockets. Shared memory would be ideal, but not sure how MS or Mac would > handle that. > As far as I can tell, the infrastructure is almost in place to do so. Considering that the multiplayer system is based on the AIModels system, it should be possible (with a few code modifications). So, the way you could set this up would be to run a multiplayer server locally, and configure all your FlightGear computers with multiplayer enabled and the traffic manager disabled. Make sure that all these machines are setup to communicate with the local multiplayer server. Next (and this step still requires a code modification of the AIModels C++ code), enable AIModels and the traffic manager to run on one master machine (most likely the same computer that also runs the FDM, and handles user input. The only thing that not in place yet is that the regular AIAircraft are exposed to the multiplayer system. I haven't gotten around to do this yet, but my guess is that this should be fairly easy to achieve, since (as mentioned above) both the Multiplayer system is based on the AIModels infrastructure. I would be very happy to dive into this at a later stage (after getting the basics for the AI/ATC system going). If you would like to play with this, I'd be happy to assist though. Cheers, Durk -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Hi Durk, Just a thought... Is it possible to design/redesign the AI stuff so that it propogates across multiple computers or cores via some IPC process -- most likely sockets. Shared memory would be ideal, but not sure how MS or Mac would handle that. On my 747, running with a quad core I5 machine. With a master and two slaves and dedicated graphics boards for each core and using the local loopback address 127.0.0.1 to connect master and slave FDMs, the frame rate is over 60fps with all the bells and whistles turned on. The down side is none of the features such as 3D clouds, AI traffic, are sync'd between the master and slaves. (or am I missing something?) Run everything from a single core with multiple cameras to keep in sync and the frame rate drops to around 27-28 fps. My wish list would be the ability to run something like the AI traffic and manager as either an integral part of the FG binary or as a seperate app similar to the JSBSim implementation with the additional caveat of providing the master and each slave the ability to receive AI updates via a socket and port. That would provide the option to run on a single core machine or take advantage of multi-core architectures. If that seems like a good idea and feasible more than willing to pitch in and help develop the code. Regards John > > after a slightly longer than expected break from FlightGear, I started > picking up coding again about a week or two ago. I am currently working > integrating the AIModels based traffic system with an ATC system in which > the user can also participate. It's going to be similar to the system that > David Luff has been working on for a long time, and is basically intended > to be a replacement of his AI/ATC code (in mutual agreement with David). > In some respects it's also similar to the "ATC" system from FS2004. But, I > will follow my own intuitions in implementing this system. The last > weeks, I've been mainly working on getting reaquainted with the inner > workings of FlightGear. Most specifically, finding out how the AI system > actually worked and finding out how to read a keyboard command from a GUI > dialog box. > > Today, I had my first minor success by managing to let my own aircraft > request permission for engine startup while parked at the B terminal at > EHAM. I managed to re-use a lot of classes that were originally designed > for AI use, and today's engine startup clearance was still accomplished > through the AI system. (i.e., it was my AI copilot doing the talking. When > it comes to user interactions, the next logical move will obviously be to > block ATC transmissions that are initiated by the AI co-pilot, although it > might be interesting to keep this as an option (see below). I still need > to look at the details, but this should be quite doable. > > As a slightly unexpected bonus, today I realized that I can use all the > relevant classes from the AIModels and traffic manager system here and set > them up to reflect the user's aircraft in the AI world, without actually > interfering with the AIModels and traffic manager subsystems. In doing so, > I realize that there are some interesting future possibilities: > > 1) Let the AI system create a flight plan for the user aircraft and use > this flightplan eiter for VFR or IFR flight planning > 2) Let the ATC system handle the comm radio and let it serve as a virtual > co-pilot. > 3) Build a simple light-weight flight planner into FlightGear > 4) Possibly a lot more that I haven't even thought of > >>From this initial success, it's probably still going to take a long road >> before I have a fully fully functional system up and running, so it may >> take a while before I will commit this to get. Nevertheless, I just >> wanted share this minor triumph with you all and to give a quick heads up >> with respect to my current flightgear whereabouts. > > Cheers, > Durk > > -- > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and > vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___
Re: [Flightgear-devel] Heads up: AI/ATC interactions
2011/4/12 Durk Talsma : > Hi All, > > after a slightly longer than expected break from FlightGear, I started > picking up coding again about a week or two ago. I am currently working > integrating the AIModels based traffic system with an ATC system in which the > user can also participate. It's going to be similar to the system that David > Luff has been working on for a long time, and is basically intended to be a > replacement of his AI/ATC code (in mutual agreement with David). In some > respects it's also similar to the "ATC" system from FS2004. But, I will > follow my own intuitions in implementing this system. The last weeks, I've > been mainly working on getting reaquainted with the inner workings of > FlightGear. Most specifically, finding out how the AI system actually worked > and finding out how to read a keyboard command from a GUI dialog box. > > Today, I had my first minor success by managing to let my own aircraft > request permission for engine startup while parked at the B terminal at EHAM. > I managed to re-use a lot of classes that were originally designed for AI > use, and today's engine startup clearance was still accomplished through the > AI system. (i.e., it was my AI copilot doing the talking. When it comes to > user interactions, the next logical move will obviously be to block ATC > transmissions that are initiated by the AI co-pilot, although it might be > interesting to keep this as an option (see below). I still need to look at > the details, but this should be quite doable. > > As a slightly unexpected bonus, today I realized that I can use all the > relevant classes from the AIModels and traffic manager system here and set > them up to reflect the user's aircraft in the AI world, without actually > interfering with the AIModels and traffic manager subsystems. In doing so, I > realize that there are some interesting future possibilities: > > 1) Let the AI system create a flight plan for the user aircraft and use this > flightplan eiter for VFR or IFR flight planning > 2) Let the ATC system handle the comm radio and let it serve as a virtual > co-pilot. > 3) Build a simple light-weight flight planner into FlightGear > 4) Possibly a lot more that I haven't even thought of > > >From this initial success, it's probably still going to take a long road > >before I have a fully fully functional system up and running, so it may take > >a while before I will commit this to get. Nevertheless, I just wanted share > >this minor triumph with you all and to give a quick heads up with respect to > >my current flightgear whereabouts. > > Cheers, > Durk > This looks very exciting ! Bertrand. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Heads up: AI/ATC interactions
Hi All, after a slightly longer than expected break from FlightGear, I started picking up coding again about a week or two ago. I am currently working integrating the AIModels based traffic system with an ATC system in which the user can also participate. It's going to be similar to the system that David Luff has been working on for a long time, and is basically intended to be a replacement of his AI/ATC code (in mutual agreement with David). In some respects it's also similar to the "ATC" system from FS2004. But, I will follow my own intuitions in implementing this system. The last weeks, I've been mainly working on getting reaquainted with the inner workings of FlightGear. Most specifically, finding out how the AI system actually worked and finding out how to read a keyboard command from a GUI dialog box. Today, I had my first minor success by managing to let my own aircraft request permission for engine startup while parked at the B terminal at EHAM. I managed to re-use a lot of classes that were originally designed for AI use, and today's engine startup clearance was still accomplished through the AI system. (i.e., it was my AI copilot doing the talking. When it comes to user interactions, the next logical move will obviously be to block ATC transmissions that are initiated by the AI co-pilot, although it might be interesting to keep this as an option (see below). I still need to look at the details, but this should be quite doable. As a slightly unexpected bonus, today I realized that I can use all the relevant classes from the AIModels and traffic manager system here and set them up to reflect the user's aircraft in the AI world, without actually interfering with the AIModels and traffic manager subsystems. In doing so, I realize that there are some interesting future possibilities: 1) Let the AI system create a flight plan for the user aircraft and use this flightplan eiter for VFR or IFR flight planning 2) Let the ATC system handle the comm radio and let it serve as a virtual co-pilot. 3) Build a simple light-weight flight planner into FlightGear 4) Possibly a lot more that I haven't even thought of >From this initial success, it's probably still going to take a long road >before I have a fully fully functional system up and running, so it may take a >while before I will commit this to get. Nevertheless, I just wanted share this >minor triumph with you all and to give a quick heads up with respect to my >current flightgear whereabouts. Cheers, Durk -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
