I’m currently scampering around my office with a great big beaming smile plastered all over my face because I just created my very first artificial intelligence (AI) / machine learning (ML) application… and it works!

When people hear the terms AI and ML, very often their knee-jerk reaction is to think about machine vision and things like object detection and recognition. While machine vision is incredibly cool and amazing, it’s really only the tip of the iceberg with regard to AI/ML applications.

In the dim and distant past, when I wore a younger man’s clothes, I spent some time supervising the installation of a new control system in a glass factory. As part of this, I became aware of the myriad different types of machines that can lurk in every corner of a factory along with some of the interesting ways in which they can decide to depart from this plane of their existence. Thus, one AI/ML application area that is of particular interest to me personally is that of predictive maintenance.

A Stitch in Time Saves Nine

When I was a kid, I used to spend more time than was good for me in the company of old ladies. As a result, I was constantly regaled with proverbs like “A stitch in time saves nine,” which means that if you sort out a problem as soon as it raises its ugly head, you’ll save a lot of time and effort later. This particular proverb could well be the tagline for the practice of predictive maintenance.

There are trillions of dollars’ worth of equipment in factories around the globe. Many of these machines — pumps, motors, generators — play small, but vital, roles in production lines and manufacturing processes. If any of these devices stop working unexpectedly, they can disrupt the operations of the factory. In some cases, a seemingly insignificant unit can bring an entire production line to a grinding halt. Not surprisingly, factory managers are keen to keep all of the machines under their control working at peak efficiency. There are three main maintenance strategies they can employ: reactive, pre-emptive, and predictive.

The simplest form of maintenance strategy is “reactive maintenance,” which is also known as “run to failure” or “run to fail.” In this case, the machines are allowed to run until they stop working, at which point a maintenance crew is dispatched to diagnose the problem and perform any required remediation. In addition to the fact that the failure mode may significantly damage the machine, therefore increasing the cost of repair or replacement, having the machine fail unexpectedly at any time of the day or night can disrupt operations in a major way.

By comparison, in the case of pre-emptive maintenance, the machines are checked, and various parts are replaced on a regular schedule or after a specified number of operating hours. The goal here is to minimize unscheduled downtime, but pre-emptive maintenance comes with associated costs in terms of parts and resources.

As its name suggests, predictive maintenance involves forecasting when a machine is going to fail and then addressing any problems before the failure actually occurs. In the past, predictive maintenance was performed by engineers with domain expertise. Walking through the factory, they could detect the early onset of problems in the form of hearing uncharacteristic sounds or feeling atypical vibrations. In addition to discerning anomalies, these engineers could also spot trends, such as a machine’s temperature or vibration slightly increasing day-by-day.

Unfortunately, this level of expertise is not always available. The problem is exacerbated when experienced engineers move on to new positions and older engineers move on to retirement. One solution is to use AI/ML techniques to monitor sensors to learn how the machine behaves when it’s running normally and when it’s running abnormally. The AI/ML system can subsequently use this knowledge to monitor the machine’s health, looking for anomalies or trends, and altering the maintenance team as to any potential problems.

Like many things, this all sounds wonderful if you say it quickly and wave your arms around a lot, but who is going to create all of these whizz-bang AI/ML applications? According to the International Data Corporation (IDC), there are currently around 22 million software developers in the world. Only about 1.2 million of these little scamps focus on embedded systems, and only about 0.2% of these little rascals have even minimal AI/ML skills.

Obviously, we need a cunning plan. “A plan so cunning you could put a tail on it and call it a weasel!” (as Edmund Blackadder might say). Happily, we have just such a plan…

Tiny AI/ML Steps

Earlier this year, I read a rather interesting book whose name, it has to be said, is a bit of a mouthful: “TinyML: Machine Learning with TensorFlow Lite on Arduino and Ultra-Low-Power Microcontrollers” (see also  Why, Hello FPGA and AI — How Nice to See You Together!).

After introducing us to fundamental AL/ML concepts and pointing us in the direction of a bunch of free software tools, the TinyML authors walk us step-by-step through the process of creating and training simple networks, analyzing the results, making modifications, and doing everything again and again until we get the results we are looking for.

It used to be that you needed pretty hairy microcontroller development systems upon which to deploy AI/ML applications, but one of the platforms capable of running all of the applications described in TinyML is the Arduino Nano 33 BLE. The reason this is of interest to me is that I’ve created loads of projects using Arduinos and other devices that can be programmed using the Arduino’s integrated development environment (IDE). Two example devices that spring to mind are the ShieldBuddy from Hitex (see Everybody Needs a ShieldBuddy) and the XIAO from Seeed Studio (see Say Hello to the Seeeduino XIAO).

One problem for me personally is that I’m a hardware design engineer by trade, and my software skills would be kindly described as rudimentary. I have friends who focus on embedded software and can navigate their way around complex IDEs like world famous explorers, locating and linking software libraries with gusto, abandon, and more than a dash of panache. By comparison, when using professional-grade IDEs, I tend to spend an inordinate amount of time gnashing my teeth, rending my garb, and muttering things like “What on earth does this cryptic error message mean?” and “Why can’t software folks speak English, for goodness sake?”

Having said this, I’ve grown to be comfortable with the Arduino’s IDE, which is why TinyML’s use of an Arduino caught my eye. Let’s keep this in mind as we wend our weary way through the remainder of this two-part miniseries.

Living in a Vacuum

There are several facets to creating an AI/ML system. The first is having a problem you need to solve. In my case, I required an example problem that I could address in my office but that was representative of real-world problems that could occur in a factory. And then it came to me…

Occasionally, my wife (Gina the Gorgeous) will ask our son (Joseph the Commonsense Challenged) to hoover the house while we are out. When we return, more often than not, we are hard pushed to spot the difference. When we ask Joseph, “Did you hoover at all?” He will indignantly protest that he spent copious time and effort on the task. It’s only when I come to look at the vacuum cleaner that the mystery is resolved — the bag (or container, depending on which machine he was using) is jam-packed full, which means he’s been hoovering furiously while not actually hoovering at all, if you see what I mean.

Thus it was that I decided to implement an AI/ML system that can detect when the hoover is full and send a text message to my phone saying, “Someone is trying to use the vacuum cleaner, but the bag is bursting.” I can only imagine Joseph’s face when, just after he’s commenced operations, I call him to tell him that he might see better results if he were to empty the hoover before continuing.

NanoEdge AI Studio Saves the Day 

Shortly after reading TinyML, I was introduced to the folks at Cartesiam and their NanoEdge AI Studio (you can access a free trial version of this little rascal from their Download page).

Available for Windows 10 and Ubuntu, NanoEdge AI Studio is very clever indeed. It starts by asking which microcontroller and sensor(s) you wish to use, and it ends by presenting you with your very own AI/ML library.

Currently supported processor options are the Arm Cortex-M0, M0+, M3, M4, and M7. Well, “good golly miss Molly,” the Arduino Nano 33 BLE sports an M0+, as does the Arduino Nano 33 IoT, which also boasts both BLE and Wi-Fi capabilities.

To cut a long story short (for now), my new BFF Louis Gobin from Cartesiam walked me through creating an AI/ML application using an Arduino Nano 33 IoT coupled with a small, low-cost CR3111-3000 split-core current transformer from CR Magnetics.

Feast your eyes on my first AI/ML-based system (Image source: Max Maxfield)

I remember once hearing an astronaut say that only a fool would go into space without a roll of duct tape. I know what he meant. In this case, as seen in the photo above, the tape prevents the weight of the extension cord’s cable from dragging everything off my office desk.

In my next column, we will first consider the current monitoring circuit we used. We will then take a stroll through the process of capturing examples of good and bad data, creating and deploying the AI/ML library, and training and using the AI/ML model. Until then, as always, I welcome any comments and questions.