Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gazebo9 Issues :-( #37

Closed
moriarty opened this Issue Feb 28, 2019 · 16 comments

Comments

Projects
None yet
6 participants
@moriarty
Copy link
Member

commented Feb 28, 2019

We have a problem with the Gazebo Robot Model. Things work fine on the Robot, but we've had a number of bugs reported with the simulated robot.

Update (March 20)

I've just added a help wanted label to this issue, as I've been tuning the model, and have attached the git diff to this issue, but we'll accept any PRs if anyone as time to try and further tune the models. It might be best if we work in parallel and communicate back via this issue.


We've been investigating the issue, and tuning/tweaking parameters. However we haven't found a solution yet. Thank you for the detailed bug reports, and youtube videos of gazebo.

#36 #35 #30 #31

I suspect, that Gazebo has gotten better, and we were relaying on some values which didn't make sense but use to work. Here is one inline comment which leads to that suspicion...

<!-- Gripper is another fallacy of physics -->

But in the past between gazebo jumps I've seen similar cases were we've had to go back and tune the kp kd values as gazebo gets better they needed to be updated.
http://gazebosim.org/tutorials/?tut=ros_urdf

@adaruna3

This comment has been minimized.

Copy link

commented Mar 12, 2019

Hi all,

Has any progress been made regarding these issues?

It's difficult to tell how well localization, navigation, etc. are working without a physical robot for the upcoming fetchit challenge due to this issue with simulating in Gazebo9. Additionally, switching between simulators makes integration across pipelines (e.g. nav and manipulation) difficult.

Thanks in advance!

@RDaneelOlivav

This comment has been minimized.

Copy link
Collaborator

commented Mar 12, 2019

Lets address these issues!

We could start addressing these two issues?
Grasping
#31

Movement of Base:
#35

@moriarty how are those issues? Lets Crush them!

@moriarty

This comment has been minimized.

Copy link
Member Author

commented Mar 12, 2019

There hasn't been any forward progress on this issue- we're looking into it and have made it worse, or marginally better in some ways but not overall fixed.

@narora1 and I will check different versions of ROS and Gazebo, and see if we can narrow down where things changed.

I just spoke with @ajzeller and @ediehr about how the original models and URDF files were generated.

@moriarty

This comment has been minimized.

Copy link
Member Author

commented Mar 14, 2019

An update on this.

We're checking where things stopped working.
Our current branches almost work with Gazebo 7 and ROS Kinetic.
https://gist.github.com/moriarty/6667d6f139b0fd80dba1f497e9d69373

I don't think this is a ROS Melodic issue, because everything is working with Melodic on the robot.

The two issues:
Grasping #31
Moving #35

Seem to be related.

A real robot, has suspension system which keeps the main drive wheels and all 4 caster wheels in contact with the ground, and the base link frame stable.
The model in Gazebo lacks the suspension system and only the main drive wheels are constantly on the ground, and the robot can rock back and forth. So when detecting the cube in #31 the robot detects the cube, and when it goes to grasp it rocks forward. The real robot, doesn't rock forward.

The base driving is similar when #35 and #36 really start to fail when rotating, but in a straight line don't fail as bad, there is a bit of a "seesaw" motion as the robot rotates and it tilts back and forth onto the front and rear casters.

I'm going to do some testing with the main drive wheels moved up into the robot further (as if the suspension system is compressed- which on the real robot it always is) this should give us 6 points of contact with the ground and a more stable base.
The next issue to look into is the friction between the caster wheels and the ground because we haven't modeled the caster wheels as caster wheels.

@moriarty

This comment has been minimized.

Copy link
Member Author

commented Mar 14, 2019

Sinking the wheels into the robot, did help make it bounce or seesaw less, but not completely. And there is still something unstable in the controller. I won't check in this change because I'm still not happy with the behaviour, especially going through the doors. the value 0.059 was just picked by launching gazebo with different values.

diff --git a/fetch_description/robots/fetch.urdf b/fetch_description/robots/fetch.urdf
index 88297f0..b492567 100644
--- a/fetch_description/robots/fetch.urdf
+++ b/fetch_description/robots/fetch.urdf
@@ -44,7 +44,7 @@
     </collision>
   </link>
   <joint name="r_wheel_joint" type="continuous">
-    <origin rpy="-6.123E-17 0 0" xyz="0.0012914 -0.18738 0.055325" />
+    <origin rpy="-6.123E-17 0 0" xyz="0.0012914 -0.18738 0.059" />
     <parent link="base_link" />
     <child link="r_wheel_link" />
     <axis xyz="0 1 0" />
@@ -72,7 +72,7 @@
     </collision>
   </link>
   <joint name="l_wheel_joint" type="continuous">
-    <origin rpy="-6.123E-17 0 0" xyz="0.0012914 0.18738 0.055325" />
+    <origin rpy="-6.123E-17 0 0" xyz="0.0012914 0.18738 0.059" />
     <parent link="base_link" />
     <child link="l_wheel_link" />
     <axis xyz="0 1 0" />
@adaruna3

This comment has been minimized.

Copy link

commented Mar 16, 2019

Thanks for all updates Alex! We're closely following.

@moriarty

This comment has been minimized.

Copy link
Member Author

commented Mar 18, 2019

I still haven't gotten a stable model. But I have made progress. The current model shows jitter, and if you view it with "transparent" and "center of mass" on in Gazebo, it can bee seen that the wheels move. There are a large number of issues similar to this on Gazebo, and it seems to be a matter of parameter tuning.

Instead of simply sinking the main drive wheels as above, I've created 4 invisible "caster" wheels near to where the real caster wheels are, but with the diameter and on same z height as the drive wheels. This is because the exact height of the casters is hard to determine.

diff --git a/fetch_gazebo/robots/fetch.gazebo.xacro b/fetch_gazebo/robots/fetch.gazebo.xacro
index b826ea2..a1b896c 100644
--- a/fetch_gazebo/robots/fetch.gazebo.xacro
+++ b/fetch_gazebo/robots/fetch.gazebo.xacro
@@ -1,6 +1,49 @@
 <robot xmlns:xacro="http://www.ros.org/wiki/xacro" name="fetch" >
   <xacro:include filename="$(find fetch_description)/robots/fetch.urdf" />
 
+  <!-- Add four casters to the base -->
+  <xacro:macro name="caster" params="prefix joint_x joint_y">
+  <link name="${prefix}_caster_link">
+    <visual>
+      <origin rpy="0 0 0" xyz="0 0 0"/>
+      <geometry>
+        <sphere radius="0.060"/> <!-- 0.06033 -->
+      </geometry>
+      <material name="">
+        <color rgba="0.086 0.506 0.767 1"/>
+      </material>
+    </visual>
+    <collision>
+      <origin rpy="0 0 0" xyz="0 0 0"/>
+      <geometry>
+        <sphere radius="0.060"/>
+      </geometry>
+    </collision>
+    <inertial>
+      <inertia ixx="1" ixy="0" ixz="0" iyy="1" iyz="0" izz="1"/>
+      <origin rpy="0 0 0" xyz="0 0 0"/>
+      <mass value="1"/>
+    </inertial>
+  </link>
+  <gazebo reference="${prefix}_caster_link">
+    <mu1>0.01</mu1>
+    <mu2>0.01</mu2>
+   <!-- <kp>500000</kp> -->
+   <!-- <kd>10.0</kd> -->
+   <!-- <maxVel>10</maxVel> -->
+  </gazebo>
+  <joint name="${prefix}_caster_joint" type="fixed">
+    <parent link="base_link"/>
+    <child link="${prefix}_caster_link"/>
+    <origin rpy="0 0 0" xyz="${joint_x} ${joint_y} 0.055325"/>
+    <axis xyz="0 1 0"/>
+  </joint>
+  </xacro:macro>
+  <xacro:caster prefix="fl" joint_x="0.15" joint_y="0.12"/>
+  <xacro:caster prefix="fr" joint_x="0.15" joint_y="-0.12"/>
+  <xacro:caster prefix="br" joint_x="-0.2" joint_y="0.12"/>
+  <xacro:caster prefix="bl" joint_x="-0.2" joint_y="-0.12"/>
+
   <!-- Base is modeled as a big tub sitting on floor, with two wheels -->
   <gazebo reference="base_link">
     <kp>100000000.0</kp>

I also have replaced our wheel stl mesh, with an cylinder. The radius comes from the CAD model.
I tried sphere but the robot again behaved weird.
In https://github.com/fetchrobotics/fetch_ros

diff --git a/fetch_description/robots/fetch.urdf b/fetch_description/robots/fetch.urdf
index 88297f0..4548fde 100644
--- a/fetch_description/robots/fetch.urdf
+++ b/fetch_description/robots/fetch.urdf
@@ -37,9 +37,11 @@
       </material>
     </visual>
     <collision>
-      <origin rpy="0 0 0" xyz="0 0 0" />
+      <origin rpy="1.57079 0 0" xyz="0 0 0" />
       <geometry>
-        <mesh filename="package://fetch_description/meshes/r_wheel_link_collision.STL" />
+        <!-- mesh filename="package://fetch_description/meshes/r_wheel_link_collision.STL"  -->
+        <cylinder radius="0.06033" length="0.051"/>
+        <!-- sphere radius="0.06033" -->
       </geometry>
     </collision>
   </link>
@@ -65,9 +67,11 @@
       </material>
     </visual>
     <collision>
-      <origin rpy="0 0 0" xyz="0 0 0" />
+      <origin rpy="1.57079 0 0" xyz="0 0 0" />
       <geometry>
-        <mesh filename="package://fetch_description/meshes/l_wheel_link_collision.STL" />
+        <!-- mesh filename="package://fetch_description/meshes/l_wheel_link_collision.STL"  -->
+        <cylinder radius="0.06033" length="0.051"/>
+        <!-- sphere radius="0.06033" -->
       </geometry>
     </collision>
   </link>
@moriarty

This comment has been minimized.

Copy link
Member Author

commented Mar 20, 2019

If anyone is able to further tune these gazebo physics values I'm throwing a help wanted label on this as we'll accept PRs, and it might speed up the process.

@RDaneelOlivav

This comment has been minimized.

Copy link
Collaborator

commented Mar 20, 2019

I can give it a try tomorrow to see if I'm more lucky in the physics parameters. Gazebo is really bad sometimes with physics... Especially when you want precision.

I'll try some configurations that in other simulations worked in the past, but who knows ;).

@moriarty To better know the issue, could you post a video showing the issue? I think it would center more what we want to improve.

@moriarty

This comment has been minimized.

Copy link
Member Author

commented Mar 20, 2019

Yes, sorry I did record a video and it's on my desktop at home. I'll post it after work

@moriarty

This comment has been minimized.

Copy link
Member Author

commented Mar 20, 2019

If you view "transparent" "links" and "center of mass" and "inertia" you'll see that the center of mass- which are black and white spheres, for the drive wheels will rotate. This could be invalid inertia values, or invalid friction values, or the PID Controller, or a combination of the above, I've been tuning and testing with all combinations of the above.

The caster wheels, in the git diff above, solve the robot rocking back and forth which fixes #31.
That change, I should probably check in and commit to the repository- because I've shared that change with @ejichen and she is able to grasp the cube (when the robot is started in the FetchIt! simulation, in front of the table to avoid the Navigation issues).

The robot is able to drive straight and pick, but when it turns #30 the behaviour is now a bit worse, and it appears to be the wheels slipping, and throwing off the odom.

@moriarty

This comment has been minimized.

Copy link
Member Author

commented Mar 21, 2019

Here is the behaviour prior to Gazebo9. Specifically running the two launch files from #31 using the Dockerfile I shared in #46

roslaunch fetch_gazebo pickplace_playground.launch
roslaunch fetch_gazebo_demo pick_place_demo.launch
  1. Gazebo2: https://www.youtube.com/watch?v=EIdDnRGhXcI
  2. Gazebo7: https://www.youtube.com/watch?v=2flx4zVyoI4
  3. Gazebo9: https://youtu.be/izZZFZgtJYo

Surprisingly it worked in Gazebo9 this time- not on the first grasp attempt. Also note, this version did not have any changes from the diff which I posted above. I was preparing a Before and After video, to show the difference with and without the diff I posted here: #37 (comment) on the first few grasp attempts the robot touched the cube but didn't grasp it, and later it dropped the cube after moving it a couple of times.

@RDaneelOlivav

This comment has been minimized.

Copy link
Collaborator

commented Mar 21, 2019

Ok, I'll create a ROSject with a testing environment to test only the locomotion and the grasping in Gazebo9 Melodic, to see if we can improve that grasping so that the cube doesn't fall and also we can dig in into the base caster wheels problem.

Hope to have it today last hour.

@RDaneelOlivav

This comment has been minimized.

Copy link
Collaborator

commented Mar 22, 2019

Ok I tested it yesterday and yeah, it needs some adjustments in the physics. The pick and place works quite bad and as you said depends a lot on luck sometimes in Melodic Gazebo 9.
So I'm sharing here a Testing ROSject with a testing environment that is only the Table, the cube and Fetch: TEST-ROSJECT

fetchit_challenge testing_env.launch

This way we can concentrate on the vital elements.

I'm trying two things:

  1. Working on the base caster wheels based on what you did so that it moves correctly as it should. I don't have any real fetch to compare so I'll post videos of the movement so you Fetchers can validate.
    --> To go faster I would say that if you could commit those caster wheel improvements would be great so that we all work on common grounds @moriarty .

  2. I'm using a world that changes the physics. I'll post this next week probably. I'll add a world with more fine-tuned physics to see if this works.

  3. We are going to work on a different grasping solution to see if this improves the grasping performance. At the end of next Monday I'll have some results on that.

But anyway I would create a branch in the fetch_gazebo or something similar so that we can have the ROSject updated with the latest improvements from all of us.

What do you think @moriarty ?

@moriarty

This comment has been minimized.

Copy link
Member Author

commented Mar 22, 2019

Okay thanks @RDaneelOlivav I'll make the changes with the caster wheels, and I'll check the branch creation github settings and figure something out

moriarty added a commit to moriarty/fetch_gazebo that referenced this issue Mar 22, 2019

fetch_gazebo: add casters to fetch.gazebo.xacro
This adds 4 casters to the gazebo model, and updates the physics params.

This should fix fetchrobotics#31.

This is related to fetchrobotics#37

moriarty added a commit that referenced this issue Mar 25, 2019

fetch_gazebo: add casters to fetch.gazebo.xacro (#49)
This adds 4 casters to the gazebo model, and updates the physics params.

This should fix #31 and fix #35 

This is related to #37

@moriarty moriarty removed the help wanted label Mar 31, 2019

@moriarty

This comment has been minimized.

Copy link
Member Author

commented Apr 5, 2019

I'm going to close this issue now.

Further comments can go into remaining open issues or new issues.

@moriarty moriarty closed this Apr 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.