About | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange

melodic noetic   Show EOL distros: 

Overview

This package provides a way of controlling the Schunk Five Finger Hand. It provides the driver for the low lever interface and enables an easy control of the hand via ROS messages.

Hardware Requirements

To use this package you will need a Schunk Five Finger Hand. It communicates via RS485 protocol. Brainbox USB to Serial converter has proven to work well with the hand and is usually delivered in combination with the hand.

Software Requirements

All required (non ROS)libraries are contained in the package and the package is tested to work under Ubuntu Linux 12.04 and 14.04 but should have no problem to work in any Linux environment.

Installation

Checkout the package into your catkin workspace and call catkin_make. This will automatically trigger a subsequent build of the internal libraries contained within the package so do not be alarmed by quite extensive output.

The package comes with UDEV rules for the Brainbox USB to Serial adapter to install these change into the udev directory of the package and call the following commands:

sudo cp 99-brainboxes-us.rules /etc/udev/rules.d/
sudo chmod a+rx /etc/udev/rules.d/99-brainboxes-us.rules
sudo /etc/init.d/udev restart

ROS API

svh_controller

This node is interfacing with the Schunk Five Finger Hand and provides the ability to control the fingers and read out any feedback

Subscribed Topics

connect (std_msgs/Empty)

• Tries to connect to the hardware when triggered. The hardware will use the serial_device that can be reconfigured via dynamic reconfigure

reset_channel (std_msgs/Int8)

• Triggers a reset of the given channel (finger). See channel mapping below.

enable_channel (std_msgs/Int8)

• Enables a given channel (finger. See channel mapping below.

connect (std_msgs/String)

• Tries to connect to the hardware by sending initial packets

channel_targets (sensor_msgs/JointState)

• Target position the channels (fingers) shall move to. Note that it is less performant to give targets for individual channels or a subset of the available DoF than providing it for all at once. If 8 channels are given instead of 9 the driver will send 8 packets instead of 1 which might influence serial device performance. Only the names and positions will be evaluated.

Published Topics

channel_feedback (sensor_msgs/JointState)

• Current position of the channels (fingers).

Parameters

~autostart (bool, default: false)

• If set to true the controller will immediately try to connect to the hardware and start a reset of all the channels (fingers)

~serial_device (string, default: /dev/ttyUSB0)

• Device handle to use for the serial communication, e.g /dev/ttyUSB0

~disable_flags (vector of bool, default: 9 x false)

• Indicates if a channel (finger) should be disabled. If disabled a finger will not be activated by the hardware but behaves as if everything was fine. This can be used in case a finger has a hardware failure.

~reset_timeout (int, default: 5)

• Time in seconds after which a reset of a channel (finger) is aborted if the reset current threshold can not be reached. If a channel (finger) needs to reach 300mA for detection of a hard stop but is stuck at 200mA the reset is aborted after reset_timeout seconds.

~finger_reset_speed (double, default: 0.2)

• Only available as dynamic reconfigure value. Speed of fingers during reset, given as percentage of their usual speed.

/robot_description (urdf model, default: URDF at description/urdf/svh-standalone.urdf.xacro)

• Urdf model of the hand, including the joints and links describing the svh

log_config (string, default: /etc/logging.xml Only in the launch file. If none is specified output will be lost.)

• Path to the logging.xml file configuring the internal logging of the svh_driver library. Usually resides in /etc/logging.xml

~log_debug_file (string, default: /log/DriverSVH_Debug.log Only in the launch file. If none is specified the output will be lost.)

• Path to the log file where debug messages (of the internal libs logging) are stored.

~log_trace_file (string, default: /log/DriverSVH_Trace.log only in the launch file. If none is specified the output will be lost.)

• path to the log file where trace messages (of the internal libs logging) are stored.

~CHANNEL_NAME/position_controller (vector of floats, default: If no values are provides the controller will use safe internal defaults.)

• Parameters used for the hardware position controller. See additional documentation in YAML files and below.

~CHANNEL_NAME/current_controller (vector of floats, default: If no values are provides the current will use safe internal defaults.)

• Parameters used for the hardware current controller. See additional documentation in YAML files and below.

~CHANNEL_NAME/home_settings (vector of floats, default: If no values are provides the controller will use safe internal defaults.)

• Parameters used for the homing of the fingers providing soft stops and reset parameterization. See additional documentation in YAML files and below.

svh_sin_test

this node is meant as a very very simple test program to show how to interface with the svh_controller and to check if the hardware works

Subscribed Topics

toggle_run (std_msgs/Empty)

• If toggled by a message the node will start or stop outputting joint angles based on a sin.

Published Topics

channel_targets (sensor_msgs/JointState)

• Target position of the fingers for the svh_controller

Additional API information

Channel Mapping

The SVH has 9 degrees of freedom which are addressed as channels. Topics that accept channels will use the following mapping:

Parameter sets

Each finger is controlled by a cascade of position and current controller (see additional Information if you are interested in that) and has a set of homing settings. The individual settings are read via parameter server addressing them via their CHANNEL_NAME which is stated in the section channel mapping. For example: The settings of the Ring Finger would be looked for at ~RING_FINGER/position_controller and so forth. All parameters are read from yaml files residing in the folder etc. If you want to edit these files just edit the file etc/controller_user.yaml. If you want to go back to the original values you can simply delete the file and copy the controller_default.yaml to the name controller_user.yaml and start again. If no controller_user.yaml file is present the values of the default file will be used. If both files are missing hardcoded default values that are safe will be used.

WARNING: These settings enable control of very low level concepts. Setting wrong values here may lead to permanent damage in the hardware. Especially the maximum allowed currents should not be exceeded.

Usage

The package is ready to be used as standalone package for fast testing or in combination with other packages providing the target points for the fingers. To test the package we recommend that you run the standalone version first and get familiar with the behaviour of the Hand.

In any case you should use the provided launch script as it sets up many variables and some additional packages that are needed for correct operation and visualisation.

Hardware setup

Make sure the hand is connected to an appropriate power source and via a USB to Serial adapter to your pc. You can check which adapters are available with a quick:

ls /dev

where an entry like /ttyUSB0 should be present. In case you have multiple adapters the easiest way to check which one you are using is to disconnect the adapter shortly and check which of the ttyUSB devices is gone.

You can change the device used by adding the argument serial_device to the launch calls, change it via dynamic reconfigure and then do a reconnect or change it permanently by replacing the argument in the launch file.

With hardware

Make sure the hardware is powered and can move freely and launch the controller node by calling

roslaunch schunk_svh_driver svh_controller.launch

This will automatically connect the driver to the hardware and call the reset routine for all fingers. Upon the message: "Driver was autostarted! Input can now be sent. Have a safe and productive day!" the hand is ready and fingers can be moved by using the Joint State publisher gui.

You can disable the autostart by adding the argument autostart:

roslaunch schunk_svh_driver svh_controller.launch autostart:=False

By default the launchfile will start a joint state publisher for easy input. If you do not want to use this input but control the hand via rostopic you simply call:

roslaunch schunk_svh_driver svh_controller.launch standalone:=False

This is also the way to use the launch file if you want to control the SVH with your custom software. Simply include the launch file like this:

  <include file="$(find schunk_svh_driver)/launch/svh_controller.launch">
        <arg name="standalone" value="False" />
        <arg name="gui" value="False" />
  </include>

As shown in the last example you can turn off the automatic start of the gui by setting the gui arg to false:

roslaunch schunk_svh_driver svh_controller.launch standalone:=false gui:=false

All arguments can be combined freely. You can change their default values in the svh_controller.launch file.

Visualisation

A rqt_gui will be launched automatically to show you the visualization (if the argument gui is set to true). However you need to configure the right plugins. The SVH comes with the plugin SVH_Reset which enables easy reset control of the hand. Additionally you can use dynamic_reconfigure to change some of the values and the RVIZ plugin to visualize the robot modell of the SVH. A configuration file for rviz is provided with the package. Your configuration should look something like this to access all GUI functionalities:

Without hardware

If you do not want to use the actual hand you can simply start a visualization of the hand by using:

roslaunch schunk_svh_driver svh_controller.launch simulation:=True

as with the real hardware you can choose to use the simulation (which is not really a simulation but just a visualisation) with convenient sliders or with the command line/ your own packages by using the standalone argument:

roslaunch schunk_svh_driver svh_controller.launch simulation:=True standalone:=false

sin test

As a test to see if the hardware is properly working the very simple test node svh_sin_test is provided. Make sure the hand can move freely and run the test with:

roslaunch schunk_svh_driver svh_sin_test.launch

after all fingers are reset you can start and stop the test by publishing the following:

rostopic pub -1 /svh_sin_test/toggle_run std_msgs/Empty "{}"

Note that the node is just intended to allow a quick function test of the hardware or a simple example of how to interface with the controller node.

Additional usage information

In case you do not use the autostart feature of the controller you will have to connect and start the controller manually. You should do this by using the SVH_Reset plugin provided with the package. When the hardware is ready press the connect button. Afterwards you can either reset all or individual fingers by pressing reset. The fingers will be disabled after start but are automatically enabled once a target position is set.

If you prefer to use the command line to send topics, some predefined test inputs are stored in the quick_commands file for convenience. Just copy and paste them to the command line.