certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] Unable to create RTI ambassador


From: Jan-Patrick Osterloh
Subject: Re: [certi-dev] Unable to create RTI ambassador
Date: Wed, 31 Aug 2011 17:06:12 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12

Am 31.08.2011 14:59, schrieb Eric Noulard:
> 2011/8/31 Jan-Patrick Osterloh <address@hidden>:
>>> Ok, I would be interested in knowing more about that, would you be able
>>> to publish some code (and may be some doc :-] ) concerning this work?
>> Yes, this should be possible. In short:
>> We are currently using two different HLA implementations. We started
>> with Pitch RTI, and are now going to use CERTI, because we can't force
>> our research partners to use a commercial RTI.
> This is a common issue we are well aware of...

;-)

>> We will use CERTI in the
>> D3CoS Project (www.d3cos.eu) for implementing a multi-agent simulation
>> platform. Therefore we will connect the cognitive architecture CASCaS
>> (as human agents) to different simulations (xplane, matlab). My main
>> work will be on simulation control, i.e. I will develop a framework to
>> define and run the simulation. We already connected successfully CASCaS
>> to CERTI (I have two instances of CASCaS exchanging information): As
>> CASCaS is implemented in C we needed a wrapper, which allows connection
>> to the C++ Part via a simple interface. This wrapper currently works for
>> PITCH and CERTI, so that we can share as much code as possible.
>> Especially the internal data management (we did not hard-code the SOM in
>> the Federate) is shared.
> Interesting, may be we could define some unofficial C API binding for
> an HLA subset.
> With CERTI we already have Python, Matlab and Fortan90, adding C may be nice.

This would be indeed very nice, but we are currently far away from such
an API. But it could be worth to think about something like this.


>>>> In the process explorer I can see, that the RTIA is started up, but then
>>>> it is exits very quickly again. But I think too, that it could be
>>>> something in the path. I tested to put rtia and associated libs to
>>>> different paths, but without success.
>>> If RTIA is starting and dying rapidely may be there could be a DLL issue?
>>> RTIA depends on severals DLL.
>>>
>>> If you installed several version of CERTI (or other RTI) be sure that you 
>>> don't
>>> have DLL version mismatch.
>> I have only one RTIA and version of CERTI installed. I used the
>> Dependency Walker to check which DLLs are loaded by our wrapper, and
>> they are the same for CASCaS as well as for xplane. The Paths are also
>> the same.
> Is the XPlane/HLA plugin multithreaded ?

Yes, we start an update thread in the reflectAttribute callbacks in
order to fasten callback delivery. But up to the point where the
exception occurs, the wrapper it is single threaded. I know that xplane
is starting multiple threads at startup (I started xplane in gdb. I
assume that in one of this threads the plugin is started (also it is
stated in the xplane documentation, that long runs of the callbacks
should be avoided, because this would slow down the framerate of xplane
too. Threfore I assumed that the plugin runs in the same thread as xplane.

> Currently libRTI is not thread-safe so that you should serialize the
> call to libRTI
> from a possible multithreaded app.

We added semaphores in our multi-threaded parts. Our CASCaS Federate is
multi-threaded, and there it works well. But at the point of exception,
no multi-threading should be active.


> Could you try to setup
>
> RTI_EXCEPTION=X
> and
> CERTI_EXCEPTION=X in order to see if any exceptoin is raised before RTIA dies?
>
> You may try to monitor message exchange using:
> RTIA_MSG=D
> and
> RTIG_MSG=D
>
> that way CERTI will trace the message (sent or received) between
> Federate and RTIA (RTIA_MSG)
> and RTIG and RTIA (RTIG_MSG).

I set these, and I get the following now, when I start xplane:

UN Socket(RecevoirUN) : : No error
HLALOG - 1314800573.328 LibRTI::UnjoinedFederate -
d:/home/patrick/eclipse/certi/certi/libCERTI/Exception.cc>
CERTI::Exception [NetworkError - reason=Error while receiving UN message.
libRTI: exception: NetworkError (read)
UN Socket(EmettreUN) : : No error
HLALOG - 1314800573.328 LibRTI::UnjoinedFederate -
d:/home/patrick/eclipse/certi/certi/libCERTI/Exception.cc>
CERTI::Exception [NetworkError - reason=Error while sending UN message.
libRTI: exception: NetworkError (write)
libRTI: Could not execute 'Close connexion' service (Network error).
Service request ignored.

ERROR: Unable to create RTI ambassador: 'libRTI: Network Read Error
waiting RTI reply'


> Did you verify that all the federate which are trying to join the
> federation have unique name?

Yes, it is the only Federate that is connecting to the Federation. I've
not yet tried to start others ;-)


>>> We lack systematic Windows tester, would you be willing to help
>>> us to maintain a clean Windows build?
>> I will ask Christoph which patches are in the version he send me. He
>> send me a version that is able to be compiled on Windows/MinGW, so I
>> guess. I'm not so familiar with Cmake, but I can try.
>> As stated above, I will be using CERTI with Windows in our project, so
>> I've interested in having a usable windows version. I will have to
>> figure out how I could manage testing while maintaining a working
>> version that I can use in the project.
> Our problem here is that we do not use the windows version so much,
> even if we try
> hard to maintain a working Windows version each time we release CERTI.
>
> Nevertheless we usually do many changes between versions so that current
> CVS verison may not work on Windows unless someone compiles it and
> run basic tests (may be our HLA TestsSuite) regularly.
>
> Fixing one regression at a time during development is usually easier
> than waiting
> to fix every breaking change at release time.
>
>
>> I will checkout the latest CSV version and try to compile it, later. I
>> will let you know.
> OK.
>
>>> Check DLLs too.
>> I checked the DLLs, but everything seems OK so far. I can only imagine
>> that xplane is loading some DLLs that interfere with CERTI, but I have
>> no idea how to check this... the dependency walker just shows that
>> xplane.exe uses a subset of the DLLs that the wrapper uses, and these
>> are the same. I tried to copy the CERTI dll's also to different
>> locations (next to xplane.exe, as well as in the plugin directory next
>> to my plugin, but it makes no difference. I'm running out of ideas. If I
>> would know, which DLLs are missing/wrong etc, it would be helpful.
> When you test your XPlane HLA connection are there any other federate
> in the federation?
No, I've got a "fresh", just started RTIG, without any other federates
joined or trying to join.



-- 
Dipl. Inform. Jan-Patrick Osterloh
FuE Bereich Verkehr | R&D Division Transportation
Human Centered Design Group

OFFIS
FuE Bereich Verkehr | R&D Division Transport
Escherweg 2 - 26121 Oldenburg - Germany
Phone/Fax: +49 441 97 22-524/502
E-Mail: address@hidden
URL: http://www.offis.de


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]