Joint::SetPosition alterate the simulation

[osrf-migration]

Original report (archived issue) by vincentrou (Bitbucket: vincentrou).

---

This is linked to an issue in gazebo_ros_pkgs where the use of a PositionJointInterface make the simulation unusable : ros-simulation/gazebo_ros_pkgs#479

To reproduce the problem with gazebo and ROS you can use the rrbot on this branch : https://github.com/vincentrou/gazebo_ros_demos/tree/position_joint_interface

I find out that the ROS library calls Joint::SetPosition in gazebo.
At the end, gazebo call Link::MoveFrame.
In this commit,
a line was added by @hsu (this line seems to freeze the simulation if there is a parent joint)

#!c++

this->SetWorldTwist(math::Vector3(0, 0, 0), math::Vector3(0, 0, 0));

When I remove this line everything seems to work again (like in gazebo 2).
Why this line has been added ? And should it be remove to fix the issue ?
I can make a PR.

Thank you for your great work on gazebo.

[osrf-migration]

Original comment by abdullah_dayem (Bitbucket: abdullah_dayem).

---

Just weighing in to say that I've experienced the same issue when mounting a UR5 arm on a Husky vehicle in gazebo7. The arm uses the PositionJointInterface and essentially acts as an anchor that prevents the vehicle from moving properly and causes it to float and descend slowly if dropped. This issue does not exist in gazebo2.

[osrf-migration]

Original comment by Pier-Marc Comtois-Rivet (Bitbucket: Pier-Marc Comtois Rivet).

---

Same problem here. We have a robot working in gazebo 2 but now we use gazebo 7. The physic is acting weirdly around the PositionJointInterface.

[osrf-migration]

Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

related to pull request #2598

[osrf-migration]

Original comment by vincentrou (Bitbucket: vincentrou).

---

To add some more visual information here is the problem, with the vehicle floating in the air and then slipping when trying to move forward
https://drive.google.com/file/d/0BwQ8uAotSmFuZk5WMkNqRUJkeWs/view?usp=sharing

Here is the desired behavior with the fix in the pull request #2598
https://drive.google.com/file/d/0BwQ8uAotSmFucFhYemw3UXpkUm8/view?usp=sharing

This has been done by launching this vehicle in gazebo : https://github.com/romea/robucar
The vehicle has 4 VelocityJointInterface for the wheels speed and 2 JointPositionInterface for the front steering.

[osrf-migration]

Original comment by miguel angel rodriguez (Bitbucket: RDaneelOlivaw).

---

Exact same problem here.
I have to joints actuated with PositionJointInterface and limits those joints move at a maximum speed in space. Is there a plan for fixing this issue?
Any provisional workaround?

[osrf-migration]

Original comment by vincentrou (Bitbucket: vincentrou).

---

There is fix here : pull request #2598 if you compile gazebo from source.

I try to push it on the default branch but @chapulina think that it could make some regression for other downstream code.
But I do not know any other use of gazebo controller other than gazebo_ros.
@RDaneelOlivaw @pmcrivet @abdullah_dayem maybe you could have some more argument to make it accepted ?

[osrf-migration]

Original comment by Ying Lu (Bitbucket: rosebudflyaway).

---

• changed state from "new" to "resolved"

Fix issue 2111 by providing options to preserve world velocity when set positions

→ <<cset d06a5ae>>

[osrf-migration]

Original comment by Ying Lu (Bitbucket: rosebudflyaway).

---

Note that the above comment is not true, I tried to fix this with a new PR, but it should be under review and NOT merged yet.
Not sure why this issue checker automatically generated the above comment and marked the issue as resolved
I didn't figure out a way to change it back to open or in review

[osrf-migration]

Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

• Edited issue description* changed state from "resolved" to "open"

Reopen accidental closing

[osrf-migration]

Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

bitbucket automatically closes issues based on text in commit messages
https://confluence.atlassian.com/bitbucket/resolve-issues-automatically-when-users-push-code-221451126.html

[osrf-migration]

Original comment by Ying Lu (Bitbucket: rosebudflyaway).

---

Thanks! @sloretz

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

• changed state from "open" to "resolved"

Merged in issue_2111 (pull request #2814)

Fix issue 2111 by providing options to preserve world velocity when set positions

Approved-by: Michael Grey grey@osrfoundation.org
Approved-by: Steven Peters scpeters@osrfoundation.org

→ <<cset 15e2ec8>>

[osrf-migration]

Original comment by Christos Gkournelos (Bitbucket: klapetos).

---

Are you sure that the above patch resolve the issue ?

I just tested with my mobile robot in gazebo9.0.0 and the problem remains.

@vincentrou
Have you tried this fix ?

[osrf-migration]

Original comment by mikaelarguedas (Bitbucket: mikaelarguedas, GitHub: mikaelarguedas).

---

Good to know a PR to address this has been merged ! As it changes API, I suppose it will not be made available in gazebo7? Is there a suggested workaround for gazebo7 (the version used with ROS Kinetic, Lunar and upcoming Melodic)?

[osrf-migration]

Original comment by vincentrou (Bitbucket: vincentrou).

---

@klapetos I confirm that the fix works fine on Gazebo9 (for my use at least)

@mikaelarguedas There is a workaround for gazebo7

https://github.com/vincentrou/gazebo_ros_demos/blob/position_joint_interface/rrbot_control/config/rrbot_control.yaml#L18

You can look here for more details : ros-simulation/gazebo_ros_pkgs#479 (comment)