Add camera exposure design notes and Q&A grounded in actual hardware specs

Design notes for multi-camera + LiDAR SLAM exposure tuning, plus a
question/answer pair that verifies the notes' assumptions (gain ceiling,
lens sweet spot, blur budget, 12-bit raw capture) against the actual
MV-CS016-10UC camera and VM0420MP5 lens datasheets and the driver source.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

doc/question_1.md

@@ -0,0 +1,27 @@
+# 질문지
+
+> 대상 카메라: **MV-CS016-10UC** (Sony IMX273, 1/2.9", 3.45 µm, global shutter, 1440×1080) — `resource/`에 첨부된 데이터시트 및 `hik_camera_ros2_driver` 코드/설정 실측 주석 기준으로 아래 질문들을 갱신함. 상세 답변은 `answer_1.md` 참조.
+
+## 1. 노출 하한 값을 100 µs보다 낮출 수 있는가
+데이터시트 기준 Standard exposure mode 하한은 15 µs다 (UltraShort 모드는 1~14 µs로 별도 모드). 현재 bag 녹화 시 3대 모두 `exposure_auto_min: 100.0`으로 설정되어 있는데, 15 µs 근방까지 낮추면 stop 계산법상 `log2(100/15) ≈ 2.74 stop`의 여유가 추가로 생긴다. 코드가 이미 쿼리하는 개체별 `ExposureTime` 노드의 실제 fMin 값(데이터시트는 스펙 상 보증치이며 개체 편차 가능)을 로그로 한 번 확인하고, `exposure_auto_min`을 실제 하한 근처로 낮춰 3대 모두 재검증이 필요한지 확인한다.
+
+## 2. 게인 상한치를 16 dB보다 더 열 수 있는가
+데이터시트 기준 게인 범위는 0~17 dB이며, `camera_params_cam1/2/3.yaml`의 실측 주석에도 "Range: 0.0 ~ 16.9 dB"로 이미 확인되어 있다. 즉 현재 16 dB 설정은 여유를 둔 보수적인 값이 아니라 **하드웨어 상한(16.9 dB)에 거의 붙은 값**이며, 24 dB 등으로 더 여는 것은 이 카메라에서 물리적으로 불가능하다. cam2는 현재 15 dB로, 상한까지 1.9 dB(0.3 stop)밖에 남지 않은 상태다. 실내 진입 시 필요한 다크사이드 stop 여유를 게인이 아니라 조리개(f/2.8 등) 또는 노출 상한(3.1절 블러 계산 기준) 쪽에서 확보하는 방향으로 조정할지 결정한다.
+
+## 3. 저장 시 12-bit raw 및 프레임별 메타데이터를 저장할 수 있는가
+현재 11분 촬영 시 3대 카메라(RGB8Packed) + mid360(10 Hz) + IMU(200 Hz) bag 용량이 100 GB 근방이며, 10 Hz 트리거 가정으로 역산한 카메라 데이터량(≈92 GB)과 대체로 맞아떨어진다.
+
+드라이버(`hik_camera_node.cpp`)가 `convert_param_.enDstPixelType`을 `RGB8Packed`로 고정해 매 프레임 강제 변환·발행하므로, `pixel_format`/`adc_bit_depth` 파라미터를 12-bit로 바꿔도 **실제로는 12-bit raw가 bag에 담기지 않는다**는 것이 코드로 확인되었다. 이 강제 변환 로직을 없애고 raw 패스스루(예: `mono16`/`bayer_rggb16` 인코딩)로 바꾸는 작업을 언제 반영할지, 그리고 이때 예상 용량(현재보다 33~67% 감소 예상 — BayerRG12Packed 1.5 byte/px 또는 Mono16 2 byte/px vs 현재 RGB8 3 byte/px)이 실측으로도 맞는지 확인한다.
+
+프레임별 메타데이터(노출시간/게인/프레임번호)는 SDK가 `MV_FRAME_OUT_INFO_EX` 구조체(`fExposureTime`, `fGain`, `nFrameNum`, `nAverageBrightness` 등)로 이미 매 프레임 제공하고 있는데, 캡처 루프가 이를 읽지 않고 버리고 있다는 것도 확인되었다 (GenICam `ChunkModeActive`를 새로 켤 필요 없이 바로 쓸 수 있음). 3대 모두 `exposure_auto: true`라 실제 노출값이 프레임마다 바뀌는데 지금은 bag에서 사후 확인이 불가능한 상태이므로, 최소한 실제 노출/게인 값만이라도 별도 토픽이나 CSV로 로깅하는 작업을 언제 반영할지 정한다.
+
+## 4. 측광 지표 관련 논문/정리 내용으로 현재 측광 지표를 개선할 수 있는가
+현재 하늘이 포함된 이미지에서 바닥이 어두워지는 경향이 눈으로도 확인된다. 원인은 카메라 온보드 Continuous AE가 `AutoTargetBrightness` 단일 스칼라(전체 프레임 평균 밝기 기준)로만 동작하기 때문으로 확인되었다. SDK 헤더상 AE 계산에만 쓰는 별도 ROI 기능은 확인되지 않으며(`MV_CC_Set/GetAOIoffsetX/Y`는 촬영 크롭용), 이 부분은 Hikvision MVS Feature Tree에서 한 번 더 확인이 필요하다.
+
+드라이버는 `exposure_auto: false` + 런타임 파라미터(`exposure_time`/`gain`, 이미 `dynamicParametersCallback`으로 지원됨)를 통해 외부 노드가 노출을 대신 제어할 수 있는 구조를 이미 갖고 있다. ROI+퍼센타일 측광(설계노트 4.2절)을 이 구조 위에 별도 ROS 2 노드로 구현하는 작업을 언제 착수할지 정한다.
+
+## 5. 회전 시 재투영 오차와 GPIO 관련 절차 사용 가능 여부
+핸즈헬드 장비를 회전하며 녹화 시 나무 등 근거리 물체 주변에 재투영 오차가 나타나는 현상은, 나무 자체의 문제가 아니라 **회전 중 카메라 간 노출 중심 타임스탬프 어긋남이 근거리·고밀도 특징점 물체에서 특히 두드러지는 일반적 현상**으로 확인되었다 (근거: 5.2절 블러 공식의 `v⊥/Z` 항 — 거리가 가까울수록 겉보기 오차가 커짐). 이 진단이 맞다면, 다음을 확인해서 5.3-[A] GPIO 오실로스코프 절차를 실제로 진행할지 정한다:
+
+- 데이터시트 확인 결과 카메라 I/O는 Line0(opto-isolated 입력, 현재 트리거용으로 사용 중), Line1(opto-isolated 출력, **현재 미사용**), Line2(양방향 비절연)로 구성되어 있어 출력 라인 자체는 물리적으로 비어 있다.
+- 다만 Hikvision MVS Feature Tree에서 Line1의 `LineSource`에 `ExposureActive`/`Strobe` 옵션이 실제로 존재하는지, 그리고 현재 6-pin 케이블이 Line1을 실제로 브레이크아웃했는지는 아직 미확인 — 이 두 가지를 확인해야 절차 진행 여부를 최종 결정할 수 있다.