In the ROS Driver repo Building section it has the following commands are included to clone a second repo in addition to the Universal Roots ROS driver repo
# clone fork of the description to use the calibration feature
$ git clone -b calibration_devel https://github.com/fmauch/universal_robot.git src/fmauch_universal_robot
It looks like the Universal Robots driver calibration depends on the packages ur_e_description and ur_description
I have a few questions:
- Why are the dependent packages not replicated in the Universal Robots Driver repo so the Universal Robots Driver repo can exist on it’s own without needing to clone a second repo?
- Are there any other packages in the
fmauch universal_robotrepo that the Universal Robot driver requires?
I’d like to create a workspace that does not include the fmauch repo. Instead I’d like to have my own custom versions of the packages in the fmauch repo (probably using the same package names that are in the fmauch repo). But I’d still like to include the calibration features and any other that are required for normal operation.
Having the description separated from the actual driver implementation is quite common, actually. In this particular case, it is also due to historical reasons. The universal_robot repository has been there for a long time, while different driver implementations came along.
For running the driver alone, only the description packages and ur_msgs from that repository are needed. However, if you want to use other functionality contained in that repo (such as MoveIt!, Gazebo, etc…)
If you are not happy with the state of packages, you can always fork it and add your own modifications / delete stuff you don’t want. What is it you want to achieve by not using this repository?
I’m very happy with the state of the packages in the universal_robots repo. What you have provided is a fantastic! Thank you very much for your time and effort! I am relatively new to ROS and I am simply thinking about how to manage all the ROS packages required for the universal robot from the perspective of configuration control. At this time we are only using a UR3e.
Currently we are using the universal_robots repo. However, we need to use a different kinematics solver with Moveit. This requires a change to the file ur3_e_moveit_config/config/kinematics.yaml. (If there is a better way to manage this setting I’d be happy to learn about it. I tried changing the kinematics solver through ROS parameters but could not get it to work.) We could make a copy of the ur3_e_moveit_config package. I think this package would need a unique name to avoid name collisions? We also probably want some other custom files for Gazebo, etc. Then I realized it might be easier to take the required packages from the universal robots repo and add our customized packages (which is when I started this topic in the forum). Then we can track and control everything we use in our own repo. I could also use a package name of ur3_e_moveit_config (which is the best name for the package) without colliding with the universal_robots repo packages.
At this point I am not sure what the best option is. I’m just exploring what all the options are.
Prom my point of view the best option would be to create your own moveit_config package. The moveit packages in the universal_robots repository are kind of starting points for standalone robots.
Usually when you use MoveIt! in an application, you create your own moveit_config for that particular application, which will in turn also contain obstacles in the scene and so on. However, I’ve never used MoveIt! much myself, so I’ll forward you to the very good Moveit! tutorials for this.
And yes, that package should have a different name than ur_3_e_moveit_config.
I do not recommend making modifications in the universal_robots repository directly, as you will then have to maintain this fork. As soon as anybody changes something upstream you will have to merge it in manually in order to receive the updates. Especially with a repo like this which is already a fork and will hopefully one day get merged back, this will produce work in the coming future.
So in your case, I think the best option would be to create your own packages in your own git repository inside your catkin workspace.
Thank you for the advice. I agree with all your points. I’ll keep the universal_robots repo included with the Universal Robots driver as described in the ROS Driver repo Building section. I’ll add custom items where necessary and reuse the universal_robots packages when possible. I think this is the best solution.