High Level Architecture Interface for Orbiter

[tappm]

Hi,

I've posted an extension request to connect Orbiter on HLA (High Level Architecture) here. It would be most interesting to understand how we could connect the Orbiter Multiplayer Project to HLA. Any insights or volunteers to describe what it implies. Think that the result of this work is going to be used for the SISO Smackdown which is sponsored by NASA.

Thanks,

Martin

 

[Face]

I've skimmed the documents behind HLA, and the complexity is way beyond what I'm willing to invest.

If you could break it down to:

1. what minimal interface is to be implemented,
2. where I can get the appropriate library binaries, and
3. how I can test the result,

I can take another look. ATM I'd just be lost in all those TLAs and government specification speak.

OTOH, OMP is open source, so everybody can do a check if interested.

regards,
Face

 

[tappm]

Hi,

thanks for the feedback. To answer your questions:
1) Basically you do pub/sub on objects and interactions. Objects are instances of a specific object class which get registered/discovered, updated and unregistered. Interactions are pin-point events.
2) Now the Pitch RTI is available here.
3) I've attached an analysis made by Daniel O'Neil from NASA

Here's info I got from Dan who is experimenting with HLA and Orbiter:


After some experimentation, this past Monday, I concluded that threading might not be the best approach.

Shared Memory, might be the better way to develop the interface. The following link leads to an example provided by Microsoft. The example has two processes that can be compiled separately. If both files reference the same file object then the second process receives a message from the first process.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx

Vessel modules for Orbiter compile to a Dynamic Link Library (*.dll), the following Microsoft article explains how to use Shared Memory with a DLL. http://msdn.microsoft.com/en-us/library/windows/desktop/ms686958(v=vs.85).aspx

Using the free Pitch RTI, the development process would be:
• InitModule within a vessel module map to a file object
• A clbkPreStep method receives messages from the C++ Chat federate provided with the free Pitch RTI
• A clbkPostStep method sends messages from Orbiter 2010P1 to the C++ Chat federate
• A modied C++ Chat federate includes the shared memory code
• Testing involves running Orbiter, pRTI, the modified Chat, and another Chat federate
If successful, the second chat federate ought to receive messages from Orbiter via the modified chat federat.


As new info comes out, I'll post it.

Thanks,

Martin

 

[Face]

Well, I've checked the pRTI license agreement, and I'm afraid that I do not agree with it, therefore I'll not incorporate it into OMP. Is there any open-source RTI available?

I also don't get what threading has to do with inter-process communication (shared memory) in this regards. In both cases, though, you'd have to implement a kind of signaling.

I still don't know what that HLA_interface class looks like. Is it in the closed-source pRTI package? Can I get it without agreeing to a restricting license agreement?

As I see it, OMP is already similar to the RTI infrastructure. The server is the RTI implementation, the clients are the federates. OMP clients maintain snapshots of the current simulation state of objects, and send them via a network protocol to the server, who distributes the information accordingly, and even creates peer-to-peer communication among clients to lower packet latency.

I really don't see where OMP can benefit from a different exchange protocol, especially as I think that HLA is a bit - please excuse the term - over-engineered. Maybe it is better to simply develop a dedicated HLA client instead.

That said, you are of course free to get your hands dirty with OMP code, but please be aware that it is GPL.