Bug: Regression in simulated Fetch robot (Melodic, Gazebo 9)

[ben-fido]

I think the simulated Fetch robot is not so good in Gazebo version 9, compared to the current performance in Gazebo 2.

New software: Ubuntu 18.04, ROS Melodic, Gazebo 9
Current software: Ubuntu 14.04, ROS Indigo, Gazebo 2.2.3

Issue description:
When moving the Fetch robot base in simulation, the base motion is very jerky. Like the robot is driving on carpet or with variable friction.
The motion is so jerky that it makes the upper body and arm shake.
Driving straight is impossible.

This issue means the base navigation is not good and it breaks the demo. See issue #30.

Steps to reproduce:

Load Fetch robot in an empty world:

roslaunch fetch_gazebo simulation.launch
roslaunch fetch_gazebo_demo fetch_nav.launch

Either, test forward motion using tele-op:
rosrun teleop_twist_keyboard teleop_twist_keyboard.py

Or command the robot to x=3, y=3:
rostopic pub /move_base_simple/goal geometry_msgs/PoseStamped '{header: {stamp: now, frame_id: "map"}, pose: {position: {x: 3.0, y: 3.0, z: 0.0}, orientation: {w: 1.0}}}'

Results:

Forward straight-line motion:

Drive robot forward in ROS Indigo, Gazebo2:
Previously the motion is smooth and the robot drives almost in a straight-line, with a small variance due to friction.
https://youtu.be/2XgbXEiBYdE

Drive robot forward in ROS Melodic, Gazebo9:
The robot motion is jerky and unstable.
https://youtu.be/XXnWqwZ_bqU

Move base using Navigation stack:

Navigate to position (3,3) in ROS Indigo, Gazebo2:
The robot moves quickly and smoothly, with a nice velocity curve.
https://youtu.be/YIsQBLa9Aig

Navigate to position (3,3) in ROS Melodic, Gazebo9:
The robot motion is jerky and the speed changes. The robot misses the goal position and takes multiple attempts.
https://youtu.be/FyyGwdU6qRE

---

I also try to drive the robot forward in RDS cloud sim (ROS Melodic). The motion is jerky and the robot does not drive straight.
https://youtu.be/62bjO1FIRQo

[moriarty]

Yes this was reported in https://github.com/fetchrobotics/fetch_ros/issues/102 which I've moved to this repository #36.

We're looking into the issue and have narrowed it down to something between Gazebo7 and Gazebo9

[moriarty]

@ben-fido can you check with the change from #49

[RDaneelOlivav]

How can I review or test these changes? Its a branch or something in your own space?
@moriarty

[moriarty]

I'm uploading a video to YouTube

[moriarty]

the branch for PR #49 is https://github.com/moriarty/fetch_gazebo branch: add-casters-for-gazebo9

[moriarty]

https://youtu.be/5u44H43ArdQ

[RDaneelOlivav]

Ah ok its a fork on your space in a branch? So to test it we have to download your version and checkout the add-casters-for-gazebo9? Is that right ? Am I missing something?
@moriarty

Great the video by the way. So that's the corrected moving base or is there any error? You fetchers are the best to indicate that ;).

[RDaneelOlivav]

Ok, I've created a ROSject with your https://github.com/moriarty/fetch_gazebo branch: add-casters-for-gazebo9.

Here is the LINK: ROSJECT

I've posted two videos to show the state in which I execute it:

MOVE BASE DEMO

PICK and Place Demo

Id this more or less the behavior that you are getting?
What would be the desired outcome and performance?
I've created this ROSJect so everyone can test it in the same environment and code.
The simulation will go slower if you use a free account but apart from that, it should have the same outcome.
On monday we will try to work on a different approach on the pick and place.

@moriarty Let me know the desired outcomes, and where you think the simulation needs work so that we all can know exactly what we are aiming for.

[moriarty]

👍 yeh the Move Base Demo looks good to me.

In this simple case of the base is going to a pose, in an empty world so the laser scanners aren't much help. So I think with #49 being merged we can close this issue.

In #30, the robot keeps rotating after arriving at the table, that is not fixed by PR #49 and will require more fine tuning.

👍 the Pick & Place Demo, does fail as shown in your video sometimes if you're unlucky and have collision with the object, but it's better than originally reported in #31 because it doesn't always fail.

[RDaneelOlivav]

Ok today I'll work mainly on the Pick and PLace issue to see if we get somewhere better

[RDaneelOlivav]

I made some adjustments and tests and it seems that at least the pick and place is improved?
Here is the ROSject: ROSJECT
What do you think?
PICk and Place with improved frictions

I made some tests with the original wheel frictions and with higher and detected that the movement of the arm affected a lot the position. This would affect the pick and place if it only made snapshots planning:

Normal Friction

High friction
Where can upload these changes? A branch?

[moriarty]

Yes, we usually use: Fork & Branch method/style for Git.

So if you create a fork, and make a new branch with the changes, and submit a PR, others can checkout your Branch without knowing or setting up your Fork, because they can checkout the PR once it is opened.

[RDaneelOlivav]

Ok done the Fork and Branch pull request ;)
#59