Deployment Best Practices
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:
Use Arrows
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.
- Having a one-to-one ratio of device to location is certainly the simplest way to configure a system. It results in reduction of picker error.
- Using a single device as an indicator for multiple locations enables you to deploy a more economical system.
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.
- Consider using our device between picks to show the inventory that should currently be in the device location. This is a powerful tool for anybody to verify at a glance that the Warehouse Management System (WMS) or Enterprise Resource Planning (ERP) system accurately represents the counts on the floor. This is a major time and cost saver that does not shorten the device battery life.
- If you have a device attached to a tote holding a customer’s order, consider putting the customer name or order number in the static display. Anybody wanting to know what the tote contains will immediately be able to identify the contents.
- Store the status of items between picks: Often a tote will contain several items that have already been picked, but there is no current pick pending. It may be useful to use a message like
- Order ID 11285
- 5 Items Completed
- 9 Picks Remain
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.
Consider the Multi-Button Device
Customers often ask us how to handle the case when they ask a picker to pick five items, but only three are available. If these types of issues are a problem in your deployment, consider using our multi-button device. The multi-button device has two extra button at the top, a plus (+) and a minus (-) to adjust quantity before acknowledgement.
The final quantity that is acknowledged is sent along with the ‘ack’ or ‘nack’, ‘nonce’, etc. to the confirmation URL.
Multi-Button Devices for Inventory Control
Having the plus (+) and minus (-) buttons on the top of a devices has other uses, too. Consider the case between picks, if a picker just goes up to a device and pushes the plus button. In that event, the device will send notice of an unsolicited ‘call_up’ to the confirmation URL. Similarly the minus button results in a ‘call_down’ notice.
These messages can be handled in a variety of ways:
- Your system can interpret them as adjustments to inventory in that device’s location. For example, perhaps the static display on a device is tied and synchronized with a quantity box to the content of your Inventory Management System. If a manager sees a location with a device showing a quantity of four of an item, but there are only three of that item in the location, he can use the minus button to change the quantity stored in the Inventory Management System. The static display is automatically updated.
- One or more calls using the plus button can be interpreted as a request for more inventory in that location. Your system can react to these messages by automatically creating a resupply request sent to a different employee.
Additionally, consider this approach for eliminating cycle counts: Your system could, at strategic times, inject extra ‘count requests’ for pickers. If your system has 3650 inventory locations, you could choose 10 locations each day, perhaps when they are at their lowest counts, and ask your picker to adjust the quantity (using the plus and minus buttons) for that location. Adjusting inventory based on the ‘quantity’ in the ‘ack’ confirmation would totally eliminate the need for annual cycle counts–just by injecting a few extra requests each day.
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.
Minimize Text
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.
Standardize Layout
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:
- Use as little speaker sound as possible. If you don’t need a beep, set the ‘sound’ parameter to ‘none’.
- Avoid using repeating tunes with an ‘r’ in the sound pattern, because it will increase battery usage.
- Use a flashing light instead of a solid light. A flashing light uses about 1/3 the energy. Turning light brightness down also helps reduce battery usage.
- Use the colors red, green and blue instead of cyan, magenta, and yellow. The latter colors actually use twice as much power as the former.
Choose the Right Type of Battery
Choose the best batteries for your operations:
- Lithium Primaries — last longest, but ridiculously expensive.
- Alkaline — best and cheapest bet. Amazon provides a great deal on these AAA batteries in bulk.
- Zinc — terrible! Stay away. This is technology from decades ago that crooks are still trying to sell.
- Various rechargeable batteries — Lithium Ion, Nickel Metal Hydride, Nickel Cadmium: Recharging can be a hassle.
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
Some customers only interact with devices using the REST API and forget that they have full access to information and reports on the server.
- Is a device behaving incorrectly? Check on the last voltage it reported.
- Are all Turbos working properly? Get a full report. You can even see a log of all API calls made.
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:
- You light up the pick location, then light up the first put location only after acknowledging the pick
- You light up the next location after acknowledging the put, and so on.
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.
Update (December 2022): With the introduction of the new Turbo II, latencies are substantially reduced, making this far less an issue.
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
A careful study of any REST API code invariably will include an analysis of what might happen if two pickers need two commands at the same time on one device.
Fortunately, we’ve taken care of that issue: Our devices (firmware 57 and above) support the concept of ‘Overlapping Transactions’. You can now send up to 12 transactions to a single device, and the device will maintain each of those transactions until dismissed. This feature makes it incredibly easy on the programmer: You can just ignore the problem!
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.
Label Turbos
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.
Public IP Address can Improve Security
Some customers have asked us to install the Big Block server behind their firewall on a private, internal IP address. This can be done but has significant security implications.
We try to use HTTPS communications where possible, not HTTP. HTTPS requires that we install a signed SSL certificate on the Big Block server. So the options are:
- If your organization can issue a certificate for the Big Block server, we can use that certificate.
- If your organization runs an ACME server for issuing certificates, we can obtain a certificate that way.
- We can create a self-signed certificate, but your browsers and client software will have to allow for a certificate without a trusted chain.
- We can forgo certificates altogether and use HTTP. This is definitely not a good option, but some customers will tolerate insecure communications behind a strong firewall.
- If the server obtains a public IP address and responds to Internet requests (even just temporarily), we can obtain a certificate from the ISRG.
Turbo Redundancies
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.
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.
Choose the Right Button Profile for your Implementation
Some customers that deploy devices in close quarters have a problem bumping into the buttons on our devices. If you find that your buttons are popping out, consider deploying devices with low profile buttons. Just let us know and we can send you some to try.
You Need Not Log in Every Time
REST API programmers often ask: When and how often do I need to login to the server? Can I just login once and reuse my SSID forever? Or should I login again and again for each command that I issue?
The server will keep you logged in for several days at a time, but at some point you will definitely need to login again. The two best strategies we have found are:
- Log in once per day or once per shift, as your picker logs in, or
- Log in when your code starts and use error handling (i.e. try-catch blocks) to recover from any automatic expiration of credentials.
Check out our new Authentication options. We now support OAuth2.
