Construction of the software for integration and control of machine controller software is often time-consuming and expensive.  Considering robots alone, the costs of integration are three to five times the cost of the robot hardware alone; twenty-five percent of this cost is represented by software alone [3].

The Robotics Research Group conducts research on several different levels of software related to robotics and machine control, including low level software used to interface with robot actuators, sensors, tooling, etc., computational software for performing robot control and high level software for task programming and control of an entire robot workcell.

The most advanced research at RRG on robot control software is represented by OSCAR (Operational Software Components for Advanced Robotics) an object-oriented framework, written in C++ [1]. OSCAR provides reusable classes for various robotics algorithms, such as mathematics, kinematics, dynamics, motion planning, and others. One of the unique strengths of OSCAR lies in its libraries for performance criteria and decision making.

Even if given a framework such as OSCAR, the construction of software requires the manual configuration of software components. Such configuration may require a significant amount of robotics and software expertise  by the developer.

We seek to automate the construction of robot and machine controller software through the design of a product line architecture.  This work is proceeding in collaboration with the Product Line Architecture Research Group [3]

The approach is predicated upon the assumption that the design and assembly of robot control software is so well understood that it can automated. This is the case with OSCAR software, as it has been used in numerous applications, including projects at NASA, the Department of Energy (DOE), and DARPA.

We apply Feature Oriented Programming (FOP) methods to create a domain specific language and automatic code generator for robot software and robot integration.  Such an approach allows a user to automatically generate a program from a declarative specification, using a GUI.  This approach can be also be considered as a form of mass customization, which allows users to order a customized program, similar to the way in which a vehicle can be custom ordered.

Feature Oriented Programming models software using features as the fundamental unit of modularity.  Features encapsulate fragments of code which implement the feature, and are a natural means of specifying a program.  By composing features in an equation, one specifies a program variant.  Each feature is a program transformation which refines an input program.  Example equations are provided below.

P = B*A (1)

In equation (1), the program P has feature A and B.  Feature B adds data and methods to program A. 

Robot Application = MotPlanner*IKinJacobian* FKin*PumaServoSim (2)

In equation (2), the PumaServoSim program only has capability for control of individual servos.  The FKin feature adds capabilities for calculating end effector poses, the IKinJacobian feature adds a resolved rate IK algorithm, and the MotPlanner feature adds motion planning algorithms to the program.

A variant of this program can be generated by substituting different variables in the equation. For example, a program for a PowerCube robot could be generated from equation (3).

Robot Application = MotPlanner*IKinJacobian*FKin*PowerCube (3)

Robot Application = MotPlanner*IKinDamped* FKin*PumaServoSim (3)

Robot control applications using OSCAR are divided into three layers of abstraction. The upper layer is the Human Machine Interface (HMI) Layer, the middle layer is the Control Components (CC) Layer, and the bottom most layer is the Device Interface (DI) layer. These layers contain software for communication and interfaces with human operators, control code and intelligence for the robot, and an abstract robot hardware interface, respectively. The division is based roughly upon timing requirements, with the lowest DI layer being the most strict. Current work is proceeding on applying FOP theories to each of these three layers, as well as to the workcell architecture.

Initial efforts focus on the upper most HMI layer and the lower most DI layer. Future work will develop FOP model for the middle CC layer and the workcell software architecture. Each is discussed separately.

Human-Machine Interface Layer
Inital research applies a feature oriented approach to the HMI layer. This work constructs a theoretical feature model for decompsing Human Machine interface software in terms of properties, actions, and state machines. Other relevant work on HMI software is available at [6].

Control Components Layer
The Computational Components layer is where the majority of OSCAR code lies. This layer contains the code for kinematics, dynamics, motion planning, obstacle avoidance, performance criteria, decision making, and control. This layer is the subject of future work. However, an initial model identifies the features in Table 1.

Device Integration
Inital research on the DI layer has implemented a prototype feature model for integrating different models of robot hardware into a controller. The design is based on the existing models of robots used by RRG. These are the KB2017 17 Dof Dual Arm Robot, the PowerCube 1-7 Dof Modular Robot, and the Roboworks simulation environment, as summarized in Table 2.

Each robot has a number of different capabilities and communications interfaces. However, there is a common set of functionality which may be provided by more than one robot. For example, all the robots mentioned provide Postion Control. However, only the KB2017 and PowerCube provide Velocity Control.

The prototype feature model consists of 41 such features divided among two sub-domains-- Real Time features and Actuator Hardware features. There are a total of 7 different Real Time features, and 34 Actuator Hardware features. The Real Time features are summarized in Table 3 and the Actuator Hardware features are summarized as in Table 4.

Also, each of the features in Table 4. may be emulated in software or directly supported by hardware. For example, the Position Control Feature actually has three different variants, a Position Control Hardware feature, a Position Control Emulation feature, and a Position Control Interface feature, which provides a common interface to any implementation of Position Control.

As there are 12 different features in Table 4., and each feature additionally has 3 variants, there are 3*12 = 36 theoretically possible features. In practice, there are only 34, as the Current Control Emulation and Torque Control Emulation features would require full inverse dynamics models of the robot, and negatively affect timing properties of the DI layer.

Using the above features, it is possible to construct equations for various programs and have them automatically generated. Preliminary work shows that 200 such combinations are possible.

Workcell Architecture

Workcell consists of hardware like robots, conveyors, tools, vision hardware, sensors etc. which must be integrated for performing a task. This integration can be best achieved with a software architecture that is reconfigurable and extendable.

Essentially, workcell software should be able to handle

1. Layout design.
2. Control and communication.

Layout design focuses on generating a suitable layout for the workcell given its components and the task to be performed. The layout may optimize speed, throughput etc.

Control of the workcell can be broken in two broad layers

1. Device control: Control of the individual devices in the workcell. One way of achieving this is to have a separate controller for each device (for example, robot controllers for each robot, PLCs for conveyors etc.). This ensures modularity since each device can work independently and new devices can be added without affecting the others.
2. Device co-ordination: This is a complex task and various architectures are possible to achieve this goal. The most common architecture which is being used in industry is supervisory control. A supervisory program takes care of the overall task coordination of the cell. It receives data from all the device controllers and gives instructions to them. This architecture can become huge and difficult to manage as more and more devices are added, and the tasks are varied.

Another architecture is agent-based architecture in which each device controller has an independent agent attached to it. These agents are capable of taking action on their own without asking a supervisor. Other agents can be used for ensuring that the system stays in a consistent state (that is, the state of the system specified by the data variables is the same for each device), for task generation for optimization etc. This architecture appears scalable to larger systems. However, it is much more difficult to achieve co-ordination between independently acting agents than that in supervisory control, and it is possible that the agent responsible for maintaining consistency in a huge system would itself become too complex to develop, maintain and repair.

A hybrid architecture with the fusion of the above two is also possible.

The key requirements of manufacturing industry today are flexibility and reconfigurability: the ability to perform different kinds of tasks and the ability to quickly change over from one task to another. In this scenario it is important that the software for workcell operation be generated and deployed quickly.

One tool for achieving this is Feature Oriented Programming (FOP). The software components for the workcell domain are modeled as features, and control software for any given workcell can be obtained from these features. The operator specifies the features, and software tools called generators automatically generate the software from the components. So in essence, the user should be able to say “I want to perform a drilling operation on this metal piece using a 5 DOF robot, and a conveyor of these specifications to transport the parts. The layout of the workcell is this and the throughput needed is this”, and software for the workcell should be generated from the components.