12mm lens effective focal length measures 13.04mm, not the nominal 12.0 — self-heal cannot identify it

オープン
  • 何か問題がありますか？
#627 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
python
領域
backend

調査の方向性

Start with the 12mm entry and identify_lens_from_fitted_fov in optics.py, then read ADR 0029 at docs/adr/0029-fov-gate-width-follows-lens-confidence.md for the gate and self-heal behavior. Use the measured 13.04 mm EFL to update the lens data, then trace the stated-12 mm gate, imx462 assumed-lens union, imx296 derived field, and associated SQM zero point. Done means the 12 mm entry is marked measured, self-heal identifies the unit within tolerance, and all derived angles and zero-point values are updated consistently.

索引モデルが issue の本文から書いたものです。

説明

bug

The 12mm lens entry in optics.py carries the nominal 12.0 mm as its effective focal length, flagged effective_focal_length_measured=False with a comment asking for an on-sky sweep. A rev4 imx462 unit with a 12 mm lens has now provided that measurement, and the nominal is wrong by 8.7%.

Measurement

Device: rev4, imx462, 12 mm lens, no camera_lens in config (lens assumed), running e499621a (#624). Solving normally on the assumed-lens gate.

Fitted FOV from /api/status, sampled over ~30 s:

12.436  12.436  12.437  12.439  12.434   (Matches 13-27)

Backing the effective focal length out of the 980 px @ 2.9 µm crop:

half_width_mm = 980 * 2.9 / 1000 / 2 = 1.421
EFL = 1.421 / tan(12.437 / 2)  =  13.04 mm     (+8.7% vs the 12.0 label)

The crop geometry is not in question here: the 16 mm's effective_focal_length_mm = 15.61 was fit against this same 980 px crop to reproduce the imx462's calibrated 10.38° field width. So the discrepancy sits in the lens, not the sensor profile. Note the sign is opposite to the 16 mm, which measured 2.4% short of its label.

Consequences today

Self-heal never promotes on these units. identify_lens_from_fitted_fov compares against the derived 13.507°:

lens derived FOV error vs fitted 12.437°
16mm 10.403° 19.6%
12mm 13.507° 7.9%

LENS_IDENTIFY_TOLERANCE is 0.05, so nothing is identified, the streak resets every frame, and camera_lens is never written. ADR 0029's "a fitted FOV matching no shipped lens writes nothing" branch is firing on a lens we actually shipped. The device keeps solving on the wide assumed gate forever, which is the safe outcome but not the intended one.

Every derived angle for 12 mm users is 8.6% wide — plate scale, the frustum, and the SQM zero point keyed to it.

The logger.info that explains the non-write is invisible in practice: the shipped logconf_default.json sets the root logger to ERROR, so no Integrator or Solver line reaches pifinder.log at all. Anyone debugging this on a stock unit sees silence.

Proposed fix

Set 12mm to the measured effective focal length (~13.04 mm) and flip effective_focal_length_measured=True. Self-heal then identifies at ~0.02% error and promotes on the next three solves.

Gate this on a second measurement before merging. The 16 mm's value earned its authority by reproducing two independently calibrated field widths on two different sensors — one unit is thinner evidence than that, and this constant moves every 12 mm user's SQM. A second 12 mm unit, ideally on an imx296 so the sensor half varies, would settle it the same way.

Knock-on changes once the value moves:

  • stated-12mm gate becomes [10.57, 14.30] instead of [11.48, 15.53]
  • the imx462 assumed union re-centres (currently 12.19 ± 3.35)
  • the imx296's 12 mm derived field moves too, and its SQM zero point with it
Rejected: widening LENS_IDENTIFY_TOLERANCE

Raising it to ~0.10 promotes today in one line, but it writes camera_lens=12mm while the device still derives 13.507°. The gate then tightens to [11.48, 15.53] around a field that is really 12.44° — 0.96° of headroom — and the 8.6% SQM error stays. It papers over a constant we know to be wrong.

Related

  • ADR 0029 docs/adr/0029-fov-gate-width-follows-lens-confidence.md
  • #624 (assumed-lens gate and self-heal)
  • The 12mm f-number comment in optics.py notes that the same on-sky sweep settles its SQM zero point, so the two want doing together.
主要言語
Jupyter Notebook
スター
253
フォーク
63
平均マージ
11時間 55分
マージ済み PR（30日）
8

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

brickbots/PiFinder のほかの issue

brickbots/PiFinder の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。