Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#627 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Jupyter Notebook
Stelle
253
Fork
63
Merge medio
11h 55m
PR unite (30g)
8

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di brickbots/PiFinder

Tutte le issue di brickbots/PiFinder

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.