|
| 1 | +.. _FeatureIdeas: |
| 2 | + |
| 3 | +Feature Ideas |
| 4 | +============= |
| 5 | + |
| 6 | +.. contents:: Table of Contents |
| 7 | + :depth: 2 |
| 8 | + :local: |
| 9 | + |
| 10 | +The following are feature ideas in no specific order. |
| 11 | +This list contains features that we think are important and can make for good contributions to ROS 2. |
| 12 | +:ref:`Please get in touch with us <Help>` before digging to a new feature. |
| 13 | +We can offer guidance, and connect you with other developers. |
| 14 | + |
| 15 | +Design / Concept |
| 16 | +---------------- |
| 17 | + |
| 18 | +* IDL format |
| 19 | + |
| 20 | + * Leverage new features like grouping constants into enums |
| 21 | + * Extend usage to ``.idl`` files with just constants and/or declare parameters with ranges |
| 22 | + * Revisit constraints of IDL interface naming, see `ros2/design#220 <https://github.com/ros2/design/pull/220>`_ |
| 23 | + |
| 24 | +* Create migration plan for ROS 1 -> ROS 2 transition |
| 25 | +* Uniqueness of node names, see `ros2/design#187 <https://github.com/ros2/design/issues/187>`_ |
| 26 | +* Specific "API" of a node in terms of topics / services / etc. in a descriptive format, see `ros2/design#266 <https://github.com/ros2/design/pull/266>`_ |
| 27 | +* Configuring QoS at runtime, see `ros2/design#280 <https://github.com/ros2/design/issues/280>`_ |
| 28 | + |
| 29 | +Infrastructure and tools |
| 30 | +------------------------ |
| 31 | + |
| 32 | +* Building |
| 33 | + |
| 34 | + * Consolidate build.ros2.org and ci.ros2.org |
| 35 | + * Provision macOS |
| 36 | + * Windows and Mac OS packages |
| 37 | + * Support profiles in ``colcon`` |
| 38 | + |
| 39 | +* Documentation |
| 40 | + |
| 41 | + * Improve documentation platform |
| 42 | + * Support for ``doc`` jobs on the `ROS 2 buildfarm <https://build.ros2.org>`__ |
| 43 | + * Consider consolidating with design.ros2.org |
| 44 | + * Provide three different kinds of content: |
| 45 | + |
| 46 | + * "demos" to show features and cover them with tests |
| 47 | + * "examples" to show a simple/minimalistic usage which might have multiple ways to do something |
| 48 | + * "tutorials" which contain more comments and anchors for the wiki (teaching one recommended way) |
| 49 | + |
| 50 | +New features |
| 51 | +------------ |
| 52 | + |
| 53 | +The trailing stars indicate the rough effort: 1 star for small, 2 stars for medium, 3 stars for large. |
| 54 | + |
| 55 | + |
| 56 | +* Logging improvements [\* / \*\*] |
| 57 | + |
| 58 | + * Configuration specified in a file |
| 59 | + * Per-logger configuration (enabling e.g. ``rqt_logger_level``) |
| 60 | + |
| 61 | +* Time related |
| 62 | + |
| 63 | + * Support rate and sleep based on clock |
| 64 | + |
| 65 | +* Parameters |
| 66 | + |
| 67 | + * enforce type |
| 68 | + |
| 69 | +* Additional Graph API features [\*\* / \*\*\*] |
| 70 | + |
| 71 | + * Introspect QoS setting for all (especially remote) topics |
| 72 | + * a la ROS 1 Master API: https://wiki.ros.org/ROS/Master_API |
| 73 | + * Event-based notification |
| 74 | + * Requires knowledge of the rmw interface which needs to be extended |
| 75 | + |
| 76 | +* Executor |
| 77 | + |
| 78 | + * Performance improvements (mostly around the waitset) |
| 79 | + * Deterministic ordering (fair scheduling) |
| 80 | + * Work with callback groups |
| 81 | + * Decouple waitables |
| 82 | + |
| 83 | +* Message generation |
| 84 | + |
| 85 | + * Catch-up message generation for languages not supported out-of-the-box |
| 86 | + * Mangle field names in message to avoid language specific keywords |
| 87 | + * Improve generator performance by running them in the same Python interpreter |
| 88 | + |
| 89 | +* Launch |
| 90 | + |
| 91 | + * Support use case of using ``xacro`` to perform substitutions before passing the result containing parameters |
| 92 | + * Use pytest for launch testing |
| 93 | + * Support for launching multi-node executables (i.e. manual composition) |
| 94 | + * Extend launch XML/YAML support: events and event handlers, tag namespaces and aliasing |
| 95 | + |
| 96 | +* Rosbag |
| 97 | + |
| 98 | + * Support recording services (and actions) |
| 99 | + |
| 100 | +* ros1_bridge |
| 101 | + |
| 102 | + * Support bridging actions |
| 103 | + |
| 104 | +* RMW configuration |
| 105 | + |
| 106 | + * Unified standard way of configuring the middleware |
| 107 | + |
| 108 | +* Remapping [\*\* / \*\*\*] |
| 109 | + |
| 110 | + * Dynamic remapping and aliasing through a Service interface |
| 111 | + |
| 112 | +* Type masquerading [\*\*\*] |
| 113 | + |
| 114 | + * a la ROS 1's message traits: https://wiki.ros.org/roscpp/Overview/MessagesSerializationAndAdaptingTypes |
| 115 | + * Requires knowledge of the typesupport system |
| 116 | + |
| 117 | +* Expand on real-time safety [\*\*\*] |
| 118 | + |
| 119 | + * For services, clients, and parameters |
| 120 | + * Expose more quality of service parameters related to real-time performance |
| 121 | + * Real-time-safe intra-process messaging |
| 122 | + |
| 123 | +* Multi-robot supporting features and demos [\*\*\*] |
| 124 | + |
| 125 | + * Undesired that all nodes across all robots share the same domain (and discover each other) |
| 126 | + * Design how to “partition” the system |
| 127 | + |
| 128 | +* Implement C client library ``rclc`` [\*\*] |
| 129 | +* Support more DDS / RTPS implementations: |
| 130 | + |
| 131 | + * Connext 6, see `ros2/rmw_connext#375 <https://github.com/ros2/rmw_connext/issues/375>`_ |
| 132 | + * Connext dynamic [\*] |
| 133 | + * RTI's micro implementation [\*] |
| 134 | + |
| 135 | +* security improvements: |
| 136 | + |
| 137 | + * more granularity in security configuration (allow authentication only, authentication and encryption, etc.) [\*] |
| 138 | + * integrate DDS-Security logging plugin (unified way to aggregate security events and report them to the users through a ROS interface) [\*\*] |
| 139 | + * key storage security (right now, keys are just stored in the filesystem) [\*\*] |
| 140 | + * more user friendly interface (make it easier to specify security config). Maybe a Qt GUI? This GUI could also assist in distributing keys somehow. [\*\*\*] |
| 141 | + * 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. [\*\*\*] |
| 142 | + * 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. [\*\*\*] |
| 143 | + |
| 144 | +Port of existing ROS 1 functionality |
| 145 | +------------------------------------ |
| 146 | + |
| 147 | +* Perception metapackage |
| 148 | + |
| 149 | + * Perception PCL |
| 150 | + |
| 151 | +* MoveIt |
| 152 | + |
| 153 | + * MoveIt Maintainers are tracking: https://discourse.ros.org/t/moveit-maintainer-meeting-recap-july-25th-2018/5504 |
| 154 | + |
| 155 | +* RQt |
| 156 | + |
| 157 | + * convert more plugins [\* each when dependencies are available] |
| 158 | + |
| 159 | +Reducing Technical Debt |
| 160 | +----------------------- |
| 161 | + |
| 162 | +* Extend testing and resolve bugs in the current code base |
| 163 | + |
| 164 | + * Waitset inconsistency |
| 165 | + * Multi-threading problems with components |
| 166 | + |
| 167 | +* Fix flaky tests. |
| 168 | +* Ability to run (all) unit tests with tools e.g. valgrind |
| 169 | +* API review, specifically user-facing APIs in rclcpp and rclpy |
| 170 | +* Refactor the rclcpp API into separate packages focused on a single aspect, rclcpp should afterward still provide the combined user-facing API |
| 171 | +* Revisit message allocators, consider using std::polymorphic_allocator to address problems |
| 172 | + |
| 173 | +* Modernization |
| 174 | + |
| 175 | + * Support/use exporting CMake targets (rather than using CMake variables like ``*_INCLUDE_DIRS``, ``*_LIBRARIES``) |
| 176 | + * Use C++17 filesystem features rather than custom code |
| 177 | + * Use pybind11 for rclpy |
| 178 | + * Move to f-strings in Python code |
| 179 | + * Use setup.cfg files for Python packages |
| 180 | + |
| 181 | +* Synchronize / reconcile design docs with the implementation. |
| 182 | + |
| 183 | + * Pre-release retrospective review (APIs, docs, etc.) |
| 184 | + |
| 185 | +* Address / classify pending tickets |
| 186 | +* Address TODOs in code / docs |
0 commit comments