Collisions in Track 1 - Task 2

Hello,

The main problem with this revolute joint is that some ROS packages we are using make use of the URDF file of the robot and due to this problem with the tf, these packages don't work properly.

Regarding the collisions, I have not found any strange behaviour.

Kind regards

Ok that sounds like trouble. We'll fix it for the next release. Meanwhile you could use a tf publisher as a workaround:

Code:

rosrun tf static_transform_publisher 0 0 0 0 0 0 1 ur_flange tool_link_c 100

OK, thanks!

We have noticed a new issue in task 2. Sometimes the workpiece makes some small "jumps" (it seems something random, nothing has happened apparently).

If this "jump" happens during the insertion (the rivet tool inside the hole), the insertion process fails as the tool ends up outside the hole.

We don't know if those movements of the workpiece are related with something.

We have the same problem here - workpiece jumps randomly.

Hi,

could you provide us some more details to trace down the error? E.g. log-files (preferably debug level) or a description of the situation when it happend?

How big was this "jump"? It could be related to a feature that resets the workpiece to a random position in case of a collision (including robot-workpiece collisions!) In this case, the target_frame is also reset to rivet_home - did this happen?

Thanks,
Frank

If this may help, the workpiece also resets its position every time a movement of the human is instantiated.

Code:

Index: ipa325_euroc_sim/ipa325_euroc_human_move/scripts/gazebo_human_move.py
===================================================================
--- ipa325_euroc_sim/ipa325_euroc_human_move/scripts/gazebo_human_move.py   (revision 2298)
+++ ipa325_euroc_sim/ipa325_euroc_human_move/scripts/gazebo_human_move.py   (working copy)
@@ -38,8 +38,8 @@
 class gazebo_human_move():
    def __init__(self,filename):
       ### resetting gazebo world with service call
-      reset_call = rospy.ServiceProxy("/gazebo/reset_world",Empty)
-      reset_call()
+      #reset_call = rospy.ServiceProxy("/gazebo/reset_world",Empty)
+      #reset_call()
       self.generate_state_machine(filename)
 
    def generate_state_machine(self,filename):


Though commenting out these lines seems to break task 1.1 in some way...

In my case, those jumps happen even when the robot is far from the workpiece and stopped (I am planning the path for example). The /target_frame does not change.

The previous comment may point to the right direction, the jump is similar to the ones which happen when some object/element is instantiated in Gazebo.

Hello,

Is there expected to solve the problem with the tool_link_c definition? (it is revolute instead of fixed)

Your solution of the transform publisher solves the issue of the error in robot model in Rviz but this kind of definition of the robot causes inconveniences with packages like MoveIt!.

Kind regards

Hm, how big is this inconvenience?

Another solution would be to publish the joint with a libgazebo_ros_joint_state_publisher. This however means two alternating joint state messages, which in turn makes a lot of other things rather inconvenient