Robotiq의 ROS 2 그리퍼 패키지를 통합하기 전에는 세 가지를 확인해야 한다. 사용하려는 ROS 배포판이 요구하는 액션 메시지, 선택한 그리퍼가 실제 하드웨어에서 검증됐는지 여부, 설치 지침의 기준이 된 정확한 소스 리비전이다. Humble과 Jazzy는 같은 액션 엔드포인트에서 서로 다른 메시지 유형을 사용할 수 있으며, 2F-140의 설명 파일이 제공된다는 사실만으로 하드웨어 검증까지 이뤄졌다고 볼 수는 없다. 빌드가 성공했다는 사실도 이 두 질문에 답해 주지 않는다.
2026년 9월 16일 확인 당시 최신 공개 릴리스는 GitHub에 8월 14일 게시된 v1.1.0이었다. Robotiq은 뒤이은 8월 26일 발표에서 이 패키지를 커뮤니티 패키지의 공식 후속판으로 소개했으며, Robotiq이 직접 유지 관리한다고 밝혔다. 현재 main 브랜치에는 이미 해당 태그 릴리스보다 앞선 문서 내용이 들어 있다. 따라서 공개 릴리스의 사실과 개발 브랜치의 지침을 구분해야 한다. 이 글은 소스를 검토해 정리한 내용이며, 패키지를 직접 빌드하거나 하드웨어를 연결해 시험하지는 않았다.
ROS 배포판과 액션 계약부터 맞춘다
현재 지원 표에는 Humble, Jazzy, Lyrical이 지원 대상으로 적혀 있다. 패키지·런치·컨트롤러 이름은 이들 배포판에서 동일하며 /robotiq_gripper_controller/gripper_cmd 액션 엔드포인트도 그대로다. 다만 그 엔드포인트가 사용하는 메시지 계약은 Humble 이후 달라진다.
| ROS 2 배포판 | 컨트롤러 계열 | 액션 메시지 | 저장소 상태 |
|---|---|---|---|
| Humble | position_controllers/GripperActionController |
control_msgs/action/GripperCommand |
지원됨. 병합을 통과하려면 CI 성공 필요 |
| Jazzy | parallel_gripper_action_controller/GripperActionController |
control_msgs/action/ParallelGripperCommand |
지원됨. 병합을 통과하려면 CI 성공 필요 |
| Lyrical | parallel_gripper_action_controller/GripperActionController |
control_msgs/action/ParallelGripperCommand |
지원됨. 병합을 통과하려면 CI 성공 필요 |
| Rolling | 계속 바뀌는 개발 대상 | 지원이 약속된 계약 없음 | 비차단 CI로 관찰하지만 지원 대상은 아님 |
| Kilted와 그 밖의 비 LTS 릴리스 | — | — | 이 저장소에서 빌드하지 않음 |
마이그레이션할 때 이 차이를 놓치기 쉽다. 액션 이름이 그대로여도 Humble의 GripperCommand를 전제로 만든 클라이언트는 Jazzy나 Lyrical의 ParallelGripperCommand와 맞지 않는다. 액션 유형도 인터페이스 계약의 일부로 다뤄야 한다. 엔드포인트가 보이는지만 시험하지 말고, 선택한 배포판을 기준으로 생성된 메시지와 클라이언트 코드, 통합 테스트를 함께 확인한다.
지원 대상과 CI 관찰 대상의 차이도 분명히 해야 한다. CI 정책은 Rolling에서 앞으로 생길 수 있는 비호환성을 드러내되, 그 작업이 릴리스를 막지는 않도록 설정돼 있다. CI 작업이 성공했다고 해서 지원을 약속한 것은 아니다. Kilted 역시 이름이 명시된 두 배포판 사이에 시간상 놓여 있다는 이유만으로 이 지원 표의 대체 대상이 되지는 않는다.
설명 파일, 드라이버, 하드웨어 검증을 나눠 본다
저장소의 그리퍼 스택에는 2F-85와 2F-140 설명 파일이 들어 있다. 고정된 커밋의 하드웨어 항목에 따르면 현재까지 하드웨어 검증 범위는 2F-85다. 2F-140 설명 파일도 배포되지만 하드웨어에서 검증됐다는 내용은 없다. 따라서 어떤 모델을 xacro나 RViz, 실행 인수에서 선택할 수 있다는 사실만으로 그 물리 장치의 통합까지 시험됐다고 판단할 수 없다.
통합 검토에서는 다음 세 가지 주장을 따로 기록한다.
- 선택한 그리퍼의 설명 파일이 존재한다.
- 드라이버가 애플리케이션에 필요한 인터페이스를 제공한다.
- 정확히 어떤 하드웨어와 배포판의 조합이 검증됐다.
이 저장소에는 TSF-85 촉각 센서용 robotiq_tsf도 들어 있다. 이는 별도의 센서 스택이며, 2F 그리퍼를 배포하면 촉각 피드백도 자동으로 제공된다는 근거가 아니다. 실제 시스템에서 해당 센서와 그 의존성을 사용할 때만 통합 범위에 포함한다.
하드웨어 선택 단계라면 로봇 그리퍼 종류 가이드에서 메커니즘과 가반하중, 센싱 요구사항을 비교할 수 있다. 장치를 정한 뒤에는 이 패키지별 점검 항목으로 더 좁은 소프트웨어 호환성 문제를 확인한다.
릴리스와 브랜치, 소스 의존성을 함께 고정한다
확인한 main 커밋에서 저장소 루트의 VERSION 파일은 여전히 1.1.0이다. 반면 같은 README의 시뮬레이터 안내는 한 인수의 이름 변경이 1.2.0에서 일어난 것으로 설명한다. 확인 시점에는 v1.2.0 태그가 없었다. 따라서 main은 개발 중인 스냅샷이며, 버전 1.2.0이 공개됐거나 현재 지침이 모두 v1.1.0 릴리스에 포함됐다는 근거가 아니다.
공개된 태그와 기록해 둔 커밋 가운데 하나를 선택하고, 그 리비전에 맞는 문서를 빌드 기록과 함께 보관한다. 소스 의존성에서는 이 구분이 특히 중요하다. 두 경로 모두 그리퍼 SDK 서브모듈이 필요하므로 서브모듈을 포함해 소스를 체크아웃해야 한다. 그러나 태그 v1.1.0의 지침은 libserialport를 수동으로 처리하도록 안내하는 반면, 확인한 main의 지침은 일반적인 rosdep 절차로 의존성을 해결한다고 설명한다. 두 지침을 섞으면 같은 환경을 다시 만들기 어려워질 수 있다.
검토한 공식 자료에는 소스 설치 방법이 나와 있다. 바이너리 패키지의 제공 여부는 확인하지 않았다. 통합 기록에는 커밋 또는 태그, ROS 배포판, Ubuntu 기반 버전, 의존성 해결 방식, SDK 서브모듈 리비전을 남긴다. 저장소의 BSD-3-Clause 라이선스는 호환성과 별개의 문제다. 결합한 빌드를 배포하기 전에는 각 의존성의 라이선스도 따로 확인해야 한다.
위치와 effort 값을 물리량으로 오해하지 않는다
현재 명령 문서는 position을 너클 관절 각도로 정의하며 단위는 라디안이다. 죠 개구 폭을 밀리미터로 나타낸 값이 아니다. 툴의 개구 폭을 기준으로 동작하는 플래너라면 선택한 지오메트리에 맞는 변환을 따로 정의하고 검증해야 한다.
Jazzy와 Lyrical에서 선택적으로 쓰는 effort 명령은 gripper_max_force를 통해 그리퍼의 rFR 설정에 매핑되는 파지 임계값이다. 문서에 따르면 이는 최대 모터 전류 임계값을 설정하며, 손가락에 가해지는 힘을 직접 지시하거나 측정하지 않는다. 닫힘 속도도 실제 힘에 영향을 주며, 그리퍼에서는 힘 값이 피드백되지 않는다. 이 인터페이스에서는 motor_current를 힘으로 변환할 수도 없다. 따라서 명령 값이나 모터 전류 판독값을 측정된 파지력으로 제시해서는 안 된다.
하드웨어를 연결하기 전에는 구동을 일으키지 않는 검토 절차로 다음 항목을 확인한다.
- 릴리스 태그 또는 커밋과 그에 맞는 README를 고정한다.
- ROS 배포판에 맞는 액션 메시지 유형을 선택한다.
- 클라이언트가 기대하는 엔드포인트와 관절 이름을 확인한다.
- SDK 서브모듈을 포함하고 그 리비전을 기록한다.
- 모델 설명의 지원 범위와 실제 하드웨어 시험 범위를 구분한다.
- 위치는 라디안, effort는 설정된 임계값으로 다루고, 개구 폭·속도·파지력은 별도의 하드웨어 검증 계획을 세운다.
ROS 2 control 하드웨어 인터페이스 가이드에서는 컨트롤러 관리자와 하드웨어 플러그인의 더 넓은 구조를 설명한다. 이 구조 안에서 Robotiq 드라이버의 위치를 파악한 뒤, 위 표를 기준으로 정확한 패키지·배포판·그리퍼 조합이 통합 테스트를 시작할 준비가 됐는지 판단한다.