Future features and enhancements

[mahmoud-ghalayini]

Do we have any clear road map on the library's future features and enhancements?

[minggangw]

For the features, we ever tagged some issues with feature, while, I think some of them are already outdated.

For the enhancement, I submitted some PRs in my mind but don't have a doc/issue to track them.

Do you have any idea to share?

[mahmoud-ghalayini]

I have a couple of ideas from my own implementation using the library

1. External Parameter Access

What we need: Built-in API to get/set parameters on other ROS 2 nodes, not just the local node.

Why we need it:

• Remote monitoring and configuration management
• Dashboards need to query parameters from multiple nodes
• Parameter synchronization across distributed systems
• Currently requires manually managing service clients for rcl_interfaces/srv/GetParameters, SetParameters, ListParameters, and DescribeParameters
• Every application has to reimplement this boilerplate

Current workaround: Custom service that manually creates service clients for each parameter operation (~200 lines of code)

---

2. JSON-Safe Message Serialization

What we need: Messages that are directly JSON-serializable without custom conversion logic.

Why we need it:

• TypedArrays (Float64Array, Int32Array, etc.) don't serialize properly with JSON.stringify()
• Web APIs, REST endpoints, and WebSockets require plain JSON
• Logging and debugging tools expect JSON-compatible data
• Every web-based ROS application faces this issue

Current workaround: Custom message normalizer service (~150 lines of recursive TypedArray conversion)

---

3. Promise-Based Service Calls

What we need: Async/await support for service calls with timeout and cancellation.

Why we need it:

• Callback-based APIs don't integrate well with modern async/await code
• No built-in timeout support
• Difficult to handle errors properly
• Can't use AbortController pattern for cancellation
• Makes code harder to read and maintain

Current limitation: Must wrap callbacks in Promises manually for every service call

---

4. Remote Parameter Watching

What we need: Subscribe to parameter change events from other nodes.

Why we need it:

• Real-time dashboard updates when parameters change
• Configuration hot-reload without polling
• Currently must poll parameters or manually subscribe to /parameter_events and filter

---

5. Message Validation

What we need: Runtime validation of message structure before publishing/processing.

Why we need it:

• Catch invalid messages early instead of silent failures
• Better error messages for debugging
• Schema introspection for documentation generation
• Prevent sending malformed messages that crash receivers

---

6. Enhanced Error Handling

What we need: Specific error types (TimeoutError, ConnectionError, ValidationError) instead of generic errors.

Why we need it:

• Better error recovery strategies
• More informative error messages
• Easier debugging and logging
• Proper error categorization for monitoring systems

---

7. Rate Limiting & Throttling

What we need: Built-in rate control for publishers and subscriptions.

Why we need it:

• Prevent overwhelming consumers
• Network bandwidth management
• Sampling high-frequency topics (sensors)
• Currently must implement custom timing logic

I have more nice to have features but for now the above suggestions are the ones that I struggled with the most, thank you for asking :). Let me know your thoughts and how I can help.

[minggangw]

@mahmoudalghalayini thanks for your suggestions, that's great! I can see that these ideas/requirements come from your practical work, so I believe they are more meaningful. Please open issues for them, you are welcome to contribute PRs based on the priority of the issues you deem. Some comments below:

1. External Parameter Access

It would be useful as the scenario you described, and not much work to implement it. Can u check if rclpy has it? This could be a differentiation compared with rclpy.

2. JSON-Safe Message Serialization

Totally undersatand, we can improve this :)

3. Promise-Based Service Calls

Absolutely, the day when this project initialized, the async was not supported well, it's time to support it now.

4. Remote Parameter Watching

As I understand, this is similar to 1st item?

5. Message Validation

I think rclnodejs has already some validation, we can make it better.

6. Enhanced Error Handling

This can be an advanced feature.

7. Rate Limiting & Throttling

I'm not familiar with this field, I think it's kind of advanced feature we can consider to support.

[mahmoud-ghalayini]

@mahmoudalghalayini thanks for your suggestions, that's great! I can see that these ideas/requirements come from your practical work, so I believe they are more meaningful. Please open issues for them, you are welcome to contribute PRs based on the priority of the issues you deem. Some comments below:

1. External Parameter Access

It would be useful as the scenario you described, and not much work to implement it. Can u check if rclpy has it? This could be a differentiation compared with rclpy.

Yes, rclpy has this. They provide SyncParametersClient and AsyncParametersClient:

from rclpy.parameter import SyncParametersClient

param_client = SyncParametersClient(node, '/other_node')
value = param_client.get_parameters(['max_speed'])
param_client.set_parameters([Parameter('max_speed', Parameter.Type.DOUBLE, 2.5)])

So this would be feature parity with rclpy rather than differentiation. However, it's essential for JavaScript/TypeScript developers to have the same capabilities as Python developers, especially for web-based robotics applications.

2. JSON-Safe Message Serialization

Totally undersatand, we can improve this :)

Great! This is probably the highest impact for web applications.

3. Promise-Based Service Calls

Absolutely, the day when this project initialized, the async was not supported well, it's time to support it now.

Excellent! Modern async/await will make rclnodejs much more pleasant to use with current JavaScript patterns.

4. Remote Parameter Watching

As I understand, this is similar to 1st item?

Yes, exactly! Remote Parameter Watching would be built on top of External Parameter Access. Once we have the parameter access APIs (point 1), watching is just:

1. Subscribe to the /parameter_events topic (already possible in rclnodejs)
2. Filter events by node name
3. Use the External Parameter Access API to fetch current values when events occur

So Remote Parameter Watching depends on External Parameter Access being implemented first. It's essentially a convenience wrapper that combines:

• Parameter event subscription (already exists)
• Remote parameter queries (needs to be implemented in point 1)
• Event filtering and callback management (convenience layer)

This means point 4 can wait until after point 1 is done, and it's a much smaller piece of work since it builds on existing functionality. Good catch - they should be tackled in sequence, not in parallel.

5. Message Validation

I think rclnodejs has already some validation, we can make it better.

Agreed! Current validation exists but could be improved:

Current:

publisher.publish({ invalid_field: 'test' });
// Error: serialization failed (generic error)

Desired:

publisher.publish({ invalid_field: 'test' });
// MessageValidationError: Unknown field 'invalid_field' in std_msgs/msg/String
// Valid fields: data

More explicit errors + optional strict mode + schema introspection would be helpful.

6. Enhanced Error Handling

This can be an advanced feature.

Agreed - can be lower priority but would improve debugging significantly.

7. Rate Limiting & Throttling

I'm not familiar with this field, I think it's kind of advanced feature we can consider to support.

These are common patterns for high-frequency sensors:

• Throttling: Limit publish rate (e.g., max 10 Hz) to prevent network overload
• Debouncing: Wait for message burst to finish before processing
• Sampling: Process every Nth message (e.g., every 5th laser scan)

Current approach (manual):

let lastPublish = 0;
if (Date.now() - lastPublish >= 100) {
  processMessage(msg);
  lastPublish = Date.now();
}

Proposed convenience:

subscription.createSubscription('/scan', callback, {
  throttle: { maxRate: 10 } // Hz
});

[minggangw]

I see, as the rclpy provides SyncParametersClient and AsyncParametersClient, we can align with it, thanks for the confimation.

[minggangw]

Setting the parameter for a node running remotely (#1), is there any security risk we can think out?

[mahmoud-ghalayini]

Yes, there are security considerations, but they're not specific to rclnodejs - they're inherent to ROS 2's design. rclpy and rclcpp have the exact same risks.

My Recommendation:

Implement the feature with good documentation:

• Link to SROS2 setup guides
• Show examples with parameter validation
• Encourage read-only parameters for critical values

Since this functionality is already possible (anyone can manually create the service clients), and rclpy/rclcpp expose the same APIs, this is really a documentation issue, not an implementation blocker.

[mahmoud-ghalayini]

At the end, it is your call 😅

[minggangw]

It sounds good to me as other clients already implemented the functionalities.

[minggangw]

Some updates about this thread (thanks to @mahmoud-ghalayini effort):

1. External Parameter Access feat: add ParameterClient for external parameter access #1318
2. JSON-Safe Message Serialization Add JSON-Safe serialization modes #1308
3. Promise-Based Service Calls feat: add promise-based service calls #1311
4. Enhanced Error Handling feat: add structured error handling with class error hierarchy #1320
5. Remote Parameter Watching feat: add ParameterWatcher for real time parameter monitoring #1326
6. Rate Limiting & Throttling Add Observable subscriptions with RxJS support #1357
7. Message Validation Enhance Message Validation #1341

[mahmoud-ghalayini]

Thank you 😄 , I was wondering if we can release the current changes also I'll be able to test them in action once I change the my app to use them
Still want to improve the message validation, add rate limiting, and throttling 😅

[minggangw]

Sure, I can make it today 😄

[minggangw]

https://www.npmjs.com/package/rclnodejs/v/1.7.0 released, enjoy

[mahmoud-ghalayini]

I think we can finally close this discussion — all of the originally proposed features and enhancements have now been implemented.

Thank you for the collaboration and guidance throughout these contributions!

I'd like to continue contributing with the following topics, though they require more planning and closer collaboration:

1. Testing utilities: A testing package or helper methods exported directly from rclnodejs. One of my biggest challenges has been mocking rclnodejs methods and classes for unit tests.

2. ES Module support: Migrating from CommonJS to modern ES module syntax, enabling import { Node } from 'rclnodejs' instead of require('rclnodejs').

Let me know if you're interested in exploring either of these.

[minggangw]

Sure, thanks for your great contributions! I also update this comment. For the future plan, I think we can start with the second one you listed, thanks!