When a product gets eyes
Adding computer vision to a connected product is now a normal engineering project rather than a research effort, because image sensors are cheap, processors carry dedicated neural accelerators, and proven models exist for common tasks. What has not changed is that a camera turns one product into four coupled subsystems -- optics, processor, model, and enclosure -- and the single most consequential decision is whether images are analyzed on the device or in the cloud. Get that wrong and you pay for it in latency, bandwidth bills, or a privacy story you cannot defend.
What products realistically "see"
- Presence and motion classification. Person, animal, or vehicle present or absent. The foundation of security devices, occupancy-driven lighting, and energy savings, and by far the most reliable category.
- Object detection and classification. What is in the frame: a product on a shelf, a defect on a line, a material type in a recycling stream.
- Measurement and comparison. Position, size, color, completeness -- automated visual quality control against a reference.
- Reading. Barcodes, labels, license plates, analog gauges and legacy meters. Often the highest-value and lowest-risk application, because success is unambiguous.
- Higher-level analysis. Gesture recognition, posture and form monitoring for fitness or care, people counting. Technically feasible, and the category where privacy obligations bite hardest.
The architectural decision: edge or cloud
Edge processing runs inference on the device. It is fast because there is no network dependency, private because images never leave the premises, and cheap to operate because you are not paying to move video. The requirement is a processor with enough compute, and current parts deliver genuine detection within a battery-friendly power envelope. Small always-on classification can even run on a microcontroller, as covered in TinyML on microcontrollers.
Cloud processing gives you effectively unlimited compute and large models, at the price of bandwidth, latency, and a privacy conversation with every customer. It fits complex, infrequent analysis and cases where the model changes often.
The hybrid usually wins. A cheap edge stage acts as a gate -- "is anything interesting happening?" -- and only the qualifying events are escalated to the cloud for deeper analysis. This is the architecture behind most successful vision products, because it keeps continuous-monitoring cost near zero while retaining heavyweight capability for the moments that matter. Where the resulting data lands is a related design question, discussed in AI in hardware products.
Hardware decisions
Camera selection is engineering in its own right. Higher resolution is not automatically better -- it raises processing cost, power, and thermal load, and most detection tasks succeed at modest resolution. What actually determines success is lens choice and field of view, low-light sensitivity, whether infrared illumination is needed for darkness, frame rate against the speed of what you are observing, and global versus rolling shutter for fast motion.
Processor choice follows the inference workload, ranging from a microcontroller with a small neural accelerator to a dedicated edge computing module. That choice cascades into unit cost, heat, and battery life -- the trade-off is laid out in microcontroller vs. embedded Linux, and for the higher end, using a Raspberry Pi in a commercial product covers what changes when you move from prototype to production.
Two mechanical realities catch teams out. Vision processors run hot, and a sealed plastic enclosure with no airflow will throttle them -- plan for it using the principles in thermal management for electronics. And the optical window is a serious enclosure problem: it has to stay clear of scratches, fogging, dust, and internal reflections from your own indicator LEDs. Window design, gasket placement, and lens alignment belong in electronics enclosure design from the first concept, not the last revision.
The model: train or adopt?
For common tasks -- people, vehicles, faces, barcodes, standard objects -- proven pretrained models exist and you should start there. A task specific to your domain, such as your particular defect on your particular part, requires a custom dataset and training, and that is a project with its own schedule and budget: collect images from the real environment, label them, train, evaluate, and iterate.
The rule that separates working products from impressive demos: define quantitative success criteria before development starts. Required detection rate, acceptable false-positive rate per day, and the lighting and mounting conditions under which those numbers must hold. "Works in the demo" and "works in a customer's garage at dusk" are different claims, and only the second one ships.
Privacy and regulation
A product with a camera enters sensitive territory. Notice and consent expectations, encrypted storage, retention limits, and state and federal privacy rules all apply, and biometric identification -- face recognition in particular -- is subject to considerably stricter requirements in several US states. This is an overview from an engineering perspective, not legal advice; a product that identifies individuals should be reviewed by qualified counsel before launch. What engineering can contribute is architecture: edge processing that never stores or transmits images is simultaneously a technical decision, a compliance advantage, and a marketing message. Privacy compliance for connected products covers the broader landscape.
Build the camera, processor, and model as one system
Vision projects fail when the optics, the compute, and the model are specified by three people who never met. Projects House develops products that see from end to end -- lens and sensor, board and thermal design, on-device inference, and the cloud layer behind it. Tell us what your product needs to recognize through the contact form and we will define a measurable target and the architecture to hit it.