[Feature] Add WidowXAI Robot, specify robot ids in example scripts

[hu-po]

Adding the new WidowXAI robot from Trossen Robotics. Implementation follows the format of the existing WidowX250S robot.

Added -robot_uids and -r args to specify robot for environments in example scripts.

Robot assets are located here, again following the format of the widowx250s

@StoneT2000 do you have a command for the png at ManiSkill/docs/source/robots/images?

[hu-po]

4.2.mp4

I was hoping for a clear video of picking up the cube to close out this PR, but despite sweeping over max_steps and seeds all I got was some lucky solves that are really more of a push than a pick. I think the biggest issue is that this robot is small so it starts far away and the gripper is barely big enough to grasp the cube. Collisions look good, but the cube needs to be smaller and nearer to the robot. Modifying the task with even more kwargs feels like it will just add more verbosity and cruft. Imo this feels okay enough to just ship, but I understand if yall would rather not include something unless it passes convincingly.

[StoneT2000]

Its strange it can't learn to grasp an object. We generally do want some sign of life that manipulation works before adding a manipulation system.

A couple suggestions:

• Initialize the robot so that the gripper is in a similar pose as what the panda starts off in. This means less steps are needed to solve the task (and you can keep the max_steps=50)
• Your PPO args could probably be optimized. The examples.sh file should be removed in favor of the baselines.sh file in there. The baselines.sh ones are better tuned and you can see the example hyperparams used for pickcube with the default robot (panda)
• You should double check if the is_grasping function is working as intended. It depends on the orientation of the gripper links and some robots have this orientation flipped compared to others. A way to check is to create the pick cube env, use pd_joint_pos action space, and script the joint positions so that the robot moves to the cube, then tries to grasp it, and then check the returned info object for whether the env thinks the robot is grasping it.

env = gym.make("PickCube-v1", robot_uids=..., control_mode="pd_joint_pos")
env.reset(seed=0)
joint_pos_points = [...]
for joint_pos in joint_pos_points:
    for _ in range(50):
        obs, rew, term, trunc, info = env.step(joint_pos)
        env.render_human()
        print(info)

to get these joint pos reference points, you can open the viewer, and click the end-effector and click the transform tab to drag the robot to the cube and figure out where it is.

[hu-po]

Quick update on this project. What has been done:

• Created a new ready_to_grasp keyframe for the robot, this starts it closer to the goal and reduces the complexity of the task.
• Removed examples.sh in favor of baselines.sh
• Added a black material to the robot meshes
• Verified grasping function by stepping through the environment:
  
• Copied over the control_mode and friction material from the panda robot.
• Sweeped over control_mode, seed, and num_steps for the PickCube-v1 task. wandb logs. Here are some cherry picked results:

funny_out.mp4

output2.mp4

output.mp4

output3.mp4

• From visual inspection, the collisions and interactions between the robot and the cube are definitely correct. The different control modes have their phenotypical quirks, but none of them work drastically better or worse than the others. The longer episode length also doesn't really help that much either. It still feels like the task is just too difficult.

What will be done: I will run a similar sweep but on the PushCube-v1 task. I think with this easier task we should be able to get much better results.

[StoneT2000]

for pick cube another consideration is the robot is too small anyway, its reach is not as large as the franka / panda arm and this task has done its randomization with the panda arm in mind.

Try lowering the amount of cube pose randomization + goal site randomization (eg the goal should probably not be so high since this arm can't reach it)

moreover what is the ppo script you use at the moment?

[hu-po]

I am using ppo_fast.py, which is what is used in baselines.sh. I also tried ppo.py and ppo_rgb.py, both run clean but don't learn as fast. My sweeping scripts are in this branch right now, but ill remove them before the merge.

[StoneT2000]

oh definitely do not need to sweep so many control modes. It should work with pd_joint_delta_pos. If not then something is modelled poorly

Also do not use any absolute control spaces (like pd_joint_pos or pd_ee_pose), RL does not learn from those easily unless you modify the reward function more to penalize large actions.

[hu-po]

PushCube-v1 works much better, it still has reach issues but it adorably discovers cube curling!

curling.mp4

double_tap.mp4

@StoneT2000 I removed the scaffolding/test code so this code should be ready to merge. I am stepping away from this work for now: I am receiving the real robot soon and will focus on that the next couple weeks (e.g. testing out lerobot's imitation learning pipeline on the real robot). After that I will come back to this ManiSkill project and work towards the original goal of some kind of real2sim2real. We can just merge this now and then I can start a new pr later, or perhaps you would prefer one larger PR over smaller PRs. Up to you as the maintainer.

[StoneT2000]

I will probably not merge for now given that it can't seem to pick up the cube yet (I haven't looked in depth enough into the robot modeling). I did notice the gripper friction is 4.0, try setting it to 2.0 instead? Training should probably take no more than 5 minutes on a 4090 with ppo_fast. You should only try using the pd_joint_delta_pos action space

Another thing to try is to make the cube a bit smaller just for sanity check. It could be relatively too big for this robot.