That would be too bad because if you do that what is it for. Such a smart pump
I am kinda hoping it will learn to adjust your BG during sports once it has learned you. But I think that’s too much to ask. Still, it will be really great to see what it can do for you when you go back to biking! I can’t wait to see what you say about that (biking) when you are further along.
That’s what I do too and it really works although not all the time! But you should not feel bad if it does not work as well as you want it to with this pump: I think maybe this pump is more designed for people who don’t work as much as we do at managing our BG.
Also, I think even if it works only for night it would be still be great, because none of us would have to walk up as often and treat lows and highs. So even if it does just that I think it would be great. I don’t mind doing the whole rest of the day in manual.
ETA more useful links. I’m actually not sure if the core of the Medtronic Algorithm is PID or Model PRedictive Control, I’ll have to read the articles.
@drbbennett, does the 670G encourage you to annotate events – i.e. can you in some way log that you are exercising? And is there actual machine learning based on historical trends? If so, then over time if you are pretty good at “tagging” certain events, theoretically the system should learn that whenever you tag something “exercise” on a Tuesday that means two hours of swimming and might need a drop in insulin preemptively, while whenever you tag something as “exercise” on the weekend it means a 5-mile jog…or something
But from the early papers I’ve seen in the literature (and some later PowerPoints) the root of the algorithm is a control system algorithm called Proportional-Integral-Derivative Controller… and from what I understand the bare-bones version of this algorithm wouldn’t have learning on that scale (i.e. where the period repeats erratically over days and weeks). And if that’s the case, I’d really struggle to see how the system could actually be learning about sufficiently dramatic deviations from the norm that occur not daily but, say, weekly or whatever.
I found one system that seems to encompass deep-learning for PID but it’s not in the arena of BG control. Medtronic probably has to have incorporated some kind of learning algorithm, but just not sure how it works.
Here’s a nice paper summarizing the different AP algorithms.
Yes, and I’ve been doing that, but I asked my MDT trainer specifically whether that figures into the algorithm’s “learning” process and she said no, it’s just for you and your team’s reference in the reports.
I think that’s correct. It isn’t set it-forget it. Part of becoming an effective experienced user is figuring out ways to adjust to deal with other circumstances. Taking it out of auto is one tactic, but I think that’s less of a problem when you’ve got the basic pattern adequately dialed in. I’ve been tempted many times but I haven’t got the basic settings dialed in well enough yet.
And thanks for the links and tech info–very useful!
There is a section in the closed 670G users group on FB dedicated to exercise. Been meaning to delve into it but haven’t yet. I may report back here when I’ve had a chance to look at it.
This is very deep learning. I am doubtful that the 670G does anything like that.
A PID algorithm is the “dumbest” kind of algorithm you can use. That is what they gave technicians in the 1940s to control systems with – and it still is what they use in many industrial environments. Essentially, there is a method to calculate the P that fits your system best (P = Proportional), then you give it enough I (I = Integrator) to allow it to not have a hard skew where it never catches up to the actual number it is tracking, then you give it a tiny, tiny bit of D (D = Derivator) to give it more speed but not too much (otherwise the output is too noisy).
If the machine learns at all, then it might be progressively adjusting the coefficients for a PID controller through learning techniques, the same way a technician would progressively tune a PID. If that is the way it works, it is unlikely to ever be able to do anything very fancy for us – a PID just can’t do much. But it is also very possible that it uses more sophisticated control techniques (than a PID), that do not require deep learning (pure AI) but mathematical regression techniques that are part of the core of control engineering.
looks like it uses some kind of fuzzy logic, or at least that’s what the papers from 2010 seem to indicate. It’s probably been updated and tricked out since then.
The fact is, PID controllers may be very simplistic at base, but they’re pretty powerful and if there was some way to overlay that with deep learning I can imagine it being very powerful indeed.
My impression is like yours though in that it is progressively essentially tweaking your parameters – it may not truly use things like basal rate, ISF or carbF in the traditional sense, but based on how far off target it is, it’s sort of asymptotically approaching your average or steady state glucose needs. So it’s really about parameter optimization in real time.
Fuzzy is possible and could make sense. At UCB I worked directly with Lotfi Zadeh, who was one of my professors, and who invented fuzzy logic. Learning is difficult with fuzzy but not impossible. Essentially, fuzzy works well in cases where simple algorithms work most of the time but break hard in some limited circumstances. A good example is a rice cooker, for instance.
Learning, these days, is primarily done with techniques related to or derived from neural nets. There is A LOT of tech on this, but it is hard and it requires a good bit of hardware.
Still - I am doubtful about PID for the 670G. I learned about PIDs in my sophomore year as a control engineer, and spent the rest of my college and professional years never using this technology again for any of the control problems I have ever encountered. So if this is the core tech that Medtronic engineers are using, even if overlaid with heuristics (or DL for that matter) for tweaking parameters, our expectations should be very low. What a PID CAN do in most circumstances with a complex system is simply too limiting. From a mathematical point of view, it can only deal with simple, low order physical systems.
you don’t think glucose control is low order? I’m just curious because a lot of the dynamics I see basically seem like first order, but maybe I’m totally wrong.
Also, if you’ve ever taken a look at openAPS it is VERY simplistic in its model. And kind of wrong in its assumptions, IMO. But it still works pretty well – certainly better than manual control for us. Of course, 10 years of us learning Samson’s patterns and we’d likely be better than such an algorithm, but the issue is that we’re not always on. I think you can make up for a lot of deficiencies in the control algorithm if you’re tweaking the parameters and it’s individualized.
I think neural networks or some kind of deep learning is going to be the future. Not sure what’s behind things like OmniPod Dash, Bigfoot Biomedical or the Bionic AP, but if they’re more sophisticated that would be huge.
Then again, because type 1s are used to things like constantly correcting or operating in a very wide range, it’s possible that even with a system that’s way better in terms of control you’d still get overall roughly the same A1Cs.
Imho it’s high order, noisy, and heavily non-linear: it would probably be the hardest system I have ever dealt with . Biological systems are typically hardest to control. But I have not worked on BG as an engineer so I am ignorant of a lot there.
As a comparison, I wrote a dissertation on multiple-degree-of-freedom robot manipulators (things with 10-15 degrees of freedom), and I have worked on controlling all kinds of industrial and chemical processes for rubber, paper, food, dynamic metal-processing machines, as well as air-to-air missile guidance systems, and fly-by-wire fighter plane control systems.
I really need to start reading up more on OpenAPS – I’ll take that as a todo item. I just don’t know enough about how they do it to speak knowledgeably, really.
Yes, that distills what I was trying to convey in the OP. I:C ratio is an active parameter in Auto but only applies to Wizard bolusing (or so I’m told). Active Insulin Time is also in effect, and is one of the more powerful instruments for tweaking the algorithm, but it seems somewhat removed from question of how long your insulin doses are actually lasting, given how short experienced users’ settings seem to be compared to a normal pump. Note that in a normal pump this parameter doesn’t pertain to basal rate but in this pump it DOES pertain to all those microboluses. And since AIT is generally a couple-three hours, and you’re getting microboluses multiple times an hour, you’re really setting the degree to which they overlap. Which is a kind of zoomed-in view of why “microbolus” and “basal,” as traditionally understood, aren’t the same thing.
You’re not alone. My kids aren’t allowed on any social media either…not just FB. Instagram, Twitter, nothing. And we won’t let them play all the games that “all the kids play” at school…we’re so horrible.
All this last couple of weeks I’ve been running 180-220 for a good part of the day, and getting these little blips of 1u or less when asking for a correction. But over the last 24 hours I began to see a new alert message: “Max delivery,” indicating “Auto mode has been at max delivery for four hours, enter BG to continue.” Max delivery is a safety setting, in case your BG isn’t coming down because of a hardware problem, like a detached infusion set. But in my case, no such problem: what it means is the system is suddenly trying hard enough to get me in range that it’s hitting the (relatively conservative) ceiling of how much it can deliver. So this struck me as a very promising development. I figured this parameter is straightforward enough that I don’t need anyone’s guidance to fiddle with it, so I went ahead and lifted the lid by a couple of points.
Even better: my fasting this a.m. was 156 (higher than I like but a little better than I’ve been seeing these last two weeks), and when I told it to give me a correction (0 carbs) I expected a minuscule fraction of a unit. I’ve been told it uses 150 as the correction target, and it has been so miserly about corrections that I figured I was only going to get a microbolus if that. Instead, OMG, a substantial 3.5u correction, which is about what I’d have selected myself.
So for a good long while it wasn’t seeing the delivery cap as any kind of problem, but something changed in the last 24-36 hours that made it decide it needed more headroom than it had, and now that I’ve raised that ceiling it seems like it’s ready to be more aggressive about things. I get the impression that even though it was “learning,” whatever that means exactly, up until now it was held off from putting any of it into practice. I gather from what I’ve read that the Algorithm (genuflect) has a six-day cycle for evaluating its data, which is one reason things seem so frustratingly slow to change at the beginning when it can’t yet implement whatever it has been learning. Anyway, I’m still a long way from being back in 6.0 A1C territory, which is where I was before going on this system, but it does feel FINALLY like it’s paying attention to what I’ve been telling it, so that’s a big relief.
It is a little confusing isn’t it. So it’s going along calculating what it will take to get you to 120, but when it calculates an extra bolus on top of that, it figures that dose by what it should take to get you to 150. I guess the idea is to get you down to 150 and let the Algorithm do the rest. Like I say, it’s just not the same as a standard pump–everything interacts, and it take some getting your head around the logic.
