Limb's IK Request when changing endpoint tool in URDF

[Padiolleau Guillaume]

Hello,

I'm working on Sawyer arm in simulation & with real one in SDK mode, and have Intera 5.3.

I added new tools we developed in robot description URDF file. When I launch a simulation through Gazebo, I can see the tool I selected. This part is ok.

But, I have 2 problems in Gazebo simulation:

- First, when no command is sent to the robot in simulation, the arm constantly moves. It seems that the gravity compensation cannot compute right commands to get the arm not moving. I may have missed something in my URDF files. (I set inertial and mass part)

- Second, using the Limb class IK_request function seems not working with new endpoint tool. If I try running an IK request without modifying the end_point arg (default is "right_hand") it says it cannot find a kinematic chain between base and this endpoint. Which normal, since it is not my endpoint tool link name in URDF file. But if is set it to the right link name (say "ttt_tool" as defined in my URDF file) then the IK solver can never find a solution whatever is the given position/orientation point requested. I must have missed somthing in configuration ?

I also have another question: Since in Gazebo simulation we have to specify the endpoint in Limb()._ik_request function which refers to the link name in urdf file, do we have anything to specify for real world robot when changing the endpoint tool ?

Thank you for reading and for future help.

(I recreated the topic because I cannot edit the first one with no reason since I had a Gateway Time-out when editing it first time, the forum crashed down)

 

Guillaume Padiolleau, PhD student

[Padiolleau Guillaume]

Edit:

I think I sovled the second part: I had the wrong gravity_tip_name and tip_name for rosparam in launch file.

BUT, I now cannot add my full tool chain (hand_interface + sensor + tool). I can just add the hand_interface and the sensor without the libgazebo_ros_ft_sensor.so plugin. If I add the tool (without plugin) gzserver run into SegFault Core Dump and the tool (specifically, idk why) does not appear or not spawn. If I add the ft plugin, it don't find the sensor joint and same scenario tool does not appear and gzserver fall inot SegFault...Any Idea ?

 

In the second hand, the arm goes really crazy when attempting to compensate gravity as you can see in the attached video ...

 

Thanks for your help.

gazebo-2020-09-03_15.48.28

[Padiolleau Guillaume]

Edit: [Solved]

- The arm stopped to go crazy. I made a mistake in units for inertial part of links definition in URDF file. Make sure you have kg/m² and not kg/mm² (output of some CAD software).

- I solve the Segmentation Fault bug. It came from the ROS parameter tip_name and gravity_tip_name that were trying to reach an unexisting link (but it was defined in my URDF file).

To solve this :

            - compile your xacro file in URDF using the ros script xacro  "$ rosrun xacro xacro my_file.urdf.xacro > my_file.urdf" and check if the resulting URDF file is correct

           - compile your URDF file in SDF format using Gazebo "$ gzsdf -p my_file.urdf > my_file.sdf" and check if you can find all of your links.

Because of the lumping in Gazebo, some of your link will "disappear", combined in one more global link, if they are connected through fixed joints. For example, my third joint in the chain was a "revolute" joint, however it followed 2 fixed joint and because of the lumping the third (even a revolute) disappeared and the last link (my tip) disappeared with. Then ROS was trying to get this link as tip and causes gzserver to crash. Not obvious at all, I was going crazy...

To solve my chain, I add a "fake" link between 1st and 2nd links. I fixed the 1st one with the right_hand, and the fake_link. Then I fixed 2nd link and fake_link, and my 3rd link with fake_link too. I must do that, because I have a FT_sensor between 2nd and 3rd links that needed to be attached on a joint. But this FT_feedback joint must NOT disappear in SDF else the ft_plugin will crash. So you have to tell Gazebo to disableFixedJointLumping on this joint, however if there is a more-than-1-joint chain of fixed joint this does not work properly...

So, the fake_link enable to disable the lumping by attaching 2 links on one fake_links. Tricky, but it works.

I any of you faces similar issues, feel free to ask here I could probably help you.

 

Guillaume Padiolleau