Future features and enhancements #1306

@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.

@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
});

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

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.

At the end, it is your call 😅

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

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 😅

Sure, I can make it today 😄

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