Split into ROS and non-ROS repositories? about robot_cal_tools HOT 3 OPEN

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

from robot_cal_tools.

@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.

from robot_cal_tools.

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

from robot_cal_tools.