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.

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:

  1. You light up the pick location, then light up the first put location only after acknowledging the pick
  2. 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.

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!)

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.

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.

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

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.

© Copyright 2022 Voodoo Robotics. All Rights Reserved. Patents Pending. Voodoo Robotics, Voodoo Devices, Big Block Server, and Turbo names and logos are all trademarks of Voodoo Robotics.