fix the bug of xarm_robotiq_140 asset load and conrol problem

[xwinks]

Here we fix the asset load and control bug for xarm robotiq 140 robot.
We provide mani_skill/examples/compute_the_drive_for_robotiq_140.py to compute the drive parameter.
We provide mani_skill/examples/test_robotiq_140.py to validate the robot control.
We provide the mani_skill/agents/robots/xarm6/xarm6_robotiq_140.py and mani_skill/assets/robots/xarm6_robotiq_140 for xarm6_robotiq_140

[StoneT2000]

Thank you, I presume this is to fix #1165?

As for the PR we currently don't want to have too many of the same type of robot in the package assets folder (it increases the package size unnecessarily). For extra robots we usually move them to a separate repo to be downloaded through the releases tab (eg Unitree g1, UR10e and a few others).

The test files should also not be in this repo. I recommend moving them to the repo dedicated to hosting the asset files for the robot.

To move forward could you make a repo similar to this one? Detail the changes made to the original URDF(s) and include the original license. https://github.com/haosulab/ManiSkill-WidowX250S

[StoneT2000]

One last point if possible to test the grasping we usually make sure the robot can solve the pick cube task. You can look at the code to see how we set up other robots.

[xwinks]

yes, it is a fix for #1165. I will follow the https://github.com/haosulab/ManiSkill-WidowX250S project and add the grasping task example for this project

[xwinks]

Hi,
I have removed the asset files from the pull request code and placed the download url in the asset download directory in utils/assets/data.py.

Additionally, I have ensured that the robot is functional in the pick-cube task, as demonstrated in the code at this link.

I’d be happy to offer any further assistance to improve the code~

[CumulusAlpha]

Thanks again for your great work!
Yes, i do follow your work and find our urdf lacks the right_inner_finger_pad_joint. it only obtains the right_outer_knuckle_joint, right_inner_finger_joint and right_inner_knuckle_joint. So i just skipped and commented the target_p[1] = -right_inner_finger_pad_joint.get_global_pose().p[0][1] and everything goes wrong.
Could you kindly please give me some advice on this problem?

[xwinks]

Thanks again for your great work! Yes, i do follow your work and find our urdf lacks the right_inner_finger_pad_joint. it only obtains the right_outer_knuckle_joint, right_inner_finger_joint and right_inner_knuckle_joint. So i just skipped and commented the target_p[1] = -right_inner_finger_pad_joint.get_global_pose().p[0][1] and everything goes wrong. Could you kindly please give me some advice on this problem?

As mentioned in #1165 (comment), the drive poses of different gripper is different, i think your urdf mentioned in #1165 (comment) is not the robotiq-140 gripper, so the drive pose of this codebase is not suitable for you.
To get the right drive pose of your own gripper, you could utilize my method described in https://github.com/xwinks/maniskill_xarm_roobtiq_140/blob/main/compute_the_drive_for_robotiq_140.py, to check out the true drive pose of your gripper. You also need to modify the joint names in the code to adapt to your own gripper.

[CumulusAlpha]

Thanks for your kind reply.
# The target_p [[0], [-0.07921], [-0.13704]] is computed by setting point in the Omniverse Platform to get more accurate estimation.
So basically speaking, you find a target_p in omniverse, can i know where did you set the target_p on the robot, is it the contact point of pad and finger link? i also see you compute it in a strange way in Python file, could you please explain it?

[CumulusAlpha]

Hello, i think i know the way you set the point on thr robot. it's the intersection of the finget link and knucle link.

However, what confused me now is that when i run the codecompute_drive_for_robotiq_140.py, it did not seem well. The gripper moved without any control signal. And here is the final state:

Could you please kindly help me solve this problem?