Refactor ActionNode to isolate side effects via pure virtual methods

[takanotaiga]

Abstract

This pull request is a refactoring of the BehaviorTreePlugin proposed by ROBOTECH.

Background

N/A

Details

Extract common pre-/post-processing into the base ActionNode and introduce a pure virtual doAction() method.
Delegate all action-specific side effects (state updates, outputs) to derived classes for improved traceability and testability.

// Base class (defines pure virtual function)
class ActionNode : public BT::ActionNodeBase {
public:
  ActionNode(const std::string &name, const BT::NodeConfiguration &config)
  : BT::ActionNodeBase(name, config) {}

  BT::NodeStatus tick() override {
    // ① Common: Retrieve values from the blackboard
    getBlackBoardValues();
    // ② Common: Perform precondition checks
    if (!checkPreconditions()) {
      return BT::NodeStatus::FAILURE;
    }
    // ③ Delegate logic to derived class (pure virtual)
    return doAction();
  }

protected:
  virtual void getBlackBoardValues() {
    // Common blackboard reading logic
  }
  virtual bool checkPreconditions() { return true; }

  // Must be implemented by derived classes
  virtual BT::NodeStatus doAction() = 0;
};

// Example of a derived class
class ExampleAction : public ActionNode {
public:

protected:
  void getBlackBoardValues() override {
    ActionNode::getBlackBoardValues();
    // Retrieve additional vehicle-specific parameters
  }

  BT::NodeStatus doAction() override {
    // Consolidate logic such as calculateUpdatedEntityStatus,
    // setOutput(), and other side effects here
    return BT::NodeStatus::SUCCESS;  // or RUNNING/FAILURE
  }
};

References

• https://github.com/tier4/sim_evaluation_tools/issues/526
• https://tier4.atlassian.net/jira/software/c/projects/RT4/boards/446?assignee=712020%3A86ceb94c-d91a-412a-8dcf-056519a0fbf8&selectedIssue=RT4-16990

Destructive Changes

N/A

Known Limitations

N/A

[github-actions]

Checklist for reviewers ☑️

All references to "You" in the following text refer to the code reviewer.

• Is this pull request written in a way that is easy to read from a third-party perspective?
• Is there sufficient information (background, purpose, specification, algorithm description, list of disruptive changes, and migration guide) in the description of this pull request?
• If this pull request contains a destructive change, does this pull request contain the migration guide?
• Labels of this pull request are valid?
• All unit tests/integration tests are included in this pull request? If you think adding test cases is unnecessary, please describe why and cross out this line.
• The documentation for this pull request is enough? If you think adding documents for this pull request is unnecessary, please describe why and cross out this line.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
39.8% Coverage on New Code
1.1% Duplication on New Code

See analysis details on SonarQube Cloud