Robot Operating System 혹은 ROS라고 부르는 로봇 시스템 개발 툴은 로봇 연구을 위한 시스템 개발에 있어서 빠질 수 없는 필수 도구로 자리 잡았습니다. 2007년 처음 등장한 이후로, 다양한 로봇 개발자들 사이에서 급격히 확산되었으며, 전 세계의 수많은 로봇 연구자들이 이를 활용하고 있습니다. 특히 오픈 소스 플랫폼으로서 커뮤니티를 활용한 수많은 정보와 리소스 공유를 기반으로 사용자를 지속적으로 늘리고 있습니다. 간혹 Robotics Operating System으로 표기하는 경우도 있으나, 정확히는 Robot Operating System이 맞습니다.
ROS가 인기 있는 이유는 다양한 장점 덕분입니다. 로봇 시스템에서 필수적인 여러 프로그램간 통신을 쉽게 할 수 있게 구성되어 있으며, 모듈화도 잘 되어있어 이미 만들어져 공유되어 있는 프로그램 및 라이브러리를 사용하기 편합니다. 이러한 이유로 로봇 연구자들뿐만 아니라 산업 분야에서도 주목받고 있으며, 앞으로도 그 활용 범위는 더욱 넓어질 것으로 기대됩니다. 다만, 연구분야가 아닌 로봇을 이용한 산업에서는 연구분야에서 만큼의 사용량을 확보하지 못하고 있습니다. 이는 연구를 위한 개발에 초점이 맞춰진 시스템의 특성으로 부터 가지게 되는 한계가 있기 때문입니다.
이번 포스팅에서는 ROS의 기본 개념부터 실제 적용 사례까지 알아보고, 로봇 연구에 어떤 식으로 기여할 수 있는지 자세히 설명드리겠습니다.
참고로, 맥북에서 ROS를 완전히 활용할 수 있는 방법에 대해 공유한 포스팅이 있으니, 맥북을 이용하시는 분들께서는 참고하시면 도움이 될 것 같습니다.
Table of Contents
Robot Operating System의 등장
ROS(Robot Operating System)는 2007년 미국의 스탠포드 대학교 인공지능 연구실(Stanford Artificial Intelligence Laboratory)에서 시작된 프로젝트입니다. 이 프로젝트는 로봇 개발자들이 복잡한 로봇 시스템을 쉽게 개발하고 연구할 수 있도록 돕기 위해 탄생했습니다. 이후, 2013년에는 Willow Garage, 한때 로봇 소프트웨어와 하드웨어 개발의 중심이었던 연구소가 본격적으로 ROS의 개발과 확산에 기여하면서 더욱 발전하게 되었습니다.
ROS가 등장하게 된 배경은 주로 로봇 연구와 개발 과정에서의 복잡성과 비효율성 문제 때문입니다. 로봇 연구자들은 로봇의 하드웨어 제어, 센서 통합, 알고리즘 개발 등 복잡한 작업을 일일이 처음부터 구현해야 했으며, 각 연구마다 다른 하드웨어와 소프트웨어를 사용하기 때문에 재사용과 협업이 어려웠습니다. 이러한 문제를 해결하고, 로봇 개발의 진입 장벽을 낮추기 위해 표준화된 플랫폼이 필요하다는 요구가 커졌습니다.
결국, 로봇 연구와 개발을 위한 표준 플랫폼으로 자리 잡았으며, 로봇 개발의 복잡성을 크게 줄이고, 연구 간의 협업을 촉진하는 중요한 역할을 하게 되었습니다. Willow Garage가 주도한 이후, 현재는 Open Robotics라는 기관이 개발과 유지보수를 담당하고 있으며, 학계뿐만 아니라 산업 현장에서도 간혹이나마 사용되고 있습니다.
Robot Operating System: ROS 이전과 이후
로봇 시스템은 여러 기능이 복합적으로 함께 동작해야 하는 시스템인 만큼 개발 내용이 비교적으로 복잡합니다. 센서나 모터를 이용하는 프로그램이 각각 필요하고, 이 프로그램들 사이 정보교환도 효율적으로 이루어지도록 개발이 되어야 실시간성을 확보할 수 있습니다. 이는 자율주행이나 이족보행 등 빠른 정보처리가 이루어져야 하는 시스템에서는 매우 중요한 부분입니다.
ROS 이전의 개발 방식
실험을 위한 시스템을 구축하기 위해서는 연구자가 각 하드웨어의 사용법을 배우며 프로그램을 구현해야 하는 경우가 많았습니다. 그나마 센서 등 하드웨어 제조사에서 어느정도의 리소스를 제공하면 조금은 덜 오래걸릴 수는 있겠지만, 여러 다른 시스템을 통합해야 하는 로봇 시스템의 특성상 연구자들이 시스템 구현에도 상당한 시간을 들여야 했습니다. 자금적인 여유가 있다면 어느정도 아웃소싱을 할 수도 있겠지만, 그렇지 못한 많은 학교 연구실에서는 고스란히 대학원생의 일이 되곤 했습니다.
각 하드웨어 제조사 마다 다른 시스템을 통합하는 과정이 이를 구현하는 주체마다 다르다 보니 다른 연구단체에서 구현한 방식과 차이가 커서 코드를 공개했음에도 이를 이용하기가 어려운 경우도 상당히 많았습니다. 다른 연구자들의 연구내용을 파악하고 비교하는 것이 중요한 연구분야에서는 복병이라고 해도 과언이 아닙니다. 즉, 로봇 시스템 개발에 ‘표준화’가 제대로 자리잡지 못하여 발생되는 비효율적인 개발이 많았고, 이를 해결하기 위한 노력 중 하나가 ROS의 배포라고 볼 수 있겠습니다.
ROS 이후의 개발 방식
ROS가 배포되고 커뮤니티가 생성되면서 많은 개발과정이 단소화 될 수 있었습니다. 가장 큰 장점으로, 여러 프로그램 간 유기적인 연결이 매우 간단해질 수 있었습니다. 이전에는 네트워크에 대해 어느정도 잘 알고 있는 연구자들만 개발할 수 있었던 여러 통신 기법이 쉽게 사용할 수 있도록 준비가 되어있습니다. 대표적으로 Broadcasing 방식의 통신과 Remote Procedure Call 방식의 통신인데, 이는 아래에서 더 설명해 보도록 하겠습니다. 이 두 방식은 모두 로봇 시스템에서 용도에 따라 유용하게 사용될 수 있는 통신기능인데, ROS는 이를 쉽게 이용할 수 있도록 설계되었습니다.
다른 하나는 데이터의 표준화가 주는 편리함으로 부터 나오는 개발 효율의 상승이 있습니다. 동일한 형태의 센서라고 해도 구체적인 데이터 구조가 조금이라도 다르면 프로그램을 바로 대체할 수 없는 불편함이 있었는데, 데이터 형식의 표준을 제시하고 이를 사용하도록 유도하면서 ROS 생태계 안에서의 다른 프로그램 사용이 매우 용이해졌습니다. 또, 다른 연구팀에서 개발한 프로그램을 이용할 때는 매번 데이터 구조에 대해 이해하는 과정이 필요했는데, 표준 형식을 사용하면 이를 건너뛸 수 있는 장점도 있습니다.
여러 편의성으로 로봇 연구 커뮤니티에서 ROS를 사용하는 경우가 크게 늘어났으며, 이용자가 많아지며 그만큼 공유되는 리소스도 많아 그 장점이 점점 더 커지는 양상으로 조금씩 발전하는 중 입니다.
Robot Operating System: ROS는 왜 좋은가
ROS를 사용하면 여러 장점이 있는데, 그 중에서 프로그램간 통신, 조금 더 정확하게는 Inter-Process Communication(IPC)의 쉬운 구현 그리고 데이터의 표준화에 있습니다.
프로세스간 통신의 편리함 (IPC)
ROS는 각 프로그램을 노드(Node)라는 개념으로 추상화하고, 각 노드간 통신을 쉽게 할 수 있도록 구성되어 있습니다. 통신 방식은 크게 3가지로 나뉘는데, 그 중 두가지에 대해 적어보겠습니다.
1. Broadcasting 방식 (Topic 기반 통신)
Broadcasting 방식은 One-to-Many 통신을 지원하는 비동기적 데이터 송수신 방식입니다. ROS에서는 토픽(Topic)을 통해 Broadcasting 방식이 구현됩니다.
특징
- One-to-Many 통신: 하나의 노드가 메시지를 발행(Publish)하고, 여러 노드가 해당 메시지를 구독(Subscribe)할 수 있는 구조입니다. 예를 들어, 로봇의 센서 데이터(카메라, 라이다 등)를 발행하면, 이를 구독하는 여러 노드들이 센서 데이터를 받아서 사용할 수 있습니다.
- 비동기적 통신: 메시지가 발행되면, 구독하는 노드들은 실시간으로 해당 메시지를 비동기적으로 수신합니다. 즉, 발행한 노드는 구독자들이 언제, 얼마나 있는지에 관계없이 메시지를 발행할 수 있고, 구독 노드도 필요할 때마다 데이터를 비동기적으로 처리할 수 있습니다.
- 주기적 또는 이벤트 기반: 데이터가 주기적으로 업데이트되거나, 특정 이벤트가 발생했을 때 메시지를 발행하는 구조로 사용할 수 있습니다. 센서 데이터와 같이 지속적으로 변하는 정보를 주기적으로 발행하거나, 특정 트리거 이벤트에 따라 메시지를 발행하는 상황에 적합합니다.
- 확장성: Broadcasting 방식은 여러 노드가 자유롭게 통신할 수 있는 구조를 가지고 있어 시스템 확장이 용이합니다. 여러 노드가 하나의 데이터를 공유하거나 처리하는 시스템에서 특히 유리합니다.
예시
- 로봇의 카메라 센서가 이미지를 토픽으로 발행하면, 이를 구독하는 노드가 이미지 처리, 객체 인식, 경로 계획 등을 수행할 수 있습니다.
- 여러 로봇이 공동 작업을 수행하는 경우, 각 로봇이 위치 정보를 발행하고 다른 로봇들이 이를 구독해 협업할 수 있습니다.
장점
- 비동기적이고 다대다 통신을 지원하므로 시스템 확장과 복잡한 통신 구조에서 유리합니다.
- 데이터 송수신에 실시간성이 요구되는 센서 데이터, 상태 정보 등을 주고받는 데 적합합니다.
단점
- 발행한 데이터에 대한 응답이나 확인 과정이 없습니다. 노드가 데이터를 발행하면 끝이며, 구독자가 그 데이터를 어떻게 처리하는지는 알 수 없습니다.
- 요청-응답 관계가 필요한 경우 적합하지 않습니다.
2. Service 방식 (Request-Response 통신)
Service 방식은 One-to-One 동기적 통신을 제공하는 요청-응답 기반의 통신 방식입니다. ROS에서 Service는 클라이언트와 서버 간의 동기적 요청과 응답을 처리하는 구조입니다.
특징
- 일대일 통신: 클라이언트가 서버에게 요청(Request)을 보내고, 서버는 요청을 처리한 후 응답(Response)을 반환하는 방식입니다. 요청을 보낸 클라이언트는 서버의 응답을 받을 때까지 대기합니다.
- 동기적 통신: 클라이언트는 요청을 보낸 후 서버가 응답을 반환할 때까지 기다립니다. 이는 동기적 통신 방식이기 때문에, 클라이언트가 응답을 받기 전까지 다른 작업을 수행할 수 없습니다.
- 일회성 작업: Service 방식은 주로 특정 작업을 처리하거나 계산을 요청할 때 사용됩니다. 반복적이거나 지속적으로 데이터를 주고받기보다는, 필요한 순간에만 요청을 보내고 결과를 받는 방식입니다. 예를 들어, 로봇이 특정 위치로 이동하라는 명령을 서버에 보내면, 서버가 해당 명령을 처리하고 완료되었을 때 응답을 보냅니다.
예시
- 로봇이 목표 지점까지 경로를 계획해야 하는 상황에서, 클라이언트가 목표 좌표를 서버에 요청하고, 서버는 경로 계산을 완료한 후 클라이언트에게 응답을 보냅니다.
- 특정 센서나 로봇 상태를 단일 요청으로 확인하거나, 모터를 한번 제어하는 등의 일회성 작업에 적합합니다.
장점
- 확실한 응답: 요청에 대한 응답을 받을 수 있으므로, 클라이언트가 요청이 성공적으로 처리되었는지 확인할 수 있습니다.
- 간단한 일대일 통신: 단일 요청과 단일 응답으로 이루어지는 간단한 작업을 처리하는 데 적합합니다.
단점
- 확장성 부족: Service 방식은 일대일 통신만 지원하므로, 여러 노드가 동시에 데이터를 주고받아야 하는 상황에서는 적합하지 않습니다.
- 비동기적 작업에 부적합: 클라이언트가 응답을 받을 때까지 대기하기 때문에, 실시간 응답이 요구되지 않거나 비동기적 처리가 필요한 경우에는 사용하기 어렵습니다.
표준화 관점에서의 장점
ROS는 로봇 연구 및 개발에서 표준화된 개발 환경을 제공하며, 이는 여러 공개된 리소스를 이용하여 새로운 프로그램을 개발하는 단계에서 상당히 유용하게 이용될 수 있습니다.
- 모듈화된 표준 인터페이스: 센서, 액추에이터, 제어기, 알고리즘 등 로봇 시스템의 다양한 구성 요소를 다룰 때 표준화된 인터페이스를 제공합니다. 예를 들어, 센서 데이터는 정해진 메시지 형식을 통해 송수신되며, 이를 통해 각기 다른 센서나 하드웨어를 사용하는 경우에도 같은 메시지 형식으로 처리할 수 있습니다. 이러한 표준화는 연구자들이 하드웨어를 교체하거나 다른 시스템에 이식할 때 매우 편리합니다.
- 재사용 가능한 패키지 생태계: 수많은 패키지(Package)를 통해 다양한 로봇 관련 알고리즘과 드라이버들을 표준화된 방식으로 제공합니다. 연구자들은 이미 개발된 패키지를 활용하여 연구를 진행할 수 있으며, 이는 새로운 프로젝트나 연구에 소요되는 시간을 크게 단축시킵니다. 또한, 이러한 패키지들은 ROS 생태계 내에서 표준화된 방식으로 관리되고 있기 때문에 상호 호환성이 높습니다.
- 다양한 하드웨어 플랫폼 지원: 다양한 로봇 하드웨어 플랫폼과의 호환성을 유지하는 표준화된 드라이버를 제공합니다. 이를 통해 연구자들은 특정 하드웨어에 종속되지 않고 여러 하드웨어를 쉽게 교체하거나 추가할 수 있습니다. 이러한 표준화된 하드웨어 지원은 연구자들이 실험 환경을 유연하게 변경하고 다양한 하드웨어 플랫폼을 테스트할 수 있는 이점을 제공합니다.
- 커뮤니티와의 협력 강화: 전 세계 연구자와 개발자들이 표준화된 소프트웨어와 프로토콜을 사용하여 연구 결과를 공유할 수 있도록 돕습니다. 이로 인해 로봇 연구의 성과를 다른 연구자들과 쉽게 교류할 수 있으며, 표준화된 코드와 모듈을 통해 다양한 프로젝트에 빠르게 적용할 수 있습니다.
Robot Operating System: ROS의 한계
여러 장점에도 불구하고 정작 로봇을 이용한 산업에서는 ROS를 이용해 시스템을 구축하는 경우가 그리 많지 않습니다. 여기에는 연구목적 개발을 위해 설계된 오픈소스 프레임워크라는 특징에서 부터 오는 한계가 있습니다.
편의성과 맞바꾼 비효율
프로그램 간 통신이 쉽게 구현되도록 준비된 것은 맞지만, 기술적으로 가장 효과적인 통신 방식은 아닌 경우가 많습니다. 특히, 범용성을 중요시 하는 구조에 초점을 맞춘 만큼 불필요한 Latency로 인한 타이밍 문제가 있을 수 있습니다. 쉽게 사용할 수 있도록 구성하는 과정에서 통신 시스템이 필요 이상으로 무거워진 점이 이유가 되겠습니다.
오픈소스의 부족한 완성도
모든 오픈소스 리소스가 그런 것은 아니지만, 상당히 많은 오픈소스 라이브러리 및 프레임워크는 완성도, 특히 안정성 면에서 부족한 상태로 공개됩니다. 아무래도 많은 자금으로 많은 엔지니어를 투입하여 개발하는 경우가 아니라 어쩔 수 없는 것 같습니다. ROS 자체는 그래도 오픈소스 리소스 중에서는 여러 사람의 손을 거쳐 많이 괜찮아진 편 이긴 하지만, ROS용으로 공개되는 다른 오픈소스 패키지들은 또 다른 경우이기 때문에, 시스템의 안정성을 보장하기 어렵습니다. 여러 오픈소스 패키지를 함께 사용 시 더욱 문제점을 찾고 해결하기 어렵겠습니다. 산업에서는 약간의 오류가 커다란 손실로 이어질 수도 있기 때문에 매우 중요한 부분입니다.
보안 관련 이슈
산업에서 사용되는 대부분의 프로그램 모듈은 상업용이며 오픈소스가 아닌 기밀로 간주되는 경우가 많습니다. 반면, ROS는 가급적 모두가 리소스를 공유하도록 유도하는 방향으로 구현되었기 때문에 지적 재산을 보호하기에는 적합하지 않습니다.
또, 연구용으로 사용되는 것을 가정하는 만큼 해킹과 같은 보안문제에도 전혀 대책이 없기 때문에, 보안이 중요한 산업에서는 ROS의 사용이 불리할 수 있습니다.
개인적인 의견
ROS는 로봇 연구에 큰 기여를 할 만큼 훌륭한 툴이며 저도 저의 연구에 많이 활용하고 있습니다만, 동시에 너무 ROS에만 의존하지 않으려고 노력하고 있습니다. 저의 개발능력이 순전히 ROS에 의존해야만 하는 제약이 생긴다는 관점에서 볼 때, 이를 사용할 수 없는 경우에는 사실상 완전히 무능해지는 것과 같다고 보기 때문인 것도 있고, 시스템을 제대로 이해하지 못하고 툴에만 의존하게 되면 꼭 필요하지 않은 간단한 문제도 굳이 용도에 비해 복잡한 시스템이 됨에도 불구하고 사용할 수 밖에 없어질 수 있기 때문입니다.
ROS가 어떤 프레임워크인지를 이해하고, 내가 풀어내려고 하는 문제에 적합한 툴인지 고민한 후 사용을 결정하는 과정을 거칠 수 있다면 개발자로서는 더 나은 결정과정이 되지 않을까 합니다.
다른 한편으로는 ROS에 사용된 기능들이 어떻게 구현되었는지를 한단계 더 깊게 들여다 볼 수 있는 기회가 있다면 한단계 더 수준높은 개발자로 발전할 수 있는 좋은 기회가 될 수 있다고도 생각합니다. 예를들어, ROS에서 네트워킹에 사용하는 Boost 라이브러리에 대해 이해하면, ROS 없이도 직접 유사한 기능을 목적에 최적화하여 개발할 수 있을 것입니다.
마무리
이번 포스팅에서는 ROS(Robot Operating System)의 장점과 한계를 다양한 측면에서 살펴보았습니다. 로봇 연구를 위한 시스템을 구현하는 단계에서 연구 내용과는 무관하지만 필요에 의해 구현해야만 하는 내용들을 이전보다 쉽고 빠르게 구현하여 연구 내용에 더 집중할 수 있다는 점에서는 매우 훌륭한 툴이지만, 연구목적 외에는 확장에 한계가 있기 때문에 무조건 ROS가 로봇 개발의 답이라고 생각하는 것은 바람직하지 않을 수 있겠습니다.