1. 项目缘起：从一次深夜的担忧到技术方案的落地

那天晚上，家里的监控摄像头推送了一条异常提醒。画面里，独居的父亲在客厅里踉跄了一下，虽然最终扶住了沙发，但那个瞬间让我后背发凉。我意识到，对于独居或行动不便的老人来说，一次不经意的摔倒，如果没能被及时发现，后果可能是灾难性的。市面上的智能摄像头虽然能提供实时画面，但依赖人工24小时盯着屏幕显然不现实；而一些所谓的“跌倒检测”产品，要么价格昂贵，要么误报率极高，实用性大打折扣。

作为一名长期在AI和嵌入式领域折腾的开发者，我决定自己动手，打造一个真正可靠、可负担、且能灵活扩展的智能监控助手。这就是“ClawVision · 守护眼”项目的起点。它的核心目标很简单：利用开源的OpenClaw框架，构建一个能够准确识别老人摔倒行为，并及时发出预警的AI视觉系统。但它的野心不止于此，我希望它成为一个“可扩展的AI视觉监控助手”，这意味着摔倒检测只是第一个应用场景，未来可以轻松接入烟火检测、陌生人闯入识别、宠物异常行为分析等多种能力。

这个项目不是简单的算法调用，它涉及从边缘设备选型、模型优化、服务端架构到报警策略设计的一整套工程实践。接下来，我将详细拆解整个系统的设计与实现过程，分享其中踩过的坑和总结出的经验，希望能为有类似需求的开发者或家庭技术爱好者提供一份可复现的参考。

2. 技术栈选型：为什么是OpenClaw + 边缘计算？

构建一个7x24小时运行的视觉监控系统，技术栈的选择直接决定了系统的实时性、可靠性和成本。经过多轮对比和原型测试，我最终确定了以OpenClaw为核心，搭配边缘计算设备和轻量级服务端的架构。

2.1 OpenClaw：不止是目标检测

OpenClaw是一个基于PyTorch的轻量级、模块化计算机视觉框架。选择它，而非直接使用YOLO或Detectron2等更知名的库，主要基于以下几点考量：

1. 可扩展性设计：OpenClaw的架构天生为多任务和多模型设计。它的核心是一个“任务调度器”和“模型仓库”，你可以像搭积木一样，为不同的视觉任务（检测、分类、姿态估计）注册不同的模型。这对于我们规划中的“可扩展助手”至关重要。今天加入摔倒检测模型，明天想加入烟雾识别，只需要编写新的任务处理模块并注册即可，底层的数据流和调度逻辑无需大改。
2. 对边缘设备的友好优化：OpenClaw内置了对ONNX、TensorRT等模型转换和推理引擎的良好支持，并且提供了一些针对ARM架构（常见于边缘设备）的预优化模型。这意味着我们可以相对轻松地将训练好的模型部署到算力有限的设备上。
3. 清晰的代码结构与文档：虽然社区规模不如顶级项目，但OpenClaw的代码结构非常清晰，模块解耦做得很好。当我们需要深入定制数据预处理流水线或修改后处理逻辑时，不会像面对一些“巨无霸”框架那样无从下手。

注意：OpenClaw并非没有缺点。其预训练模型库相对较少，很多场景需要自己从头训练或从其他框架（如MMDetection）迁移模型。这对于新手是一个挑战，但也迫使你更深入地理解模型和任务本身。

2.2 边缘设备：算力、功耗与成本的平衡

将AI推理放在摄像头端（边缘）还是云端，是另一个关键决策。全部上云，延迟和隐私是问题；全部在边缘，设备成本和高并发处理能力是瓶颈。我采用了“边缘轻推理 + 云端重决策”的混合架构。

• 边缘节点（摄像头端）：选用搭载了华为昇腾310芯片的Atlas 200 DK开发者套件。这款芯片在INT8精度下能提供约8TOPS的算力，功耗仅8W左右。它的优势在于：

  • 专用AI算力：针对视觉任务优化，效率远高于通用CPU。
  • 低功耗：适合长期通电运行。
  • 完整的开发工具链：昇腾CANN架构提供了从模型转换（ATC工具）到应用开发（AscendCL）的全套支持。
  • 我将OpenClaw中的人体检测和关键点检测模型，通过ATC工具转换成了昇腾芯片支持的om格式，部署在Atlas 200 DK上。它的任务是实时运行轻量级模型，提取视频流中的人体框和骨骼关键点信息，然后将这些结构化数据（而非原始视频）上传到服务端。这极大地减少了网络带宽占用。

• 服务端（决策中心）：使用一台普通的家用NAS（我用的群晖DS920+，搭载Intel J4125 CPU）来担任。它的任务是：

  • 接收来自多个边缘设备的结构化数据。
  • 运行更复杂的“摔倒判定算法”（基于时序关键点数据的规则与轻量级分类模型）。
  • 管理报警规则、记录日志、并向手机APP推送告警。
  • 由于处理的是已经过压缩和抽象的数据，对服务器算力要求不高，家用NAS完全胜任。

这套方案的优势在于，将高密度的原始视频分析压力分散到各个边缘点，云端只做聚合与复杂逻辑判断，系统整体扩展性很强，增加一个摄像头只需增加一个边缘节点，对中心服务器压力增加很小。

3. 核心算法实现：如何定义并识别“摔倒”？

摔倒检测的准确性是整个系统的生命线。一个高误报的系统会让人麻木并最终被关闭；而一个漏报的系统则毫无意义。我的方法不是依赖单一帧图像的检测，而是基于时序的人体姿态分析与行为理解。

3.1 数据准备与标注：自己动手，丰衣足食

公开的摔倒数据集（如UR Fall Detection Dataset）场景比较单一，且与国内家庭环境差异较大。为了获得更好的效果，我决定自己构建一个小型数据集。

1. 数据收集：

   • 在确保安全和隐私的前提下，邀请了几位亲友在客厅、卧室、卫生间等不同场景下，模拟各种动作：正常行走、坐下、蹲下、弯腰捡东西，以及多种姿势的摔倒（向前扑倒、向后坐倒、侧向滑倒）。
   • 使用多个角度的普通摄像头进行录制，以丰富视角。
   • 总共收集了约50个小时的原始视频，从中抽帧并筛选出约2万张包含各种姿态的图像。

2. 数据标注：

   • 第一步：人体检测框。使用LabelImg工具，标注出图像中每个人的边界框（Bounding Box）。这用于训练我们的人体检测模型。
   • 第二步：关键点标注。这是更繁琐但更重要的一步。我使用了COCO关键点格式（17个点，包括鼻、眼、耳、肩、肘、腕、髋、膝、踝）。这里有一个关键技巧：对于摔倒后人体被遮挡或扭曲严重的帧，必须尽最大努力根据肢体走向进行合理推测标注，而不是跳过。因为正是这些非常规姿态，才是摔倒检测的关键。我使用了CVAT标注工具，它对于关键点标注的效率比LabelImg高很多。
   • 第三步：行为标签。为每一段连续的视频片段（而不是单张图片）打上行为标签：“正常”、“坐下”、“弯腰”、“摔倒”。这用于后续的时序分类模型训练。

3.2 模型训练与优化：两步走策略

我没有直接训练一个端到端的“摔倒检测”模型，而是将其拆解为两个更成熟、更易优化的子任务。

任务一：人体检测与关键点估计（部署在边缘）

• 模型选择：采用了OpenClaw中提供的基于YOLOv5s改进的轻量级检测模型，并集成了轻量级的关键点估计头（类似于YOLO-Pose的思路）。一个模型同时输出人体框和17个关键点坐标。
• 训练：使用自标注的2万张图片训练。损失函数为检测损失（GIoU、Objectness、Classification）和关键点损失（MSELoss）的加权和。
• 边缘优化：
  • 将PyTorch模型导出为ONNX。
  • 使用昇腾的ATC工具，将ONNX模型转换为.om格式，并指定输入输出格式，进行INT8量化。
  • 实测在Atlas 200 DK上，处理一张1080P图片的推理时间约80ms，完全满足实时性要求（>10 FPS）。

任务二：时序摔倒行为分类（部署在服务端）

• 输入：边缘设备上传的，连续若干帧（我采用了一个2秒的滑动窗口，约30帧）里同一个人的关键点序列数据。这是一个形状为[T, 17, 2]的张量（T帧，17个关键点，2个坐标）。
• 特征工程：直接使用原始坐标效果并不好，因为人在画面中的位置和大小会变。我计算了相对特征：
  • 以髋部中点（左右髋关键点的平均值）为原点，将所有关键点坐标归一化到这个人体的局部坐标系。
  • 计算一些有物理意义的特征，如：人体主轴与地面的夹角、头部与脚部的垂直高度差、膝盖和肘关节的角度等。
• 模型选择与训练：尝试过LSTM和1D CNN，最终选择了一个非常轻量的多层感知机（MLP）。因为经过上述特征工程后，问题已经得到了很大简化。模型输入是30帧x 20个特征，输出是“正常”或“摔倒”的概率。
  • 为什么不用更复杂的模型？在服务端，虽然算力相对充裕，但我们需要处理来自多个摄像头的并发数据流。轻量级模型意味着更低的延迟和更高的吞吐量。实践证明，对于这个精心设计过的特征空间，一个3层的MLP已经能达到98%以上的准确率。
  • 训练数据是我从视频片段中提取的数千个正样本（摔倒）和负样本（其他动作）序列。

3.3 规则引擎与后处理：降低误报的最后防线

即使分类模型很准，仍会有误报。例如，快速躺下、做大幅度的瑜伽动作等。因此，我引入了一个基于规则的后处理过滤器：

1. 空间一致性检查：摔倒通常发生在下半身支撑面（脚、臀部）附近。如果系统判断摔倒，但人的头部关键点位置在近几帧内没有显著的高度下降，则可能是误判。
2. 静止状态判断：摔倒后，人通常会在一段时间内保持静止或只有小幅移动。如果“摔倒”后立即检测到大规模移动（如站起来），则可能是误判。
3. 报警延迟与持续确认：单次检测到“摔倒”不立即报警。而是启动一个5秒的观察窗口。如果在这5秒内，连续有多帧（如超过70%）都判断为摔倒，且符合上述规则，才最终触发报警。这能过滤掉瞬间的相似姿态。

这个“模型分类 + 规则过滤”的两级判断机制，在实际测试中将误报率从最初的约15%降低到了2%以下，效果显著。

4. 系统架构与工程实践：从数据流到报警闭环

有了算法模型，我们需要一个健壮的系统将它们串联起来，确保稳定、可靠地运行。下图展示了“ClawVision·守护眼”的整体数据流与组件交互，这是一个典型的边缘-云端协同架构：

flowchart TD subgraph A[边缘端：Atlas 200 DK] A1[USB摄像头<br>视频流捕获] --> A2[OpenClaw推理引擎<br>人体检测 & 关键点估计] A2 --> A3[数据封装<br>JSON序列化] end subgraph B[云端：家用NAS服务器] B1[MQTT Broker<br>消息中枢] A3 -- 关键点数据流 --> B1 B1 --> B2[行为分析服务<br>时序分类模型 + 规则引擎] B2 -- 报警事件 --> B3[报警管理服务] B3 --> B4[通知推送<br>APP/短信] B3 --> B5[事件存储与日志<br>数据库] end B4 --> C[用户终端<br>手机APP] B5 --> D[Web控制台<br>历史回顾与配置]

4.1 边缘侧服务：高效、稳定地采集与预处理

边缘设备上的程序需要长时间稳定运行，我将其设计为一个多进程服务：

1. 视频采集进程：使用OpenCV的VideoCapture从USB摄像头拉取RTSP流。这里的关键是设置合理的缓冲区和丢帧策略。如果处理速度跟不上采集速度，视频缓冲区会堆积，导致延迟越来越高。我的做法是开启一个独立的线程负责抓帧，并维护一个固定长度的队列。推理进程从这个队列取最新的帧进行处理，如果队列满了，就丢弃最老的帧。这保证了系统始终处理的是“最近”的画面，延迟可控。
2. AI推理进程：这是核心进程。它从队列中取帧，调用通过昇腾AscendCL接口封装的OpenClaw模型进行推理。得到人体框和关键点后，需要进行跨帧目标跟踪（使用简单的IOU跟踪算法），为同一个人分配一个唯一ID，并将同一ID的关键点序列缓存在内存中。
3. 数据发送进程：将跟踪后、带有ID的关键点数据（每帧或每N帧）封装成JSON格式，通过MQTT协议发布到服务端的一个指定主题（例如clawvision/camera01/person_pose）。选择MQTT是因为它轻量、支持发布订阅模式，非常适合物联网场景。边缘端作为Publisher，只负责发送数据，与云端解耦。

实操心得：边缘端的稳定性：边缘设备最怕程序崩溃或内存泄漏。我使用了systemd来管理这个多进程服务，并编写了看门狗脚本监控进程状态。此外，定期（如每天凌晨）重启一次服务，可以清除长时间运行可能积累的不稳定状态。

4.2 云端服务：聚合、分析与决策

服务端使用Docker容器化部署，主要包含三个服务：

1. MQTT Broker（EMQX）：作为消息中枢，接收所有边缘设备的数据。选择EMQX是因为它性能好，支持海量连接，并且有丰富的Webhook和规则引擎功能，可以方便地将数据转发到其他处理服务。
2. 行为分析服务（Python Flask + 分析模型）：这是核心决策单元。它订阅MQTT Broker上的关键点主题。收到数据后：
   • 根据人员ID，将其关键点数据存入对应的时序缓冲区（Redis，用作高速缓存）。
   • 当某个ID的缓冲区数据达到预设长度（如30帧，2秒），便触发一次行为分析：提取特征 -> MLP模型分类 -> 规则引擎过滤。
   • 如果判定为摔倒，则生成一个结构化报警事件，写入消息队列（RabbitMQ）。
3. 报警与日志服务：消费报警事件队列。它负责：
   • 多渠道报警：根据预设规则，通过集成“钉钉机器人”、“Server酱”（微信推送）和“Twilio”（短信，备用）的API，向家属手机发送报警通知。通知内容包含快照图片（边缘端可附带一张低分辨率截图）、发生时间、摄像头位置。
   • 数据持久化：将报警事件、日常的关键点日志（用于后期模型优化）存入PostgreSQL数据库。
   • 提供查询接口：为手机APP或Web控制台提供RESTful API，用于查看历史报警、实时状态等。

4.3 报警策略设计：既要及时，又不扰民

报警策略的精细程度直接决定了用户体验。

• 分级报警：我将报警分为两级。
  • 一级报警（紧急）：在卧室、卫生间等高风险区域检测到摔倒，立即触发电话级别的通知（如连续拨打预设电话直至接听）。
  • 二级报警（提醒）：在客厅等区域检测到摔倒，先推送APP消息和短信。如果10分钟内未被确认（比如家属在APP上点击“已处理”），则升级为电话通知。
• 静默期与学习期：系统可以设置“静默时段”，例如夜间老人睡眠时间，除非是一级报警区域，否则只记录不通知，避免打扰。系统运行初期，可以设置为“学习期”，此期间所有报警只记录不通知，用于观察和调整算法阈值，降低误报对用户的干扰。
• 报警确认与反馈：家属收到报警后，可以通过APP快速查看实时画面（边缘端收到请求后临时上传一段短视频），并点击“误报”或“已处理”。这些反馈数据会记录下来，作为后续优化规则引擎和模型的宝贵数据。

5. 部署、调试与长期维护的实战经验

将代码部署到实际环境并让它稳定运行，是比开发更考验人的环节。

5.1 边缘设备环境部署

Atlas 200 DK运行Ubuntu系统。部署步骤：

1. 基础环境：安装昇腾CANN工具包、Python及依赖。这里注意要使用昇腾提供的特定版本的PyTorch和TorchVision（如果有），或者使用ONNX作为中间格式。
2. 模型部署：

   # 1. 将训练好的PyTorch模型导出为ONNX python export_pose_model_to_onnx.py --weights best.pt --img-size 640 # 2. 使用ATC工具将ONNX转换为昇腾OM模型 atc --model=./yolopose.onnx --framework=5 --output=./yolopose_bs1 --input_format=NCHW --input_shape="images:1,3,640,640" --log=debug --soc_version=Ascend310

3. 服务部署：将我们编写的多进程推理服务代码拷贝到设备，配置systemd服务文件，设置开机自启。

   # /etc/systemd/system/clawvision-edge.service [Unit] Description=ClawVision Edge AI Service After=network.target [Service] Type=simple User=root WorkingDirectory=/opt/clawvision-edge ExecStart=/usr/bin/python3 main.py Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

4. 网络配置：确保设备能稳定连接到家庭Wi-Fi，并设置静态IP或DHCP保留，避免IP变化导致连接中断。

5.2 服务端（NAS）部署

我使用群晖NAS的Docker套件进行部署，非常方便。

1. 创建自定义网络：docker network create clawvision-net，让所有容器在同一个网络内，通过容器名互访。
2. 部署各个服务：
   • EMQX：直接使用官方镜像，映射1883（MQTT）和8083（Web管理）端口。
   • PostgreSQL & Redis：使用官方镜像，挂载数据卷到NAS的物理存储上，保证数据持久化。
   • 行为分析服务 & 报警服务：需要自己构建Docker镜像。编写Dockerfile，将Python代码、模型文件打包进去。

   # Dockerfile for analysis service FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY . . CMD ["gunicorn", "-w", "2", "-b", "0.0.0.0:5000", "app:app"]

3. 使用docker-compose编排：这是最佳实践，用一个docker-compose.yml文件定义所有服务及其依赖关系、网络、卷，一键启动。

   version: '3.8' services: emqx: image: emqx:5.0 container_name: emqx ports: - "1883:1883" - "8083:8083" networks: - clawvision-net postgres: image: postgres:14 container_name: postgres environment: POSTGRES_PASSWORD: yourpassword POSTGRES_DB: clawvision volumes: - ./data/postgres:/var/lib/postgresql/data networks: - clawvision-net analysis-service: build: ./analysis_service container_name: analysis-service depends_on: - emqx - redis environment: MQTT_BROKER: "emqx" REDIS_HOST: "redis" networks: - clawvision-net # ... 其他服务

4. 配置与监控：所有服务的配置（如MQTT地址、数据库连接串、API密钥）都通过环境变量传入。使用Portainer或NAS自带的Docker管理界面监控容器状态和日志。

5.3 调试与优化：真实环境中的挑战

实验室里运行良好的系统，到了真实环境会遇到各种问题。

• 光照变化：黄昏时，室内光线变化剧烈，导致检测框抖动甚至丢失。解决方案是在边缘端代码中加入自适应亮度预处理，使用CLAHE等算法增强图像对比度，并适当提高模型推理的置信度阈值，宁可漏检，也要减少误检带来的ID切换。
• 遮挡问题：老人有时会被家具部分遮挡。这会导致关键点不全。我们的策略是：对于遮挡严重的帧，如果跟踪器能通过运动轨迹和部分可见特征维持ID，就使用上一帧的有效关键点进行插值补全，并标记该帧数据置信度较低，在行为分析时给予较低权重。
• 网络抖动：家庭Wi-Fi可能不稳定，导致边缘端数据上传延迟或丢失。在边缘端代码中，我实现了本地缓存和断线重传机制。如果检测到网络断开，将数据暂存到本地SQLite数据库；网络恢复后，优先上传最近一段时间（如最近5分钟）的高优先级数据（如包含报警预判的数据）。
• 功耗与散热：Atlas 200 DK长期运行会发热。我为其加装了一个小型静音风扇散热器，并放置在通风处。同时，监控其温度，如果核心温度持续过高，则动态降低推理帧率（如从15FPS降到10FPS），以牺牲少许实时性换取稳定性。

5.4 长期维护：让系统越用越聪明

系统上线不是终点。我建立了一个简单的持续迭代流程：

1. 误报/漏报收集：通过APP的反馈功能，家属可以标记误报和漏报事件。系统会将这些事件相关的视频片段（边缘端保存的短期缓存）和关键点数据自动打包，上传到服务端的一个特定目录。
2. 数据清洗与标注：定期（如每月）查看收集到的案例。对于典型的误报（如宠物跑过、大幅挥手），将其加入负样本集；对于漏报的摔倒，加入正样本集。这是一个持续的数据闭环。
3. 模型迭代：用新积累的数据，对关键点检测模型和时序分类模型进行增量训练。由于我们采用的是模块化设计，只需要替换模型文件，重启服务即可完成升级，无需改动业务逻辑。
4. 日志分析：定期检查系统日志，监控各服务的CPU/内存占用、消息队列堆积情况、报警响应延迟等指标，及时发现潜在的性能瓶颈。

6. 可扩展性设计：从摔倒检测到通用视觉助手

“可扩展”是本项目的一个重要目标。目前系统已经为接入新的视觉能力做好了准备。

1. 任务注册机制：在OpenClaw框架中，我已经抽象出了一个BaseTask类。要新增一个任务（如“烟火检测”），只需：
   • 继承BaseTask，实现数据预处理、模型推理、结果后处理等方法。
   • 在任务调度中心注册这个新任务，并指定其运行的模型文件和处理优先级。
   • 边缘端的视频流会被自动复制一份给这个新任务，互不干扰。
2. 事件总线：服务端的行为分析服务也进行了抽象。新的分析模块（如“陌生人识别分析”）可以订阅MQTT中相应的原始数据流（如人脸特征流），产生自己的分析事件（如“识别到陌生人”），并发布到统一的事件总线。
3. 规则引擎配置化：报警规则不再硬编码。我设计了一个简单的JSON配置格式，允许通过Web控制台动态添加、修改报警规则。例如，可以添加一条规则：“如果‘烟火检测’任务置信度大于0.9，且‘区域’为厨房，则立即触发火灾报警”。
4. 插件化前端：手机APP和Web控制台的界面组件也是插件化的。新增一个检测任务后，只需要编写对应的数据展示组件（如图表、告警面板），并注册到前端框架中，即可在界面上显示。

通过这套设计，未来为系统增加“婴儿啼哭检测”、“门窗异常开关检测”等功能，都将变成相对标准化的开发工作，真正实现了“助手”的灵活演进。

这个项目从构思到稳定运行，历时近四个月。它不仅仅是一个技术Demo，而是一个真正在守护家人的实用系统。最大的成就感不是代码跑通的那一刻，而是某天收到一条准确的报警，并及时联系上家人确认平安的那个瞬间。技术最终的温度，在于它如何服务于人。如果你也有类似的想法，不妨从一个小摄像头和一份开源代码开始，亲手搭建属于自己的智能守护。过程中遇到的每一个问题，都是通往更可靠系统的阶梯。