基于STM32的智能输液监护调控系统设计与PID闭环控制实现

1. 升级版到底升级了什么：从"监护"到"调控"的架构变化

很多做过输液监控类项目的朋友应该都有同感：第一版往往做的只是一个"报警器"——用红外对管或者重力传感器检测输液进度，液滴快没了就蜂鸣器响，护士跑过来处理。这版所谓智能输液监护调控系统，最大的差异就落在"调控"两个字上。它不再满足于"发现问题再叫人来"，而是要在发现异常之前就主动干预，比如滴速偏离设定值、输液管内出现气泡、管路堵塞、液面低于安全线，系统要在第一时间自动调速、夹管、告警，甚至把数据通过无线模块上报到护士站。

这套系统本质上是一个典型的嵌入式闭环控制系统：传感器采集物理量，MCU做决策运算，执行机构改变被控对象，再由传感器反馈形成闭环。主控选择STM32，准确说是STM32F103C8T6，这个选型很务实——Cortex-M3内核、72MHz主频、20KB RAM、64KB Flash，对于滴速检测、PID调速、多路传感器扫描外加一个简单的OLED显示任务来说，绰绰有余。而且F103系列的开发生态太成熟了，标准库、HAL库都有大量现成参考，做毕设或者做产品原型都合适。

升级版的另一个重要变化是加入了仿真环节。我见过太多人直接焊板子，结果硬件问题软件问题搅在一起，排查起来非常痛苦。这版项目把Proteus电路仿真和Keil代码调试打通，让系统逻辑在虚拟环境里先跑通一遍，再上实物验证，整个开发节奏会健康很多。后面我会详细讲仿真模型怎么搭、哪些器件在仿真里能省、哪些不能省。

整机功能按模块拆解，大致可以分成六块：

• 信号采集端：红外对管滴速传感器 + 液位传感器 + 气泡检测模块
• 执行机构端：步进电机驱动的蠕动泵或夹管电磁阀（用于调速/阻断）
• 主控核心：STM32F103C8T6最小系统，负责信号处理与控制逻辑
• 人机交互：OLED显示滴速/液位/报警信息，矩阵键盘设定目标参数
• 告警与通信：蜂鸣器 + 指示灯 + 可选的无线串口模块（如ESP8266或NRF24L01）
• 电源系统：宽压输入 + LDO稳压，必要时加隔离模块，保证医疗环境下的稳定性

模块之间怎么配合，我习惯先画一张信号流图再动手写代码。传感器把液滴脉冲送到MCU的输入捕获引脚，MCU计算单位时间脉冲数得到实时滴速（滴/分钟），与用户设定的滴速做差，经过PID运算输出控制量驱动步进电机，通过调整蠕动泵的挤压频率或者夹管阀的开度来修正滴速。整个循环每200ms运行一次调速计算，既保证响应速度，又避免步进电机抖动过频。

这套架构的妙处在于：传感器和执行机构互相独立，任何一个环节坏了都可以单独替换；控制逻辑集中在MCU内部，调试的时候先在仿真里调参数，上板之后微调PID系数就行，不会牵一发动全身。

2. 硬件原理图拆解：从传感器选型到电机驱动的每个细节

2.1 滴速采集的实现方式与工作原理

滴速是整个系统里最核心的反馈量，它的测量精度直接决定调速效果。常见的方案有两种：一是用红外对管透射检测，二是用红外对管做反射检测，再就是压电陶瓷感应振动。升级版选的是红外对管透射方案，稳定性最高，对安装位置的要求最友好。

原理其实非常简单：输液器的滴壶两侧分别放置红外发射管和接收管。滴壶里没有液滴下落时，红外光可以顺利穿透滴壶到达接收管，接收管导通，输出低电平；一滴药液落下经过光路时，光线被液体折射和吸收，接收管接收到的光强突然下降，输出高电平。把这个高电平脉冲送进MCU的定时器输入捕获引脚，统计1分钟内脉冲数，就得到了滴速。一滴药液的体积大约在0.05mL左右，20滴约等于1mL，这个换算关系在做目标滴速设定时要用到。

电路设计上要注意几个问题。红外发射管需要串联限流电阻，典型值100-220Ω，电流控制在10-20mA，太小了接收端信号弱容易误判，太大了发射管寿命会缩短。接收管通常用光电三极管，集电极接上拉电阻到3.3V，发射极接地，构成一个简单的开关电路。这个上拉电阻的值很有讲究：太大会导致输出沿变缓，配合滴速快的场景时可能丢脉冲；太小电路功耗大。我一般取10kΩ，配合MCU引脚的施密特触发特性，实测上升沿在微秒级别，足够用。

一滴液体的下落时间非常短，大概在几十毫秒量级，所以在代码里要对捕获到的脉冲做消抖处理。硬件上可以在接收管输出端加一个RC低通滤波，时间常数选0.5ms左右，既能滤掉环境光的快速波动，又不会把有效脉冲一起滤掉。软件上再加一个20ms的连续采样确认，双重保险。

2.2 执行机构选型：为什么用步进电机驱动蠕动泵

执行机构在升级版里是个关键选择。第一版项目里很多人图省事，用一个电磁夹管阀，正常输液时阀门全开，报警时全关。这个方案的缺点是只能做开关控制，做不了连续调速，不能算真正意义上的"调控"。升级版改成步进电机驱动蠕动泵，通过改变电机转速来改变泵的挤压频率，进而精确控制输液速度。

28BYJ-48这款步进电机在DIY圈子里很常用，5V驱动电压，四相五线制，自带减速齿轮箱，减速比大概1:64。用ULN2003达林顿管阵列做驱动，引脚和STM32的GPIO直连即可，加上一个公共端接地，逻辑非常简单。不过要注意，28BYJ-48的步距角标称5.625°，经过1/64减速后，输出轴每步只有约0.088°，这个精度用于驱动蠕动泵完全够。程序里通过控制脉冲频率即可调整电机转速，比如设定每秒发送200个步进脉冲，配合64倍减速，蠕动泵的挤压轮转速约为0.049转/秒，换算出来的流量精度可达0.1mL/min级别。

选步进电机而不是直流电机，核心原因是开环可控性。步进电机每个脉冲对应一个固定的角位移，不需要编码器反馈就知道轴转了多少角度；直流电机则必须靠测速码盘或电流环估算，在负载变化时误差较大。输液过程中管路阻力会随着液面高度变化而变化，步进电机的开环特性刚好适合这种工况。

驱动电路还有个细节：续流二极管必须接。ULN2003内部虽然自带了钳位二极管，但为了保险，我通常会在电机每一相的驱动端对地再接一个1N4007，防止关断瞬间的反电动势冲击GPIO。这个东西在实际运行中不接，短期内可能没事，一旦电机堵转或频繁启停，MCU莫名其妙复位甚至烧IO，大概率就是这个原因。

2.3 电源架构与抗干扰设计

系统里存在多个电源域：STM32和传感器需要3.3V，步进电机需要5V，OLED和蜂鸣器兼容两者。所以电源设计采用两级结构：输入用USB 5V或者DC 9-12V适配器，经过一个降压LDO（如AMS1117-3.3）得到3.3V给MCU和逻辑电路；5V直接取自输入源（如果是12V输入，则先降压到5V再分流），电机电源与逻辑电源之间用磁珠或0Ω电阻做单点连接，减小电机启动瞬间的电压跌落对MCU的干扰。

还要强调一点：电机地和逻辑地必须分开铺铜，最后在主电源输入处单点汇合。如果用电线连接，尽量使用双绞线，能显著降低电机绕组通断产生的共模噪声。这部分在处理真实硬件时非常关键，原理图阶段不规划好，画PCB的时候会很别扭。

另外，STM32的每个电源引脚边都要放0.1μF的退耦电容，布局尽量靠近引脚。复位引脚接一个10kΩ上拉电阻，再并联一个0.1μF电容到地，避免上电瞬间的毛刺导致反复复位。晶振电路用8MHz无源晶振，两个20pF负载电容，走线要短，晶振下方尽量不要走数字信号线，这个在原理图和PCB阶段就要注意。

2.4 原理图绘制中的可维护性设计

原理图阶段我就开始考虑后续调试和迭代，所以每个模块的电源入口都加了跳线帽或者0Ω电阻位。比如红外对管模块单独供电，调试时如果发现它干扰了其他电路，我可以直接把它的供电路径断开，隔离排查。OLED的I2C上拉电阻也做成可焊接/可拆的，传感器信号线上预留了串联电阻位，方便调试时示波器勾测。

实测中还有一个非常实用的设计：所有传感器的信号输出都接到了MCU的5V容忍引脚上（F103的大部分IO都支持5V容忍），即使在传感器供电5V时，信号直连也不会烧MCU引脚，省掉了电平转换电路。这一点在原理图阶段就确认好，可以省不少事。

3. 核心代码逻辑：滴速闭环控制与异常告警的工程实现

3.1 系统状态机的划分

这版项目的代码结构比第一版复杂，我建议从一开始就按状态机来组织，而不是把所有逻辑塞进一个while(1)死循环。状态机的好处是：系统的每个行为阶段是明确的，从一个状态切换到另一个状态的条件清晰，排查问题时可以快速定位程序跑到了哪里。

我划分的状态如下：

代码上用枚举类型表示这些状态，switch-case分发处理。每个状态内再细分几项任务，比如运行状态里包含滴速采样任务、PID计算任务、显示刷新任务。按键扫描放到定时器中断里，10ms一次，配合消抖逻辑，不会阻塞主流程。

3.2 滴速测量：定时器输入捕获的精髓

滴速脉冲的测量方式要选对。用简单的while轮询去扫描引脚电平变化，在低速滴速下还勉强可行，一旦滴速上升到每分钟100滴以上，主循环稍微被显示刷新阻塞一下，就会漏掉脉冲。所以必须用硬件定时器的输入捕获功能。

STM32F103的TIM2支持四路输入捕获，配置为上升沿或下降沿触发、捕获中断。初始化时把红外接收管输出接到PA0（TIM2_CH1），设置预分频器，让捕获计数器以1MHz频率递增。每次捕获中断发生时，读取当前计数值，和上一次捕获值做差，就能得到两个脉冲之间的时间间隔，单位是微秒。滴速的计算公式：

滴速（滴/分钟）= 60,000,000 / 脉冲间隔（微秒）

举个例子，如果两个脉冲间隔为500ms，也就是500,000微秒，那滴速就是每分钟120滴。这就是临床常用的输液速度，对应每小时约360mL（按20滴/mL换算）。

捕获中断服务函数里只做两件事：记录时间戳、置一个标志位。真正的时间差计算和滴速换算放到主循环里去处理，避免在中断里做浮点运算。浮点运算是F103的软肋，一个float除法可能要消耗上百个周期，放在中断里会严重影响实时性，尤其当滴速较快时，中断可能频繁到吃掉大量CPU时间。后来我干脆把滴速用整数表示，单位是"滴/小时"，只在显示的时候除以60转换成滴/分钟，全程没有浮点参与。

3.3 PID调速：参数整定与输出限幅

PID是闭环控制的核心，升级版的调节目标是让实时滴速稳定在用户设定值附近。标准位置式PID公式如下：

u(k) = Kp * e(k) + Ki * Σe(i) + Kd * [e(k) - e(k-1)]

其中e(k)是当前偏差——目标滴速与实时滴速之差。输出u(k)对应步进电机的转速档位。实际代码里我用的是增量式PID，输出的是转速的增量而不是绝对值，这样有个好处：即使PID参数整定不够完美，输出也不会产生大幅跳变，电机动作更平滑。

int16_t PID_Calc(PID_TypeDef *pid, int16_t target, int16_t current) { int16_t error = target - current; pid->integral += error; if (pid->integral > pid->integral_max) pid->integral = pid->integral_max; if (pid->integral < -pid->integral_max) pid->integral = -pid->integral_max; int16_t output = pid->Kp * error + pid->Ki * pid->integral + pid->Kd * (error - pid->last_error); pid->last_error = error; if (output > pid->output_max) output = pid->output_max; if (output < -pid->output_max) output = -pid->output_max; return output; }

积分限幅这步一定不能省。如果不用限幅，系统长时间达不到目标值，积分项会一直累积，最后输出饱和，恢复时出现严重超调——临床上就是滴速猛冲一下，非常危险。抗积分饱和的一种简单做法是：偏差过大时直接清积分项。

PID参数的整定，我在Proteus仿真里先跑了一轮，得到一组初值：Kp=8，Ki=0.5，Kd=2。这组参数在仿真里调节效果还行，但上实物后发现一个问题：仿真里的传感器是理想模型，没有真实世界的噪声和延迟，实物的滴速测量值会有波动，导致PID输出频繁抖动，步进电机嗡嗡响。解决办法是在滴速采样后加一个滑动平均滤波，取最近10次脉冲间隔的平均值作为实测值，这样PID的输入信号平滑很多，电机也就安静了。

调节周期也需要注意。200ms执行一次PID计算比较合适。太短，滴速还没测出来就调一次，控制量拿的是旧数据，容易震荡；太长，系统的响应速度赶不上管路状态的变化。200ms刚好能积累4-5次滴速脉冲数据（以30滴/分钟计），既有统计意义，又有实时性。

3.4 异常检测与告警：宁可误报，不可漏报

升级版的告警逻辑比第一版多了两类检测：气泡检测和堵塞检测。

气泡检测的原理也是红外对管，安装位置在输液管靠近针头的末端。正常输液中液体连续流过，红外接收信号稳定；当有气泡经过时，光线在气液界面发生折射，接收信号会出现一个明显的尖峰。判断逻辑用阈值+持续时间确认：信号超过阈值并维持超过100ms，判定为气泡，立即关闭蠕动泵并告警。这个100ms有讲究，太短容易把输液管内壁的反光波动误判成气泡，太长则可能在高速输液时让气泡通过末端。

堵塞检测相对简单：如果蠕动泵在运行，滴速持续30秒低于设定值的70%，认为管路可能堵塞。还有一种情况是滴速传感器测得的脉冲间隔持续增大，同时电机的PID输出已经达到上限但滴速还在下降，说明系统已经尽力但物理条件不允许，判定为堵塞。

告警输出用了蜂鸣器、红色LED和OLED三路同时报警。蜂鸣器用有源蜂鸣器，一个GPIO拉高就能响，简单可靠。如果项目有无线模块（比如用ESP8266连WiFi或者用NRF24L01组网），我建议在告警函数里加一个串口输出，通过透明传输把告警码发给上位机，方便以后扩展护士站集中监控。告警码用16位十六进制表示，比如0xA101表示气泡告警，0xA102表示液位低，0xA103表示滴速偏差超限，这样既方便程序判断，也方便协议对接。

4. 仿真环节：在Proteus里把控制策略先跑通一遍

4.1 为什么强烈建议先仿真再上板

很多人觉得仿真麻烦，Proteus里面找原件、画连线要花不少时间，不如直接买开发板开干。但我做了这么多项目，只要涉及闭环控制，都强烈建议先做仿真，原因有三个。

第一，仿真能帮你把"逻辑问题"和"硬件问题"彻底分开。如果代码逻辑错误——比如PID符号反向、状态机跳转条件写错、定时器初始化配置不对——在仿真里会直接暴露出来，而且定位非常快，不用拿示波器到处量。等到上板时，你已经可以确信"代码逻辑是对的"，真正需要花时间的是检查硬件。这两件事混在一起排查，最消耗精力。

第二，仿真可以安全地测试异常场景。比如气泡告警，我可以随时在仿真里改动传感器信号来模拟气泡，测试系统的响应行为。在真实输液器上，想反复制造气泡还要清理，非常麻烦。仿真里随便造，想测几次测几次。

第三，仿真里可以直观地观察内部变量。把实时滴速、目标滴速、PID输出、状态值这些变量通过Proteus的虚拟终端或者调试窗口输出，肉眼就能看到控制过程的每个细节。上板后这些信息只能靠串口打印，而且还会占用CPU资源。

4.2 Proteus模型搭建要点

在Proteus里搭建这套系统的仿真模型，关键的器件清单如下：

• STM32F103C8芯片模型，Proteus 8.9以上版本自带
• 红外对管模块用两个分立器件模拟：一个光敏电阻模拟接收管，串联在电路里的开关模拟液滴经过时遮挡光路的效果
• 步进电机用Proteus自带的MOTOR-STEPPER模型，接ULN2003驱动
• OLED显示用Proteus的LGM12864或者直接用一个虚拟终端代替显示输出
• 蜂鸣器用SOUNDER模型，按键用BUTTON

一个重要的细节：Proteus里没有液滴传感器这个现成模型，需要自己用"开关+电阻+光敏元件"搭一个等效电路。我用一个脉冲发生器控制一个模拟开关，开关闭合时把光耦接收端的电平拉低，模拟液滴遮光，脉冲频率就是液滴速率。这个方法的优点是可以在仿真运行中实时调节脉冲频率，模拟滴速变化，看系统的调速响应。

搭建完原理图后，把Keil编译生成的hex文件加载到STM32模型上。在Proteus里双击芯片，在Program File里选择hex文件即可。如果代码里用了串口打印，需要添加一个COMPIM虚拟串口组件，或者用Proteus的Virtual Terminal直接察看输出。

4.3 仿真结果与参数整定实测记录

我在仿真中做了一组阶跃响应测试：初始滴速设定为60滴/分钟，系统稳定后，把目标值突然改为80滴/分钟，观察PID的调节过程。记录的数据大致是这样的：

• 0-2秒：实时滴速仍为60，偏差为+20（目标高于当前），PID输出正值，电机加速，滴速上升
• 2-6秒：滴速逐渐升高到75附近，积分项开始累积，输出继续增加
• 6-10秒：滴速到达78，接近目标值，微分项抑制超调，输出减小
• 10-15秒：滴速稳定在80±1之间，系统进入稳态

这个过程中我最关注的是超调量。如果Kp过大，滴速会冲到85甚至90再回落，在临床上患者会不舒服。通过仿真我可以反复调整Kp、Ki、Kd，每次改完看曲线，调参效率比上板之后拿示波器一点一点试高太多了。我在仿真里最终确定了一组比较满意的参数（Kp=6，Ki=0.8，Kd=1.5），超调量控制在3%以内，稳定时间大概8秒，后续上板只需要微调。

还有一个值得注意的点：仿真中我故意在滴速反馈通道上加了一个模拟噪声（用Proteus的随机电压源），用来考验系统的抗干扰性。结果发现不加滤波时，PID输出出现周期性抖动，电机转速忽快忽慢。后来在代码里加了滑动平均滤波，抖动明显减弱。这说明滤波不是可有可无的优化，而是系统稳定性的基本保障。

5. 硬件实测与排错：从仿真到真机这一步踩了多少坑

5.1 电机驱动引起的MCU复位问题

第一次上实物的时候遇到一个很诡异的现象：系统空跑没问题，一接上步进电机，跑几秒钟MCU就复位，看门狗重启，OLED闪一下重新初始化。排查了很久，最后用示波器测电机电源引脚，发现电机启动时5V电压跌落到3.2V左右，持续约几十毫秒，STM32的供电已经低于可靠工作的最低电压。

根源是USB供电的电流能力不足，电机启动瞬间电流可达300mA以上，加上其他负载，直接把5V拉垮了。解决办法有三层：一是改用外部DC 9V适配器供电，用LM2596降压到5V给电机，再用AMS1117降到3.3V给逻辑电路；二是电机控制引脚上电后保持低电平，防止GPIO悬空导致电机爬行；三是在电机电源端并联一个大容量电解电容（470μF），吸收瞬态电流。

这个小问题让我意识到，仿真里看不到电源轨的跌落和噪声，很多看似"玄学"的问题其实都是电源问题。建议上板前先单独测试电机驱动电路，确认电源的带载能力没问题，再接入MCU部分。

5.2 滴速传感器误报：环境光与安装位置

红外对管方案有个天然的弱点：强环境光的干扰。在日光灯直射或者窗边阳光下，接收管可能会一直处于导通状态，脉冲信号淹没在背景光里，导致MCU测不到滴速，系统误报"无滴速"或"滴速异常"。

我的解决方法是双管齐下。硬件上，给传感器套一个黑色热缩管或者用3D打印的遮光罩，把滴壶包住，只留出红外光通过的路径，从物理上减少环境光的进入。软件上，校准逻辑做了一次基线校准：上电后先测10秒的接收信号平均值作为基线，后续判断脉冲时用"信号相对基线的变化量"而不是"绝对电平"，这样即使环境光缓慢变化，系统也能自动适应。

还有一个安装细节：红外发射管和接收管必须严格对准。滴壶是圆柱形的，光路经过时会发生折射，如果两个管子的轴线不重合，接收信号非常弱，脉冲跳变不明显。我最终用了一个固定支架把两边的管子夹住，间距固定，光轴对齐，滴速检测的可靠性立刻就上来了。

5.3 串口调试与参数在线调整技巧

实物调试阶段，我在代码里加了一个简单的串口命令解析，通过USART1接收上位机指令，可以在线修改PID参数、目标滴速、查询系统状态。命令格式如下：

• "S 60"：设置目标滴速为60滴/分钟
• "P 5.0,K 0.6,D 1.2"：在线修改PID参数
• "G"：查询当前滴速、PID输出、状态

这个功能在参数整定时帮了大忙，不用每次改参数都重新编译烧录。用串口助手下个命令，观察系统的响应，几轮就能找到合适的参数。有些项目版本会把这部分做成上位机图形界面，用Python写个简单的串口读取程序，把滴速数据实时画成曲线，效果更直观。这个如果读者有兴趣，后续可以单独写一篇聊。

5.4 一个值得警惕的坑：浮点运算与看门狗喂狗顺序

最后分享一个比较隐蔽的问题。我早期版本的主循环里把PID计算放在一个耗时的浮点运算后面，结果就是，在最坏情况下单次循环耗时超过100ms，而IWDG的超时时间设置为约500ms。平时没问题，但一旦串口中断和滴速捕获中断同时频繁触发，主循环可能被拖慢，看门狗就会复位。后来我把喂狗操作放在主循环最开头，并且把PID计算里的浮点运算量降到最小，问题就消失了。

这个经验是：任何实时性要求高的系统，都要统计一下主循环的最坏执行时间，确保看门狗的超时时间远大于这个值。同时，喂狗操作要放在循环的"最不容易被阻塞"的位置，而不是放在末尾等着一堆计算跑完再喂。

6. 项目复用与扩展思路：这版代码还能往哪里改

这套系统的架构其实具有很强的复用性。把传感器和执行机构换掉，它就能变成别的闭环控制系统。比如把滴速传感器换成DS18B20温度传感器，把蠕动泵换成加热丝，PID控制目标就从"滴速"变成了"温度"，这就是一个恒温控制器。理解了状态机+PID+定时器采集这套主骨架，很多项目都是一通百通。

有几个比较有价值的扩展方向，给想做二次开发的读者参考。

第一个是加入无线通信做多床位组网。目前系统是单机版，通过串口可以接ESP8266模块把数据发到医院局域网，多个床位的数据汇总到护士站大屏。这个扩展的工程量主要在协议层面，需要定义好床位ID、设备状态、告警信息的数据格式，硬件的改动很小。

第二个是改用无刷电机或者医用级别的注射泵方案。步进电机+蠕动泵的方式适合演示和基础研究，但它在低速时脉动较大。如果要追求平稳流速，可以考虑用丝杆滑块结构配合注射器，做成注射泵。这个方案的执行机构控制逻辑会稍微复杂一点，需要处理行程限位和推进速度的换算。

第三个是增加一个闭环的液面高度检测。目前系统只在液面低于传感器时报警，还没有做到"根据液面高度动态调整滴速"。如果加上重力传感器或者超声波液位传感器，做一个上层液面高度的慢速控制环，整个系统就更完善了。两个控制环的设计思路是：外层环根据液面高度计算目标滴速，内层环根据滴速控制电机转速，级联P控制是医疗设备里比较常用的策略。

我个人的实际体会是，做嵌入式项目，最重要的不是代码写得多花哨，而是把"采集-决策-执行-反馈"这条路走通，并且每一个环节都有可靠的异常处理。这个输液监护系统如果只是抄代码，几天就能搭出来，但真正把它调到稳定运行、能应对各种边界情况，花在调试上的时间远远超过写代码的时间。希望这篇拆解能帮大家少走一些弯路，尤其是一些我踩过的电源、滤波、看门狗相关的坑，提前规避掉之后，整个开发过程会顺畅很多。