ROS 2 Support

[Yadunund]

Hello,

I'd like to enquire whether this repository is actively maintained and if so any plans to migrate these packages to ROS 2? If you're willing I can help with the migration. The ABB ROS 2 driver, abb_ros2 currently houses a few robot descriptions which I think should be moved here instead. As one of the maintainers of abb_ros2, I can assist with the move.

[gavanderhoorn]

I'd like to enquire whether this repository is actively maintained

it's maintained in the sense that community contributions would be considered for merging, and any really serious breakages would be addressed.

That's what the community badge in the readme conveys.

and if so any plans to migrate these packages to ROS 2?

if the users of these packages would be interested, a migration could happen.

I'd personally not be opposed to it, but we do not have anything planned.

If you're willing I can help with the migration.

that would certainly be appreciated.

The ABB ROS 2 driver, abb_ros2 currently houses a few robot descriptions which I think should be moved here instead.

yes, indeed. I agree.

I contributed that observation when abb_ros2 was created, but the then-maintainers didn't agree.

Some initial comments:

• we should probably first either merge or close all open PRs
• migrating support packages is relatively trivial. I've done it a couple of times, such as with the packages in ros-industrial/motoman. I believe a similar approach could be taken here
• I really, really prefer XML based launch files over Python. Especially for test_ or view_ launch files. I added some to the branch I linked in the previous bullet (gavanderhoorn/motoman@ros2...gavanderhoorn:motoman:add_view_launchfiles). XML launch files can be included/imported into Python launch files, so there's no strong argument for complicating things unnecessarily
• related to the launch files: a trend in ROS 2 migrations for/with robot drivers and related packages has been to reduce duplication to the extreme -- fi by introducing (many) more arguments to launch and .xacro files. Examples would be variants from robot series, or even package names. While reducing duplication is a good idea, in ROS-Industrial we've traditionally accepted and perhaps even preferred duplication over parameterisation as it tends to reduce complexity. I would prefer having multiple launch files, even if they are mostly identical, with very clear names in very clear locations over having a single launch file with 5 arguments. ROS (especially ROS 2) is complex enough as it is. We should try to avoid complicating things even further
• similar to how this was recently changed in the Universal Robots description package after some discussion (Remove ros2_control tag from package (and move it to ur_robot_driver) UniversalRobots/Universal_Robots_ROS2_Description#114), I would strongly prefer to keep ros2_control optional everywhere. I would probably even make it a strong requirement on my side. As nice as ros2_control is, there are many more use-cases for support packages besides using them with the/a driver. Note: I'm not saying we should do it exactly as the UR PR does it, I only linked it as an example and a link to the discussions that led up to it

and perhaps optional:

• take a look at migrating the description packages in abb_experimental first, then migrate packages to ROS 2

[Yadunund]

Thanks for the quick response @gavanderhoorn.

I think it would be great to have a ros2 branch in this repo and like you said, the conversion is fairly trivial.
I'm aligned with you on leaving ros2_control optional. This would also make maintaining the ros2 branch easier since we don't have to keep up with any breaking changes in ros2_control.

we should probably first either merge or close all open PRs

Is that something you can help with? I could help move things along if given the necessary permissions.

take a look at migrating the description packages in abb_experimental first, then migrate packages to ROS 2

I saw that repo but am wary of the requirement to have things exhaustively tested first before transferring over here. I'd like to propose we

• merge/close outstanding PRs
• Port to ROS 2
• As time permits, move descriptions from other repos including abb_ros2 and abb_experimental

Let me know what you think.

[gavanderhoorn]

I saw that repo but am wary of the requirement to have things exhaustively tested first before transferring over here.

all of those packages have been available for multiple years already.

If there were any serious issues with them, they would probably have been identified by now.

If they weren't, keeping those packages in the experimental repository for even longer is not going to suddenly get any latent issues exposed/identified.

I would just migrate everything over, then port everything to ROS 2 in one go.

[Yadunund]

Sure that works too although I fear it will stretch the timeline for ROS 2 support in this repo as more time and effort will be needed port the additional packages and potentially makes reviews larger too. Plus it will require a single contributor to work on it whereas if we port this repo first, community members can contribute by porting the packages from abb_experimental.