schunk_canopen_driver crashes at startup

Hi,

i am using the schunk_canopen_driver with the schunk_lwa4p robot. I run the standalone_interpolated_position.launch file. Everything works (after some time), BUT I have observed two things, that seem odd to me:

1. When starting the robot, the node throws:

<2016-12-09 17:54:19.291> CanOpen(Info) EMCY::update: Error reset EMCY received. Node 4 is now in state error free. terminate called after throwing an instance of 'icl_hardware::canopen_schunk::DeviceException' what(): ��������t perform fault reset for node 4 after multiple tries. Is the device hard-disabled? Otherwise: Have you tried turning it off and on again? Check your configuration and make sure the device is properly connected. [schunk_canopen_node-1] process has died [pid 14265, exit code -6, cmd /home/marcel/ros/test_ws/devel_isolated/schunk_canopen_driver/lib/schunk_canopen_driver/schunk_canopen_driver_node __name:=schunk_canopen_node __log:=/home/marcel/.ros/log/07d1c7d2-be13-11e6-ad72-001e8c26fa47/schunk_canopen_node-1.log]. log file: /home/marcel/.ros/log/07d1c7d2-be13-11e6-ad72-001e8c26fa47/schunk_canopen_node-1*.log

This is thrown once per node, i.e. in the first run, it is thrown for node 3, second node 4, ...., which means, i have to rerun the script once per node. This occurs on every startup, i.e. when start the robot (not the node).

1. After the first thing occured and the node now may start flawlessly, an error occurs irregularly, but only at startup, i.e. when no error occurs, the node runs perfectly:

[INFO] [1481301065.242754]: Loading controller: pos_based_pos_traj_controller_arm Traceback (most recent call last): File "/opt/ros/kinetic/lib/controller_manager/spawner", line 212, in <module> if __name__ == '__main__': main() File "/opt/ros/kinetic/lib/controller_manager/spawner", line 190, in main resp = load_controller(name) File "/opt/ros/kinetic/lib/python2.7/dist-packages/rospy/impl/tcpros_service.py", line 435, in __call__ return self.call(args, *kwds) File "/opt/ros/kinetic/lib/python2.7/dist-packages/rospy/impl/tcpros_service.py", line 505, in call raise ServiceException("unable to connect to service: %s"%e) rospy.service.ServiceException: unable to connect to service: [Errno 104] Connection reset by peer [INFO] [1481301065.448173]: Shutting down spawner. Stopping and unloading controllers... [schunk_canopen_node-1] process has died [pid 24481, exit code -11, ...]

This seems like it has trouble loading the controller. After killing and rerunning the launch file several times (this occurs irregularly), sometimes it just works.

After I have gone through the first part and when the second part finished (This can be fast or take some time..), I can finally use the node normally.

Does anyone work with the schunk_canopen_driver and has the same issues (or not). It bugs me, this behaviour seems not to be normal.

Thanks, Marcel

Full log of 2:

process[schunk_canopen_node-1]: started with pid [24481]
process[ros_control_controller_spawner-2]: started with pid [24509]
<2016-12-09 17:31:03.093> CanOpen(Info)::init: CAN Device was set to auto.
<2016-12-09 17:31:03.093> CanOpen(Info)::init: Trying CAN device: /dev/pcanusb0... flags:2050
process[robot_state_publisher-3]: started with pid [24510]
the rosdep view is empty: call 'sudo rosdep init' and 'rosdep update'
[INFO] [1481301063.727872]: Controller Spawner: Waiting for service controller_manager/load_controller
Can Init successful!
<2016-12-09 17:31:04.280> CAN ...
edit retag close merge delete

Sorry, ROS seems to not accept the first code snippets although they are formatted correctly.

( 2016-12-09 11:10:16 -0500 )edit

Hi @marcelusai, did you find the solution to this problem?

( 2018-11-26 09:15:57 -0500 )edit

Sort by » oldest newest most voted

Hey Marcel,

thanks for the detailed writeup.

The message indicating that the state Error Free was reached is perfectly normal. As you have terminated the software with the nodes still running before (as you have not disconnected the power) the NMT registers that the nodes are in a different state than expected. This warrants a state change and subsequent error clearing after which the EMCY reports that all errors have been cleared.

However, after that the nodes are re-initialized and a commutation search is done. As stated in another question (see http://answers.ros.org/question/26153... ) we have identified a sleep which most likely triggers a PDO-timeout during this routine. Your log states that an RPDO timeout has occurred so it might be the same issue. You could also try the snippet stated there and see if that brings any change.

Please tell me if that worked of the problem still remains. If successful the patch will of course be applied to the master.

Best Regards Georg

more

Thanks for your answer! Does the first part (about the error free state) mean, that at shutdown, I should first disable all joints, power off the robot and then terminate the program? - I always terminated the program before powering off the robot. I will now look at the link and test the snippet.

( 2017-05-26 05:53:36 -0500 )edit

Unfortunately, this does not solve the issue. I get this error for the standalone_interpolated_position.launch, the standalone_profile_position.launch works fine. Additionally we have one computer where the code works, and tried to get the code running on 3 different machines, with no success.

( 2017-08-24 07:16:17 -0500 )edit

Some of the machines had the same configuration (Xubuntu 14.04, ros indigo) and some had other configurations (xubuntu 16.04, ros kinetic). Are some additional packages required? I am wondering, why it is working on this specific machine and not on the others. Drivers are installed correctly.

( 2017-08-24 07:18:22 -0500 )edit