1317.48 PlanSys2의 버전 호환성과 ROS2 배포판 지원

1317.48 PlanSys2의 버전 호환성과 ROS2 배포판 지원

1. 개요

PlanSys2(Planning System 2)는 ROS2(Robot Operating System 2) 생태계 위에 구축된 PDDL 기반 태스크 플래닝 프레임워크이다. ROS2는 주기적으로 공식 배포판(distribution)을 발표하며, 각 배포판은 고유한 API, 의존성 라이브러리, 그리고 미들웨어 구성을 갖는다. PlanSys2가 이러한 다양한 ROS2 배포판과 올바르게 호환되려면, 빌드 시스템, 의존성 체계, API 인터페이스 전반에 걸친 체계적인 버전 관리 전략이 필수적이다. 본 절에서는 PlanSys2의 버전 호환성 정책, ROS2 배포판별 지원 현황, 그리고 버전 전환 시 고려해야 할 기술적 사항을 다룬다.

2. ROS2 배포판의 생명주기와 지원 정책

2.1 ROS2 배포판 릴리스 모델

ROS2 프로젝트는 Open Robotics(현 Open Source Robotics Foundation)에 의해 관리되며, 매년 5월경 새로운 배포판을 공개한다. 각 배포판은 알파벳 순서에 따른 코드명을 부여받으며, 지원 기간에 따라 두 가지 유형으로 분류된다.

  • 일반 지원 배포판(Non-LTS): 약 1년간의 지원 기간을 갖는다. Foxy 이전의 Dashing, Eloquent 등이 이에 해당한다.
  • 장기 지원 배포판(LTS, Long-Term Support): 약 3~5년간의 공식 지원이 보장된다. Foxy Fitzpatrick(2020), Humble Hawksbill(2022), Jazzy Jalisco(2024) 등이 LTS 배포판에 해당한다.

각 배포판은 Ubuntu의 특정 LTS 버전과 밀접하게 연동되며, Target Platform이라 부르는 공식 지원 운영체제 조합이 명시된다. 예컨대 Humble은 Ubuntu 22.04(Jammy Jellyfish)를, Jazzy는 Ubuntu 24.04(Noble Numbat)를 주 지원 대상으로 한다.

2.2 EOL 정책과 보안 패치

ROS2 배포판이 EOL(End of Life)에 도달하면, 공식적인 버그 수정 및 보안 패치가 중단된다. PlanSys2 역시 EOL에 도달한 배포판에 대한 지원을 공식적으로 종료하며, 해당 배포판용 브랜치는 유지보수 모드(maintenance mode)로 전환되거나 아카이브 처리된다.

3. PlanSys2의 버전 관리 체계

3.1 시맨틱 버전 관리

PlanSys2는 시맨틱 버전 관리(Semantic Versioning, SemVer) 규칙을 따른다. 버전 번호는 MAJOR.MINOR.PATCH 형태로 구성되며, 각 구성 요소의 의미는 다음과 같다.

구성 요소의미변경 시 영향
MAJOR하위 호환성을 깨뜨리는 API 변경기존 사용자 코드의 수정이 필요함
MINOR하위 호환성을 유지하는 기능 추가기존 코드는 변경 없이 동작함
PATCH하위 호환성을 유지하는 버그 수정기존 코드에 영향 없음

PlanSys2의 주요 버전 변경은 대체로 ROS2 배포판의 전환과 맞물려 이루어진다. 새로운 ROS2 배포판이 출시되면, PlanSys2 개발팀은 해당 배포판에 맞춘 새로운 브랜치 또는 릴리스를 제공한다.

3.2 브랜치 전략

PlanSys2의 소스 저장소(GitHub: ros2/ros2_planning_system)는 ROS2 배포판별로 독립적인 브랜치를 유지한다. 이러한 브랜치 전략은 ROS2 생태계의 표준 관례를 따르며, 각 브랜치명은 해당 배포판의 코드명과 일치한다.

main (또는 rolling)  ← 최신 개발 브랜치
humble               ← ROS2 Humble 배포판 대응
galactic             ← ROS2 Galactic 배포판 대응 (EOL)
foxy                 ← ROS2 Foxy 배포판 대응 (EOL)

main 또는 rolling 브랜치는 ROS2 Rolling Ridley(롤링 배포판)에 대응하며, 최신 API 변경 사항이 가장 먼저 반영된다. 안정적인 배포판 브랜치는 main으로부터 주기적으로 백포트(backport)를 수신하되, 하위 호환성을 깨뜨리는 변경은 배제한다.

4. ROS2 배포판별 PlanSys2 지원 현황

4.1 Foxy Fitzpatrick (2020.06 ~ 2023.05)

PlanSys2가 본격적으로 성숙한 첫 번째 안정 배포판이다. Foxy는 ROS2 최초의 LTS 배포판으로서, PlanSys2의 초기 아키텍처가 이 배포판 위에서 검증되었다. 주요 특성은 다음과 같다.

  • DDS 미들웨어: Fast DDS(구 Fast RTPS)를 기본 RMW(ROS Middleware) 구현체로 사용하였다.
  • 라이프사이클 노드: rclcpp_lifecycle 기반의 관리형 노드(managed node)가 PlanSys2의 4대 핵심 노드에 적용되었다.
  • PDDL 파서: 초기 버전의 PDDL 파서가 통합되었으며, PDDL 2.1의 기본 기능을 지원하였다.

Foxy는 2023년 5월에 EOL에 도달하였으므로, 현재는 공식 지원 대상이 아니다.

4.2 Galactic Geochelone (2021.05 ~ 2022.11)

Galactic은 비-LTS 배포판으로서, 약 18개월간의 비교적 짧은 지원 기간을 가졌다. PlanSys2는 Galactic에서 다음과 같은 개선을 수행하였다.

  • 액션 인터페이스 개선: ROS2 액션 서버/클라이언트의 API 변경에 맞추어 PlanSys2의 액션 실행 메커니즘이 갱신되었다.
  • 행동 트리 통합 강화: BehaviorTree.CPP 라이브러리의 버전 업데이트에 따른 호환성 조정이 이루어졌다.

Galactic은 2022년 11월에 EOL에 도달하였다.

4.3 Humble Hawksbill (2022.05 ~ 2027.05)

Humble은 두 번째 LTS 배포판으로서, PlanSys2의 현재 주력 지원 대상 가운데 하나이다. Humble에서의 주요 변경 사항은 다음과 같다.

  • RMW 기본 구현체 변경: Cyclone DDS가 기본 RMW 구현체로 채택되었다. 이에 따라 PlanSys2의 QoS(서비스 품질) 설정 및 미들웨어 관련 파라미터가 조정되었다.
  • rclcpp API 변경: 노드 생성자, 콜백 그룹(callback group), 실행기(executor) 관련 API가 변경되었으며, PlanSys2의 내부 코드가 이에 맞추어 수정되었다.
  • 빌드 시스템 갱신: ament_cmake 및 colcon 빌드 도구의 업데이트에 따른 CMakeLists.txt 및 package.xml의 수정이 이루어졌다.
  • 테스트 프레임워크 호환성: launch_testing 및 ament_lint 도구의 버전 변경에 대응하여 통합 테스트 코드가 갱신되었다.

4.4 Jazzy Jalisco (2024.05 ~ 2029.05)

Jazzy는 세 번째 LTS 배포판이며, PlanSys2의 최신 개발이 활발히 이루어지는 대상이다. Jazzy에서 도입된 주요 변경 사항과 PlanSys2에 미치는 영향은 다음과 같다.

  • Type Adaptation 및 Type Negotiation: ROS2 메시지 전달 과정에서의 타입 적응(type adaptation) 기능이 강화되었으며, PlanSys2의 커스텀 메시지 타입 처리에 영향을 미칠 수 있다.
  • ros2_control 통합 개선: 하드웨어 추상화 계층의 변경이 PlanSys2와 외부 액추에이터 제어 시스템 간의 연동에 잠재적 영향을 준다.
  • Iron Irwini 이후의 API 안정화: Iron(2023)에서 도입된 실험적 기능 가운데 일부가 Jazzy에서 안정화되었으며, PlanSys2는 이러한 안정화된 API를 활용하도록 전환되었다.

4.5 Rolling Ridley

Rolling은 ROS2의 지속적 릴리스(rolling release) 배포판으로서, 최신 개발 코드가 실시간으로 반영된다. PlanSys2의 main 브랜치는 Rolling에 대응하며, 차기 안정 배포판에 포함될 기능이 먼저 통합된다. Rolling은 안정성이 보장되지 않으므로, 프로덕션 환경에서의 사용은 권장되지 않는다.

5. 버전 전환 시 기술적 고려사항

5.1 API 호환성 단절 대응

ROS2 배포판 간 API 변경은 PlanSys2의 소스 코드에 직접적인 영향을 미친다. 주요 API 호환성 단절 유형과 대응 방법은 다음과 같다.

노드 인터페이스 변경: rclcpp::Node의 생성자 시그니처, 파라미터 선언 방식, 콜백 등록 메커니즘 등이 배포판 간에 변경될 수 있다. PlanSys2는 조건부 컴파일(#ifdef)이나 추상화 계층을 통해 다중 배포판 호환성을 유지하거나, 배포판별 전용 브랜치를 운영하여 이 문제를 해결한다.

메시지 및 서비스 정의 변경: plansys2_msgs 패키지에 정의된 커스텀 메시지와 서비스는 ROS2의 IDL(Interface Definition Language) 컴파일러 버전에 의존한다. IDL 컴파일러의 변경은 생성되는 코드의 구조에 영향을 줄 수 있으므로, 배포판 전환 시 메시지 패키지의 재빌드가 필수적이다.

DDS 미들웨어 차이: ROS2의 기본 DDS 구현체가 배포판 간에 변경될 경우(Foxy의 Fast DDS → Humble의 Cyclone DDS), QoS 프로파일의 동작 특성이 미묘하게 달라질 수 있다. PlanSys2의 노드 간 통신에 사용되는 QoS 설정이 변경된 미들웨어에서 올바르게 작동하는지 검증해야 한다.

5.2 의존성 라이브러리 버전 충돌

PlanSys2는 다수의 외부 라이브러리에 의존하며, ROS2 배포판마다 이들 라이브러리의 지원 버전이 상이하다.

의존성FoxyHumbleJazzy
BehaviorTree.CPP3.x3.x / 4.x4.x
POPF Planner자체 포함자체 포함자체 포함
Boost1.711.741.83
CMake 최소 요구3.163.163.22

특히 BehaviorTree.CPP 라이브러리의 메이저 버전 변경(3.x → 4.x)은 PlanSys2의 액션 실행 아키텍처에 상당한 영향을 미쳤다. BehaviorTree.CPP 4.x에서는 트리 노드의 등록 방식, 블랙보드(blackboard) 인터페이스, 그리고 XML 스키마가 변경되었으므로, PlanSys2의 행동 트리 관련 코드도 이에 맞추어 전면 수정이 필요하였다.

5.3 마이그레이션 절차

기존 PlanSys2 프로젝트를 새로운 ROS2 배포판으로 마이그레이션하는 절차는 다음과 같이 체계화할 수 있다.

  1. 대상 배포판 환경 구성: 새 배포판에 맞는 Ubuntu 버전을 설치하고, ros-<배포판>-desktop 메타 패키지를 통해 기본 ROS2 환경을 구성한다.
  2. PlanSys2 소스 체크아웃: 해당 배포판에 대응하는 PlanSys2 브랜치를 체크아웃한다. 
    git clone https://github.com/PlanSys2/ros2_planning_system.git -b <배포판명>

3. **의존성 해결**: `rosdep`를 활용하여 시스템 수준의 의존성을 자동 설치한다.
   ```bash
   rosdep install --from-paths src --ignore-src -r -y
  1. 빌드 및 테스트: colcon build를 통해 전체 워크스페이스를 빌드하고, colcon test로 통합 테스트를 수행한다.
  2. 사용자 코드 수정: 사용자가 작성한 액션 수행기(action performer), PDDL 도메인 파일, 런치 파일 등에서 변경된 API에 대응하는 수정을 적용한다.
  3. 통합 검증: 시뮬레이션 환경(Gazebo 등)에서 전체 임무 계획 파이프라인의 정상 동작을 검증한다.

6. 크로스 배포판 호환성 유지 전략

6.1 CI/CD 파이프라인을 통한 다중 배포판 검증

PlanSys2 프로젝트는 GitHub Actions 등의 CI(Continuous Integration) 파이프라인을 활용하여, 지원 대상인 모든 ROS2 배포판에 대한 빌드 및 테스트를 자동화한다. 각 배포판에 대응하는 Docker 이미지(예: ros:humble, ros:jazzy)를 기반으로 병렬 빌드를 수행함으로써, 코드 변경이 특정 배포판에서 회귀(regression)를 유발하는지를 조기에 탐지한다.

6.2 조건부 빌드 및 기능 게이팅

배포판 간 API 차이가 존재하는 경우, ament_cmake의 조건부 빌드 기능이나 C++ 전처리기 매크로를 활용하여 배포판별 코드 경로를 분기할 수 있다. 다만, 이러한 접근법은 코드 복잡도를 증가시키므로, PlanSys2는 원칙적으로 배포판별 독립 브랜치 전략을 선호한다.

6.3 rosdistro를 통한 패키지 등록

PlanSys2의 바이너리 패키지는 rosdistro 저장소를 통해 각 배포판의 공식 패키지 인덱스에 등록된다. 이를 통해 사용자는 apt install ros-<배포판>-plansys2-* 명령으로 사전 빌드된 바이너리 패키지를 간편하게 설치할 수 있다. rosdistro 등록 절차에서는 bloom이라는 릴리스 자동화 도구가 사용되며, 이를 통해 소스 배포(source distribution)에서 DEB 패키지를 자동 생성한다.

7. 호환성 문제 진단 및 해결

7.1 일반적인 빌드 오류 유형

배포판 전환 시 빈번하게 발생하는 빌드 오류와 그 원인은 다음과 같다.

  • rclcpp 심볼 미발견(undefined symbol): 노드 API의 시그니처 변경으로 인해 발생한다. 해당 배포판의 rclcpp API 문서를 참조하여 함수 시그니처를 갱신해야 한다.
  • ament_cmake 매크로 미인식: ament_cmake의 버전 변경으로 인해 특정 CMake 매크로가 제거되거나 이름이 변경된 경우에 발생한다. ament_cmake의 변경 로그(changelog)를 참조하여 대응해야 한다.
  • BehaviorTree.CPP 헤더 경로 변경: 메이저 버전 업그레이드 시 헤더 파일의 디렉토리 구조가 변경될 수 있다. #include 경로를 새 버전에 맞추어 수정해야 한다.

7.2 런타임 호환성 문제

빌드에 성공하더라도, 런타임에서 다음과 같은 문제가 발생할 수 있다.

  • QoS 불일치: 노드 간 통신에서 QoS 프로파일이 일치하지 않으면 메시지 송수신이 실패한다. 특히 DDS 구현체가 변경된 경우, 특정 QoS 조합의 호환성(compatible) 여부가 달라질 수 있다.
  • 라이프사이클 상태 전이 실패: rclcpp_lifecycle의 상태 전이 로직이 변경된 경우, PlanSys2의 관리형 노드가 정상적으로 활성화(activate)되지 않을 수 있다.
  • 파라미터 기본값 변경: 배포판 간에 ROS2 코어 파라미터의 기본값이 변경될 수 있으며, 이는 PlanSys2의 동작에 미묘한 차이를 유발할 수 있다.

8. 요약

PlanSys2의 버전 호환성 관리는 ROS2 배포판의 생명주기와 밀접하게 연동된다. 시맨틱 버전 관리, 배포판별 독립 브랜치 전략, CI/CD 기반 다중 배포판 검증, 그리고 rosdistro를 통한 패키지 배포가 PlanSys2의 핵심 버전 관리 전략을 구성한다. 사용자는 프로덕션 환경에서 LTS 배포판(Humble 또는 Jazzy)을 선택하고, 마이그레이션 시 API 변경 사항, 의존성 버전 충돌, 미들웨어 차이 등을 체계적으로 점검해야 한다.