企业官网建设流程全解析

基于 Ultralytics YOLO26 的实时队列管理与区域人数统计实战

【免费下载链接】ultralyticsUltralytics YOLO26, YOLO11, YOLOv8 — object detection, instance segmentation, semantic segmentation, image classification, pose estimation, object tracking项目地址: https://gitcode.com/GitHub_Trending/ul/ultralytics

队列管理（Queue Management）是指借助 Ultralytics YOLO26 对排队区域内的行人（或车辆）进行持续检测与跟踪，从而实时掌握队列长度、辅助优化等候流程的计算机视觉方案。本文以官方指南 queue-management.md 为骨架，结合仓库中 QueueManager 实现 与底层 solutions.py、config.py 源码，完整讲解该方案的概念、优势、CLI/Python 用法、全部可调参数、内部计数原理与落地实践建议，读完即可在零售收银台、机场值机、银行网点、医院候诊等场景搭建一套可运行的实时队列监控应用。

什么是实时队列管理

队列管理本质上是对"排队区域"的智能监控：让摄像头持续捕捉等候区画面，由 YOLO 模型识别画面中的人/车辆，配合多目标跟踪（MOT）维持每个目标的身份 ID，最终统计出当前仍停留在划定区域内的目标数量，即实时的队列长度。其核心目标是通过量化排队过程来缩短等待时间、提升运营效率，并改善顾客满意度。

在 Ultralytics 中，这一能力被封装为solutions.QueueManager，属于仓库ultralytics/solutions解决方案族中的一员，与目标计数（ObjectCounter）、区域计数（RegionCounter）、人群密度热力图（Heatmap）等方案共用同一套基座。它不是简单地每帧检测一遍人数，而是基于跟踪轨迹判断目标当前是否处于排队区域内，因此能在人员走动、进出区域的真实场景下给出稳定的队列占用数。

队列管理带来的核心价值

围绕排队场景，YOLO26 驱动的队列管理方案主要提供四方面价值：

• 显著降低等待时间：系统化地组织与管理队列，让顾客把时间花在服务与商品上而不是排队上，从而提升满意度。
• 提升运营效率：通过队列长度数据合理调配人员与资源，优化排班，降低人力成本并提升整体生产力。
• 实时数据洞察：逐帧输出队列人数，为管理者提供即时、可量化的决策依据，例如何时增开收银台。
• 改善顾客体验：缓解长时间等待带来的焦躁情绪，帮助企业提升客户满意度和忠诚度。

值得强调的是，文档中的"等待时间"更多是一个管理视角的衡量指标——严格来说本方案直接给出的是区域内目标数量（live queue length），等待时间可通过记录目标进出区域的时刻进一步推导，相关结果字段定义可参见下方"结果对象"小节。

实时队列管理的典型应用场景

该方案在文档中被定位为跨行业的通用能力，典型场景包括：

• 零售 / 商超：监控收银台结账队伍长度，及时增开窗口，缩短结账等待；
• 机场 / 交通枢纽：值机柜台、安检口等关键节点的排队疏导；
• 医疗 / 银行：门诊候诊、柜台叫号等场景的人流组织与动态调配。

用 QueueManager 实现实时队列管理

QueueManager的核心工作方式是：为等候区域划定一个多边形 ROI，逐帧统计"仍然停留在这个多边形内部"的跟踪目标数量，并把实时队列数绘制到输出画面上。你可以通过 CLI 或 Python API 两种方式驱动它。

方式一：CLI 命令行

仓库通过yolo solutions子命令统一分发各类解决方案，queue在 解决方案注册表 中被映射到QueueManager类，因此可以直接执行：

# 运行一个队列管理示例（未指定 source 时会自动下载并播放演示视频） yolo solutions queue show=True # 指定自己的视频文件作为输入源 yolo solutions queue source="path/to/video.mp4" # 显式传入排队区域坐标（四边形的四个角点） yolo solutions queue region="[(20, 400), (1080, 400), (1080, 360), (20, 360)]"

需要注意以下几点 CLI 行为（均来自源码可验证的实现事实）：

• 当is_cli=True且未提供source时，BaseSolution 会从 Ultralytics 官方资源下载solutions_ci_demo.mp4作为默认演示视频；
• CLI 模式下处理完成的结果视频默认写入runs/solutions/exp目录（参见 cfg/init.py 中对解决方案任务保存目录的创建逻辑）；
• region参数在 CLI 中直接以 Python 字面量语法传递坐标点列表，yolo solutions的用法帮助文本中也给出了相同格式的示例（见 cfg/init.py）。

方式二：Python API

Python 方式便于与自己的采集、存储或告警系统集成，官方文档给出如下可直接运行的完整脚本：

import cv2 from ultralytics import solutions cap = cv2.VideoCapture("path/to/video.mp4") assert cap.isOpened(), "Error reading video file" # 视频写出器 w, h, fps = (int(cap.get(x)) for x in (cv2.CAP_PROP_FRAME_WIDTH, cv2.CAP_PROP_FRAME_HEIGHT, cv2.CAP_PROP_FPS)) video_writer = cv2.VideoWriter("queue_management.avi", cv2.VideoWriter_fourcc(*"mp4v"), fps, (w, h)) # 定义排队区域（四边形的四个角点） queue_region = [(20, 400), (1080, 400), (1080, 360), (20, 360)] # region points # queue_region = [(20, 400), (1080, 400), (1080, 360), (20, 360), (20, 400)] # polygon points（首尾闭合写法） # 初始化队列管理器 queuemanager = solutions.QueueManager( show=True, # 弹窗显示处理结果 model="yolo26n.pt", # YOLO26 nano 模型文件 region=queue_region, # 排队区域坐标点 ) # 逐帧处理视频 while cap.isOpened(): success, im0 = cap.read() if not success: print("Video frame is empty or processing is complete.") break results = queuemanager(im0) # print(results) # 可通过字符串打印查看队列数等结果字段 video_writer.write(results.plot_im) # 把标注后的帧写入输出视频 cap.release() video_writer.release() cv2.destroyAllWindows() # 关闭所有打开的窗口

代码中QueueManager是可直接调用的对象：每次queuemanager(im0)等价于触发其父类BaseSolution.__call__，内部按顺序执行"跟踪（track）→ 解决方案处理（process）→ 返回SolutionResults"，并自动记录跟踪与处理各自的耗时（见 solutions.py）。

区域坐标的两种写法

从 queue_management.py 的注释可以看到区域既可以用不闭合的四边形点列给出，也可以写成首尾闭合的多边形点列。QueueManager构造时会调用initialize_region()（见 solutions.py）：当点数 ≥ 3 时用 shapely 的Polygon建立多边形；点数不足 3 时退化为LineString线段。而队列计数要求"目标处于区域内"，因此排队区域请务必提供 ≥ 3 个点构成多边形，两点的直线区域不会被计入队列数（详见"内部原理"小节）。

QueueManager 参数详解

官方文档通过宏渲染参数表，仓库中对应宏源文件为 docs/macros/solutions-args.md、docs/macros/solutions-track-args.md 与 docs/macros/visualization-args.md。这些参数的默认值最终都落在统一配置类 SolutionConfig 中，任何非法参数名都会被update()拒绝并抛出ValueError（config.py）。

核心构造参数

跟踪相关参数

QueueManager内部逐帧调用self.model.track(...)，跟踪参数经由track_add_args转发（solutions.py），官方文档列出以下最常用的五个：

其余同样会传给跟踪器的底层参数还包括max_det（默认300，每帧最大检测数）与imgsz（默认640，推理输入尺寸），它们一并出现在track_add_args中。跟踪器配置 YAML 存放于 ultralytics/cfg/trackers 目录，可整体定制如deepocsort.yaml、fasttrack.yaml等算法以权衡精度与速度。

可视化参数

标签的具体拼接逻辑见 adjust_box_label：当show_labels=False时标签整体不绘制；否则显示格式为track_id 类别名 置信度（类别名与置信度是否展示分别受show_labels、show_conf控制）。

结果对象字段

官方文档的示例脚本通过results.plot_im取得标注画面。除此之外，QueueManager.process返回的SolutionResults（solutions.py）还携带结构化数据，可直接用于业务逻辑：

• plot_im：携带队列数文字与检测框标注的当前帧；
• queue_count：当前帧位于排队区域内的目标数量；
• total_tracks：当前帧被跟踪到的目标总数；
• speed：{"track": ..., "solution": ...}毫秒耗时，用于性能监控。

内部原理：队列人数是如何逐帧算出来的

理解计数逻辑有助于正确地布置区域与解读结果。在 queue_management.py 的 process 方法 中，每帧处理流程如下：

1. 重置本帧计数：self.counts = 0，保证队列数是"当前这一帧的实况值"而非累计值。

2. 跟踪并抽取轨迹：调用extract_tracks(im0)（solutions.py），内部执行model.track(source=im0, persist=True, classes=..., verbose=False, ...)，随后取出每帧的目标框boxes、类别clss、跟踪 IDtrack_ids、置信度confs；若没有跟踪结果则清空上述列表并告警No tracks found.。

3. 记录跟踪历史：对每个目标以track_id为键追加其边界框中心点到track_history，历史保留最近 30 个点，超出即丢弃最旧点（solutions.py）；同时会清理已被跟踪器标记移除的 ID（forget_tracks）。

4. 判断是否在区域内：计数条件见 queue_management.py：

   • 区域点数region_length >= 3（必须构成多边形）；
   • 该目标已存在历史轨迹（len(track_history) > 1，即至少连续两帧被跟踪到，用于滤除单帧闪过的误检）；
   • 该目标当前帧中心点self.track_line[-1]落在由 shapelyprep预处理的Polygon内（self.r_s.contains(...)）。

   三者同时满足才self.counts += 1。

5. 绘制与返回：用SolutionAnnotator绘制区域边框与角点（draw_region），并在区域几何中心以带背景的色块叠加Queue Counts : {counts}文案（queue_counts_display），最后封装成SolutionResults返回。

由此可以推导出该方案的几个使用要点：

• 结果是"此刻区域内目标数"：每帧重置，适合判断"现在排了几个人"，不适合表达"今天共服务了多少人"（累计统计请参考 solutions/index.md 中的计数类方案）；
• 跟踪质量决定准确性：区域判定依赖稳定的 track ID，频繁遮挡或镜头抖动会造成 ID 切换（track_id 变化），因此参数表中tracker、conf、iou的选择会直接影响队列数的可靠性；
• 依赖shapely几何库：构造任何 Solution 时都会执行check_requirements("shapely>=2.0.0")（solutions.py），运行前请确保该依赖已安装。

实施落地最佳实践

官方文档给出的四条策略是保证现场效果的关键：

1. 科学布设摄像头：机位应能完整无遮挡地覆盖整个队列区域，避免柱子、柜台等造成目标"断跟踪"。
2. 合理划定排队区域：依据空间实际布局小心设定区域边界。区域应贴合真实的排队通道，宁可略窄于通道也不要跨到无关过道，否则会把路人计入队列。
3. 微调置信度阈值：根据光照条件与人群密度调整conf。灯光昏暗、相互遮挡严重的场景可适度调低以召回更多目标，同时用classes过滤掉非目标类别。
4. 对接既有业务系统：将实时队列数接入数字标牌、员工值班提醒或工单系统，实现"队列过长自动开窗/自动通知"的闭环响应。

常见问题（FAQ）

1. 如何用 YOLO26 做实时队列管理？

按官方文档的推荐步骤：加载模型 → 读取视频流 → 划定 ROI → 逐帧推理。下面是精简版最小示例：

import cv2 from ultralytics import solutions cap = cv2.VideoCapture("path/to/video.mp4") queue_region = [(20, 400), (1080, 400), (1080, 360), (20, 360)] queuemanager = solutions.QueueManager( model="yolo26n.pt", region=queue_region, line_width=3, show=True, ) while cap.isOpened(): success, im0 = cap.read() if success: results = queuemanager(im0) # results.queue_count 即当前队列人数 cap.release() cv2.destroyAllWindows()

如需把方案进一步产品化（模型托管、数据集管理、在线部署），官方文档建议结合 Ultralytics Platform；方案总览可参见 solutions/index.md，上手安装流程参见 quickstart.md。

2. 相比传统检测方案有什么优势？

文档从方案收益角度归纳为四点：显著缩短等待时间（高效组织队列、降低顾客排队时长）、提升运营效率（用队列数据分析优化人力配置、降低成本）、实时告警（队列过长即时通知以便快速干预）、易于扩展（同一套方案可复制到零售、机场、医疗等不同环境）。从实现层面看，这些优势的基础是"检测 + 跟踪 + 区域判定"的一体化封装：模型缺省即为yolo26n.pt，无需单独搭建跟踪器，verbose=True时每帧还会输出处理耗时与类别计数日志，便于量化性能。

3. QueueManager 能应对不同形态的队列吗？

可以。机场、零售、医院等场景的差异主要体现在区域形状与业务参数上，而不需要改代码。例如文档中机场值机场景的写法：

queue_region_airport = [(50, 600), (1200, 600), (1200, 550), (50, 550)] queue_airport = solutions.QueueManager( model="yolo26n.pt", region=queue_region_airport, line_width=3, )

从源码角度可补充说明：区域点数不同只会影响几何类型（多边形 vs 直线），≥3 点即构成可用于队列计数的多边形，因此四边形、五边形甚至更贴合现场的多边形点列均可直接传入；配合conf、classes、tracker等参数即可适配不同密度与布局。

4. 单帧无目标时会发生什么？

不会崩溃。当视频读取出错时 Python 示例通过if not success: break主动跳出；当某一帧跟踪不到任何目标时，extract_tracks 会把boxes/clss/track_ids/confs清空，counts保持为 0，程序继续处理后续帧，保证长时间运行的稳定性。同时注意区域外的目标不会被计数，但会正常显示检测框（这类目标不计入queue_count，只计入total_tracks）。

小结

本文基于 docs/en/guides/queue-management.md 及其配套源码完整梳理了 Ultralytics 队列管理方案的落地路径：先用 CLIyolo solutions queue或 Pythonsolutions.QueueManager快速跑通，再通过model/region/line_width/verbose、跟踪参数（tracker/conf/iou/classes/device）与可视化参数（show/show_conf/show_labels）做精细化调优，最后结合逐帧"区域包含判定"的内部机制理解数据的真实含义。掌握这些内容后，你可以在多种排队场景中独立搭建并调优一套实时、可量化的队列监控系统。

【免费下载链接】ultralyticsUltralytics YOLO26, YOLO11, YOLOv8 — object detection, instance segmentation, semantic segmentation, image classification, pose estimation, object tracking项目地址: https://gitcode.com/GitHub_Trending/ul/ultralytics