Why we did not extend /diagnostics?
요약
ROS Discourse에 게재된 이 글은 ROS 2 진단(diagnostics) 시스템을 확장하지 않고 별도 설계를 택한 이유를 설명한다. REP 107(Tully Foote, 2010년 11월)이 정의한 /diagnostics 토픽은 DiagnosticArray와 DiagnosticStatus를 담아 정상 운용 확인·디버그 정보·장기 로그 수집에 적합하게 설계됐으며, OK·WARN·ERROR·STALE 네 가지 레벨을 제공한다. 저자들은 '상태(status)'는 정보를 전달하는 반면 '결함(fault)'은 쿼리하고 행동할 수 있는 모델이라는 점에서 두 개념이 본질적으로 다르다고 주장한다. 따라서 기존 diagnostic_msgs나 diagnostic_updater에 필드나 컨텍스트를 추가하는 방식으로는 결함 모델을 구현할 수 없다고 결론짓는다.
큐레이터 노트
원문에 없는 맥락입니다
'상태'와 '결함'의 개념 분리는 저자들의 설계 판단이므로, 제안된 결함 모델이 기존 diagnostic 생태계와 어떻게 공존·연동될지는 아직 구체적으로 제시되지 않은 부분이다.
이 글은 원문을 요약한 큐레이션입니다. 수치·스펙은 원문 표기를 유지했습니다. 로봇 발표는 제조사·연구실 보도자료가 많으므로 검증된 결과와 구분해 읽으세요.