ipa320 / schunk_modular_robotics Goto Github PK

Hi,

I noticed that the URDF joint limits for the lwa4p exceed the manufacturers' specs.

http://mobile.schunk-microsite.com/fileadmin/user_upload/broshures/SCHUNK_Technical_data_LWA4P.pdf

Is this an error, or can the robot actually safely exceed the manufacturer's stated joint limits?

Thanks,
Will

Hi

I was using lwa4p manipulator for one month and everything works correctly. I am using peak controller and I also setup arm with moveit and I am planning to use descartes for cartesian path control but yesterday I tried to initialize the arm and I got following error after calling init all from dashboard.

[ INFO] [1462370072.916654384]: waitForService: Service [/arm/controller_manager/load_controller] has not been advertised, waiting...
[ INFO] [1462370076.942933582]: Initializing XXX
[ INFO] [1462370076.943194663]: Current state: 1 device error: system:0 internal_error: 0 (OK)
[ INFO] [1462370076.943313656]: Current state: 2 device error: system:0 internal_error: 0 (OK)
[ INFO] [1462370077.924076854]: waitForService: Service [/arm/controller_manager/load_controller] has not been advertised, waiting...
[ INFO] [1462370082.928755781]: waitForService: Service [/arm/controller_manager/load_controller] has not been advertised, waiting...
[ INFO] [1462370087.940142244]: waitForService: Service [/arm/controller_manager/load_controller] has not been advertised, waiting...
[ INFO] [1462370090.046918356]: waitForService: Service [/arm/controller_manager/load_controller] is now available.
[ INFO] [1462370090.173969755]: joint_trajectory_controller loaded
[ INFO] [1462370090.244010447]: joint_group_position_controller loaded
Loaded joint_state_controller
[ INFO] [1462370090.313903997]: joint_group_interpol_position_controller loaded
Started ['joint_state_controller'] successfully
[ INFO] [1462370090.383854288]: joint_group_velocity_controller loaded
Slave timeout
[arm/arm_controller_spawner-4] process has finished cleanly
log file: /home/mirec/.ros/log/b43292d8-11ff-11e6-adb5-ac7ba189beb7/arm-arm_controller_spawner-4*.log
Could not switch to mode 7, reason: Mode switch timed out.
[ERROR] [1462370095.397488511]: arm_1_jointcould not enter mode 7
[ERROR] [1462370095.397585440]: Could not switch one joint for joint_trajectory_controller, will stop all related joints and the controller.
[ INFO] [1462370095.397933967]: Switched Controllers. From no_stop_controller_defined to joint_trajectory_controller
[ WARN] [1462370095.397973796]: notify failed
[ INFO] [1462370095.405355236]: advertised as /joint_states

Could anyone help me with this issue I did not make any changes in package and neither in my workspace.

Thank you for your help.

The package ros-indigo-schunk-sdh installs the executables:

/opt/ros/indigo/lib/schunk_sdh/dsa_only
/opt/ros/indigo/lib/schunk_sdh/schunk_sdh
/opt/ros/indigo/lib/schunk_sdh/sdh_only

The library libSDHLibrary-CPP.so that is used by these executables is however not installed:

$ ldd /opt/ros/indigo/lib/schunk_sdh/schunk_sdh
	../common/lib/libSDHLibrary-CPP.so => not found

and hence they cannot be used.

...after next firmware upgrade.
Including extensive testing!

from Román Navarro (Robotnik):
"I think that the arm link 4 of the arm doesn't have the correct length in the stl as well as in the coordinates defined in the lwap4.urdf.xacro. I think in the model it's longer (approx 6 cm) than the real one."

Would you mind releasing especially schunk_description into noetic, such that the meshes and URDF files are available?

Is there anything blocking a noetic release that requires help?

should be _component_/driver/init and _component_/joint_trajectory_controller/follow_joint_trajectory

Desperately waiting for it :)
Is there any blocking issue or anything I can help you with?

xref: ipa320/cob_control#45

Hi,
Is the exec_depend on Gazebo for schunk_description required? It's a pretty heavy dependency when installing a robot model - I assume people attempting to simulate the robot and including the URDF for simulation will have the Gazebo dependency on that package. I.e., can we remove the dependency from the description package?

Thanks,
Wolfgang

move to schunk repository

The mesh added in #96 have a wrong orientation...

Please fix the orientation of arm_1_link.dae

I recently got random exits/restarts of the SDH node:
terminate called after throwing an instance of 'SDH::cDSAException*'

Backtrace:

Program received signal SIGABRT, Aborted.
0x00007fa63c34ac37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007fa63c34ac37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007fa63c34e028 in __GI_abort () at abort.c:89
#2  0x00007fa63c953535 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007fa63c9516d6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007fa63c951703 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007fa63c951922 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007fa63e250c8c in SDH::cDSA::ParseFrame (this=0x23d0b80, response=0x7fff41578280, frame_p=0x23d0c70) at dsa.cpp:559
#7  0x00007fa63e250380 in SDH::cDSA::ReadFrame (this=0x23d0b80, frame_p=0x23d0c70) at dsa.cpp:397
#8  0x00000000004c0068 in SDH::cDSA::UpdateFrame (this=0x23d0b80) at /home/kuka/dev/kuka_ws/src/schunk_modular_robotics/schunk_sdh/common/include/schunk_sdh/dsa.h:499
#9  0x00000000004ca351 in SdhNode::updateDsa (this=0x7fff41578450) at /home/kuka/dev/kuka_ws/src/schunk_modular_robotics/schunk_sdh/ros/src/sdh.cpp:905
#10 0x00000000004bc713 in main (argc=1, argv=0x7fff41578a28) at /home/kuka/dev/kuka_ws/src/schunk_modular_robotics/schunk_sdh/ros/src/sdh.cpp:982

Since I presume it is only related to a malformed package of the tactile sensor array, I would like to ignore this exceptions and just print a warning instead.

I tried to add another catch to:

When trying to dig deeper into the driver issue, I found that the driver source file dsa.cpp (traceback line 6, 7) is nowhere available.

Do you have further ideas for catching the exception / ignoring malformed DSA packages or where to find the source files for the SDH driver?

Hi,
I'm seeing a different axis of rotation on the prl+ joints from what the URDF model indicates. In particular the axis of rotation seems to be pointing toward the base of the robot (positive delta = clockwise rotation) as opposed to what the URDF indicates -- rotation pointing toward the end effector (positive delta = counter clockwise rotation). I have checked to make sure my arm is using the default settings. Are other people having this issue? Should the model be updated to match the arm or is it better if I flip the direction of the motor in firmware? Schunk seemed to indicated changing direction in firmware would not be ideal.

Hello!

I have seen the previous issue about exploding SDH and I also saw that it is fixed. Now, I am using SDH with the current repository and SDH looks as in the image.
Is this a known problem? Is there any solution?

(I am not using any controllers. I have just spawned SDH in Gazebo. If the simulation is paused, then SDH looks good.)

Could you please consider releasing (at least) the schunk_description package to melodic?

I used ros conversion but it does not seem to work. The urdf is empty as below.

sdh.urdf.txt

I am using kinetic.

rosrun xacro xacro --inorder sdh.urdf.xacro > sdh.urdf

Any suggestions on how to clear it ?

Thank you

is already done for lwa4d in #122, still needs to be done for lwa4p and lwa4p_extended

In the PowerCubeCtrl::MoveVel two target position vectors are declared:

• target_pos: https://github.com/ipa320/schunk_modular_robotics/blob/hydro_dev/schunk_powercube_chain/common/src/PowerCubeCtrl.cpp#L433
• target_pos_horizon: https://github.com/ipa320/schunk_modular_robotics/blob/hydro_dev/schunk_powercube_chain/common/src/PowerCubeCtrl.cpp#L434

In the following code, values are calculated for the target_pos_horizon vector:
https://github.com/ipa320/schunk_modular_robotics/blob/hydro_dev/schunk_powercube_chain/common/src/PowerCubeCtrl.cpp#L486

However, all the comparisons are performed on the target_pos vector:
https://github.com/ipa320/schunk_modular_robotics/blob/hydro_dev/schunk_powercube_chain/common/src/PowerCubeCtrl.cpp#L515

Is this the correct behavior?

we have here a Schunk Dexterous Hand that we are using with ROS. I'm using the hydro version of the schunk_sdh package. We are able to move the hand in position operation mode using the dashboard.
I tried to use the velocity operation mode, changing the parameter OperationMode to velocity (in the configuration file sdh.yaml of schunk_hardware_config package) and publishing the velocities to the topic /sdh_controller/set_velocities but in this way the sdh does not move. I used as joint names the ones in the sdh.yaml configuration file and rad/s as unit. Moreover I noticed that if I publish a negative velocity the sdh_controller node gives the error:

[ERROR]: An exception was caught: cSDHErrorInvalidParameter: Invalid target velocity value (-2.864789 not in range [0.000000..157.895000])

as if only positive velocities are admitted. Exploring a little bit the code I think the problem should be in the function SetAxisTargetVelocity(axes_,velocities_) of the SDHLibrary, but I can't understand what's wrong.

Hi,
I am trying to make urdf file out of lwa.urdf.xacro ... When I am running the xacro.py command with following script I am getting the error. Can you please clarify whats wrong with it .

""" This is the code I am using for generating URDF file out of lwa.urdf.xacro"

<xacro:include filename="$(find schunk_description)/urdf/lwa/lwa.urdf.xacro"/>

<xacro:schunk_lwa parent="world" name="my_lwa">

/xacro:schunk_lwa

I am using Ros Jade with ubuntu 14.04.5

Hello everyone,

I've recently ran into a problem using your lwa4p robot model and moveit. Trajectory planning didn't work very well with default joint limits as described here.
Perhaps i did something wrong in the setup, but so far i haven't spotted the issue.

For now have now adjusted the Limits to these values:
Joint: 1 -2.9 2.9
Joint: 2 -2.9 2.9
Joint: 3 -2.7 2.7
Joint: 4 -2.9 2.9
Joint: 5 -2.9 2.9
Joint: 6 -2.9 2.9
which greatly improved the rate of successful motion plans.

There is an ongoing discussion about a problem which may have a similar cause: ros-industrial/universal_robot#265

We used to be able to visualize the arm_base_link.stl with rviz before but the new version fails as it requires that the length of the stl file be (84 + number_of_triangles*50) and arm_base_link.stl has a single extra byte.
Deleting the extra byte at the end of the stl fixes the problem.

Hi,

it seems that the new Schunk PTUs such as the PW 70 v6 only support the Schunk Motion Protocol and not the Amtec protocol anymore. Is there a plan about supporting the new protocol in this package?

I have contacted Schunk about if there is maybe an updated "libm5api", implementing the same interface, but with updated communication messages. I got no reply yet, but I fear there is nothing yet. I consider writing a wrapper myself, but wanted to ask here first.

Best regards,
Manuel

Z-axis of arm_7_link should point "away" from the arm!
For schunk_lwa it is pointing "into" the arm.
(This results in problems with cob_pick_place_action where approach and retreat direction is defined wrt arm_7_link coordinate system!)

I instantiated a sdh model at the top of my lwr in gazebo on indigo, and got fingers exploding, usually coming from inter-penetrating collision objects.

I noticed that the palm and knuckle collision objects somehow inter-penetrate and are also quite detailed for collision objects.

Did you notice a similar behaviour ?

I will provide a PR with simplified collision models that do not inter-penetrate and hence with a model that does not explode in my gazebo simulation.

We encountered communication issues with the SDH and DSA controller that was somehow related to the binary distributed driver in this node (libSDHLibrary-CPP.so). We solved the issue by building the driver (SDHLibrary-CPP) directly from source via a catkinised pure CMake package.

Are you willing to replace the binary library by the source version of the SDH driver? If so, could you create an empty repository at https://github.com/ipa320/SDHLibrary-CPP to hold the SDH driver? I will then open PR for the driver and the node.

hi, I'm working with Schunk SDH and the smallest angle that I can give in position mode to any joint on the hand to move is 0.2 degrees but I tried the smallest angle with python interface that comes with the hand and it moves for much less angles like .0012. where could the problem be?

Currently sdh has default inertial terms, which create some huge inertia and then bad arm behavior when controlled in torque mode gazebo.

Compared to a shadow hand inertial, one can see with gazebo inertia/mass display that it does not match the model.

How accurate should be a fix I am willing to provide ? I don't know were to find individual masses of each sdh element, but could give estimates and use correctly parametrized box inertial macro calls instead of default.

What do you think ?

Hi all,
im a newbie hier, can you tell me how can i build the pakages for windows 64-bits?
Thanks

Hey,
Thank you very much for a fantastic driver package!
We are using the Schunk SDH hand with your ROS driver. Since we are suffering from frequent and severe overheating (hand stops responding to input commands without throwing an exception) after about 30mins of usage, we have expanded your SDH driver with service calls to engage and disengage the motors (calling respective Schunk SDH API calls). Since overheating happens very frequently for us (just the hand being powered, not in use - and sometimes even when motors are disengaged), we are wondering whether you have seen this issue with Schunk SDH hands back when you used them on Care-O-Bots or what you have done to mitigate this issue - are there any secret tricks? ;)

Also, did you see any issues when initialising the hand in the beginning? When calling the /init service, initialising fails ~one out of five times.

Thank you very much in advance :)

related to:

• https://github.com/ipa320/cob_common/issues/222
• ipa320/cob_simulation#150

[ WARN] [1499671498.320796292, 0.162000000]: Deprecated syntax, please prepend 'hardware_interface/' to 'PositionJointInterface' within the <hardwareInterface> tag in joint 'XXX'.

needs to be adjusted in the joint's transmissions e.g. https://github.com/ipa320/schunk_modular_robotics/blob/indigo_dev/schunk_description/urdf/common.xacro#L45-L57
However, this is currently not dual-distro compatible with indigo

@fmessmer FYI

this bug is blocking us from having a hydro release.

@ipa-mdl can you please fix that by adapting from https://github.com/ipa320/cob_extern/blob/hydro_dev/libntcan/CMakeLists.txt. Please send a PR and I'll trigger a new release.