Add ROS 2 support

[aprotyas]

This is a meta-ticket that I'll use to track progress for multiple smaller items. Notably:

• trac_ik_lib: ([trac_ik_lib, trac_ik_examples]: Add support for ROS 2 #2)
  • Migrate parameters business to be rclcpp compliant.
    • ⚠️API break⚠️: As a fallout of this directive, I've changed a TracIK constructor to accept a std::string of the URDF XML robot description file, rather than a std::string of the parameter housing the robot description XML. This was necessary because parameters are not global in ROS 2, and because I didn't want to publish the XML on a robot_description topic (although that's how it's done in robot_state_publisher).
  • Convert roscpp logging macros to rclcpp logging macros.
  • Move from boost::posix_time::ptime to std::chrono::time_point.
    • This is not exactly needed, but I'd like to remove superfluous boost dependencies.
• trac_ik_kinematics_plugin: ([trac_ik_kinematics_plugin]: Add support for ROS 2 #9)
  • Write the plugin for moveit2.
  • Update moveit documentation about the trac_ik library and about writing said plugins.
• trac_ik_python: ([trac_ik_python]: Add suport for ROS 2 #5)
  • Move from rospy to rclpy.
  • Use required ament_cmake_python functions to install the package.
  • Remove boost dependencies.
  • Move from tf/tf_conversions to tf2/tf2_kdl.
  • Settle on the trac_ik Python class API. What to do about the URDF string? Ideally it should mimic trac_ik_lib.
  • Update tests to be ROS 2 compliant.
• trac_ik_examples: ([trac_ik_lib, trac_ik_examples]: Add support for ROS 2 #2)
  • Convert ROS 1 examples to ROS 2 equivalents.
  • Migrate launch file to be ROS 2 compliant.
  • Import a pr2.urdf file into the package launch tree.
    • This can be achieved by manually calling xacro on the pr2.urdf.xacro from the pr2_description package.
    • This is necessary because pr2_common is not published as a ROS 2 package.
  • Migrate parameters business to be rclcpp compliant.
  • Move from boost::posix_time::ptime to std::chrono::time_point.
    • This is not exactly needed, but I'd like to remove superfluous boost dependencies.
• Miscellaneous:
  • Add tests for trac_ik_lib. #10
  • Enable common linters. #11
  • Update documentation to reflect changes. #7
  • Move all packages from catkin to ament.
  • Change name to trac_ik2?
  • Add CI. #8
    • Add GitHub Actions CI for Linux #18
    • Add CI workflow for Windows. #20
  • Remove previous release CHANGELOGs.
  • Ensure packages build on Windows. #13
  • Remove previous tags.
  • Migrate from math3d.h to Eigen for matrix math. THANKS! #26 (comment)
• Community (?):
  • Add GitHub issue/PR templates. #21
  • Add docker image(s) support for the package. #22
  • Configure helpful utilities like dependabot and mergify. #23

[aprotyas]

Notes:

1. How should the parameter migration be done? Should TracIK really inherit from rclcpp::Node just for logging and some param services?
2. Should TracIK be composable?
   i. This has to happen if I want to add support for a URDF XML subscription callback for TracIK.

[SteveNguyen]

Hi, I'm trying to get trac_ik_python compiling for ros2 but without success...
I made the changes from rospy to rclpy and the like, but I mostly have problems with ament and swig right now.
Do you have any clue on how to properly do that by any chance?

[aprotyas]

Hi @SteveNguyen, unfortunately I haven't had the time to look at trac_ik_python yet. The "Move from rospy to rclpy" directive I've noted was only an initial hunch, and as you've seen already, there is probably a bunch more to do on top of that. I think you're on the right track because the rospy -> rclpy migration should be a big part of the port, but I'm not sure what to do after that.
TLDR: Give me a few hours to investigate, and I will report back here with any details I find. If you don't mind, can you open a draft PR for the ROS 2 port of trac_ik_python? It'd be easier to track progress that way.

Edit:
@SteveNguyen, can you give me some items to base this conversation off of? What swig problem are you having? Are you not able to use the swig functions in CMake? How about for ament? Linking errors? trac_ik_python needs a little more careful consideration while porting because, as you can tell, it's not just a regular Python package. I'll update the TODO list to reflect this. Please share any updates/thoughts you may have!