[첨단 헬로티]

로봇에서 시스템 인티그레이션을 할 때에, 특히 최첨단의 연구 성과/소프트웨어 모듈의 활용이나 혹은 센서, 제어 데이터의 로깅, 비주얼리제이션 등의 경우에서 ROS의 활용은 반드시 필요해지고 있으며, 현재에는 디팩트 스탠더드로서 널리 인식되고 있다.

 

필자 자신도 ROS에 관한 해설 기사를 여러 번 썼는데, 거기에서는 ‘ROS=통신 라이브러리, 툴, 기반, 에코 시스템’의 도식을 소개, ROS의 최대 특징으로서 미들웨어 기술에 머물지 않고 그것을 이활용하기 위한 개발 툴과 유저 커뮤니티에 주력한 점을 지적하며, 이 점이 기존 개발된 미들웨어와 구분되어 ROS가 널리 유저를 모아 디팩트 스탠더드로서의 위치를 확립한 이유라고 설명해 왔다.

 

이 글에서는 계측과 제어라는 측면에서 ROS의 활용 상황을 소개하는 동시에, 다른 미들웨어 간의 상호 운용성을 확보하는 브리지 기술을 시작으로 산업계의 응용과 ROS2의 상황에 대해 전망해 본다.

ROS와 계측

ROS 툴에서 가장 널리 사용되고 있는 것의 하나로 rviz라고 불리는 데이터 비주얼리제이션 툴이 있다. 이 툴의 특징은 특정 데이터, 분야, 응용에 의존하지 않고, 미들웨어 상에서 통신되고 있는 데이터형에 대응해 그것의 시각화 방식을 기술한 플러그인을 준비함으로써 센서 정보나 제어 지령이라도, 그것이 미들웨어 상에서 통신되는 데이터라면 시각화할 수 있다는 점에 있다.

또한, 각종 데이터에는 타임스탬프를 설정하는 것이 일반적이고, 네트워크상을 흘러 도착 시간이 다른 복수의 센서 데이터도 타임스탬프를 참조해 동시각의 복수 소스 데이터를 동시시키는 message_filter와 같은 라이브러리도 널리 사용되고 있다.

그림 1 rviz를 이용한 비주얼리제이션의 예. 위의 그림은 3차원 센서로 계측한 환경 정보를 rviz 툴로

표시하고 있는 모습. 아래 그림은 동일한 rviz 툴로 로봇의 계획 궤도를 시각화하고 있는 모습.

예를 들면 그림 1의 위 그림에서는 3차원 센서로 계측한 환경 정보를 rviz 툴로 표시하고 있는 모습을 나타내고 있으며, 아래 그림은 동일한 rviz 툴로 로봇의 계획 궤도를 시각화하고 있는 모습을 나타낸다. 로보틱스에서는 전자는 3차원 비전·환경 인식 등의 분야이고, 후자는 궤도 계획·로봇 플래닝 등의 분야로, 예를 들면 연구자나 개발자가 겹치는 것도 드물 만큼 동떨어진 분야인데, 그러한 분야의 격차에도 불구하고 동일한 툴을 공유할 수 있다.

계측 분야에서는 그 비주얼리제이션은 데이터의 정밀조사나 평가, 프리젠테이션에서 중요함에도 불구하고 계측의 최대 요점인 데이터 수집이나 데이터 해석의 뒤로 밀리는 경우가 많다. 이와 같이 미들웨어의 통신 프로토콜이나 혹은 최첨단 알고리즘의 실장이나 소프트웨어 패키지화 등이 아니라, 데이터의 비주얼리제이션과 같이 본질적이지는 않지만 없으면 곤란한 가려운 곳을 긁어 주는 툴의 충실에도 주력하고 있는 것이 ROS의 특징으로, rviz는 그 가장 좋은 예의 하나일 것이다. 계측 분야의 연구자나 엔지니어에게는 꼭 활용을 권하고 싶다.

ROS와 제어

한편, ROS와 로봇 제어는 계측 분야만큼 친화성을 인정하는 것은 어렵다. ROS의 세계에는 ros_control이라고 하는 범용 로봇 컨트롤러 소프트웨어 패키지가 존재해 로봇의 정의 데이터 파일이 있으면, 그 로봇의 축 수에 대응한 데이터의 입출력을 제공해 준다. 또한, 위치 제어, 토크 제어 등의 기본 제어 컨트롤러 소프트웨어도 플러그인화되고, 교체할 수 있게 되어 있다. 더구나 gazebo 로봇 시뮬레이터와의 통합도 추진, ros_control과 동일한 인터페이스를 시뮬레이터로도 쉽게 제공할 수 있고, 동일한 컨트롤러 플러그인을 이용할 수 있다.

그러나 이 패키지를 이용해 그 제어 부분까지 ROS를 이용하고 있는 것은 일부이고, 대부분의 ROS 대응 로봇은 그 로봇 메이커의 기술을 이용해 로봇 제어 프로그램이 작성되어 있으며, 그것을 ROS에서 이용할 수 있는 인터페이스를 제공하고 있는 양식이 일반적이다.

그 이유는 몇 가지 생각할 수 있는데 ROS나 ros_control이 정비되기 전부터 각사가 로봇 컨트롤러를 가지고 있으며, 안전성이나 신뢰성과 직결하는 이 제어 부분에 관해서는 이행이 어려운 것이 실제는 아닌가 생각하고 있다.

이하에서는 기존 산업용 로봇 시스템과 ROS를 어떻게 접속해 오픈소스 로봇 컨트롤러를 실현하는지, 그 실례를 소개한다.

1. 산업용 로봇의 오픈소스 컨트롤러

기존 산업용 로봇 분야에서 컨트롤러는 전원 관리에서부터 유저 인터페이스, 때로는 프로그래밍 환경까지 포함한 통합적인 시스템으로 되어 있었다. 그러나 최근의 IoT나 인공지능 분야 발전에 동반해 이들 기술에 대응한 고도지능화, 고성능화가 요구되고 있는데, 이를 위해서는 기존형의 폐쇄된 시스템이 아니라 외부와의 오픈성을 확보해 세계적인 성과를 도입할 수 있는 시스템이 요구되고 있다. 또한, 그러한 시스템을 구축할 수 있으면, 신흥국의 높은 자동화 요구에 대응해 문제가 되고 있는 현지 엔지니어 부족에 대해, 각사의 시스템 언어가 아니라 일반의 프로그래밍 언어를 이용한 효율적인 교육도 기대할 수 있다.

이와 같은 사고에서 산업용 로봇의 오픈소스 컨트롤러의 개발이 시작됐다. 오픈소스 로봇 컨트롤러에서는 궤도 보간을 담당하는 모션 컨트롤러와 서보 루프를 주로 하는 하위 컨트롤러와 궤도의 생성, 유저 인터페이스, 프로그래밍을 관리하는 상위의 컨트롤러로 나누어 생각, 상위측을 ROS로 관리하고 하위측은 산업용 로봇의 기존 컨트롤러를 활용하는 방침으로 하고 있다.

그림 2. DENSO WAVE 로봇용 오픈소스 컨트롤러의 시스템 구성도

그림 2에 개발한 산업용 ROS 시스템 구성도를 나타내고 있다. 로봇으로는 DENSO WAVE사제의 VS-060을 이용하고 있으며, 하위 컨트롤러는 RC-8 로봇 컨트롤러가 담당, 상위층을 산업용 ROS 오픈소스 로봇 컨트롤러가 담당하고 있다. 양자의 사이는 1G 이더넷에 의해 접속되어 있으며, 통신에는 ORiN2/b-CAP을 이용하고 있다.

이 구성에 의해 지령축 속도, 위치 지령값, 손끝 속도, 손끝 위치, 자세의 각종 제한이 하위 컨트롤러로 산업용 로봇 기준으로 확보되고, 또한 안전 정지계의 하드웨어 신호는 양 컨트롤러로 공유되어 있으며, 이것에 의해 오픈소스 컨트롤러측이 이상한 지령을 생성해도 이상 동작이 되지 않게 되어 있다.

ROS와 브리지

1. OpenRTM-ROS 상호 운용

다른 미들웨어 간의 상호 운용을 확보하는 브리지 기술의 연구 개발 예로서 OpenRTM-ROS 상호 운용 프로젝트가 있다. 이것은 2007년도부터 5년간 실시한 ‘차세대 로봇 지능화 기술 개발 프로젝트’의 실시 기간 중에 세계적으로 ROS가 급격하게 발전했기 때문에 지능화 프로젝트에서 채용하고 있는 OpenRTM 미들웨어와 ROS 간의 연계에 관한 연구와 실제 운용 시스템 개발을 갑작스럽게 프로젝트 리더로부터 의뢰받아 최종 연도에 실시하게 된 것이다.

여기에서는 2가지 관점에서 상호 운용을 실현하고 있다. 하나는 ROS 툴을 OpenRTM에서 활용하는 것이고, 또 다른 하나는 ROS와 OpenRTM의 자동 브리지 기술이다.

(1) ROS 개발 환경에 대한 OpenRTM의 편입

ROS 소프트웨어를 개발할 때는 워크 스페이스나 패키지의 매니페스트 파일(package.xml)이라고 하는 디렉토리 구성의 룰을 따라 소스 코드를 배치함으로써 catkin_make라고 하는 커멘드 하나로 모든 소프트웨어 모듈군이, 각 컴포넌트가 이용하는 인터페이스 정의 파일의 실장 언어에 대한 컴파일이나 생성된 파일에 대한 패스 설정과 링크도 포함해 소프트웨어 모듈 간의 의존 관계에 따라 순서대로 컴파일되는 구조로 되어 있다. 

또한, ROS 소프트웨어를 실행할 때에는 roslaunch라고 하는 복수 프로그램 컴포넌트의 실행이나 파라미터 설정을 관리하는 디플로이 툴을 이용한다. 이들의 ROS 툴군은 개발의 압도적인 효율화를 실현하고 있으며, OpenRTM 모듈의 개발에서도 동일한 기능을 이용할 수 있게 했다.

구체적으로 OpenRTM의 CORBA IDL 파일의 컴파일이나 링크도 catkin_make 중에서 할 수 있게 하는 동시에, roslaunch에 대해 rtconnect, rtactivate라는 새로운 태그를 도입, OpenRTM 컴포넌트의 상태 천이, 데이터 포트 및 서비스 포트의 접속을 할 수 있게 확장했다.

(2) OpenRTM-ROS 자동 변환 기술

앞에서 소개한 ROS 개발 환경에 대한 OpenRTM의 도입은 OpenRTM 개발자·이용자가 ROS의 편리한 개발 툴군을 사용할 수 있게 하는 것이었다. 더구나 OpenRTM 컴포넌트가 그 입출력 인터페이스를 ROS로 변환해 제공하고 OpenRTM-ROS 브리지 프로그램이 존재할 수 있으면 ROS 유저가 보통의 ROS 프로그램의 취급과 동일하게 OpenRTM의 기능을 활용할 수 있게 된다. 특히 이 브리지 프로그램을 자동으로 생성할 수 있으면, 기존 OpenRTM 컴포넌트 프로그램의 사양에 변경이 있어도 ROS 측에서 명시적으로 대응할 필요가 없어 계속적으로 브리지를 이용할 수 있게 된다.

이와 같은 인터페이스의 자동 변환에 의한 상호 운용 실행에는 실행하고 있는 프로그램의 입출력을 조사, 이것에 대응한 인터페이스 정의 파일과 프로그램을 생성하는 온라인 변환 방식과 인터페이스 정의 파일의 해석으로부터 대응하는 프로그램을 생성하는 오프라인의 변환 방식을 생각할 수 있다.

OpenRTM의 컴포넌트 프로그램의 경우에는 컴포넌트에 대응한 인터페이스 정의 파일을 해석함으로써 그 컴포넌트가 어떠한 서비스 포트를 제공하는지 알 수 있기 때문에 OpenRTM의 컴포넌트 프로그램에서 OpenRTM-ROS 브리지 프로그램을 생성하는 경우에는 온라인 변환 방식이 적절하다고 할 수 있다.

그림 3. OpenRTM 컴포넌트에서 ROS 노드의 자동 생성. 왼쪽 그림은 OpenRTM에 의한 휴머노이드 시뮬레이터(hrpsys)이고,

오른쪽 그림은 거기서 가동하고 있는 OpenRTM 컴포넌트의 입출력 인터페이스 정의 파일에서 자동 생성한 ROS 노드를 나타

내고 있으며, ROS 서비스 포트를 제공하고 있다. 즉, ROS 유저는 ROS 서비스를 호출함으로써 OpenRTM의 휴머노이드 

시뮬레이션 기능을 이용할 수 있게 되어 있다.

그림 3에 나타낸 OpenRTM 휴머노이드 로봇 시뮬레이터(hrpsys)의 예에서는 인터페이스 정의 파일인 CORBA IDL 파일을 해석하고, 거기에서 대응한 ROS의 msg/srv 파일을 생성, 또한 브리지 컴포넌트 프로그램의 소스 코드를 생성해 상호 운용 브리지 컴포넌트 프로그램을 생성하고 있다. 상호 운용 브리지 컴포넌트 프로그램은 OpenRTM 컴포넌트와 함께 ROS 노드로서도 존재하고, 휴머노이드 로봇 시뮬레이션이 제공하는 전 서비스 포트에 대응하는 ROS 서비스 포트를 제공하고 있으며, ROS 유저는 OpenRTM에 관한 지식이 없어도 ROS 프로그램과 같이 휴머노이드 시뮬레이터를 활용할 수 있다.

또한 지금까지 소개한 상호 운용 툴은 모두 http://github.com/start-jsk/rtmros_common에 공개되어 있으므로 꼭 활용하기 바란다.

그림 4. OpenRTM-ROS 브리지를 이용한 산업용 쌍완 로봇 Nextage OPEN

(3) OpenRTM-ROS 브리지 응용 예

OpenRTM-ROS 브리지 기술은 필자의 연구실에서 이용하고 있는 등신대 휴머노이드 로봇의 기반 시스템으로서 활용되고 있을 뿐 아니라, 산업용 쌍완 로봇인 Nextage의 오픈판에서도 동일한 시스템이 채용되어 있으며, 오래된 기술에 의한 로봇 제어 컨트롤러와 ROS의 브리지에 의해 오픈 시스템을 제공하려고 하는 이 구성의 유효성을 나타내고 있다.

ROS2의 상황

ROS2는 2014년경부터 기획되어 2015년에 알파판, 2016년에 베타판이 공개되고, 2017년부터 정식판이 출시되기 시작했다. ROS2는 기존 ROS(이하 편의적으로 ‘ROS1’이라고 부른다)와는 호환성이 없고 전혀 새로운 시스템으로서 풀 스크래치로 개발이 이루어진 것이며, 주로 연구자나 개발자를 대상으로 프로그래머가 선호하는 자유도가 높은 구조를 제공하는 것에 주안점을 둔 ROS1에 비해, 산업용 로봇이나 실제 사회 전개의 면을 강하게 의식해 PC 워크스테이션이 아니라 임베디드 환경의 대응, Linux뿐만 아니라 Windows나 Mac 등의 멀티 플랫폼 대응, 안정된 네트워크 환경뿐만 아니라 옥외나 저품질의 통신 상황 운용이나 QoS(Quality of Service) 통신, 시큐어 리얼타임 통신 등 노드의 라이프사이클 관리, 단일 장해점이 되는 네임 서버(roscore)를 필요로 하지 않는 노드 간의 상호 발견 등이 특징으로 되어 있다.

한편으로 앞에서 소개한 브리지 기술이라는 관점에서는 ROS2는 ‘DDS-ROS2 브리지’와 ‘ROS1-ROS2 브리지’의 2가지 브리지 기술에 지지되고 있다고 할 수 있다.

그림 5. ROS2 아키텍처

1. DDS-ROS2 브리지

ROS2의 최대 특징은 그 미들웨어 기술로서 DDS(Data Distribution Service)를 채용하고 있다는 점에 있다. DDS는 CORBA에서도 이용되고 있는 IDL(Interface Description Language)에 기초한 출판 구독형의 미들웨어 사양으로, CORBA, SysML, UML 등을 정의한 OMG(Object Management Group)에 의해 사양이 정의되고 있다. 또한 DDS-RPC라고 불리는 원격 함수 호출 인터페이스도 베타판이면서 사양에 포함되어 있다.

ROS2의 새로운 특징으로서 선전되고 있는 임베디드, QoS 통신, 시큐어 통신, 리얼타임성, 노드 간의 상호 발견 등은 다름 아닌 DDS의 특징 그 자체이다. 반대로 보면, ROS2는 DDS 시스템에 대해 ROS 라이크한 프로그래밍을 가능하게 하려고 한다고 볼 수도 있다. 이 점에 대해서는 나중에 의논하려고 한다.

그림 5에 ROS2의 통신 아키텍처를 나타내고 있다. ROS2의 미들웨어는 DDS의 실장(여기에서는 Fast RTPS가 예로 되어 있는데, RTI Connext나 Opensplice도 이용 가능) 위에 rmw(ROS middleware Interface)라고 불리는 인터페이스를 준비하고 있다. 이것은 DDS 벤더에 의존하지 않고, 출판 구독이나 원격 함수 호출의 인터페이스를 제공하는 것이다. 또한, 그 위에 rcl(ROS client library)라고 불리는 C의 라이브러리가 존재, 이것이 통신계에 더해져 이름 공간, 시간, 로깅 등 ROS의 기본 기능을 제공하고 있다. 실제로 유저가 이용하는 rclcpp, rclpy, rcljava 등의 각각 C＋＋, Python, Java 언어의 ROS2 클라이언트 라이브러리는 rcl 위에 구축되어 있다.

또한, 통신면에서는 ROS1과 동일한 사양의 msg/srv 파일을 이용하는데, 내부에서는 이것이 DDS IDL 파일로 변환되고 ID1 컴파일러를 통해 DDS의 통신용 클래스가 생성되어 DDS 통신으로 이용되고 있다. 

앞에서 소개한 OpenRTM-ROS 통합 운용 시스템에서는 OpenRTM-ROS에서 이용하고 있는 CORBA IDL 파일에 대응하는 ROS msg/srv 파일을 생성, OpenRTM의 CORBA 통신을 하고 있는 컴포넌트를 ROS 함수 호출을 통해 이용할 수 있게 하고 있었다. 동일하게 생각하면 이 ROS2의 통신 아키텍처는 DDS 애플리케이션에 대한 브리지로서 작용, 기존의 DDS 애플리케이션에 대한 ROS2의 클라이언트 라이브러리 경유로 이용할 수 있게 되어 있다고 할 수 있다.

실제로 DDS가 미국국방성(DoD)나 미국항공우주국(NASA)에서 채용되거나 조달 규격에 편입되는 등의 실적이 있으며, 이들 기관이 ROS2 개발의 최대 스폰서인 것을 생각하면 ROS2에는 DDS로 제어되고 있는 기기에 대한 브리지로서의 측면이 있다고 개인적으로는 생각하고 있다.

2. ROS1-ROS2 브리지

ROS2에서는 또한 ROS1과의 상호 통신이 가능한 브리지 기능을 제공하고 있다. 이것에 의해 ROS1과 ROS2의 혼재 환경에서 운용이 가능하고, 예를 들면 임베디드 등에 강한 ROS2로 로봇의 제어 시스템을 구축하고 이것에 대해 지능 모듈, 시각화, 분석 등의 각종 툴이 충실한 ROS1으로 개발을 계속하는 것이 가능해진다. 혹은 이미 ROS2로 개발을 추진하고 있는 경우에는 ROS1으로만 제공되고 있는 로봇이나 디바이스도 임베디드해서 이용할 수 있다.

구체적인 사용법은 roscore을 미리 기동한 상태에서 터미널 상에서

$ source /opt/ros/kinetic/setup.bash

$ source /opt/ros/ardent/setup.bash 

$ ros2 run ros1_bridge dynamic_bridge 

와 같이 ROS1과 ROS2의 양쪽 환경을 세트해 ROS2의 ros1_bridge로 제공되고 있는 ROS1-ROS2 브리지 프로그램인 dynamic_bridge를 기동할 수 있으면, 다음은 ROS1의 출판 노드로서 터미널 상에서

$ source /opt/ros/kinetic/setup.bash 

$ rosrun rospy_tutorials talker

ROS2의 구독 노드로서 다른 터미널 상에서

$ source /opt/ros/ardent/setup.bash 

$ ros2 run demo_nodes_cpp listener 

로 하여, 각각을 기동할 수 있으면 상호 통신할 수 있다는 것을 확인할 수 있다.

이것은 앞에서 나온 실행 중인 프로그램의 입출력을 조사해 이것에 대응한 인터페이스를 갖는 프로그램을 동적으로 제공하는 온라인 변환 방식과 인터페이스 정의 파일의 해석으로부터 대응하는 프로그램 소스 파일을 생성, 이것을 실행함으로써 인터페이스를 제공하는 오프라인 변환 방식으로 분류하면, 온라인형으로 되어 있다. 그러나 브리지에서 이용하는 메시지에 관해서는 사전에 ROS1, ROS2 양쪽에서 사용할 수 있게 해 놓을 필요가 있다.

맺음말

이 글에서는 브리지 기술을 시작으로 ROS1 및 ROS2를 살펴보았다. 실제 로봇 시스템 중에서는 제어 분야는 안전성이나 성능에 직결되는 부분으로 가장 변경/갱신이 어려운 분야라고 생각된다. 이러한 가운데 기존의 시스템을 활용하면서 ROS와 같은 오픈소스의 유연한 시스템과 연계하려고 하는 사고는 자연스럽게 보인다.

실제로 앞에서 소개한 산업용 수직다관절 로봇은 ORiN2/b-CAP으로 가동하고 있는 기기와 ROS의 브리지 시스템이며, 또한 Open-RTM 베이스의 로봇 컨트롤러(hrpsys)와 ROS의 브리지 시스템을 채용한 산업용 쌍완 휴머노이드를 소개했다. 그리고 ROS2를 DDS로 가동하고 있는 기기와 ROS의 브리지 시스템으로서 파악하는 견해를 나타냈다.

지금까지 여러 가지 미들웨어 기술과 시스템 인티그레이션에 대해 해설했는데, 이러한 해설 기사에서도 볼 수 있듯이 단일 미들웨어 기술이나 개발 환경에서 전부를 커버하는 것은 특히 ‘통합의 과학’이라고 불리며 폭넓은 시스템이 필요한 로봇 분야에서는 어렵다. 그러한 의미에서 브리지 기술의 이해와 활용은 앞으로 점점 더 중요해질 것으로 생각하고 있다.

또한, 이 글에서는 미들웨어 기술이라는 소프트웨어 분야에 주목하고 있지만, ROS의 발전에서 배울 수 있는 것은 미들웨어 기술과 동등 혹은 그 이상으로 그 주변의 이활용을 쉽게 하는 툴군, 더 나가서는 그것을 사용하거나 혹은 앞으로 사용하려고 하는 사람들을 받아들이는 유저 그룹이 매우 중요한 것을 알 수 있다.

이 글을 읽고 미들웨어 기술에 흥미를 갖게 된 분들은 꼭 한걸음 더 나아가 커뮤니티의 형성에도 참여 혹은 지원을 하길 바란다.

岡田 慧, 도쿄대학 대학원 정보이공학계연구과