ROS 배포와 운영의 실제
ROS(Robot Operating System)를 공부하면서 처음엔 ‘이론’이 전부인 줄 알았다.
노드, 메시지, 토픽 — 문서 위에 그려진 깔끔한 다이어그램들.
하지만 실제 로봇을 움직이는 일은, 책상 위에 그린 것과는 전혀 달랐다.
로봇은 살아 움직이는 시스템이다.
ROS를 ‘어디에’, ‘어떻게’ 심어야 하는지가 진짜 시작이었다.
대부분의 로봇은
Onboard Computer(로봇 안에 들어가는 PC)
Controller Board(모터 제어나 센서 신호를 담당하는 보드)
로 구성된다.
여기에 ROS를 설치할 PC를 고르고, 리눅스 환경을 세팅하는 것부터 시작한다.
(ROS는 기본적으로 Ubuntu 기반에서 작동한다.)
느낀 점
"로봇이 움직이기 전에, 이미 하드웨어 구조와 OS가 깔끔히 정리돼야 한다."
ROS는 하나의 거대한 생태계다.
기본 패키지를 설치하고, 로봇에 맞는 커스텀 노드(프로그램)를 개발하거나 연결한다.
모터 제어 노드
카메라 입력 노드
경로 탐색 노드
사용자 입력 노드
이 각각의 기능들이 모여 하나의 '로봇'이 된다.
기획자 관점 포인트
"로봇의 모든 기능은 독립된 서비스처럼 관리된다. 기능별 분리 사고가 중요하다."
ROS에서는 여러 개의 노드를 한 번에 띄우기 위해
launch 파일이라는 걸 만든다.
"전원 켜자마자 이 노드들 실행해 줘"
"시뮬레이터는 옵션에 따라 켜고 끄게 해 줘"
이런 걸 설정해 두는 스크립트다.
→ 즉, 기획자가 서비스 흐름을 짤 때 '어떤 기능이 함께 움직여야 하는가'를 명확히 정의해야 한다.
개발이 끝나면 ROS 패키지를 빌드하고, 로봇의 온보드 컴퓨터로 배포한다.
(ssh 원격 접속을 쓰기도 하고, 직접 USB로 옮기기도 한다.)
로봇 부팅 시 자동으로 launch 파일을 실행시키거나, 터미널 명령어로 직접 올릴 수도 있다.
느낀 점
"로봇은 소프트웨어처럼 '버전 관리'가 필수다. 하나라도 틀어지면 바로 움직임에 문제가 생긴다."
로봇이 세상에 나가면, 계속 운영이 필요하다.
네트워크 끊김
센서 오류
토픽 충돌
예상치 못한 하드웨어 다운
이런 이슈가 언제든 터진다.
그래서 운영팀은 주기적으로 로봇의 ROS 노드 상태를 모니터링하고, 필요하면 바로 리부팅하거나 리커버리 스크립트를 실행한다.
기획자가 알아야 할 운영 포인트
데이터 흐름을 시각화하고,
장애 케이스를 예상하고,
복구 시나리오를 설계해야 한다.
처음엔 단순했다.
"버튼을 누르면, 로봇이 손을 흔들게 해 주세요."
하지만 실제로는,
ROS가 어디 깔리고
어떤 노드들이 연결되고
어떤 데이터가 오가고
어디서 장애가 나고
어떻게 복구할 것인가
이 모든 걸 설계하고 운영하는 일이었다.
기획자는 결국,
"로봇이 진짜 세상에서 움직이게 만드는 사람"이어야 한다.
나는 아직 배워야 할 게 많다.
하지만 적어도, 이제 로봇을 ‘기획서 속 캐릭터’가 아니라 ‘운영해야 할 시스템’으로 볼 수 있게 됐다.
로봇 메시지 설계의 흐름 (서비스 기획자가 직접 설계하는 데이터 모델)