KOR'K Sensor

KOR'K Sensor 05 Engineering and calculations

Chapter 05

Engineering and calculations

Every choice in the unit rests on a calculation or a test. The five studies follow the same format: the question, the method, the assumptions, the result and its limits. The errors found along the way are shown too.

First

The limits, before the calculations

  • 13.4% of the time with a usable face: this is the result of a simulation, not a measurement.
  • The figure assumes a crop that follows the child, that of the future “bedroom” mode. Without it, it drops to less than 1%.
  • In the V1, the filmed area is fixed. The unit always crops the same square of floor: a child who leaves it is no longer seen.
  • One bias is not addressed: the interesting moments may happen precisely out of shot.
  • The “bedroom” mode (30-second chunks, sorted according to whether the child is present, with a crop that follows them) would change some of these limits. It has not been coded yet.

Sources: study 05.1 below; 06-logiciel/README.md; design journal, steps 8 and 14.

Study 05.1

Where should the unit go in the bedroom?

Question

At what height, and at what tilt, does the unit most often see the face of a playing child, while staying out of the child's reach?

Result

13.4%

of the time, the child's face is usable with the unit placed at a lens height of 1.6 m and tilted 20°. On the ceiling (2.3 m), this falls to 7.0%; without cropping on the child, to less than 1%.

Example, as an order of magnitude: if a child plays 3 h a day in the room (an unsourced assumption, to be checked with families), 13.4% represents about 24 minutes of usable face per day, with the future “bedroom” mode (planned, not coded yet). This is not a measurement.

Figure 1

Share of the time the child's face is usable, by unit height

Unit in a corner, tilted 20°. Simulation of a 3.5 × 3.5 m bedroom.

Source: KOR'K simulation, 02-modele-3d/etude-position/grille.json, corrected model of 9 November 2026. This is a simulation, not a measurement.
See the data
HeightUsable faceFloor covered (seated child)
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 (recommended)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 (ceiling)7.0%86.7%
2.4 m6.2%84.9%

Correction

7.9% → 13.4%

Corrected on 9 November 2026. The first version kept the seated child's head tilted at 30° permanently: seen from a unit at 1.6 m, the child was almost never facing it. The error was spotted in a review carried out with another AI model, then checked in the code. The unit remains 1.9 times more effective than on the ceiling. See 05.5

Figure 2

Height matters far more than tilt

Share of the time the face is usable, for 285 settings: 15 heights × 19 tilts. The darker the cell, the more often the face is legible.

Source: grille.json, same simulation (9 Nov. 2026). Hover over a cell for its value, click to set the simulator.

Figure 3
The simulator

The bedroom in 3D: set the unit, place the child

Choose the height and the tilt, seated or standing, the direction of the gaze; click on the top view to move the child. Clicking a cell in figure 2 also sets the simulator.

The simulator loads when you scroll to this point.

The same model as figures 1 and 2, recalculated in the page and checked against the Python calculation over the 285 settings (07-site-prive/outils/tests/test_chambre.mjs). The furniture is decorative: it hides nothing in the model.

And two cameras?

A second camera in the opposite corner doubles the share of the time the face is seen: 26.8% instead of 13.4%. The two cameras never see the same face at the same moment. In two adjacent corners, they overlap a little: 25.7%. It is not planned for now: it would cost about €230 more, complicate synchronisation and strengthen the impression of surveillance.

Configuration (1.6 m, 20°)Corrected modelPrevious model
1 camera in a corner13.4%7.9%
2 cameras, opposite corners26.8%15.7%
2 cameras, adjacent corners25.7%15.0%

Recalculated on 9 November 2026 with the corrected model (recherches/2026-11-09_etude-deux-cameras-corrigee.json). The earlier study reported 15.9% and 15.1%: the second unit had lost its 9 cm setback from the wall. Once corrected, the previous model gives 15.7% and 15.0%, which does not change the conclusion.

Detail

See the method

Method

A simulation in Python. A child is placed every 10 cm in the bedroom, facing 36 directions, seated or standing, and the share of cases in which the face is usable is counted. This is repeated for 15 heights (from 1.0 to 2.4 m) and 19 tilts (from 0 to 45°).

Assumptions

  • Square bedroom of 3.5 × 3.5 m. Unit in a corner, lens 9 cm from the walls, facing the centre of the room.
  • Camera Module 3 Wide: 102° horizontally, 67° vertically (official datasheet).
  • Cropping on the child: the fineness of the 12 MP sensor is kept (4,608 px across 102°).
  • Child aged 2 to 7, always more than 30 cm from the walls: seated on the floor 60% of the time (face at 0.55 m, head tilted by 18° on average, standard deviation 14°), standing 40% of the time (face at 0.95 m, head tilted by 10°).
  • Usable face: within the field of view, seen at less than 45° from front-on, and at least 48 px wide (for a 12 cm face).

Figures

SettingUsable faceFloor coveredBlind zone at the foot of the corner
1.6 m, 20° (recommended)13.4%96.9%0.78 m
1.6 m, 37.5° (best setting, out of reach)13.4%99.9%0.36 m
1.7 m, 20°12.5%96.0%0.85 m
Ceiling, 2.3 m, 20°7.0%86.7%1.29 m
1.0 m, 25° (within a child's reach)19.4%100%0.28 m
1.7 m, 25°, no cropping1.0%97.7%0.70 m
1.6 m, 20°, previous model (head fixed at 30°)7.9%——

Source: recherches/2026-11-09_etude-placement-resultats-corrigee.json. “Floor covered”: the share of the room where a seated child is within the field of view. “Blind zone”: the distance from the corner within which a seated child falls outside the field of view.

Why 20° rather than 37.5°

At 1.6 m, the tilt changes the result very little between 7.5° and 40°. 20° is kept, the angle of the design, which sees the body of a seated child from 0.78 m from the corner. The 37.5° setting reduces the blind zone to 0.36 m: this is a lead for V2.

Limits

  • A simplified model, not a measurement: no furniture, no body hiding the face, a single typical bedroom.
  • Head posture (18° on average) is an assumption. It will be checked with the real unit, after assembly.
  • The 48 px threshold is a working threshold adopted for the model, with no published reference.
  • The figure says how long the face is legible, not what the analysis makes of it.

Files

02-modele-3d/etude-position/etude_position.py, grille.json, etude_deux_cameras.py; design journal, steps 8, 10 and 14.

Study 05.2

How many pixels on a face?

Question

How many pixels does a child's face occupy in the image, and is a more powerful computer needed to get enough?

Result

74.6 px

across a face at 3 m, cropping within the full 12 MP sensor. With the full 1080p image, only 31.1 px, below the working threshold of 48 px. This real-time cropping requires a Raspberry Pi 5; the Zero 2 W planned at the outset was incapable of it, and it was out of stock almost everywhere anyway.

Diagram

The sensor: 4,608 × 2,592 pixels, 102° wide kept part, pixel for pixel pixels grouped by 4: 2,304 px wide whole image scaled down to 1,920 px wide

0 px

Calculation: the same formula as figure 4, for a 12 cm face. The face is drawn for illustration; the 48 px threshold is a working threshold. Specifications: official Camera Module 3 Wide product brief (raspberrypi.com, 9 Nov 2026).

Figure 4

Width of a 12 cm face in the image, by distance

Three ways of filming with the same camera (Camera Module 3 Wide, 102° horizontally).

Calculation: width in pixels = sensor pixels × 0.12 m ÷ (2 × distance × tan 51°). Specifications: official datasheet of the Camera Module 3 Wide (raspberrypi.com, accessed 9 Nov. 2026). The “binned mode” is the one the software would have used by mistake (05.5).
  • Full sensor, cropped on the child (Pi 5)
  • Binned sensor mode (2,304 px wide)
  • Full 1080p image (no cropping)

Detail

See the calculation

Calculation

pixels on the face = image width in pixels × 0.12 m ÷ (2 × d × tan(102° ÷ 2))

With cropping, the image keeps the fineness of the full sensor: 4,608 px for 102°. Without cropping, a 1080p image has only 1,920 px for the same field of view.

Values

DistanceCropped sensorBinned modeFull 1080p
1.5 m149 px75 px62 px
2.0 m112 px56 px47 px
2.7 m83 px41 px35 px
3.0 m75 px37 px31 px

These are also the values that test M1 will check on the real camera, with a 12 cm disc photographed at 1.5, 2, 2.7 and 3 m (checklist in the plans).

Choosing the Raspberry Pi 5

Raspberry Pi 5 with 4 GB, at €136.80 (price noted on 9 Nov. 2026, sharply up with the price of memory). It did not fit lying flat against a wall: it sits on the axis, behind the camera, and the unit comes to 12.4 cm along the walls. Discarded: the Zero 2 W, two cameras, a low-light sensor (IMX585) with an unofficial driver.

Limits

  • The lens is assumed rectilinear: towards the edges of the image, a wide-angle lens stretches faces slightly.
  • Blur, noise and compression reduce the real sharpness: the pixel count is an upper bound.
  • The 48 px threshold is a working threshold, with no published reference.

Study 05.3

Exposure and fixed focus

Question

What exposure time limits motion blur when the child moves, and can autofocus be dispensed with?

Result

1/50 s

at most: the software aims for about 1/100 s and, in the dark, raises the gain rather than the exposure time

0.71 m → ∞

everything is sharp with the focus fixed at 1.7 m: no autofocus “hunting”

Table

Motion blur, in sensor pixels, for a face at 2 m

By exposure time and speed of movement. The speeds are examples, not measurements.

Exposure time0.2 m/s0.5 m/s1.0 m/s
1/30 s6 px16 px31 px
1/50 s (ceiling)4 px9 px19 px
1/100 s2 px5 px9 px
1/125 s1 px4 px7 px

Calculation: blur = speed × exposure time × 933 px per metre at 2 m. Software settings: decisions register (9 Nov. 2026).

Detail

See the calculation

Motion blur

blur (px) = speed (m/s) × exposure time (s) × focal length in pixels ÷ distance (m)

The focal length in pixels is 4,608 ÷ (2 × tan 51°) ≈ 1,866 px. At 2 m, a movement of one metre therefore covers about 933 px of the sensor. The compromise adopted: about 1/100 s, never more than 1/50 s; beyond that, it is the gain that rises, with slightly more noise in the evening. Forcing 1/125 s would have swamped the image in noise in a dimly lit bedroom.

Depth of field

H = f² ÷ (N × c) + f ≈ 1.23 m

With f = 2.75 mm, N = 2.2 and a circle of confusion c of 2 pixels (2.8 µm), the hyperfocal distance H is about 1.23 m. With the focus set at 1.7 m, beyond H, everything is sharp from about 0.71 m to infinity. A fixed focus is therefore enough for the whole bedroom.

Specifications of the Camera Module 3 Wide (focal length 2.75 mm, aperture F2.2, 1.4 µm pixels): official Raspberry Pi documentation, accessed 9 Nov. 2026.

Limits

  • Calculation added on 9 November 2026, to be confirmed by test M2 (blur and evening light, around 100 lux) on the real camera.
  • A circle of confusion of 2 pixels is a choice; with a stricter one, the sharp zone starts further away.
  • The clip sent is reduced to 1,920 px wide: blur looks slightly smaller there than in sensor pixels.

Study 05.4

What Gemini really sees

Question

What image does the analysis model really receive, and is the default setting enough to read an expression?

Result

11 / 11

correct answers in HIGH, in every condition tested, against 9 to 11 in LOW. On a test chart, HIGH reads text 2.5 times smaller and invents no codes; in LOW, the model invents some despite the instruction “do not guess”.

Figure 5
The test chart

Smallest text read on a chart of codes

4K video of codes from 8 to 60 px, sent whole or cropped to 1280 × 720.

Source: recherches/2026-11-09_test-gemini-mire.json, model gemini-3.1-flash-lite (the one in the KOR'K Scan backend), 9 Nov. 2026.
See the data
TrialSmallest text readCorrect linesInvented codesVideo tokens per secondResponse time
Whole image, LOW42 px31662.7 s
Whole image, HIGH17 px802642.4 s
1280 × 720 crop, LOW14 px93661.8 s
1280 × 720 crop, HIGH8 px1202641.4 s

The test chart: lines of alphanumeric codes of decreasing size.
The test chart used: twelve lines of codes, from 60 to 8 px high. No one is filmed: the measurement is objective.

Figure 6
The video

Correct answers on a real video, LOW against HIGH

An adult filmed following a scenario, 4 sharp moments, 11 answers (gaze, expression, hands). What the Sensor would deliver is simulated at 2 m and at 2.7 m.

Source: recherches/2026-11-09_test-gemini-video-adulte.json and verite-video-adulte.json, 9 Nov. 2026. The backend's default setting gives the same result as LOW.
See the 11 trials
TrialCorrectWrongVideo tokens per second
Phone, default setting10 / 11191
Phone, LOW10 / 11191
Phone, HIGH11 / 110289
Sensor fixed zone at 2.0 m, LOW9 / 11291
Sensor fixed zone at 2.0 m, HIGH11 / 110289
Sensor tracking at 2.0 m, LOW11 / 11091
Sensor tracking at 2.0 m, HIGH11 / 110289
Sensor fixed zone at 2.7 m, LOW10 / 11191
Sensor fixed zone at 2.7 m, HIGH11 / 110289
Sensor tracking at 2.7 m, LOW11 / 11091
Sensor tracking at 2.7 m, HIGH11 / 110289

Cost

91 → 289

tokens per second of video, from LOW to HIGH (×3.2)

66 → 264

tokens per second on the test chart

1.4 to 2.7 s

per answer: HIGH is no slower

Decisions

  • At the Nuremberg stand: a fixed zone, sent in HIGH. No framing that follows the person: it adds nothing more in HIGH in this test.
  • Later, the “bedroom” mode: a 1280 × 720 crop that follows the child; LOW is enough there in this test, with 3.2 times fewer tokens, to be evaluated.
  • For KOR'K Scan: explicitly switch all videos to HIGH, after the new version of the analysis has been evaluated.

Detail

See the method

Method

The gemini-3.1-flash-lite model receives the same video with two resolution settings: LOW (the default setting, about 70 tokens per frame) and HIGH (about 280). The test chart measures the smallest text read; the video of an adult, whose answers are known in advance, measures what matters for KOR'K: gaze, expression, hands. The test chart count compares the codes by their content.

What this shows

  • The reading threshold follows the width of the image: about 1.1% of the width in LOW, 0.45% in HIGH. Gemini therefore reduces every video to a fixed size, about 2.5 times finer in HIGH. The internal sizes (about 384 and 900 px wide) are a deduction, not a measurement.
  • Cropping in LOW is as good as the full image in HIGH, for four times fewer tokens.
  • All the errors in LOW concern expression: “speaking” and “smiling” read as “neutral”.

Limits

  • A single adult, a single video, in good light, 11 answers.
  • “Speaking” is judged on one frame per second.
  • The simulation reproduces the size of the face, but neither the sensor noise, nor the high-angle view, nor the compression of the Raspberry Pi.
  • This is a clear signal, not proof. The test with the real unit remains to be done.

Study 05.5

Errors corrected

The errors found along the way are kept and shown. Several were spotted in a review carried out with another AI model; each was checked in the code before being corrected.

  1. 1

    The seated child's head, always tilted

    BeforeThe placement study kept the seated child's head tilted at 30° permanently. Seen from 1.6 m, the child was almost never facing the unit: 7.9% of the time.

    AfterA moving head, tilted by 18° on average (± 14°): 13.4%, 1.9 times better than on the ceiling.

  2. 2

    The binned sensor mode

    BeforeBy requesting 1080p at 30 frames per second, the software would have filmed in the sensor's binned mode (2,304 × 1,296): cropping lost half of the pixels on the face.

    AfterThe software forces the sensor's full resolution, 4,608 × 2,592, at 14 frames per second.

  3. 3

    The stand window cut off faces

    BeforeThe face of a standing adult projects towards line 590 of the sensor; the stand's fixed window started at line 778.

    AfterWindow moved up (about 3,040 × 1,710 px). The preview and the recording show exactly the same framing.

  4. 4

    The test chart count

    BeforeA line break in Gemini's response shifted the line-by-line comparison.

    AfterThe codes are compared by their content.

  5. 5

    The width of the diamond

    Before108 mm: the width of the theoretical diamond, with sharp angles.

    After91 mm, measured while dimensioning the plans: the real width of the diamond with rounded edges.

  6. 6

    The two-camera study

    BeforeCalculated with the old head posture, and a second unit flush against the wall: 15.9% and 15.1%.

    AfterRedone with the corrected model and two identical units: 26.8% and 25.7%.

Rejected

What was not adopted

  • A “fisheye” resolution formula, which overestimated faces by about 30%: the lens is almost rectilinear.
  • Coefficients with no source (furniture 0.72, gaze towards the parent +55%, a child who “looks up 70% of the time”) and the minutes per day that followed from them.
  • “14 minutes of face per day”: a figure drawn from the old model and from an unsourced assumption of 3 h of play. It comes back recalculated in 05.1, as a simple example.
  • Automatic blurring of adults according to their height: a seated or crouching adult would slip through, which would be a false guarantee.
  • A fixed 1280 × 720 crop without tracking the child: it would not cover the stand's zone.

Sources: design journal, steps 12, 14, 15 and 16; decisions register (9 Nov. 2026).