3 Ways to Avoid Obstacles on Your Robot Scaling Journey

One of the hardest parts of growing a company is coming to terms with the inevitable growing pains. Robots add an interesting paradox – while they are inherently built to support scaling, they often add complexity by generating massive amounts of data that requires intelligent processing to manage and drive continuous improvement.

Robots, especially autonomous mobile robots (AMRs), must also operate in a range of settings, which often involve unpredictable situations where robots need assistance. The good news is that many robotics companies have gone through this, creating some great techniques to avoid common pain points. These techniques can help a company scale their fleet to dozens, hundreds and eventually thousands of robots.

#1: Take advantage of the cloud

While the first few trials of a robotic deployment can take months or longer, a successful initial deployment can trigger the need for very rapid growth at arbitrary scales. The elasticity of cloud services is made for this. While some industries are especially cautious about this transformation and the possible exposure of their data, security practices of today’s cloud vendors in many ways offer superior protection of critical data than even pure on-premise solutions. Beyond the cost savings of a fully scalable architecture, the cloud provides additional benefits for companies willing to take the leap.

For example, robots that need assistance can get help from operators located anywhere on the planet, giving companies massive flexibility in providing cost-effective operations. Data compiled at one site can be aggregated and easily stored across multiple sites for deep analytics and comparisons, to rapidly trace disparities and help optimize site and fleet performance. Actions taken to manage the data better in one setting can be deployed across a distributed fleet around the world in seconds through the cloud.

#2: Use adaptive diagnostics to control costs while scaling

A typical AMR can generate terabytes of data from all of its sensors, and when it needs sub-second precision in certain situations. When introducing robot operations, monitoring and diagnostic tools, this can quickly get expensive if a company does not observe best practices with robot cloud connectivity. This includes potentially excessive data transmission costs (even with somewhat controllable data costs), as well as storage costs for data associated with fleet performance for reporting and analysis.

The reality is that AMRs, especially at the scaled deployment stage, are generally great at doing their work, so they don’t require anywhere near the amount of data that they are generating to be transmitted or stored. A RobOps (Robotics Operations) practice that can help control costs while scaling robot fleets is what we call adaptive diagnostics. By transmitting only the data required to identify potential issues and still be continuous enough to provide a snapshot of steady-state operations, costs remain well under control. In addition, the process is flexible enough to instantly and selectively ramp up to provide targeted, higher-resolution data.

Triggers for higher precision data can be activated automatically, responding to exactly the events that a company believes warrant attention, or when a robot operator wants to take a closer look at a particular robot for any reason. This extends to video resolution (a critical source of massive data) and data logging, along with awareness of current network connectivity and the available data channels in any given time window. All of these combine to optimize data traffic and storage, so companies can have the data they need, but little more than that. Less to store. Less to analyze. Less to pay for. Context is king and context-aware, adaptive resource management is built on intelligent throttling, downsampling, and compression.

Requirements for real-time intervention and long term storage should be appropriately configurable, optimized for the specific needs of these different use cases, such as fulfilling Service Level Agreements (SLAs) and honoring security and data retention policies.

However, remember that RobOps should never infringe on the robot’s autonomy needs. Any operations or monitoring software must always be light on resource usage. If a robot is running a mission, the RobOps software should never use more CPU than whatever is left over from the robot’s autonomy software. For non-critical operations, such as data compression or batch transmission, this needs to be completed when the robot is idle and charging, as well as connected to a lower-cost network connection, such as Wi-Fi instead of LTE.

#3: Avoid VPN, yet remain secure

Security is often the first checkbox when companies are considering robots, and many opt for VPN, a go-to solution that has earned trust as a security source for the average remote worker. But just as VPN can create minor headaches when a company requires it for what otherwise would be a casual, remote check-in, it introduces challenges that can be a major barrier to rapidly scaling a robot fleet.

VPN is meant for relatively stationary computers that connect to a corporate network, and in many cases this doesn’t match the use case of an AMR, which autonomously roams in an uncontrolled environment with unreliable connectivity. In addition, managing a VPN setup requires a permanent staff of network specialists, often from an IT department. For a small fleet, VPN can be managed as a side project, but at scale we’ve encountered many times when this turns into a non-trivial maintenance burden, requiring its own specialized staff.

In addition, VPN grants essentially unrestricted access to the connected machines (in this case, robots), which makes it harder to explain to adopters and requires specialized knowledge in order to implement refined security policies.

Security benefits that VPN brings can be effectively addressed with a much less complex solution, as long as a company’s IT team is willing to consider the core reasons they rely on or require VPN, and are open to alternatives. Specific, concrete measures can be taken to achieve the same level of security, and won’t bring your fleet to a crawl at the critical moment when you need to scale to a level that you haven’t had the opportunity to exercise in practice.

Start by only having encrypted data processed outbound from robots against well-known endpoints, with strong role-based access control involved, and whatever level of security certificates your company requires. When relying on a managed, secure cloud connection, and leveraging NAT traversal techniques, VPN is no longer a requirement. 

Additionally, robots can be configured with the principle of least privilege, meaning that the robot should be given only those privileges it needs to complete its task. If implemented within a zero trust architecture, robots can perform their tasks without companies worrying that the machine is a possible vulnerable endpoint.

With these three techniques, companies can more rapidly scale their robotic fleets, avoiding potential pitfalls as they grow. To discover ways that robot companies or firms deploying robotics can scale fleets further, schedule a demo of the InOrbit platform.