Deployment Best Practices
Voodoo Robotics Modern Devices
In almost every case, you should be using at least an up or down arrow. Pickers are not always very experienced, and they may not know if a device placed on a shelf refers to the inventory on that shelf or the inventory below that shelf. Heck, we even have the same problem with pricing labels in the supermarket!
Arrows can point up, down, left, right, top left, top right, bottom left, and bottom right. And arrows save money: By using a single device as an indicator for multiple locations you may be able to deploy a more economical system. At the same time, pick to light systems are often deployed to minimize picker confusion, and having a one-to-one ratio of device to location is certainly the simplest way to configure a system.
Often prospective customers think of our devices as simply Pick to Light devices that only do something when it’s time to pick. But we’re so much more: Consider using our device to simply show (between picks) the current inventory that is supposed to be in the device location. What a powerful tool for anybody, at a glance, to verify that counts on the floor are accurately represented in the WMS or ERP! There are myriad other uses for our devices.
That’s why we call them ‘Cloud Display Devices’. We challenge you to think creatively about what sort of signage would be most useful to your operations.
Using a standardized location on the display of devices for quantity is very easy to do with our ‘qty’ parameter. The biggest error in picking is in picking the correct quantity. You should have a clear and consistent way to present this critical piece of information to your picker.
There’s really no point in putting up our devices right next to a shelf label with a barcode. Save time energy and stickers by encoding the barcode on the device itself. Remember also that you can construct a new unique barcode for every transaction with a device. Having the picker scan this code can be a powerful (very specific) way to verify a pick.
Where possible you should use the location feature of the device. If a device is mounted to a rack, the location on that rack should be coded into the device. If the device is attached to a tote, you should use the location feature to hold the tote ID. Or even consider using the location to represent a customer order ID.
The way text is displayed on our devices is very dependent on the number of lines of text and the number of characters on each of those lines that you specify. Using fewer lines and using fewer characters on each line will allow the device to maximize the scale of the message you’re trying to deliver.
Where possible, you should try to use a consistent number of lines with a consistent number of characters per line when sending a command to a device. Pickers don’t want to have to read very carefully all the information on the display of a device. They need to be able to find the pertinent information on the display quickly in a simple glance. Putting that information in the same place in the same sized font, over and over again, is the way to go.
There are three key ways to minimize battery usage:
- Use as little sound as possible. If you don’t need a beep, set the ‘sound’ parameter to ‘none’. And avoid repeating sounds like the plague!
- Use a flashing light instead of a solid light. A flashing light uses about 1/3 the energy of a solid light. Turning light brightness down also helps a bit.
- Favor the colors red, green and blue over cyan, magenta, and yellow. It’s just a quirk of our devices that the latter use twice as much power as the former.
The REST API offers much more flexibility than the QueryString API. For example, you can retrieve device voltage using the REST API but cannot with the QueryString. Having named parameters (not available in the QueryString API) also makes coding simpler and easier to debug. On the other hand, doing an HTTP POST as required by the REST API will require the CSRF token. Adding multiple commands to a single call to the ‘devices’ endpoint is also a little faster than a bunch of singletons. See our documentation for more details.
Our modern devices work in basically two modes, a signaling mode and a static mode. During signaling, the device lights up and plays a tune as well as displaying text. Between signalings, the device only shows text.
Sometimes it’s obvious to signal a picker with a lighted device to take some action and push the button to complete the action, but other times, it’s not so obvious. You might be tempted to light a set of lights to show their status, but it’s often the better choice to simply update the static display. In general, if you’re lighting a device or a set of devices for longer than about five minutes, it’s worth reviewing your process.
Our number one enemy at Voodoo Robotics is latency! Latency is the amount of time it takes from the moment you scan a barcode or hit the enter key until the device lights up with instructions for the picker. No picker wants to scan a barcode and then waste time waiting for a light to light up. There will always be some lag and we try our best to minimize it. But these delays are only emphasized by lockstep scenarios. For example, in the case of a putwall, you could light up the pick location, and then only after that pick is acknowledged, you then highlight the first put location. And then only when that put is acknowledged do you highlight the next location, and so on.
Why not just turn on the pick device and all put devices at the same time?! Better yet, if you have the chance, try to anticipate the path a picker might take and light up a device before he even gets to the point where he’s in a position to pick.
As fast as your software runs, and we like you to create very fast software with low latencies, there is no way that your software can respond faster to a button press than Big Block can. By pre-building sequences with the Big Block sequencing engine, you can control the real-time response to events without investing in enormous resources to process requests at the speed of light.
Our devices are tough, especially with their ruggedized covers. The buttons should last for millions of button-presses (and can even be easily replaced). But from time to time, devices are run over by forklifts or melted by flamethrowers! Whatever software you design to interface with our server, it should allow for the maintenance, movement, or replacement of devices over time. Do not hardcode a DeviceID for a specific location. You’ll regret it down the road.
When sending a command to our devices to light up, it is possible to, at the same time in the same command, send an update about what the device should display between commands. DON’T DO IT! Because of the way our devices communicate, this can cause a full doubling of your call latency. And the static information is not needed until after the command times out or the button is pushed. Instead, separate out your commands from your static updates and send the static updates later.
An overlooked feature of Big Block is the ability to assign a location name to each Turbo. It’s important that you take the time to do this because it facilitates the easy identification of Turbos in the system. Nobody wants to refer to a Turbo by its serial number. Having the associated location with the serial number is helpful in a variety of ways.
Some customers have asked us to install our Big Block behind their firewalls on a private, internal IP address. This can be done but has significant security implications. For example, without a public IP address for the server, we cannot obtain an SSL certificate. And without that certificate, all communications in and out of the server and between the server and Turbos must be passed in the clear using HTTP, not HTTPS. That’s definitely not the way to make a reliably secure system.
While each Turbo POE can communicate with 250 devices, it’s certainly not a good idea to use just one Turbo for that type of deployment. A real deployment should never have only one Turbo if for no other reason than simple redundancy. We strive to always have any single device in the system visible to two Turbos.
As they say, “If you want to optimize a metric, start by measuring it.” In our obsession to minimize latency on our devices, we’ve developed some very useful tools for measuring these latencies. Check out the latency graphs for devices that show delay times broken down by Turbo, and check out the latency graphs for Turbos broken down by device. It’s very useful information in evaluating your setup.