What is OpenRTM-aist?

rtm_logo.png
OpenRTM-aist is a software platform for robot systems. It is based on component-oriented development.

OpenRTM-aist builds a system by creating software modules called "RT component (RTC)" for each functional elements and connecting the RT components to build the robot system. The RT component can be developed by using C++, Python, Java language and work on major OSs (Linux / Unix, Windows, Mac OS X). Eclipse tool and command line tool can be used for component development and system development using components.

The RT component has functions called "ports" for exchanging data and commands with other components, basic state transitions called "activities" for unifying behaviors, and functions called "configuration" that can externally manipulate parameters. By using these functions, you can easily create modules with high independence and re-usability. By using existing components, you can build a system with just the minimum effort.

OpenRTM-aist is implemented based on CORBA distributed object Architecture, to emphasis network transparency, OS independency, and language independency. Currently, OpenRTM-aist provides implementations on C++, Python and Java languages.

RT-Middleware


(G)RT-Middleware (RTM)

(G)RT Middleware (RT-Middleware: RTM) is a generic name that refers to a software platform for constructing a robot system (RT system) by combining multiple software modules of robot functional elements (RT function elements). OpenRTM-aist is one of RT middleware implementations, Open - source and open architecture Robot Tchnology M iddleware implemented by AIST ( National Institute of Advanced Industrial Science and Technology).

(G)The RT function element constituting the RT system is a robot component that provides a certain function, for example, a unit of a device such as a servo motor, a sensor, a camera, or the like, or a combination of such a mobile cart, arm You can also capture it as an RT function element.

(G)Mata, hādouea ni musubitsuite iru mono dakedenaku, seigyo arugorizumu, gazō shori arugorizumu to itta, sofutōea nomi de kōsei sa reru mono mo RT kinō yōso to kangaeru koto ga dekimasu. Shitazu ni shimesu yō ni, mojūru-ka sa reta RT kinō yōso o kaisō-teki ni kumiawaseru koto de, robotto shisutemu kōchiku o yōi ni suru tame no purattofōmu ga RT midoruueadesu. In addition to what is tied to hardware, what can be thought of as an RT function element is one composed only of software such as a control algorithm and an image processing algorithm. RT Middleware is a platform for facilitating robot system construction by hierarchically combining modularized RT function elements as shown below.

rtsystem_integration_en.png
RT system integration by RT middleware

(G)RT Component (RTC)

(G)In RT middleware, the RT function element is made into a software module is called an RT component (RT-Component: RTC). The RT component has an interface called a port for exchanging data and communicating with other RT components.

(G)The relationship between RTC and RTM is shown in the figure. As mentioned above, RTC is a piece of software that modulates a function of a unit, its entity is a shared object (DLL) (dynamic link library) executed on RTM. The RTC developer embeds the code of the control algorithm it owns, the existing library code etc. (called the core logic) in the RTC template code automatically generated by the tool such as RTCBuilder, compiles (script language It is unnecessary in this case) to create an RTC.

rtm_and_rtc_ja.png
RTC(RTComponent) and RTM (RTMiddleware)

(G)Split and integrate modules

(G)The RT system connects ports of multiple components and is constructed as a collection of RT component functions of each. Consider a dialogue / recognition component as an example. The dialogue / recognition component is a component that has the function of recognizing and observing the user's voice and facial expression and having the function of interacting with the user by voice, gesture gesture, etc. It consists of the following subcomponents.

  • Camera component
  • Stereo vision component
  • Face recognition component
  • Microphone component
  • Speech recognition component
  • interactive component
  • Head and arm components
  • Speech synthesis component
    rtcbased_hri_system_en.png
    Example of dialogue and recognition system consisting of RTC

(G)As shown above, each of the divided components has an interface that communicates with other components called ports, and exchanges data and commands to realize one collective function as a whole. Modularization enables parallel development, reuse, exchange, update, separation, etc. on a module basis, thus reducing complexity, improving development efficiency, and improving system flexibility, expandability, and stability You can expect.

(G)History of development

(G)RT Middleware was proposed by the New Energy and Industrial Technology Development Organization (NEDO) in the project of the 21st Century Robot Challenge Program (2002 - 2004), its concept was proposed, and the National Institute of Advanced Industrial Science and Technology Research, development and standardization were conducted by Matsushita Electric Works (now Panasonic Electric Works Co., Ltd.), Japan Robot Industry Association.

(G)As a result of the project, OpenRTM - aist - 0.2 which is a reference implementation of RT middleware and its interface specification was released. After that, standardization of the RTC interface specification was advanced in the International Standards Organization OMG (Object Manegement Group: http://www.omg.org), and became OMG official standard specification in April 2008. One of RT Middleware implementations conforming to this standard is OpenRTM - aist - 1.0 published in January 2010.

(G)RTC OMG standard

(G)A major feature of OpenRTM-aist is that the component model and its interface are standardized by an international standardization organization called OMG.

(G)OMG is a software standardization organization founded in 1989. It is composed of distributed object middleware: CORBA (Common Object Request Broker Architecture), software modeling language: UML (Unified Modeling Language), various software standards It is known as an organization that has formulated and managed it.

(G)RTC interface specifications are also standardized by AIST and US middleware vendor RTI (Real Time Innovations) in OMG as well as CORBA, and RTC (Robotic Technology Component) Specification (http://www.omg.org/spec/RTC/ 1.0 /) was officially released in April 2008.

(G)One of the merits of standardization is that many vendors and developers can freely implement middleware based on standards. Currently, there are seven types (including three languages of OpenRTM-aist) shown in the table as middleware conforming to or partly conforming to the OMG RTC specification.

OMG RTC compliant middleware list

Name Vendor name Overview
OpenRTM-aist AIST Three types of C ++, Python, Java
OpenRTM.NET SEC .NET implementation, compatible with OpenRTM-aist
OPRoS Project Korea ETRI Implementation on original middleware
PALRO (Palo) Fuji Software Co., Ltd. Compact humanoid robot PARLO (Palo) control software is compatible at C ++ language level
GostaiRTC GOSTAI / Thales OMG RTC Complies with Local PSM


(G)Among these, only compatible objects via communication are OpenRTM-aist and OpenRTM.NET, but since the internal model is the same as other implementations, even when bridges etc. are created and linked, the whole There will be less inconsistency in consistency as. Also, since there are various implementations by multiple organizations, it is also possible to select the appropriate language and license according to the application, and the middleware itself is more durable.

License

OpenRTM-aist consists of middleware libraries of various languages (C ++, Java, Python), tools such as RTCBuilder, RTSystemEditor, etc. We distributed them in open source format under:
  • OpenRTM-aist (C++, Java, Python version) LGPL or individual contract dual license
  • RTSystemEditor, RTCBuilder EPL or individual contract dual license

LGPL(GNU Lesser General Public License) is a copyleft-type free software license released by the Free Software Foundation(FSF).

EPL(Eclipse Public License) is listed as one of "free software licenses" by FSF, it is a license form similar to CPL (partly LGPL) and promotes more commercial use.

These licenses can not be applied to (i) software that is distributed as a separate module or (ii) software that is not derived from the licensed program. Also, the EPL license contains a clause concerning patents, and the patent owned by the contributor does not affect the use of the software (the user is granted a patent license free of charge).

For details of the LGPL license, please refer to For details on the EPL license, please refer to

In the following, the Licenses and the constraints related to the examples of OpenRTM-aist products are explained.

RT Component Development/Distribution

The OpenRTM-ais license does not apply to individual RT components. Therefore, RT component creator can distribute/sell their products with any license .

The RT component is dynamically linked with libRTC.so (or RTC.DLL) of OpenRTM-aist, and the RT component itself can also be distributed as a shared object (or dynamic link library). Therefore, the RT component itself is not regarded as a derivative defined by the license, and it does not include the LGPL license.

license_for_rtcs_en.png
license of RT component

If you create and distribute RT components, you can distribute or sell RT components under any license and you can freely choose to open or close source code.

Modification and redistribution of OpenRTM-aist based on LGPL

If using OpenRTM-aist published by AIST under the LGPL, AIST grants the users a license to execute, modify, redistribute, and use OpenRTM-aist free of charge. However, when redistributing in LGPL, it is requested that the redistributing software is done based on LGPL, including a condition in which ensures that anyone must be able to get the modified source code. Therefore, when modifying and selling OpenRTM-aist under LGPL, it is required to disclose the source code.

In many case embedded systems,it is difficult to apply software to a target without modifying the source code and it might not be good for the vendor to open the modified source code. It may be inconvenient for companies that want to commercialize the robot. In consideration of these cases, OpenRTM - aist is a dual license format so that it can take the form of licensing based on individual contract as described below.

Modification and redistribution of OpenRTM-aist based on an individual contract

As in the above cases, if you do not want to disclose the modified source code to prevent leakage of the technology in case of commercializing a robot system, you can select an individual license instead of LGPL or EPL.

It is possible to provide a non-LGPL/EPL license for you based on an individual contract when you want to modify/re-distribute OpenRTM-aist after the intellectual property division of AIST discuss with you individually. In that case, the condition like the fee for using the source code and the giving rights will be defined based on your usage, how much/what you modify the source code and your own intellectual property inclusion after discussion between you and the intellectual property division of AIST. However, since AIST is a nonprofit organization for industrial promotion, the fee might not be expensive.

license_for_rtms_en2.png
RT Middleware License

There were individual contracts to license the redistribution and the source code disclosure for RtcLink(former RTSystem Editor), RtcTemplate (former RTC Builder) and OpenRTM-aist (Java version).

OpenRTM-aist specifications

OpenRTM-aist consists of RT component framework, RT middleware, basic RT components, libraries, basic services, basic tools and so on. The RT component framework consists of the base classes for creating RT components, and all RT components are created as subclasses of the base classes. RT middleware loads RT component modules which are made based on the framework, handles the instances life cycle such as construction/destruction, registers the components to the name service, etc. OpenRTM-aist also includes libraries for user convenience, basic services like component registering/searching (currently CORBA Naming Service is used), tools like RTCbuilder which generate base code, RTSystemEditor which connects and control RT components.

At present, OpenRTM-aist supports C++, Python and Java languages. It can run on Windows, UNIX based OS, µITRON (C++ only) based OS. In addition, System Engineering Consultants Co, LTD. has released OpenRTM-aist compatible middleware: OpenRTM .NET. It can create and execute RTC in .NET environment including C# use. RTCs that are created in different languages or work on different OSs can be connected and operate together.

Interface Specification

Rreference

Constitution

OpenRTM-aist consists of the following each language version of middleware libraries and the tools.

Configuration of OpenRTM-aist

Name Summary
OpenRTM-aist (C++ version) Component framework and middleware libraries and commands for creating RT components in C++ language
OpenRTM-aist (Python version) Component framework and middleware library and commands for creating RT components in Python language
OpenRTM-aist (Java version) Component framework and middleware library and commands for creating RT components in Java language
RTCBuilder Eclipse plugin for RT component design and code generation
RTSystemEditor Eclipse plugin for RT component operation and RT system design/operation
rtshell A set of commands which can be used to control RT component and RT system

Each of these distributions is distributed under the dual licenses - individual contract and EPL.

Operating condition

OpenRTM-aist (C++ version)

Compiler gcc 3.x or higher, Visual C++ 2008, 2010, 2012, 2013, 2015, 2017, 2019
OS Linux, FreeBSD, Windows, Mac OS X, TOPPERS ASP
CPU i386, x86_64, ppc, arm
Dependent library omniORB 4.0 or higher, libuuid (Linux)

OpenRTM-aist (Python version)

Python Python 2.7, Python 3.6, Python 3.7
Dependent library omniORBpy - 2.3 or higher

OpenRTM-aist (Java version)

Java JDK 5 or higher
Dependent library Java IDL included in JDK

RTCBuilder/RTSystemEditor

Eclipse 3.4 or more
Java JDK 6 or higher
Dependent library Eclipse EMF 2.2 or higher (including SDO and XSD), Eclipse GEF 3.2 or higher (including Draw 2D)

rtcshell/rtsshell

Python Python 2.6 and higher
Dependent library omniORBpy - 2.3 or higher

RT Component architecture

RT Component Framework

RT Component Framework is a framework for creating RT Components.

To modularize the elements which are constructing a robot system, there are many types of granularity of the modularization. For example, a single function device like a motor/sensor, a compound function device like a moving cart robot, robot arm and a set of algorithm which handle various processes are considerable. A system would be built up by hierarchical integration of them. In RT middleware, the software part of the fundamental functional elements is called as "Core logic". RT component framework is a mechanism for covering the Core Logic by common interface and make the user be able to use the modules uniformly.

rtc_framework_en.png
RT Component Framework and Core Logic

Consider an example of componentized stereo vision algorithm as shown in the above figure. The program itself which implements the algorithm corresponds to the Core logic. Stereo vision component can be made by preparing RT component framework with appropriate Port's and implementing a stereo vision algorithm into the framework. The module in which Core logic is implemented based on RT component framework is called as "RT component". RT component framework hides the implementation of the common interface from the component developer and the integrator who make a system by combining the components. As a result, the component developer can focus on the implementation of the main logic and the integrator can focus on the whole system design without worrying about the implementation details of the component.

RT Component architecture

In RT system, various levels of processing should be handled with considering the cooperation of them from low-level sensor process and actuator control to high-level Recognition, Judgement, Controlling the behavior, etc. In low-level controlling program might require the speed and the real-time capability. However, the high-level program might require computer language which has high abstraction capability and high descriptive power. Also, the use of multiple CPU system is currently increasing in RT system world, and it is necessary to have parallel control and cooperation function via the network.

To modularize these functional elements, the RT component provides a framework based on a distributed component technology that can be modularized with various granularity and operate on various languages and OS.

The figure shows the basic architecture of RTC. The main functions of RTC are as follows.

rtc_architecture_en.png
RT Component architecture

Get meta information

RTC has interfaces (introspection function) for obtaining meta information (RTC profile). RTC profile is a set of information that describes the characteristics of a component, such as the name of the component and the profile of Port's it owns. This function is necessary for dynamic system configuration at run time.

Introspection: A mechanism to acquire meta information of objects and components translated to "NAISEI" in Japanese. The definitions are not commonly fixed, but the function is similar to Reflection in Java. OMG RTC specification defines the function as "Introspection".

rtc_arch_introspection_en.png
Get meta information

Activity

Execution itself to implement major functions into a component. Common states such as Inactive (OFF state), Active (ON state), Error (Error state), etc are defined for unified management of RTC. An RTC developer creates an RTC by mainly implementing the desired feature into the function (callback function) assigned to each state and each state transition event.

rtc_arch_activity_en.png
activity and execution context

Execution Context

The functions which construct "Activity" are executed by a thread called Execution Context (EC). EC can be attached and detached dynamically to RTC. It is possible to attach one EC to multiple RTCs to execute them synchronously in series. Also, it is possible to make RTC execution real-time by changing the EC to real-time capable EC,

Data port

A data directional port for transmitting and receiving continuous data. There are two types of input port (InPort) and output port (OutPort). Even if the same data types are used, even if the language and OS are different, you can connect and communicate via the network.

rtc_arch_dataport_en.png
Data port

Service port

Ports which is used for providing functions and using external functions in command-base. It is used-defined. There are two types of interface - Provider (Provided interface) and Consumer (Required interface). The Provided interface provides functions to external units. Required interface is for requesting/using the function on external units. Like Data port, even if the language and OS are different, you can connect and call the function if the interface type is the same.

rtc_arch_serviceport_en.png
Service port

Configuration

A function to change the user-defined parameters externally at runtime. It has multiple sets of the parameters and you can swap them all at once. By making the parameters changeable, RTC can be reused in various systems.

rtc_arch_configuration_en.png
Configuration

Generally, in the low-level part of the RT system like the servo controller, etc. are mainly composed by data-oriented tightly coupled subsystems. In high-level part like subsystems which judges and decides the behavior would be mainly coarse-grained and service-oriented. Since RTC realizes such modularization with various granularity with a common framework, the coupling between hierarchies which becomes a problem in the hierarchical other frameworks is not a problem.

The transparent linkage between RTCs in different languages is realized by using CORBA (Common Object Request Broker Architecture) which is the standard specification of distributed object middleware.

Flow of RTC development

// Title: Flow of RTC development

This section explains how to develop RT-Components using RT-Middleware (OpenRTM-aist).

Development flow

OpenRTM-aist consists of a framework for componentization and middleware for managing/executing components.

OpenRTM-aist provides a framework for an easy way for the user (component developer) to convert existing user-owned software assets and newly developed software to RTC. A rough flow of component creation is as follows.

rtc_devel_flow_en.png
RTC and RT system development flow

As mentioned above, the code related to the common interface of the RT component, the processing of exchanging data with other components, etc. are hidden by the RT component framework. Since these processes are common, many portions of an RTC can be created as libraries or automatically generated. OpenRTM-aist provides RTCBuilder as a tool for generating an RTC base code.

RTC developers build RT-Components by incorporating existing programs developed by themselves into the component framework and build robot systems by combining multiple RTCs. Once you make RTCs by using existing software resources as software parts, you can reuse them in many situations. Also, a created RTC can be put on a network node and can be used from other network nodes.

RTC created according to the RTC framework can roughly be divided into two types - Standalone RTC (Standalone RT-Component) and Loadable module RTC (Loadable Module RT-Component). Standalone RTC is an executable binary file. Loadable module RTC is a dynamically loadable binary file and used for the case where multiple RTCs are executed at the same time in a single process.

Creating model code with RTCBuilder

RTCBuilder is a development tool that automatically generates a base code of RT component. Most of the code other than the core logic is generated automatically by entering information on the basic profile and information about the data port, the service port, and the configuration. Supporting languages are C ++, Java, Python, and Lua. Before creating the component, we decide the following things.

  • Profile (name, category name, version etc.)
  • Data port (InPort/OutPort, port name, data type)
  • Service port (port name, service interface)
  • Configuration (variable name, variable type)

Open a dialogue by selecting [File]> [New]> [Other] from the Eclipse menu. Then, select "RTCBuilder" from "Others" in the tree pane and then click Next". Enter the project name and click [Finish]. The following figure screen is displayed, RTCBuilder has tab pages - "Basic", "Activity", "Data Ports", "Service Ports", "Configuration", "Documentation", "Language and Environment" and "RTC.xml". Fill in the items as needed on the page tabbed from "Basic" to "Language and Environment", finally click the "Code Generation" button on the "Basic" tab page to generate the base code. The generated code is saved under the folder of the project name in the workspace specified when Eclipse is started.

rtcbuilder_en.png
RTCBuilder development screen

Implementation of RTC

Unlike ordinary programmings, RT component programming do not directly implement processes in the main function. I will describe an RTC implementation example of a C ++ case.

An RT component is implemented as a class that inherits a base class. In the RT component, the processing performed by the core logic is programmed by overriding the member function (method) of the base class. For example, the processing to be performed at the initialization time is programmed in onInitialize function, the periodically executing process at an active time is programmed in onExecute function.

 class MyComponent
  : public DataflowComponentBase
 {
 public:
   // What we want to execute at initialization
   virtual ReturnCode_t onInitialize()
   {
     if (mylogic.init())
       return RTC::RTC_OK;
     return RTC::RTC_ERROR;
   }
 
   // Process to be executed periodically
   virtual ReturnCode_t onExecute(RTC::UniqueId ec_id)
   {
     if (mylogic.do_someting())
       return RTC::RTC_OK;
     RTC::RTC_ERROR;
   }
 
 private:
   MyLogic mylogic;
   // Declaration of port etc.
   //   :
 };

The above is a C++ implementation example. In this example, the class declaration and the implementation are written in a program. But in actual, the generated source codes are separated into a header file (.h) and an implementation file (.cpp). The object mylogic of the MyLogic class is an instance of the class in which the core logic is implemented. In the example, RTC is implemented by calling the mylogic member function very simply, even in the actual implementation, it is recommended to implement the core logic in a class which can be used easily in such a manner in advance, Also, it is recommended that the number of calls in the call back function is minimum.

RTCBuilder also generates several files (Makefile/Project file) at the same time as the base code generation. By compiling/building process with using the files, an executable file or a shared object (or DLL) file is generated.

RTC life cycle

As described in the above, in the implementation of the RTC, a component is created by programming the required process in a predetermined function (callback function). To know what kind of function is called and at what timing it is called, it is necessary to understand the state transition of RTC, that is, life cycle. The figure below shows the RTC state transition diagram.

rtc_state_machine_en.png
RTC Life Cycle (UML State Machine Diagram)

A component has the following states.

  • Created state (Created)
  • Alive state (Alive)
    • Inactive state (Inactive)
    • Active state (Active)
    • Error state (Error)
  • Exit state

At each of these states and transitions, a predetermined function (callback function) is called by an EC. The table shows the callback functions and the timing when each is called.

Function name Overview
onInitialize Called only once at the life cycle initialization.
onActivated Called once when activated.
onDeactivated Called once when deactivated.
onExecute Called periodically in active state.
onStateUpdate Called after every onExecute.
onAborting Called once when enter to the error state.
onError Called periodically when in error state.
onReset Called once when returning from error state.
onShutdown Called once when EC driving stops.
onStartup Called once when EC driving starts.
onFinalize Called only once at the end of the life cycle.

Flow of RT system development

In this section, we will explain how to build a system by combining multiple RTCs created.

Name Service

Distributed Object Middleware provides transparent access via proxy objects that hold References to objects on the computer at some locations. The reference is called IOR (Interoperable Object Reference) in CORBA, and the actual entity is a character string that encodes the IP address, port number, and object-specific key of the computer where the object exists. One way for a program on another computer to know the IOR of an object is to register the IOR on a server on the network. The service that registers and obtains this reference is the Name Service. The name service is one of the standard services defined in CORBA standards, and it is provided as a wrapper command rtm-naming in OpenRTM-aist.

Before starting up your RT systems, you need to start the name server for registering RTCs. Also, for each RTC, it is necessary to give the name server location in advance in the configuration file rtc.conf'. For example, if you start a name server on the hostname openrtm.mydomain.net'', you need to provide rtc.conf which has the following line for all the RTCs.

 corba.nameservers: openrtm.mydomain.net

The name server can also be specified by the IP address, and by separating it with "," you can register RTC to multiple servers at the same time. Normally, it is not necessary to frequently rewrite the configuration file, since the name server is usually be kept running for a long time and it is a fixed item in the system.

System construction with RTSystemEditor

The system runs by running some created RTCs, connecting and activating those ports. RTSystemEditor is provided as a tool for connecting RTCs, sending activation and deactivation commands to the RTCs, and starting up the system.

rtse_en.png
System construction with RTSystemEditor

When RTC is started, it is displayed in the name service view on the left pane. When RTCs are on the name service view, RTCs can be dragged and dropped to the central editor area. The dropped RTC is displayed as an icon in the system editor. The protrusion on the side of the rectangle represents the port and the system is constructed by connecting the ports between the RTCs. Also, the RTC configuration view is displayed at the lower center of the screen, so you can edit the parameters of the RTC.

After building the system, it is possible to activate all the RTC by right-clicking on the editor and selecting All Activate. You can also save the system configuration information by right-clicking on the editor and selecting Save as. By saving the system configuration information again, it is possible to restore system connection information, configuration information and so on.

Currently, it is necessary to start up RTC beforehand when restoring the system configuration information, but in the future it will be possible to restore all elements from RTC startup to connection restoration.

Research and Development

History of development

The concept of RT-Middleware was proposed at the 21st-century Robot challenge program (2002-2004 fiscal year) bu New Energy and Industrial Technology Development Organization (NEDO). National Institute of Advanced Industrial Science and Technology (AIST), Matsushita Electric Works (now Life Solutions Company in Panasonic Cooperation), and Japan Robot Association (JARA) conducted the research, the development, and the standardization.

As a result of the project, a reference implementation of RT-Middleware: OpenRTM-aist-0.2 and its interface specification were released. After that, standardization of the RTC interface specification was being made in an international standards organization: OMG (Object Management Group: http://www.omg.org), and became OMG official standard specification in April 2008. One of RT-Middleware implementations conforming to the standard is OpenRTM-aist-1.0 released in January 2010.

The figure shows the current research/development/standardization system.

rtm_randd_en.png
OpenRTM-aist research/development/standardization system

Research and development for RT-Middleware started as the RT-Middleware project in 2002 and then it was continued as various projects (the following figure) including NEDO's daily life support robot realizing project.

rtm_projects_en.png
Various projects related to OpenRTM-aist

The following shows the overview of our major projects so far.

RT Middleware related project

RT middleware project

"Development for required underlying technology for Robot function discovery" project (common name: RT middleware project) is conducted in the 21st Century Robot Challenge Program by New Energy and Industrial Technology Development Organization (NEDO). In this project, the research and the development of Distributed Middleware for robots (RT middleware) were conducted. As a result, a middleware interface specification was developed, and an implementation based on the specification OpenRTM-aist-0.2.0 was released.

Distributed component type robot simulator

The purpose of the project, which was carried out from 2005 to 2007 fiscal year by using the Special Coordination Funds for Promoting Science and Technology, was developing a more effective way to develop next-generation robots by developing a distributed component framework which enables to increase software property for robot and a robot simulator made on the framework.

openhrp_openrtm_en.png
Distributed Component based Robot Simulator

As a result of the project, we integrated OpenRTM-aist and OpenHRP3 which is a robot dynamics simulator. Those were developed separately at AIST.

We developed a target system in the simulator, external controller module, etc as RT components. And we enhanced Execution Context function which is the main logic driving entity of RT component to be usable without the re-compilation of the controller components both on the real system and the simulator.

Next-generation Robot Intelligent RT Software Project

"Next-Generation Robot Intelligent RT Software Project" (2007 - 2011 fiscal year) by the Ministry of Economy, Trade and Industry and NEDO is a large-scale project that cost a totally of 7 billion yen (forecast) over 5 years. The purpose of the project was making methodology to design/implementation of the next-generation robot and accumulating RT components which can be used in an actual robot system. The components would be developed through the discussion about the re-use method, interface unifying.

Also, a platform called "OpenRTP" was constructed on OpenRTM-aist. The platform is including various tools which can be used in the various development phase for a robot system, a middleware, libraries. The tools were implemented as Eclipse plug-in and it is a toolchain that can allow the user to do a series of work in a single development environment.

openrtp_en.png
OpenRT platform (OpenRTP)

Data between the tools are written with the format which is defined based on the module and system specification description method (defined by UML model and XML schema). This provides better co-working between tools. We also considering to standardize it in the future. Also, we are considering to make the big collection of RT components and the tools open-source and do business with them.

Open Innovation Promotion Project

Fundamental Robot Technology-based Open Innovation Promotion Project were funded by NEDO for 3 years from 2008. In the project, to make existing elementally function parts to RT components, the development of cheap and compact base communication module was targeted. Also using the base communication module, an intelligent house in which various sensors and actuators are installed on various parts of the house and the devices are co-worked were built as a POC system.

Other

We are also doing OpenRTM-aist research/development/promotion activity other than the projects.

Training session

In The Robotics and Mechatronics Conference (by the Japan Society of Mechanical Engineers) we are holding a lecture yearly base as a tutorial session. Also, several workshop style lectures are being held in various place in indeterminate matter.

RTM Contest

The Robot Business Promotion Council is holding RT-Middleware contest as an event in SICE system integration division conference. In the contest, competitions of RT-Middleware based products are being performed.