Split into ROS and non-ROS repositories?

[schornakj]

I've been using robot_cal_tools with ROS2, and I would like to contribute back some of the work I did in my weird fork to enable this without adversely affecting ROS1 projects that use this repo. Since some of the RCT packages contain ROS nodes, I think we will need to reorganize the structure of this repo.

A reasonable initial approach could be:

• Make rct_optimizations and rct_image_tools pure CMake packages.
• Move rct_ros_tools and rct_examples to a new repository with parallel branches for ROS1 and ROS2.

I recall that one of the goals of this project is to integrate it with the industrial_calibration project, with robot_cal_tools providing the underlying optimization libraries and industrial_calibration providing ROS nodes. I think restructuring this repo a little bit will actually help with that integration process down the road.

[marip8]

We should move forward with the changes to rct_optimizations and rct_image_tools sooner rather than later. Our current development efforts may make it difficult to reconcile those packages (at least rct_optimizations) if we wait too long

[schornakj]

@marip8 It looks like we're halfway through this, since rct_optimization and rct_image_tools are pure-CMake packages now. Seems like a good time for us to strategize.

What do you think would be a good way to handle rct_ros_tools? The two important parts of that package are:

• The target loader utilities, which take a ROS1 nodehandle to load target properties from parameters.
• The command line cal app, which is a standalone node that interacts with the parameter server and performs TF lookups.

I was originally thinking that some parts (e.g. the data_set library) could be moved into the non-ROS part of this repo, but on further investigation they ultimately depend on ROS parameter loading so that might not be feasible.

For the time being I'm going to make a separate repo for my current ROS2 port of rct_ros_tools, since I'd like to take advantage of the improvements we made this summer to the core calibration libraries without being blocked by this.

[marip8]

I think we could move the data and target loading functions into rct_image_tools since they primarily deal with loading targets and images. I believe yaml-cpp and xmlrpcpp are both ROS-independent C++ packages that could be used in a ROS1 or ROS2 context, so we could probably just revise the parameter loader utilities to deal in terms of those objects and string filepaths rather than ROS1 node handles