CN111338820A - Operation method, client and storage medium - Google Patents
Operation method, client and storage medium Download PDFInfo
- Publication number
- CN111338820A CN111338820A CN202010113852.7A CN202010113852A CN111338820A CN 111338820 A CN111338820 A CN 111338820A CN 202010113852 A CN202010113852 A CN 202010113852A CN 111338820 A CN111338820 A CN 111338820A
- Authority
- CN
- China
- Prior art keywords
- file
- service
- target
- target data
- client
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 83
- 230000006870 function Effects 0.000 claims description 66
- 230000004044 response Effects 0.000 claims description 41
- 230000008569 process Effects 0.000 claims description 27
- 238000004590 computer program Methods 0.000 claims description 9
- 238000004891 communication Methods 0.000 description 11
- 230000009471 action Effects 0.000 description 8
- 230000006399 behavior Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 7
- 230000001360 synchronised effect Effects 0.000 description 6
- 238000011161 development Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 241000272814 Anser sp. Species 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000011017 operating method Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000004851 dishwashing Methods 0.000 description 1
- 235000019800 disodium phosphate Nutrition 0.000 description 1
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 1
- 239000010931 gold Substances 0.000 description 1
- 229910052737 gold Inorganic materials 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Manipulator (AREA)
Abstract
The embodiment of the application discloses an operation method, a client and a computer storage medium, wherein the method comprises the following steps: obtaining attributes of at least one service in an actionlib of a robot operating system; wherein each service enables the robot to perform a function; the attribute is at least characterized by data required by the service to be executed; according to the attribute of each service, creating corresponding target data for each service; running at least one target data in the client; wherein the executed target data is capable of causing the robot to execute a target function, the target function being a function that the service corresponding to the executed target data causes the robot to execute.
Description
Technical Field
The present application relates to Robot Operating System (ROS) technology, and more particularly, to an operating method, a client, and a computer storage medium.
Background
The robot operating system library (actionlib) is a collection of important function packages in the ROS and is a function library officially published by the ROS. For ease of description, each function in actionlib is considered a service. In the working mode, actionlib adopts a client-server working mode, the client is an electronic device such as a desktop, a mobile phone and a tablet computer, the server is a robot (the robot is provided with an ROS) for example, if a user wants to execute the operation of stopping the pile returning of the robot, a command is input to the client, the client sends the command to the robot, the robot executes the command, and the actionlib is used for executing the operation of stopping the pile returning of the robot. In the related art, if the client side adopts JAVA language for compiling, the robot and the client side can communicate in a rossjava manner. In this communication mode, if the client develops additional business expected to call actionlib service of the robot end by using JAVA language, especially requests an interrupt service or requests the robot to give feedback, the client can only call by using C + + language, otherwise the client cannot successfully call. And the development of other languages besides JAVA language is carried out at the client, so that the development cost is not increased.
Disclosure of Invention
In order to solve the existing technical problem, embodiments of the present application provide an operation method, a client, and a computer storage medium.
The technical scheme of the embodiment of the application is realized as follows:
the embodiment of the application provides an operation method, which is applied to a client side and comprises the following steps:
obtaining attributes of at least one service in an actionlib of a robot operating system; wherein each service enables the robot to perform a function; the attribute is at least characterized by data required by the service to be executed;
according to the attribute of each service, creating corresponding target data for each service;
running at least one target data in the client;
wherein the executed target data is capable of causing the robot to execute a target function, the target function being a function that the service corresponding to the executed target data causes the robot to execute.
In the above scheme, the target data at least includes a first target file, a second target file and a third target file; the first target file is a file which is characterized as a request service; the second target file is a file characterized as a service response result; the third target file is a file characterized as a service response process;
correspondingly, the creating of the corresponding target data for each service includes:
obtaining at least attributes of a first file, a second file and a third file of each service, wherein the first file is characterized as a file for receiving a request service; the second file is characterized as a file of the service response result; the third file is characterized as a file of the service response process;
according to the attribute of the first file of each service, creating a first target file corresponding to target data;
creating a second target file corresponding to the target data according to the attribute of the second file of each service;
and creating a third target file corresponding to the target data according to the attribute of the third file of each service.
In the foregoing solution, the running the at least one target data includes:
running a first target file, a second target file and a third target file of the target data;
the first target file is operated, so that the service request can be sent; running a second target file capable of receiving data of a service response result generated for the service request; running the third object file can receive data of a service response procedure generated for the service request.
In the above scheme, the method further comprises:
creating corresponding indication files for each target data; and the indication file is at least used for indicating the service corresponding to the target data. 5. The method of claim 4, further comprising:
the target data further includes fourth target data, the fourth target data being a file characterized as canceling the service request generated based on the first target file;
correspondingly, the creating of the corresponding target data for each service includes: obtaining the attribute of a fourth file of each service, wherein the fourth file is characterized as a file for receiving a service canceling request;
and creating fourth target data corresponding to the target data according to the attribute of the fourth file of each service.
In the above scheme, the method further comprises:
the target data further includes fifth target data, the fifth target data being a file characterized as a state of a service request generated based on the first target file; accordingly, the method can be used for solving the problems that,
the creating of the corresponding target data for each service includes:
obtaining attributes of a fifth file of each service, wherein the fifth file is a file characterized as a service request state;
and creating fifth target data corresponding to the target data according to the attribute of the fifth file of each service.
An embodiment of the present application provides a client, including:
the obtaining unit is used for obtaining the attribute of at least one service in the actionlib of the robot operating system; wherein each service enables the robot to perform a function; the attribute is at least characterized by data required by the service to be executed;
the creating unit is used for creating corresponding target data for each service according to the attribute of each service;
the operation unit is used for operating at least one target data in the client;
the executed target data can enable the robot to execute a target function, and the target function is a function which is executed by the robot through a service corresponding to the executed target data.
In the above-mentioned scheme, the first step of the method,
the target data at least comprises a first target file, a second target file and a third target file; the first target file is a file which is characterized as a request service; the second target file is a file characterized as a service response result; the third target file is a file characterized as a service response process;
accordingly, the creating unit is configured to:
obtaining at least attributes of a first file, a second file and a third file of each service, wherein the first file is characterized as a file for receiving a request service; the second file is characterized as a file of the service response result; the third file is characterized as a file of the service response process;
according to the attribute of the first file of each service, creating a first target file corresponding to target data;
creating a second target file corresponding to the target data according to the attribute of the second file of each service;
and creating a third target file corresponding to the target data according to the attribute of the third file of each service.
The embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the steps of the foregoing operating method.
The embodiment of the present application provides a client, which includes a memory, a processor, and a computer program stored on the memory and capable of running on the processor, where the processor implements the steps of the foregoing running method when executing the program.
The embodiment of the application provides an operation method, a client and a computer storage medium, wherein the method comprises the following steps: obtaining attributes of at least one service in an actionlib of a robot operating system; wherein each service enables the robot to perform a function; the attribute is at least characterized by data required by the service to be executed; according to the attribute of each service, creating corresponding target data for each service; running at least one target data in the client; wherein the executed target data is capable of causing the robot to execute a target function, the target function being a function that the service corresponding to the executed target data causes the robot to execute.
In the embodiment of the application, the target data is created by the client according to the attributes of the services in the actionlib, and the created target data can be regarded as data which is associated with the services in the actionlib to a certain extent, so that the target data is operated, that is, the direct calling of the client to the actionlib services is realized, no additional compiling language is required to be developed, and the cost is saved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a first schematic diagram of a communication mechanism between an Actionclient and an ActionServer in the embodiment of the present application;
FIG. 2 is a diagram of a second communication mechanism between an Actionclient and an ActionServer in the embodiment of the present application;
FIG. 3 is a first flowchart illustrating an implementation of the operation method in the embodiment of the present application;
FIG. 4 is a schematic flow chart illustrating an implementation of the operation method in the embodiment of the present application;
FIG. 5 is a third schematic flow chart illustrating an implementation of the operation method in the embodiment of the present application;
FIG. 6 is a diagram illustrating class relationships among documents in an embodiment of the present application;
FIG. 7 is a schematic diagram of an application flow in an embodiment of the present application;
fig. 8 is a schematic structural diagram of a client in an embodiment of the present application;
fig. 9 is a schematic hardware configuration diagram of a client in the embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions in the embodiments of the present application will be described clearly and completely with reference to the accompanying drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application. In the present application, the embodiments and features of the embodiments may be arbitrarily combined with each other without conflict. The steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.
Prior to describing the embodiments of the present application, a description will be given of related technologies that may be used in the embodiments of the present application.
Aiming at the client-server working mode used by actionlib, the method can be regarded as the working mode of ActionClient-actionServer. The Actionclient and the ActionServer communicate with each other through a robot operating system behavior Protocol (ROS Action Protocol), and the ROS Action Protocol transmits data in an ROS message (Topic) mode. The communication mechanism in the application scenarios of ActionClient and ActionServer is roughly as shown in FIG. 1. In the Application scenario, the device includes a Client Application system (Application) and a Server Application system. Wherein, the ActionClient is positioned in the Client application system; the ActionServer is positioned in the Server application system; the Server application may be considered to be an application included in a robot running actionlib. On the Client application system side, a central control transmits request data (the request data can be given in the form of called function functions) to be sent to the Server application system to an Actionclient, and the Actionclient sends the request data to the Server application system side in the ROS message mode. The Server application side, specifically the ActionServer, receives this request data and requests the central control to give a response (or execution) result (callbacks) to this request data. The Server application system side, specifically the central control, gives the request result in the form of calling function calls, and transmits the request result to the Client application system, specifically the Actionclient, through the ActionServer, as the feedback (callbacks) to the request data. From the foregoing, it can be seen that the data transmission between the Client Application system (Application) and the Server Application system can be further regarded as data transmission between an ActionClient and an ActionServer. As shown in fig. 2, is a communication mechanism between an ActionClient and an ActionServer. The types of communication information (message) between the ActionClient and the ActionServer mainly include the following:
and 9, gold: request data sent by the Actionclient to the ActionServer;
cancel: the data of the cancellation request data sent to the ActionServer by the Actionclient;
status: the state data of the service request fed back to the ActionClient by the ActionServer, such as the service request is executing, the service request is suspended, etc.;
feedback: response process data aiming at the request data is fed back to the Actionclient by the ActionServer, if the request data is that the robot returns to the pile, the feedback can return to the position of the pile with a difference of 1m, return to the position of the pile with a difference of 0.5m and the like;
result: result data of success or failure of the request fed back to the ActionClient by the ActionServer.
Those skilled in the art will appreciate that a client's call to a service provided in actionlib requires at least sending of a good, receiving of a feedback, and result. For cancel and status, it can be decided whether to send or request feedback according to actual situations. Any of the foregoing types of data may be given by a function.
The embodiment of the application provides a first embodiment of an operation method, which is applied to a client. The client can be an ActionClient and adopts JAVA language for compiling. The client is capable of rossjava communication with a server, such as a robotic device. As shown in fig. 3, the method includes:
s301: obtaining attributes of at least one service in an actionlib of a robot operating system; wherein each service enables the robot to perform a function; the attribute is at least characterized by data required by the service to be executed;
in this step, one service in actionlib may cause the robot device (located at the service end) to execute a corresponding behavior, for example, service 1 may cause the robot device to execute a stub returning behavior, and service 2 may cause the robot device to execute a stub stopping behavior; the service 3 can cause the robot device to perform dish washing actions or the like. It will be appreciated that due to differences in behavior, services may differ, and that different services may require different amounts of data when executed. The attribute of the service may be considered as a parameter or a variable fed back by the client and the server to the service client or a parameter or a variable sent by the client and the server to the client, that is, data that needs to be transferred by the client and the server to implement the service.
S302: according to the attribute of each service, creating corresponding target data for each service;
in this step, if there are N services (N ≧ 1 positive integer) in actionlib, N pieces of target data can be created. Target data corresponding to each service may also be created for a portion of the services in the selected actionlib.
S303: running at least one target data in the client; wherein the executed target data is capable of causing the robot to execute a target function, the target function being a function that the service corresponding to the executed target data causes the robot to execute.
In this step, similar to the action in which a service in actionlib can make a robot implement a behavior, an item target function in the embodiment of the present application can make the robot implement a behavior, which is a behavior that the service on which the creation of the target data depends makes the robot implement.
The main body executing S301 to S303 is a client. Because the target data is created by the client according to the attributes of the services in the actionlib, the created target data is data which has a certain correlation with the services in the actionlib, the target data is operated, which is equivalent to realizing the direct call of the client to the actionlib services, no additional compiling language is required to be developed, and the cost is saved.
In an alternative, as shown in fig. 4, S302 may further be:
s3021: obtaining at least attributes of a first file, a second file and a third file of each service, wherein the first file is characterized as a file for receiving a request service; the second file is characterized as a file of the service response result; the third file is characterized as a file of the service response process;
s3022: according to the attribute of the first file of each service, creating a first target file corresponding to target data;
s3023: creating a second target file corresponding to the target data according to the attribute of the second file of each service;
s3024: according to the attribute of the third file of each service, a third target file corresponding to the target data is created;
s3025: and at least collecting the first target file, the second target file and the third target file as target data.
In the foregoing solution, it is assumed that actionlib has a service 1, the service 1 can implement stub returning operation of the robot, and target data created by the client according to the attribute of the service 1 is the target data 1. It is assumed that the object data 1 includes at least an object file 1 (first object file), an object file 2 (second object file 2), and an object file 3 (third object file). The client creates a good file for the client to initiate request data to the server, namely creates target data 1, according to the attribute of the file (i.e. the first file) in the service 1 which receives the request service. The client creates a file for the client to receive the result returned by the server, that is, create the target data 2, according to the attribute of the file (result, that is, the second file) of the service response result in the service 1. The client creates a file for the client to receive the feedback returned by the server, that is, create the target data 3, according to the attribute of the file (feedback, that is, the third file) of the service response process in the service 1. It can be understood that, because the services in actionlib are all implemented by functions, the files can be regarded as function files. The client and the server transfer data through the functions, and at least the functions, the number of the functions, the sequence of the functions and the meaning of the functions which are expressed by the functions, which are transferred between the client and the server, are corresponding or consistent (matched). That is, the client creates the corresponding function file according to at least the meaning, the number of functions, the sequence of the functions, the implementation principle of the function file, and the like (the attribute of the file) indicated by each function in each function file in the service 1. In this way, each file of the client target data is created based on the attribute of each file of the service in actionlib located at the server. That is, each file of the target data of the client is created depending on the attribute of the actionlib service of the server, so that the relevance between the target data created by the client and the actionlib service of the server can be greatly improved, and the data transfer between the client and the server can be greatly facilitated. It is understood that S3021 to S3025 are further descriptions of S302.
In an alternative arrangement, where the target data includes target file 1, target file 2 and target file 3, as shown in figure 5,
s303 is S303': the executing the at least one target data comprises:
running a first target file, a second target file and a third target file of the target data;
the first target file is operated, so that the service request can be sent; running a second target file capable of receiving data of a service response result generated for the service request; running the third object file can receive data of a service response procedure generated for the service request.
Here, when the client creates the object files 1 to 3, the client executes the operation of each object file, and transmits the goal to the server based on the operated object file 1, receives the result fed back by the server based on the operated object file 2, and receives the feedback fed back by the server based on the operated object file 3. It can be understood that the client creates the target data based on the content, such as file functions, function quantity, sequence, meaning and the like, required by the actionlib service of the server, and such creation can facilitate direct call of the client to the actionlib service, thereby facilitating smooth interaction between the client and the server.
In an optional aspect, before creating the first target file to the third target file, the method further includes:
creating corresponding indication files for each target data; and the indication file is at least used for indicating the service corresponding to the target data.
It can be understood that actionlib has a plurality of services, and in order to facilitate the invocation of these services at the client, a corresponding instruction file needs to be created for each service used by the client, where the instruction file is used to instruct the client which service of the server is to be invoked and which function is to be executed. In practical application, when a client wants to use the service 1 to realize the pile-returning operation of the robot, the client needs to run the indication file corresponding to the service first and then run the first target file, the second target file and the third target file created for the service on the basis that the indication file is run, so that the service can be called.
In an optional scheme, the step S302, that is, creating corresponding target data for each service further includes:
obtaining attributes of a fourth file and/or a fifth file of each service; the fourth file is characterized as a file for receiving a service canceling request, and the fifth file is characterized as a file in a service request state;
according to the attributes of the fourth file and/or the fifth file of each service, fourth target data and/or fifth target data corresponding to the target data are created, wherein the fourth target data are files which are characterized in that service requests generated based on the first target file are cancelled; the fifth target data is a file characterized by a status of a service request generated based on the first target file.
In some application scenarios, the data types between the client and the server may include cancel and status, in addition to good, feedback, and result. The creation of the fourth target data by the client corresponds to a file (fourth file) for the server to receive status for a certain service, and creates cancel (fourth target file) for the service. The client creates the fifth target data corresponding to creation of a file (fifth target file) for receiving the status for a certain service fed back by the server, based on the file (fifth file) for sending the status for the service generated by the server. The client creates the fourth target file and the fifth target file according to at least the meaning, the number of functions, the sequence of the functions, the implementation principle and the like (the attributes of the files) represented by the functions in the fourth file and the fifth file in the service. Therefore, data transmission between the client and the server can be greatly facilitated.
The technical solution of the embodiment of the present application is further described below.
Assuming that the robot stub return is realized through the service 1 in actionlib as an example, the service 1 includes a function file (first file) for receiving a request of the client to send the stub back, a function file (second file) for feeding back a result of the stub failure or success to the client, and a function file (third file) for feeding back a process of the stub to the client.
For the service 1, the client creates an indication file corresponding to the service 1 for the service, as shown in fig. 6, the indication file is a pilereturn action, and the operation of the indication file means that the client needs to call the service 1 to perform a stub returning operation of the robot. In the embodiment of the present application,
as shown in fig. 6, the pileretunActiongood file is a target file 1 for the stub-returning service that the client needs to create (a file that the client uses to send good). The PileReturnActionResult file is a target file 2 (a file for receiving result by the client) which needs to be created by the client and is used for receiving the result fed back by the server. The PileReturn Actionfeedback file is a target file 3 (a file for receiving feedback) which needs to be created by the client and is used for receiving the feedback of the server to the stub process.
It should be noted that the client creates the piletrurnactional file according to the first file of the service 1, creates the piletrurnactionresult file according to the second file of the service 1, and creates the piletrurnactionfeedback file according to the third file of the service 1. In the creation process, the function variables, the number of variables, the meanings and the sequence of the created target files need to be consistent with the files of the service 1. The following takes the pileReturnActiongood file as an example to specifically describe the creation process: on the client side, the PileReturnActionGoal files are compiled using the JAVA language. As shown in fig. 6, the piletrurnactional file includes a Header (Header), a message identification (goaldd), and a body of the file (piletrurnactional). The message header file is used for function declarations and interface declarations of the good file, and can be created according to a header file of the service 1 in actionlib, and variables in the message header file need to correspond to variables of the header file of the service 1. The message identifier is used to identify the good, by being the timestamp + the identity of the good itself (as distinguished from a different good). The text of the file is a JAVA language program for realizing successful transmission to the good. Wherein the message identification is automatically created for the client. And carrying out JAVA compiling on the goose file according to the analyzed implementation principle of the service 1 to obtain the JAVA implementation of the goose file. Variables, the number, the meaning and the sequence of the variables of the function which needs to be transferred to the server side in the text of the file need to be consistent with those of the first file, so that the correct transfer of function information in the target file and the first file can be ensured. It is understood that the creation process of the piletrurnactionresult file and the piletrurnactionfeedback file is substantially the same as the creation process of the piletrurnactionsummary file, and repeated details are omitted. The Goalstatus represents the execution state of the good at the server, such as executing, stopping executing, and the like. In general terms, the process of creating a target file is essentially: the server side needs which variables or parameters to complete a service, and the client side creates a function capable of transferring the variables or parameters to complete the successful transfer of the variables or parameters. In this way, the client side realizes the transmission of parameters required by the server side through the created target file, and can smoothly realize the calling of the actionlib of the server side. The above can be regarded as creation of each target file in the target data 1 (S701). The above scheme is described by taking an example that the object data 1 includes an object file 1 to an object file 3, and the object data 1 may further include an object file 4 and an object file 5. The creation of object files 4 and 5 is similar to the creation process described above and the repetition is not described in detail.
It is understood that the above created piletrurnactional file, piletrurnactionresult file, and piletrurnactionfeedback file are actually implemented by JAVA functions, and may be stored in the central control of the Client application system shown in fig. 1. In use, the client wants to control the robot device of the server to return to the position where the pile is located (pile return operation). The client (ActionClient) calls (subscribes) the PilerReturnActionGoal file from the central control to run, and issues the PilerReturnActionGoal file to the server (S702), which is equivalent to sending the goose variable or parameter required by the server to execute the stub return to the server. In this way, the server can perform pile-returning operation of the robot, and feed back the results of pile-returning success or failure, and pile-returning response process information (1 m difference back to the position of the pile, 0.5m difference back to the position of the pile) to the client. The client receives the pile-returning success or failure result through the PiLEReturnActionResult file; the receipt of the pile return response process information is performed through the piletrurnactionfeedback file (S703).
In the foregoing solution, the instruction file pilereurnactionaction may be regarded as holding three members, namely pilereurnactionavailable, pilereurnactionfeedback, and pilereurnactionresult. Wherein the PileReturnActiongood member is used for holding back the stub good parameter; the PileReturn ActionResult member holds data reflecting the success or failure of the response of the post-back service; the PileReturn Actionfeedback member holds data that reflects the response process back to the stub service.
It should be noted that the created piletrurnaction, piletrurnactiongold, piletrurnactionresult, and piletrurnactionfeedback files have respective interfaces, which are logical interfaces, and specifically, may be storage addresses of the respective files. The client can read the header file 1 from the storage address of the header file 1 and read each target file from the storage address of each target file. For example, when the target file 1 is stored at the address 0010-001F, the target file 1 is read from the storage address 0010-001F. Therefore, each target file can be conveniently called and operated.
In general, if the xxfeed file is regarded as a feedback fed back to the client by the server in the actionlib, the xxGoal file is regarded as a goal generated by the client for the service 1 in the actionlib, and the xxResult file is regarded as a result fed back to the client by the server in the actionlib, the xxGoal file may be regarded as a holding file of a pileretunnActionGoal file, the xxfeed file may be regarded as a holding file of a pileretunnActionfeedback file, and the xxResult may be regarded as a holding file of a pileretunnActionresponse file. Equivalently, the client needs to call 7 class files using service 1 in actionlib: PileReturn action file, PileReturn action feedback file, PileReturn action response file, xxGoal file, xxResult file, and xxFeedback file. The xxActionfeedback file holds an xxFeedback file, which is equivalent to data reflecting the response process of the pile-returning service; xxActionResult holds xxResult files, which are equivalent to holding data reflecting the success or failure of the response of the stub service; the PileReturnActionGoal file holds the xxResult file, which is equivalent to holding the stub good parameter back. On the application level, if the client wants to use the service 1 to implement the stub-returning operation of the machine, the above 7 class files need to be called, so that the stub-returning operation of the robot can be implemented. It can be inferred that the target data is created by the client according to the attributes of the services in actionlib, the created target data is data which has a certain correlation with the services in actionlib, and the running of the target data related to the actionlib services is equivalent to the realization of the direct calling of the client to the services in actionlib, so that the development of additional compiling languages is not needed, and the cost is saved. That is, the problem that the java client cannot directly call actionlib is solved by the scheme, and the function use of the rossjava is enriched, so that the rossjava can directly use the actionlib service in ros. Compared with the problems that the client cannot obtain the real-time feedback of the robot end and the robot end cannot send the feedback to the client in the related art, the method and the device for processing the feedback solve the problems. The problem that an additional development interface or other compiling languages are needed to send the feedback to the client in the related technology is avoided, and the additional development interface or the compiling languages are not needed for normal transmission of the feedback through the additionally developed interface or the compiling languages, so that the cost is greatly saved.
The embodiment of the application provides a client, which is the aforementioned ActionClient. As shown in fig. 8, the client includes: an obtaining unit 801, a creating unit 802, and an operating unit 803; wherein,
an obtaining unit 801, configured to obtain an attribute of at least one service in an actionlib of a robot operating system; wherein each service enables the robot to perform a function; the attribute is at least characterized by data required by the service to be executed;
a creating unit 802, configured to create corresponding target data for each service according to an attribute of each service;
an execution unit 803, configured to execute at least one target data in the client;
wherein the executed target data is capable of causing the robot to execute a target function, the target function being a function that the service corresponding to the executed target data causes the robot to execute.
In an optional aspect, the target data includes at least a first target file, a second target file, and a third target file; the first target file is a file which is characterized as a request service; the second target file is a file characterized as a service response result; the third target file is a file characterized as a service response process;
accordingly, the creating unit 802 is configured to:
obtaining at least attributes of a first file, a second file and a third file of each service, wherein the first file is characterized as a file for receiving a request service; the second file is characterized as a file of the service response result; the third file is characterized as a file of the service response process;
according to the attribute of the first file of each service, creating a first target file corresponding to target data;
creating a second target file corresponding to the target data according to the attribute of the second file of each service;
and creating a third target file corresponding to the target data according to the attribute of the third file of each service.
In an optional scheme, the running unit 803 is configured to run a first target file, a second target file, and a third target file of the target data;
the first target file is operated, so that the service request can be sent; running a second target file capable of receiving data of a service response result generated for the service request; running the third object file can receive data of a service response procedure generated for the service request.
In an optional aspect, the creating unit 802 is configured to: creating corresponding indication files for each target data; and the indication file is at least used for indicating the service corresponding to the target data.
In an optional aspect, the target data further includes fourth target data, where the fourth target data is a file characterized by canceling a service request generated based on the first target file; correspondingly, the creating unit 802 is configured to obtain an attribute of a fourth file of each service, where the fourth file is a file characterized by receiving a request to cancel a service; and creating fourth target data corresponding to the target data according to the attribute of the fourth file of each service.
In an optional aspect, the target data further includes fifth target data, the fifth target data being a file characterized by a status of the service request generated based on the first target file; accordingly, the method can be used for solving the problems that,
the creating unit 802 is configured to obtain an attribute of a fifth file of each service, where the fifth file is a file characterized as a service request state; and creating fifth target data corresponding to the target data according to the attribute of the fifth file of each service. It is understood that the obtaining Unit 801, the creating Unit 802, and the running Unit 803 may be implemented by a Central Processing Unit (CPU), a Digital Signal Processor (DSP), a Micro Control Unit (MCU), or a programmable gate Array (FPGA) in practical applications.
It should be noted that, in the client according to the embodiment of the present application, because the principle of solving the problem of the client is similar to that of the foregoing operation method, both the implementation process and the implementation principle of the client can be described by referring to the implementation process and the implementation principle of the foregoing operation method, and repeated descriptions are omitted.
An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, where the computer program is configured to, when executed by a processor, perform at least the steps of the method shown in any one of fig. 1 to 7. The computer readable storage medium may be specifically a memory. The memory may be memory 62 as shown in fig. 9.
The embodiment of the application also provides a terminal. Fig. 9 is a schematic diagram of a hardware structure of a client according to an embodiment of the present application, and as shown in fig. 9, the client includes: a communication component 63 for data transmission, at least one processor 61 and a memory 62 for storing computer programs capable of running on the processor 61. The various components in the terminal are coupled together by a bus system 64. It will be appreciated that the bus system 64 is used to enable communications among the components. The bus system 64 includes a power bus, a control bus, and a status signal bus in addition to the data bus. For clarity of illustration, however, the various buses are labeled as bus system 64 in fig. 9.
Wherein the processor 61 executes the computer program to perform at least the steps of the method of any of fig. 1 to 7.
It will be appreciated that the memory 62 can be either volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. Among them, the nonvolatile Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a magnetic random access Memory (FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical disk, or a Compact Disc Read-Only Memory (CD-ROM); the magnetic surface storage may be disk storage or tape storage. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. By way of illustration and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Enhanced Synchronous Dynamic Random Access Memory (Enhanced DRAM), Synchronous Dynamic Random Access Memory (SLDRAM), Direct Memory (DRmb Access), and Random Access Memory (DRAM). The memory 62 described in embodiments herein is intended to comprise, without being limited to, these and any other suitable types of memory.
The method disclosed in the above embodiments of the present application may be applied to the processor 61, or implemented by the processor 61. The processor 61 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 61. The processor 61 described above may be a general purpose processor, a DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. The processor 61 may implement or perform the methods, steps and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium located in the memory 62, and the processor 61 reads the information in the memory 62 and performs the steps of the aforementioned method in conjunction with its hardware.
In an exemplary embodiment, the client may be implemented by one or more Application Specific Integrated Circuits (ASICs), DSPs, Programmable Logic Devices (PLDs), Complex Programmable Logic Devices (CPLDs), FPGAs, general purpose processors, controllers, MCUs, microprocessors (microprocessors), or other electronic components for executing the aforementioned clients.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.
Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: a mobile storage device, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or portions thereof contributing to the prior art may be embodied in the form of a software product stored in a storage medium, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic or optical disk, or various other media that can store program code.
The methods disclosed in the several method embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments.
Features disclosed in several of the product embodiments provided in the present application may be combined in any combination to yield new product embodiments without conflict.
The features disclosed in the several method or apparatus embodiments provided in the present application may be combined arbitrarily, without conflict, to arrive at new method embodiments or apparatus embodiments.
The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims (10)
1. An operation method applied to a client, the method comprising:
obtaining attributes of at least one service in an actionlib of a robot operating system; wherein each service enables the robot to perform a function; the attribute is at least characterized by data required by the service to be executed;
according to the attribute of each service, creating corresponding target data for each service;
running at least one target data in the client;
wherein the executed target data is capable of causing the robot to execute a target function, the target function being a function that the service corresponding to the executed target data causes the robot to execute.
2. The method of claim 1, wherein the target data comprises at least a first target file, a second target file, and a third target file; the first target file is a file which is characterized as a request service; the second target file is a file characterized as a service response result; the third target file is a file characterized as a service response process;
correspondingly, the creating of the corresponding target data for each service includes:
obtaining at least attributes of a first file, a second file and a third file of each service, wherein the first file is characterized as a file for receiving a request service; the second file is characterized as a file of the service response result; the third file is characterized as a file of the service response process;
according to the attribute of the first file of each service, creating a first target file corresponding to target data;
creating a second target file corresponding to the target data according to the attribute of the second file of each service;
and creating a third target file corresponding to the target data according to the attribute of the third file of each service.
3. The method of claim 2, wherein the executing the at least one target data comprises:
running a first target file, a second target file and a third target file of the target data;
the first target file is operated, so that the service request can be sent; running a second target file capable of receiving data of a service response result generated for the service request; running the third object file can receive data of a service response procedure generated for the service request.
4. A method according to claim 2 or 3, characterized in that the method further comprises:
creating corresponding indication files for each target data; and the indication file is at least used for indicating the service corresponding to the target data.
5. The method of claim 4, further comprising:
the target data further includes fourth target data, the fourth target data being a file characterized as canceling the service request generated based on the first target file;
correspondingly, the creating of the corresponding target data for each service includes: obtaining the attribute of a fourth file of each service, wherein the fourth file is characterized as a file for receiving a service canceling request;
and creating fourth target data corresponding to the target data according to the attribute of the fourth file of each service.
6. The method of claim 4, further comprising:
the target data further includes fifth target data, the fifth target data being a file characterized as a state of a service request generated based on the first target file; accordingly, the method can be used for solving the problems that,
the creating of the corresponding target data for each service includes:
obtaining attributes of a fifth file of each service, wherein the fifth file is a file characterized as a service request state;
and creating fifth target data corresponding to the target data according to the attribute of the fifth file of each service.
7. A client, comprising:
the obtaining unit is used for obtaining the attribute of at least one service in the actionlib of the robot operating system; wherein each service enables the robot to perform a function; the attribute is at least characterized by data required by the service to be executed;
the creating unit is used for creating corresponding target data for each service according to the attribute of each service;
the operation unit is used for operating at least one target data in the client;
the executed target data can enable the robot to execute a target function, and the target function is a function which is executed by the robot through a service corresponding to the executed target data.
8. The client of claim 7,
the target data at least comprises a first target file, a second target file and a third target file; the first target file is a file which is characterized as a request service; the second target file is a file characterized as a service response result; the third target file is a file characterized as a service response process;
accordingly, the creating unit is configured to:
obtaining at least attributes of a first file, a second file and a third file of each service, wherein the first file is characterized as a file for receiving a request service; the second file is characterized as a file of the service response result; the third file is characterized as a file of the service response process;
according to the attribute of the first file of each service, creating a first target file corresponding to target data;
creating a second target file corresponding to the target data according to the attribute of the second file of each service;
and creating a third target file corresponding to the target data according to the attribute of the third file of each service.
9. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 6.
10. A client comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of the method of any one of claims 1 to 6 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010113852.7A CN111338820B (en) | 2020-02-24 | 2020-02-24 | Operation method, client and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010113852.7A CN111338820B (en) | 2020-02-24 | 2020-02-24 | Operation method, client and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111338820A true CN111338820A (en) | 2020-06-26 |
| CN111338820B CN111338820B (en) | 2024-04-05 |
Family
ID=71183785
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010113852.7A Active CN111338820B (en) | 2020-02-24 | 2020-02-24 | Operation method, client and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111338820B (en) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1678580A2 (en) * | 2003-10-27 | 2006-07-12 | Nokia Corporation | Apparatus, system, method and computer program product for service selection and sorting |
| US20080253330A1 (en) * | 2007-04-10 | 2008-10-16 | Danger, Inc. | System and method for dynamically changing service characteristics based on device and network connectivity attributes |
| CN103164270A (en) * | 2011-12-12 | 2013-06-19 | 阿里巴巴集团控股有限公司 | Java system application programming interface calling method and system using the same |
| CN106648935A (en) * | 2016-12-29 | 2017-05-10 | 深圳市优必选科技有限公司 | C + + language-based remote function calling method and communication device |
| CN106796665A (en) * | 2014-07-24 | 2017-05-31 | X开发有限责任公司 | Method and system for generating instructions for a robotic system to perform a task |
| CN107277050A (en) * | 2017-07-27 | 2017-10-20 | 维沃移动通信有限公司 | A kind of data processing method, server, terminal and computer-readable recording medium |
| CN109213611A (en) * | 2018-08-01 | 2019-01-15 | 天津字节跳动科技有限公司 | The striding course means of communication, device, terminal and storage medium |
| CN109995805A (en) * | 2017-12-29 | 2019-07-09 | 深圳市优必选科技有限公司 | Intelligent robot management method, terminal device and medium |
| CN110019835A (en) * | 2017-11-06 | 2019-07-16 | 阿里巴巴集团控股有限公司 | Resource method of combination, device and electronic equipment |
| CN110569179A (en) * | 2018-06-06 | 2019-12-13 | 富晋精密工业（晋城）有限公司 | Data acquisition system and data acquisition method |
-
2020
- 2020-02-24 CN CN202010113852.7A patent/CN111338820B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1678580A2 (en) * | 2003-10-27 | 2006-07-12 | Nokia Corporation | Apparatus, system, method and computer program product for service selection and sorting |
| US20080253330A1 (en) * | 2007-04-10 | 2008-10-16 | Danger, Inc. | System and method for dynamically changing service characteristics based on device and network connectivity attributes |
| CN103164270A (en) * | 2011-12-12 | 2013-06-19 | 阿里巴巴集团控股有限公司 | Java system application programming interface calling method and system using the same |
| CN106796665A (en) * | 2014-07-24 | 2017-05-31 | X开发有限责任公司 | Method and system for generating instructions for a robotic system to perform a task |
| CN106648935A (en) * | 2016-12-29 | 2017-05-10 | 深圳市优必选科技有限公司 | C + + language-based remote function calling method and communication device |
| CN107277050A (en) * | 2017-07-27 | 2017-10-20 | 维沃移动通信有限公司 | A kind of data processing method, server, terminal and computer-readable recording medium |
| CN110019835A (en) * | 2017-11-06 | 2019-07-16 | 阿里巴巴集团控股有限公司 | Resource method of combination, device and electronic equipment |
| CN109995805A (en) * | 2017-12-29 | 2019-07-09 | 深圳市优必选科技有限公司 | Intelligent robot management method, terminal device and medium |
| CN110569179A (en) * | 2018-06-06 | 2019-12-13 | 富晋精密工业（晋城）有限公司 | Data acquisition system and data acquisition method |
| CN109213611A (en) * | 2018-08-01 | 2019-01-15 | 天津字节跳动科技有限公司 | The striding course means of communication, device, terminal and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| NORMAN HENDRICH 等: ""助老服务机器人***设计及软件架构"", vol. 1, no. 1, pages 26 - 34 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111338820B (en) | 2024-04-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100328516B1 (en) | SYSTEM AND METHOD FOR SETTING COMMUNICATION PROTOCOL BETWEEN APPLICATIONS | |
| CN108961033B (en) | Multi-service system interaction method and device, storage medium and electronic terminal | |
| US8584081B2 (en) | Server side application integration framework | |
| US8136127B1 (en) | System and method for linearly managing client-server communication | |
| US7519950B2 (en) | Method and system for version negotiation of distributed objects | |
| CN111666745B (en) | File downloading method, device, server and medium | |
| CN113076209B (en) | Communication method, communication device, electronic device and storage medium | |
| KR20110065448A (en) | Composing message processing pipelines | |
| CN113835911A (en) | Intranet penetration agent method, system, host and computer readable storage medium | |
| CN109725887B (en) | Data interaction method and device based on message research and development framework and terminal equipment | |
| CN112667371B (en) | Asynchronous task processing method, device, equipment and storage medium | |
| CN113111666A (en) | System and method for realizing multi-language translation of application program | |
| CN111338820A (en) | Operation method, client and storage medium | |
| CN112769975B (en) | Data integration method and device, server and storage medium | |
| Moulick et al. | Medical image processing using a service oriented architecture and distributed environment | |
| US20060195834A1 (en) | Method and system for availability checking on distributed objects | |
| CN113448960A (en) | Method and device for importing form file | |
| CN111552907A (en) | Message processing method, device, equipment and storage medium | |
| AU2022204692B2 (en) | Methods and systems for persistent communications between client applications and application servers | |
| CN116400988B (en) | Target parameter returning method, storage medium and electronic equipment | |
| CN117076160B (en) | Component calling method, device, equipment and storage medium | |
| CN117170941B (en) | Data backup method, device, electronic equipment and storage medium | |
| CN116132214B (en) | Event transmission method, device, equipment and medium based on event bus model | |
| CN113986379B (en) | Application starting method and device, computer equipment and storage medium | |
| CN111953581B (en) | Method and device for managing template message task and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 100176 601, 6th floor, building 2, No. 18, Kechuang 11th Street, Daxing Economic and Technological Development Zone, Beijing Applicant after: Jingdong Technology Information Technology Co.,Ltd. Address before: 100176 601, 6th floor, building 2, No. 18, Kechuang 11th Street, Daxing Economic and Technological Development Zone, Beijing Applicant before: Jingdong Shuke Haiyi Information Technology Co.,Ltd. Address after: 100176 601, 6th floor, building 2, No. 18, Kechuang 11th Street, Daxing Economic and Technological Development Zone, Beijing Applicant after: Jingdong Shuke Haiyi Information Technology Co.,Ltd. Address before: 100176 601, 6th floor, building 2, No. 18, Kechuang 11th Street, Daxing Economic and Technological Development Zone, Beijing Applicant before: BEIJING HAIYI TONGZHAN INFORMATION TECHNOLOGY Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |