Config log: getting devices to understand voice commands in an offline warehouse

Spent two days in a client's warehouse last week. The most annoying thing was the northwest corner with no signal — the robot not walking accurately was secondary. Our original voice interaction went through the cloud: audio up, result down, and if it dropped in the middle it was dead. Later we switched to a solution running locally — the audio never leaves the machine, and after processing it outputs the command directly. This time we used Creoir's defense-grade edge voice AI. The name sounds intimidating, but in practice it does one thing: turns what you say into executable commands, entirely offline.

Don't let the words "defense-grade" scare you. Broken down it's three actions: turn your speech into text, figure out what you want it to do, then decide whether to say something back. Those three steps used to all be in the cloud; now they're crammed into a small local box. Edge AI means processing locally on the device — it runs without a network, responds faster, and data never leaves the machine.

Not much to prepare. An edge box that can run inference, the kind with an NPU — the one I have is palm-sized; a near-field microphone — don't cheap out with those ceiling-mounted far-field mics in the warehouse; a command phrase list spelling out which sentences you want it to recognize; a laptop to connect to the box and change config; and an environment where you can cut the network — that's important, more on that later.

From power-on to the first result, the steps go like this. Power up the box, connect it to the laptop with an Ethernet cable. The box doesn't open to the public internet by default, only on a local subnet; change the laptop's address to the same subnet and you can reach it. Type the box's LAN address in a browser, go to the config page, and on the left you'll see four tabs: voice frontend, command phrases, local inference, output. Click command phrases and add the sentences you want recognized one by one. My first batch was only six: station one out of material, line stop, reset, continue, call someone, emergency stop. Back to local inference, flip the switch on, pick the Chinese model — this step takes a while to load, there's a progress bar on screen, don't rush to cut power. Say "station one out of material" into the mic and a line of recognition result appears on the page, followed by a confidence score; a high score means the model is sure. Click output and wire the result to a serial port or a local message queue — downstream PLCs and AGV dispatch can all receive it. On my side I hooked it to a ROS2 topic, two lines of config and it was through. The expected result: you say a sentence, text appears on screen, downstream equipment receives a command, and the whole process never touches the public internet.

Next, three pitfalls I hit. First, microphone placement. I initially mounted the mic on top of the cabinet, a meter and a half from the person, and with fan noise in the warehouse the recognition rate tanked. Later I moved it thirty centimeters in front of the console and added a piece of acoustic foam, and it stabilized immediately. No matter how strong the edge model is, it can't survive dirty input. Second, command phrases written too long. My earliest version was "station one workstation material is almost used up please restock," and the model often only caught the second half. The phrase list on an edge device is small; the longer the sentence, the more it drifts. Changing it to four characters, "station one out of material," was much more stable. Also watch out for pronunciations that are too close — "line stop" and "machine stop" — in my testing they really do get confused, just swap one out. Third, it wouldn't boot after the network was cut — this one's the sneakiest. Some systems do an online check on first boot and hang at the boot screen without a network. The fix is to activate once online first, then pull the cable. I remembered that on the second deployment: power on with network, run one command through, then disconnect. One more detail: don't set the confidence threshold too high. Set it near perfect and it won't respond with even slight ambient noise, and on site people will think the machine is broken.

Next step: don't rush to add features. I'd suggest doing just one thing — hook this up to a real action, like saying "line stop" and having the conveyor actually stop. Get that chain working and you'll know whether the latency is acceptable. After that you can add voice readback, having it confirm "line stopped" so the operator has peace of mind. Chaining multiple commands is also worth trying, but that's step two.

The value of edge voice AI, in the end, is that it's still there when the network is down.