晚上十点的病区走廊，呼叫铃刚响过一轮，护士小跑着换完一瓶液体回到护士站，还没坐稳，另一床的滴速报警又响了。这种画面在临床上一对比真实：患者液体走空、滴速变慢、药袋拿错、换瓶不及时，大部分要靠人工盯守和一双眼睛反复核对。一位在某病区工作的护士长朋友跟我闲聊时说了句话：“如果滴速监视和药袋核对这两个动作能合成一个自动化系统就好了。”这句话直接催生了这套基于arduino的病患滴液匹配系统原型。它不是什么高深医疗设备，而是把红外滴珠检测、RFID身份识别、称重校验和舵机调速给串成一个闭环，把“人、处方、药袋、滴速”四件事用单片机管起来，能匹配、能计量、能纠错、能报警。这篇文章就围绕这套系统，讲清需求拆解、硬件选型、软件逻辑、实测数据和踩过的坑，给想复现或者想在此基础上做毕设、做医工信息化项目的读者一个能直接上手的参考。
1. 为什么医院输液会“滴错人”：场景与需求拆解
1.1 输液护理中的真实痛点
输液这件事看起来简单：针扎上、挂上瓶、调滴速、走人。但实际病房里，输液是整个护理流程中出错风险最高、占用人力最多的环节之一。
先说核对压力。每瓶液体从药房到患者手里，中间要经过科室二次核对、床旁核对、加药混合、换瓶记录等环节。传统靠的是“三查七对”，查对的内容包括床号、姓名、药名、浓度、剂量、方法、时间。这套制度本身没毛病，但依赖人在高强度工作下不犯迷糊。夜班、连续处置、多床并行呼叫时，靠记忆和肉眼核对，风险就会上升。某院医务科之前统计过差错事件，输液相关占到的比例相当高，其中相当一部分属于药袋标识与患者身份不匹配、或者调错滴速。
再说滴速监控。很多患者家属比护士更紧张液体有没有滴完，因为输液滴速直接关系到给药安全和治疗时长。成人常用滴速大约每分钟30到40滴，儿童和重症有的慢到每分钟15到20滴。滴速过快可能引起循环负荷过重，过慢则影响按时给药。护士调好滴速后，患者体位变动、挂瓶高度变化、输液管打折，都会让实际滴速漂移。靠护士频繁巡查很难兼顾所有床位。
我做这个项目前也想过：医院不是有输液泵吗？但输液泵价格高、需要电源管理、耗材和管路要专用，普通病房不可能每个床位都配。低成本的监测辅助设备，在普通病区和社区门诊里反而更实用。病患滴液匹配系统的定位，不是替代护士，而是当一个不会累的助手：盯着滴、盯着药袋、盯着身份。
1.2 “匹配”到底匹配什么：患者、处方、药袋、滴速
项目名叫“病患滴液匹配系统”，很多人第一反应是“匹配滴速”，但真正做的时候会发现，匹配是多维的。我把整个系统要管的内容拆成了四个维度，缺一不可。
- 患者身份匹配：确认此刻在输液的这个人，是不是本次医嘱对应的患者。
- 处方匹配：系统要能知道当前患者正在执行什么处方，哪几种药、用量多少、计划多久输完。
- 药袋匹配：实际挂上去的药袋，从药品名称到规格，必须和处方一致。
- 滴速匹配：系统监测实时滴速，并与医嘱要求的滴速范围做闭环校正。
这四个维度之间的关系，用一张对照表能看得很清楚：
| 匹配维度 | 输入来源 | 系统输出 | 失败后果 |
|---|---|---|---|
| 患者身份 | RFID腕带/身份卡 | 患者编号、当前处方列表 | 给错误的患者输上液体 |
| 处方匹配 | 预置的处方数据表 | 药品名、剂量、滴速上下限 | 用药方案与医嘱不符 |
| 药袋匹配 | 药袋RFID标签 + 称重数据 | 药品名、总量、剩余量校验 | 拿错药袋或空袋挂上 |
| 滴速匹配 | 红外滴珠传感器 | 当前滴速、误差上报 | 滴速过快或过慢、输液延迟 |
只看“匹配”两个字，容易理解成一个比对过程；真正落地才发现，“比对”只是软件层面的一个步骤，前后还有大量的数据采集和现场感知工作。这也是为什么这个项目要同时用到RFID、称重传感器和红外液滴检测。
1.3 系统的功能边界：能做什么，不能做什么
设计原型时我给系统划了很清楚的能力边界。
能做的事包括：滴珠自动计数并换算滴速；对超过滴速范围的情况报警；用RFID确认患者和药袋身份；用称重校验药袋重量防止空袋和标签错贴；通过舵机缓慢调节滴速；把所有状态显示在LCD上并记录事件。
不能做的事，也必须说清楚：它不能替代护士做临床判断，不能直接控制输液泵给药，不能在断电、断网情况下保证报警，更不能把未经过完整医疗电气安全验证的原型机直接用于真实患者。这个项目更适合作为课程设计、创客项目、医工系统的功能验证demo，或者后续改装成智能监测研究平台。我真的做原型时，也始终把它定位在“辅助监护”而不是“治疗设备”的层级。
明确了边界，后续的每一个设计决策就都有了依据。下面进入硬件的核心部分，先说清楚滴珠怎么测、身份怎么认。
2. 硬件选型：一滴一滴怎么测量，患者怎么认证
2.1 主控：成熟的arduino Uno已经够了
谈传感器之前，先把平台问题说清楚。这套系统的主控，我最终选了arduino Uno。有人问为什么不上更高性能的板子，或者直接用STM32？答案是：够用就行。
系统里真正费计算资源的活儿，无非是读取红外中断、读取RFID UID、读取称重数据、显示LCD、控制舵机。这些工作Uno完全能扛住，而且Uno生态成熟，库文件丰富，调试工具多，出问题容易排查。对原型验证来说，开发效率比极限性能重要得多。
Uno有几个点在这个项目里是刚需：外部中断引脚（D2/D3）适合滴珠脉冲计数；SPI总线方便接RFID模块；I2C总线方便接LCD和扩展传感器；PWM引脚可以控制舵机。这些功能不是它独有的，但组合起来非常省事。
选型还要考虑现场环境的容错。医院的病床周边电磁环境其实比较复杂，频繁开关的电机、输液泵、呼叫系统都可能带来干扰。Uno的5V逻辑电平抗干扰能力不如工业级方案，但我们在信号线上加RC滤波、用屏蔽线走脉冲信号，实测足够稳定。如果后续要做多床位扩展，再考虑换更高规格主控也不迟。
2.2 滴珠检测的红外方案设计与信号调理
滴速监测是整个系统的“眼睛”，这块做不好，后面匹配和报警全是空中楼阁。
我采用的方案是红外对射式检测，把红外发射管和光敏接收管分别卡在滴斗两侧，让液滴从上往下经过两者之间。液滴有折射和吸光特性，当它穿越光束时，接收管收到的光强会发生一个明显跳变，转换成电信号就是一个脉冲。
具体实现上，我没有直接用裸光电管接arduino模拟口，因为裸管信号输出幅度小、还容易受环境光干扰。更稳定的做法是用一块集成比较器的红外对管模块，上面带有可调电位器和数字输出口，调节阈值后输出标准的3.3V/5V数字电平。这样既能拿到干净的数字信号，又能直接把输出接到arduino的外部中断引脚上。
还有一个容易被忽略的细节：安装位置。滴斗内部的结构决定了滴珠并不是始终落在正中位置，液滴会在滴斗入口处形成、然后垂直下落，但由于管壁张力和病人活动带来的倾斜，落点会稍微偏移。所以我把对管安装位置定在滴斗入口下方大约2到3厘米处，并把两个对管稍作内收，保证液滴从光束中间穿过。采集到的信号脉宽一般在10到20毫秒，如果用软件在中断里做20毫秒去抖，基本不会漏掉真实滴珠，也不会被抖动信号干扰。
2.3 患者身份和药袋验证：RFID加称重双重校验
身份匹配是“病患滴液匹配”里最容易做花样、也最容易做虚的部分。我选择了RFID方案，因为它的使用流程最贴近病房真实操作：患者手腕上戴一个RFID腕带，药袋上贴一个RFID标签，护士操作时先刷卡再刷袋，系统自动查表核对。
RFID模块用的是基于MFRC522协议的通用读卡模块，工作频率13.56MHz，支持14443A卡和钥匙扣卡。模块通过SPI接口和arduino通信。使用时把读卡器固定在一个盒子上，护士手持药袋或者患者腕带靠近即可，识别距离大约3到5厘米，对短距离核对场景足够。
但光靠RFID有个漏洞：标签只能证明“这个药袋贴了这个标签”，不能证明“药袋里真的有液体”。药房打单时贴错标签、液体已经输完但没有人换袋，这时候RFID依然显示“可匹配”。
所以我在吊钩上加了一路称重校验。用HX711芯片接一个悬臂式称重传感器，把药袋挂在传感器挂钩上。系统读取实时重量，再对比药袋标签里登记的毛重和当前患者处方需要的液体重量范围，误差超过预设阈值就直接报警。这一招能拦住两种最典型的错误：空袋被执行、贴错标签被执行。
2.4 滴速调节执行机构：用舵机做渐进式夹子
输液管路的滴速调节，本质上是改变液体通过的阻力。临床上护士用手指转动滴管上的滚轮，把管路压扁一点，滴速就变慢；松开一点，滴速就变快。我这个系统里用舵机模拟这个动作。
舵机选用常用的9克微型舵机，输出力矩足够压缩输液管硅胶段。机械结构上设计了一个夹持执行器：舵机臂推动一个圆弧形压片，压片压在输液管外侧，舵机角度从60度到120度变化，对应压紧程度从完全松开到基本堵死。这里有个原则，不能让舵机一次性大步长动作，否则滴速会突然跳变，有安全风险。程序里把每次修正控制在1到2度的步长，并且设置了上限角度，防止压管过死。
为什么不用电磁阀或蠕动泵？电磁阀响应快但动作粗暴，一旦误动作就是完全阻断，风险太大；蠕动泵精度高但要专用管路，成本上去了。舵机方案的好处是“慢、柔、可逆”，即使PID完全跑飞，物理上也不会因为一次指令就把管路死死夹住。慢，在这个场景里反而是优势。
2.5 外围配套与接线布局
整套系统还要配显示、报警和供电部分。我用的是2004字符型LCD配I2C模块，四行内容分别显示患者编号、药名、当前滴速和目标滴速。报警部分用蜂鸣器和红色LED，不同场景用不同次数和节奏的鸣响区分：匹配失败两声短鸣，滴速异常三声短鸣，输液接近完成持续慢鸣。
供电思路要单独讲一下。arduino用USB供电看似方便，但加上舵机、RFID和蜂鸣器后，电流需求可能超过USB单口稳定输出能力。舵机启动瞬间的电流尤其大，电压跌落会导致arduino重启。我的做法是：舵机单独用一个5V/2A的适配器供电，arduino用另一个5V供电，两个电源的地线连在一起但供电回路分开。这样的“电源隔离”能有效防止干扰。
完整的接线分配如下：
| 外设 | 信号线 | arduino引脚 | 备注 |
|---|---|---|---|
| 红外液滴检测模块 | OUT | D2 | 外部中断0 |
| RFID读卡器 | SDA / SCK / MOSI / MISO / RST | D10 / D13 / D11 / D12 / D9 | SPI总线 |
| HX711称重 | DT / SCK | A0 / D4 | 读取药袋重量 |
| 舵机 | 信号 | D6 | 滴速夹执行器 |
| 蜂鸣器 | I/O | D3 | 分级报警 |
| LED指示灯 | I/O | D5 | 状态指示 |
| LCD2004 | SDA / SCL | A4 / A5 | I2C接口 |
接线看起来简单，实际做的时候我的建议是给红外信号线和称重数据线都套上屏蔽层，并把信号回路在arduino侧并联一个100nF电容到地。这一手在病床附近实测下来，能够明显减少干扰导致的误计数。
3. 软件逻辑：把“滴错人”挡在算法里
3.1 全局状态机的设计
硬件搭起来之后，真正的灵魂在软件逻辑里。我一开始直接写了一堆函数，散乱调用，结果发现各种边界情况处理不干净。后来改成状态机结构，整个系统一下子清晰了。
状态机定义了五个基本状态：待机、身份核对、药袋核对、输注监控、报警处理。
- 待机：系统上电，等待护士刷患者腕带或药袋。
- 身份核对：读取患者UID，在预置患者表里找到对应处方。
- 药袋核对：读取药袋RFID，同时读取称重数值，执行匹配逻辑。
- 输注监控：匹配通过后，舵机松到设定角度，红外滴珠检测开始工作，系统持续计算滴速并和处方目标比对。
- 报警处理：匹配失败、无滴珠、滴速超限、重量突降，都会进入对应的报警分支。
用状态机的好处是：任何一个环节卡住，系统都知道自己“现在该干什么”，不会因为异常跳转而重复执行同一段操作。代码维护起来也直白，每个状态对应一个处理函数，逻辑互不干扰。
3.2 滴珠判断的滤波与滴速计算
滴珠检测最核心的需求是把“真实滴珠”从干扰信号里捞出来，然后算出稳定、可信的滴速。
在外部中断函数里，我做的第一件事是时间滤波。收到一个下降沿中断后，先记录当前毫秒时间，对比上一次中断触发时间，如果间隔小于20毫秒，直接判断为抖动，放弃。真实滴珠的下落间隔即使是最快的每分钟120滴，也至少在500毫秒以上，所以20毫秒去抖窗口不会误杀真实信号。
去抖后的时间是相邻两颗液滴的时间差。滴速计算公式很简单：
volatile unsigned long lastDropTime = 0; volatile unsigned long thisDropTime = 0; volatile unsigned int dropCount = 0; volatile unsigned long intervalMs = 0; void dropISR() { unsigned long now = millis(); if (now - thisDropTime < 20) return; lastDropTime = thisDropTime; thisDropTime = now; intervalMs = thisDropTime - lastDropTime; dropCount++; } float getDropRate() { if (intervalMs == 0) return 0; return 60000.0 / intervalMs; }单次间隔换算出来的滴速波动很大，因为液滴本身就不是绝对匀速的。我在主循环里取最近20次间隔的中位数作为当前实时滴速，中位数比平均值更抗偶然抖动。用这个方式测出来，目标30滴/分钟的工况下，显示值能稳定在29.5到30.5之间，偶尔跳一下也在误差范围内。
还有一个专业名词要提一下：滴系数。输液器厂家会在包装上标出每毫升对应多少滴，常见有10、15、20、60滴每毫升。医嘱给的是“多少毫升每小时”或者“多少滴每分钟”，处方表里必须同时存滴系数，才能让系统把毫升换算成滴速。比如500毫升液体，3个小时输完，滴系数15滴/毫升，那么总滴数是7500滴，滴速就是7500除以180分钟，约等于每分钟41.6滴。系统会把处方给的毫升数换算成目标滴速，再和红外传感器实测滴速做闭环比对。这个换算逻辑虽然简单，但涉及处方表设计，很多复现者会忽略。
3.3 三重匹配流程：患者、处方、实物药袋
匹配流程是这套系统的核心体验。我用一个模拟场景来演示整个流程：
第一步，护士将患者腕带靠近RFID读卡器。系统读到一个UID后，在患者数据表里查到患者编号，表中还预置了他的处方列表，包含药品名、单次剂量、总毫升数、滴系数和目标滴速范围。
第二步，护士拿起从药房领到的药袋，将药袋上的RFID标签靠近读卡器。系统读到药袋UID，在药品表中查询到药名、规格、毛重等参数。
第三步，系统自动比对：药袋药品名是否在患者处方里；药袋规格与处方是否一致；称重传感器读到的实时重量是否在“空袋+药液”的合理范围内。三件事全部通过，才进入输注监控状态。
如果任何一个环节对不上，系统会立刻拒绝打开滴速执行器，并发出匹配失败报警。比如患者A的处方根本不包含葡萄糖注射液，护士却刷了葡萄糖药袋，系统直接红灯警告，舵机锁定在初始关闭位置。这一套逻辑从软件实现上并不复杂，但现场意义很大：它把“查对”从人工记忆变成了机器强制校验。
3.4 滴速控制的闭环逻辑
滴速闭环控制我采用的是简化版PID的变体，核心思路是“小步慢调、死区保护”。
主循环每隔5秒计算一次当前滴速，和处方目标比较，得到误差值。当误差绝对值小于3滴/分钟时，认为在允许范围内，不动作，避免系统频繁打扰。当误差超过阈值时，根据误差方向微调舵机：滴速偏低就松开压片1到2度，滴速偏高就压紧1到2度。
这个策略看起来简单，但实际效果比教科书式的完整PID更安全。因为输液管路的压紧程度和滴速之间存在非线性关系，在接近全关的位置，角度变化一点点滴速就变化很大；在完全松开的位置，角度变化又影响很小。如果PID参数调得激进，很容易震荡。用死区加固定小步长，虽然收敛慢，但全程稳定，不会出现滴速忽快忽慢。
实测中从某个异常滴速修正回目标范围，一般需要10到30秒，这个响应速度在输液场景里完全够用。毕竟护士手动调节也没那么快，而且人调完往往还会过头。
4. 从接线到跑通：完整搭建过程和实测记录
4.1 硬件组装的关键步骤
整个原型机的组装过程，值得拿出来说说步骤顺序，因为顺序错了会浪费大量排查时间。
我建议的顺序是：先固定机械结构，再连传感器，最后接执行器。机械结构就是把红外对管支架固定在滴斗两侧、称重传感器固定在输液架的挂钩位置、舵机夹持器固定在滴管下方某处。这个顺序不能乱，因为如果先连接了复杂电路，后面调整机械位置时很容易扯断信号线。
固定好机械件以后，再按照之前那张表格接线。接完线先做单项测试：单独给红外模块供电，用手在滴斗处做遮挡动作，看串口输出是否产生脉冲；单独刷RFID卡，看读卡器能否返回UID；单独读取称重值，看挂上药袋前后重量是否有合理变化。单项测试全过，才进行联调。
联调时我第一次就踩了坑：RFID和LCD同时工作正常，但滴珠计数串口数据偶尔跳数。排查后发现是舵机转动时造成电源瞬时波动，影响了红外模块的比较器阈值。后来把舵机改到独立供电，同时给红外模块加了一个小电容退耦，问题立刻消失。
4.2 系统初始化与自检流程
原型机加电后，不能直接进入待机状态。程序里我写了一个约3秒的自检过程：读一次称重传感器的零漂，确认传感器输出在合理范围；读取IR模块的数字输出状态，确认滴斗区域没有阻挡物；尝试读取一次RFID模块的固件版本号，确认SPI总线通信正常；舵机先回到初始角度，再松到默认位置。
自检结果通过LCD显示，比如显示“SELF-TEST OK”。一旦自检失败，蜂鸣器会连续鸣叫，并循环停在该错误项，不进入后续流程。这套自检逻辑花费的代码量不大，但现场体验差距明显。设备一上电就进入状态，和上电后才发现传感器没响应，完全两种感受。
自检通过后，系统显示当前的患者列表名称和等待刷卡提示。护士刷完患者腕带，再刷药袋，LCD会分两行显示比对结果。整个过程一气呵成，大概15秒内完成一次完整核对。
4.3 实测数据与调参结果
我搭建的是模拟输液环境：用生理盐水袋、一次性输液器和一个废液收集瓶，没有接真实患者。连续测试了多个时段，这里挑几组有代表性的数据：
| 测试项 | 目标值 | 实测值 | 误差情况 |
|---|---|---|---|
| 滴珠计数 | 300滴 | 301滴 | 0.33% |
| 滴速控制 | 30滴/分钟 | 29.8-30.4滴/分钟 | 稳定 |
| 滴速控制 | 40滴/分钟 | 39.6-40.5滴/分钟 | 稳定 |
| 匹配正确率 | 40组标签 | 40组判断正确 | 无一次误判 |
| 输完报警 | 药袋重量低于阈值 | 触发报警 | 无漏报 |
| 停滴报警 | 人为捏住管路 | 3至5秒内报警 | 延迟可接受 |
滴珠计数误差主要来自边界情况，比如液滴正好在下落过程中断裂成两段，或者滴斗壁上的液珠滑落产生第二信号。用了中位数滤波和去抖后，计数误差控制在千分之一以内，对滴速显示和报警判断来说完全够用。
匹配正确率100%听起来很漂亮，但这里要诚实说明：我只是在一个受控环境里测试了固定标签集，没有覆盖标签损坏、超远距离误读、药物袋重量误差过大等复杂场景。真实环境下的匹配性能，还要通过更大样本去验证。
5. 实景干扰中踩过的坑，以及对应处理
5.1 滴斗起雾导致检测失效
这是整个调试过程中最头疼的问题，没有之一。输液器滴斗内部有液滴不断飞溅，管壁上会凝结一层水雾。水雾在光源和接收管之间形成漫反射，红外信号会被严重削减，导致原本清晰的脉冲变得非常微弱，甚至完全消失。
第一次遇到这个问题时，我怀疑是光电模块损坏，排查了半个多小时才发现是滴斗内壁雾气。处理办法有两个层面。一是选型层面，改用增益更高、带自动阈值校准的红外对管模块；二是结构层面，把对管从水平正对改成略微倾斜，让光束尽量穿过液滴下落通道，而不是贴着滴斗内壁的雾气层。两个措施叠加后，信号幅值恢复到了可分辨的程度。
这里也推荐一个调试技巧：在串口监视器里以200Hz左右的采样频率实时打印接收管的模拟值，观察滴珠经过时的波形特征。肉眼看到明显的“尖峰-回落”形状，说明结构安装合适；波形模糊得像慢坡，说明安装位置或雾气影响需要处理。
5.2 药袋晃动造成称重误判
HX711称重传感器本身分辨率可以到克级，但病房里患者翻身、家属触碰床架、输液架微微晃动，都会让药袋产生加速度，称重读数剧烈跳动。如果直接拿瞬时重量去做匹配和报警判断，很容易误报。
我的处理方式是在软件里加了滑动均值滤波：每次读取20个采样值取平均，然后再对这20个平均值取滑动中位数。同时把“重量异常”判断设置了持续条件，要求连续3次以上超过阈值才触发报警，而不是单次跳变就报警。
这个逻辑有点像学生时代做模拟电路时候的“去毛刺”，原理不复杂，但在现场非常管用。挂袋时人为晃动输液架，读数也基本稳定在预设区间内。
5.3 药袋遮挡等原因导致红外信号盲区
实际挂液时，输液袋的标签、药房的装药清单有时候会耷拉下来，正好挡在滴斗外侧，把红外对管的光路完全遮住。这种情况红外模块会输出一个恒定的遮挡信号，系统误以为一直有液滴，滴速计算直接爆表。
排查过程是这样的：串口打印发现滴速显示为999，但肉眼看到滴斗里液滴速度正常。拿手电筒照一下才发现是纸质标签挡住了检测窗。解决手段很笨但有效，在红外模块外围加一个半开放的遮光罩，只给液滴下落通道留出窗口，杂质物没有机会贴在检测面上。
这个坑让我深刻意识到，现场环境永远比桌面环境脏乱差得多。做医疗相关设备原型，边界感一定要强，任何可能被患者或者家属触碰到的东西，都要提前做物理防护。
5.4 报警疲劳：频率和分级都要克制
一开始我把报警条件设置得很敏感，滴速偏离目标2滴/分钟就会响。结果测试过程中蜂鸣器几乎每隔几十秒就叫一次，听到后来我都不想处理了。这就是典型的报警疲劳，长期处于高频报警状态下，真正出严重问题时反而不被人注意。
后来我把报警重新分级：滴速偏离但还在安全区间，只更新LCD显示，不响铃；滴速持续5秒以上严重偏离，短响三声；匹配失败或重量异常，持续响铃并点亮红灯；停滴超过10秒，连续鸣叫直到护士确认。分级的核心是让报警在“需要关注”和“需要处置”之间拉开档次。实际跑下来，鸣叫次数大幅下降，但真正报警时的威慑感反而更强了。
6. 想复现这套系统的人，先搞清楚这几件事
6.1 材料清单与成本估算
整套原型的材料成本，我在国内市场环境下大致估了一下，控制在200元以内：
| 材料 | 用途 | 估算成本 |
|---|---|---|
| arduino Uno兼容板 | 主控 | 30-60元 |
| 红外对管模块 | 滴珠检测 | 5-15元 |
| MFRC522 RFID读卡模块 | 患者/药袋识别 | 5-20元 |
| HX711 + 称重传感器 | 药袋重量校验 | 10-30元 |
| 9克舵机 | 滴速夹执行 | 5-15元 |
| 2004 LCD + I2C模块 | 状态显示 | 10-20元 |
| 蜂鸣器、LED、电阻、面包板 | 报警与连接 | 10-20元 |
| 5V电源和降压模块 | 稳定供电 | 20-40元 |
| 支架、3D打印件、热缩管 | 机械固定 | 20-50元 |
如果你手里已经有arduino和基础传感器，实际新增投入几十元就能跑起来。注意电源模块不要图便宜，多花十几块钱买纹波小的电源，能避免大量诡异的硬件复位问题。
6.2 调试顺序建议和必要仪器
复现时最怕的是所有功能一起调，出了问题完全不知道在哪。我建议严格按三个阶段推进。
第一阶段只调感知层：确保红外模块能正确识别液滴、RFID能读到标签、称重能稳定读数。第二阶段只调逻辑层：把每个传感器数据打印到串口，用程序里的状态机驱动流程。第三阶段才接执行层：让舵机开始介入，此时如果发生机械上问题，还能用前面的串口数据辅助定位。
必备工具方面，不需要昂贵仪器。一个靠谱的USB转串口调试助手、一个数字万用表、一把质量好的杜邦线就够了。万用表主要用来检查电源轨电压和信号线通断；调试助手用来观察串口输出的滴珠间隔和状态机跳转情况。
6.3 安全边界与后续扩展方向
最后必须说一个原则性问题：这类原型系统不具备医疗器械资质，不能直接拿来给真实患者用。我做的所有测试都是在模拟输液环境里完成的，没有接入任何真实治疗流程。如果有人想继续做下去，我建议把这个项目当成医工结合的技术验证平台，在合规前提下开展数据采集和交互设计研究。
如果还想扩展，我个人觉得有两个方向很有价值。一个是往无线化走，加一块Wi-Fi模块，把滴速、匹配结果和报警事件推送到护士站的大屏或者手机端，这在病房物联网里非常实用。另一个方向是做多床位管理，用一块主控带多个传感器节点，通过分布在病床旁的采集终端，集中到一个上位机界面。原型的匹配算法和状态机逻辑，在这两个方向上基本可以复用，主要工作量会落在通信协议和并发管理上。
最后说一点个人体会。做完这套系统，我最深的感觉是：医疗场景里的“智能”，要求的不只是准确率，更重要的是行为的可预期性和安全性。一个设备可以允许偶尔误报，但绝对不能突然做出不可控的动作。所以整个系统里，我最满意的不是识别和匹配算法，反而是舵机的“小步慢调”和报警的“分级克制”——它们让整套系统变得温和、可靠、可沟通。如果你也要做类似的项目，不妨把“安全感和确定性”放在性能指标的前面来考虑。那样做出来的东西，哪怕只是一个课堂里的原型，也会让你自己觉得踏实。
