How to Design Robots for Adoptability, Automation Use Cases

In our previous post, we discussed some of the key aspects in defining requirements for designing a robot. Let’s dig a bit deeper into this topic by focusing on how customers will adopt and use the robot. Having clear, well-defined automation use cases or use models is critical to the success of any product development effort. Our intent here is to provide a framework to build upon in developing your use cases.

Let’s start with the environment — where will automation be used? For robotics, we can break this down into several broad categories (each having design implications):

Environment 1: Isolated, (somewhat) fixed environment

This is an environment where a robot is more or less stationary or only moves within a confined space that is likely to be protected. Direct physical contact with people is not the norm.

Think of production lines, or robotic systems that operate inside something. One can think of this as a fairly traditional robotic application.

Environment 2: Somewhat defined environment

Such automation use cases may still be somewhat defined, but the robots have some flexibility in terms of movement and tasks. They may be autonomous, semi-autonomous, or remote controlled. They will likely be operating near or directly with people (though not necessarily so).

A robot can move and adapt, but it usually does so within a larger fixed environment, such as a warehouse, a hospital, or home. Robots in this category include pick-and-place warehouse robots and floor-cleaning robots.

Environment 3: Unstructured environment

This environment changes significantly, requiring the robot — and/or its operator — to be able to “see” and understand its environment and adapt accordingly. Underwater robots, security robots that patrol, and autonomous vehicles are examples of robots that fall into these categories.

Preparing for adoption

The next set of questions revolve around who will be setting up and using the robot. What is their expected skills level? How difficult will it be to set up the robot? How often is it likely that setup will need to occur? How do you debug or adjust the robot’s behavior?

These are important to understand in terms of ease of use, and proper integration of the robot into its operating environment. For example, iRobot’s latest Roomba series of floor cleaners has a programming use case that is different from the programming for Starship Technologies’ package-delivery systems (shown above).

In the case of the Roomba, it maps out the floor plan of the area you want to vacuum. If a piece of furniture is moved, the robot can adapt/relearn about its environment.

The delivery robot has to deal with an ever-changing landscape of locations, etc. While it can build up a knowledge base — and share it with its peer robots to improve navigation efficiency — it needs to deal with a larger amount of navigation data and requires significantly more navigation intelligence.

RoboteX’s Avatar was designed with ease of use in mind.

In another implementation example, the Avatar robot from RoboteX is controlled by an operator via a handheld controller, which requires very little user training. This was a requirement that was identified early on and incorporated into the design.

The level of autonomy (if any) is another complex area that needs to be clearly defined in automation use cases. If a robot is semi-autonomous, when and how does the user interact and intervene? What level of “decision making” will be the responsibility of the robot vs. not? What are the limitations of the decision-making capability?

For example, suppose a pick-and-place robot drops an item — should it try to retrieve it? How many times should it try before it asks for assistance?

For successful adoption, what is expected from the user/operator of the robot? What changes will be necessary (and acceptable) by customers who wish to adopt this robot to their work? What kind of management/support is needed for the ongoing operation of the robot — and who will provide that support?

Will the robot have its own “health” or status monitoring capabilities? Who will it report to in case of difficulty? How will the issue be handled?

The work done in defining the automation use cases or use models will have significant impact on the design — and indeed can help control costs as more they are defined up front, the smoother the design process will be vs. determining that a feature/capability is needed after the design is underway that will require work to be redone.

Automation use cases guide

Use cases and requirements go hand in hand — and one drives the other. And while requirements and automation use cases are generally developed by product marketing, it’s important to have engineering involved as well. Engineering provides valuable insight into what’s possible, the potential impacts on cost/performance/manufacturability/etc. of the various features/capabilities needed in the design to support the use cases.

Companies like Acorn have extensive experience in product design (and in Acorn’s case, robotics design) and can also help in early stages of use case and requirements definition.

If you happen to be attending the RoboBusiness 2017 robotics conference this week at the Santa Clara Convention Center, be sure to stop by our booth (No. 114). We’ll have the RoboteX robot on display and would love to talk with you about it and your design. And be sure to attend the panel session at 3:45 on Thursday on “Working With Partners to Adopt Robotics,” where Ken Haven, Acorn CEO, will be participating.

[note style=”success” show_icon=”true”]