# OpenRTM-aist

OpenRTM-aist is a software platform developed on the basis of the RT middleware standard. OpenRTM-aist is developed by National Institute of Advanced Industrial Science and Technology which also contributes to definition of the RT-middleware standard.

## Abstract

In RT middleware, all robotic technological elements, such as actuators and sensors, are regarded as RT-components (RTC). Each RTC provides ports to communicate with other RTCs, and developers can implement their own robotics technology (RT) systems as RTCs. The RT-middleware can thus be considered as a distributed control architecture.
RT-middleware is originally a platform independent model (PIM). Implementations of this model include CORBA, Enterprise JavaBean (EJB), and .NET Framework. OpenRTM-aist is based on the CORBA technology and implements the extended RTC specification. Experiences with OpenRTM-aist will be fed back to the RT-middleware standardization process.

## Characteristics

OpenRTM-aist implements some extended RTC features, and it also includes a Manager component to help manipulating RTCs. RTCs in OpenRTM-aist can be implemented using many programming languages, and RTCs programmed in different languages can communicate with each other. A lot of tools to ease RTC manipulations are also released by the National Institute of Advanced Industrial Science and Technology and their co-workers (in a strict sense, OpenRTM-aist itself is a library and does not include these tools).

### RT-component

The RT-component is a functional unit which conforms to the RT-component specification defined by OMG. In OpenRTM-aist, RTCs have data ports, service ports, and execution context which controls the RTC's state.

### State Machine

In standards of RT-component, RTC must have 4 states such as CREATED, INACTIVE, ACTIVE, and ERROR. When the state changes, corresponding event-handlers are called by the execution context which manages the RTCs' state machine.
For example, "on_activated" callback function is called when the RTC is activated (from INACTIVE to ACTIVE state). In on_activated callback, initialization codes are implemented.
On the other hand, "on_deactivated" callback function is called when the RTC is deactivated (from ACTIVE to INACTIVE state). In this callback, finalization codes are implemented.
"on_execute" is periodically called when the RTC is in ACTIVE state. Here, controlling or some device management (ex., polling) functions are called.
These callbacks are called by the "execution context" object. If the special execution context is attached to the RTCs, calling method or policy is modified (see execution context section).

### Data port

A data port is an endpoint to communicate with other RTCs. The data ports have their types. Ports with the same type can be connected to each other.
In OpenRTM-aist, primitive data types (like "TimedLong", "TimedDouble", and so on) are implemented. Moreover, from OpenRTM-aist version 1.0, extra data types which are expected to be used commonly in robotic systems were released as ExtendedDataType (like "TimedVelocity2D", "TimedPose2D", and so on)
Developers can define their own data types by describing IDL file. Tools can parse the IDL file and automatically generate the skeleton and stub file of the original data types.

### Service port

The service port allows communicating much more flexibly than the data ports. Developers should define service port interfaces by making their IDL files.

### Execution contexts

Execution contexts handle the state-machine operations of RT-components. In OpenRTM-aist, several kinds of execution contexts are provided. For example:
* the periodic execution context, one of the most commonly used, provides periodic calls of the "on_execute" event-handler (sensor acquisition or actuator control are usually implemented there);
* the real-time execution context, which uses Linux's pre-emptive kernel function, supports real-time operation of the RTC;
* the extra trigger execution context is an important characteristic of OpenRTM-aist. It provides the synchronization capability with dynamics simulators like OpenHRP-3.

### Configuration

Configuration is a function which dynamically changes the parameters of the RTCs during run-time. Configuration can be numeric and string.

### Supported operating systems

OpenRTM-aist runs on Windows, Linux and macOS. Furthermore, VxWorks is supported experimentally.

### Supported programming languages

Since OpenRTM-aist is based on the CORBA technology, it supports several programming languages, including: C++, Java, Python, and Erlang (unofficial).

## Tools
### RTC Builder

RTC Builder is a tool for skeleton-code generation. It is launched in the eclipse developmental environment. OpenRTM-aist also supports RTC-template which is a command-line type skeleton-code generation tool.

### RT System Editor

RT System Editor is a tool for handling RTCs. RT system editor provides following services:
* Referring RTCs' states
* Connecting RTCs' ports
* Configuring RTCs
* Activate/deactivate/reset RTCs
* Save/restore the RT-system

### rtshell

rtshell is a command-line tool which provides following services:
* Referring RTCs' states
* Connecting RTCs' ports
* Configuring RTCs
* Activate/deactivate/reset RTCs
* Restore the RT-system
* Log output of DataPorts
* Replay the log of the DataPorts

### RTC debugger

RTC debugger is a debugging tool for RTCs. RTC debugger is an Eclipse plug-in.

## License

OpenRTM-aist is licensed under the GNU Lesser General Public License (LGPL).