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.
