Vision-to-light mapping
Model probabilities and optical weights produce per-channel requests. Channel decisions depend on the full light footprint, not just a detected bounding box.
PCBA PARTNER · ENGINEERING & APPLICATIONS
Map nail regions to independently driven light channels, then combine the requested pattern with local timing, hand detection and hardware permission. An architecture for camera-guided selective illumination.
Model probabilities and optical weights produce per-channel requests. Channel decisions depend on the full light footprint, not just a detected bounding box.
Keep exposure timing, hand-presence policy and hardware gating with the local MCU. A camera result requests a pattern; it does not directly authorize light.
Use independently controlled channels for localized light patterns. Calibrate each optical path by wavelength, height and mechanical registration.
Core1106-class vision hardware provides a camera/compute branch. The local MCU handles timing and driver communication. A framed UART protocol connects them using session identifiers, frame tickets and bounded results, keeping transport errors distinct from optical decisions.
Keep the vision power branch available independently of the guarded LED power branch. A display or camera should not lose the state needed for diagnostics when lighting permission is removed.
The mapper uses a 16 × 12 probability grid. For each channel, combine nail probability with its calibrated optical weights. Compare weighted nail energy with the channel footprint energy using exact integer arithmetic. This is a model decision variable, rather than a measured skin-exposure ratio.
Use nail_energy × 1000 ≥ maximum_energy × threshold_permille with 64-bit intermediates. A 1999/2000 ratio must fail a 100% threshold even if a rounded diagnostic display shows 1000‰. Likewise, 1899/2000 must fail a 95% threshold.
Bind results to the request ticket and calibration identifier. Hand presence is a prerequisite rather than permission for every channel. Reject stale or inconsistent results; motion between capture and illumination can move a valid nail region away from the requested optical footprint.
Calibrate the camera-to-LED coordinate transform and each wavelength-specific footprint. Evaluate nail-region segmentation, hand height, curved nails, reflections and skin coverage together. Synthetic probability grids are useful for algorithm boundary tests; actual images and optical measurements answer different questions.
The 61-channel arrangement uses three PCA9956B driver devices. Apply per-channel PWM limits and local exposure limits, then combine them with IR hand detection, temperature observations and the hardware permission path. Removing any required permission returns the requested output to dark.
Evaluate 365/405 nm LED choice, optical spreading, driver current and thermal paths as one design. A LED count or electrical current alone cannot specify curing dose, uniformity or comfort. Derive the exposure sequence from the material and optical requirements.
The display branch considers RGB666: 18 data signals plus DOTCLK, HSYNC, VSYNC and DE. Match the module pinout, connector direction, I/O voltage, timing and initialization. Similar-sized screens can differ in backlight polarity and serial-control requirements.
Compare display modules as complete subsystems. A common-cathode backlight cannot automatically replace a design using four independent low-side sinks; redraw the current path and supply requirements before comparing cost.
Applications include camera-guided nail curing, localized optical tools and multi-channel illumination systems. Reusable building blocks are ticketed messaging, probability mapping, bounded channel output, freshness checking and local timing supervision.
At 1,000 units, compare compute-module variants, camera/lens, panel, optical board, thermal structure and interconnect labor. The appropriate compute configuration comes from model memory and latency, rather than automatically choosing the largest advertised RAM or NPU figure.
Editable KiCad files, firmware, algorithms, BOM tables, interfaces and technical revision documents. The complete archive stores identical bytes once; historical ZIPs are expanded into .zip.contents folders. Its included restore.py reconstructs the technical file paths.
419 files · 3.6 MiB
SHA-256 53c98e43d92414a53d5d56371369d8372c7ab707745afe6598299780782d3e5717498 files · 81.9 MiB
SHA-256 8d01eb775a94d93ab9ea4d80a05982b2ab701ad290f4e09ba2a1a2311a529d37