[devpark435]

실기기 1회차 결과 (1.3.0+45)

분석 성공. 진단 로그로 두 문제의 원인이 좁혀짐.

[BallDetection] 검출 73/210 프레임, 최고 점수 0.875
[ReleaseDetector] release=67, conf=0.4
[Trajectory] refined f71~f114 (lane y 2.1 → 13.5m)
[PinImpact] 핀 폭발 프레임: 124
[Trajectory] 리본 소스: 픽셀투영 (59개 단면, 관측 37개, rms 0.00062)
[SpeedEstimator] 32.7km/h (파울라인통과 f=63.6, 폭발 f=124, 회귀 28.7, R² 1.00)
[Speed] 랜드마크 없음km/h, 기존 32.7km/h → 채택 32.7km/h(기존)

구속이 높은 이유

landmark_speed_kmh = null — 화살표 검출 실패로 랜드마크 코어가 죽고 legacy 폴백. legacy는 원근 압축에 취약해 재설계 대상이었던 그 코어다.

legacy 내부에서도 두 추정이 어긋난다:

• 회귀 기울기: 28.7 km/h (추적 구간 2.1~13.5m)
• 이벤트 시간: 32.7 km/h (파울라인 f63.6 → 폭발 f124)

게다가 파울라인 통과가 f=63.6인데 릴리즈는 f=66~67 — 공이 릴리즈보다 3.4프레임 먼저 파울라인을 넘었다는 모순. 호모그래피 레인 y가 신뢰할 수 없다는 직접 증거.

궤적이 BP에서 끝나 보이는 건

코드상 리본은 f66f124 59개 단면 전부 생성됨(관측 37 + 모델 연장 22). 끊기지 않는다. 남은 가능성은 연장 구간이 소실점 근처라 픽셀 이동이 거의 없는 것 — 판정하려면 리본 끝점 ny를 핀존 ny(이번 회차 0.340.41)와 비교해야 한다.

변경

1. 화살표 검출 입력 교체 (실질 수정)

분석 프레임은 scale=480:-1 -q:v 5로 뽑힌다. 화살표는 이 해상도/압축에서 뭉개진다. 화살표는 레인에 고정된 마킹이라 어느 프레임을 써도 무방하므로, 레인 확인용으로 이미 원본 해상도(-q:v 3, 스케일 없음)로 디코딩해둔 첫 프레임을 run(landmarkFrame:)으로 넘긴다. ffmpeg 추가 호출 없음.

2. 진단

• [Arrow] — 입력 해상도, 검출 개수, 각 좌표, 선 성립 여부. 실패가 "0개 검출"인지 "선 구성 실패"인지 구분
• [Trajectory] 리본 끝점 — 리본 f범위·ny범위, 마지막 관측, 핀존 ny를 한 줄에
• metrics에 trajectory_first/last_frame, trajectory_first/last_ny — SQL만으로 도달 판정

검증

• flutter analyze lib/features/analysis/ — 신규 이슈 0 (기존 info 2건은 homography_solver 네이밍)
• flutter test test/features/analysis — 210 passed