You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A topic tool that subscribes to one topic, and based on one of the message fields splits the topic into two. I can see this being useful for debugging and other uses, maybe not deployment runtime applications. An example is 2 lidars that publish to a single topic for use by a mapping node, but this tool could be used to temporarily split this into 2 topics for debugging and looking at just 1 of the lidars data at a time.
Completion Criteria
A new Split node that splits a topic into multiple topics
Implementation Notes / Suggestions
I don't have any suggestions other than that I am happy to work on this if you feel it could be useful. I imagine implementation wise it would be a bit of a mix between demux for one input multi output, and transform for looking at a specific message field.
Testing Notes / Suggestions
An example test case could be a series of ros2 std_msgs/Header messages on a topic like /input. Each message with different timestamps and 1 of N frame_ids. Then the output of this node should be /output/N where N is the frame_id of the header message.
The first step of this feature looks like TopicFilter to me, where you take an input topic, and Relay to an output topic if the message meets a condition. You could then combine multiple filter components to make a MultiFilter. Not attached to any particular naming, thoughts:
Splitter (or Router ?) suggests that each input message is sent to one output topic
MultiFilterRelay (or something) would suggest that each input message could be sent to zero or more output topics
It depends which of those promises we'd want to make. Maybe both are separately useful, though the latter contains the former as one configuration state (especially if there's an "else" filter to fall back to when no others are matched)
MultiFilterRelay (name pending hahaha) sounds like a great idea! Seems much more versatile while still being capable of the use case I described. I might give this a try this weekend if you are open to outside contributions?
Activity
emersonknapp commentedon Nov 20, 2025
Seems useful!
The first step of this feature looks like
TopicFilterto me, where you take an input topic, andRelayto an output topic if the message meets a condition. You could then combine multiple filter components to make aMultiFilter. Not attached to any particular naming, thoughts:Splitter(orRouter?) suggests that each input message is sent to one output topicMultiFilterRelay(or something) would suggest that each input message could be sent to zero or more output topicsIt depends which of those promises we'd want to make. Maybe both are separately useful, though the latter contains the former as one configuration state (especially if there's an "else" filter to fall back to when no others are matched)
4lon commentedon Nov 20, 2025
MultiFilterRelay (name pending hahaha) sounds like a great idea! Seems much more versatile while still being capable of the use case I described. I might give this a try this weekend if you are open to outside contributions?
emersonknapp commentedon Nov 25, 2025
Of course! "PRs welcome" is the motto out here
4lon commentedon Apr 2, 2026
@emersonknapp sorry to bother, I just wanted to bump this and ask if you had any recommendations as to how I can get this reviewed?