A general software layered architecture for distributed formation robots

Abstract

The present invention discloses a general software layered architecture for distributed formation robots, comprising: a physical link layer, which is responsible for providing different communication modes to the upper layer and completing communication driver configuration; a communication management layer, which includes a formation communication management module and a hardware communication management module, which are used to manage the communication between the robot and different nodes and implement node management, clock synchronization, and data verification functions; a data exchange layer, which includes a network protocol encapsulation module, a hardware data module, and a hardware protocol encapsulation and parsing module, which are responsible for data encapsulation and parsing, and complete data exchange with the algorithm task layer; a task layer, which includes a task manager and a task pool, which are used to develop formation control algorithms and implement the operation and switching of formation tasks. The present invention reduces the difficulty of expanding the formation robot by modifying the communication cycle of the formation robot, increasing or decreasing the number of robots within a certain range, and can be widely used in the field of robot formation control technology.

Description

Technical Field

[0001] The present invention relates to the technical field of robot formation control, and in particular to a general software layered architecture for distributed formation robots. Background Art

[0002] With the continuous development of robotics technology, the application scope of mobile robots is becoming increasingly broad. Mobile robots are now widely used in fields such as resource exploration, search and rescue, and military aerospace. Individual mobile robots have achieved relatively good performance. However, due to the complex environments they face, many tasks require coordination between them. Compared to individual robots, formation robot systems offer improved robustness and information accuracy, and as a result, formation robots have attracted extensive research. Complex formation robots are mostly composed of distributed, multi-tasking, heterogeneous embedded systems. The hardware platforms vary significantly between different systems, and the underlying communication protocols, hardware drivers, and operating systems can differ significantly. This leads to shortcomings such as low code reuse, poor scalability, and difficulty in maintenance. Furthermore, collaboration between formation robots requires data sharing, and different formation control algorithms require widely varying data. This creates inconvenience for formation control algorithm designers. Therefore, how to shield the differences in the underlying hardware of formation robots, resolve data sharing issues among different control algorithms, and achieve system software commonality are unresolved challenges in the field of formation robots. Summary of the Invention

[0003] In order to solve at least one of the technical problems existing in the prior art to a certain extent, the present invention aims to provide a general software layered architecture for distributed formation robots.

[0004] The technical solution adopted in the present invention is:

[0005] A general software layered architecture for distributed formation robots, including:

[0006] The physical link layer is responsible for providing different communication methods to the upper layer and completing the communication driver configuration;

[0007] The communication management layer, including the formation communication management module and the hardware communication management module, is used to manage the communication between the robot and different nodes, and implement node management, clock synchronization, and data verification functions. Among them, the formation communication management module modifies the communication cycle of the formation robot and increases or decreases the number of robots to reduce the difficulty of expanding the formation robot.

[0008] The data exchange layer includes a network protocol encapsulation module, a hardware data module, and a hardware protocol encapsulation and parsing module. It is responsible for data encapsulation and parsing, and completes data exchange with the algorithm task layer.

[0009] The task layer, including the task manager and task pool, is used to develop the formation control algorithm and realize the operation and switching of formation tasks.

[0010] Furthermore, the physical link layer is specifically used to provide different data transmission paths, including but not limited to UART, CAN, I2C, wireless communication and other communication methods, providing a data transmission interface in bytes to the upper layer, and freely switching the transmission path according to the upper layer's selection to achieve transparent transmission.

[0011] Furthermore, the formation communication management module manages the communication between the formation robot nodes in a time-division multiplexing manner, dividing a single formation communication cycle into multiple time slices. Each communication cycle is initiated by the instruction sending node and occupies the first time slice in the cycle. The remaining formation robot nodes sequentially use subsequent time slices to send data.

[0012] Among them, the instruction sending node is used to send formation instructions to control the task execution of the formation; the instruction sending node is a robot node in the formation, or an industrial computer node outside the formation.

[0013] Furthermore, the hardware communication management module manages the communication between the robot and the hardware nodes in a polling manner, that is, the robot node sends control instructions to the hardware node in turn, and receives data returned by the hardware node in turn.

[0014] Furthermore, the network protocol encapsulation module is responsible for completing the encapsulation of shared data, where shared data refers to the data that the formation robots need to obtain to complete the current task;

[0015] The shared data includes: robot information, task data packet, verification information robot information, and the verification information robot information is used to confirm which robot in the formation the data comes from;

[0016] The task data packet includes task information and task data, and the task information is used to determine which task pool the task data comes from.

[0017] Furthermore, the encapsulation and parsing of the shared data are implemented using a variable-length communication protocol;

[0018] The task data packet is generated when the task layer calls the data exchange layer interface; the size and quantity of the task data packet are modified according to the data sharing requirements of different tasks.

[0019] Furthermore, the hardware data module stores measurement data and instruction data of different robot hardware; wherein the instruction data includes the control mode, communication link selection, control parameters, and control instructions of the hardware node; the measurement data includes data and timestamp;

[0020] The algorithm task layer modifies instruction data through the inter-layer interface to control the corresponding hardware functions and obtain measurement data. The instruction writing method adopts multi-level instructions, that is, the hardware controlled by the robot is divided into primary equipment and secondary equipment. The primary equipment is directly connected to the robot and is controlled by primary instructions; the secondary equipment is connected to the primary equipment and is controlled by secondary instructions.

[0021] Multi-level instructions consist of device number, instruction code, and data. Each hardware has a separate device number, and the instruction code and data are determined according to the functions of different devices. Multi-level instructions can unify the robot instruction writing interface and reduce the difficulty of using hardware for tasks.

[0022] Furthermore, the hardware protocol encapsulation and parsing module is used to complete protocol encapsulation according to different hardware communication protocols and instruction data, and to parse the data frames returned from the hardware and upload the data to the measurement data.

[0023] Furthermore, the task manager is responsible for sending or receiving formation instructions. Formation instructions are issued by the instruction sending node, and the other robot nodes receive the formation instructions. The instructions are used to control the running status of the task and realize the free switching of different tasks.

[0024] The task manager adopts a three-patrol verification mechanism when receiving instructions to ensure the correctness of the instructions received by the robot node; the task manager controls the task to switch between four states: task preparation, task running, task pause, and task end according to the instructions.

[0025] Furthermore, the task pool stores the tasks that can be run in the formation, and the task manager selects tasks from the task pool to run according to the instructions;

[0026] The fleet's executable tasks include task codes, and each task is provided with an independent number for the task manager to select and distinguish sources of shared data.

[0027] The beneficial effects of the present invention are as follows: based on the formation communication management module, the present invention can increase or decrease the number of robots within a certain range by modifying the communication cycle of the formation robots, thereby reducing the difficulty of expanding the formation robots. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following introduction is made to the drawings of the embodiments of the present invention or the related technical solutions in the prior art. It should be understood that the drawings introduced below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative work.

[0029] Figure 1 This is a schematic diagram of a general software layered architecture for a distributed formation robot according to an embodiment of the present invention;

[0030] Figure 2 Schematic diagram of the communication cycle of formation robots in an embodiment of the present invention;

[0031] Figure 3 2. It is a schematic diagram of calculating the zero time of the communication cycle in an embodiment of the present invention;

[0032] Figure 4 1 is a schematic diagram of the hardware communication process in an embodiment of the present invention;

[0033] Figure 5 1 is a schematic diagram of the variable-length protocol frame format according to an embodiment of the present invention;

[0034] Figure 6 1 is a schematic diagram of a multi-level instruction format according to an embodiment of the present invention;

[0035] Figure 7 Schematic diagram of the three-round verification mechanism in an embodiment of the present invention;

[0036] Figure 8 Schematic diagram of task state switching in an embodiment of the present invention. DETAILED DESCRIPTION

[0037] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention and are not to be construed as limiting the present invention. The step numbers in the following embodiments are provided for ease of explanation only and do not limit the order of the steps. The order of execution of the steps in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0038] In the description of the present invention, it should be understood that descriptions involving orientations, such as up, down, front, back, left, right, etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, they cannot be understood as limitations on the present invention.

[0039] In the description of the present invention, "several" means one or more, "many" means more than two, "greater than," "less than," and "exceed" are understood to exclude the number itself, while "above," "below," and "within" are understood to include the number itself. The use of "first" and "second" in the description is solely for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance, implicitly specifying the number of the indicated technical features, or implicitly specifying the order of the indicated technical features.

[0040] In the description of the present invention, unless otherwise clearly defined, terms such as setting, installing, and connecting should be understood in a broad sense, and technicians in the relevant technical field can reasonably determine the specific meanings of the above terms in the present invention based on the specific content of the technical solution.

[0041] This embodiment provides a distributed formation robot general software layered architecture that can shield the underlying hardware differences of the formation robots, solve the data sharing differences of different control algorithms of the formation robots, reduce the difficulty of developing the formation control algorithm, and ensure the convenience of designing the formation control algorithm. Figure 1 As shown, Figure 1 This is a general software layered architecture for formation robots. The general software layered architecture for formation robots includes: from the bottom to the top, there are physical link layer, communication management layer, data exchange layer, and algorithm task layer.

[0042] The physical link layer is responsible for providing different communication methods to the upper layer and completing the communication driver configuration, such as UART, CAN, I2C, wireless communication and other communication methods.

[0043] The communication management layer includes the formation communication management module and the hardware communication management module, which are responsible for managing the communication between the robot and different nodes, and realizing node management, clock synchronization, and data verification functions.

[0044] The data exchange layer includes the network layer protocol encapsulation module, the hardware data module, and the hardware protocol encapsulation and parsing module. It is responsible for data encapsulation and parsing, and completes data exchange with the algorithm task layer.

[0045] The task layer includes a task manager and a task pool, which are used to develop formation control algorithms and realize the operation and switching of formation tasks.

[0046] This implementation case takes a formation system consisting of four robots and one base station as an example, and further explains it with reference to the attached figures. The following is a detailed explanation of the construction of different layers of the software layered architecture:

[0047] Step S1-1: The physical link layer is responsible for providing different communication methods to the upper layer and completing the communication driver configuration. This layer includes the physical transmission media and equipment, as well as the relevant configuration and code of various bus protocols in the software, such as UART, CAN, I2C, wireless communication and other communication methods.

[0048] Step S1-2: The communication management layer includes a formation communication management module and a hardware communication management module, which are responsible for managing the communication between the robot and different nodes.

[0049] The formation communication management module uses time division multiplexing to manage the formation robot nodes. The formation management module has a unified interface function, including: communication cycle management function FTManager(), data sending function FSendData(), data receiving function FGetData(), etc. Figure 2 As shown, a formation communication cycle is established. The system uses the base station as the command sending node for sending formation commands. However, the software framework does not require a base station as the formation command sending node; the command sending node can also be a robot in the formation. The variable FPeriod represents the communication cycle duration. A single communication cycle is initiated by the command sending node, which starts a loop timer with a duration of FPeriod and uses a time slice of FLeaderTS to send commands. Command sending is implemented by calling the data sending function FSendData(). The remaining robot nodes, in turn, use time slices of FRobotTS to send data. By modifying the communication cycle duration FPeriod and the time slice length FRobotTS, the formation communication cycle can be expanded or modified, improving the scalability of the formation robot system. For example, if a single robot node needs to be added, FPeriod can be increased by the length of FRobotTS and the variables on the remaining robot nodes can be simply modified.

[0050] Since the formation robot is a distributed system, in order to realize the real-time control of the formation robot, it is necessary to calculate the starting time of the communication cycle on the non-command sending node. Figure 3As shown in the figure, the transmission delay from the start of the communication cycle, T0, to the time the base station sends the command, T1, is called the command transmission delay. This transmission delay can be calculated by the base station and sent along with the command to the formation robot node. The propagation delay from the time the base station sends the command, T1, to the time the robot node receives the command, T2, is called the propagation delay. This propagation delay can be ignored in indoor environments or roughly calculated by dividing the distance by the propagation speed. Therefore, after the robot node receives the base station command at T2, the propagation delay and the command transmission delay are subtracted to calculate the start of the communication cycle, T0. After calculating T0, the node determines the start of the time slice, T3, based on the sequence, calculates the timer delay, and starts the timer. After the timer expires, the data transmission function FSendData() is called to send the protocol frame encapsulated in the data exchange layer to the other robot nodes.

[0051] The hardware communication management module uses polling to manage the robot's own sub-nodes. Figure 4 As shown, a hardware communication management module is established. The robot cyclically transmits hardware command data. The hardware address and command frame are provided by the corresponding hardware object module in the data exchange layer. The hardware communication management module is only responsible for sending the corresponding protocol frame. After the command is sent, the data is received. After completion, the protocol frame is obtained and handed over to the corresponding hardware object in the data layer. The corresponding timestamp is recorded for each received protocol frame for subsequent calculations.

[0052] Step S1-3: The data exchange layer includes a network layer protocol encapsulation module, a hardware data module, and a hardware protocol encapsulation and parsing module. It is responsible for data encapsulation and parsing, and completes data exchange with the algorithm task layer.

[0053] The network layer protocol encapsulation module is responsible for encapsulating shared data between different robot nodes. The network layer protocol encapsulation module has unified interface functions, including: task data packet write function FWriteData(), task data packet read function FReadData(), task data packet clear function Fclear(), etc.

[0054] The network layer protocol encapsulation module encapsulates data using a variable length protocol frame, such as Figure 5As shown in the figure, the format is: frame header + robot information + task data packet 1 + task data packet 2 + ... + checksum + frame trailer. Robot information includes the robot number and frame data length. To easily distinguish which robot in the formation is sending data, each robot has a unique number. Task data packets are generated by the task calling the data packet write function FWriteData(). The network protocol encapsulation module converts data of different formats into character data. They contain three parts: task number, task packet data length, and data. The task number is used to identify the task generating the data packet. A single task number can only have one task data packet at a time; subsequent data packets with the same task number will overwrite the previous one. A single variable-length protocol frame can contain multiple task data packets with different task numbers, provided that the frame length is less than the maximum frame length FMaxLength. Task data packets can also vary in length, thus flexibly adapting to the data transmission requirements of different task algorithms and enabling transparent communication between different robot nodes. The maximum frame length can be calculated based on the robot's transmission capacity and is generally set to 60% of the robot's maximum data transmission capacity in the time slice FRobotTS. After the network layer protocol encapsulation module receives the protocol frames from the remaining robot nodes, it segments the protocol frames into task data packets, categorizes them by robot number and task packet number, and temporarily stores them in the network layer protocol encapsulation module. Tasks can use the task data packet read function FReadData() to read task data packets shared by different robots, enabling data sharing between different robot nodes.

[0055] The hardware data module is responsible for completing the data exchange between the hardware and the task, which is divided into command data and measurement data. The hardware data module has a unified interface function, including: command data writing function HWriteOrder(), measurement data reading function HReadData(), etc.

[0056] Instruction data refers to the relevant data that the algorithm task layer needs to write to control the hardware. The task writes the control instructions of the hardware through the instruction data writing function HWriteOrder(). The control instructions of the hardware are written in a multi-level instruction manner, such as Figure 6As shown in the figure, devices directly connected to the robot are called first-level devices. First-level devices are controlled using first-level instructions, which consist of a first-level device number, an instruction code, and a control variable. Each first-level device has a unique first-level device number. The instruction code determines the device's operating mode. The instruction code and control variable are determined based on the device's functionality. The control variable is written or set to zero based on the device's actual needs. If the first-level device is a programmable device, such as an embedded system, and hardware is still connected to the first-level device, the hardware is called a second-level device. Second-level devices are controlled using second-level instructions, which consist of a first-level device number, a first-level instruction code, a second-level device number, a second-level instruction code, and a control variable. The first-level instruction code's functionality is limited to enable, select, and disable, while the second-level instruction code is set based on the specific device's specific needs. Multi-level instructions not only unify the data exchange layer interface, improving code maintainability and scalability, but also enable the algorithm task layer to precisely control the underlying hardware. In the instruction data, the hardware's communication mode can be modified by modifying the link path variable. The hardware address is provided in the instruction data. Measurement data refers to the sensor measurement data returned by the hardware. The algorithm task layer can use the function HReadData() to read the hardware measurement data. The reading also adopts the multi-level instruction method, but each data reading only requires sending the device number. For example, if you need to obtain the data of the first-level device, you only need to send the first-level device number; and to obtain the data of the second-level device, you need to send the first-level device number + the second-level device number.

[0057] The hardware protocol encapsulation module is responsible for encapsulating and parsing the hardware object's protocol frames. It matches the instruction data in the hardware data module with the device object's communication protocol, encapsulating the instruction data into instruction frames and sending them to the hardware communication management module to control the hardware. After receiving the data frames from the hardware communication management module, the hardware protocol encapsulation module parses the measurement data and uploads it to the hardware data module for use by the algorithm task layer.

[0058] Step S1-4: The algorithm task layer includes two modules: task pool and task manager, which are used to develop formation control algorithms and realize task operation and switching.

[0059] The task pool stores the runnable formation tasks, each of which has an independent task number and a task running function TaskRun(). The task manager is responsible for sending and receiving instructions for the formation robot, and controls the operation of the formation according to the instructions. By setting the variable MMode, the task manager can be switched to an instruction sending node or a non-instruction sending node. The instruction sending node is used to issue formation instructions, and the remaining nodes receive instructions to complete the formation's task operation. The task manager can be regarded as a special formation task. This task runs when the formation robot program starts. Its fixed number is 0xff, and communication between each other is achieved by calling the network layer protocol encapsulation module interface. Among them, the communication between task managers can be divided into instruction packets and data packets. Instruction packets are used to exchange instructions, and a three-patrol verification mechanism is adopted, such as Figure 7 As shown, the instruction sending node sends the corresponding instruction frame; after receiving the instruction, the other robot nodes return the received instruction code to the instruction sending node; after the instruction sending node receives the instruction code of all robot nodes in the formation and confirms that it is correct, it will issue an instruction confirmation. Only then is the single instruction transmission completed and the formation can proceed to the next step. The three-round verification mechanism can ensure the accuracy of the formation instructions. The data frame is used to upload data to the instruction sending node for analysis. The content of the uploaded data can be determined according to different tasks. For the real-time nature of the data, the data packet will not be transmitted using the three-round verification mechanism. Figure 8 As shown in the figure, each task can switch between four states according to instructions, including task preparation, task running, task pause, and task end. During the task preparation phase, the robot node selects the task to be run according to the instructions; during the task running phase, the selected task run function TaskRun() is executed; during the task pause phase, the formation robot will stop the movement of the robot drive wheel. The task manager will directly set the drive wheel instruction to be stationary and disable the writing of the drive wheel in the hardware data module, but will not suspend the calculation of the remaining algorithms in the task so that the formation can run again; during the task end phase, the state of the entire formation is initialized, including hardware instructions and algorithm task layer data.

[0060] In summary, compared with the prior art, this embodiment has at least the following advantages and beneficial effects:

[0061] (1) An expandable and easy-to-develop formation robot platform. The formation communication management module can increase or decrease the number of robots within a certain range by modifying the communication cycle of the formation robot, thereby reducing the difficulty of expanding the formation robot. In addition, the variable-length communication protocol, as a communication protocol between formation robots, can flexibly adapt to the needs of data sharing between different tasks and realize the transparent transmission of shared data between formation robots. In addition, by using the instruction data of the data exchange layer, the hardware operation is simplified to the modification of the instruction data, and it is written through the unified interface of the data exchange layer, which effectively isolates the differences in communication methods and hardware platforms between different underlying hardware.

[0062] (2) Real-time switching of formation tasks. Based on the needs of the actual scenario, the task manager provides the function of switching task status in real time, which can switch task status online. After the task is paused or ended, the task manager can also switch any task in the task pool in real time, realizing flexible operation of the formation.

[0063] In the above description of this specification, reference to the terms "one embodiment / example," "another embodiment / example," or "certain embodiments / examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0064] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to the embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the claims and their equivalents.

[0065] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.

Claims

1. A general software layered architecture for distributed formation robots, characterized by: include: The physical link layer is responsible for providing different communication methods to the upper layer and completing the communication driver configuration; The communication management layer, including the formation communication management module and the hardware communication management module, is used to manage the communication between the robot and different nodes, and implement node management, clock synchronization, and data verification functions. Among them, the formation communication management module modifies the communication cycle of the formation robot and increases or decreases the number of robots to reduce the difficulty of expanding the formation robot. The data exchange layer includes a network protocol encapsulation module, a hardware data module, and a hardware protocol encapsulation and parsing module. It is responsible for data encapsulation and parsing, and completes data exchange with the algorithm task layer. The task layer, including the task manager and task pool, is used to develop the formation control algorithm and realize the operation and switching of formation tasks; The hardware data module stores measurement data and instruction data of different robot hardware; the instruction data includes the control mode, communication link selection, control parameters, and control instructions of the hardware node; the measurement data includes data and timestamp; The algorithm task layer modifies instruction data through the inter-layer interface to control the corresponding hardware functions and obtain measurement data. The instruction writing method adopts multi-level instructions, that is, the hardware controlled by the robot is divided into primary equipment and secondary equipment. The primary equipment is directly connected to the robot and is controlled by primary instructions; the secondary equipment is connected to the primary equipment and is controlled by secondary instructions. Multi-level instructions consist of device number, instruction code, and data. Each hardware has a separate device number, and the instruction code and data are determined according to the functions of different devices.

2. A distributed formation robot general software layered architecture according to claim 1, characterized in that: The physical link layer is specifically used to provide different data transmission paths, provide a data transmission interface in bytes to the upper layer, and freely switch the transmission path according to the upper layer's selection to achieve transparent transmission.

3. A distributed formation robot general software layered architecture according to claim 1, characterized in that: The formation communication management module manages the communication between the formation robot nodes in a time-division multiplexing manner, dividing a single formation communication cycle into multiple time slices. Each communication cycle is initiated by the instruction sending node and occupies the first time slice in the cycle. The remaining formation robot nodes use subsequent time slices to send data in turn. Among them, the instruction sending node is used to send formation instructions to control the task execution of the formation; the instruction sending node is a robot node in the formation, or an industrial computer node outside the formation.

4. A distributed formation robot general software layered architecture according to claim 1, characterized in that: The hardware communication management module manages the communication between the robot and the hardware nodes in a polling manner, that is, the robot node sends control instructions to the hardware nodes in turn, and receives data returned by the hardware nodes in turn.

5. A distributed formation robot general software layered architecture according to claim 1, characterized in that: The network protocol encapsulation module is responsible for completing the encapsulation of shared data, which refers to the data that the formation robots need to obtain to complete the current task; The shared data includes: robot information, task data packet, verification information robot information, and the verification information robot information is used to confirm which robot in the formation the data comes from; The task data packet includes task information and task data, and the task information is used to determine which task pool the task data comes from.

6. A distributed formation robot general software layered architecture according to claim 5, characterized in that: The encapsulation and parsing of the shared data are implemented using a variable-length communication protocol; The task data packet is generated when the task layer calls the data exchange layer interface; the size and quantity of the task data packet are modified according to the data sharing requirements of different tasks.

7. A distributed formation robot general software layered architecture according to claim 1, characterized in that: The hardware protocol encapsulation and parsing module is used to complete the protocol encapsulation according to different hardware communication protocols and instruction data, and to parse the data frame returned from the hardware and upload the data to the measurement data.

8. A distributed formation robot general software layered architecture according to claim 1, characterized in that: The task manager is responsible for sending or receiving formation instructions. Formation instructions are issued by the instruction sending node, and the other robot nodes receive the formation instructions. The instructions are used to control the running status of the task and realize the free switching of different tasks. The task manager adopts a three-patrol verification mechanism when receiving instructions to ensure the correctness of the instructions received by the robot node; the task manager controls the task to switch between four states: task preparation, task running, task pause, and task end according to the instructions.

9. A distributed formation robot general software layered architecture according to claim 1, characterized in that: The task pool stores the tasks that can be run by the formation, and the task manager selects tasks from the task pool to run according to the instructions; The fleet's executable tasks include task codes, and each task is provided with an independent number for the task manager to select and distinguish sources of shared data.

Images