로봇 운영체제(Robot Operating System, ROS)는 2007년 처음 등장한 이래 로봇 애플리케이션 개발을 위한 표준적인 소프트웨어 라이브러리 및 도구 모음으로 자리 잡았다.1 그러나 ROS1은 단일 마스터에 의존하는 통신 구조, 실시간성(real-time) 보장의 어려움, 상용 수준의 안정성 및 보안 기능 미비 등 현대 로봇 시스템이 요구하는 여러 가지 한계를 내포하고 있었다. 이러한 근본적인 문제들을 해결하고, 다중 로봇 시스템, 실시간 제어, 임베디드 시스템, 상용 제품 개발 등 변화하는 로봇 기술의 요구사항에 부응하기 위해 ROS2 프로젝트가 시작되었다.1
ROS2는 데이터 분산 서비스(Data Distribution Service, DDS)를 통신 미들웨어로 채택하여 탈중앙화된 노드 발견 및 통신을 가능하게 하고, 실시간 제어에 유리한 아키텍처를 도입했으며, 컴포넌트 기반의 모듈식 개발과 수명 주기(Lifecycle) 관리 기능을 통해 시스템의 강건성(robustness)을 크게 향상시켰다. 이러한 변화 속에서 ROS2 Humble Hawksbill은 중요한 이정표로 평가된다. Humble은 2022년 5월에 릴리스된 장기 지원(Long-Term Support, LTS) 버전으로, 5년간의 지원이 보장되어 안정적인 개발 및 배포 환경을 제공한다.2 특히 Ubuntu 22.04 (Jammy Jellyfish)를 공식 지원함으로써 개발자들은 최신 운영체제 환경에서 안정적으로 로봇 애플리케이션을 구축할 수 있게 되었다.2 MoveIt2와 같은 복잡한 프레임워크가 Humble을 주요 타겟 배포판으로 삼는다는 것은, ROS2 생태계가 실험 단계를 지나 안정화 및 성숙기에 접어들었음을 시사한다.4
MoveIt2는 ROS2를 위한 로봇 매니퓰레이션 플랫폼으로서, 모션 플래닝, 조작(manipulation), 3D 인식, 기구학, 제어, 내비게이션 등 로봇 팔을 다루는 데 필요한 최신 기술들을 통합하여 제공하는 것을 목표로 한다.5 이는 단순히 개별 알고리즘 라이브러리의 집합이 아니다. MoveIt2의 핵심은 move_group이라는 통합 노드에 있다. 이 노드는 다양한 플래너, 역기구학(Inverse Kinematics, IK) 솔버, 충돌 검사기, 센서 데이터 처리기 등의 개별 구성 요소들을 유기적으로 결합하여, 사용자에게 일관된 ROS 액션(Action) 및 서비스(Service) 형태의 인터페이스를 제공하는 프레임워크 역할을 수행한다.7
사용자는 C++ (move_group_interface), Python (moveit_py), 또는 그래픽 사용자 인터페이스(RViz Motion Planning Plugin)를 통해 move_group 노드와 상호작용하며 복잡한 매니퓰레이션 작업을 비교적 간단하게 구현할 수 있다.7 이처럼 MoveIt2는 로봇 매니퓰레이션 분야의 복잡성을 추상화하고 표준화된 개발 환경을 제공함으로써, 연구자와 개발자가 저수준의 알고리즘 구현보다는 고수준의 애플리케이션 로직 개발에 집중할 수 있도록 돕는다.
ROS2 Humble을 기점으로 한 MoveIt2 릴리스는 단순한 기능 이식(porting) 단계를 넘어, ROS2의 아키텍처적 장점을 적극적으로 활용하는 새로운 기능들이 대거 도입된 중요한 전환점으로 볼 수 있다. 초기 ROS2 버전의 MoveIt2가 ROS1과의 기능적 동등성(feature parity) 확보에 주력했다면, Humble 릴리스는 MoveIt2만의 독자적인 정체성과 발전 방향을 명확히 보여주기 시작했다.
이 시기에 도입된 핵심적인 개선 사항들은 MoveIt2가 ‘성숙기’에 접어들었음을 증명한다. 개발의 초점이 안정화와 기능 확장에서 새로운 패러다임 도입으로 이동하고 있음을 보여주는 것이다. 예를 들어, 동적 환경에 대한 반응성을 극대화하는 하이브리드 플래닝(Hybrid Planning) 아키텍처의 도입, 더 부드럽고 예측 가능한 궤적 생성을 위한 TOTG(Time-Optimal Trajectory Generation) 및 Ruckig 알고리즘의 기본 채택, 그리고 ROS2 환경에 맞춰 완전히 재설계된 MoveIt 설정 어시스턴트(Setup Assistant)는 MoveIt2의 기술적 깊이를 더했다.4 또한, C++ 핵심 기능에 직접 바인딩되는 공식 Python API
moveit_py의 등장은 AI/ML 연구 커뮤니티와의 접점을 넓히고 신속한 프로토타이핑을 가능하게 하는 전략적 움직임으로 평가된다.11 이러한 변화들은 MoveIt2가 더 이상 ROS1의 연장선이 아닌, ROS2 시대에 최적화된 독립적인 차세대 매니퓰레이션 프레임워크로 진화하고 있음을 명백히 보여준다.
| 기능 (Feature) | 핵심 내용 (Core Description) | 관련 소스 |
|---|---|---|
| 하이브리드 플래닝 (Hybrid Planning) | 전역 플래너(Global Planner)와 지역 플래너(Local Planner)를 결합하여 동적 환경에서의 반응형 재계획(reactive replanning)을 가능하게 하는 새로운 아키텍처. | 9 |
| Ruckig / TOTG | 기본 시간 매개변수화(time parameterization) 방법으로 채택되어, 더 부드럽고 저크(jerk)가 적은 궤적을 생성하며, 0이 아닌 초기/최종 속도 및 가속도 조건을 지원한다. | 4 |
| MoveIt 설정 어시스턴트 (ROS2 버전) | ROS2 환경에 맞춰 재설계된 설정 도구. ros2_control과의 연동을 포함하여 로봇 설정을 간소화한다. |
4 |
moveit_py (Python API) |
C++ 핵심 기능에 직접 바인딩되는 새로운 공식 Python 라이브러리. moveit_commander보다 더 깊이 있는 제어와 신속한 프로토타이핑을 지원한다. |
11 |
| 병렬 플래닝 (Parallel Planning) | 여러 모션 플래너를 동시에 실행하고, 사용자 정의 기준에 따라 최상의 결과를 선택하여 계획의 성공률과 품질을 높인다. | 15 |
moveit_configs_utils |
런치 파일(launch file) 작성 시 복잡한 파라미터 로딩 과정을 단순화하는 유틸리티. | 4 |
Table 1: ROS2 Humble MoveIt2 주요 신기능 요약
MoveIt2 아키텍처의 심장부에는 move_group 노드가 자리 잡고 있다. 이 노드는 단순한 실행 파일이 아니라, 분산된 MoveIt의 모든 구성 요소를 하나로 묶어주는 핵심 통합자(integrator) 역할을 수행한다.7 모션 플래닝, 기구학 계산, 충돌 검사, 환경 인식 등 각기 다른 기능을 수행하는 모듈들이
move_group을 통해 유기적으로 연동되며, 사용자는 이 노드가 제공하는 표준화된 ROS 인터페이스를 통해 로봇을 제어하게 된다. 이러한 중앙 집중식 통합 구조는 복잡한 매니퓰레이션 시스템의 설계를 단순화하고 일관성을 부여한다.
move_group은 크게 세 가지 방향으로 인터페이스를 제공한다. 첫째, 사용자 인터페이스다. 개발자는 고수준의 C++ API인 move_group_interface나 새로 도입된 Python API moveit_py를 사용하여 프로그래밍 방식으로 move_group에 계획 및 실행 명령을 내릴 수 있다.7 또한, 비전문가나 빠른 프로토타이핑을 위해 RViz의 Motion Planning Plugin이라는 그래픽 사용자 인터페이스(GUI)를 통해서도 직관적인 조작이 가능하다.8
둘째, 로봇 인터페이스다. move_group은 실제 로봇 하드웨어나 시뮬레이션 환경과 통신하기 위해 표준 ROS 메커니즘을 활용한다. /joint_states 토픽을 구독하여 로봇의 현재 관절 각도와 같은 상태 정보를 실시간으로 수신하고, TF2 라이브러리를 통해 로봇의 각 링크(link)와 외부 환경의 좌표계 관계를 파악한다.7 계획된 궤적을 실행할 때는
FollowJointTrajectoryAction이라는 표준 액션 인터페이스를 사용하는데, 이 지점이 바로 ros2_control과 같은 하드웨어 추상화 계층과 연동되는 핵심적인 부분이다.7
셋째, 내부 구성 요소와의 상호작용이다. move_group은 플러그인(plugin) 기반으로 설계되어 높은 확장성을 자랑한다. 역기구학 솔버, 모션 플래너 등 핵심 기능들이 pluginlib를 통해 동적으로 로드되는 플러그인 형태로 구현되어 있어, 사용자는 필요에 따라 기본 제공되는 OMPL 플래너 대신 STOMP나 CHOMP를 사용하거나, KDL 솔버를 TRAC-IK로 교체하는 등의 커스터마이징을 손쉽게 할 수 있다.8 또한, move_group은 내부적으로 ‘플래닝 씬 모니터(Planning Scene Monitor)’를 운영하여 로봇 자체의 상태뿐만 아니라 주변 환경에 존재하는 장애물, 로봇이 집고 있는 물체 등의 정보를 통합적으로 관리하는 ‘플래닝 씬(Planning Scene)’을 유지한다. 이 플래닝 씬은 모든 계획 및 충돌 검사의 기준이 되는 가상 세계의 복사본 역할을 한다.8
전통적인 로봇 제어 패러다임인 “Sense-Plan-Act”는 환경을 인식(Sense)하고, 목표까지의 경로를 계획(Plan)한 뒤, 계획된 경로를 실행(Act)하는 순차적인 방식으로 동작한다.12 이 모델은 정적인 환경이나 변화가 예측 가능한 환경에서는 매우 효과적이지만, 인간과 함께 작업하거나 예측 불가능한 장애물이 나타나는 동적인 실제 환경에서는 명백한 한계를 드러낸다. 계획이 실행되는 도중에 환경이 변하면 기존 계획은 무효화되며, 로봇은 동작을 멈추고 전체 계획 과정을 처음부터 다시 시작해야 하기 때문이다. 이는 비효율적일 뿐만 아니라 로봇의 반응성을 현저히 떨어뜨린다.
MoveIt2 Humble에서 도입된 하이브리드 플래닝(Hybrid Planning)은 이러한 전통적인 패러다임의 한계를 극복하기 위한 새로운 아키텍처적 접근이다.12 이 아키텍처의 핵심 아이디어는 서로 다른 시간 척도(timescale)와 문제 범위(scope)를 가진 두 종류의 플래너를 결합하여 사용하는 것이다.
이 두 플래너는 하이브리드 플래닝 매니저(Hybrid Planning Manager)에 의해 조율된다.12 매니저는 전역 플래너에게 초기 경로 생성을 요청하고, 지역 플래너에게 해당 경로를 따라 실행하도록 지시한다. 만약 지역 플래너가 실행 도중 해결할 수 없는 문제(예: 전역 경로가 완전히 막힘)를 감지하면, 매니저에게 이를 알리고 매니저는 전역 플래너에게 재계획(replanning)을 요청하는 방식으로 상호작용한다.
이러한 하이브리드 플래닝 아키텍처는 ROS1의 move_group이 종종 비대하고 단일 실패 지점(single point of failure)이 될 수 있었던 점에 대한 반성에서 비롯된 설계 철학을 반영한다. 하이브리드 플래닝은 매니저, 전역 플래너, 지역 플래너라는 세 개의 독립적인 ROS 노드로 구성된다.12 이들은 오직 ROS2의 표준 메시지 인터페이스(액션, 토픽)를 통해서만 상호작용한다. 이러한 모듈식 설계는 각 컴포넌트의 독립적인 개발, 테스트, 교체를 용이하게 한다. 예를 들어, 사용자는 기본 OMPL 기반 전역 플래너를 자체 개발한 특수 플래너로 교체하더라도, ROS 액션 API만 준수한다면 매니저나 지역 플래너 코드를 전혀 수정할 필요가 없다. 이는 연구(새로운 알고리즘 테스트)와 산업(특화된 솔루션 통합) 양쪽 모두에 큰 유연성과 강건성을 제공하며, ROS2의 컴포저블(composable) 노드 철학을 성공적으로 구현한 사례라 할 수 있다.
MoveIt2는 플러그인 기반 아키텍처를 통해 다양한 모션 플래닝 라이브러리를 지원한다. 그중에서도 가장 대표적인 것은 샘플링 기반의 OMPL과 최적화 기반의 STOMP, CHOMP이다. 각 플래너는 서로 다른 철학과 장단점을 가지고 있어, 주어진 문제의 특성에 따라 적절한 플래너를 선택하거나 조합하는 것이 중요하다.
OMPL(Open Motion Planning Library)은 MoveIt2의 기본 플래너로, 로봇의 설정 공간(Configuration Space) 내에서 무작위로 샘플을 추출하고, 이 샘플들을 연결하여 유효한 경로를 탐색하는 다양한 알고리즘을 제공한다.17 대표적인 알고리즘으로는 RRT(Rapidly-exploring Random Trees), RRTConnect, RRT* 등이 있다.
최적화 기반 플래너들은 시작점과 목표점을 잇는 초기 경로(naive trajectory, 예를 들어 직선 보간)를 설정한 후, 이 경로를 반복적으로 변형하여 비용 함수(cost function)를 최소화하는 방식으로 동작한다. 비용 함수는 보통 경로의 부드러움(smoothness), 장애물과의 거리, 운동학적 제약 등을 포함한다.
STOMP (Stochastic Trajectory Optimization for Motion Planning): 확률적 최적화(stochastic optimization) 기법을 사용하는 플래너다.19 각 반복 단계에서 현재 경로 주변에 무작위 노이즈를 추가하여 다수의 후보 경로들을 생성하고, 이들의 비용을 평가하여 더 나은 경로로 업데이트한다. 이러한 확률적 탐색 방식 덕분에 경사 하강법(gradient descent) 기반의 플래너들이 빠지기 쉬운 지역 최솟값(local minima)을 효과적으로 회피하는 경향이 있다.19 또한, 비용 함수의 미분 가능성을 요구하지 않아 토크 제한이나 에너지 소비와 같은 비연속적인 비용 항을 쉽게 추가할 수 있다는 장점이 있다.19
CHOMP (Covariant Hamiltonian Optimization for Motion Planning): 경사 하강법에 기반한 궤적 최적화 알고리즘이다.18 초기 경로상의 각 지점에서 비용 함수의 그래디언트(gradient)를 계산하고, 이를 이용해 경로를 충돌이 없고 더 부드러운 방향으로 수정해 나간다. 하지만 이 방식은
지역 최솟값에 매우 취약하여, 초기 경로가 좋지 않거나 환경이 복잡할 경우 최적해를 찾지 못하고 실패할 가능성이 있다.19 성공적인 계획을 위해서는 ridge_factor와 같은 파라미터를 신중하게 튜닝해야 한다.17
세 플래너는 뚜렷한 장단점을 가지며, 이는 다음 표와 같이 요약될 수 있다.
| 비교 기준 | OMPL | STOMP | CHOMP |
|---|---|---|---|
| 알고리즘 유형 | 샘플링 기반 | 확률적 최적화 | 경사 하강법 기반 최적화 |
| 확률적 완전성 | 보장됨 (Probabilistically Complete) | 보장되지 않음 (Incomplete) | 보장되지 않음 (Incomplete) |
| 경로 품질 | 낮음 (후처리 필요) | 높음 (기본적으로 부드러움) | 높음 (기본적으로 부드러움) |
| 계획 시간 | 매우 빠름 | 비교적 느림 | 비교적 느림 |
| 지역 최솟값 회피 | 문제되지 않음 | 강함 | 약함 (자주 갇힘) |
| 튜닝 난이도 | 보통 (기본값으로도 잘 동작) | 보통 | 어려움 (많은 튜닝 필요) |
Table 2: 모션 플래너 비교 (OMPL vs. STOMP vs. CHOMP)
어떤 플래너가 특정 문제에 최적일지 미리 아는 것은 매우 어렵다. 이러한 “플래너 선택”의 딜레마를 해결하기 위해 MoveIt2는 병렬 플래닝(Parallel Planning)이라는 새로운 인터페이스를 도입했다.15 이는 단순히 여러 플래너를 순차적으로 시도하는 것을 넘어, 다수의 플래닝 파이프라인(예: OMPL, STOMP, Pilz)을 동시에 실행하고, 이들로부터 생성된 여러 해답 중에서 사용자 정의 기준에 따라 가장 좋은 것을 선택하는 방식이다.15
이 접근법은 사용자 상호작용 모델의 근본적인 변화를 의미한다. 개발자는 더 이상 “어떤 플래너를 선택하고 어떻게 튜닝해야 하는가?”라는 전문가 수준의 질문에 답할 필요가 없다. 대신, “내 작업에 있어 좋은 계획이란 무엇인가(예: 가장 짧은 경로, 가장 빠른 계산 시간)?”라는 문제 중심적인 질문에 답하면 된다.15 예를 들어, ‘가장 짧은 경로’를 선택 기준으로 설정하면, 병렬 플래너는 OMPL이 빠르게 찾은 긴 경로와 STOMP가 느리게 찾은 짧은 경로 중 후자를 자동으로 선택해준다. 또한, ‘가장 먼저 도착한 유효한 해’를 정지 조건(stopping criterion)으로 설정하면, 가장 빠른 플래너의 장점을 취하면서 다른 플래너들을 통해 성공률을 보완하는 효과를 얻을 수 있다.15 이처럼 병렬 플래닝은 계획 과정의 복잡성을 추상화하여, 개발자가 더 높은 수준에서 문제 해결에 집중할 수 있도록 돕는 강력한 도구다.
MoveIt2 프레임워크는 모션 플래닝 파이프라인 외에도 로봇 매니퓰레이션의 근간을 이루는 여러 핵심 기술 요소들로 구성되어 있다. 이들 역시 플러그인 형태로 제공되어, 사용자가 필요에 따라 선택하고 교체할 수 있는 유연성을 제공한다. 그중 역기구학(IK) 솔버와 충돌 검사 라이브러리는 가장 기본적이면서도 시스템 전체 성능에 큰 영향을 미치는 중요한 구성 요소다.
역기구학은 로봇의 엔드 이펙터(end-effector)가 도달하고자 하는 목표 자세(position and orientation)가 주어졌을 때, 그 자세를 만족하는 각 관절의 각도를 계산하는 문제다. 이는 모든 매니퓰레이션 작업의 기본이 된다.
이러한 하이브리드 접근 방식 덕분에 TRAC-IK는 KDL에 비해 월등히 높은 성공률을 보인다. 또한, TRAC-IK는 사용자가 최적화 목표를 선택할 수 있는 solve_type 파라미터를 제공하여 유연성을 더한다.22 예를 들어,
Speed는 가장 빠른 해를, Distance는 초기 시드(seed) 자세와 가장 가까운 해를, Manip1 또는 Manip2는 조작성(manipulability)이 가장 좋은 해를 찾도록 지시할 수 있다.
| 비교 기준 | KDL | TRAC-IK |
|---|---|---|
| 기반 알고리즘 | 뉴턴-랩슨 방법 | 뉴턴-랩슨 확장 + 순차적 2차 계획법(SQP) 병렬 실행 |
| 조인트 제한 처리 능력 | 약함 (지역 최솟값에 취약) | 강함 (무작위 점프 및 SQP 최적화로 극복) |
| 신뢰성 / 수렴률 | 낮음 | 높음 |
| 설정 가능 옵션 | 제한적 (timeout, epsilon 등) | 다양함 (solve_type: Speed, Distance, Manip1, Manip2 등) |
Table 3: 역기구학 솔버 비교 (KDL vs. TRAC-IK)
이러한 IK 솔버들의 성능은 ik_benchmarking 패키지를 통해 정량적으로 평가할 수 있다. 이 도구는 지정된 로봇과 플래닝 그룹에 대해 여러 IK 솔버를 수천 번씩 테스트하여 해결 시간, 성공률, 위치 및 방향 오차 등을 측정하고 시각화해준다.24 이를 통해 개발자는 자신의 애플리케이션에 가장 적합한 IK 솔버를 데이터 기반으로 선택할 수 있다.
충돌 검사는 모션 플래닝의 필수적인 부분으로, 계획된 경로가 로봇의 자체 링크들이나 외부 환경의 장애물과 충돌하지 않는지 확인하는 과정이다. MoveIt2는 CollisionEnv라는 추상 클래스를 통해 충돌 검사 기능을 제공하며, 실제 계산은 플러그인 형태로 구현된 외부 라이브러리가 담당한다.25
KDL에서 TRAC-IK로의 진화, 그리고 FCL과 Bullet 같은 다양한 충돌 검사 라이브러리의 지원은 MoveIt 프레임워크의 성숙도를 보여주는 중요한 지표다. 이는 IK나 충돌 검사와 같은 핵심 로봇 공학 문제에 대해 ‘하나의 정답’은 없다는 것을 인정한 결과다. 따라서 MoveIt 프레임워크의 가치는 단일 알고리즘의 우수성에서, 사용자가 자신의 특정 로봇과 작업에 가장 적합한 도구를 선택하여 장착할 수 있는 견고한 플러그인 인터페이스를 제공하는 플랫폼으로서의 역할로 점차 이동하고 있다. 이는 MoveIt이 특정 구현에 얽매이지 않고, 각 분야에서 최고 수준의 알고리즘들을 유연하게 통합할 수 있는 생태계의 허브가 되고자 하는 전략적 방향성을 시사한다.
실제 로봇 애플리케이션은 정적인 환경에서 미리 계획된 경로를 그대로 실행하는 경우보다, 예측 불가능한 변화에 실시간으로 대응해야 하는 경우가 훨씬 많다. MoveIt2는 이러한 도전에 맞서기 위해, 서로 다른 시간 척도와 반응 수준을 가진 두 가지 강력한 기능, 즉 MoveIt Servo와 하이브리드 플래닝을 제공한다.
MoveIt Servo는 전통적인 ‘계획 후 실행(plan-then-execute)’ 패러다임에서 벗어나, 로봇의 엔드 이펙터를 실시간으로 제어하기 위한 기능이다.28 이는 외부 장치로부터 geometry_msgs/msg/TwistStamped(선속도 및 각속도 명령) 또는 geometry_msgs/msg/PoseStamped(목표 자세)와 같은 명령을 지속적으로 받아, 이를 충족시키는 관절 속도를 계산하여 로봇에 전달하는 방식으로 동작한다.28
Servo의 주된 용도는 다음과 같다.
MoveIt Servo는 단순한 역기구학 속도 계산기를 넘어선다. 내부적으로 실시간 충돌 검사, 특이점(singularity) 감지, 관절 제한 준수 기능을 포함하고 있다.29 만약 명령된 움직임이 충돌을 유발하거나, 로봇이 특이점 자세에 가까워지면, Servo는 자동으로 로봇의 속도를 줄이거나 정지시켜 시스템의 안전을 보장한다.30 이처럼 Servo는 고주파(high-frequency)의 연속적인 제어 명령에 안전하고 빠르게 반응하는 데 특화되어 있다.
MoveIt Servo가 저수준의 실시간 ‘제어’에 가깝다면, 하이브리드 플래닝은 고수준의 실시간 ‘계획’에 해당한다. 이는 작업의 전체적인 맥락을 유지하면서 중대한 환경 변화에 대응하기 위한 아키텍처다.
하이브리드 플래닝은 전역 플래너가 생성한 거시적인 경로를 지역 플래너가 실시간으로 따라가는 구조로 동작한다.12 여기서 핵심은 지역 플래너의 역할이다. 지역 플래너는 전역 경로를 따라가면서, 예상치 못했던 동적 장애물을 감지하면 두 가지 방식으로 대응할 수 있다. 첫째, 지역적인 회피 기동을 통해 장애물을 살짝 비켜갈 수 있다. 둘째, 만약 장애물이 전역 경로를 완전히 막아버리는 등 지역적으로 해결할 수 없는 문제라고 판단되면, 실행을 안전하게 일시 중지하고 하이브리드 플래닝 매니저를 통해 전역 플래너에게 새로운 경로를 찾아달라고
재계획(replanning)을 요청한다.12
이러한 메커니즘은 로봇이 작업을 완전히 중단하고 처음부터 다시 시작하는 대신, 변화에 유연하게 적응하며 임무를 계속 수행할 수 있게 해준다. 이는 저주파(low-frequency)로 발생하는 중대한 환경 변화에 대한 지능적인 반응 전략이라 할 수 있다.
두 기능의 차이점과 적용 분야를 명확히 이해하기 위해, 산업 현장에서 흔히 볼 수 있는 ‘움직이는 컨베이어 벨트 위의 물체를 집는’ 작업을 예로 들어보자.31
Twist 또는 Pose 명령을 Servo에 계속해서 보내주면, 로봇은 물체의 움직임을 부드럽게 따라갈 수 있다. 이는 고주파의 연속적인 위치 변화에 대응하는 ‘추적’ 작업의 전형이다. 단, 이 과정에서 로봇이 특이점이나 충돌 위험이 없는 비교적 짧은 범위 내에서 움직인다고 가정한다.31결론적으로, MoveIt2는 동적 환경 문제에 대해 단일 해결책을 제시하는 대신, 정교한 다층적 전략을 제공한다. MoveIt Servo는 고주파, 저지연의 미세 제어를 담당하고, 하이브리드 플래닝은 저주파, 고지연의 거시적 재계획을 담당한다. 이 두 기능은 서로 경쟁하는 것이 아니라, 서로 다른 시간 척도에서 발생하는 문제들을 해결하며 상호 보완적으로 작동한다. 개발자는 이러한 다층적 접근 방식을 통해 자신의 애플리케이션이 요구하는 반응성의 수준과 종류에 맞춰 가장 적합한 도구를 선택하여 견고하고 유연한 시스템을 구축할 수 있다.
| 비교 기준 | MoveIt Servo | 하이브리드 플래닝 (Hybrid Planning) |
|---|---|---|
| 주요 목적 | 실시간 속도/자세 제어 | 동적 환경에서의 반응형 재계획 |
| 입력 방식 | TwistStamped, PoseStamped 등 연속적인 외부 명령 |
MotionPlanRequest 등 단일 작업 목표 |
| 반응 속도 | 매우 빠름 (고주파, 저지연) | 비교적 느림 (저주파, 고지연) |
| 처리 가능한 문제 | 원격 조작, 비주얼 서보잉, 미세 조정 | 중대한 환경 변화, 동적 장애물 회피 |
| 적합한 애플리케이션 | 컨베이어 추적, 표면 연마, 인간-로봇 상호작용 | 물류 창고, 서비스 로봇, 비정형 환경 작업 |
Table 4: 실시간 제어 전략 비교 (MoveIt Servo vs. Hybrid Planning)
MoveIt2를 실제 로봇에 적용하기 위해서는 로봇의 기구학적, 동역학적 정보를 MoveIt2가 이해할 수 있는 형식으로 변환하고, 하드웨어 제어 시스템과 연동하는 과정이 필수적이다. 이 과정은 MoveIt 설정 어시스턴트(Setup Assistant)를 통해 상당 부분 자동화할 수 있으며, ros2_control 프레임워크가 하드웨어 연동의 핵심적인 다리 역할을 한다.
MoveIt 설정 어시스턴트는 URDF(Unified Robot Description Format) 파일로부터 MoveIt 설정 패키지를 생성해주는 그래픽 도구다.13 이 과정을 통해 로봇의 의미론적 정보(SRDF), 기구학 및 플래닝 설정, 컨트롤러 설정 등을 담은 파일들이 자동으로 생성된다. ROS2 Humble 기준의 일반적인 워크플로는 다음과 같다.13
ros2 launch moveit_setup_assistant setup_assistant.launch.py 명령으로 어시스턴트를 실행하고, 로봇의 URDF 파일을 로드한다.13fixed)하거나, 이동형 로봇의 경우 평면상에서 움직이도록(planar) 가상의 조인트를 추가한다.32ros2_control 연동 설정 (8~10단계): 이 부분이 MoveIt2와 하드웨어를 연결하는 가장 중요한 과정이다.
ros2_control을 통해 제어하기 위해, URDF 파일에 <ros2_control> 태그를 추가한다. 이 태그 안에는 각 관절이 어떤 명령 인터페이스(command_interface, 예: position)를 받고 어떤 상태 인터페이스(state_interface, 예: position, velocity)를 제공하는지 명시한다.13ros2_control 프레임워크 위에서 동작할 컨트롤러를 설정한다. 예를 들어, ‘arm’ 그룹을 위해서는 joint_trajectory_controller/JointTrajectoryController를, ‘gripper’를 위해서는 position_controllers/GripperActionController를 선택하고, 각 컨트롤러가 제어할 관절들을 지정한다.13FollowJointTrajectory 타입의 MoveIt 컨트롤러를 생성하고, 이를 panda_arm_controller와 같은 ROS 2 컨트롤러 이름과 매핑한다.13moveit_config 패키지를 생성한다. 이 패키지에는 SRDF 파일, 각종 YAML 설정 파일, 런치 파일 등이 포함된다.13ros2_control은 ROS2 생태계에서 로봇 하드웨어를 제어하기 위한 표준 프레임워크다.34 이는 하드웨어 드라이버(실제 모터를 구동하는 코드)와 고수준의 제어기(궤적을 따라가는 컨트롤러 등) 사이에 위치하여, 하드웨어의 복잡성을 추상화하는 역할을 한다. MoveIt2는 ros2_control을 통해 특정 제조사의 로봇에 종속되지 않고, 표준화된 방식으로 로봇을 제어할 수 있다.
연동 과정은 다음과 같다.
ros2_control 하드웨어 인터페이스를 작성한다. 이 코드는 실제 하드웨어로부터 현재 관절 상태(위치, 속도)를 읽어와 state_interface에 값을 채우고, command_interface로 들어온 목표 값(예: 목표 위치)을 하드웨어에 전달하는 역할을 한다.33controller_manager 노드는 URDF에 정의된 정보를 바탕으로 joint_trajectory_controller와 같은 컨트롤러들을 로드하고 활성화한다.move_group은 모션 플래닝을 통해 생성된 궤적(trajectory_msgs/msg/JointTrajectory)을 FollowJointTrajectoryAction 액션 목표에 담아 joint_trajectory_controller에게 전송한다.joint_trajectory_controller는 수신한 궤적을 시간에 맞춰 보간(interpolation)하면서, 매 제어 주기마다 계산된 목표 관절 값을 command_interface를 통해 하드웨어 인터페이스에 전달한다. 하드웨어 인터페이스는 이 값을 실제 로봇 모터에 명령하여 로봇이 움직이게 한다.35이러한 구조를 통해 MoveIt2는 실제 하드웨어의 구체적인 제어 방식에 대해 알 필요 없이, 표준 액션 인터페이스를 통해 궤적 실행을 요청하기만 하면 된다. 이는 시뮬레이션(예: Gazebo)과 실제 로봇 간의 전환을 매우 용이하게 만들어 준다.
MoveIt2는 C++과 Python, 두 가지 주요 프로그래밍 인터페이스를 제공한다.
C++ API (move_group_interface): 전통적으로 사용되어 온 고수준 C++ 인터페이스다.16
moveit::planning_interface::MoveGroupInterface 클래스를 통해 특정 플래닝 그룹에 대한 목표 자세 설정(setPoseTarget), 목표 관절 값 설정(setJointValueTarget), 계획(plan), 실행(execute) 등의 기능을 직관적으로 사용할 수 있다.16 성능이 중요한 애플리케이션이나 시스템의 핵심 로직을 개발할 때 주로 사용된다.
Python API (moveit_py): ROS2 Humble 이후 본격적으로 도입된 새로운 공식 Python 라이브러리다.11 과거의
moveit_commander가 move_group 노드의 ROS 인터페이스를 단순히 감싸는 래퍼(wrapper)에 가까웠다면, moveit_py는 pybind11을 사용하여 MoveIt의 핵심 C++ 컴포넌트(예: RobotState, PlanningScene, moveit_cpp 인터페이스)에 직접 바인딩된다.11
MoveItPy 노드를 인스턴스화하고, get_planning_component 메서드를 통해 제어하고자 하는 플래닝 그룹 객체를 얻는다.38# instantiate MoveItPy instance and get planning component
panda = MoveItPy(node_name="moveit_py")
panda_arm = panda.get_planning_component("panda_arm")
set_start_state_to_current_state, set_goal_state 등의 메서드를 사용하여 계획의 시작과 목표를 설정하고 plan 및 execute를 호출한다. RobotState 객체를 직접 생성하고 조작하여 목표를 설정하거나, 여러 플래닝 파이프라인을 병렬로 실행하는 등 C++ API에서 가능한 거의 모든 고급 기능을 Python 환경에서 사용할 수 있다.38moveit_py의 등장은 단순한 언어 지원 추가 이상의 전략적 의미를 갖는다. AI 및 머신러닝 연구 커뮤니티는 압도적으로 Python을 선호한다. moveit_py는 이러한 커뮤니티가 강화학습이나 모방학습과 같은 최신 기술을 로봇 매니퓰레이션에 쉽게 접목할 수 있는 다리를 놓아준다. 실제로 moveit_py의 향후 개발 계획에는 ‘학습된 정책을 MoveIt Servo로 배포’하거나 ‘모방학습을 위한 데이터 수집’과 같은 기능이 명시되어 있다.11 Jupyter Notebook을 활용한 대화형 프로토타이핑이 가능하다는 점 또한 연구 및 개발 속도를 획기적으로 높여준다.14 이는 MoveIt2가 차세대 로봇 연구의 핵심 플랫폼으로 자리매김하기 위한 중요한 전략적 투자임을 보여준다.
MoveIt2는 독립적인 프레임워크를 넘어, ROS2라는 거대한 생태계 안에서 다른 강력한 도구들과 상호작용하며 발전하고 있다. Tesseract, Drake와 같은 다른 모션 플래닝 프레임워크와의 관계를 이해하고, MoveIt의 공식 개발 로드맵을 분석하는 것은 MoveIt2의 현재 위치와 미래 방향성을 파악하는 데 중요하다.
const 함수의 스레드 안전성(thread-safety)을 강조하는 반면, Tesseract는 모션 플래닝 시 환경 전체를 복제(cloning)하는 방식을 사용한다.41 이는 각 플래닝 스레드가 독립적인 환경 복사본을 소유하게 하여, 데이터 복사로 인한 성능 저하를 최소화하고 복잡한 락(lock) 메커니즘을 피할 수 있게 해준다. 또한, 환경에 가해지는 모든 변경사항(장애물 추가/제거 등)을 순차적으로 기록하는 ‘Command History’ 기능을 내장하여, 특정 시점의 환경 상태를 완벽하게 재현하고 디버깅을 용이하게 한다.41 이는 예측 가능성과 재현성이 극도로 중요한 산업 현장에 더 적합한 설계라 할 수 있다.MoveIt2는 이러한 프레임워크들과 단순히 경쟁하는 관계에만 머무르지 않는다. 오히려 MoveIt의 강력한 ROS 통합 능력과 사용자 친화성을 기반으로, 다른 프레임워크의 장점을 흡수하려는 노력을 기울이고 있다. 대표적인 예가 moveit_drake 프로젝트다.44 이는 MoveIt의 플러그인 아키텍처를 활용하여 Drake의 강력한 궤적 최적화 알고리즘(KinematicTrajectoryOptimization)을 MoveIt의 모션 플래너 중 하나로 통합하려는 시도다.43 이는 MoveIt이 모든 문제를 해결하려는 단일체(monolith)가 아니라, 각 분야 최고의 도구들을 연결하는 통합 허브(integration hub)로서의 역할을 지향하고 있음을 보여준다.
MoveIt의 공식 로드맵은 프로젝트의 단기 및 장기 발전 방향을 가늠할 수 있는 중요한 자료다.45 로드맵을 통해 최근 완료된 주요 기능들을 살펴보면, 하이브리드 플래닝, MoveIt Task Constructor(MTC)의 ROS2 포팅, STOMP 플래너 개선 등 ROS2의 장점을 활용하고 사용자 경험을 개선하는 데 집중해왔음을 알 수 있다.45
MoveIt의 장기적인 목표는 크게 두 가지 방향으로 요약될 수 있다.4
moveit_configs_utils와 같은 유틸리티 제공, 그리고 moveit_py를 통한 Python 지원 강화는 모두 이 목표를 향한 구체적인 노력이다.Google Summer of Code(GSoC)와 같은 프로그램을 통해 Python 바인딩 생성, 다중 로봇 팔의 동시 궤적 실행과 같은 도전적인 과제들을 해결해 나가는 것 또한 MoveIt 커뮤니티의 활발한 발전을 보여주는 증거다.4 이러한 움직임들은 MoveIt2가 학계의 최신 연구 성과를 빠르게 흡수하고, 산업계의 실질적인 요구에 부응하며, 초심자부터 전문가까지 아우르는 폭넓은 사용자층을 확보하려는 명확한 비전을 가지고 있음을 시사한다.
MoveIt2는 강력한 프레임워크지만, 그 복잡성으로 인해 개발 과정에서 다양한 문제에 직면할 수 있다. 효과적인 디버깅을 위해서는 MoveIt2 자체의 오류 메시지를 이해하는 것뿐만 아니라, 그 기저에 있는 ROS2 시스템 전반에 대한 이해가 필수적이다.
개발자들이 흔히 마주치는 MoveIt2 관련 오류와 그 원인 및 해결책은 다음과 같다.
Controller Manager not available: 이 오류는 move_group 노드가 ros2_control의 controller_manager 서비스와 통신할 수 없을 때 발생한다.46
controller_manager 노드가 실행되지 않았거나, 로드가 완료되지 않았거나, 네트워크 문제로 서비스가 발견되지 않는 경우.ros2 service list | grep controller_manager 명령을 통해 /controller_manager/list_controllers와 같은 서비스가 활성화되어 있는지 확인한다. 런치 파일에서 controller_manager가 move_group보다 먼저 실행되도록 순서를 조정하는 것도 도움이 될 수 있다.Move Group process died: move_group 노드가 예기치 않게 종료되었음을 의미하는 가장 일반적인 오류 메시지다.46
나 수준의 메시지를 확인해야 한다. 더 자세한 정보는 ROS2 로그 디렉토리(~/.ros/log/)에 저장된 파일에서 찾을 수 있다.46Requesting Initial Scene failed: RViz의 Motion Planning Plugin이 move_group으로부터 현재 플래닝 씬 정보를 받아오지 못할 때 나타나는 경고다.46
move_group 노드가 제대로 실행되지 않았거나, 플래닝 씬을 발행하는 토픽에 문제가 있는 경우.ros2 node list를 통해 move_group 노드가 실행 중인지 확인하고, ros2 topic echo /planning_scene (토픽 이름은 다를 수 있음) 명령으로 플래닝 씬 데이터가 정상적으로 발행되고 있는지 점검한다.MoveGroup Action Client/Server Not Ready: move_group_interface와 같은 클라이언트가 move_group의 액션 서버를 찾지 못할 때 발생한다.46
move_group 노드가 아직 액션 서버를 초기화하지 못했거나, 클라이언트와 서버 간의 DDS 통신에 문제가 있는 경우.move_group 노드의 로그를 확인하여 액션 서버가 성공적으로 생성되었는지(Action server /move_group/plan ready.) 확인한다. 클라이언트 코드에서 액션 서버를 기다리는 대기 시간(waitForServer)을 충분히 길게 설정하는 것도 방법이다.상당수의 “MoveIt2 문제”는 사실상 “ROS2 시스템 문제”인 경우가 많다. ROS1에 비해 복잡해진 ROS2의 통신 및 실행 모델은 새로운 유형의 잠재적 오류 지점을 만들어낸다. 따라서 MoveIt2를 디버깅하기 위해서는 ROS2 시스템 수준의 디버깅 능력이 필수적이다.
use_sim_time 파라미터 불일치: 시뮬레이션 환경에서 일부 노드는 use_sim_time을 true로 설정하고 다른 노드는 false(기본값)로 설정하면, 타임스탬프가 맞지 않아 TF 변환 오류(Lookup would require extrapolation into the future.)가 발생한다. 시스템의 모든 노드가 동일한 시간 소스(real 또는 sim)를 사용하도록 런치 파일에서 일관되게 설정해야 한다.47RMW_IMPLEMENTATION)를 설정하여 모든 노드가 동일한 DDS를 사용하도록 강제하거나, 다른 DDS로 변경하여 테스트해볼 필요가 있다.47Ctrl+C)할 경우, 일부 노드가 백그라운드에서 계속 실행 중인 상태로 남을 수 있다. 이 ‘좀비 노드’가 새로 시작된 노드와 충돌하여 예기치 않은 동작을 유발할 수 있다. ros2 node list나 ps aux | grep ros와 같은 명령으로 불필요한 프로세스가 남아있는지 확인하고 종료해야 한다.47colcon build를 실행하지 않거나, 빌드 후 source install/setup.bash 명령을 실행하지 않으면 변경 사항이 적용되지 않는다. 특히 Python 노드나 런치 파일 수정 시 잊기 쉬운 실수다.47chmod +x)이 부여되어야 한다. 또한, 스크립트 최상단에는 #!/usr/bin/env python3와 같은 Shebang 라인이 있어야 한다.47모든 문제를 혼자 해결할 수는 없다. MoveIt2와 ROS2는 거대하고 활발한 커뮤니티를 가지고 있으며, 이를 적극적으로 활용하는 것이 중요하다.
효과적인 문제 해결은 단지 코드 디버깅에 그치지 않고, 시스템 전체의 상태를 분석하고 커뮤니티의 집단 지성을 활용하는 종합적인 접근 방식을 요구한다.
ROS2 Humble Hawksbill 배포판을 기점으로 한 MoveIt2는 로봇 매니퓰레이션 프레임워크의 중요한 변곡점을 맞이했다. 이는 단순히 ROS1의 기능을 ROS2로 이식하는 초기 단계를 성공적으로 완수했음을 넘어, ROS2가 제공하는 실시간성, 모듈성, 강건성이라는 아키텍처적 장점을 본격적으로 활용하는 성숙한 플랫폼으로 진화했음을 의미한다.
아키텍처 측면에서, 하이브리드 플래닝의 도입은 정적인 ‘Sense-Plan-Act’ 패러다임을 넘어 동적 환경에 능동적으로 반응할 수 있는 새로운 가능성을 열었다. 특히 이를 세 개의 독립적인 ROS 노드로 구현한 것은 ROS2의 컴포저블 철학을 반영한 모듈식 설계의 승리이며, 향후 확장성과 유지보수성을 크게 향상시킬 것이다. 플래닝 측면에서는 병렬 플래닝 인터페이스가 추가되어, 개발자가 더 이상 특정 플래너의 전문가가 되지 않아도 문제의 ‘요구사항’을 정의함으로써 높은 품질의 계획을 얻을 수 있게 되었다. 이는 복잡한 모션 플래닝 기술의 민주화에 기여하는 중요한 진보다. 제어 측면에서는 MoveIt Servo가 실시간 원격 조작 및 서보잉을 위한 안전하고 신뢰할 수 있는 솔루션을 제공하며, ros2_control과의 긴밀한 통합은 하드웨어 추상화 수준을 한 단계 끌어올렸다. 마지막으로 사용성 측면에서, moveit_py라는 강력한 Python API의 등장은 신속한 프로토타이핑을 가능하게 하고, AI/ML 연구 커뮤니티와의 교류를 촉진하여 MoveIt2 생태계를 더욱 풍성하게 만들 잠재력을 지니고 있다.
결론적으로 ROS2 Humble MoveIt2는 과거의 유산을 성공적으로 계승하면서도, 미래 지향적인 새로운 패러다임을 적극적으로 수용한, 안정성과 혁신성을 모두 갖춘 강력한 매니퓰레이션 프레임워크로 평가할 수 있다.
MoveIt의 공식 로드맵과 생태계 동향을 종합해 볼 때, 향후 발전은 ‘사용 편의성 증대’와 ‘고급 궤적 지원’이라는 두 가지 큰 축을 중심으로 이루어질 것이다. 이는 더 많은 개발자와 연구자들이 MoveIt2를 쉽게 도입하고, 더 복잡하고 지능적인 매니퓰레이션 작업을 수행할 수 있도록 지원하겠다는 명확한 비전을 보여준다. 특히 Python API의 지속적인 강화와 AI/ML 기술과의 접목은 MoveIt2가 차세대 지능형 로봇 개발의 핵심 플랫폼으로 자리 잡는 데 중요한 역할을 할 것으로 전망된다.
이러한 환경 속에서 MoveIt2를 활용하는 개발자들에게 다음과 같은 제언을 하고자 한다.
moveit_py를 적극적으로 활용할 것을 권장한다. Jupyter Notebook을 이용한 대화형 개발 환경은 연구 및 개발 생산성을 극적으로 향상시킬 수 있다.ros2_control의 동작 원리, DDS 통신 메커니즘, 런치 파일 시스템 등 ROS2 전반에 대한 깊은 이해가 필수적임을 명심해야 한다. 탄탄한 기본기가 복잡한 문제를 해결하는 가장 강력한 무기가 될 것이다.| MoveIt 2 Humble Release | MoveIt, 8월 17, 2025에 액세스, https://moveit.ai/moveit/ros/humble/2022/06/02/MoveIt-Humble-Release.html |
| Concepts | MoveIt, 8월 17, 2025에 액세스, https://moveit.ai/documentation/concepts/ |
| Developer concepts | MoveIt, 8월 17, 2025에 액세스, https://moveit.ai/documentation/concepts/developer_concepts/ |
| Introducing MoveIt Servo in ROS 2 | MoveIt, 8월 17, 2025에 액세스, https://moveit.ai/moveit/ros2/servo/jog/2020/09/09/moveit2-servo.html |
| MoveIt Roadmap | MoveIt, 8월 17, 2025에 액세스, https://moveit.ai/documentation/contributing/roadmap/ |