휴머노이드, 피지컬 AI 개발시 좌표계와 통신 설정, 운영 관측 체계가 정리되지 않으면 기능 구현과 별개로 시스템 통합이 지연될 수 있어 ROS 통합시 ‘운영 기준’ 점검이 요구되고 있다.

피지컬 AI 전문가들에 따르면 휴머노이드, 피지컬 AI가 센서, AI, 제어 소프트웨어를 동시에 구동하는 구조인 만큼, ROS 2 설정의 일관성이 중요하다고 조언했다.

피지컬 AI와 휴머노이드는 ‘센서로 보고(감지) → 생각하고(AI) → 몸을 움직이는(제어)’ 과정을 수십 개 프로그램이 동시에 맞물려 돌려야 한다.

이때 개발자들이 자주 쓰는 로봇 운영체제가 ROS 2다. 하지만 “설치만 하면 되겠지”라고 접근했다가 통합 단계에서 시간을 크게 잃는 경우가 많다.

첫 번째 함정은 좌표계(프레임)와 시간(타임스탬프)이다.

로봇은 몸통(`base_link`)·주행 기준(`odom`)·지도 기준(`map`) 등 여러 기준점을 쓰는데, 이름과 의미가 제각각이면 센서 데이터가 ‘어느 방향을 보고 있는지’부터 어긋난다.

ROS의 좌표 프레임 규약(REP-105)은 `base_link`, `odom`, `map` 같은 프레임의 의미를 정해 소프트웨어 재사용을 돕는다고 설명한다.

두 번째는 통신 품질(QoS) 설정이다.

ROS 2는 주로 DDS 기반 미들웨어를 통해 통신하며, QoS는 신뢰성, 지속성, 히스토리, 데드라인 등 여러 정책을 조합해 통신 특성을 정한다.

공식 문서는 QoS 정책을 조합해 프로필을 만들고, 센서 데이터처럼 흔한 용도를 위한 미리 정의된 프로필도 제공한다고 밝힌다.

문제는 발행자와 구독자의 QoS가 다르면 호환되지 않아 메시지가 아예 전달되지 않을 수 있다는 점이다.

현장에서는 토픽 미수신 원인 중 하나로 QoS 불일치가 자주 지목된다.

세 번째는 한 번에 실행·설정하는 ‘런치(launch)’의 부재다.

ROS 2 런치 파일은 여러 노드를 동시에 띄우고, 파라미터·YAML·리맵·네임스페이스 같은 설정을 한 곳에서 관리하도록 돕는다.

휴머노이드는 센서, 상태추정, 제어, 로깅이 동시에 올라가야 하므로, “노드를 하나씩 수동 실행”하는 방식은 곧 운영 리스크로 돌아온다.

네 번째는 로그와 관측(Observability) 이다.

ROS 2 로깅은 기본적으로 콘솔(stderr), 디스크 로그 파일, 그리고 `/rosout` 토픽으로 나가도록 설계돼 있다.

하드웨어가 간헐적으로 끊기거나 온도·전압이 흔들릴 때, 이 기록이 없으면 “가끔 안 된다”는 말만 남고 원인 분석은 멈춘다.

다섯 번째는 진단(/diagnostics) 체계 미비다.

`diagnostic_updater`는 장치 드라이버에서 센서 토픽 상태나 장치 상태를 추적하는 데 흔히 쓰이며, 센서 토픽 상태 발행, 장치 닫힘 보고, 온도 같은 값이 범위를 벗어날 때 오류 보고 등을 예로 든다.

또 ROS 진단 시스템은 `/diagnostics` 토픽을 중심으로 정보를 모아 운영자가 상태를 볼 수 있도록 구성된다고 안내한다.

즉, “데이터가 나오긴 한다”를 넘어 “정상인지, 위험 신호인지”를 기계가 말하게 해야 실전에서 버틴다.

마지막은 데이터 기록 포맷과 재현성이다.

피지컬 AI는 학습·검증을 위해 “그때 로봇이 무엇을 봤고(센서), 무엇을 했고(명령), 어떤 상태였는지”를 다시 꺼내 볼 수 있어야 한다.

ROS 2는 rosbag2_storage_mcap 플러그인을 통해 MCAP 형식의 기록·재생·정보 조회를 지원하며, -s mcap 옵션으로 저장 형식을 지정할 수 있다. 또한 --storage-config-file을 사용하면 MCAP 작성 옵션을 YAML 파일로 설정할 수 있다.

기록이 없다면 학습은 데이터 부족에, 디버깅은 재현 불가에 막힌다.

전문가들은 “휴머노이드의 난이도는 AI 모델만이 아니라, 센서·제어·운영이 같은 규약으로 맞물리는 데서 갈린다”고 말한다.

센서 업체가 드라이버뿐 아니라 프레임·QoS·런치·진단·기록 가이드를 함께 제공하면, 개발자는 ‘연결 문제’보다 ‘지능과 동작’에 더 많은 시간을 쓸 수 있다.