Discussion:
[Rock-dev] TaskInspector influences TaskExecutoin
Matthias Goldhoorn
2014-09-14 14:23:10 UTC
Permalink
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
-----------------------------------------------------------------------
Janosch Machowinski
2014-09-16 07:39:03 UTC
Permalink
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
Post by 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
--
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik

Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengesch?ftstelle:
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Tel.: +49 421 178 45-6614
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: jmachowinski at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
Matthias Goldhoorn
2014-09-16 08:15:23 UTC
Permalink
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
Post by Janosch Machowinski
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
Post by 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
-----------------------------------------------------------------------
Sylvain Joyeux
2014-09-16 11:49:50 UTC
Permalink
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
Post by Matthias Goldhoorn
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
Post by Janosch Machowinski
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
Post by 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
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
Alexander Duda
2014-09-16 12:45:17 UTC
Permalink
Post by 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.
Unfortunately, the real problem is coming from:
https://github.com/rock-core/tools-orocosrb/blob/master/lib/orocos/async/task_context_base.rb#L69

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
Post by Sylvain Joyeux
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
Post by Matthias Goldhoorn
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
Post by Janosch Machowinski
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
Post by 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
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
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140916/537d2195/attachment-0001.htm
Loading...