How many topics?
I have a 'device' (a custom drive-by-wire vehicle) that has a CAN bus onto which various messages are published. There are in the order of 20-30 different messages published by the various ECUs on the bus every 20ms.
I have connected a socketcan_bridge_node to the bus and can happily receive the raw data into ROS. It is my intention to add a node to the system that subscribes to the received_messages and publishes a more meaningful, domain specific version.
I have a few choices. 1) On receipt of each message, I take the stream of bytes, fill in a message structure and publish it. This would mean I a node that advertises 20-30 topics and publishes on each of them every 20ms. 2) Same as (1) but only publish if the data are different to previous content (latching the topic). This would reduce repetition and bandwidth but would cause problems for nodes that need to know that the data are current. 3) I collect the data from the messages into one or more larger message structures and publish that (those) periodically. i.e. less topics with larger messages.
Which of these options (or another option that I haven't considered) best fits the 'ROS style'? I am new to ROS, I know how to implement any of the above solutions, but would like to fit with the community way of doing things.
One additional data point: I tend to dislike transparent bridges, as they import domain concepts from beyond the bridge (your CAN network) into your ROS nodegraph. That almost always results in reduced re-usability of nodes on the ROS side. A ROS API abstraction, which a set of 'driver-like' ..
.. could provide, would prevent that, while still allowing you to expose all the infrastructure 'on the other side' through services and dataflows.
If you really need to bag raw CAN frames, then you could still include the CAN bridge that you have now.