A task processing method, apparatus and device

Abstract

The embodiment of the present specification provides a task processing method, device and equipment. The scheme comprises: acquiring, by the MCU, the sensing information collected by the sensing module, and detecting, locally in the MCU, whether the target event corresponding to the sensing information is a valid event, to realize the edge decision of the sensing task; when it is detected that the target event is a valid event and the SOC is in a deep sleep mode, the MCU can send an interrupt signal to the SOC to wake it up and switch it to a normal working mode, so that the SOC is only woken up when there is a valid event, and can remain in a deep sleep during no event; the SOC in the normal working mode can control the NFC payment module to process the payment event based on the AI algorithm, to complete the payment process.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a task processing method. This specification also relates to a task processing apparatus and a computing device. Background Technology

[0002] With the rapid development of mobile payment technology and the intelligent upgrading of commercial retail scenarios, intelligent robots have been widely used in various commercial venues such as retail stores, restaurants, cafes, and cosmetic counters. Currently, most intelligent robots on the market adopt a system-on-chip (SOC) architecture that centrally processes various tasks. The sensory data collected by the various sensing modules on the robot are uniformly uploaded to the SOC for centralized analysis and processing. The SOC coordinates the determination of various events and subsequent business execution.

[0003] In this operating mode, all data processing tasks are centrally handled by the SOC, which causes the SOC to bear a large amount of computing work for a long time, resulting in a large overall workload for the SOC. This can easily lead to SOC lag and reduce the SOC's business processing efficiency.

[0004] Therefore, how to reduce the workload of the SOC and improve its business processing efficiency has become an urgent technical problem to be solved. Summary of the Invention

[0005] In view of this, one or more embodiments of this specification provide a task processing method, apparatus, and device to reduce the workload of a System-on-Chip (SOC) and improve the business processing efficiency of the SOC.

[0006] According to a first aspect of one or more embodiments of this specification, a task processing method is provided, applied to a robot, the robot including a SOC, an MCU, a sensing module, and an NFC payment module; the SOC has at least a deep sleep mode and a normal working mode, in the normal working mode, the SOC is at least used to carry out payment-related processing tasks based on AI algorithms; The MCU acquires the sensing information collected by the sensing module; The MCU detects whether the target event corresponding to the perceived information is a valid event; the valid event includes at least a payment event. After detecting that the target event is a valid event, if the SOC is in the deep sleep mode, the MCU sends an interrupt signal to the SOC to wake up the SOC and switch to the normal working mode. The SOC, in its normal operating mode, controls the NFC payment module to process the AI-based payment event.

[0007] According to a second aspect of one or more embodiments of this specification, a computing device, a memory, and a processor are provided; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the above-described task processing method.

[0008] One or more embodiments of this specification can achieve at least the following beneficial effects: The microcontroller unit (MCU) can receive the sensing information collected by the sensing module and can perform a preliminary determination of the validity of the target event. This allows the MCU to rely on its local autonomous analysis and judgment capabilities. Only after the target event is identified as a valid event can the corresponding sensing data be uploaded to the SOC. This can filter out redundant and invalid sensing data in advance, so as to accurately identify the user's real and valid interaction intent. In this way, the SOC's processing flow for invalid data can be reduced, thereby effectively reducing the SOC's invalid computing resource consumption.

[0009] Meanwhile, by utilizing the deep sleep mode configured in the SOC, the SOC can maintain a low-power sleep state for extended periods in the absence of valid events, thus alleviating the operational burden caused by continuous high-load operation of the SOC from the source. Only when the MCU detects a valid interaction event will it send an interrupt signal to wake up the SOC, allowing it to switch to normal operating mode. This enables the SOC to promptly utilize computing resources to run AI algorithms and conduct various payment-related business processing.

[0010] This hardware and software collaborative operation mode can not only ensure the efficient implementation of core payment business, but also further optimize the overall computing resource utilization of SOC and improve the business processing efficiency of SOC, so as to adapt to the actual application needs of efficient interaction and stable operation of payment robots in various business scenarios such as retail and catering. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1This is a schematic diagram illustrating an application scenario of a task processing method provided in one embodiment of this specification; Figure 2 This is a flowchart illustrating a task processing method provided in one embodiment of this specification; Figure 3 This is a schematic diagram of the structure of a robot provided in one embodiment of this specification; Figure 4 This is a schematic diagram of the structure of a task processing device provided in one embodiment of this specification; Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0014] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0015] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0016] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0017] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0018] The word "if" can be interpreted as "when," "when," or "in response to a determination," depending on the context.

[0019] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0020] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0021] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. For example, in locations where robots are deployed, video capture prompts may be displayed by pasting or showing; or, when a user becomes a registered user of the terminal application or processes business, authorization prompts may be displayed through terms and conditions, etc., and data collection and use may be carried out based on user authorization; or, authorization prompts may be displayed on the robot's display interface. In practical applications, authorization prompts may be presented to users in one or more ways, and the specific methods are not specifically limited.

[0022] The following explains the terms and concepts used in one or more embodiments of this specification.

[0023] Robots: These can be small, intelligent, and interactive devices used for payment processing. They can be placed on desktops, workbenches, or other locations as auxiliary tools for business operations. They typically possess one or more functions such as speech recognition, emotion simulation, facial expression display, motion feedback, and environmental awareness. A robot can include hardware components (such as the main structure, drive mechanism, and sensors) and software components (such as control algorithms and human-computer interaction interfaces). Alternatively, robots can also have network connectivity to interact with servers.

[0024] PIR sensors are sensors that use the principle of infrared radiation sensing to detect the presence of human bodies and objects within a preset range. They can passively receive infrared heat source signals from the human body to achieve low-power detection of human presence, proximity, and departure at close range.

[0025] A Direct Time of Flight (DToF) sensor is a 3D distance sensing device that directly measures the round-trip time of a light pulse, and is one of the mainstream branches of Time-of-Flight (ToF) technology. It emits nanosecond / picosecond infrared laser pulses through a transmitter (such as a VCSEL), and a receiver (such as a SPAD single-photon avalanche diode) captures the reflected photons. A Time-to-Digital Converter (TDC) directly measures the time difference between the emission and reception of the light pulse, and then accurately calculates the distance between the sensor and the target using the formula "Distance = Speed ​​of Light × Time of Flight ÷ 2".

[0026] A microphone array is a system composed of multiple microphones arranged in a specific geometric structure. It can synchronously collect sound signals and use signal processing technology to achieve functions such as sound source localization, sound enhancement in the direction of the target, noise suppression, and reverberation.

[0027] While some robots on the market transmit sensor data to an MCU, the MCU merely acts as a data transmission medium. It can only forward raw sensor data or passively receive control commands from the SOC and execute corresponding hardware operations, such as controlling power supply or device startup / shutdown based on SOC commands. These MCUs lack a pre-built logic rule library and do not possess the ability to independently analyze sensor data, identify target events, or perform autonomous logic analysis. Therefore, they cannot autonomously identify events or make control decisions without the SOC.

[0028] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0029] Figure 1 This is a schematic diagram illustrating an application scenario of a task processing method provided in one embodiment of this specification.

[0030] like Figure 1 As shown, Robot 100 can be deployed in retail stores, restaurants, cafes, cosmetic counters, and self-checkout areas to provide users with convenient payment services. Robot 100 can be equipped with a sensing module, MCU, SOC, and NFC payment module. The sensing module can collect information about the robot's surrounding environment, such as distance sensors to collect target distance information, NFC detection modules to identify external NFC devices, microphone arrays to collect voice information, and cameras to collect image information. During operation, the MCU can acquire various sensing information collected by the sensing module in real time and perform pre-analysis to determine whether the target event corresponding to the sensing information is a valid event. When no valid event is detected, the SOC can maintain a low-power state in deep sleep, with only the MCU maintaining basic sensing monitoring. When the MCU detects a valid event, it can send an interrupt signal to the SOC to wake it up and switch to normal operating mode. The SOC then uses AI algorithms to process payment-related tasks and controls the NFC payment module to complete the payment interaction.

[0031] User 200 can conveniently interact and make payments with robot 100 through a user terminal. The payment methods are flexible and diverse. For example, user 200 can use a user terminal equipped with NFC to make close contact with robot 100 and complete the transaction through near-field NFC payment; or, user 200 can also scan the QR code displayed by robot 100 to make a payment; or, user 200 can also present a payment code through the user terminal, which robot 100 will recognize and complete the payment process.

[0032] By using a collaborative operation mode where the MCU pre-screens valid events and the SOC is woken up on demand, the SOC can avoid processing invalid sensing data for extended periods, thereby reducing its computational load and minimizing the risk of device lag. This also addresses the need for low-power operation. Furthermore, when a payment request is detected, the SOC can be quickly woken up to process core payment tasks promptly, ensuring the stable operation of payment services. This approach adapts to the actual needs of high-frequency interactions and long-term stable operation in commercial scenarios, thereby improving the user's payment experience and the reliability of device operation.

[0033] In practical applications, robots can employ various task management logic deployment methods. One approach is independent local deployment. Task management logic can be deployed locally on the robot. Specifically, logic for analyzing sensory information collected by the sensing module, determining whether the corresponding target event is valid, and waking the SOC from deep sleep mode to normal operation upon detection of a valid event can be deployed at the MCU. Logic for enabling the SOC to focus on AI-based payment-related tasks can also be deployed on the SOC itself. Another approach is cloud server deployment. The robot can establish a communication connection with the server, where the task management logic can be deployed. The server receives and analyzes the sensory information uploaded by the robot, determines whether it is a valid event, and issues a wake-up command. The robot can then control the SOC to switch operating modes and perform NFC payment-related operations based on the command. A third approach is collaborative deployment in both the local and cloud environments. The task management logic is broken down into smaller parts. Lightweight logic such as simple event detection and SOC sleep / wake-up control can be deployed and executed locally on the MCU, while heavyweight logic such as complex AI recognition and multi-event comprehensive judgment can be executed on the cloud server. This collaborative approach balances the needs for SOC load reduction, low-power operation, and efficient interactive response.

[0034] The user terminal can be one or more of the following: smartphone, laptop, tablet, IoT device, portable wearable device, or immersive image display device. Specifically, IoT devices can be one or more of the following: smart speaker, smart TV, smart air conditioner, or smart in-vehicle device. Portable wearable devices can be one or more of the following: smartwatch, smart bracelet, or head-mounted device. Immersive image display devices can include, but are not limited to, augmented reality (AR) devices and virtual reality (VR) devices.

[0035] A server can be a standalone physical server, a server cluster consisting of multiple physical servers, or a distributed file system. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0036] The server can connect to one or more robots via a local area network (LAN), wide area network (WAN), internet connection, or other types of data network. If user terminals can also connect to the server, the server can also connect to one or more user terminals via a LAN, WAN, internet connection, or other types of data network to synchronously acquire user interaction data. This assists the SOC in completing high-precision, high-computing-power AI payment calculation tasks, thereby alleviating the complex computing pressure on the SOC.

[0037] This specification provides a task processing method, a task processing apparatus, and a computing device, which will be described in detail in the following embodiments.

[0038] Figure 2 This is a flowchart illustrating a task processing method provided in one embodiment of this specification.

[0039] From a programming perspective, the entity executing the process can be a program hosted on an application server or a robot. It can be understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0040] Figure 2 The method described above can be applied to robots, which may include a SOC, an MCU, a sensing module, and an NFC payment module; the SOC has at least a deep sleep mode and a normal working mode, and in the normal working mode, the SOC is at least used to carry out payment-related processing tasks based on AI algorithms.

[0041] In one or more embodiments of this specification, "robot" can refer to an intelligent service robot deployed in commercial locations that has perception and interaction functions as well as payment functions.

[0042] A System-on-Chip (SoC) can refer to a high-performance main control chip that integrates multiple functional modules. An SoC can integrate a high-performance computing unit (CPU), a graphics processing unit (GPU), an AI processing unit, a large-capacity internal storage unit, and various interfaces for high-speed data transmission and connection to external devices. SoCs are characterized by strong computing power and fast processing speed, but also high power consumption. SoCs can be mainly used to perform complex and power-intensive computing tasks, such as running AI algorithms, payment data security verification, facial recognition, voice recognition, or processing multiple tasks simultaneously.

[0043] MCU can refer to a small control chip used to integrate basic functional modules. MCU can integrate basic computing units, small-capacity internal storage units, and simple interfaces for connecting sensors or outputting control signals. MCU has the characteristics of weak computing power and slow processing speed, but extremely low power consumption and low cost. MCU can be mainly used to perform simple, low-power control tasks, such as reading sensor data, simple logic judgment, or sending wake-up signals to SOC.

[0044] In practical applications, the MCU can carry and run lightweight firmware programs. These programs are adaptable to the MCU's limited hardware resources, featuring a concise and compact codebase. They consume minimal storage space and computational power during operation, enabling basic data parsing, local logic scheduling, and simple instruction scheduling. They can stably perform basic control tasks without requiring a complex operating system. Simultaneously, the MCU can have a built-in, complete set of preset rule libraries. These libraries can pre-load human body sensing distance thresholds, external device recognition standards, valid interaction event matching conditions, and SOC wake-up word templates, among other criteria. The MCU, relying on the lightweight firmware, calls the built-in rule library to perform autonomous data analysis and logical judgment. It can make independent control decisions first, and then, based on the final decision, autonomously determine whether to report the corresponding event information and sensor data to the SOC for further in-depth processing.

[0045] The perception module can include various types of sensor devices, which can actively collect environmental data in the robot's surrounding environment and interaction data from external objects, providing raw data support for the device's logical judgment.

[0046] An NFC payment module refers to a near-field communication payment hardware unit, which can be used to complete near-field data interaction, payment sending and receiving, and verification with external NFC terminals (mobile phones, bank cards).

[0047] Deep sleep mode refers to a low-power operating state set for a System-on-a-Chip (SoC). In this state, the SoC shuts down most operating devices and external channels, retaining only basic timing functions and being unable to perform various data calculations or business processing tasks. As one implementation method, when the SoC is in deep sleep mode, the overall power consumption can be lower than a first preset power consumption percentage, for example, 5% of the power consumption at full load.

[0048] Normal operating mode refers to the full-load operating state set for the SOC. In this state, all functional devices and communication channels of the SOC can be activated normally, enabling smooth completion of various high-computing operations and corresponding business processing tasks. As one implementation method, when the SOC is in normal operating mode, the overall power consumption can be higher than the second preset power consumption percentage, for example, the power consumption reaches 80% or more of the full-load operating power consumption.

[0049] AI algorithms can refer to artificial intelligence algorithms, mainly referring to a set of algorithms deployed in SOC for payment scenarios. AI algorithms can include NFC payment security verification algorithms, transaction risk assessment algorithms, user identity recognition algorithms, or payment data encryption algorithms, etc.

[0050] Payment-related processing tasks can refer to the high-computing-power tasks required to complete the entire NFC payment process, which may include tasks such as payment data parsing, terminal identity verification, transaction amount verification, risk identification, data encryption and decryption, or payment result generation.

[0051] like Figure 2 As shown, the process may include the following steps.

[0052] Step 202: The MCU acquires the sensing information collected by the sensing module.

[0053] In one or more embodiments of this specification, the sensing information can be raw sensing data collected by the sensing module based on the environmental conditions and various interactive behaviors within a preset range. Specifically, it can include distance data, NFC device identification data, human body sensing data, voice data, touch sensing data, etc. The preset area can be a spatial range centered on the robot and defined by a radius according to a set length.

[0054] In practical applications, MCUs can be installed in different locations such as the robot's torso or legs. Based on the actual installation location, MCUs can be divided into torso MCUs and leg MCUs.

[0055] It should be noted that the robot can also be equipped with a single MCU, which can integrate all the functions of the torso MCU and the foot MCU.

[0056] MCUs can use three common low-speed communication interfaces, namely I2C, SPI, and UART, to complete data interaction. I2C is an integrated circuit serial communication bus, SPI is a serial peripheral communication interface, and UART is a universal asynchronous serial transceiver interface. All three are suitable for short-distance, small-volume data transmission between chips and sensors.

[0057] The MCU can retrieve sensing data from the sensing module in two ways: periodic polling or interrupt triggering. Periodic polling means that the MCU can actively initiate a data reading request to the sensing module at a pre-set fixed time interval. Interrupt triggering means that after the sensing module collects valid sensing data, it can actively send a trigger level signal to the MCU, which can temporarily pause the normal operation process and read the corresponding sensing data.

[0058] After the MCU reads the raw data output by the sensing module, it can temporarily store the obtained sensing information in its own internal register or cache area to complete the local data storage operation.

[0059] Step 204: The MCU detects whether the target event corresponding to the perceived information is a valid event; the valid event includes at least a payment event.

[0060] In one or more embodiments of this specification, the MCU can perform local data parsing, feature matching, and logical judgment operations on the acquired perception information.

[0061] The target event can be a robot-related interactive behavior event formed by mapping the perceived information. Specifically, it can include user approach events, payment events generated by connecting to external NFC devices, device wake-up events, etc.

[0062] Valid events can refer to events that actually occur in real-world scenarios, as opposed to false events caused by misjudgments; or they can be defined as events that require high-computing power processing involving the SOC, or events of high importance with actual interactive value. These events can initiate core businesses such as robot payment, robot risk avoidance, or intelligent interaction.

[0063] Payment events can be events formed when a user initiates a payment interaction using an NFC terminal. These events require the SOC to run artificial intelligence algorithms to complete the verification of payment-related information (such as facial verification or voice verification) and the corresponding business processing.

[0064] In practical applications, the MCU, leveraging its local event determination capabilities, can perform pre-screening of perceived data. Specifically, the MCU can extract key features such as distance values, NFC radio frequency signal strength, or human infrared radiation intensity from the acquired perceived information. It then calls pre-defined local event determination logic rules to compare and match the extracted key features with valid event determination criteria. If the matching result confirms that the current target event is a valid event, the corresponding event type is marked, and subsequent related processes are initiated according to that event type. If the matching result determines that the target event is not a valid event, no subsequent execution process is initiated. Through pre-screening of perceived data and accurate identification of valid events, various environmental interference-related invalid events can be effectively eliminated, reducing the SOC's processing of redundant data. This reduces the amount of unnecessary computation generated by the SOC at the data processing front end, allowing the SOC to have sufficient computing power to process valid events and improving the SOC's business processing efficiency.

[0065] Step 206: After detecting that the target event is a valid event, if the SOC is in the deep sleep mode, the MCU sends an interrupt signal to the SOC to wake up the SOC and switch to the normal working mode.

[0066] In one or more embodiments of this specification, an interrupt signal can refer to a hardware trigger signal sent by the MCU to the SOC, which has a higher priority than regular instructions and can force the SOC to exit the sleep state. Wake-up can refer to the action of triggering the SOC to switch from a low-power sleep state to a high-computing-power working state through an interrupt signal.

[0067] In practical applications, after the MCU determines the validity of the target event and confirms that the current event is valid, it can read the current operating state of the SOC. If the MCU detects that the SOC is in deep sleep mode, it can send a high-level hardware interrupt trigger signal to the SOC through a dedicated interrupt pin reserved in the device. Upon receiving this hardware interrupt signal, the SOC can automatically initiate its internal reset process and system initialization program, gradually exit the deep sleep state, and smoothly switch to normal operating mode, while simultaneously sending a ready feedback signal back to the MCU. If the MCU fails to receive the ready feedback signal from the SOC within a preset time, the MCU can send the interrupt trigger signal to the SOC again, repeating the action until the SOC completes the wake-up operation and returns a ready signal to the MCU.

[0068] Thanks to the MCU's ability to independently perform local valid event analysis and logical judgment, the robot does not need to keep the SOC in a constantly active state. Relying on the MCU's front-end data filtering and event identification capabilities, the SOC can be flexibly activated based on actual business needs, and can remain in a dormant state when there are no business processing tasks. This operating mode effectively reduces power consumption during standby and improves overall power consumption. When a valid event that meets the judgment criteria occurs, the MCU can promptly send a wake-up signal to initiate the SOC's operation process, ensuring that core payment-related businesses can be processed quickly. This achieves both reduced device power consumption and stable maintenance of overall business processing response efficiency.

[0069] Step 208: The SOC, in its normal operating mode, controls the NFC payment module to process the AI-based payment event.

[0070] In one or more embodiments of this specification, after the SOC completes the state switch and enters the normal operating mode, the MCU can forward relevant information about valid events to the SOC through a data channel. This data channel can be a dedicated communication path between devices for transmitting service details or structured data, primarily used for the interactive transmission of various types of service information. The MCU sending a hardware interrupt wake-up signal to the SOC can be achieved through an independently deployed interrupt channel, which can be used to transmit level-based trigger control signals.

[0071] After receiving valid event information forwarded by the MCU, the SOC can first parse and organize the various business data contained within the payment event, and then call its own built-in artificial intelligence algorithm to sequentially complete a series of verification tasks, including NFC payment terminal identity verification, transaction amount verification, and transaction scenario risk identification. Once the entire verification process is successfully completed, the SOC can issue a formal payment execution command to the NFC payment module, thereby controlling the two-way data interaction between the NFC payment module and external NFC terminals, completing transaction content confirmation, and outputting the complete payment processing result.

[0072] By outsourcing basic front-end processing tasks such as data analysis and event identification of perceived information to the MCU, the MCU can alleviate the pressure of simple data processing at the front end, allowing the SOC to avoid expending computing power on basic judgment processes. In this way, the SOC can concentrate its hardware computing resources on high-performance AI payment-related business processing, fully leveraging its high-performance computing advantages to steadily improve the rigor of information verification and risk assessment in the payment process. This ensures the security, accuracy of data verification, and efficiency of transaction processing during payment transactions, enabling the construction of a complete closed-loop payment business framework and further optimizing the user's daily payment interaction experience.

[0073] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only possible execution order. The order of some steps may be adjusted according to actual needs, or some steps may be omitted. When the claims involve method steps, changes in the order of such steps, or parallel execution between steps, are also within the scope of protection of the claims.

[0074] Figure 2 The method described above allows the MCU to acquire sensing information collected by the sensing module and pre-detect whether the target event is valid. Only after the MCU, based on its local analysis and judgment functions, detects that the target event is valid will it report the sensing data to the SOC. This filters out redundant and invalid sensing data in advance, accurately identifying the user's true and valid interaction intent, thus avoiding the SOC from frequently processing meaningless sensing data and reducing the SOC's unnecessary computational overhead. Furthermore, relying on the SOC's deep sleep mode, the SOC can remain in a low-power sleep state when there are no valid events, thereby alleviating the pressure of long-term high-load operation of the SOC from the root. Only when the MCU detects a valid event such as payment will it wake up the SOC through an interrupt signal and switch to normal working mode, so that the SOC can promptly handle payment-related business based on AI algorithms. This achieves efficient execution of core payment business while further reducing the SOC's computational overhead, adapting to the actual needs of efficient interaction and stable operation of payment robots in commercial scenarios such as retail and catering.

[0075] based on Figure 2 In addition to the method described herein, this specification also provides some implementation methods of the method, which will be described below.

[0076] In order to achieve accurate identification of payment events, one or more embodiments of this specification further refine the composition of the sensing module and the judgment logic of payment events.

[0077] Optionally, the sensing module may include at least a distance sensing module for detecting distance information and an NFC sensing module for detecting NFC device information; the MCU detecting whether the target event corresponding to the sensing information is the payment event may include: determining whether there is NFC device information detected by the NFC sensing module in the sensing information, and obtaining a first determination result; if the first determination result indicates that there is NFC device information in the sensing information, then determining whether the distance value collected by the distance sensing module for the NFC device corresponding to the NFC device information is less than a first preset distance threshold, and obtaining a second determination result; if the second determination result indicates that the distance value is less than the first preset distance threshold, then determining that the target event is the payment event.

[0078] In one or more embodiments of this specification, the distance sensing module can refer to a sensor component capable of acquiring distance information between a target object and a robot. The distance sensing module may include a DToF (Direct Time-of-Flight) sensor, an infrared ranging sensor, or an ultrasonic sensor, etc. Among them, a DToF sensor calculates the distance value by emitting a light pulse and measuring the time of flight of the reflected signal, and can be used in close-range, high-precision ranging scenarios. The information acquired by the distance sensing module can be a distance value, which can represent the spatial distance between the target object and the robot.

[0079] An NFC sensing module refers to a sensor component capable of detecting information about Near Field Communication (NFC) devices. NFC sensing modules can interact with nearby NFC devices via the NFC protocol, detecting NFC devices entering their sensing range and acquiring their corresponding NFC device information. This NFC device information may include device identification, device type, or communication capabilities.

[0080] It should be noted that the NFC sensing module and the NFC payment module can refer to the same module or two different modules; there is no limitation on this.

[0081] The NFC device corresponding to NFC device information refers to the NFC device whose information has been detected by the NFC sensing module. When the NFC sensing module detects NFC device information, the distance sensing module can collect distance values ​​based on the location of the NFC device to determine the distance between the NFC device and the robot.

[0082] As one implementation method, the NFC device can be a mobile terminal (such as a mobile phone) that supports NFC functionality, or an NFC card, etc.

[0083] The first preset distance threshold can be a pre-defined distance judgment value used to measure whether the NFC device is within a sufficiently close distance range. This threshold can be configured according to the actual application scenario. For example, in a desktop payment robot scenario, the first preset distance threshold can be set to a value within the range of 10 cm to 30 cm to accommodate the interaction distance of the user bringing the NFC device close to the robot to perform a payment operation.

[0084] In practical applications, after receiving the sensing information reported by the sensing module, the MCU first analyzes the content of the sensing information to determine whether it contains NFC device information detected by the NFC sensing module. If the sensing information does not contain NFC device information, it means that no NFC device has entered the sensing range, and the MCU can continue listening without further processing; if the sensing information contains NFC device information, it means that an NFC device is approaching the robot, and the next step of distance determination is required.

[0085] Once NFC device information is confirmed, the MCU can further retrieve the distance value collected by the distance sensing module for that NFC device and compare it with a preset distance threshold. The purpose of this step is to confirm that the NFC device is not only within the sensing range but has also approached close enough for payment interaction. If the distance value is not less than the preset distance threshold, it means that although the NFC device has been detected, it is still too far away and has not yet entered the effective range for payment interaction; if the distance value is less than the preset distance threshold, it means that the NFC device is within the effective range for payment interaction.

[0086] When the MCU determines that NFC device information exists and the distance value meets the preset distance threshold, the MCU can determine that the current target event is a payment event, that is, the user is bringing the NFC device (such as a mobile phone or NFC payment card) close to the robot to prepare for payment.

[0087] In one or more embodiments of this specification, a joint judgment mechanism combining an NFC sensing module and a distance sensing module is employed. First, NFC device information is detected to confirm the presence of an NFC device approaching. Then, a distance threshold is compared to confirm whether the NFC device has entered the effective range for payment interaction. This achieves two-level verification of payment events, reducing the risk of misjudging payment events based solely on a single sensing signal (e.g., scenarios where only an NFC signal is detected but the user has no real intention to pay). This improves the accuracy and reliability of payment event recognition, thus addressing the problem of accidental triggering of payment events in desktop payment robot scenarios. Furthermore, this two-level judgment logic is completed locally by the MCU, eliminating the need for the main control SOC to participate in each step of the judgment. This allows the main control SOC to maintain a low-power state during periods without payment events, thereby extending the standby time of battery-powered robots.

[0088] In one or more embodiments of this specification, in order to ensure that high-priority events can be responded to and properly handled in a timely manner when the SOC is in normal operating mode, an operation mechanism for interrupting and scheduling business tasks currently being executed by the SOC based on event priority determination rules can be further added.

[0089] Optionally, after detecting that the target event is a valid event, the method may further include: if the SOC is in the normal operating mode, determining whether the first event priority of the valid event is higher than the second event priority of the current event being processed by the SOC, and obtaining a third determination result; if the third determination result indicates that the first event priority is higher than the second event priority, then sending an interrupt signal to the SOC through the MCU to force the SOC to suspend processing of the current event and prioritize processing the valid event.

[0090] In one or more embodiments of this specification, the first event priority may refer to the priority level corresponding to a valid event, used to measure the urgency or importance of the valid event in the system. The second event priority may refer to the priority level corresponding to the event currently being processed by the SOC. Event priorities can be set according to dimensions such as event type, timeliness requirements, or urgency of interaction. For example, the priority of a payment event may be higher than that of a general voice interaction event because payment scenarios have higher requirements for response timeliness; similarly, the priority of an emergency obstacle avoidance event may be higher than that of a payment event because the response to safety-related events requires the shortest possible delay.

[0091] An interrupt signal refers to a hardware interrupt signal sent by the MCU to the SOC via a dedicated INT pin. It can be used to notify the SOC that there is a higher priority event that needs to be processed. After receiving the interrupt signal, the SOC can interrupt the currently executing task, save the context state of the current task, and start processing the newly arrived high-priority event. After processing the high-priority event, the SOC can resume the previously paused event and continue execution.

[0092] In practical applications, after detecting a valid event, the MCU can first determine whether the SOC is in normal working mode. If the SOC is in deep sleep mode, the MCU can wake up the SOC through an interrupt message. If the SOC is in normal working mode, the MCU can determine whether the priority of the first event of the valid event is higher than the priority of the second event of the current event being processed by the SOC. The MCU can determine the priority of the valid event by querying a local preset priority mapping table, and at the same time obtain the priority information of the event currently being processed by the SOC through the SOC status interface or shared memory, and then compare them.

[0093] If the first event has a higher priority than the second event, an interrupt signal can be sent from the MCU to the SOC to force the SOC to pause processing the current event and prioritize processing the valid event. After receiving the interrupt signal, the SOC will save the context information of the current task and switch to responding to the higher-priority event. The previously paused task will resume after the higher-priority event is processed.

[0094] If the priority of the first event is not higher than that of the second event, the MCU can cache the valid event in the event queue and wait for the SOC to complete the current event processing before responding, so as to avoid low-priority events interfering with high-priority tasks.

[0095] In one or more embodiments of this specification, an event priority comparison mechanism is employed on the MCU side. When the SOC is in normal operating mode, the MCU can first compare the priority of valid events with the priority of the events currently being processed by the SOC. Only when the priority of the valid event is confirmed to be higher will an interrupt signal be sent to force the SOC to switch tasks. This enables effective scheduling of SOC computing resources, avoiding the risk of task jitter and degraded user experience caused by low-priority events frequently interrupting important tasks being processed by the SOC. It also ensures that high-priority events can promptly preempt the SOC's processing resources for a rapid response. This solves the problem of response chaos and reduced efficiency caused by the lack of priority constraints in SOC task scheduling in multi-event concurrent scenarios. Furthermore, this priority comparison logic is completed locally by the MCU, eliminating the need for the SOC to participate in priority judgment. This reduces the decision-making burden on the SOC during the interrupt response phase, allowing the SOC to focus more efficiently on processing the events themselves.

[0096] In one or more embodiments of this specification, in order to enable the SOC to complete the payment event-related processing work based on AI algorithms more efficiently, the MCU can first integrate, sort and organize the received raw perception information to transform the messy raw perception information into well-organized structured information, and then report it to the SOC after the information format conversion is completed.

[0097] Optionally, before the SOC in the normal operating mode controls the NFC payment module to process the AI-based payment event, the process may further include: the MCU sending structured information converted from the perceived information to the SOC; the SOC in the normal operating mode controlling the NFC payment module to process the AI-based payment event may include: the SOC in the normal operating mode controlling the NFC payment module to process the AI-based payment event based on the structured information.

[0098] In one or more embodiments of this specification, structured information refers to data with clear semantics and structure obtained by the MCU after local analysis and transformation of perceived information. Structured information differs from the original perceived information collected by the sensing module, such as the original radio frequency signal data output by the NFC sensing module or the original ranging waveform data output by the distance sensing module. Structured information can be information that has undergone preprocessing and semantic extraction at the MCU end and is presented in a standardized, parsable format. For example, structured information may include fields such as event type identifier, NFC device information summary, distance value, or event timestamp. The format of structured information can be key-value pairs, structures, or lightweight data protocols, so that the SOC can directly read and parse it without further low-level decoding of the original perceived information.

[0099] In practical applications, after completing local analysis of the sensed information, the MCU can extract key information from the raw sensed data and encapsulate it into structured information. For example, the MCU extracts the NFC device identifier from the raw sensed data reported by the NFC sense module, extracts the distance value from the raw sensed data reported by the distance sense module, and combines this with local judgment results (such as the event type being a payment event) to form a structured message which is then reported to the SOC. Subsequently, the SOC, in normal operating mode, can control the NFC payment module to process payment events based on AI algorithms based on this structured information. After receiving the structured information, the SOC can parse the field content to determine the type of the current event and context parameters, and then call the AI ​​algorithm to process the payment event (such as performing payment authentication or transaction risk assessment), and drive the NFC payment module to complete the payment data interaction operation with the NFC device.

[0100] In one or more embodiments of this specification, after the MCU completes the acquisition, analysis, and judgment of the sensing information locally, it converts the raw sensing information into structured information before reporting it to the SOC. During this process, the MCU does not directly transmit the raw sensing data to the SOC; the MCU is no longer a data repeater. Instead, it performs preprocessing and semantic conversion locally and reports the processed results to the SOC in structured form.

[0101] Because the MCU converts the raw sensing information into structured information locally before sending it to the SOC, the SOC receives structured data with clear semantics, rather than unprocessed raw signals. This eliminates the need for the SOC to handle the decoding and parsing of underlying sensor data, reducing its computational load and data processing overhead. This addresses the issue of high CPU load and response latency caused by the SOC simultaneously handling multiple tasks such as raw data parsing and AI inference. Furthermore, since the SOC directly drives the NFC payment module to process payment events based on the semantic content of the structured information, the intermediate step from raw data to semantic understanding is eliminated, shortening the latency from event confirmation to payment processing initiation and improving the SOC's response speed in payment scenarios. Additionally, the transmission bandwidth of structured information is much smaller than that of raw sensing data, which helps reduce the occupancy of the communication bus between the MCU and the SOC, thus improving the overall communication efficiency of the system.

[0102] In one or more embodiments of this specification, in order to enable the SOC to reliably sense the user's interaction intent during sleep and wake up in a timely manner, the conditions for the MCU to determine the target event as a wake-up event are further clarified.

[0103] Optionally, the valid event may further include a wake-up event for waking up the SOC; the sensing module may include at least one of an infrared sensing module for detecting infrared information, a distance sensing module for detecting distance information, a voice sensing module for detecting voice information, and a touch sensing module for detecting touch information; the conditions for the MCU to determine that the target event is the wake-up event may include at least one of the following: the infrared sensing image acquired by the infrared sensing module contains a heat source target that matches the human body temperature characteristics; the distance sensing module detects an approaching moving target object; the voice information received by the voice sensing module contains a wake-up keyword; and the touch sensing module acquires touch sensing information.

[0104] In one or more embodiments of this specification, a wake-up event can refer to a valid event used to wake up the SOC. When the SOC is in deep sleep mode or low power mode, after the MCU determines that the target event is a wake-up event, it can trigger a hardware interrupt signal to wake up the SOC from the sleep state to the normal operating mode.

[0105] An infrared sensing module refers to a sensor component capable of acquiring infrared information. Infrared sensing modules can include passive infrared (PIR) sensors or infrared thermal imaging sensors. PIR sensors detect human movement by detecting infrared radiation emitted by the human body, while infrared thermal imaging sensors generate infrared images and display the heat source distribution of the observed area.

[0106] For an explanation of the distance sensing module, please refer to the description of the distance sensing module above.

[0107] As one implementation method, the distance sensing module can also be used to detect approaching moving objects. A moving object can refer to an object that is moving towards the robot, such as a person approaching or an outstretched hand. The distance sensing module can determine the presence of an approaching moving object by continuously sampling the trend of distance values. If the continuously collected distance values ​​show a decreasing trend and the change exceeds a preset threshold, it can be determined that an approaching moving object exists.

[0108] A voice sensing module can refer to a sensor component capable of collecting voice information. A voice sensing module may include a microphone array (MIC) or a single microphone, and the voice information received by the voice sensing module can be the user's spoken words.

[0109] A touch sensing module refers to a sensor component capable of collecting touch sensing information, such as buttons. Touch sensing modules can include capacitive touch sensors or resistive touch sensors. Touch sensing information indicates that an object (such as a user's finger) has touched the touch-sensing area on the robot's surface.

[0110] Human body temperature characteristics refer to the temperature range corresponding to the infrared energy radiated from the human body surface. The human body surface temperature is typically around 36°C to 37°C, which can be represented as a heat source area within this temperature range in an infrared sensor image. By identifying heat source targets in the infrared sensor image that match this temperature characteristic, it can be determined whether a human body is approaching.

[0111] A wake-up keyword can refer to a pre-defined keyword or phrase used to trigger a wake-up event. A wake-up keyword can be one or more specific words, such as a robot's wake-up name. The MCU or voice perception module can run a lightweight keyword detection algorithm to locally recognize the acquired voice information and determine whether it contains a wake-up keyword.

[0112] In practical applications, the conditions for the MCU to determine a target event as a wake-up event can include at least one of conditions 1, 2, 3, and 4. Condition 1 can include: the MCU analyzes the infrared sensing images reported by the infrared sensing module to identify whether there are heat source areas within the temperature range characteristic of human body temperature. If so, it indicates that a human body is approaching the robot, and the MCU can determine the target event as a wake-up event. Condition 2 can include: the MCU performs trend analysis on the distance values ​​continuously collected by the distance sensing module. If it detects that the distance value is continuously decreasing and the change meets a preset condition, it can determine that there is an approaching moving object, and the MCU can determine the target event as a wake-up event. Condition 3 can include: the MCU performs keyword detection on the voice information collected by the voice sensing module. If it identifies that the voice contains preset wake-up keywords, the MCU can determine the target event as a wake-up event. Condition 4 can include: when a user touches the touch-sensing area on the robot's surface, the touch sensing module generates a touch sensing signal and reports it to the MCU. The MCU can determine the target event as a wake-up event based on the received touch sensing signal. The MCU can determine the wake-up event based on any one of the conditions 1 to 4 above, or it can make a joint determination based on a combination of multiple conditions. Through the collaborative verification of multiple independent wake-up sources, the reliability of wake-up determination can be improved.

[0113] In one or more embodiments of this specification, the sensing module may include at least one of an infrared sensing module, a distance sensing module, a voice sensing module, and a touch sensing module, so that the MCU can comprehensively determine the wake-up event based on sensing information of multiple different modalities. This makes the wake-up of the SOC no longer dependent on a single sensing source, broadens the wake-up triggering methods and scene coverage, and thus improves the convenience for users to wake up the robot under different interaction habits.

[0114] Meanwhile, since the wake-up event determination conditions correspond to different dimensions of perception signals such as human heat source detection, object proximity detection, voice keyword detection, and touch detection, the combined determination of multimodal conditions can cross-validate and suppress false triggering from a single perception source. This reduces the probability of the SOC being falsely woken up due to environmental interference (such as environmental heat sources or accidental noises), thereby solving the problem of additional power consumption caused by frequent false wake-ups of the SOC and extending the robot's standby time. In addition, the determination logic for various wake-up conditions is completed locally by the MCU, and the SOC can remain in a deep sleep state during periods without wake-up events, thus enabling the division of labor between wake-up perception and main control operation.

[0115] To reduce the risk of the infrared sensing module misjudging a wake-up event due to interference from environmental heat sources or a human body passing by briefly, in one or more embodiments of this specification, the judgment logic for heat source targets in infrared sensing images is further refined, and two-level verification conditions of duration and signal strength are introduced.

[0116] Optionally, determining whether a heat source target matching human body temperature characteristics exists in the infrared sensing image acquired by the infrared sensing module may include: determining whether a first duration of the heat source target appearing in the infrared sensing image is greater than or equal to a first preset duration threshold, to obtain a fourth determination result; if the fourth determination result indicates that the first duration is greater than or equal to the first preset duration threshold, then determining whether the infrared thermal radiation signal intensity corresponding to the heat source target is greater than or equal to a first preset intensity threshold, to obtain a fifth determination result; if the fifth determination result indicates that the infrared thermal radiation signal intensity is greater than or equal to the first preset intensity threshold, then determining that a heat source target matching human body temperature characteristics exists in the infrared sensing image.

[0117] In one or more embodiments of this specification, a heat source target can refer to a target area in the infrared sensing image whose temperature is higher than the ambient background temperature. Since a heat source target could be a human body, or a non-human heat source such as a radiator, a hot water cup, or an area exposed to sunlight, the mere presence of a heat source target in the infrared sensing image is insufficient to reliably confirm that the heat source target is a human body. Therefore, further verification can be performed by combining the duration and signal strength.

[0118] The first duration refers to the length of time a heat source target persists in an infrared sensor image. The MCU can determine the duration of the heat source target's presence by comparing and analyzing multiple consecutive frames of infrared sensor images. For example, if a heat source target can be detected at the same or similar locations in N consecutive frames of infrared sensor images, the first duration can be calculated based on the frame interval.

[0119] The first preset duration threshold can be a pre-defined duration judgment value used to measure whether the heat source target exists for a sufficiently long time to distinguish between two scenarios: staying and passing by. For example, the first preset duration threshold can be set to a value in the range of 2 to 5 seconds. When the duration of the heat source target is greater than or equal to this threshold, it indicates that the heat source target is not a fleeting, transient disturbance, but rather exists continuously near the robot.

[0120] Infrared thermal radiation signal intensity refers to the intensity of infrared energy radiated by a heat source target detected by an infrared sensing module. The intensity of the infrared thermal radiation signal is related to the temperature of the heat source target and its distance; the higher the temperature and the closer the distance, the stronger the signal. At normal distances, the intensity of the infrared thermal radiation signal from a human body is usually within a relatively stable range.

[0121] The first preset intensity threshold can be a pre-set signal intensity judgment value, which can be used to measure whether the infrared thermal radiation signal intensity of the heat source target reaches the level that the human body should have at a reasonable distance. When the signal intensity is greater than or equal to the threshold, it indicates that the temperature characteristics of the heat source target are consistent with the infrared radiation characteristics of the human body at close range.

[0122] In practical applications, the MCU can perform inter-frame analysis on multiple continuously acquired infrared sensor images. A frame can refer to a single infrared image generated sequentially. Inter-frame analysis compares and analyzes adjacent infrared image frames to detect whether the heat source target appears within the robot's preset sensing and monitoring range, and to verify whether the heat source target can stably persist within the continuous monitoring period. If the heat source target can continuously exist within the monitoring time window corresponding to a first preset duration threshold, it indicates that the heat source target has time-term persistence characteristics and can proceed to the next stage of the verification process. If the actual persistence time of the heat source target is short, it indicates that the heat source target is likely a temporary passing object or a momentary interference factor from the environment, and the MCU may not classify it as a valid human body sensing indication signal.

[0123] Provided that the heat source target has passed the continuous duration verification, the MCU can further extract the infrared thermal radiation signal intensity corresponding to the heat source target and compare it with the first preset intensity threshold. If the signal intensity is greater than or equal to the first preset intensity threshold, it indicates that the temperature characteristics of the heat source target are consistent with the infrared radiation characteristics of the human body at close range; if the signal intensity is lower than the first preset intensity threshold, it indicates that the heat source target may be a distant heat source or a low-temperature interference source.

[0124] When a heat source target simultaneously meets the duration and signal strength conditions, the MCU can confirm that the heat source target is a heat source target that matches the temperature characteristics of a human body, and thus determine that a human body is near the robot.

[0125] In one or more embodiments of this specification, when determining whether there is a heat source target in the infrared sensing image that matches the temperature characteristics of a human body, a two-level judgment logic of duration verification and signal strength verification is adopted. First, the duration condition can eliminate heat sources that do not have time continuity, such as those that pass by briefly or cause instantaneous interference. Then, the signal strength condition can eliminate distant heat sources or interference sources with inconsistent temperature characteristics. This enables multi-dimensional cross-verification of whether the heat source target is a human body, reducing the probability of false wake-up due to environmental factors in single-dimensional judgment. This improves the reliability of the infrared sensing module in wake-up scenarios and reduces the additional power consumption of the SOC caused by false wake-up.

[0126] To reduce the risk of the distance sensing module misjudging a wake-up event due to the movement or brief passage of an object in the environment, in one or more embodiments of this specification, the judgment logic for the distance sensing module to detect a moving target object approaching is further refined, and two levels of conditions are introduced: movement trend verification and close-range duration verification.

[0127] Optionally, determining whether the distance sensing module has detected an approaching moving object may include: determining whether the distance information collected by the distance sensing module reflects the existence of a moving object whose position is continuously changing, and obtaining a sixth determination result; if the sixth determination result indicates that there is a moving object whose position is continuously changing, then determining whether the second duration for which the distance between the moving object and the robot is less than a second preset distance threshold is greater than or equal to a second preset duration threshold, and obtaining a seventh determination result; if the seventh determination result indicates that the second duration is greater than or equal to the second preset duration threshold, then determining that the distance sensing module has detected an approaching moving object.

[0128] In one or more embodiments of this specification, a moving object whose position continuously changes can refer to an object whose spatial position, relative to the robot, exhibits a regular change within a continuous sampling period. The MCU can perform time-series analysis on the distance information continuously collected by the distance sensing module to identify whether the distance value is continuously changing. If the distance value shows an increasing or decreasing trend within multiple consecutive sampling periods, and the amount of change exceeds a preset rate of change threshold, it can indicate the presence of a moving object whose position is continuously changing.

[0129] The second preset distance threshold can be a pre-defined distance judgment value, used to measure whether a moving object is within a sufficiently close distance range to distinguish between close-range interaction and distant activity. For example, the second preset distance threshold can be set to a value within the range of 30 cm to 80 cm. When the distance between the moving object and the robot is less than this threshold, it indicates that the moving object has entered the effective interaction area near the robot.

[0130] The second duration can refer to the length of time during which the distance between the moving object and the robot remains less than a second preset distance threshold. After the MCU detects that the distance value of the moving object is lower than the second preset distance threshold, it can continuously time this state until the distance value rises back above the second preset distance threshold.

[0131] The second preset duration threshold can be a pre-defined duration judgment value, which can be used to measure whether the time a moving object stays in the vicinity is long enough. If the duration of the moving object's close proximity is greater than or equal to this threshold, it indicates that the moving object is not passing by quickly, but intentionally staying near the robot, and is more likely to have an interactive intent.

[0132] In practical applications, the MCU can perform time-series analysis on the distance values ​​continuously collected by the distance sensing module to detect whether there is a continuous trend of change in the distance values. If the distance values ​​show a decreasing trend within the continuous sampling period and the amount of change meets the preset conditions, it indicates that there is an approaching moving object, and the next step of verification can be carried out; if the distance values ​​are relatively stable or show no obvious trend in fluctuation, it indicates that there is currently no object with a clear trend of movement.

[0133] Once the presence of a moving object is confirmed, the MCU can further determine whether the moving object has entered the close-range area. The MCU can monitor the distance between the moving object and the robot in real time. When the distance is less than a second preset distance threshold, a timer is started to calculate the second duration. If the second duration is greater than or equal to the second preset duration threshold, it indicates that the moving object has remained in the close-range area for a sufficiently long time, and the possibility of it having an interactive intent is high. If the second duration is less than the second preset duration threshold, it indicates that the moving object may have only briefly passed through the close-range area, and the possibility of it having an interactive intent is low.

[0134] When a moving object simultaneously meets both conditions of continuous position change and continuous close-range stay, the MCU can confirm that it has detected an approaching moving target.

[0135] In one or more embodiments of this specification, when determining whether the distance sensing module has detected an approaching moving object, a two-level judgment logic is adopted, namely, movement trend verification and close-range duration verification. First, the MCU can confirm whether the object has an approaching movement trend through the continuous position change condition, so as to eliminate the distance fluctuation interference caused by static objects or random disturbances. Then, the close-range duration condition is used to confirm whether the moving object has stayed in the close range for a sufficient period of time, so as to exclude the scenario of short approach such as passing by quickly. In this way, the fine recognition of the approach interaction intention can be realized, so as to reduce the probability of false wake-up events caused by accidental movement or short passing by. This can improve the judgment accuracy of the distance sensing module in the wake-up scenario and reduce the additional power consumption of the SOC caused by false wake-up.

[0136] To reduce the risk of the voice perception module misjudging wake-up events due to brief noises or occasional sounds in the environment, in one or more embodiments of this specification, the logic of the voice perception module in determining whether the voice information contains wake-up keywords has been further refined, and two-level conditions of duration verification and keyword comparison have been introduced.

[0137] Optionally, determining whether the voice information received by the voice perception module contains a wake-up keyword may include: determining whether the third duration of the received voice information is greater than or equal to a third preset duration threshold to obtain an eighth determination result; if the eighth determination result indicates that the third duration is greater than or equal to the third preset duration threshold, then comparing each word in the voice information with each wake-up keyword in the wake-up keyword library; if there is a target word among the words that matches the target wake-up keyword in the wake-up keyword library, then determining that the voice information contains the wake-up keyword.

[0138] In one or more embodiments of this specification, the third duration may refer to the duration of the voice information received by the voice perception module. After the voice perception module detects a sound signal, the MCU can measure the duration of that sound signal. The third duration reflects the length of time the user speaks, distinguishing it from extremely short noises in the environment such as instantaneous collisions or slapping sounds.

[0139] The third preset duration threshold can be a pre-defined duration judgment value, used to measure whether the duration of the voice information is long enough to distinguish human voice from short noise. A wake-up keyword typically consists of one or more words, and a user usually needs a minimum duration to speak the wake-up keyword. For example, the third preset duration threshold can be set to a value in the range of 0.5 seconds to 1 second. When the duration of the voice information is greater than or equal to this threshold, it indicates that the voice information has sufficient duration to carry human semantics.

[0140] A wake-up keyword library refers to a pre-stored collection of one or more wake-up keywords. This library can be stored in the MCU's local firmware, allowing the MCU to perform keyword comparison locally without uploading voice data to the SOC for recognition. Each wake-up keyword in the library can be the robot's wake-up name or a specific command word. For example, the wake-up keyword library could contain wake-up phrases such as "Hello Xiao X". The MCU's local firmware can be an embedded fixed-run program or accompanying fixed configuration content pre-programmed into the MCU's built-in storage space, and it can store the wake-up keyword library using the MCU's built-in storage area.

[0141] A target wake-up keyword refers to a wake-up keyword in a wake-up keyword database that matches a specific word or phrase in the speech information. A target word or phrase refers to a word or phrase in the speech information that, after recognition, matches the target wake-up keyword.

[0142] The MCU can perform local speech recognition on voice information, breaking it down into individual word units. These word units are then matched one by one with wake-up keywords stored in a wake-up keyword database. Matching methods can include text matching or acoustic feature matching. When at least one word matches a wake-up keyword in the database, the voice information is considered to contain a wake-up keyword.

[0143] In practical applications, the MCU can measure the duration of the voice information collected by the voice perception module. If the third duration is less than the third preset duration threshold, it means that the duration of the voice information is too short, and the user is unlikely to be able to say the complete wake-up keyword. The MCU does not need to perform keyword recognition, thus avoiding unnecessary voice recognition processing on brief noise and saving the MCU's recognition resources. If the third duration is greater than or equal to the third preset duration threshold, it means that the voice information has enough duration to carry human voice semantics, and the user is more likely to say the complete wake-up keyword. The next step of keyword comparison can be carried out.

[0144] The MCU can perform local speech recognition on voice information that has passed the duration verification, extract each word, and then compare it one by one with the wake-up keywords in the wake-up keyword library. When the MCU finds that a word in the voice information matches a wake-up keyword in the wake-up keyword library during the comparison process, it can confirm that the voice information contains a wake-up keyword, and the MCU can determine that the target event is a wake-up event.

[0145] In one or more embodiments of this specification, when determining whether a voice message contains a wake-up keyword, the MCU can first filter out voice messages with sufficient duration by comparing a third duration with a third preset duration threshold, and then perform keyword recognition on the filtered voice messages. This eliminates the need for the MCU to perform keyword recognition processing on every detected voice message, reducing unnecessary computational overhead in noisy environments and improving the efficiency of keyword detection. Simultaneously, since short noises are pre-filtered in terms of duration and do not enter the keyword comparison stage, the risk of instantaneous sounds in the environment (such as collision sounds or slapping sounds) being misjudged as wake-up events due to accidental similarity in acoustic features to wake-up keywords is reduced. This improves the accuracy of the voice perception module in wake-up scenarios, reducing the additional power consumption of the SOC due to false wake-ups.

[0146] To reduce the risk of the touch sensing module misjudging a wake-up event due to environmental contact or unintentional touch, in one or more embodiments of this specification, the logic for determining whether the touch sensing module has collected touch sensing information has been further refined, and two levels of conditions, namely sensing force verification and duration verification, have been introduced.

[0147] Optionally, determining whether the touch sensing module has collected touch sensing information may include: determining whether the sensing force corresponding to the touch sensing information collected by the touch sensing module is greater than or equal to a preset force threshold, to obtain a ninth determination result; if the ninth determination result indicates that the sensing force is greater than or equal to the preset force threshold, then determining whether the fourth duration of the touch sensing information is greater than or equal to a fourth preset duration threshold, to obtain a tenth determination result; if the tenth determination result indicates that the fourth duration is greater than or equal to the fourth preset duration threshold, then determining that the touch sensing module has collected touch sensing information.

[0148] In one or more embodiments of this specification, the sensing force can refer to the magnitude of the force applied to the touch sensing area when the touch sensing module detects a touch action. The touch sensing module can map electrical parameters such as changes in capacitance or resistance of the touch area into a sensing force value. The magnitude of the sensing force can reflect the degree of intent of the touch action; when a user intentionally touches the robot, the applied force is usually greater; while unintentional touches (such as friction from clothing or light contact with an object) usually correspond to a smaller force.

[0149] The preset force threshold can be a pre-defined force judgment value, which can be used to measure whether the touch sensing force reaches the level of intentional touch. When the sensing force is greater than or equal to the preset force threshold, it can be said that the force characteristics of the touch behavior are consistent with the performance of the user's active touch; when the sensing force is less than the preset force threshold, it can be said that the touch behavior may be a slight accidental contact, without clear interactive intent.

[0150] The fourth duration refers to the length of time that the touch behavior corresponding to the touch sensing information persists. The MCU can start timing from the moment the touch sensing module first detects a touch signal that meets the force condition, until the touch signal disappears or the force drops below a preset force threshold. The fourth duration reflects the length of time the user's finger (or other part) remains in the touch sensing area.

[0151] The fourth preset duration threshold can be a pre-defined duration judgment value, which can be used to measure whether the duration of the touch behavior is long enough to distinguish between intentional touch and brief contact. For example, the fourth preset duration threshold can be set to a value in the range of 0.3 seconds to 1 second. When the duration of the touch behavior is greater than or equal to this threshold, it can be indicated that the touch is not a momentary contact that is immediately removed, but rather a user's intentional lingering behavior on the touch-sensitive area.

[0152] In practical applications, the MCU can read the touch sensing information reported by the touch sensing module, extract the sensing force value, and compare it with a preset force threshold. If the sensing force is less than the preset force threshold, it indicates that the touch signal is insufficient, possibly due to unintentional contact such as clothing friction or light contact with an object, and the MCU may not consider it a valid touch input. If the sensing force is greater than or equal to the preset force threshold, it indicates that the force characteristics of the touch behavior match the performance of an active touch by the user, and the MCU can proceed to the next step of duration verification.

[0153] Provided the touch action passes the force verification, the MCU can further measure the duration of the touch action. If the fourth duration is less than the fourth preset duration threshold, it indicates that the touch action is too short, possibly a brief contact where the user's arm unintentionally swept across the touch area, and does not constitute a clear interaction intention; if the fourth duration is greater than or equal to the fourth preset duration threshold, it indicates that the user has remained on the touch sensing area for a sufficiently long time and has a clear interaction intention.

[0154] When a touch action simultaneously meets the conditions of sensing force and duration, the MCU can confirm that the touch sensing module has collected valid touch sensing information, and the MCU can determine that the target event is a wake-up event.

[0155] In one or more embodiments of this specification, a two-level judgment logic is employed to determine whether the touch sensing module has collected touch sensing information: force verification and duration verification. The MCU first uses the force condition to exclude unintentional contact due to insufficient force, such as clothing friction or light contact with an object, and then uses the duration condition to exclude brief contact such as an unintentional sweep of an arm. This allows for more refined recognition of intentional touch interactions, reducing the probability of false wake-up events due to insufficient force or short duration. This improves the reliability of the touch sensing module in wake-up scenarios, reducing the additional power consumption of the SOC due to false wake-ups.

[0156] In order to enable the robot to detect dangerous events such as its feet dangling in the air during movement, which may cause operational abnormalities, and thus take relevant actions such as safety avoidance in advance, in one or more embodiments of this specification, a distance sensing module can be further installed at the bottom of the robot's feet, and corresponding discrimination criteria can be formulated.

[0157] Optionally, the robot may further include feet, and the sensing module may include a distance sensing module installed at the bottom of the feet. The distance sensing module can be used to measure the suspended distance value of the feet. The valid event may further include a hazard avoidance event. The MCU detects whether the target event corresponding to the sensing information is a hazard avoidance event, which may include: determining whether the first suspended distance value collected by the distance sensing module for the feet is greater than or equal to a third preset distance threshold, and obtaining an eleventh determination result; if the eleventh determination result indicates that the first suspended distance value is greater than or equal to the third preset distance threshold, then the target event is determined to be a hazard avoidance event.

[0158] In one or more embodiments of this specification, the feet are a component of the robot and can be used to support the robot's body and enable walking or movement.

[0159] In one implementation, the robot may include multiple feet, each with a distance sensing module installed at the bottom to enable independent suspension detection of each foot.

[0160] The distance sensing module, mounted at the bottom of the foot, measures the distance of the foot suspended in the air, with its measurement direction pointing downwards towards the foot. Unlike the distance sensing module mentioned above, which is used to detect approaching moving objects, this distance sensing module focuses on the distance between the bottom of the foot and the supporting surface below, rather than the distance between the object in front and the robot.

[0161] In one implementation, the distance sensing module at the bottom of the foot may include a DTOF sensor or an infrared ranging sensor, etc.

[0162] The overhang distance refers to the vertical distance between the bottom of the foot and the supporting surface below (such as the ground, tabletop, or step). When the robot is standing or walking normally, the bottom of the foot is in contact with or close to contact with the ground, and the overhang distance is close to zero. When the foot misses the ground, steps into the edge of the supporting surface, or encounters a pit, the distance between the bottom of the foot and the supporting surface below increases, and the overhang distance increases accordingly.

[0163] The third preset distance threshold can be a pre-defined suspension distance judgment value, which can be used to measure whether the degree of foot suspension has reached the level that requires triggering risk avoidance. The third preset distance threshold can be configured according to the structural dimensions of the robot's feet and walking gait parameters. When the first suspension distance value is greater than or equal to the third preset distance threshold, it indicates that the degree of foot suspension has exceeded the reasonable range for normal walking, and there is a risk of stepping into a hole or falling.

[0164] A risk avoidance event can refer to a valid event triggered by an abnormal foot dangling distance, indicating that the robot is currently facing the risk of its foot slipping or falling, and that timely risk avoidance measures need to be taken.

[0165] In practical applications, the MCU can continuously read the suspended distance value collected by the distance sensing module installed at the bottom of the foot, and compare the current first suspended distance value with a third preset distance threshold. If the first suspended distance value is less than the third preset distance threshold, it means that the distance between the foot and the supporting surface below is within the normal range, and there is no risk of stepping into a hole; if the first suspended distance value is greater than or equal to the third preset distance threshold, it means that the degree of suspension of the foot has exceeded the normal range.

[0166] When the distance of the foot in the air reaches or exceeds the third preset distance threshold, the MCU can determine that the current target event is a risk avoidance event, which means that the robot is at risk of stepping into the air or falling, and needs to execute a risk avoidance response in time.

[0167] In one or more embodiments of this specification, a distance sensing module is installed at the bottom of the robot's foot to measure the suspended distance value of the foot. By comparing the suspended distance value with a third preset distance threshold, a risk avoidance event is determined. This allows the robot to perceive the suspended state of its foot in real time and trigger a risk avoidance response in a timely manner when the suspended distance exceeds the safe range. This prevents the robot from falling due to stepping into a hole or stepping off the edge of the support surface, thereby solving the problem of fall risk caused by the lack of foot suspension detection capability during robot walking or movement.

[0168] In order to enable the MCU to independently complete risk management tasks by relying on its own local computing power in various risk avoidance scenarios, thereby effectively improving the response time of the whole machine's risk avoidance actions, in one or more embodiments of this specification, complete risk avoidance execution operation rules can be pre-deployed locally on the MCU.

[0169] Optionally, the MCU may have a local autonomous risk avoidance function. After detecting that the target event is a valid event, if the SOC is in the deep sleep mode, the MCU sends an interrupt signal to the SOC. This may include: after detecting that the target event is the risk avoidance event, the MCU controls the feet to perform a risk avoidance operation; determining whether the second suspended distance value of the robot's feet after performing the risk avoidance operation is greater than or equal to the third preset distance threshold, obtaining a twelfth determination result; if the twelfth determination indicates that the second suspended distance value is greater than or equal to the third preset distance threshold, then the MCU sends an interrupt signal to the SOC.

[0170] In one or more embodiments of this specification, the local autonomous risk avoidance function of the MCU refers to the MCU's ability to independently identify risk avoidance events and control the foot actuators to perform risk avoidance actions locally. In risk avoidance scenarios, the MCU's local autonomous risk avoidance function can be manifested as follows: after detecting a risk avoidance event, the MCU can directly control the foot servo to perform risk avoidance actions such as backward movement, without waiting for commands from the SOC. The MCU can have built-in preset rules related to risk avoidance (such as hovering distance thresholds and risk avoidance action sequences), thereby enabling risk avoidance response actions to be completed locally within a closed loop on the MCU.

[0171] Risk avoidance operation can refer to the actions performed by the foot actuators controlled by the MCU based on its local autonomous risk avoidance function, which are aimed at eliminating the risk of being suspended in mid-air.

[0172] As one implementation method, the avoidance operation may include controlling the foot servo to move slightly backward, lifting the foot, or adjusting the gait. The goal of the avoidance operation is to remove the foot from the suspended area and return it to a safe support surface, thereby reducing the suspension distance value to below a third preset distance threshold.

[0173] The second hovering distance value refers to the hovering distance value re-collected by the distance sensing module after the MCU controls the foot to perform a risk avoidance operation. The second hovering distance value can be used to measure whether the risk avoidance operation has successfully eliminated the risk of the foot being suspended in the air. If the second hovering distance value is less than the third preset distance threshold, it means that the foot has returned to a safe position; if the second hovering distance value is still greater than or equal to the third preset distance threshold, it means that the local risk avoidance operation has failed to effectively eliminate the risk.

[0174] In practical applications, after the MCU detects that the target event is a risk avoidance event, the MCU can control the feet to perform risk avoidance operations. Specifically, the MCU may not immediately send an interrupt signal to the SOC, but instead, based on its local autonomous risk avoidance function, control the foot servo to perform risk avoidance actions such as backward movement, attempting to resolve the risk of being suspended in mid-air locally.

[0175] After the MCU controls the foot to complete the obstacle avoidance maneuver, it can read the suspended distance value re-collected by the distance sensing module and compare it with a third preset distance threshold. If the second suspended distance value is less than the third preset distance threshold, it indicates that the obstacle avoidance operation has successfully eliminated the suspension risk, and the MCU does not need to report to the SOC. If the second suspended distance value is greater than or equal to the third preset distance threshold, it indicates that the local obstacle avoidance operation has failed to resolve the suspension problem, and there is still a risk of falling. At this time, the MCU determines that local autonomous obstacle avoidance is no longer sufficient to resolve the risk, and the SOC needs to intervene to make global obstacle avoidance decisions and control the actions. An interrupt signal can be sent to the SOC, which is in deep sleep mode, via the INT pin to wake up the SOC and take over all servo actions.

[0176] In one or more embodiments of this specification, because the MCU has a local autonomous risk avoidance function, after detecting a risk avoidance event, it first performs risk avoidance operations locally based on this function. Only when the risk avoidance operation fails to eliminate the suspension risk will an interrupt signal be sent to the SOC to wake up the SOC. This allows most suspension risks to be resolved in the MCU's local closed loop without waking up the SOC in deep sleep mode, reducing the number of times the SOC is frequently woken up due to risk avoidance scenarios. This, in turn, reduces the overall standby power consumption of the system and extends the battery-powered robot's endurance. At the same time, because the response link of the MCU's local risk avoidance operation is much shorter than the link of "reporting to SOC → SOC wake-up → SOC decision → SOC issuing command", the feet can quickly perform risk avoidance actions such as retreating after detecting a suspension risk. This improves the real-time performance of the risk avoidance response and reduces the risk of the robot falling while waiting for the SOC response due to wake-up delay.

[0177] It should be noted that if the MCU fails to eliminate the dangling risk after performing a single avoidance operation, it can continue with subsequent avoidance operations. If, after multiple avoidance operations, the dangling distance value still fails to be reduced below the third preset distance threshold, the MCU can send an interrupt signal to the SOC, which will then perform global avoidance processing. Because the MCU does not immediately report to the SOC when a single avoidance operation fails, but instead continues to attempt multiple avoidance operations locally, it is given ample opportunity to autonomously adjust and mitigate the risk. This avoids frequent SOC wake-ups due to occasional failures in a single avoidance operation, thus reducing unnecessary SOC wake-ups and improving overall system power consumption control. Simultaneously, multiple local attempts provide the SOC with more deep sleep time, allowing it to make more accurate decisions based on the sufficient avoidance status information generated during the MCU's multiple avoidance operations when intervention is truly necessary.

[0178] It should be noted that when the SOC is in normal working mode, if the MCU still fails to eliminate the risk of suspension after local risk avoidance operations, the MCU can also send an interrupt signal to the SOC to request the SOC to suspend the event it is currently processing and take over the risk avoidance process first. This ensures that when a risk avoidance event occurs while the SOC is in working mode, the robot can still obtain timely global risk response.

[0179] Figure 3 This is a schematic diagram of the structure of a robot provided in one embodiment of this specification.

[0180] like Figure 3As shown, module 302 includes a microphone (MIC) located above the robot's body for collecting voice information. Module 304 includes a DirectToF (DToF) and an NFC payment module. The DToF can detect the proximity of external devices, and the NFC payment module can detect NFC device information. The voice information collected by the microphone, the distance information collected by the DToF, and the NFC device information collected by the NFC payment module can be uploaded to the System-on-Chief Engine (SOC), and the SOC can also issue control commands to these modules. The NFC payment module can also handle payment events based on AI algorithms, which require strong computing power from the SOC (such as payment authentication or transaction risk detection). Simultaneously, the distance information collected by the DToF in module 304 and the NFC device information collected by the NFC payment module can also be sent to the body MCU in module 308. The body MCU will then locally determine whether the NFC device information exists and whether the distance value is less than a preset distance threshold. Only after confirming the existence of a genuine payment event will it be reported to the SOC.

[0181] Module 306 may include a System-on-a-Chip (SOC), an audio unit, a communication unit, and other peripherals. The SOC, as the main platform, can run the operating system and is responsible for AI inference (such as facial recognition or speech semantic understanding), network communication, multimedia output, and system scheduling. The SOC can have a normal operating mode and a deep sleep mode. In normal operating mode, the SOC can perform high-computing tasks such as AI inference; during periods of inactivity, the SOC can enter a deep sleep mode to reduce power consumption, resuming operation only when woken up by an interrupt signal from the MCU. The SOC can receive structured information or interrupt signals reported by the MCU (body MCU, first-foot MCU, or second-foot MCU), and can also issue commands to the MCU (body MCU, first-foot MCU, or second-foot MCU). Other peripherals may refer to peripheral hardware other than the SOC, audio unit, and communication unit, used to implement functions such as signal acquisition, motion driving, human-computer interaction, service execution, power management, and interface expansion, such as touch displays, indicator lights, or buzzers.

[0182] Module 308 may include a torso MCU PIR sensor, a barcode scanner, buttons, and multiple servos. The torso MCU can be a low-power MCU located in the middle of the body, and various sensing modules can be mounted around it. The PIR sensor can collect infrared sensing images and report them to the torso MCU, which then determines locally whether there is a heat source target in the infrared sensing image that matches the human body temperature characteristics. The MIC array can collect voice information and report it to the torso MCU, which then determines locally whether there is a wake-up keyword in the voice information. The buttons can collect touch / press sensing information and report it to the torso MCU, which then determines locally whether valid touch sensing information has been collected. The barcode scanner can collect scanning information and report it to the torso MCU, which then performs local preprocessing.

[0183] After completing the above judgments locally, the torso MCU only reports confirmed valid events to the SOC as structured information. For example, when the PIR detects a human approach, the MIC recognizes a wake-up keyword, or a button detects a valid touch, the torso MCU can determine the target event as a wake-up event and wake up the SOC through an interrupt signal. When the information from the DToF and NFC payment modules is jointly determined to be a payment event, the torso MCU can report the structured information to the SOC, which then drives the NFC payment module to complete the payment process. In addition, multiple servos can execute preset actions under the local control of the torso MCU to complete local closed-loop operation. The torso MCU can also be equipped with a ChargeIC (battery management module), which is mainly responsible for power distribution and charging management, thereby offloading power management tasks from the SOC and reducing the SOC's load.

[0184] Module 310 may include a first foot MCU, foot servos, and two DToF sensors; module 312 may include a second foot MCU, foot servos, a wireless charging terminal, and two DToF sensors. The DToF sensor at the bottom of the foot can measure the hovering distance of the foot in real time and report the sensing information to the corresponding foot MCU. The foot MCU can locally determine whether the hovering distance is greater than or equal to a preset distance threshold; if it exceeds this threshold, it is considered a safety event. The foot MCU can directly control the foot servos to perform safety operations such as backward movement based on its local autonomous safety function, without waiting for SOC commands. Only when the hovering risk cannot be eliminated after multiple safety operations will the foot MCU send an interrupt signal to the SOC, requesting SOC takeover.

[0185] Figure 3In this system, the sensor information collected by each sensing module is not directly aggregated to the SOC for unified processing. Instead, the corresponding MCUs (body MCU and foot MCU) perform preprocessing, analysis, and judgment locally. Based on the judgment results, the MCUs autonomously decide whether to execute locally or report to the SOC. This eliminates the need for the SOC to participate in polling and parsing sensor data in every round. Each MCU shares the preprocessing and initial judgment of the sensor data, thereby reducing the SOC's load. In addition, critical actions such as hazard avoidance can be responded to locally by the foot MCU in milliseconds without waiting for instructions from the SOC, thus shortening the control loop latency and improving the timeliness of hazard avoidance response. Furthermore, the SOC is only interrupted and woken up when the MCU confirms a valid event. During periods without events, it can remain in deep sleep, thereby reducing the SOC's power consumption.

[0186] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods.

[0187] Figure 4 This is a schematic diagram of the structure of a task processing device provided in one embodiment of this specification.

[0188] like Figure 4 As shown, the device can be a robot, which includes an SOC 402, an MCU 404, a sensing module 406, and an NFC payment module 408; the SOC has at least a deep sleep mode and a normal working mode, and in the normal working mode, the SOC is at least used to carry out payment-related processing tasks based on AI algorithms. The MCU acquires the sensing information collected by the sensing module; The MCU detects whether the target event corresponding to the perceived information is a valid event; the valid event includes at least a payment event. After detecting that the target event is a valid event, if the SOC is in the deep sleep mode, the MCU sends an interrupt signal to the SOC to wake up the SOC and switch to the normal working mode. The SOC, in its normal operating mode, controls the NFC payment module to process the AI-based payment event.

[0189] It is understood that the modules mentioned above refer to computer programs or program segments used to perform one or more specific functions. Furthermore, the distinction between these modules does not imply that the actual program code must also be separate.

[0190] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0191] The above is an illustrative scheme of a task processing device according to this embodiment. It should be noted that the technical solution of this device and the technical solution of the above-described task processing method belong to the same concept. For details not described in detail in the technical solution of this device, please refer to the description of the technical solution of the above-described task processing method.

[0192] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0193] Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification.

[0194] The computing device 500 includes: Memory 510 and processor 520; The memory 510 is used to store computer programs / instructions, and the processor 520 is used to execute the computer programs / instructions, which, when executed by the processor 520, implement the steps of the above-described task processing method.

[0195] Specifically, the components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and the database 550 is used to store data.

[0196] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0197] In one embodiment of this specification, the aforementioned components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0198] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 500 can also be a mobile or stationary server.

[0199] The processor 520 executes the computer instructions to implement the steps of the above-described task processing method.

[0200] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described task processing method belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described task processing method.

[0201] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the apparatus and device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and relevant parts can be referred to the description of the method embodiments. The apparatus and device provided in the embodiments of this specification correspond to the methods; therefore, the apparatus and device also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding apparatus and device will not be repeated here.

[0202] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0203] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0204] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0205] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0206] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0207] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0208] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0209] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0210] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0211] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0212] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0213] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0214] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0215] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A task processing method applied to a robot, the robot including a SOC, an MCU, a sensing module, and an NFC payment module; the SOC having at least a deep sleep mode and a normal working mode, wherein in the normal working mode, the SOC is at least used to carry out payment-related processing tasks based on AI algorithms; The MCU acquires the sensing information collected by the sensing module; The MCU detects whether the target event corresponding to the perceived information is a valid event; the valid event includes at least a payment event. After detecting that the target event is a valid event, if the SOC is in the deep sleep mode, the MCU sends an interrupt signal to the SOC to wake up the SOC and switch to the normal working mode. The SOC, in its normal operating mode, controls the NFC payment module to process the AI-based payment event.

2. The method according to claim 1, wherein the sensing module includes at least a distance sensing module for detecting distance information and an NFC sensing module for detecting NFC device information; The MCU detects whether the target event corresponding to the perceived information is the payment event, including: Determine whether the sensed information contains NFC device information detected by the NFC sensing module, and obtain a first determination result; If the first judgment result indicates that the NFC device information exists in the sensing information, then it is determined whether the distance value collected by the distance sensing module for the NFC device corresponding to the NFC device information is less than the first preset distance threshold, and a second judgment result is obtained. If the second determination result indicates that the distance value is less than the first preset distance threshold, then the target event is determined to be the payment event.

3. The method according to claim 1, further comprising, after detecting that the target event is a valid event: If the SOC is in the normal working mode, then it is determined whether the first event priority of the valid event is higher than the second event priority of the current event being processed by the SOC, and a third determination result is obtained; If the third determination result indicates that the priority of the first event is higher than the priority of the second event, then the MCU sends an interrupt signal to the SOC to force the SOC to suspend processing of the current event and prioritize processing the valid event.

4. The method according to claim 1, further comprising, before the SOC in the normal operating mode controls the NFC payment module to process the AI-based payment event: The MCU will send the structured information converted from the perceived information to the SOC; The SOC, in its normal operating mode, controls the NFC payment module to process the AI-based payment event, including: The SOC, in its normal operating mode, controls the NFC payment module to process the AI-based payment event based on the structured information.

5. The method according to claim 1, wherein the valid event further includes a wake-up event for waking up the SOC; the sensing module includes at least one of an infrared sensing module for detecting infrared information, a distance sensing module for detecting distance information, a voice sensing module for detecting voice information, and a touch sensing module for detecting touch information; the condition for the MCU to determine that the target event is the wake-up event includes at least one of the following: The infrared sensing image acquired by the infrared sensing module contains a heat source target that matches the temperature characteristics of the human body. The distance sensing module detects an approaching moving target; The voice information received by the voice perception module contains wake-up keywords; The touch sensing module collects touch sensing information.

6. The method according to claim 5, determining whether there is a heat source target matching human body temperature characteristics in the infrared sensing image acquired by the infrared sensing module, comprising: Determine whether the first duration of the heat source target appearing in the infrared sensing image is greater than or equal to a first preset duration threshold, and obtain a fourth determination result; If the fourth judgment result indicates that the first duration is greater than or equal to the first preset duration threshold, then it is determined whether the intensity of the infrared thermal radiation signal corresponding to the heat source target is greater than or equal to the first preset intensity threshold, and a fifth judgment result is obtained. If the fifth determination result indicates that the intensity of the infrared thermal radiation signal is greater than or equal to the first preset intensity threshold, then it is determined that there is a heat source target in the infrared sensing image that conforms to the characteristics of human body temperature.

7. The method according to claim 5, determining whether the distance sensing module detects an approaching moving target, includes: The sixth judgment result is obtained by determining whether the distance information collected by the distance sensing module reflects the existence of a moving object whose position is continuously changing. If the sixth judgment result indicates the existence of a moving object whose position is continuously changing, then it is determined whether the second duration during which the distance between the moving object and the robot is less than the second preset distance threshold is greater than or equal to the second preset duration threshold, and a seventh judgment result is obtained. If the seventh determination result indicates that the second duration is greater than or equal to the second preset duration threshold, then it is determined that the distance perception module has detected an approaching moving target object.

8. The method according to claim 5, determining whether the voice information received by the voice perception module contains a wake-up keyword, includes: Determine whether the third duration of receiving the voice information is greater than or equal to the third preset duration threshold, and obtain the eighth determination result; If the eighth judgment result indicates that the third duration is greater than or equal to the third preset duration threshold, then each word in the voice information is compared with each wake-up keyword in the wake-up keyword library; If any of the words contains a target word that matches the target wake-up keyword in the wake-up keyword library, then the voice information is determined to contain the wake-up keyword.

9. The method according to claim 5, wherein determining whether the touch sensing module has collected touch sensing information includes: Determine whether the sensing force corresponding to the touch sensing information collected by the touch sensing module is greater than or equal to a preset force threshold to obtain the ninth determination result; If the ninth judgment result indicates that the sensing force is greater than or equal to the preset force threshold, then it is determined whether the fourth duration of the touch sensing information is greater than or equal to the fourth preset duration threshold, and the tenth judgment result is obtained. If the tenth judgment result indicates that the fourth duration is greater than or equal to the fourth preset duration threshold, then it is determined that the touch sensing module has collected touch sensing information.

10. The method according to claim 1, wherein the robot further comprises feet, the sensing module includes a distance sensing module installed at the bottom of the feet, the distance sensing module being used to measure the suspended distance value of the feet, and the effective event further includes a risk avoidance event; The MCU detects whether the target event corresponding to the perceived information is a risk avoidance event, including: The eleventh judgment result is obtained by determining whether the first suspended distance value collected by the distance sensing module for the foot is greater than or equal to the third preset distance threshold. If the eleventh judgment result indicates that the first suspended distance value is greater than or equal to the third preset distance threshold, then the target event is determined to be a risk avoidance event.

11. The method according to claim 10, wherein the MCU has a local autonomous risk avoidance function, and after detecting that the target event is a valid event, if the SOC is in the deep sleep mode, the MCU sends an interrupt signal to the SOC, including: After detecting that the target event is the avoidance event, the MCU controls the foot to perform an avoidance operation; The twelfth judgment result is obtained by determining whether the second suspended distance value of the robot's feet after performing the avoidance operation is greater than or equal to the third preset distance threshold. If the twelfth determination indicates that the second suspended distance value is greater than or equal to the third preset distance threshold, then the MCU sends an interrupt signal to the SOC.

12. A computing device, comprising: Memory and processor; The memory is used to store computer programs or instructions, and the processor is used to execute the computer programs or instructions, wherein when the computer programs or instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 11.

Images