1295.37 ReactiveFallback의 매 Tick 재평가 원칙

1. 재평가 원칙의 정의

ReactiveFallback의 매 Tick 재평가 원칙(re-evaluation principle)은 ReactiveFallback 노드가 매 Tick마다 항상 첫 번째 자식 C_1부터 순차적으로 Tick을 전파한다는 동작 규칙이다. 이전 Tick에서 어떤 자식이 RUNNING을 반환하였는지와 무관하게, 새로운 Tick이 시작되면 자식 리스트의 최상단부터 평가를 재개한다.

이 원칙은 일반 Fallback 노드의 “기억 기반(memory-based)” 동작과 대비되는 “무기억(memoryless)” 동작이다. 일반 Fallback은 이전에 RUNNING을 반환한 자식의 인덱스를 기억하고 해당 자식부터 재개하지만, ReactiveFallback은 이러한 기억을 유지하지 않는다.

2. 재평가 원칙의 동작 과정

다음과 같은 ReactiveFallback 구조를 고려하라.

ReactiveFallback
├── C_1 (조건 노드)
├── C_2 (조건-행동 시퀀스)
└── C_3 (기본 행동)

2.1 Tick 1: 초기 상태

Tick 1:
  C_1.tick() → FAILURE    (조건 미충족)
  C_2.tick() → FAILURE    (조건 미충족)
  C_3.tick() → RUNNING    (기본 행동 실행 중)
  
  ReactiveFallback → RUNNING

C_1C_2가 모두 FAILURE를 반환하였으므로, C_3가 Tick되어 RUNNING을 반환한다. ReactiveFallback은 RUNNING을 반환한다.

2.2 Tick 2: 상위 조건 변화 없음

Tick 2:
  C_1.tick() → FAILURE    (조건 여전히 미충족)
  C_2.tick() → FAILURE    (조건 여전히 미충족)
  C_3.tick() → RUNNING    (기본 행동 계속 실행)
  
  ReactiveFallback → RUNNING

일반 Fallback이었다면 Tick 2에서 C_1, C_2를 건너뛰고 C_3부터 Tick하였을 것이다. 그러나 ReactiveFallback은 C_1부터 다시 평가한다. 조건이 변하지 않았으므로 결과는 동일하지만, 재평가가 수행되었다는 점이 핵심이다.

2.3 Tick 3: 상위 조건 변화 발생

Tick 3:
  C_1.tick() → SUCCESS    (조건 충족됨! 환경 변화 감지)
  
  [C_1이 SUCCESS → C_3는 RUNNING 상태이므로 Halt 전파]
  C_3.halt()               (기본 행동 즉시 중단)
  
  ReactiveFallback → SUCCESS

Tick 3에서 C_1의 조건이 성립하여 SUCCESS를 반환한다. ReactiveFallback은 즉시 SUCCESS를 반환하고, 이전에 RUNNING 상태였던 C_3에 Halt를 전파하여 실행을 중단시킨다. 이것이 매 Tick 재평가 원칙의 핵심 효과이다. C_1의 조건 변화가 발생한 바로 그 Tick에서 즉각적으로 반영된다.

3. 일반 Fallback에서의 동일 시나리오

비교를 위해 동일한 시나리오를 일반 Fallback 노드에서 살펴보라.

Tick 3 (일반 Fallback):
  [이전 Tick에서 C_3가 RUNNING이었으므로, C_3부터 재개]
  C_3.tick() → RUNNING    (기본 행동 계속 실행)
  
  Fallback → RUNNING

일반 Fallback에서는 C_1의 조건이 성립하였음에도 C_1이 재평가되지 않으므로, C_3가 계속 실행된다. C_1의 조건 변화는 C_3SUCCESS 또는 FAILURE를 반환하여 일반 Fallback이 초기 상태로 복귀한 후에야 반영된다. 이 지연은 로봇의 환경 변화에 대한 즉각적 반응을 방해한다.

4. 재평가에 의한 Halt 전파의 조건

매 Tick 재평가에 의해 Halt가 전파되는 조건을 형식적으로 정의하면 다음과 같다. Tick t에서 자식 C_iSUCCESS 또는 RUNNING을 반환하고, 인덱스 j > i인 자식 C_j가 Tick t-1에서 RUNNING 상태였다면, C_j에 Halt가 전파된다.

\text{Halt}(C_j) \iff \exists\, i < j : \text{status}(C_i, t) \in \{\text{SUCCESS}, \text{RUNNING}\} \land \text{status}(C_j, t-1) = \text{RUNNING}

이 조건은 “더 높은 우선순위의 자식이 비실패 상태를 반환하면, 더 낮은 우선순위에서 실행 중인 행동이 중단된다“는 의미론을 형식화한 것이다.

재평가의 비용과 이점

이점

  1. 즉각적 우선순위 반영: 상위 조건의 변화가 발생한 바로 그 Tick에서 행동 전환이 이루어진다. 최대 반응 지연은 한 Tick 주기이다.

  2. 환경 변화 대응: 동적으로 변화하는 환경에서 로봇이 항상 가장 적절한 행동을 선택하도록 보장한다.

  3. 안전 조건 즉시 반영: 안전 관련 조건을 최상위 자식에 배치하면, 안전 조건이 성립하는 즉시 현재 행동이 중단되고 안전 행동이 실행된다.

비용

  1. 연산 오버헤드: 매 Tick마다 이미 FAILURE를 반환한 자식도 재평가하므로, 상위 자식의 조건 평가 비용이 매 Tick마다 발생한다. 일반 Fallback에서는 이 비용이 발생하지 않는다.

  2. 불필요한 Halt 가능성: 상위 조건이 불안정하게 진동(oscillation)하면, 하위 행동의 반복적인 시작과 중단이 발생할 수 있다. 이는 로봇의 동작을 불안정하게 만들 수 있다.

  3. 행동 진행 방해: 장시간 소요되는 하위 행동이 빈번하게 중단되면, 해당 행동이 완료에 도달하지 못할 수 있다.

조건 노드의 경량 설계 원칙

재평가의 연산 비용을 최소화하기 위해, ReactiveFallback의 상위 자식에 배치되는 조건 노드는 경량으로 설계하여야 한다. 조건 노드는 매 Tick마다 재평가되므로, 해당 Tick의 연산 시간에 직접적인 영향을 미친다.

조건 노드가 수행하여야 하는 연산은 블랙보드 값의 읽기 및 단순 비교, 또는 캐시된 센서 데이터의 임계값 비교 수준으로 제한하는 것이 권장된다. 복잡한 센서 데이터 처리나 계획 연산을 조건 노드 내에서 수행하면 전체 행동 트리의 Tick 주기가 지연된다.

// 권장: 경량 조건 노드
function IsObstacleDetected.tick():
    distance ← blackboard.get("min_obstacle_distance")
    if distance < threshold:
        return SUCCESS
    else:
        return FAILURE

// 비권장: 중량 조건 노드
function DetectObstacleFromRawData.tick():
    pointcloud ← subscribeLidarData()
    obstacles ← runClusteringAlgorithm(pointcloud)  // 비용 높음
    if obstacles.count > 0:
        return SUCCESS
    else:
        return FAILURE

히스테리시스를 통한 진동 방지

상위 조건이 임계값 경계에서 빈번하게 참/거짓을 오가면, 하위 행동의 반복적 시작과 중단이 발생한다. 이를 방지하기 위해 히스테리시스(hysteresis)를 적용할 수 있다.

활성화 임계값 \theta_{on}과 비활성화 임계값 \theta_{off}\theta_{on} \neq \theta_{off}로 설정하여, 조건의 활성화와 비활성화에 서로 다른 임계값을 적용한다. 예를 들어, 장애물 거리 감시에서 \theta_{on} = 1.0\,\text{m} (활성화: 장애물 1.0m 이내 접근 시 회피 행동 개시)과 \theta_{off} = 1.5\,\text{m} (비활성화: 장애물 1.5m 이상 이격 시 회피 행동 종료)으로 설정하면, 0.5m의 히스테리시스 대역이 형성되어 경계 부근에서의 진동이 억제된다.

function IsObstacleNear.tick():
    distance ← blackboard.get("min_obstacle_distance")
    
    if was_active:
        if distance > threshold_off:
            was_active ← false
            return FAILURE
        else:
            return SUCCESS
    else:
        if distance < threshold_on:
            was_active ← true
            return SUCCESS
        else:
            return FAILURE

이 히스테리시스 기법은 ReactiveFallback의 매 Tick 재평가 환경에서 안정적인 행동 전환을 보장하는 핵심적인 설계 기법이다.