Ask Your Question

How many topics?

asked 2017-03-10 06:19:38 -0500

updated 2017-03-15 05:23:31 -0500

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.

edit retag flag offensive close merge delete


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

gvdhoorn gravatar image gvdhoorn  ( 2017-03-15 14:05:41 -0500 )edit

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

gvdhoorn gravatar image gvdhoorn  ( 2017-03-15 14:07:09 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2017-03-10 10:44:27 -0500

seanarm gravatar image

ROS-style aside, options #2 and #3 seem flawed. With #2, you laid out the problem yourself. With #3, you'd either need to add message fields for the timestamp of each datum, or throw out all the timestamps except for the one on the new aggregate message. Even in the former case, some of your data would age while waiting for the aggregate message to fill. Go with #1.

edit flag offensive delete link more


With (3) I would timestamp each block of parameters with the message it came from.

Data comes in on all signals (that I would use) every 20ms, so the data would not be stale. The timing on most of these data are not critical. I could choose one of the messages and each time I receive it send the

Dave Barnett gravatar image Dave Barnett  ( 2017-03-13 04:16:14 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2017-03-10 06:19:38 -0500

Seen: 213 times

Last updated: Mar 15 '17