실물·ROS 2 후속 시험 범위

실물 시험의 범위를 문서로 제한합니다

PC에서 정상 이동과 누락 정지를 확인했어도 실제 바퀴와 센서, 통신 환경의 동작을 확인한 것은 아닙니다. 다음 담당자가 검증 범위를 넓히려면 지금까지의 증거와 아직 확인하지 않은 질문을 분리해서 받아야 합니다. 이 레슨은 구현을 더 추가하는 대신 시험표를 작성합니다. 범위를 적는 일은 작업을 미루는 것이 아니라 다음 실험의 시작 조건을 만드는 일입니다.

가상 HAL은 명령을 받아 수학적 이동을 계산하지만 모터 전류나 관성, 바닥 마찰, 배터리 상태를 측정하지 않습니다. PWM 0은 모델에 내린 명령과 반환값입니다. 실제 정지에는 감속 시간과 거리, 드라이버 상태가 관여할 수 있습니다. 시험표에서 명령 0, 장치 응답, 물리적 정지 관측을 별도 칸으로 나누면 PC 결과가 물리적 안전의 승인으로 바뀌는 일을 줄일 수 있습니다.

검증 상태를 세 가지로 표현합니다

확인한 항목에는 관측 파일과 실행 조건을 연결하고, 실패한 항목에는 중단 이유를 적고, 아직 수행하지 않은 항목에는 PENDING을 씁니다. 빈 칸이나 OK만 있는 표는 누구도 다음 행동을 정하기 어렵습니다. 각 행에는 대상 버전, 담당자, 날짜, 자극, 관측, 판정 기준, 중단 조건, 재시험 조건을 둡니다. 자동 검사와 사람이 관찰해야 할 부분도 구분합니다.

예를 들어 PC 센서 누락 행은 입력 500000us의 null, SENSOR_MISSING, 최종 PWM 두 값 0, 재생 해시 경로를 근거로 적습니다. 실물 센서 단선 행은 PENDING으로 시작합니다. 실물에서는 연결을 끊는 방법 자체도 장치와 시설 절차의 검토가 필요합니다. PC에서 null을 넣은 실행과 전기적 단선에 대한 장치 반응을 같은 실험 이름으로 묶지 않습니다.

Linux 실행과 실제 통신을 나눠 확인합니다

현재 실행 기록은 이 맥의 표준 라이브러리와 gcc로 만든 PC 모델 증거입니다. 후속 Linux 시험은 운영체제와 도구 버전, 설정 파일 위치, 실행 사용자, 작업 폴더를 정해 동일 다운로드를 실행합니다. 실행 로그뿐 아니라 종료 뒤 잔존 프로세스와 출력 파일 권한도 확인할 항목으로 남깁니다. 맥에서 동작한 코드를 Linux에서 검증 완료했다고 쓰지 않습니다.

순수 Python의 노드 모델은 실제 rclpy 프로세스와 통신하지 않습니다. 후속 시험에서는 센서 노드와 소비 노드를 별도 실행하고 이름, 타입, 메시지 필드, 프레임, 단위, 발행 간격을 기록할 계획을 씁니다. 값이 보이는지와 소비자가 정해진 주기로 값을 받는지는 다른 질문입니다. 수신이 멈출 때 명령 경로에서 어떤 보호가 작동할지도 함께 관찰하도록 설계합니다.

측정 시각과 수신 시각은 계속 구분합니다. 다른 장치의 시계를 바로 빼서 센서 나이를 계산하면 시계 차이를 지연으로 오해할 수 있습니다. 후속 시험표에는 사용할 시간 기준과 동기화 확인 방법, 재생 시 시간 설정을 적습니다. 현재 가상 시계의 0.20초 검사는 실제 환경의 종단 지연 측정이 아닙니다. 실제 측정이 나오면 예산 가정을 갱신하고 다시 판단합니다.

서비스와 액션은 결과와 정지를 확인합니다

서비스 시험은 정상 요청뿐 아니라 잘못된 프레임, 범위 밖 값, 중복 요청을 넣고 결과를 확인하는 계획을 포함합니다. 액션 시험은 목표 수락, 진행 피드백, 취소 요청, 최종 상태를 연결합니다. 취소 응답을 받았다는 사실만으로 장치가 멈췄다고 판단하지 않습니다. 마지막 구동 명령과 실제 움직임 관측을 함께 남길 후속 기준을 작성합니다.

응답이 없으면 즉시 같은 목표를 반복 전송하는 대신 현재 작업 식별자와 상태를 확인하는 절차를 적습니다. 통신이 회복되었을 때 이전 이동을 자동으로 재개해도 되는지는 별도 정책입니다. 이 프로젝트의 종료된 액션은 새 요청과 구분합니다. 시험표에는 복구 승인 담당자와 주변 확인 조건을 넣어 기술적 연결 회복과 주행 허가를 혼동하지 않도록 합니다.

DDS QoS는 실제 환경에서 관측합니다

모사 토픽에는 실제 DDS의 발견, 네트워크 손실, QoS 조합 검증이 없습니다. 후속 시험은 발행자와 구독자의 적용 설정을 기록하고 정상 연결, 설정 불일치, 수신 중단 조건을 관찰하도록 작성합니다. 이 문서에서 특정 설정이 모든 현장에 적합하다고 단정하지 않습니다. 결과가 안 보일 때 타입과 이름, 시간과 QoS를 순서대로 확인할 근거를 남깁니다.

메시지가 도착해도 너무 오래된 센서 값일 수 있습니다. 통신 성공과 제어 입력 유효성은 같은 통과 기준으로 합치지 않습니다. 시험표의 관측에는 발행 간격과 실제 수신 간격, 측정 시각의 나이를 포함합니다. 허용 나이를 초과했을 때 보호 판단이 발생했는지와 명령이 차단되었는지를 함께 기록합니다. 수신 로그 한 줄로 전체 주행 연결을 승인하지 않습니다.

rosbag 재생의 경계를 설계합니다

현재 JSONL 재생은 직접 만든 가상 시계 계약이며 rosbag 실행 결과가 아닙니다. 후속 기록 시험은 대상 토픽, 시간 기준, TF와 설정 보관 위치, 코드 버전, 파일 식별자를 목록으로 남깁니다. 기록만 있으면 충분한지 판단하려면 그 기록이 참조한 지도와 설정도 같은 묶음에 있는지 확인해야 합니다. 시간 설정을 바꾼 재생은 원본 실행과 차이를 명시합니다.

재생 명령이 실제 모터 경로에 도달하지 않도록 격리하는 절차를 먼저 정합니다. 오래된 목표나 구동 명령을 다시 보내는 시험은 단순 분석 도구 실행과 다릅니다. 기록을 읽는 분석 프로그램과 실제 구동 인터페이스 사이의 경계를 문서에 표시합니다. 이 레슨은 ROS 명령을 실행하지 않으며 후속 담당자가 장치 없는 상태부터 검증할 순서를 작성합니다.

구동 시험은 에너지와 공간을 고려합니다

실물 단계의 처음에는 이동을 허용하지 않은 상태에서 명령 제한과 방향, timeout, 독립 정지 수단을 점검하는 계획을 둡니다. 구체적인 회로 조작과 구동 방식은 장치 제조사와 시설 절차를 따르도록 적습니다. 소프트웨어 명령 차단과 독립적인 정지 경로는 같은 구성 요소가 아닐 수 있습니다. 어떤 경로를 누구가 확인하는지 담당을 나눕니다.

제한 주행은 격리 공간, 관찰자, 승인된 속도와 이동 범위, 진입 금지 영역을 정한 뒤 시작하도록 설계합니다. 이번 PC 속도 상한을 실물의 안전 속도로 그대로 복사하지 않습니다. 바닥과 하중, 구동기 특성이 바뀌면 정지 거리가 달라질 수 있으므로 수치 기준은 시험 책임자가 정합니다. 문서에는 기준을 정할 주체와 관측 방법을 적습니다.

중단과 재시험 기준이 있어야 범위가 닫힙니다

예상보다 긴 정지 거리, 방향 불일치, 시간 기준 오류, 센서 검출 누락, 과열처럼 관측 가능한 중단 조건을 씁니다. 모든 이상을 사람이 판단한다고만 적으면 시험 중 결정이 흔들립니다. 중단 뒤에는 원인 파일과 조건을 보존하고 수정, PC 회귀, 제한 범위 재시험, 담당 승인 순서로 확대 여부를 판단하는 계획을 남깁니다.

마찰과 미끄러짐은 현재 모델의 바퀴별 추정 잡음과 다릅니다. 추정 오차를 넣은 시뮬레이션에서 실패를 봤다고 실제 구동 오차의 범위를 알게 되는 것은 아닙니다. 센서 range=1m 역시 주변 장애물 감지 성능을 뜻하지 않습니다. 한계 항목마다 실제로 관측할 값과 시험 조건을 연결하면 막연한 추가 테스트라는 문장을 구체적인 작업으로 바꿀 수 있습니다.

시험표의 제출 기준을 확인합니다

제출물에는 PC 확인 2행 이상과 후속 PENDING 8행을 적고 각 후속 행의 담당 역할, 자극, 관측, 중단, 재시험 조건을 채웁니다. 실제 Linux, rclpy 토픽, 서비스, 액션, DDS QoS, rosbag, 구동 제한, 비상정지, 제한 실물 주행이 빠지지 않게 합니다. 각 항목의 연결 여부는 사람이 검토하며 아직 실행하지 않은 결과를 출력처럼 만들지 않습니다.

더 읽기는 ROS 학습 후 이어 갈 작업을 정리하는 자료입니다. 이번 산출물은 그 장의 설명을 복사한 목록이 아니라 자신의 PC 프로젝트에서 남은 간극을 설명하는 시험 계약입니다. 동료에게 표만 전달해도 어디서 시작하고 어떤 증거를 남기며 언제 멈춰야 하는지 알 수 있도록 작성합니다. 미확인 항목을 정직하게 표시하는 것이 최종 인계의 완성도를 높입니다.