Inter-nuclear communication method and device and robot

Abstract

The embodiment of the invention provides an inter-core communication method and device and a robot, and the method comprises the steps: responding to a first processor of the robot, registering a request theme and a response theme corresponding to a target method in a shared memory of the robot, the first processor issues a request message at least comprising the target method and request data to the request theme; obtaining the request message in the request theme in response to a second processor of the robot, and processing the request data by the second processor based on the target method to obtain a response message including response data; and in response to a response message corresponding to the request message in the response theme, the first processor acquires the response data.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, and relate to but are not limited to an inter-core communication method and device and a robot. BACKGROUND

[0002] With the continuous improvement of the complexity of robot systems, multi-core processor architecture is widely used to improve the parallel processing capability and response efficiency of the system. In a multi-core environment, efficient and reliable information exchange is needed between different processors to cooperatively complete complex task control and data processing. Inter-core communication, as one of the key technologies for realizing multi-core cooperation, directly affects the running efficiency and stability of the entire system.

[0003] In related technologies, inter-core communication of a heterogeneous multi-core processing system usually relies on a remote processor messaging (RPMsg) protocol as a communication mechanism, and combines an open asymmetric multi-processing (OpenAMP) framework to realize support for remote processor life cycle management, resource scheduling and message transmission. However, in actual applications, the flexibility is poor, and it is difficult to adapt to the high-concurrency and low-latency communication requirements in robot systems, and cannot meet the high-standard requirements of complex robot systems for real-time communication. SUMMARY

[0004] To solve the problems in related technologies, embodiments of the present application provide an inter-core communication method, device and robot.

[0005] In a first aspect, the present application provides an inter-core communication method, which comprises: in response to a first processor of a robot registering a request topic and a response topic corresponding to a target method in a shared memory of the robot, the first processor publishes a request message including at least the target method and request data to the request topic; in response to a second processor of the robot obtaining the request message in the request topic, the second processor processes the request data based on the target method to obtain a response message including response data; and in response to the presence of the response message corresponding to the request message in the response topic, the first processor obtains the response data.

[0006] In some embodiments, the inter-core communication method further comprises: the first processor generates a request identifier of the request message based on a device address and a request sequence number of the first processor; the first processor serializes to-be-processed data to obtain the request data; and the first processor generates the request message based on the request identifier, the request data, the target method and a request response time length.

[0007] In some embodiments, the inter-core communication method further comprises: the first processor acquires a message in the response topic, compares a message identifier of the message with the request identifier, and obtains a comparison result; in response to the comparison result indicating that the message identifier is the same as the request identifier, the first processor determines the message as the response message; correspondingly, the first processor acquires the response data, including: the first processor parses the response message, and obtains the response data.

[0008] In some embodiments, after the first processor publishes the request message to the request topic, the inter-core communication method further comprises: in response to the response message not existing in the response topic after the request response duration, the first processor triggers a request retry mechanism; in response to the number of times of the request retry mechanism being equal to a preset threshold, the response message not existing in the response topic, the first processor stops acquiring the response message, and generates an error log; wherein the request retry mechanism comprises: updating the request sequence number, generating a new request message, publishing the new request message to the request topic, and acquiring the response message in the request topic after a first request response duration; the first request response duration is greater than the request response duration.

[0009] In some embodiments, the inter-core communication method further comprises: the second processor subscribes to the request topic; in response to the request message existing in the request topic, the second processor acquires the request message; the second processor checks the request message, and obtains a checking result; the checking at least includes format checking, uniqueness checking and timeliness checking of a request identifier of the request message; correspondingly, the second processor processes the request data based on the target method, and obtains a response message including response data, including: in response to the checking result indicating that the checking of the request message is passed, the second processor processes the request data based on the target method, and obtains a response message including response data.

[0010] In some embodiments, the second processor processes the request data based on the target method, and obtains a response message including response data, including: the second processor performs deserialization processing on the request data, and obtains to-be-processed data of the first processor; the second processor performs logical processing on the to-be-processed data based on the target method, and obtains response data; the second processor generates the response message based on the response data and the request identifier; correspondingly, the inter-core communication method further comprises: the second processor publishes the response data to the response topic.

[0011] In some embodiments, the shared memory comprises a meta-information region; the inter-core communication method further comprises: in response to a registration request of the request subject and the response subject, the first processor acquires a spin lock of the shared memory, and locks the shared memory; the first processor traverses a subject information structure body of the meta-information region based on subject names of the request subject and the response subject respectively, and determines historical registration information of the request subject and the response subject; the first processor determines a request storage space of the request subject and a response storage space of the response subject in the shared memory based on the historical registration information; the first processor releases the spin lock; and correspondingly, the first processor publishes a request message comprising at least the target method and request data to the request subject, including that the first processor writes the request message to the request storage space.

[0012] In some embodiments, the first processor determines a request storage space of the request subject and a response storage space of the response subject in the shared memory based on the historical registration information, including: in response to the historical registration message representing that the request subject and the response subject do not exist in the shared memory, the first processor registers the request subject and the response subject based on a number of subjects in the shared memory, determines a request subject index of the request subject and the request storage space, and a response subject index of the response subject and the response storage space; the request storage space and the response subject space are unused regions in the shared memory; and in response to the historical registration message representing that the request subject and the response subject exist in the shared memory, the first processor determines a data region corresponding to the request subject and the response subject in the shared memory as the data storage space.

[0013] In a second aspect, the embodiments of the present application provide an inter-core communication device, which comprises: a publishing module configured to, in response to a first processor of a robot registering a request subject and a response subject corresponding to a target method in a shared memory of the robot, the first processor publishing a request message comprising at least the target method and request data to the request subject; a processing module configured to, in response to a second processor of the robot acquiring the request message in the request subject, the second processor processing the request data based on the target method to obtain a response message comprising response data; and an acquiring module configured to, in response to the response subject existing in the response message corresponding to the request message, the first processor acquiring the response data.

[0014] In a third aspect, an embodiment of the present application provides a robot, comprising: a memory configured to store executable instructions; a processor comprising at least a first processor and a second processor; the first processor is configured to, in response to a request topic and a response topic corresponding to a target method of a shared memory registration method of the robot, publish a request message comprising at least the target method and request data to the request topic; the second processor is configured to, in response to obtaining the request message in the request topic, process the request data based on the target method to obtain a response message comprising response data; and the first processor is further configured to, in response to the response topic containing the response message corresponding to the request message, obtain the response data.

[0015] In some embodiments, the first processor is further configured to generate a request identifier of the request message based on a device address and a request sequence number of the first processor; the first processor is further configured to serialize the to-be-processed data to obtain the request data; and the first processor is further configured to generate the request message based on the request identifier, the request data, the target method, and a request-response time length.

[0016] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium storing executable instructions, which are used to cause a processor to execute the executable instructions to implement the inter-core communication method.

[0017] In a fifth aspect, an embodiment of the present application provides a computer program product, which comprises executable instructions stored in a computer-readable storage medium; when a processor of a robot reads the executable instructions from the computer-readable storage medium and executes the executable instructions, the inter-core communication method is implemented.

[0018] The embodiments of the present application realize zero data copying by dynamically creating a request topic and a response topic in a shared memory, the first processor publishes a request message to the request topic, and the second processor obtains the request message from the request topic and processes the request message, thereby reducing intermediate links of data transmission and improving the efficiency of data processing, so that multiple cores can efficiently communicate with each other; the second processor processes the request data while the first processor can continue to execute other tasks, thereby realizing parallel processing and improving overall performance; the function of the robot can be extended by defining new topics without the need to make a large number of modifications to the existing architecture, thereby improving the flexibility of inter-core communication; the embodiments of the present application can respond quickly in application scenarios with high real-time requirements, and are suitable for robot tasks that require fast data processing and decision-making.

[0019] The above description is only a summary of the technical solutions of the present application. In order to enable the technical means of the present application to be more clearly understood, and to be implemented according to the content of the description, and in order to enable the above and other purposes, characteristics and advantages of the present application to be more apparent and easy to understand, the following specific embodiments of the present application are described. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 is an optional flow diagram of the inter-core communication method provided by the embodiments of the present application Figure 1 ;

[0021] Figure 2 is an optional flow diagram of the inter-core communication method provided by the embodiments of the present application Figure 2 ;

[0022] Figure 3 is a structure partitioning diagram of shared memory provided by the embodiments of the present application;

[0023] Figure 4 is an interaction flow diagram of inter-core communication provided by the embodiments of the present application;

[0024] Figure 5 is a message structure diagram provided by the embodiments of the present application;

[0025] Figure 6 is a hardware entity diagram of a robot provided by the embodiments of the present application. DETAILED DESCRIPTION

[0026] In order to make the purposes, technical solutions and advantages of the present application more clear, the following will further describe the present application in combination with the drawings, and the described embodiments should not be regarded as limiting the present application. All other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0027] In the following description, "some embodiments" are described, which describe a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict. Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application are the same as the meanings commonly understood by those skilled in the art of the technical field to which the embodiments of the present application belong. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0028] In the field of robots, upper algorithms include perception, navigation, mapping, planning, etc. The complex algorithm level needs a strong real-time execution module of the bottom layer to support, so the robot has a high real-time requirement for the execution module. Under the heterogeneous core architecture, the link consumption can be reduced to the maximum extent, and the performance requirements of the robot can be adapted.

[0029] Currently in a multi-core heterogeneous system (for example, a combination of Cortex-A and Cortex-R, Cortex-M cores), efficient and reliable data communication and cooperative control between different cores are needed. The current architecture based on RPMsg+OpenAMP supports remote processor life cycle management, resource scheduling and message transmission.

[0030] RPMsg is a lightweight inter-core communication protocol designed for heterogeneous multi-core systems, used for message-level communication between the master core and the slave core of Linux. OpenAMP is a higher-level software framework based on RPMsg, which provides a complete set of middleware for inter-core communication, resource management, and remote core life cycle control in a heterogeneous system.

[0031] Although the RPMsg+OpenAMP architecture is relatively mature and widely used, there are still many technical limitations and deficiencies in actual use, including: due to the dependence on virtio device model and libmetal for platform abstraction, and the need to adapt to underlying interrupts and memory resources, RPMsg and OpenAMP are more complex to integrate and transplant in lightweight real-time operating systems (RTOS, Real-Time Operating System) or bare-metal environments. Frequent interrupts, limited scheduling efficiency. Each two domains consists of independent channels, causing multi-domain communication isolation, and communication channel sharing between multiple domains, resulting in a significant reduction in communication efficiency. Linux side does not support multiple processes to open RPMsg mapping devices simultaneously, and cannot achieve distributed communication, requiring a central process to forward read and write, resulting in low communication efficiency. The master-slave relationship between different cores is strongly dependent on the start-up logic, and the bind / unbind logic is complex, making it difficult to implement dynamic registration, which will limit the flexibility and performance of application startup. Single packet data is limited to 512 bytes, which is not friendly to large packet applications, and 0 is also transmitted to 512 bytes for small packet data, increasing system resource consumption and latency consumption, resulting in low communication efficiency.

[0032] Based on this, the embodiment of the present application can provide an inter-core communication method, in response to the first processor of the robot registering the request topic and the response topic corresponding to the target method in the shared memory of the robot, the first processor publishes the request message including at least the target method and the request data to the request topic; in response to the second processor of the robot obtaining the request message in the request topic, the second processor processes the request data based on the target method to obtain the response message including the response data; in response to the presence of the response message corresponding to the request message in the response topic, the first processor obtains the response data.

[0033] In this way, by dynamically creating the request topic and the response topic in the shared memory, the first processor publishes the request message to the request topic, the second processor obtains the request message from the request topic and processes it, zero data copy is realized, the intermediate link of data transmission is reduced, the efficiency of data processing is improved, efficient communication between multiple cores is enabled, the first processor can continue to perform other tasks while the second processor processes the request data, parallel processing is realized, and the overall performance is improved, the function of the robot can be extended by defining a new topic, without the need to make a large number of modifications to the existing architecture, the flexibility of inter-core communication is improved, and the application embodiment can realize fast response in an application scenario with high real-time requirement, and is suitable for robot tasks requiring fast data processing and decision-making.

[0034] Here, the new topic can be a regular medication reminder, which can be used on a nursing robot. The nursing robot reminds the old people to take medicine through the topic at a fixed time every day, and records the taking medicine situation, and the family members or nursing staff can remotely query the record. The new topic can also be an order notification, which can be used on a meal delivery or hotel robot. After the guest room orders, the order information is transmitted to the robot to trigger the meal delivery process. The robot obtains the order state and goes to the kitchen to take the meal and delivers it to the corresponding guest room. The above scheme does not need to modify the robot architecture, and can extend new functions based on the existing modules.

[0035] In the embodiment of the application, inter-core communication can refer to data exchange and collaborative processing process between different processor cores (such as Cortex-A and Cortex-R / M) in a multi-core system through shared memory or other mechanisms. The goal is to realize efficient, reliable and low-latency cross-core data interaction. The inter-core communication method provided by the embodiment of the application can be applied to the field of autonomous driving, industrial robots and other fields that require processing of high-frequency sensor data and real-time control instructions, which have very high time efficiency requirements.

[0036] In the embodiment of the application, the remote procedure call (RPC) architecture encapsulates two topics (request Topic and response Topic) based on pub / sub to realize request and response, and realize bidirectional communication.

[0037] The embodiment of the application can adopt a client-server (C / S) model, realize cross-core remote procedure call based on shared memory, and be used in a heterogeneous computing environment (such as an ARM+R5 multi-core system). The core interaction process can include that the client (Core1) initiates an RPC request, constructs a request message and blocks to wait for a response; the shared memory (SHM) is used as a communication medium, stores request / response Topic data, and provides an atomic access mechanism; the server (Core 2) listens to the request Topic, parses and executes the method, and returns the result to the response Topic.

[0038] For example, in a robot task, multiple different modules may need to work together, such as a navigation module, a visual recognition module, and a robot arm control module. The navigation module can dynamically create a request node for requesting the visual recognition module to analyze the surrounding environment; at the same time, the robot arm control module can dynamically create a service node to provide an interface for robot arm operation. Through the topic index, each module can conveniently find the corresponding communication node to achieve efficient message passing.

[0039] The technical solutions of the present application will be described in detail below with reference to the accompanying drawings.

[0040] Figure 1 is an optional flowchart of the inter-core communication method provided by the embodiments of the present application Figure 1 The execution subject of the inter-core communication method provided by the embodiments of the present application is a first processor and a second processor of a robot, the first processor can be a client, for example, a sensor data processing unit (such as a LiDAR point cloud processing module) or a real-time control instruction generation module of the robot, and the second processor can be a server, for example, a motion control module (such as a motor drive).

[0041] In some embodiments, the first processor and the second processor can also be one of a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC).

[0042] As shown in Figure 1 The inter-core communication method provided by the embodiments of the present application can be implemented through steps S101 to S103:

[0043] S101, in response to the first processor of the robot registering a request topic and a response topic corresponding to a target method of the robot in a shared memory of the robot, the first processor publishes a request message including at least the target method and request data to the request topic.

[0044] In the embodiments of the present application, the first processor can be any one processing core in the robot, used to initiate a remote call request. For example, a main processing unit (MPU), which is a processing unit used to generate or collect data, such as a sensor data processing module or a control instruction generation module.

[0045] Here, the shared memory can refer to a physical memory region shared by multiple processor cores in a heterogeneous multi-core system. The region is accessed by each core through memory mapping, supports zero-copy data transmission, and can avoid the additional overhead caused by traditional message middleware or protocol stacks, thereby improving communication efficiency.

[0046] In some embodiments, the request topic and the response topic are a set of topic names used to identify the communication direction. Among them, the request topic is used by the first processor (for example, the client) to publish a request message, and the response topic is used by the second processor (for example, the server) to return the result. Each request topic corresponds to a unique response topic to ensure the matching relationship between the request and the response. For example, in an addition operation, the client can create a request topic named Request_Add, and synchronously create a response topic named Reply_Add, so that the second processor listens and returns the calculation result.

[0047] In some embodiments, the request message can be a message body containing at least target method name, request data and other information. It is built by the client and published to the request topic to trigger the server to perform remote call. For example, if the target method is Add, the request message can contain two integer parameters representing the data to be added, and can also contain a request identifier composed of a device unique identifier and an incremental sequence number (for example, a universally unique identifier (UUID)), to prevent conflicts between multiple clients.

[0048] In the embodiments of the present application, after the first processor registers the request topic and the response topic corresponding to the target method in the shared memory, the first processor can publish the request message including the target method and the request data to the request topic, so that the second processor subscribed to the request topic can process the request data. In this way, the first processor can establish a communication connection with other cores, and compared with the RPMsg+OpenAMP scheme in the related art, it does not depend on a specific master-slave architecture and master core start sequence, and has higher flexibility and deployment convenience.

[0049] In some embodiments, the first processor needs to acquire a spin lock of a shared memory head area when registering a request topic and a response topic, to ensure atomic update of meta information. Subsequently, the first processor traverses a topic table to determine whether the request topic and the response topic exist, and allocates a new segment offset address and initializes related structures if the request topic and the response topic do not exist.

[0050] S102, in response to the second processor of the robot acquiring the request message in the request topic, the second processor processes the request data based on the target method, to obtain a response message including response data.

[0051] In the embodiments of the present application, the second processor can be another processing core in the robot different from the first processor, and is configured to receive a request and execute corresponding business logic. After the first processor publishes the request message to the request topic, the second processor listens to the topic, and starts a processing flow as soon as a new request message is detected.

[0052] The target method can be a service function, such as addition (Add) or multiplication (Multiply), which the first processor wants to remotely call. After the second processor receives the request message, the second processor can first verify the legality of the request message, including checking whether the UUID is valid, and then finds corresponding execution logic according to the target method name. For example, if the target method is Add, the second processor deserializes two integers in the request data and performs addition operation.

[0053] Here, the response message can be a message body generated and published by the second processor, and includes the UUID of the original request message and the execution result. In order to ensure that the response message can be accurately received by the original requester, the response message must be published to a response topic corresponding to the request topic. For example, if the request topic is Request_Add, the response topic should be Reply_Add.

[0054] S103, in response to the response message corresponding to the request message existing in the response topic, the first processor acquires the response data.

[0055] In the embodiments of the present application, the second processor publishes the response message to the response topic after completing the request processing. At this time, the first processor subscribes to the response topic and waits for the arrival of the response message. When the response message arrives, the first processor checks whether the UUID of the response message matches the request message published by the first processor, and only the response message matching the request message is further processed, and the remaining responses are ignored.

[0056] Here, the response data is the execution result parsed from the response message, such as the sum after addition operation or error code if the calculation is not performed, etc. After obtaining the response data, the first processor can perform subsequent processing according to actual needs, such as updating the user interface, storing the result or triggering other operations.

[0057] In the embodiment of the application, the entire communication process is implemented through shared memory, without the need to copy data to complete cross-core transmission, achieving zero-copy transmission and greatly reducing communication delay. At the same time, since a distributed model is adopted, there is no strict master-slave dependency relationship between cores, achieving a more flexible system architecture design of the robot.

[0058] In the embodiment of the application, the request topic and the response topic are dynamically created in the shared memory, the first processor publishes the request message to the request topic, and the second processor obtains the request message from the request topic and processes it, achieving zero data copying, reducing the intermediate link of data transmission, improving the efficiency of data processing, and enabling efficient communication between multiple cores; while the second processor processes the request data, the first processor can continue to perform other tasks, achieving parallel processing and improving overall performance; by defining new topics, the function of the robot can be extended without the need to make a large number of modifications to the existing architecture, improving the flexibility of inter-core communication; the embodiment of the application can respond quickly in application scenarios with high real-time requirements, and is suitable for robot tasks that require fast data processing and decision-making.

[0059] In some embodiments, the inter-core communication method can further include steps S1 to S3:

[0060] S1, the first processor generates a request identifier of the request message based on a device address of the first processor and a request sequence number.

[0061] In some embodiments, the device address can be a unique physical or logical address assigned to the first processor in a heterogeneous multi-core system, used to identify the identity of the request initiator. The address can be a MAC address, an IP address at the hardware level, or a virtual node ID at the software level. Through the device address, the system can identify the request source and route and distribute among multiple cores.

[0062] In some embodiments, the request sequence number can be an increasing integer, used to distinguish different requests sent by the same device. Each time a request is sent, the system will automatically generate a unique sequence number to ensure the orderliness and traceability of the request. The request sequence number can be used in combination with a timestamp to avoid duplicate requests or request loss.

[0063] Here, the request identifier can be a unique string composed of a combination of device address and request sequence number, used to uniquely identify a request operation. The identifier remains unchanged throughout the communication process, helping the system to track the request status and prevent message confusion and conflict. The request identifier can also be used for log recording and error diagnosis.

[0064] In this way, the request identifier can provide a globally unique identifier for each request, so that concurrent requests can be effectively managed and request conflicts or repeated processing can be avoided, thereby improving the stability and reliability of the system.

[0065] S2, the first processor serializes the to-be-processed data to obtain the request data.

[0066] In some embodiments, serialization can refer to the process of converting complex data structures (such as objects, arrays, structures, etc.) into a continuous byte stream or other linear format. Here, serialization can be the process of converting the to-be-processed data of the application layer into a standard format that can be transmitted in shared memory, facilitating cross-core parsing and processing. Serialization formats can include TLV (Tag-Length-Value), JSON, Protobuf, etc.

[0067] Request data is the data content in binary or text format after serialization, containing the parameter information required for calling remote methods. These data must meet the compatibility requirements across platforms and languages, so that processors on different cores can correctly parse and execute the corresponding methods. In this way, efficient transmission and parsing of data between different processors can be ensured, thereby improving communication efficiency and enhancing the stability of communication.

[0068] S3, the first processor generates the request message based on the request identifier, the request data, the target method, and the request response time length.

[0069] In the embodiments of the present application, the request message can refer to a complete communication unit encapsulating the request identifier, request data, target method, and request response time length. The message is used to be published in shared memory and subscribed and processed by the server. The structure of the request message can include two parts: header (Header) and payload (Payload), where the header can contain meta information (such as request identifier, target method name, response time length, etc.), and the payload contains the actual request data.

[0070] Here, the target method refers to the specific function or interface name that the first processor wants to remotely execute, which is used to guide the second processor to select the correct processing logic. The naming of the target method has a unified specification, so that the system can correctly route and schedule the request.

[0071] In some embodiments, the request response duration can refer to a maximum time limit that the client expects to wait for the second processor to return a response. If the second processor fails to complete processing and return a result within the request response duration, the first processor will consider this request to have failed, and can trigger a retry or exception handling mechanism. The request response duration can be dynamically configured according to a quality of service (QoS) level to adapt to different application scenarios.

[0072] In this way, the unified management of requests can be implemented through a standardized message format, so that various types of service calls can be supported, thereby improving the flexibility and scalability of the system.

[0073] Embodiments of the present application generate a unique request identifier through the first processor address and the request sequence number, ensuring that each request message is unique, thereby avoiding request conflicts or confusion. In combination with the serialized request data and the target method, a structured request message is constructed, facilitating subsequent processing and analysis. In addition, the request response duration is introduced as the basis of the timeout mechanism, providing a basis for request retries, thereby enhancing the reliability and fault tolerance of communication.

[0074] In some embodiments, the inter-core communication method can further include steps S4 to S5:

[0075] S4, the first processor acquires the message in the response subject, compares the message identifier of the message with the request identifier, and obtains a comparison result.

[0076] In some embodiments, the message identifier is retained throughout the communication process and is returned by the second processor to the first processor in the response phase, so that the first processor can confirm whether the response belongs to the request it sent.

[0077] After the first processor in the embodiments of the present application acquires the message in the response subject, it can compare the message identifier of the message with the request identifier to determine whether the currently received message is a response to the request message. This effectively prevents the thundering herd effect that can occur when multiple first processors send requests simultaneously, i.e., multiple first processors mistakenly receive response messages of other requests, thereby improving the stability and communication efficiency of the system.

[0078] Embodiments of the present application introduce a comparison mechanism between the message identifier and the request identifier, which can achieve high-precision message matching in a multi-core heterogeneous system, thereby improving the reliability and security of inter-core communication. In this way, message confusion can be effectively avoided, thereby ensuring that each first processor only processes responses related to its request, thereby optimizing system resource utilization and reducing error rates.

[0079] S5, in response to the comparison result representing that the message identifier is identical to the request identifier, the first processor determines the message as the response message.

[0080] Here, when the message identifier matches the request identifier successfully, the system regards the message as the response message corresponding to the request message. The response message is the data packet returned by the second processor after executing the request of the first processor, and usually contains the UUID of the original request and the execution result.

[0081] Correspondingly, the first processor obtaining the response data in step S103 can include the first processor parsing the response message to obtain the response data.

[0082] In some embodiments, parsing can refer to extracting the data encapsulated in the response message and restoring it to the structured data required by the original business logic. The parsing process can include operations such as deserialization, integrity checking, signature verification, etc.

[0083] In some embodiments, the parsing process also needs to consider the consistency and security of the data. For example, in a robot control system, if an abnormal data is carried in a response message, it may cause incorrect control instructions and affect the stability of the system. Therefore, the parsing stage can also add mechanisms such as cyclic redundancy check (CRC), data type checking, etc. to ensure the reliability of the response data.

[0084] The embodiments of the present application introduce the comparison mechanism based on the message identifier and the request identifier and the parsing process of the response message, which realizes efficient inter-core communication control, can ensure the correct matching of the request and the response, thereby improving the accuracy and reliability of the communication, and further improving the overall performance of task scheduling and data interaction in the heterogeneous multi-core system.

[0085] In some embodiments, in order to improve the concurrency and service quality of the robot, a timeout mechanism and a retry strategy can also be introduced. If the first processor does not receive a response within a set time, it will automatically initiate a retry until it successfully receives a response or reaches the maximum number of retries.

[0086] Therefore, after the first processor publishes the request message to the request topic, the inter-core communication method can further include steps S6 and S7:

[0087] S6, in response to the absence of the response message in the response topic after the request response duration, the first processor triggers a request retry mechanism.

[0088] In some embodiments, the request response duration can refer to the maximum allowed time for the first processor to wait for the server to return a response after sending a request message to the request topic. This duration can be configured according to the business scenario and QoS (Quality of Service) level, to determine whether the current request has timed out without a response. For example, in a low-latency sensitive control application, the request response duration can be set to 50 ms; while in a non-real-time data acquisition scenario with high requirements, it can be set to 500 ms or longer. By setting the request response duration, resource waste or deadlock problems caused by long waiting time can be avoided while ensuring the response efficiency of the robot.

[0089] In the embodiments of the present application, the request response duration is set to determine whether to enter the retry process, which can timely detect communication abnormalities and improve the reliability of robot control, preventing the entire communication link from being blocked due to a single request failure.

[0090] S7, in response to the number of request retry mechanisms being equal to a preset threshold, the response message is not present in the response topic, the first processor stops obtaining the response message, and generates an error log; wherein the request retry mechanism includes updating the request sequence number, generating a new request message, publishing the new request message to the request topic, and obtaining the response message in the request topic after a first request response duration; the first request response duration is greater than the request response duration.

[0091] In some embodiments, the preset threshold can be the maximum number of request retries set by the user or the processor according to the actual application scenario. When the number of retries reaches the threshold and no valid response is received, further retry operations are terminated, and an error log is recorded for subsequent debugging or troubleshooting. This mechanism can effectively prevent resource exhaustion caused by infinite loop retries, while ensuring that communication is attempted to be restored within a reasonable range. For example, the preset threshold can be set to 3 times, and each retry interval is gradually increased (exponential backoff strategy) to reduce the impact on system performance.

[0092] Here, the request sequence number is the number of request identification, and the sequence number is incremented each time the first processor initiates a new request, to distinguish different request instances. In the request retry process, the system can update the sequence number based on the information of the last request, generate a new request message, and publish it to the same request topic again. The first request response duration refers to the length of time the system waits for a response under the request retry mechanism, which can be longer than the initial request response duration to accommodate possible network fluctuations or server processing delays. For example, the initial request response duration is 500 ms, and the first retry is extended to 750 ms, the second retry is extended to 1125 ms, and so on, forming an exponential backoff mechanism.

[0093] In the embodiments of the present application, by introducing the request retry mechanism, dynamically adjusting the request response time length, and generating error logs, temporary failures in the communication process can be effectively dealt with, thereby improving the reliability and robustness of inter-core communication, and further supporting more complex and higher real-time requirement application scenarios. By updating the request sequence number and using the exponential backoff retry mechanism, request conflicts can be avoided, the retry success rate can be improved, the continuity and stability of communication can be ensured, and the fault tolerance of the system in complex environments can be improved. By setting an upper limit for the number of request retries and generating error logs, the system burden caused by invalid retries can be avoided, the communication stability and resource utilization can be improved, and the overall system efficiency can be improved.

[0094] Figure 2 is an optional flow diagram of an inter-core communication method provided by the embodiments of the present application Figure 2 The inter-core communication method provided by the embodiments of the present application can also be implemented by steps S201 to S203:

[0095] S201, the second processor subscribes to the request topic.

[0096] In some embodiments, the second processor subscribing to the request topic can mean that the second processor listens to the request topic through a registration mechanism, so that when a message under the topic is subsequently received, it can be processed. Here, the request topic is a namespace used by the first processor to publish a remote method call (RPC, Remote Procedure Call) request, and the second processor listens to and responds to the request by subscribing to the topic.

[0097] In some embodiments, the request topic can be a logical message classification identifier used to distinguish different types of requests. Each request topic can follow the Request_ <method>The naming rule is, for example, Request_Add, which indicates a request channel for an addition operation. The request topic and the response topic are paired to ensure the correspondence between the request and the response.

[0098] In some embodiments, the second processor can find and register the corresponding request topic by accessing the Header area in the shared memory. After the registration is completed, the second processor subscribes to the request topic, and will be notified when a new request message is published to the topic, and processes the request message.

[0099] The second processor of the embodiments of the present application can efficiently listen to and process cross-core requests by subscribing to the request topic, avoiding the communication isolation problem caused by the fixed channel limitation in the traditional RPMsg+OpenAMP architecture. In this way, the flexibility of inter-core communication can be improved, so as to support a dynamically expandable communication model, and thus the concurrent processing capability of the system can be improved.

[0100] S202, in response to the occurrence of the request message in the request topic, the second processor acquires the request message.

[0101] In some embodiments, when the first processor writes the request message into the shared memory, the second processor receives an event notification and acquires the request message accordingly. The process of acquiring the request message includes reading the request content from the shared memory, parsing its structure, and verifying its integrity. The zero-copy mechanism is adopted in the embodiments of the present application, and the request message is directly stored in the shared memory without additional copying, so that the data transmission efficiency is improved.

[0102] In some embodiments, when a sensor module in the robot control system initiates a state query request, the request will be published in the form of a request message to a designated topic. The main controller as the second processor can acquire and process the request in time by subscribing to the topic.

[0103] The second processor can quickly respond to cross-core requests without increasing the system overhead by quickly acquiring the request message, which can reduce the communication delay, so as to improve the real-time control performance, and thus the demand for high-precision robot control can be met.

[0104] S203, the second processor verifies the request message to obtain a verification result; the verification at least includes format verification, uniqueness verification and timeliness verification of the request identifier of the request message.

[0105] Here, the checking of the request message can refer to the legality check of the content of the request message to ensure that it conforms to the expected data structure and business logic. During the checking process, the format checking can refer to verifying whether the request message is organized according to the predefined format, such as whether the field order, length, etc. is correct; the uniqueness checking can refer to checking whether the UUID carried in the request message is unique to prevent repeated or conflicting requests; the timeliness checking can refer to judging whether the request message is sent within the valid time to avoid processing of expired or invalid requests. These checking measures help to ensure the consistency and security of communication and prevent malicious or erroneous requests from interfering with the system.

[0106] In some embodiments, in the robot motion control task, if the timestamp of a certain remote call request is abnormal, it can indicate that there is a fault in the network or hardware. At this time, the second processor can refuse to process the request, thereby preventing misoperation.

[0107] Here, by performing multi-level checking on the request message, the second processor can effectively filter illegal or invalid requests, thereby improving the stability and security of the system, and thus avoiding system crashes or data errors caused by erroneous requests.

[0108] Correspondingly, step S102 can be implemented by step S1021:

[0109] S1021, in response to the fact that the checking result represents that the checking of the request message passes, the second processor processes the request data based on the target method to obtain a response message including response data.

[0110] Here, when the request message passes all the checks, the second processor will execute the corresponding processing logic according to the target method and parameters of the request and generate response data. The response data can be encapsulated into a response message and published to the response topic corresponding to the request topic for the first processor to receive and process.

[0111] In some embodiments, the response message can comply with Reply_ <method>The naming rule is, for example, Reply_Add, the UUID in the response message is consistent with that in the request message, so as to ensure the matching of the request and the response. The response message can also contain the execution result, error code and the like, so as to enable the first processor to perform subsequent processing.

[0112] In the robot system, when the path planning module sends a movement request to the motion control module, if the request passes the verification, the motion control module will execute the movement instruction and return the actual movement result to the path planning module.

[0113] By processing the request data based on the target method and generating a response message, the second processor realizes efficient cross-core RPC communication, which can simplify the development complexity of the distributed system, thereby improving the overall collaborative efficiency of the system, and further supporting more complex robot application scenarios.

[0114] In the embodiments of the application, by introducing the mechanisms of subscribing to a request topic, obtaining a request message, verifying the request content and generating a response message, an efficient and flexible inter-core communication scheme is realized, which can significantly improve the communication efficiency and reliability between heterogeneous systems, thereby optimizing resource utilization and system response speed, and further better adapting to the needs of high-performance computing scenarios such as robots.

[0115] In some embodiments, in the case where the verification result represents that the request message passes the verification, step S102 can also be implemented by steps S1022 to S1024:

[0116] S1022, the second processor deserializes the request data to obtain the to-be-processed data of the first processor.

[0117] In some embodiments, the request data is usually serialized in a specific format (such as TLV, JSON, etc.) before transmission, so as to facilitate cross-core communication and data consistency verification. The deserialization process is responsible for parsing these data and converting them into a structure or object that can be directly used by the business logic. There is a close data dependency between deserialization and subsequent logic processing. Only after deserialization is completed, the correctness of the request parameters can be ensured and used by the subsequent logic.

[0118] For example, in a robot system, a control command can contain multiple parameters such as target position coordinates, speed limits, etc., which must be restored to their original form through the deserialization operation, so as to be correctly recognized and executed by the control system.

[0119] In some embodiments, after receiving the request data, the second processor first parses the request content according to the predefined data format rule. For example, if the TLV format is used, the tag (Tag), length (Length) and value (Value) are read in sequence, and the tag is mapped to the corresponding service parameter. The parsed result forms a structured data object for subsequent logical processing module, ensuring efficient transmission and accurate parsing of data between different cores.

[0120] S1023, the second processor performs logical processing on the to-be-processed data based on the target method to obtain response data.

[0121] In some embodiments, the target method can refer to a service logic function predefined by the second processor, used to process requests from the first processor and generate corresponding response data. The execution of the target method usually involves a series of calculations, state judgments, resource accesses and other operations, depending on the nature of the request and system requirements. For example, in a robot system, the target method can be moving to a specified coordinate, adjusting the angle of a mechanical arm, etc.

[0122] In some embodiments, the deserialized to-be-processed data is the input parameter of the target method, and the output of the target method is the response data, which is published to the response request for further processing by the first processor, realizing the ordered execution and result return of cross-domain tasks in a heterogeneous multi-core system.

[0123] In some embodiments, when the second processor completes deserialization, it will pass the parsed parameters as input into the target method. For example, if the request method is Move To Position, the processor will call the predefined move control function and pass the target coordinates as parameters. After execution, the function returns the execution result or error information as part of the response data.

[0124] S1024, the second processor generates the response message based on the response data and the request identifier.

[0125] Here, the response message is a message encapsulating the response data in a specific format for transmission in shared memory and ultimately received and processed by the first processor. The response message can include the request identifier, response data, and possibly status code or error information.

[0126] In some embodiments, the request identifier ensures that the first processor can correctly identify and process the corresponding response data, avoiding data confusion caused by concurrent requests. For example, in a high-concurrency scenario, multiple first processors may send requests at the same time, and the second processor must ensure that each response is accurately returned to the corresponding first processor.

[0127] In some embodiments, the second processor encapsulates the request identifier together with the response data into a response message after generating the response data. The response message is usually constructed in a predefined format, for example, in a fixed header + data body manner, where the header contains the request identifier and the message type, and the data body contains the specific response content. In this way, it can be ensured that the response data is correctly written in the shared memory and efficiently read and parsed by the client.

[0128] Correspondingly, the inter-core communication method can also include step S11:

[0129] S11, the second processor publishes the response data to the response topic.

[0130] Here, the response topic is a communication channel for the first processor to subscribe to the response data, for the first processor to listen to and obtain the response data. Publishing to the response topic means writing the response data to the shared memory area and notifying the relevant subscribers that there is new data available for reading. The design of the response topic can support a multi-subscriber model, that is, one response data can be accessed and processed by multiple first processors at the same time.

[0131] In the distributed RPC model, the request topic is used for the first processor to send the request data, and the response topic is used for the first processor to receive the response data, which together form a complete communication loop, enabling the heterogeneous multi-core system to achieve efficient point-to-point communication without the need for central scheduling.

[0132] After generating the response message, the second processor writes the response data to the shared memory area corresponding to the response topic and updates the relevant notification mechanism (such as the Notify queue). The first processor can detect new data in the response topic by polling or interrupting and extract the required response content therefrom. For example, in a robot system, the master unit (MPU) can subscribe to multiple response topics to monitor the execution results of different coprocessors (SCPs) and make real-time decisions accordingly.

[0133] In the embodiments of the present application, by sequentially performing deserialization processing, logical processing, response message generation, and response data publishing operations on the second processor, the integrity and accuracy of request processing in cross-core communication are achieved. In this way, it can be ensured that the request data is correctly parsed and the target method is executed, so that the expected response data can be generated and then efficiently returned to the first processor through the response topic, improving the overall communication efficiency and stability of the system.

[0134] In some embodiments, when multiple processing units (such as Cortex-A and Cortex-R) need to work together, data exchange is performed through shared memory. The shared memory can include a header, which is a logical division in the shared memory, used to store system-level metadata and control information, such as a topic registry, a segment allocation pointer, and the like, and also used to manage the overall shared memory state and topic configuration. The header includes a next_valid_segment_offset_ for allocating a new storage segment, a topic_num_ representing the number of currently registered topics, a topic_lock_ for accessing the topic registry, and a topic_struct, which can support multiple topics, each topic including a topic_id, a length, a string name, and a start segment offset, a block number, and a buffer size per block, and the like.

[0135] By centrally managing the registered topics in the header, the embodiments of the present application enable each core to obtain the latest state of the topic by uniformly accessing the header in a multi-core environment, thereby avoiding repeated calculations or conflicts. In this way, the use efficiency of the shared memory and the consistency of data access can be improved, thereby reducing system complexity and improving communication performance, and further supporting high-concurrency and low-latency inter-core communication requirements.

[0136] The inter-core communication method provided by the embodiments of the present application can further include steps S21 to S24:

[0137] S21, in response to the registration request of the request topic and the response topic, the first processor acquires a spin lock of the shared memory, and locks the shared memory.

[0138] In the embodiments of the present application, the spin lock is a lightweight synchronization mechanism that can be used to protect shared resources from data inconsistency problems caused by concurrent access. When a processor attempts to access a critical data structure (such as a topic registry) in the shared memory, it will first acquire a spin lock to ensure that no other processor modifies the same data during access.

[0139] In the embodiments of the present application, the spin lock can be used to protect the key data structure in the shared memory, such as the topic registry in the Header area and the segment allocation pointer. When the first processor receives the registration request of the request topic or the response topic, it will first try to obtain the spin lock in the shared memory. Only after successfully obtaining the lock, the subsequent topic registration process will be continued, thereby avoiding the data conflict or destructive operation that may be caused by concurrent access of multiple cores.

[0140] In this way, locking the shared memory by the spin lock can prevent multiple processors from simultaneously modifying the key data structure of the shared memory, thereby ensuring the consistency and integrity of the data, and further improving the stability and reliability of the system.

[0141] S22, the first processor traverses the topic information structure body of the meta information area based on the topic name of the request topic and the response topic respectively, and determines the historical registration information of the request topic and the response topic.

[0142] In the embodiments of the present application, the topic name can be topic_id, which is a user-defined string identifier used to uniquely identify a communication topic. In the distributed inter-core communication provided in the embodiments of the present application, the topic name can be used as an index to find whether the request topic and the response topic have been published in the topic information structure body of the shared memory.

[0143] Here, the topic information structure body can be a predefined data structure in the shared memory, which is used to record the related information of each registered topic. For example, it can include the fields of topic_id, length, string name, starting segment offset, data block quantity, and each block data size. By traversing the topic information structure body array, it can be checked whether the request topic and the response topic have been registered. If they have been registered, the historical registration information such as the allocated segment offset address can be obtained.

[0144] In the embodiments of the present application, in the topic registration process, the processor will find the topic information structure body according to the name of the request topic and the response topic in turn, and judge whether the same topic exists. If it exists, it means that the topic has been registered; if it does not exist, it means that the topic has not been registered. This process ensures that the same topic will not be registered repeatedly, thereby avoiding communication conflict and resource waste.

[0145] In this way, repeated registration and resource waste can be avoided, and the flexibility and scalability of the robot system can be improved.

[0146] S23, the first processor determines the request storage space of the request topic and the response storage space of the response topic in the shared memory based on the historical registration information.

[0147] In the embodiment of the present application, the data storage space can refer to an actual data buffer allocated in the shared memory for a specific topic. Each topic can correspond to one or more data storage spaces, and each data storage space is composed of a plurality of data blocks, each of which can contain an independent read-write lock and a data buffer. Through the data storage space offset address in the historical registration information, the specific location of the topic in the shared memory can be calculated, and the available data block list thereof can be further determined. Here, the number of data blocks corresponding to the data storage space of each topic can be determined based on the number of data to be published to the data storage space. If a single data block cannot meet the storage requirement, multiple data blocks need to be allocated to ensure sufficient space to store the data to be published.

[0148] In the embodiment of the present application, the first processor calculates the location of the storage space required by the request topic and the response topic respectively according to the information recorded in the topic information structure, and allocates them at the corresponding location of the shared memory. This process ensures that each topic has independent storage space, thereby realizing data isolation and efficient communication management.

[0149] S24, the first processor releases the spin lock.

[0150] After completing the topic registration process, the first processor needs to release the spin lock acquired previously, so that other processors can continue to access the shared memory. The release of the spin lock is an atomic operation, which ensures that the release of the lock does not affect other processors waiting for the lock at the same time.

[0151] After releasing the spin lock, the related data structure in the shared memory enters an accessible state, and other processors can safely read or modify these data. This step is crucial to guarantee the overall concurrent performance and stability of the system. Here, releasing the spin lock not only means releasing the lock itself, but also involves updating related state variables, such as resetting the flag bit or notifying other processors that the lock has been released.

[0152] In this way, releasing the spin lock can ensure that other processors can access the key data structure in the shared memory in a timely manner, thereby improving the concurrent capability and response speed of the system, and further enhancing the performance and stability of the entire inter-core communication system.

[0153] In the embodiment of the present application, by dividing the meta-information area in the shared memory and using the spin lock mechanism to guarantee the consistency of data access, it can effectively prevent multiple processors from modifying the key data structure in the shared memory at the same time, thereby ensuring the consistency and integrity of the data, and further improving the stability and reliability of the system.

[0154] Correspondingly, step S101 can also be implemented through step S1011.

[0155] S1011, the first processor writes the request message into the request storage space.

[0156] In the embodiment of the present application, the first processor directly writes the request message into the request storage space in the shared memory without additional data copying. This zero-copy mode significantly reduces communication delay and improves the real-time performance and throughput of the system.

[0157] In the embodiment of the present application, by setting the meta information region in the shared memory and using the spin lock mechanism to synchronize the topic registration process, the data conflict problem caused by multi-core concurrent access can be effectively avoided. In this way, the uniqueness and consistency of each topic during registration can be ensured, thereby realizing efficient and reliable inter-core communication. Further, it can support stable operation of the distributed RPC model and improve the collaboration efficiency between heterogeneous cores in the robot system.

[0158] In some embodiments, step S23 can be implemented through steps S231 and S232:

[0159] S231, in response to the historical registration message representing that the request topic and the response topic do not exist in the shared memory, registering the request topic and the response topic based on the number of topics in the shared memory, determining the request topic index of the request topic and the request storage space, and the response topic index of the response topic and the response storage space; the request storage space and the response topic space are unused areas in the shared memory.

[0160] In some embodiments, the request topic index topic_num_ can refer to a unique index number in the shared memory for identifying a specific topic, which is dynamically allocated by the system according to the number of currently registered topics. The index value can uniquely point to the data structure and storage area corresponding to a certain topic. Through the index, the relevant data of the topic can be quickly found and accessed in the shared memory. For example, a topic_struct array is maintained in the Header region, and each topic is assigned a unique index value topic_num_ after registration, which is used for positioning and operating the topic in the subsequent communication process.

[0161] The response topic index can represent the unique index number of a certain response topic in the shared memory. When the first processor initiates a request, the second processor will generate a corresponding response topic according to the request topic and write the response data into the storage space corresponding to the response topic index. In this way, it can ensure that each request has a unique response channel and avoid data confusion or overlap.

[0162] Unused region refers to the shared memory space that is not currently occupied by any registered topic, which can be located in the part of the shared memory that has not been initialized, and the starting address thereof can be recorded by a system-maintained offset pointer (such as next_valid_segment_offset_). These regions can be dynamically allocated to newly registered topics as their exclusive data storage areas. The selection of the unused region needs to consider the memory fragmentation problem, and the selection of a continuous and large enough space is preferred to improve the memory utilization. For example, the next_valid_segment_offset_ field is maintained in the Header to record the starting position of the next available segment, and it is ensured that a suitable unused region can be found each time the allocation is performed.

[0163] In the embodiments of the present application, when it is detected that the request topic and the response topic have not been registered, the global lock (topic_lock_) in the shared memory header structure is first acquired to ensure the thread safety of the registration process. Then, the number of currently registered topics (topic_num_) is checked, and the next available position in the topic_struct array is found to create a new topic structure. The structure can include the request topic index, the response topic index, the topic name, the starting segment offset, the number and size of blocks, and other meta information. After the registration is completed, the system updates the global topic counter (topic_num_) and the offset address of the next available segment (next_valid_segment_offset_), and initializes the related segment and the event notification region (notify region) so that the subsequent data publishing and subscription operations can be normally performed.

[0164] S232, in response to the historical registration message representing that the request topic and the response topic exist in the shared memory, determining the data region corresponding to the request topic and the response topic in the shared memory as the data storage space.

[0165] In the embodiments of the present application, the historical registration message refers to the information record generated by the registration request issued by other processes or cores before, which contains the state of whether the topic is registered, the registration time, the identity of the registerer, and other metadata. By analyzing the historical registration message, the system can determine whether the request topic and the response topic have been registered, and accordingly decide whether to perform a new registration process or directly reuse the existing data region. The historical registration message can be saved in the topic_struct in the Header area, and the existence of the request topic and the response topic can be quickly determined by traversing the array.

[0166] The data storage space refers to a shared memory space that has been allocated to the request topic and the response topic, and can include a plurality of data blocks, each of which can be used to store data of one publication. Since the request topic and the response topic have been registered, the starting offset address in the existing shared memory can be directly referenced without re-allocating the memory. In this way, not only memory resources are saved, but also performance loss caused by frequent memory allocation / deallocation is reduced. For example, if a plurality of publishers want to publish data to the same topic, they can share the same data storage space and only need to distinguish different batches of data through different data blocks.

[0167] In some embodiments, if it is detected that the request topic and the response topic already exist in the shared memory, repeated registration is not needed, but the existing topic configuration is directly reused. The overhead caused by repeated registration is reduced, and the system running efficiency is improved.

[0168] Here, the data area of the request topic and the response topic refers to the storage space in the shared memory that has been allocated to the topic, and usually includes a plurality of block buffer areas, each of which can have an independent lock mechanism to support concurrent read / write operations. The state, data length, sequence number, etc. of each block can be obtained by accessing the segment_block[m] structure, so as to determine whether the block can be used for data writing or reading.

[0169] In some embodiments, when it is found that the request topic and the response topic already exist, the registration process is skipped and the data access stage is directly entered. For example, in the process of one RPC call, the first processor sends a request message and checks whether the target request topic exists. If the target request topic exists, the request data is directly written into the corresponding block buffer area, and the response is waited for. When the second processor listens to the response topic, the allocated buffer is directly accessed, and the response logic is parsed and executed. The performance loss caused by repeated registration is avoided, and the continuity and consistency of data transmission are ensured.

[0170] In the embodiments of the present application, the storage space of the request topic and the response topic is dynamically allocated in the shared memory, which not only solves the problem of limited number of channels in traditional inter-core communication, but also improves the flexibility and real-time performance of communication in a multi-core environment. In this way, the system resource occupation can be effectively reduced, so that the communication delay and throughput can be optimized, and the communication requirements in a high-concurrency and low-latency scenario can be met.

[0171] Next, an application of an inter-core communication method in an actual scenario is provided.

[0172] To solve the problems in the related art, embodiments of the present application provide a set of general and efficient distributed inter-core communication solutions based on the shared memory region between heterogeneous cores. A distributed design idea is adopted, and client / server nodes are dynamically created based on topics as indexes, and the shared memory regions corresponding to different topics are dynamically allocated. The solution supports multi-core data sharing, flexible configuration of the number and size of buffers, multi-reader / multi-writer, a relatively complete data asynchronous security mechanism, an RPC (client / server) communication model, zero-copy of data, and a polling mechanism for a notification mechanism.

[0173] Figure 3 is a structure division schematic diagram of the shared memory provided by the embodiments of the present application, as shown in Figure 3 The shared memory structure is divided into three parts: a Header area 301, a Notify area 302, and a Segment area 303 (which can be multiple, for example, Segment 303-1 to Segment 303-n).

[0174] The Header area 301 (i.e., the meta-information area) is used to manage the overall shared memory state and topic configuration. It contains: next_valid_segment_offset_: used to allocate a new segment; topic_num_: the number of currently registered topics; topic_lock_: a lock for accessing the topic table; topic_struct

[100] : supporting a maximum of 100 topics, each topic containing: topic_id, length, string name; starting segment offset, block number, and each block buffer size information. uint64_t in the figure is used to represent an unsigned 64-bit integer data type, which can store large values, for example, to store memory addresses; Spin_lock topic_lock_ is a spin lock mechanism in the Header; struct topic_struct

[100] indicates that a structure body array named topic_struct is defined in the Header, with a size of 100; topic_valid_ (validity flag), topic_id_, topic_len_ (length of the topic name or other related string data), topic_str_ (store the name of the topic or other descriptive string information), segment_offset_ (segment offset address corresponding to the topic), block_num_ (number of data blocks allocated for each topic), and block_buffer_size_ (buffer size of each data block) are included in topic_struct.

[0175] Notify area 302 (i.e. event notification area) is used to support data synchronization between publishers and subscribers. It includes: Notify_state: records global sequence number; Notify_info[k]: records topic_id and corresponding segment sequence of each subscription; Notify_seq[k]: current sequence number of each topic, which is used by the subscriber to determine whether there is new data. The padding_ in Notify_state is used for byte alignment or data padding to ensure that the memory layout of the structure meets certain requirements.

[0176] Segment area 303 (i.e. storage area), each segment manages a data block of a topic, and the structure is as follows: Segment_state: global sequence number of the current segment; Segment_block[m]: header information of each data block, including lock, data length, sequence number, etc.; Segment_block_buf[m]: actual data buffer; block_buffer_size_: buffer size of each data block.

[0177] Embodiments of the present application can adopt a three-level computing architecture, including a main processing unit (MPU, Memory Protection Unit), a shared memory management unit (SMMU, System Memory Management Unit) and a plurality of secure co-processors (SCP, Secure Co-Processors). The MPU can be used as a central control unit, and the SCP can be used as a dedicated computing unit, and cross-domain communication can be achieved through the SMMU. A hierarchical memory management model can be used, and the core data structure includes: control header (Header): global state management area, including topic registration table, spin lock, segment allocation pointer; notification queue (Notify): event-driven mechanism, maintaining seq sequence and callback information; data segment (Segment): dynamic storage unit, each segment includes a plurality of block buffers with independent locks.

[0178] Embodiments of the present application can adopt a client-server (C / S) model, and implement cross-core remote procedure call based on shared memory, which is used in a heterogeneous computing environment (such as ARM+R5 multi-core system). The core interaction process can include that the client (Core1) initiates an RPC request, constructs a request message and blocks to wait for a response; the shared memory (SHM) is used as a communication medium, stores request / response topic data, and provides an atomic access mechanism; the server (Core 2) listens to the request topic, parses and executes the method, and returns the result to the response topic.

[0179] Figure 4 This is a schematic diagram of the interactive flow of inter-core communication provided by the embodiment of the present application, such as Figure 4 As shown, the steps are connected by solid lines, and the acquisition and release of messages are represented by dotted lines. Inter-core communication is implemented by different cores core1 (i.e., the first processor or client) and core2 (i.e., the second processor or server), and can be implemented through steps S401 to S407:

[0180] S401: The client registers a topic.

[0181] Here, the client / server registration process can be implemented through steps S4011 to S4018:

[0182] S4011. Obtain SHM Header spin lock.

[0183] S4012. Loop through the topic_struct in the Header to determine whether the topic has been registered.

[0184] S4013. If the topic has been registered, return the Topic_struct.

[0185] S4014. If the topic has not been registered, create a new Topic_struct based on the current topic_num_ at the topic_num_ index position of the topic_struct (that is, the first unused area).

[0186] S4015. Update the fields in the newly created Topic_struct, including topic_valid_, topic_id_, topic_len_, and topic_str_. Also update the current segment_offset_, which represents the actual offset address of the current topic's segment in the SHM. Update block_num_ and block_buffer_size_; these two parameters can be set by QoS.

[0187] S4016. Update next_valid_segment_offset_ and topic_num_ in the Header.

[0188] Here, the next_valid_segment_offset_ field records the next available valid segment offset address. The purpose of updating is to correctly find the next free memory location when creating new topics or other data structures, avoiding problems such as data overwriting.

[0189] Meanwhile, the topic_num_ field is updated, and the topic number is added by 1, reflecting that there is one more new topic in the shared memory. In this way, other processes can accurately understand the total number of registered topics when reading the shared memory header information subsequently, and then perform corresponding operations, such as traversing all topics.

[0190] S4017, allocate the segment region and the notify region, and initialize.

[0191] In the embodiment of the present application, the client can dynamically create a request topic (the naming rule can be Request_). <method>The client can create a response topic synchronously (Naming rule: Reply <method>Ensure the service side is subscribable.

[0192] Here, the service topic suffix (used to identify different service categories or specific service content) can be defined by the user, and the prefix is added by the middleware and is guaranteed not to be repeated.

[0193] S4018, return the SHM Header spin lock.

[0194] S402, the service side subscribes to the topic.

[0195] In the embodiments of the present application, the service side can subscribe to a wildcard topic (such as Request_*) when starting, and dynamically respond to different method requests.

[0196] S403, the client constructs a request message and publishes it to the request topic.

[0197] The request message can be attached with a UUID representing the unique identification of the client (client). The UUID can be composed of at least a globally unique entity identifier (such as a MAC address, which can ensure that there is no repeated identification between different clients) and a request sequence number (used to distinguish different requests issued by the same client, to ensure the order and uniqueness of the request).

[0198] Figure 5 is a message structure diagram provided by the embodiments of the present application, as shown in Figure 5 The request message 501 can include a unique message identifier (i.e. message identifier) and a request method structure body. The unique message identifier can be a UUID, the unique message identifier format can be <entity ID>_<sequence number>, the entity ID can be the globally unique entity identifier of the client; the sequence number is a number that increases with each request, so that the UUID of different requests issued by the same entity is also unique.

[0199] The request method structure body can include a method name, parameter data and a timeout time, wherein the method name is a target RPC method (such as Add); the parameter data is the serialized input parameter (which can be in Tag-Length-Value (TLV) format). The Tag is used to identify the type or purpose of the parameter; the Length indicates the length of the corresponding parameter value; the Value is the specific parameter value; the timeout time can be set according to the QoS level (which can be the default 500ms). Different business scenarios have different requirements for the timeliness of the response to the request, and a request with a high QoS level may require a shorter timeout time to ensure a fast response, while some requests with lower requirements for timeliness can be appropriately extended.

[0200] In the embodiments of the present application, after the client constructs the request message, the request message can be published to the request topic, for example, the request message is written into the Request <method>Topic, the client suspends execution of other operations related to the request and focuses on waiting for the server's response.

[0201] Here, the client can start a timeout timer, and if the response is not received within the timeout (500ms), trigger the retry mechanism (up to 3 times). After the client sends the request message, it blocks and waits until the timeout or receives the response message.

[0202] S404, the server receives the request message, parses the request method structure, executes and obtains the structure, and assembles the response message.

[0203] The server receives the request message from the shared memory request topic, checks the legality of the request message UUID, and in the case of legality, the server will perform deserialization operation on the parameter data in the request message. In the parsing process, different parameter types and purposes are identified according to the Tag identifier, and then the corresponding Length and Value information are extracted, and the serialized parameter data is restored to a data structure that can be directly used by the server. The server can distribute the request to the corresponding business logic processing module through the routing mechanism according to the method name (such as "Add") specified in the request message, obtain the execution result, and assemble the UUID (to ensure that the client matches) and the execution result (which can be a data processing result or exception information) into a response message.

[0204] Please continue to refer to Figure 5 The structure of the response message 502 is a unique message ID (i.e. UUID) and a response data structure (i.e. execution result). The server receives the request message, first checks the UUID (for example, it can be judged whether the UUID conforms to the established format specification, whether it can correctly identify the corresponding client, if the UUID check is passed, the server will execute the corresponding business logic, and according to the content in the request message, perform corresponding operations such as data query, calculation processing, etc., and obtain the execution result), and attaches the UUID to the response data header, executes and returns.

[0205] The naming of the request method structure and the response data structure can be void*request_data_.

[0206] Here, the server can be executed in a sandbox environment, isolating the impact of exceptions.

[0207] S405, the server publishes the response message to the response topic.

[0208] The server can publish the response to Reply_ <method>Topic, release client blocking.

[0209] S406, the client listens to the response topic and obtains the response message.

[0210] The client can listen to Reply_ <method>Topic, obtaining a response message, filtering a response with a non-matching UUID in the response message (for example, checking whether the UUID is consistent after receiving the response message, filtering out the response message with a non-client UUID at the bottom layer, and achieving the anti-pinging design), and obtaining a response data message.

[0211] S407, the client parses the response data message.

[0212] After the client obtains the response message, the client filters the non-matching UUID to obtain a valid response data message, parses the response data message (that is, the valid response message), extracts the returned data, and ends the call.

[0213] In the embodiment of the present application, the UUID is globally unique, and can be combined with an entity identifier (such as a MAC address) and an atomic incremental serial number to avoid request conflicts. A double-checking mechanism is achieved: the server response must carry the original request UUID; and the client processes the response only after verifying that the UUID matches.

[0214] In the embodiment of the present application, a timeout retry mechanism is adopted, the first retry can be performed after 500 ms, the second retry can be performed after 750 ms, and the third retry can be performed after 1125 ms. CRC32 check codes can also be added to the head and tail of the message, and for data in the shared memory, error correction code (ECC) memory can be used for storage to protect the shared data.

[0215] In the embodiment of the present application, the client and the server directly operate the shared memory buffer, avoiding data copying, achieving zero-copy transmission, and enabling high-priority requests to preempt the communication bandwidth of low-priority topics, and achieving priority scheduling.

[0216] In the embodiment of the present application, the main processing unit MPU / memory management unit (MMU, Memory Management Unit) protects the address space of each core to prevent out-of-bound access, and achieves memory isolation. After the server continuously makes errors and exceeds a threshold value, the server can automatically isolate an abnormal method, and automatically trigger a fuse mechanism to temporarily isolate the abnormal method, and no longer receive and process requests for the method.

[0217] The inter-core communication method provided by the embodiment of the application is a secure communication framework based on a multi-level index designed by sharing memory, and is based on a distributed architecture. A communication model based on a topic is designed. High-performance zero-copy data transmission can be supported, and certain communication delay performance can be guaranteed even for large packet data transmission. Meanwhile, a custom topic is supported, and the number and size of the buffer of the topic can also be customized, facilitating application expansion. Meanwhile, multi-domain sharing is also supported, and the topic is subscribed on demand. Multiple cores can share the subscription, and one-time sending and multi-domain receiving can be realized. Meanwhile, a sound concurrent mechanism is designed, and atomic operations are used to guarantee the data safety under multi-topic and multi-concurrency.

[0218] The inter-core communication RPC model can achieve good real-time performance and support anti-scaring design to prevent invalid message processing of multiple clients in the application layer. The embodiment of the application supports a distributed RPC model in the innovative inter-core communication of a robot, dynamically creates a bidirectional client / server node based on a topic as an index. And support for dynamically configuring buffer parameters facilitates the demand of the application layer for the request-response model of data communication. Prevents the overwrite mechanism. For high-concurrency and high-frequency data, effectively judge data overwrite, prevent buffer invalidation. The system porting requirement is relatively simple, and a piece of shared memory that both parties can map is enough. Memory pre-allocation, compact structure, suitable for robot embedded systems, multiple cores share a piece of shared memory, support multi-core data sharing, eliminate the end-to-end channel restriction of RPMsg. Can guarantee the safety of multi-core synchronization and avoid concurrent conflicts. A 64-bit atomic counter is used to maintain a global seq to ensure the orderliness of cross-core communication. Decouples publishing and subscribing, and synchronizes the state of publishing and subscribing through independent areas; adopts a hierarchical lock mechanism of a global Header lock, a segment area lock and a block unit lock to realize fine-grained concurrent control; adopts a double-buffer segment design: each segment contains multiple block buffer areas, supporting pipeline processing of read and write operations; adopts a dynamic mapping mechanism: supports runtime segment area expansion, and realizes elastic allocation of storage space through a next_valid_segment pointer. The inter-core communication RPC model has strong performance, can achieve good real-time performance, and supports anti-scaring design. Prevents invalid message processing of multiple clients in the application layer. Prevents the overwrite mechanism. For high-concurrency and high-frequency data, effectively judge data overwrite, prevent buffer invalidation.

[0219] Figure 6 is a hardware entity schematic diagram of a robot provided by the embodiment of the application, as Figure 6 shown, the hardware entity of the robot 60 includes a processor 601, a communication interface 602 and a memory 603, wherein:

[0220] The processor 601 generally controls the overall operation of the robot 60. Here, the processor can at least include a first processor and a second processor, and here, the processor is not limited to including only the first processor and the second processor.

[0221] The communication interface 602 can enable the robot to communicate with other terminals or servers through a network.

[0222] The memory 603 is configured to store instructions and applications executable by the processor 601, and can also cache data (for example, image data, audio data, voice communication data, and video communication data) to be processed by the processor 601 and modules in the robot 60, which have been processed or have been processed, and can be implemented by a FLASH or a Random Access Memory (RAM). The processor 601, the communication interface 602, and the memory 603 can transmit data through the bus 604.

[0223] In some embodiments, the first processor is configured to, in response to a request topic and a response topic corresponding to a target method of a shared memory of the robot, publish a request message including at least the target method and request data to the request topic; the second processor is configured to, in response to obtaining the request message in the request topic, process the request data based on the target method to obtain a response message including response data; and the first processor is further configured to, in response to the response message corresponding to the request message existing in the response topic, obtain the response data.

[0224] In some embodiments, the first processor is further configured to generate a request identifier of the request message based on a device address and a request sequence number of the first processor, serialize the to-be-processed data to obtain the request data, and generate the request message based on the request identifier, the request data, the target method, and a request response time length.

[0225] In some embodiments, the first processor is further configured to obtain a message in the response topic, compare a message identifier of the message with the request identifier to obtain a comparison result, and in response to the comparison result indicating that the message identifier is the same as the request identifier, determine the message as the response message; and correspondingly, the first processor is further configured to parse the response message to obtain the response data.

[0226] In some embodiments, after the first processor publishes the request message to the request topic, the first processor is further configured to trigger a request retry mechanism in response to the absence of the response message in the response topic after the request response duration; and stop obtaining the response message, and generate an error log in response to the absence of the response message in the response topic when the number of times of the request retry mechanism equals a preset threshold. The request retry mechanism comprises updating the request sequence number, generating a new request message, publishing the new request message to the request topic, and obtaining the response message in the request topic after a first request response duration. The first request response duration is greater than the request response duration.

[0227] In some embodiments, the second processor is further configured to subscribe to the request topic, obtain the request message in response to the occurrence of the request message in the request topic, and check the request message to obtain a check result. The check comprises at least format checking, uniqueness checking, and timeliness checking of the request identifier of the request message. Correspondingly, the second processor is further configured to process the request data based on the target method to obtain a response message comprising response data in response to the check result indicating that the check of the request message is passed.

[0228] In some embodiments, the second processor is further configured to deserialize the request data to obtain the to-be-processed data of the first processor, logically process the to-be-processed data based on the target method to obtain response data, generate the response message based on the response data and the request identifier, and publish the response data to the response topic.

[0229] In some embodiments, the shared memory comprises a meta-information region. The first processor is further configured to obtain a spin lock of the shared memory, and lock the shared memory in response to a registration request of the request topic and the response topic, traverse a topic information structure body of the meta-information region based on the topic names of the request topic and the response topic respectively, determine historical registration information of the request topic and the response topic, determine a request storage space of the request topic and a response storage space of the response topic in the shared memory based on the historical registration information, release the spin lock, and write the request message into the request storage space.

[0230] In some embodiments, the first processor is further configured to, in response to the historical registration message indicating that the request topic and the response topic do not exist in the shared memory, register the request topic and the response topic based on a number of topics in the shared memory, determine a request topic index of the request topic and a request storage space, and a response topic index of the response topic and a response storage space; the request storage space and the response topic space are unused areas in the shared memory; in response to the historical registration message indicating that the request topic and the response topic exist in the shared memory, determine data areas corresponding to the request topic and the response topic in the shared memory as the data storage space.

[0231] It should be noted that the above description of the robot embodiments is similar to the description of the method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the robot embodiments of the present application, please refer to the description of the method embodiments for understanding.

[0232] The computer readable storage medium provided in the embodiments of the present application stores a computer program, and the computer program is executed by a processor to implement the above-mentioned inter-core communication method. The computer readable storage medium can be transitory or non-transitory.

[0233] The computer program product provided in the embodiments of the present application includes a non-transitory computer readable storage medium storing a computer program, and the computer program is read and executed by a computer to implement some or all steps of the above-mentioned method. The computer program product can be implemented by hardware, software or a combination thereof. In an optional embodiment, the computer program product is specifically embodied as a computer storage medium, and in another optional embodiment, the computer program product is specifically embodied as a software product, such as a software development kit (SDK) and the like.

[0234] In some embodiments, the storage medium can be a computer-readable storage medium, such as a ferromagnetic random access memory (FRAM), 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 flash memory, a magnetic surface storage, an optical disk, or a compact disk-read only memory (CD-ROM), and the like. It can also be various devices including one or any combination of the above memories.

[0235] In some embodiments, the executable instructions can take the form of a program, software, software modules, scripts, or code, written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; and they can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0236] By way of example, the executable instructions can or can not correspond to a file in a file system, can be stored in a part of a file that holds other programs or data, such as one or more scripts stored in a hypertext markup language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files, such as files that store one or more modules, sub programs, or portions of code. The executable instructions may, by way of example, be deployed to be executed on one computer, or on multiple computers of a distributed system located in one site, or on multiple computers distributed across multiple sites and interconnected by a communication network.

[0237] The above description is only some embodiments of the present application, and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, and improvement within the spirit and scope of the present application shall be included in the protection scope of the present application.

[0238] It should be understood that the term "one embodiment" or "an embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the application. Thus, the appearances of the phrase "in one embodiment" or "in an embodiment" in various places throughout the specification are not necessarily referring to the same embodiment. Further, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that the sequence of steps in the above-described embodiments can not necessarily be the only sequence of steps, and that the embodiments can be carried out in other sequences than the one described above. The above-described embodiments are merely exemplary and do not limit the scope of the application. It should be understood that all the features that can be described in the above embodiments must be interpreted as separable solutions and can be in any combination or sub-combination. It should be understood that the sequence of steps in the above-described embodiments can not necessarily be the only sequence of steps, and that the embodiments can be carried out in other sequences than the one described above. The above-described embodiments are merely exemplary and do not limit the scope of the application. It should be understood that all the features that can be described in the above embodiments must be interpreted as separable solutions and can be in any combination or sub-combination.

[0239] It should be noted that, in the present document, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without limitation, an element preceded by "comprises... a" does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article, or apparatus that comprises the element. In several embodiments provided in the present document, it is to be understood that the disclosed apparatus and methods can be implemented in other ways. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and in actual implementation, additional division can be made, for example, multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed.

[0240] The above describes only the embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.< / method> < / method> < / method> < / method> < / method> < / method> < / method>

Claims

1. A method for inter-core communication, characterized in that: The inter-core communication method includes: In response to the first processor of the robot registering a request topic and a response topic corresponding to a target method in a shared memory of the robot, the first processor publishes a request message including at least the target method and request data to the request topic; In response to the second processor of the robot obtaining the request message in the request subject, the second processor processes the request data based on the target method to obtain a response message including response data; In response to the presence of a response message corresponding to the request message in the response topic, the first processor obtains the response data.

2. The inter-core communication method according to claim 1, wherein: The inter-core communication method further includes: The first processor generates a request identifier of the request message based on the device address of the first processor and the request sequence number; The first processor serializes the data to be processed to obtain the request data; The first processor generates the request message based on the request identifier, the request data, the target method, and the request response duration.

3. The inter-core communication method according to claim 2, wherein: The inter-core communication method further includes: The first processor obtains the message in the response topic, compares the message identifier of the message with the request identifier, and obtains a comparison result; In response to the comparison result indicating that the message identifier is the same as the request identifier, the first processor determines the message as the response message; Correspondingly, the first processor obtains the response data, including: The first processor parses the response message to obtain the response data.

4. The inter-core communication method according to claim 2 or 3, characterized in that: After the first processor publishes the request message to the request topic, the inter-core communication method further includes: In response to the absence of the response message in the response topic after the request response time, the first processor triggers a request retry mechanism; In response to the request retry mechanism having a number of times equal to a preset threshold, the response message does not exist in the response topic, the first processor stops acquiring the response message and generates an error log; Among them, the request retry mechanism includes updating the request serial number, generating a new request message, publishing the new request message to the request topic, and obtaining the response message in the request topic after the first request response time; the first request response time is greater than the request response time.

5. The inter-core communication method according to any one of claims 1 to 4, characterized in that: The inter-core communication method further includes: The second processor subscribes to the request topic; In response to the request message appearing in the request subject, the second processor obtains the request message; The second processor verifies the request message to obtain a verification result; the verification includes at least a format check, a uniqueness check, and a timeliness check of the request identifier of the request message; Correspondingly, the second processor processes the request data based on the target method to obtain a response message including response data, including: In response to the verification result indicating that the request message passes verification, the second processor processes the request data based on the target method to obtain a response message including response data.

6. The inter-core communication method according to claim 5, characterized in that: The second processor processes the request data based on the target method to obtain a response message including response data, including: The second processor deserializes the request data to obtain data to be processed by the first processor; The second processor performs logical processing on the data to be processed based on the target method to obtain response data; The second processor generates the response message based on the response data and the request identifier; Correspondingly, the inter-core communication method further includes: The second processor publishes the response data to the response topic.

7. The inter-core communication method according to any one of claims 1 to 6, characterized in that: The shared memory includes a meta information area; The inter-core communication method further includes: In response to the registration request of the request subject and the response subject, the first processor acquires the spin lock of the shared memory and locks the shared memory; The first processor traverses the topic information structure of the meta information area based on the topic names of the request topic and the response topic respectively, and determines the historical registration information of the request topic and the response topic; The first processor determines, in the shared memory, a request storage space of the request subject and a response storage space of the response subject based on the historical registration information; The first processor releases the spin lock; Correspondingly, the first processor publishes a request message including at least the target method and request data to the request topic, including: The first processor writes the request message into the request storage space.

8. The inter-core communication method according to claim 7, characterized in that: The first processor determines, in the shared memory, a request storage space of the request subject and a response storage space of the response subject based on the historical registration information, including: In response to the historical registration message indicating that the request topic and the response topic do not exist in the shared memory, the first processor registers the request topic and the response topic based on the number of topics in the shared memory, and determines a request topic index and the request storage space of the request topic, and a response topic index and the response storage space of the response topic; the request storage space and the response topic space are unused areas in the shared memory; In response to the historical registration message indicating that the request topic and the response topic exist in the shared memory, the first processor determines the data areas corresponding to the request topic and the response topic in the shared memory as the data storage space.

9. An inter-core communication device, characterized in that: The inter-core communication device includes: a publishing module, configured to, in response to a first processor of the robot registering a request topic and a response topic corresponding to a target method in a shared memory of the robot, publish a request message including at least the target method and request data to the request topic; a processing module, configured to obtain the request message from the request subject in response to a second processor of the robot, wherein the second processor processes the request data based on the target method to obtain a response message including response data; An acquisition module is configured to enable the first processor to acquire the response data in response to the presence of a response message corresponding to the request message in the response topic.

10. A robot, characterized in that: The robot comprises: a memory for storing executable instructions; a processor comprising at least a first processor and a second processor; The first processor is configured to, in response to a request topic and a response topic corresponding to a target method registered in a shared memory of the robot, publish a request message including at least the target method and request data to the request topic; The second processor is configured to, in response to obtaining the request message in the request subject, process the request data based on the target method to obtain a response message including response data; The first processor is further configured to obtain the response data in response to the presence of a response message corresponding to the request message in the response topic.

Images