ROS2 port

[whoenig]

There is many reasons to move to ROS2. This issue is for discussing how to do it.

General

1. Should we have ROS1 and ROS2 development side-by-side, or focus from a certain point on ROS2, only (with only bugfixes for the ROS1 version, if needed)? [My opinion: Due to constrained resources, I prefer the second option.]
2. What compatibility do we have to keep and what can we change. [My opinion: ROS2 is a breaking change. Ideally, the Python user scripts will keep working without changes, but everything else, e.g., config files or system architecture is IMO up for redesign.]

Architecture

1. The overall architecture of having a single crazyswarm_server should remain.
2. It should still be possible to simulate scripts without ROS.
3. The repo should be re-organized to be a proper ROS package (or stack), i.e., it should not contain a workspace. This will allow easier interoperability with other ROS packages. This will also allow us to use the regular CI/CD tools.
4. With the nativelink backend, we should re-think the threading model (currently: 1 thread per channel/radio). The new backend will do the load balancing over radios for us. The crazyswarm_server could either use no threads, or use a threadpool with uniform distribution of Crazyflies, regardless of the channel. The latter seems to only have an advantage for the ICP-based tracking.

New/Changing Features

1. It should be possible to add/remove Crazyflies dynamically (like it was possible with crazyflie_ros). This is important as we move from centralized control to distributed swarm management. Thus, it should also be possible to use chooser (or a similar tool), while the server is running.
2. Avoid exceptions for failures that occur with just a few Crazyflies. Use ROS errors instead.
3. We should not restrict ourselves to fixed URIs anymore - it should be possible to change the datarate and other parts of the address.
4. Updating params should not require an additional service call. Changed params via broadcasts should be properly reflected on the param server.

Thoughts/ideas welcome!

[jpreiss]

(converted to Discussion so we can have threaded topics)

General

Should we have ROS1 and ROS2 development side-by-side, or focus from a certain point on ROS2, only (with only bugfixes for the ROS1 version, if needed)? [My opinion: Due to constrained resources, I prefer the second option.]

I agree, especially because Noetic is the last official ROS1 release and we would have to maintain systems running old versions of Ubuntu to test Crazyswarm on hardware.

What compatibility do we have to keep and what can we change. [My opinion: ROS2 is a breaking change. Ideally, the Python user scripts will keep working without changes, but everything else, e.g., config files or system architecture is IMO up for redesign.]

I agree.

Off the top of my head, the only thing I might want to break in the Python API is the collision avoidance (see #481).

I wouldn't mind if we break something w.r.t. initialization as long as we keep the main commander APIs compatible.

It might be nice if the embedded YAML part of the launch file remained compatible, or at least could be updated to the new format with regex search and replace, or failing that maybe we provide a Python script à la 2to3. Working configurations are valuable!

[jpreiss]

For the ROS2 version I suggest we make a new repo crazyswarm2 under your lab's github account. Or we could create a github account specifically for crazyswarm.

[knmcguire]

Can the Bitcraze github account be of service here or do you prefer it on your lab's account @whoenig ?

[whoenig]

I prefer it on https://github.com/IMRCLab - this is essentially advertisement for my lab as well as an indication for my funding agency that I am disseminating the results as promised in the proposal.

[jpreiss]

Architecture

1. The overall architecture of having a single crazyswarm_server should remain.
2. It should still be possible to simulate scripts without ROS.

Fully agree for both.

3. The repo should be re-organized to be a proper ROS package (or stack), i.e., it should not contain a workspace. This will allow easier interoperability with other ROS packages. This will also allow us to use the regular CI/CD tools.

I don't have strong feelings about this. Is there any downside to making this change?

4. With the nativelink backend, we should re-think the threading model (currently: 1 thread per channel/radio). The new backend will do the load balancing over radios for us. The crazyswarm_server could either use no threads, or use a threadpool with uniform distribution of Crazyflies, regardless of the channel. The latter seems to only have an advantage for the ICP-based tracking.

Looking at Figure 3 in our paper, it does seem like the latency benefit from multithreaded ICP tracking is significant for large numbers of CFs. However, in practice I think very few Crazyswarm users fly more than 20 CFs at once. I strongly prefer simplicity so I would lean towards single-threaded tracking. But "you can fly 49 CFs" is a big part of our claimed contribution. Since ICP tracking is easily expressed as a pure function, maybe we could use std::async to get multithreading with a small impact on the overall code structure?

[whoenig]

The repo should be re-organized to be a proper ROS package (or stack), i.e., it should not contain a workspace. This will allow easier interoperability with other ROS packages. This will also allow us to use the regular CI/CD tools.

I don't have strong feelings about this. Is there any downside to making this change?

• Initial setup is harder, because users now have to create their own ROS workspace (although we could provide a helper script)
• Files will move around from the current location, although not by very much

Agreed with the other points! It will be difficult to test with 49, but I think we could test with 20 and then also check what the CPU utilization looks like in that case.

[knmcguire]

About the ROS package, yes the initial setup would be harder but discoverability would be much better. Like when people google crazyflie and ros together, they will get to this old package: http://wiki.ros.org/crazyflie. It would be nice to have new users go to the right place for the package right away.

Is it also perhaps an idea to even further split it up? The lib-object tracker could already be it's own package as it can also be used for other robotic platform or perhaps separating the server part from the teleop?

Maybe I'm suggesting something completely crazy in terms of how the frameworks is put together, but the idea of smaller more manageable packages sound more appealing then everything in one bunch.

[knmcguire]

Ah wait, my last suggestion to split it up goes completely to your first architecture requirement @whoenig. let's discuss it next time we meet

[whoenig]

I have a separate ROS package just for tracking (https://github.com/IMRCLab/motion_capture_tracking). This already has a (partial) ROS2 port and CI for both ROS1 and ROS2. It would be possible to re-evaluate the option to keep it separate for Crazyswarm2 (and use ROS topics to communicate between different nodes), but I am a bit worried about latency and computing requirements. What's nice right now is that I can run the Crazyswarm on a pretty old Laptop and it just works:-)

[knmcguire]

yeah true, but that still requires code that needs to be maintained at two places which is usually is asking for problems.... Let's see if this is an option or not, as it would be good not to compromise quality for the sake of maintainability

Perhaps we work along the way of a separate place for the main code for motion tracking and ROS wrappers with submodules in both the repo you have now and crazyswarm2 in the future?

[knmcguire]

How much would rely on completing the native link aka crazyflie-link-cpp for the ROS2 port? https://github.com/bitcraze/crazyflie-link-cpp. There were still some issues with this I've heard?

[whoenig]

I already have a crazyflie_cpp port that uses the new link. There are open firmware issues, but they are small enough that I do have working workarounds for them. So in short: the ROS2 effort is not blocked.

[knmcguire]

oke great!

Seems that the windows build might also be fixed soon. so let's keep an eye on that.

[whoenig]

The fork is now available at https://github.com/IMRCLab/crazyswarm2. The readme describes the current status (and I'll try to update it there, as it progresses). @knmcguire: This should suffice for you to test on Windows. I expect this to be bumpy:-/ I wasn't able to enable windows CI, due to dirk-thomas/vcstool#205 not being picked up in ros-tooling.

[knmcguire]

Great! Still installing it in on windows as we speak... the QT install took forever and installing ignition fortress took a big chunk of my time.

Anyway, perhaps we should start a discussion in crazyswarm2 fork now :) I'll start an issue if I run into problems on windows.