Have an idea for an innovative healthcare robot? Here are a few design principles to help you avoid common pitfalls.
Ken Haven, Acorn Product Development
When people think of robotics, they often think about warehouses or manufacturing lines, where robots automate multiple processes. But robotics has the potential to reshape the way healthcare is delivered in a variety of applications and locales. While we’re a long way from a robot replacing a physician, there are many opportunities to provide automation in the healthcare arena that can reduce costs and free up healthcare workers’ time to focus more on patient care. Possibilities abound in areas including surgical robots, exoskeletons, telepresence robots and robotics for medication management.
No matter the application, there are a few principles to keep in mind when designing for robotics.
1. Design for manufacturability: Emphasis on “design for”
The implementation of a DFM approach to design can have a significant impact on the overall development cost as well as the timeline for getting a design through production. Keeping sight of the end goal from the start can ensure higher quality and lower overall cost. While DFM analysis can be done after the design is “completed,” that’s far from the optimum approach.
For post-design design for manufacturability, you’ve already invested time and money creating the current version. Any changes you make for the parts of the design that are creating potential DFM issues must be analyzed in the context of the impact of those changes on the larger system. Changes will also need to be verified and tested to determine if there is any impact on performance, quality, reliability, etc. DFM done at this stage also means there are now two different versions of the product to document, manufacture and support.
Lastly, DFM done post-design is usually very constrained. There are tooling modification limits and previous “baked-in” design concepts which would require a complete redesign to correct. The product is often perpetually compromised and won’t ever have been as cost-effective as one designed with manufacturing in mind. The later in the design cycle all of this is done, the more costly the changes are. It’s crucial to consider DFM from the start!
2. Design for adoptability: Use models
Having clear, well defined use models is critical to the success of any product development effort. Let’s start with the environment: Where will the robot be used?
We can break use down into several broad categories:
- The first is an isolated, (somewhat) fixed environment. This is an environment where a robot is more or less stationary or only moves within a confined space that’s 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.
- The second is a somewhat defined environment. This environment may still be somewhat fixed, 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. Robots in this category include warehouse “pick-and-place” robots and floor-cleaning robots.
- Last is an 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 patrol robots and 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 will the set-up 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.
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 accepted) 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 a significant impact on the design – and indeed can help control costs. The more they are defined up front, the smoother the design process will be.
Ken Haven has been CEO of Acorn Product Development (Newark, Calif.) since the company’s founding in 1993. Haven has more than 25 years of product development experience including technical leadership roles with NeXT Computer, Attain and Hewlett-Packard. He holds MS and BS degrees in mechanical engineering from Cornell University.
The opinions expressed in this blog post are the author’s only and do not necessarily reflect those of MedicalDesignandOutsourcing.com or its employees.