0
$\begingroup$

Rosanswers logo

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.


Originally posted by Dave Barnett on ROS Answers with karma: 23 on 2017-03-10

Post score: 0


Original comments

Comment by gvdhoorn on 2017-03-15:
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' ..

Comment by gvdhoorn on 2017-03-15:
.. 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.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by seanarm with karma: 753 on 2017-03-10

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by Dave Barnett on 2017-03-13:
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

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.