Create ros2 branch to host just support packages

[gavanderhoorn]

@ros-industrial/motoman-admins, @ros-industrial/motoman-admins-oem, @ros-industrial/motoman-push: I'd like to create a ros2 branch which would be used to host just the _support packages after they've been converted to ROS 2.

motoman_driver will not be ported to ROS 2, and the MoveIt configurations are very much outdated and not easy to port.

The new branch would likely essentially be what kinetic-devel...gavanderhoorn:motoman:ros2 contains, but then not on a private fork.

I plan to also add XML based launch files, but only for viewing the robots in RViz. Like this: gavanderhoorn/motoman@ros2...gavanderhoorn:motoman:add_view_launchfiles.

I'm opening this discussion to ask for some input from the other maintainers about this plan.

[ted-miller]

My only comment is regarding organization. All the other ROS2 related files are outside of this repository. I think it would be easier to understand that way.

[gavanderhoorn]

That's a good point. I do like the fact we'd keep the (Git) history connected if we just create a branch here though.

[gavanderhoorn]

What about a compromise? We fork ros-industrial/motoman to yaskawa-global/motoman, then create a ros2 branch and merge in the changes from kinetic-devel...gavanderhoorn:motoman:ros2.

All ROS 1 support would stay here on ros-industrial.

Everything ROS 2 related would be over at yaskawa-global.

The fork keeps provenance clear and history in-tact. We'd update the readme here to direct ROS 2 users to yaskawa-global/motoman (and conversely: ROS 1 users to ros-industrial/motoman from the yaskawa-global/motoman readme).

[ted-miller]

I'm fine with maintaining history through a fork. But I'd want to rename the fork to something other than motoman. That name makes sense in the context of ros-industrial. But it doesn't work for yaskawa-global where we're hosting multiple things for controlling a motoman robot.

[marip8]

It would be nice if these packages were agnostic of ROS so they could be used in the context of ROS1 and ROS2. This should be possible if building with colcon by installing hooks for setting the ament prefix path and ROS package path environment variables. We do this in RICB here. We could either potentially copy the contents of the macros we need from RICB or use RICB and specify it as a build dependency for generating the required CMake package files

[gavanderhoorn]

That would be nice, and we discussed this earlier (Yaskawa-Global/motoros2#73 (comment)), but I'm not sure that's going to work given a potential issue with how Gazebo loads models. I still haven't had time to look into that.

[gavanderhoorn]

A sdformat_urdf PR related to this: ros/sdformat_urdf#20.