Robot control method and apparatus, and robot

Abstract

A robot control method. By means of deploying a non-real-time operating system and a real-time operating system on a control apparatus, the non-real-time operating system sends a control instruction to the real-time operating system so as to execute a non-real-time task, and the real-time operating system sends an electric-motor motion instruction to a servo electric motor so as to execute the real-time task, and the non-real-time task is prevented from affecting the real-time performance of the real-time task, thereby reducing latency. Further provided is a robot apparatus. Further provided is a robot.

Description

A robot control method, device, and robot

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411445273.7, filed on October 15, 2024, entitled "A Control Method, Apparatus and System for a Robot", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of robotics technology, and in particular to a robot control method, device, and robot. Background Technology

[0004] Robots are increasingly being used in high-precision applications, such as semiconductors and electronics manufacturing, requiring them to support high-speed, high-precision motion. The robot motion control system, acting as the robot's brain, is therefore of paramount importance.

[0005] The robot's motion control system mainly consists of two parts: the robot controller (also known as the master station) and the robot joint motors (also known as the slave stations). The robot controller is responsible for running real-time and non-real-time tasks, generating motion commands for each robot joint motor, and then periodically sending them to each robot joint motor to complete the motor movement.

[0006] The main station uses a Linux system to run real-time and non-real-time tasks. However, as a general-purpose operating system, Linux contains a lot of code in its kernel that disables interrupts and preemption, thus it cannot guarantee the real-time performance of real-time tasks, resulting in significant latency. Summary of the Invention

[0007] This application provides a robot control method, device, and robot to solve the problem of large latency in real-time tasks.

[0008] In a first aspect, embodiments of this application provide a robot control method applied to a robot control device, the control device being equipped with a non-real-time operating system and a first real-time operating system; the robot includes N servo motors, where N is a positive integer; the control device is connected to the N servo motors.

[0009] For example, a non-real-time operating system executes non-real-time tasks, while a real-time operating system executes real-time tasks. For instance, the non-real-time operating system generates control instructions for controlling the robot's movement and sends these instructions to the first real-time operating system. The first real-time operating system then generates motor motion instructions for N servo motors based on these control instructions, and drives the corresponding servo motors to move according to these instructions.

[0010] Currently, motor motion commands are generated in the Linux system and fed back to the servo motor, which cannot guarantee that the motor motion commands are transmitted to the servo motor in real time. This application's embodiment addresses this by deploying a real-time operating system and a non-real-time operating system in the control device, separating real-time and non-real-time task commands. This ensures that real-time tasks are not affected by non-real-time tasks, thereby reducing latency.

[0011] In one possible implementation, the control device further includes at least one second real-time operating system; each of the N servo motors corresponds to one second real-time operating system; the first real-time operating system drives the corresponding servo motor to move according to the motor motion commands corresponding to the N servo motors, including: the first real-time operating system sending a corresponding first motor motion command to the second real-time operating system corresponding to the first servo motor; the first servo motor is any one of the N servo motors; the second real-time operating system corresponding to the first servo motor drives the first servo motor to move according to the first motor motion command.

[0012] Traditional EtherCAT-based master-slave architectures suffer from problems such as communication latency, bandwidth limitations, and complex wiring. In the embodiments described above, the servo motor control function (slave control node) is implemented within the control device using a software-defined approach, which reduces transmission latency between the master and slave stations and improves system performance.

[0013] In one possible implementation, the control device is equipped with multiple virtual machines, and the non-real-time operating system, the first real-time operating system, and the at least one second real-time operating system run on different virtual machines.

[0014] In the above scheme, virtualization technology is used to deploy a non-real-time operating system and a real-time operating system on the control device to achieve strong isolation between each real-time task and a non-real-time task, thus preventing high real-time tasks from being affected by non-real-time tasks.

[0015] In one possible implementation, the non-real-time operating system sending the control command to the first real-time operating system includes: the non-real-time operating system sending the control command to the first real-time operating system via inter-process communication (IPC); the first real-time operating system sending a corresponding first motor motion command to the second real-time operating system corresponding to the first servo motor includes: the first real-time operating system sending the first motor motion command to the second real-time operating system corresponding to the first servo motor via the IPC.

[0016] The above scheme uses IPC to transmit commands, which can reduce transmission latency compared to using the EtherCAT bus.

[0017] In one possible implementation, the control device is deployed on a single chip. In the above scheme, the control device incorporates slave control functionality, enabling the virtual slave and master stations to operate on the same control board. During robot operation, communication between the robot and the slave control nodes does not require bus / Ethernet communication, reducing Ethernet / bus communication latency, minimizing connection lines between robot components, increasing communication bandwidth, reducing size, improving efficiency, and enhancing real-time performance.

[0018] In one possible implementation, the control device is connected to the N servo motors via at least one peripheral interface. In this solution, the control device and servo motors only need to be connected via a peripheral interface, which further reduces the number of connecting cables between components and minimizes the overall size.

[0019] Secondly, embodiments of this application provide a robot control device, the control device being equipped with a non-real-time operating system and a first real-time operating system; the robot further includes N servo motors; the non-real-time operating system is used to generate control commands for controlling the robot's movement and send the control commands to the first real-time operating system; the first real-time operating system is used to generate motor movement commands corresponding to the N servo motors according to the received control commands, and drive the N servo motors to move according to the motor movement commands corresponding to the N servo motors.

[0020] In one possible implementation, the non-real-time operating system and the first real-time operating system occupy different hardware resources on the control device, including a processor and / or a network interface card (NIC). Through this approach, the real-time operating system is unaffected by the non-real-time operating system, further reducing processing latency.

[0021] In one possible implementation, the control device further includes at least one second real-time operating system; each of the N servo motors corresponds to one second real-time operating system; the first real-time operating system is specifically used to send a first motor motion command to the second real-time operating system corresponding to the first servo motor; the first servo motor is any one of the N servo motors, and the first motor motion command is a motor motion command that drives the first servo motor to move; the second real-time operating system corresponding to the first servo motor is used to receive the first motor motion command from the first real-time operating system and drive the first servo motor to move according to the first motor motion command.

[0022] In one possible implementation, the control device is equipped with multiple virtual machines, and the non-real-time operating system, the first real-time operating system, and the at least one second real-time operating system run on different virtual machines.

[0023] In one possible implementation, the number of second real-time operating systems is the same as the number of servo motors. Different servo motor control nodes will not interfere with each other when processing real-time tasks, further reducing processing latency.

[0024] In one possible implementation, a virtual machine manager is also deployed; the virtual machine manager is used to create N virtual machines in the control device that correspond one-to-one with the N servo motors, according to the number of servo motors.

[0025] In one possible implementation, the at least one second real-time operating system independently occupies different hardware resources on the control device, including a processor and / or a network interface card (NIC). This approach prevents different real-time operating systems from interfering with each other, further reducing processing latency.

[0026] In one possible implementation, the control device further includes an inter-process communication (IPC) module; the IPC module is used to schedule the control commands from the non-real-time operating system to the first real-time operating system; and to schedule the first motor motion commands from the first real-time operating system to the second real-time operating system.

[0027] In one possible implementation, the IPC module schedules the control commands with a lower priority than the motor motion commands. By scheduling commands for real-time tasks using a priority mechanism, the execution of real-time tasks can be prevented from being affected by non-real-time tasks.

[0028] In one possible implementation, the message type of the motor motion command includes at least a first message type and a second message type, and the IPC module schedules motor motion commands of the first message type with a higher priority than scheduling motor motion commands of the second message type.

[0029] In one possible implementation, the IPC module includes a first queue and a second queue. The first queue is used to add motor motion commands of the first message type from the first real-time operating system, and the second queue is used to add motor motion commands of the second message type from the first real-time operating system. The scheduling priority of the first queue is higher than that of the second queue. This priority mechanism ensures that commands with low latency requirements are executed first, thereby reducing latency.

[0030] In one possible implementation, the priority of the motor motion command is related to the message importance of the motor motion command and / or the maximum supported latency.

[0031] In one possible implementation, the control device is deployed on a chip.

[0032] In one possible implementation, the control device is connected to the N servo motors via peripheral interfaces.

[0033] Thirdly, embodiments of this application provide a robot including the control device described in the second aspect or any embodiment of the second aspect.

[0034] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including instructions for performing the first aspect or any possible implementation thereof.

[0035] Fifthly, embodiments of this application provide a control chip connected to a memory. The control chip is used to read and execute software programs stored in the memory, and to execute the methods described in the first aspect and various possible implementations of the first aspect.

[0036] Sixthly, this application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods described in the first aspect and various possible implementations of the first aspect.

[0037] In a seventh aspect, embodiments of this application provide a control device including at least one processor configured to perform corresponding functions in the method provided in the first aspect. The control device may further include a memory coupled to the processor, storing necessary program instructions and data for the control device. The control device may also include a peripheral interface for communicating with a servo motor.

[0038] Based on the implementations provided in the above aspects, this application can be further combined to provide more implementations. Attached Figure Description

[0039] Figure 1 is a schematic diagram of the architecture of the motion control system of the robot provided in an embodiment of this application;

[0040] Figure 2 is a schematic diagram of the software layer structure of a control device provided in an embodiment of this application;

[0041] Figure 3A is a schematic diagram of another control device provided in an embodiment of this application;

[0042] Figure 3B is a schematic flowchart of a robot control method provided in an embodiment of this application;

[0043] Figure 4 is a schematic diagram of another control device provided in an embodiment of this application;

[0044] Figure 5 is a schematic diagram of another control device provided in an embodiment of this application;

[0045] Figure 6 is a schematic diagram of the basic architecture of a control device for running a virtual machine provided in an embodiment of this application;

[0046] Figure 7 is a schematic diagram of the architecture of another control device for running a virtual machine provided in an embodiment of this application;

[0047] Figure 8 is a schematic diagram of the architecture of another control device for running a virtual machine provided in an embodiment of this application;

[0048] Figure 9 is a schematic diagram of the architecture of another control device for running a virtual machine provided in an embodiment of this application;

[0049] Figure 10 is a schematic diagram of the operation flow of the control device provided in the embodiment of this application;

[0050] Figure 11 is a schematic diagram of instruction cycle message transmission provided in an embodiment of this application;

[0051] Figure 12 is a schematic diagram of the control device provided in an embodiment of this application. Detailed Implementation

[0052] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0053] In the description of this application, unless otherwise stated, "multiple" refers to two or more. Additionally, " / " indicates that the related objects are in an "or" relationship; for example, A / B can represent A or B. "And / or" in this application merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. It should also be noted that, unless specifically stated, the specific description of some technical features in one embodiment can also be used to explain the corresponding technical features mentioned in other embodiments.

[0054] To facilitate understanding of the technical solutions of the embodiments of this application, some concepts involved in this application will be introduced first.

[0055] (1) Virtualization technology, virtual machine (VM), virtualization platform.

[0056] Virtualization is a resource management technology that abstracts and transforms the various physical resources of electronic devices, such as processors, memory, and interfaces, and presents them in a more accessible way. Virtualization is a resource allocation method from a logical perspective; it is a logical abstraction of physical resources.

[0057] Electronic devices can form software modules with independent operating environments by means of virtualization technology. In this embodiment of the application, the software modules with independent operating environments formed on electronic devices are referred to as virtual machines.

[0058] A virtual machine (VM) is a simulated "complete computer" with full hardware system functionality, running in a completely isolated environment, created using virtualization technology. Any task that can be performed on a physical computer can also be performed in a VM. A VM has components such as a processor (also called a virtual processor), memory, and hard disk; these components are virtualized from the processor, memory, and hard disk of the physical electronic device. An operating system is installed on the VM, and this operating system is independent of the physical device's own operating system. To distinguish between these two operating systems, the operating system on the physical device is usually called the host operating system (hostOS), while the operating system on the VM is usually called the guest operating system (guestOS).

[0059] A virtualization infrastructure refers to a technical architecture that abstracts physical hardware resources into virtual resources through virtualization technology, thereby providing flexible and scalable computing, storage, and network resources. This architecture allows users to dynamically allocate and release resources according to demand, improving resource utilization and reducing operating costs. A virtualization infrastructure typically includes a combination of virtualization software and hardware resources. Through virtualization technology, physical servers, storage devices, and network devices can be transformed into multiple virtual resources to meet the needs of different applications. Implementing this technical architecture can bring several advantages, including improved resource utilization, reduced operating costs, and enhanced system flexibility and scalability.

[0060] The virtualization dock can also be called a virtual machine monitor or virtual machine manager.

[0061] For electronic devices, a virtual machine is viewed as a special kind of "process." This "process" performs computational tasks and consumes resources such as the electronic device's processor, memory, and hard drive. For example, the electronic device's operating system allocates dedicated memory space for the virtual machine, which the virtual machine uses to support the computational tasks it needs to perform.

[0062] (2) Linux is a free and open-source Unix-like operating system. It is a multi-user, multi-tasking operating system based on POSIX and UNIX, supporting multi-threading and multi-CPU. It can run major UNIX utilities, applications, and network protocols. It supports 32-bit and 64-bit hardware. Linux inherits Unix's network-centric design philosophy and is a stable multi-user network operating system.

[0063] (3) Inter-process communication (IPC) is a general term for a class of data communication methods between processes in an operating system. The two or more parties involved in the communication use primitives such as message sending and receiving to transfer data between processes, thereby completing data communication.

[0064] A latency-sensitive centralized IPC is used to coordinate and manage communication between different virtual machines. It employs a latency-sensitive message prioritization mechanism, adjusting message priorities based on urgency and real-time requirements. Other names may also be used for latency-sensitive centralized IPC; this application does not impose specific limitations on these names.

[0065] (4) A real-time operating system is an operating system that can accept and process external events or data at a sufficiently fast speed when they are generated. The result of its processing can control the production process or respond quickly to the processing system within a specified time, schedule all available resources to complete real-time tasks, and control all real-time tasks to run in a coordinated manner. Examples include uCOS, VxWorks, and RTLinux.

[0066] Non-real-time operating systems refer to systems that do not guarantee the timely execution of tasks, do not require response time to external events, and do not require the simultaneous execution of multiple tasks. Examples include Windows, Linux, and macOS.

[0067] This application applies to robot application scenarios. The robot involved in this application can be a mechanical device that can replace or assist humans in performing tasks, and can also be called an electromechanical device, controlled by computer programs or electronic circuits.

[0068] Robots can be applied in various fields, such as homes, hotels, hospitals, museums, and industrial parks, to provide services like logistics, inspection, and guidance. For example, robots in industrial parks can provide delivery services, perform work condition checks, and even replace humans in high-risk environments. Robots used in industrial settings are also called industrial robots; these could be multi-jointed manipulators or multi-degree-of-freedom robots designed for industrial applications. Robots used in hotels, museums, and hospitals can provide directions, food delivery, and guided tours for visitors and patients.

[0069] The embodiments of this application can be applied to the motion control system of a robot. Referring to Figure 1, the motion control system of the robot includes the robot's control device and one or more servo motors of the robot.

[0070] The robot's control unit, also known as the controller or master station, is the robot's brain, responsible for processing and executing program instructions and coordinating and controlling the robot's motion sequences. It comprises hardware and software components used for decision-making, motion planning, and real-time control. For example, the control unit runs algorithms required for robot operation, generating motor motion commands for each of the robot's servo motors. This control unit periodically sends these commands to each servo motor. The robot's servo motors can also be called servo drives or slave stations. Servo motors (or servo drives): Servo motors are the robot's power source, periodically receiving motor motion commands from the control unit and converting electrical energy into mechanical energy to drive the robot's joints or moving parts. Servo motors provide precise speed and position control.

[0071] Referring to Figure 2, this is a schematic diagram of the software structure of the control device. The software structure of the control device can be a layered architecture, for example, the software can be divided into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. For example, the robot control device may include an operating system layer and a hardware layer. The operating system layer may include an application layer and an operating system kernel layer. The application layer may include robot application components and robot runtime components. The application layer can also be called the task layer. Robot tasks include real-time tasks and non-real-time tasks. The robot application components are used to execute non-real-time tasks, and therefore can also be called non-real-time application components, non-real-time application nodes, or non-real-time task nodes. The robot runtime components are used to execute real-time tasks, and therefore can also be called real-time application components, real-time application nodes, real-time task nodes, or robot runtime nodes. In the following description, it will be referred to as a robot runtime node. The robot application components can also be called robot application nodes, and other names can also be used. This application embodiment does not impose specific limitations on this. In the following description, it will be referred to as a robot application node.

[0072] Robot application nodes are used to run non-real-time applications for the robot, such as image processing and human-computer interaction. For example, they generate control commands for the robot's movement position and pose based on business requirements. Robot runtime nodes are used to execute real-time tasks, such as receiving control commands from robot application components, generating motor movement commands for each joint of the robot, and periodically sending them to the servo motors.

[0073] In some potential application scenarios, servo motors may also include an operating system layer and a hardware layer. The operating system may include a control layer and an operating system kernel layer. The control layer may include slave control nodes. The control nodes periodically receive motor motion commands from the robot control device and drive the various motor components to perform movements according to the motor motion commands.

[0074] Understandably, a shorter instruction cycle for motor motion commands results in more precise control, and better real-time performance and stability of the underlying operating system and communication allow for even shorter instruction cycles. Good system real-time performance leads to less jitter, and a smaller proportion of jitter and communication latency in the instruction cycle allows for even shorter instruction cycles. Therefore, real-time performance, low latency, and stability of the system and communication are core fundamental capabilities.

[0075] Currently, the robot's motion control system is primarily developed based on the Linux operating system. This system relies on the real-time stability of Linux to meet the robot's motion control requirements. However, as a general-purpose operating system, Linux contains a lot of code that disables interrupts and preemption. Because of this disabling of interrupts and preemption in the kernel, the robot's runtime components may experience interruptions in real-time tasks, resulting in a significant latency and inability to guarantee real-time performance.

[0076] Therefore, in this embodiment, real-time application components and non-real-time application components are deployed on different operating systems. Real-time application components run on a real-time operating system (RTOS), while non-real-time application components run on a non-real-time operating system. The real-time operating system does not have much code for disabling interrupts and preemption, thus ensuring the real-time performance of real-time applications and reducing latency.

[0077] Taking a robot with N servo motors as an example. Referring to Figure 3A, the control device is equipped with both a non-real-time operating system and a real-time operating system. For clarity, this is referred to as the first real-time operating system, distinguishing it from the real-time operating system mentioned later. The control device is connected to each of the N servo motors, where N is a positive integer. For example, the non-real-time operating system can be a Linux system, and the real-time operating system can be a non-Linux system.

[0078] Robot application nodes run on a non-real-time operating system. Robot runtime nodes run on a real-time operating system. Robot application nodes can include motion path planning, machine vision image processing, etc. Data from robot application nodes is transmitted in the form of aperiodic data (aperiodic control instructions). Robot runtime nodes execute the robot's underlying speed, position, and other controls. Data from robot runtime nodes is transmitted in the form of periodic data (periodic control instructions).

[0079] Referring to Figure 3B, which is a flowchart illustrating a robot control method according to an embodiment of this application, the method includes steps 301-304. 301: A non-real-time operating system generates control instructions to control the robot's movement. 302: The non-real-time operating system sends the control instructions to a first real-time operating system. For example, the control instructions can indicate the robot's running position and / or pose. For instance, the robot moves to a certain coordinate point or turns to a certain angle. 303: The first real-time operating system generates motor movement instructions corresponding to N servo motors based on the control instructions. 304: The corresponding servo motors are driven to move according to the motor movement instructions for each of the N servo motors.

[0080] In one possible implementation, the control function of the servo motors can also be moved from the servo motors to the control device. For example, as shown in Figure 4, one or more second real-time operating systems are deployed on the control device, with each of the N servo motors corresponding to one second real-time operating system. The second real-time operating system is used to drive the movement of the servo motors in real time. The control functions of different servo motors can be implemented by one real-time operating system, or they can be implemented by different real-time operating systems, which can be configured according to real-time requirements. For example, the control function of the servo motor with the highest real-time requirements can be implemented by a separate second real-time operating system, while the functions of multiple servo motors with less stringent real-time requirements can be implemented by a single second real-time operating system.

[0081] Referring to Figure 4, an example is taken where N servo motors correspond one-to-one with N second real-time operating systems. Each second real-time operating system can run the control node of the servo motor. The control node of the servo motor can also be called the slave control node.

[0082] The first real-time operating system (RTOS) can periodically send motor motion commands to the second real-time operating system (RTOS), which then drives the motor components based on these commands. The second ROS can also acquire servo motor status information and feed it back to the first ROS. Furthermore, the first ROS uses this status information to perform motion compensation and other functions to optimize the motor commands for the next cycle. After completing the motion operation over multiple cycles, the first ROS returns the results to the non-real-time operating system. Based on this, the first and second ROS can synchronize motor motion commands and status information. The second ROS can also communicate with the physical driver of the motor components to control and exchange data with it.

[0083] Taking the first servo motor as an example, the first servo motor is any one of the N servo motors. The first real-time operating system sends the corresponding first motor motion command to the second real-time operating system corresponding to the first servo motor. Further, the second real-time operating system corresponding to the first servo motor drives the first servo motor to move according to the first motor motion command. For example, after the first real-time operating system generates the first motor motion command, it can store it in shared memory. This shared memory is shared between the first real-time operating system and the second real-time operating system. The second real-time operating system obtains the first motor motion command from the shared memory, and can generate a motor control signal (such as a pulse width modulation (PWM) control signal) according to the first motor motion command, and send the control signal to the motor, so that the motor moves according to the control signal. The first motor motion command can be understood as a digital signal, while the control signal can be understood as an analog signal. Optionally, the second real-time operating system can also obtain the motor status information of the servo motor and send it to the first real-time operating system, so that the first real-time operating system can perform functions such as motion compensation according to the motor status information to optimize the motor motion command for the next cycle.

[0084] In some possible implementations, different operating systems can transmit instructions through inter-process communication (IPC).

[0085] IPC is a general term for inter-process data communication methods in operating systems. Two or more parties involved in the communication use primitives such as message sending and receiving to transfer data between processes, thereby completing data communication.

[0086] Currently, the control device and the controller (or slave station) on the servo motor are connected via the EtherCAT bus. However, the EtherCAT bus can only bypass the kernel's Transmission Control Protocol / Internet Protocol (TCP / IP) stack, but still requires other protocol stacks, resulting in high latency in message transmission from the master station to the slave station. The solution described in this application migrates the servo motor control function, i.e., the slave control node, to the control device. In other words, both the master and slave stations are deployed on the control device, eliminating the need for the EtherCAT bus connection and thus reducing message transmission latency.

[0087] Referring to Figure 5, an IPC module can be deployed in the control device. The IPC module can also be called an IPC scheduler or other names; this embodiment does not limit the specific terminology used. The IPC module is used for instruction scheduling between the non-real-time operating system and the first real-time operating system, and between the first real-time operating system and the second real-time operating system. For example, the IPC module is used to schedule control instructions from the non-real-time operating system to the first real-time operating system, and to schedule first motor motion instructions from the first real-time operating system to the second real-time operating system.

[0088] In some possible implementation scenarios, the IPC module also has latency-sensitive capabilities. Based on this, the IPC module can also be called a latency-sensitive centralized IPC module or a latency-sensitive centralized IPC scheduler.

[0089] The latency-sensitive centralized IPC scheduler is responsible for coordinating and managing communication between different operating systems. It supports a unified scheduling mechanism to ensure that message transmission latency is minimized and to dynamically adjust resource allocation according to system load and real-time requirements. The latency-sensitive centralized IPC scheduler supports (1) priority scheduling function.

[0090] Priority scheduling function: This function schedules messages based on their priority. Message priority is related to the urgency (or importance) of the message and the real-time requirements (or the maximum supported latency). Priority scheduling ensures that critical instructions are delivered first, reducing the waiting time for important instructions or instructions requiring low latency, thus improving system real-time performance. For example, the priority of IPC module scheduling control instructions is lower than the priority of scheduling motor motion instructions. This can be understood as the priority of messages transmitted between a non-real-time operating system and a first real-time operating system being lower than the priority of messages transmitted between the first real-time operating system and a second real-time operating system. Furthermore, motor motion instructions include various message types. Taking a first message type and a second message type as examples, the priority of the IPC module scheduling motor motion instructions of the first message type is higher than the priority of scheduling motor motion instructions of the second message type.

[0091] For example, priorities are categorized into three types: high priority, medium priority, and low priority. These can be referred to as first priority, second priority, and third priority. The order of priority from highest to lowest is: first priority > second priority > third priority. For instance, instructions from a non-real-time operating system have a low priority. Instructions sent from a first real-time operating system to a second real-time operating system have medium and high priorities. For example, periodic instructions for a real-time task have a medium priority, while instructions used to interrupt or adjust the task have a high priority.

[0092] The latency-sensitive centralized IPC scheduler also supports (2) message queue management. Message queues are set up for messages of different priorities, and messages of different priorities enter different message queues. The latency-sensitive centralized IPC scheduler supports maintaining the status of all message queues in the system. The priority of each message in the queue is related to the importance of the message and the real-time requirements. The messages in the message queue are dynamically scheduled to ensure the orderly transmission of messages and to ensure that high-priority messages are transmitted first. The latency-sensitive centralized IPC scheduler includes a first queue and a second queue. The first queue is used to add motor motion instructions of the first message type from the first real-time operating system, and the second queue is used to add motor motion instructions of the second message type from the first real-time operating system. The scheduling priority of the first queue is higher than that of the second queue. The latency-sensitive centralized IPC scheduler may also include a first queue and a third queue for adding control instructions from a non-real-time operating system. The scheduling priority of the third queue is lower than that of the second queue.

[0093] A latency-sensitive centralized IPC scheduler can reduce data copying by using (3) shared memory. For example, there is shared memory between a non-real-time operating system and a first real-time operating system. There is also shared memory between the first real-time operating system and different second real-time operating systems. This shared memory can be allocated to each operating system by the IPC scheduler. For example, when the IPC scheduler receives control instructions from a non-real-time operating system, the IPC scheduler stores the control instructions in the shared memory. The identification information of the control instructions can also be added to the corresponding priority queue according to the priority of the control instructions for subsequent scheduling. Correspondingly, this method can also be used between the first real-time operating system and the second real-time operating system. By optimizing the communication path between different operating systems in the above way, data copying is reduced, further reducing the latency and processing overhead of data transmission, and improving communication efficiency.

[0094] In the above scheme, multiple critical operating systems (OS) are deployed in a hybrid manner, including robot application nodes, robot runtime nodes, and virtual slave nodes. A latency-sensitive centralized IPC scheduler coordinates and manages communication between different operating systems. A latency-sensitive message prioritization mechanism is employed to dynamically adjust message priorities based on message urgency and real-time requirements, thereby reducing robot transmission latency. Furthermore, the control scheme in this application meets intelligent requirements without relying on existing ecosystem software.

[0095] The aforementioned non-real-time operating systems and real-time operating systems can occupy different hardware resources on the control device. For example, hardware resources may include a processor and / or a network interface card (NIC). In some possible implementations, the non-real-time operating system and the first real-time operating system occupy different hardware resources. Different second real-time operating systems can occupy the same hardware resources or different hardware resources. For example, two or more second real-time operating systems may occupy the same hardware resources, while the remaining second real-time operating systems occupy different hardware resources. In some implementations, different second real-time operating systems exclusively occupy different hardware resources. In some implementations, different second real-time operating systems may exclusively occupy different processors but may share the same NIC.

[0096] In some embodiments, the control device is deployed on a chip (or board); therefore, the control device can also be called a control board. The control board can connect to N servo motors via peripheral interfaces. For example, the peripheral interface can be a PWM port or a serial port. The control board can include multiple processors to allow real-time and non-real-time operating systems to be deployed on different processors.

[0097] In some possible implementations, different operating systems can be deployed on different processor cores or on different virtual machines. Different virtual machines can be deployed on the same processor or on different processors.

[0098] When different operating systems are deployed on different processor cores, the real-time operating system and the non-real-time operating system are deployed separately in this embodiment of the application. The IPC module in this embodiment of the application supports message scheduling between processor cores. Instruction transmission does not need to go through the network, which can eliminate the Ethercat bus latency between the master station and the slave station, reduce the communication latency of Ethernet / bus, and also reduce the connection lines between various components of the robot, thereby increasing communication bandwidth and miniaturizing size.

[0099] The following description focuses on the method of deploying the operating system on a virtual machine. This application utilizes a virtualization dock to deploy different operating systems on a control device, allowing real-time application components and non-real-time application components to be deployed on different operating systems. Real-time application components run on a real-time operating system and are deployed on one or more virtual machines, while non-real-time application components run on a non-real-time operating system and are deployed on different virtual machines than the real-time application components. The real-time operating system does not have extensive code for disabling interrupts and preemption, thus ensuring the real-time performance of real-time applications and reducing latency. The virtualization dock can also be called a Virtual Machine Manager (VMM) (or Hypervisor).

[0100] Before describing the specific solutions provided in the embodiments of this application, a brief description of the virtualization framework is given below.

[0101] Referring to Figure 6, this application provides a schematic diagram of the basic architecture of a control device for running virtual machines. At least two virtual machines are deployed on the control device. As shown in Figure 6, the control device includes a hardware layer and a software layer. The hardware layer is a standard configuration for the control device, and the software layer includes a Virtual Machine Manager (VMM, also known as a Hypervisor). The Virtual Machine Manager's role is to implement computational virtualization, network virtualization, and storage virtualization of the virtual machines, and to manage the virtual machines.

[0102] Computational virtualization refers to providing a portion of the processor and memory of the control unit to virtual machines. Network virtualization refers to providing a portion of the network interface card's (NIC) functionality (such as bandwidth) to virtual machines. Storage virtualization refers to providing a portion of the disk space to virtual machines. A virtual machine manager can also achieve logical isolation between different virtual machines and manage them, such as creating virtual machines, simulating virtual hardware for virtual machines based on the hardware layer (hardware emulation function), deleting virtual machines, forwarding and / or processing network packets between all virtual machines running on the control unit (e.g., virtual machine 1 and virtual machine 2) or forwarding network packets between virtual machines on the control unit and the external network (virtual switching function), and handling I / O generated by virtual machines.

[0103] The runtime environments (such as virtual machine applications, operating systems, and virtual hardware) in different virtual machines are completely isolated. Communication between virtual machine 1 and virtual machine 2 requires the virtual machine manager to forward network packets. Users can install, configure, and uninstall applications within the virtual machine's operating system environment.

[0104] In some embodiments of this application, different operating systems can run on virtual machine 1 and virtual machine 2. For example, virtual machine 1 runs a non-real-time operating system, and virtual machine 2 runs a real-time operating system (RTOS). In the following description, the non-real-time operating system will be referred to as Linux, and virtual machine 1 can also be called a Linux virtual machine, while virtual machine 2 can be called an RT virtual machine (RTVM). Embodiments of this application can utilize hardware virtualization, isolation, and device passthrough technologies of the virtualization platform to deploy robot application nodes and runtime nodes with different real-time requirements on Linux and RTOS respectively. This combines the ecosystem capabilities of Linux with the real-time capabilities of RTOS to reduce the processing latency of real-time tasks.

[0105] As shown in Figure 7, the Linux virtual machine runs the robot application node, and the RTVM runs the robot runtime node. There is strong isolation between the Linux virtual machine and the RTVM, ensuring that the tasks executed by the robot application node do not affect the tasks executed by the robot runtime node, thus reducing the processing latency of real-time tasks.

[0106] A Linux virtual machine runs a robot application node, generates control commands to control the robot's movement, and sends these commands to the robot runtime node running on RTVM. The robot runtime node parses the control commands and generates motor motion commands for N servo motors, then drives the corresponding servo motors according to these commands.

[0107] In one possible implementation, the control function of the servo motor can also be moved from the servo motor to the control device. For example, as shown in Figure 8, one or more virtual machines can be created on the control device, which can act as virtual slaves. A real-time operating system is deployed on the virtual slaves.

[0108] In some embodiments, the number of virtual slaves matches the number of servo motors, as shown in Figure 8, where servo motors 1 to N correspond to virtual slaves 1 to N. Virtual slaves can be created by a virtual machine manager. The virtual machine manager can create real-time virtual machines (or real-time OS instances) based on the number of servo motors, performing the original motor (or slave) control functions on the control device. It should be noted that the control functions of different servo motors can be implemented by one real-time virtual machine, or by different real-time virtual machines, depending on the real-time requirements.

[0109] RTVM can periodically send motor motion commands to the virtual slave, which then drives the motor portion of the machine based on these commands. The virtual slave can also acquire the servo motor's status information and feed it back to RTVM. RTVM then uses this status information to perform motion compensation and other functions to optimize the motor commands for the next cycle. After completing multiple cycles of motion operations, RTVM returns the results to the Linux virtual machine. Based on this, RTVM and the virtual slave can synchronize motor motion commands and status information. The virtual slave can also communicate with the physical driver of the motor portion to control and exchange data with it. For example, the virtual slave may have an interface adapted to the physical driver for control and data exchange.

[0110] Taking servo motor 1 as an example, the RTVM sends a corresponding first motor motion command to the virtual slave station 1 corresponding to servo motor 1. Further, the virtual slave station 1 drives the servo motor 1 to move according to the first motor motion command. In some embodiments, virtual machines can use shared memory to achieve real-time communication. For example, after the RTVM generates the first motor motion command, it can store it in shared memory. This shared memory is shared between the RTVM and the virtual slave station 1. The RTVM retrieves the first motor motion command from the shared memory, and can generate control signals for the motor (such as pulse width modulation (PWM) control signals) based on the first motor motion command, and send the control signals to the motor, thereby causing the motor to move according to the control signals.

[0111] With the rapid development of robotics technology, the demands on the real-time performance, accuracy, and reliability of control systems are increasing. Traditional EtherCAT-based master-slave architectures face challenges such as communication latency, bandwidth limitations, and complex wiring. Virtual slave technology implements slave functionality within the control device through software definition and employs a high-performance IPC mechanism to communicate with the robot during runtime. This eliminates latency between physical master and slave stations, thereby improving system performance.

[0112] In some possible implementations, the virtualization platform supports different virtual machines (VMs) exclusively using hardware resources, such as processors and network interface cards (NICs). Linux VMs and RTVMs can occupy different hardware resources on the control unit. In some possible implementations, Linux VMs and RTVMs occupy different hardware resources. Different virtual slaves can occupy the same hardware resources or different hardware resources. For example, two or more virtual slaves may occupy the same hardware resources, while the rest may occupy different hardware resources. In some implementations, different virtual slaves exclusively use different hardware resources. In some implementations, different virtual slaves can exclusively use different processors but can share the same NIC.

[0113] In some embodiments, an IPC scheduler or a latency-sensitive centralized IPC scheduler is deployed in the control device, as shown in Figure 9. Optionally, the IPC scheduler can be deployed on a separate virtual machine, in a virtual machine manager, or in a Linux virtual machine. The Linux virtual machine and the RTVM can communicate through the latency-sensitive centralized IPC scheduler, and the RTVM and the virtual slaves can communicate with low latency through latency-sensitive centralized IPC technology.

[0114] In one possible implementation scenario, the control device can also deploy a separate virtual machine responsible for management, referred to as the first management virtual machine. This virtual machine can interact with the virtual machine manager to manage the lifecycle of other virtual machines, such as starting, stopping, or deleting them. Optionally, the first management virtual machine can provide a user-friendly interface, allowing users to create virtual machines as needed.

[0115] In another possible implementation scenario, a separate virtual machine, referred to as the second management virtual machine, can be deployed in the control device to manage the virtual slave stations. The second management virtual machine is primarily responsible for creating virtual slave station instances. For example, it can have one or more of the following functions.

[0116] (1) Virtual slave creation: Dynamically create virtual slave instances based on configuration files.

[0117] (2) Lifecycle management: manage the startup, shutdown, and restart of virtual slave stations.

[0118] (3) Resource allocation: Allocate resources to the virtual slave station, such as CPU, network card or memory.

[0119] (4) Configuration Management: Manage the parameter configuration of virtual slave stations.

[0120] (5) Status monitoring: Real-time monitoring of the operating status of virtual slave stations.

[0121] (6) Fault handling: Detect and handle virtual slave station faults.

[0122] Optionally, the functionality of the first management virtual machine can also be implemented by a Linux virtual machine or by a virtual machine manager. Similarly, the functionality of the second management virtual machine can also be implemented by a Linux virtual machine or by a virtual machine manager. In some implementation scenarios, the functionality of both the first and second management virtual machines can be implemented by a single virtual machine, which can be referred to as the management virtual machine.

[0123] The solution provided in this application is described below with examples. Taking the control device deployed on a board as an example, this board will be referred to as the control board in the following description.

[0124] As shown in Figure 10, after deploying the virtualization base on the robot's control board, a management virtual machine is first created and started. The management virtual machine provides a user-operable interface. Through this interface, users can create a Linux VM and several RTVMs, and can deploy robot application nodes (such as human-machine interaction) on the Linux VM, while the RTVMs deploy robot runtime nodes with high real-time requirements and virtual slave stations for N servo motors.

[0125] After the robot application node starts running, it waits for user input to generate control commands. For example, the user can perform operations through a human-machine interface to control the robot's movement. The robot application node responds to the operation by generating control commands. For example, the control commands indicate the robot's position and pose. Optionally, the robot application node can first determine whether the user's operation is valid based on the current robot state. If valid, it generates control commands and sends them to the robot runtime node via the IPC module. If invalid, it continues to wait for user input. After the robot runtime node starts running, it waits for control commands. Upon receiving the control commands from the robot application node, the robot runtime node parses the control commands and generates motor motion commands for each servo motor. Since the control commands need to be converted into motor motion commands for multiple clock cycles, the robot runtime node can cache the received control commands. Furthermore, the robot runtime node periodically calculates the motor motion commands for each servo motor and periodically sends them to each virtual slave station. As shown in Figure 11, the robot runtime node calculates the motor motion commands for each servo motor in each command cycle and sends them to each virtual slave station. The virtual slave station receives corresponding motor motion commands to complete motor control and feeds back motor status information to the robot runtime node. The robot runtime node can perform functions such as motion compensation based on the motor status information to optimize the servo motor motion commands for the next cycle. Optionally, after receiving the motor status information, the robot runtime node notifies the robot application node to update the robot's status information. Optionally, after receiving the motor status information, the robot runtime node determines whether the servo motor has completed its motion in the current cycle. If so, it completes the current motion, returns the result to the robot application node, and the robot application node continues to wait for the next user operation. If it determines that the servo motor has not completed its motion in the current cycle, it can perform functions such as motion compensation based on the motor status information to optimize the servo motor motion commands for the next cycle.

[0126] The technical solution provided in this application embodiment can fully utilize the device pass-through and multi-domain isolation capabilities offered by the real-time virtualization platform, ensuring that each component does not interfere with the others. Simultaneously, due to the strong real-time capabilities of the real-time operating system, the stability of the instruction cycle is guaranteed, enabling real-time communication and providing a solid guarantee for the stable and high-speed operation of the robot.

[0127] The solution described in this application achieves multi-OS deployment through a virtualization platform, introducing the strong real-time capabilities of an RTOS and reducing OS latency jitter. Different robot components can be deployed on different OSs, achieving strong isolation and preventing high-real-time applications from being affected by low-real-time applications, further reducing latency. In addition, this application proposes a virtual slave station solution to implement slave station functionality on the same control board. During robot operation, communication between the robot and the slave station control node does not need to be via bus / Ethernet, reducing Ethernet / bus communication latency, reducing the number of connection cables between robot components, achieving increased communication bandwidth, miniaturization, higher efficiency, and better real-time performance.

[0128] Figure 12 shows a schematic diagram of the control device provided in an embodiment of this application. The control device shown in Figure 12 is used to perform the operations performed by the control device described in any of the above embodiments.

[0129] As shown in Figure 12, the control device includes at least one processor, a memory, and at least one communication interface. The processor may be, for example, a general-purpose central processing unit (CPU), a digital signal processor (DSP), a network processor (NP), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the scheme of this application. For example, the processor may include an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The PLD may be, for example, a complex xprogrammable logic device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof. It can implement or execute various logic blocks, modules, and circuits described in conjunction with the embodiments of this application. The processor may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0130] Optionally, the control device also includes a bus. The bus is used to transmit information between the various components of the control device. The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one thick line is used in Figure 12, but this does not indicate that there is only one bus or one type of bus.

[0131] The memory may be, for example, read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; electrically erasable programmable read-only memory (EEPROM); compact disc read-only memory (CD-ROM) or other optical disc storage; optical disc storage (including compressed discs, laser discs, optical discs, digital universal discs, Blu-ray discs, etc.); magnetic disk storage media or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited to these. The memory may exist independently and be connected to the processor via a bus. The memory may also be integrated with the processor. The communication interface uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, wireless access networks (RAN), or wireless local area networks (WLAN). The communication interface includes at least a peripheral interface, such as a PWM interface. It may also include an Ethernet interface, a Fast Ethernet (FE) interface, a Gigabit Ethernet (GE) interface, an Asynchronous Transfer Mode (ATM) interface, a Wireless Local Area Network (WLAN) interface, a cellular network communication interface, or a combination thereof. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. In this embodiment, the communication interface can be used for the control device to communicate with other devices.

[0132] In a specific implementation, as one example, the processor may include one or more CPUs, such as CPU0 and CPU1 shown in Figure 12. Each of these processors may be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0133] In a specific implementation, as one embodiment, the control device may include multiple processors, such as processor 121 and processor 122 shown in FIG12. Each of these processors may be a single-core processor (single CPU) or a multi-core processor (multi CPU). Here, a processor may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0134] In a specific implementation, as one example, the control device may further include output devices and input devices. The output device communicates with the processor and can display information in various ways. For example, the output device may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device communicates with the processor and can receive user input in various ways. For example, the input device may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0135] In some embodiments, the memory is used to store program code for executing the solution of this application, and the processor can execute the program code stored in the memory. That is, the control device can execute the program code in the memory through the processor to implement the inter-process communication method provided in the method embodiments. The program code may include one or more software modules. Optionally, the processor itself may also store program code or instructions for executing the solution of this application.

[0136] In specific embodiments, the control device of this application can correspond to the controller in the above-described method embodiments. The processor in the control device reads instructions from the memory, enabling the control device shown in FIG12 to execute all or part of the operations performed by the controller.

[0137] In the above embodiments, each step of the method executed by the control device is completed through integrated logic circuits in the hardware of the control device's processor or through software instructions. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or as a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. Since this storage medium is located in memory, the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method; to avoid repetition, these will not be described in detail here.

[0138] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected via internal interconnection paths. The processor is used to execute code in the memory, and when the code is executed, the processor is used to perform any of the inter-process communication methods described above.

[0139] It should be understood that the aforementioned processor can be a CPU, or it can be other general-purpose processors, DSPs, ASICs, FPGAs, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting the ARM architecture.

[0140] Further, in an optional embodiment, the processor and the memory may be one or more. Optionally, the memory may be integrated with the processor or may be disposed separately from the processor. The memory may include read-only memory and random access memory, and provide instructions and data to the processor. The memory may also be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may be ROM, PROM, EPROM, EEPROM, or flash memory. Volatile memory may be RAM, which is used as an external cache. By way of example, but not limitation, many forms of RAM are available. For example, SRAM, DRAM, SDRAM, DDR SDRAM, ESDRAM, SLDRAM, and DR RAM.

[0141] In this embodiment of the application, a computer-readable storage medium is also provided, which stores computer instructions. When the computer instructions stored in the computer-readable storage medium are executed by a control device, the control device executes the inter-process communication method provided above.

[0142] In this application embodiment, a computer program product containing instructions is also provided, which, when run on a control device, causes the control device to execute the inter-process communication method provided above.

[0143] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk).

[0144] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0145] The above description is merely an optional embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0146] Unless otherwise defined, the technical or scientific terms used herein shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “first,” “second,” “third,” and similar terms used in this patent application specification and claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, the terms “an” or “a” and similar terms do not indicate a quantity limitation, but rather indicate the presence of at least one. The terms “comprising” or “including” and similar terms used in this application mean that the elements or objects preceding “comprising” or “including” encompass the elements or objects listed following “comprising” or “including” and their equivalents, and do not exclude other elements or objects.

[0147] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A control method of a robot characterized by, A control device for a robot is provided, wherein the control device is equipped with a non-real-time operating system and a first real-time operating system; the robot includes N servo motors, where N is a positive integer; the control device is connected to the N servo motors. The non-real-time operating system generates control instructions for controlling the robot's movement and sends the control instructions to the first real-time operating system. The first real-time operating system generates motor motion instructions corresponding to the N servo motors according to the control instructions, and drives the corresponding servo motors to move according to the motor motion instructions corresponding to the N servo motors.

2. The method of claim 1, wherein, The control device is also equipped with at least one second real-time operating system; each of the N servo motors corresponds to one second real-time operating system. The first real-time operating system drives the corresponding servo motors to move according to the motor motion commands corresponding to the N servo motors, including: The first real-time operating system sends a corresponding first motor motion command to the second real-time operating system corresponding to the first servo motor; the first servo motor is any one of the N servo motors. The second real-time operating system corresponding to the first servo motor drives the first servo motor to move according to the first motor movement command.

3. The method of claim 2, wherein, The control device is equipped with multiple virtual machines, and the non-real-time operating system, the first real-time operating system, and the at least one second real-time operating system run on different virtual machines.

4. The method of claim 2 or 3, wherein, The non-real-time operating system sends the control commands to the first real-time operating system, including: The non-real-time operating system sends the control commands to the first real-time operating system via inter-process communication (IPC). The first real-time operating system sends corresponding first motor motion commands to the second real-time operating system corresponding to the first servo motor, including: The first real-time operating system sends the first motor motion command to the second real-time operating system corresponding to the first servo motor via the IPC method.

5. The method of claim 4, wherein, The control device is deployed on a chip.

6. The method according to any one of claims 1 to 5, wherein, The control device is connected to the N servo motors through at least one peripheral interface.

7. A control device of a robot characterized by comprising: The control device is equipped with a non-real-time operating system and a first real-time operating system; the robot also includes N servo motors; The non-real-time operating system is used to generate control commands for controlling the robot's movement and send the control commands to the first real-time operating system. The first real-time operating system is used to generate motor motion commands corresponding to the N servo motors according to the received control commands, and drive the N servo motors to move according to the motor motion commands corresponding to the N servo motors.

8. The apparatus of claim 7, wherein, The non-real-time operating system and the first real-time operating system occupy different hardware resources on the control device, including a processor and / or a network card.

9. The apparatus of claim 7 or 8, wherein, The control device is also equipped with at least one second real-time operating system; each of the N servo motors corresponds to one second real-time operating system. The first real-time operating system is specifically used to send a first motor motion command to the second real-time operating system corresponding to the first servo motor; the first servo motor is any one of the N servo motors, and the first motor motion command is a motor motion command that drives the first servo motor to move. The second real-time operating system corresponding to the first servo motor is used to receive the first motor motion command from the first real-time operating system and drive the first servo motor to move according to the first motor motion command.

10. The apparatus of claim 9, wherein, The control device is equipped with multiple virtual machines, and the non-real-time operating system, the first real-time operating system, and the at least one second real-time operating system run on different virtual machines.

11. The apparatus of claim 9 or 10, wherein, The number of the second real-time operating system is the same as the number of the servo motors.

12. The apparatus of claim 10, wherein, It also includes a virtual machine manager; The virtual machine manager is used to create N virtual machines in the control device that correspond one-to-one with the N servo motors, according to the number of servo motors.

13. The apparatus of any one of claims 9-12, wherein, The at least one second real-time operating system independently occupies different hardware resources on the control device, including a processor and / or a network card.

14. The apparatus of any one of claims 9-13, wherein, The control device also includes an inter-process communication (IPC) module; The IPC module is used to schedule the control commands from the non-real-time operating system to the first real-time operating system; and to schedule the first motor motion commands from the first real-time operating system to the second real-time operating system.

15. The apparatus of claim 14, wherein, The IPC module schedules the control commands with a lower priority than it schedules the motor motion commands.

16. The apparatus of claim 14 or 15, wherein, The message types of the motor motion commands include at least a first message type and a second message type. The IPC module schedules motor motion commands of the first message type with a higher priority than scheduling motor motion commands of the second message type.

17. The apparatus of claim 16, wherein, The IPC module includes a first queue and a second queue. The first queue is used to add motor motion commands of the first message type from the first real-time operating system, and the second queue is used to add motor motion commands of the second message type from the first real-time operating system. The scheduling priority of the first queue is higher than that of the second queue.

18. The apparatus of claim 16 or 17, wherein, The priority of the motor motion command is related to the message importance of the motor motion command and / or the maximum supported latency.

19. The apparatus of any one of claims 7-18, wherein, The control device is deployed on a chip.

20. The apparatus of any one of claims 7-19, wherein, The control device is connected to each of the N servo motors via an external interface.

21. A robot, characterized in that Includes the control device as described in any one of claims 7-20.

Images