CN111338820B - Operation method, client and storage medium - Google Patents
Operation method, client and storage medium Download PDFInfo
- Publication number
- CN111338820B CN111338820B CN202010113852.7A CN202010113852A CN111338820B CN 111338820 B CN111338820 B CN 111338820B CN 202010113852 A CN202010113852 A CN 202010113852A CN 111338820 B CN111338820 B CN 111338820B
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 85
- 230000006870 function Effects 0.000 claims abstract description 69
- 230000004044 response Effects 0.000 claims description 40
- 230000008569 process Effects 0.000 claims description 23
- 238000004590 computer program Methods 0.000 claims description 7
- 230000000875 corresponding effect Effects 0.000 description 45
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 18
- 239000010931 gold Substances 0.000 description 18
- 229910052737 gold Inorganic materials 0.000 description 18
- 230000001360 synchronised effect Effects 0.000 description 9
- 238000004891 communication Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 8
- 238000012546 transfer Methods 0.000 description 8
- 230000009471 action Effects 0.000 description 6
- 238000011161 development Methods 0.000 description 5
- 230000005291 magnetic effect Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 108091035663 GOLLD RNA motif Proteins 0.000 description 1
- 238000004851 dishwashing Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000005294 ferromagnetic effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000011017 operating method Methods 0.000 description 1
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
Abstract
The embodiment of the application discloses an operation method, a client and a computer storage medium, wherein the method comprises the following steps: acquiring the attribute of at least one service in a robot operating system library actionlib; wherein each service is capable of causing the robot to perform a function; the attribute is at least characterized by data that the service is to be executed for use; creating corresponding target data for each service according to the attribute of each service; running at least one target data in the client; the running target data can enable the robot to execute target functions, and the target functions are functions which are executed by the robot through services corresponding to the running target data.
Description
Technical Field
The present application relates to Robotic Operating System (ROS) technology, and in particular, 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 ROS, a function library officially published by ROS. For convenience of description, each function in actionlib is considered a service. In the working mode, actionlib adopts a client-server working mode, taking a client as electronic equipment such as a desktop, a mobile phone, a tablet personal computer and the like, and taking a server as an example of a robot (the robot is provided with ROS), if a user wants to execute stopping of the robot pile-back, inputting a command to the client, the client sends the command to the robot, the robot executes the command, and the actionlib is utilized to execute the service stopping of the robot pile-back. In the related art, if the client uses JAVA language for compiling, the robot and the client can communicate in a rosjava mode. In this communication manner, if the client develops additional services using JAVA language to expect to call actionlib service of the robot, especially request interrupt service or request the robot to give feedback, call can be performed only through c++ language, otherwise, successful call cannot be achieved. However, development of other languages than JAVA language is performed at the client, which does not increase development cost.
Disclosure of Invention
In order to solve the existing technical problems, 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, and comprises the following steps:
acquiring the attribute of at least one service in a robot operating system library actionlib; wherein each service is capable of causing the robot to perform a function; the attribute is at least characterized by data that the service is to be executed for use;
creating corresponding target data for each service according to the attribute of each service;
running at least one target data in the client;
the running target data can enable the robot to execute target functions, and the target functions are functions which are executed by the robot through services corresponding to the running target data.
In the above scheme, the target data at least comprises a first target file, a second target file and a third target file; wherein the first target file is a file 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 the corresponding target data for each service includes:
obtaining at least the 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 the requested service; the second file is a file characterized as a service response result; the third file is a file characterized as a service response process;
creating a first target file corresponding to target data according to the attribute of the first file of each service;
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 above solution, the running the at least one target data includes:
operating a first target file, a second target file and a third target file of the target data;
the method comprises the steps that a first target file is operated to send a service request; running a second object 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 a corresponding indication file for each target data; the indication file is at least used for indicating the service corresponding to the target data.
In the above scheme, the method further comprises:
the target data further comprises fourth target data, the fourth target data being a file characterized as canceling a service request generated based on the first target file;
correspondingly, the creating 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 cancellation 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 being based on a state of the service request generated by the first target file; in a corresponding manner,
the creating corresponding target data for each service includes:
obtaining the attribute of a fifth file of each service, wherein the fifth file is a file characterized by 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.
The embodiment of the application provides a client, which comprises:
an obtaining unit, configured to obtain an attribute of at least one service in the robot operating system library actionlib; wherein each service is capable of causing the robot to perform a function; the attribute is at least characterized by data that the service is to be executed for use;
the creation unit is used for creating corresponding target data for each service according to the attribute of each service;
an operation unit for operating at least one target data in the client;
the running target data can enable the robot to execute target functions, and the target functions are functions which are executed by the robot through services corresponding to the running target data.
In the above-described arrangement, the first and second embodiments,
the target data at least comprises a first target file, a second target file and a third target file; wherein the first target file is a file 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 creation unit is configured to:
obtaining at least the 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 the requested service; the second file is a file characterized as a service response result; the third file is a file characterized as a service response process;
Creating a first target file corresponding to target data according to the attribute of the first file of each service;
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 present embodiments provide a computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of the foregoing method of operation.
The embodiment of the application provides a client, which comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the processor realizes the steps of the 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: acquiring the attribute of at least one service in a robot operating system library actionlib; wherein each service is capable of causing the robot to perform a function; the attribute is at least characterized by data that the service is to be executed for use; creating corresponding target data for each service according to the attribute of each service; running at least one target data in the client; the running target data can enable the robot to execute target functions, and the target functions are functions which are executed by the robot through services corresponding to the running target data.
In the embodiment of the application, since the target data is created by the client according to the attribute of the service in the actionlib, the created target data can be regarded as the data which has a certain association with the service in the actionlib, and the target data is operated, which is equivalent to realizing the direct call of the client to the actionlib service, without developing additional compiling language, and saving the cost.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present application, and that other drawings may be obtained according to the provided drawings without inventive effort to a person skilled in the art.
FIG. 1 is a diagram illustrating a communication mechanism between an ActionClient and an ActionServer according to an embodiment of the present application;
FIG. 2 is a second diagram illustrating a communication mechanism between an ActionClient and an ActionServer in an embodiment of the present application;
FIG. 3 is a schematic diagram of an implementation flow of the operation method in the embodiment of the present application;
FIG. 4 is a second schematic implementation flow chart of the operation method in the embodiment of the present application;
FIG. 5 is a third schematic diagram of an implementation flow of the operation method in the embodiment of the present application;
FIG. 6 is a schematic diagram of class relationships for files 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 diagram of a composition structure of a client in an embodiment of the present application;
fig. 9 is a schematic diagram of hardware configuration of a client in an embodiment of the present application.
Detailed Description
For the purposes of making the objects, technical solutions and advantages of the present application more apparent, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure. Embodiments and features of embodiments in this application may be combined with each other arbitrarily without conflict. The steps illustrated in the flowchart of the figures may be performed in a computer system, such as a set of computer-executable instructions. Also, while a logical order is depicted in the flowchart, in some cases, the steps depicted or described may be performed in a different order than presented herein.
Prior to describing the embodiments of the present application, related techniques that may be used in the embodiments of the present application will be described.
The client-server mode used for actionlib can be regarded as an ActionClient-ActionServer mode. Wherein, actionClient and ActionServer communicate through a robot operating system behavior protocol (ROS Action Protocol), ROS Action Protocol is to transmit data in the form of ROS messages (Topic). The communication mechanism in the application scenario of ActionClient and ActionServer is approximately 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 located in the Client application system; the actionServer is located in the Server application system; the Server application may be considered as an application comprised by the robot device running actionlib. At the Client application system side, the central control transmits ActionClient, actionClient request data (which may be given in the form of a called function calls) to be sent to the Server application system, and sends the request data to the Server application system side by means of ROS messages. The Server application system side, specifically, the ActionServer receives the request data, and requests a central control to give a response (or execution) result (callbacks) of the request data. The Server application system side, particularly the central control, gives out the request result in the form of calling function calls, and transmits the request result to the Client application system, particularly the ActionClient, through the ActionServer as feedback (callbacks) for the request data. From the foregoing, it can be seen that the data transfer between the Client Application system (Application) and the Server Application system can be further seen as the data transfer between ActionClient and ActionServer. As shown in fig. 2, a communication mechanism between ActionClient and ActionServer is shown. The types of communication information (message) between ActionClient and ActionServer mainly include the following:
gol: request data sent to an actionServer by an ActionClient;
cancel: data of cancellation request data sent to an ActionServer by an ActionClient;
status: the actionServer feeds back the status data of the service request to the ActionClient, such as the service request is executing, the service request is stopped, etc.;
feedback: the response process data for the request data fed back to the ActionClient by the ActionServer, if the request data is that the request robot returns to the pile, the feedback can return to the position of the pile by 1m, return to the position of the pile by 0.5m, and the like;
result: and the actionServer feeds back the result data of success or failure of the request to the ActionClient.
Those skilled in the art will appreciate that a client call to a service provided in actionlib requires at least sending gold, receiving feedback, and result. For cancel and status, it may be decided whether feedback needs to be sent or requested according to the actual situation. Any of the foregoing types of data may be provided by a function.
The embodiment of the application provides a first embodiment of an operation method, which is applied to a client. The client may be an ActionClient, compiled in JAVA language. The client can communicate with a server, such as a robot device, for example, rosjava. As shown in fig. 3, the method includes:
S301: acquiring the attribute of at least one service in a robot operating system library actionlib; wherein each service is capable of causing the robot to perform a function; the attribute is at least characterized by data that the service is to be executed for use;
in this step, one service in actionlib may enable the robot device (located at the service end) to perform a corresponding action, for example, service 1 may enable the robot device to perform a pile returning action, and service 2 may enable the robot device to perform a pile stopping action; the service 3 enables the robotic device to perform dishwashing actions and the like. It will be appreciated that due to the different behavior, the services may be different and the data required when different services are executed may be different. The attribute of the service may be considered as a parameter or variable fed back by the client desired to the service or a parameter or variable sent by the client desired to the service, that is, data that needs to be transferred by the client and the service to implement the service.
S302: creating corresponding target data for each service according to the attribute of each service;
in this step, if there are N services (positive integer of N.gtoreq.1) in actionlib, then N 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; the running target data can enable the robot to execute target functions, and the target functions are functions which are executed by the robot through services corresponding to the running target data.
In this step, similar to a service in actionlib, a project label function in the embodiment of the present application can enable a robot to implement a behavior, which is implemented by a service on which creation of target data depends.
The main body performing S301 to S303 is a client. Because the target data is created by the client according to the attribute of the service in the actionlib, the created target data is data which has a certain association with the service in the actionlib, and the target data is operated, which is equivalent to realizing the direct call of the client to the actionlib service, without developing additional compiling language, and saving the cost.
In an alternative, as shown in fig. 4, S302 may further be:
s3021: obtaining at least the 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 the requested service; the second file is a file characterized as a service response result; the third file is a file characterized as a service response process;
S3022: creating a first target file corresponding to target data according to the attribute of the first file of each service;
s3023: creating a second target file corresponding to the target data according to the attribute of the second file of each service;
s3024: creating a third target file corresponding to the target data according to the attribute of the third file of each service;
s3025: and at least integrating the first target file, the second target file and the third target file into target data.
In the foregoing solution, it is assumed that the actionlib has a service 1, where the service 1 can implement a pile-back operation of the robot, and the target data created by the client according to the attribute of the service 1 is the target data 1. Among them, it is assumed that the target data 1 includes at least a target file 1 (first target file), a target file 2 (second target file 2), and a target file 3 (third target file). The client creates a gold file for the client to initiate request data to the server, that is, creates target data 1, according to the attribute of the file (first file) in service 1 that receives the request service. The client creates a file for the result returned by the client receiving the service, namely creates the target data 2 according to the attribute of the file (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, creates 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 through functions, the file can be regarded as a function file. The client and the server transfer data through functions, and at least functions, the number of functions, the order of functions, and the meaning represented by the functions for data transfer between the client and the server are to be corresponded or matched. That is, the client creates the corresponding function file at least according to the meaning, the number of functions, the order of functions, the implementation principle of the function file, and the like (attributes of the file) represented by each function in each function file in the service 1. The creation of each file of the client target data is performed according to the attribute of each file of the service in the actionlib of 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 description of S302.
In an alternative, in the case where the target data includes the target file 1, the target file 2, and the target file 3, as shown in fig. 5,
s303 is S303': said running said at least one target data, comprising:
operating a first target file, a second target file and a third target file of the target data;
the method comprises the steps that a first target file is operated to send a service request; running a second object 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 target files 1 to 3, the client runs each target file, sends gold to the server based on the running target file 1, receives the result fed back by the server based on the running target file 2, and receives the feedback fed back by the server based on the running target file 3. It can be understood that the client creates the target data based on the content required by the actionlib service of the server, such as the functions, the number of the functions, the sequence, the meaning and the like, and the creation can facilitate the direct call of the client to the actionlib service, thereby facilitating the smooth interaction between the client and the server.
In an alternative, before creating the first target file to the third target file, the method further includes:
creating a corresponding indication file for each target data; the indication file is at least used for indicating the service corresponding to the target data.
It will be appreciated that there are a variety of services for actionlib, and in order to facilitate the invocation of these services at the client, it is necessary to create a corresponding instruction file 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 functions are to be performed. In practical application, to implement the robot pile-back operation by using the service 1, the client should first run the instruction file corresponding to the service, 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 instruction file is run, so as to implement the call to the service.
In an alternative solution, S302, that is, creating the corresponding target data for each service, further includes:
obtaining the attribute of a fourth file and/or a fifth file of each service; the fourth file is a file characterized by receiving a service cancellation request, and the fifth file is a file characterized by a service request state;
Creating fourth target data and/or fifth target data corresponding to target data according to attributes of fourth files and/or fifth files of various services, wherein the fourth target data is a file characterized by canceling service requests generated based on the first target file; the fifth target data is a file characterized as a state 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 goal, feedback and result. The client creates the fourth target data, which corresponds to a file (fourth file) of the service for receiving status for a certain service, and creates a cancel (fourth target file) of the service. The creation of the fifth target data by the client corresponds to the creation of a file (fifth target file) for receiving status for a certain service, which is fed back by the server, according to a file (fifth file) for transmitting status for the certain service, which is generated by the server. The client creates the fourth target file and the fifth target file at least according to the meaning, the number of functions, the order of the functions, the implementation principle and the like (the attribute of the file) represented by each function in the fourth file and the fifth file in the service. Therefore, data transfer between the client and the server can be greatly facilitated.
The technical scheme of the embodiment of the application is further described below.
Assuming that the robot pile-back is implemented by the service 1 in actionlib as an example, the service 1 includes a function file (first file) for receiving a pile-back request sent by a client, a function file (second file) for feeding back a pile failure or success result to the client, and a function file (third file) for feeding back a pile process to the client.
For service 1, the client creates an indication file corresponding to service 1 for the server, as shown in fig. 6, where the indication file is a pileReturn action, and the operation of the indication file means that the client needs to call service 1 to perform a pile-back operation of the robot. In the embodiments of the present application,
as shown in fig. 6, the pilereturn actiongold file is a target file 1 for the back stub service that the client needs to create (the file that the client uses to send gold). The pileretaractionresult file is a target file 2 (a file used by the client to receive result) which needs to be created by the client and is used for receiving the pile result fed back by the server. The pileReturn Actionfeedback file is a target file 3 (a file for receiving feedback by a client) which needs to be created by the client and is used for receiving feedback of the server to the pile process.
It should be noted that the client creates a pileretaractionaction file according to the first file of the service 1, creates a pileretaractionresult file according to the second file of the service 1, and creates a pileretaractionfeedback file according to the third file of the service 1. In the creation process, the function variables, the number of variables, the meaning, and the order of the created target files all need to be consistent with the files of the service 1. The creation process is specifically described below by taking the pileReturn Actiongold file as an example: on the client side, the pileReturn Actiongold file is compiled using the JAVA language. As shown in fig. 6, the pileretaractiongold file includes a message Header (Header), a message identifier (golld), and a file body (pileretargo). The message header file is used for function declaration and interface declaration of the gold file, and can be created according to the header file of the service 1 in actionlib, and the variable in the message header file needs to correspond to the variable of the header file of the service 1. The message identification is used to identify the gold by identifying the timestamp + gold itself (as distinguished from a different gold). The file text is the JAVA language program for realizing successful sending of the gold. Wherein the message identification is automatically created for the client. And the file text carries out JAVA compiling of the gold file according to the analyzed realization principle of the service 1 to obtain the JAVA realization of the gold file. The variables, the quantity, the meaning and the sequence of the functions which need to be transferred to the server in the file text are consistent with those of the first file, so that the correct transfer of the function information in the target file and the first file can be ensured. It will be appreciated that the procedure for creating the pileretaractionresult and pileretaractionfeed back files is substantially the same as the procedure for creating the pileretaractionsource file described above, and the repetition is omitted. The golalstatus represents the execution state of the gold at the server, such as executing, stopping, etc. Colloquially, the process of creating a target file is essentially: the client creates a function that can pass the variables or parameters to complete the successful pass of the variables or parameters. Therefore, the client side realizes the transfer of parameters required by the server side through the created target file, and can smoothly realize the call of the server side actionlib. The above can be regarded as creation of each target file in the target data 1 (S701). The above description is given taking the example that the target data 1 includes the target file 1-the target file 3 as an example, and in addition, the target data 1 may further include the target file 4 and the target file 5. The creation of the target file 4 and the target file 5 is similar to the foregoing creation process, and a specific description will not be given here.
It will be appreciated that the PileReturn Actiongold file, pileReturn ActionResult, and PileReturn Actionfeed back files created as described above are actually implemented by JAVA functions, which 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 location where the pile is located (pile-returning operation). The client (ActionClient) calls (subscribes) the pileretaractionactive file from the central control to run, and issues the pileretaractionactive file to the server (S702), which is equivalent to sending the gold variable or parameter required by the server to execute the stub back to the server. Thus, the server side can execute the pile returning operation of the robot and feed back the result of the success or failure of pile returning and pile returning response process information (the position where the pile is returned by 1m and the position where the pile is returned by 0.5 m) to the client side. The client receives a pile returning success or failure result through a PileReturn Actionresult file; the reception of the back stub response procedure information is performed through the pileReturn Actionfeed file (S703).
In the foregoing scenario, it may be considered as three members of the instruction file pileretargent hold PileReturnActiongoal, pileReturnActionfeedback, pileReturnActionresult. The PileReturn Actiongold member is used for holding a pile returning gold parameter; the PileReturn Actionresult member holds data reflecting the success or failure of the response of the back-stub service; the pileReturn Actionfeedback member holds data reflecting the back stub service response procedure.
It should be appreciated that the PileReturnAction, pileReturnActiongoal file, the pileReturn Actionresult, and the pileReturn Actionfeed file created have respective interfaces that are logical interfaces, and may specifically be the storage addresses of the 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, if the target file 1 is stored at the addresses 0010 to 001F, the target file 1 is read from the storage addresses 0010 to 001F. Therefore, each target file can be conveniently called and operated.
In colloquial terms, if the xx feed back file is considered as a feedback of the client to the server in actionlib, the xx gold file is considered as a gold generated by the client for service 1 in actionlib, the xx result file is considered as a result of the feedback of the client to the server in actionlib, the xx gold file can be considered as a holding file of the pileReturn actionActiongold file, the xx feed back file can be considered as a holding file of the pileReturn Actionfeed back file, and the xx result can be considered as a holding file of the pileReturn Actionresult file. Equivalently, the client needs to call 7 class files using service 1 in actionlib: the PileReturn ActionFile, pileReturn Actiongold File, pileReturn Actionfeed Back File, pileReturn ActionResult File, xxGoal File, xxResult File, and xxFeedBack File. The xxActionfeed back file holds an xxFeedback file, which is equivalent to data reflecting a response process of the pile-back service; the xxActionresult holds an xxResult file, which is equivalent to holding data reflecting success or failure of response of the stub return service; the pileReturn Actiongold file holds the xxResult file, which is equivalent to holding the backspin gold parameters. On the application level, if the client side wants to use the service 1 to realize the pile-back operation of the machine, the above 7 class files need to be called, and the pile-back operation of the robot can be implemented. It can be inferred that, because the target data is created by the client according to the attribute of the service in the actionlib, the created target data is data with a certain association with the service in the actionlib, and the running of the target data associated with the actionlib service is equivalent to realizing the direct call of the client to the service in the actionlib without developing additional compiling language, thereby saving the cost. That is, the problem that the java client cannot directly call actionlib is solved, so that function use of the rosjava is enriched, and the rosjava can directly use actionlib services in the ros. Compared with the problems that in the related art, the client cannot obtain the real-time feedback of the robot and the robot cannot send the feedback to the client, the scheme in the embodiment of the application can be used for solving the problems. The problem that in the related art, an additional development interface or other compiling languages are needed for sending the feedback to the client is avoided, and the additional development interface or compiling language is not needed for normal transmission of the feedback through the additional development interface or compiling language, 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 a robot operating system library actionlib; wherein each service is capable of causing the robot to perform a function; the attribute is at least characterized by data that the service is to be executed for use;
a creating unit 802, configured to create corresponding target data for each service according to the attribute of each service;
an operation unit 803 for operating at least one target data in the client;
the running target data can enable the robot to execute target functions, and the target functions are functions which are executed by the robot through services corresponding to the running target data.
In an alternative scheme, the target data at least comprises a first target file, a second target file and a third target file; wherein the first target file is a file 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 the 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 the requested service; the second file is a file characterized as a service response result; the third file is a file characterized as a service response process;
creating a first target file corresponding to target data according to the attribute of the first file of each service;
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 alternative scheme, the running unit 803 is configured to run the first target file, the second target file, and the third target file of the target data;
the method comprises the steps that a first target file is operated to send a service request; running a second object 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 alternative, the creating unit 802 is configured to: creating a corresponding indication file for each target data; the indication file is at least used for indicating the service corresponding to the target data.
In an alternative, 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 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 for canceling the service; and creating fourth target data corresponding to the target data according to the attribute of the fourth file of each service.
In an alternative, the target data further includes fifth target data, the fifth target data being a file characterized as a status of a service request generated based on the first target file; in a corresponding manner,
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 by 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 will be appreciated that the obtaining unit 801, the creating unit 802, and the running unit 803 may be implemented by a central processing unit (CPU, central Processing Unit), a digital signal processor (DSP, digital Signal Processor), a micro control unit (MCU, microcontroller Unit), or a programmable gate array (FPGA, field-Programmable Gate Array) in practical applications.
It should be noted that, in the client of the embodiment of the present application, since the principle of the client for solving the problem is similar to that of the foregoing operation method, the implementation process and the implementation principle of the client may refer to the implementation process and the implementation principle description of the foregoing operation method, and the repetition is omitted.
Embodiments of the present application also provide a computer readable storage medium having a computer program stored thereon, wherein the program is at least for performing the steps of the method shown in any of fig. 1 to 7 when the program is executed by a processor. The computer readable storage medium may be a memory in particular. The memory may be the memory 62 shown in fig. 9.
The embodiment of the application also provides a terminal. Fig. 9 is a schematic hardware structure of a client according to an embodiment of the present application, as shown in fig. 9, where the client includes: a communication component 63 for data transmission, at least one processor 61 and a memory 62 for storing a computer program capable of running on the processor 61. The various components in the terminal are coupled together by a bus system 64. It is understood that the bus system 64 is used to enable connected communications between these components. The bus system 64 includes a power bus, a control bus, and a status signal bus in addition to the data bus. But for clarity of illustration the various buses are labeled as bus system 64 in fig. 9.
Wherein the processor 61, when executing the computer program, performs at least the steps of the method shown in any of fig. 1 to 7.
It will be appreciated that the memory 62 may be volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. Wherein the nonvolatile Memory may be Read Only Memory (ROM), programmable Read Only Memory (PROM, programmable Read-Only Memory), erasable programmable Read Only Memory (EPROM, erasable Programmable Read-Only Memory), electrically erasable programmable Read Only Memory (EEPROM, electrically Erasable Programmable Read-Only Memory), magnetic random access Memory (FRAM, ferromagnetic random access Memory), flash Memory (Flash Memory), magnetic surface Memory, optical disk, or compact disk Read Only Memory (CD-ROM, compact Disc Read-Only Memory); the magnetic surface memory may be a disk memory or a tape memory. The volatile memory may be random access memory (RAM, random Access Memory), which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as static random access memory (SRAM, static Random Access Memory), synchronous static random access memory (SSRAM, synchronous Static Random Access Memory), dynamic random access memory (DRAM, dynamic Random Access Memory), synchronous dynamic random access memory (SDRAM, synchronous Dynamic Random Access Memory), double data rate synchronous dynamic random access memory (ddr SDRAM, double Data Rate Synchronous Dynamic Random Access Memory), enhanced synchronous dynamic random access memory (ESDRAM, enhanced Synchronous Dynamic Random Access Memory), synchronous link dynamic random access memory (SLDRAM, syncLink Dynamic Random Access Memory), direct memory bus random access memory (DRRAM, direct Rambus Random Access Memory). The memory 62 described in the embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.
The method disclosed in the 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 with signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in the processor 61 or by instructions in the form of software. The processor 61 may be a general purpose processor, DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. Processor 61 may implement or perform the methods, steps, and logic blocks disclosed in embodiments of the present application. The 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 embodied in 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 in a memory 62. The processor 61 reads information from the memory 62 and, in combination with its hardware, performs the steps of the method as described above.
In an exemplary embodiment, the client may be implemented by one or more application specific integrated circuits (ASIC, application Specific Integrated Circuit), DSP, programmable logic device (PLD, programmable Logic Device), complex programmable logic device (CPLD, complex Programmable Logic Device), FPGA, general purpose processor, controller, MCU, microprocessor, or other electronic component for executing the aforementioned client.
In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above described device embodiments are only illustrative, e.g. the division of the units is only one logical function division, and there may be other divisions in practice, such as: multiple units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. In addition, the various components shown or discussed may be coupled or directly coupled or communicatively coupled to each other via some interface, whether indirectly coupled or communicatively coupled to devices or units, whether electrically, mechanically, or otherwise.
The units described as separate units may or may not be physically separate, and units displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units; some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may be separately used as one unit, or two or more units may be integrated in one unit; the integrated units may be implemented in hardware or in hardware plus software functional units.
Those of ordinary skill in the art will appreciate that: all or part of the steps for implementing the above method embodiments may be implemented by hardware associated with program instructions, where the foregoing program may be stored in a computer readable storage medium, and when executed, the program performs steps including the above method embodiments; and the aforementioned storage medium includes: a mobile storage device, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk or an optical disk, or the like, which can store program codes.
Alternatively, the integrated units described above may be stored in a computer readable storage medium if implemented in the form of software functional modules and sold or used as a stand-alone product. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially or partly contributing to the prior art, and the computer software product may be stored in a storage medium, and include several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) 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, ROM, RAM, magnetic or optical disk, or other medium capable of storing program code.
The methods disclosed in the several method embodiments provided in the present application may be arbitrarily combined without collision to obtain a new method embodiment.
The features disclosed in the several product embodiments provided in the present application may be combined arbitrarily without conflict to obtain new product embodiments.
The features disclosed in the several method or apparatus embodiments provided in the present application may be arbitrarily combined without conflict to obtain new method embodiments or apparatus embodiments.
The foregoing is merely 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 think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to 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. A method of operation for a client, the method comprising:
acquiring the attribute of at least one service in a robot operating system library actionlib; wherein each service is capable of causing the robot to perform a function; the attribute is at least characterized by data that the service is executed and requires the client and the server to communicate;
Creating corresponding target data for each service according to the attribute of each service; the target data at least comprises a first target file, a second target file and a third target file; the target data is data associated with a service in actionlib;
running at least one target data in the client;
the running target data can enable the robot to execute target functions, and the target functions are functions which are executed by the robot through services corresponding to the running target data.
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; wherein the first target file is a file 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 the corresponding target data for each service includes:
obtaining at least the 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 the requested service; the second file is a file characterized as a service response result; the third file is a file characterized as a service response process;
Creating a first target file corresponding to target data according to the attribute of the first file of each service;
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 said running said at least one target datum comprises:
operating a first target file, a second target file and a third target file of the target data;
the method comprises the steps that a first target file is operated to send a service request; running a second object 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 a corresponding indication file for each target data; the indication file is at least used for indicating the service corresponding to the target data.
5. The method according to claim 4, wherein the method further comprises:
The target data further comprises fourth target data, the fourth target data being a file characterized as canceling a service request generated based on the first target file;
correspondingly, the creating 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 cancellation 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 according to claim 4, wherein the method further comprises:
the target data further includes fifth target data, the fifth target data being a file characterized as being based on a state of the service request generated by the first target file; in a corresponding manner,
the creating corresponding target data for each service includes:
obtaining the attribute of a fifth file of each service, wherein the fifth file is a file characterized by 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:
an obtaining unit, configured to obtain an attribute of at least one service in the robot operating system library actionlib; wherein each service is capable of causing the robot to perform a function; the attribute is at least characterized by data that the service is executed and requires the client and the server to communicate;
The creation unit is used for creating corresponding target data for each service according to the attribute of each service; the target data at least comprises a first target file, a second target file and a third target file; the target data is data associated with a service in actionlib;
an operation unit for operating at least one target data in the client;
the running target data can enable the robot to execute target functions, and the target functions are functions which are executed by the robot through services corresponding to the running target data.
8. The client of claim 7, wherein the client is configured to,
the target data at least comprises a first target file, a second target file and a third target file; wherein the first target file is a file 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 creation unit is configured to:
obtaining at least the 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 the requested service; the second file is a file characterized as a service response result; the third file is a file characterized as a service response process;
Creating a first target file corresponding to target data according to the attribute of the first file of each service;
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, characterized in that the program, when being executed by a processor, implements the steps of the method of any 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, characterized in that the processor implements the steps of the method of any 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 CN111338820A (en) | 2020-06-26 |
| CN111338820B true 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 (8)
| 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 |
| 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 | 深圳市优必选科技有限公司 | Remote function call method based on C++ 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 |
| CN109995805A (en) * | 2017-12-29 | 2019-07-09 | 深圳市优必选科技有限公司 | A kind of management method of intelligent robot, 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 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7764965B2 (en) * | 2007-04-10 | 2010-07-27 | Microsoft Corporation | Dynamically changing service characteristics based on device and network connectivity attributes |
| CN109213611B (en) * | 2018-08-01 | 2021-07-02 | 天津字节跳动科技有限公司 | Cross-process communication method, device, terminal and storage medium |
-
2020
- 2020-02-24 CN CN202010113852.7A patent/CN111338820B/en active Active
Patent Citations (8)
| 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 |
| 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 | 深圳市优必选科技有限公司 | Remote function call method based on C++ 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 | 深圳市优必选科技有限公司 | A kind of management method of intelligent robot, terminal device and medium |
| CN110569179A (en) * | 2018-06-06 | 2019-12-13 | 富晋精密工业（晋城）有限公司 | Data acquisition system and data acquisition method |
Non-Patent Citations (1)
| Title |
|---|
| Norman Hendrich 等."助老服务机器人系统设计及软件架构".《Engineering》.2015,第1卷(第1期),第26-34页. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111338820A (en) | 2020-06-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8584081B2 (en) | Server side application integration framework | |
| US5546584A (en) | System and method for establishing communication protocols between application programs | |
| CN107678778B (en) | Hybrid-based compatible method, adapter, operation device and system | |
| CN110838071B (en) | Policy data processing method, device and server | |
| KR20060099392A (en) | Dynamic service generation for legacy components | |
| CN103092602A (en) | Software development kit and terminal apparatus | |
| CN111967236A (en) | Message processing method and device, computer equipment and storage medium | |
| EP3430792A1 (en) | Method and device for message sending and receiving based on a communication interface framework | |
| CN109725887B (en) | Data interaction method and device based on message research and development framework and terminal equipment | |
| Chopra et al. | Bungie: Improving fault tolerance via extensible application-level protocols | |
| CN111338820B (en) | Operation method, client and storage medium | |
| CN116755788A (en) | On-line rule modification method, device, equipment and storage medium | |
| CN114827297B (en) | Protocol adaptation method, device, equipment and storage medium | |
| US10645196B1 (en) | Multicomponent software-controllable system and a method for interaction of server-client processes and a machine-readable carrier for performing the method | |
| CN112235411B (en) | Server communication method, device, equipment and medium of RPA flow control terminal based on AI | |
| CN113918245A (en) | Data calling method, device, equipment and computer readable storage medium | |
| CN110191141B (en) | Service calling information processing method and device and computer system | |
| CN112769975B (en) | Data integration method and device, server and storage medium | |
| EP4155844A1 (en) | Remote function customization method and apparatus, device, and storage medium | |
| CN116800807A (en) | GPU resource remote calling method, device, equipment and storage medium | |
| CN117519728A (en) | Container mirror image deployment method, system, device, equipment and storage medium | |
| CN117648211A (en) | Runtime unified interface, server and calling method of artificial intelligent framework | |
| CN117742991A (en) | Method and device for acquiring user information by micro-service and electronic equipment | |
| CN112783492A (en) | Method and device for rendering driving form applied to block chain management platform | |
| CN115794183A (en) | Upgrading method, upgrading device, electronic equipment and computer readable storage medium |
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 |