Closed isamu-takagi closed 6 months ago
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.
diagnostic_aggregator
and system_error_monitor
with system_diagnostic_graph
node.diagnostics_agg
and hazard_status
with diagnostics_graph
and diagnostics_summary
topic.
diagnostics_summary
is similar to emergency, emergency_holding
fields in hazard_status
diagnostics_graph
is similar to nf, sf, lf, spf
fields in hazard_status
or diagnostics_agg
This pull request has been automatically marked as stale because it has not had recent activity.
Add diagnostic graph aggregator
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 https://github.com/autowarefoundation/autoware.universe/issues/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