ROS2 Support

[tpanzarella]

First off, thanks for the nice work on this project. We use it heavily in our analysis stack.

I had looked to see if there was ROS2 support for ros_numpy and could not find it anywhere. To that end, I've forked the repo and ported it so that this package now works with ROS2 Foxy. My working repo is here with the relevant branch being foxy-devel (it should be the default).

All unit tests are passing and I also tested it live against an Ouster LiDAR, ROS2 Foxy, Cyclone DDS, where I was only calling numpify(...) on a PointCloud2 and that seems to be working as well. I will do some deeper checks to further ensure correctness.

There was some effort involved in the port. The big things being:

• Moving from catkin to ament and making sure it all builds with colcon
• tf.transformations is not available in ROS2 AFAIK. So, a local copy of transformations.py has been added to the project
• Some of the msg field constructors in ROS2 were incompatible with the current code base so I ported those too
• I took the liberty to convert tabs to spaces. I hope that does not offend anyone.

The full diff is here.

All of the above said, if you think the port is acceptable, it would be great to figure out how to best keep the ROS and ROS 2 projects together. I'm open to any suggestions.

[tpanzarella]

Thinking on this more, maybe the ROS 2 version should be renamed ros2_numpy and we let them evolve separately while making a best effort to keep the projects in parity in terms of features. I think the changes to get this to work in ROS 2 may have been significant enough that it is not worth the effort of trying to keep the ROS 1 and ROS 2 versions in the same repository. Especially since ROS 1 is now "done" at Noetic and ROS 2 is a pretty fast moving train these days with rolling releases.

Just a thought. Would like to get some feedback from stakeholders of this project.

[tpanzarella]

Providing an update here....

I'd like to try to get ros_numpy into the ROS 2 Foxy distribution. To attempt to facilitate that, I have taken the following steps in my fork:

• I've renamed my fork to ros2_numpy so it will not conflict with ros_numpy. However, the fork relationship on Github has been preserved.
• I initialized the version numbering of the ROS 2 port to 2.0.3. The MAJOR was set to 2 to indicate ROS 2. The MINOR and PATCH were left as 0 and 3 respectively to preserve provenance to the the ROS 1 ros_numpy from which the ROS 2 port was bootstrapped. I did not really want to do that, however, AFAIK a unique release tag is necessary to integrate with the ROS 2 bloom release machinery.
• Building on the previous point, I created a new release tag for 2.0.3 in my fork.

Again, I'd love some feedback as to how to best keep the ROS 1 and ROS 2 ports of this project together. The steps I have taken (short of any feedback) seems to me to be a reasonable way forward.

Thoughts, comments, etc. are welcome and encouraged. Thank you.

[DLu]

@tpanzarella Any progress on releasing your fork to the buildfarm?

@eric-wieser Other option would be to create a ros2 branch on this repo

[tpanzarella]

@DLu No progress to report. If there is community interest and those with the relevant buildfarm skills that can help, I am happy to do what I can to facilitate. For clarity, I still have interest in getting the ros2 support in the distributions.

Tangentially related and something I have not had time to fully investigate, one of the unit tests fails when using the default RMW but passes when using Cyclone (my default). It is the round tripping on the data marshaling through the middleware stack. So as to not conflate the issues too much, I won't expand any further here. But, it may cause some CI issues and warrant further investigation as to where the bug lives (in the middleware or perhaps in the test itself).

[krishk16]

Thanks for the great work!
I used to build ros_numpy using python3 setup.py install. How to use your fork in ROS2 Foxy?

You can import it into your workspace 'src' folder and use colcon build to make the workspace.

If it fails, use rosdep to install the required depends before building