Artificial pancreas

[twodoor2]

I suspect the the Kp gages the correct dose based on the predictive analysis of the Ki and the Kd components of the algorithm. This is why it works, and it also takes around 3 weeks for the itterations of the algorithm to fine tune itself. In a way, it works like how we, as humans, use trial and error to gage the correct I:C ratios using 10 finger pokes a day (pretty pathetic sample size).

However using CGMS gives a much larger sample size and a much more accurate basis for correcting to the BG range. The one minute Navigator CGMS is optimal, as "moco89" suggests, for correcting for meal boluses as well. I think the five minute lag time for the Medtronic CGMS might be an obstacle for bolus corrections

Moco89, or Ed, please correct me if I'm wrong.

[coop]

[QUOTE=frizzyrazzy;178187]my head hurts and I want to cry. LOL.

I second that!

Seroiusly, Ed, Marsha and moco89 thank you for this discussion. I mostly get it!

[twodoor2]

I apologize, it is more complicated than the algebraic problems we currently use (whether we know it or not) to do our predictive analysis for carb ratios, ISF, etc. . . The PID controller method introduces calculus to do predictive analysis since it has a much greater sample set to work from (using the CGMS). Therefore, that is where the derivative and the integral terminology are coming from. These are calculus terms.

The integral portion is used to calculate the amount of error. This is the area over or under the target BG represented by the curve of the CGMS BG trail for each time interval - one minute for the navigator, five minutes for the Medtronic. The derivative is used to calculate the change in error, which is the slope of the tangent of the curve of the CGMS BG trail at each time interval. Based on this information, it gains knowledge about how to best correct this error over many itterations. It becomes self-intuitive, just like the thermostat in your house knows how to get the temperature to 75 degrees.

Of course, it's much more complex than what I've stated (if I'm actually stating what I believe to understand), but it's a good example of how calculus can play an important role in diabetes management when used with computerized devices.

[moco89]

Yeah, K(p) is a rate for insulin delivery which exists in order to prevent error (a BG above or below target). In the most basic sense, the ,K(p) function is a basal rate-which exists in order to keep the blood sugar steady around the target BG. K(p) is also applicable to high and low blood sugars, since a proportionate increase/decrease in insulin would result from an above or below target blood sugar. The K(p) in an above/below target blood sugar is comparable to calculating the ICF. The K(p) may be in this circumstance a linear function, just like the calculation using a ICF for a correction dose. They are both proportionate functions.

Also, another factor in the artificial pancreas is the device responding to drops in blood sugars. Drops would result in lows w/o corrective actions by the algorithm itself. For example, we already have CGMS devices that predict and alarm for future highs/lows. The navigator and the mm cgms have algorithms that alarm a future low/high up to 30 minutes in advance.

The predictive algorithm already present in the MM and Navigator CGMS devices are a component in the whole artificial pancreas. The difference between the CGMS and the future artificial pancreas would be that a PID would also integrate the predictive BG warnings to back off on giving insulin by the artificial pancreas.

So basically, there's more than one PID present in the artificial pancreas-one that predicts and responds to highs by giving insulin and one that notices drops in blood sugars (based on rate of change-derivative and the integration function) and then tells the device to back off of the insulin. Also, advanced prediction of future BGs is a totally different component that is important to the formulas involved in the artificial pancreas.

So basically the whole formula for the artificial pancreas is dependent on at least two different PID functions. A minimum of two PID functions has to exist to accommodate the variable of the absorption/duration of action of the insulin, which is why blood sugar prediction is necessary. However, they can be combined into a single algorithm, similar to a piecewise function (think back to algebra 2). They are interrelated and are individually determined to be used based on the factors such as rate of change and whether the BG is above or below the target. One PID accommodates rapidly rising blood sugars I mean, when there is a lack of insulin, and the other PID accommodates rapidly lowering blood sugars-where it is predicted the BG will go below target. There has to be two separate PIDs, since one must deal with two much insulin in the body (and possibly insulin taking action too fast) and the other needs to correct too little insulin in the body (and possibly take in to factor inefficient absorption of insulin-causing the high). So insulin absorption causes another variable which cannot be "ideally" or "adequately" resolved by a simple PID algorithm.

I hope I didn't confuse you, twodoor2

[WestinsMom]

I can't imagine you could find another forum for parents with such a interesting, complex topic. I have enjoyed reading and watching to the linked materials. I am a math major drop out (I loved math but couldn't get past calc 2) so I can't follow all the math, but I follow the ideas. Very, very interesting to read. Thank you for letting us all pretend to be so smart!

[coni]

THANK YOU for this fascinating discussion. I can't say I could do the math, but I understand the concepts.

moco89 - I hope we hear more from you. Your contributions have been awesome!

[twodoor2]

Originally Posted by moco89

I hope I didn't confuse you, twodoor2

I just hope my pathetic explanation simplified how this works, if I explained it properly to begin with. I'm about to look at my husband's "Automatic Control Systems" book from college. I would imagine you would need two PID controllers, one to automate basal output, and the other to deal with boluses if I'm understanding you properly in the most simplistic of terms.

With my daughter's blood sugars, one thing I'm always trying to do, and many of us do this as well, is to try to use some math or intuition to figure out where she'll be in an hour or so. I do this based on the IOB that is estimated by the pump relative to her BG. However, the IOB is only an estimation, and cannot be perfect (it does work well for us though). This machine takes the intuition away from the user and performs this predictive analysis itself, but instead of predicting far into the future (one hour ahead), it uses smaller gaps in time intervals to asses this with small increases and decreases in insulin (such as basal). I must admit that the bolus part of the equation seems a bit more daunting, and more difficult to deal with I would imagine. However, the fact that it has such a large sample size helps the "intuitive" part of the controller.

I second Coni's request that we hear from you more often. It's great that you're using your technology-related knowledge to gain information about your diabetes with advanced management tools like the AP. I hope you don't mind a personal question. Do you pump now, and do you use a CGMS and do you currently apply any of the advanced mathematics to your management routines?

[My_Dana]

I was tinkering in Excel and tried to simulate a PID output.
Seeing a graphic helps me related to the math behind it.
I can change the Kp, Ki, and Kd gains to see the change in output. I think it's working.
I've posted a few graphs below.

Also, in my earlier post with the PID drawing, I should have included what is
referred to as the plant or controlling process. This is the thing we want
to (and can) control. In our case it's literally the pump motor which is administering the insulin and/or glucagon.

I also wanted to comment on moco89's post. He mentioned needing 2 PID loops to handle basal and bolus demands.
While certainly possible, I'm not sure if necessary especially in an insulin/glucagon output system. Or even just an insulin system.
PID loops are good at having a steady state output (basal) and responding to sudden demands (bolus). Sudden changes in this system are not very.
I wanted to point out that a PID loop is not "smart". It does what it does based on the set gains and fixed equations.
The real smarts involved for the AP system is a very complicated software program that is changing the gains terms
(and probably other terms too) in real time to learn and adapt.
I basically understand what it's doing but I couldn't tell you how to write it.
I'll leave that to programmers like Twodoor2.

It's also important to note that more complex functions can be added to the basic PID loop to cover other requirements.
Discontinuities like the backlash region of a geartrain (very difficult to control) is a good example.
The delay in response when insulin is delivered and when it starts action is also very tricky.
This is where Jacob's Dad is correct in saying an "instant" responding insulin
would make the controlling algorithm simpler. So for 15-20 minutes after giving
insulin, the loop needs to incorporate a delay before changing the output.
And then that delay will change. This is were the software has to learn.

So for the graphs below I used the equations our controller use..
Pout = Kp*error 'output proportional to the error.
Iout = Iout + (Ki*error) 'time iterative function.
Dout = Delta_error*Kd 'responds to the magnitude of the change in error.

OUTPUT = Pout + Iout + Dout

I simulated using step change to a setpoint of 100.
The step input to a PID system is the typical way to test the response for tuning. It represents the the worse case scenario.


Graph 1 -
Shows the simulated error in BG against the step change setting of 100.
All gains set to "0" so nothing happening.


Graph 2 -
Shows only Pout to see how it is proportional to the error. Opposite to the error. Magnitude set by the gain Kp.
You can crank it up but too high will cause the output to oscillate and go unstable.


Graph 3 -
Now with some I gain the PID output can somewhat anticipate the needed response. The summed outputs are the red trace.
The gain values are arbitrary.


Graph 4 -
Here I cranked up the D gain to show how this term is responding to the changes
in error with additional output.
This would illustrate how the loop kicks
additional output when the BG feedback changes between samples.
Obviously, this example would be an unstable situation. The yellow trace is the
Dout isolated. Kd around 0.1 in my example looked pretty good.


Sorry for the long post. Thanks for reading.
.
.
.

[saxmaniac]

I have no EE experience whatever, but this makes perfect sense. Thanks for the crash-course!

[twodoor2]

Hi Ed,
That is awesome, and thanks for that. I sent you a pm btw. Jeff has to make this thread permanent - I don't think there's every been so much information produced in one thread!!