上周三晚课，第三组的男生把应力采集盒的线拔了三次。
最后蹲在实验台旁边骂了句脏话。
他们把1000Hz的采样数据全传到云端服务器算，结果实验室的校园网卡成PPT。加载出曲线的时候，悬臂梁已经被压到塑性变形了。
之前我们的实验大纲里，从来没把“在哪算数据”当成个需要单独拎出来讲的知识点——总觉得学生只要能把应变片的信号采下来，最后用Matlab算出应力值，就算完成了机械测试的基本训练。
把算力从云拉回实验台的第一节课
说实话，当初想在实验课里加这部分内容，完全是被去年苏州机床厂的参观经历戳中了。
车间里的老监测系统，每次主轴出异常，要过30秒才能在中控室弹出报警。有次机床撞了刀，损失小两万。后来换了巴掌大的边缘模块，报警延迟直接降到100毫秒以内。
这种把计算逻辑下沉到采集端的做法，就是我们这学期想让学生摸透的边缘数据运算。
没人喜欢等。
当你站在实验台边，手捏着手轮慢慢给悬臂梁加载，眼睛盯着屏幕上迟迟跳不出来的数值时，你会突然明白，为什么工业现场的工程师宁愿多花点成本在采集端装个小算力模块，也不愿意等那十几秒的网络传输延迟。
我们一开始的设计很贪心，想把整套频谱分析的算法全塞到几十块的STM32小板子上。结果跑了两秒就卡死，串口直接吐不出来数据。后来干脆拆——把最需要实时反馈的部分，比如应力峰值、振动超限的阈值判断，直接放在边缘端算；复杂的模态分析、数据溯源这些不急的，等实验结束了再传去服务器慢慢算。
当初拆算法的时候我也心疼，熬了两个礼拜写的完整傅里叶变换代码，最后只留了个1/10的子模块放在板子上，换谁都得郁闷半天。
学生踩过的那些没必要的坑
第一节课上，学生的问题比我预想的多得多。
有个组为了体现自己用了边缘运算，把所有数据都在边缘端算完，连原始波形都不存。结果最后写报告的时候，想找个超限时刻的原始应变数据做分析，啥都没了。
还有的组，把边缘端的阈值设得太死。悬臂梁刚压了个0.1mm的变形，板子就亮红灯报警，最后整个实验过程连个正常的加载曲线都没录到。
我当时站在旁边看他们连按三次复位键，差点笑出声——这帮孩子对“实时运算”的理解，简直是把油门焊死在踏板上。
边缘数据运算从来不是要替代云端的算力，而是把最急的那部分计算，从“等传输”的时间差里抠出来。
这句话我在课上讲了三遍。
还是有学生忍不住把所有功能都往采集盒上塞。有个组甚至想在边缘端跑个机器学习的裂纹识别模型，最后板子直接重启了三次，连实验的基本数据都没录全。
下次实验要改的地方
实验结束收器材的时候，有个学生跟我聊，说之前在实训基地看到的振动监测系统，全是把数据传半天，出问题的时候根本来不及报警。
他之前总觉得“智能设备”就得是把所有数据都传到云里，现在才反应过来，真要赶在设备损坏前发出报警，很多计算根本等不到云的响应。
这话比我在课上讲十遍都有用。
我们现在准备调整下一次的实验指导书，加个强制要求：边缘端只做三类事——第一是实时阈值判断，第二是关键节点的特征值提取，第三是断网状态下的本地数据缓存。剩下的所有分析工作，全留给课后的离线环节。
还要给每个组的采集盒加个小小的OLED屏，让学生能在加载的过程中，直接在实验台边上看到实时的应力值，不用盯着离三米远的电脑屏幕等加载。
上周改实验大纲的时候，我翻到之前的旧教案，上面还写着“引导学生建立云端数据处理的思维”。现在想想，哪有什么绝对正确的技术路线。
机械设计的本质，不就是在对的地方放对的东西吗。
把计算放在离传感器最近的地方，和把轴承放在离载荷最近的地方，本质上是一回事。
