[Rock-dev] TaskInspector influences TaskExecutoin

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

[Rock-dev] TaskInspector influences TaskExecutoin

On 16.09.2014 13:49, Sylvain Joyeux wrote:
> 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.
Unfortunately, the real problem is coming from:
https://github.com/rock-core/tools-orocosrb/blob/master/lib/orocos/async...

Here, the worker thread is triggering "states" every second. A
workaround would be to remove this peace from the watch_dog and use
Sylvain suggestion.

Greets
Alex

>
> 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 [dot] goldhoorn [..] ...> 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 [..] ...
>>
>> 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 [..] ...
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
> _______________________________________________
> Rock-dev mailing list
> Rock-dev [..] ...
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

[Rock-dev] TaskInspector influences TaskExecutoin

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
>

[Rock-dev] TaskInspector influences TaskExecutoin

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 [dot] goldhoorn [..] ...> 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 [..] ...
>
> 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 [..] ...
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev