A Universal Pendant Could Elucidate the Interface to Industrial Robot Manipulators
/A guest post by Dr. Mitch Pryor, UT Austin Nuclear and Applied Robotics Group
The ROS-Industrial Consortium Americas held its 2014 members meeting at SwRI in San Antonio, Texas on March 6th. One of the primary activities of the Consortium is to establish the technical vision and requirements for ROS-Industrial. This is done through a series of requirements gathering and analysis activities known as roadmapping. This blog provides a useful forum for sharing ideas on the proposed ROS-I roadmap and gives members a chance to succinctly present thoughts on particular topics and receive feedback from all stake holders via constructive comments. The roadmap development approach presented by Clay Flannigan (and Steve Jobs) starts with the end-user’s needs (i.e. applications). Once identified, as many were at the ROS-I spring meeting, the roadmap then pinpoints the technical gaps and puts forward an implementation plan to develop the envisioned technologies.
I want to start a discussion on what “commands” hardware must reliably execute to follow the desired trajectories and/or apply proscribed forces for a given application. In the traditional paradigm, such commands are communicated via a teach pendant or offline programming.
A teach pendant is a handheld controller that provides the primary conduit for moving the robot and recording the position locations. Traditionally, it is used to sequentially teach the EEF locations associated with a given task. This instruction method is insufficient for ROS-I to extend the advanced (i.e. advancing the autonomy or flexibility of a system) capabilities of ROS to new industrial applications. Offline programming offers more flexibility but there is no standard language or set of capabilities offered among hardware vendors. What is needed is a universal Application Program Interface (or universal API) with as much of the functionality as possible accessible via a Universal Pendant.
Traditional Dedicated Industrial Robot Teach Pendant. Source: SwRI 2011
Mobile HMI: Notional Universal (i.e. interoperable) Pendant. Source link.
The notion of a universal pendant is not new. Toyota developed an internal unified teach pendant in 2000. Its development did more than reduce the training time for Toyota operators, it helped Toyota define the underlying capabilities that robotic vendors must provide. The Toyota unified pendant currently does not provide access to all of the capabilities envisioned by ROS-I members. If the ROS-I Consortium was to develop a similar, but more advanced device, it would help clarify and illustrate many of the API capabilities that are needed by industry. Its development would help clarify API ambiguities and hopefully reduce the barrier to entry to much of the API functionality in an industrial setting.
What would such a teach pendant look like? What core functionality should it have? As developers, the second question is more important to answer. It certainly must provide access to the internal state of the robot (i.e. tool location, current position, current motor currents, operational status, etc.) It should be possible to modify individual joint positions as well as command joint velocities. Many advanced technologies would require access to joint torques and/or joint currents. Another useful feature would be to directly prompt a given robotic system for its mass, inertial and/or compliance parameters that are necessary in many advanced control algorithms. Remote systems should provide battery life information which is necessary to plan extended tasks. Another interesting option would be access to any internal, extensible wiring harness . One could even envision a universal messaging service for commanding hardware via existing proprietary languages. As the ROS-I Consortium develops new capabilities, such a service may become obsolete, but the universal API should not negate existing system capabilities.
Once the API is defined, it may not be possible to expose all functionality in a traditional pendant. Innovative ideas may be necessary if the full API is to be exposed. Even then certain functionality may still require writing code. The definition and scope of such an API is not trivial. All parties (end-users, integrators, vendors, researchers, etc.) need to assist in its creation. Once developed, hardware vendors must have the right to only partially implement the proposed functionality. But our goal must be to develop an API that enables all the technologies proposed in the roadmap and make as much of the API as possible accessible to traditional (i.e. no command line!) end-users. A universal pendant would help address this and provide a mechanism for precisely illustrating and resolving ambiguities in the proposed API.
