How Olympus Controls Automates Predictive Maintenance with Telit, MQTT, and InfluxDB

Session date: Apr 12, 2022 08:00am (Pacific Time)

Olympus Controls specializes in simplifying the integration of motion control, machine vision, and robotic technologies through better automation. They partner with their clients from creation to implementation, and nearly half of the Fortune 100 use Olympus Controls to improve manufacturing plants and factories. Discover how Olympus Controls uses a time series database to collect and analyze industrial sensor data, which is ultimately used to increase their customers’ competitive advantage.

Join this webinar to learn as Nick Armenta dives into:

• Olympus Controls' strategy to developing hardware and software used to improved IIoT monitoring
• How they use Telit and MQTT to reduce siloed manufacturing operations, including monitoring robotic arms (i.e. vibration and temperature)
• Their approach to developing IoT analysis using InfluxDB, Telegraf, and Flux

Click here for presentation

Watch the Webinar

Watch the webinar “How Olympus Controls Automates Predictive Maintenance with Telit, MQTT, and InfluxDB” by filling out the form and clicking on the Watch Webinar button on the right. This will open the recording.

[et_pb_toggle _builder_version=”3.17.6” title=”Transcript” title_font_size=”26” border_width_all=”0px” border_width_bottom=”1px” module_class=”transcript-toggle” closed_toggle_background_color=”rgba(255,255,255,0)”]

Here is an unedited transcript of the webinar “How Olympus Controls Automates Predictive Maintenance with Telit, MQTT, and InfluxDB”. This is provided for those who prefer to read than watch the webinar. Please note that the transcript is raw. We apologize for any transcribing errors.

Speakers:

• Caitlin Croft: Customer Marketing Manager, InfluxData
• Nick Armenta: Automation Engineer, Olympus Controls

Caitlin Croft 00:00:00.699 Hello everyone and welcome to today’s webinar. My name is Caitlin, and I’m very excited to be joined by Nick, who will be presenting how they are using InfluxDB at Olympus Controls. Once again, this webinar is being recorded and will be available tomorrow. Please post any questions you may have in the Q&A, which you can find at the bottom of your Zoom screen. And I just like to remind people to please be friendly and courageous to all attendees and speakers. We want to make sure that this is a fun place for all participants. And without further ado, I’m going to hand things off to Nick.

Nick Armenta 00:00:40.614 Thank you so much, Caitlin. But yeah. So thank you everyone for joining today across the world. Really cool to see all the different people interested in both the internet and robots data. But that is the theme these days. So I titled this Cloud Native Robotics. But really the idea is extracting data from industrial robot arms and getting it into a format that we can all understand and use to make better decisions. That’s the theme. So I’ll get started here. And so who is Nick, myself, and why should I listen to him? Caitlin informed me I should tell you about me since most of you do not know me. I consider myself a technology explorer. I just like playing with things. It’s just my engineering nature. So new technologies always made me definitely interested - hence why we’re here today. I got my bachelor’s in electrical engineering from a local school, UTA, here in 2012. And I’ve actually been doing automation and manufacturing ever since. So manufacturing. Primarily who am I working with? So a lot in the DFW area. We have a lot of aerospace, defense, telecom, semiconductor. We have sawmills. We have automotive. We essentially have every industry under the sun. So I can get exposed to a lot of different companies, different people, and different problems. As far as the size of the company, my favorite visits are honestly two garages. Some of the coolest ideas come out of the smallest garages. But of course it goes up to aircraft hangers and some of the largest factories on the planet. So scale really goes everywhere. So I get to, again, see those common problems people are coming across. As far as different departments I work with, most of the time, of course, with newer technologies we work with, I’m coming in with R&D groups, center of excellences, basically people experimenting, testing out technologies. But then of course it gets deployed into production and then eventually into sustainment and long-term.

Nick Armenta 00:02:28.995 What do I do in my spare time? You’ll see me in the mountains there. Unfortunately, here in Texas it’s very flat, but I do enjoy the mountains. I’ve been across the world, all different areas, but technology is interested in deep learning, generative stuff like RT stuff, IoT like we’re doing today, grabbing data from the edge and then sticking it in the cloud where we can send it through different resources, either for storage or analysis. And then home automation. It’s like a little mini factory, so it’s kind of fun to mess around with different things there. Who do I work for? So I work for Olympus Controls. So we’re actually uniquely a hardware distribution company. So we sell primarily robotics and motion control type technologies. But really our goal is to be an engineering partner to our customers. So when we come in, we’re driven to find the root cause of the problem. And generally it’s not always technology. It’s sometimes people. It’s sometimes process. So really understanding everything at a fundamental level helps us quite a bit. And then once we understand the problem, we can implement our newest technologies. So here are some of our suppliers here, too. So really the dream being that we could essentially connect any of these devices to the cloud onto a platform like Influx. So that is kind of the core goal of what we call industrial Internet of Things, basically having complete visibility into your manufacturing floors 100% of the time to make better decisions.

Nick Armenta 00:03:49.361 So typically, how do we work together with people? I won’t go too much into detail. Planning. Obviously we want to phase these types of things. There are many unknowns in automation. So by phasing our approach, we’re actually able to create a much better deployment because we’re understanding what the hiccups are at each potential step. When it comes to deployment, there’s a lot of resources, infrastructure, both networking infrastructure, power, air, hydraulics, whatever that may be. So working with all the internal teams to actually deploy it successfully, understanding what’s available to us and what we can do. And finally, continuous improvement. That comes right back to where we are today. Remote monitoring. We’re trying to grow like everyone else, so we’re trying to see what we can improve every single time we work on a project, and remote monitoring is a huge portion of that. When I say remote monitoring, that basically means I can see what’s happening in my factory without actually being in the factory. So critically important whenever you’re just not on the floor.

Nick Armenta 00:05:07.321 And so why InfluxDB? Why are we here today? So being totally honest, I don’t really have any database experience, at least before this. So I didn’t know quite where to start. But when I saw Influx, to me it made the most sense. Why did InfluxDB make the most sense to me? Really, it’s the easy data collection. So a lot of what we do in manufacturing areas, we’re exploring these new types of protocols, one of those being MQTT. So with MQTT, you of course have a central broker. And with the proper credentials, you can subscribe to that broker and collect data without actually having to have a direct access to the machine. So when I saw that Influx had Telegraf to actually allow me to scrape that data, that made it a lot better, because I didn’t actually have to talk directly to my machine. I could simply point to that broker in the cloud, start pulling that data right away with really minimal impact of what I’m currently doing. I love visualization. I’m a sucker for a good dashboard, and the neon colors, of course, caught my eye. However, a big portion of it was the quick queries. So not being a database guy, I’m not going to write query strips all day. So being able to build one visually and just quickly put stuff on a simple dashboard is really what helps me be most effective as fast as possible. Cloud access. Generally, people are not cool with you going on their network all the time from anywhere in the world. So starting in the cloud natively just enables us to give complete access to whoever may be needed without, again, having to access the floor of the factory, the critical infrastructure of the network. And then I mentioned this before, but Flux was a little bit more of an intuitive language for me when I [inaudible]. I love a good long SQL query. But at the same time, the kind of just step-by-step approach to the query made a lot more sense to me.

Nick Armenta 00:06:54.269 And so where would we use a relational database? So, I mean, if we were tracking assets like products going out the line, shipping, accounting, receiving, those types of things, for sure, we’re actually using those already for our own internal purposes. But when it comes to production rates, really everything is about rates. It’s all very cyclical. So again, full stack data to visualization on one platform. I was able to scrape my broker, send it to my cloud instance of DB and start visualizing it. Low cost of entry to set that up. It was free. They just give you the first bucket for 30 days. So that was nice for proof of concept. Then scalability. I can flip a switch, subscribe, change my plan. And now I can essentially unlock as much functionality as I want without any additional infrastructure on my end. So that’s always nice.

Nick Armenta 00:07:41.323 So what are we trying to measure today? I guess I’ll start with the goals. So in manufacturing, really what we’re trying to do with industrial IoT, IIoT for short, is predict what’s going to happen in our factory. If we can see the line going up into the left or down to the right, those are two different indicators that can tell us what’s happening. But what that allows us to do is create additional uptime. What uptime means is of course more money for everyone involved. And that’s why we’re here. So the machine state. It’s kind of like what is the current state of the factory. So typically I like to classify this in five areas. This is pretty common. So is the machine running? So for our case, we’re using a palletizing system. So are we actively handling packages? Is the machine touching and moving? Is it waiting? Is it running right now, but maybe nothing’s coming down the line? Maybe did it jam upstream? Is it halted? Did someone protective stop it, trigger it, pause it, whatever? Is the program not running? Is it faulted? Did something bad happen? Did something crash? We need to check out something? Or is it down? Is it just off? Is it not in use at this time? So those different metrics allow us to really understand exactly where the breakdown is. You can see a bunch of green running, and then you see a red faulted, you know exactly where your problem is in your production line.

Nick Armenta 00:09:00.894 As far as other data, we can pull production data, so counting the daily number of packages, products we’re pushing out. That’s a pretty clear metric of how you’re doing productivity wise. Then hourly rates. You can see cool things - like during lunch, it slows down, obviously. Maybe it’s a little slow in the morning, or maybe there’s a shift change and there’s some type of an inefficiency you can capture there. So rates are, of course, critically important, because it helps us understand what’s happening throughout the day. And then in this case, robot or machine health. So really, these machines run for years, if not decades. So really understanding how well they’re doing and the maintenance that may be needed is critically important. Generally, the longer the machine lasts, the more danger you’re getting of it becoming a critical bottleneck. It’s not uncommon for us to get calls from people saying, “Hey, my whole manufacturing plant is down. Can you find me this drive or motor?” And sometimes the answer is, unfortunately, “That’s a very long lead time. You’re going to have to talk to someone in emergency services.” So really, we like to stay ahead as much as possible by monitoring our assets so that we know if they’re going to go out soon or if they’re having these strange issues. So for the robot, for example, each robot has six joints on it. So we’re going to monitor both the current and the temperature. To save time today, I’m just going to focus on the current.

Nick Armenta 00:10:21.078 What is current? Current is basically the force of the motor. As force goes up - as wear goes up, your force is going to go up, aka your current goes up. So that’s where we’re looking today. What are we going to put this on? So we’ve got a new solution. It’s called the Robotiq Palletizer. But the idea of being - you’ll see this handy GIF on the right [inaudible] palette layout, your box layout on the pallet. And then from there, you basically say, “Just run the robot.” So it’s a really nice solution that allows people to quickly deploy automation. But the question is, how useful is it in your application? So how can we track this? What I love about end-of-line solutions like this [inaudible] line, the [inaudible] box, that box is probably going out the door, aka that’s probably a sale. That’s something we can tie directly back to the bottom line. So that’s why, like this one in particular - and also a potential bottleneck, obviously, with something outside the line. But next, we’ll see.

Nick Armenta 00:11:19.992 So the next piece of hardware we’re using is the gateway. What is getting the data for cloud instance? So we used Opto 22’s real edge gateway. I’ll show that here in a little bit. But it’s basically just a simple IO device with a DB and Linux on board. So we installed a company Telit, their deviceWISE edge platform, onto it. And that allows us - as you can see here, the robots communicate to our gateway. The gateway communicates to an endpoint database, whatever that may be, in this case, Influx, or can talk to cloud instances. We can talk to remote connections. So really we can put our data wherever we need. But that gateway is our gateway to the cloud. So network architecture. How is this whole thing hooked up? That is a great question. That’s why [inaudible] robot on the left I mentioned - that palletizing solution. There is a UR10e universal robot on top of that. And that’s actually what we’re going to be talking to in this system. So the robot itself is just a simple ethernet connection to the system. And we’re going to be using the Modbus TCP protocol to talk to the gateway. I’ll go into detail on that later. There’s the “groov RIO” that I just talked about. So that is a - it’s got edge IO. So the nice thing about this is if we did have an external, say, temperature or vibration, some type of sensor, we could actually hook that as well into this. And so we can just get some additional data points from it. So that’s why we chose that gateway or that hardware in particular. From there, we installed deviceWISE edge on top of it, which gave us all of those communication protocols, that Modbus TCP, the MQTT, all of that built-in, so that really we’re just pointing where to put the data instead of building our own protocols or drivers.

Nick Armenta 00:13:04.506 And from there, we’re just on the wide area connection and we’re going MQTT to our cloud broker. Pick your broker. I’m not going to go into too much detail on this. Just assuming you have a working knowledge of what an MQTT broker is. We just use the generic consensus case to test. So not too critical, but we are publishing to a specific topic at this data broker. I’ll give you a link in the presentation, so if you want to subscribe later, you can see our robot data. That will be pretty cool and safe. So once it gets to the broker, where can it go? In this case, we are going to Telegraf. So Telegraf is watching the broker at that specific topic and it is parsing that JSON message and then extracting those values and putting them into the database. But of course, if we wanted to use that data elsewhere, our other factories could subscribe to it, and we could use this like, “Oh, robot A is down in Dallas. Robot B makes that same thing in Chicago. Let’s just let Robot B do that for a little bit.” So you can make really cool decisions as far as - we call it load balancing of your automation by just understanding what your assets are currently doing, all based on that nice little MQTT broker. And of course, finally, where are we trying to go? We’re trying to go to the database. So we’ll end up going to InfluxDB, into a bucket, and then we will use a simple query to actually visualize some of the data inside of that bucket. But I’ve made some helpful boxes in yellow. You’ll see that’s everything at the factory. And then once we leave the factory, in blue, you’ll see everything else is - I call it the cloud. We all know it’s just Linux in that space.

Nick Armenta 00:14:36.889 All right, on to the fun part. So this is where it slows down a little bit. So if there are questions, Caitlin, please interrupt me, because we’ll be going through the whole technical installation. So as I mentioned before, you’ll see here this handy graphic to the right. That is a representation of our UR10 robot. So that robot, like I said, has six joints. That’s basically just like us. We have a shoulder and elbow, a cool wrist. Our robot has three just very simple wrists. But each of those joints has a motor inside. It’s a servo motor. So each motor’s current and temperature are actually already being monitored. So if you look here - I hit play right here. Hopefully, you see it okay. Those are changing live. So while the robot is changing and doing things, you’ll see - say the elbow is lifting for a little bit. You’ll see the current go up on the elbow as we can kind of see right here. So these are all always available. So whenever we want to pick them up, we can. How are those values stored, though? Obviously this is a visual interface. We need to grab them from a central data source. So use Modbus. Cool thing about manufacturing is that most of our stuff can go back to legacy hardware. So Modbus is a protocol that started in 1979 with one of the first companies to make a PLC or programmable logic controller. So they made Modbus. And to this day we [inaudible] ethernet. We do Modbus over ethernet, call it Modbus TCP. So here we are using Modbus TCP over 40 years later to talk to our universal robot.

Nick Armenta 00:16:12.451 An then where are those stored? So just like many other protocols, they’re just set registers. So in this case, if you just look left to right, you can see exactly where those numbers are coming from inside of our Modbus TCP master. So those are the data points where we’re actually going to grab that current data. Oops, there it goes. I see the video running again. Okay. So now we have our Modbus register from the robot. That was pretty much taken care of for us. That’s great. So why do we use deviceWISE again? Say we were using - and hopefully some of you are familiar with this language - an Alan Bradley or Rockwell type PLC. Those use a different protocol. Those use ethernet IP. Say we’re using Siemens. Those typically use PROFINET. So we can’t assume we know exactly who our clients will be using. So with a deviceWISE type gateway, that will allow us to talk to any device regardless of their preferred protocol. And really that’s what we’re after is we don’t want to have to reinvent the wheel every single time. We want to make sure that we’re able to talk out of the box.

Nick Armenta 00:17:15.828 Okay. So what does deviceWISE look like? So on the left, it’s a pretty simple graphical interface. So we have what are called triggers. So this trigger runs four times a second or every 250 milliseconds. But what it does is it converts those internal Modbus registers into a JSON object. So why did we do that? So Modbus registers themselves. They’re just data points inside of a register. So what we did essentially is pull out those, in this case, integer values, and then we assigned them to properties inside of that object. And so now that’s a pretty simple payload that we could send really anywhere, RestAPI, whatever call you want to make. In this case, like I mentioned before, we chose MQTT. So once those are all set up, we can simply publish. And there’s that broker I mentioned. So yeah, if you boot up Mosquitto, whatever you like, you actually could be able to start seeing what’s happening on our robot line. So we send that JSON message you see to the right to the public and MQTT broker, since we’re just testing. And then we know we can subscribe to that topic. And then that will allow us to start grabbing the data from the robot.

Nick Armenta 00:18:24.544 So now the fun part. So this part took probably the longest portion of the time, just because I’m not as familiar with the configuration files. So we told you about Telegraf. So just like the deviceWISE gateway we have from a hardware perspective, this is similar in a software perspective. So whether it’s HTTP, MQTT, they have a bunch. I’m not going to list them all off. But they have the same type of protocol, same type of configuration device to send you to the same database. So to me, it made just obvious sense just to use the built-in solution from Influx. MQTT Consumer was the specific plugin that I used. And that’s how I subscribed to the device once gateway and that [data status?] topic. From there, since we’re doing a JSON object, I use the new JSON v2 parser to create the database entry, or sorry, the script - it’s actually the query - to send over. And then Telegraf is running detached in Docker Compose. I just like to keep things containerized. It makes it a little bit less messy and just works better. So that’s running that right now just in the background as a daemon. And here’s the config file. I believe I’ve hidden all the - yeah, wait, there’s no [inaudible] on there.

Nick Armenta 00:19:39.916 So if we look at this config file, I’ll break it down, obviously. That’s why we’re here. So as far as the intervals, I mentioned that our MQTT publish is happening every 250 milliseconds. So I’ll set our interval. I’ll just double that so we don’t miss anything. I’m not saying any of this is best practice, and I’m sure many people are saying things to their computer right now. I would appreciate your feedback, because I didn’t know exactly what I’m doing, but I figured it out, so. The interval’s 500 milliseconds. Flush interval, 30 seconds. I don’t expect to have any kind of timeout or drop out before then. And so like I mentioned, the MQTT Consumer plug in. So of course, we need to append our protocol on the left and our port on the right to that end point that I said. And actually, that one is slightly different. HiveMQ has a few different domains pointed to the same one. So if that’s confusing, that’s why. Topics. This one, it was just one topic. But before, if we were doing things like looking at multiple robot joints or maybe looking at temperature and current or production stats, I would probably parse that topic out a little bit better so that it’s just a little bit cleaner where all those data points are going. As I mentioned, the format is JSON v2. So this is just the one recommended. So it’s the one I went with.

Nick Armenta 00:20:56.061 And then so what do we do once we have it? So I just chose the measurement name Current, so that all of these different fields will be filled with the same measurement type, which is current, obviously. And from there, it was pretty simple. I picked each of the fields from my current object and then I just declared those integers just to make sure nothing weird was happening. And then as far as the output side, you can see here, it’s just the cloud instance, like I mentioned. Of course, you could do that locally. For me, I’m a little bit lazy. So if you’re going to do the whole thing for me, I’ll give you a little bit of money to host my instance. So that’s fair. The token, of course, organization, bucket, those are all pretty straightforward. The docs will show you how to do that.

Nick Armenta 00:21:39.316 And the query. So like I mentioned, I didn’t really use the script editor. I mostly used the query builder. So with this, it just allowed me to go through, just click the measurement I wanted, current, check all the boxes, as you can see here for the visualization I made. So there’s all six joints just fluctuating as they do. As the robot moves, the current tends to fluctuate, so that’s not out of the normal. I’ll get into some scenarios here in a second. But yeah, from there, even if I was writing this from scratch, which I’ve had to do a couple of times just to do some modifications or transformations, it’s pretty easy. So from my bucket, in this case “gulf”, I just say the time range start and stop. So that’s actually the name or the one up top in the master interface. So I don’t even have to set that, really. And then from there, [inaudible] just a long way. So I’m sure you have opinions. But every single field has its own object there, too, because I filtered for them. And of course, I just go through the period. I’m actually looking for max currents. That’s different than the standard mean, because to me, if I see a spike in current, I definitely want to catch that. I don’t want to average that out and make everything look like it’s okay. So for me, I’m looking for anomalies, generally, with this, so max or min. In some cases potentially our current can go negative. That would be good to see just to make sure we’re going. And then at the very end, it would just spit out the max from that query.

Nick Armenta 00:23:06.190 And so now for the fun part. So dashboard examples. So what kind of things can we catch? And we can do much more than this, and I’ll elaborate on that later. But here - hopefully, it’s not too choppy - you’ll see the robot doing a pretty basic routine until a mean intruder comes in and starts messing with the robot. Now the robot is just trying to do its job. So this is no fault of the robot. Basically you see as I start to engage in physical combat with the robot, it actually stops, protective stops, and causes an error. So I want to catch that. If someone on the floor is punching my robot, I would like to know that. And that can be seen very clearly right here. So if you’ll look on the left, I’m just moving those shoulder and elbow joints, you’ll see. So it’s cycling up nicely. Everything else is pretty idle. But as soon as I see something happen, I [inaudible]. So to me, it’s very clear that something happened right at this red line. So that’s a pretty easy one. You can just see everything is holding idle, so it’s not dropped to zero. It’s actually still pulling some current, but it’s clearly not moving. [inaudible], just by looking at this dashboard, something is wrong.

Nick Armenta 00:24:16.016 Continuing on to the example. So this is just another one, but very similar. [inaudible]. The robot itself, it’s running. Occasionally, it will have an e-stop. So an e-stop, it doesn’t always mean everything’s going terribly. It just sometimes means I’m too lazy to turn it off the right way. It happens. I just did it right here. So as the robot stops, you’ll see it click. You go in here. Like I said, it goes idle. So the robot’s active but not moving, that state I mentioned before. As soon as that e-stop is pressed, you see everything goes to zero. So what that means is that the motors are no longer active and the brakes are engaged. So your robot is currently not under its own power. It’s just hanging there like dead weight. So those are a couple of scenarios that we can see just with this really basic installation.

Nick Armenta 00:25:04.768 But what does the future hold in this scenario? So obviously, we saw those cool lines, waves, that went up and down. But in reality, there actually are some states inside of the robot that we can use to monitor that. So we don’t have to do any kind of deep learning regression on those signals. We can just say like, “Yeah, the robot told me it’s off. I don’t need to worry about that too much.” So we can use those as more discrete types of states while we use the current for more just making sure the current’s not going up over time. We can add production metrics. So with production metrics, what that means essentially am I doing the [inaudible] of cases am I working on? Am I doing number of parts built, number of screws inserted? But generally, you’re able to parse that out with a user type variable. So with Modbus, for example, we could simply say like, “This variable is this Modbus register.” And from there, just like we’re querying those base joint currents, we could do the same thing to actually extract the metrics from Modbus on just a general purpose register. We don’t want to flood the broker, but we do want to make sure that the MQTT broker has pretty much all the data that people would be interested in. So they could set up their own Telegraf instance and they could just scrape whatever is relevant to them, put it in their own buckets. And then we can all be happy just knowing that the data is available in that single broker. Obviously, you want to pick a production-ready one, as well. Just using [IMBQ?] is cool in the public, but at same time, that’s not really scalable. I’m sure they’ll yell at you if you start putting a ton of data up there.

Nick Armenta 00:26:34.754 Custom dashboards. So this is really one of the biggest, I would say, sticking points that we have in manufacturing is visualization. So every time we present with a data point, if we’re not able to show that in a very obvious way, it’s not obvious what we should do. So when I saw the ability basically just to put a visualization on top of the database I already had with Influx, it made just almost obvious sense to me that I could just start running with this almost immediately, create different dashboards, say, for me. Hence, that would be more of the current that I mentioned before. There we want to make sure that none of their motors aren’t using a lot more power today, tomorrow, that machines aren’t unexpectedly down, for just managers on the floor making sure production rates are being hit, that there’s no quality issues. And of course, more enterprise exec level, how are all the factories running? But you could still just distill that data down more and more and more so that everyone is seeing the most important variables to them. And then of course, this is just one simple robot, but ideally we’re putting multiple machines into the same bucket or the same type of query. So it’s not uncommon for us to have - you saw the palletizer before - just one robot at the end. But what if we had eight? I mean, most warehouses have at least like, say, six to eight different lines coming out where they need their product to move. So instead of just one robot to monitor, there’s six now. But we can still visualize that pretty easily using the exact same methods. We would just change, of course, the topic and the robot. And then from there, just scrape data all the same. So the scalability seems to be pretty nice. And we can just continue to add on to that as needed. And I think it looks like that is it for me. I mentioned to Caitlin, I’m a little bit of a fast talker. But that’s 10 at 30. So yeah, I don’t know if there are any questions you would like to ask.

Caitlin Croft 00:28:23.137 Wow. That was great, Nick. So the first question is, is it necessary to use a separate MQTT broker somewhere for InfluxDB to collect data? What is the role of Telegraf in the schema? So I will say this before you chime in. There’s a bunch of different IoT brokers that you can use. You don’t have to use MQTT. And Telegraf is simply the collector agent that InfluxData has created. So it’s completely open source and there’s over 300 plugins. So you can either use one of the plugins to write the data directly to InfluxDB, or you can even use our client library to write the data to InfluxDB. I don’t know what your experience was between picking MQTT or one of the others.

Nick Armenta 00:29:19.838 Yeah. Well, I guess I’ll answer that in a couple of ways. One, you’re correct. We actually did some other implementations where we did not need MQTT, because we had a small local development environment and so we could send it to a local database. Once we started to go to more of an enterprise type of deployment, that’s where it made more sense, because now we need to go to a cloud instance, so we couldn’t keep that localized anymore. So that’s where that stepped in. But you’re absolutely right about just MQTT and the protocols. It’s not necessarily what we needed. It just made the most sense in this standpoint, because really in manufacturing, it’s all about simplicity. We did have a broker running locally, just Mosquitto, just Docker container, as well. So it doesn’t have to be that specific endpoints. But MQTT was simple and safe to communicate, which is why I chose it in this instance. But by no means the only way.

Caitlin Croft 00:30:12.099 And I think it’s just really cool how manufacturing companies, they’re discovering the benefits of newer technologies, per se. Like the idea of time stamp data isn’t new, but using something like InfluxDB in these manufacturing spaces is definitely becoming more and more popular.

Nick Armenta 00:30:32.016 Yep, absolutely. And sometimes dragged kicking and screaming to the future, but generally we want to make sure it’s going to be work for them, first. So we’re not going to force MQTT on you, but most of the time, it makes a lot of sense.

Caitlin Croft 00:30:45.981 Did you face any pushback in your organization? How did you overcome that?

Nick Armenta 00:30:51.221 Yeah. So really, it’s a matter of everyone just being so busy. So the number one complaint I get in factories is just that they don’t have enough people. So generally people are stressed. They got tunnel vision. They’re [inaudible] accomplish the task. So really pulling them back to that 10,000 foot view and saying, “Hey, if you look right here, this is a serious pain point. If we can address this, we can alleviate your stress.” And generally, to eliminate those pain points, we need to pull data that allows us to show them where they could be most productive. So it’s really just pulling them back for a little bit, talking them off the ledge, and saying like, “Let’s look at this area first.” And from there, we can start generating more traction and more productivity.

Caitlin Croft 00:31:31.467 Totally. Are you considering a machine learning approach, for example, using neural networks, classification algorithms, or something similar, to predict specific events, trying to learn something from available data?

Nick Armenta 00:31:48.759 Yeah. So that’s a great question. Really to do that, you need data. So that’s the number one problem I’ve seen is really just a lack of data availability. So step one, let’s get a good pool of clean, formatted data, and then we can start doing that. But one thing you can actually start to notice is once your data is really clean, formatted, and visualized in an understandable way, you can actually make a lot of just quick judgment calls and understanding just by looking at a good, visualized interface. So where AI could come in, too, is when you’re working on just a lot bigger technologies. There’s a bunch of different data streams and it’s a very complex type of scenario. But when it comes to things like preventative maintenance or just kind of productivity metrics, those are pretty just basic, discrete type signals we can usually look for. So step one, get the data. We’re still right here.

Caitlin Croft 00:32:42.180 Great. But I like that you guys are already thinking of what you want to do next, because there’s always so much more you can do once you have the data.

Nick Armenta 00:32:49.286 Absolutely.

Caitlin Croft 00:32:53.327 Let’s see. How much resources does a server need to deploy in the cloud to deploy InfluxDB and Telegraf?

Nick Armenta 00:33:03.648 I think that would be a question for you. I’m not sure. It wasn’t a lot. I mean, it was very lightweight, on the Telegraf end, at least. [crosstalk] -

Caitlin Croft 00:33:12.496 Yeah. From what I gathered -

Nick Armenta 00:33:14.867 I think [crosstalk]. I don’t know how much data, but.

Caitlin Croft 00:33:18.349 They’re pretty lightweight, especially the cloud option. So if you’re worried about that, I would definitely say check out the InfluxDB cloud offering, because it might be perfect for you. And I mean, it’s all open source, so there’s no harm in trying. Let’s see. Did you use Node-RED and Grafana?

Nick Armenta 00:33:42.134 I have actually. I’ve used Node-RED and Grafana. In this case, since we’re looking for more enterprise solution, we went Telit deviceWISE. But as I mentioned earlier on in home automation, that little section, I did use some Node-RED for that, as well. And they actually have a direct InfluxDB plugin, so I could skip the MQTT for that step. Grafana, it’s another step for visualization. It was kind of cool for my purposes that you saw on that dashboard. I didn’t think it was necessary quite yet. But yeah, I’ve definitely used Grafana as well when it comes to more complex typed visualizations or other types of data sources.

Caitlin Croft 00:34:18.034 Do you have an estimate of how much data you’re transmitting to the cloud, for example, to be able to send data to the cloud using a 3G or LTE SIM card instead of relying on the site’s internet access?

Nick Armenta 00:34:33.522 Yeah. That’s kind of the question when it comes to edge computation is how much do you do at the edge before you send it out? Theoretically, you could do that AI model and send that up to the cloud as a very basic yes or no. But for us, really, a lot of servo robotics is extremely high speed. So a lot of times we’re talking microsecond clock cycles for stuff. And getting that much data just doesn’t really make sense. So when it comes to more of [inaudible], we want to have faster scan rates. But at the same time, we don’t necessarily want to send all that data. So ideally we’d scan a cycle, whatever it may be, look for anomalies. And we can send that metadata, if you will, to the cloud. When it comes to productivity, I mean, generally we’re not moving at lightning speed, putting parts out all the time. In bottling factories, sure. So it’s very lightweight. To quickly answer your question, it’s just a simple integer value, just a bite, essentially, maybe times 10, 20, whatever it may be. But very low overhead. So if you’re smart about how much data you’re putting out and not spamming a bunch via 3G to the cloud, you can be pretty lean with it.

Caitlin Croft 00:35:41.510 How do you know that something bad happens without observing the visualization? Can you define some bad conditions and get notifications?

Nick Armenta 00:35:54.579 Yeah. There’s honestly a ton of different ways to do this. It was something I was interested in as well, too, because I’m looking for triggers, right? I’m trying to see like, “Okay, if something’s down, I want to address it immediately.” So I believe [inaudible] - I believe there are some ways we could do this with alarms in Influx. But as far as just other ways we can monitor it, like the Telit platform, if we catch an anomaly at the edge, before even transmitting that, we can actually send that. Maybe it’s email. Maybe it’s a text alert. Maybe it’s a light we turn on or something. Generally, we’ll try to catch that at the edge to notify someone immediately. And then we can store it in the cloud just for long-term analysis or postmortems whenever it may be needed.

Caitlin Croft 00:36:34.567 And I’ll also just add that with the InfluxDB platform, you can set notifications and alerts. So there’s a bunch of different endpoints that you can do. HTTP, email, Slack. I think PagerDuty is another one. There’s a bunch of different ways you can have alerts sent to you beyond just actually looking at the dashboard, because not everyone’s going to be able to just sit there and watch the data come in live and look at the visualization. And something -

Nick Armenta 00:37:03.653 [inaudible].

Caitlin Croft 00:37:05.042 Yes. And something else just to - wanted to plug this in regards to the notifications. Beyond being notified when something interesting happens, it’s also good to be notified if maybe your data isn’t coming in at all. Sometimes it’s really critical to also have alerts that it’s monitoring the infrastructure, monitor the monitor. Where another customer, they were monitoring their website and they realized over the course of a weekend, something went down, so they weren’t actually collecting the data. And I know that’s also especially important in the manufacturing space, where maybe there’s not as many people there on the weekend. So you want to make sure that everything’s running efficiently, so.

Nick Armenta 00:37:49.908 Yep. Great point.

Caitlin Croft 00:37:52.369 Let’s see. Can you capture time series of images of video clips and perform feature extraction, either locally or in the cloud base, in this infrastructure?

Nick Armenta 00:38:06.020 It goes back to that data question, but I’d absolutely extract the metadata first before sending that on. So yeah, you’d probably run that at the edge. And then, yeah, say you’re counting the number of parts in a pile of robots, people walking around, you can just send that number up rather than send all that information, because unless you want to do some kind of training or inference on it later, I don’t see why you’d need that image. But yeah, I don’t know if you have image - I don’t know how you time series an image. That’d be interesting. That’s a good question.

Caitlin Croft 00:38:34.501 Yeah. I’m not sure. I haven’t necessarily seen people - I mean, obviously, I know that photos have timestamps, but I’m not sure if people have been putting that data into InfluxDB.

Nick Armenta 00:38:46.958 Yeah. That temporal stuff’s really interesting, but I haven’t seen it.

Caitlin Croft 00:38:51.214 How do you manage loss of connection to the MQTT broker? Is there an MQTT client or other agent buffering data locally in the factory?

Nick Armenta 00:39:05.244 Yeah. So there’s actually a couple of different ways. So one, MQTT comes with quality of service. So that’s basically similar to UDP broadcast versus TCP, where your quality of service of zero is you send a message and you don’t care what happened. Quality of service one, I believe it makes sure it sends it exactly once. So that needs to send that quality service to - I believe it sends it at least once. I may have those backwards. But yeah, that’s built into the protocol by default if you want to use that feature. And then you also - part of the - I think it’s a smart plug protocol, they say basically like alive and dead [inaudible], so getting a “Hello world” when you attach versus a “Goodbye world,” when you disconnect. But there are some in MQTT. I’m not as familiar with protocol. I’m not an expert by any means, but I know there are some methods where you can trace that, for sure.

Caitlin Croft 00:39:58.913 Great. Can you talk about maybe any security around your data? Any issues around that?

Nick Armenta 00:40:10.540 So I didn’t do a security audit. And it’s a great question because that is a big concern. But I did make sure to shelter myself. And at that, aside from just our being connected to the internet - of course, that’s just a vulnerability in itself - we’re not talking directly to things. We’re using protocols. So for MQTT, for example, at the edge, we talked to this broker. So yeah, there actually is traffic there you can potentially monitor if needed, but you don’t have a way to write back to us, essentially. We’re not even [inaudible] connections from anybody. So while you understand what’s happening out here, you can’t actually have any impact on it. So it’s very much a read-only type of set up we have right now. And then, of course, the capability with Influx’s cloud [inaudible], I don’t have to worry about that as much. They do that work. That’s why I use it, too. So that also [inaudible].

Caitlin Croft 00:41:07.709 Perfect. Do you have any recommendations for open source resources for newbies to improve their skill?

Nick Armenta 00:41:20.755 Oh man, that’s a good question. I just love scouring GitHub for cool projects. YouTube’s great. But yeah, if you’re looking just to start with no money down, just a simple Raspberry Pi with something like Node-RED and Docker, you can do quite a bit. But yeah, message me after the fact. I’ve got stuff, a lot, too. So I can go into more detail. It definitely depends on what you’re trying to do to get you in that direction. But there’s so many tools out there. It definitely is overwhelming at times.

Caitlin Croft 00:41:50.635 And if you’re specifically looking for resources for InfluxDB, if you’re new, definitely check out our trainings, InfluxDB University, and check out the forums. People are so friendly and helpful in the forums and also in the community’s Slack workspace. So if you’re new to InfluxDB and you want to learn more, definitely check it out. And I love all of Nick’s ideas of where you can learn more about just open source in general. Can you share more details about your InfluxDB schema? Tags, measurements, fields?

Nick Armenta 00:42:28.691 That is another area of my weak point. So the schema could be better. And it’s going to depend on the use case and the customer, too, what they are. So ours was very simple. The measurement was current. And the field had a name of - which would make sense related to [it?], too. So I didn’t go into that much detail, probably just because of lack of database expertise. I’m not familiar with all the different approaches to it. So apologies for the bad answer there. Oh, and then just to add to Caitlin’s thing. The newbie. I did not actually have to talk to anyone in Influx to set up the whole thing. The documentation was enough. So it wasn’t too difficult just to get something running.

Caitlin Croft 00:43:07.416 What is the piece of software infrastructure that can help pull data from InfluxDB to use to train and run AI models, for example, using TensorFlow?

Nick Armenta 00:43:21.532 I mean, I would imagine you could query the database and use the raw data combined with a timestamp to run some type of temporal analysis. But I don’t know how to get data out besides looking at it visually. That was kind of - I like the pretty lights. And that’s where I stopped.

Caitlin Croft 00:43:36.054 I mean, everyone likes pretty visualizations, right? Let’s see. If you were to monitor, say, 1000 robots for your use case, can you describe what kind of server configuration would be required?

Nick Armenta 00:43:52.612 I could. I would be lying because I do not know. But I mean, thousands of robots, I imagine that would scale pretty easily with Influx. I mean, you basically [inaudible] your different buckets and different areas there, too. But I’d, again, lean in heavily on their enterprise product in that I would not set up the servers on my own in the cloud, because I don’t have that expertise. So to answer your question, if Influx does it, I think it’s pretty easy. But I wouldn’t know how to do it myself.

Caitlin Croft 00:44:18.862 Someone asked if the slides will be made available. Yes, they will be made available later today or tomorrow along with the recording. Are you analyzing data for events using Flux inside of InfluxDB, or are you doing it another way? And how does your alerting look?

Nick Armenta 00:44:38.772 So this one we’re actually - I guess I mentioned. We’re kind of doing more on the edge. So whenever we have something, we want to just alert them locally rather than having to have them talk to Influx directly, because like I mentioned, we’re actually on the internal [inaudible] network at that edge level. So we don’t necessarily have to talk to the cloud to send that alert. That also allows us to keep that contained, too, so there’s just less connections than an endpoint. So for us, we would do it on the Telit deviceWISE platform. As Caitlin mentioned, you can do it with Influx. I just did not set that up on my end. It wasn’t as useful for my purpose.

Caitlin Croft 00:45:16.723 At least not yet.

Nick Armenta 00:45:18.304 Not yet. Yeah. Not that I’m aware of. I’m sure they will be as we scale.

Caitlin Croft 00:45:22.478 I mean, it’s always amazing talking to InfluxDB community members. And I talk to them one day and then I talk to them again a year later and they’ve - it just keeps growing. So I can only imagine what you guys are going to do in the future considering where you guys have already come. All right. I’m just going through all the questions here. Just want to make sure that I’ve answered all of them. Let’s see. Is it possible to scale Telegraf with the MQTT broker consumer horizontally in Docker?

Nick Armenta 00:45:57.610 Ho

rizontally being different end points, or different brokers we’re talking to? I would imagine so. So in the Telegraf - and correct me if I’m wrong, Caitlin. The Telegraf configuration, I mean, we could run multiple containers if you need to and just look at different endpoints, different buckets. So based on the - if you look at the configuration file, I think that should answer your question. But yeah, I don’t see that being an issue. When I was running the container, I did a no-no and I was using the host’s network. So that would be the only quirk, I would say, is just how you connect it to the wider network.

Caitlin Croft 00:46:31.654 Perfect. Let’s see. A couple of people have raised their hands. So Peter, I’m going to allow you - you’re allowed to unmute yourself if you wanted a - if you wanted to ask a question live to Nick. All right.

Nick Armenta 00:46:55.882 I think he just wanted to say hi. Hello, Peter.

Caitlin Croft 00:46:59.800 And then Rajendra, it looks like you also wanted to talk, so I’ve also allowed you to unmute yourself. So Rajendra or Peter, if you want to talk, you can go into Zoom and unmute yourself. Oh, this is a good question. Oh.

Nick Armenta 00:47:24.699 [inaudible].

Caitlin Croft 00:47:25.097 Hi.

Attendee 00:47:26.465 Yeah, hi. It was wonderful use case actually presented. So I’m really thankful to you for demonstrating this particular case. I think overall this Influx seems to have a very easy [inaudible].

Caitlin Croft 00:47:52.264 Nick, were you able to catch that? I heard a bit of static.

Nick Armenta 00:47:55.203 I heard a good compliment. And thank you. And then I heard some static.

Attendee 00:48:01.976 Yeah, well, welcome.

Nick Armenta 00:48:04.273 Thank you. I guess that was the compliment. Okay. You said it seems -

Attendee 00:48:11.235 Yeah. At this point, you’re actually monitoring only a handful of robots. If I would ask you, how many robots do you monitor using Influx right now?

Nick Armenta 00:48:22.619 So right now, this is more of a pilot project. So it’s on the UR robot. But we could absolutely talk to other platforms, some more typical industrial robots. As long as it has that Modbus TCP or ethernet IP protocol, theoretically, we can talk to it without issues. So it’s not necessarily just robots. It could be programmable logic controllers, data type systems. There’s a lot we can do with the same type of setup.

Attendee 00:48:48.173 Great.

Nick Armenta 00:48:52.582 No, thank you. Good question.

Caitlin Croft 00:48:53.612 Awesome. All right. Let’s see. How do you persuade your customers to use a cloud solution? That is hard for this industry.

Nick Armenta 00:49:04.679 It is. No, it is. And I’m not going to act like I sold everyone on it. It goes back to the shell, the type of protections. So one, you don’t need to manage the infrastructure yourself. So that’s good. But who it’s attractive to mostly is multi-site type enterprise user customer, so people with factories across the state, nation, and world. It’s just a better way to consolidate that data. If you were just a single factory that was running your own system, I mean, you could probably do it locally. But as soon as you have many things interconnected and you have to build your own network, it makes more sense to go into the cloud. But I can’t give you the sales pitch that just makes everyone want to do it. It’s definitely use case specific. But the core of it is no infrastructure to manage, and security is managed, and it’s available to everybody with the proper credentials.

Caitlin Croft 00:50:01.207 Awesome. And I also think that cloud is just becoming increasingly important, especially in the last couple of years with everyone at home. Not having to manage your infrastructure is increasingly important. All right. I think that’s all the questions. Nick, did you have any last comments or anything else you wanted to add?

Nick Armenta 00:50:28.251 No. I mean, we clearly just touched the surface of what’s possible, too. So yeah, if this was helpful and if there’s other ways we can show what we can do, I’d be happy to step into that. But it should be a pretty similar implementation, too. So yeah, thanks everyone for joining. And if I could be more useful and otherwise, please let me know.

Caitlin Croft 00:50:48.486 Thank you everyone for joining today’s webinar. And thank you so much, Nick, for presenting. I thought this was very cool. It’s always fun, robots. Once again, this session has been recorded. The recording as well as the slides will be made available later today or tomorrow. So be sure to check back, watch the recording, check out the slides. If you have any questions for Nick, everyone should have my email address. Feel free to email me. I am happy to put you in contact with Nick directly.

Nick Armenta 00:51:24.054 Thank you.

Caitlin Croft 00:51:25.434 Thank you. And Nick, I think I might want you to come back and do an update once you’re out of the pilot phase and you’ve moved along -

Nick Armenta 00:51:34.479 Sounds good.

Caitlin Croft 00:51:34.729  -even further.

Nick Armenta 00:51:35.305 Do some cool stuff.

Caitlin Croft 00:51:37.815 Well, thank you everyone, and I hope you have a good day.

Nick Armenta 00:51:41.183 Thank you.

[/et_pb_toggle]