You're reading the documentation for a development version. For the latest released version, please have a look at Iron.
The following are feature ideas in no specific order. This list contains features that we think are important and can make for good contributions to ROS 2. Please get in touch with us before digging into a new feature. We can offer guidance, and connect you with other developers.
Leverage new features like grouping constants into enums
Extend usage to
.idlfiles with just constants and/or declare parameters with ranges
Revisit constraints of IDL interface naming, see ros2/design#220
Create migration plan for ROS 1 -> ROS 2 transition
Uniqueness of node names, see ros2/design#187
Specific “API” of a node in terms of topics / services / etc. in a descriptive format, see ros2/design#266
Fix per-package documentation builder to be able to document build artifacts, i.e. messages, services, actions, etc.
Add documentation examples of using ROS 2 with Jupyter notebooks.
Add documentation for implementing a new RMW.
Provide three different kinds of content:
“demos” to show features and cover them with tests
“examples” to show a simple/minimalistic usage which might have multiple ways to do something
“tutorials” which contain more comments and anchors for the wiki (teaching one recommended way)
The trailing stars indicate the rough effort: 1 star for small, 2 stars for medium, 3 stars for large.
Logging improvements [* / **]
Configuration specified in a file
Per-logger configuration (enabling e.g.
Support rate and sleep based on clock
Additional Graph API features [** / ***]
Introspect QoS setting for all (especially remote) topics
a la ROS 1 Master API: https://wiki.ros.org/ROS/Master_API
Requires knowledge of the rmw interface which needs to be extended
Performance improvements (mostly around the waitset)
Deterministic ordering (fair scheduling)
Catch-up message generation for languages not supported out-of-the-box
Mangle field names in message to avoid language specific keywords
Improve generator performance by running them in the same Python interpreter
Support for launching multi-node executables (i.e. manual composition)
Extend launch XML/YAML support: events and event handlers, tag namespaces and aliasing
Support recording services (and actions)
Support bridging actions
Unified standard way of configuring the middleware
Remapping [** / ***]
Dynamic remapping and aliasing through a Service interface
Type masquerading [***]
a la ROS 1’s message traits: https://wiki.ros.org/roscpp/Overview/MessagesSerializationAndAdaptingTypes
Requires knowledge of the typesupport system
Expand on real-time safety [***]
For services, clients, and parameters
Expose more quality of service parameters related to real-time performance
Real-time-safe intra-process messaging
Multi-robot supporting features and demos [***]
Undesired that all nodes across all robots share the same domain (and discover each other)
Design how to “partition” the system
Support more DDS / RTPS implementations:
RTI Connext DDS Micro (implemented, not enabled by default or officially supported).
More granularity in security configuration (allow authentication only, authentication and encryption, etc.) [*]
Integrate DDS-Security logging plugin (unified way to aggregate security events and report them to the users through a ROS interface) [**]
Key storage security (right now, keys are just stored in the filesystem) [**]
More user friendly interface (make it easier to specify security config). Maybe a Qt GUI? This GUI could also assist in distributing keys somehow. [***]
A way to say “please secure this running system” with some UI that would auto-generate keys and policies for everything that is currently running. [***]
If there are hardware-specific features for securing keys or accelerating encryption/signing messages, that could be interesting to add to DDS/RTPS implementations that don’t use it already. [***]
Fix flaky tests on https://ci.ros2.org/view/nightly.
Ability to run (all) unit tests with tools e.g. valgrind, clang-tidy, clang static analysis (scan-build), ASAN, TSAN, UBSAN, etc.
API review, specifically user-facing APIs in rclcpp and rclpy
Refactor the rclcpp API into separate packages focused on a single aspect, rclcpp should afterward still provide the combined user-facing API
Revisit message allocators, consider using std::polymorphic_allocator to address problems
Synchronize / reconcile design docs with the implementation.
Address / classify pending tickets
Address TODOs in code / docs
Remove tinyxml as a dependency