Ask Your Question

Schunk_canopen_driver launch file crash

asked 2017-05-11 09:28:05 -0600

matkok gravatar image

updated 2017-05-13 14:27:41 -0600


I am using Schunk LWA4P robot arm, and I recently downloaded schunk_canopen_driver package. After catkin_make_isolated, I launch standalone_interpolated.launch or some other launch file, and it crashes after trying to do "Commutation search for node 3". I was using arm previously with ipa_canopen and it worked good. Besides that, my controller_manager/spawner is waiting for service, and never spawns a controller. (ros_control and ros_controllers are installed).

I'll give you my output of my cmd.

Update: I found that it crashes when SchunkPowerBallNode::CommutationCalibrated calls m_sdo.upload(false, 0x2050, 0, commutation_status);. Then in SDO.cpp in SDO::upload on argument if( m_data_buffer[0] == SDO_SEG_ABORT_TRANSFER ). That is true and sends break exception.

Update2: In SchunkPowerBallNode.cpp in void SchunkPowerBallNode::commutationSearch(), when I comment the line bool calib_ok = CommutationCalibrated(); and set bool calib_ok = true;, in other words, when I don't go to CommutationCalibrated(), everything works, and all nodes initialize. BUT, I don't know why is that, and I don't want to do it that way. I have a feeling that the id 0x2050 in bool SchunkPowerBallNode::CommutationCalibrated() doesn't pass. Any opinions?

Thanks in advance, Matko


 * /hardware_control_loop/loop_hz: 125
 * /hardware_interface/joints: ['arm_1_joint', '...
 * /joint_limits/arm_1_joint/has_acceleration_limits: True
 * /joint_limits/arm_1_joint/has_velocity_limits: True
 * /joint_limits/arm_1_joint/max_acceleration: 6.0
 * /joint_limits/arm_1_joint/max_velocity: 1.25
 * /joint_limits/arm_2_joint/has_acceleration_limits: True
 * /joint_limits/arm_2_joint/has_velocity_limits: True
 * /joint_limits/arm_2_joint/max_acceleration: 6.0
 * /joint_limits/arm_2_joint/max_velocity: 1.25
 * /joint_limits/arm_3_joint/has_acceleration_limits: True
 * /joint_limits/arm_3_joint/has_velocity_limits: True
 * /joint_limits/arm_3_joint/max_acceleration: 6.0
 * /joint_limits/arm_3_joint/max_velocity: 1.25
 * /joint_limits/arm_4_joint/has_acceleration_limits: True
 * /joint_limits/arm_4_joint/has_velocity_limits: True
 * /joint_limits/arm_4_joint/max_acceleration: 6.0
 * /joint_limits/arm_4_joint/max_velocity: 1.25
 * /joint_limits/arm_5_joint/has_acceleration_limits: True
 * /joint_limits/arm_5_joint/has_velocity_limits: True
 * /joint_limits/arm_5_joint/max_acceleration: 6.0
 * /joint_limits/arm_5_joint/max_velocity: 1.25
 * /joint_limits/arm_6_joint/has_acceleration_limits: True
 * /joint_limits/arm_6_joint/has_velocity_limits: True
 * /joint_limits/arm_6_joint/max_acceleration: 6.0
 * /joint_limits/arm_6_joint/max_velocity: 1.25
 * /joint_state_controller/publish_rate: 50
 * /joint_state_controller/type: joint_state_contr...
 * /pos_based_pos_traj_controller_arm/joints: ['arm_1_joint', '...
 * /pos_based_pos_traj_controller_arm/publish_rate: 50
 * /pos_based_pos_traj_controller_arm/type: position_controll...
 * /robot_description: <?xml version="1....
 * /rosdistro: kinetic
 * /rosversion: 1.12.7
 * /schunk_canopen_node/autostart: True
 * /schunk_canopen_node/can_device_name: auto
 * /schunk_canopen_node/chain_arm: [3, 4, 5, 6, 7, 8]
 * /schunk_canopen_node/chain_names: ['arm']
 * /schunk_canopen_node/frequency: 30
 * /schunk_canopen_node/node_mapping_3: arm_1_joint
 * /schunk_canopen_node/node_mapping_4: arm_2_joint
 * /schunk_canopen_node/node_mapping_5: arm_3_joint
 * /schunk_canopen_node/node_mapping_6: arm_4_joint
 * /schunk_canopen_node/node_mapping_7: arm_5_joint
 * /schunk_canopen_node/node_mapping_8: arm_6_joint
 * /schunk_canopen_node/ppm_profile_acceleration: 0.3
 * /schunk_canopen_node/ppm_profile_velocity: 0.3
 * /schunk_canopen_node/ppm_use_relative_targets: False
 * /schunk_canopen_node/traj_controller_name: pos_based_pos_tra...
 * /schunk_canopen_node/use_ros_control: True

    robot_state_publisher (robot_state_publisher/robot_state_publisher)
    ros_control_controller_spawner (controller_manager/spawner)
    schunk_canopen_node (schunk_canopen_driver/schunk_canopen_driver_node)

auto-starting new master
process[master]: started with pid [11738]

setting /run_id to fce92254-366f-11e7-8af9-fc4dd456d934
process[rosout-1]: started with pid [11751]
started core service [/rosout]
process[schunk_canopen_node-2]: started with pid [11769]
process[ros_control_controller_spawner-3]: started with pid [11770]
process[robot_state_publisher-4]: started with pid [11771]
<2017-05-11 19:33:48.039> CanOpen(Info)::init: CAN Device was set to auto. 
<2017-05-11 19:33:48.039> CanOpen(Info)::init: Trying CAN device: /dev/pcanusb0... 
[INFO] [1494524028.524145]: Controller Spawner: Waiting for service controller_manager/load_controller
Invalid CanDescriptor!
<2017-05-11 19:33:49.039> CAN(Error) tCanDevice(PEAK-CAN)::tCanDeviceT: Error open CAN-device '/dev/pcanusb0' (errno=Bad file ...
edit retag flag offensive close merge delete


And if someone can tell my how to put my Terminal output so it is easyer to read. Thanks :)

matkok gravatar image matkok  ( 2017-05-11 11:57:52 -0600 )edit

Edit your question, select the terminal output, press the Preformatted Text button (the one with 101010 on it). Save.

gvdhoorn gravatar image gvdhoorn  ( 2017-05-11 12:09:56 -0600 )edit

Does anyone know how to start tests, like test_sdo.cpp, that are in the package?

matkok gravatar image matkok  ( 2017-05-12 07:01:36 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2017-05-24 09:18:40 -0600

heppner gravatar image

Hi matkok,

we looked into the problem, thanks for your detailed writeup which helped tremendously.

The error is not as assumed an SDO error which would produce a much more verbose output but (at least that is the theory) a PDO timing error which is resulting from the way we had implemented the commutation search.

The following lines in SchunkPowerballNode.cpp (135 following) are responsible for this:

  size_t counter = 50;

   // Try commutation search for counter times
  while (!calib_ok && counter--)
    usleep(100000); // sleep for 100 ms
    calib_ok = CommutationCalibrated();

The routine waits for the commutation calibration by doing a fixed time wait. This is not the best way to do it as no SYNC signals are sent anymore during this time. If the sync signal is missed for a predefined number of steps a PDO exeception (resulting in a ProtocollException) is thrown and the nodes will enter the fault state.

Please try the following patch:

  size_t counter = 500;

   // Try commutation search for counter times
   while (!calib_ok && counter--)
     calib_ok = CommutationCalibrated();

The explicit sleep is actually not relevant as the sendSync will already take care of the wait without skipping the SYNC signal.

Please let me know if this works or you encounter further problems.

edit flag offensive delete link more


Hi, I am sorry to inform you that is not the answer. I get exactly the same error, and output on my cmd. If you have any other idea, please let me know.

matkok gravatar image matkok  ( 2017-05-25 11:11:45 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2017-05-11 09:24:28 -0600

Seen: 248 times

Last updated: May 24 '17