在工业现场设备停机一小时的成本可能比一台传感器的价格高出几十倍。传统的定期维护要么维护不足导致突发故障要么过度维护浪费备件和工时。我做了多年的设备状态监测项目一直在想能不能做一个既便宜又足够智能的方案直到 VibeSentinel-AI 这个项目落地才算真正找到了一个平衡点。VibeSentinel-AI 是一个基于边缘计算的振动哨兵系统核心就干一件事把振动数据的分析和故障预测直接放在设备旁边的嵌入式硬件上完成不依赖云端。它用 AI 模型实时识别轴承磨损、齿轮点蚀、不对中、不平衡这些常见机械故障在设备真正坏掉之前给出预警。这套方案适合设备维护工程师、产线自动化团队以及任何想在有限预算内做预测性维护落地的技术团队参考。我用 Jetson Nano 作为边缘算力载体配合 MEMS 加速度计采集三轴振动信号跑轻量级 1D-CNN 模型做故障分类再通过 MQTT 把诊断结论和原始特征值同步到本地监控面板。整个系统从传感器到预警推送的端到端延迟控制在 500 毫秒以内真正的预测性维护不需要机房不需要 GPU 服务器一个巴掌大的盒子就够了。1. 项目动机与整体架构拆解1.1 为什么必须在边缘端做预测性维护很多团队一提到 AI 故障诊断第一反应就是把振动数据传到云端用服务器跑模型。理论上这条路没错但实际落地时会遇到几个现实问题。首先是带宽和成本。一个工业级加速度计在 20kHz 采样率下单通道一小时产生的数据量大约是 144MB三轴传感器就是 432MB。一条产线装 20 个传感器一天的原始数据超过 200GB。这个量级的数据全部回传云端流量费、存储费、计算费加在一起项目还没见到效果成本先失控了。其次是延迟和可靠性。设备故障不会提前打招呼。轴承从初期损伤到完全失效最短可能只有几十个小时如果数据传输链路不稳定或者云端服务出现抖动预警的时效性会大打折扣。更重要的是很多工厂的网络环境并不理想车间里电磁干扰、机房断网都是常态把关键诊断逻辑押在云上风险太高。边缘计算的思路就是把算力下沉到设备端。传感器采集数据之后直接在边缘节点上完成特征提取和模型推理只把诊断结果和轻量化的特征值传出去。这样可以做到实时响应同时把网络依赖降到最低。就算断网边缘节点依然在持续监测等网络恢复后再把这段时间的诊断结果补传上去就行。1.2 VibeSentinel-AI 的系统分层设计VibeSentinel-AI 采用四层架构每一层的职责边界非常清晰。感知层负责数据采集核心器件是三轴 MEMS 加速度计。我用的是 ADXL345量程正负 16g分辨率在 3.9mg/LSB 左右对工业设备的振动监测来说足够用了。采样率设置为 3200Hz覆盖设备的故障特征频率范围同时控制单次采样的数据量。边缘计算层是整个系统的大脑运行在 Jetson Nano 上。这一层负责信号预处理、特征工程、模型推理以及异常阈值的动态计算。模型采用 1D-CNN 架构卷积核直接作用于原始振动波形自动学习频域特征不需要额外的人工特征提取步骤。通信层用 MQTT 协议承载。边缘节点作为 publisher监控端作为 subscriber。数据包采用 JSON 格式包含设备 ID、时间戳、诊断结果、置信度以及 RMS、峰值因子等几个关键特征值。单个数据包大小控制在 1KB 以内即便用 4G 网络传输一个月消耗的流量也微乎其微。展示层是监控面板我用 Node-RED 搭了一个简单的 Dashboard实时展示每台设备的健康状态、故障类型、趋势曲线和预警记录。维护人员可以随时查看也能通过设置好的规则把预警消息推送到企业微信或钉钉群。这套架构最大的好处是模块化。传感器坏了只换传感器模型升级只更新边缘节点上的权重文件展示界面想换框架也不影响底层逻辑。项目走到后期你会发现这种松耦合的设计能帮你省掉大量联调时间。2. 核心硬件选型与信号链路设计2.1 传感器选型的几个关键指标很多第一次做振动监测的朋友问我说传感器是不是越贵越好。这个问题的答案没那么简单选传感器一要看被测设备的振动特性二要看算力平台能处理什么量级的数据。优先确认量程。普通电机、泵、风机振动幅值一般在 1g 到 3g 之间。但对于往复式压缩机、破碎机这类设备冲击载荷可能达到 10g 以上。量程选小了信号会削顶失真选大了小故障的特征会被量化噪声淹没。我用 ADXL345 的原因之一就是它有 16g 的量程裕度足够。然后是分辨率。ADXL345 在 16g 量程下分辨率约为 3.9mg这个精度对故障诊断来说意味着能捕捉到早期微弱损伤产生的冲击脉冲。如果你的设备转速很低比如低于 300 转每分钟可能需要考虑分辨率更高的传感器。再就是频响范围。MEMS 加速度计的频响一般到 1kHz 到 5kHz 不等这取决于传感器本身的机械结构和滤波设置。我的应用场景是转速 1500 转每分钟的异步电机转频只有 25Hz轴承外圈故障特征频率大约在 178Hz 左右加上故障引发的谐振频带集中在 1kHz 到 2kHzADXL345 的频响完全覆盖得住。还有一点容易被忽略就是传感器的安装方式。我建议用螺纹安装或者强力胶粘接尽量避免手持或磁吸方式否则高频信号会衰减得非常厉害。曾经我用磁吸方式测一个离心泵的轴承振动特征频带的幅值比螺纹安装低了将近 40%差点漏掉一个齿轮缺齿故障。2.2 边缘计算平台的算力评估提到边缘 AI很多人第一时间想到树莓派。树莓派做常规的 IoT 网关确实没问题但跑深度学习推理就有点吃力了。尤其是振动信号这种时序数据模型要处理的不只是一张静态图而是连续的时序波形对计算吞吐量有更高的要求。Jetson Nano 的 128 核 Maxwell GPU 在算力上有明显优势。我实测下来批量推理一个 2048 点的振动切片单次推理耗时大约 22ms加上预处理和特征提取整个数据流水线的吞吐能力可以稳定支撑每秒 20 组切片的处理。相比之下树莓派 4B 跑同样的模型单次推理耗时在 480ms 左右而且 CPU 直接被打满。当然选 Jetson Nano 不只是因为算力。它还支持 JetPack SDK自带 CUDA 和 TensorRT 加速部署时不需要额外折腾复杂的依赖库。TensorRT 对模型做 INT8 量化之后推理延迟能进一步压到 8ms 左右Jetson Nano 完全够用。这里也给一个实际的选型建议如果只是做单台设备的离线诊断树莓派加 TFLite Micro 的方案也能跑通如果是多设备轮询监测、需要低延迟实时响应的场景Jetson 系列是更稳妥的选择。成本差距大概是几百块但系统稳定性和扩展性完全不在一个量级。2.3 信号链路的抗干扰与噪声控制振动信号的采集链路中干扰最多的环节不是传感器而是信号线和电源。ADXL345 通过 I2C 接口连接到 Jetson Nano 的 GPIO 引脚排线长度控制在 20 厘米以内并且选用带屏蔽层的 FFC 软排线。如果是较长的布线建议改用 RS485 接口的工业级传感器I2C 的抗干扰能力在这种场景下有天花板。电源方面则要特别注意。我曾经用普通的 USB 充电器给 Jetson Nano 供电采集到的频谱图上出现了明显的 50Hz 工频干扰和周期性尖峰导致误报率升到 15%。后来改用工业级 DC-DC 隔离电源模块并且把模拟部分和数字部分的地线做了单点接地处理频谱干净了很多误报率直接降到了 2% 以下。还有一个细节是采样触发的抖动问题。工业现场存在大量的电磁干扰如果采样时钟不稳定波形数据会出现时间轴上的扭曲导致后续的频域分析结果失真。我的方案是用 DMA 方式读取传感器数据配合 Jetson 的实时时钟做时间戳校正确保 3200Hz 的采样率不受系统调度波动的影响。3. 数据采集与预处理流程实现3.1 振动数据的切片策略与重叠率设定原始振动数据不能直接丢给模型。一是长度不固定模型无法统一处理二是单次采样的数据量太大推理成本高三是随机噪声会对分类结果造成干扰。所以第一步就是做固定长度的切片。我用的是 2048 点作为每个切片的长度对应 640ms 的时间窗。为什么是这个数因为要保证切片内包含足够多的旋转周期。拿 1500 转每分钟的电机来说转频 25Hz640ms 里包含 16 圈完整转动的数据。如果转速更低比如 300 转每分钟转频只有 5Hz就需要把切片长度扩展到 4096 点确保每个切片里至少有 8 圈周期。切片之间的重叠率我设定为 50%。这样相邻两个切片的起点间隔 1024 点能有效避免故障特征恰好落在切片边缘而丢失的情况。实测下来50% 重叠率对诊断准确率的提升大约有 3% 到 5%而且计算代价可以忽略。这里要特别提醒一个细节重叠率不是越高越好。我曾经把重叠率调到 87.5%诊断准确率几乎没有提升但推理次数翻了 8 倍边缘节点的 CPU 占用率飙升到 90%。后续做多设备轮询时就撑不住了。所以50% 到 75% 是一个性价比比较高的区间。3.2 信号去噪与滤波的三段式处理信号预处理我分成三步去除直流偏置、带通滤波、归一化。传感器输出的原始信号会有一个固定的直流偏置这个偏置在频谱分析时通常会形成一个 0Hz 处的巨大分量压制有效信号。我采用高通滤波器截止频率设为 5Hz可以有效滤掉偏置和非常低频的漂移。带通滤波器分两路设计。一路保留 5Hz 到 1600Hz 频段用于加速度时域信号的特征提取另一路是包络分析前置滤波截止频率设为 500Hz 到 1600Hz专用于提取轴承早期故障的冲击特征。包络分析是轴承故障诊断的核心手段之一。故障产生的冲击脉冲会激发结构共振通过带通滤波把共振频段提取出来再做希尔伯特变换得到包络波形。包络波形里包含了故障特征频率的调制成分频谱分析时就能定位到具体损伤位置。内圈故障、外圈故障、滚动体故障对应的调制频率计算公式各不相同参考试验数据就能反过来定位损伤位置。最后是归一化。为了消除不同设备、不同工况下信号幅值量级差异对模型的影响我把每个切片的数据缩放到标准差为一、均值为零。3.3 特征工程的层叠组合策略和直接扔给模型学习原始波形不同我在特征提取层额外做了一套时域、频域指标的层叠组合目的是给模型提供更丰富的判别依据。时域特征包括 RMS 值、峰值因数、峭度、波形因子频域特征包括频谱重心、均方频率、频率方差这些。RMS 值反映振动的整体能量水平峰值因数的作用在于识别冲击性故障峭度指标对早期轴承损伤尤为敏感它衡量信号偏离正态分布的程度。谱重心反映频率能量分布的集中趋势当故障频谱的高频成分占比升高时谱重心会明显偏移。这些特征不直接输入到神经网络里而是作为辅助信息用于数值报警门限的计算和模型输出的交叉验证。比如当神经网络判别轴承故障的置信度超过 0.8同时峭度指标超过阈值 3.5 时系统就判定为高阶预警。两个信号互相验证可以有效降低因为单一指标波动引起的误报。4. 轻量化 AI 模型的设计与训练流程4.1 为什么选用 1D-CNN 而非传统机器学习提到设备故障分类很多人会想到支持向量机、随机森林这些传统机器学习算法。它们在小样本场景下表现不错但有一个通病特征工程做得好不好直接决定上限。同一个故障频谱图你提取的特征和专家提取的特征模型效果可能天差地别。而 1D-CNN 通过卷积核直接在时域波形上学习特征模型自己就知道该关注哪些频率模式省去了大量人工调特征的时间。1D-CNN 和二维 CNN 的区别在于卷积核只沿时间轴滑动参数量更少推理速度更快。振动信号本质上就是一维时序数据直接使用一维卷积是更贴近物理本质的处理方式。同时1D-CNN 对工业现场的噪声鲁棒性更好因为它能从大量带噪样本中自动学习到不变性特征。我用 TensorFlow 2.x 搭建了模型结构输入层接收 1x2048 的振动切片经过三层一维卷积加最大池化每层卷积核数量依次为 16、32、64卷积核大小为 3步长为 1。之后接一个全局平均池化层把高维特征压缩成 64 维向量。最后是三层全连接分类头输出层用 Softmax输出六个类别的概率分布正常、外圈故障、内圈故障、滚动体故障、不对中、不平衡。整个模型的参数总量只有约 28 万个占用存储空间仅 392KB。做 INT8 量化之后权重文件压缩到 98KB。在 Jetson Nano 上用 TensorRT 推理一次只要 8ms算力开销极低完全可以用单节点轮询监测多台设备。4.2 数据增强策略与训练数据集构建模型效果的上限由数据决定。我刚做这套系统的时候犯过一个错误直接在网上下了一个公开轴承数据集来训练结果在产线实测时准确率惨不忍睹。原因很简单公开数据的采集工况、传感器安装方式、设备转速和现场数据差异太大模型学了 A 环境的知识硬套到 B 环境自然失灵。正确的做法是自建数据集。我把振动传感器安装到一台试验电机上人为制造了不同类型的故障包括用电火花加工在轴承外圈、内圈、滚动体上制作不同尺寸的损伤点以及通过加配重模拟不平衡通过调整底座垫片模拟不对中。每种故障类型采集 2000 个切片总共约 12000 个样本。采集时覆盖了不同的负荷条件——空载、半载、满载确保模型能学到的特征不是单一工况下的偶然现象。数据量不大所以数据增强策略很关键。我用了四类增强手段给原始信号叠加不同信噪比的高斯白噪声模拟不同现场的噪声环境对信号做随机时间偏移增强模型对相位变化的鲁棒性对幅值做轻微缩放模拟不同负载下的能量差异对少数故障类别做合成少数类过采样缓解样本不平衡的问题。增强之后训练集扩充到 48000 个样本。训练参数方面优化器选用 Adam初始学习率设为 0.001并采用带热重启的余弦退火策略动态调整。批量大小设为 32训练 120 轮使用早停法防止过拟合。训练集和验证集按 82 划分测试时使用完全没参与训练的现场实测数据。最终测试结果分类准确率 94.7%F1 分数 93.2%满足实际部署的需求。4.3 模型压缩与 TensorRT 加速边缘设备的算力有限但模型精度和推理速度之间存在此消彼长的权衡。我在部署时走了两步压缩。第一步是权重剪枝。把所有绝对值小于 0.01 的权重置零再训练 10 轮微调恢复剪枝带来的精度损失。经测试剪枝后模型的 FLOPs 减少了约 35%准确率只掉了 0.3 个百分点是可控范围。然后在第二步做定点量化把 FP32 权重转换为 INT8。这步使用了校准集让量化器统计真实的激活值分布降低量化噪声的影响。TensorRT 的部署流程是先读取 ONNX 格式的模型文件然后构造推理引擎设置工作空间大小和精度模式最后序列化到本地文件。实际运行时从文件中反序列化引擎推理耗时从 22ms 降至 8ms提升了接近三倍。内存占用控制在 180MB 左右在 Jetson Nano 的 4GB 内存上限内非常宽裕。需要特别注意的是TensorRT 的版本和 JetPack 中的 CUDA 版本必须严格匹配。如果版本不对引擎构建时会报各种各样的错误我当时就因为这个坑折腾了两天。建议直接使用 JetPack 预装的 TensorRT 包别急着升级最新版本稳定压倒一切。5. 边缘端预测性维护的实战部署5.1 多设备轮询调度策略在实际产线上你不大可能每台设备都配一个 Jetson Nano成本太高也浪费算力。更合理的方案是一台边缘节点轮询监测多台设备。VibeSentinel-AI 的设计目标就是单节点同时覆盖 8 台设备。轮询调度我采用了自适应策略而非固定间隔。对健康状态正常的设备采样周期设定为 24 小时一次。当某台设备的振级趋势出现抬升或者单个指标超过设定的门限值系统把该设备的巡检周期自动切换到 15 分钟。如果诊断模型输出的故障置信度超过 0.6 且持续 3 次这个周期会进一步缩短到 5 分钟相当于进入高密监控模式。这套策略的核心逻辑是把算力集中用在刀刃上。健康设备的周期性巡检只是为了建立基线数据故障初期的频繁采样才是真正需要计算资源支撑的部分。实测下来8 台设备的轮询周期在几十毫秒级Jetson Nano 的 CPU 平均负载只有 45%GPU 利用率更是低到不足 10%。巡检周期切换的触发条件我建议宁可敏感也别迟钝。实际故障从萌芽到恶化往往速度很快预警系统的价值就是尽早发现。误报的代价是让人去看一眼设备漏报的代价是直接停机换轴两害相权取其轻。5.2 自适应报警门限的构建逻辑固定门限最大的问题在于不同设备、不同转速下的振动能量水平差异很大。同样一个是轴承故障振动幅值为 2g 的信号放在小型水泵上是严重超限放在大型破碎机上可能只是正常波动。所以门限必须是自适应生成的。我给每台设备建立了一个健康基线模型用设备在正常状态下前 14 天的振动数据做统计。这个基线包含 RMS 值均值、标准差、峰值因数的 P99 分位数以及主要频带的能量分布。正常状态下的数据呈现一个稳定的统计分布实际的监测数据如果偏离这个分布超过一定置信区间就会被视为异常。实际运维过程中的数据会被持续吸收进基线模型但做了时序加权衰减处理。最近一周的数据权重更高28 天前的数据会逐渐被遗忘。这样设备自然老化导致的缓慢性能退化不会触发持续误报而突发性的故障特征会在第一时间被捕获。报警分级我设了三个层级。黄色预警对应单指标超门限且置信度低系统推送提示维护人员 24 小时内检查即可。橙色预警对应两个以上指标超门限置信度高出现特征频率谐波成分系统推送通知并要求 8 小时内安排手持仪表复测。红色预警对应高置信度故障分类连续三次采样确认立即停机和检修。5.3 MQTT 通信与数据持久化实时通信层使用 MQTT 协议边缘节点作为客户端发布数据本地服务器作为 Broker 订阅消息。Broker 我选了 Eclipse Mosquitto部署简单支持 TLS 加密。数据发送频率的动态变化是这套系统的一个特色正常状态下每 24 小时发一条摘要包预警状态下每条数据载荷加大并提高发送频率网络开销可以忽略不计。MQTT 数据包的结构里包含设备 ID、时间戳、诊断结论、各类特征值以及模型的各类置信度。历史数据持续存储在本地 SQLite 数据库数据保留策略定为 13 个月实际占用空间远小于回传原始波形的方案。原始波形数据则保留下作为备份故障诊断存疑时还能回溯分析。我调试时遇到过一个典型问题设备离线后重新上线因为时区设置不一致数据库里的时间戳顺序错位了。这个问题导致趋势曲线刚恢复的时候出现了断崖式跳动。最后统一把时间戳设置成 UTC 时间存储展示层再做本地时区转换就彻底解决了。5.4 监控面板与预警推送集成展示层用 Node-RED 搭了可视化面板Dashboard 上能看到设备列表、实时振动特征卡片、最近 24 小时趋势图以及各设备的预警记录时间线。这个面板的实际作用是帮助维护人员在排查故障时定位问题比如拿到设备 ID、时间戳和指标数据后可以快速对比相邻设备的振动水平判断故障是单机问题还是共性干扰源。预警推送我接了两个通道企业微信 webhook 机器人和钉钉群机器人。报警消息的格式是紧凑卡片模式包含设备名称、故障类型、置信度和建议操作。维护人员在手机端直接点击卡片里的链接就能跳到面板的详情页查看趋势数据。这一环对实际的维护效率提升明显。以前是巡检员带纸质记录表逐台看设备现在是手机弹消息直接通知责任人响应时间从小时级压缩到了分钟级。推送频率也要加防抖策略同一设备同一故障类型在 30 分钟内不重复推送。故障初期的报警连续高频推送会严重消耗运维团队的耐力大家会习惯性无视预警消息反而错失了真正严重的告警。6. 实际测试结果与调优避坑指南6.1 现场部署后的诊断效果实测我在一台 37kW 的异步电机和一台离心泵上分别做了 7 天连续部署测试。电机人工置入外圈故障故障直径约 0.8mm离心泵则是模拟不平衡状态在叶轮上加装了 20g 的配重块。系统在第 2 天就捕捉到电机轴承外圈故障的明显征兆。包络频谱图上清晰出现了外圈故障特征频率及其二倍频、三倍频谐波模型输出外圈故障类别概率 0.74但此时 RMS 振速只有 1.8mm/s远低于常规报警门限。这套系统比传统的单一振速门限方法提前了约 13 小时发出预警为停机检修预留了充足的备件采购时间窗口。离心泵不平衡故障的诊断更加直接。1 倍转频处幅值显著增大但谐波成分不多方向特征典型。系统在第 8 小时打出了橙色预警检修时发现叶轮配重块确实松动紧固后振值恢复了正常。这次测试让我确认了一件事诊断模型的输出不能替代维护人员的判断但能提供一个足够清晰的量化方向。故障类型是轴承还是松动是外圈还是内圈维护团队到现场可以带着问题去排查检修速度明显加快。6.2 部署过程中踩过的典型坑第一个坑是 I2C 通信不稳定。ADXL345 在长排线和高速模式下很容易出现数据丢失和 CRC 校验错误。我一开始用 400kHz 的高速模式在靠近变频器的地方10 次采样里有两次会读到全零数据。后来把 I2C 速率降到 100kHz同时改用屏蔽排线并加上了 CRC 校验和重传机制问题才彻底解决。第二个坑是 JetPack 和 TensorRT 版本不匹配导致的推理引擎构建失败。这个在之前已经提到过。初期为了解决这个问题浪费了不少时间最终的经验是严格锁版本不使用最新版只使用 LTS 版本。第三个坑是数据标注错误的连锁放大。采集训练数据时我是在电火花加工后的轴承上直接采集数据。但因为装配间隙不均匀其中一部分外圈故障数据实际上混入了平衡不良的成分。训练初期模型准确率始终上不去一度卡在 80% 左右。最后通过聚类分析找出异常样本重新清洗数据集并重新训练准确率才上到 94.7%。数据质量是整个项目的基石宁可多花时间核验数据也不要在模型调参上盲目用力。6.3 常见问题速查与处理方案习惯把问题整理成速查表现场排查时可以快速定位也分享给有需要的人。MQTT 断线重连异常。检查 Broker 的 keepalive 配置是否小于网络超时时间同时在边缘节点上设置自动重连逻辑并定期发送心跳包。模型置信度高但频繁抖动。观察频谱特征是否呈现间歇性冲击这种信号更多与设备装配状态有关建议结合时域包络和相位分析进一步判断。如果抖动持续超过 12 小时手动复查设备的润滑状态和皮带张力。设备离线后重新上线数据时间戳顺序错乱。已解决统一使用 UTC 时间存储展示层转换时区。单台设备的 RMS 基线漂移。检查设备是否改变了运行工况比如变频器的频率设定发生了变化或是工件的负载特性改变。确认这些因素后重新采集数据更新基线即可。预警推送没有送达。检查企业微信或钉钉的 webhook 地址是否有效、机器人是否被移出群聊。验证策略是往群里发一条固定关键字的消息不要手动点测试按钮直接发送真实格式的消息去验证关键字匹配规则。6.4 模型长期迭代与持续优化方向预测性维护系统的价值不是一次部署就完结了它是一个持续迭代的过程。第一版模型可能只有正常和不正常两大类随着数据积累可以逐渐细分为不同的故障子类型甚至加入剩余使用寿命的回归预测。我在 VibeSentinel-AI 中预留了模型热更新的框架通过 MQTT 下发新的权重文件到边缘节点节点校验完整性后自动加载并切换。版本回滚做了三层保障保留上一版权重、新的权重先试运行 100 个样本验证输出分布再切换、异常情况下自动回退确保现场安全。后续可以考虑的方向是把多台设备的横向对比做成基线群当某台设备的频谱形态与群内其他设备出现统计意义上的显著偏差时即使单台绝对值没超限也会触发预警。这在大型旋转机械集群上有明显的应用价值。还可以尝试把模型进一步压缩到 STM32 平台或者把自监督学习方法引入振动特征预训练减少对标注数据的依赖。坦白说标注数据一直是领域痛点自监督预训练加上少量微调可能是未来更落地的方向。我个人的体会是做边缘 AI 预测性维护的关键不在于模型多先进。真正的门槛在于把传感、通信、算力、算法、运维流程串成一条完整且可靠的链路。VibeSentinel-AI 这套系统设计的核心思路是每一个决策都要能在没有云端帮助的情况下独立工作。设备坏了不会等你有空处理模型也一样要时刻待命。最后再分享一个小技巧边缘 AI 项目的调试时间有一半都花在数据链路的验证上。别急着跑模型先用脚本连续记录 24 小时原始数据做一次频谱分析确认信号里能看到明显的转频和频谱特征峰。这一步如果通过了后面模型训练和部署基本上就顺了。传感器信号本身就带问题的话后面加再多算法也很难弥补这是我在现场实战里得到的经验。