Revision history [back]

I had 10s instead of 100s of different topics but I recently did something similar where a received message was parsed and then published onto individual topics (I used marti_common_msgs/Float32Stamped because I wanted the reception time captured). It pollutes the topic list some but it's very easy to plot any of the values, which isn't going to work well with yaml.

Then there had to be a second layer to subscribe to some of those topics to turn into JointStates- which added a little latency (but it's all ros1 tcp on localhost with messages that are a handful of bytes, so not that much). Most of the rest had no subscribers other than rosbag. So if you have groups of data that map to existing message types those would be good to publish out, then they will easy to visualize in rviz or use in other off the shelf nodes- like groups of xyz into Points or Vectors. Anything you have a real subscriber for right now, where different actions will be taken automatically based on the value of the data, or someone needs to monitor and make live decisions based on plots or 3D visualization- those deserve more consideration for what kind of message they go in, everything else could be swept into a big generic array message for recording.

From ros1 the dynamic_reconfigure/Config message could be a model to use for a big generic array- there are arrays of different types along with string names for each array element, though it seems wasteful to resend the same string names every message unless message-to-message there are changes in which name is in which index of the array (it ought to be more efficient than sending a bunch of doubles as strings in yaml though):

$ rosmsg show dynamic_reconfigure/Config
dynamic_reconfigure/BoolParameter[] bools
  string name
  bool value
dynamic_reconfigure/IntParameter[] ints
  string name
  int32 value
dynamic_reconfigure/StrParameter[] strs
  string name
  string value
dynamic_reconfigure/DoubleParameter[] doubles
  string name
  float64 value
dynamic_reconfigure/GroupState[] groups
  string name
  bool state
  int32 id
  int32 parent

I had 10s instead of 100s of different topics but I recently did something similar where a received message was parsed and then published onto individual topics (I used marti_common_msgs/Float32Stamped because I wanted the reception time captured). It pollutes the topic list some but it's very easy to plot any of the values, which isn't going to work well with yaml.

Then there had to be a second layer to subscribe to some of those topics to turn into JointStates- which added a little latency (but it's all ros1 tcp on localhost with messages that are a handful of bytes, so not that much). Most of the rest had no subscribers other than rosbag. So if you have groups of data that map to existing message types those would be good to publish out, then they will be easy to visualize in rviz or use in other off the shelf nodes- like groups of xyz into Points or Vectors. Anything you have a real subscriber for right now, where different actions will be taken automatically based on the value of the data, or someone needs to monitor and make live decisions based on plots or 3D visualization- those deserve more consideration for what kind of message they go in, everything else could be swept into a big generic array message for recording.

From ros1 the dynamic_reconfigure/Config message could be a model to use for a big generic array- there are arrays of different types along with string names for each array element, though it seems wasteful to resend the same string names every message unless message-to-message there are changes in which name is in which index of the array (it ought to be more efficient than sending a bunch of doubles as strings in yaml though):

$ rosmsg show dynamic_reconfigure/Config
dynamic_reconfigure/BoolParameter[] bools
  string name
  bool value
dynamic_reconfigure/IntParameter[] ints
  string name
  int32 value
dynamic_reconfigure/StrParameter[] strs
  string name
  string value
dynamic_reconfigure/DoubleParameter[] doubles
  string name
  float64 value
dynamic_reconfigure/GroupState[] groups
  string name
  bool state
  int32 id
  int32 parent