Designing Robots for Adoptability

By

Ken Haven

September 5, 2017

In our last blog we discussed some of the key aspects in defining requirements for designing a robot – in this week’s blog, we’re going to dig a bit deeper into this topic by focusing on how customers will adopt and use the robot in their work (aka, “use models” and “use cases”). Having clear, well defined 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 the robot 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 such that 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

This environment may still be somewhat defined, but the robot has some flexibility in terms of movement and tasks. It may be autonomous, semi-autonomous, or remote controlled and will likely be operating near or directly with people (thought necessarily so). It can move and adapt, but usually does so within a larger fixed environment (e.g., warehouse, hospital, home). Robots in this category include warehouse “pick and place” robots, floor cleaning robots

Environment#3: Unstructured Environment

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

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/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 latest Roomba series of floor cleaners has a programming use case that is different from robot that is used to deliver packages (e.g., Starship Technologies robots). 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.., and 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. Or in the case of the Avatar robot from Robotex, it 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 – if the 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 use models/cases 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.

Use cases and requirements go hand in hand – and one drives the other. And while requirements and 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 September 27-28—at the Santa Clara Convention Center, be sure to stop by our booth (#114). We’ll have the Robotex robot on display and would love to talk with you about it and/or your design.

About the author

Ken Haven has been CEO of Acorn Product Development since the company’s founding in 1993. Ken has more than 25 years of product development experience including technical leadership roles with NeXT Computer, Attain, Inc., and Hewlett-Packard. He holds MS and BS degrees in mechanical engineering from Cornell University.