[Documentation] [TitleIndex] [WordIndex

  Show EOL distros: 

Package Summary

The schunk_canopen_driver package

Package Summary

The schunk_canopen_driver package

Package Summary

The schunk_canopen_driver package


This package provides a driver interface for the Schunk LWA4P robot arm through the CANOPEN interface. It provides a simple interface that accepts position commands and another interface for ros_control.



To control the arm you will need a PEAK can adapter as the driver communicates through a pcan interface. We recommend to install the PEAK driver from source as this works best. For example this can be done through the fzi_icl_can package, which is a dependency for this package:

   rosrun fzi_icl_can install_pcan_module.sh

Note: You will be asked for your sudo password during execution.

You can also build the driver from source by hand, see the PEAK website for instructions. IMPORTANT: Build the driver in CHARDEV mode, not the default netdev mode.

Please note that the fzi_icl_can library is linked against version 7.15.2. If you decide to use a different driver version for the kernel module, this might work, however this cannot be guaranteed.

Building from source

You will need to checkout the following packages into your workspace:

then just call

   source devel_isolated/setup.bash
   # If Peak driver was not installed before.
   # Note: You will be asked for your sudo password during execution.
   rosrun fzi_icl_can install_pcan_module.sh

If you have the fzi_icl_core or fzi_icl_can package in your workspace you'll have to build it with catkin_make_isolated, as those packages are plain cmake packages. See the REP 134 for details.

Installing via package manager

To install the package use your apt-get package manager:

  sudo apt-get install ros-indigo-schunk-canopen-driver
  # If Peak driver was not installed before.
  # Note: You will be asked for your sudo password during execution.
  rosrun fzi_icl_can install_pcan_module.sh


Understanding the different modes

The package offers two different interfaces, which both differ in the action topics, parameters and the way commanded waypoints are interpreted by the hardware.

The simpler profile_position-interface accepts series of waypoints which the robot will drive to with internal interpolation. It is not guaranteed (and might almost never happen), that all joints finish moving at the same time. If multiple waypoints are given, a new waypoint is started for all joints at the same time as soon as the last joint reached it's previous destination. Ramping up and down between waypoints is done by the robot internally depending on it's configuration. The ramping setup will be treated later on.

The ros_control-interface provides a position controller in joint space which will interpolate between waypoints inside the controller (on the host PC). You can set joint velocities and time constraints for each waypoint which the controller will take care of.


Handles controlling of a Schunk robot.

Action Goal

follow_joint_trajectory/follow_joint_trajectory (control_msgs/FollowJointTrajectoryActionGoal) pos_based_pos_traj_controller/follow_joint_trajectory (control_msgs/FollowJointTrajectoryActionGoal)

Published Topics

joint_states (sensor_msgs/JointState) joint_currents (std_msgs/Int16MultiArray)


close_brakes (std_srvs/TriggerRequest) enable_nodes (std_srvs/TriggerRequest) quick_stop_nodes (std_srvs/TriggerRequest) home_reset_offset_by_id (schunk_canopen_driver/HomeWithIDs) home_reset_offset_by_name (schunk_canopen_driver/HomeWithJointNames) home_reset_offset_all (schunk_canopen_driver/HomeAll) init_devices (std_srvs/TriggerRequest)


autostart (bool) can_device_name (string) frequency (int) traj_controller_name (string) use_ros_control (bool)


Example launchfiles


This launchfile gives a ready-to-use action interface to simply access position configurations. It also loads a urdf description of the arm and starts a robot state publisher. Parameters:


This launchfile gives a ready-to-use action interface for ros_control. It loads controllers defined in config/arm_controllers.yaml (This can be changed in the ros_control.launch file). Parameters:


This moves the robot to it's zero position using the profile_position mode. Parameters:

Advanced usage

Defining custom canopen IDs

If your robot arm does use custom canopen IDs, you can modify those in the config/example_config file. When modifying the canopen IDs you will also have to modify the node mapping in config/node_mapping.yaml which will perform the mapping between the canopen IDs and the URDF joint names. See the example config file for a syntax explanation.

In Principal you can configure multiple canopen chains, for example an arm and a gripper. The example configuration file already contains such a setup, however this is untested and might not work.

Setting up Profile Position ramps

When using the simple profile position mode Ramping up and down is controlled by the hardware. The velocity and acceleration can be configured in the config/example_config.yamlfile. Also, targets can be commanded as a relative motion to the current position or as an absolute position relative to the home position (which is the default). Change the ppm_use_relative_targets parameter if you like to change this behavior.


Fault after canceling a goal

Canceling a goal at high speeds seems to set the robot into a fault state. This comes from within the used position controller as it commands the robot to hold a position which is too far away to be reached within one control cycle. As a workaround prefer the quick_stop_nodes service

Fault after starting ros_control mode

Sometimes the robot gets into a fault mode after enabling the interpolated position mode (ros_control mode) when the arm is at a non-zero position. This should not happen with a recent version of ros_control, but if it happens, move the robot to it's zero position using the move_to_home_position.launch launchfile.

2019-06-15 13:10