A robot planning simulation system and method based on a distributed decoupling architecture

Abstract

The application discloses a robot planning simulation system and method based on a distributed decoupling architecture. The system comprises a scene construction layer and an algorithm simulation layer. The scene construction layer is a Web-based online scene editing platform, which is used for parameter configuration and scene element editing, and serializes completed scene data into a scene description file in a preset format. The algorithm simulation layer is a planning simulation engine based on a local running environment, which is used for loading the scene description file and performing closed-loop simulation. The scene construction layer and the algorithm simulation layer perform offline data transmission through the scene description file, or realize real-time bidirectional data communication through a communication protocol. The application completely separates scene construction from algorithm development, effectively solves the technical problem of deep coupling between algorithms and simulation environments in the prior art, and significantly improves research and development efficiency.

Description

Technical Field

[0001] This invention belongs to the field of robot simulation technology, specifically relating to a robot planning simulation system and method based on a distributed decoupled architecture. Background Technology

[0002] In the fields of mobile robotics and autonomous driving, the development and verification of path planning algorithms cannot be separated from the support of simulation environments. Currently, developers mainly use simulation platforms based on ROS (Robot Operating System) (such as Gazebo+RViz) for algorithm research and testing. In this approach, the planning algorithm runs on the ROS communication framework as a ROS node or plugin, and is deeply integrated with the simulation environment.

[0003] However, the aforementioned existing technical solutions share a common technical flaw: the planning algorithm is deeply coupled with the simulation environment. In ROS-based simulation platforms, the input and output formats of the planning algorithm must be consistent with ROS's standard message types. The algorithm's operation depends on the coordination and scheduling of the ROS master node. The algorithm code contains a large amount of non-core logic such as environment adaptation, message format conversion, and topic communication management. This non-core code usually accounts for a considerable proportion of the total algorithm file size, and the algorithm cannot be compiled or run once it is removed from the ROS environment. In self-built simulation environments based on local IDEs, the algorithm code is also tightly bound to specific visualization libraries, mathematical libraries, and file read / write interfaces. When it is necessary to change the visualization scheme or adjust the data format, the core algorithm logic itself needs to be modified synchronously. This tight coupling means that the algorithm cannot exist independently of the simulation environment; the core algorithm logic and environment adaptation code are deeply embedded and difficult to separate.

[0004] The aforementioned tight coupling directly leads to the following technical consequences: poor portability of algorithm code; an algorithm often can only run within a specific simulation framework, requiring extensive refactoring when changing simulation platforms or migrating to real robots; developers cannot perform unit testing and debugging of algorithms independently of the simulation environment, and must start a complete simulation environment to verify the algorithm's correctness, severely slowing down algorithm iteration efficiency; and algorithm modules are also difficult to separate from the simulation framework for independent reuse. All of these technical consequences stem from the tight coupling between the algorithm and the simulation environment.

[0005] The information disclosed in this background section is included only to enhance the understanding of the context of this disclosure, and therefore may contain information that does not constitute relevant technology currently known to those skilled in the art. Summary of the Invention

[0006] This application provides a robot planning simulation system and method based on a distributed decoupled architecture to solve the technical problem in the prior art where the robot path planning algorithm is deeply coupled with the simulation environment, resulting in developers having to deal with a lot of non-algorithm core work and low R&D efficiency.

[0007] The technical solution adopted in this application is as follows: Firstly, this application provides a robot planning and simulation system based on a distributed decoupled architecture, comprising: The scene construction layer is a web-based online scene editing platform used for parameter configuration and scene element editing, and serializing the edited scene data into a scene description file in a preset format. The algorithm simulation layer is a planning simulation engine based on the local runtime environment. It is used to load the scene description file and periodically execute closed-loop iteration of perception, planning, control and simulation to achieve continuous control and physical simulation verification of the virtual robot. The scene construction layer and the algorithm simulation layer transmit data offline through scene description files and / or achieve real-time bidirectional data communication through communication protocols to realize remote closed-loop control in the online state. The scene building layer is used for scene building, and the algorithm simulation layer is used for algorithm simulation. The two are independent of each other to achieve decoupling between scene building and algorithm development.

[0008] In conjunction with the first aspect, in one alternative implementation, the scene construction layer includes: The parameter configuration module allows users to select and configure at least two robot chassis types and edit chassis kinematic constraint parameters. Chassis types include differential chassis, Ackerman chassis, tracked chassis, and four-wheeled vehicle chassis. Chassis kinematic constraint parameters include wheelbase, wheel width, maximum speed limit, and maximum angular velocity limit. The scene element editing module provides a visual and interactive scene element editing function. The scene element editing function includes setting the start and end positions and orientation information in the scene, supporting the drawing of static obstacles with two geometric shapes: circles and rectangles, and supporting the configuration of motion parameters on the basis of static obstacles to generate dynamic obstacles. The scene data management module is used to serialize the edited scene data into a preset format file, supporting local storage, loading, and online storage of scene files.

[0009] In conjunction with the first aspect, in one alternative implementation, the algorithm simulation layer includes: The pluggable plug-in system includes a perception plug-in and a planning plug-in, as well as a perception plug-in manager for managing the perception plug-in and a planning plug-in manager for managing the planning plug-in. It achieves plug-and-play functionality through a unified plug-in interface specification and supports both static linking and dynamic loading. The algorithm management module is used to uniformly schedule and manage the plug-in plug-in system and periodically execute closed-loop iterations of perception, planning, control and simulation. The local simulation engine is used to parse scene description files, perform physical simulation integration at a set time step, perform collision detection, support simulation control, and broadcast world state data through a callback mechanism. The trajectory tracking module is used to calculate the tracking strategy based on the planning results, supports multiple operating modes, and manages the trajectory keeping mechanism; The visualization module is used for scene rendering, data curve display, simulation control panel display, and performance statistics.

[0010] In conjunction with the first aspect, in one optional implementation, the algorithm management module includes: The plugin management unit is used to initialize and manage the perception plugin manager and the planning plugin manager, and dynamically load and manage various algorithm plugins through configuration files. The data preprocessing unit is used to receive world state data from the local simulation engine and / or receive remote world state data from the scene construction layer via a communication protocol, normalize the world state through the preprocessing pipeline, and output standardized perceptual input. The resource scheduling unit is used to allocate the computation time budget for perception and planning, calculate the performance indicators of each module, and handle timeout and failure retry logic. The loop control unit is used to interact with the local simulation engine and perform closed-loop iterative scheduling control; The target processing unit is used to reuse the previous trajectory when the virtual robot approaches the target point, so as to avoid trajectory jitter near the end point.

[0011] In conjunction with the first aspect, in one alternative implementation, the pluggable system includes: The plugin registration management unit is used to manage perception plugins and planning plugins through a plugin registration mechanism, supporting both static linking and dynamic loading. In the static linking method, the plugin is linked to the core library, while in the dynamic loading method, the plugin file is dynamically loaded from a specified directory to achieve hot loading of plugins at runtime. The plug-in interface unit includes a perception plug-in interface and a planning plug-in interface; the perception plug-in interface is used to receive perception input and output perception processing results to the planning context; the planning plug-in interface is used to read perception data in the planning context, calculate the trajectory within a given time budget, and generate planning results.

[0012] In conjunction with the first aspect, in one alternative implementation, the perceptual plugin manager includes: The map builder is used to construct a configurable raster map based on obstacle information. The configuration parameters of the raster map include resolution, map size, and expansion radius. The distance field builder generates a distance field based on the occupied grid. The configuration parameters of the distance field include the maximum distance and the option to include dynamic obstacles.

[0013] In conjunction with the first aspect, in one alternative implementation, the local simulation engine includes: The scene parsing unit is used to parse the scene description file and convert the scene element information into an internal world state data structure. The physical integration unit is used to perform integral calculations on the motion of dynamic objects and virtual robots according to a set time step. The collision detection unit is used to simplify the virtual robot into a geometric model, perform real-time collision detection between the virtual robot and obstacles, and trigger a callback event when a collision occurs. The simulation control unit supports the pause, resume, and reset operations of the simulation process, and records real-time simulation parameters and statistical information; The data broadcasting unit is used to send data containing the complete world state of the current simulation frame to the algorithm management module via a callback mechanism.

[0014] In conjunction with the first aspect, in one alternative implementation, the robot planning and simulation system based on a distributed decoupled architecture supports two communication modes: In offline mode, after editing the scene in the scene building layer, the scene file data is transferred to the local machine and then loaded and run in the algorithm simulation layer. In real-time online mode, the algorithm simulation layer establishes a real-time bidirectional connection with the scene construction layer through a communication protocol to conduct bidirectional data communication, thereby achieving real-time data synchronization and closed-loop control.

[0015] In conjunction with the first aspect, in one optional implementation, the robot planning and simulation system based on a distributed decoupled architecture also includes a development aid tool, which is a plug-in automatic generation tool used to automatically generate template code that conforms to the plug-in interface specification.

[0016] Secondly, this application provides a robot planning and simulation method based on a distributed decoupled architecture, including a scene construction stage and a closed-loop simulation stage; The scene building phase is executed by the scene building layer and includes the following steps: S1, Parameter configuration in the scene construction layer; S2. In the scene editor of the scene building layer, set the start and end point information and orientation; draw static and dynamic obstacles, and configure dynamic parameters; S3. Save the edited scene as a scene description file in a preset format to complete scene construction; The closed-loop simulation phase is executed by the algorithm simulation layer and includes the following steps: S4. The local simulation engine of the algorithm simulation layer loads the scene description file, parses it into the world state, and starts the physical simulation. S5. The algorithm management module receives the world state data of the current simulation frame broadcast from the local simulation engine and schedules the preprocessing pipeline to standardize the data into a sensory input. S6. The perception plugin manager executes perception plugins, builds environmental perception data, and writes it into the planning context. S7. The planning plug-in manager calls the main planner to read the planning context and calculates the optimal trajectory within the time budget; if the main planner fails, it automatically falls back to the backup planner. S8. The trajectory tracking module generates control commands based on the planning results and feeds them back to the local simulation engine to drive the virtual robot's movement. S9. Repeat steps S5 to S8 above until the simulation termination condition is met, so as to periodically perform closed-loop iteration of perception, planning, control and simulation. S10, the visualization module renders scene, trajectory and performance data curves in real time; The scenario building phase and the closed-loop simulation phase operate independently to decouple scenario building from algorithm simulation.

[0017] In conjunction with the second aspect, in one alternative implementation, the main planner includes a search-based global path planner that combines the LBFGS optimization algorithm for trajectory optimization; The backup planner includes a straight trajectory generator based on geometric information.

[0018] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Compared with the prior art, this application has achieved the following beneficial effects: (1) Complete decoupling of scene construction and algorithm simulation is achieved, and the algorithm code no longer contains non-core algorithm logic such as environment adaptation and data format conversion. This application divides the system into two independent parts: a scene construction layer and an algorithm simulation layer. Scene construction is completed by the scene construction layer, and algorithm simulation is executed by the algorithm simulation layer. The two exchange data through standardized scene description files. The algorithm code does not need to handle any non-core logic related to the ROS communication framework, scene construction, and data format conversion. Developers can focus entirely on the mathematical modeling and optimization of the algorithm itself.

[0019] (2) The algorithm can be debugged and verified independently of the simulation environment, which significantly improves the efficiency of algorithm development. In this application, the algorithm simulation layer can independently load the scene description file and execute the simulation. The scene construction and algorithm simulation run independently of each other. Developers can independently debug and verify the algorithm locally without starting the scene construction layer. There is no need to repeatedly configure the environment and build the scene. The algorithm iteration cycle is significantly shortened and the development efficiency is greatly improved.

[0020] (3) The algorithm module has good portability and reusability, and can be flexibly migrated between different scenarios or real robots. In this application, the algorithm runs in the algorithm simulation layer, which is completely decoupled from the scenario construction. The same set of algorithm code can be directly loaded with different scenario description files for testing. After verification, it can be directly migrated to the real robot platform for operation without modifying the core algorithm logic. The portability and reusability of the algorithm are significantly enhanced.

[0021] Other advantages, objectives and features of this application will be partly apparent from the description below, and partly understood by those skilled in the art through study and practice of this application. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of a robot planning and simulation system based on a distributed decoupled architecture provided in an embodiment of this application; Figure 2 This is a schematic diagram of the modules of the scene construction layer 101 provided in the embodiments of this application; Figure 3 This is a schematic diagram of the algorithm simulation layer 103 provided in the embodiments of this application; Figure 4 This is a schematic diagram of the algorithm management module 303 provided in an embodiment of this application; Figure 5 This is a schematic diagram of the modules of the pluggable plug-in system 301 provided in the embodiments of this application; Figure 6 This is a schematic diagram of the perception plugin manager provided in an embodiment of this application; Figure 7 This is a schematic diagram of the local simulation engine 305 provided in an embodiment of this application; Figure 8This is a schematic diagram illustrating the two communication modes supported by the robot planning and simulation system based on a distributed decoupled architecture provided in this application embodiment; Figure 9 This is a flowchart of a robot planning and simulation method based on a distributed decoupled architecture provided in an embodiment of this application. Detailed Implementation

[0024] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0025] The term "and / or" as used in this application includes any and all combinations of one or more of the associated listed items. In this application, "at least one" means one or more, and "more than one" means two or more. The terms "first," "second," and other ordinal terms used in this application may be used to describe various constituent elements, but these constituent elements are not limited by these terms. The purpose of using these terms is solely to distinguish one constituent element from others and should not be construed as indicating or implying relative importance. For example, without departing from the scope of this application, a first constituent element may be named a second constituent element, and similarly, a second constituent element may be named a first constituent element.

[0026] refer to Figure 1 , Figure 1 This is a schematic diagram of a robot planning and simulation system based on a distributed decoupled architecture provided in an embodiment of this application. Figure 1 As shown, the robot planning simulation system based on a distributed decoupled architecture includes a scene construction layer 101 and an algorithm simulation layer 103, specifically including:

[0027] The scene construction layer 101 is a web-based online scene editing platform used for parameter configuration and scene element editing, and serializing the edited scene data into a scene description file in a preset format.

[0028] The algorithm simulation layer 103 is a planning simulation engine based on the local operating environment. It is used to load the scene description file and periodically execute closed-loop iterations of perception, planning, control and simulation to achieve continuous control and physical simulation verification of the virtual robot.

[0029] The scene construction layer 101 and the algorithm simulation layer 103 transmit data offline through the scene description file and / or achieve real-time bidirectional data communication through a communication protocol to realize remote closed-loop control in an online state.

[0030] The scene construction layer 101 is used for scene construction, and the algorithm simulation layer 103 is used for algorithm simulation. The two are independent of each other to achieve decoupling between scene construction and algorithm development.

[0031] Specifically, this robot planning and simulation system based on a distributed decoupled architecture fundamentally solves the technical problem of tight coupling between planning algorithms and simulation environments in existing technologies by separating the deeply coupled scene construction function and algorithm simulation function in traditional ROS solutions into two independent layers. In existing ROS-based simulation solutions, planning algorithms run on the ROS communication framework as ROS nodes or plugins. The input and output formats of the algorithms must be consistent with the standard message types of ROS, and the operation of the algorithms depends on the coordination and scheduling of the ROS master node. The algorithm code contains a large amount of non-core algorithm logic such as environment adaptation, message format conversion, and topic communication management. This non-core code usually accounts for a considerable proportion of the total algorithm file size, and the algorithm cannot be compiled or run once it is removed from the ROS environment. In a self-built simulation environment based on a local IDE, the algorithm code is also tightly bound to specific visualization libraries, mathematical libraries, and file read / write interfaces. When it is necessary to change the visualization scheme or adjust the data format, the core algorithm logic itself needs to be modified synchronously.

[0032] In contrast, this application deploys the scene building function entirely on the web through the scene building layer 101. Users access the online scene editing platform through a browser and complete chassis parameter configuration, start-end point setting, and drawing and parameter configuration of static and dynamic obstacles through interactive operations such as clicking and dragging in the 3D visualization interface. All scene data is serialized into a scene description file in standard JSON format. The algorithm simulation layer 103 runs entirely on the user's local computer as a standalone application written in standard C++, independent of the ROS framework, and can directly load the JSON scene description file and execute the simulation. The only connection between the two layers is the standardized JSON scene description file. The scene building layer 101 produces this file, and the algorithm simulation layer 103 consumes it. This architectural design eliminates the need for any code related to ROS message format conversion, topic communication management, or scene file parsing in the algorithm code. Algorithm developers can focus entirely on the mathematical modeling and optimization of the planning algorithm itself. The core algorithm logic and environment adaptation code are no longer deeply embedded, fundamentally decoupling the algorithm from the simulation environment.

[0033] Thus, this application divides the system into two independent parts: a scene construction layer 101 and an algorithm simulation layer 103. This removes all non-algorithm-centric tasks such as scene construction, environment adaptation, and data conversion, which are often mixed in with the algorithm code in traditional ROS-based simulation platforms, from the scene construction layer 101. The algorithm simulation layer 103 then retains only pure algorithm simulation functionality. In existing ROS solutions, developers must specify a list of dependent ROS packages when creating a package. During compilation, the entire package is deeply bound to the ROS environment. The algorithm code uses ROS core libraries, manages communication through message publishing and subscription mechanisms, and handles coordinate system transformations through coordinate transformation mechanisms. These non-algorithm logic codes are mixed in the same file as core algorithm codes such as pathfinding and trajectory optimization, resulting in a significant decrease in the readability, maintainability, and portability of the algorithm code. In this application, the scene description file loaded by the algorithm simulation layer 103 is a pure data file, which does not contain any executable code or environment configuration instructions. The planning algorithm plugin in the algorithm simulation layer 103 only obtains the perception data in the planning context and returns the trajectory results through a standardized interface. The plugin does not contain any code related to the introduction of the ROS core library, node initialization, or message communication loop. The algorithm code and the simulation framework are completely decoupled. Algorithm developers do not need to understand the ROS communication mechanism, handle message format conversion, or manage topic subscription and publication. They can focus entirely on the algorithm logic itself.

[0034] For example, in the development scenario of an AGV (Automated Guided Vehicle) path planning algorithm, this distributed decoupled architecture can be deployed as follows: Test engineers access the online scene editing platform in the scene construction layer 101 via a browser to complete chassis parameter configuration, start-end point settings, and the drawing and parameter configuration of static and dynamic obstacles. After editing, the scene is saved as a scene description file in a standard format. Simultaneously, algorithm engineers develop their planning algorithm plugin locally. This plugin is encapsulated as an independent module, containing only pure algorithmic logic such as path search and trajectory optimization, without any code related to ROS core library import, message publish / subscribe, specific message type conversion, or scene file parsing and data format conversion. Algorithm engineers place the scene description file in a designated directory in the algorithm simulation layer 103, and run the startup command to load the scene and perform simulation verification, without needing to install a specific operating system, the ROS framework, start the ROS master node, or configure a 3D simulation environment and visualization tools. Scene editing and algorithm development are completed in parallel by different roles without interfering with each other, fundamentally solving the technical problem that algorithm developers in traditional solutions must simultaneously handle non-core tasks such as scene construction, environment configuration, and data adaptation.

[0035] In some embodiments, reference Figure 2, Figure 2 This is a schematic diagram of the modules of the scene construction layer 101 provided in an embodiment of this application. For example... Figure 2 As shown, the scene construction layer 101 includes: The parameter configuration module 201 supports users in selecting and configuring at least two robot chassis types and editing chassis kinematic constraint parameters. The chassis types include differential chassis, Ackerman chassis, tracked chassis, and four-wheeled vehicle chassis. The chassis kinematic constraint parameters include wheelbase, wheel width, maximum speed limit, and maximum angular velocity limit.

[0036] The scene element editing module 203 provides a visual and interactive scene element editing function. This function includes setting the start and end points and orientation information in the scene, supporting the drawing of static obstacles in both circular and rectangular geometric shapes, and supporting the configuration of motion parameters based on static obstacles to generate dynamic obstacles.

[0037] The scene data management module 205 is used to serialize the edited scene data into a preset format file, supporting local storage, loading, and online storage of scene files.

[0038] Specifically, the parameter configuration module 201 is first presented when the user accesses the scene construction layer. The user selects one of four chassis types (differential chassis, Ackerman chassis, tracked chassis, and four-wheeled vehicle chassis). The system automatically loads the corresponding kinematic model and displays editable parameter input controls on the interface, including fields such as wheelbase, wheel width, maximum speed limit, and maximum angular velocity limit. The user can adjust the above parameters within preset ranges to meet the simulation requirements of a specific robot platform. After the parameter configuration is completed, the system automatically saves it to the chassis field of the scene data structure.

[0039] The scene element editing module 203 uses Three.js to build a 3D visual interactive interface, allowing users to build scenes through clicking and dragging. When placing the start and end points, the user clicks anywhere in the scene, and the system uses raycasting technology to map the mouse click location to ground coordinates in 3D space, recording the (x, y) coordinates and heading angle θ. When drawing static obstacles, selecting the circular obstacle tool, clicking to define the center, and dragging to define the radius; selecting the rectangular obstacle tool, clicking to define the center, and dragging to define the length, width, and orientation angle. Based on the static obstacles, the user can input the movement speed (v) through the information panel on the right. x ,v y The system takes the scene element data and its direction of motion, and then appends these motion parameters to the obstacle data to generate dynamic obstacles. All scene element data is stored in the front-end data structure in real time during the editing process.

[0040] The scene data management module 205 is triggered when the user clicks the save button, storing all elements of the current scene, including chassis parameters, start and end point information (position coordinates and orientation angle), static obstacles (center and radius of circular obstacles, center, length, width, and orientation angle of rectangular obstacles), and dynamic obstacles (velocity component v). x and v y The scene description file is uniformly serialized into a standard JSON format and can be downloaded to the local file system. Simultaneously, this module allows users to upload saved JSON files from their local devices for scene loading and further editing, and also supports saving scenes to an online storage service for easy cross-device access and team sharing.

[0041] Therefore, this application constructs a complete scene construction workflow of "parameter configuration - scene building - data persistence" through the collaborative work of the parameter configuration module 201, scene element editing module 203, and scene data management module 205. In existing ROS-based simulation solutions, scene building requires developers to manually write configuration files or code. In Gazebo, .world files and .sdf model files need to be written; in RViz, display parameters need to be configured; and in self-built simulation environments, OpenCV drawing code needs to be written. These tasks are not only tedious and time-consuming, but also lack intuitive visual feedback. Developers must repeatedly save files and restart the simulation to verify the correctness of the scene configuration. This application abstracts chassis parameter configuration into a visual form through the parameter configuration module 201. Users can complete the configuration by selecting the chassis type from the drop-down list and entering the kinematic parameters in the input box. The scene element editing module 203 abstracts obstacle placement into click and drag-and-drop interactions, providing a WYSIWYG scene editing experience where users can build scenes without writing any code. The scene data management module 205 abstracts the saving and loading of the entire scene into a standardized JSON format operation, allowing for one-click export for local simulation. Furthermore, the scene construction layer 101 is completely decoupled from the algorithm simulation layer 103. The scene construction layer 101 only generates JSON scene files and does not depend on any simulation framework or ROS environment; scene editors do not need to understand the algorithm implementation details.

[0042] For example, in the simulation scene editing of AGVs in a cold storage environment, the test engineer needs to construct a cold storage rack intersection scene containing multiple dynamic obstacles to test the obstacle avoidance capability of the planning algorithm in a complex environment. The engineer opens a browser to access the webpage of scene construction layer 101, selects "differential chassis" from the drop-down list in parameter configuration module 201, enters 0.5 in the wheelbase field, 1.0 in the maximum speed limit field, and 2.0 in the maximum angular velocity limit field. Then, in the 3D scene view of scene element editing module 203, clicks to place the starting point at coordinates (0,-20) on the south side of the passage, drags the mouse to set the initial orientation to north, and clicks to place the ending point at coordinates (0,20) on the north side of the passage, setting the target orientation to north. Next, selects a rectangular obstacle from the toolbar, draws a static obstacle (e.g., 2m wide and 1.5m high) on the east side of the passage, and draws another static obstacle (e.g., 1.8m wide and 1.2m high) on the west side of the passage, leaving enough space between the two obstacles for the AGV to pass through. Next, based on the existing static obstacles, a dynamic obstacle with a radius of 0.4m is placed in the middle of the intersection to simulate a worker. The movement speed (v) is entered in the information panel on the right. x =0.5, v y =0), the movement trajectory is from west to east across the intersection, and the movement period is 30 seconds. During the editing process, engineers can freely rotate the viewpoint and zoom in the 3D scene to view the editing details. After editing, clicking save will cause the scene data management module 205 to serialize all elements of the current scene into a standard JSON format scene description file and download it to the local machine. This JSON file can be directly loaded and used by the algorithm simulation layer 103, and engineers can complete the construction of a complete simulation scene without writing any configuration files or code.

[0043] In some embodiments, reference Figure 3 , Figure 3 This is a schematic diagram of the algorithm simulation layer 103 provided in an embodiment of this application. For example... Figure 3 As shown, the algorithm simulation layer 103 includes: The pluggable plug-in system 301 includes a perception plug-in and a planning plug-in, as well as a perception plug-in manager for managing the perception plug-in and a planning plug-in manager for managing the planning plug-in. It achieves plug-and-play functionality through a unified plug-in interface specification and supports both static linking and dynamic loading.

[0044] The algorithm management module 303 is used to uniformly schedule and manage the plug-in plug-in system 301, and periodically execute closed-loop iteration of perception, planning, control and simulation.

[0045] The local simulation engine 305 is used to parse the scene description file, perform physical simulation integration at a set time step, perform collision detection, support simulation control, and broadcast world state data through a callback mechanism.

[0046] The trajectory tracking module 307 is used to calculate the tracking strategy based on the planning results, supports multiple operating modes, and manages the trajectory keeping mechanism.

[0047] The visualization module 309 is used for scene rendering, data curve display, simulation control panel display, and performance statistics.

[0048] Specifically, the perception plugin extracts environmental perception data from the simulation environment, including grid maps and distance fields. The planning plugin calculates the optimal path based on the perception data. All plugins must implement a unified interface specification. The perception plugin interface defines standardized calling methods for initialization, core processing, and resource release. The planning plugin interface defines standardized calling methods for initialization, core calculation, and resource release. Both the perception and planning plugins establish an interaction contract with the algorithm simulation layer by implementing these standardized interfaces. The perception plugin receives standardized perception input and outputs the perception processing results to the planning context. The planning plugin reads the perception data from the planning context, completes trajectory calculation within a given time budget, and returns the planning result. The system manages the plugins through a unified interface specification, enabling each algorithm module to access the simulation framework in a standardized manner. The specific algorithm implementation within the plugin has no code-level dependency on the simulation environment, thus decoupling the algorithm logic from the simulation framework.

[0049] The algorithm management module 303 is the core scheduling hub of the algorithm simulation layer 103. It is responsible for receiving world state data from the local simulation engine 305, standardizing it, and distributing it to the perception and planning plugins for execution. It also manages the time budget and scheduling control of the entire closed-loop iteration. In each closed-loop cycle, the algorithm management module 303 triggers the execution of each module in the order of perception, planning, control, and simulation until the simulation termination condition is met.

[0050] After loading the JSON scene file, the local simulation engine 305 converts the scene elements into an internal world state data structure, performs physical simulation integration at a certain frequency, updates the poses of the AGV and dynamic obstacles, detects collision events, and broadcasts WorldTick data to the algorithm management module 303 through a callback mechanism. For example, this frequency can be 33Hz.

[0051] The trajectory tracking module 307 receives the trajectory generated by the planning plugin and, in playback mode, directly issues the trajectory points as speed commands to most accurately reflect the trajectory quality of the planner. In tracking mode, trajectory tracking control is performed based on the forward preview parameters. When the AGV approaches the target point, the trajectory tracking module 307 activates the trajectory holding mechanism, reusing the previous trajectory to avoid trajectory jitter near the endpoint.

[0052] The visualization module 309 is implemented based on ImGui and SDL2 backend, refreshing and displaying the bird's-eye view (including static / dynamic obstacles, distance field color mapping, planned trajectory line, AGV pose icon) and velocity curve (including linear velocity and angular velocity) at a certain frequency, and providing simulation start / pause / reset controls as well as real-time performance statistics on perception / planning time. For example, this frequency can be 20Hz.

[0053] Specifically, the algorithm simulation layer 103 constructs a complete, independently runnable local simulation environment through the clear division of responsibilities and standardized interface definitions of five modules. The local simulation engine 305 generates the world state as the data source; the algorithm management module 303 acts as the scheduling center, coordinating the execution of perception and planning plugins; the trajectory tracking module 307 acts as the execution end, converting planning results into control commands and feeding them back to the simulation engine; the visualization module 309 acts as the observation end, independently displaying the simulation state; and the pluggable plugin system 301 acts as the algorithm carrier, realizing the standardized encapsulation and dynamic management of algorithm plugins. The modules interact through standardized data interfaces, without relying on any specific communication framework. The planning algorithm is encapsulated as an independent plugin, obtaining perception data from the planning context and returning trajectory results through a unified `plan()` interface. The plugin does not contain any non-algorithmic logic related to environment adaptation, data format conversion, or communication management; the algorithm code is completely decoupled from the simulation framework.

[0054] Therefore, it can be seen that the simulation layer 103 of this algorithm solves the technical problem of tight coupling between the algorithm and the simulation environment in existing ROS-based simulation solutions through a modular and plug-in architecture design. In the ROS Navigation Stack, the planning algorithm runs on the ROS communication framework as a node or plug-in. The input and output formats of the algorithm must be consistent with the standard message types of ROS. The operation of the algorithm depends on the coordination and scheduling of the ROS master node. The algorithm code contains a large amount of non-core algorithm logic such as environment adaptation, message format conversion, and topic communication management. Once the algorithm is separated from the ROS environment, it cannot be compiled or run. In contrast, this application encapsulates the algorithm as an independent plug-in. The plug-in interacts with the simulation framework only through a pure virtual function interface. The plug-in does not contain any code bound to ROS or a specific simulation framework. Developers can focus entirely on the implementation of the core logic of the planning algorithm. At the same time, the plug-in supports both static linking and dynamic loading. The dynamic loading mechanism allows developers to dynamically switch or update the planning algorithm during simulation without recompiling the entire system, which greatly improves the efficiency of algorithm debugging and verification.

[0055] For example, in the development scenario of a path planning algorithm for cold storage AGVs, the R&D team needed to develop an autonomous navigation algorithm suitable for narrow passages and slippery surfaces in a cold storage environment. The team deployed the following application in algorithm simulation layer 103: First, the team constructed a 3D scene simulating a cold storage environment through scene construction layer 101. The scene included narrow shelf aisles only 1.2 meters wide, pallets of goods stacked on both sides of the aisle (as static obstacles), and dynamic obstacles simulating manual replenishment operations (models of handling personnel moving through the aisle at a speed of 0.5 m / s). After the scene was constructed, it was exported as a JSON scene description file.

[0056] Subsequently, the algorithm engineer launched the algorithm simulation layer 103 locally, loading the developed JPS (Jump Point Search) global planning plugin and the DWA (Dynamic Window Approach)-based local planning plugin through the configuration file. When the simulation started, the local simulation engine 305 parsed the JSON scene file, performed physical simulation integration at a frequency of 33Hz, and continuously updated the AGV's pose and the motion state of dynamic obstacles in the cold storage aisle. The data preprocessing unit of the algorithm management module 303 received the world state data of the current simulation frame broadcast from the local simulation engine 305 and normalized it into perception input through the preprocessing pipeline. The plugin management unit sequentially called the perception plugin manager to execute the grid map builder and distance field builder, generating a cold storage aisle grid map with a resolution of 0.05m and an ESDF distance field (maximum distance 3.0m), and wrote it into the planning context. Then, the planning plugin manager was called to execute the JPS planning plugin, which read the grid map and distance field data from the planning context within a 25ms time budget, completed global path search and trajectory optimization, and generated a smooth trajectory from the AGV's current position to the target storage location. The trajectory tracking module 307 receives the planning results and, in playback mode, sends the trajectory point speed commands to the local simulation engine 305 to drive the AGV's movement. Simultaneously, the visualization module 309 renders a bird's-eye view of the cold storage aisle and the AGV's speed curve in real time at a frequency of 20Hz, allowing engineers to monitor and analyze the data.

[0057] During the simulation, algorithm engineers discovered that the trajectory generated by the JPS planner in narrow aisles was too close to the edge of the shelving, posing a collision risk. Engineers did not need to modify any simulation environment configurations or restart the entire simulation system. They simply modified the safety distance parameter in the JPS planning plugin within the integrated development environment (e.g., adjusting `safe_dis` from 0.15m to 0.25m), recompiled the dynamic plugin, and then directly replaced the original plugin during runtime using the plugin dynamic loading mechanism in algorithm simulation layer 103. Rerunning the simulation verified the effect of the adjustment. Throughout the debugging process, engineers did not write any code related to ROS topic subscription, message type conversion, or coordinate transformation, nor did they start any external simulation environment or master node service. The algorithm debugging and verification were completed entirely locally and independently, significantly improving development efficiency and algorithm iteration speed.

[0058] Furthermore, once the JPS planning algorithm is validated in the simulation environment, the team can directly deploy the same plugin code to the industrial control computer of a real cold storage AGV. Since the algorithm plugin does not rely on any ROS or specific simulation framework interfaces, but only obtains perception data and returns trajectory results through the standardized plan() function interface, a seamless migration from simulation to real vehicle can be achieved simply by switching the input source of the perception data from the simulation engine to real sensor data. No modification to any core algorithm logic is required, fully demonstrating the portability and reusability of the algorithm module.

[0059] In some embodiments, reference Figure 4 , Figure 4 This is a schematic diagram of the algorithm management module 303 provided in an embodiment of this application. Figure 4 As shown, the algorithm management module 303 includes: The plugin management unit 401 is used to initialize and manage the perception plugin manager and the planning plugin manager, and dynamically load and manage various algorithm plugins through configuration files.

[0060] The data preprocessing unit 403 is used to receive world state data from the local simulation engine 305 and / or receive remote world state data from the scene construction layer 101 via a communication protocol, normalize the world state through a preprocessing pipeline, and output standardized perceptual input.

[0061] The resource scheduling unit 405 is used to allocate the computation time budget for perception and planning, calculate the performance indicators of each module, and handle timeout and failure retry logic.

[0062] The loop control unit 407 is used to interact with the local simulation engine 305 to perform the closed-loop iterative scheduling control.

[0063] The target processing unit 409 is used to reuse the previous trajectory when the AGV approaches the target point to avoid trajectory jitter near the endpoint.

[0064] Specifically, the algorithm management module 303 is responsible for scheduling and managing all perception, planning, and control closed loops in the algorithm simulation layer 103. In the simulation scenario of the cold storage AGV, the plug-in management unit 401 first reads the configuration file (e.g., default.json), loads perception plug-ins (such as map builder and ESDF builder) and planning plug-ins (such as JPS planner) according to the preset plug-in list, and completes the initialization and registration of the plug-ins. Subsequently, the data preprocessing unit 403 receives WorldTick data broadcast from the local simulation engine 305 at a certain frequency. This data includes the AGV's pose (x, y, θ), linear velocity v, angular velocity ω in the current simulation frame, as well as the position information of static obstacles (such as shelf columns and refrigeration pipes) and dynamic obstacles (such as other AGVs and workers) in the cold storage environment. The preprocessing pipeline performs coordinate transformation and format unification on the above data, outputting standardized perception input. For example, the broadcast frequency can be 33Hz. At the start of each closed-loop cycle, the resource scheduling unit 405 allocates the computational budget to the perception and planning phases according to the system configuration parameters (e.g., 25ms). During execution, it monitors the time consumption of each component in real time, triggering retry or rollback logic when the planner times out or fails. The loop control unit 407 periodically triggers the execution of each module in the order of perception, planning, control, and simulation, continuously checking whether the simulation termination conditions are met (e.g., the AGV reaches the target location or the user actively pauses), thereby controlling the start and stop of the closed-loop iteration. When the AGV approaches the target point, i.e., the distance between the AGV's current position and the target point is less than a preset threshold (e.g., 2.0m), the target processing unit 409 sends a command to the trajectory tracking module 307, causing it to stop receiving new planned trajectories and instead reuse the previously received trajectory until the AGV fully reaches the target point, thus avoiding frequent replanning caused by numerical oscillations near the endpoint.

[0065] Thus, the algorithm management module 303, through the refined division of labor among five functional units, centralizes the scheduling logic scattered across multiple nodes and topics in the traditional ROS NavigationStack—including plug-in management, data preprocessing, time budget allocation, loop control, and endpoint oscillation suppression—into a single module for unified management. In the actual operating environment of cold storage AGVs, AGVs need to continuously perform cargo handling tasks in a low-temperature environment. The starting and stopping of refrigeration fans, the opening and closing of cold storage doors, and temporary entry and exit of personnel all generate unpredictable dynamic obstacles, requiring the planning algorithm to have high-frequency response capabilities. This application, through the time budget management and failure retry logic of the resource scheduling unit 405, ensures that even if the algorithm times out, a backup planner (such as a straight trajectory generator) takes over, guaranteeing the continuity and robustness of the simulation. Through the trajectory-keeping mechanism of the target processing unit 409, the common reciprocating oscillation problem of AGVs approaching target locations in narrow shelf aisles is solved, improving trajectory smoothness and positioning accuracy.

[0066] In some embodiments, reference Figure 5 , Figure 5 This is a schematic diagram of the modules of the pluggable plug-in system 301 provided in an embodiment of this application. For example... Figure 5 As shown, the pluggable plug-in system 301 includes: The plugin registration management unit 501 is used to manage the perception plugin and the planning plugin through a plugin registration mechanism, supporting both static linking and dynamic loading methods. In the static linking method, the plugin is linked to the core library, while in the dynamic loading method, plugin files are dynamically loaded from a specified directory, achieving hot loading of plugins at runtime.

[0067] The plug-in interface unit 503 includes a perception plug-in interface and a planning plug-in interface. The perception plug-in interface is used to receive perception input and output perception processing results to the planning context. The planning plug-in interface is used to read perception data in the planning context, calculate the trajectory within a given time budget, and generate planning results.

[0068] Specifically, the pluggable plugin system 301 is the core mechanism for the algorithm simulation layer 103 to decouple the algorithm from the simulation environment. Upon system startup, the plugin registration management unit 501 first reads the plugin declaration list from the configuration file. For perception plugins marked as "built-in" (such as map builders and ESDF builders) and planning plugins (such as JPS planners and TEB planners), they are directly linked to the core library using static linking, allowing for direct invocation after system startup. For custom plugins marked as "dynamic," the plugin registration management unit 501 scans the dynamic link library files in the specified directory, loads the plugin files into memory through a dynamic loading mechanism, calls the plugin creation function to generate plugin instances, and registers the plugin information to the global plugin registry through a registration mechanism. The plugin interface unit 503 defines standardized perception plugin interfaces and planning plugin interfaces. The perception plugin interface specifies the data format of the perception input and the output specifications of the processing results. All perception plugins must follow this interface, receiving standard perception inputs containing information such as raster maps and obstacle lists, and outputting perception products such as maps or distance fields to the planning context after processing. The planning plugin interface specifies the data format for planning inputs and the output specifications for planning results. All planning plugins must follow this interface to read perception data from the planning context, complete trajectory search and optimization within a given time budget, and return the planning results.

[0069] Therefore, the pluggable plugin system 301, through the collaborative work of the plugin registration management unit 501 and the plugin interface unit 503, simplifies the cumbersome process of writing configuration files, declaring plugins, and inheriting specific base classes in the ROS Navigation Stack to simply implementing the core algorithm functions to complete custom plugin development. In practical applications of cold storage AGVs, different cold storage areas have drastically different environmental characteristics. For example, in the ambient temperature passageway (-5℃ to 5℃), the floor may be slippery due to condensation, requiring the planner to consider friction constraints. In the cryogenic zone (-25℃ to -18℃), the aisle width may be as narrow as 1.2 meters, requiring the planner to have high-precision narrow space passage capabilities. In the loading and unloading platform area, large dynamic obstacles such as pallets and forklifts move frequently, placing higher demands on the planner's real-time response speed. Faced with these diverse application scenarios, developers do not need to develop a separate planner for each scenario. Instead, they can configure different planning plugins for different cold storage areas through the dynamic loading mechanism of the plugin registration management unit 501. For example, the JPS planner can be used in narrow aisle areas, while the TEB planner can be switched to in loading / unloading platform areas. This switching is achieved in real-time during simulation by simply modifying the plugin name in the configuration file, without needing to recompile the system or restart the simulation process. Furthermore, the standardized interface design of the plugin interface unit 503 completely isolates the algorithm code from the simulation framework. The plugin contains only pure algorithm logic and no non-core code related to ROS topic subscription, message type conversion, or cold storage environment modeling. Planner developers can focus entirely on improving path search and trajectory optimization algorithms.

[0070] For example, in the development scenario of a cold storage AGV scheduling algorithm, the algorithm team needs to compare and test the performance of three different planning algorithms in different cold storage areas: Algorithm A is a global planner based on JPS (suitable for long-distance transportation in narrow aisles), Algorithm B is a local planner based on TEB (suitable for areas with dense dynamic obstacles), and Algorithm C is a newly developed topology-driven parallel MPC planner (suitable for multi-AGV collaborative scenarios). The system performs the following operations: First, the plug-in registration management unit 501 reads the configuration file when the system starts, loads Algorithm A and Algorithm B in a static link manner, and loads and registers the dynamic library of Algorithm C stored in the specified directory through a dynamic loading mechanism. The plug-in interface unit 503 ensures that the three algorithm plug-ins interact with the simulation framework through a unified planning plug-in interface. The input is the planning context (including grid map, ESDF distance field, and dynamic obstacle list), and the output is the planning result (including trajectory point sequence and speed command). When the AGV travels in the narrow shelf aisle of the deep-cold zone, the resource scheduling unit calls Algorithm A (JPS planner) to complete the long-distance path search. When the AGV enters a dynamic obstacle-dense area of ​​the loading / unloading platform, the system switches the main planner from Algorithm A to Algorithm B (TEB planner) by modifying the configuration file during operation. Upon detecting the configuration change, the plugin registration management unit 501 unloads the current instance of Algorithm B and reloads it during runtime, achieving hot switching without restarting the simulation. When it is necessary to verify the performance of the newly developed Algorithm C in a cold storage scenario, developers only need to set the main planner to Algorithm C in the configuration file. The plugin registration management unit 501 automatically loads the dynamic library of Algorithm C from the specified directory and instantiates it. The entire process does not require recompiling the system. The core code of the three algorithm plugins does not contain any non-algorithmic logic related to environment adaptation or message format conversion. Developers can focus on the mathematical modeling and optimization of their respective algorithms, significantly improving the efficiency of algorithm development and comparative verification.

[0071] In some embodiments, reference Figure 6 , Figure 6 This is a schematic diagram of the perception plugin manager provided in an embodiment of this application. For example... Figure 6 As shown, the perception plugin manager includes: Map builder 601 is used to construct a configurable grid map based on obstacle information, wherein the configuration parameters of the grid map include resolution, map size, and expansion radius.

[0072] Distance field builder 603 is used to generate a distance field based on an occupied grid, the configuration parameters of which include a maximum distance and the ability to select whether to include dynamic obstacles.

[0073] Specifically, at the start of each perception cycle, the map builder 601 receives standardized perception input from the data preprocessing unit 403, including the location information of static obstacles (such as shelf pillars, refrigeration pipes, and the fixed outlines of stacked goods in a cold storage environment) and dynamic obstacles (such as other AGVs in motion and workers temporarily handling goods). Centered on the current location of the AGV, the map builder 601 constructs a two-dimensional occupied grid map on a horizontal plane according to the resolution (e.g., 0.1m) and map size (e.g., 30m × 30m) specified in the configuration file. For each grid cell, the map builder 601 marks its status based on the presence or absence of obstacles in the perception input. Grids occupied by shelf pillars or stacked goods are marked as occupied, while passageways accessible to the AGV are marked as idle. After map construction is complete, the map builder 601 expands the grids occupied by obstacles according to an expansion radius parameter (e.g., 0.2m), marking the idle grids within a certain radius around the obstacle as expanded areas to represent the safe distance the AGV must maintain during movement. Subsequently, the distance field builder 603 reads the occupied grid information output by the map builder 601, and calculates the Euclidean distance between each grid cell and the nearest obstacle grid cell using dynamic programming or a fast traverse algorithm, generating an Euclidean notated distance field for collision cost calculation and path optimization in subsequent planning algorithms. The value of each grid cell in the distance field is the distance from that location to the nearest obstacle. Distance values ​​inside obstacles are negative, while distance values ​​outside obstacles are positive; the magnitude of the distance value characterizes the safety of the location. The calculation range of the distance field builder 603 is the maximum distance specified in the configuration file (e.g., 5.0m). Grid cells exceeding this range are no longer included in the distance field calculation to control computational overhead. Furthermore, the distance field builder 603 controls whether dynamic obstacles are included in the distance field calculation through the configuration parameter `include_dynamic`. When this parameter is set to true, dynamic obstacles participate in the distance field calculation along with static obstacles, providing a more conservative collision cost estimate. When set to false, the distance field only reflects static environment information, and dynamic obstacles are handled separately by the planner at runtime through other mechanisms.

[0074] Therefore, the map builder 601 and the distance field builder 603, through cascading processing, transform the raw world state data from the local simulation engine 305 into structured environmental perception information that the planning algorithm can directly use, forming a complete perception processing chain from "original obstacle position" to "grid occupancy state" and then to "continuous distance field". In the ROSNAvigation Stack, map building is maintained by SLAM nodes, and the cost map is maintained by costmap_2d nodes. Data synchronization and coordinate system transformation between the two require manual configuration by the developer, and the handling of dynamic obstacles depends on the independent observation layer and expansion layer in costmap_2d, with dozens of configuration items. This application integrates the above logic into two standardized plugins, map builder 601 and distance field builder 603, which are executed sequentially. The configuration parameters of both are centrally managed in the configuration file, and the data is passed through the planning context. Developers do not need to maintain the communication state and coordinate system transformation relationship between nodes, which significantly reduces the configuration complexity and maintenance cost of the perception chain.

[0075] In some embodiments, reference Figure 7 , Figure 7 This is a schematic diagram of the local simulation engine 305 provided in an embodiment of this application. For example... Figure 7 As shown, the local simulation engine 305 includes: The scene parsing unit 701 is used to parse the scene description file and convert the scene element information into an internal world state data structure.

[0076] The physical integration unit 703 is used to perform integral calculations on the motion of dynamic objects and AGVs according to a set time step.

[0077] The collision detection unit 705 is used to simplify the AGV into a geometric model, perform real-time collision detection between the AGV and obstacles, and trigger a callback event when a collision occurs.

[0078] The simulation control unit 707 is used to support the pause, resume and reset operations of the simulation process, and to record real-time simulation parameters and statistical information.

[0079] The data broadcasting unit 709 is used to send data containing the complete world state of the current simulation frame to the algorithm management module 303 through a callback mechanism.

[0080] Specifically, the local simulation engine 305 is responsible for all physical simulation and state management in the simulation environment. In the simulation scenario of the cold storage AGV, the scene parsing unit 701 first reads the JSON-formatted scene description file exported by the user through the scene construction layer 101, extracts the cold storage layout information (including static elements such as shelf arrangement, aisle width, refrigeration pipe position, and charging pile position), the coordinates of the AGV's starting point and target storage location, and the initial position and motion parameters of dynamic obstacles (such as the travel paths of other AGVs and the movement trajectories of workers), and transforms the above information into an internal world state data structure as the data basis for subsequent physical simulation and collision detection. Subsequently, the physical integration unit 703 performs integral updates on the motion state of the AGV at a fixed time step (e.g., 33Hz), calculates the position and orientation of the AGV in the next frame based on the linear velocity and angular velocity in the current control command, combined with the chassis kinematic model of the AGV, and updates the pose of the dynamic obstacles. In each simulation step, the collision detection unit 705 simplifies the AGV into a circular or rectangular geometric model, calculates its distance and intersection relationships with the shelf edge, refrigeration pipes, other AGVs, and workers in real time, and triggers a preset callback event when a collision is detected. The simulation control unit 707 provides a unified simulation state management interface, controls the execution and stopping of the physical integration unit 703 by setting the simulation running state, and records real-time parameters and statistics such as the current simulation duration, AGV travel distance, and number of planning calls. After each physical integration step, the data broadcasting unit 709 encapsulates complete world state data, including the AGV's current pose, speed, the position and speed of all static and dynamic obstacles, and the current simulation timestamp, into a WorldTick data structure, and sends it to the algorithm management module 303 at a certain frequency (e.g., 20Hz) through a callback mechanism, triggering a new round of perception, planning, and control closed-loop iteration.

[0081] Therefore, the local simulation engine 305 constructs a complete and independently operable local simulation environment through the pipelined collaboration of five functional units: scene analysis, physics integration, collision detection, simulation control, and data broadcasting. In the actual operating environment of cold storage AGVs, the cold storage maintains a low temperature of -18°C to -25°C year-round, and the AGV's battery performance, tire friction coefficient, and braking distance are all significantly affected by the low temperature. This application uses the scene analysis unit 701 to read the cold storage temperature parameters and ground friction coefficient from the scene description file, and the physics integration unit 703 introduces a temperature correction factor into the kinematic integration, making the simulated motion state closer to the dynamic characteristics of AGVs in a real cold storage environment. Through the real-time collision detection and callback mechanism of the collision detection unit 705, safety hazards of the planning algorithm in high-risk areas such as the intersection of shelf aisles and the entrance and exit of cold storage doors can be detected in advance during the simulation stage. Through the simulation parameter recording of the simulation control unit 707, algorithm engineers can run simulation tests in batches, statistically analyze the quantitative indicators of different algorithms in the same cold storage scenario, and provide data support for algorithm selection and parameter optimization.

[0082] In some embodiments, reference Figure 8 , Figure 8 This diagram illustrates the two communication modes supported by the robot planning and simulation system based on a distributed decoupled architecture provided in this embodiment of the application. Figure 8 As shown, this robot planning and simulation system based on a distributed decoupled architecture supports two communication modes: offline mode 801 and real-time online mode 803.

[0083] The offline mode 801 involves editing the scene in the scene construction layer 101, transferring the scene file data to the local machine, and loading and running it in the algorithm simulation layer 103. In the simulation scene of the cold storage AGV, in offline mode 801, the user first accesses the scene construction layer 101 through a browser to complete the 3D scene editing of the cold storage environment, including the cold storage layout, AGV model and kinematic parameters, start and end points, static obstacles, and dynamic obstacle configurations. After editing, the scene data is serialized into a JSON format scene description file and exported for download. Subsequently, the user transfers the JSON file to the local computer running the algorithm simulation layer 103 and starts the simulation by specifying the scene file path using command-line parameters. The local simulation engine 305 of the algorithm simulation layer 103 loads the JSON file, the scene parsing unit 701 converts the scene element information into an internal world state data structure, the physical integration unit 703 performs integration calculations according to a set time step, and the AGV executes the transport task in the simulation environment according to a preset perception, planning, and control closed loop. This mode is suitable for algorithm developers to perform independent algorithm debugging and regression testing locally, and the entire simulation process does not require a network connection with the scene construction layer 101.

[0084] The real-time online mode 803 involves the algorithm simulation layer 103 establishing a real-time bidirectional connection with the scene construction layer 101 via the WebSocket communication protocol to conduct bidirectional data communication, achieving real-time data synchronization and closed-loop control. Specifically, in the simulation scenario of the cold storage AGV, in real-time online mode 803, the scene construction layer 101 starts a WebSocket server and listens on a specified port. The algorithm simulation layer 103 specifies the server address through command-line parameters and initiates a connection request. After the connection is established, the data broadcast unit 709 of the algorithm simulation layer 103 encapsulates WorldTick data containing the AGV's current pose, linear velocity, angular velocity, and the position information of all static and dynamic obstacles and sends it to the scene construction layer 101 at a certain frequency. Simultaneously, the algorithm simulation layer 103 continuously listens for downlink messages from the scene construction layer 101, including real-time adjustment instructions for scene parameters, simulation control instructions, and heartbeat detection signals. After receiving the WorldTick data, the scene construction layer 101 updates the pose status of the AGV and obstacles in the 3D scene in real time, achieving remote visual monitoring. When a scene parameter adjustment command is received, the algorithm simulation layer 103 dynamically updates its internal world state data structure and applies the new scene configuration in the next closed-loop iteration, thereby achieving remote closed-loop control. This mode is suitable for collaborative work scenarios in distributed R&D teams. Algorithm developers run the algorithm locally, while scene editors or testers remotely observe the simulation running status in real time through a web interface and can dynamically adjust scene parameters to verify the robustness of the algorithm under different operating conditions.

[0085] Thus, this application, through the flexible configuration of two communication modes—offline mode 801 and real-time online mode 803—covers the application needs of all scenarios, from individual independent research and development to team collaborative development. In traditional ROS solutions, all modules must run in the same ROS network and communicate through the Topic / Service mechanism, resulting in strong runtime dependencies between modules. If the Gazebo simulator fails to start properly, RViz cannot display any data. If roscore is not running, all nodes cannot communicate. Furthermore, ROS's communication mechanism is based on the DDS middleware, making it difficult to deploy flexibly in distributed team collaboration scenarios across regions and networks. In contrast, the offline mode 801 of this application allows scenario construction and algorithm simulation to be performed completely independently, without the need for network connection and server support. Algorithm engineers can repeatedly load different scenario JSON files in a local offline environment to perform batch regression tests, suitable for individual research and development or development and debugging in network-constrained environments. The real-time online mode 803 achieves end-to-end bidirectional real-time communication through the lightweight WebSocket protocol, eliminating the need to deploy a complex ROS network environment, allowing team members with different roles to work collaboratively in different locations. The common core feature of the two modes is that, regardless of whether offline mode 801 or real-time online mode 803 is used, the core module in the algorithm simulation layer 103 does not contain any code related to the communication protocol. The difference in the communication mechanism is completely controlled by the startup parameters of the algorithm simulation layer 103. The algorithm plugin is completely transparent to the communication mode. The same set of algorithm code runs in the same logic in both modes, which fundamentally ensures the decoupling of algorithm logic and communication method.

[0086] In some embodiments, the robot planning and simulation system based on a distributed decoupled architecture further includes a development aid tool, which is a plug-in automatic generation tool used to automatically generate template code that conforms to the plug-in interface specification.

[0087] Specifically, developers input plugin creation instructions (including plugin name, plugin type, and output directory path) via command line. In response, the tool generates an algorithm layer directory and an adaptation layer directory in the output directory. An algorithm implementation template file is generated in the algorithm layer directory for developers to populate with pure algorithm logic. Interface adaptation template code is generated in the adaptation layer directory to encapsulate the pure algorithm logic into a plugin instance conforming to the perceptual plugin interface or planning plugin interface specification. A build configuration file (e.g., CMakeLists.txt) and registration code are automatically generated. The build configuration file compiles the algorithm layer and adaptation layer into a dynamic link library, and the registration code registers the compiled plugin instance to the global plugin registry of the pluggable plugin system. Through this process, developers only need to fill in the core algorithm logic in the algorithm layer to complete the entire development work of a pluggable plugin conforming to the system plugin interface specification, without manually writing any interface adaptation code, build configuration file, or plugin registration code.

[0088] Thus, this automatic plugin generation tool further reduces the coupling between the algorithm and the simulation environment at the development process level. In the ROS Navigation Stack, developers need to understand the pluginlib mechanism, write XML configuration files, and declare plugins and configure compilation options in multiple files. Errors in any step can lead to plugin loading failures. This application uses automated template generation to automatically complete all the above non-algorithm development work, including interface adaptation, build configuration, and plugin registration, all at once. Developers only need to fill in the pure algorithm core logic in the algorithm layer directory, and it can be used directly after compilation. The separation design of the algorithm layer and the adaptation layer ensures that there is no code coupling between the core algorithm logic and the simulation framework interface. The code that developers fill in at the algorithm layer does not contain any dependencies related to ROS message types, topic communication, or system APIs. This algorithm code can be directly ported to real robot platforms or other simulation systems for reuse.

[0089] Based on the same technical concept, embodiments of this application also provide a robot planning and simulation method based on a distributed decoupled architecture. (Reference) Figure 9 , Figure 9 This is a flowchart of a robot planning and simulation method based on a distributed decoupled architecture provided in an embodiment of this application. Figure 9 As shown, the robot planning and simulation method based on a distributed decoupled architecture includes a scenario construction stage and a closed-loop simulation stage.

[0090] The scene construction phase is executed by the scene construction layer 101 and includes the following steps: S1. The scene construction layer 101 is configured with parameters; S2. In the scene editor of the scene construction layer 101, set the start and end point information and orientation. Draw static and dynamic obstacles and configure dynamic parameters; S3. Save the edited scene as a scene description file in a preset format to complete scene construction; The closed-loop simulation phase is executed by the algorithm simulation layer 103 and includes the following steps: S4. The local simulation engine 305 of the algorithm simulation layer 103 loads the scene description file, parses it into world state, and starts physical simulation. S5. The algorithm management module 303 receives the world state data of the current simulation frame broadcast by the local simulation engine 305, and schedules the preprocessing pipeline to standardize the data into a perceptual input. S6. The perception plugin manager executes the perception plugin, constructs environmental perception data, and writes it into the planning context. S7. The planning plug-in manager calls the main planner to read the planning context and calculates the optimal trajectory within the time budget. If the main planner fails, it automatically falls back to the backup planner. S8. The trajectory tracking module 307 generates control commands based on the planning results and feeds them back to the local simulation engine 305 to drive the AGV movement. S9. Repeat steps S5 to S8 until the simulation termination condition is met, so as to periodically perform closed-loop iteration of perception, planning, control and simulation.

[0091] S10, The visualization module 309 renders the scene, trajectory, and performance data curves in real time.

[0092] The scenario construction phase and the closed-loop simulation phase operate independently of each other to achieve decoupling between scenario construction and algorithm simulation.

[0093] In some embodiments, the primary planner includes a search-based global path planner that incorporates the LBFGS optimization algorithm for trajectory optimization. The backup planner includes a geometrically based straight-line trajectory generator.

[0094] Specifically, the main planner includes a search-based global path planner (such as JPS), which performs a global path search on the grid map to obtain a sequence of collision-free path points. This sequence is then smoothed using the LBFGS optimization algorithm. Under the premise of satisfying safety distance constraints and AGV kinematic constraints, a nonlinear optimization problem involving path length cost, curvature cost, and collision cost is iteratively solved to generate a smooth and executable optimal trajectory. The backup planner includes a geometrically based straight-line trajectory generator. When the main planner experiences a timeout or planning failure due to sudden environmental changes, it immediately generates a straight-line trajectory based on the AGV's current pose and the target point's pose, and outputs control commands along with a trapezoidal velocity curve to ensure the continuity and robustness of the simulation. In the actual simulation test scenario of the cold storage AGV, if a dynamic obstacle (such as a stacker crane being loaded or unloaded) suddenly appears in the passage ahead, blocking the original path, the main planner will trigger a calculation timeout when replanning. The resource scheduling unit 405 of the algorithm management module 303 will automatically switch the planner to the backup planner, which will generate a temporary straight trajectory to guide the AGV around the obstacle. After the main planner recovers, it will automatically switch back, thus completing dynamic obstacle avoidance without interrupting the simulation. Algorithm engineers do not need to write any exception handling code and can focus on improving the core algorithm of the main planner. Among them, the LBFGS (Limited-memory Broyden-Fletcher-Goldfarb-Shanno) algorithm is a numerical optimization algorithm applied to the field of robot path planning and trajectory optimization. Its core function is to perform fine smooth optimization of the initial path obtained by global path search (such as the JPS algorithm) in a local continuous space under multiple constraints such as kinematics and safety distance. As a quasi-Newton method, the LBFGS algorithm, when solving large-scale optimization problems, does not directly calculate or store the Hessian matrix (i.e., the second derivative matrix) required in Newton's method. Instead, it approximates the inverse of this matrix by only storing the gradient change information of the most recent few steps. This reduces its storage and computational complexity from O(n²) to O(m·n) (where n is the number of optimization variables and m is the number of memory steps stored, usually a smaller value). It is particularly suitable for handling real-time trajectory optimization problems in fields such as robotics and autonomous driving. In this system, after the planner obtains a collision-free initial reference trajectory, the LBFGS algorithm uses this path point as the initial solution and iteratively minimizes a nonlinear objective function that includes path length cost (making the trajectory shorter), curvature cost (making the trajectory smoother), and collision cost (making the path away from obstacles). This generates an optimal executable trajectory that satisfies vehicle kinematic constraints while balancing safety and ride comfort.

[0095] It should be noted that the order of description of the embodiments in this application is not intended to limit the priority of the embodiments.

[0096] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this application and in its specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0097] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many forms under the guidance of this application without departing from the spirit and scope of protection of the claims. All equivalent transformations made under the inventive concept of this application using the content of this application's specification and drawings, or direct / indirect applications in other related technical fields, are included within the patent protection scope of this application.

Claims

1. A robot planning and simulation system based on a distributed decoupled architecture, characterized in that, include: The scene construction layer is a web-based online scene editing platform used for parameter configuration and scene element editing, and serializing the edited scene data into a scene description file in a preset format; The algorithm simulation layer is a planning simulation engine based on the local runtime environment. It is used to load the scene description file and periodically execute closed-loop iteration of perception, planning, control and simulation to achieve continuous control and physical simulation verification of the virtual robot. The scene construction layer and the algorithm simulation layer transmit data offline through the scene description file and / or achieve real-time bidirectional data communication through a communication protocol to realize remote closed-loop control in an online state. The scene construction layer is used for scene construction, and the algorithm simulation layer is used for algorithm simulation. The two are independent of each other to achieve decoupling between scene construction and algorithm development.

2. The robot planning and simulation system based on a distributed decoupled architecture as described in claim 1, characterized in that, The scene construction layer includes: The parameter configuration module is used to support users in selecting and configuring at least two robot chassis types and editing chassis kinematic constraint parameters; the chassis types include differential chassis, Ackerman chassis, tracked chassis and four-wheel vehicle chassis, and the chassis kinematic constraint parameters include wheelbase, wheel width, maximum speed limit and maximum angular velocity limit; The scene element editing module provides a visual and interactive scene element editing function. The scene element editing function includes setting the start and end positions and orientation information in the scene, supporting the drawing of static obstacles with two geometric shapes: circles and rectangles, and supporting the configuration of motion parameters on the basis of static obstacles to generate dynamic obstacles. The scene data management module is used to serialize the edited scene data into a preset format file, supporting local storage, loading, and online storage of scene files.

3. The robot planning and simulation system based on a distributed decoupled architecture as described in claim 1, characterized in that, The algorithm simulation layer includes: A pluggable plug-in system, comprising a perception plug-in and a planning plug-in, as well as a perception plug-in manager for managing the perception plug-in and a planning plug-in manager for managing the planning plug-in, achieves plug-and-play functionality through a unified plug-in interface specification, and supports both static linking and dynamic loading methods. The algorithm management module is used to uniformly schedule and manage the plug-in plug-in system and periodically execute closed-loop iterations of perception, planning, control and simulation. The local simulation engine is used to parse the scene description file, perform physical simulation integration at a set time step, perform collision detection, support simulation control, and broadcast world state data through a callback mechanism. The trajectory tracking module is used to calculate the tracking strategy based on the planning results, supports multiple operating modes, and manages the trajectory keeping mechanism; The visualization module is used for scene rendering, data curve display, simulation control panel display, and performance statistics.

4. The robot planning and simulation system based on a distributed decoupled architecture as described in claim 3, characterized in that, The algorithm management module includes: The plugin management unit is used to initialize and manage the perception plugin manager and the planning plugin manager, and dynamically load and manage various algorithm plugins through configuration files. The data preprocessing unit is used to receive world state data from the local simulation engine and / or receive remote world state data from the scene construction layer via a communication protocol, normalize the world state through a preprocessing pipeline, and output standardized perceptual input. The resource scheduling unit is used to allocate the computation time budget for perception and planning, calculate the performance indicators of each module, and handle timeout and failure retry logic. A loop control unit is used to interact with the local simulation engine and execute the closed-loop iteration scheduling control; The target processing unit is used to reuse the previous trajectory when the virtual robot approaches the target point, so as to avoid trajectory jitter near the end point.

5. The robot planning and simulation system based on a distributed decoupled architecture as described in claim 3, characterized in that, The pluggable plug-in system includes: The plugin registration management unit is used to manage the perception plugin and the planning plugin through a plugin registration mechanism, supporting both static linking and dynamic loading methods. In the static linking method, the plugin is linked with the core library, while in the dynamic loading method, the plugin file is dynamically loaded from a specified directory to achieve hot loading of plugins at runtime. The plug-in interface unit includes a perception plug-in interface and a planning plug-in interface; the perception plug-in interface is used to receive perception input and output perception processing results to the planning context; the planning plug-in interface is used to read perception data in the planning context, calculate the trajectory within a given time budget, and generate planning results.

6. The robot planning and simulation system based on a distributed decoupled architecture as described in claim 3, characterized in that, The perception plugin manager includes: A map builder for constructing a configurable grid map based on obstacle information, wherein the configuration parameters of the grid map include resolution, map size, and expansion radius; A distance field builder is used to generate a distance field based on an occupied grid. The configuration parameters of the distance field include a maximum distance and the ability to select whether to include dynamic obstacles.

7. The robot planning and simulation system based on a distributed decoupled architecture as described in claim 3, characterized in that, The local simulation engine includes: The scene parsing unit is used to parse the scene description file and convert the scene element information into an internal world state data structure. The physical integration unit is used to perform integral calculations on the motion of dynamic objects and virtual robots according to a set time step. The collision detection unit is used to simplify the virtual robot into a geometric model, perform real-time collision detection between the virtual robot and obstacles, and trigger a callback event when a collision occurs. The simulation control unit supports the pause, resume, and reset operations of the simulation process, and records real-time simulation parameters and statistical information; The data broadcasting unit is used to send data containing the complete world state of the current simulation frame to the algorithm management module through a callback mechanism.

8. The robot planning and simulation system based on a distributed decoupled architecture as described in claim 1, characterized in that, The robot planning and simulation system based on a distributed decoupled architecture supports two communication modes: In offline mode, after editing the scene in the scene construction layer, the scene file data is transferred to the local machine and loaded and run in the algorithm simulation layer; In real-time online mode, the algorithm simulation layer establishes a real-time bidirectional connection with the scene construction layer through a communication protocol to conduct bidirectional data communication, thereby achieving real-time data synchronization and closed-loop control.

9. The robot planning and simulation system based on a distributed decoupled architecture as described in claim 1, characterized in that, The robot planning and simulation system based on a distributed decoupled architecture also includes a development aid tool, which is a plug-in automatic generation tool used to automatically generate template code that conforms to the plug-in interface specification.

10. A robot planning and simulation method based on a distributed decoupled architecture, characterized in that, This includes the scenario construction phase and the closed-loop simulation phase; The scene construction phase is executed by the scene construction layer and includes the following steps: S1. The scene construction layer is configured with parameters; S2. In the scene editor of the scene construction layer, set the start and end point information and orientation; draw static and dynamic obstacles, and configure dynamic parameters; S3. Save the edited scene as a scene description file in a preset format to complete scene construction; The closed-loop simulation phase is executed by the algorithm simulation layer and includes the following steps: S4. The local simulation engine of the algorithm simulation layer loads the scene description file, parses it into world state, and starts physical simulation. S5. The algorithm management module receives the world state data of the current simulation frame broadcast by the local simulation engine, and schedules the preprocessing pipeline to standardize the data into a perceptual input. S6. The perception plugin manager executes the perception plugin, constructs environmental perception data, and writes it into the planning context. S7. The planning plug-in manager calls the main planner to read the planning context and calculates the optimal trajectory within the time budget; if the main planner fails, it automatically falls back to the backup planner. S8. The trajectory tracking module generates control commands based on the planning results and feeds them back to the local simulation engine to drive the virtual robot to move. S9. Repeat steps S5 to S8 above until the simulation termination condition is met, so as to periodically perform closed-loop iteration of perception, planning, control and simulation. S10. The visualization module renders the scene, trajectory, and performance data curves in real time. The scenario construction phase and the closed-loop simulation phase operate independently of each other to achieve decoupling between scenario construction and algorithm simulation.

11. The robot planning and simulation method based on a distributed decoupled architecture as described in claim 10, characterized in that, The main planner includes a search-based global path planner, which combines the LBFGS optimization algorithm for trajectory optimization; The backup planner includes a straight trajectory generator based on geometric information.

Images