[Rock-dev] TaskInspector influences TaskExecutoin

[Sylvain Joyeux]

When using pull connections, such a problem should not happen. The
only bit missing was to not send notifications (needed for
port-triggered tasks) when they are not needed, but I've seen a pull
request a while ago fixing that

Just had a quick look. A leftover is the call to #state and #states in
http://goo.gl/6Mt0H3 and http://goo.gl/fBXb8n. These are  actually a
port read, so here's one non-pull connection. Given that I know that
your code is usually spamming with state changes, that is definitely
one possible culprit.

You can try the following: get rid of #process_states and define
#on_state_change with
https://gist.github.com/doudou/0ff1b3ac8f2d397c0307. This is
completely untested. You will probably have to define an attr_reader
:state_symbols on Orocos::TaskContext. The documentation says that you
can listen to states by doing obj.state { |s| ... } but I can't see
where this comes from.

Sylvain

PS: The proper fix (that I wanted to implement for a long, long time)
would be to have multiple corba dispatchers. It would allow to isolate
priorities (high RT priority for in-robot com, low non-RT priority for
GUI) and completely isolate different domains in general.

On Tue, Sep 16, 2014 at 5:15 AM, Matthias Goldhoorn
<matthias.goldhoorn at dfki.de> wrote:
> I thougt this was fixed by adding the :pull flag to the connection.
> That the data are activly requested instead pushed from the system.
> I know what you suggest solves, but if the network connection is
> unstable or overloaded i got the same problems again...
>
> ;-(
>
> Matthias
>
>
>
> On 16.09.2014 09:39, Janosch Machowinski wrote:
>> Hey,
>> if I recall it correct, there is one receiver and one
>> sender thread per task, that pulls/pushes the data from/to
>> the connections. (I included orocos-dev to confirm this)
>>
>> In your usecase the cable to the UAV is disconnected,
>> while the task-inspector is connected to the tasks on
>> your system.
>> This means, that all connections to the task-inspector
>> time out, making the sender thread block. Thus you also
>> get no data any more on the 'internal' connections.
>>
>> For your case, it should help to disconnect all task
>> inspectors, before unplugging the Ethernet cable.
>> Greetings
>>       Janosch
>>
>> Am 14.09.2014 um 16:23 schrieb Matthias Goldhoorn:
>>> Hi Dev's
>>> It still seems that the Task Inspector influences the task execution.
>>> I thoug this was fixed by the async api? (and pull?)
>>>
>>> This is a critical bug for us currently...
>>>
>>> Best,
>>> Matthias
>>
>
>
> --
>   --
>   Matthias Goldhoorn
>   Unterwasserrobotik
>
>   Standort Bremen:
>   DFKI GmbH
>   Robotics Innovation Center
>   Robert-Hooke-Straße 5
>   28359 Bremen, Germany
>
>   Phone: +49 (0)421 218-64100
>   Fax:   +49 (0)421 218-64150
>   E-Mail: robotik at dfki.de
>
>   Weitere Informationen: http://www.dfki.de/robotik
>   -----------------------------------------------------------------------
>   Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>   Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>   Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>   (Vorsitzender) Dr. Walter Olthoff
>   Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>   Amtsgericht Kaiserslautern, HRB 2313
>   Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>   USt-Id.Nr.:    DE 148646973
>   Steuernummer:  19/673/0060/3
>   -----------------------------------------------------------------------
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev