WO2014061516A1

WO2014061516A1 - Method and device for generation of conversion module linking between different robot middleware types

Info

Publication number: WO2014061516A1
Application number: PCT/JP2013/077419
Authority: WO
Inventors: 慧岡田; 斎藤　学; 雅幸稲葉
Original assignee: 国立大学法人東京大学
Priority date: 2012-10-19
Filing date: 2013-10-09
Publication date: 2014-04-24
Also published as: JP2014085732A

Abstract

Provided are a method and a device for automatically generating a bridge module of middleware whereof interoperability is desired. The method comprises: a step of analyzing a first interface definition of a first type of robot function element module, and generating a second interface definition of a second type of robot function element module and inter-middleware conversion source code; and a step of generating a conversion module, using the second interface definition and the source code.

Description

Method and apparatus for generating conversion module for linking different types of robot middleware

The present invention virtualizes a program running on one middleware for interoperating robot middleware of different standards so that it can be controlled and communicated on another middleware. The present invention relates to a technique for generating a conversion module called a bridge for converting information.

Traditionally, in the robot research field, although an open source OS and development environment have been utilized, the intelligent information processing module that is the core of the research has never been open. In the field, open source software is expanding rapidly, especially overseas. Known open source projects for robots include ROS (Robot Operating System) developed by Willow Garage in the United States, projects such as Orocos and iCub / Yarp in Europe, and OpenRTM projects in Japan. Provides middleware.

Such robot middleware is a technology for componentizing robot components (actuators and sensors) and robot control software as functional component modules. Simply combine the functional component modules according to the application. Various robots can be developed. For example, in OpenRTM-aist, an OpenRTM project, when creating a robot system, a program is created for each functional element module (RTC: RT component) and the robot system is constructed by connecting RT components.

As described above, since there are multiple robot middlewares with different standards, there has been a tendency that development has been progressed independently for each robot middleware, and there have been few attempts to link these. . When these different types of robot middleware are to be linked, a so-called bridge module must be developed manually, and when the middleware is upgraded or the function of the target program is updated or changed, the bridge The module did not work, and it was necessary to re-develop it again by manpower.

If the generation of bridge modules can be done automatically, not only will it be possible to work manually, but it will not only lead to efficiency, but it will also be able to respond quickly to middleware and program updates and changes, but the methodology for that is clear. There wasn't. The patent document discloses a method for generating an RT component for data relay, but corresponds to a mismatch between middleware components of the same standard.
JP2011-86182A

The present invention provides a bridge module automatic generation method and apparatus based on analysis of middleware to be interoperated.

The technical means adopted by the present invention are:
Method for automatically generating a conversion module for linking between a first middleware having a set of first-type robot functional element modules and a second middleware having a set of second-type robot functional element modules Because
Analyzing a first interface definition of a first type robot functional element module to generate a second interface definition of a second type robot functional element module and an inter-middleware conversion source code;
Using the second interface definition and the source code to generate a conversion module;
Automatic generation method with
Apparatus for automatically generating a conversion module for linking between first middleware having a set of first type robot functional element modules and second middleware having a set of second type robot functional element modules Because
Means for analyzing a first interface definition of a first type robot functional element module and generating a second interface definition of a second type robot functional element module and an inter-middleware conversion source code;
Means for generating a conversion module using the second interface definition and the source code;
Is an automatic generation device.
The present invention is realized by cooperation between a computer (including an input unit, an output unit, a calculation unit, a storage unit, a display unit, etc.) as hardware and software that causes the computer to execute a predetermined function. Files or programs are stored in a storage unit of one or more computers.
The present invention relates to a conversion module that cooperates between a first middleware having a set of robot function element modules of a first type and a second middleware having a set of robot function element modules of a second type. Is automatically realized as a computer program for causing a computer to function as a predetermined means.

In one aspect, generating the conversion module comprises:
The source code;
Source code generated from the first interface definition;
Source code generated from the second interface definition;
Is used to generate a conversion module.
The interface definition file is defined for each middleware, and is an IDL file in OpenRTM, and a message file and a service file in ROS. It is understood by those skilled in the art that other middleware also has interface definition files corresponding to these, and can be processed using these.
The “source code generated from the first interface definition” is “message file / service file generated by ROS compiler (ROS message service compiler) .py” in the flowchart (ROS → RTM) shown in FIG. 1A. In the flowchart (RTM → ROS) shown in FIG. 1B, “IDL is processed by an IDL compiler. Cpp, .h”.
The “source code generated from the second interface definition” is “IDL message generated by IDL compiler .py” in the flowchart (ROS → RTM) shown in FIG. 1A, and the flowchart (RTM → ROS shown in FIG. 1B). ) “Cpp, .h generated by processing a message file / service file with a ROS compiler (ROS message service compiler)”.

In one aspect, the input / output of the first type robot functional element module is defined by the first interface definition before executing the program of the first type robot functional element module, and the analysis Performed before program execution.
This is a so-called offline conversion method, in which a first interface definition file (for example, component IDL file) of a robot function element module is analyzed, and a corresponding second interface definition file (node message file, service file) is obtained therefrom. This is a method for generating the source code of the bridge module.

In one aspect, the first middleware is OpenRTM (Open Robot Middleware), the first type robot functional element module is an OpenRTM component, and the first interface definition is an IDL file.
In one aspect, the second middleware is ROS (Robot Operating System), the second type robot functional element module is a node of ROS, and the second interface definition file is a message file or a service file. is there.
In this case, a bridge module that provides the ROS node program is generated from the OpenRTM component program.
In a more specific aspect, the first type robot functional element module is a component of OpenRTM, the second type robot functional element module is a node of ROS,
Analyzing the component IDL file to generate a node message file or / and a service file and source code;
Generating a source code of the IDL file by an IDL compiler;
Generating a source code of the message file or / and the service file by a ROS compiler,
A conversion module is generated using the three source codes.

In one aspect, the input / output of the first type robot functional element module is specified when the program of the first type robot functional element module is executed, and the analysis is performed when the program is executed. Done.
In one aspect, a first interface definition file (e.g., message file, service) that is a so-called online conversion method and that defines input / output of a first type robot function element module (e.g., node program) that is running. File) and a corresponding second interface definition file (for example, IDL file) and a source code of the bridge module are generated.

In one aspect, the first middleware is a ROS (Robot Operating System), the first type robot functional element module is a ROS node, and the input / output is a message of the topic of the node being executed. It is obtained by analyzing a file or / and a service file of a service.
In one aspect, the second middleware is OpenRTM (Open Robot Middleware), the second type robot function element module is an OpenRTM component, and the second interface definition file is an IDL file.
In this case, a bridge module that provides an OpenRTM component program corresponding to the ROS node program is generated.
In a more specific aspect, the first type robot functional element module is a ROS node, and the second type robot functional element module is an OpenRTM component,
Analyzing the message file or / and service file of the node to generate a component IDL file and source code;
Generating a source code of the message file or / and the service file by a ROS compiler;
Generating a source code of the generated IDL file by an IDL compiler,
A conversion module is generated using the three source codes.

According to the present invention, it is possible to automatically generate a bridge module, which does not require any single-handed work, leading to efficiency, but also being able to quickly respond to middleware and program updates and changes.

It is a conceptual diagram of the bridge module which concerns on this embodiment. 5 shows a flowchart for generating a bridge module that provides an OpenRTM component program corresponding to a ROS node program. 5 shows a flowchart for generating a bridge module that provides a ROS node program from an OpenRTM component program. It is a diagram showing RT component architecture (quoted from http://www.openrtm.org/openrtm/ja/content/openrtm-aist-official-website). It is a figure which shows the concept of a node (cited from http://www.ros.org/wiki/). Indicates the navigation node of ROS. The central ellipse is a node, and a plurality of rectangles around the node indicate topics. From the topic to the node is input (subscribe), and from the node to the topic is output (publish). Shows an RTM component that provides automatically generated ROS navigation capabilities. The central vertical rectangle is the component, with the input port on the left and the output port on the right. Shows how OpenRTM component bridges are automatically generated from ROS nodes. Shows how ROS nodes are automatically generated from OpenRTM components. An example of ROS node information is shown. An example of ROS node information is shown. An example of ROS node information is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of IDL automatically generated by the automatic conversion program is shown below. An example of IDL automatically generated by the automatic conversion program is shown below. An example of a program that generates two files of the source code (main) and IDL and creates an OpenRTM node using these two files is shown. An example of a program that generates two files of the source code (main) and IDL and creates an OpenRTM node using these two files is shown. An example of a program that generates two files of the source code (main) and IDL and creates an OpenRTM node using these two files is shown. An example of a program that generates two files of the source code (main) and IDL and creates an OpenRTM node using these two files is shown. An example of a program that generates two files of the source code (main) and IDL and creates an OpenRTM node using these two files is shown. An example of a program that generates two files of the source code (main) and IDL and creates an OpenRTM node using these two files is shown. An example of a program that generates two files of the source code (main) and IDL and creates an OpenRTM node using these two files is shown. Here is an example of OpenRTM IDL. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a program automatically generated by an automatic conversion program (main body part of a different middleware conversion source code) is shown. An example of a service file automatically generated by an automatic conversion program is shown. An example of a service file automatically generated by an automatic conversion program is shown. An example of a service file automatically generated by an automatic conversion program is shown. An example of a service file automatically generated by an automatic conversion program is shown. An example of a service file automatically generated by an automatic conversion program is shown. An example of a message file automatically generated by the automatic conversion program is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown. An example of an automatic conversion program for generating the source code (main) and a message file / service file is shown.

[A] Robot middleware Robot middleware is a software platform for constructing a robot system by combining a plurality of software modules of robot functional elements. As robot middleware, ROS (Robot Operating System) developed by Willow Garage in the US, projects such as Orocos and iCub / Yarp in Europe, and OpenRTM projects in Japan are known. There are also middleware developed by companies. Here, the present embodiment will be described by taking ROS and OpenRTM-aist as an example, but it will be understood by those skilled in the art that middleware to which the present invention is applied is not limited to ROS and OpenRTM-aist.

[A-1] ROS (Robot Operating System)
For more information on ROS, you can refer to http://www.ros.org/wiki/. Here, some terms related to ROS necessary for understanding the present embodiment will be described. The following description includes a description based on the translation of the description on the website.

[Package]
A package is a set of folders or development files containing software that provides a set of functions. The package is the main unit in ROS, and ROS software is organized in the package. The package contains ROS runtime processes (nodes), ROS dependent libraries, datasets, configuration files, and other files that can be usefully organized.

[Node]
A node is a process that performs computation, and is an executable file that can communicate with other nodes using ROS. A node is a functional unit of software, that is, a robot functional element module. The robot control system is composed of many nodes.

[Msg files]
Message is a ROS data type used when subscribing or publishing a topic. Nodes communicate with each other by passing this message. A message is a simple data structure that contains typed fields. The data structure of the message is specified by a message file that is a simple text file. The message file is a simple text file with a field type and a field name per line. Field types include "int8, int16, int32, int64 (plus uint *)", "float32, float64", "string", "time, duration", "other msg files", "variable-length
array [] and fixed-length array [C] ". Message files are used to generate source code for messages in different languages. The message file is stored in the message directory of the package. Message (msg) types (message type) is a message description stored in the package, and defines the data structure of the message transmitted in the ROS.

[Srv files (service file)]
A service is defined using a service file, and the service file is compiled into source code by the ROS client library. A service file describes a service and consists of two parts, a request and a response. A service file is similar to a message file except that it contains two, a request and a response. Examples of service files are “int64 A”, “int64 B”, “int64
Sum ". A and B are requests, and Sum is a response. The service file is stored in the package service directory. Service (srv) types is a service description stored in a package, and defines a request data request and response data structure in the ROS.

[Topic]
In ROS, data transmission / reception is performed using topics. A topic is a named bus through which nodes exchange messages. Nodes send messages by publishing the message to a given topic. The topic is a name that identifies the content of the message. Subscribers interested in certain data subscribe to the appropriate topic. A publisher is a side that provides data, and a subscriber is a side that receives data. There can be multiple publishers and subscribers simultaneously for a topic. A node may also publish and / or subscribe to multiple topics. In general, publishers and subscribers are unaware of each other's existence. Logically, topics can be viewed as a strongly typed message bus. Each bus has a name, and anyone can connect to the bus and send and receive messages (with a predetermined type). The node accesses the required topic and receives data. The topic is intended for one-way streaming communication, and the node that receives the response to the request uses the service.

Sample code for Publisher Node (extracted from the above website)

pub = rospy.Publisher ("chatter", String) declares that this node publishes to the chatter topic using the message type String.

Example code for Subscriber Node (extracted from the above website)

rospy.Subscriber ("chatter", String, callback) declares that this node subscribes to the chatter topic of message type String.

[Service]
The service is used when receiving a response to a certain operation (execution of a request / response) instead of sending and receiving data. A service is defined by a pair of messages, a request and a reply. The provided ROS node provides a service under the name, and the client calls the service by sending a request message and waits for a response. A service is similar to a function call or remote procedure call.

Service Node code example (extracted from the above website)

Client Node code example (extracted from the above website)

[A-2] OpenRTM-aist
For details of OpenRTM-aist, you can refer to http://www.openrtm.org/openrtm/en/content/openrtm-aist-official-website. Here, some terms related to OpenRTM-aist necessary for understanding the present embodiment will be described. The following description includes the use of the description of the website.

[RT component (RTC)]
In OpenRTM-aist, the robot function elements that are made into software modules are called RT components (RT-Component: RTC). The RT component has an interface called a port for exchanging data and communicating with other RT components. When creating a robot system, a program is created for each functional element (RT component), and the system is constructed by connecting RT components. The RT system is constructed as a collection of RT component functions by connecting a plurality of RT component ports (endpoints for data communication). RTC developers embed their own control algorithm code and existing library code (called core logic) in the RTC template code that is automatically generated by tools such as RTCBuilder and compile it (in script languages) RTC can be created.

[Data port]
The data port is a port for mainly transmitting / receiving continuous data between RTCs, a data port (OutPort) for transmitting data to other RTCs, and a data port for receiving data from other RTCs ( InPort). One RTC has any number of data ports as required. For example, when creating a component that acquires data from a sensor, this component requires an OutPort to output at least one sensor data. Alternatively, when creating a component that drives a motor according to a specified torque value, this component requires an InPort that receives at least one torque value command. When creating a controller component for feedback control using these components, InPort that receives sensor data, InPort that receives command values (for example, speed command), and OutPort that outputs torque values Each of these is required. Each data port has a specific type, and the definition of the data port type is defined by a language-independent interface definition language called IDL (Interface Definition Language). The same data type can be connected and communicated via the network even if the language and OS are different.

[Service Port]
In order to construct a robot system, in addition to data communication between components, communication between components at a command level (or function level) is required. For example, in the case of a manipulator component that controls a robot arm, the position and speed of the hand are data to be sent from a host application or component through a data port. On the other hand, functions such as setCoordinationSystem (), setParameter (), setMode (), etc. are prepared for the manipulator object for various settings of the robot arm, coordinate system, control parameter, operation mode, etc. These functions are called at an appropriate timing as necessary. The service port provides a mechanism for such exchange between command level components. Generally, a service is a group of commands (also called functions, methods, operations, etc.) that are functionally related. In OpenRTM-aist, the side that provides this function is the service provider, The side that uses the function is called a service consumer. RT components can have any number of service ports as well as data ports. Also, any type and number of providers or consumers can be added to the service port. A provider and a consumer are collectively referred to as an interface or a service interface, and a port having these service interfaces is referred to as a service port. As with data ports, even if the language and OS are different, if the interface type is the same, you can connect and call functions. “Same type” means having the same interface definition.

[Interface definition]
In OpenRTM-aist, the interface is defined by the CORBA interface definition language called IDL. IDL provides a language-independent interface definition method, and by using an IDL compiler, codes (stubs and skeletons) corresponding to various languages are automatically generated. A stub is a code for a proxy object for calling a remote object, and a skeleton is a base code for implementing a provider. With these automatically generated codes, calling between different languages can be performed seamlessly. For example, a provider implemented in C ++ can be easily called with Python or Java.

The following is the IDL definition used in the OpenRTM-aist sample (extracted from the above website).

module is equivalent to a C ++ namespace, which prevents interface name collisions. There is a typedef keyword as well as C language. In the above example, sequence (dynamic array type) is defined. One defines an EchoList type as a string (string type) type list, and the other defines a ValueList type as a float type list. Next, the part that starts with interface is the actual interface definition. Five functions (operations) are defined in the MyService interface. Although it is a definition similar to C language or Java, IDL adds an in, out or inout modifier before the argument declaration to clarify whether the argument is input or output.

[IDL compilation]
Compiling with the IDL defined to the IDL compiler usually generates code for stubs and skeletons (sometimes called servers and clients). A client, that is, a service user uses a proxy (proxy) object defined as a stub by using stub code inclusion or the like to access a remote server function. Defining and compiling IDL automatically generates most of the code needed to define and use distributed objects. Since the IDL definition method itself can be relatively easily defined by those skilled in the art working on C language and Java, detailed description thereof is omitted.

[B] Conversion module for linking different types of robot middleware To enable control and communication of programs running on one middleware for interoperating robot middleware with different standards from another middleware Therefore, a conversion module called a bridge that virtualizes the program itself and converts information is generated. If the bridge module can be automatically generated, it is possible not only to work by one person at a time, but also to improve efficiency, and to quickly respond to middleware and program updates and changes.

A “bridge” is a device (including software) that exchanges information between two systems and structural units. Such a bridge module is obtained by the cooperation of a computer (including an input unit, an output unit, a calculation unit, a storage unit, a display unit, etc.) as hardware and software that causes the computer to execute a predetermined function. Realized.

In the present embodiment, a method for automatically generating a bridge module based on analysis of middleware to be interoperated is provided. It shows that automatic conversion of robot functional element module can be solved by two methods of online method and offline method. When middleware with clear input / output of program is static (before program execution), online method is not. Adopts the offline method. As an automatic generation of the bridge module, online conversion method and offline conversion method, specifically, the online conversion method to check the input / output of the running program and generate the interface definition file and program corresponding to this, We propose an offline conversion method that generates a corresponding program from the analysis of the interface definition file. Both methods generate “interface definition file (broad definition)” and “source code” to realize a bridge module. Conventionally, the specific procedure for this has not been clarified, but in this embodiment, it is shown that there are two methods of automatic generation of the bridge module, online and offline, which is determined by analysis of the target middleware. Proceed with the procedure of whether to adopt the method.

[B-1] OpenRTM-ROS automatic interoperability system
If a bridge component or bridge module that automatically converts information between ROS and OpenRTM can be generated from the ROS node program, the ROS node program can be easily used from OpenRTM, and the specification of the future ROS node program. Even if there is a change in, the bridge component can be used continuously without having to deal explicitly with OpenRTM.

Comparing OpenRTM and ROS, the middleware component unit (robot function element module) is that the former is an RT component, the latter is a node, and the RT component and node correspond. OpenRTM provides a "service port" and a "data port". The data port is a port for transmitting and receiving data. A service port is considered to be a mechanism that allows a specific function to be executed remotely as well as data transmission and reception. In response to a service request, the success / failure result can be returned. ROS provides “topics” and “services”. A topic is intended for one-way streaming communication, and a message file that describes a message that specifies the content of the topic is used to generate source code for messages in different languages. A node that executes reception of a response to a request uses a service. A service file for specifying the contents of a service consists of two requests and a response, and is stored in the service directory of the package. OpenRTM data port and ROS topic, OpenRTM service port and ROS service are the same in the sense that the former is one-way data flow (data transmission / reception) and the latter sends data and receives the result (function call) It is functioning.

By analyzing the IDL file corresponding to the component, the OpenRTM component program knows what data port port and / or service port the component provides. On the other hand, unless the ROS program analyzes the contents of the program, it does not know what input / output the program has. More specifically, it is necessary to analyze the input / output topics and service types of the operating ROS module and the types of message files (topics) and service files (services) exchanged there. . ROS message files can be defined as data types in IDL, and ROS service files correspond to IDL function calls.

We developed a tool that generates an OpenRTM component program from an ROS node program using an online conversion method, and a tool that generates an ROS node program from an OpenRTM component program using an offline conversion method.

[B-2] Online Conversion Method The online conversion method is a method for checking input / output of a running node program and generating a corresponding idl file and bridge module source code.

The online conversion method is an effective method for a system in which the input / output of the program of the robot functional element module of the robot middleware system is not clear until the program is executed. For example, in the ROS node program, the message interface definition file defines the input and output of data, but it is not specified which node program provides it, so the OpenRTM corresponding to the ROS node program is not specified. When generating a bridge module that provides a component program, an online conversion method is appropriate.

FIG. 1A shows a flowchart for generating a bridge module that provides an OpenRTM component program corresponding to a ROS node program.
Examples of conversion from ROS to OpenRTM are shown in FIGS. 5A to 8G.
FIG. 5A to FIG. 5C (rosnode.info.txt) illustrate ROS node information.
6A to 6H (rosbridge_idl.py) are source codes that are automatically generated using the automatic conversion program according to the present embodiment.
7A and 7B are (rosbridge.idl) IDL files that are automatically generated using the automatic conversion program according to the present embodiment.
8A to 8G (rtmros-data-bridge.py) generates the above two files (source code and IDL file) and uses these files to create an OpenRTM node (so to speak, Conversion program execution control source code). The bridge module is generated by an automatic conversion program.
Furthermore, it demonstrates with reference to FIG. 1A.
(1) By analyzing and processing the ROS node msg, srv (msg file, srv file) with the automatic conversion program (FIGS. 8A to 8G), the “IDL file (FIGS. 7A, 7B)” and “Main” Source code (FIGS. 6A-6H) ”is generated simultaneously. The main source code (Python file in the present embodiment) is a different middleware conversion source code (the main part), which is a middleware conversion core source code.
(2) By processing the msg and srv files of the ROS node with a known ROS compiler, an interface source file (Python file) is generated.
(3) By processing the “IDL file” generated in (1) with a known IDL compiler, a source code (Python file) of the “IDL file” is generated.
(4) The above three source codes are processed using an automatic conversion program (FIGS. 8A to 8G) to generate a bridge program.

FIG. 3A shows a navigation node of ROS. The central ellipse is a node, and a plurality of rectangles around the node indicate topics. From the topic to the node is input (subscribe), and from the node to the topic is output (publish). FIG. 3B shows an RTM component that provides an automatically generated ROS navigation function. The central vertical rectangle is the component, with the input port on the left and the output port on the right. In Fig. 3C, the left side is a two-dimensional navigation simulator 上 (top) where the ROS navigation tutorial is generated, and its sensor information display (bottom), and the right side is automatically generated from the navigation node of the ROS operating there. The navigation component of OpenRTM is displayed, and the ROS navigation function can be used with OpenRTM input and output.

[B-3] Offline conversion method The offline conversion method analyzes an IDL file that is a component interface definition file, generates a corresponding interface definition file (message file, service file) from the IDL file, and generates the source code of the bridge module. Is a method for generating

The offline conversion method is an effective method when the input / output of the program of the robot functional element module of the robot middleware system is specified in the interface definition file. For example, an OpenRTM component program can understand what data port port and / or service port the component provides by analyzing the interface definition file corresponding to the component. An off-line conversion method is appropriate when generating a bridge module that provides a ROS node program.

A flow chart for generating a bridge module that provides a ROS node program from an OpenRTM component program is shown in FIG. 1B.
Examples of conversion from OpenRTM to ROS are shown in FIGS.
FIG. 9 (MyService.idl) illustrates an OpenRTM IDL file.
9A to 9E (MyServiceROSBridge.cpp), FIGS. 10A to 10C (MyServiceROSBridge.h), and FIGS. 11A and 11B (MyServiceROSBridgeComp.cpp) are sources automatically generated using the automatic conversion program according to the present embodiment. Indicates the code (main).
Figure 12 (SimpleService_MyService_echo.srv),
Figure 13 (SimpleService_MyService_get_echo_history.srv)
Figure 14 (SimpleService_MyService_get_value.srv),
Figure 15 (SimpleService_MyService_get_value_history.srv,
Figure 16 (SimpleService_MyService_set_value.srv),
Figure 17 (StringMultiArray.msg),
These are service files and message files that are automatically generated using the automatic conversion program according to the present embodiment.
18A to 18L (idl2srv.py) are automatic conversion programs (ie, conversion program execution control source code) that generate the above two files (source code and message file / service file) from the OpenRTM IDL file. is there.
Furthermore, it demonstrates with reference to FIG. 1B.
(1) By analyzing and processing the IDL file of the RTM component with the automatic conversion program, the "message (msg) file, service (srv) file" and "source code (Main) cpp file and h file" are simultaneously Generated. The main source code (in this embodiment, the cpp file and the h file) is a different middleware conversion source code (its main body part), that is, a middleware conversion core source code.
(2) An interface source file (cpp file and h file) is generated by processing the IDL file of the RTM component with a known IDL compiler.
(3) Source code of “message (msg) file, service (srv) file” by processing the “message (msg) file, service (srv) file” generated in (1) with a known ROS compiler (Cpp file and h file).
Some of the known processes are exemplified below.
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceSkel.h
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceSK.cc
./idl_gen/cpp/openrtm_ros_bridge/idl/MyService.hh
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceDynSK.cc
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceStub.h
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceSkel.cpp
./idl_gen/cpp/openrtm_ros_bridge/idl/MyServiceStub.cpp
(4) The bridge program is generated by processing the three source codes using a known C ++ compiler.

In Fig. 4, the left figure is a humanoid simulation by OpenRTM, and the right figure shows the ROS node automatically generated from the input / output interface definition file of the OpenRTM component that is running there. The humanoid simulation function of OpenRTM can be used.

Those skilled in the art will understand that matters that can be read by those skilled in the art from the code attached to the specification or the code attached as a drawing can be treated as matters described in the present specification and drawings.

Numerous standards for robot middleware currently exist, and companies that have traditionally studied robots have similar systems in-house. On the other hand, each middleware has a useful application, and when you want to use it, you have to re-implement the application on another middleware or develop a bridge module between middleware individually. is the current situation. If this invention is utilized, since these can be produced | generated automatically, significant labor saving is attained.

Claims

Method for automatically generating a conversion module for linking between a first middleware having a set of first-type robot functional element modules and a second middleware having a set of second-type robot functional element modules Because
Analyzing a first interface definition of a first type robot functional element module to generate a second interface definition of a second type robot functional element module and an inter-middleware conversion source code;
Using the second interface definition and the source code to generate a conversion module;
Automatic generation method with
The step of generating the conversion module includes:
The source code;
Source code generated from the first interface definition;
Source code generated from the second interface definition;
The method according to claim 1, wherein the conversion module is generated using.
The input / output of the first type robot functional element module is defined by the first interface definition before the execution of the program of the first type robot functional element module, and the analysis is performed before the execution of the program. The method according to claim 1 or 2, wherein:
The first middleware is OpenRTM (Open Robot Middleware), the first type robot function element module is a component of OpenRTM, and the first interface definition is an IDL file. 2. The method according to item 1.
The second middleware is ROS (Robot Operating System), the second type robot functional element module is a node of ROS, and the second interface definition is a message file or a service file. 4. The method according to any one of 4 above.
The first type of robot functional element module is a component of OpenRTM, the second type of robot functional element module is a node of ROS,
Analyzing the component IDL file to generate a node message file or / and a service file and source code;
Generating a source code of the IDL file by an IDL compiler;
Generating a source code of the message file or / and the service file by a ROS compiler,
A conversion module is generated using the three source codes.
The method of claim 5.
The input / output of the first type robot functional element module is specified when the program of the first type robot functional element module is executed, and the analysis is performed when the program is executed. The method according to 1 or 2.
The first middleware is ROS (Robot Operating System), the first type robot functional element module is a node of ROS, and the input / output is a message file or / and service of the topic of the node being executed. The method according to claim 7, wherein the method is obtained by analyzing a service file.
The second middleware is OpenRTM (Open Robot Middleware), the second type robot functional element module is a component of OpenRTM, and the second interface definition is an IDL file. the method of.
The first type robot functional element module is an ROS node, the second type robot functional element module is an OpenRTM component,
Analyzing the message file or / and service file of the node to generate a component IDL file and source code;
Generating a source code of the message file or / and the service file by a ROS compiler;
Generating a source code of the generated IDL file by an IDL compiler,
A conversion module is generated using the three source codes.
The method of claim 9.
Apparatus for automatically generating a conversion module for linking between first middleware having a set of first type robot functional element modules and second middleware having a set of second type robot functional element modules Because
Means for analyzing a first interface definition of a first type robot functional element module and generating a second interface definition of a second type robot functional element module and an inter-middleware conversion source code;
Means for generating a conversion module using the second interface definition and the source code;
Automatic generation device with
The means for generating the conversion module includes:
The source code;
Source code generated from the first interface definition;
Source code generated from the second interface definition;
12. The apparatus of claim 11, wherein the conversion module is generated using
The input / output of the first type robot functional element module is defined by the first interface definition before the execution of the program of the first type robot functional element module, and the analysis is performed before the execution of the program. 13. The device according to claim 11 or 12, wherein:
The first middleware is OpenRTM (Open Robot Middleware), the first type robot function element module is a component of OpenRTM, and the first interface definition is an IDL file. The apparatus according to item 1.
The second middleware is ROS (Robot Operating System), the second type robot functional element module is a node of ROS, and the second interface definition is a message file or a service file. 14. The apparatus according to any one of 14.
The first type of robot functional element module is a component of OpenRTM, the second type of robot functional element module is a node of ROS,
Means for analyzing the IDL file of the component to generate a message file or / and a service file of the node and a source code;
Means for generating source code of the IDL file by an IDL compiler;
Means for generating a source code of the message file or / and the service file by a ROS compiler,
A conversion module is generated using the three source codes.
The apparatus according to claim 15.
The input / output of the first type robot functional element module is specified when the program of the first type robot functional element module is executed, and the analysis is performed when the program is executed. The apparatus according to 11 or 12.
The first middleware is ROS (Robot Operating System), the first type robot functional element module is a node of ROS, and the input / output is a message file or / and service of the topic of the node being executed. The apparatus according to claim 17, wherein the apparatus is obtained by analyzing the service file.
The second middleware is OpenRTM (Open Robot Middleware), the second type robot functional element module is a component of OpenRTM, and the second interface definition is an IDL file. Equipment.
The first type robot functional element module is an ROS node, the second type robot functional element module is an OpenRTM component,
Means for analyzing the message file or / and service file of the node to generate a component IDL file and source code;
Means for generating source code of the message file or / and service file by a ROS compiler;
Means for generating source code of the IDL file generated by an IDL compiler,
A conversion module is generated using the three source codes.
The apparatus of claim 19.
A conversion module that cooperates between the first middleware having the first type of robot functional element module set and the second middleware having the second type of robot functional element module set is automatically generated. Therefore, a computer program for causing a computer to function as the means according to any one of claims 11 to 20.