{"results":{"result":{"added-files":{"code-health":6.684908209192828,"old-code-health":0.0,"files":[{"file":"evaluator/autoware_planning_evaluator/src/obstacle_metrics_calculator.cpp","loc":352,"code-health":6.6849082091928285}]},"external-review-url":"https://github.com/autowarefoundation/autoware_universe/pull/11761","old-code-health":8.439955103044893,"modified-files":{"code-health":8.31381802715826,"old-code-health":8.439955103044893,"files":[{"file":"evaluator/autoware_planning_evaluator/src/metrics/metrics_utils.cpp","loc":139,"old-loc":81,"code-health":9.387218218812514,"old-code-health":9.6882083290695},{"file":"evaluator/autoware_planning_evaluator/src/metrics_calculator.cpp","loc":98,"old-loc":109,"code-health":9.500346130021617,"old-code-health":9.446570267382697},{"file":"evaluator/autoware_planning_evaluator/src/planning_evaluator_node.cpp","loc":455,"old-loc":408,"code-health":7.52061020301581,"old-code-health":7.9380569118820405},{"file":"evaluator/autoware_planning_evaluator/test/test_planning_evaluator_node.cpp","loc":816,"old-loc":683,"code-health":8.283981080161325,"old-code-health":8.283981080161325},{"file":"evaluator/autoware_planning_evaluator/src/metrics/trajectory_metrics.cpp","loc":153,"old-loc":153,"code-health":9.096655465156704,"old-code-health":9.096655465156704}]},"removed-files":{"code-health":0.0,"old-code-health":0.0,"files":[]},"external-review-id":"11761","analysis-time":"2026-01-16T04:11:56Z","negative-impact-count":11,"suppressions":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"affected-hotspots":0,"commits":["976bcbf1b93065bcb937ffc72d858c6accd0702b","30bc709c6fa83486f04e3adbc2713fadcad85926","8d34130b1972700c0987e39a4123d033d0dc96f7","6587d890b617f39b7c0ed24e6310cf229157bb8f","dcf8443bc47e27b8d98d5692f4b1e9ffd2af919a","c8724a482ecfabdb1492bff2c968eccbb3c4b07f","22880edd5ef34d5e6bbbebeaa3f39690a02c5f15","be671c360bff4076be02c8d2f9a4f19feff98a26","aa1359ddffe0599e2c4a533904b280fb7041a17f","c9daa26609ecd95bd05642311254be06dbe695e4","7301064673f0aec0152b9ee3239fd996c50b8c34","77ba0fd78f9ba03c49aec58f564f02b9f58e3a98","175051c7c8548d2ae907eb1d71537c21aaa0f849"],"is-negative-review":true,"negative-findings":{"number-of-types":4,"number-of-files-touched":3,"findings":[{"method":"polygon_intersects","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"evaluator/autoware_planning_evaluator/src/metrics/metrics_utils.cpp","refactoring-examples":[{"architectural-component-id":null,"author-name":"Taekjin LEE","training-data":{"loc-added":"11","loc-deleted":"14","delta-cc-mean":"0.0","delta-cc-total":"0","delta-penalties":"1.0","delta-n-functions":"0","current-file-score":"10.0"},"author-email":"taekjin.lee@tier4.jp","commit-full-message":"* feat(tracker_processor): set existence probability for tracked objects\n\nSigned-off-by: Taekjin LEE \n\n* refactor(tracker): rename classification parameter for clarity in updateClassification method\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): ensure minimum covariance values to prevent large Mahalanobis distance\n\nSigned-off-by: Taekjin LEE \n\n* feat(tracker): disable trust in existence probability for input channels\n\nSigned-off-by: Taekjin LEE \n\n* fix(tracker): update decay rate for existence probability to reflect a 0.5s half-life\n\nSigned-off-by: Taekjin LEE \n\n* style(pre-commit): autofix\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): correct spelling of \"mahalanobis\" in comment for clarity\n\nSigned-off-by: Taekjin LEE \n\n---------\n\nSigned-off-by: Taekjin LEE \nCo-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>","commit-date":"2025-08-04T07:38:26Z","current-rev":"47a0fb82f4","filename":"autoware_universe/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp","previous-rev":"70be106253","commit-title":"fix(autoware_multi_object_tracker): existence probability adjustment to mitigate tracker lost (#11109)","language":"C++","id":"410ebd13723902158abcb4c2d1698bc1c3c4c442","model-score":0.54,"author-id":null,"project-id":29372,"delta-file-score":0.31179166,"diff":"diff --git a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\nindex 094c9537a9..7c34b30b36 100644\n--- a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n+++ b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n@@ -46,3 +46,3 @@ float decayProbability(const float & prior, const float & delta_time)\n constexpr float minimum_probability = 0.001;\n- const float decay_rate = log(0.5f) / 0.3f; // half-life (50% decay) of 0.3s\n+ const float decay_rate = log(0.5f) / 0.5f; // half-life (50% decay) of 0.5s\n return std::max(prior * std::exp(decay_rate * delta_time), minimum_probability);\n@@ -135,7 +135,4 @@ bool Tracker::updateWithMeasurement(\n // update total existence probability\n- const double existence_probability = channel_info.trust_existence_probability\n- ? object.existence_probability\n- : types::default_existence_probability;\n total_existence_probability_ = updateProbability(\n- total_existence_probability_, existence_probability * probability_true_detection,\n+ total_existence_probability_, object.existence_probability * probability_true_detection,\n probability_false_detection);\n@@ -195,3 +192,3 @@ bool Tracker::updateWithoutMeasurement(const rclcpp::Time & timestamp)\n void Tracker::updateClassification(\n- const std::vector & classification)\n+ const std::vector & input)\n {\n@@ -223,6 +220,6 @@ void Tracker::updateClassification(\n // Normalize the input\n- auto classification_input = classification;\n+ auto classification_input = input;\n normalizeProbabilities(classification_input);\n \n- auto & classification_ = object_.classification;\n+ auto & classification = object_.classification;\n \n@@ -231,3 +228,3 @@ void Tracker::updateClassification(\n bool found = false;\n- for (auto & old_class : classification_) {\n+ for (auto & old_class : classification) {\n if (new_class.label == old_class.label) {\n@@ -242,3 +239,3 @@ void Tracker::updateClassification(\n adding_class.probability *= gain;\n- classification_.push_back(adding_class);\n+ classification.push_back(adding_class);\n }\n@@ -247,10 +244,10 @@ void Tracker::updateClassification(\n // If the probability is less than the threshold, remove the class\n- classification_.erase(\n+ classification.erase(\n std::remove_if(\n- classification_.begin(), classification_.end(),\n+ classification.begin(), classification.end(),\n [remove_threshold](const auto & a_class) { return a_class.probability < remove_threshold; }),\n- classification_.end());\n+ classification.end());\n \n // Normalize tracking classification\n- normalizeProbabilities(classification_);\n+ normalizeProbabilities(classification);\n }\n","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":105,"what-changed":"polygon_intersects has a cyclomatic complexity of 9, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"ObstacleMetricsCalculator::ProcessObstaclesTrajectory","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"evaluator/autoware_planning_evaluator/src/obstacle_metrics_calculator.cpp","refactoring-examples":[{"architectural-component-id":null,"author-name":"Taekjin LEE","training-data":{"loc-added":"11","loc-deleted":"14","delta-cc-mean":"0.0","delta-cc-total":"0","delta-penalties":"1.0","delta-n-functions":"0","current-file-score":"10.0"},"author-email":"taekjin.lee@tier4.jp","commit-full-message":"* feat(tracker_processor): set existence probability for tracked objects\n\nSigned-off-by: Taekjin LEE \n\n* refactor(tracker): rename classification parameter for clarity in updateClassification method\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): ensure minimum covariance values to prevent large Mahalanobis distance\n\nSigned-off-by: Taekjin LEE \n\n* feat(tracker): disable trust in existence probability for input channels\n\nSigned-off-by: Taekjin LEE \n\n* fix(tracker): update decay rate for existence probability to reflect a 0.5s half-life\n\nSigned-off-by: Taekjin LEE \n\n* style(pre-commit): autofix\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): correct spelling of \"mahalanobis\" in comment for clarity\n\nSigned-off-by: Taekjin LEE \n\n---------\n\nSigned-off-by: Taekjin LEE \nCo-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>","commit-date":"2025-08-04T07:38:26Z","current-rev":"47a0fb82f4","filename":"autoware_universe/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp","previous-rev":"70be106253","commit-title":"fix(autoware_multi_object_tracker): existence probability adjustment to mitigate tracker lost (#11109)","language":"C++","id":"410ebd13723902158abcb4c2d1698bc1c3c4c442","model-score":0.54,"author-id":null,"project-id":29372,"delta-file-score":0.31179166,"diff":"diff --git a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\nindex 094c9537a9..7c34b30b36 100644\n--- a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n+++ b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n@@ -46,3 +46,3 @@ float decayProbability(const float & prior, const float & delta_time)\n constexpr float minimum_probability = 0.001;\n- const float decay_rate = log(0.5f) / 0.3f; // half-life (50% decay) of 0.3s\n+ const float decay_rate = log(0.5f) / 0.5f; // half-life (50% decay) of 0.5s\n return std::max(prior * std::exp(decay_rate * delta_time), minimum_probability);\n@@ -135,7 +135,4 @@ bool Tracker::updateWithMeasurement(\n // update total existence probability\n- const double existence_probability = channel_info.trust_existence_probability\n- ? object.existence_probability\n- : types::default_existence_probability;\n total_existence_probability_ = updateProbability(\n- total_existence_probability_, existence_probability * probability_true_detection,\n+ total_existence_probability_, object.existence_probability * probability_true_detection,\n probability_false_detection);\n@@ -195,3 +192,3 @@ bool Tracker::updateWithoutMeasurement(const rclcpp::Time & timestamp)\n void Tracker::updateClassification(\n- const std::vector & classification)\n+ const std::vector & input)\n {\n@@ -223,6 +220,6 @@ void Tracker::updateClassification(\n // Normalize the input\n- auto classification_input = classification;\n+ auto classification_input = input;\n normalizeProbabilities(classification_input);\n \n- auto & classification_ = object_.classification;\n+ auto & classification = object_.classification;\n \n@@ -231,3 +228,3 @@ void Tracker::updateClassification(\n bool found = false;\n- for (auto & old_class : classification_) {\n+ for (auto & old_class : classification) {\n if (new_class.label == old_class.label) {\n@@ -242,3 +239,3 @@ void Tracker::updateClassification(\n adding_class.probability *= gain;\n- classification_.push_back(adding_class);\n+ classification.push_back(adding_class);\n }\n@@ -247,10 +244,10 @@ void Tracker::updateClassification(\n // If the probability is less than the threshold, remove the class\n- classification_.erase(\n+ classification.erase(\n std::remove_if(\n- classification_.begin(), classification_.end(),\n+ classification.begin(), classification.end(),\n [remove_threshold](const auto & a_class) { return a_class.probability < remove_threshold; }),\n- classification_.end());\n+ classification.end());\n \n // Normalize tracking classification\n- normalizeProbabilities(classification_);\n+ normalizeProbabilities(classification);\n }\n","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":185,"what-changed":"ObstacleMetricsCalculator::ProcessObstaclesTrajectory has a cyclomatic complexity of 38, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"ObstacleMetricsCalculator::PreprocessEgoTrajectory","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"evaluator/autoware_planning_evaluator/src/obstacle_metrics_calculator.cpp","refactoring-examples":[{"architectural-component-id":null,"author-name":"Taekjin LEE","training-data":{"loc-added":"11","loc-deleted":"14","delta-cc-mean":"0.0","delta-cc-total":"0","delta-penalties":"1.0","delta-n-functions":"0","current-file-score":"10.0"},"author-email":"taekjin.lee@tier4.jp","commit-full-message":"* feat(tracker_processor): set existence probability for tracked objects\n\nSigned-off-by: Taekjin LEE \n\n* refactor(tracker): rename classification parameter for clarity in updateClassification method\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): ensure minimum covariance values to prevent large Mahalanobis distance\n\nSigned-off-by: Taekjin LEE \n\n* feat(tracker): disable trust in existence probability for input channels\n\nSigned-off-by: Taekjin LEE \n\n* fix(tracker): update decay rate for existence probability to reflect a 0.5s half-life\n\nSigned-off-by: Taekjin LEE \n\n* style(pre-commit): autofix\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): correct spelling of \"mahalanobis\" in comment for clarity\n\nSigned-off-by: Taekjin LEE \n\n---------\n\nSigned-off-by: Taekjin LEE \nCo-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>","commit-date":"2025-08-04T07:38:26Z","current-rev":"47a0fb82f4","filename":"autoware_universe/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp","previous-rev":"70be106253","commit-title":"fix(autoware_multi_object_tracker): existence probability adjustment to mitigate tracker lost (#11109)","language":"C++","id":"410ebd13723902158abcb4c2d1698bc1c3c4c442","model-score":0.54,"author-id":null,"project-id":29372,"delta-file-score":0.31179166,"diff":"diff --git a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\nindex 094c9537a9..7c34b30b36 100644\n--- a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n+++ b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n@@ -46,3 +46,3 @@ float decayProbability(const float & prior, const float & delta_time)\n constexpr float minimum_probability = 0.001;\n- const float decay_rate = log(0.5f) / 0.3f; // half-life (50% decay) of 0.3s\n+ const float decay_rate = log(0.5f) / 0.5f; // half-life (50% decay) of 0.5s\n return std::max(prior * std::exp(decay_rate * delta_time), minimum_probability);\n@@ -135,7 +135,4 @@ bool Tracker::updateWithMeasurement(\n // update total existence probability\n- const double existence_probability = channel_info.trust_existence_probability\n- ? object.existence_probability\n- : types::default_existence_probability;\n total_existence_probability_ = updateProbability(\n- total_existence_probability_, existence_probability * probability_true_detection,\n+ total_existence_probability_, object.existence_probability * probability_true_detection,\n probability_false_detection);\n@@ -195,3 +192,3 @@ bool Tracker::updateWithoutMeasurement(const rclcpp::Time & timestamp)\n void Tracker::updateClassification(\n- const std::vector & classification)\n+ const std::vector & input)\n {\n@@ -223,6 +220,6 @@ void Tracker::updateClassification(\n // Normalize the input\n- auto classification_input = classification;\n+ auto classification_input = input;\n normalizeProbabilities(classification_input);\n \n- auto & classification_ = object_.classification;\n+ auto & classification = object_.classification;\n \n@@ -231,3 +228,3 @@ void Tracker::updateClassification(\n bool found = false;\n- for (auto & old_class : classification_) {\n+ for (auto & old_class : classification) {\n if (new_class.label == old_class.label) {\n@@ -242,3 +239,3 @@ void Tracker::updateClassification(\n adding_class.probability *= gain;\n- classification_.push_back(adding_class);\n+ classification.push_back(adding_class);\n }\n@@ -247,10 +244,10 @@ void Tracker::updateClassification(\n // If the probability is less than the threshold, remove the class\n- classification_.erase(\n+ classification.erase(\n std::remove_if(\n- classification_.begin(), classification_.end(),\n+ classification.begin(), classification.end(),\n [remove_threshold](const auto & a_class) { return a_class.probability < remove_threshold; }),\n- classification_.end());\n+ classification.end());\n \n // Normalize tracking classification\n- normalizeProbabilities(classification_);\n+ normalizeProbabilities(classification);\n }\n","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":94,"what-changed":"ObstacleMetricsCalculator::PreprocessEgoTrajectory has a cyclomatic complexity of 15, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"ObstacleMetricsCalculator::CollectWorstMetrics","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"evaluator/autoware_planning_evaluator/src/obstacle_metrics_calculator.cpp","refactoring-examples":[{"architectural-component-id":null,"author-name":"Taekjin LEE","training-data":{"loc-added":"11","loc-deleted":"14","delta-cc-mean":"0.0","delta-cc-total":"0","delta-penalties":"1.0","delta-n-functions":"0","current-file-score":"10.0"},"author-email":"taekjin.lee@tier4.jp","commit-full-message":"* feat(tracker_processor): set existence probability for tracked objects\n\nSigned-off-by: Taekjin LEE \n\n* refactor(tracker): rename classification parameter for clarity in updateClassification method\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): ensure minimum covariance values to prevent large Mahalanobis distance\n\nSigned-off-by: Taekjin LEE \n\n* feat(tracker): disable trust in existence probability for input channels\n\nSigned-off-by: Taekjin LEE \n\n* fix(tracker): update decay rate for existence probability to reflect a 0.5s half-life\n\nSigned-off-by: Taekjin LEE \n\n* style(pre-commit): autofix\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): correct spelling of \"mahalanobis\" in comment for clarity\n\nSigned-off-by: Taekjin LEE \n\n---------\n\nSigned-off-by: Taekjin LEE \nCo-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>","commit-date":"2025-08-04T07:38:26Z","current-rev":"47a0fb82f4","filename":"autoware_universe/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp","previous-rev":"70be106253","commit-title":"fix(autoware_multi_object_tracker): existence probability adjustment to mitigate tracker lost (#11109)","language":"C++","id":"410ebd13723902158abcb4c2d1698bc1c3c4c442","model-score":0.54,"author-id":null,"project-id":29372,"delta-file-score":0.31179166,"diff":"diff --git a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\nindex 094c9537a9..7c34b30b36 100644\n--- a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n+++ b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n@@ -46,3 +46,3 @@ float decayProbability(const float & prior, const float & delta_time)\n constexpr float minimum_probability = 0.001;\n- const float decay_rate = log(0.5f) / 0.3f; // half-life (50% decay) of 0.3s\n+ const float decay_rate = log(0.5f) / 0.5f; // half-life (50% decay) of 0.5s\n return std::max(prior * std::exp(decay_rate * delta_time), minimum_probability);\n@@ -135,7 +135,4 @@ bool Tracker::updateWithMeasurement(\n // update total existence probability\n- const double existence_probability = channel_info.trust_existence_probability\n- ? object.existence_probability\n- : types::default_existence_probability;\n total_existence_probability_ = updateProbability(\n- total_existence_probability_, existence_probability * probability_true_detection,\n+ total_existence_probability_, object.existence_probability * probability_true_detection,\n probability_false_detection);\n@@ -195,3 +192,3 @@ bool Tracker::updateWithoutMeasurement(const rclcpp::Time & timestamp)\n void Tracker::updateClassification(\n- const std::vector & classification)\n+ const std::vector & input)\n {\n@@ -223,6 +220,6 @@ void Tracker::updateClassification(\n // Normalize the input\n- auto classification_input = classification;\n+ auto classification_input = input;\n normalizeProbabilities(classification_input);\n \n- auto & classification_ = object_.classification;\n+ auto & classification = object_.classification;\n \n@@ -231,3 +228,3 @@ void Tracker::updateClassification(\n bool found = false;\n- for (auto & old_class : classification_) {\n+ for (auto & old_class : classification) {\n if (new_class.label == old_class.label) {\n@@ -242,3 +239,3 @@ void Tracker::updateClassification(\n adding_class.probability *= gain;\n- classification_.push_back(adding_class);\n+ classification.push_back(adding_class);\n }\n@@ -247,10 +244,10 @@ void Tracker::updateClassification(\n // If the probability is less than the threshold, remove the class\n- classification_.erase(\n+ classification.erase(\n std::remove_if(\n- classification_.begin(), classification_.end(),\n+ classification.begin(), classification.end(),\n [remove_threshold](const auto & a_class) { return a_class.probability < remove_threshold; }),\n- classification_.end());\n+ classification.end());\n \n // Normalize tracking classification\n- normalizeProbabilities(classification_);\n+ normalizeProbabilities(classification);\n }\n","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":442,"what-changed":"ObstacleMetricsCalculator::CollectWorstMetrics has a cyclomatic complexity of 14, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"ObstacleMetricsCalculator::ProcessObstaclesTrajectory","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is levels of conditionals.","name":"Bumpy Road Ahead","file":"evaluator/autoware_planning_evaluator/src/obstacle_metrics_calculator.cpp","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":185,"what-changed":"ObstacleMetricsCalculator::ProcessObstaclesTrajectory has 9 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"ObstacleMetricsCalculator::PreprocessEgoTrajectory","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is levels of conditionals.","name":"Bumpy Road Ahead","file":"evaluator/autoware_planning_evaluator/src/obstacle_metrics_calculator.cpp","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":94,"what-changed":"ObstacleMetricsCalculator::PreprocessEgoTrajectory has 4 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"ObstacleMetricsCalculator::CollectWorstMetrics","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is levels of conditionals.","name":"Bumpy Road Ahead","file":"evaluator/autoware_planning_evaluator/src/obstacle_metrics_calculator.cpp","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":442,"what-changed":"ObstacleMetricsCalculator::CollectWorstMetrics has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"why-it-occurs":"Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.\n\nCyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).","name":"Overall Code Complexity","file":"evaluator/autoware_planning_evaluator/src/obstacle_metrics_calculator.cpp","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"what-changed":"This module has a mean cyclomatic complexity of 7.17 across 12 functions. The mean complexity threshold is 4","how-to-fix":"You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:\n\nModularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.\n\n","change-type":"introduced"},{"method":"ObstacleMetricsCalculator::ProcessObstaclesTrajectory","why-it-occurs":"Deep nested logic means that you have control structures like if-statements or loops inside other control structures. Deep nested logic increases the cognitive load on the programmer reading the code. The human working memory has a maximum capacity of 3-4 items; beyond that threshold, we struggle with keeping things in our head. Consequently, deep nested logic has a strong correlation to defects and accounts for roughly 20% of all programming mistakes.\n\nCodeScene measures the maximum nesting depth inside each function. The deeper the nesting, the lower the code health. The threshold for the C++ language is 6 levels of nesting.","name":"Deep, Nested Complexity","file":"evaluator/autoware_planning_evaluator/src/obstacle_metrics_calculator.cpp","refactoring-examples":[{"architectural-component-id":null,"author-name":"Yukinari Hisaki","training-data":{"loc-added":"31","loc-deleted":"6","delta-cc-mean":"0.0","delta-cc-total":"0","delta-penalties":"2.0","delta-n-functions":"0","current-file-score":"10.0"},"author-email":"42021302+yhisaki@users.noreply.github.com","commit-full-message":"* fix traffic light\n\nSigned-off-by: Y.Hisaki \n\n* add comment\n\nSigned-off-by: Y.Hisaki \n\n---------\n\nSigned-off-by: Y.Hisaki ","commit-date":"2025-09-02T03:16:19Z","current-rev":"42dec2a31f","filename":"autoware_universe/planning/behavior_velocity_planner/autoware_behavior_velocity_traffic_light_module/src/manager.cpp","previous-rev":"83ef381955","commit-title":"fix(traffic_light_module): update stop line when route changes (#11293)","language":"C++","id":"44628f541aba0738b1a1ca5075d65c377808b6d1","model-score":0.63,"author-id":null,"project-id":29372,"delta-file-score":0.61278176,"diff":"diff --git a/planning/behavior_velocity_planner/autoware_behavior_velocity_traffic_light_module/src/manager.cpp b/planning/behavior_velocity_planner/autoware_behavior_velocity_traffic_light_module/src/manager.cpp\nindex ca7c448c37..434fe02e16 100644\n--- a/planning/behavior_velocity_planner/autoware_behavior_velocity_traffic_light_module/src/manager.cpp\n+++ b/planning/behavior_velocity_planner/autoware_behavior_velocity_traffic_light_module/src/manager.cpp\n@@ -119,7 +119,8 @@ void TrafficLightModuleManager::launchNewModules(\n const auto lane_id = traffic_light_reg_elem.second.id();\n- if (!isModuleRegisteredFromExistingAssociatedModule(lane_id)) {\n+ auto existing_module = getRegisteredAssociatedModule(lane_id);\n+ if (!existing_module) {\n registerModule(\n std::make_shared(\n- lane_id, *(traffic_light_reg_elem.first), traffic_light_reg_elem.second, planner_param_,\n- logger_.get_child(\"traffic_light_module\"), clock_, time_keeper_,\n+ lane_id, *(traffic_light_reg_elem.first), traffic_light_reg_elem.second, *stop_line,\n+ planner_param_, logger_.get_child(\"traffic_light_module\"), clock_, time_keeper_,\n planning_factor_interface_));\n@@ -129,2 +130,5 @@ void TrafficLightModuleManager::launchNewModules(\n path.header.stamp);\n+ } else {\n+ // Update the stop line for the existing module\n+ existing_module->updateStopLine(*stop_line);\n }\n@@ -143,3 +147,3 @@ TrafficLightModuleManager::getModuleExpiredFunction(\n for (const auto & id : lanelet_id_set) {\n- if (isModuleRegisteredFromExistingAssociatedModule(id)) {\n+ if (getRegisteredAssociatedModule(id)) {\n return false;\n@@ -151,3 +155,3 @@ TrafficLightModuleManager::getModuleExpiredFunction(\n \n-bool TrafficLightModuleManager::isModuleRegisteredFromExistingAssociatedModule(\n+std::shared_ptr TrafficLightModuleManager::getRegisteredAssociatedModule(\n const lanelet::Id & id) const\n@@ -157,9 +161,19 @@ bool TrafficLightModuleManager::isModuleRegisteredFromExistingAssociatedModule(\n for (const auto & registered_id : registered_module_id_set_) {\n- const auto registered_lane =\n- planner_data_->route_handler_->getLaneletMapPtr()->laneletLayer.get(registered_id);\n- for (const auto & registered_element : registered_lane.regulatoryElementsAs()) {\n- for (const auto & element : lane.regulatoryElementsAs()) {\n- if (hasSameTrafficLight(element, registered_element)) {\n- return true;\n- }\n+ if (hasAssociatedTrafficLight(lane, registered_id)) {\n+ return findModuleById(registered_id);\n+ }\n+ }\n+ return nullptr;\n+}\n+\n+bool TrafficLightModuleManager::hasAssociatedTrafficLight(\n+ const lanelet::ConstLanelet & lane, const lanelet::Id & registered_id) const\n+{\n+ const auto registered_lane =\n+ planner_data_->route_handler_->getLaneletMapPtr()->laneletLayer.get(registered_id);\n+\n+ for (const auto & registered_element : registered_lane.regulatoryElementsAs()) {\n+ for (const auto & element : lane.regulatoryElementsAs()) {\n+ if (hasSameTrafficLight(element, registered_element)) {\n+ return true;\n }\n@@ -170,2 +184,13 @@ bool TrafficLightModuleManager::isModuleRegisteredFromExistingAssociatedModule(\n \n+std::shared_ptr TrafficLightModuleManager::findModuleById(\n+ const lanelet::Id & module_id) const\n+{\n+ for (const auto & scene_module : scene_modules_) {\n+ if (scene_module->getModuleId() == module_id) {\n+ return std::dynamic_pointer_cast(scene_module);\n+ }\n+ }\n+ return nullptr;\n+}\n+\n bool TrafficLightModuleManager::hasSameTrafficLight(\n","improvement-type":"Deep, Nested Complexity"},{"architectural-component-id":null,"author-name":"lei.gu","training-data":{"loc-added":"21","loc-deleted":"14","delta-cc-mean":"0.0","delta-cc-total":"0","delta-penalties":"2.0","delta-n-functions":"0","current-file-score":"7.384117463736593"},"author-email":"lei.gu@tier4.jp","commit-full-message":"* feat(multi_object_tracker): enhance pedestrian handling in tracker association and merging\n\n- Introduced a distance-based scoring mechanism for pedestrian measurements in the DataAssociation class, bypassing the IoU check.\n- Updated the mergeOverlappedTracker method to implement specific merging criteria for overlapping pedestrian trackers, improving accuracy in tracking.\n- Added a new helper function, canMergePedestrianTargets, to encapsulate the logic for merging pedestrian targets based on confidence and distance.\n\nThese changes enhance the robustness of the multi-object tracking system, particularly for pedestrian detection and association.\n\nSigned-off-by: lei.gu \n\n* refactor(multi_object_tracker): improve scoring logic and optimize probability vector handling\n\n- Updated the scoring logic in the DataAssociation class to return a score of 0.0 when below the threshold, enhancing clarity in score calculations for pedestrian measurements.\n- Changed the handling of existence probability vectors in the TrackerProcessor class to use const references, improving performance by avoiding unnecessary copies.\n\nThese changes aim to enhance the efficiency and readability of the multi-object tracking system.\n\nSigned-off-by: lei.gu \n\n* feat(multi_object_tracker): add 1D IoU calculation and enhance tracker merging logic\n\n- Introduced a new function, get1dIoU, for calculating the Intersection over Union (IoU) for 1D objects, improving the tracking accuracy for specific scenarios.\n- Updated the mergeOverlappedTracker method to utilize the new 1D IoU calculation for pedestrian tracking, enhancing the merging criteria based on IoU thresholds.\n- Refactored the canMergeOverlappedTarget function to streamline the merging logic and improve readability.\n\nThese changes aim to enhance the robustness and accuracy of the multi-object tracking system, particularly for pedestrian detection and association.\n\nSigned-off-by: lei.gu \n\n* refactor(multi_object_tracker): update IoU calculations for pedestrian tracking\n\n- Modified the scoring logic in the DataAssociation class to utilize 1D IoU for pedestrian measurements, enhancing the accuracy of the association process.\n- Adjusted the minimum union length threshold in the get1dIoU function to improve the robustness of the IoU calculation for 1D objects.\n\nThese changes aim to refine the multi-object tracking system's handling of pedestrian detection and association, ensuring more reliable tracking performance.\n\nSigned-off-by: lei.gu \n\n* refactor(multi_object_tracker): enhance 1D IoU calculation logic\n\n- Updated the get1dIoU function to improve the accuracy of intersection over union calculations for 1D objects.\n- Adjusted the logic for determining radii and union length, ensuring more reliable IoU results in tracking scenarios.\n\nThese changes aim to further refine the multi-object tracking system's performance, particularly in pedestrian detection and association.\n\nSigned-off-by: lei.gu \n\n* refactor(multi_object_tracker): improve 1D IoU calculation for accuracy\n\n- Enhanced the get1dIoU function by refining the logic for radius computation and distance checks, ensuring more accurate intersection over union results for 1D objects.\n- Adjusted the handling of minimum length and union length calculations to improve robustness in tracking scenarios.\n\nThese updates aim to further optimize the multi-object tracking system's performance, particularly in pedestrian detection and association.\n\nSigned-off-by: lei.gu \n\n* refactor(multi_object_tracker): further refine 1D IoU calculation\n\n- Updated the get1dIoU function to use constexpr for minimum lengths and const for radius calculations, enhancing code clarity and performance.\n- Adjusted the IoU calculation logic to improve accuracy in determining intersection over union for 1D objects.\n\nThese changes aim to optimize the multi-object tracking system's performance, particularly in pedestrian detection and association.\n\nSigned-off-by: lei.gu \n\n* refactor(multi_object_tracker): simplify 1D IoU calculation logic\n\n- Revised the get1dIoU function to streamline the calculation of intersection over union for 1D objects.\n- Removed redundant comments and improved the clarity of the logic for determining intersection and union lengths.\n\nThese changes aim to enhance the readability and maintainability of the multi-object tracking system's IoU calculations.\n\nSigned-off-by: lei.gu \n\n* refactor(multi_object_tracker): correct intersection length calculation in get1dIoU\n\n- Fixed the calculation of intersection length in the get1dIoU function to ensure accurate results for 1D IoU.\n- This change enhances the reliability of intersection over union calculations, contributing to improved performance in multi-object tracking scenarios.\n\nSigned-off-by: lei.gu \n\n---------\n\nSigned-off-by: lei.gu ","commit-date":"2025-07-09T07:13:21Z","current-rev":"aabb41122c","filename":"autoware_universe/perception/autoware_multi_object_tracker/src/processor/processor.cpp","previous-rev":"d0a0c73537","commit-title":"perf(multi_object_tracker): fast IoU calculation in the tracker association and merging (#10929)","language":"C++","id":"3172bb23bb619231421d14aae7f289a185d44b45","model-score":0.33,"author-id":null,"project-id":29372,"delta-file-score":0.54687583,"diff":"diff --git a/perception/autoware_multi_object_tracker/src/processor/processor.cpp b/perception/autoware_multi_object_tracker/src/processor/processor.cpp\nindex f882102a4a..760b5cf4fa 100644\n--- a/perception/autoware_multi_object_tracker/src/processor/processor.cpp\n+++ b/perception/autoware_multi_object_tracker/src/processor/processor.cpp\n@@ -234,2 +234,19 @@ void TrackerProcessor::mergeOverlappedTracker(const rclcpp::Time & time)\n \n+ auto isIoUOverThreshold = [this](\n+ const TrackerData & source_data, const TrackerData & target_data) {\n+ constexpr double min_union_iou_area = 1e-2;\n+ constexpr float min_known_prob = 0.2;\n+ constexpr double min_valid_iou = 1e-6;\n+ bool is_pedestrian =\n+ (source_data.label == Label::PEDESTRIAN && target_data.label == Label::PEDESTRIAN);\n+ bool is_target_known = target_data.tracker->getKnownObjectProbability() >= min_known_prob;\n+ const auto iou =\n+ is_pedestrian ? shapes::get1dIoU(source_data.object, target_data.object)\n+ : shapes::get2dIoU(source_data.object, target_data.object, min_union_iou_area);\n+ if (iou < min_valid_iou) return false;\n+\n+ return is_target_known ? iou > config_.min_known_object_removal_iou\n+ : iou > config_.min_unknown_object_removal_iou;\n+ };\n+\n std::vector valid_trackers;\n@@ -327,10 +344,5 @@ void TrackerProcessor::mergeOverlappedTracker(const rclcpp::Time & time)\n \n- // Calculate IoU only if necessary\n- constexpr double min_union_iou_area = 1e-2;\n- const auto iou = shapes::get2dIoU(data2.object, data1.object, min_union_iou_area);\n-\n- // Skip if IoU is too small\n- if (iou < 1e-6) continue;\n-\n- if (canMergeOverlappedTarget(*data2.tracker, *data1.tracker, time, iou)) {\n+ if (\n+ canMergeOverlappedTarget(*data2.tracker, *data1.tracker, time) &&\n+ isIoUOverThreshold(data2, data1)) {\n // Merge tracker2 into tracker1\n@@ -363,3 +375,3 @@ void TrackerProcessor::mergeOverlappedTracker(const rclcpp::Time & time)\n bool TrackerProcessor::canMergeOverlappedTarget(\n- const Tracker & target, const Tracker & other, const rclcpp::Time & time, const double iou) const\n+ const Tracker & target, const Tracker & other, const rclcpp::Time & time) const\n {\n@@ -382,28 +394,23 @@ bool TrackerProcessor::canMergeOverlappedTarget(\n // both are known class, check the IoU\n- if (iou > config_.min_known_object_removal_iou) {\n- // compare probability vector, prioritize lower index of the probability vector\n- std::vector target_existence_prob = target.getExistenceProbabilityVector();\n- std::vector other_existence_prob = other.getExistenceProbabilityVector();\n- constexpr float prob_buffer = 0.4;\n- for (size_t i = 0; i < target_existence_prob.size(); ++i) {\n- if (target_existence_prob[i] + prob_buffer < other_existence_prob[i]) {\n- // if a channel probability has a large difference in higher index, remove the target\n- return true;\n- }\n+ // compare probability vector, prioritize lower index of the probability vector\n+ std::vector target_existence_prob = target.getExistenceProbabilityVector();\n+ std::vector other_existence_prob = other.getExistenceProbabilityVector();\n+ constexpr float prob_buffer = 0.4;\n+ for (size_t i = 0; i < target_existence_prob.size(); ++i) {\n+ if (target_existence_prob[i] + prob_buffer < other_existence_prob[i]) {\n+ // if a channel probability has a large difference in higher index, remove the target\n+ return true;\n }\n-\n- // if there is no big difference in the probability per channel, compare the covariance size\n- return target.getPositionCovarianceDeterminant() > other.getPositionCovarianceDeterminant();\n }\n+\n+ // if there is no big difference in the probability per channel, compare the covariance size\n+ return target.getPositionCovarianceDeterminant() > other.getPositionCovarianceDeterminant();\n }\n // 2. the target class is unknown, check the IoU\n- if (iou > config_.min_unknown_object_removal_iou) {\n- if (other_known_prob < min_known_prob) {\n- // both are unknown, remove the larger uncertainty one\n- return target.getPositionCovarianceDeterminant() > other.getPositionCovarianceDeterminant();\n- }\n- // if the other class is known, remove the target\n- return true;\n+ if (other_known_prob < min_known_prob) {\n+ // both are unknown, remove the larger uncertainty one\n+ return target.getPositionCovarianceDeterminant() > other.getPositionCovarianceDeterminant();\n }\n- return false;\n+ // if the other class is known, remove the target\n+ return true;\n }\n","improvement-type":"Deep, Nested Complexity"}],"change-level":"warning","is-hotspot?":false,"line":185,"what-changed":"ObstacleMetricsCalculator::ProcessObstaclesTrajectory has a nested complexity depth of 6, threshold = 4","how-to-fix":"Occassionally, it's possible to get rid of the nested logic by [Replacing Conditionals with Guard Clauses](https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html).\n\nAnother viable strategy is to identify smaller building blocks inside the nested chunks of logic and extract those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring explains the steps.","change-type":"introduced"},{"method":"PlanningEvaluatorNode::onTrajectory","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"evaluator/autoware_planning_evaluator/src/planning_evaluator_node.cpp","refactoring-examples":[{"architectural-component-id":null,"author-name":"Taekjin LEE","training-data":{"loc-added":"11","loc-deleted":"14","delta-cc-mean":"0.0","delta-cc-total":"0","delta-penalties":"1.0","delta-n-functions":"0","current-file-score":"10.0"},"author-email":"taekjin.lee@tier4.jp","commit-full-message":"* feat(tracker_processor): set existence probability for tracked objects\n\nSigned-off-by: Taekjin LEE \n\n* refactor(tracker): rename classification parameter for clarity in updateClassification method\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): ensure minimum covariance values to prevent large Mahalanobis distance\n\nSigned-off-by: Taekjin LEE \n\n* feat(tracker): disable trust in existence probability for input channels\n\nSigned-off-by: Taekjin LEE \n\n* fix(tracker): update decay rate for existence probability to reflect a 0.5s half-life\n\nSigned-off-by: Taekjin LEE \n\n* style(pre-commit): autofix\n\nSigned-off-by: Taekjin LEE \n\n* fix(association): correct spelling of \"mahalanobis\" in comment for clarity\n\nSigned-off-by: Taekjin LEE \n\n---------\n\nSigned-off-by: Taekjin LEE \nCo-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>","commit-date":"2025-08-04T07:38:26Z","current-rev":"47a0fb82f4","filename":"autoware_universe/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp","previous-rev":"70be106253","commit-title":"fix(autoware_multi_object_tracker): existence probability adjustment to mitigate tracker lost (#11109)","language":"C++","id":"410ebd13723902158abcb4c2d1698bc1c3c4c442","model-score":0.54,"author-id":null,"project-id":29372,"delta-file-score":0.31179166,"diff":"diff --git a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\nindex 094c9537a9..7c34b30b36 100644\n--- a/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n+++ b/perception/autoware_multi_object_tracker/lib/tracker/model/tracker_base.cpp\n@@ -46,3 +46,3 @@ float decayProbability(const float & prior, const float & delta_time)\n constexpr float minimum_probability = 0.001;\n- const float decay_rate = log(0.5f) / 0.3f; // half-life (50% decay) of 0.3s\n+ const float decay_rate = log(0.5f) / 0.5f; // half-life (50% decay) of 0.5s\n return std::max(prior * std::exp(decay_rate * delta_time), minimum_probability);\n@@ -135,7 +135,4 @@ bool Tracker::updateWithMeasurement(\n // update total existence probability\n- const double existence_probability = channel_info.trust_existence_probability\n- ? object.existence_probability\n- : types::default_existence_probability;\n total_existence_probability_ = updateProbability(\n- total_existence_probability_, existence_probability * probability_true_detection,\n+ total_existence_probability_, object.existence_probability * probability_true_detection,\n probability_false_detection);\n@@ -195,3 +192,3 @@ bool Tracker::updateWithoutMeasurement(const rclcpp::Time & timestamp)\n void Tracker::updateClassification(\n- const std::vector & classification)\n+ const std::vector & input)\n {\n@@ -223,6 +220,6 @@ void Tracker::updateClassification(\n // Normalize the input\n- auto classification_input = classification;\n+ auto classification_input = input;\n normalizeProbabilities(classification_input);\n \n- auto & classification_ = object_.classification;\n+ auto & classification = object_.classification;\n \n@@ -231,3 +228,3 @@ void Tracker::updateClassification(\n bool found = false;\n- for (auto & old_class : classification_) {\n+ for (auto & old_class : classification) {\n if (new_class.label == old_class.label) {\n@@ -242,3 +239,3 @@ void Tracker::updateClassification(\n adding_class.probability *= gain;\n- classification_.push_back(adding_class);\n+ classification.push_back(adding_class);\n }\n@@ -247,10 +244,10 @@ void Tracker::updateClassification(\n // If the probability is less than the threshold, remove the class\n- classification_.erase(\n+ classification.erase(\n std::remove_if(\n- classification_.begin(), classification_.end(),\n+ classification.begin(), classification.end(),\n [remove_threshold](const auto & a_class) { return a_class.probability < remove_threshold; }),\n- classification_.end());\n+ classification.end());\n \n // Normalize tracking classification\n- normalizeProbabilities(classification_);\n+ normalizeProbabilities(classification);\n }\n","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":380,"what-changed":"PlanningEvaluatorNode::onTrajectory has a cyclomatic complexity of 14, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"PlanningEvaluatorNode::onTrajectory","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is levels of conditionals.","name":"Bumpy Road Ahead","file":"evaluator/autoware_planning_evaluator/src/planning_evaluator_node.cpp","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":380,"what-changed":"PlanningEvaluatorNode::onTrajectory has 3 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"}]},"positive-impact-count":1,"repo":"autoware_universe","code-health":8.028981337677966,"version":"3.0","authors":["xtk8532704"],"directives":{"added":[],"removed":[]},"positive-findings":{"number-of-types":1,"number-of-files-touched":1,"findings":[{"method":"MetricsCalculator::calculate","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the C++ language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"evaluator/autoware_planning_evaluator/src/metrics_calculator.cpp","change-level":"improvement","is-hotspot?":false,"line":25,"what-changed":"MetricsCalculator::calculate decreases in cyclomatic complexity from 20 to 18, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"improved"}]},"notices":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"external-review-provider":"GitHub"},"analysistime":"2026-01-16T04:11:56.000Z","project-name":"autoware.universe","repository":"https://github.com/autowarefoundation/autoware_universe.git"}}