Skip to content
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

Reduce excessive error and warning logs on Autoware launch #5539

Open
3 of 8 tasks
xmfcx opened this issue Nov 9, 2023 · 5 comments · Fixed by autowarefoundation/autoware_common#224 or tier4/pointcloud_to_laserscan#6
Assignees
Labels
component:system System design and integration. (auto-assigned) type:bug Software flaws or errors.

Comments

@xmfcx
Copy link
Contributor

xmfcx commented Nov 9, 2023

Checklist

  • I've read the contribution guidelines.
  • I've searched other issues and no duplicate issues were found.
  • I've agreed with the maintainers that I can plan this task.

Description

When Autoware is executed, it generates a significant number of warning and error logs, despite the system running as expected. The logs are not only excessive but also misrepresent the stability of the running application, as they appear even in the absence of actual functional issues. This creates a noisy debugging environment, making it challenging to identify and address genuine issues.

The issue was replicated using the latest main branch with the planning simulator demo as per the Autoware documentation: Planning Simulation Tutorial.

A video demonstrating the issue is available here:

The logs from the run that showcase the problem can be found here:

Purpose

The primary goal is to clean up the logs by either resolving the underlying causes of the warnings and errors or by adjusting the threat levels if the logs are not indicative of real issues.
This will aid in de-cluttering the console output, making it easier to debug actual problems, and generally improve the developer experience.

Possible approaches

  1. Log Analysis: Go through the logs to determine if the warnings/errors are justified. If they represent real issues, then they should be addressed with bug fixes.
  2. Adjust Log Levels: If the logs are overly cautious and do not represent actual errors or critical warnings, then the log levels should be adjusted accordingly.
  3. Code Refactoring: Inspect the sections of the code-base that are generating these logs and refactor if necessary to prevent false positives.
  4. Configuration Tweaks: Check if the verbosity of the logs can be configured, allowing users to set the desired level of log detail.
  5. Documentation Update: If certain logs are expected and do not indicate problems, this should be clearly documented to avoid confusion. (last resort, not preferred)
  6. Incremental Fixing: Tackle the errors and warnings in batches, creating multiple issues or pull requests to address them systematically.

Definition of done

  • The error and warning logs that are not indicative of actual issues are eliminated or their threat levels are adjusted.
  • The logging output should be clear and should accurately reflect the operational status of Autoware.
  • Documentation should be updated, if necessary, to reflect any changes made to log management.
  • Additional issues should be created for any unresolved logs that require further investigation or long-term changes.
  • The Autoware community agrees that the logging is now informative and not excessively verbose, allowing for effective debugging.
@xmfcx xmfcx added component:system System design and integration. (auto-assigned) type:bug Software flaws or errors. labels Nov 9, 2023
@xmfcx
Copy link
Contributor Author

xmfcx commented Nov 9, 2023

To clarify, this task encapsulates warning and error logs coming from any part of the Autoware for any reason.

@ahmeddesokyebrahim
Copy link
Contributor

ahmeddesokyebrahim commented Dec 26, 2023

I would like to share updates regarding this issue.

The target of this issue is to reduce excessive log message in Autoware for the following tutorials with default parameters

In this sheet, we are categorize and following up the log messages during the fixing process of this issue.

The initial plan is to have the task into 5 phases :

Phase Definition
Phase 1 Planning simulation : starting planning simulator and before setting vehicle start location. This phase produces a lot of recurrent message while nodes are initializing
Phase 2 Planning simulation : setting vehicle start location, goal location, and basic driving scenario. This phase where actually the nodes are starting to work and communicate.
Phase 3 Planning simulation : handing special driving scenarios in planning simulator like parking, …
Phase 4 Rosbag replay simulation
Phase 5 AWSIM (extended goal)

The following is the list of relevant PRs for proposing solution fixing the different log messages.
For completing this issue, these PRs must be successully reviewed and merged [list can be updated during development]

@ahmeddesokyebrahim
Copy link
Contributor

ahmeddesokyebrahim commented Feb 7, 2024

The PRs for the first 3 phases are ready for review.
Recommended Merge Sequence

  1. fix(log-messages): reduce excessive log messages autoware_common#224
  2. fix(log-messages): reduce excessive log messages #5971
  3. fix(log-messages): reduce excessive log messages autoware_launch#760

The following one does not matter in sequence

The following phases will be addressed in separate PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:system System design and integration. (auto-assigned) type:bug Software flaws or errors.
Projects
None yet
2 participants