Added: Modified fetch robot xml

[josiahls]

Added fetch/main.xml .

Results from loading:

Modified dir struct:

Notes: The only change this pull request makes is adding a fetch robot that can be loaded without error. I needed to comment out the <camera tags (is there a way to support these or no?), and add type="hinge" to joints that did not have the types. I went ahead and kept the backup files to compare the original and the changed xml.

There are no fetch objects, environments, or anything else in this branch, however I plan to begin adding that code to my github as well. But still, I am making the pull request A. so that others can see that someone is trying to get the fetch to work, and B. so others might be willing to help.

Loaded via custom Fetch robot locomotor:

[josiahls]

I am not sure if this is just how pybullet allows the robot to move however after several steps I get: The main issue is the fingers becoming disconnected because they are being moved beyond their limit. Now I understand that this is actually shown by joints_at_limit and the point is to train the robot to not move beyond what it is physically supposed to, however shouldn't there be a way to force it to avoid movements beyond itself in the xml? like below: Like are there parameters that I am missing to prevent this, are is the point to check the joints_at_limit and simply don't do actions that break any of the limits? This issue seems to be only related to the 'slide' joint type.

I am looking at the current ways the environments are setup and they involve applying the action, doing a global step, then determing which joints are outside of their limits. Obviously this is not a big deal for RL, but if I want to test a regular planner, it needs to know that an action is going to be invalid preferably before executing that action (both due to self limits, but also environment collisions).

Are there any implimentations of this that I can reference? I'm not an expert in gym environments (but getting this fetch to spawn actually helped me a lot in terms of understanding how to make and test gym envs) so I might not be super familier if there are already some that do action validation.

[josiahls]

Also, I am currently working on the URDF version of fetch, which is showing more promise:

Both models demonstrate collisions.

Which I understand is kind of moving farther from the Mujoco simulation, however the bullet Mujoco format support just does not seem to be there. So at best, the model with look ugly.

[benelot]

Hi there! Thanks for working on this. The mujoco support should be made to work by reporting the problems to pybullet (bullet3 repo). We should check what joint is the problem and why. Using URDF is a workaround in my opinion, but not a solution.

Furthermore, we should ask Erwin to somehow skip unimplemented declarations (such as the camera tag you had to comment).

On Sun, Jan 27, 2019, 23:49 josiahls [email protected] wrote:

Also, I am currently working on the URDF version of fetch, which is showing more promise: [image: image] https://user-images.githubusercontent.com/19930483/51807977-af4df180-225b-11e9-92c3-90ad38e563a8.png

Both models demonstrate collisions.

Which I understand is kind of moving farther from the Mujoco simulation, however the bullet Mujoco format support just does not seem to be there. So at best, the model with look ugly.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/benelot/pybullet-gym/pull/21#issuecomment-457961834, or mute the thread https://github.com/notifications/unsubscribe-auth/AC97q5GxDD5MJ0ZyTYRGYBsJ0_s9l8A_ks5vHi0OgaJpZM4aUcW7 .

[benelot]

I am just about to look into your fetch robot to see what might be wrong with it.

If in doubt how to implement a proper env for pybullet-gym check out the reacher_env.py (it is a manipulator as fetch probably is): https://github.com/benelot/pybullet-gym/blob/master/pybulletgym/envs/roboschool/envs/manipulation/reacher_env.py

[josiahls]

Thanks, let me know if the gripper is just supposed to be that way. The reacher has a Boolean keyword called limited that is set to true. Does that have anything to do with problem? The reacher env does not have any code related to checking actions before taking them.

Also, for both the URDF and the xml, the colors do not register. Like the URDF is a weird blue tint, and the xml has different colors.

One main reason why I switched over to URDF was because of the difficulty I had converting the xml Mujoco pick-and-place environment. Both table and the block were the same white color and the sphere goal seemed invisible. It seems the color tags do not register. Also I joined the slack, and am accessable through it.

On Mon, Jan 28, 2019, 11:39 AM Benjamin Ellenberger < [email protected] wrote:

I am just about to look into your fetch robot to see what might be wrong with it.

If in doubt how to implement a proper env for pybullet-gym check out the reacher_env.py (it is a manipulator as fetch probably is):

https://github.com/benelot/pybullet-gym/blob/master/pybulletgym/envs/roboschool/envs/manipulation/reacher_env.py

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/benelot/pybullet-gym/pull/21#issuecomment-458205185, or mute the thread https://github.com/notifications/unsubscribe-auth/ATAdc6EiCh4ZfCCjv7QVdY84CB_6HOn7ks5vHye2gaJpZM4aUcW7 .

[benelot]

That was the problem. I set the slider joint just as they are done in the pendulum. Here is my diff:

diff --git a/pybulletgym/envs/assets/mjcf/fetch/main.xml b/pybulletgym/envs/assets/mjcf/fetch/main.xml
index 621f9e3..a1c7451 100755
--- a/pybulletgym/envs/assets/mjcf/fetch/main.xml
+++ b/pybulletgym/envs/assets/mjcf/fetch/main.xml
@@ -160,7 +160,7 @@
													 <site name="grip_r" pos="0.02 -0.01 0" rgba="0 1 0 1"
														   size="0.01 0.01 0.01"/>
													 <inertial diaginertia="0.1 0.1 0.1" mass="4" pos="-0.01 0 0"/>
-                                                    <joint type="slide" axis="0 1 0" name="r_gripper_finger_joint"
+                                                    <joint type="slide" axis="0 1 0" limited="true" pos="0 0 0" name="r_gripper_finger_joint"
															range="0 0.05"/>
													 <geom pos="0 -0.008 0" size="0.0385 0.007 0.0135" type="box"
														   name="r_gripper_finger_link" material="gripper_finger_mat"
@@ -170,7 +170,7 @@
													 <site name="grip_l" pos="0.02 0.01 0" rgba="0 1 0 1"
														   size="0.01 0.01 0.01"/>
													 <inertial diaginertia="0.1 0.1 0.1" mass="4" pos="-0.01 0 0"/>
-                                                    <joint type="slide" axis="0 -1 0" name="l_gripper_finger_joint"
+                                                    <joint type="slide" axis="0 -1 0" limited="true" pos="0 0 0" name="l_gripper_finger_joint"
															range="0 0.05"/>
													 <geom pos="0 0.008 0" size="0.0385 0.007 0.0135" type="box"
														   name="l_gripper_finger_link" material="gripper_finger_mat"

I basically added limited="true" and pos="0 0 0". You can check if limited="true" alone would work as well.

[benelot]

You should try to stick with the mujoco, I intend to support the openai code as closely as possible to support future updates. In case things do not work, just ask and I might be able to help.

[benelot]

Did you continue to work on this?

[josiahls]

Hi, I haven't touched it in a few months. Been in the process of learning DQN's / DDPGs in general. Might pick back up in a few weeks though since I have some base line models.

Originally I was doing a URDF version of fetch, I can try getting the MJCF version to work instead. One remaining issue with MJCF is the complete lack fo pybullet texturing control. So when I attempt to have a fetch bot that can reach torward an object, everything has 1 texture... Of course, its been a few months, so maybe things have changed.