Closed jschleicher closed 5 years ago
For comparison: A slow normal run gives the following log:
[DEBUG] [1561375790.240632492]: Calling Unhold (Service: /prbt/manipulator_joint_trajectory_controller/unhold)
[DEBUG] [1561375790.242061900]: Calling Recover (Service: /prbt/driver/recover)
[ INFO] [1561375790.242838459]: Recovering XXX
EMCY: 83#0000000000000000
EMCY: 84#0000000000000000
EMCY: 85#0000000000000000
EMCY: 86#0000000000000000
EMCY: 87#0000000000000000
EMCY: 88#0000000000000000
[DEBUG] [1561375793.049824326]: Sending new ROS-message.
Warning: recursive print statement has occurred. Throwing out recursive print.
[ INFO] [1561375793.050019671]: Performing STOP due to STO signal
[DEBUG] [1561375793.050061011]: Calling Hold on controller (Service: /prbt/manipulator_joint_trajectory_controller/hold)
[DEBUG] [1561375793.251132146]: Calling Halt on driver (Service: /prbt/driver/halt)
[ INFO] [1561375793.252249256]: Halting down XXX
Note: The /hold
service call happens < 0.5ms after "Sending new ROS-message".
@jschleicher Thank you for this insight. We'll have to do some research. I don't know if a /recover
call can be aborted.
The recover and halt callbacks are mutually exclusive ...
The recover and halt callbacks are mutually exclusive ...
What are you referring to? Could you add a link? Should we open an issue in upstream ros_canopen?
I don't have a deep understanding of the processes in ros_canopen. At first glance it seems that this callback mainly sets a state in the canopen layer. If this is true I think a solution could be found upstream.
As other approach: Skip /hold
service call, if bRunpermitted already goes to false during /recover
.
Is it also valid to skip the /halt
service call if Runpermitted goes to true during /hold
?
So to recap this happens with: 101 Build 11345 Date:2018-12-17 07:33:065
@jschleicher @martiniil I could really need a statement on the used hardware / software running on this hardware in order to reproduce...
Commit
836eeb30d93de4bd873a61373753bf4e61c163ab
Steps to reproduce
How can the issue/bug be reproduced?
roslaunch prbt_moveit_config moveit_planning_execution.launch sim:=false has_braketest_support:=true has_operation_mode_support:=true pipeline:=pilz_command_planner
Expected behavior
Hold service is called as soon as it is detected via modbus.
Observed behavior
Call of
/hold
and subsequent/halt
service is delayed by more than 50ms.Logfiles
The delay between "Sending new ROS message" and "Performing STOP" is about 68 milliseconds in this log.
The delay triggers bug #93.
Probably the reason is the blocking
/recover
call. Is it possible to abort that or overrule it by a multithreaded/halt
call?