Operational Software Components for Advanced Robotics (OSCAR)

Research Projects

Table of Contents

Overview - What is OSCAR and what aspects of robotics does it address.
Domains - What are the sub domains inside OSCAR and what functionality they address.
XML Schemas - Schemas for representing robot specific data such as DH parameters, units, etc.
Reference - Online class reference manual
Tutorials - Exercises that help introduce and teach OSCAR functionality
Applications - Various applications developed using OSCAR
Publications - Technical documents that describe design of OSCAR, including some OSCAR applications
Links - Web links to software, papers, etc. related to OSCAR

Overview

Operational Software Components for Advanced Robotics (OSCAR) is an object-oriented framework for the development of control programs for robotic manipulators. OSCAR is developed in C++ and is primarily independent of the application software architecture. The primary goals addressed by OSCAR are:

OSCAR addresses advanced robotics.Our definition of advanced robotics is based on two goals: reconfigurability and performance based decision making. The need for reconfigurability leads to our emphasis on modularity and fault tolerance. Modularity allows us to assemble or reconfigure robots, on demand, from standardized actuator and link modules to suit application needs. Fault Tolerance is desired in critical environments and can be offered in serial manipulators through fault tolerant actuators, by extra degrees-of-freedom (redundancy), or by multi-arm systems. In the event of a fault, an actuator could have degraded performance or complete failure. Either way, we are faced with a kinematic and dynamic reconfiguration of the system.

Performance Based Decision Making (PBDM) is a means of maximizing non-linear system performance by actively utilizing the redundancy in the system. For example, a redundant manipulator has infinite ways of satisfying its end-effector constraints. These multiple solutions to the same constraint are known as the self-motions of the manipulator. The goal of PBDM is to find the best solution based on priorities set by the operator. These priorities are specified using performance criteria (for example, obstacle avoidance) and conflicts between multiple criteria are actively resolved using a decision-making system. Based on the two goals discussed above, software for an advanced manipulator system should address:

Generalized Kinematics
- Forward
- Inverse
Decision Making
Performance Criteria
- Constraint
- Dynamic
- Geometric
- Compliance

Generalized Dynamics
Compliance Modeling
Man Machine Interface
Obstacle Avoidance
Device Interface
- Servos
- Sensors
- Tools

Software development in the above mentioned areas is the first step towards developing a generic robot operating system. Besides the areas mentioned above, other necessary domains include communications, math, optimization algorithms, IO Devices, manual controllers, etc. These domains are required for the framework development, but are fairly well established and are leveraged in this work. A framework for manual controller interfacing has already been developed as a part of OSCAR.

OSCAR should intrinsically support evolution. That is, the addition of new algorithms and constructs and the deletion of defunct ones without compromising the integrity of the framework.
OSCAR's design should be decoupled from the application architecture, making possible its use in a wide variety of systems such as hierarchical, product-line, etc.
OSCAR should be completely generalized. That is it should not be designed with specific manipulator geometry in mind. This requirement makes selection of the analytical foundations critical.
Most pedagogical developments targeting advanced manipulators have been bereft of operational requirements of robotic control software. One key goal of this work was that any development done using OSCAR should directly translate to the control of a physical manipulator.
As this work targeted advanced robotics, it was critical that the system provide for integration with a simulation environment in which novel robotic devices could be conceptualized and modeled. This would also make this development valuable to users without access to physical robots and also support off-line program development.
As validation of this work, a key goal was that this software framework should lead to a reduction in program development time as compared to existing environments or methods.
A software framework’s eventual success is judged by its use in demanding applications and continuous growth through its users. As such, creating accessible documentation, examples, simulations, and packaged software would be critical to the frameworks success.

OSCAR Domains

It was earlier mentioned that OSCAR does not adhere itself to a particular architecture, however it was necessary to start with an architecture to help organize the software analysis and design process. As such, robot control software was envisioned in three layers as shown in Figure 1. The top-most layer is the Human Machine Interface (HMI), the middle is the Computational Components (CC), and the bottom is the Device Interface (DI) layer. The external constraints that affect the robot controller can be broadly categorized in two areas: (1) constraints defined by the user interface and deployment environment, and (2) constraints defined by the hardware devices such as actuators, sensors, tools, etc. that constitute the robot. User interface constraints primarily affect the HMI layer, while hardware device constraints affect the DI layer. The selection of CC depends on the capability desired from the controller, which is further defined by the robot application.

Figure 1. Layers of a Robotic System
Though the system shown in Figure 1 is described in terms of three major layers, it is not strictly hierarchical. For example, the HMI can interact directly with the DI layer and also certain applications may demand integration directly with the CC layer or the DI layer. The real-time constraints are the most stringent (millisecond level) at the DI layer and are progressively relaxed as you move up to the HMI layer. The software also tends to become more distributed moving towards the HMI layer. For example, the DI layer is normally implemented on one system, while it is common to distribute the GUI and the system state machine components of the HMI. Based on this, OSCAR is further subdivided into the following domains:

Base	Base class that acts as parent to all other OSCAR classes Supports error-handling, error logging, class naming, etc. String, Time, display, etc. classes
Mathematics	Support for linear algebra constructs Matrices, vectors, tensors, transformations, quaternions, Euler-angle representations, etc. Provides building blocks for operational software constructs
Robot Data	Support for storing robotics-related data and perform error-checking on the data Automatic initialization for data files Examples are DH parameters, inertia tensors, center-of-gravity data, etc.
IO Devices	Abstract input-output device classes Serial-ports, keyboard, memory-mapped IO, device drivers, etc.
Communications	Inter-process communication Network communications Client-server classes using TCP-IP
Forward Kinematics	Position level Velocity level Acceleration level Kinematic influence coefficients
Inverse Kinematics	Inverse Kinematics solution Resolved-rate motion control Direct-search technique Hybrid inverse technique Closed-form and generalized approaches Level III Fault-tolerance
Performance Criteria	Abstract components for performance criteria Obstacle Avoidance Criteria fusion Blackboard Architecture Decision Making Schemes
Dynamics	Newton-Euler inverse dynamics Lagrangian dynamics Complete description of physical plant
Deflection Modeling	Deflection prediction in serial manipulators Deflection due to joint and link compliance Generalized spring
Motion Planning	On-Line Motion Planner Off-Line Motion Planner Real-Time Trajectory Generation

Table 1. Domain Functionality

XML Schemas

The following schemas are being developed to facilitate data exchange between various robotic software. Additional goal is to generate a schema that leads to a well defined command set for manipulators.
Units - Measurement units related to robotics.
Manipulator Data - Manipulator level variables used to define inputs. Includes Joint Position vector, Xform, Quaternion, etc.
ManipulatorCommands - Task level commands for manipulators. Example, MoveTo.
Manipulator Modeling Types - Defines primitives such as DH parameters, Limits, Manipulator, Workcell, etc.
ObstacleModelingTypes - Primitives to describe manipulator and environment obstacle models.
ToolingTypes - Primitives to describe end effector tools.

Example Applications

Document - Decision Making for Deactivation and Decommissioning Robotic Applications
Presentation - Decision Making for Deactivation and Decommissioning Robotic Applications
Teleoperation and Automation
Modular Small Automation
Simulations
MotionPlanner - An example API of an OSCAR-based MotionPlanner.

Publications

Theses and Dissertations

[10]	Kapoor, C., “A Reusable Operational Software Architecture for Advanced Robotics,” Dissertation, 1996.
[11]	Taylor, R., “Automatic Software Interface Generation via Feature Oriented Analysis,” Thesis, 2004.
[12]	Tisius, M., “An Empirical Approach to Performance Criteria and Redundancy Resolution,” Thesis, 2004.