[Documentation] [TitleIndex] [WordIndex

  Show EOL distros: 

Package Summary

SVH Driver wrapper to enable control of the Schunk five finger hand

Package Summary

SVH Driver wrapper to enable control of the Schunk five finger hand

Package Summary

SVH Driver wrapper to enable control of the Schunk five finger hand

Package Summary

SVH Driver wrapper to enable control of the Schunk five finger hand

The demonstration in the video was developed for the Schunk Expert Days and uses the reflexxxes library for interpolation. The SVH driver used is an early version of this repository

Info: The newest Version of this driver (v0.2.0 and above) will support the new hardware versions of the Schunk SVH (2.0 and above).

Overview

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

Installation

If you just want to use the driver it is recommended to install it via repository. All the required libraries are contained within the package. The core driver for the SVH is independent of ros and can also be used in other frameworks if you desire.

Hardware Requirements

To use this package you will need a Schunk Five Finger Hand. It communicates via RS485 protocol. Brainbox USB to Serial converter have proven to work well with the hand and are 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, 14.04 and 16.04 but should have no problem to work in any Linux environment.

From Repository

Install the package by calling:

apt-get install ros-indigo-schunk-svh-driver

apt-get install ros-jade-schunk-svh-driver

apt-get install ros-hydro-schunk-svh-driver

apt-get install ros-indigo-schunk-svh-driver

apt-get install ros-kinetic-schunk-svh-driver

the package comes with udev rules that allow for an easy discovery of the brainbox adapters. Install them by calling:

rosrun schunk_svh_driver create_udev_rules

this will copy the udev rules to /etc/udev/rules.d and restart your udev service.

From Source

You will need to checkout the following packages into your workspace's src directory:

then just call

   catkin_make_isolated
   source devel_isolated/setup.bash

If you have the fzi_icl_core or fzi_icl_comm 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.

The package comes with UDEV rules for the Brainbox USB to Serial adapter to install these source your workspace and call the following:

   rosrun schunk_svh_driver create_udev_rules

which will copy the udev rules into /etc/udev/rules.d and restart your udev service.

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) reset_channel (std_msgs/Int8) enable_channel (std_msgs/Int8) channel_targets (sensor_msgs/JointState)

Published Topics

channel_feedback (sensor_msgs/JointState) channel_currents (std_msgs/Float64MultiArray) parameter_descriptions (dynamic_reconfigure/ConfigDescription) parameter_descriptions (dynamic_reconfigure/ConfigDescription) parameter_updates (dynamic_reconfigure/Config)

Parameters

~autostart (bool, default: true) ~serial_device (string, default: /dev/ttyUSB0) ~disable_flags (vector of bool, default: 9 x false) ~reset_timeout (int, default: 5) ~finger_reset_speed (double, default: 0.2) /robot_description (urdf model, default: URDF at description/urdf/svh-standalone.urdf.xacro) ~logging_config (string, default: /etc/logging.xml) ~use_internal_logging (bool, default: false) ~CHANNEL_NAME/position_controller (vector of floats, default: see yaml files) ~CHANNEL_NAME/current_controller (vector of floats, default: see yaml files) ~CHANNEL_NAME/home_settings (vector of floats, default: see yaml files) ~VERSIONS_PARAMETER (array, default: Filled with values from the etc/controller_default.yaml file)

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) speed (std_msgs/Float32) loop (std_msgs/Float32)

Published Topics

channel_targets (sensor_msgs/JointState)

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:

Channel Name

Number

ALL

-1

svh_finger_description.png

THUMB_FLEXION

0

THUMB_OPPOSITION

1

INDEX_FINGER_DISTAL

2

INDEX_FINGER_PROXIMAL

3

MIDDLE_FINGER_DISTAL

4

MIDDLE_FINGER_PROXIMAL

5

RING_FINGER

6

PINKY

7

FINGER_SPREAD

8

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 hardware version and CHANNEL_NAME which is stated in the section channel mapping. For example: The settings of the Ring Finger would be searching for the corresponding hardware version and the entry of RING_FINGER and so forth.

When using the launch file svh_controller.launch all parameters are read from yaml files residing in the folder etc. If you want to give custom parameters just edit the file etc/controller_user.yaml if you are using the source installation. In case of an installation from deb you should first copy the file under etc/controller_user.yaml to a folder with user write acces, make your changes and then use it by adding the argument controller_config:=path_to_your/logging.xml when launching the node.

If you want to go back to the original values (and have edited the file, residing in etc) 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 or the node use used without the launch file 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. Consult the svh_hardware_information.pdf before you change things.

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 or your hardware we recommend that you run the standalone version first and get familiar with the behavior of the Hand.

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

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 ttyUSBx 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.

If no ttyUSBx device comes up, make sure you have installed the udev rules correctly or if you are using any other hardware installed the drivers according to their documentation.

If the power supply is not connected probably or the it delivers not enough power the connection to the hand may have problems. This will lead to a package loss during communication.

Standalone usage

If you want to check out that everything is working or just want to move the hand into any position you can use the package as standalone with sliders.

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

roslaunch schunk_svh_driver svh_controller.launch standalone:=true

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 that has come up.

You can disable the autostart by adding the argument autostart:

roslaunch schunk_svh_driver svh_controller.launch standalone:=true autostart:=false

By using the standalone argument the launchfile will start a joint state publisher for easy input. If you do not activate this as input you have to provide the target positions by another node or console input. The package folder comes with a file called "quick_commands" which gives you some examples how to controll the hand via rostopic.

Together with other packages

By default the node will await input from another node. To use the svh_controller with your project it is highly recommended that you include it via its 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>

The argmuments are not strictly necessary as the values default to these. This way of including the node may however be more than you want because the launch script already contains things like a robot state publisher etc. if you just want the node, but do not want to care about the config files and so on you can use the very simple include file:

<include file="$(find schunk_svh_driver)/launch/svh_node.launch">
            <arg name="serial_device" value="$(arg serial_device)"/>
            <arg name="autostart" value="$(arg autostart)" />
</include>

again, fill out the arguments you need, the rest will default to predefined values. If you use the svh_node.launch file you will have to provide an "output joint state publisher" for the joint states in order to generate the joint states required for the URDF (note below). This option is only available from version 0.1.6 and up (deb file install is 0.1.5).

If you just want to use the node without the configuration files, etc. the node will default to hard-coded values.

NOTE The urdf of the node makes use of the mimic tag which is currently only resolved by the robot joint state publisher. in order to generate TFs for the visualization and to get the angles of the coupled joints the node is used in conjunction with a joint state publisher and a robot state publisher. If you include the node without these nodes the TF tree will not be complete as the joints that use mimic are not working. See the URDF section for details on joints, their naming and relation.

Visualisation

The node will automatically show the input sliders if started with the standalone argument. If you additionally provide the gui argument as true an rqt gui will be opened when launching the node:

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

The rqt gui opens always to its default configuration (which is usually the last one). 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 model of the SVH. A configuration file for rviz is provided with the package at "urdf/svh.rviz". Your configuration should look something like this to access all GUI functionalities:

svh_rqt_gui.jpg

Simulation

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

roslaunch schunk_svh_driver svh_controller.launch simulation:=true gui:=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:=true gui:=true

Note: The SVH uses relative encoders that need a hard stop to reset. Especially the finger spread however also contains springs that will lead to a slightly different pose than commanded in real execution. So please beware when you develop poses without the hardware in the loop.

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 all fingers except the thumb will perform a sinus like motion. You can stop/start the motion execution by sending:

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

During execution the driver will output warnings like this:

<2014-09-29 14:40:56.004> DriverSVH(Warning) SVHFingerManager::setAllTargetPositions: Could not set target position vector: At least one channel is out of bounds!

this is perfectly normal as the sin test tries to drive the fingers to positions outside of the soft stops.

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.

Argument Listing

The following arguments are possible for the main launch file and can be mixed freely (most are just passed to the parameters of the node):

gui (default: true)

autostart (default: true)

serial_device (default: /dev/ttyUSB0)

simulation (default: false)

logging_config (default: schunk_svh_driver/etc/logging.xml)

use_internal_logging (default: false)

controller_config (default: schunk_svh_driver/etc/controller_user.yaml)

general_config (default: schunk_svh_driver/etc/svh.yaml)

standalone (default: false)

Troubleshooting

After an autostart (default setting) of the software the fingers do not begin to move

After an autostart of the software it says Send packages = 28, received packages = 20 or something similar

During reset of the fingers it states Driving channel 5 to hard stop. Detection thresholds: Current MIN: -500.000000mA MAX: 500.000000mA or similar and nothing is happening

During reset the finger stops as soon as it touches any resistance and is initialized in an odd position

The fingers work but they "run away" when they do fast movements or touch something and can not be controlled afterwards

A finger is broken, can i still use the rest of the finger?

The plugin does not show in rqt, or a failure occurs during loading

The hand gets very hot

RVIZ shows nothing like the screenshot when i load it

When i start the node with rosrun the URDF tree of a robot state publisher is not complete

Where is the actual functionality within the ROS package? It hardly seems to do anything

Getting Help

If the troubleshooting did not answer your questions you can ask the community via ROS Answers or contact the support offered by FZI on behalf of Schunk at svh-support AT fzi DOT de


Additional information

Information provided here is meant for developers that want to use the driver in a very specific way or extend it.

URDF

The following illustration shows where the individual joints are located within the kinematic model of the hand and how the connected finger segments are scaled in respect to these joints. The mimic joints will always have the joint angle of the joint they mimic times the scaling factor that is stated for each joint

The links in the URDF contain many helper and dummy links that are needed to create the quite complex kinematic chain why the following illustration of the links is only partially accurate. Especially the links names "e" are mostly virtual and really in one place. Also the base link is actually further in the back than drawn in the picture. Due to the limitations of 2D we could not accurately illustrate this:

For proper illustration of the robot model simplified collada files where created out of the original CAD data of the SVH. The following picture shows which part corresponds to a file name:

Kinematic dependencies and ranges

The following indicates the maximum angles (from wich the scaling for the svh driver was calculated):

The joint names correspond to the ones seen in this kinematic description

Additional Documents


2019-09-21 13:11