실험 근거로 설명하기

프로젝트 설명은 주장과 증거를 연결합니다

검토 자리에서 모든 코드를 처음부터 읽어 주면 듣는 사람이 핵심 결정을 찾기 어렵습니다. 반대로 로봇이 잘 움직인다고만 말하면 설계 판단을 평가할 수 없습니다. 이번 레슨에서는 질문 하나마다 주장, 재현 조건, 관측, 한계, 다음 행동을 짧게 연결합니다. 설명의 목적은 성공을 꾸미는 것이 아니라 동료가 같은 결과를 확인하고 변경을 판단할 수 있게 하는 것입니다.

HANDOFF에는 실행 명령과 기준 폴더, manifest, 조건별 결과, 실패 프레임, 개선 기록, 후속 시험표의 위치를 적습니다. 자료가 많아도 파일 이름만 나열하면 무엇을 읽어야 할지 알 수 없습니다. 각 자료 옆에 그 자료로 확인할 주장 하나를 붙입니다. 예를 들어 before-after.json은 센서 누락 보호의 효과를, summary.json은 조건별 도달률과 실패 사유를 설명합니다.

좌표 변환 질문에 프로젝트로 답합니다

서로 다른 좌표계의 위치를 변환하는 질문에는 기준 프레임과 변환 방향부터 답합니다. sensor의 점을 base_link로 옮기는 장착 변환, base_link 자세를 이용한 map 변환을 구분합니다. 위치 단위와 yaw 단위를 말하고 알려진 원점이나 회전 입력의 테스트를 근거로 제시합니다. 행렬을 쓴다는 말만으로 방향이나 적용 순서가 맞다는 사실이 증명되지는 않습니다.

이번 프로젝트의 frames.svg는 PC에서 map과 odom이 같다는 가정과 sensor의 앞쪽 장착을 보여 줍니다. 실제 환경에서는 이 관계를 별도로 확인할 필요가 있다고 덧붙입니다. 그림은 좌표 관계의 설명이고 실행 증거는 기존 frames 테스트입니다. 그림에 쓴 값을 바꾸었다고 코드의 변환이 바뀌지 않으므로 질문을 받은 뒤 두 자료가 일치하는지 함께 확인합니다.

통신 선택 질문은 작업의 수명을 말합니다

센서 값처럼 반복해서 관측하는 정보는 토픽 역할로 설명하고 짧은 조회와 응답은 서비스 역할로 설명합니다. 진행과 취소가 있는 이동 목표는 액션 역할에 대응합니다. 이 설명에는 실제 프로젝트의 작업 식별자와 상태 전이를 붙입니다. 모든 요청을 토픽으로 처리할 수 있다는 구현 가능성과 신입이 설명해야 할 책임 계약은 다른 판단 기준입니다.

이 트랙의 통신은 실제 ROS 2 실행 대신 가상 모델로 역할을 구현했습니다. 따라서 DDS 연결이나 rclpy 사용을 검증했다고 말하지 않습니다. 확인한 것은 메시지 필드와 발행 주기 모델, 목표 상태와 취소 계약입니다. 검토자가 실제 연결 범위를 물으면 REAL-TEST-SCOPE의 해당 PENDING 행을 가리킵니다. 구현한 역할과 실행한 환경을 함께 답하면 주장 범위가 명확해집니다.

흔들림 질문은 원인을 나누어 설명합니다

목표 가까이에서 방향이나 속도가 반복해서 바뀌는 현상은 제어 이득만으로 설명하지 않습니다. 오차 계산, 제어 주기, 포화, 도착 허용 범위, 추정 잡음을 나누어 후보로 둡니다. 프로젝트에서는 제어기가 추정 자세를 읽고 참값으로 평가한다는 점을 먼저 보여 줍니다. 잡음이 있는 자세와 목표 차이가 명령 부호를 바꿀 수 있음을 같은 조건의 로그에서 찾아 설명합니다.

개선 비교를 하려면 무엇을 고정하고 무엇을 바꿨는지 말합니다. 같은 지도와 목표, seed, 주기를 유지하고 한 정책만 바꾸면 원인 후보를 좁힐 수 있습니다. 여러 값을 동시에 바꾸어 결과가 좋아졌다면 어느 변경의 효과인지 더 실험해야 합니다. 이 모듈의 before-after는 제어 이득 조정이 아니라 센서 보호 정책 비교라는 점을 분명히 합니다.

잡음 평가 질문은 분모와 지표를 말합니다

25조건 실험은 다섯 조건과 seed 0부터 4까지의 조합입니다. 조건별 도달률의 분모는 그 조건의 다섯 실행이며 실패도 포함합니다. 위치 RMSE는 같은 자세 시각의 참값과 추정값을 비교합니다. 멈춤이 빨라 표본이 없는 실행에는 null을 두고 0 오차라고 표현하지 않습니다. 지표 이름, 계산 대상, 표본 수를 함께 답합니다.

도달은 액션의 SUCCEEDED만으로 판정하지 않습니다. 참값 목표 거리와 충돌 0까지 요구합니다. 추정 위치로는 도착했지만 참값이 허용 거리 밖인 잡음 실행은 TRUTH_NOT_REACHED가 될 수 있습니다. 검토 자리에서 이런 실패를 숨기지 않고 어떤 관측이 성공 판단을 바꾸었는지 설명합니다. 프로젝트가 자신의 한계를 드러내는 검사를 갖추었는지도 평가 대상입니다.

재생 질문은 파일과 시간을 연결합니다

같은 seed만 있으면 재현된다고 답하지 않습니다. 설정과 지도, 원본 입력 해시, 소스 식별, 시간 기준, 사건 순서를 함께 남깁니다. 입력 JSONL의 at_us와 seq는 순서를 복원하고 payload의 측정 시각은 지연 판단을 유지합니다. 재생 두 번의 상태와 결과 파일 해시를 비교한 자료가 같은 환경에서의 결정성을 보여 줍니다.

해시 일치는 결과 파일의 바이트가 같다는 근거이며 물리 정확도나 작성자 인증을 뜻하지 않습니다. Python 버전이나 구현이 바뀐 환경에서도 무조건 같은 수치가 나올 것이라고 확대하지 않습니다. 원본 로그가 달라지면 manifest 검사가 먼저 실패합니다. 검토자에게는 파일 손상 탐지와 실행 결과 비교를 분리해서 설명하여 해시의 역할을 과장하지 않습니다.

실패와 개선을 한 장에 설명합니다

센서 누락 사례는 legacy가 누락 뒤 계속 주행하고 safe가 SENSOR_MISSING으로 종료한 비교입니다. before와 after의 목표와 입력이 같다는 조건을 먼저 말합니다. 결과가 멈췄다는 사실과 그 멈춤이 보호 요구를 만족했다는 판단을 연결합니다. 안전을 실제로 입증했다는 문장 대신 PC 명령과 상태 계약을 검증했다는 범위로 설명합니다.

실패 영상에서는 정지 직전과 마지막 ABORTED 프레임을 보여 줍니다. 프레임 번호, at_us, pose_us를 읽고 sensor 이벤트에서 중단되었다면 마지막 tick과의 차이를 설명합니다. 영상은 표본을 줄인 표현이므로 정확한 PWM 시각은 states-safe.jsonl로 확인한다고 덧붙입니다. 숫자 표와 영상, 원본 로그가 같은 실행을 가리키는지 확인한 뒤 발표합니다.

반론을 실험으로 바꾸는 방법을 연습합니다

검토자가 고정 range=1m이라 장애물 감지가 없다고 지적하면 그 한계를 인정하고 지도 기반 회피와 센서 시간 보호가 이번 검사 범위라고 답합니다. 다음 시험은 실제 센서 누락과 오검출, 지도 불일치 관측으로 구체화합니다. 없는 기능을 있는 것처럼 설명하거나 지적을 단순 취향으로 처리하지 않습니다. 유효한 반론은 후속 시험표의 행으로 바꿉니다.

실물에서 멈추는지 묻는 질문에는 PWM 0 검사 파일을 보여 주고 물리 정지 측정은 PENDING이라고 답합니다. 실제 정지 거리와 독립 정지 수단은 시험 책임자가 장치 조건으로 확인해야 합니다. 이 답변은 근거 부족을 숨기지 않으면서 지금 완료한 검증의 가치를 설명합니다. 확인한 것과 다음 행동이 연결되어야 검토자가 인계를 맡길 수 있습니다.

오류 메시지와 근거를 읽는 순서를 정합니다

SOURCE 또는 HASH 오류가 나면 발표용 그림부터 수정하지 않고 실행 코드와 원본 파일 변경을 확인합니다. NONDETERMINISTIC이면 재생 순서와 난수 소비, 파일 직렬화 규칙을 봅니다. NORMAL_MAP이면 결과의 reason과 참값 거리, 충돌 수를 읽습니다. 이런 조사 순서를 HANDOFF에 적으면 다음 담당자가 같은 오류를 다시 발견했을 때 첫 행동을 정할 수 있습니다.

보고서에 실패 수를 쓰면서 성공한 실행만 분모로 삼는 오류를 피합니다. 표본 없는 RMSE를 0으로 바꾸거나 조건별 RMSE를 단순 평균 내는 것도 지표 의미를 바꿉니다. 기존 summarize는 표본 수로 제곱 오차를 가중합니다. 결과를 더 좋아 보이게 편집하는 대신 정의를 유지하고 필요한 새 지표를 별도 이름으로 제안합니다.

설명 자료를 제출하고 동료 검토를 받습니다

실습은 5분 설명문과 질문별 증거표를 제출하는 문서 과제입니다. 좌표, 통신, 흔들림, 잡음, 재생 다섯 주제를 각 한 문단으로 쓰고 정확한 파일 경로와 확인할 필드를 붙입니다. 미확인 질문 하나와 그 질문을 해결할 다음 시험도 적습니다. 동료는 링크한 자료로 주장을 따라갈 수 있는지와 실행 조건이 빠지지 않았는지 검토합니다.

더 읽기의 프로젝트 사례는 평가 지표와 통합 결정을 비교하는 참고입니다. 그 사례의 수치나 실행 결과를 자신의 보고서에 옮기지 않습니다. 최종 설명에는 자신의 실험에서 확인한 정상 도달, 보호 정지, 잡음 실패를 함께 넣습니다. 질문에 즉시 답할 수 없는 부분은 확인할 파일이나 후속 담당을 제시하여 검토 이후에도 작업이 이어지게 합니다.