基于Jetson NANO与YOLOv5的智能门店访客计数系统实战

最近有个做零售的朋友找我说，门店每天想在出入口数一下客流，好算转化率。我当时第一个想到的就是用Jetson NANO来搭这套访客计数系统。这个板子虽然型号老了一点，但做边缘端的视频流目标检测和统计，性价比是真的高，一张开发板加一个普通USB摄像头就能把活干完。整套系统不光能数人数，还能区分进出方向、去掉重复计数、把数据存成报表，甚至能在本地开个网页实时看曲线。这篇文章我就把整个方案从头到尾拆开讲，包括硬件选型、环境部署、YOLOv5检测、跟踪去重、虚拟线计数逻辑，还有我在实际调试中踩过的坑。适合想入门嵌入式AI、做智能零售、或者打算在低成本设备上落地轻量视觉应用的朋友参考。

1. 系统整体设计与方案选型

1.1 需求拆解：不只是数人头

访客统计看起来简单，就是“摄像头对着门口，画面里进来一个数就加一”，但实际跑到现场会发现，需求要比这句话复杂很多。

首先你要回答几个问题：是只统计进店人数，还是进出都要统计？是否需要区分“一个人反复在门口逗留”导致的重复计数？检测到的是真人还是屏幕上的人影、推车上的模特？数据要实时看，还是每天汇总？如果同一个顾客在门口踱步三分钟再走进来，系统应该计几次？如果没有一个清晰的业务规则，后面算法写得再好看也没用。

我这边最终定的需求是：单入口门框区域，统计进入和走出两个方向的人数；去除在门口犹豫、徘徊、路过等无效目标；识别范围只覆盖门口地面和门框附近区域，不抓全店画面；数据需要实时上传到本地网页，并且每隔10分钟自动落盘一份CSV日志。

把这些规则理清楚后，整个系统的技术路线也就清楚了：视频流输入 -> 行人检测 -> 多目标跟踪 -> 进出方向判断 -> 计数去重 -> 展示和存储。

1.2 为什么选Jetson NANO而不是树莓派或云服务器

这套方案以前最常见的实现方式有两个：一个是用树莓派加普通Opencv做背景差分，但稍微复杂一点的光线变化、人员重叠就会把准确率拉到没法看的程度；另一个是把视频传上云，用云端GPU跑目标检测，但门店带宽不一定撑得住，而且每路摄像头持续推流，流量费用很快会超过设备本身。

Jetson NANO正好卡在中间。它自带128核心的Maxwell GPU，能够本地跑CUDA加速的深度学习模型，不用把视频传出去，延迟和隐私都有保障。对比树莓派4B，NANO在推理性能上有明显优势，同样是跑YOLOv5s，树莓派CPU很难达到实时处理，但NANO配合TensorRT能轻松跑到25到30FPS。对比云服务器，它是一次性硬件投入，没有后续流量费，断电重启后能自动恢复运行，非常适合长期摆在线下门店。

当然它的短板也很明显，4GB内存对现在的模型动辄几百MB权重来说确实紧张，而且CPU性能一般，很多图像预处理操作不能全指望CPU。但这些通过合理的模型选择和推理引擎优化，都是可以接受的。这套方案换到Jetson Orin NANO上也能无缝跑，而且还能留出余量给大模型部署，后面我会讲扩展方向。

1.3 整体架构与数据流

整个系统的数据流可以分成五段：

1. 图像采集：USB摄像头或CSI摄像头，分辨率我建议720P或1080P，帧率按实际检测速度来，不用无脑拉高。
2. 预处理：把摄像头帧从BGR转RGB，缩放到模型输入尺寸，做归一化。
3. 目标检测：用YOLOv5或者自己训练的行人检测模型，输出每个目标的边界框和置信度。
4. 多目标跟踪：把相邻帧的检测框关联起来，形成稳定轨迹，这样同一个目标不会每帧都重复数一次。
5. 计数决策：根据轨迹穿过虚拟线的方向，判断朝内还是朝外，进入“待确认”状态，轨迹消失或越过第二条线时提交计数。

其中最关键的是第4和第5步，检测模型选得再猛，如果没有跟踪和去重逻辑，统计出来的人数一定是虚高的。

1.4 硬件清单与选型要点

以下是我这套系统实际用到的硬件，以及选型时的注意事项：

部件	型号建议	备注
主控板	Jetson NANO 4GB B01版本	性能比早期A02强一些，内存必须4GB版
摄像头	USB免驱摄像头，支持720P/30FPS	优先选全局快门型号，避免运动拖影
存储	64GB以上TF卡或USB3.0 U盘	系统镜像加模型加日志，空间至少要留够
电源适配	5V 4A DC电源，或PoE分离线	NANO对供电非常敏感，供电不足是各种奇怪故障的元凶
散热	主动风扇加铝制散热片	满载时芯片温度会飙到85度，必须强制风冷
网络	有线网口优先	无线网卡也能用，但长期运行稳定性不如有线

摄像头的位置最好装在门正上方或者侧上角，能看到人的头顶和肩膀，这样YOLOv5的检测框和人体轮廓会比较稳定。如果装成水平视角，人脸占比大，反倒会增加检测难度。

2. 环境搭建与核心依赖部署

2.1 JetPack版本选择与系统烧录

Jetson NANO的系统不像树莓派那样随便装一个桌面版就行，它需要NVIDIA官方提供的JetPack，里面包含了Linux系统、CUDA、cuDNN、TensorRT这些基础组件。我这里用的是JetPack 4.6.1，对应的Ubuntu版本是18.04，CUDA版本是10.2，TensorRT是8.2.1。这个版本组合经过很多项目验证，踩坑最少。

烧录方式有两种。最简单的是用SDK Manager通过PC（Ubuntu主机）给NANO刷机，等于用USB线把PC和NANO连起来，SDK Manager会把系统直接写入TF卡或者eMMC模块。另一种是直接下载官方预制作的SD卡镜像，用Etcher写入TF卡。我更推荐后者，因为不需要专门一台Ubuntu电脑，Windows下也能搞定。

烧录完成后开机，进入系统先在终端里确认一下基础环境版本：

nvcc --version tensorrt --version ls /usr/lib/aarch64-linux-gnu/libcudnn*

如果这几个都能看到版本号，说明JetPack被正确刷进去了。然后设置好用户密码、网络和远程连接。

2.2 基础依赖与Python环境准备

NANO默认识别的是GPU跑CUDA，但对很多人来说，第一步先是用Python写代码，所以得先把Python环境弄好。JetPack 4.6自带的Python3.6版本比较老，但配合PyTorch官方提供的aarch64轮子，跑YOLOv5是没问题的。

先更新系统并安装常用工具：

sudo apt update sudo apt install -y python3-pip python3-dev python3-wheel git cmake libopenblas-dev

然后安装PyTorch。这一步不用去PyPI普通源装，因为在aarch64架构下官方源里很多包没有对应版本，最好用NVIDIA论坛发布的PyTorch 1.9.0 for JetPack 4.6：

pip3 install torch==1.9.0 torchvision==0.10.0

装完验证一下GPU是否识别：

python3 -c "import torch; print(torch.cuda.is_available())"

如果输出True，说明PyTorch已经把CUDA调用打通了。接着安装YOLOv5依赖，在YOLOv5源码目录下执行：

pip3 install -r requirements.txt

不过这里有个容易出问题的地方，requirements.txt里包含opencv-python，这个包在aarch64下经常编译失败或安装很慢。可以先用apt装系统级OpenCV，再从requirements里注释掉opencv那一行，这样会省很多事：

sudo apt install -y python3-opencv

2.3 YOLOv5模型准备与行人检测选择

YOLOv5官方仓库默认的模型权重是COCO数据集训练的，能检测80类物体，其中第0类就是person，所以直接用默认权重也能跑行人检测。但直接用COCO权重有两个问题：一是模型体积偏大，YOLOv5s也有14MB左右，综合速度虽然还能接受，但精度和目标范围其实没必要那么广；二是COCO对行人的检测在某些场景下容易漏检，特别是只露出半个身体、坐着、遮挡严重的场景。

建议的优化方式是只挑出person这一类，用YOLOv5的自动锚框重训练脚本在你的门店门口视角下做一轮微调。如果不想采集数据，那就直接使用默认YOLOv5s权重，配合跟踪算法，在中等密度的门店入口场景已经够用。

我实际用的是YOLOv5s，模型输入尺寸640x640，confidence阈值0.25，NMS阈值0.45。选择YOLOv5s而不是YOLOv5m或l的原因很直接：NANO的GPU算力有限，m和l在推理时FPS会掉到个位数，影响实时性。如果确实想要更高精度但不想牺牲速度，可以换YOLOv5n，这是一个更轻量的版本，速度更快但精度略低，适合人流不密集的场景。

2.4 TensorRT引擎转换

这一步是让Jetson NANO跑得更快的核心。直接用PyTorch模型在GPU上推理，YOLOv5s可能只有8到10FPS，但做了TensorRT推理引擎之后，速度能提升到25FPS以上。原理很简单，TensorRT会分析网络结构，把一些可以合并的层合并起来，同时根据GPU的算力去选择最优的kernel实现，推理阶段不再依赖PyTorch动态图。

YOLOv5官方提供了从PyTorch权重导出TensorRT引擎的脚本，最简单的方式是在YOLOv5目录下执行：

python3 export.py --weights yolov5s.pt --include engine --device 0

导出后得到的是yolov5s.engine文件，之后推理就不要再加载pt文件了，直接加载engine。engine文件是和当前TensorRT版本、当前GPU架构强绑定的，换一张Orin NANO或者升级TensorRT版本后，原来的engine文件不能直接用，必须重新生成一遍。

导出过程中常见一个坑：报错缺少库或者直接卡死。多半是因为TensorRT版本和PyTorch的安装顺序有问题，重装一下pycuda就能解决：

pip3 install pycuda

我建议在代码里动态加载engine，并做一次较长的预热循环，这样能避免第一帧推理特别慢的假象。

3. 访客计数核心逻辑实现

3.1 行人检测与跟踪：YOLOv5 + ByteTrack

检测只能回答“这一帧画面里有哪些行人”，但访客计数不能只看单帧，因为一个人连续出现在100帧画面里，如果每帧都检测到就累加，人数会爆炸。必须把不同帧里的同一个目标关联起来，这一块就是多目标跟踪。

常用的算法有DeepSORT和ByteTrack。DeepSORT依赖ReID模型提取外观特征，在密集人群场景下效果不错，但多一个模型会增加NANO的负担。ByteTrack胜在简单高效，它只用检测框之间的IoU关联，配合卡尔曼滤波预测轨迹，对大多数门店入口场景完全够用，而且它在低算力设备上跑得很轻松。

我这里采用TypeTrack的思路：先跑YOLOv5拿到每一帧所有行人检测框，然后输入ByteTrack，维护每个轨迹的ID、状态和坐标历史。ByteTrack会返回当前帧所有目标的活动轨迹ID和更新后的坐标，这样后续计数只需要基于轨迹ID做判断。

ByteTrack的安装也比较轻量，它依赖cython_bbox，在Jetson上编译可能需要先设置环境变量：

export CFLAGS="-fPIC" pip3 install cython_bbox

如果没有安装成功，也可以用纯Python方式实现一个简单的IoU匹配跟踪器，逻辑并不复杂，只是官方实现做了很多优化。对访客计数来说，一个能用卡尔曼滤波的基础Tracker足够了。

3.2 虚拟线与区域计数逻辑

计数规则怎么设计，直接决定统计数据的可信度。我的方案里没有用复杂的“进出区域面积变化法”，而是用了一条虚拟线加两个辅助框。

具体来说，在画面里设定一条水平的计数线，比如画面高度y=520像素。系统把轨迹的中心点坐标作为目标位置，每当一个轨迹的中心点从线的上方移动到下方，就判断为“进入”；反过来从下方移动到上方，就判断为“走出”。

但直接按中心点跨线有个问题：人从画面旁边路过，可能只有一只脚跨过线，或者人在线旁边晃两下，中心点来回跳动，就会误计。所以我加了两个辅助区域，分别叫Enter Zone和Exit Zone，它们分别是计数线上方和下方的窄条区域。只有当轨迹中心点在连续5帧以上都稳定处于Enter Zone或Exit Zone，并且在某一帧发生跨线，才认为是一次有效事件。

用伪代码表示：

for track in tracks: cx, cy = track.center # 判断当前坐标相对线的位置 if cy < line_y: current_side = "in" else: current_side = "out" if track.last_side is None: track.last_side = current_side if current_side != track.last_side: # 如果跨越方向为 in -> out，表示走出 if track.last_side == "in": exit_count += 1 else: enter_count += 1 track.last_side = current_side

这样即使一个目标在线附近来回试探，也只会在一段时间内记录一次有效跨线。

3.3 去重与防抖处理

在实际门店场景里，最影响统计数据质量的就是“一个人反复进出”和“检测框闪烁”。

先说检测框闪烁。当人站在门口时，YOLOv5的检测框可能忽大忽小，中心点会抖动，导致跨线判断反复触发。解决方法是引入轨迹稳定性判定。一个目标从出现到消失，至少要连续被跟踪3帧以上，才参与计数判断；如果中间有某一帧检测丢失，但预测轨迹还在，就继续保持状态，不立刻删除轨迹。

再说反复进出。有些顾客走到门口看了一眼又走了，这在业务上不应该算作进店。我会设置一条“确认线”或者在进入方向后面再画一条更深的区域，只有从外部区域连续进入内部区域，且停留时间超过1秒，才会计数。如果轨迹只是从线外到线内，又马上折返，则取消这次计数。

具体实现可以用计时器：每个轨迹维护一个状态变量，初始是“未计数”；当它跨过计数线进入店内区域后，状态变为“待确认”，记录当前时间戳；如果这个轨迹在店内区域存在超过1秒，就确认计数；如果1秒内又回到店外，就重置为“未计数”。

这么做的逻辑是，真正进店的客人不会只闪一下，而路过、探头、犹豫的人会被过滤掉。经过这个逻辑后，实测准确率比单纯跨线计数提升了差不多10个百分点。

3.4 数据存储与Web展示

访客数据除了实时看，还要能追溯。我在系统里用了一套轻量方案：数据维护在内存里，每10分钟写一次CSV，同时用Flask开一个本地网页，访问Jetson的IP地址就能看到今天的进店数、出店数和实时画面。

CSV的记录字段包括时间戳、进店数、出店数、当前在店人数、平均停留时长。当前在店人数不需要额外计算，用“累计进入数 - 累计走出数”就行，但要注意摄像头开机前已经在店内的人无法统计，所以需要在每天运营开始时手动清零或者重启服务。

Flask网页端我用的是Server-Sent Events方式把计数事件推送过去，这样前端不需要轮询，数字能实时跳。展示页面用简单HTML加一点CSS，配合一张检测画面的MJPEG视频流，可以在浏览器看到摄像头画面和画在画面上的人数框。这里有一个小技巧：MJPEG流会消耗额外解码资源和网络带宽，所以我的视频流分辨率故意降到960x540，帧率限制在5FPS，不然本地访问的人一多，Jetson会卡成PPT。

4. 性能调优与实测效果

4.1 TensorRT加速与INT8量化

前面已经提过导出TensorRT engine，但真正把NANO的性能榨干，还要做INT8量化。FP16推理其实已经比FP32快很多了，但INT8能进一步减少内存占用和计算量。

INT8量化需要准备一组代表性图片，官方脚本里叫校准数据。校准数据最好从摄像头画面里选几百张包含人物不同姿势、不同光照的帧，不要全是空背景。量化的过程其实是统计激活值的分布范围，然后映射到8bit整数范围。如果校准数据不具代表性，量化后精度可能掉得离谱，比如漏掉穿黑色衣服的行人。

我在NANO上用Pytorch转INT8 engine时，实际流程是用YOLOv5的scripts里工具跑一遍量化校准。如果用TensorRT自带的工具链，就是trtexec配合校准缓存：

trtexec --onnx=yolov5s.onnx --saveEngine=yolov5s_int8.engine --int8 --calib=yolov5s_calibration.cache

需要注意的是INT8量化后，YOLOv5某些层精度损失比较敏感，特别是小目标检测。如果发现行人的检测框变少或者置信度降得很凶，可以退回到FP16精度，有时候FP16的收益比INT8更稳。

实测下来，在我的NANO上，FP16推理单帧耗时大约35毫秒，INT8大约25毫秒，换算成FPS分别是28和40。但帧率的提升并不是线性的，因为图像采集、预处理、后处理和显示都要吃CPU和内存，实际运行时会受到制约。

4.2 散热与稳定运行

Jetson NANO满载运行时的发热量完全不能小看。我不止一次见过有人把NANO放在弱电箱里，跑了一个小时就开始掉帧、卡顿，甚至自动关机。因为芯片温度超过85度后，系统会主动降频保护，推理速度直接掉一半。

解决方法是上主动散热风扇，并且风扇不是随便接个5V常转，最好通过PWM控制，根据CPU/GPU温度调整转速。Jetson自带的风扇控制接口可以直接用GPIO，也可以买一个带调速模块的散热套件。

还有一个容易被忽略的点：供电。NANO如果通过Micro USB供电，只有5V 2A的输入能力，一旦算力拉满，电流需求会超过4A，Micro USB口很容易压降，导致系统重启。我建议用DC电源适配器直接接在NANO的DC引脚上，保证稳定5V 4A。

实际部署时，我把NANO放在门厅顶部的铝合金挡板上，周围留出10厘米以上的散热空间，夏天开一天温度稳定在70度上下，FPS基本不掉。

4.3 实测结果：FPS与准确率

我拿这套系统在一个5米宽的店铺门口测了两天，摄像头角度是斜朝下45度，光线以自然光为主，偶尔有人打伞、推婴儿车。

测试数据大致如下：

场景	实际人数	系统进店计数	系统出店计数	准确率
单人进出	47	46	46	97.9%
双人并排进入	23	22	23	95.6%
门口停留后进入	15	13	13	86.7%
推婴儿车/抱小孩	12	10	10	83.3%
背光/逆光环境	31	28	27	90.3%

单人场景表现最好，基本不会漏。双人并排偶尔会被漏掉一个，因为两个目标重叠度太高，检测框合并成了一个。推婴儿车时，有时婴儿车被当成了人，或者大人被当成非人物体，漏检多一点。逆光环境下检测整体变弱，我后面通过调曝光参数和改用带宽动态功能的摄像头后有所改善。

综合下来，误差率基本能控制在5%到15%之间，对于活动客流趋势分析来说完全够用。

4.4 不同场景的调参建议

如果是更稀疏的办公室入口，可以把检测置信度从0.25调到0.4，减少误检，人数统计会更干净；如果是拥挤的商场出入口，置信度调到0.15到0.2，避免漏检，但多目标跟踪的压力会变大，需要缩短轨迹失效时间，防止大量轨迹堆积。

摄像头角度也影响很大。理想角度是俯视45度到60度，这样人的头顶、肩膀能被完整看到，检测框高度变化比较稳定，跨线判断的误差小。如果摄像头水平正对门口，人走近时检测框会突然变大，中心点下降，容易被误判为“走出”，这就是俯视角度为什么重要的原因。

灯光方面，门口的灯最好装在摄像头侧后方，避免直射镜头。如果避不开逆光，就在代码里把图像预处理改成自适应直方图均衡化，或者直接换一颗支持宽动态的摄像头，效果提升非常明显。

5. 常见问题与排查技巧实录

5.1 Jetson NANO内存不足崩溃

这个是我遇到最多的坑。Jetson NANO只有4GB内存，而PyTorch加载模型、TensorRT推理、OpenCV图像缓冲区、多个Python进程加起来，很容易把内存吃满。表现就是命令行直接卡死，SSH连不上，或者系统会自动杀掉Python进程。

排查时先看内存占用：

free -h

如果发现可用内存不足500MB，就要开始瘦身了。常见的瘦身方法：关掉桌面环境，GNOME桌面会吃掉接近1GB内存，我直接设置开机进入多用户命令行模式，省出来的内存给推理用；YOLOv5推理时限制GPU显存分配比例，防止显存一次性占满；不要再开多个摄像头流，一个写入队列就够了。

另外建议在启动脚本里加一个看门狗，每隔30秒检测Python进程是不是还活着，如果挂掉就自动重启。配合systemd服务，可以实现无人值守。

5.2 检测框乱跳与重复计数

检测框乱跳通常有三个原因：一是模型训练场景和实际场景差别大；二是帧率太低，目标在相邻两帧的位置变化太大，跟踪跟不上；三是后处理NMS阈值设置不合理，导致同一目标产生多个重叠框。

解决方法是先把FPS稳定在15以上，否则跟踪效果很难做好。其次把ByteTrack中的框匹配IoU阈值调低一点，比如从0.2调到0.1，允许轨迹匹配到位置变化更大的检测框。还有就是检测置信度别调太低，0.2到0.3之间比较好，太低的话一个行人会被拆成两个框，因为模型的局部置信度会产生多个peak。

重复计数还跟轨迹生命周期有关。我把轨迹的最大丢失帧数从30调到了10，这样目标短暂被遮挡后重新出现，不会因为轨迹重新创建而重复计数。但代价是遮挡时间超过10帧的目标会被当成新目标，例如并排人走过去互相挡了一下，出现重复计数的概率会增加。这个需要按实际人流密度来平衡。

5.3 夜间和背光场景识别不准

夜间室外或者门内灯光强烈时，YOLOv5会很吃力。我自己遇到的问题是晚上开灯后，门口地面有白色高光，行人走过去时身体轮廓和高光混在一起，检测置信度直接掉到0.1以下。

我的解决方案分三步：第一步，把摄像头曝光模式改成手动，固定曝光度，不要让它自动追着高光调整；第二步，在预处理里增加图像增强，使用Gamma校正把暗部亮度拉高，同时压一下高光溢出；第三步，如果条件允许，在门口装一盏向地面打光的筒灯，把地面均匀照亮，而不是让灯光从背后直射摄像头。

实际调完以后，夜间检测率从50%提升到了85%左右，虽然做不到白天水平，但客流趋势已经能看出来了。

5.4 模型部署常见坑

很多初学者栽在Engine转换上。我整理几个最容易踩的坑。

第一个是onnx模型导出的opset版本。YOLOv5的export脚本默认导出opset 12，但TensorRT 8.2对高版本opset支持有些层会报错，如果转换失败，直接在export.py后面加--opset 11试试。

第二个是engine文件不匹配。把在Orin NANO上生成的engine拷贝到普通NANO上去用，加载必报错。engine文件绑定了硬件架构和TensorRT版本，必须在目标机器上现场生成。

第三个是pycuda安装失败。如果pip3 install pycuda卡很久，可以先安装libboost-python再编译，或者直接下载NVIDIA论坛里别人预编译好的whl包，省得自己折腾。

第四个是推理时出现黑白画面或错乱颜色。多半是预处理时没有把BGR转成RGB，或者归一化方式不对。YOLOv5训练时用的是RGB，0到1归一化，推理时一定要保持一致。

5.5 后续扩展：从NANO到Orin NANO与更复杂的模型

这套系统架构不只是为Jetson NANO服务的，换到Jetson Orin NANO上，整体代码不用改，只需要重新生成TensorRT engine，推理速度会有明显提升，而且运行更大的模型也没问题。

Orin NANO的算力比普通NANO高很多，除了继续跑YOLOv5，还能尝试YOLOv8甚至轻量级大模型部署。我之前用Orin NANO试过把Qwen这类小型语言模型跑在本地做数据问答，比如对着客流统计结果问“今天下午两点到三点进了多少人”，模型可以根据查询生成自然语言回答。这个方向对门店运营很有价值，相当于把“计数系统”升级成“数据助手”。

如果你现在还在用NANO，想往这个方向试，建议代码层面提前做好解耦：检测、跟踪、计数、报表这四块互相独立，后续把检测模块从YOLOv5换成YOLOv8，或者把计数模块的数据接到大模型接口，都不需要重写整个系统。

最后再分享一个小技巧：访客统计这类系统的价值不在于精确到个位数的“人数”，而在于趋势和相对变化。就算系统偶尔漏一个两个，只要误差稳定，你依然可以用它对比不同时段、不同促销活动的客流差异。所以别把精力全花在追求100%准确率上，把采集、存储、展示这条链路稳定跑起来，才是这套系统真正值钱的地方。