CAN Bridge Node can't differentiate between multiple interfaces after reception / before sending

[njoye]

Currently the socketcan_bridge_node (consisting of the topic_to_socketcan_node and the socketcan_to_topic_node) can't differentiate between multiple socketcan interfaces as soon as the messages are published in the ROS network or before the messages are passed to the socketcan bridge. The reason for this is that the topic name of each node is fixed to received_messages and sent_messages without regard for the can interface. I will provide a PR in the next days that will make the topic name changeable through the use of ros parameters similar to the parameters that can be set for the can interface name. This will allow users to send data onto two different can busses without sending them onto both at the same time as well as receiving messages from different can busses on different topics which might reduce or eliminate the need for filtering and discarding unnecessarily received messages.

Backwards-compatibility will be achieved by defaulting to the existing topic names should no parameter be set.

[gavanderhoorn]

What about remapping the topics?

Topic names as parameters is a bit of an anti-pattern.

[ivan140]

  <!-- Socket CAN bridge can1-->  
  <node pkg="socketcan_bridge" type="socketcan_bridge_node" name="socketcan1_node" output="screen">
    <param name="can_device" value="can1" />
    <!-- <rosparam param="can_ids"> [ ] </rosparam> -->
  </node>

  <!-- Socket CAN bridge can0--> 
  <node ns="can0" pkg="socketcan_bridge" type="socketcan_bridge_node" name="socketcan0_node" output="screen">
    <param name="can_device" value="can0" />
    <rosparam param="can_ids"> [ 390, 646 ] </rosparam>
  </node>

We're using 2 different can interfaces also by just putting the nodes into a namespace. :-)

[njoye]

Probably got carried away when thinking about this problem. I’ll see to do just that … issue can be closed.

Am Mi., 01.Juni.2022 um 18:28, G.A. vd. Hoorn @.***> schrieb:

What about remapping the topics/

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>