The RK3588 combines four Cortex-A76 cores, four Cortex-A55 cores, a 6 TOPS NPU, and camera interfaces on one SoC. That is enough hardware to capture a room, run a person-detection model locally, and send a small occupancy count to a building controller instead of streaming video to a server.
Local processing is the useful part here. It cuts network traffic, keeps the system working when the internet connection drops, and gives the designer a chance to discard frames as soon as inference finishes. But an NPU and a camera do not automatically make a reliable occupancy sensor. Placement, model conversion, lighting, privacy rules, and the control logic after detection matter just as much.
Table of Contents
- From Sensor to Edge AI System
- What the RK3588 Runs
- RK3588 or Intel N100?
- Optimize the Pipeline, Not Just the Model
- Privacy and Reliability
- FAQ
From Sensor to Edge AI System
A conventional PIR unit answers a fairly narrow question: did a warm object move across its detection zones? An AI camera can estimate how many people are present, where they are standing, and whether someone remains seated with very little movement. Those are different jobs, so it helps to understand what an occupancy sensor does before replacing one with a camera and a neural network.
The camera approach is useful in meeting rooms, shops, entrances, and open offices where a simple motion event is not enough. A building system might need a headcount for ventilation, a direction of travel for an entrance counter, or zone-level presence for lighting. A PIR sensor cannot provide that data. A camera model can, although it brings more compute, setup work, and privacy responsibility with it, which is why many turn to people counting solutions.
And the camera does not have to work alone. Door contacts, PIR, mmWave radar, CO2 sensors, or badge events can act as additional signals. The RK3588 then becomes the local decision point: it receives sensor events, checks the vision result, applies timeouts and thresholds, and publishes the final state over MQTT, BACnet, Modbus, or another interface used by the building controller.
What the RK3588 Runs
A basic vision pipeline has four stages: capture a frame, resize and normalize it, run inference, then track or count the detections. Linux exposes USB and supported MIPI cameras through its media stack, while the board vendor’s image and drivers determine which camera modes and hardware paths actually work. That last detail is easy to miss. The SoC may support multiple camera inputs, but the connector layout and software support belong to the board.
The model also needs to reach the Rockchip NPU in a supported form. In practice, that usually means exporting a trained model, converting it for the RKNN runtime, and checking every operator during conversion. A model that runs under PyTorch or ONNX on a workstation is not automatically ready for the NPU. Unsupported layers may require a replacement, a different model version, or CPU fallback.
Quantization is where much of the practical work happens. INT8 can reduce model size and improve inference throughput, but a poor calibration set can damage accuracy in the exact conditions that matter: dim rooms, partial occlusion, unusual camera angles, or dense groups near a doorway. The correct test is not whether the converted model launches. It is whether counting errors remain acceptable on footage from the intended installation.
The NPU should handle the neural network while the CPU takes care of capture, tracking, rules, networking, and logging. This separation leaves considerably more CPU time than running the entire detector on the Cortex cores. It also means that a quoted 6 TOPS figure is not a system benchmark. Preprocessing, memory copies, tracker cost, camera resolution, and model compatibility can still set the real frame rate.
RK3588 or Intel N100?
An Intel N100 box is a reasonable alternative, especially when the deployment depends on x86 packages, Windows, or an existing OpenVINO application. The RK3588 has the integrated NPU and more embedded camera options, while the N100 offers a familiar PC software environment. Our RK3588 vs Intel N100 comparison covers the broader CPU, media, expansion, and software differences.
For a dedicated appliance that receives one or more camera feeds and publishes occupancy metadata, the RK3588 is often the more interesting starting point. For a small server that also runs unrelated x86 services, the N100 may take less integration work. There is no useful answer based on CPU benchmark charts alone because the RK3588 design only pays off when the application can use its NPU and media hardware.
Optimize the Pipeline, Not Just the Model
Measure each stage before changing code. Frame capture may be waiting on a driver, image conversion may be copying full buffers, and post-processing may spend more time on non-maximum suppression than the NPU spends on inference. Lowering the input resolution or removing one memory copy can matter more than replacing a block of C++ with hand-written assembly.
The Cortex-A76 and Cortex-A55 cores support Arm Neon SIMD, so CPU-side image conversion and array operations can benefit from vectorized libraries, compiler intrinsics, or carefully optimized code. Direct assembly is the last step, not the first. Developers who need to inspect generated instructions or tune a proven hotspot can use our ARM assembler programming guide, but most projects should start with profiling and Neon-aware libraries.
Privacy and Reliability
Processing at the edge does not make a camera private by itself. A sensible design keeps raw frames in memory only as long as necessary, disables recording unless it has a defined purpose, restricts access to debug streams, and sends counts or zone events rather than images. Device credentials, signed updates, and a documented retention policy are part of the system too.
Reliability needs a similarly plain approach. Test empty rooms, seated occupants, cleaning staff, reflections, changing daylight, and people entering side by side. Decide what happens if the camera fails or the model stops producing results. Lighting and HVAC controls should fall back to a safe state, and a local health signal should tell the controller that the count is stale.
The RK3588 is a strong base for edge AI occupancy detection when the system needs local vision, several sensor inputs, and no continuous video stream to the cloud. Its 6 TOPS NPU is useful, but the finished product will be judged by missed people, false counts, recovery after faults, and the amount of private data it exposes – not by the TOPS number on the product page.
FAQ
Can RK3588 run occupancy detection without the cloud?
Yes. Camera capture, model inference, tracking, and counting can run locally. A network connection may still be used for dashboards, software updates, or sending occupancy metadata to another controller.
Is 6 TOPS enough for people counting?
It can be enough for compact detection models and practical camera resolutions, but TOPS alone does not predict frame rate. Model architecture, quantization, preprocessing, memory movement, and the number of streams all affect performance.
Does edge processing solve camera privacy concerns?
It reduces exposure when raw images stay on the device and are discarded promptly. The system still needs access control, secure updates, clear retention rules, and an installation policy appropriate for the building.
Should I choose RK3588 or Intel N100?
Choose based on the software and I/O. RK3588 suits an embedded design that can use the NPU and camera interfaces; N100 suits software that depends on x86 compatibility or a conventional PC environment.
Sources
