KOR'K Sensor

KOR'K Sensor 05 L'ingénierie, les calculs

Chapitre 05

L'ingénierie, les calculs

Chaque choix du boîtier repose sur un calcul ou sur un test. Les cinq études suivent le même format : la question, la méthode, les hypothèses, le résultat et ses limites. Les erreurs trouvées en chemin sont montrées aussi.

D'abord

Les limites, avant les calculs

  • 13,4 % du temps avec un visage exploitable : c'est le résultat d'une simulation, pas une mesure.
  • Ce chiffre suppose un recadrage qui suit l'enfant, celui du futur mode « chambre ». Sans lui, on tombe à moins de 1 %.
  • Dans la V1, la zone filmée est fixe. Le boîtier recadre toujours le même carré au sol : un enfant qui en sort n'est plus vu.
  • Un biais n'est pas traité : ce qui se passe d'intéressant peut arriver justement hors du champ.
  • Le mode « chambre » (des tranches de 30 s, triées selon la présence de l'enfant, avec un recadrage qui le suit) changerait une partie de ces limites. Il n'est pas encore codé.

Sources : étude 05.1 ci-dessous ; 06-logiciel/README.md ; journal de conception, étapes 8 et 14.

Étude 05.1

Où poser le boîtier dans la chambre ?

Question

À quelle hauteur, et avec quelle inclinaison, le boîtier voit-il le plus souvent le visage d'un enfant qui joue, tout en restant hors de sa portée ?

Résultat

13,4 %

du temps, le visage de l'enfant est exploitable avec le boîtier posé à 1,6 m et incliné de 20°. Au plafond (2,3 m), on tombe à 7,0 % ; sans recadrage sur l'enfant, à moins de 1 %.

Exemple, comme ordre de grandeur : si un enfant joue 3 h par jour dans la pièce (une hypothèse sans source, à vérifier avec les familles), 13,4 % représentent environ 24 minutes de visage exploitable par jour, avec le futur mode « chambre » (prévu, pas encore codé). Ce n'est pas une mesure.

Figure 1

Part du temps où le visage de l'enfant est exploitable, selon la hauteur du boîtier

Boîtier dans un coin, incliné de 20°. Simulation d'une chambre de 3,5 × 3,5 m.

Source : simulation KOR'K, 02-modele-3d/etude-position/grille.json, modèle corrigé du 9 novembre 2026. C'est une simulation, pas une mesure.
Voir les données
HauteurVisage exploitableSol couvert (enfant assis)
1,0 m19,4 %99,9 %
1,1 m18,4 %99,7 %
1,2 m17,3 %99,3 %
1,3 m16,3 %98,9 %
1,4 m15,3 %98,3 %
1,5 m14,3 %97,7 %
1,6 m (recommandé)13,4 %96,9 %
1,7 m12,5 %96,0 %
1,8 m11,5 %95,0 %
1,9 m10,5 %93,9 %
2,0 m9,6 %92,7 %
2,1 m8,7 %89,9 %
2,2 m7,8 %88,3 %
2,3 m (plafond)7,0 %86,7 %
2,4 m6,2 %84,9 %

Corrigé

7,9 % → 13,4 %

Corrigé le 9 novembre 2026. La première version gardait la tête de l'enfant assis penchée de 30° en permanence : vu d'un boîtier à 1,6 m, il n'était presque jamais de face. L'erreur a été relevée par une relecture faite avec un autre modèle d'IA, puis vérifiée dans le code. Le boîtier reste 1,9 fois plus efficace qu'au plafond. Voir 05.5

Figure 2

La hauteur compte bien plus que l'inclinaison

Part du temps où le visage est exploitable, pour 285 réglages : 15 hauteurs × 19 inclinaisons. Plus c'est foncé, plus le visage est souvent lisible.

Source : grille.json, même simulation (9 nov. 2026). Survolez une case pour sa valeur, cliquez pour régler le simulateur.

Figure 3
Le simulateur

La chambre en 3D : réglez le boîtier, placez l'enfant

Choisissez la hauteur et l'inclinaison, assis ou debout, la direction du regard ; cliquez sur la vue de dessus pour déplacer l'enfant. Un clic sur une case de la figure 2 règle aussi le simulateur.

Le simulateur se charge quand on arrive ici.

Le même modèle que les figures 1 et 2, recalculé dans la page et vérifié contre le calcul Python sur les 285 réglages (07-site-prive/outils/tests/test_chambre.mjs). Meubles décoratifs : ils ne cachent rien dans le modèle.

Et deux caméras ?

Une seconde caméra dans le coin opposé double la part du temps où le visage est vu : 26,8 % au lieu de 13,4 %. Les deux caméras ne voient jamais le même visage au même instant. Dans deux coins voisins, elles se recouvrent un peu : 25,7 %. Elle n'est pas prévue pour l'instant : elle coûterait environ 230 € de plus, compliquerait la synchronisation et renforcerait l'impression de surveillance.

Configuration (1,6 m, 20°)Modèle corrigéAncien modèle
1 caméra dans un coin13,4 %7,9 %
2 caméras, coins opposés26,8 %15,7 %
2 caméras, coins voisins25,7 %15,0 %

Recalculé le 9 novembre 2026 avec le modèle corrigé (recherches/2026-11-09_etude-deux-cameras-corrigee.json). L'ancienne étude annonçait 15,9 et 15,1 % : le second boîtier y avait perdu son retrait de 9 cm par rapport au mur. Corrigé, l'ancien modèle donne 15,7 et 15,0 %, ce qui ne change pas la conclusion.

Détail

Voir la méthode

Méthode

Une simulation en Python. On place un enfant tous les 10 cm dans la chambre, tourné dans 36 directions, assis ou debout, et on compte la part des cas où son visage est exploitable. On recommence pour 15 hauteurs (de 1,0 à 2,4 m) et 19 inclinaisons (de 0 à 45°).

Hypothèses

  • Chambre carrée de 3,5 × 3,5 m. Boîtier dans un coin, objectif à 9 cm des murs, tourné vers le centre de la pièce.
  • Camera Module 3 Wide : 102° à l'horizontale, 67° à la verticale (fiche officielle).
  • Recadrage sur l'enfant : on garde la finesse du capteur de 12 Mpx (4 608 px sur 102°).
  • Enfant de 2 à 7 ans, partout à plus de 30 cm des murs : assis par terre 60 % du temps (visage à 0,55 m, tête penchée en moyenne de 18°, écart-type de 14°), debout 40 % du temps (visage à 0,95 m, tête penchée de 10°).
  • Visage exploitable : dans le champ, vu à moins de 45° de face, et large d'au moins 48 px (pour un visage de 12 cm).

Chiffres

RéglageVisage exploitableSol couvertZone aveugle au pied du coin
1,6 m, 20° (recommandé)13,4 %96,9 %0,78 m
1,6 m, 37,5° (meilleur réglage hors de portée)13,4 %99,9 %0,36 m
1,7 m, 20°12,5 %96,0 %0,85 m
Plafond, 2,3 m, 20°7,0 %86,7 %1,29 m
1,0 m, 25° (à portée d'un enfant)19,4 %100 %0,28 m
1,7 m, 25°, sans recadrage1,0 %97,7 %0,70 m
1,6 m, 20°, ancien modèle (tête fixe à 30°)7,9 %——

Source : recherches/2026-11-09_etude-placement-resultats-corrigee.json. « Sol couvert » : part de la pièce où un enfant assis est dans le champ. « Zone aveugle » : distance au coin en deçà de laquelle un enfant assis sort du champ.

Pourquoi 20° plutôt que 37,5°

À 1,6 m, l'inclinaison change très peu le résultat entre 7,5° et 40°. On garde 20°, l'angle du design, qui voit le corps d'un enfant assis dès 0,78 m du coin. Le réglage à 37,5° réduit la zone aveugle à 0,36 m : c'est une piste pour la V2.

Limites

  • Un modèle simplifié, pas une mesure : pas de meubles, pas de corps qui cache le visage, une seule chambre type.
  • La posture de la tête (18° en moyenne) est une hypothèse. Elle sera vérifiée avec le vrai boîtier, après le montage.
  • Le seuil de 48 px est un seuil de travail retenu pour le modèle, sans référence publiée.
  • Le chiffre dit combien de temps le visage est lisible, pas ce que l'analyse en tire.

Fichiers

02-modele-3d/etude-position/etude_position.py, grille.json, etude_deux_cameras.py ; journal de conception, étapes 8, 10 et 14.

Étude 05.2

Combien de pixels sur un visage ?

Question

Combien de pixels occupe le visage d'un enfant dans l'image, et faut-il un ordinateur plus puissant pour en avoir assez ?

Résultat

74,6 px

sur un visage à 3 m, en recadrant dans le capteur entier de 12 Mpx. En image 1080p entière, seulement 31,1 px, sous le seuil de travail de 48 px. Ce recadrage en temps réel demande un Raspberry Pi 5 ; le Zero 2 W prévu au départ en était incapable, et il était de toute façon en rupture presque partout.

Schéma

Le capteur : 4 608 × 2 592 pixels, 102° de large partie gardée, pixel pour pixel pixels regroupés par 4 : 2 304 px de large toute l'image réduite à 1 920 px de large

0 px

Calcul : la même formule que la figure 4, pour un visage de 12 cm. Le visage est dessiné pour l'illustration ; le seuil de 48 px est un seuil de travail. Caractéristiques : fiche officielle de la Camera Module 3 Wide (raspberrypi.com, 9 nov. 2026).

Figure 4

Largeur d'un visage de 12 cm dans l'image, selon la distance

Trois façons de filmer avec la même caméra (Camera Module 3 Wide, 102° à l'horizontale).

Calcul : largeur en pixels = pixels du capteur × 0,12 m ÷ (2 × distance × tan 51°). Caractéristiques : fiche officielle de la Camera Module 3 Wide (raspberrypi.com, consultée le 9 nov. 2026). Le « mode réduit » est celui que le logiciel aurait utilisé par erreur (05.5).
  • Capteur entier, recadré sur l'enfant (Pi 5)
  • Mode réduit du capteur (2 304 px de large)
  • Image 1080p entière (sans recadrage)

Détail

Voir le calcul

Calcul

pixels sur le visage = largeur de l'image en pixels × 0,12 m ÷ (2 × d × tan(102° ÷ 2))

Avec le recadrage, l'image garde la finesse du capteur entier : 4 608 px pour 102°. Sans recadrage, une image 1080p n'a que 1 920 px pour le même champ.

Valeurs

DistanceCapteur recadréMode réduit1080p entier
1,5 m149 px75 px62 px
2,0 m112 px56 px47 px
2,7 m83 px41 px35 px
3,0 m75 px37 px31 px

Ce sont aussi les valeurs que l'essai M1 vérifiera sur la vraie caméra, avec un disque de 12 cm photographié à 1,5, 2, 2,7 et 3 m (checklist des plans).

Le choix du Raspberry Pi 5

Raspberry Pi 5 de 4 Go, à 136,80 € (prix relevé le 9 nov. 2026, en forte hausse avec le prix de la mémoire). Il ne tenait pas couché contre un mur : il se loge dans l'axe, derrière la caméra, et le boîtier passe à 12,4 cm le long des murs. Écartés : le Zero 2 W, deux caméras, un capteur basse lumière (IMX585) au pilote non officiel.

Limites

  • L'objectif est supposé rectiligne : sur les bords de l'image, un grand-angle étire un peu les visages.
  • Le flou, le bruit et la compression réduisent la netteté réelle : le nombre de pixels est une borne haute.
  • Le seuil de 48 px est un seuil de travail, sans référence publiée.

Étude 05.3

Exposition et mise au point fixe

Question

Quel temps de pose limite le flou quand l'enfant bouge, et peut-on se passer de la mise au point automatique ?

Résultat

1/50 s

au plus : le logiciel vise environ 1/100 s et, dans le noir, monte le gain plutôt que le temps de pose

0,71 m → ∞

tout est net avec la mise au point fixée à 1,7 m : pas d'autofocus qui « pompe »

Tableau

Flou de bougé, en pixels du capteur, pour un visage à 2 m

Selon le temps de pose et la vitesse du mouvement. Les vitesses sont des exemples, pas des mesures.

Temps de pose0,2 m/s0,5 m/s1,0 m/s
1/30 s6 px16 px31 px
1/50 s (plafond)4 px9 px19 px
1/100 s2 px5 px9 px
1/125 s1 px4 px7 px

Calcul : flou = vitesse × temps de pose × 933 px par mètre à 2 m. Réglages du logiciel : registre des décisions (9 nov. 2026).

Détail

Voir le calcul

Flou de bougé

flou (px) = vitesse (m/s) × temps de pose (s) × focale en pixels ÷ distance (m)

La focale en pixels vaut 4 608 ÷ (2 × tan 51°) ≈ 1 866 px. À 2 m, un mètre de déplacement couvre donc environ 933 px du capteur. Le compromis retenu : environ 1/100 s, jamais plus de 1/50 s ; au-delà, c'est le gain qui monte, avec un peu plus de bruit le soir. Imposer 1/125 s en dur aurait noyé l'image de bruit dans une chambre peu éclairée.

Profondeur de champ

H = f² ÷ (N × c) + f ≈ 1,23 m

Avec f = 2,75 mm, N = 2,2 et un cercle de netteté c de 2 pixels (2,8 µm), la distance hyperfocale H vaut environ 1,23 m. En faisant la mise au point à 1,7 m, au-delà de H, tout est net d'environ 0,71 m jusqu'à l'infini. Une mise au point fixe suffit donc pour toute la chambre.

Caractéristiques de la Camera Module 3 Wide (focale 2,75 mm, ouverture F2.2, pixels de 1,4 µm) : documentation officielle Raspberry Pi, consultée le 9 nov. 2026.

Limites

  • Calcul ajouté le 9 novembre 2026, à confirmer par l'essai M2 (flou et lumière le soir, vers 100 lux) sur la vraie caméra.
  • Un cercle de netteté de 2 pixels est un choix ; plus strict, la zone nette commence plus loin.
  • Le clip envoyé est réduit à 1 920 px de large : le flou y paraît un peu plus faible qu'en pixels du capteur.

Étude 05.4

Ce que Gemini voit vraiment

Question

Quelle image le modèle d'analyse reçoit-il vraiment, et le réglage par défaut suffit-il pour lire une expression ?

Résultat

11 / 11

réponses justes en HIGH, dans toutes les conditions testées, contre 9 à 11 en LOW. Sur une mire, HIGH lit un texte 2,5 fois plus petit et n'invente aucun code ; en LOW, le modèle en invente malgré la consigne « ne devine pas ».

Figure 5
La mire

Plus petit texte lu sur une mire de codes

Vidéo 4K de codes de 8 à 60 px, envoyée entière ou recadrée en 1280 × 720.

Source : recherches/2026-11-09_test-gemini-mire.json, modèle gemini-3.1-flash-lite (celui du backend de KOR'K Scan), 9 nov. 2026.
Voir les données
EssaiPlus petit texte luLignes justesCodes inventésTokens vidéo par secondeDurée de réponse
Image entière, LOW42 px31662,7 s
Image entière, HIGH17 px802642,4 s
Recadrage 1280 × 720, LOW14 px93661,8 s
Recadrage 1280 × 720, HIGH8 px1202641,4 s

La mire : des lignes de codes alphanumériques de taille décroissante.
La mire utilisée : douze lignes de codes, de 60 à 8 px de haut. Aucune personne n'est filmée : la mesure est objective.

Figure 6
La vidéo

Réponses justes sur une vraie vidéo, LOW contre HIGH

Un adulte filmé selon un scénario, 4 instants nets, 11 réponses (regard, expression, mains). Ce que livrerait le Sensor est simulé à 2 m et à 2,7 m.

Source : recherches/2026-11-09_test-gemini-video-adulte.json et verite-video-adulte.json, 9 nov. 2026. Le réglage par défaut du backend donne le même résultat que LOW.
Voir les 11 essais
EssaiJustesFauxTokens vidéo par seconde
téléphone, réglage par défaut10 / 11191
téléphone, LOW10 / 11191
téléphone, HIGH11 / 110289
Sensor zone fixe à 2,0 m, LOW9 / 11291
Sensor zone fixe à 2,0 m, HIGH11 / 110289
Sensor suivi à 2,0 m, LOW11 / 11091
Sensor suivi à 2,0 m, HIGH11 / 110289
Sensor zone fixe à 2,7 m, LOW10 / 11191
Sensor zone fixe à 2,7 m, HIGH11 / 110289
Sensor suivi à 2,7 m, LOW11 / 11091
Sensor suivi à 2,7 m, HIGH11 / 110289

Le coût

91 → 289

tokens par seconde de vidéo, de LOW à HIGH (×3,2)

66 → 264

tokens par seconde sur la mire

1,4 à 2,7 s

par réponse : HIGH n'est pas plus lent

Décisions

  • Au stand de Nuremberg : une zone fixe, envoyée en HIGH. Pas de cadrage qui suit la personne : il n'apporte rien de plus en HIGH dans ce test.
  • Plus tard, le mode « chambre » : un cadrage de 1280 × 720 qui suit l'enfant ; LOW y suffit dans ce test, pour 3,2 fois moins de tokens, à évaluer.
  • Pour KOR'K Scan : passer explicitement en HIGH toutes les vidéos, après l'évaluation de la nouvelle version de l'analyse.

Détail

Voir la méthode

Méthode

Le modèle gemini-3.1-flash-lite reçoit la même vidéo avec deux réglages de résolution : LOW (le réglage par défaut, environ 70 tokens par image) et HIGH (environ 280). La mire mesure le plus petit texte lu ; la vidéo d'un adulte, dont les réponses sont connues d'avance, mesure ce qui compte pour KOR'K : le regard, l'expression, les mains. Le comptage de la mire compare les codes par leur contenu.

Ce que ça montre

  • Le seuil de lecture suit la largeur de l'image : environ 1,1 % de la largeur en LOW, 0,45 % en HIGH. Gemini réduit donc toute vidéo à une taille fixe, environ 2,5 fois plus fine en HIGH. Les tailles internes (environ 384 et 900 px de large) en sont une déduction, pas une mesure.
  • Le recadrage en LOW vaut l'image entière en HIGH, pour quatre fois moins de tokens.
  • Toutes les erreurs de LOW portent sur l'expression : « parle » et « sourire » lus « neutre ».

Limites

  • Un seul adulte, une seule vidéo, en bonne lumière, 11 réponses.
  • « Parle » est jugé sur une image par seconde.
  • La simulation reproduit la taille du visage, mais ni le bruit du capteur, ni la vue plongeante, ni la compression du Raspberry Pi.
  • C'est un signal clair, pas une preuve. Le test avec le vrai boîtier reste à faire.

Étude 05.5

Les erreurs corrigées

Les erreurs trouvées en chemin sont gardées et montrées. Plusieurs ont été relevées par une relecture faite avec un autre modèle d'IA ; chacune a été vérifiée dans le code avant d'être corrigée.

  1. 1

    La tête de l'enfant assis, toujours penchée

    AvantL'étude de placement gardait la tête de l'enfant assis penchée de 30° en permanence. Vu de 1,6 m, il n'était presque jamais de face : 7,9 % du temps.

    AprèsUne tête qui bouge, penchée de 18° en moyenne (± 14°) : 13,4 %, 1,9 fois mieux qu'au plafond.

  2. 2

    Le mode réduit du capteur

    AvantEn demandant du 1080p à 30 images par seconde, le logiciel aurait filmé dans le mode réduit du capteur (2 304 × 1 296) : le recadrage perdait la moitié des pixels du visage.

    AprèsLe logiciel force la pleine résolution du capteur, 4 608 × 2 592, à 14 images par seconde.

  3. 3

    La fenêtre du stand coupait les visages

    AvantLe visage d'un adulte debout se projette vers la ligne 590 du capteur ; la fenêtre fixe du stand commençait à la ligne 778.

    AprèsFenêtre remontée (environ 3 040 × 1 710 px). L'aperçu et l'enregistrement montrent exactement le même cadrage.

  4. 4

    Le comptage de la mire

    AvantUn saut de ligne dans la réponse de Gemini décalait la comparaison ligne à ligne.

    AprèsLes codes sont comparés par leur contenu.

  5. 5

    La largeur du losange

    Avant108 mm : la largeur du losange théorique, à angles vifs.

    Après91 mm, mesurés en cotant les plans : la largeur réelle du losange aux arêtes arrondies.

  6. 6

    L'étude des deux caméras

    AvantCalculée avec l'ancienne posture de tête, et un second boîtier collé au mur : 15,9 et 15,1 %.

    AprèsRefaite avec le modèle corrigé et deux boîtiers identiques : 26,8 et 25,7 %.

Refusé

Ce qui n'a pas été repris

  • Une formule de résolution « fisheye », qui surestimait les visages d'environ 30 % : l'objectif est presque rectiligne.
  • Des coefficients sans source (meubles 0,72, regard vers le parent +55 %, un enfant qui « lève la tête 70 % du temps ») et les minutes par jour qui en découlaient.
  • « 14 minutes de visage par jour » : un chiffre tiré de l'ancien modèle et d'une hypothèse de 3 h de jeu sans source. Il revient recalculé en 05.1, présenté comme un simple exemple.
  • Le flou automatique des adultes selon leur taille : un adulte assis ou accroupi passerait au travers, ce serait une fausse garantie.
  • Un recadrage fixe en 1280 × 720 sans suivi de l'enfant : il ne couvrirait pas la zone du stand.

Sources : journal de conception, étapes 12, 14, 15 et 16 ; registre des décisions (9 nov. 2026).