-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rosconsole: Reduce duplicate log messages in rosconsole #1
Labels
enhancement
New feature or request
Milestone
Comments
From @ablasdel on January 8, 2013 22:39 content of ros_console_limit_repeats.patch:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From @ablasdel on January 8, 2013 22:39
When things go wrong on a running robot (both real and in simulation) many components output warning/error messages repeatedly to the console until killed. This is especially problematic for components that run at high rates, such as move_base, because they can overwhelm the terminal to the point that you have to wait a while before a ctrl-c has an effect (especially true on slow laptops and flaky wifi!).
This patch is a first stab at reducing the number of repeat messages. It works by allowing the initial output of a message and then counting the number of times the message is repeated. It will then output the number of repeats and the message once a second or when a different message is logged. File logging is not currently affected, though I'm thinking about applying this there too.
migration of trac ticket 4055:
https://code.ros.org/trac/ros/ticket/4055
change history (for attachements see first comment):
Changed 3 months ago by kbogert
attachment ros_console_limit_repeats.patch added
Changed 3 months ago by dthomas
Your patch adds throttling for once specific appender. There are two drawbacks with that approach: - throttling should potentially affect all appenders - some log messages should not be throttled if the source decides that this is better
Therefore ROS provides specific logging macros with the suffix _THROTTLE ( http://www.ros.org/wiki/roscpp/Overview/Logging). It enables the source of the log message to specify a specific max rate for publishing that message. Is there a reason why that already existing method is not sufficient?
Changed 3 months ago by kbogert
The THROTTLE macros would work if all sources used it, they do not and shouldn't necessarily. The problem specifically is with flooding the console with too many messages to read and/or slowing down the terminal to the point that it's impossible to interact with. I would consider adding throttling to the other appenders if they also have a negative effect on some portion of the system due to repeat messages. However, in the case of file logs, for instance, it's likely that you want all messages with accurate timestamps for debugging after the fact.
To use the THROTTLE macro the source would have to know that no one wants to hear a message as often as it is being generated. Here we're making a practical concession that no one can read "missed desired rate" messages as they fly by at 30hz, printing all of them will likely cause you to miss more important messages, and you still want to receive other messages from the problem component of the same logging level (so filtering them at with log4cxx is not an option). This patch allows you to know that the repeat message is happening and at what rate without flooding your console to do so.
Copied from original issue: ros/ros_comm#68
The text was updated successfully, but these errors were encountered: