Deployment Best Practices
for Voodoo Robotics Modern Devices
for Voodoo Robotics Modern Devices
Whether you are building your own picking system with our Modern Devices or you are integrating our Big Block Server engine with your Warehouse Management System (WMS) or Enterprise Resource Planning (ERP) system, Voodoo Robotics is here to help. Please do not hesitate to contact us to review your software plans. We have helped many customers before and bring a wealth of experience to the table.
Given what we have seen, we suggest you keep the following design guidelines in mind:
In almost every case, at least use 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 is above or below that shelf. (This problem is similar to what one might encounter with pricing labels in a supermarket or warehouse store.) Pick-to-light systems reduce costs by minimizing picker confusion.
Arrows can point in six directions: up, down, left, right, top left, top right, bottom left, and bottom right.
Using arrows saves money.
Use Static Text Elements
Often prospective customers think of our devices as simply pick-to-light devices that only do something when it is time to pick. Our devices can do much more and that is why we call them Cloud Display Devices rather than just pick-to-light devices.
There are myriad of other uses for our Cloud Display Devices. We challenge you to be creative in deciding what would be most useful for your operations.
Use Quantity (\qt)
Using a standardized location on the display of devices for quantity is very easy to do with our ‘\qt‘ parameter. The most frequent error in picking happens when the the picker pulls the incorrect quantity. Use this parameter so that the Cloud Display Device clearly and consistently presents this critical piece of information to your pickers.
Use Barcodes and QR Codes
There is really no point in putting up our devices right next to a shelf label with a barcode. Save time, energy, and sticker costs by encoding the barcode on the device itself. Remember that you also can construct a new unique barcode for every transaction with a device. Having the picker scan this code can be a powerful (very specific) method to verify a pick. The Cloud Display Devices support QR codes just as easily.
Use Location and Area
Where possible, use the location feature of the device. If you mount the device to a rack, code the location of the rack or the specific location on that rack into the device (e.g., row, aisle, and shelf). For devices attached to a cart, tote, or bin, consider using the location feature to hold the identifier of the cart, tote, or bin. You may even consider using the customer order ID as a location.
The way text displays on our devices depends 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 optimize the scale (size of text) of the message you are trying to display.
Try to use a consistent number of lines and a consistent number of characters per line when sending a command to a device. Pickers do not want to have to read all the information very carefully on the device display. They need to be able to quickly find the pertinent information on the display with just a simple glance. Putting that information in the same place and using the same font and font size is the optimal way to go.
Minimize Battery Usage
There are four key ways to minimize battery usage:
Choose the Right Type of Battery
Choose the best batteries for your operations:
Big Block Server supports detailed reporting to show battery discharge curves over time. These graphs can be very useful in figuring out what brand and technology batteries suit your particular picking processes.
Choose REST over QueryString for Integration
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.
Use the LED for Signalling not for Status
Our modern devices work in basically two modes: a signaling mode and a static mode:
In signaling mode, the device lights up, plays a tune and displays text, bar/QR codes and images.
In static mode, between signals or even if the battery dies, the information on the device display remains visible. This is one of the reasons that eInk displays have such low power consumption.
Sometimes it is 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 is not so obvious. You might be tempted to light a set of lights to show their status, but often the better choice is to simply update the static display. In general, if you are lighting a device or a set of devices for longer than about five minutes, it is worth reviewing your process.
User Your Web Browser to Check on Devices
Facilitate Device Replacement/Movement
Our devices are tough, especially with their ruggedized covers. The LED buttons should last for millions of button-presses (and, if they do fail, they can easily be replaced). But from time to time, we have heard of devices destroyed by being 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. You should not hardcode a particular DeviceID expecting it in a specific location. You will certainly regret such a choice down the road.
Never Create Locksteps
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 wait for a light to come on. There will always be some lag and we try our best to minimize it, but lockstep scenarios only emphasize these delays.
An example of a lockstep scenario for a putwall follows:
This presents a problem because it might slow down the picker.
Would it make more sense to just light up the pick device and all put devices at the same time? Better yet, if possible, try to anticipate the path a picker might take and light up a device before the picker is in a position to pick.
Let Big Block take care of Sequencing
As fast as your software runs, it is unlikely that your software can respond faster to a button press than our Big Block server can. By prebuilding 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.
Use Overlapping Transactions (NEW!)
Never Update Statics and Send Commands Simultaneously
When sending a command to light up a device, it is possible to send an update about what the device should display between commands at the same time as a command. DO NOT DO THIS! Because of the way our devices communicate, this can cause a full doubling of your call latency and the static information is unneeded until after the command times out or someone pushes the button. Instead, separate 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 is 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 more helpful.
While each Turbo POE can communicate with 250 devices, it is certainly not a good idea to use just one Turbo for that type of deployment. A working production system should never have only one Turbo if for no other reason than simple redundancy. When tuning your system, we strive to always have any single device visible to at least two Turbos.
Use a Public IP Address to Improve Security
Some customers have asked us to install our Big Block server behind their firewall 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 pass in the clear using HTTP, not HTTPS. That is definitely not the way to deploy a reliably secure system.
Check Latencies on Big Block
As they say, “If you want to optimize a metric, start by measuring it.” In our obsession to minimize latency on our devices, we have 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 is very useful information in evaluating your setup.
Don’t Overlook Temperature
Each device has a built-in thermometer. The temperature that devices report can be graphed and analyzed over time. Further, devices can be set up individually to sound an alarm if a temperature exceeds a high threshold or goes below a low threshold. You can even send out e-mail alerts to a set of addresses if a device goes into an alarm condition. Check with us if you would like to enable this feature in your system.
You do not need to Log in Every Time