BACKGROUND

Robots are machines having both electrical and mechanical systems that allow the robot to be controllably managed to perform intended actions. For example, a robotic arm is a type of robot implemented as a mechanical arm, where the robotic arm may be controllably manipulated into a range of different positions and motions. The robotic arm may further include an end effector or gripping mechanism (such as a robotic hand) which can be used to pick up, hold, and release objects to be manipulated.

Robots may be used in any environment in which it is advantageous to have a mechanical entity automatically handle a task, especially a task that requires precise, repeatable manipulations of objects in the environment. In fact, modern manufacturing facilities often use a variety of robot devices at different stages of the manufacturing process to make, assemble, test, and/or package items being manufactured in the facility.

Robots typically include some sort of control system to control the operation of the robot. Computer code is often employed to guide the operation of the robot, where the computer code is embedded or otherwise loaded onto the robot, and execution of the computer code causes the robot to perform its intended operations.

FIG. 1Ashows an example robotic arm104whose operation is controlled by a robot controller102a. A control computer124may be used to interface with the robot controller102a, where the control computer has a user interface to allow a user to send control instructions to the robot (such as “start” and “stop” instructions). The control computer124may also include software pertaining to the analysis/processing of data from the robot system.

Consider if the robot arm is employed by an organization as a test platform to perform a manufacturing function, but once the proof-of-concept for the manufacturing task has been approved, the organization would like to move to another type of robotic mechanism (such as a conveyor belt) to perform the manufacturing task. The robotic arm is often used to create and refine a given manufacturing task, given the wide range of control that can be achieved over the motions and articulations of the arm. However, robotic arms are comparatively more complicated and expensive compared to simpler and more specialized devices such as conveyor belts.

Therefore, once the concept behind the manufacturing task has been sufficiently developed using the robotic arm104ofFIG. 1A, the organization may seek to implement that same task on the factory floor using the simpler device, such as conveyor belt106ofFIG. 1B.

The issue is that each robot manufacturer typically provides its own unique programming environment to allow its customers to create and install a software application to control the operation of the robot. The robot manufacturer may include a toolkit of functionality that may be called from the software application. In some cases, the software may be implemented using a general purpose programming language (such as Java or C), and on other cases, a specialty software language may need to be employed to create the software application.

However, when implementing a new robot from a different/second robot manufacturer, that second robot manufacturer will likely provide its own programming environment that is different from the programming environment provided by the first manufacturer. This means that users that seek to use a different robot to perform a function may need to engage in a new grounds-up process to create the software for the different/new/second robot, even if the function to be performed by the second robot is similar or identical to the first robot.

In the situations ofFIGS. 1A and 1B, this means that even after a first custom application104awas fully created for the system ofFIG. 1Ato control the robotic arm104, a second entirely new and custom application104bmay need to be created for the system ofFIG. 1Bto control the conveyor belt106—even if there is a substantial overlap of functionality between custom applications104aand104b.

This situation raises numerous issues for the typical organization. First, since each robot's programming environment is likely to be complex and different from any other type of robot's programming environment, the typical user that seeks to develop software for a robot normally requires a significant investment in training and experience to allow for a competent background to safely and effectively develop the robot's software. Indeed, the robot can be a very dangerous piece of hardware that is capable of destroying itself and things around it at high speed. Thus, it is not advisable to allow a user to develop a custom application for the robot unless that user has been fully trained to do so. However, this severely limits the scope and/or number of users within an organization that are eligible to develop programming for the robots, especially if a number of different robots systems are used within the organization.

Another issue that may exist is that the custom computer code may include information that is considered sensitive and/or proprietary by the organization. For example, the robot may be employed to engage in a manufacturing process where the manufacturing/operating processing and/or conditions are embedded into the operating software, and that information about manufacturing process or operating conditions are considered trade secrets. However, if the robot is being operated and/or provide by a third party (such as a third party contract manufacturer), then a security risk may exist with respect to the organization's trade secretes since the third party would potentially have access to the robot and its custom computer code.

Therefore, for at least the above reasons, there is a need for an improved approach to implement software for robotics systems.

SUMMARY

Embodiments herein provide an improved method, system, and apparatus to generate an architecture to implement execution modes on robotic systems. In the architecture, a mode execution module is provided to execute execution modes on the robotic system.

In one embodiment, a system includes an execution module that receives software instructions in a normalized programming language. The system also includes an interface having a translation layer that converts the software instructions from the normalized language into robot-specific instructions that operate in a particular robotic system. The system further includes a controller that is communicatively coupled to the interface, wherein the controller receives the robot-specific instructions. Moreover, the system includes a robotic device that is operatively controlled by the controller by execution of the robot-specific instructions.

In one or more embodiments, the software instructions include one or more execution modes corresponding to at least one of an enter mode, an exit mode, and a trigger mode. The system may also include a second interface that converts the software instructions from the normalized language into second robot-specific instructions that are sent to a second controller to operatively control a second robotic device, where the second robotic device corresponds to a different type of device from the robot device. The second robot-specific instructions for the second robotic device may correspond to a different set of programming instructions from the robot-specific instructions for the robotic device.

In one or more embodiments, the execution module includes a mode selection module, a mode instruction processing module, and a controller interface module. The mode selection module may select a specific mode based on a mode selection instruction. The mode instruction processing module may determine a specific combination or sequence of mode instructions to be issued to the controller to perform a desired operation. The controller interface module may issue one or more API calls corresponding to the particular robotic system that are sent to the controller. At least one of safe entry points or safe exit points may be established for entry or exit of modes.

In one or more embodiments, the system also includes a rulebase having a set of rules that identifies acceptable or unacceptable sequences of modes for one or more robotic systems. The set of rules may be accessed to determine where a selected mode of operation for the robotic device is acceptable as a next mode of operation. The controller may include a real-time operating system that controls a motor driver to operate the robotic device. The execution module may be loaded as an application onto the controller.

In one or more embodiments, the controller includes both a real-time operating system (RTOS) and a user-space operating system (OS). The RTOS may control a motor driver to operate the robotic device. The user-space OS may provide user-specified commands to the RTOS. The interface may issue API calls that are understandable by a manufacturer-provided robot application layer within the user-space OS to execute the software instructions.

In one or more embodiments, the controller includes a thin interface layer and mode control functionality is located within a mode control/select layer that is located at a control application at a control computer. The interface may have functionality to communicate with the mode control/select layer and to deliver the robot-specific instructions to a RTOS. The execution module may be implemented as a loadable kernel module (LKM) within a RTOS at the controller.

In another embodiment, a method includes receiving software instructions for a robotic device in a normalized programming language. The method also includes converting the software instructions from the normalized language into robot-specific instructions that operate in a particular robotic system corresponding to the robotic device. The method further includes controlling the robotic device by execution of the robot-specific instructions.

In one or more embodiments, the software instructions include one or more execution modes corresponding to at least one of an enter mode, an exit mode, and a trigger mode.

In one or more embodiments, the method also includes identifying a selection of a selected mode. The method further includes determining whether the selected mode is acceptable in light of a current state of the robotic device. Moreover, the method includes placing the robotic device into a safe exit state or location for a current mode if the selected mode is acceptable. In addition, the method includes stopping the current mode. The method also includes placing the robotic device into a safe entry state or location for the selected mode. The method further includes starting the selected mode.

In one or more embodiments, a set of rules in a rulebase are accessed to determine where the selected mode for the robotic device is acceptable as a next mode of operation. If the selected mode is not acceptable, then a determination may be made of an alternative instruction that is an acceptable alternative to the selected mode. The alternative instruction may be determined by at least one of checking the rulebase, performing manual intervention, or using a machine learning system. Within a single mode, the safe exit state or location may be different from the safe entry state or location. Between different modes, the safe exit state or location or safe entry state or location for a first mode may be different from the safe exit state or location or safe entry state or location for a second mode.

In one or more embodiments, once a new mode is entered, a waiting period is entered for a trigger. The robotic device may perform a predefined mode function corresponding to the trigger. The software instructions may be converted from the normalized language into robot-specific instructions by generating a set of API calls that correspond to the particular robotic system corresponding to the robotic device.

In still another embodiment, a computer program product embodied on a computer readable medium, the computer readable medium having stored thereon a sequence of instructions which, when executed by a processor causes the processor to execute a method including receiving software instructions for a robotic device in a normalized programming language. The method also includes converting the software instructions from the normalized language into robot-specific instructions that operate in a particular robotic system corresponding to the robotic device. The method further includes controlling the robotic device by execution of the robot-specific instructions.

In one or more embodiments, the software instructions includes one or more execution modes corresponding to at least one of an enter mode, an exit mode, and a trigger mode.

In one or more embodiments, the sequence of instructions further executes the method also including identifying a selection of a selected mode. The method further includes determining whether the selected mode is acceptable in light of a current state of the robotic device. Moreover, the method includes placing the robotic device into a safe exit state or location for a current mode if the selected mode is acceptable. In addition, the method includes stopping the current mode. The method also includes placing the robotic device into a safe entry state or location for the selected mode. The method further includes starting the selected mode.

In one or more embodiments, a set of rules in a rulebase are accessed to determine where the selected mode for the robotic device is acceptable as a next mode of operation. If the selected mode is not acceptable, then a determination may be made of an alternative instruction that is an acceptable alternative to the selected mode. The alternative instruction may be determined by at least one of checking the rulebase, performing manual intervention, or using a machine learning system. Within a single mode, the safe exit state or location may be different from the safe entry state or location. Between different modes, the safe exit state or location or safe entry state or location for a first mode may be different from the safe exit state or location or safe entry state or location for a second mode.

In one or more embodiments, once a new mode is entered, a waiting period is entered for a trigger. The robotic device may perform a predefined mode function corresponding to the trigger. The software instructions may be converted from the normalized language into robot-specific instructions by generating a set of API calls that correspond to the particular robotic system corresponding to the robotic device.

Further details of aspects, objects, and advantages of the invention are described below in the detailed description, drawings, and claims. Both the foregoing general description and the following detailed description are exemplary and explanatory, and are not intended to be limiting as to the scope of the invention.

