1. 我需要先聊聊“为什么是输液液位检测”1.1 医院病房里的真实痛点到底是什么静脉输液是医院里最日常的治疗手段之一但它的监护方式几十年没怎么变过——靠患者家属盯瓶子、靠护士定时巡房。我自己去医院陪护时见过最典型的场景家属盯着输液瓶不敢眨眼药液快完了赶紧按铃护士跑过来换瓶一天来回几十趟。这套流程看起来没什么问题但它本质上依赖的是人的注意力。人的注意力是会衰减的特别是在深夜、在患者多的时候。从问题本质来看输液监护要解决的是三件事液位低了能及时知道、滴速异常能被发现、输液过程中尽量少打扰患者和护士。前两个是安全需求第三个是体验需求。而我见过的很多所谓“输液监控系统”要么只做了个射频标签加重力感应精度不够要么价格高到只有ICU才用得起。普通病房需要的其实是一个低成本、易部署、识别的准的视觉检测方案。1.2 适合做成计算机毕设项目的关键点在哪选择“静脉输液液位检测系统”作为毕设项目有它天然的合理性。第一它有明确的视觉目标——输液瓶里的液面是清晰可观测的不像一些抽象的分类问题那样边界模糊。第二它同时涉及传统图像处理和深度学习两条技术路线适合做对比实验、消融实验这在答辩时有话可说。第三它有一个真实的部署场景硬件成本可控做出来是一个完整的软硬结合系统而不是一个纯跑数据的算法Demo。大多数毕设项目容易犯的毛病是“偏科”——要么只做算法不管部署要么只做硬件算法刻意弱化。而这类项目天然要求你兼顾两端我觉得这是它作为毕设选题最大的优势。如果往深了做还能把时间序列预测、告警日志分析这些“大数据”方向的内容加进去让项目的技术层次更丰富。这也是我在这篇文章里想重点展开的部分不只是告诉你模型怎么训练而是把一个完整项目从数据到答辩的每个环节都摊开讲。2. 需求拆解与整体方案选型2.1 一个合格的系统应该做到什么程度先把项目需求拆细直接用表列出来。这个表也是你写开题报告时可以直接用的素材功能维度核心需求关键指标备注液位状态识别区分高液位、正常、低液位、空瓶四类状态准确率 ≥ 95%低液位和空瓶是告警重点告警响应液位低于阈值时触发本地声光告警并推送记录延迟 ≤ 2秒本地蜂鸣器加LED历史追溯记录每次输液过程的时间、液位变化、告警记录可查询、可导出为数据分析提供原始数据趋势预测根据历史液位变化速率预测剩余时间误差不超过10%这是“大数据”方向的主要落点成本控制整套硬件成本控制在500元以内越便宜越好便于普通病房推广从需求倒推技术路线液位识别是核心可以用深度学习模型做也可以用传统图像处理做趋势预测需要时间序列数据所以系统得有记录功能告警需要本地硬件响应所以得有输出接口。这些需求叠在一起项目自然而然就成了一个软硬件结合的系统。2.2 为什么“深度学习传统视觉”两条腿走路我在做这个项目之前最先想到的方案是用摄像头拍摄、用YOLO直接检测液面位置。但后来我发现一个问题如果只依赖深度学习数据量不够的时候模型会很不稳定。而单纯用传统图像处理比如边缘检测加阈值分割在光照变化大、瓶子有反光的时候误检率也比较高。所以最后我采用了双轨方案传统视觉算法作为实时基线在每一帧上做快速检测保证基本功能不出错深度学习模型负责在复杂场景下做修正当两个结果不一致时以置信度更高的一方为准。这种做法在工业检测里叫“多传感器融合”在毕设项目里它还有一个隐藏的好处——你可以比较两种路线的效果差异形成完整的实验对比这在答辩时会非常加分。系统整体架构是这样的摄像头采集图像预处理后并行跑两个检测分支。传统分支用颜色阈值加形态学处理提取液位高度深度学习分支用轻量级YOLO模型检测输液瓶区域并分类液位状态。两个分支的结果汇入一个简单状态机由状态机决定是否触发告警。与此同时系统每30秒记录一次当前液位高度形成时间序列写入本地数据库供后续趋势预测使用。3. 数据从哪里来别再去网上找了自己造3.1 真实医疗数据的合规难题与应对思路做医疗AI第一个绕不开的问题就是数据。真实的医院输液场景视频属于患者隐私数据获取流程极其繁琐而且要经过伦理审查。作为一个毕设项目你不能也不应该在公开渠道随便找医疗影像数据来用这里面的合规风险是实实在在的。我采用的替代方案是搭建一个模拟输液环境自己采集数据。具体做法是找一个透明的玻璃输液瓶灌入不同颜色和不同水位的液体放置在光照可调节的背景板前用摄像头从正面和侧面分别采集图像。通过改变水的颜色淡黄、淡红、无色、改变液面高度、改变背景亮度、改变瓶子角度模拟出尽可能丰富的实际工况。这样建出来的数据集虽然和真实医院场景有差异但胜在数据完全可控、标注精确、版权和隐私问题为零。而且在这个采集过程中你已经接触到数据生产流程的完整链路——从场景搭建到数据清洗到标注规范——这本身就是工程项目里很宝贵的经验。3.2 标注规范与数据集规模的设计我用LabelImg工具标注标注类别设为四类high液位高于2/3、normal液位在1/3到2/3之间、low液位低于1/3且可见、empty瓶底基本无液体。注意这里有个细节标注的是“整个输液瓶的液位状态”而不是去标注液面的具体分割线。这样设计的好处是模型学的是“瓶子呈现出的整体状态特征”而不是某个精确的边界位置。数据集规模我做到了1500张图像其中900张用于训练300张验证300张测试。每张图像中除了输液瓶本身还人为加入了一些干扰物比如桌面的反光、旁边的其他瓶子、不同背景纹理这样训练的模型才会具备一定的抗干扰能力。数据增强用了随机亮度扰动、随机裁剪、水平翻转、高斯模糊四类把训练集扩到了2400张左右。一个小提示拍摄时尽量使用固定机位因为这个系统最终部署时摄像头位置是固定的训练数据里过度变化的视角反而会让模型学到不必要的位置特征。3.3 数据标注容易踩的坑标注这件事看着简单做的过程中就会遇到很具体的问题。最大的坑是“状态边界”的定义。比如液面刚好在1/3刻度线附近该标成normal还是low我处理的办法是把这类模糊样本单独分出来标为unsure不参与训练。其实深度学习模型对边界模糊本身就具有容错性你硬给它一个标签反而会干扰训练。第二个坑是光线方向不一致。前期我拍的图片有些是从窗户方向采光有些是从室内灯光采光结果训练出来的模型在验证集上表现不稳定。后来统一使用正面漫射光源并额外采集了一些强逆光样本作为负样本模型稳定性明显改善。这说明采集数据时控制变量比事后用算法去弥补效果要好得多。4. 双轨检测的完整实现每一步都是经验4.1 传统视觉基线用OpenCV做液位定位传统方法的核心逻辑是“药液颜色 形态学滤波 高度投影”。输液液体无论是葡萄糖还是生理盐水在图像上一般呈现为淡黄色或无色透明加上瓶壁的透光性它和空气区域的灰度分布是有区分的。第一步先做颜色空间转换把BGR转到HSV用颜色阈值把液体区域粗提取出来。这里要特别说明不要直接在BGR上做阈值HSV下的饱和度与色调更稳定受亮度波动影响小。提取后用中值滤波去噪再做一次闭运算把小的空洞填上。第二步是找液面位置。方法很简单把二值图像按列做像素统计对每一行计算液体像素占比从下往上扫描遇到连续几行占比低于阈值的位置就认为是液面所在高度。再把这个高度和瓶体总高度做比值映射到high/normal/low/empty四个档位。这套代码不到100行就能跑通但它有个天然缺陷如果液体颜色和背景相近或者瓶壁反光太强二值化结果里会出现大块断裂区。这也是为什么不能只靠传统方法的原因。4.2 深度学习分支轻量级YOLO的实际训练细节深度学习分支我建议从YOLOv5s起步因为相关教程最多遇到问题最容易排查。但实际部署时YOLOv8s的效果更好精度提升明显而且推理速度相差不大。考虑到树莓派这样的设备建议直接用ncnn或者ONNX Runtime跑转换后的模型帧率可以做到10FPS以上足够检测液位用了。训练配置方面我用的输入尺寸是640×640batch size 16epoch 80初始学习率0.01采用余弦退火衰减。这里有个经验教训不要一上来就加大输入尺寸检测小物体时大输入确实有优势但这个项目里的输液瓶占画面比例较大640已经足够再增大只是徒增推理耗时。损失曲线在60个epoch左右趋于平稳最后的验证集mAP0.5达到了0.96低液位和空瓶这两个关键类别的召回率均在0.95以上。这个结果比传统视觉基线好但传统方法在正常场景下也能跑到0.93左右两者的差距并没有想象中那么大。这正是值得在论文里分析的点。4.3 融合决策状态机两个分支的结果怎么合并是影响系统稳定性的关键。我设计了一个简单的状态机一共四个状态分别为高液位、正常、低液位、空瓶。每个状态下都有相应的触发条件。规则如下每当传统分支给出结果为低液位或空瓶且深度学习分支置信度大于0.6时立即进入对应的告警状态。如果两个分支结果不一致则取深度学习分支结果但标记为“待确认”连续5帧之后才触发状态切换。这样做的原因是单帧误检率高但5帧连续一致时误检概率会大幅下降。状态机的好处还在于它给测试带来了极大的便利。你可以在视频回放中逐帧标注当前真实状态然后看状态机的输出是否和真实状态一致。这样做评测比只算模型的单帧分类准确率更有说服力。4.4 硬件选型与部署成本控制整体预算控制在500元以内是完全可行的。树莓派4B是主流选择性能足够生态成熟价格在300元左右。摄像头选普通的USB免驱摄像头50元左右。再加上一个蜂鸣器模块、两个LED灯和若干杜邦线总成本不超过450元。如果预算更紧张也可以考虑用香橙派或类似的国产开发板成本能再压100元。但你需要提前确认OpenCV和ONNX Runtime的兼容性这个坑我在用某些小众开发板时踩过有些板子上的NPU驱动对ONNX的支持不完整导致模型加载失败。部署软件环境时我建议直接用Docker封装运行环境把Python版本、OpenCV、ONNX Runtime、Flask等依赖全部锁进镜像。这样你在演示时不会因为环境问题翻车。我吃过这个亏毕设答辩前一天换了一台电脑环境装了半天差点没赶上演示。5. 趋势预测与数据记录项目里的“大数据”元素5.1 数据记录的设计逻辑很多毕设做到液位检测就停了但我觉得趋势预测这个环节才是让项目升一个档次的关键。系统每30秒往SQLite数据库里写入一条记录包括时间戳、当前液位高度像素值、当前检测状态。这样积累一小时就有120条数据点一次完整输液过程就是几千条数据。为什么要记录液位高度而不是只记状态因为状态是离散的而高度是连续的。连续数据可以做拟合可以算滴速可以预估剩余时间这些才是对护士真正有用的信息。在答辩的时候你拿出一张液位随时间下降的散点图再叠加一条拟合曲线效果比任何文字说明都有说服力。5.2 剩余时间预测的两种实现路径第一种是线性拟合。液位下降过程在匀速滴注时近似线性所以用最小二乘法对最近10个数据点做一次线性回归斜率的倒数乘以当前剩余液位高度就是预估剩余时间。这个方法简单直接误差在正常滴速下不超过10%可以接受。第二种是滑动窗口ARIMA预测。这个方法适合液滴速度不均匀的情况比如患者手臂移动导致滴速变化。把液位高度序列视为时间序列用ARIMA模型做短时预测。我在实验中测试了ARIMA(1,1,1)的参数组合预测未来10分钟的液位变化平均绝对误差比线性拟合低了约30%。代价是模型训练时间稍长但在树莓派上完全跑得动。5.3 数据可视化与告警日志配套的数据可视化可以做一个简易Web页面用Flask加Chart.js展示实时液位曲线和历史告警列表。页面每10秒刷新一次能看到当前液位状态、剩余时间预估、当日告警次数。这部分工作量和难度都不高但对系统完整性帮助很大尤其是答辩现场一个有Web界面实时刷新的系统会让评委直观感受到项目的闭环能力。告警记录表设计为id、时间、液位高度、触发类型视觉告警/预测告警、是否已处理五个字段。这个表是后续做召回率统计的数据基础也能体现“数据驱动”的工程思维。6. 系统评测用数据说话才硬气6.1 评测指标体系如何设计答辩时最怕被问“你的系统准不准”如果只回答“准”就完了因为没有依据。要建立一套可复现的评测方法。我的评测分三个层面模型层、系统层、场景层。模型层用的是mAP、Precision、Recall三个标准指标可以对比两种检测路线的差异。系统层看的是告警响应延迟、状态切换准确性、误报率。场景层则模拟三种典型使用条件光线充足的白天、光线偏暗的夜间、强背光干扰分别统计系统整体表现。最终测试结果给出一个可以直接放论文里的表格评测场景传统视觉准确率深度学习准确率融合系统准确率告警延迟中位数正常光照93.2%96.8%97.6%1.4秒夜间暗光84.6%92.1%94.3%1.8秒强背光干扰76.8%89.4%92.5%2.1秒模拟震动场景81.3%88.9%91.7%2.0秒这个表格能直观说明两个问题一是融合方案确实优于任何单一方案二是系统在恶劣条件下仍然保持可用水平。有数据支撑的观点答辩时自然站得住脚。6.2 别忘了做“失败分析”很多毕设项目只放成功的准确率我觉得这是个失分点。真诚地分析一下系统在什么情况下会失效反而体现工程素养。我在反复测试中发现当输液瓶被遮挡超过1/4时视觉检测效果急剧下降此时需要依靠预测分支兜底。另外液体颜色过深比如某些药物呈深棕色时HSV颜色阈值会失效深度学习分支的表现也会波动。这些失败分析不是让你否定自己的项目而是展示你已经理解系统能力的边界。评委问“你的系统有什么不足”时你能有理有据地说出三条不足和对应的改进方向这比支支吾吾强十倍。7. 答辩全流程实战从开场到收尾的节奏控制7.1 答辩PPT的逻辑主线PPT建议控制在12页左右顺序是背景痛点、需求分析、系统架构、数据集构建、算法选型与对比、实验设计、系统实现、结果分析、创新点总结、后期改进方向。我见过很多答辩翻车的例子大多不是因为项目做得不好而是PPT线索混乱评委根本跟不上思路。每一页PPT只讲一个核心问题不要堆砌。比如“数据集构建”这一页就讲三件事数据怎么来的、标注规范是什么、规模和数据增强怎么做。讲清楚这三点评委就能判断你数据方面的工程质量。一套好的答辩话术是先讲问题再讲方案再讲验证过程最后讲局限与展望。不要一上来就说用了某种高大上算法评委更想听的是“你如何判断这个项目的问题并解决它”。7.2 现场演示的排雷指南现场演示是答辩里最危险也最加分的环节。我的建议是准备两套演示方案实时演示和录像演示。优先用实时演示但一定要把录像作为Plan B。因为摄像头、灯光、网络任何一环出问题实时演示都可能翻车。实时演示脚本需要提前彩排至少五遍。第一遍走全流程第二遍专注于讲解节奏第三遍专门模拟意外情况比如故意遮挡摄像头看系统的容错表现。录像是给你一个保险——万一现场摄像头无法识别你的录像至少能完整展示系统正常运行的状态。开场白我自己试过多次最自然的方式是直接说思路不废话不煽情。7.3 容易被追问的刁钻问题和应答逻辑根据我总结的经验评委最常问的问题集中在几个方向第一个方向为什么不直接用现成的液位传感器而要选择视觉方案应答要点是——投入产出比。电容式液位传感器精度高但无法贯通测量连续液位且需要贴合瓶体不同规格的输液瓶要不同型号。视觉方案只要一个通用摄像头就能适配各种瓶体改造成本最低。第二个方向你自己采集的数据集和真实医院场景的差距有多大应答要点是——承认差距同时强调迁移学习的可行方案。可以说“当前数据集聚焦于模拟场景后续可以通过少量真实医院数据做微调用域自适应方法缩小分布差距这也是后续工作可以重点推进的方向”。第三个方向如果网络断开系统还能用吗这是一个很容易被问到的检查点。答本地推理不依赖云服务所有检测和告警在边缘设备完成网络只负责日志上传断开不影响核心功能。这个回答背后的逻辑是你的系统设计是否做了充分的本地化部署考量。8. 常见问题与排坑实录越到后面越要稳住8.1 我把开发中最典型的五个坑列出来第一个坑是摄像头白平衡漂移。自动白平衡会在环境光线变化时响应过慢导致画面颜色漂移HSV阈值检测失效。解决办法是在OpenCV里关闭自动白平衡改用固定色温参数。第二个坑是ONNX Runtime版本不兼容。YOLOv8s模型导出ONNX后在树莓派上加载时曾遇到算子不支持的报错原因是onnxruntime版本过旧。锁定onnxruntime版本在1.16以上问题就解决了。第三个坑是推理线程阻塞。在树莓派上同时跑视频采集和模型推理如果都在主线程里循环调用界面会卡死。解决办法是用多线程采集线程只管抓帧推理线程用队列消费最新帧并丢弃未处理的旧帧。这样做的原因是系统只需要实时响应不需要处理每一帧。第四个坑是SQLite并发写入失败。告警模块和状态记录模块都往数据库写偶尔会出现“database is locked”错误。解决办法是加一个数据库写入队列所有写入操作串行执行读取操作放在另外一个连接上进行。尽量不要让多个线程同时对同一个SQLite连接进行操作。第五个坑是蜂鸣器误报噪声过大。低液位状态下蜂鸣器会一直响现场测试时吵得人受不了。解决办法是改为间歇性鸣叫响1秒停2秒同时加上一个消音按钮护士确认后可以手动关闭当前告警。8.2 每个坑背后的工程思维如果只把上面这些当成Bug去解决格局就小了。白平衡漂移的问题告诉你视觉系统必须考虑环境自适应性线程阻塞的问题告诉你实时系统的核心不完全是算法性能还包括调度策略数据库并发问题告诉你日志系统设计要提前想清楚读写路径。这些坑在论文的“系统实现与优化”章节都可以作为素材。把如何发现问题、分析原因、设计方案、验证解决的过程完整写出来比单纯堆砌技术指标更能体现工程能力。因为有一个优秀工程师的核心素质就是排除故障的系统化思维。8.3 提一个“数据备份与离线运行”的小建议我建议在系统里加一个简单的自动备份功能每完成一次输液过程自动把SQLite数据库文件和当日告警日志打包压缩存储到U盘备份目录。这个功能代码量很小但展现了你对数据可靠性的重视。答辩现场如果你主动提这一点评委对你的印象分往往会有明显提升。另外系统应能够在完全离线状态运行所有核心功能不依赖外网。这一点我在答辩时反复强调过它是一个非常实在的加分项因为医疗场景对网络故障的容忍度极低。9. 最后一个建议在项目里留一个“彩蛋”如果你还有余力我建议在系统里加入一个自动滴速估计功能通过分析液滴在滴壶中下落的间隔估算当前滴速。这个功能可以在无人值守时自动记录滴速波动曲线当滴速偏差超过20%时触发提醒。它不需要额外硬件只用现有摄像头对滴壶区域做一个动态ROI检测就能实现。这个“彩蛋”在答辩现场演示时效果会很好——它能直接解决护士关心的核心问题之一而且视觉技术的深度也更足。我当时做了一个简化版效果很好好几个评委都追问了实现细节。项目做完之后我最大的体会是一个好的毕设项目不是技术名词堆砌得越多越好而是把有限的几个技术点做扎实把每个环节的逻辑讲通透。输液液位检测这个题目看着不大但把数据、算法、硬件、部署、评测、答辩这一整条链路走下来你收获的绝对不仅仅是一个模型精度数字——你会真正理解一个能落地的系统是怎么从零长出来的。
1. 我需要先聊聊“为什么是输液液位检测”1.1 医院病房里的真实痛点到底是什么静脉输液是医院里最日常的治疗手段之一但它的监护方式几十年没怎么变过——靠患者家属盯瓶子、靠护士定时巡房。我自己去医院陪护时见过最典型的场景家属盯着输液瓶不敢眨眼药液快完了赶紧按铃护士跑过来换瓶一天来回几十趟。这套流程看起来没什么问题但它本质上依赖的是人的注意力。人的注意力是会衰减的特别是在深夜、在患者多的时候。从问题本质来看输液监护要解决的是三件事液位低了能及时知道、滴速异常能被发现、输液过程中尽量少打扰患者和护士。前两个是安全需求第三个是体验需求。而我见过的很多所谓“输液监控系统”要么只做了个射频标签加重力感应精度不够要么价格高到只有ICU才用得起。普通病房需要的其实是一个低成本、易部署、识别的准的视觉检测方案。1.2 适合做成计算机毕设项目的关键点在哪选择“静脉输液液位检测系统”作为毕设项目有它天然的合理性。第一它有明确的视觉目标——输液瓶里的液面是清晰可观测的不像一些抽象的分类问题那样边界模糊。第二它同时涉及传统图像处理和深度学习两条技术路线适合做对比实验、消融实验这在答辩时有话可说。第三它有一个真实的部署场景硬件成本可控做出来是一个完整的软硬结合系统而不是一个纯跑数据的算法Demo。大多数毕设项目容易犯的毛病是“偏科”——要么只做算法不管部署要么只做硬件算法刻意弱化。而这类项目天然要求你兼顾两端我觉得这是它作为毕设选题最大的优势。如果往深了做还能把时间序列预测、告警日志分析这些“大数据”方向的内容加进去让项目的技术层次更丰富。这也是我在这篇文章里想重点展开的部分不只是告诉你模型怎么训练而是把一个完整项目从数据到答辩的每个环节都摊开讲。2. 需求拆解与整体方案选型2.1 一个合格的系统应该做到什么程度先把项目需求拆细直接用表列出来。这个表也是你写开题报告时可以直接用的素材功能维度核心需求关键指标备注液位状态识别区分高液位、正常、低液位、空瓶四类状态准确率 ≥ 95%低液位和空瓶是告警重点告警响应液位低于阈值时触发本地声光告警并推送记录延迟 ≤ 2秒本地蜂鸣器加LED历史追溯记录每次输液过程的时间、液位变化、告警记录可查询、可导出为数据分析提供原始数据趋势预测根据历史液位变化速率预测剩余时间误差不超过10%这是“大数据”方向的主要落点成本控制整套硬件成本控制在500元以内越便宜越好便于普通病房推广从需求倒推技术路线液位识别是核心可以用深度学习模型做也可以用传统图像处理做趋势预测需要时间序列数据所以系统得有记录功能告警需要本地硬件响应所以得有输出接口。这些需求叠在一起项目自然而然就成了一个软硬件结合的系统。2.2 为什么“深度学习传统视觉”两条腿走路我在做这个项目之前最先想到的方案是用摄像头拍摄、用YOLO直接检测液面位置。但后来我发现一个问题如果只依赖深度学习数据量不够的时候模型会很不稳定。而单纯用传统图像处理比如边缘检测加阈值分割在光照变化大、瓶子有反光的时候误检率也比较高。所以最后我采用了双轨方案传统视觉算法作为实时基线在每一帧上做快速检测保证基本功能不出错深度学习模型负责在复杂场景下做修正当两个结果不一致时以置信度更高的一方为准。这种做法在工业检测里叫“多传感器融合”在毕设项目里它还有一个隐藏的好处——你可以比较两种路线的效果差异形成完整的实验对比这在答辩时会非常加分。系统整体架构是这样的摄像头采集图像预处理后并行跑两个检测分支。传统分支用颜色阈值加形态学处理提取液位高度深度学习分支用轻量级YOLO模型检测输液瓶区域并分类液位状态。两个分支的结果汇入一个简单状态机由状态机决定是否触发告警。与此同时系统每30秒记录一次当前液位高度形成时间序列写入本地数据库供后续趋势预测使用。3. 数据从哪里来别再去网上找了自己造3.1 真实医疗数据的合规难题与应对思路做医疗AI第一个绕不开的问题就是数据。真实的医院输液场景视频属于患者隐私数据获取流程极其繁琐而且要经过伦理审查。作为一个毕设项目你不能也不应该在公开渠道随便找医疗影像数据来用这里面的合规风险是实实在在的。我采用的替代方案是搭建一个模拟输液环境自己采集数据。具体做法是找一个透明的玻璃输液瓶灌入不同颜色和不同水位的液体放置在光照可调节的背景板前用摄像头从正面和侧面分别采集图像。通过改变水的颜色淡黄、淡红、无色、改变液面高度、改变背景亮度、改变瓶子角度模拟出尽可能丰富的实际工况。这样建出来的数据集虽然和真实医院场景有差异但胜在数据完全可控、标注精确、版权和隐私问题为零。而且在这个采集过程中你已经接触到数据生产流程的完整链路——从场景搭建到数据清洗到标注规范——这本身就是工程项目里很宝贵的经验。3.2 标注规范与数据集规模的设计我用LabelImg工具标注标注类别设为四类high液位高于2/3、normal液位在1/3到2/3之间、low液位低于1/3且可见、empty瓶底基本无液体。注意这里有个细节标注的是“整个输液瓶的液位状态”而不是去标注液面的具体分割线。这样设计的好处是模型学的是“瓶子呈现出的整体状态特征”而不是某个精确的边界位置。数据集规模我做到了1500张图像其中900张用于训练300张验证300张测试。每张图像中除了输液瓶本身还人为加入了一些干扰物比如桌面的反光、旁边的其他瓶子、不同背景纹理这样训练的模型才会具备一定的抗干扰能力。数据增强用了随机亮度扰动、随机裁剪、水平翻转、高斯模糊四类把训练集扩到了2400张左右。一个小提示拍摄时尽量使用固定机位因为这个系统最终部署时摄像头位置是固定的训练数据里过度变化的视角反而会让模型学到不必要的位置特征。3.3 数据标注容易踩的坑标注这件事看着简单做的过程中就会遇到很具体的问题。最大的坑是“状态边界”的定义。比如液面刚好在1/3刻度线附近该标成normal还是low我处理的办法是把这类模糊样本单独分出来标为unsure不参与训练。其实深度学习模型对边界模糊本身就具有容错性你硬给它一个标签反而会干扰训练。第二个坑是光线方向不一致。前期我拍的图片有些是从窗户方向采光有些是从室内灯光采光结果训练出来的模型在验证集上表现不稳定。后来统一使用正面漫射光源并额外采集了一些强逆光样本作为负样本模型稳定性明显改善。这说明采集数据时控制变量比事后用算法去弥补效果要好得多。4. 双轨检测的完整实现每一步都是经验4.1 传统视觉基线用OpenCV做液位定位传统方法的核心逻辑是“药液颜色 形态学滤波 高度投影”。输液液体无论是葡萄糖还是生理盐水在图像上一般呈现为淡黄色或无色透明加上瓶壁的透光性它和空气区域的灰度分布是有区分的。第一步先做颜色空间转换把BGR转到HSV用颜色阈值把液体区域粗提取出来。这里要特别说明不要直接在BGR上做阈值HSV下的饱和度与色调更稳定受亮度波动影响小。提取后用中值滤波去噪再做一次闭运算把小的空洞填上。第二步是找液面位置。方法很简单把二值图像按列做像素统计对每一行计算液体像素占比从下往上扫描遇到连续几行占比低于阈值的位置就认为是液面所在高度。再把这个高度和瓶体总高度做比值映射到high/normal/low/empty四个档位。这套代码不到100行就能跑通但它有个天然缺陷如果液体颜色和背景相近或者瓶壁反光太强二值化结果里会出现大块断裂区。这也是为什么不能只靠传统方法的原因。4.2 深度学习分支轻量级YOLO的实际训练细节深度学习分支我建议从YOLOv5s起步因为相关教程最多遇到问题最容易排查。但实际部署时YOLOv8s的效果更好精度提升明显而且推理速度相差不大。考虑到树莓派这样的设备建议直接用ncnn或者ONNX Runtime跑转换后的模型帧率可以做到10FPS以上足够检测液位用了。训练配置方面我用的输入尺寸是640×640batch size 16epoch 80初始学习率0.01采用余弦退火衰减。这里有个经验教训不要一上来就加大输入尺寸检测小物体时大输入确实有优势但这个项目里的输液瓶占画面比例较大640已经足够再增大只是徒增推理耗时。损失曲线在60个epoch左右趋于平稳最后的验证集mAP0.5达到了0.96低液位和空瓶这两个关键类别的召回率均在0.95以上。这个结果比传统视觉基线好但传统方法在正常场景下也能跑到0.93左右两者的差距并没有想象中那么大。这正是值得在论文里分析的点。4.3 融合决策状态机两个分支的结果怎么合并是影响系统稳定性的关键。我设计了一个简单的状态机一共四个状态分别为高液位、正常、低液位、空瓶。每个状态下都有相应的触发条件。规则如下每当传统分支给出结果为低液位或空瓶且深度学习分支置信度大于0.6时立即进入对应的告警状态。如果两个分支结果不一致则取深度学习分支结果但标记为“待确认”连续5帧之后才触发状态切换。这样做的原因是单帧误检率高但5帧连续一致时误检概率会大幅下降。状态机的好处还在于它给测试带来了极大的便利。你可以在视频回放中逐帧标注当前真实状态然后看状态机的输出是否和真实状态一致。这样做评测比只算模型的单帧分类准确率更有说服力。4.4 硬件选型与部署成本控制整体预算控制在500元以内是完全可行的。树莓派4B是主流选择性能足够生态成熟价格在300元左右。摄像头选普通的USB免驱摄像头50元左右。再加上一个蜂鸣器模块、两个LED灯和若干杜邦线总成本不超过450元。如果预算更紧张也可以考虑用香橙派或类似的国产开发板成本能再压100元。但你需要提前确认OpenCV和ONNX Runtime的兼容性这个坑我在用某些小众开发板时踩过有些板子上的NPU驱动对ONNX的支持不完整导致模型加载失败。部署软件环境时我建议直接用Docker封装运行环境把Python版本、OpenCV、ONNX Runtime、Flask等依赖全部锁进镜像。这样你在演示时不会因为环境问题翻车。我吃过这个亏毕设答辩前一天换了一台电脑环境装了半天差点没赶上演示。5. 趋势预测与数据记录项目里的“大数据”元素5.1 数据记录的设计逻辑很多毕设做到液位检测就停了但我觉得趋势预测这个环节才是让项目升一个档次的关键。系统每30秒往SQLite数据库里写入一条记录包括时间戳、当前液位高度像素值、当前检测状态。这样积累一小时就有120条数据点一次完整输液过程就是几千条数据。为什么要记录液位高度而不是只记状态因为状态是离散的而高度是连续的。连续数据可以做拟合可以算滴速可以预估剩余时间这些才是对护士真正有用的信息。在答辩的时候你拿出一张液位随时间下降的散点图再叠加一条拟合曲线效果比任何文字说明都有说服力。5.2 剩余时间预测的两种实现路径第一种是线性拟合。液位下降过程在匀速滴注时近似线性所以用最小二乘法对最近10个数据点做一次线性回归斜率的倒数乘以当前剩余液位高度就是预估剩余时间。这个方法简单直接误差在正常滴速下不超过10%可以接受。第二种是滑动窗口ARIMA预测。这个方法适合液滴速度不均匀的情况比如患者手臂移动导致滴速变化。把液位高度序列视为时间序列用ARIMA模型做短时预测。我在实验中测试了ARIMA(1,1,1)的参数组合预测未来10分钟的液位变化平均绝对误差比线性拟合低了约30%。代价是模型训练时间稍长但在树莓派上完全跑得动。5.3 数据可视化与告警日志配套的数据可视化可以做一个简易Web页面用Flask加Chart.js展示实时液位曲线和历史告警列表。页面每10秒刷新一次能看到当前液位状态、剩余时间预估、当日告警次数。这部分工作量和难度都不高但对系统完整性帮助很大尤其是答辩现场一个有Web界面实时刷新的系统会让评委直观感受到项目的闭环能力。告警记录表设计为id、时间、液位高度、触发类型视觉告警/预测告警、是否已处理五个字段。这个表是后续做召回率统计的数据基础也能体现“数据驱动”的工程思维。6. 系统评测用数据说话才硬气6.1 评测指标体系如何设计答辩时最怕被问“你的系统准不准”如果只回答“准”就完了因为没有依据。要建立一套可复现的评测方法。我的评测分三个层面模型层、系统层、场景层。模型层用的是mAP、Precision、Recall三个标准指标可以对比两种检测路线的差异。系统层看的是告警响应延迟、状态切换准确性、误报率。场景层则模拟三种典型使用条件光线充足的白天、光线偏暗的夜间、强背光干扰分别统计系统整体表现。最终测试结果给出一个可以直接放论文里的表格评测场景传统视觉准确率深度学习准确率融合系统准确率告警延迟中位数正常光照93.2%96.8%97.6%1.4秒夜间暗光84.6%92.1%94.3%1.8秒强背光干扰76.8%89.4%92.5%2.1秒模拟震动场景81.3%88.9%91.7%2.0秒这个表格能直观说明两个问题一是融合方案确实优于任何单一方案二是系统在恶劣条件下仍然保持可用水平。有数据支撑的观点答辩时自然站得住脚。6.2 别忘了做“失败分析”很多毕设项目只放成功的准确率我觉得这是个失分点。真诚地分析一下系统在什么情况下会失效反而体现工程素养。我在反复测试中发现当输液瓶被遮挡超过1/4时视觉检测效果急剧下降此时需要依靠预测分支兜底。另外液体颜色过深比如某些药物呈深棕色时HSV颜色阈值会失效深度学习分支的表现也会波动。这些失败分析不是让你否定自己的项目而是展示你已经理解系统能力的边界。评委问“你的系统有什么不足”时你能有理有据地说出三条不足和对应的改进方向这比支支吾吾强十倍。7. 答辩全流程实战从开场到收尾的节奏控制7.1 答辩PPT的逻辑主线PPT建议控制在12页左右顺序是背景痛点、需求分析、系统架构、数据集构建、算法选型与对比、实验设计、系统实现、结果分析、创新点总结、后期改进方向。我见过很多答辩翻车的例子大多不是因为项目做得不好而是PPT线索混乱评委根本跟不上思路。每一页PPT只讲一个核心问题不要堆砌。比如“数据集构建”这一页就讲三件事数据怎么来的、标注规范是什么、规模和数据增强怎么做。讲清楚这三点评委就能判断你数据方面的工程质量。一套好的答辩话术是先讲问题再讲方案再讲验证过程最后讲局限与展望。不要一上来就说用了某种高大上算法评委更想听的是“你如何判断这个项目的问题并解决它”。7.2 现场演示的排雷指南现场演示是答辩里最危险也最加分的环节。我的建议是准备两套演示方案实时演示和录像演示。优先用实时演示但一定要把录像作为Plan B。因为摄像头、灯光、网络任何一环出问题实时演示都可能翻车。实时演示脚本需要提前彩排至少五遍。第一遍走全流程第二遍专注于讲解节奏第三遍专门模拟意外情况比如故意遮挡摄像头看系统的容错表现。录像是给你一个保险——万一现场摄像头无法识别你的录像至少能完整展示系统正常运行的状态。开场白我自己试过多次最自然的方式是直接说思路不废话不煽情。7.3 容易被追问的刁钻问题和应答逻辑根据我总结的经验评委最常问的问题集中在几个方向第一个方向为什么不直接用现成的液位传感器而要选择视觉方案应答要点是——投入产出比。电容式液位传感器精度高但无法贯通测量连续液位且需要贴合瓶体不同规格的输液瓶要不同型号。视觉方案只要一个通用摄像头就能适配各种瓶体改造成本最低。第二个方向你自己采集的数据集和真实医院场景的差距有多大应答要点是——承认差距同时强调迁移学习的可行方案。可以说“当前数据集聚焦于模拟场景后续可以通过少量真实医院数据做微调用域自适应方法缩小分布差距这也是后续工作可以重点推进的方向”。第三个方向如果网络断开系统还能用吗这是一个很容易被问到的检查点。答本地推理不依赖云服务所有检测和告警在边缘设备完成网络只负责日志上传断开不影响核心功能。这个回答背后的逻辑是你的系统设计是否做了充分的本地化部署考量。8. 常见问题与排坑实录越到后面越要稳住8.1 我把开发中最典型的五个坑列出来第一个坑是摄像头白平衡漂移。自动白平衡会在环境光线变化时响应过慢导致画面颜色漂移HSV阈值检测失效。解决办法是在OpenCV里关闭自动白平衡改用固定色温参数。第二个坑是ONNX Runtime版本不兼容。YOLOv8s模型导出ONNX后在树莓派上加载时曾遇到算子不支持的报错原因是onnxruntime版本过旧。锁定onnxruntime版本在1.16以上问题就解决了。第三个坑是推理线程阻塞。在树莓派上同时跑视频采集和模型推理如果都在主线程里循环调用界面会卡死。解决办法是用多线程采集线程只管抓帧推理线程用队列消费最新帧并丢弃未处理的旧帧。这样做的原因是系统只需要实时响应不需要处理每一帧。第四个坑是SQLite并发写入失败。告警模块和状态记录模块都往数据库写偶尔会出现“database is locked”错误。解决办法是加一个数据库写入队列所有写入操作串行执行读取操作放在另外一个连接上进行。尽量不要让多个线程同时对同一个SQLite连接进行操作。第五个坑是蜂鸣器误报噪声过大。低液位状态下蜂鸣器会一直响现场测试时吵得人受不了。解决办法是改为间歇性鸣叫响1秒停2秒同时加上一个消音按钮护士确认后可以手动关闭当前告警。8.2 每个坑背后的工程思维如果只把上面这些当成Bug去解决格局就小了。白平衡漂移的问题告诉你视觉系统必须考虑环境自适应性线程阻塞的问题告诉你实时系统的核心不完全是算法性能还包括调度策略数据库并发问题告诉你日志系统设计要提前想清楚读写路径。这些坑在论文的“系统实现与优化”章节都可以作为素材。把如何发现问题、分析原因、设计方案、验证解决的过程完整写出来比单纯堆砌技术指标更能体现工程能力。因为有一个优秀工程师的核心素质就是排除故障的系统化思维。8.3 提一个“数据备份与离线运行”的小建议我建议在系统里加一个简单的自动备份功能每完成一次输液过程自动把SQLite数据库文件和当日告警日志打包压缩存储到U盘备份目录。这个功能代码量很小但展现了你对数据可靠性的重视。答辩现场如果你主动提这一点评委对你的印象分往往会有明显提升。另外系统应能够在完全离线状态运行所有核心功能不依赖外网。这一点我在答辩时反复强调过它是一个非常实在的加分项因为医疗场景对网络故障的容忍度极低。9. 最后一个建议在项目里留一个“彩蛋”如果你还有余力我建议在系统里加入一个自动滴速估计功能通过分析液滴在滴壶中下落的间隔估算当前滴速。这个功能可以在无人值守时自动记录滴速波动曲线当滴速偏差超过20%时触发提醒。它不需要额外硬件只用现有摄像头对滴壶区域做一个动态ROI检测就能实现。这个“彩蛋”在答辩现场演示时效果会很好——它能直接解决护士关心的核心问题之一而且视觉技术的深度也更足。我当时做了一个简化版效果很好好几个评委都追问了实现细节。项目做完之后我最大的体会是一个好的毕设项目不是技术名词堆砌得越多越好而是把有限的几个技术点做扎实把每个环节的逻辑讲通透。输液液位检测这个题目看着不大但把数据、算法、硬件、部署、评测、答辩这一整条链路走下来你收获的绝对不仅仅是一个模型精度数字——你会真正理解一个能落地的系统是怎么从零长出来的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
