The carma-msgs repo currently uses the convention of making separate ROS 1 and ROS 2 interface description packages so that any new CARMA interfaces can be back-ported to legacy ROS 1 systems. This leads to several issues, mainly that there are unnecessary duplicate message, service, and action description files.
Additionally, the CI build script for carma-msgs hard-codes the interfaces packages to build. I assume the install.sh script's structure predates the carma_cmake_common package and the colcon build sytem, both of which prevent us from having to create duplicate interfaces packages for ROS 1 and ROS 2.
Since CARMA builds all ROS packages with colcon, we should update the package manifest files (package.xml) to use version 3. This will allow us to use condition="$ROS_VERSION == 1" and condition="$ROS_VERSION == 2" to limit certain dependencies to certain ROS versions. We can also check the ROS_VERSION environment variable to tailor packages' CMake configurations for either ROS 1 or ROS 2.
Reasoning for new functionality
Having duplicate ROS interface packages is confusing to user and developers, and it is a pain to maintain.
Summary
The
carma-msgs
repo currently uses the convention of making separate ROS 1 and ROS 2 interface description packages so that any new CARMA interfaces can be back-ported to legacy ROS 1 systems. This leads to several issues, mainly that there are unnecessary duplicate message, service, and action description files.Additionally, the CI build script for
carma-msgs
hard-codes the interfaces packages to build. I assume theinstall.sh
script's structure predates thecarma_cmake_common
package and thecolcon
build sytem, both of which prevent us from having to create duplicate interfaces packages for ROS 1 and ROS 2.Since CARMA builds all ROS packages with
colcon
, we should update the package manifest files (package.xml
) to use version 3. This will allow us to usecondition="$ROS_VERSION == 1"
andcondition="$ROS_VERSION == 2"
to limit certain dependencies to certain ROS versions. We can also check theROS_VERSION
environment variable to tailor packages' CMake configurations for either ROS 1 or ROS 2.Reasoning for new functionality
Having duplicate ROS interface packages is confusing to user and developers, and it is a pain to maintain.