‹ Reports
The Dispatch

OSS Watchlist: px4/PX4-Autopilot


GitHub Logo GitHub Logo

Development Team and Recent Activity

Team Members and Their Most Recent Activity

Daniel Agar (dagar)

Bluedisk

Alex Klimaj (AlexKlimaj)

Peter van der Perk (PetervdPerk-NXP)

PX4 Build Bot (PX4BuildBot)

Matthias Grob (MaEtUgR)

Patrik Dominik Pordi (patrikpordi)

Silvan Fuhrer (sfuhrer)

Mathieu Bresciani (bresch)

Konrad Rudin (KonradRudin)

Patterns, Themes, and Conclusions

  1. Broad Involvement Across Modules: Key developers like Daniel Agar are involved in multiple areas including EKF2, flight mode management, and logging controls, indicating a holistic approach to development.
  2. Hardware Driver Improvements: Several commits focus on improving hardware drivers, such as UAVCAN and GNSS, reflecting ongoing efforts to enhance hardware compatibility and performance.
  3. Submodule Updates: Frequent updates to submodules like libevents suggest an emphasis on keeping dependencies up-to-date with upstream changes.
  4. System Resource Management: New checks for high RAM usage indicate a focus on improving system reliability by monitoring resource consumption.
  5. Parameter Management Enhancements: Updates in setup tools and logging controls show efforts to streamline configuration management for better system reliability.

Analysis of Progress Since Last Report

Since the last report seven days ago, there has been significant activity in the PX4 Autopilot Software project:

  1. EKF2 Module Enhancements:

    • Daniel Agar made several updates to the EKF2 module, including more conservative clipping checks for bad_acc_clipping fault status and introducing verbose logging control. These changes aim at improving the accuracy and reliability of the EKF2 module.
  2. Setup Tools Fixes:

    • Bluedisk fixed deprecated expressions in requirements.txt, ensuring that setup tools are using correct syntax.
  3. UAVCAN Driver Adjustments:

    • Alex Klimaj updated the UAVCAN GNSS driver to set system time based on fix_type instead of valid_pos_cov, likely improving GNSS time synchronization accuracy.
  4. NuttX Backports for SoC Support:

    • Peter van der Perk worked on backporting NuttX changes for imxrt1170 SoC support, indicating ongoing efforts to support a wider range of hardware platforms.
  5. Submodule Updates:

    • The PX4 Build Bot updated the libevents submodule to its latest version, ensuring that the project benefits from recent upstream improvements.
  6. System Resource Checks:

    • Matthias Grob added checks for high RAM usage, aiming to prevent issues related to resource exhaustion during operation.
  7. DDS Client Topic Updates:

    • Patrik Dominik Pordi added vehicle_land_detected to DDS topics, enhancing communication capabilities within the DDS client module.

Overall, the recent activities reflect a strong focus on enhancing system reliability through parameter management, improving hardware compatibility with optimized drivers, maintaining up-to-date dependencies, and expanding system checks for better resource management.

Risks

Invalid Mission with RTL Causes Crash

A critical bug where uploading an invalid mission during flight can cause a crash during Return-to-Launch (RTL), posing a significant safety risk. - Evidence: Issue #23340 details that an invalid mission upload can lead to a crash during RTL. - Reasoning: Crashes during RTL are critical as they occur during an emergency procedure, potentially leading to loss of the vehicle and endangering safety. - Next Steps: Prioritize fixing this bug immediately. Implement additional validation checks for mission uploads to prevent invalid missions from being accepted.

Continuous Integration (CI) Failures Due to VTOL SITL Tests

The failure of VTOL SITL tests on every pull request is a critical issue that disrupts the CI process, delaying development and integration of new features. - Evidence: Issue #23275 details that the RTL direct rally without approaches forced test is failing consistently on every PR. - Reasoning: Continuous integration failures can halt the development pipeline, preventing new code from being tested and merged, which can significantly slow down project progress. - Next Steps: Assign a dedicated team to investigate and resolve the root cause of the VTOL SITL test failures. Implement temporary workarounds or disable the failing test if necessary to unblock the CI pipeline while a permanent fix is developed.

Decline in Team Velocity

There is evidence of multiple PRs being left open without resolution, indicating a potential decline in team velocity. - Evidence: Multiple PRs such as #23236, #23233, #23229, #23228, and #23227 have been open for several days without resolution. - Reasoning: While not critical, the accumulation of unresolved PRs can slow down development progress and indicate potential bottlenecks in the review process. - Next Steps: Assign dedicated reviewers to address the backlog of open PRs. Implement stricter timelines for PR reviews and merges to ensure timely progress.

Prolonged Disagreement on Gimbal Control Logic

The changes in PR #23236 regarding gimbal control logic adjustments suggest potential prolonged disagreements or complexities in achieving consensus on control mechanisms. - Evidence: The detailed changes in gimbal control logic and the need for extensive testing across different scenarios indicate potential areas of disagreement or complexity. - Reasoning: Disagreements or complexities in core control logic can delay feature releases and affect overall project stability. - Next Steps: Facilitate discussions among key stakeholders to reach a consensus on gimbal control logic. Conduct thorough testing and gather feedback from users to validate the changes.

Ambiguous Specifications for EKF2 Enhancements

The recent updates to EKF2 modules such as innovation sequence monitoring (#23233) and mag spikes preflight errors (#23229) indicate ambiguous specifications that may lead to implementation challenges. - Evidence: The issues and PRs related to EKF2 enhancements involve complex algorithms and state estimation logic, which may not be clearly defined. - Reasoning: Ambiguous specifications can lead to multiple rewrites and delays in achieving stable implementations. - Next Steps: Clarify specifications and acceptance criteria for EKF2 enhancements. Engage domain experts to review and refine the implementation details.

Of Note

System Resource Management

Matthias Grob's addition of high RAM usage checks indicates an increased focus on monitoring system resources. This proactive measure aims at preventing potential issues related to resource exhaustion during operation.

Parameter Management Enhancements

Bluedisk's fixes in requirements.txt highlight ongoing efforts to streamline configuration management. Ensuring correct syntax in setup tools is crucial for maintaining system reliability across different environments.

Hardware Driver Improvements

Alex Klimaj's updates to UAVCAN GNSS drivers reflect continuous efforts towards enhancing hardware compatibility. Accurate time synchronization based on fix_type rather than valid_pos_cov improves overall GNSS performance.

Detailed Reports

Report On: Fetch commits



Development Team and Recent Activity

Team Members and Their Most Recent Activity

Daniel Agar (dagar)

  • Commits:
    • 1 day ago: "ekf2: more conservative clipping checks for bad_acc_clipping fault status (#23337)"
    • 1 day ago: "ekf2: verbose logging control (new EKF2_LOG_VERBOSE)"
    • 2 days ago: "flight_mode_manager: delete unused avoidance waypoint"
    • 2 days ago: "ekf2: verbose logging control (new EKF2_LOG_VERBOSE)"
    • 2 days ago: "ekf2: verbose logging control (new EKF2_LOG_VERBOSE)"
  • Collaborations:
    • Frequent updates across multiple modules, indicating broad involvement in the project.

Bluedisk

  • Commits:
    • 1 day ago: "Tools/setup: fix the wrong - deprecated - expression in the requirements.txt"
  • Collaborations:
    • Worked on fixing issues in the setup tools.

Alex Klimaj (AlexKlimaj)

  • Commits:
    • 1 day ago: "drivers/uavcan: GNSS set system time based on fix_type instead of valid_pos_cov"
    • 5 days ago: "boards ark pi6x add vl53l0x"
  • Collaborations:
    • Focused on UAVCAN drivers and board configurations.

Peter van der Perk (PetervdPerk-NXP)

  • Commits:
    • 2 days ago: "NuttX with imxrt1170 soc vdd backport (#23333)"
  • Collaborations:
    • Worked on NuttX backports for specific SoC support.

PX4 Build Bot (PX4BuildBot)

  • Commits:
    • 2 days ago: "Update submodule libevents to latest Thu Jun 27 12:39:19 UTC 2024"
  • Collaborations:
    • Automated updates to keep submodules current.

Matthias Grob (MaEtUgR)

  • Commits:
    • 3 days ago: "Add check for high RAM usage"
  • Collaborations:
    • Added system checks for resource usage.

Patrik Dominik Pordi (patrikpordi)

  • Commits:
    • 2 days ago: "uxrce_dds_client: dds_topics.yaml add vehicle_land_detected"
  • Collaborations:
    • Updated DDS client topics.

Silvan Fuhrer (sfuhrer)

  • Commits:
    • None in the last week.

Mathieu Bresciani (bresch)

  • Commits:
    • None in the last week.

Konrad Rudin (KonradRudin)

  • Commits:
    • None in the last week.

Patterns, Themes, and Conclusions

  1. Broad Involvement Across Modules: Key developers like Daniel Agar are involved in multiple areas including EKF2, flight mode management, and logging controls, indicating a holistic approach to development.
  2. Hardware Driver Improvements: Several commits focus on improving hardware drivers, such as UAVCAN and GNSS, reflecting ongoing efforts to enhance hardware compatibility and performance.
  3. Submodule Updates: Frequent updates to submodules like libevents suggest an emphasis on keeping dependencies up-to-date with upstream changes.
  4. System Resource Management: New checks for high RAM usage indicate a focus on improving system reliability by monitoring resource consumption.
  5. Parameter Management Enhancements: Updates in setup tools and logging controls show efforts to streamline configuration management for better system reliability.

Analysis of Progress Since Last Report

Since the last report seven days ago, there has been significant activity in the PX4 Autopilot Software project:

  1. EKF2 Module Enhancements:

    • Daniel Agar made several updates to the EKF2 module, including more conservative clipping checks for bad_acc_clipping fault status and introducing verbose logging control. These changes aim at improving the accuracy and reliability of the EKF2 module.
  2. Setup Tools Fixes:

    • Bluedisk fixed deprecated expressions in requirements.txt, ensuring that setup tools are using correct syntax.
  3. UAVCAN Driver Adjustments:

    • Alex Klimaj updated the UAVCAN GNSS driver to set system time based on fix_type instead of valid_pos_cov, likely improving GNSS time synchronization accuracy.
  4. NuttX Backports for SoC Support:

    • Peter van der Perk worked on backporting NuttX changes for imxrt1170 SoC support, indicating ongoing efforts to support a wider range of hardware platforms.
  5. Submodule Updates:

    • The PX4 Build Bot updated the libevents submodule to its latest version, ensuring that the project benefits from recent upstream improvements.
  6. System Resource Checks:

    • Matthias Grob added checks for high RAM usage, aiming to prevent issues related to resource exhaustion during operation.
  7. DDS Client Topic Updates:

    • Patrik Dominik Pordi added vehicle_land_detected to DDS topics, enhancing communication capabilities within the DDS client module.

Overall, the recent activities reflect a strong focus on enhancing system reliability through parameter management, improving hardware compatibility with optimized drivers, maintaining up-to-date dependencies, and expanding system checks for better resource management.

Report On: Fetch issues



Analysis of Recent Changes in PX4 Autopilot Project

Summary of Recent Changes

Notable Open Issues

  1. Issue #23342: ekf2: continue adding IMU bias process noise

    • Details: Created by Daniel Agar, this issue focuses on continuing to add accelerometer/gyroscope bias process noise even if inhibited.
    • Significance: This could improve the accuracy and reliability of the EKF2 estimator by ensuring that bias process noise is consistently accounted for.
  2. Issue #23341: ekf2: remove legacy accel z bias checks

    • Details: Also created by Daniel Agar, this issue proposes removing legacy checks for accelerometer z-axis bias.
    • Significance: Simplifies the codebase and may enhance performance by removing outdated checks.
  3. Issue #23340: Invalid mission with RTL causes crash

    • Details: Created by Ryan Johnston, this issue describes a bug where uploading an invalid mission while in flight can cause a crash during Return-to-Launch (RTL).
    • Significance: Critical for safety; needs immediate attention to prevent crashes during vulnerable phases like RTL.
  4. Issue #23338: [WIP] commander: remove multicopter nav test

    • Details: Created by Daniel Agar, this issue suggests removing the multicopter navigation test in the commander module.
    • Significance: Needs careful review as it might affect navigation reliability. The removal is proposed due to potential false positives that could harm the system.
  5. Issue #23336: [Bug] make px4_sitl gazebo is not working

    • Details: Created by lucamonte, this issue reports an error when running make px4_sitl gazebo with PX4 v1.14.0.
    • Significance: Important for developers using SITL (Software In The Loop) for testing and development.
  6. Issue #23335: ekf2: use bias corrected angular velocity

    • Details: Created by Daniel Agar, this issue proposes using bias-corrected angular velocity when correcting velocity for position offsets.
    • Significance: Enhances the accuracy of velocity corrections, particularly for setups using GNSS antenna positions.
  7. Issue #23334: Update aux_global_position.cpp

    • Details: Created by None (ydv129), this issue aims to solve problems related to EKF2 GPS position parameters.
    • Significance: Enhances robustness and accuracy of state estimation by allowing auxiliary global position data.
  8. Issue #23332: Autostart: load all airframes IDs with priority ROMFS -> SD card

    • Details: Created by Matthias Grob, this issue proposes loading airframe files from ROMFS first and then from the SD card.
    • Significance: Improves flexibility and reduces confusion related to airframe file locations.
  9. Issue #23331: [Bug] GotoControl: No yaw when drone is facing backward

    • Details: Created by None (avidoramzn), this issue describes a bug where the drone does not change its yaw when facing backward.
    • Significance: Critical for navigation and control; needs fixing to ensure correct yaw behavior.
  10. Issue #23326 & #23324

    • Various enhancements related to EKF2 optical flow logic cleanup and MRO Control Zero H7 OEM USART6 support.
    • Significance: These changes improve sensor fusion logic and extend hardware support.

Recently Closed Issues

  1. Issue #23339 & #23337 & #23333

    • Various fixes including setting system time based on fix_type, more conservative clipping checks in EKF2, and updating NuttX.
    • Significance: Enhances system stability and hardware compatibility.
  2. Issue #23330 & #23329

    • Fixes related to deprecated syntax in requirements.txt and adding VehicleLandDetected to DDS topics configuration.
    • Significance: Ensures compatibility with newer pip versions and improves DDS middleware handling.
  3. Issue #23327 & #23325

    • Minor fixes including deleting unused avoidance waypoint and adding check for high RAM usage.
    • Significance: Improves code cleanliness and system resource monitoring.
  4. Issue #23291 & #23290

    • Updates to submodules libevents and mavlink.
    • Significance: Keeps dependencies up-to-date, ensuring compatibility and access to new features.
  5. Issue #23288 & #23287

    • Fixes related to gimbal input handling and moving estimator_status test ratios to filtered values in EKF2.
    • Significance: Enhances gimbal control reliability and improves innovation monitoring in EKF2.
  6. Issue #23286 & #23285

    • Efficiency improvements in magnetometer probe function and updating all px4board kconfig.
    • Significance: Optimizes sensor initialization and ensures consistent board configurations.
  7. Issue #23284 & #23283

    • Updates to all NuttX defconfigs and gz submodule.
    • Significance: Ensures up-to-date configurations and dependencies for better stability and performance.
  8. Issue #23282 & #23280

    • Purging deprecated RC switch parameters and adding initial frame support to vehicle_command.
    • Significance: Cleans up obsolete parameters and enhances command flexibility.
  9. Issue #23278 & #23276

    • Disabling CONFIG_DRIVERS_TONE_ALARM for flash savings on v5_stackcheck build and updating gazebo classic.
    • Significance: Addresses flash overflow issues and ensures up-to-date simulation environments.

Summary

The recent activity reflects ongoing efforts to enhance PX4's capabilities, address various bugs, and improve system stability and reliability. Notable improvements include better handling of IMU bias process noise, enhanced gimbal control reliability, improved innovation monitoring in EKF2, and expanded hardware support with new board additions like MRO Control Zero H7 OEM USART6 support.

Several critical bugs have been fixed, particularly those affecting continuous integration (CI) processes, ensuring that new changes do not introduce regressions or instability into the system. The project continues to show significant progress in expanding its capabilities across different domains, including new hardware support, marine vehicle integration, and space robotics applications.

Overall, these changes reflect an active maintenance effort aimed at improving PX4's versatility, reliability, and developer experience across various modules of the system.

Report On: Fetch PR 23342 For Assessment



PR #23342

Summary of Changes

This pull request introduces modifications to the EKF/covariance.cpp file and updates two CSV test files. The primary change in the code is related to the handling of IMU bias process noise for accelerometers and gyroscopes. Specifically, the changes ensure that process noise is always added to the bias states, even if they are inhibited.

Detailed Analysis

Code Changes

  1. File: src/modules/ekf2/EKF/covariance.cpp

    • Lines Modified: 4 lines changed (2 additions, 2 deletions)
    • Key Changes:
    • The condition to add process noise to gyro and accel bias states has been modified.
    • Previously, process noise was added only if the state was not inhibited (!_gyro_bias_inhibit[index] and !_accel_bias_inhibit[index]).
    • Now, process noise is added if the variance of the state is below a certain threshold (P(i, i) < gyro_var for gyro and P(i, i) < accel_var(index) for accel).
  2. Files: src/modules/ekf2/test/change_indication/ekf_gsf_reset.csv and src/modules/ekf2/test/change_indication/iris_gps.csv

    • Lines Modified: 300 lines changed (150 additions, 150 deletions)
    • Key Changes:
    • These files have been updated to reflect the new behavior in the covariance prediction logic.
    • The changes are primarily numerical adjustments in the state values to align with the updated logic.

Code Quality Assessment

  1. Correctness:

    • The changes appear to be logically sound. By ensuring that process noise is always added based on variance thresholds rather than inhibition flags, the robustness of state estimation can be improved.
    • This modification helps in maintaining a more accurate covariance matrix, which is crucial for sensor fusion and overall system performance.
  2. Readability:

    • The comments in the code have been updated to reflect the new logic, which enhances readability.
    • The code remains clear and concise, with well-defined conditions for adding process noise.
  3. Maintainability:

    • The changes are minimal and localized, making them easy to maintain.
    • The use of variance thresholds instead of inhibition flags simplifies the logic, potentially reducing future debugging efforts.
  4. Testing:

    • The updates to the test CSV files indicate that the changes have been tested against existing datasets.
    • Ensuring that tests pass with these modifications provides confidence in the correctness of the implementation.

Conclusion

The changes introduced in this pull request enhance the handling of IMU bias process noise by ensuring that it is always added based on variance thresholds. This approach improves the robustness of state estimation in the EKF2 module. The modifications are minimal yet impactful, maintaining high code quality and readability. The updates to test files further validate the correctness of these changes.

Overall, this pull request represents a positive step towards improving sensor fusion accuracy and system performance in the PX4 Autopilot software.

Report On: Fetch pull requests



Analysis of Progress Since Last Report

Summary

Since the previous analysis 7 days ago, there has been significant activity in the PX4/PX4-Autopilot repository. Several new pull requests (PRs) have been created, and some notable PRs have been merged or closed. Below is a detailed analysis of the changes.

New Pull Requests

  1. #23342: ekf2: continue adding IMU bias process noise

    • State: Open
    • Created: 0 days ago
    • Summary: Continues adding accelerometer/gyroscope bias process noise even if inhibited.
    • Significance: Enhances the accuracy of IMU bias estimation.
  2. #23341: ekf2: remove legacy accel z bias checks

    • State: Open
    • Created: 0 days ago
    • Summary: Removes outdated accelerometer Z bias checks.
    • Significance: Cleans up legacy code, improving maintainability.
  3. #23338: [WIP] commander: remove multicopter nav test

    • State: Open (Draft)
    • Created: 1 day ago
    • Summary: Proposes removing the multicopter navigation test in the commander module.
    • Significance: Needs careful review to ensure it doesn't negatively impact navigation reliability.
  4. #23335: ekf2: use bias corrected angular velocity

    • State: Open
    • Created: 2 days ago
    • Summary: Updates to use bias-corrected angular velocity for position offset corrections.
    • Significance: Improves accuracy in setups with GNSS antenna positions.
  5. #23334: Update aux_global_position.cpp

    • State: Open
    • Created: 2 days ago, edited 1 day ago
    • Summary: Enhances EKF to use auxiliary global position data.
    • Significance: Increases robustness and accuracy of state estimation.
  6. #23332: Autostart: load all airframes IDs with priority ROMFS -> SD card

    • State: Open
    • Created: 2 days ago
    • Summary: Proposes loading airframe files with priority from ROMFS and then SD card.
    • Significance: Improves flexibility in updating vehicle configurations.
  7. #23326: ekf2 optical flow logic cleanup

    • State: Open
    • Created: 3 days ago, edited 1 day ago
    • Summary: Cleans up optical flow logic and fixes related issues.
    • Significance: Enhances reliability and performance of optical flow fusion.
  8. #23317: Duplicate empty _node check removed from Subscription.hpp (#23316)

    • State: Open
    • Created: 7 days ago, edited 1 day ago
    • Summary: Removes duplicate empty node check in Subscription.hpp.
    • Significance: Refactors code for better maintainability.
  9. #23315: ekf2: require valid filter vz for GPS vspeed check State: Open, created: Created, edited: Edited, Summary: Introduces a requirement for a valid filter vertical speed (vz) for GPS vertical speed check. Significance: Enhances the reliability of GPS vertical speed checks by ensuring valid filter data.

  10. #23314: mavlink: with cmake policy CMP0118 verion 3.20 we can depend on the mavlink_c library State: Open, created: Created, edited: Edited, Summary: Updates CMake policy to version 3.20 to depend on the mavlink_c library instead of including its content in multiple places. Significance:** Simplifies build configuration and reduces redundancy in CMake files.

Recently Closed/Merged Pull Requests

  1. #23339: can gps set system time based on fix_type instead of valid_pos_cov State: Closed, created: Created, closed: Merged by Daniel Agar (dagar) Summary: Sets system time based on GPS fix type instead of position covariance validity. Significance: Ensures system time is set correctly even for certain CAN GPS without position covariance.

  2. #23337: ekf2: more conservative clipping checks before declaring bad_acc_clipping fault status State: Closed, created: Created, closed: Merged by Daniel Agar (dagar) Summary: Implements more conservative clipping checks before declaring bad accelerometer clipping fault status. Significance:** Reduces unnecessary estimator selection switching due to brief clipping events.

  3. #23333: Update NuttX State: Closed, created: Created, closed: Merged by Daniel Agar (dagar) Summary: Updates NuttX to include imxrt1170 SOC VDD fix. Significance: Enhances hardware compatibility and stability.

  4. #23330: Fix the deprecated syntax in the "Tools/setup/requirements.txt" State: Closed, created: Created, edited: Edited, closed: Merged by Daniel Agar (dagar) Summary: Fixes deprecated syntax in Tools/setup/requirements.txt. Significance: Ensures compatibility with pip version 24.1 and above.

  5. #23328: Update dds_topics.yaml State: Closed, created: Created, closed: Merged by Daniel Agar (dagar) Summary: Adds px4_msgs::msg::VehicleLandDetected to dds_topics.yaml. Significance: Ensures proper handling of landing state information in DDS-based systems.

  6. #23327: flight_mode_manager: delete unused avoidance waypoint State: Closed, created: Created, closed: Merged by Daniel Agar (dagar) Summary: Deletes unused avoidance waypoint in flight mode manager. Significance:** Cleans up codebase, improving maintainability.

  7. #23325: Add check for high RAM usage State: Closed, created: Created, edited: Edited, closed: Merged by Matthias Grob (MaEtUgR) Summary: Extends existing CPU load check to also look at RAM usage. Significance: Improves system monitoring by checking RAM usage.

  8. #23322: boards ark pi6x add vl53l0x State: Closed, created: Created, closed: Merged by Daniel Agar (dagar) Summary: Adds support for VL53L0X distance sensor on ARK Pi6X board. Significance: Enhances sensor support for ARK Pi6X board.

  9. #23291: Update submodule libevents to latest Tue Jun 18 12:3940 UTC 2024 State: Closed, created: Created, edited: Edited, closed: Merged by Daniel Agar (dagar) Summary: Updates libevents submodule to the latest version. Significance: Ensures compatibility with the latest libevents updates.

  10. #23263: EKF2 Terrain state State: Closed, created: Created, edited: Edited, closed: Merged by Silvan Fuhrer (sfuhrer) Summary: Integrates terrain estimator into EKF2. Significance: Improves accuracy and reliability of terrain height estimation.*

Conclusion

There has been significant activity in the PX4/PX4-Autopilot repository since the last report. Several new PRs have been created, addressing various enhancements and bug fixes across different modules. Notably, there have been additions related to new hardware support, improvements in existing functionalities, and updates to CI/CD pipelines.

The recently merged PRs include critical bug fixes and enhancements that improve system stability and functionality. The ongoing PRs indicate active development efforts towards expanding hardware compatibility, improving control algorithms, and enhancing developer tools.

Overall, the repository is seeing active contributions that are likely to enhance its robustness and feature set in the near future.

Report On: Fetch Files For Assessment



Source Code Assessment

1. src/modules/ekf2/EKF/ekf.cpp

Structure and Quality Analysis

  • Initialization and Reset:

    • The init and reset functions are well-defined, ensuring that the state variables are properly initialized and reset.
    • The use of conditional compilation (#if defined(CONFIG_EKF2_*)) allows for modular inclusion of various sensors, enhancing flexibility.
  • Update Mechanism:

    • The update function is structured to check if the filter is initialized and if new IMU data is available before proceeding with state prediction and covariance updates.
    • The separation of concerns is maintained by delegating specific tasks to helper functions like predictState, predictCovariance, and controlFusionModes.
  • Filter Initialization:

    • The initialiseFilter function ensures that the filter is only initialized when valid IMU data is available, preventing erroneous initialization.
    • The use of low-pass filters for accelerometer and gyroscope data helps in stabilizing the initial tilt estimation.
  • State Prediction:

    • The predictState function correctly applies bias corrections to IMU data and uses quaternion multiplication for orientation updates.
    • The use of trapezoidal integration for velocity and position updates is appropriate for maintaining numerical stability.
  • Logging and Debugging:

    • The print_status function provides comprehensive logging of the EKF states, aiding in debugging and performance monitoring.
    • The use of ring buffers for storing IMU data ensures efficient data management.

Improvements

  • Code Duplication: There are multiple instances where similar checks are performed across different sensor types (e.g., _control_status.flags.*). This could be refactored into a helper function to reduce code duplication.
  • Error Handling: While the code handles initialization errors gracefully, additional logging or error messages could be added to provide more context in case of failures.

2. src/modules/ekf2/EKF/height_control.cpp

Structure and Quality Analysis

  • Height Control Logic:

    • The controlHeightFusion function orchestrates the height fusion process by invoking specific control functions for each sensor type (e.g., barometer, GNSS, range finder).
    • The fallback mechanism in checkHeightSensorRefFallback ensures robustness by switching to secondary height references when the primary reference fails.
  • Bias and Health Checks:

    • The checkVerticalAccelerationBias function performs thorough checks on vertical acceleration bias, including conditions based on various sensor innovations.
    • The checkVerticalAccelerationHealth function estimates the likelihood of inertial navigation falling based on vertical innovations, providing a robust mechanism for detecting accelerometer clipping.

Improvements

  • Code Duplication: Similar to ekf.cpp, there are repeated checks for different sensor types. Refactoring these into a common utility function would improve maintainability.
  • Parameter Tuning: Some parameters (e.g., _params.vert_innov_test_min, _params.vert_innov_test_lim) are hardcoded. Consider making these configurable through parameters or macros.

3. src/modules/commander/HealthAndArmingChecks/checks/cpuResourceCheck.cpp

Structure and Quality Analysis

  • CPU and RAM Usage Checks:

    • The file introduces checks for high CPU load and RAM usage, which are critical for ensuring system stability during flight.
    • The use of hysteresis in _high_cpu_load_hysteresis prevents false positives by requiring sustained high CPU load before triggering a failure.
  • Event Reporting:

    • The code uses events (reporter.healthFailure) to log errors related to missing CPU/RAM load information or excessive usage, aiding in diagnostics.
    • Mavlink logging (mavlink_log_critical) ensures that critical issues are communicated effectively to ground control stations.

Improvements

  • Code Duplication: The checks for CPU load and RAM usage follow a similar pattern. Consider abstracting this logic into a common function to reduce redundancy.
  • Error Handling: Add more granular error messages or codes to differentiate between various failure modes (e.g., missing CPU info vs. high usage).

4. src/modules/ekf2/EKF2.cpp

Structure and Quality Analysis

  • Verbose Logging Control:

    • Introduction of verbose logging through the new parameter EKF2_LOG_VERBOSE enhances debugging capabilities by allowing detailed logging when needed.
  • Parameter Management:

    • Addition of new parameters improves configurability and allows fine-tuning of EKF behavior based on specific requirements.

Improvements

  • File Length: At over 3000 lines, this file is quite large. Consider breaking it down into smaller, more manageable files or modules.
  • Documentation: Ensure that all new parameters and logging controls are well-documented to aid users in understanding their purpose and usage.

5. src/modules/logger/logged_topics.cpp

Structure and Quality Analysis

  • Topic Management:

    • The file manages a comprehensive list of topics to be logged, categorized by their importance (e.g., default topics, high-rate topics).
  • Dynamic Topic Addition:

    • Functions like add_topics_from_file allow dynamic addition of topics from external files, enhancing flexibility.
  • Profile-Based Logging:

    • Use of profiles (SDLogProfileMask) enables selective logging based on different use cases (e.g., estimator replay, thermal calibration).

Improvements

  • Code Duplication: There are multiple instances where similar logic is used for adding topics. Abstracting this logic into reusable functions would improve maintainability.
  • Error Handling: Add error handling for file operations (e.g., checking if the file exists before attempting to open it) to make the code more robust.

Overall, the source code demonstrates good practices in terms of modularity, error handling, and configurability. However, there are opportunities for improvement in reducing code duplication, enhancing documentation, and improving error handling mechanisms.

Aggregate for risks



Notable Risks

Invalid Mission with RTL Causes Crash

Severity: High (3/3)

Rationale

A critical bug where uploading an invalid mission during flight can cause a crash during Return-to-Launch (RTL), posing a significant safety risk.

  • Evidence: Issue #23340 details that an invalid mission upload can lead to a crash during RTL.
  • Reasoning: Crashes during RTL are critical as they occur during an emergency procedure, potentially leading to loss of the vehicle and endangering safety.

Next Steps

  • Prioritize fixing this bug immediately.
  • Implement additional validation checks for mission uploads to prevent invalid missions from being accepted.

Continuous Integration (CI) Failures Due to VTOL SITL Tests

Severity: High (3/3)

Rationale

The failure of VTOL SITL tests on every pull request is a critical issue that disrupts the CI process, delaying development and integration of new features.

  • Evidence: Issue #23275 details that the RTL direct rally without approaches forced test is failing consistently on every PR.
  • Reasoning: Continuous integration failures can halt the development pipeline, preventing new code from being tested and merged, which can significantly slow down project progress.

Next Steps

  • Assign a dedicated team to investigate and resolve the root cause of the VTOL SITL test failures.
  • Implement temporary workarounds or disable the failing test if necessary to unblock the CI pipeline while a permanent fix is developed.

Decline in Team Velocity

Severity: Medium (2/3)

Rationale

There is evidence of multiple PRs being left open without resolution, indicating a potential decline in team velocity.

  • Evidence: Multiple PRs such as #23236, #23233, #23229, #23228, and #23227 have been open for several days without resolution.
  • Reasoning: While not critical, the accumulation of unresolved PRs can slow down development progress and indicate potential bottlenecks in the review process.

Next Steps

  • Assign dedicated reviewers to address the backlog of open PRs.
  • Implement stricter timelines for PR reviews and merges to ensure timely progress.

Prolonged Disagreement on Gimbal Control Logic

Severity: Medium (2/3)

Rationale

The changes in PR #23236 regarding gimbal control logic adjustments suggest potential prolonged disagreements or complexities in achieving consensus on control mechanisms.

  • Evidence: The detailed changes in gimbal control logic and the need for extensive testing across different scenarios indicate potential areas of disagreement or complexity.
  • Reasoning: Disagreements or complexities in core control logic can delay feature releases and affect overall project stability.

Next Steps

  • Facilitate discussions among key stakeholders to reach a consensus on gimbal control logic.
  • Conduct thorough testing and gather feedback from users to validate the changes.

Ambiguous Specifications for EKF2 Enhancements

Severity: Medium (2/3)

Rationale

The recent updates to EKF2 modules such as innovation sequence monitoring (#23233) and mag spikes preflight errors (#23229) indicate ambiguous specifications that may lead to implementation challenges.

  • Evidence: The issues and PRs related to EKF2 enhancements involve complex algorithms and state estimation logic, which may not be clearly defined.
  • Reasoning: Ambiguous specifications can lead to multiple rewrites and delays in achieving stable implementations.

Next Steps

  • Clarify specifications and acceptance criteria for EKF2 enhancements.
  • Engage domain experts to review and refine the implementation details.