0
$\begingroup$

Rosanswers logo

Greetings. My model combining a simple mobile base with the UR10 acts strangely when I add

which is needed for controlling the UR10 joints. The strange behavior is that the mobile robot resists motion (or maybe it's just the mobile base that does this). Two examples:

(1) If I publish a large velocity twist to the cmd_vel topic for the differential_drive_controller on the mobile base the two wheels spin quickly but the robot rotates only very slowly.

(2) If I publish a positive z-position to set_model_state, effectively dropping the robot from this height, it falls very slowly to the ground.

The "real time factor" is 1.00 so it's not as if the simulation is running slowly when the plugin is added. When I don't add the plugin the robot arm is floppy but it moves quickly, as one would expect (the base moves it around at the desired rate and it falls as fast as normal). The differential_drive_controller seems to be working fine and so does the arm_controller it's just that when I'm using the arm_controller the sim acts crazy. If I remove the diff-drive controller but keep arm_controller the weird behavior remains.

I will look through the husky simulator with UR5 enabled to try to find what is wrong with my robot.

When publishing an arm pose to arm_controller/command the manipulator moves at a reasonable speed relative to its base but the overall mobile robot is still very slow. For example, if I drop it from two meters and publish a manipulator pose the arm moves fine but the entire robot falls very slowly.

For reference, here is the source (except for ur10.urdf.xacro). The offending gazebo plugin tag is found in models/common.gazebo.xacro.

One other note: this question is also posted to answers.gazebosim.org. Is it frowned-upon behavior to post at both these sites?

*edit: First off, thanks for the information in the accepted answer. My inital attempt to resolve this was to replace PositionJointInterface in ur.transmission.xacro with VelocityJointInterface. This required changing

type: position_controllers/JointTrajectoryController

in arm_controller_ur10.yaml to

type: velocity_controllers/JointTrajectoryController

however, when I launch my simulation the following appears.

[ERROR] [1520431422.716199942, 0.480000000]: No p gain specified for pid.  Namespace: /arm_controller/gains/shoulder_pan_joint

Since I don't know how to specify gains for that controller, I tried another option you describe. For my second attempt, I reverted to the original configuration (PositionJointInterface with position_cotrollers) and added this line to my launch file.

  <rosparam file="$(find mobile_arm)/models/my_ur10/pid_for_gazebo_ros_control.yaml" command="load"/>

where pid_for_gazebo_ros_control.yaml contains just the following.

gazebo_ros_control:
  pid_gains:
    shoulder_pan_joint: {p: 100.0, i: 0.01, d: 10.0}
    shoulder_lift_joint: {p: 100.0, i: 0.01, d: 10.0}
    elbow_joint: {p: 100.0, i: 0.01, d: 10.0}
    wrist_1_joint: {p: 100.0, i: 0.01, d: 10.0}
    wrist_2_joint: {p: 100.0, i: 0.01, d: 10.0}
    wrist_3_joint: {p: 100.0, i: 0.01, d: 10.0}

This does remove the unwanted behavior but the position controller works poorly. For example, wrist_3_joint is oscillating and shoulder_lift_joint is sagging. My guess is that the PID gains need to be adjusted for each joint. Since my aim is to treat motion control for both the UR10 and the mobile base as black boxes, I'm disinclined to invest time trying to get decent behavior from the PositionJointInterface with PID compensation.

The next route seems to be to replace Gazebo 7 with 9, but a couple of users (ros-simulation/gazebo_ros_pkgs#479) are reporting that the preserveWorldVelocity flag in Gazebo 9 is no longer resolving the problem so I'm hesitant to risk breaking my installation by moving to Gazebo 9. Please let me know any thoughts you have on the matter.

edit2: After going ahead with gazebo9 installation my simulation won't launch because

ResourceNotFound: ur_gazebo

Trying

$ sudo apt install ros-kinetic-universal-robot

fails because it depends on ros-kinetic-ur-gazebo, which depends on ros-kinetic-gazebo-ros "but it is not going to be installed." It seems to me that I cannot use the universal_robot package with gazebo9. Do you think that's correct?

edit3: Installing universal_robot from source resolved the "ResourceNotFound: ur_gazebo" problem.

edit4: In common.gazebo.xacro I have added the following line but the unwanted behavior is still there.

    <preserveWorldVelocity>1</preserveWorldVelocity>

Is that not how one is supposed to disable the regression?


Originally posted by raequin on ROS Answers with karma: 368 on 2018-03-02

Post score: 2


Original comments

Comment by Martin Günther on 2018-03-08:
Re edit1: You can see how to specify gains for the velocity controller here: https://github.com/ThomasTimm/ur_modern_driver/blob/master/config/ur5_controllers.yaml . Note however that these values are for the real UR5. For my Gazebo UR5, I use {p: 100.0, i: 0.0, d: 0.1} .

Comment by Martin Günther on 2018-03-08:
The UR10 is heavier, so you probably have to increase the p value.

Comment by Martin Günther on 2018-03-08:
Re edit4: I don't think that's how it works. Gazebo9 added the option of specifying that flag in a function call, but the source code of the ros_control gazebo plugin has to be changed to actually call that function with the flag. Until then, installing gazebo9 solves nothing.

Comment by jayess on 2018-03-20:
@raequin are you saying that the problem is not solved? You have accepted an answer already so if this is a new problem (even if related) please create a new question and reference this one.

Comment by raequin on 2018-03-20:
@jayess excuse me if I have muddied the waters. The accepted answer pinpoints the cause of the problem and offers a couple of solutions. The latest edit I made to this question gives details of how, starting with the accepted answer, the problem was resolved in my case.

Comment by jayess on 2018-03-20:
No problem, but the body of a question isn't the appropriate place for a solution to a problem (i.e., an answer). Can you please put your solution as an answer instead?

Comment by Martin Günther on 2018-03-21:
I've updated my answer, no need to add another answer.

Comment by raequin on 2018-03-21:
Great! Thank you both.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

It's this really annoying regression in Gazebo: https://github.com/ros-simulation/gazebo_ros_pkgs/issues/612 . Basically everyone using ros_control (and many other plugins) + Gazebo is affected by this, and it looks like it won't get fixed in ROS Kinetic / Gazebo 7. :(

For workarounds, see the issue I've linked to.

The problem is that there is a regression in the Joint::SetPosition() method in Gazebo. Previously, it only did just that (it set the joint angle). Later, the implementation of that method was changed so that it also reset the link velocity of the link connected to the joint to zero - this is why your robot is falling so slowly: Gravity pulls the robot down, but the joint controller always involuntarily stops that falling motion when it sets the joint angle. Since the gravity force now doesn't work properly, the mobile base loses proper contact to the ground (you can see that when you visualize contacts in the Gazebo GUI); this is why the base doesn't properly respond any more.

If you do any of the workarounds in the issue (adding pid_gains, using the VelocityJointInterface or EffortJointInterface instead of the PositionJointInterface), the ros_control Gazebo plugin won't call the Joint::SetPosition() method any more, thereby avoiding the problem.

Please note that you also have to do the workaround for any other Gazebo plugin that might call the Joint::SetPosition() method, such as the mimic joint plugin.

Edit 2018-03-21: Now there is a third option to avoid this bug (the first two being (1) adding pid_gains and (2) using the VelocityJointInterface or EffortJointInterface). Option (3) is to install Gazebo 9 (from deb packages, or from source) and the newest version of gazebo_ros_pkgs (from source until 2.5.15 is released). This bugfix has been added in PR 688, but only for Gazebo 9.


Originally posted by Martin Günther with karma: 11816 on 2018-03-05

This answer was ACCEPTED on the original site

Post score: 5


Original comments

Comment by gvdhoorn on 2018-03-05:
This seems like a clear case of a regression. Are there issues reported against Gazebo proper for this @Martin Günther? Or is it all in gazebo_ros_pkgs?

Comment by Martin Günther on 2018-03-05:
Yes, this is the relevant Gazebo issue: https://bitbucket.org/osrf/gazebo/issues/2111/joint-setposition-alterate-the-simulation . It's linked from ros-simulation/gazebo_ros_pkgs#612 . I prefer pointing people to #612 instead of the actual Gazebo issue, since #612 has the workarounds.

Comment by raequin on 2018-03-07:
Thank you very much. My work on resolving this has not thus far succeeded and the description seemed too long for a comment so I edited the question. Since I'm new to this site I did not know whether or not you'd be notified of that change. Hence this comment.

Comment by raequin on 2018-03-21:
The third option is the one that I went with. It's a simple fix.

Comment by raequin on 2018-04-24:
When moving this project to a different computer the system gives errors like

Could not load controller 'arm_controller' because controller type 'position_controllers/JointTrajectoryController' does not exist.

Is there something I need to do to have ROS use the latest gazebo_ros_kpgs?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.