Closed ri-ceres closed 5 years ago
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.
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.
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.
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.
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.
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.
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.
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>
It seems to me that you're mixing relatively unrelated settings inside a single controllers.yaml
file, namely:
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/packagecontroller_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 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/packageOk, I just saw some edits in @gavanderhoorn's comments, that I hadn't read in the email notifications, which make this post somehow redundant.
@miguelprada: no, your comment actually succinctly summarises my ramblings.
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.
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
.
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 createconfig/ros_controllers.yaml
, while the ur_modern README.md specifies to "add the desired controller to thecontrollers.yaml
in theurXX_moveit_config/config
folder". This seems to imply that this modification should be appended to theconfig/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 calledmy_robot_moveit_config/config/controllers.yaml
and adding thecontroller_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 theros_control
config :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: