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, <cas...@mminternet.com> 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 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
> >
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
--
Regards Harry
------------------------------------------------------------------------------
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
