Revisiting Control Delays

As discussed in the last log, feedback lag is a major concern. Most introductory control system courses focus on single input-single output (SISO) linear systems. For these simple systems, there is a mountain of theory that can be used to analyze a system and predict certain characteristics about performance, observability, controllability, stability, and more. For the Ventilator, we do indeed have a SISO system. We are controlling output commands to the blower motor controller, using pressure feedback as the input. The system is not linear, but may possibly be close enough. For linear SISO systems, Bode plot analysis of the controlled transfer function is typical. To learn more about this process, this page is enlightening. To summarize, the Bode plot can be analyzed to determine stability of a system. A major de-stabilizing factor within these systems is the pure time delay. This makes sense even without  detailed mathematical analysis in the frequency domain. Imagine holding a broom upright on your palm with your eyes closed. A friend will call out which way to move your hand so you stabilize it. The delay added from having your friend tell you what to do will destabilize the control system and you will drop the broom. 

For the Low Cost Ventilator, I recently adjusted the air circuit so that the pressure sensors are connected to the Wye (just before the ETT). An extra length of hose carries the air from that section to the pressure sensors. That, combined with some apparently slow ramp up on blower speed adds a significant feedback delay. The image below shows one breath cycle at 20 breaths per minute. Even though the command to the motor ramps up relatively quickly, the measured pressure only reaches its peak about 1.25 seconds later. This controller is mainly feedforward, since the delay would destabilize a PID controller.

Likewise, this delay is visible for a slower breath cycle which allows more time for the dynamics to stabilize.

Although there are some control approaches that can be done to combat pure delays, such as Model Reference Adaptive Control or the use of a Smith Predictor, the best approach is to adapt the design to reduce this delay. Likely this would mean a stronger blower or a controller that ramps up speed faster, and moving the pressure sensor nearer to the Wye.

The Ventilator has reached the point that it can be put inside its enclosure. From the beginning, our design was meant to have a single flat front panel that all custom parts would mount to. This panel would replace the panel on a COTS Hammond Industries metal enclosure. This makes assembly easy, fast, and the result looks fairly professional. The below images show it mounted inside the enclosure. Unfortunately there are still a few parts still on order for the air circuit, so it isn't quite right, but it's close enough for testing. Note the smaller hose leading from the Wye back into the vent. This provides pressure feedback back to the sensors inside, likely contributing to the control delay somewhat.

The system was powered up using its medical grade power supply (port hidden just behind the hoses in the picture below) and two (figuratively and literally) heavy textbooks were used to add some resistance to the "lung" during breathing. This is not a great dummy lung, but is cheap and available.

Finally, I made a demo video of the ventilator, embedded below. Note a few things in particular:

• On power up, the alarm buzzer and light turn on. They shut off when the system boots. The hardware that controls those are physically different from the microcontroller, and alarm by default. The microcontroller must periodically toggle a pin to that subsystem, or the alarm will sound. This is an important safety feature.
• All settings are entered through a pushbutton and knob. The brightness of the screen washes out the settings, but they are shown in real-time on the display. The display refreshes at over 30Hz. The use of an RTOS and non-blocking interrupt driven I2C interface to the display allows this.
• All settings are stored in non-volatile FRAM, and are loaded on boot. CRCs are used to check for data integrity. This means any unintended reboot (such as one triggered by its watchdog) will load the correct settings, and get back to normal operation quickly. In addition, settings remain constant over power cycles.
• This demo shows a slow and a faster breathing cycle. Although the controller isn't well tuned (see above issues with delays), the code does support a wide variety of settings.

Although the system is still a work in progress, I decided to make the firmware repository public in case people want to dig in deeper or have suggestions. It can be viewed here: https://github.com/jwachlin/LCV