Use new ur_description_model #97
Conversation
fmauch
added
enhancement
fmauch
force-pushed
the
description_dev
branch
4 times, most recently
from
69a9829 to
f880ca9
Compare
| @@ -26,7 +26,7 @@ Debug flag that will get passed on to ur_common.launch | |||
|
|
|||
| Automatically send URScript to robot to execute. On e-Series this does require the robot to be in 'remote-control' mode. With this, the URCap is not needed on the robot. | |||
|
|
|||
| ##### kinematics_config (default: "$(find ur_e_description)/config/ur3e_default.yaml") | |||
| ##### kinematics_config (default: "$(find ur_description)/config/ur3e/default_kinematics.yaml") | |||
|
|
|||
| Kinematics config file used for calibration correction. This will be used to verify the robot's calibration is matching the robot_description. | |||
There was a problem hiding this comment.
Suggestion: be vocal about the fact that the default value will not result in accurate FK results -- as it's really just a default, with the values of a "random robot".
There was a problem hiding this comment.
Added a note in 00b09ba
| <arg name="headless_mode" default="false" doc="Automatically send URScript to robot to execute. On e-Series this does require the robot to be in 'remote-control' mode. With this, the URCap is not needed on the robot."/> | ||
|
|
||
| <!-- robot model --> | ||
| <include file="$(arg robot_description_file)"> | ||
| <arg name="limited" value="$(arg limited)"/> |
There was a problem hiding this comment.
would you also want to allow to pass joint_limits_params in order to be able to configure the former limited/unlimited variant?
There was a problem hiding this comment.
That doesn't exist any more. All joints get their full +-2pi range, except the elbow, as that is the only joint which can't actually use that range.
That solves works-around the issue sufficiently.
Edit: oh wait, are you asking whether it should still be possible to use different joint limits?
There was a problem hiding this comment.
I think, it's a valid question to raise what arguments should be forwarded / at what point users should write their own description launch files instead.
My initial thought:
- kinematics_params: This is the most important one that will depend on the *actual robot *in use
- joints_limits_params: This might be changed depending on the use case (e.g. the robot being mounted on a table). I would naively assume that in this situation would provide their own xacro and thus their own launchfile. Therefor I wouldn't forward this argument.
- physical_params: This is only depending on the actual robot model, I don't see any necessity to forward this.
- visual_params: This is only depending on the actual robot model, I don't see any necessity to forward this.
- transmission_hw_interface: As far as I understand, this is used for gazebo, so I wouldn't forward it.
- safety_limits: Probably should be forwarded, see Add support for ros_control joint limits? #198. Or is this something different?
- safety_pos_margin: see above
- safety_k_position: see above
There was a problem hiding this comment.
This seems to come down to how do we expect users to use the driver with custom setups (ie: just about any real use of the driver)?
Personally I would probably create a custom version of one of the load_urNN.launch files, override the defaults for the relevant args and then make the bringup .launch file in ur_robot_driver/launch use that .launch file instead of the defaults.
That would only require the ability to pass a path to my custom .launch file to the bringup .launch.
It would not be very convenient to always have to provide all args to the bringup .launch.
visual_params: This is only depending on the actual robot model, I don't see any necessity to forward this.
So I know of at least one use-case which would become possible by allowing access to this arg: ros-industrial/universal_robot#267, and this was actually partly what motivated me to suggest moving to a completely parameterised _macro.xacro: the ability to override specific aspects of the visual model of the robot.
There was a problem hiding this comment.
I think, I'll stick with the current implementation, as we actually want users to provide their own calibration file. If users want to modify other things themselves, they should bring along their own description launch file, as @gavanderhoorn suggested.
Documenting this still has to be done.
There was a problem hiding this comment.
Documentation added in f6a7328
fmauch
force-pushed
the
description_dev
branch
2 times, most recently
from
b54831e to
c4cfef3
Compare
|
This should now be ready apart from the fact, that using the melodic-devel-staging currently breaks moveit-compatibility. Once melodic-devel-staging gets merged into melodic-devel we should be able to simply merge this. |
fmauch
force-pushed
the
description_dev
branch
from
f6a7328 to
643e252
Compare
|
@fmauch Do you know that the status is on this one? |
|
I'll work on ros-industrial/universal_robot#538 next to get this forward. |
|
I've rebased this branch ontop of the current master. |
This PR can be used for testing ros-industrial/universal_robot#477. Therefore, this is also the testing branch for ur16e support (see #73).
Note: This PR will not be merged before there's any decision on testing ros-industrial/universal_robot#477.