rosbag2는 timestamp가 붙은 ROS 2 메시지를 저장하고 재생하지만, 기록 성공 표시만으로 데이터 완전성이 보장되지는 않습니다. QoS 호환성, 수신 시각과 메시지 시각, 저장 장치 처리량, 캐시·분할·압축 정책과 재생 clock을 함께 검증해야 같은 실험을 재현할 수 있습니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
rosbag2는 데이터 파일이 아니라 시간순 메시지 기록 체계다
rosbag2는 ROS 2 topic 메시지와 timestamp를 저장해 분석과 재생에 씁니다. 로봇 행동 데이터 글이 학습 기록의 의미를 설명했다면, 이 글은 수집 도구가 메시지를 놓치지 않고 재현 가능한 파일을 만드는 운영 조건에 집중합니다.
명령이 성공하고 폴더가 생겨도 모든 topic이 기대한 비율로 들어갔다고 볼 수 없습니다. 발견 시점, QoS 호환, 직렬화와 캐시, 디스크 처리량, 종료 시 flush와 metadata가 모두 정상이어야 기록이 완결됩니다.
기록 전에 topic 목록·형식·기대 주기를 고정한다
ROS 2 기록·재생 공식 튜토리얼은 topic 선택, 기록, 정보 확인과 재생의 기본 흐름을 제공합니다. 현장에서는 여기에 topic별 메시지 형식, 기대 Hz, 허용 gap과 필수 여부를 수집 명세로 추가해야 합니다.
-a로 모든 topic을 기록하면 편리하지만 숨은 대역폭과 민감 정보, 불필요한 debug topic까지 늘 수 있습니다. 필수·선택·금지 topic을 나누고 동적 topic 발견을 허용할지, 시작 뒤 늦게 나타난 topic을 어떻게 기록할지 정합니다.
QoS 호환성 실패는 파일 안의 조용한 빈칸을 만든다
rosbag2 QoS override 공식 가이드는 기록·재생에서 reliability와 durability 호환을 고려하고 필요하면 YAML override를 지정하는 방법을 설명합니다. 센서 publisher와 recorder가 연결되지 않으면 기록 프로세스는 살아 있어도 메시지가 없습니다.
ROS 2 QoS 선택 기준과 함께 publisher가 실제 제공한 profile, recorder가 선택한 profile, 연결 수와 첫 메시지 시각을 기록합니다. override는 문제를 숨기는 만능 설정이 아니라 해당 topic의 전달 의도에 맞는 계약이어야 합니다.
| 경계 | 확인값 | 실패 신호 |
|---|---|---|
| 발견 | topic·type·publisher 수 | topic 누락·늦은 등장 |
| QoS | reliability·durability | 연결 0·초기 샘플 없음 |
| 저장 | cache·write latency | drop·backlog·파일 지연 |
| 종료 | flush·metadata | 불완전 파일·count 불일치 |
header stamp와 기록 수신 시각을 구분한다
센서 메시지의 header stamp는 장치가 측정한 시각을 나타내야 하지만, rosbag2가 메시지를 받은 시각과 같지 않을 수 있습니다. 드라이버 queue, 네트워크와 executor 대기로 두 시각 사이가 벌어지므로 분석 목적에 맞는 clock domain을 명시해야 합니다.
한 topic에서 timestamp가 역행하거나 큰 점프가 생기면 정렬과 속도 계산이 깨질 수 있습니다. topic별 첫·마지막 시각, 최소·최대 간격, 역행 횟수와 수신 지연 분포를 검사하고 재부팅·clock 조정 구간을 이벤트로 남깁니다.
대용량 센서는 평균 MB/s보다 순간 버스트가 문제다
카메라·LiDAR·point cloud는 평균 데이터율뿐 아니라 여러 센서가 같은 순간 프레임을 내는 버스트를 만듭니다. 직렬화, 압축과 디스크 flush가 겹치면 캐시가 차고 recorder가 메시지를 처리하지 못할 수 있습니다.
기록 시험은 실제 topic 조합과 최고 해상도, 최악 프레임률로 수행합니다. 입력 MB/s, 저장 MB/s, cache 사용량, write latency, CPU와 디스크 대기시간을 같은 시간축에 놓아 병목이 수신·처리·저장 중 어디인지 찾습니다.
저장소 플러그인과 파일 분할은 복구·분석 단위를 바꾼다
ros2/rosbag2 공식 저장소 문서는 storage 설정, 파일 크기·시간 기준 분할, 압축, snapshot과 simulation time 옵션을 설명합니다. SQLite3와 MCAP 같은 저장 방식은 인덱싱·압축·성능 특성이 다르므로 작업 도구와 함께 시험해야 합니다.
하나의 큰 파일은 관리가 단순하지만 손상과 전송 실패의 영향 범위가 큽니다. 너무 짧은 분할은 파일과 metadata가 늘고 사건 전후 연속 분석을 어렵게 하므로 업로드 단위, 장애 복구 시간과 보존 정책을 기준으로 크기와 시간을 정합니다.
압축은 저장 공간과 CPU·지연을 교환한다
압축은 디스크 쓰기량을 줄일 수 있지만 CPU 사용과 종료 flush 시간을 늘릴 수 있습니다. 이미 압축된 카메라 영상에는 이득이 작을 수 있고 point cloud나 반복 구조 데이터에는 더 큰 효과가 날 수 있으므로 실제 데이터로 비교합니다.
파일 단위와 메시지 단위 압축의 운영 특성도 다릅니다. 기록 중 CPU 포화, cache backlog, 파일 완결 시간, 읽기·재생 속도와 압축률을 함께 측정하고 공간 절감만 보고 선택하지 않습니다.
snapshot과 원형 기록은 사건 전 구간을 보존하는 방법이다
항상 모든 데이터를 영구 저장하기 어렵다면 메모리의 bounded buffer에 최근 구간을 유지하고 오류나 관심 이벤트에서 snapshot을 내릴 수 있습니다. 이 방식은 충돌 직전과 직후를 확보하는 데 유용하지만 buffer 크기와 시간 범위가 사건보다 충분해야 합니다.
트리거가 늦거나 recorder가 함께 멈추면 중요한 구간을 잃을 수 있으므로 독립 watchdog과 원격 트리거, 트리거 timestamp를 시험합니다. snapshot도 topic별 count와 시간축 검수를 통과해야 정상 파일로 인수합니다.
simulation time 기록은 첫 /clock과 시간 점프를 경계한다
simulation time을 사용하면 recorder timestamp가 /clock을 따릅니다. 첫 /clock이 오기 전에 시간 0으로 기록하거나 시뮬레이터 reset으로 clock이 뒤로 가면 파일 안에 큰 점프와 역행이 생겨 재생과 통계가 왜곡될 수 있습니다.
기록 시작 조건에 /clock 수신과 단조 진행 확인을 넣고, reset 시 새 bag으로 분할할지 이벤트를 남길지 정합니다. 실물 센서와 시뮬레이션 topic을 섞는다면 서로 다른 clock domain을 무리하게 한 시간축으로 해석하지 않습니다.
재생은 파일 열기보다 소비 노드와의 계약을 다시 맞추는 작업이다
재생 시 publisher QoS가 소비 노드의 요청과 호환되는지, rate 변경이 timeout과 제어 로직에 어떤 영향을 주는지 확인합니다. transient local 데이터, latched 성격의 설정, sensor best effort topic은 원래 전달 의도가 재현되는지 별도 시험합니다.
외부 장치를 구동하는 노드가 연결된 환경에서 명령 topic을 재생하면 실제 동작 위험이 있습니다. 분석망과 로봇 제어망을 분리하고 remap·allowlist·안전 interlock을 적용한 뒤 재생해야 합니다.
데이터 인수는 topic별 count·gap·timestamp·재생 결과로 판정한다
수집 파일은 로봇 학습 데이터 품질 검수와 연결해 필수 topic 존재, 기대 count 대비 비율, 최대 gap, timestamp 역행, 센서·행동 정렬과 실패 라벨을 검사합니다. 총 파일 크기만으로는 특정 topic의 빈 구간을 찾을 수 없습니다.
대표 구간을 재생해 소비 노드가 같은 상태와 이벤트를 만드는지도 봅니다. 재생 로그, 출력 checksum 또는 핵심 궤적 차이를 기준으로 두면 파일 포맷이 열리는 수준을 넘어 실제 재현 가능성을 판단할 수 있습니다.
| 검사 | 지표 | 합격 예시 |
|---|---|---|
| 존재 | 필수 topic·type | 누락 0 |
| 연속 | count·Hz·최대 gap | 명세 허용치 이내 |
| 시간 | 역행·offset·지연 | clock 정책과 일치 |
| 재현 | 소비 노드 출력 | 기준 결과와 허용차 이내 |
운영 절차는 기록 시작 전과 종료 후를 포함해야 한다
시작 전에는 저장 공간, topic·QoS, clock, 장치 건강과 쓰기 성능을 확인하고, 종료 뒤에는 정상 stop과 flush, metadata, checksum, topic 통계와 업로드 완료를 확인합니다. 전원 차단을 정상 종료로 간주하지 않습니다.
센서 퓨전 시간 정렬에 사용할 bag이라면 원시 센서뿐 아니라 calibration 버전, TF, clock 상태와 소프트웨어 빌드 식별자를 함께 보존해야 합니다. 그래야 동일 파일을 나중에 열었을 때 좌표와 시간의 의미를 복원할 수 있습니다.
rosbag2 기록과 재생에서 자주 묻는 질문
rosbag2가 실행 중이면 모든 topic이 기록되나요?
아닙니다. topic 발견, type support, QoS 호환과 저장 처리량 문제로 일부 topic이나 메시지가 빠질 수 있어 topic별 통계를 확인해야 합니다.
Reliable QoS로 기록하면 손실이 없어지나요?
전송 신뢰성은 높일 수 있지만 recorder 처리와 cache·디스크 병목, 종료 실패까지 없애지는 못합니다. 지연과 backlog도 함께 봐야 합니다.
압축은 항상 켜는 편이 좋은가요?
데이터와 CPU·디스크 조건에 따라 다릅니다. 실제 센서 조합에서 압축률, CPU, drop, flush와 재생 속도를 비교해 선택해야 합니다.
파일 크기가 예상과 비슷하면 정상인가요?
충분하지 않습니다. 특정 필수 topic이 빠져도 다른 대용량 topic 때문에 총 크기는 비슷할 수 있으므로 topic별 count와 gap을 검사해야 합니다.
bag 재생을 실제 로봇에 바로 연결해도 되나요?
명령 topic이 물리 장치를 움직일 수 있어 위험합니다. 격리 환경, remap·allowlist와 안전 interlock을 준비한 뒤 연결해야 합니다.
rosbag2 옵션과 storage 기능은 ROS 2 배포판별로 다를 수 있습니다. 사용 중인 버전의 공식 문서와 실제 센서 부하에서 기록·복구·재생 시험을 수행해야 합니다.