1. 项目概述与系统整体设计思路1.1 这个项目解决的是什么问题输液监护这个场景做硬件的朋友应该都不陌生。传统输液方式最大的痛点就是必须有人盯着——护士要定时巡视、家属要守着吊瓶药液滴完如果没有及时发现回血、空气栓塞这些风险就来了。即使现在很多医院用了输液泵也不过是把“盯着”这件事交给了昂贵设备本质上还是依赖于医护人员的主动观察。我在复盘这个“智能输液监护调控系统-升级版”项目时最核心的设计动机就是解决两个问题一是自动监测二是自动调控。监测好理解就是实时感知滴速和剩余药液量异常时报警调控则是更进一步通过电机控制挤压输液管让滴速稳定在医生设定的范围内药液快滴完时自动减慢甚至停止避免空气进入血管。这一版被称为“升级版”主要是相较于初版做了三点改动加入闭环调速、优化低功耗下的传感器采集可靠性、补充了Proteus仿真工程让没有实体硬件的初学者也能先跑通逻辑流程。这个项目特别适合三类人看正在做课程设计的电子信息类学生、刚入门STM32想找个完整项目练手的开发者、以及在医院设备科或医疗电子行业工作的工程师。1.2 系统整体架构拆解整个系统的功能划分可以用一句话概括采集端负责感知主控端负责决策执行端负责动作显示端负责交互。采集端有两个关键信号源一是红外对管或光电传感器检测墨菲斯滴管内的液滴下落二是称重传感器配合HX711模块检测整瓶药液的重量变化。这两个信号互为冗余又各有侧重——红外对管测的是瞬时滴速响应快称重模块测的是总量可以算出剩余药量和预计输液完成时间。主控端用的是STM32F103C8T6选择这颗芯片的原因很实在成本低、资料全、性能够用。72MHz主频跑滴速计算和PID控制完全有余量20KB RAM足够支撑多级缓冲和多模式逻辑切换。主控承担的工作包括定时器输入捕获处理红外传感器的脉冲信号、软件I2C或模拟时序读取HX711数据、执行PID算法输出PWM控制电机转速、驱动OLED/LCD显示参数、处理按键中断和蜂鸣器报警。执行端是一个小型蠕动泵或直流减速电机通过挤压硅胶管控制药液流速。这里有一个很多新手容易踩的坑电机转速和滴速不是线性关系因为输液管的弹性、针头粗细、药液粘稠度都会影响实际流量所以纯开环控制根本稳不住滴速必须用闭环——这也是这版升级的核心。显示与交互端保留物理按键和屏幕没有做手机APP联动刻意保持系统独立性。原因很直接医疗场景下有线连接比无线更可靠减少通信协议带来的不确定因素这在功能验证阶段是明智的选择。1.3 升级版相比初版改进了哪些关键点初版的问题我在测试中记录得比较清楚红外对管检测滴速时如果滴速太慢比如低于20滴/分钟单片机容易误判为停滴蠕动泵转速波动大导致打印出来的滴速曲线忽高忽低还有一个很隐蔽的bug——HX711的SCK引脚和按键共用了同组IO按键按下瞬间读数跳变几十克。升级版针对这些问题逐一做了处理滴速检测改为外部中断定时器捕获双通道确认不仅检测脉冲下降沿还通过两个通道的时间间隔过滤毛刺信号电机控制加入增量式PID目标值从“转速”改为“滴速”直接对最终物理量闭环IO资源重新分配把传感器和交互外设彻底隔离另外增加了系统自检流程——上电后先检测传感器是否在线屏幕显示传感器状态而不是像初版那样直接进入主界面省得调试时排错半天。这些改动看起来单项都不难但合在一起系统稳定性提升非常明显。2. 方案选型剖析传感器、主控与执行机构的取舍2.1 滴速检测红外对管为什么比摄像头方案更实用滴速检测是这个项目的感知核心方案选择直接决定了系统复杂度和可靠性。我见很多学习者用摄像头加图像识别来检测效果确实好但代价是MCU跑不动得换MPU级别甚至树莓派成本和开发周期完全不是一个量级。对于“能落地、可复现”的智能输液监护系统红外对管方案仍然是最优解。具体结构是一对红外发射管和接收管卡在墨菲斯滴管两侧。液滴落下时经过光路红外线被液滴折射和吸收接收管输出电平发生变化。整理一下电路状态转换无液滴时接收管导通输出低电平液滴经过瞬间光线被遮挡输出跳变为高电平。这样每一次液滴下落就产生一个脉冲。实际操作时有一个很重要的细节对管的位置要对准液滴下落的轨迹中心。墨菲斯滴管内壁容易挂水珠如果对管位置偏了水珠残留会导致持续遮挡误判成连续滴液。我在初版测试时发生过这个问题解决办法是在滴管两侧贴遮光海绵片做一个大约2mm宽的狭缝只允许光线从固定位置穿过水珠留在海绵材质表面就不容易形成光路遮挡。信号进单片机后用输入捕获模式测量相邻两个脉冲的时间间隔滴速 60秒 / 间隔秒数。如果1.5秒内没有脉冲到来判断为停滴或堵塞系统触发报警并自动将电机降速到安全值。这里补充一个经验滴速检测不能只靠一个阈值判断因为输液刚开始时滴管内可能有空气扰动建议在启动后前5秒做一个“稳定窗口”窗口内的数据只作参考不触发报警逻辑。2.2 药液余量监测称重方案的数据稳定性处理称重模块选用HX711加电阻应变式压力传感器量程选5kg规格因为一瓶250ml生理盐水加瓶子自重大约在350g左右留出足够余量。HX711是24位高精度ADC通过SCK和DOUT两根线跟MCU通信硬件上非常简单。但称重方案的坑主要在数据稳定性上。输液过程不是静止的——药液在滴管内流动输液管晃动甚至护士调整病床高度都会引起传感器读数波动。如果直接拿原始读数去计算剩余药量显示的数字会不停跳动严重时还会误触发低液量报警。处理办法分三步硬件滤波、软件均值、迟滞比较。硬件上在传感器和HX711之间加一个RC低通滤波器10kΩ电阻并联0.1μF电容截止频率大约160Hz先滤掉一部分高频噪声软件上对连续20次采样排序后取中位数这样意外尖峰就不会影响结果最后的液量阈值判断用迟滞比较——低液量报警阈值设为50ml但恢复正常标记要到70ml才解除避免临界范围反复切换报警状态。另一个实用技巧是在系统校准时执行两件工程师容易偷懒但千万别省的事去皮和标定。开机提示用户确保吊瓶为空瓶状态按去皮键将当前重量记为0然后放入已知重量的标准砝码我当时用的是一瓶未开封的500ml矿泉水电子秤先称好实际重量记录ADC原始值算出线性比例系数K 实际重量 / (ADC值 - 零点值)。后续的重量换算就是 (当前原始值 - 零点值) × K注意符号方向取决于传感器的安装方向。2.3 执行机构蠕动泵vs夹紧式电磁阀的决策逻辑控制输液速度的执行机构市面上常见的方案有两类蠕动泵和夹紧式电磁阀也叫截止阀。这个项目最终选了蠕动泵理由如下对比项蠕动泵夹紧式电磁阀调速能力连续可调配合PWM可任意设定转速只有全开/全关/半开三态精度低控制方式直流电机PWM闭环方便需要高压驱动12V/24V电磁阀功耗高流量线性度一定范围内近似线性但需校准通过改变挤压行程控制流量精度较差机械复杂度需要蠕动泵头、硅胶管结构简单但行程控制机构不简单成本常见型号约30-80元医用级电磁阀价格偏高选蠕动泵的另一个原因是符合“调控”的项目定位——如果只需要报警而不调速夹紧阀确实够用但升级版的核心功能就是闭环稳速必须有连续的调节手段。直流减速电机配合L298N或DRV8833驱动模块PWM频率设为10kHz避开音频噪声占空比从0到100%对应滴速从0到最大约120滴/分钟的调节范围。实践中要注意蠕动泵的机械特性低速时转速过低扭矩不足容易出现爬行现象就是电机一顿一顿地转微小转速输出严重非线性。解决办法是给PID控制器的输出加一个死区低于最小有效占空比时直接输出0避免执行机构在小信号下反复振荡。3. 硬件设计细节与原理图深度解读3.1 电源系统的三级稳压设计这个项目外部供电是12V适配器但系统内部需要多组电压电机驱动需要12V、传感器和逻辑电路需要5V、MCU和OLED需要3.3V。如果简单用一片AMS1117-3.3直接从12V降至3.3V压差接近9V线性稳压器的功耗 压差 × 电流 ≈ 9V × 0.05A 0.45W虽然不至于烧毁但芯片发烫严重长时间运行可靠性堪忧。所以电源部分做成了三级结构12V先经过一个DCDC降压模块MP1584或LM2596输出5V给传感器和逻辑电路5V再经AMS1117-3.3转出3.3V给MCU和显示模块。这样每级压差都不超过2V热损耗显著降低。还有一个容易遗漏的点电机启动瞬间电流尖峰。蠕动泵电机堵转时电流可能到1A甚至更高如果电源没有足够余量电压会被拉低导致MCU复位或者HX711读数异常。我的解决方法是电机供电和逻辑供电在电源模块出口前用π型滤波分离——L1电感10μH串联给逻辑电路电机回路直接走粗线同时在12V母线并联一个大容量电解电容470μF/25V和一个TVS管SMBJ15A吸收瞬态尖峰。3.2 STM32最小系统与IO资源分配表画原理图时STM32F103C8T6最小系统包括8MHz晶振经PLL倍频到72MHz、32.768kHz低速晶振用于RTC可选、复位电路、BOOT0下拉电阻确保从Flash启动、SWD下载调试接口4线SWDIO、SWCLK、GND、3.3V、以及每个VDD/VSS引脚的0.1μF去耦电容。IO资源分配在升级版中做了明确规划这里给出我最终定版的完整清单功能模块IO引脚备注HX711_SCKPA0模拟时序驱动输出时钟脉冲HX711_DOUTPA1数据输入下降沿触发读取红外对管OUTPA8外部中断输入下降沿触发电机PWMPA2 (TIM2_CH3)10kHz PWM输出经驱动芯片电机方向/使能PA3高电平使能方向固定OLED_SCLPB6 (I2C1_SCL)软件I2C模拟OLED_SDAPB7 (I2C1_SDA)软件I2C模拟蜂鸣器PB0有源蜂鸣器高电平触发按键K1-设置PB1内部上拉按下为0按键K2-加PB10内部上拉按键K3-减PB11内部上拉按键K4-启动/停止PB12内部上拉备用串口PA9/PA10USART1预留调试这里有一个教训值得写进原理图注释PA0和PA1同时复用了HX711的数据引脚和按键的某个备用脚设计时千万别贪方便把多个外设挤在同一组IO上。升级版之所以把按键全部移到PB端口就是因为在初版上吃了共IO的亏——按下按键瞬间会改变引脚电平状态传感器读数直接跳变这种干扰在原理图评审阶段就得挡掉。3.3 传感器信号调理电路设计要点红外对管这部分电路设计要特别注意接收管的偏置电阻选择。我的电路是发射管串联220Ω限流电阻接5V接收管光电三极管的集电极接5V发射极通过10kΩ下拉电阻到地信号从发射极取出。这个10kΩ的取值很关键——太小了输出高电平不够太大了响应速度变慢。实测10kΩ在10kHz脉冲下波形边沿约30μs完全满足滴速检测的响应需求。HX711和称重传感器之间的接线用四线制E、E-接传感器的激励输入端A、A-接传感器的信号输出端。原理图上要注意把A和A-之间的差分走线包地避免电机PWM线从旁边经过时引入串扰。我实际测试时发现电机转起来之后HX711读数会有规律性波动排查后确认就是PWM走线和A信号线在PCB上平行走了大约3cm间距只有0.5mm。后来把信号线改成垂直穿越并加宽地线隔离问题就消失了。4. 软件核心逻辑拆解与代码实现4.1 三段式程序架构初始化、轮询、中断响应固件代码整体上采用前后台架构——主循环做非实时任务中断服务函数处理实时性要求高的任务。这套架构在医疗监控场景里非常成熟比上RTOS更可控关键路径执行时间可精确计算。初始化阶段做这些事SystemInit时钟配置到72MHz、GPIO模式初始化、NVIC中断优先级配置、定时器初始化TIM2用于PWM输出TIM3用于输入捕获/基准时基、HX711上电延时后读取首次零点、OLED显示欢迎界面和传感器自检状态。主循环前台的循环周期控制在20ms以内每轮执行读取HX711数据约40ms一次刚好和循环周期匹配、执行滴速PID计算并更新PWM占空比、更新OLED显示限帧率不超过20Hz避免I2C通信拖慢主循环、扫描按键消抖状态机。中断服务函数后台有三路外部中断EXTI9_5处理红外对管脉冲每次触发记录当前系统时间戳TIM3的计数值然后与上一次时间戳做差得到滴间隔TIM2的更新中断用于PWM输出无额外逻辑串口空闲中断用于调试命令接收比如在线修改目标滴速或强制电机动作。4.2 滴速检测算法从脉冲间隔到稳定滴速值滴速检测的数学关系很直接滴速滴/分钟 60000ms / 相邻脉冲间隔ms。如果间隔是1000ms滴速就是60滴/分钟。但直接算出来的瞬时滴速抖动很大——人手动调整输液管滚轮时甚至会出现两滴连落的情况两个脉冲间隔极短。所以软件端要加一个滑动平均滤波器保存最近10次滴间隔去掉最大值和最小值后取平均再换算成滴速。这个窗口长度是我测试后定下来的太短小于5次滤波效果差太长大于20次响应迟钝滴速真正变化时系统要十几秒才能跟上这在医疗场景下不行。还有一个细节相邻脉冲间隔超时判定。如果连续3秒没有新的滴间隔更新说明输液可能停止或堵塞。这时候需要区分两种情况——是电机停转还是液路堵塞判断依据是电机是否在转动如果PWM占空比大于0但滴速为0判断为管路堵塞或液尽立即报警并反向旋转电机1秒尝试“松管”如果PWM占空比为0且滴速为0判断为正常停机仅提示输液完成。4.3 蠕动泵闭环控制增量式PID的工程实现PID控制是这个升级版项目的灵魂。先说为什么用增量式而不是位置式位置式PID输出是绝对占空比值一旦计算错误或饱和电机会猛地冲到一个错误转速上增量式PID输出的是“相对上次调整了多少”天然带记忆性且不会产生积分饱和时的剧烈超调对执行机构的冲击更小。增量式PID的公式ΔU(k) Kp × [e(k) - e(k-1)] Ki × e(k) Kd × [e(k) - 2e(k-1) e(k-2)] U(k) U(k-1) ΔU(k)其中误差e(k) 目标滴速 - 当前滴速。目标滴速由用户通过按键设定典型范围20~80滴/分钟。控制周期选1秒和滴速数据更新率匹配。参数整定方面我分享一下实测过程先设置Kp2、Ki0、Kd0观察滴速响应曲线。此时系统表现为从启动到接近目标大约要5秒超调量约15%比如目标60滴实际冲到69滴然后缓慢回落。接着把Ki逐步加大到0.05发现稳态误差消失初始阶段大约差3-4滴/分钟但出现了约±2滴的周期性波动。最后加Kd0.5波动被压到±1滴以内响应时间缩到约3秒整体效果满足临床输液精度需求±1滴基本是肉眼看不出差别的水平。实际代码里还有一个保护逻辑PWM输出占空比上下限限制。上限80%防止低速时电机扭矩不足而堵转下限15%低于这个值电机根本转不动直接输出0。PID输出如果超过这个范围直接饱和到边界值同时置一个标志位供显示模块提示“电机已到极限”。4.4 液晶显示状态机的实现OLED显示模块采用软件I2C驱动SSD1306方案相比硬件I2C省掉了复用引脚的麻烦代价是占一点CPU时间。显示内容分三屏主界面显示实时滴速、目标滴速、剩余药量、预计时间参数设置界面显示当前目标值和加减箭头提示报警界面全屏显示故障类型STOP-SLOW / NO-DRIP / LOW-LEVEL / PRESS-KEY。显示更新用状态机管理防止按键和显示刷新互相干扰。核心状态定义如下S_INIT自检、S_RUN正常运行、S_SET_SPEED设置目标滴速、S_ALARM报警、S_PAUSE暂停。每次状态跳转时OLED刷新对应界面同时蜂鸣器按不同频率鸣叫提示操作成功——进入设置界面时短鸣一声参数保存时长鸣一声报警时连续间歇鸣叫。这套状态机写下来约200行C代码逻辑直接初学者对照状态转移表很容易看懂。5. 仿真环境搭建与Proteus调试实录5.1 为什么这版项目要额外做一套Proteus仿真很多玩STM32的开发者对Proteus仿真有偏见觉得“仿真和实物的差距太大跑了也是白跑”。这话对一半。对于这个输液监控系统仿真真正能验证的是逻辑正确性和状态跳转是否合理——按键按下后滴速显示是否正确变化、到达报警阈值时蜂鸣器是否触发、LCD显示是否按预期切换。这些属于逻辑层面的验证跟ADC精度、PWM驱动能力这些模拟量无关。我搭的Proteus工程包含STM32F103C8T6模型、LCD1602显示模型Proteus的SSD1306 OLED模型不好用仿真里用LCD1602代替、按键模型、发光二极管代替蜂鸣器因为Proteus无源蜂鸣器模型响应不太直观、以及一个液滴发生器模型——这玩意儿Proteus库里没有现成的我用NE555定时器生成脉冲信号模拟红外对管的液滴脉冲脉冲频率对应滴速。这样仿真工程和实物工程的代码可以共用只是初始化函数里做条件编译区分LCD型号。5.2 仿真工程搭建步骤和常见掉坑点搭建仿真工程的步骤相对固定这里给出可直接照抄的流程新建Proteus工程选好STM32F103C8T6芯片型号在器件库添加LED、RES、BUTTON、LCD1602、NE555、CAP、CRYSTAL等基础元件按下图连接电路PA8接NE555输出端脉冲输入、PB0接LED阳极串联电阻、PB1/PB10/PB11/PB12接按键到地、PB6/PB7接LCD I2C引脚若用LCD1602则接PA0-PA7数据口STM32模型属性中设置外部晶振频率8MHz烧录HEX文件NE555的频率由R1、R2、C1决定公式f ≈ 1.44 / ((R12×R2)×C1)设置成1Hz对应60滴/分钟进行初步验证。最容易掉进去的坑有两个。一是Proteus的STM32模型默认不仿真PWM输出到电机所以仿真工程里我没放电机模型而是把PWM引脚接到一个LED上用LED亮度变化演示调速效果——这已经足够验证PID输出随误差变化的方向是否正确。二是NE555产生的脉冲是固定频率的方波不会像真实红外对管那样有随机抖动所以仿真中的滴速显示值会非常平稳和实物的±1滴波动有差异这是正常现象不能说明代码计算错误。5.3 仿真中发现的一个逻辑Bug复盘仿真最大的价值在于能复现那些“灵异”问题。我遇到过最典型的一个设置目标滴速从60改到30时滴速显示从60跳到4然后慢慢爬升到30稳定。花了很久排查逻辑最后发现问题出在增量式PID的微分项上——目标值突变时误差e(k)从0突然变成-30导致微分项Kd×[e(k) - 2e(k-1) e(k-2)]瞬间爆出一个巨大的负值PWM输出被限幅到0电机几乎停转滴速从60陡降到接近0。等到误差变化率趋缓后PID才重新把输出拉回来表现为“暴跌后缓慢爬升”。这在控制理论里叫微分冲击。解决办法有两个一是限制每次PID输出的最大增量ΔU_max我设为5%占空比让输出平滑变化二是对目标值做斜坡输入——用户按键调整目标滴速时不直接跳变而是按每秒3滴的速度逐步逼近目标值。两个方案我最终都采用了代码里加了“目标斜坡生成器”效果非常好。如果没有仿真环境这种偶发性逻辑bug要在实物上复现和排查至少要花掉一整个晚上的时间。6. 常见问题排查与避坑指南6.1 硬件调试中的高频问题速查表现象可能原因排查方法上电后OLED白屏无显示I2C地址错误或SDA/SCL接反用万用表量SCL/SDA引脚电压确认3.3V和GND正常换一个已知OK的I2C例程单独测试屏幕滴速显示值偏大或偏小红外对管位置偏移或灵敏度下降观察示波器波形确认脉冲高电平持续时间是否在合理范围重新调整对管狭缝位置HX711读数跳变共地不良或PWM走线耦合检查传感器、HX711、MCU三者是否共地万用表测量A/A-之间静态电压应稳定在mV级别电机不转使能脚电平错误或PWM频率太高用示波器查看PWM引脚波形把频率降到1kHz看是否能转确认不是驱动芯片开关速度问题蜂鸣器无声驱动电流不足或有源/无源搞混确认是有源蜂鸣器内部带振荡电路无源蜂鸣器需要PWM信号驱动才响按键偶尔失灵按键消抖时间太短把消抖时间从10ms提高到50ms同时确认按键接的是外部中断还是轮询扫描轮询方式要注意主循环周期小于消抖时间的一半6.2 软件层面容易被忽略的三个细节第一个是STM32的ADC和HX711同时使用时要特别注意I/O口的复用设置。HX711用软件模拟时序时SCK和DOUT都要配成开漏输出/输入模式如果配错成推挽复用模式时序波形会不对读数偶尔正常偶尔乱跳这类问题靠看逻辑分析仪才能发现。第二个是中断优先级分配。滴速检测用的是外部中断如果优先级低于定时器更新中断极端情况下滴间隔数据会被延迟处理导致滴速计算值偏大。我的配置是EXTI中断优先级设为2数字越小优先级越高TIM3更新中断设为3串口中断设为4。原则很简单——实时性要求越高的中断优先级越高而像串口打印这种慢速任务优先级低了反而能避免频繁打断主逻辑。第三个是悄悄藏在库函数里的坑HAL_Delay()和中断的交互问题。如果在外部中断服务函数里调用了HAL_Delay整个系统会卡住——HAL的延时基于Systick中断而外部中断优先级如果高于Systick会导致Systick无法响应延时永远不结束。我在这项目里坚持在中断里只做时间戳记录和标志位置位所有耗时运算全部丢到主循环处理从根上规避这个问题。6.3 从“能跑”到“稳定”实测数据与优化记录测试项目改善前改善后做了什么滴速稳态误差±4滴/分钟±1滴/分钟加入增量式PID 目标斜坡生成低液量报警准确性偶尔误报连续30次采样确认才报警增加迟滞比较和连续判据电机启动响应时间约6秒达到目标约3秒达到目标PID参数整定 输出限幅优化系统长时间运行稳定性4小时出现1次卡死连续12小时无异常看门狗启用 状态机初始化保护蜂鸣器误鸣率每小时约2次趋近于0报警条件增加多轮确认机制最后再分享一个调试阶段的土办法给输液系统做“矿泉水瓶模拟测试”。用500ml矿泉水瓶装水输液管末端加一个精密流量计没有的话就用量筒手工接液计时然后把系统目标滴速依次设成40、60、80滴/分钟记录实际滴速和流量数据。这个测试能同时验证三个指标滴速检测准确性、PID控制收敛性、以及蠕动泵磨损后的重复精度。建议每连续运行8小时后重新校准一次HX711零点因为泵管长期挤压后弹性会变化影响流量与转速的线性关系。我个人实际做下来最大的体会是这个项目的价值不在于“我造了一个输液泵的简陋替代品”而在于把传感器检测、闭环控制、状态机设计、软硬联调这些嵌入式核心技能完整串了一遍。仿真工程在初学阶段帮你确认逻辑实物工程在进阶阶段帮你理解真实世界的不确定性——两者配合踩过的坑都会变成你看待复杂系统的直觉。照着这个项目完整做一遍再回头去看任何带传感器加电机的智能硬件项目心里都会更有底。