ROS2 Support

[theseankelly]

Hey @whoenig -- I've been working on porting this ROS package to ROS2 and I'm happy to say I've reached full functionality for the core crazyflie_driver package on ROS2 Eloquent.

Current working branch: https://github.com/theseankelly/crazyflie_ros/tree/ros2

There's still some work to be done, and I propose using this issue to track the tasks in case anyone is curious or looking for ROS2 support.

• crazyflie (metapackage)
  • not started
• crazyflie_controller
  • not started
• crazyflie_cpp
  • ROS2 port (working branch here)
  • Fix cmake scripts to detect cmake/catkin/ament properly
• crazyflie_demo
  • not started
• crazyflie_description
  • not started
• crazyflie_driver
• crazyflie_tools
  • not started

[theseankelly]

There's also the issue of how to merge/maintain this fork. I think we have two options and I'll leave it up to you, @whoenig:

1. I can maintain a fork and rename it crazyflie_ros2
2. Create a ros2 or distro (eloquent) branch in this crazyflie_ros project

Option 2 seems to be the most common in ROS packages right now (example) unless the ROS2 version of the package is a complete rewrite. In this case, I'm attempting to keep feature/naming/API pairity between ROS1/ROS2. It took me a while to get used to the idea, but it seems like its easier to maintain patches between ROS1/ROS2 as well as manage a single release repo if you were ever to release this to the ROS index.

[whoenig]

This looks great - thanks Sean! I have not looked into ROS2 in detail, but had the plan to work on a port in the fall of this year while also merging crazyswarm and crazyflie_ros into one package. This merge will be a breaking change, in the sense that some of the parameter/topic names (especially for the launch files) will not be fully compatible.

Moving forward, I prefer option 2 - I think fragmentation by forks is a great "risk" in open-source projects in general. I could give you push access to the repo (there seems to be no way to restrict access to a particular branch for my github account type, so this would assume that you'll only push to the ros2 branch), or I can create a branch and you submit PRs to that branch. Depending on how different the ROS1 and ROS2 implementations will get, the merge of crazyswarm -> crazyflie_ros might then only happen for the ROS2 version in the fall.

Some other notes:

• Once we have a separate branch, we should also setup continuous integration. I'd be interested in trying github actions, since Travis CI is very slow in adding newer OS images.
• This will also give the opportunity to extend to Mac and Windows platforms (crazyflie_cpp/tools work on Mac, but not yet Windows).
• I currently don't like the design that the crazyflie_cpp repo "knows" about ROS by providing cmake files. I think we need to find an alternative solution here. There are two options: a) requiring that crazyflie_cpp is installed as a library, or b) duplicating the code to build (a specific version of crazyflie_cpp) inside the crazyflie_ros package. I think b) is probably easier to handle and allows us to keep crazyflie_cpp and crazyflie_tools as submodules.

[theseankelly]

Sounds good. The choice for push access vs submitting PRs is entirely up to you. I'll likely submit changes via PR either way -- probably better to have one person doing merges unless you don't want to be bothered with code reviews for ROS2.

CI -- agreed! GitHub actions is the way to go for ROS projects. I've recently set this up for work and can help if needed.

crazyflie_cpp -- agreed. I just submitted a PR which changes crazyflie_cpp into a standard cmake project. This is the recommended way to incorporate third party, non-ROS libs into the ROS index. Using colcon in ROS2 to build is pretty easy, but I think standard cmake packages present some challenges in ROS1; not sure. Either way, I think this is a better way to go since crazyflie_cpp isn't really a ROS node.

Another idea is to merge crazyflie_cpp and crazyflie_tools into a single repo with a module based cmake architecture (cmake -DBUILD_MODULE_TOOLS=OFF to disable the tools binaries, for example).

[whoenig]

I created a ros2 branch, for which you can submit PRs. If it ends up being too annoying or I am too slow, I can still give you direct push access later. I'd love to look over the changes as well, since that will allow me to learn about ROS2 as we go.

CI: Do you know if people use it for ROS1 as well or is Travis still the preferred way? Moving forward, we should definitely go with the github actions for the ros2 branch, but it might also be worthwhile to upgrade other repositories/branches for me, especially since github actions seem to have more OS images.

Crazyflie_cpp: This was a nice change - thanks. Originally, I had in mind to have no ROS-related files in there (i.e., no package.xml), but lets see how far we can go this route. Either way, your refactoring is certainly nicer than how it was before. Moving crazyflie_cpp and crazyflie_tools into the same repo would be a possibility. However, the only benefit would be to reduce the overhead to update submodules (which can be pretty annoying), or do you see other advantages, too?