Multi-apparatus cooperative control method and apparatus, autonomous mobile apparatus, and storage medium

Abstract

The embodiments of the present application relate to autonomous mobile apparatuses. Provided are a multi-apparatus cooperative control method, apparatus and system, and a storage medium. The method comprises: in response to being determined as a lead vehicle of a platoon and receiving a cooperative task, planning a task trajectory on the basis of the cooperative task, wherein the platoon comprises one lead vehicle and at least one following vehicle; publishing the task trajectory and an execution starting time of the cooperative task to the at least one following vehicle, such that the at least one following vehicle plans their respective following trajectories on the basis of the task trajectory, and executes the respective following trajectories upon reaching the execution starting time of the task trajectory; and executing the task trajectory upon reaching the execution starting time of the task trajectory, such that the lead vehicle and the at least one following vehicle maintain platoon synchronization for task execution. Therefore, a cooperative operation with a plurality of apparatuses integrated into a whole is realized, thereby expanding the application scenarios of cooperative collaboration of the plurality of apparatuses.

Description

Multi-device collaborative control method, device, autonomous mobile device and storage medium

[0001] Cross-references

[0002] This application claims priority to the Chinese patent application filed with the Patent Office of China on February 4, 2024, with application number 202410159008.6, entitled “Multi-device collaborative control method, device, autonomous mobile device and storage medium”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present application relates to the technical field of autonomous mobile devices, and more specifically, to a multi-device collaborative control method, device, system and storage medium. Background Art

[0004] Autonomous mobile devices such as mobile robots are widely used in many fields. When a single robot cannot carry large cargo, multiple robots are needed to work together to carry the large cargo.

[0005] Regarding the collaborative cooperation involving multiple mobile robots, the relevant technology adopts the segmented forward and lateral movement of multiple mobile robots. In this way, the overall movement mode and movement scene of multiple mobile robots are relatively limited, and the collaborative operation of multiple mobile robots as one is not truly achieved. Summary of the Invention

[0006] The embodiments of the present application provide a multi-device collaborative control method, device, system and storage medium, so that a master vehicle and at least one slave vehicle can maintain a queue to synchronously execute tasks, and can achieve collaborative operation of multiple devices as one, thereby expanding the application scenarios of collaborative cooperation of multiple devices.

[0007] In a first aspect, an embodiment of the present application provides a multi-device collaborative control method, the method comprising: in response to being determined as a master vehicle of a queue and receiving a collaborative task, planning a task trajectory according to the collaborative task, wherein the queue includes one master vehicle and at least one slave vehicle; publishing the task trajectory and the start execution time of the collaborative task to the at least one slave vehicle, so that the at least one slave vehicle plans its respective follow-up trajectory according to the task trajectory, and executes its respective follow-up trajectory when the start execution time of the task trajectory is reached; and executing the task trajectory when the start execution time of the task trajectory is reached.

[0008] In a second aspect, an embodiment of the present application provides a multi-device collaborative control method, which includes: after being determined to be a slave vehicle in a queue, receiving a task trajectory and a start execution time of the task trajectory issued by a master vehicle of the queue, wherein the queue includes one master vehicle and at least one slave vehicle; performing trajectory planning according to the task trajectory to obtain a follow-up trajectory; and executing the follow-up trajectory when the start execution time of the task trajectory is reached.

[0009] In a third aspect, an embodiment of the present application provides a multi-device collaborative control method, which is applied to a multi-device collaborative control system, wherein the multi-device collaborative control system includes a master vehicle and at least one slave vehicle, wherein the master vehicle and the at least one slave vehicle form a queue. The method includes: in response to being determined as the master vehicle of the queue and receiving a collaborative task, the master vehicle plans a task trajectory according to the starting point and end point of the collaborative task, and publishes the task trajectory and the start execution time of the collaborative task to the at least one slave vehicle; the at least one slave vehicle performs trajectory planning according to the task trajectory to obtain the respective follow-up trajectories of the at least one slave vehicle; when the start execution time of the task trajectory is reached, the master vehicle executes the task trajectory, and the at least one slave vehicle respectively executes its respective follow-up trajectory.

[0010] In a fourth aspect, an embodiment of the present application provides a multi-device collaborative control device, which includes: a response module for planning a task trajectory according to the collaborative task in response to being determined as a master vehicle of a queue and receiving a collaborative task, wherein the queue includes one master vehicle and at least one slave vehicle; a publishing module for publishing the task trajectory and the start execution time of the collaborative task to the at least one slave vehicle, so that the at least one slave vehicle plans its respective follow-up trajectory according to the task trajectory and executes its respective follow-up trajectory when the start execution time of the task trajectory is reached; an execution module for executing the task trajectory when the start execution time of the task trajectory is reached.

[0011] In a fifth aspect, an embodiment of the present application provides a multi-device collaborative control device, which includes: a receiving module for receiving a task trajectory and a start execution time of the task trajectory issued by a master vehicle of the queue after being determined to be a slave vehicle in the queue, wherein the queue includes one master vehicle and at least one slave vehicle; a planning module for performing trajectory planning according to the task trajectory to obtain a follow-up trajectory; and a following module for executing the follow-up trajectory when the start execution time of the task trajectory is reached.

[0012] In a sixth aspect, an embodiment of the present application provides an autonomous mobile device, which includes: a memory and a processor, wherein the memory stores an application program, which is used to execute the method provided in the first aspect or the second aspect of the embodiment of the present application when called by the processor.

[0013] In the seventh aspect, an embodiment of the present application provides a computer-readable storage medium, on which program code is stored, and the program code is used to enable the processor to execute the method provided in the first aspect or the second aspect of the embodiment of the present application when called by the processor.

[0014] In the multi-device collaborative control method, device, system and storage medium provided in the embodiments of the present application, the master vehicle will publish the task trajectory and the start execution time of the task trajectory to at least one slave vehicle. The at least one slave vehicle can plan its own following trajectory according to the task trajectory. When the start execution time of the task trajectory is reached, the master vehicle executes the task trajectory, and at least one slave vehicle executes its own following trajectory at the same time. In this way, the master vehicle and at least one slave vehicle can maintain queue synchronization to execute tasks, and can achieve collaborative operation of multiple devices as one, thereby improving the autonomy and intelligence of the collaborative operation of multiple devices, thereby expanding the application scenarios of collaborative cooperation of multiple devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of this application, not all embodiments. All other embodiments and drawings obtained by ordinary technicians in this field based on the embodiments of this application without creative work are within the scope of protection of this application.

[0016] FIG1 is a block diagram of a multi-device collaborative control system according to an embodiment of the present application;

[0017] FIG2 is a flow chart of a multi-device collaborative control method provided by an embodiment of the present application;

[0018] FIG3 is a flowchart of a multi-device collaborative control method for a platoon master vehicle according to an embodiment of the present application;

[0019] FIG4 is a schematic diagram of a queue provided by an exemplary embodiment of the present application;

[0020] FIG5 is a schematic diagram of a queue provided by another exemplary embodiment of the present application;

[0021] FIG6 is a schematic diagram of a queue provided by another exemplary embodiment of the present application;

[0022] FIG7 is a flowchart of obstacle avoidance control in a multi-device collaborative control method according to an embodiment of the present application;

[0023] FIG8 is a schematic diagram of a rotation control process in a multi-device cooperative control method provided by an exemplary embodiment of the present application;

[0024] FIG9 is a schematic diagram of a rotation control process in a multi-device cooperative control method provided by another exemplary embodiment of the present application;

[0025] FIG10 is a flowchart of chassis control on the main vehicle side in the multi-device coordinated control method provided in one embodiment of the present application;

[0026] FIG11 is a flowchart of the jacking control of the main vehicle side in the multi-device coordinated control method provided in one embodiment of the present application;

[0027] FIG12 is a flowchart of a multi-device collaborative control method for a platoon slave vehicle side according to an embodiment of the present application;

[0028] FIG13 is a schematic diagram of a process of a queue performing curved motion according to an embodiment of the present application;

[0029] FIG14 is a flowchart of chassis control from the vehicle side in a multi-device coordinated control method provided by an embodiment of the present application;

[0030] FIG15 is a flowchart of jacking control from the vehicle side in the multi-device coordinated control method provided in one embodiment of the present application;

[0031] FIG16 is a flowchart of a multi-device collaborative control method provided by an embodiment of the present application;

[0032] FIG17 is a structural block diagram of a multi-device cooperative control device on the main vehicle side of a platoon provided by an embodiment of the present application;

[0033] FIG18 is a structural block diagram of a multi-device cooperative control device on a platoon slave vehicle side provided by an embodiment of the present application;

[0034] FIG19 is a structural block diagram of an autonomous mobile device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0035] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0036] See Figure 1, which is a block diagram of a multi-device collaborative control system according to one embodiment of the present application. The multi-device collaborative control system may include a dispatching system, a master vehicle, and at least one slave vehicle. The master vehicle and at least one slave vehicle form a fleet. The dispatching system coordinates and manages the dispatch of the master vehicle and slave vehicles, which execute tasks according to the dispatching system's schedule.

[0037] The scheduling system can be used to schedule and manage the coordinated operation of multiple autonomous mobile devices, enabling them to efficiently execute user-issued tasks within the same area without interfering with each other. The scheduling system includes a user interface (UI), which allows for task management and control, such as issuing, canceling, pausing, and stopping tasks.

[0038] The master vehicle and at least one slave vehicle can both be autonomous mobile devices, and the autonomous mobile devices can include but are not limited to automated guided vehicles (AGVs) and autonomous mobile robots (AMRs). Autonomous mobile devices can adapt to various models such as differentials, steering wheels, and Mecanum wheels, and support multiple devices to collaboratively execute functions such as straight trajectories, curved trajectories, spinning in place, stopping obstacles, bypassing obstacles, state synchronization, and exception handling. It should be noted that the same autonomous mobile device can support both the master vehicle role and the slave vehicle role, and an autonomous mobile device can also only support the master vehicle role or the slave vehicle role, and no specific restrictions are made here.

[0039] The multi-device coordinated control system operates as follows: The dispatching system issues tasks to the master vehicle. The master vehicle leads all the slave vehicles in executing the tasks issued by the dispatching system. Specifically, upon receiving a task from the dispatching system, the master vehicle issues the task and its start time to all the slave vehicles. When the start time arrives, the master vehicle and all the slave vehicles maintain a queue formation and execute the task synchronously.

[0040] For example, see Figure 2. The scheduling system issues a formation task to the master vehicle. The master vehicle plans its task trajectory (i.e., master vehicle trajectory) based on data such as kinematic constraints, obstacle information, formation profile, and path information. Slave vehicles 1 and 2 receive the master vehicle's task trajectory and the start execution time of the task trajectory (i.e., the start execution time of the task), and respectively calculate their own following trajectories (slave vehicle trajectories) based on the formation model. When the start execution time of the task trajectory is reached, the master vehicle executes the task trajectory, slave vehicle 1 executes following trajectory 1, and slave vehicle 2 executes following trajectory 2. After completing the following trajectory, slave vehicles 1 and 2 report instructions to the master vehicle to indicate that the task is complete. When the master vehicle determines that it has completed the task trajectory and slave vehicles 1 and 2 have completed the following trajectory, it determines that the formation task is complete.

[0041] The multi-device collaborative control method in the embodiment of the present application is applied to a multi-device collaborative control system. Specifically, the multi-device collaborative control method on the master vehicle side is applied to an autonomous mobile device serving as a master vehicle, or a multi-device collaborative control device on the master vehicle side. The multi-device collaborative control method on the slave vehicle side is applied to an autonomous mobile device serving as a slave vehicle, or a multi-device collaborative control device on the slave vehicle side. In the embodiment of the present application, the master vehicle may publish trajectories, tasks, instructions, and other publishing operations to the slave vehicle in a broadcast or point-to-point manner, and the embodiment of the present application does not limit the communication method between the master vehicle and the slave vehicle.

[0042] 3 , which is a flow chart of a multi-device coordinated control method on a host vehicle side provided in one embodiment of the present application. The method may include steps S110 to S130 .

[0043] Step S110: In response to being determined as a master vehicle of a queue and receiving a collaborative task, planning a task trajectory according to the collaborative task, wherein the queue includes one master vehicle and at least one slave vehicle.

[0044] Before a transport task is initiated, users can use the dispatch system to determine the number of coordinated vehicles and the queue configuration based on the size and shape of the cargo being transported. The dispatch system considers factors such as the availability of each autonomous mobile unit, distance, and model, and notifies multiple autonomous mobile units to form a queue to carry out the task. When issuing this notification, it also specifies the queue's lead vehicle and the position of each autonomous mobile unit within the queue.

[0045] In the embodiment of the present application, the formation of the queue may include but is not limited to a horizontal straight line (horizontal queue), a vertical straight line (vertical queue) and a T-shaped (T-shaped queue), etc. For example, assuming that this transportation task requires three autonomous mobile devices, the formation of the queue can be seen in Figures 4 to 6. Figure 4 shows a horizontal straight queue, in which the autonomous mobile device in the middle is designated as the main vehicle, and the autonomous mobile devices on both sides are slave vehicles. Figure 5 shows a vertical straight queue, in which the autonomous mobile device in the middle is designated as the main vehicle, and the autonomous mobile devices in the front and back are slave vehicles. Figure 6 shows a T-shaped queue, in which the autonomous mobile device in the front is designated as the main vehicle, and the autonomous mobile devices in the back are slave vehicles.

[0046] In some embodiments, after each autonomous mobile device is in place, it reports its arrival to the dispatch system, which then issues the current collaborative task to the master vehicle. In other embodiments, when the dispatch system notifies each device of its arrival to form a queue, it can also issue the collaborative task to the master vehicle.

[0047] In the embodiments of the present application, a collaborative task refers to a task that requires a queue to execute, that is, a task that requires the collaborative execution of multiple autonomous mobile devices. The collaborative task can be issued by the user through the user interface of the scheduling system. One collaborative task or multiple collaborative tasks can be issued at a time. For example, the collaborative task can be a transport task.

[0048] In some embodiments, the collaborative task includes a task endpoint, that is, the endpoint to be reached by this handling task, for example, a cargo unloading point. When the autonomous mobile device serving as the main vehicle receives a collaborative task, it can plan the task trajectory based on the endpoint of the collaborative task, the current position of the main vehicle, obstacles in the global map, kinematic constraints and other information. The task trajectory is the trajectory from the current position of the main vehicle to the endpoint of the collaborative task. For example, multiple discrete points can be obtained from the current position of the main vehicle to bypass obstacles in the global map to reach the task endpoint, and the distance between each discrete point and the obstacle is greater than the distance between the geometric center of the queue contour and the obstacle. A fifth-order Bezier curve is used to fit multiple discrete points, and the curve is smoothed after fitting to obtain the task path. According to the maximum speed limit of each point on the task path and the kinematic constraints, the speed and posture of each point on the task path are planned to obtain the task trajectory.

[0049] In some embodiments, if multiple collaborative tasks are received and each has its own priority, the multiple collaborative tasks can be executed sequentially based on the priority. In other embodiments, if multiple collaborative tasks are received, the multiple collaborative tasks can be executed sequentially based on the time of receipt of the multiple collaborative tasks. For collaborative tasks received simultaneously, the execution order of the collaborative tasks can be randomly arranged, or the execution order of the collaborative tasks received simultaneously can be arranged sequentially based on the distance between the task endpoint and the current position of the host vehicle, from near to far.

[0050] Step S120: publishing the task trajectory and the start execution time of the collaborative task to at least one slave vehicle, so that the at least one slave vehicle plans its own following trajectory according to the task trajectory and executes its own following trajectory when the start execution time of the task trajectory is reached.

[0051] In some embodiments, in order to ensure that the master vehicle and the slave vehicle execute the collaborative task synchronously, the master vehicle and the slave vehicle may be time synchronized first, thereby ensuring that the timestamps of the master vehicle and the slave vehicle are consistent, thereby achieving synchronous execution of the collaborative task.

[0052] After the task trajectory planning (and time synchronization) is completed, the task trajectory and the start execution time of the collaborative task can be published to at least one slave vehicle. After receiving the task trajectory and the start execution time of the collaborative task, the slave vehicle can plan its own follow-up trajectory based on the task trajectory and execute the follow-up trajectory when the start execution time of the task trajectory is reached, thereby ensuring that the master vehicle and the slave vehicle maintain the formation of the queue and execute the collaborative task synchronously, achieving the integration of multiple devices. Among them, the detailed description of the slave vehicle planning the follow-up trajectory is shown in step S220 below.

[0053] In some embodiments, when the host vehicle completes the task trajectory planning, the collaborative task start time can be determined as the time obtained by adding N (N is a positive integer) seconds to the current time. That is, the collaborative task start time = the task trajectory planning completion time + N seconds. For example, assuming N is 1, the collaborative task start time = the task trajectory planning completion time + 1 second.

[0054] In other embodiments, the start execution time of the collaborative task can be issued by the user through the scheduling system, but it should be understood that when setting the start execution time of the collaborative task, a certain trajectory planning time needs to be reserved for the master vehicle and the slave vehicle.

[0055] Step S130: When the start execution time of the task trajectory is reached, execute the task trajectory.

[0056] During the execution of the mission trajectory, global path collision detection based on the global map and / or local collision detection based on the vehicle coordinate system can be performed to ensure the safety of the master and slave vehicles in the collaborative operation. The global map is a map of the entire collaborative operation scene, including static and dynamic obstacles. Static obstacles can include those added to the global map before the operation and those updated to the global map by autonomous mobile devices in the scene during the operation. Dynamic obstacles can be obstacles updated to the global map by autonomous mobile devices in the scene during the operation.

[0057] In some embodiments, collision detection of a global path based on a global map may include: the main vehicle may perform collision detection on the track points on the mission trajectory based on the outline of the queue and the (outline of) obstacles in the global map. Specifically, the track point on the mission trajectory may be used as the center and expanded outward to the outline of the queue to determine whether the outline of the queue intersects with the (outline of) obstacles in the global map. If the outline of the queue intersects with the (outline of) obstacles in the global map, the track point corresponding to the intersection of the outline of the queue and the (outline of) obstacles is determined as the collision point. As long as there is a collision at any point, it is considered that there is a collision on the path to be traveled by the multi-device collaborative queue.

[0058] In some embodiments, local collision detection based on the vehicle body coordinate system may include: the main vehicle may perform collision detection on the track points on the mission trajectory based on the expanded outline of the main vehicle. Specifically, the track point on the mission trajectory may be used as the center and expanded outward to the expanded outline of the main vehicle to determine whether the expanded outline of the main vehicle intersects with the obstacle (outline) in the global map. If the expanded outline of the main vehicle intersects with the obstacle (outline) in the global map, the track point corresponding to the intersection of the expanded outline of the main vehicle and the obstacle is determined as the collision point. As long as there is a collision at any point, it is considered that there is a collision on the path to be traveled by the multi-device collaborative queue. Among them, the expanded outline of the main vehicle = the outline of the main vehicle itself + the safety distance (around), and the safety distance is used to protect the autonomous mobile device from colliding with the obstacle. It should be understood that the safety distances around the main vehicle can be the same or different. The safety distances can be set according to the actual operation scenario and safety requirements. For example, the safety distances around the front, back, left and right can all be 0.5 meters. Since the longitudinal movement of the autonomous mobile device is more intense than the lateral movement, the front and back safety distances can also be set to 1 meter, and the left and right safety distances can be set to 0.5 meters.

[0059] In some embodiments, performing local collision detection based on the vehicle body coordinate system may further include: at least one slave vehicle may perform collision detection on a track point on the following track based on the expanded outline of the slave vehicle. Specifically, for each slave vehicle, the slave vehicle may use the track point on the following track as the center, expand outward to the expanded outline of the slave vehicle, and determine whether the expanded outline of the slave vehicle intersects with (the outline of) the obstacle in the global map. If the expanded outline of the slave vehicle intersects with (the outline of) the obstacle in the global map, the track point corresponding to the intersection of the expanded outline of the slave vehicle and the obstacle is determined as the collision point. As long as there is a collision at any point, it is considered that there is a collision on the path to be traveled by the multi-device coordinated queue. Wherein, the expanded outline of the slave vehicle = the outline of the slave vehicle itself + the above-mentioned safety distance. In this embodiment, after discovering the collision point, the slave vehicle will synchronously feedback the collision point to the master vehicle. In response to receiving the collision point sent by any of the at least one slave vehicle, the master vehicle determines that the collision point has been detected.

[0060] After detecting a collision point using any of the three collision detection methods described in the preceding embodiments, the host vehicle can determine that a collision has occurred in the multi-device collaborative queue. In this case, the host vehicle must synchronize the parking of the multiple devices in the queue to ensure that each device remains in its position within the queue after stopping, thus preserving the queue's formation. In other words, the host vehicle must plan a parking trajectory.

[0061] During the execution of the mission trajectory, the master vehicle can respond to detecting a collision point (or receiving a temporary parking instruction) by planning a parking trajectory. Upon completing parking trajectory planning, the master vehicle can determine the time obtained by adding N (N is a positive integer) seconds to the current time as the start execution time of the parking trajectory. That is, the start execution time of the parking trajectory = the time when the parking trajectory planning is completed + N seconds. For example, assuming N is 1, the start execution time of the parking trajectory = the time when the parking trajectory planning is completed + 1 second. After completing parking trajectory planning, the master vehicle can publish the parking trajectory and the start execution time of the parking trajectory to at least one slave vehicle, so that at least one slave vehicle plans its own parking follow-up trajectory based on the parking trajectory. When the start execution time of the parking trajectory is reached, the master vehicle executes the parking trajectory, and at least one slave vehicle executes its own parking follow-up trajectory. This ensures that the master vehicle and the slave vehicles maintain their queue formation and park synchronously, preventing a situation where an autonomous mobile device stops first or multiple autonomous mobile devices have inconsistent parking positions, causing confusion in the queue, and achieving the integration of multiple devices. For a detailed description of how the slave vehicle plans the parking follow-up trajectory, please refer to step S220 below.

[0062] The parking trajectory planning of the main vehicle is implemented as follows: the main vehicle can determine the parking point based on the collision point, and the distance between the parking point and the collision point in the direction of the task trajectory is a specified distance; the parking trajectory is planned based on the current trajectory point and the parking point on the task trajectory. The specified distance can be pre-set by relevant personnel according to actual needs. For example, the specified distance can be 1 meter. The main vehicle can plan a path from the current point to a point 1 meter before the collision point along the original straight or curved task path, and re-plan the speed of this path to obtain a parking trajectory that allows the main vehicle to stop accurately 1 meter in front of the obstacle.

[0063] After stopping when encountering an obstacle (or receiving a command to continue execution), the main vehicle can plan an obstacle avoidance trajectory. The main vehicle can obtain multiple discrete points based on the task trajectory and obstacles. These multiple discrete points bypass the obstacles from the current trajectory point of the task trajectory and return to the task trajectory; based on these multiple discrete points, the obstacle avoidance trajectory is planned. Specifically, obstacle avoidance trajectory planning can include three parts, namely path search, path optimization, and speed planning. That is, the A* (A Star) algorithm can be used to search for multiple discrete points (discrete point sets) that bypass the obstacles and return to the task trajectory from the current trajectory point of the task trajectory. The discrete points are sequentially connected using a fifth-order Bezier curve. By continuously adjusting the tangent direction of the two endpoints (starting point and target point) of each Bezier curve and the intermediate control point, the discrete path is optimized to obtain a smooth obstacle avoidance path. According to the kinematic and dynamic constraints of the queue, the speed of the points on the obstacle avoidance path is planned to obtain an obstacle avoidance trajectory.

[0064] After the obstacle avoidance trajectory is planned, to avoid affecting the operations of other autonomous mobile devices in the work scenario, the master vehicle needs to request permission from the dispatching system to pass through the area where the obstacle avoidance trajectory passes. The dispatching system then determines whether the queue is allowed to avoid the obstacle. Specifically, after the obstacle avoidance trajectory is planned, the master vehicle can report the area through which the obstacle avoidance trajectory passes to the dispatching system to request the obstacle avoidance. Based on the movement of all autonomous mobile devices in the work scenario, the dispatching system determines whether the queue's obstacle avoidance trajectory will affect other autonomous mobile devices in the area through which the obstacle avoidance trajectory passes. If the obstacle avoidance trajectory does affect other autonomous mobile devices, the master vehicle is notified to disallow the obstacle avoidance. If the obstacle avoidance trajectory does not affect other autonomous mobile devices, the master vehicle is notified to allow the obstacle avoidance.

[0065] Upon receiving the obstacle avoidance notification issued by the scheduling system, that is, when the obstacle avoidance trajectory is allowed to be executed, the master vehicle can determine the time obtained by adding N (N is a positive integer) seconds to the current time as the start execution time of the obstacle avoidance trajectory, that is, the start execution time of the obstacle avoidance trajectory = the time when the obstacle avoidance trajectory planning is completed + N seconds. For example, assuming that N is 1, the start execution time of the obstacle avoidance trajectory = the time when the obstacle avoidance trajectory planning is completed + 1 second. The master vehicle publishes the obstacle avoidance trajectory and the start execution time of the obstacle avoidance trajectory to at least one slave vehicle, so that at least one slave vehicle plans its own obstacle avoidance following trajectory according to the obstacle avoidance trajectory. When the start execution time of the obstacle avoidance trajectory is reached, the master vehicle executes the obstacle avoidance trajectory, and at the same time, at least one slave vehicle executes its own obstacle avoidance following trajectory, thereby ensuring that the master vehicle and the slave vehicle maintain the formation of the queue and execute the obstacle avoidance synchronously, achieving the integration of multiple devices. Among them, the detailed description of the obstacle avoidance following trajectory planned by the slave vehicle is shown in step S220 below.

[0066] For example, see the obstacle avoidance process shown in Figure 7: During the execution of the collaborative task, the master vehicle and the slave vehicle each perform collision detection. When a collision point is detected, the parking task is executed: the master vehicle plans a parking trajectory, publishes the parking trajectory and the start execution time of the parking trajectory to the slave vehicle, and the slave vehicle plans a parking trajectory based on the parking trajectory. When the parking trajectory start execution time is reached, the master vehicle and the slave vehicle simultaneously park, while continuing to perform collision detection during the parking process. After stopping due to an obstacle, the obstacle avoidance task is executed: the master vehicle plans an obstacle avoidance trajectory and requests a pass through the area through which the obstacle avoidance trajectory passes from the scheduling system. After the scheduling system notifies the master vehicle that the obstacle avoidance is allowed, the master vehicle publishes the obstacle avoidance trajectory and the start execution time of the obstacle avoidance trajectory to the slave vehicle, and the slave vehicle plans an obstacle avoidance trajectory based on the obstacle avoidance trajectory. When the obstacle avoidance trajectory start execution time is reached, the master vehicle and the slave vehicle simultaneously circumvent the obstacle, while continuing to perform collision detection during the obstacle avoidance process. After the obstacle avoidance is completed, the obstacle avoidance task is deleted and the collaborative task continues to be executed: the master vehicle and the slave vehicle delete the obstacle avoidance task, the master vehicle continues to execute the collaborative task along the task trajectory, and the slave vehicle continues to execute the collaborative task along the following trajectory.

[0067] During the execution of the mission trajectory, if the current trajectory point on the mission trajectory requires a spin in place, the master vehicle can obtain the type of spin in place and the target attitude corresponding to the current trajectory point; use the rotation method corresponding to the spin in place type to control the master vehicle and at least one slave vehicle to rotate according to the target attitude.

[0068] Among them, the types of in-place spins can include a first type and a second type. The first type of in-place spin task is to carry the rack (shelf) to rotate around the geometric center of the queue. The second type of in-place spin task is not to carry the rack together, that is, the rack does not move, and the autonomous mobile device rotates in place. It should be noted that the second type is for symmetrical queues, which can include but are not limited to horizontal queues, vertical queues, and square queues consisting of four autonomous mobile devices.

[0069] If a trajectory point has a requirement for spinning in place, the trajectory point stores a preset target posture, and the target posture is used to guide each device to spin in place.

[0070] The entire in-place spinning process is led by the master vehicle, which controls the synchronous rotation of the slave vehicles by issuing rotation control instructions and the start execution time of the rotation control instructions to the slave vehicles.

[0071] In some embodiments, if the in-place spin type is the first type, the master vehicle can control the master vehicle and at least one slave vehicle carrying the storage rack to rotate around the geometric center of the queue according to the target posture. For example, the first type of rotation includes the following three rotations:

[0072] First Rotation: The master vehicle controls the master vehicle and at least one slave vehicle to rotate around their respective Z-axes to their corresponding tangential directions, where the tangential directions of the master vehicle or slave vehicle are the tangent directions of a circle centered at the geometric center of the queue at the master vehicle or slave vehicle. Specifically, the master vehicle issues a first command and an execution time for the first command to the slave vehicle. When the execution time of the first command is reached, the master vehicle and slave vehicle synchronously perform the first rotation.

[0073] For example, see Figure 8. Assume a master vehicle and two slave vehicles form a "P" formation. The current formation is shown on the left side of Figure 8. The directions indicated by the solid black arrows in the formation on the left side of Figure 8 represent the orientations of the devices, and therefore the orientation of the formation. After the master vehicle and slave vehicles rotate around their respective Z axes to their corresponding tangent directions, the formation becomes as shown on the right side of Figure 8. The directions indicated by the solid black arrows in the formation on the right side of Figure 8 represent the orientations of the devices, and also the corresponding tangent directions of the devices.

[0074] Second rotation: The master vehicle controls the master vehicle and at least one slave vehicle, carrying the rack, to rotate around the geometric center of the formation to the target position. Specifically, the master vehicle issues a second command and an execution time for the second command to the slave vehicle. When the execution time of the second command is reached, the master vehicle and the slave vehicle synchronously perform the second rotation.

[0075] Third Rotation: The master vehicle controls the master vehicle and at least one slave vehicle, rotating them around their respective Z-axes to a formation posture, with the master vehicle and at least one slave vehicle facing the same direction. Specifically, the master vehicle issues a third instruction and a timer for executing the third instruction to the slave vehicle. When the timer arrives, the master and slave vehicles synchronously execute the third rotation. This third rotation aims to align the orientations of all devices and maintain the formation posture, allowing them to maintain formation and synchronized execution of the collaborative task.

[0076] In other embodiments, if the in-place spin type is the second type, the master vehicle can control the master vehicle and at least one slave vehicle to rotate around their respective Z-axes to a target attitude. Specifically, the master vehicle issues a single rotation command and an execution time for the single rotation command to the slave vehicle. When the execution time for the single rotation command is reached, the master vehicle and the slave vehicle synchronously perform the second type of in-place spin.

[0077] For example, see Figure 9. Assume that the master vehicle and two slave vehicles form a horizontal formation. The current formation is shown in the left-hand side of Figure 9. The directions indicated by the solid black arrows in the formation represent the orientations of the devices, which is also the orientation of the formation. After the master vehicle and the slave vehicles rotate around their respective Z axes to the target pose, the formation is shown in the right-hand side of Figure 9. The directions indicated by the solid black arrows in the formation represent the orientations of the devices, which is also the orientation of the formation. It should be noted that, referring to Figure 9, the position of slave vehicle 1 changes from the left side of the master vehicle to the right side of the master vehicle, and the position of slave vehicle 2 changes from the right side of the master vehicle to the left side of the master vehicle. Therefore, after the second type of in-place spin, the formation model needs to be updated. That is, the relative positions of the slave vehicles relative to the master vehicle after the in-place spin must be updated, and subsequent trajectories are calculated according to the new model. For this reason, the second type of in-place spin requires a symmetric formation model.

[0078] The above trajectory execution control all belongs to chassis control. The goal of chassis control for the master vehicle is to ensure that it accurately tracks the trajectory issued by the planning layer, allowing it to lead the entire convoy. Referring to Figure 10, the specific process of chassis control for the master vehicle is as follows: The chassis control input for the master vehicle comes from the external trajectory of the planning layer (including the mission trajectory, parking trajectory, and obstacle avoidance trajectory). The velocity of the trajectory point is directly fed into the master vehicle as a feedforward variable. The difference between the desired and actual position of the trajectory point serves as the input to the longitudinal proportional integral (PI) controller and the lateral PI controller, where the longitudinal and lateral terms are defined relative to the vehicle coordinate system. Therefore, the longitudinal PI controller corrects the deviation of the autonomous vehicle in the longitudinal direction, while the lateral PI controller eliminates deviation in the lateral direction and heading angle. The outputs of the two PI controllers and the feedforward velocity from the external trajectory are jointly input into the kinematic model of the autonomous vehicle, which is then solved to obtain the speed of each wheel of the autonomous vehicle and sent to the motor controller.

[0079] During the collaborative operation of multiple devices, the master vehicle will monitor the task status of each slave vehicle in real time, including task execution status, safety status, obstacle status, etc. The slave vehicle needs to report the above status to the master vehicle in real time. In addition to chassis control, the multi-device collaborative control method can also include the control of other designated tasks (such as jacking tasks). When the master vehicle receives a temporary designated task, the master vehicle needs to publish the designated task and the start execution time of the designated task to the slave vehicle in real time to ensure that multiple vehicles execute the designated task at the same time, where the designated task may include but is not limited to jacking, cancellation, abnormality, error clearing, emergency stop and other tasks.

[0080] In the process of executing the task trajectory, in response to receiving the designated task, the master vehicle can determine the moment obtained by adding N (N is a positive integer) seconds to the current moment as the start execution time of the designated task, that is, the start execution time of the designated task = the moment of receiving the designated task + N seconds. For example, assuming that N is 1, the start execution time of the designated task = the moment of receiving the designated task + 1 second. The designated task and the start execution time of the designated task are published to at least one slave vehicle. When the start execution time of the designated task is reached, at least one slave vehicle and the master vehicle execute the designated task synchronously, thereby ensuring that the master vehicle and the slave vehicle execute the designated task synchronously and achieving the integration of multiple devices.

[0081] In some embodiments, the designated task includes a lifting task, which includes a target lifting height, where the target lifting height is less than or equal to the maximum lifting height of the autonomous mobile device. The master vehicle can obtain the target lifting height in the lifting task and control the master vehicle to lift to the target lifting height based on the difference between the target lifting height and the master vehicle's current lifting height. During the lifting process, the master vehicle's current lifting height is communicated to the slave vehicle in real time. The slave vehicle adjusts its lifting speed based on the difference between its current lifting height and the master vehicle's current lifting height, thereby ensuring synchronization with the master vehicle's lifting.

[0082] For example, see Figure 11. The specific process of the main vehicle's jacking control is as follows: the main vehicle's motion controller starts timing after receiving the jacking task, and starts executing the jacking instruction after reaching the start execution time of the jacking task. The difference between the main vehicle's current jacking height and the target jacking height is used as the input of the jacking PI controller. The output of the PI controller and the preset speed are jointly input to the jacking model, and finally converted to the speed of the jacking motor and sent to the jacking motor driver. The entire control process ensures that the main vehicle starts jacking to the target height at the start execution time of the jacking task at the predetermined speed. Among them, the preset speed can be pre-set by relevant personnel. The preset speed should not be too large, which may easily cause the cargo to fall off.

[0083] It should be understood that the implementation of the descending task in the opposite direction to the jacking task is similar to the implementation of the jacking task, the only difference is that the operating directions of the autonomous mobile device in the two tasks are opposite, one is ascending and the other is descending.

[0084] After completing the following trajectory, the slave vehicle may send an instruction to the master vehicle indicating that the trajectory has been completed. In response to the master vehicle completing the task trajectory and at least one slave vehicle completing its respective following trajectory, the master vehicle sends an instruction to the scheduling system indicating that the collaborative task has been completed. In some embodiments, after sending the instruction indicating that the collaborative task has been completed, in response to receiving a disband instruction issued by the scheduling system, the master vehicle resumes its independent motion state and simultaneously issues a disband instruction to at least one slave vehicle to notify the at least one slave vehicle to resume its independent motion state. In other embodiments, after sending the instruction indicating that the collaborative task has been completed, in response to receiving a new collaborative task issued by the scheduling system, the master vehicle re-executes steps S110 to S130.

[0085] Based on steps S110 to S130, the master vehicle will publish the task trajectory and the start execution time of the task trajectory to at least one slave vehicle. The at least one slave vehicle can plan its own following trajectory according to the task trajectory. When the start execution time of the task trajectory is reached, the master vehicle executes the task trajectory, and at least one slave vehicle executes its own following trajectory at the same time. In this way, the master vehicle and at least one slave vehicle can maintain queue synchronization to execute tasks, and can achieve collaborative operation of multiple devices as one, thereby improving the autonomy and intelligence of the collaborative operation of multiple devices, thereby expanding the application scenarios of collaborative cooperation of multiple devices.

[0086] 12 is a flowchart of a multi-device collaborative control method for a platoon slave vehicle provided by an embodiment of the present application. The method includes steps S210 to S230.

[0087] Step S210: After being determined as a slave vehicle in a queue, receiving a task trajectory and a start execution time of the task trajectory issued by a master vehicle in the queue, wherein the queue includes a master vehicle and at least one slave vehicle.

[0088] Step S220: performing trajectory planning according to the task trajectory to obtain a following trajectory.

[0089] The follower vehicle can determine the relative position relationship between itself and the master vehicle in the queue; according to the position of the track point on the task track and the relative position relationship, it plans the position of the track point on the follower track. For example, through the queue model, the relative position relationship between the follower vehicle and the master vehicle in the queue can be calculated, and the rotation matrix can be constructed as follows: P follower =P leader *T

[0090] Among them, P leader represents the position of the main vehicle in the queue, P follower represents the position of the slave car in the queue, and T represents the rotation matrix.

[0091] The rotation matrix includes two processes: translation and rotation. The final result is the product of the rotation matrix and the translation matrix. Since autonomous mobile devices such as mobile robots only rotate along the Z axis and do not consider rotation along the X and Y axes, the rotation matrix is:

[0092] The translation matrix is:

[0093] Where α is the rotation angle, x e 、y e 、z eare the moving distances on the X, Y, and Z axes, respectively. Taking the T-shaped formation shown in Figure 6 as an example, the relative position relationship between slave car 1 and the master car is 1 meter backward translation along the X axis and 1 meter left translation along the Y axis, and the posture has not rotated relative to the master car. The relative position relationship between slave car 2 and the master car is 1 meter backward translation along the X axis and 1 meter right translation along the Y axis, and the posture has not rotated relative to the master car. Because there is no rotation relative to the master car, the rotation matrix does not need to be added, so it is only necessary to update the corresponding X-axis and Y-axis offsets to the translation matrix, and combine the posture of the autonomous mobile device to solve the respective posture information of slave car 1 and slave car 2 in the following trajectory.

[0094] The slave vehicle can determine the angular velocity, curvature, and attitude direction corresponding to the track point on the mission trajectory; determine the distance between itself and the master vehicle in a direction perpendicular to the attitude direction; and plan the speed of the track point on the follow-up trajectory based on the angular velocity, curvature, and the distance.

[0095] The basis for calculating the speed of the slave vehicle is that the rotational angular velocity of the multiple autonomous mobile devices in the queue is consistent while they are following the track, so the rotational speeds of the various autonomous mobile devices are different because their rotation radiuses are different while they are tracking the curve. From the speed calculation formula V=W*R, it can be seen that when the angular velocity of the master vehicle and the rotation radius of the slave vehicle are obtained, the speed of the slave vehicle can be obtained. Taking a horizontal queue as an example, the relationship between the rotation radius of the two slave vehicles 1 and 2 and the rotation radius of the master vehicle can be shown in Figure 13: When the queue tracks the curve, it moves from position 1 to position 2 around the rotation center of the curve. Referring to Figure 13, it can be obtained that: R1=R+L R2=RL

[0096] Where R1 is the rotation radius of slave vehicle 1 at position 2, R is the rotation radius of the master vehicle at position 2, R2 is the rotation radius of slave vehicle 2 at position 2, and L is the vertical distance between the slave vehicle and the master vehicle in the attitude direction of the trajectory point on the mission trajectory (the orientation of the master vehicle at the trajectory point, as indicated by the black solid arrow in Figure 13). The rotation radius R of the master vehicle is inversely proportional to the curvature K of the master vehicle, so: R = 1 / K

[0097] Therefore, the velocities of vehicles 1 and 2 at position 2 are: V1 = W*R1 V2 = W*R2

[0098] Wherein, is the speed of slave vehicle 1 at position 2, and is the angular velocity of master vehicle at position 2.

[0099] It should be understood that Figure 13 shows the trajectory of the queue rotating to the right, that is, the curvature of the (task and follower) trajectory is less than 0. When the curvature of the trajectory is greater than 0, that is, when the queue rotates to the left, then follower car 2 is located outside the rotating circle and follower car 1 is located inside the rotating circle. At this time, the rotation radius calculation formula of the two follower cars is as follows: R1 = RL R2 = R + L

[0100] Step S230: When the start execution time of the task trajectory is reached, the following trajectory is executed.

[0101] During the trajectory following process, the slave vehicle can obtain the master vehicle's real-time position, the slave vehicle's real-time speed, and the communication delay. The communication delay is the difference between the time the master vehicle publishes information (e.g., real-time position) and the time the slave vehicle receives it. Based on the master vehicle's real-time position, relative positional relationship, communication delay, and the slave vehicle's real-time speed, the slave vehicle's desired position is determined. The trajectory following is then executed based on the desired position. The slave vehicle's real-time speed includes both linear velocity and angular velocity.

[0102] Since the slave vehicles need to maintain the same formation as the master vehicle while tracking the trajectory, they need to track the master vehicle's position in real time. Therefore, three sets of data must be published to the control module in real time: the master vehicle's real-time position and speed, the master vehicle's real-time target position in the corresponding slave vehicle model (the slave vehicle's desired position), and the slave vehicle's real-time position and speed. At the same time, due to communication delays, a time compensation must be added when calculating the slave vehicle's desired position to ensure accurate tracking and maintain the formation of the fleet.

[0103] The real-time position and speed of the master vehicle and the real-time position and speed of the slave vehicle can be directly obtained through their respective positioning modules and published in real time.

[0104] The real-time target position of the master vehicle in the corresponding slave vehicle model is calculated according to the following expression: P = P follower +P0

[0105] Among them, P follower The above expression P can be used follower =P leader *T is calculated. P is the desired position of the slave vehicle, and P0 is the compensation amount caused by communication delay. Compensation amount P0 = V current *t,V current is the real-time speed of the slave vehicle, and t is the communication delay. The compensation amount needs to be compensated in the X-axis, Y-axis, and posture, so the X-axis position compensation is expanded to: P x =V x *t; Y-axis position compensation is: P y =V y *t; posture compensation is: T x =W*t. Where, V x is the speed on the X axis, V y is the velocity on the Y axis, and W is the angular velocity.

[0106] During the trajectory following process, the slave vehicle performs collision detection on track points along the following trajectory based on its inflated outline. The point corresponding to the intersection of the slave vehicle's inflated outline and the obstacle is identified as the collision point, and the collision point is sent to the master vehicle. The details of the slave vehicle's collision detection based on the vehicle's body coordinate system are described in the section above on collision detection and are omitted here.

[0107] During the following trajectory, if the following vehicle receives a parking trajectory and a start time for the parking trajectory issued by the master vehicle, it can plan a parking following trajectory based on the parking trajectory. When the start time for the parking trajectory is reached, the following trajectory is executed, thereby ensuring that the master vehicle and the following vehicle maintain their formation and park synchronously, avoiding situations where one autonomous mobile unit stops first or multiple autonomous mobile units park in inconsistent positions, causing confusion in the queue, and achieving the integration of multiple units. The planning of the parking following trajectory is similar to that of the following trajectory. For a detailed description of the parking following trajectory planning, please refer to the section on the planning method for the following trajectory, which will not be repeated here.

[0108] During the trajectory following process, if a slave vehicle receives an obstacle avoidance trajectory and its start time from the master vehicle, it can plan an obstacle avoidance trajectory based on the trajectory. When the start time arrives, the obstacle avoidance trajectory is executed. This ensures that the master and slave vehicles maintain formation and avoid obstacles synchronously, achieving multi-device integration. Obstacle avoidance trajectory planning is similar to that of the following trajectory. For a detailed description of obstacle avoidance trajectory planning, please refer to the section on following trajectory planning and will not be repeated here.

[0109] The above trajectory execution control all belongs to chassis control. The goal of the slave vehicle chassis control is to ensure that the slave vehicle accurately maintains its position in the queue, thereby maintaining the formation of the entire queue during movement. Referring to Figure 14, the specific process of the slave vehicle chassis control is as follows: The slave vehicle chassis control input is derived from the following trajectory in the planning layer and the desired position of the slave vehicle calculated to maintain the formation (the master vehicle's real-time position × rotation matrix + compensation for communication delay). The velocity of the trajectory point is directly fed into the master vehicle as a feedforward. The difference between the desired and actual position of the slave vehicle in the queue serves as the input to the longitudinal and lateral PI controllers, where longitudinal and lateral are defined relative to the vehicle's body coordinate system. Therefore, the longitudinal PI controller corrects the slave vehicle's deviation in the longitudinal direction, while the lateral PI controller eliminates deviation in the lateral direction and heading angle. The outputs of the two PI controllers and the feedforward velocity from the following trajectory are jointly input into the vehicle kinematic model, which is then solved to obtain the speed of each wheel and sent to the motor controller.

[0110] In addition to chassis control, the multi-device coordinated control method can also include control of other designated tasks (such as jacking tasks). During the trajectory following process, if a designated task and a start time are issued by the master vehicle, the slave vehicle can execute the designated task when the start time is reached.

[0111] For example, see Figure 15. The specific process of controlling the jacking of the slave vehicle is as follows: the slave vehicle's motion controller begins timing upon receiving the jacking task. The jacking task begins when the task's start time is reached. The difference between the slave vehicle's current jacking height and the master vehicle's current jacking height serves as the input to the jacking PI controller. The PI controller's output, along with the jacking speed, is then fed into the jacking model and converted into the jacking motor's rotational speed, which is then transmitted to the jacking motor driver. The entire control process ensures that the slave vehicle and the master vehicle begin jacking simultaneously and synchronously to the target jacking height in the jacking task. It should be noted that the master and slave vehicles have the same starting height for jacking. During the jacking process, errors may occur between the slave vehicle and the master vehicle, resulting in different current jacking heights. If there is a difference in the current jacking height between the slave vehicle and the master vehicle, the slave vehicle can adjust its own jacking speed based on this difference to synchronize the jacking heights of the slave vehicle and the master vehicle.

[0112] In some embodiments, the designated task includes a lifting task. The slave vehicle can obtain the current lifting height of the master vehicle and, based on the difference between its own current lifting height and the master vehicle's current lifting height, control its lifting speed to synchronize itself with the master vehicle to reach the target lifting height.

[0113] Upon completion of the following trajectory, the slave vehicle may send a command to the master vehicle indicating the completion of the collaborative task. In some embodiments, in response to a disband command issued by the master vehicle, the slave vehicle resumes its independent motion. In other embodiments, in response to a new task trajectory issued by the master vehicle, steps S210 through S230 are re-executed.

[0114] Based on steps S210 to S230, the slave vehicle can plan its own following trajectory according to the received task trajectory, and execute its own following trajectory when the start execution time of the task trajectory is reached, so that the slave vehicle can maintain a queue formation with the master vehicle and execute the task synchronously, and can achieve collaborative operation of multiple devices as one, thereby improving the autonomy and intelligence of the collaborative operation of multiple devices, thereby expanding the application scenarios of collaborative cooperation of multiple devices.

[0115] 16 is a flowchart of a multi-device collaborative control method provided by another embodiment of the present application. The method includes steps S310 to S330.

[0116] Step S310: In response to being determined as the master vehicle of the queue and receiving the collaborative task, the master vehicle plans a task trajectory according to the collaborative task, and publishes the task trajectory and the start execution time of the collaborative task to at least one slave vehicle.

[0117] Step S320: at least one slave vehicle performs trajectory planning according to the mission trajectory to obtain a respective following trajectory of at least one slave vehicle.

[0118] Step S330: When the start execution time of the task trajectory is reached, the master vehicle executes the task trajectory, and at least one slave vehicle executes its own following trajectory.

[0119] For the detailed description of steps S310 to S330 , please refer to steps S110 to S130 and steps S210 to S230 , which will not be repeated here.

[0120] Based on steps S310 to S330, the master vehicle will publish the task trajectory and the start execution time of the task trajectory to at least one slave vehicle. At least one slave vehicle can plan its own follow-up trajectory according to the task trajectory. When the start execution time of the task trajectory is reached, the master vehicle executes the task trajectory, and at least one slave vehicle executes its own follow-up trajectory. In this way, the master vehicle and at least one slave vehicle can maintain queue synchronization to execute tasks, and can achieve collaborative operation of multiple devices as one, thereby improving the autonomy and intelligence of the collaborative operation of multiple devices, thereby expanding the application scenarios of collaborative cooperation of multiple devices.

[0121] Referring to Figure 17 , which is a block diagram of a multi-device collaborative control apparatus for a platoon leader vehicle, according to one embodiment of the present application, the multi-device collaborative control apparatus 100 can be applied to autonomous mobile devices. The multi-device collaborative control apparatus 100 includes a response module 110 , a publishing module 120 , and an execution module 130 .

[0122] Response module 110 is configured to, in response to a vehicle being determined to be the leader of a platoon and receiving a collaborative task, plan a task trajectory based on the collaborative task, wherein the platoon includes one leader vehicle and at least one follower vehicle. The specific operation of response module 110 is described in step S110.

[0123] The publishing module 120 is configured to publish the task trajectory and the collaborative task start time to the at least one slave vehicle, so that the at least one slave vehicle plans its own tracking trajectory based on the task trajectory and executes its own tracking trajectory when the task trajectory start time is reached. The specific operation of the publishing module 120 is described in step S120.

[0124] The execution module 130 is configured to execute the task trajectory when the execution start time of the task trajectory is reached. The specific working process of the execution module 130 is shown in step S130.

[0125] Referring to Figure 18 , Figure 18 is a block diagram of a multi-device collaborative control apparatus for a platoon slave vehicle, according to one embodiment of the present application. Multi-device collaborative control apparatus 200 can be applied to autonomous mobile devices. Multi-device collaborative control apparatus 200 includes a receiving module 210 , a planning module 220 , and a following module 230 .

[0126] Receiving module 210 is configured to receive, after being identified as a slave vehicle in a queue, a task trajectory and a start time for the task trajectory published by the master vehicle in the queue, where the queue consists of one master vehicle and at least one slave vehicle. The specific operation of receiving module 210 is described in step S210.

[0127] The planning module 220 is used to plan a trajectory according to the task trajectory to obtain a follow-up trajectory. The specific working process of the planning module 220 is shown in step S220.

[0128] The following module 230 is used to execute the following trajectory when the start execution time of the task trajectory is reached. The specific working process of the following module 230 is shown in step S230.

[0129] Those skilled in the art can clearly understand that the above devices provided in the embodiments of the present application can implement the corresponding methods provided in the embodiments of the present application. The specific working processes of the above-described devices and modules can refer to the corresponding processes of the methods in the embodiments of the present application, which will not be repeated here.

[0130] In the embodiments provided in the present application, the coupling, direct coupling or communication connection between the modules shown or discussed may be an indirect coupling or communication coupling through some interfaces, devices or modules, and may be electrical, mechanical or other forms, and the embodiments of the present application do not impose specific limitations on this.

[0131] In addition, the functional modules in the embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0132] Referring to Figure 19, which is a block diagram of an autonomous mobile device according to an embodiment of the present application, the autonomous mobile device 300 may include a memory 310 and a processor 320. The memory 310 may store an application program configured to execute the method according to an embodiment of the present application when invoked by the processor 320.

[0133] The processor 320 may include one or more processing cores. The processor 320 connects various components within the autonomous mobile device 300 using various interfaces and lines. The processor 320 is used to run or execute instructions, programs, code sets, or instruction sets stored in the memory 310, and to call and execute data stored in the memory 310, thereby performing various functions of the autonomous mobile device 300 and processing data.

[0134] The processor 320 can be implemented in at least one hardware form of digital signal processing (DSP), field programmable gate array (FPGA), and programmable logic array (PLA). The processor 320 can integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem is used to handle wireless communications. It is understandable that the above-mentioned modem may not be integrated into the processor 320, but may be implemented separately through a communication chip.

[0135] The memory 310 may include random access memory (RAM) or read-only memory (ROM). The memory 310 may be used to store instructions, programs, codes, code sets, or instruction sets. The memory 310 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described above, and the like. The data storage area may store data created by the autonomous mobile device 300 during use.

[0136] The embodiment of the present application also provides a computer-readable storage medium having program code stored thereon. The program code is configured to execute the method provided by the embodiment of the present application when called by a processor.

[0137] The computer-readable storage medium may be an electronic memory such as a flash memory, an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a hard disk, or a ROM.

[0138] In some embodiments, the computer-readable storage medium includes a non-volatile computer-readable medium (Non-Transitory Computer-Readable Storage Medium, referred to as Non-TCRSM). The computer-readable storage medium has storage space for program codes that execute any method step in the above method. These program codes can be read from or written into one or more computer program products. The program code can be compressed in an appropriate form.

[0139] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A multi-device collaborative control method, characterized in that: include: In response to being determined as a master vehicle of a platoon and receiving a collaborative task, planning a task trajectory according to the collaborative task, wherein the platoon includes one master vehicle and at least one slave vehicle; Publishing the task trajectory and the start execution time of the collaborative task to the at least one slave vehicle, so that the at least one slave vehicle plans its own following trajectory according to the task trajectory and executes its own following trajectory when the start execution time of the task trajectory is reached; When the start execution time of the task trajectory is reached, the task trajectory is executed.

2. The method according to claim 1, characterized in that The method further comprises: During execution of the mission trajectory, in response to detecting a collision point, performing parking trajectory planning; publishing a parking trajectory and a start execution time of the parking trajectory to the at least one slave vehicle, so that the at least one slave vehicle plans a respective parking following trajectory according to the parking trajectory and executes the respective parking following trajectory when the start execution time of the parking trajectory is reached; When the start execution time of the parking trajectory is reached, the parking trajectory is executed.

3. The method according to claim 2, characterized in that The parking trajectory planning includes: determining a parking point according to the collision point, wherein the distance between the parking point and the collision point in the direction of the task trajectory is a specified distance; Parking trajectory planning is performed based on the current trajectory point on the task trajectory and the parking point.

4. The method according to claim 2, characterized in that After executing the parking trajectory, the method further includes: After stopping when encountering an obstacle, plan a trajectory around the obstacle; When the obstacle avoidance trajectory is allowed to be executed, publishing the obstacle avoidance trajectory and the start execution time of the obstacle avoidance trajectory to the at least one slave vehicle, so that the at least one slave vehicle plans its own obstacle avoidance following trajectory according to the obstacle avoidance trajectory and executes its own obstacle avoidance following trajectory when the start execution time of the obstacle avoidance trajectory is reached; When the start execution time of the obstacle avoidance trajectory is reached, the obstacle avoidance trajectory is executed.

5. The method according to claim 4, characterized in that The obstacle avoidance trajectory planning includes: Acquire a plurality of discrete points according to the task trajectory and the obstacle, wherein the plurality of discrete points go from a current trajectory point of the task trajectory around the obstacle and then return to the task trajectory; Obstacle avoidance trajectory planning is performed based on the multiple discrete points.

6. The method according to claim 4, characterized in that When the obstacle avoidance trajectory is allowed to be executed, publishing the obstacle avoidance trajectory and the start execution time of the obstacle avoidance trajectory to the at least one slave vehicle includes: Report the area passed by the obstacle avoidance trajectory to the dispatch system; In response to receiving the obstacle avoidance permission notification issued by the scheduling system, the obstacle avoidance trajectory and the start execution time of the obstacle avoidance trajectory are published to the at least one slave vehicle.

7. The method according to any one of claims 2 to 6, characterized in that: Before performing parking trajectory planning in response to detecting the collision point, the method further includes: performing collision detection on trajectory points on the task trajectory based on the outline of the queue and obstacles in the global map; The trajectory point corresponding to the intersection of the outline of the queue and the obstacle is determined as the collision point.

8. The method according to any one of claims 2 to 7, characterized in that: Before performing parking trajectory planning in response to detecting the collision point, the method further includes: performing collision detection on track points on the task track according to the expanded outline of the main vehicle; The trajectory point corresponding to the intersection of the expanded outline of the host vehicle and the obstacle is determined as the collision point.

9. The method according to any one of claims 2 to 7, characterized in that: Before performing parking trajectory planning in response to detecting the collision point, the method further includes: In response to receiving a collision point sent by any one of at least one slave vehicle, it is determined that a collision point is detected, and the at least one slave vehicle performs collision detection in the following manner: based on the expanded contour of the slave vehicle, collision detection is performed on the trajectory points on the follow-up trajectory; and the trajectory point corresponding to the intersection of the expanded contour of the slave vehicle and the obstacle is determined as the collision point.

10. The method according to any one of claims 1 to 9, characterized in that The method further comprises: During the execution of the task trajectory, if a current trajectory point on the task trajectory has a spin-in-place requirement, obtaining the type of the spin-in-place requirement and the target posture corresponding to the current trajectory point; The master vehicle and the at least one slave vehicle are controlled to rotate according to the target posture using a rotation method corresponding to the in-place spin type.

11. The method according to claim 10, characterized in that The method of adopting a rotation method corresponding to the in-place spin type and controlling the master vehicle and the at least one slave vehicle to rotate according to the target posture includes: If the in-place spin type is the first type, controlling the master vehicle and the at least one slave vehicle carrying the storage rack to rotate around the geometric center of the queue according to the target posture; If the in-place spin type is the second type, the master vehicle and the at least one slave vehicle are controlled to rotate around their respective Z axes to the target posture.

12. The method according to claim 11, characterized in that The controlling the master vehicle and the at least one slave vehicle carrying the storage rack to rotate around the geometric center of the queue according to the target posture includes: Controlling the master vehicle and the at least one slave vehicle to rotate about their respective Z axes to their respective corresponding tangential directions, wherein the tangential direction corresponding to the master vehicle or the slave vehicle is the tangential direction of a circle with the geometric center of the platoon as the center at the master vehicle or the slave vehicle; Controlling the master vehicle and the at least one slave vehicle to carry the storage rack together and rotate around the geometric center of the queue to a target posture; The master vehicle and the at least one slave vehicle are controlled to rotate around their respective Z axes to a queue posture, in which the master vehicle and the at least one slave vehicle have the same orientation.

13. The method according to any one of claims 1 to 12, characterized in that The method further comprises: During the execution of the task trajectory, in response to receiving a designated task, publishing the designated task and a start execution time of the designated task to the at least one slave vehicle, so that the at least one slave vehicle executes the designated task when the start execution time of the designated task is reached; When the start execution time of the designated task is reached, the designated task is executed.

14. The method according to claim 13, wherein: The designated task includes a jacking task, and controlling the main vehicle to perform the designated task includes: Obtaining a target lifting height in the lifting task; According to the difference between the target lifting height and the current lifting height of the main vehicle, the main vehicle is controlled to be lifted to the target lifting height.

15. The method according to any one of claims 1 to 14, characterized in that When the start execution time of the task trajectory is reached, after executing the task trajectory, the method further includes: In response to the master vehicle completing the task trajectory and the at least one slave vehicle completing its respective follow-up trajectory, sending an instruction indicating completion of the collaborative task to the scheduling system; In response to receiving the disbanding instruction issued by the dispatching system, the vehicle resumes its own independent movement state, and issues the disbanding instruction to the at least one slave vehicle to notify the at least one slave vehicle to resume its own independent movement state.

16. A multi-device collaborative control method, characterized in that: include: After being determined as a slave vehicle in a queue, receiving a task trajectory and a start execution time of the task trajectory issued by a master vehicle of the queue, wherein the queue includes one master vehicle and at least one slave vehicle; Perform trajectory planning according to the task trajectory to obtain a following trajectory; When the start execution time of the task trajectory is reached, the following trajectory is executed.

17. The method according to claim 16, characterized in that The performing trajectory planning according to the task trajectory to obtain a following trajectory includes: Determine the relative position relationship between the vehicle itself and the host vehicle in the queue; The positions of the track points on the following track are planned according to the positions of the track points on the task track and the relative position relationship.

18. The method according to claim 17, characterized in that The method further comprises: During the process of following the trajectory, the real-time speed of the vehicle, the real-time position of the host vehicle, and the communication delay are obtained, wherein the communication delay is the difference between the time when the host vehicle publishes the real-time position and the time when the vehicle receives the real-time position; determining a desired position of the slave vehicle according to the real-time position, the relative position relationship, the communication delay, and the real-time speed; According to the desired position, the following trajectory is performed.

19. The method according to any one of claims 16 to 18, characterized in that: The performing trajectory planning according to the task trajectory to obtain a following trajectory includes: Determining the angular velocity, curvature, and attitude direction corresponding to the trajectory points on the task trajectory; determining a distance between the vehicle and the host vehicle in a direction perpendicular to the attitude direction; The speed of the track point on the following track is planned according to the angular velocity, the curvature and the distance.

20. The method according to any one of claims 16 to 19, characterized in that: The method further comprises: During the execution of the following trajectory, if a parking trajectory and a start execution time of the parking trajectory issued by the host vehicle are received, a parking following trajectory is planned according to the parking trajectory; When the start execution time of the parking trajectory is reached, the parking following trajectory is executed.

21. The method according to any one of claims 16 to 20, characterized in that The method further comprises: During the execution of the following trajectory, collision detection is performed on the trajectory points on the following trajectory according to the expanded contour of the self; Determining the trajectory point corresponding to the intersection of the expanded outline of the slave vehicle and the obstacle as the collision point; The collision point is sent to the host vehicle.

22. The method according to any one of claims 16 to 21, characterized in that The method further comprises: During the execution of the following trajectory, if an obstacle avoidance trajectory and a start execution time of the obstacle avoidance trajectory issued by the host vehicle are received, an obstacle avoidance following trajectory is planned according to the obstacle avoidance trajectory; When the start execution time of the obstacle avoidance trajectory is reached, the obstacle avoidance following trajectory is executed.

23. The method according to any one of claims 16 to 22, characterized in that The method further comprises: During the process of following the trajectory, if a designated task issued by the host vehicle and a start time for executing the designated task are received, the designated task is executed when the start time for executing the designated task is reached.

24. The method according to claim 23, wherein The designated task includes a lifting task, and when the start execution time of the designated task is reached, executing the designated task includes: Obtaining the current lifting height of the main vehicle; The vehicle controls its own lifting speed according to the difference between its own current lifting height and the current lifting height of the main vehicle, so that the vehicle and the main vehicle are synchronously lifted to the target lifting height.

25. The method according to any one of claims 16 to 24, characterized in that: After executing the following trajectory when the start execution time of the task trajectory is reached, the method further includes: In response to completing the following trajectory, sending an instruction to the host vehicle indicating completion of the collaborative task; In response to the disbanding command issued by the host vehicle, the host vehicle resumes its own independent movement state.

26. A multi-device collaborative control method, characterized in that: Applied to a multi-device collaborative control system, the multi-device collaborative control system includes a master vehicle and at least one slave vehicle, the master vehicle and the at least one slave vehicle forming a platoon, the method comprising: The master vehicle, in response to being determined as the master vehicle of the queue and receiving the collaborative task, plans a task trajectory according to the collaborative task, and publishes the task trajectory and the start execution time of the collaborative task to the at least one slave vehicle; The at least one slave vehicle performs trajectory planning according to the task trajectory to obtain a respective following trajectory of the at least one slave vehicle; When the start execution time of the mission trajectory is reached, the master vehicle executes the mission trajectory, and the at least one slave vehicle respectively executes its own following trajectory.

27. A multi-device collaborative control device, characterized in that: include: a response module, configured to, in response to being determined as a master vehicle of a queue and receiving a collaborative task, plan a task trajectory according to the collaborative task, wherein the queue includes one master vehicle and at least one slave vehicle; a publishing module, configured to publish the task trajectory and the start execution time of the collaborative task to the at least one slave vehicle, so that the at least one slave vehicle plans its own following trajectory according to the task trajectory and executes its own following trajectory when the start execution time of the task trajectory is reached; The execution module is used to execute the task trajectory when the start execution time of the task trajectory is reached.

28. A multi-device collaborative control device, characterized in that: include: a receiving module, configured to receive, after being determined to be a slave vehicle in a queue, a task trajectory and a start execution time of the task trajectory issued by a master vehicle in the queue, wherein the queue comprises one master vehicle and at least one slave vehicle; A planning module, configured to perform trajectory planning according to the task trajectory to obtain a follow-up trajectory; The following module is used to execute the following trajectory when the start execution time of the task trajectory is reached.

29. An autonomous mobile device, characterized in that: include: A memory and a processor, wherein an application is stored on the memory, and the application is used to execute the method according to any one of claims 1 to 15 or the method according to any one of claims 16 to 25 when called by the processor.

30. A computer-readable storage medium, characterized in that The computer-readable storage medium stores program code, and the program code is used to execute the method according to any one of claims 1 to 15 or the method according to any one of claims 16 to 25 when called by a processor.

Images