1261.64 행동 제어 인터페이스의 표준화

1. 인터페이스 표준화의 의의

행동 제어 인터페이스의 표준화(standardization)는 행동 컴포넌트 간의 상호 운용성(interoperability)을 확보하기 위해 통신 규약, 데이터 형식, 호출 규습을 통일하는 과정이다. 표준화된 인터페이스는 다음과 같은 공학적 가치를 제공한다.

1. 상호 운용성: 서로 다른 개발 주체가 제작한 행동 컴포넌트가 동일한 시스템 내에서 원활하게 협동할 수 있다.
2. 교체 가능성: 동일한 인터페이스를 준수하는 대체 컴포넌트로의 교체가 투명하게 이루어진다.
3. 생태계 형성: 표준 인터페이스를 기반으로 행동 컴포넌트의 공유, 배포, 재사용이 촉진되어 커뮤니티 수준의 생태계가 형성된다.
4. 검증 용이성: 표준화된 인터페이스를 기준으로 컴포넌트의 적합성(conformance)을 체계적으로 검증할 수 있다.

2. ROS2 표준 인터페이스 체계

2.1 메시지 인터페이스의 계층 구조

ROS2의 인터페이스 시스템은 세 가지 유형의 인터페이스 정의를 제공한다.

• 메시지(.msg): 단방향 데이터 전달을 위한 데이터 구조 정의이다. 토픽 통신에 사용된다.
• 서비스(.srv): 요청-응답 쌍의 데이터 구조 정의이다. 서비스 통신에 사용된다.
• 액션(.action): 목표, 결과, 피드백 세 가지 데이터 구조의 정의이다. 장시간 행동 실행에 사용된다.

이 세 가지 인터페이스 유형은 행동 제어의 다양한 통신 요구사항을 포괄적으로 지원한다.

2.2 공통 인터페이스 패키지

ROS2 생태계에서는 다음의 공통 인터페이스 패키지가 표준으로 제공된다.

행동 제어 컴포넌트의 설계 시에는 이러한 표준 메시지 타입을 최대한 활용하여 호환성을 확보하여야 한다.

3. 행동 제어에 특화된 표준 인터페이스

3.1 Nav2 행동 인터페이스

Nav2(Navigation2) 프레임워크는 자율 이동 로봇의 행동 제어를 위한 표준화된 액션 인터페이스를 정의한다. 대표적인 인터페이스는 다음과 같다.

• NavigateToPose.action: 지정된 목표 자세(pose)로의 자율 이동을 요청한다.
• NavigateThroughPoses.action: 복수의 경유 자세를 순차적으로 통과하는 이동을 요청한다.
• FollowPath.action: 사전 계획된 경로를 추종하는 행동을 요청한다.
• Spin.action: 지정된 각도만큼 제자리 회전을 수행한다.
• BackUp.action: 지정된 거리만큼 후진한다.
• Wait.action: 지정된 시간 동안 대기한다.

이 인터페이스들은 행동의 목표, 피드백, 결과의 구조가 명확히 정의되어 있으므로, 다양한 로봇 플랫폼에서 동일한 인터페이스로 내비게이션 행동을 제어할 수 있다.

3.2 MoveIt2 행동 인터페이스

MoveIt2 프레임워크는 매니퓰레이터 제어를 위한 표준 인터페이스를 제공한다.

• MoveGroup.action: 로봇 팔의 운동 계획 및 실행을 통합적으로 수행한다.
• FollowJointTrajectory.action: 관절 공간에서의 궤적 추종을 실행한다.
• GripperCommand.action: 그리퍼의 개폐 명령을 전달한다.

이 인터페이스들은 control_msgs 패키지에 정의된 표준 메시지 타입을 기반으로 하므로, 다양한 로봇 하드웨어와의 호환성이 보장된다.

4. 인터페이스 정의 언어와 표준화 메커니즘

4.1 IDL(Interface Definition Language)

ROS2는 OMG(Object Management Group)의 IDL(Interface Definition Language)을 인터페이스 정의의 기반으로 채택하고 있다. IDL은 프로그래밍 언어에 독립적인 데이터 구조 정의를 지원하며, C++, Python, Java 등 다양한 언어로의 자동 코드 생성을 가능하게 한다.

IDL 기반 인터페이스 정의의 장점은 다음과 같다.

• 언어 독립성: 인터페이스 정의와 구현 언어가 분리되어, 다중 언어 환경에서의 상호 운용이 가능하다.
• 자동 코드 생성: rosidl 도구 체인이 IDL 정의로부터 직렬화/역직렬화 코드, 타입 지원 코드 등을 자동 생성한다.
• 버전 관리: 인터페이스 정의의 변경 이력을 추적하고, 하위 호환성(backward compatibility)을 관리할 수 있다.

4.2 인터페이스 버전 관리

행동 제어 인터페이스의 변경은 기존 컴포넌트와의 호환성에 영향을 미치므로, 체계적인 버전 관리가 필수적이다. 인터페이스 버전 관리의 주요 원칙은 다음과 같다.

1. 하위 호환적 확장: 새로운 필드의 추가는 허용하되, 기본값을 지정하여 기존 클라이언트가 영향을 받지 않도록 한다.
2. 비호환 변경의 명시: 필드 삭제, 타입 변경 등의 비호환 변경은 새로운 메시지 타입으로 분리하고, 기존 타입은 폐기(deprecation) 고지 후 유지한다.
3. 시맨틱 버전 관리(Semantic Versioning): 패키지 수준에서 주요(major), 부(minor), 수정(patch) 버전 번호를 부여하여 변경의 성격을 명시한다.

5. 사용자 정의 인터페이스 설계 지침

표준 인터페이스가 특정 응용의 요구사항을 충족하지 못하는 경우, 사용자 정의(custom) 인터페이스를 설계할 수 있다. 이 경우 다음의 설계 지침을 준수한다.

5.1 최소 충분 원칙

인터페이스에는 행동의 실행에 필수적인 데이터만을 포함한다. 불필요한 필드의 포함은 인터페이스의 복잡도를 증가시키고, 통신 대역폭을 낭비하며, 하위 호환적 변경의 여지를 축소한다.

5.2 자기 기술적(Self-Descriptive) 설계

인터페이스의 필드 이름과 타입은 그 의미를 명확히 전달하여야 한다. 약어의 남용을 회피하고, 물리적 단위가 있는 경우 필드 이름에 명시한다(예: velocity_m_per_s, angle_rad). ROS2 커뮤니티에서는 SI 단위계의 사용을 표준으로 권장한다(REP-103).

5.3 표준 메시지 타입의 재활용

사용자 정의 메시지 내부에서도 geometry_msgs/Pose, std_msgs/Header 등의 표준 메시지 타입을 재활용하여 기존 도구 및 시각화 시스템과의 호환성을 유지한다.

5.4 헤더(Header) 필드의 포함

시간 정보가 필요한 메시지에는 std_msgs/Header 필드를 포함하여 타임스탬프와 좌표 프레임 정보를 전달한다. 이는 데이터의 시간 동기화와 좌표 변환에 필수적이다.

6. 인터페이스 적합성 검증

6.1 정적 검증

인터페이스 정의의 정적 검증은 IDL 컴파일러(rosidl_generator)를 통해 수행된다. 메시지 타입의 구문적 정확성, 필드 타입의 유효성, 중첩 참조의 해결 가능성 등이 빌드 시점에 검증된다.

6.2 통합 테스트

인터페이스의 기능적 적합성은 통합 테스트를 통해 검증한다. 모의(mock) 서버와 클라이언트를 구성하여, 정의된 인터페이스를 통한 데이터 교환이 기대 사항을 만족하는지 확인한다. ROS2의 launch_testing 프레임워크는 노드 간 통신의 통합 테스트를 지원한다.

6.3 호환성 테스트

인터페이스 변경 시에는 이전 버전의 클라이언트가 새 버전의 서버와 정상적으로 통신할 수 있는지를 검증하는 호환성 테스트를 수행한다. DDS의 타입 호환성 규칙에 따라, 필드 추가는 호환 가능하나 필드 삭제나 타입 변경은 비호환적이다.

7. 참고 문헌

• Object Management Group (2018). Interface Definition Language (IDL) Specification, Version 4.2. OMG Document formal/2018-01-05.
• ROS Enhancement Proposal 103 (REP-103). Standard Units of Measure and Coordinate Conventions. https://www.ros.org/reps/rep-0103.html