[go: up one dir, main page]

WO2014061516A1 - Procédé et dispositif de génération de liaison de module de conversion entre différents types d'intergiciel de robot - Google Patents

Procédé et dispositif de génération de liaison de module de conversion entre différents types d'intergiciel de robot Download PDF

Info

Publication number
WO2014061516A1
WO2014061516A1 PCT/JP2013/077419 JP2013077419W WO2014061516A1 WO 2014061516 A1 WO2014061516 A1 WO 2014061516A1 JP 2013077419 W JP2013077419 W JP 2013077419W WO 2014061516 A1 WO2014061516 A1 WO 2014061516A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
functional element
source code
middleware
ros
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2013/077419
Other languages
English (en)
Japanese (ja)
Inventor
慧 岡田
斎藤　学
雅幸 稲葉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
University of Tokyo NUC
Original Assignee
University of Tokyo NUC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by University of Tokyo NUC filed Critical University of Tokyo NUC
Publication of WO2014061516A1 publication Critical patent/WO2014061516A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code

Definitions

  • 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.
  • 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.
  • RTC RT component
  • 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.
  • 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.
  • 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)”.
  • 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.
  • a first interface definition file for example, component IDL file
  • a second interface definition file node message file, service file
  • 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.
  • 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.
  • a bridge module that provides the ROS node program is generated from the OpenRTM component program.
  • 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.
  • 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.
  • a first interface definition file e.g., message file, service
  • a first type robot function element module e.g., node program
  • File and a corresponding second interface definition file (for example, IDL file) and a source code of the bridge module are generated.
  • the first middleware is a ROS (Robot Operating System)
  • the first type robot functional element module is a ROS node
  • 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.
  • the second middleware is OpenRTM (Open Robot Middleware)
  • the second type robot function element module is an OpenRTM component
  • the second interface definition file is an IDL file.
  • a bridge module that provides an OpenRTM component program corresponding to the ROS node program is generated.
  • the first type robot functional element module is a 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.
  • 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 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.
  • 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.
  • Robot middleware is a software platform for constructing a robot system by combining a plurality of software modules of robot functional elements.
  • ROS Robot Operating System
  • projects such as Orocos and iCub / Yarp in Europe, and OpenRTM projects in Japan are known.
  • middleware developed by companies.
  • 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.
  • ROS Robot Operating System
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • RT component 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.
  • 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.
  • a command level (or function level)
  • the position and speed of the hand are data to be sent from a host application or component through a data port.
  • 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.
  • a service is a group of commands (also called functions, methods, operations, etc.) that are functionally related.
  • 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.
  • IDL CORBA interface definition language
  • 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
  • a skeleton is a base code for implementing a provider.
  • calling between different languages can be performed seamlessly.
  • a provider implemented in C ++ can be easily called with Python or Java.
  • 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.
  • typedef keyword as well as C language.
  • sequence dynamic array type
  • EchoList type is defined as a string (string type) type list
  • ValueList type as a float type list.
  • Five functions (operations) are defined in the MyService interface.
  • 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.
  • proxy proxy
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • ROS message files can be defined as data types in IDL, and ROS service files correspond to IDL function calls.
  • 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.
  • 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.
  • 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 illustrate ROS node information.
  • 6A to 6H 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.
  • an interface source file (Python file) is generated.
  • a source code (Python file) of the “IDL file” is generated.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1B 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
  • FIGS. 9A to 9E MyServiceROSBridge.cpp
  • FIGS. 10A to 10C MyServiceROSBridge.h
  • FIGS. 11A and 11B 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)
  • 18A to 18L 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.
  • the main source code in this embodiment, the cpp file and the h file
  • the main source code is a different middleware conversion source code (its main body part), that is, a middleware conversion core source code.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention porte sur un procédé et un dispositif pour générer automatiquement un module de pont d'intergiciel dont l'interopérabilité est souhaitée. Le procédé comprend : une étape d'analyse d'une première définition d'interface d'un premier type de module d'élément fonctionnel de robot, et de génération d'une seconde définition d'interface d'un second type de module d'élément fonctionnel de robot et de code source de conversion inter-intergiciel ; et une étape de génération d'un module de conversion à l'aide de la seconde définition d'interface et du code source.
PCT/JP2013/077419 2012-10-19 2013-10-09 Procédé et dispositif de génération de liaison de module de conversion entre différents types d'intergiciel de robot Ceased WO2014061516A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012232391A JP2014085732A (ja) 2012-10-19 2012-10-19 異なるタイプのロボットミドルウェア間を連携する変換モジュールの生成方法及び装置
JP2012-232391 2012-10-19

Publications (1)

Publication Number Publication Date
WO2014061516A1 true WO2014061516A1 (fr) 2014-04-24

Family

ID=50488084

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/077419 Ceased WO2014061516A1 (fr) 2012-10-19 2013-10-09 Procédé et dispositif de génération de liaison de module de conversion entre différents types d'intergiciel de robot

Country Status (2)

Country Link
JP (1) JP2014085732A (fr)
WO (1) WO2014061516A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015204751A1 (de) * 2015-03-17 2016-09-22 Robert Bosch Gmbh Vorrichtung und verfahren zum erstellen von applikationen für anwendungen für eine kommunikation zwischen einem server und einem client einer automatisierungsanlage
CN111198770A (zh) * 2018-11-19 2020-05-26 北京图森智途科技有限公司 Ros1消息的通信方法、装置和系统、转换方法和装置
CN113849449A (zh) * 2021-09-18 2021-12-28 北京京东乾石科技有限公司 一种通信系统和信息交互方法、设备和介质
CN114527982A (zh) * 2020-11-23 2022-05-24 中移互联网有限公司 中间件文件生成和中间件的调用方法、装置及电子设备
CN115134361A (zh) * 2022-06-20 2022-09-30 中汽创智科技有限公司 一种自动驾驶软件平台的跨平台通信方法及装置
CN119621025A (zh) * 2024-11-19 2025-03-14 北京百度网讯科技有限公司 消息转换插件的生成方法、装置、设备以及存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101668441B1 (ko) * 2014-05-13 2016-10-21 (주)큐센텍 이기종 장치의 데이터 수집을 위한 미들웨어 간 인터페이스 장치 및 방법
KR102822813B1 (ko) * 2023-09-27 2025-06-25 강원대학교산학협력단 정보모델 및 로봇 운영 체제(ros)간 매핑 장치 및 방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011129115A (ja) * 2009-12-18 2011-06-30 Korea Electronics Telecommun 異機種ロボットの協業のためのコンポーネント連動装置およびそれに伴う方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011129115A (ja) * 2009-12-18 2011-06-30 Korea Electronics Telecommun 異機種ロボットの協業のためのコンポーネント連動装置およびそれに伴う方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JOHANNES WIENKE ET AL.: "A Middleware for Collaborative Research in Experimental Robotics", 2011 IEEE/SICE INTERNATIONAL SYMPOSIUM ON SYSTEM INTEGRATION (SII), 20 December 2011 (2011-12-20), pages 1187 *
KEI OKADA: "A Review of Robotics Open-Source Software and its Future Trends", SYSTEMS, CONTROL AND INFORMATION, vol. 56, no. 11, 15 November 2012 (2012-11-15), pages 25 - 27 *
NORIAKI ANDO: "The Robotic Technology Component (RTC) and Its Relevant Specifications Standardization Activities in OMG", JOURNAL OF THE ROBOTICS SOCIETY OF JAPAN, vol. 29, no. 4, 15 May 2011 (2011-05-15), pages 19 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015204751A1 (de) * 2015-03-17 2016-09-22 Robert Bosch Gmbh Vorrichtung und verfahren zum erstellen von applikationen für anwendungen für eine kommunikation zwischen einem server und einem client einer automatisierungsanlage
CN111198770A (zh) * 2018-11-19 2020-05-26 北京图森智途科技有限公司 Ros1消息的通信方法、装置和系统、转换方法和装置
CN111198770B (zh) * 2018-11-19 2023-06-20 北京图森智途科技有限公司 Ros1消息的通信方法、装置和系统、转换方法和装置
CN114527982A (zh) * 2020-11-23 2022-05-24 中移互联网有限公司 中间件文件生成和中间件的调用方法、装置及电子设备
CN113849449A (zh) * 2021-09-18 2021-12-28 北京京东乾石科技有限公司 一种通信系统和信息交互方法、设备和介质
CN115134361A (zh) * 2022-06-20 2022-09-30 中汽创智科技有限公司 一种自动驾驶软件平台的跨平台通信方法及装置
CN115134361B (zh) * 2022-06-20 2024-04-26 中汽创智科技有限公司 一种自动驾驶软件平台的跨平台通信方法及装置
CN119621025A (zh) * 2024-11-19 2025-03-14 北京百度网讯科技有限公司 消息转换插件的生成方法、装置、设备以及存储介质

Also Published As

Publication number Publication date
JP2014085732A (ja) 2014-05-12

Similar Documents

Publication Publication Date Title
WO2014061516A1 (fr) Procédé et dispositif de génération de liaison de module de conversion entre différents types d'intergiciel de robot
US8190274B2 (en) Method and control device for controlling an automating system
Calisi et al. OpenRDK: a modular framework for robotic software development
Thramboulidis Development of distributed industrial control applications: The CORFU framework
JP2011503682A (ja) 制御プログラムを有する自動化装置ならびに制御プログラムをプログラミングするための方法
CN106936932A (zh) 一种通过云服务协议访问机器人软件包的方法
KR20160000542A (ko) 데이터 분산 서비스 응용 생성 방법 및 장치
CN113791758B (zh) 一种服务编排本地化执行系统及其方法
US20030069998A1 (en) Motion services protocol accessible through uniform resource locator (URL)
Veiga et al. Experiments with service-oriented architectures for industrial robotic cells programming
US7398527B2 (en) Dispatching application steps of an application running on an application server in a client/server environment
Dai et al. Enabling plug-and-play software components in industrial cyber-physical systems by adopting service-oriented architecture paradigm
Wehner et al. Internet of things simulation using omnet++ and hardware in the loop
Eisenhauer et al. DataExchange: high performance communications in distributed laboratories
Wu et al. Service-oriented communication architecture for automated manufacturing system integration
Huang et al. Designing an agent synthesis system for cross-RPC communication
Blake et al. Robots on the web
Jang et al. A heterogeneous coupling scheme of OPRoS component framework with ROS
Wu et al. Remote multi‐robot monitoring and control system based on MMS and web services
Peng et al. Connecting the Robot to ROS
JP4776602B2 (ja) コントローラ用のプログラミング装置、コントローラ及びコントローラ管理システム
Grzelak et al. Towards a Software Architecture for Near Real-time Applications of IoT.
JP2003076563A (ja) 分散オブジェクトミドルウェア連携方法及びプログラムを記録した記録媒体並びにプログラム
Gottardi et al. Run-time Adaptable Service Oriented Architecture in the Context of Repository Systems
Krizsán ICE extension of RT-Middleware framework

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13847856

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13847856

Country of ref document: EP

Kind code of ref document: A1