Documentation on using controllers.yaml correctly with ros_control

[ri-ceres]

Following the documentation in the README.md, I am trying to configure ros_control using the configuration provided by the MoveIt! Setup Assistant. I am using ROS Kinetic and have the goal of trying to continuously control a UR5e with a Robotiq 2f-140 gripper.

The MoveIt! Setup Assistant does not output a config/controllers.yaml, but does create config/ros_controllers.yaml, while the ur_modern README.md specifies to "add the desired controller to the controllers.yaml in the urXX_moveit_config/config folder". This seems to imply that this modification should be appended to the config/ros_controllers.yaml that is generated by the MoveIt! Setup Assistant.

This makes sense because it looks similar to the existing ur_modern_driver/config/ur5e_controllers.yaml. So, by copying the content into a new file called my_robot_moveit_config/config/controllers.yaml and adding the controller_list: needed for ROS control, we should have the necessary changes.

Finally, modifying the paths in ur_modern_driver/launch/ur5e_ros_control.launch to reflect the path of the new configuration should load the ros_control config :

  <rosparam file="$(find my_robot_moveit_config)/config/controllers.yaml" command="load"/>

However, following this logic, the controller_manager can't spawn /follow_joint_trajectory:

[ERROR] [1557271637.324512055]: Could not load controller 'follow_joint_trajectory' because the type was not specified. Did you load the controller configuration on the parameter server (namespace: '/follow_joint_trajectory')?

Are the instructions for using ros_control incomplete, or am I interpreting them incorrectly? I have found other issues such as #261, but they don't provide any more details.

For reference, my new my_robot_moveit_config/config/controllers.yaml looks like this:

      # MoveIt-specific simulation settings
      moveit_sim_hw_interface:
        joint_model_group: controllers_initial_group_
        joint_model_group_pose: controllers_initial_pose_
      # Settings for ros_control control loop
      generic_hw_control_loop:
        loop_hz: 500
        cycle_time_error_threshold: 0.01
      # Settings for ros_control hardware interface
      hardware_interface:
        joints:
          - shoulder_pan_joint
          - shoulder_lift_joint
          - elbow_joint
          - wrist_1_joint
          - wrist_2_joint
          - wrist_3_joint
          - finger_joint
        sim_control_mode: 1  # 0: position, 1: velocity
      # Publish all joint states
      # Creates the /joint_states topic necessary in ROS
      joint_state_controller:
        type: joint_state_controller/JointStateController
        publish_rate: 500
      controller_list:
        - name: ""
          action_ns: gripper
          type: GripperCommand
          default: true
          joints:
            - finger_joint
        - name: /pos_based_pos_traj_controller
          action_ns: follow_joint_trajectory
          default: True
          type: FollowJointTrajectory
          joints:
            - shoulder_pan_joint
            - shoulder_lift_joint
            - elbow_joint
            - wrist_1_joint
            - wrist_2_joint
            - wrist_3_joint
      pos_based_pos_traj_controller:
        type: position_controllers/JointTrajectoryController
        joints:
          - shoulder_pan_joint
          - shoulder_lift_joint
          - elbow_joint
          - wrist_1_joint
          - wrist_2_joint
          - wrist_3_joint
        constraints:
          goal_time: 0.6
          stopped_velocity_tolerance: 0.05
          shoulder_pan_joint: {trajectory: 0.1, goal: 0.1}
          shoulder_lift_joint: {trajectory: 0.1, goal: 0.1}
          elbow_joint: {trajectory: 0.1, goal: 0.1}
          wrist_1_joint: {trajectory: 0.1, goal: 0.1}
          wrist_2_joint: {trajectory: 0.1, goal: 0.1}
          wrist_3_joint: {trajectory: 0.1, goal: 0.1}
        stop_trajectory_duration: 0.5
        state_publish_rate:  500
        action_monitor_rate: 10
        gains:
          shoulder_pan_joint:
            p: 100
            d: 1
            i: 1
            i_clamp: 1
          shoulder_lift_joint:
            p: 100
            d: 1
            i: 1
            i_clamp: 1
          elbow_joint:
            p: 100
            d: 1
            i: 1
            i_clamp: 1
          wrist_1_joint:
            p: 100
            d: 1
            i: 1
            i_clamp: 1
          wrist_2_joint:
            p: 100
            d: 1
            i: 1
            i_clamp: 1
          wrist_3_joint:
            p: 100
            d: 1
            i: 1
            i_clamp: 1
      vel_based_pos_traj_controller:
         type: velocity_controllers/JointTrajectoryController
         joints:
           - shoulder_pan_joint
           - shoulder_lift_joint
           - elbow_joint
           - wrist_1_joint
           - wrist_2_joint
           - wrist_3_joint
         constraints:
            goal_time: 0.6
            stopped_velocity_tolerance: 0.05
            shoulder_pan_joint: {trajectory: 0.1, goal: 0.1}
            shoulder_lift_joint: {trajectory: 0.1, goal: 0.1}
            elbow_joint: {trajectory: 0.1, goal: 0.1}
            wrist_1_joint: {trajectory: 0.1, goal: 0.1}
            wrist_2_joint: {trajectory: 0.1, goal: 0.1}
            wrist_3_joint: {trajectory: 0.1, goal: 0.1}
         stop_trajectory_duration: 0.5
         state_publish_rate:  500
         action_monitor_rate: 10
         gains:
            #!!These values have not been optimized!!
            shoulder_pan_joint:  {p: 1.2,  i: 0.01, d: 0.1, i_clamp: 1}
            shoulder_lift_joint: {p: 1.2,  i: 0.01, d: 0.1, i_clamp: 1}
            elbow_joint:         {p: 1.2,  i: 0.01, d: 0.1, i_clamp: 1}
            wrist_1_joint:       {p: 1.2,  i: 0.01, d: 0.1, i_clamp: 1}
            wrist_2_joint:       {p: 1.2,  i: 0.01, d: 0.1, i_clamp: 1}
            wrist_3_joint:       {p: 1.2,  i: 0.01, d: 0.1, i_clamp: 1}
         # Use a feedforward term to reduce the size of PID gains
         velocity_ff:
            shoulder_pan_joint: 1.0
            shoulder_lift_joint: 1.0
            elbow_joint: 1.0
            wrist_1_joint: 1.0
            wrist_2_joint: 1.0
            wrist_3_joint: 1.0
         state_publish_rate:  500

[gavanderhoorn]

This appears to be a cross-post of Modifications for launching UR5e ros_control with new MoveIt! config on ROS Answers. Please do not cross-post like that. It leads to split discussions and duplication of effort.

Decide which post you want to keep open, close the other and I'll see if I can answer your question.

[ri-ceres]

To clarify my intent, I posted an issue here specifically regarding ur_modern_driver documentation that arose from the more general question you referenced at ROS Answers. As a relative novice to ROS, I expected ROS Answers to operate like Stack Overflow. Part of this expectation was the assumption that I could post any well-formulated question there and get the ROS community to contribute different answers, while opening specific package issues such as this in GitHub where maintainers could respond.

Without intending to sound unappreciative, the only reason why I see not to post in both places is because you are a common moderator between the two and it splits your own attention and effort. I acknowledge those are both valuable resources to the community, but I feel like making your help conditional on closing questions elsewhere is an impediment to community growth and is discouraging to newcomers.

As a general practice, I do agree that issues and questions should be organized into appropriate channels, but its not always clear where to ask for help when the community is so small and fragmented.

[ri-ceres]

I do think the ur_modern_driver documentation could be improved for implementing ros_control. So, given the choice, I would prefer to continue the conversation here rather than ROS Answers.

[gavanderhoorn]

Part of this expectation was the assumption that I could post any well-formulated question there and get the ROS community to contribute different answers, while opening specific package issues such as this in GitHub where maintainers could respond.

That makes sense and I may have missed the generic vs pkg-specific differences between the two posts.

Not an excuse, but we get so many people spamming their support requests on just about every channel they find it's almost the first thing we check.

It's obviously completely ok to leave both posts open if they are sufficiently different.

---

Reading your post on ROS Answers I'm not entirely sure where the difference is you mention. It's both essentially the same question and you show the same files. The only difference I can see is that you mention GripperCommand in your ROS Answers post.

[gavanderhoorn]

As to the documentation on usage with ros_control: I'm fine with someone contributing that, but the thing is that the usage of those controllers is so generic and similar across all ros_control compatible robots that it would be really unfortunate if we'd have to duplicate all of that in this repository.

I'll take a look at your configuration but as a first comment I would say that it's not necessarily possible to just merge whatever the MSA creates and whatever is already there in this repository (or any other ros_control compatible package). The MSA makes some specific assumptions that may not hold outside of the types of usage that were considered when that specific screen for it was created.

It's also not flexible enough I believe to be able to deal with all of combinations of hw, hw interfaces and controller configurations, so some manual work will almost always be required.

[gavanderhoorn]

Can you please push your MoveIt config to somewhere so I can inspect it?

It's probably because it's already 18h here, but the controllers.yaml you show contains so many lines that don't make sense to me I'm having a hard time figuring out what's going on.

My second suggestion would be to just not use the output of the MSA. Configuring the use of ros_control here is not rocket science and the MSA output adds a bunch of stuff that's either not going to get used or is even unnecessary.

---

Note also btw: the controllers.yaml file that is shown in the readme is what configures the client side of all of this (where MoveIt is the client and the driver is the server).

The file that you show also seems to contain stanzas for the configuration of ros_control controllers. It's not needed to configure those yourself, as they are already provided by ur_modern_driver (here for the UR5 fi). It's certainly not SOP to put the ros_control configuration and the MoveIt client side controller configuration in the same file and/or in the MoveIt configuration package.

I would advise against mixing all of this and would suggest to keep things separate.

[ri-ceres]

Thanks for understanding. I also agree that the intrinsic content of the questions is similar, and it wasn't my intent to spam.

I realize there is some manual work after running the MSA, and I've tried to include the necessary changes. I pushed the config here.

When you say that controllers.yaml contains stanzas for ros_control configuration that aren't necessary, can you clarify what is necessary? Is it simply the addition of the line /pos_based_pos_traj_controller ? It sounds like ros_controllers.yaml (as produced by MSA) is completely unnecessary if I follow what you are saying.

[ri-ceres]

Looking at this a little more, it appears that even if I use the default config for ros_control (with name remapped to /pos_based_pos_traj_controller in the moveit config from the universal_robot repo), there is a problem with the namespaces when I launch the robot.

I can launch ros_control using urXX_ros_control.launch, but when I launch moveit with rviz /follow_joint_trajectory fails to load.

roslaunch urXX_ros_control.launch robot_ip:=$ROBOT_IP
roslaunch urXX_moveit_config ur5_moveit_planning_executing.launch
roslaunch urXX_moveit_config moveit_rviz.launch config:=true

[ERROR] [1557335470.932682774]: Could not load controller 'follow_joint_trajectory' because the type was not specified. Did you load the controller configuration on the parameter server (namespace: '/follow_joint_trajectory')?
[ERROR] [1557335471.934234]: Failed to load follow_joint_trajectory

This can be fixed by remapping /follow_joint_trajectory to /pos_based_pos_traj_controller/follow_joint_trajectory in unniversal_robot/urXX_moveit_config/launch/urXX_moveit_planning_execution.launch, but I'm not sure if this is the recommended way of dealing with this for using ros_control.

<launch>
  <arg name="sim" default="false" />
  <arg name="limited" default="true"/>
  <arg name="debug" default="false" />

  <!-- Remap follow_joint_trajectory -->
  <remap if="$(arg sim)" from="/follow_joint_trajectory" to="/arm_controller/follow_joint_trajectory"/>
  <remap unless="$(arg sim)" from="/follow_joint_trajectory" to="/pos_based_pos_traj_controller/follow_joint_trajectory"/>

  <!-- Launch moveit -->
  <include file="$(find ur5_e_moveit_config)/launch/move_group.launch">
    <arg name="limited" default="$(arg limited)"/>
    <arg name="debug" default="$(arg debug)" />
  </include>
</launch>

[miguelprada]

It seems to me that you're mixing relatively unrelated settings inside a single controllers.yaml file, namely:

• the joint_state_controller, pos_based_pos_traj_controller and vel_based_pos_traj_controller keys contain configuration for the controllers that the driver should use, this should probably go into your robot bringup configuration/package
• the controller_list key contains configuration MoveIt needs in order to know how to send the trajectories it generates to the robot driver, this should probably go into your moveit configuration/package
• the generic_hw_control_loop and hardware_interface (and possibly moveit_sim_hw_interface) keys contain configuration for a ros_control_boilerplate/moveit_sim_controller "simulator" setup, this should probably go into your simulator configuration/package

---

Ok, I just saw some edits in @gavanderhoorn's comments, that I hadn't read in the email notifications, which make this post somehow redundant.

[gavanderhoorn]

@miguelprada: no, your comment actually succinctly summarises my ramblings.

[miguelprada]

As to the documentation on usage with ros_control: I'm fine with someone contributing that, but the thing is that the usage of those controllers is so generic and similar across all ros_control compatible robots that it would be really unfortunate if we'd have to duplicate all of that in this repository.

I mostly agree. My impression is that your issue is mainly about connecting MoveIt to the underlying driver and are not specific to this driver nor ros_control. Hopefully this tutorial may help you, but otherwise I think this is better suited for being dealt with on ROS Answers.

Will therefore close this issue, but feel free to continue discussing if you disagree with the reasoning above.

[gavanderhoorn]

Just to keep things connected: @ri-ceres, I believe #245 tracks the need for "improved documentation" about ros_control configuration (although, as @miguelprada notes in his comment, it would be more about how to interface with the driver when it's configured to use ros_control, as ur_modern_driver already provides the necessary ros_control configuration).

If you want, you could add a comment there to highlight the need for perhaps some improved examples on how to configure MoveIt for the different modes of ur_modern_driver.