One of my personal projects that I hope to continue work on is a proper swift implementation of RCL. Implementing the core RCL functionality is simple and straightforward, but message generation is still a point of confusion. I tried using some of esteve’s client libraries as a reference, but these are rather old and need updating. I see this in the Roadmap for ros2, “Catch-up message generation for languages not support out-of-the-box.” A lot of the documentation on ros2 Design is also old in this respect. I checked out rclpy and rclcpp’s implementations but these are spread across multiple repo’s and it’s not necessarily clear how the whole process is supposed to work. Should we all be using just .idl now? Are .msg, .srv files still the go-to or are they more legacy? I know updating documentation takes a lot of time and effort, but would anyone be able to help clarify the best current practice for how we are supposed to implement message generation/serialization for community client libraries?
1 Like
You don’t need this feature. You can simply build ROS 2 from source with a custom packages for a new language and it will be used. The item on the roadmap would only enable to e.g. install Debian (which don’t use your custom generator) and then build your custom package which then generates code for the message packages already installed.
If you don’t need any of the features which is exclusively available in .idl you should just stick to .msg / .srv / .action files.
The high level summary:
- declare that you package contains a message generator or provides resources needed for generated messages (runtime):
- for C++ that is both done by a single package: rosidl_generator_cpp
- for Python these two aspects are separated:
- register your CMake file which performs the code generation to be invoked by interface packages
- provide the CMake logic performing the code generation
- commonly that involved invoking Python to parse the interface files and then expand templates for your target language
- (depending on the targeted language those expanded templates might need to be compiled)
- all the artifacts need to be installed (if not requested otherwise by flags passed from the message package)
1 Like