User-facing alternative of rosgraph_msgs/Log msg type

asked 2019-09-16 03:08:25 -0500

130s gravatar image

updated 2019-09-18 07:03:31 -0500

rosgraph_msgs/Log is a well-defined msg type for logging. However multiple sources discourage downstream packages to depend on it.

  • Q-1. What downside can be expected if downstream project uses rosgraph_msgs/Log directly? I think by discouraging such a usage, API is free from guaranteeing stability. What else?
  • Q-2. In ROS either somewhere in core package suite or packages commonly used, are there alternative message types (so that downstream can avoid reintenting wheels and maintenance)?

From wiki.ros.org/rosgraph_msgs:

rosgraph_msgs contains message relating to the ROS Computation Graph. Most users are not expected to interact with messages in this package, and it is strongly advised against.

From rep-0100:

The Clock and Log msg files are not considered to be user facing. They are also specific to the ROS middleware implementation and would pollute a more generic ontology like std_msgs.


UPDATE: In response to clarification request,

Can you describe what use-case or requirement you're trying to cover/fullfil? It's unclear to me whether you are just looking to show some log messages to your users (in a UI perhaps) or something else.

I'm thinking generic module-to-module API level. So (well-)defined log level, log message (str) are useful. Some more medium to help conveying various other types of log messages is a plus. But yes, end usage of such API I have in mind is making non-engineer facing GUI to present troubleshoot info (to achieve that, our app wants to receive log topic (system-level info) then customize message content to end-user friendly content).

edit retag flag offensive close merge delete

Comments

Can you describe what use-case or requirement you're trying to cover/fullfil? It's unclear to me whether you are just looking to show some log messages to your users (in a UI perhaps) or something else.

gvdhoorn gravatar image gvdhoorn  ( 2019-09-16 05:32:22 -0500 )edit

Updated to clarify my usecase, and also added Q-1.

130s gravatar image 130s  ( 2019-09-17 20:37:46 -0500 )edit

I'm thinking generic module-to-module API level

module-to-module != user facing?

But yes, end usage I have in mind is making non-engineer fasinc GUI to present troubleshoot info.

probably a custom UI, but not dissimilar from rqt_console?

gvdhoorn gravatar image gvdhoorn  ( 2019-09-18 02:11:51 -0500 )edit

I meant API somewhere in intermediate location would allow the developers to build application with less restriction. Update OP to clarify

130s gravatar image 130s  ( 2019-09-18 07:01:48 -0500 )edit