-
Notifications
You must be signed in to change notification settings - Fork 639
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
Improve diagnostics aggregation method #3829
Comments
It was not possible to support graph structures without changing the plugin interface for diagnostic_aggregator. It seems that AnalyzerGroup cannot share child Analyzer with others. |
This pull request has been automatically marked as stale because it has not had recent activity. |
I'll change the Autoware diagnostics as follows.
|
This pull request has been automatically marked as stale because it has not had recent activity. |
This pull request has been automatically marked as stale because it has not had recent activity. |
Package creation is complete. We will integrate with MRM in https://github.com/orgs/autowarefoundation/discussions/4176. |
Checklist
Description
Recently MRM supports the multiple behavior that are emergency stop and comfortable stop and will plan to support pull over in #3221. Therefore, the system must select an appropriate MRM from the diagnostics.
Current diagnostics do not have well-structured diagnostic trees, making it difficult to select a appropriate MRM. Autonomous driving systems are complex, so diagnostic dependencies are directed acyclic graph (DAG) rather than tree.
For users, there is the problem that it is difficult to understand the error that prevents the switch to automatic driving, and thare are false positives. Also, I feel that terms such as SPF/LF/SF are a little different from their original meanings, so I would like to improve these as well.
Purpose
Possible approaches
The diagram below is the sample of an improved diagnostic structure. Each block in the diagram has the same information as DiagnosticStatus.msg with extra "links" field for DAG. The mechanism is almost the same as diagnostic_aggregator. So we need to extend it to support DAG, or create a similar implementation.
Error classification
Now the system_error_monitor classifies each status as either SPF/LF/SF/NF. However, the severity of the impact depends on the functionality that requires it. For example, consider a situation where the system has LiDAR and radar, and only LiDAR is broken. The object detection can work if either is fine, so that is not an error. But the object prediction, which needs the exact position of an object, requires LiDAR, so that is an error.
So instead of categorizing each error, consider the impact on the functionality that each error affects. In this case it is sufficient to create a DiagnosticStatus for that functionality and determine its level. In conclusion, remove the classification (SPF/LF/SF/NF), use the error level (ERROR/WARN/OK) instead.
Select MRM
Create a DiagnosticStatus for the functionality for each MRM and set the diagnostic dependencies appropriately for that MRM to work. Then the system can easily find the currently available MRMs by checking at their error levels.
Also, create a status for normal functionality such as autonomous driving and remote driving in the same way. Then simply prioritize these functionality and select the one with the highest priority.
Error report
Create a root (it's not a tree, but a node that can reach all other nodes) DiagnosticsStatus for error reporting. It dynamically determines the level of error according to the user's interests and vehicle conditions. For example:
Message types
/diagnostics_graph
(DiagnosticArray.msg)/diagnostics_graph_struct
(DiagnosticGraph.msg)Backward compatibility
You can create messages compatible with
/hazard_status
by assigning error categories as follows:Definition of done
The text was updated successfully, but these errors were encountered: