An unmanned urban combat confrontation system
Patent Information
- Application Number
- CN202610972120.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-01
- Publication Date
- 2026-10-16
AI Technical Summary
[0003]第一,城市作战环境复杂多变,建筑物密集、视线遮挡严重、电磁干扰强烈、室内定位困难,现有仿真系统难以真实模拟这些复杂条件
基于国产化软硬件平台构建,实现核心仿真环境全面自主可控;数字孪生模型库包含人物、装备、武器、工事、建筑五类模型,支持实装传感器数据动态校准,保证仿真与真实装备高度一致;通过对AFSIM仿真框架进行插件抽离与轻量化重构,保留高保真仿真能力并实现跨平台迁移,支持热插拔与故障隔离;跨平台集成开发环境统一管理脚本、插件、接口、异构硬件及通信库,易于新增模型与算法;三维视景渲染模块基于GIS快速构建城市环境,实现实体与环境的精准空间匹配;作战效能评估模块集成弹道、毁伤与综合评估模型,自动输出交换比、任务完成率等量化指标;室内定位模块融合UWB、Wi-Fi、IMU及视觉SLAM,采用扩展卡尔曼滤波解决室内遮挡与信号衰减问题,填补城市室内作战仿真定位空白;系统支持无人机、无人车与作战人员联合推演,适用于复杂城市环境下的有人/无人协同对抗训练。
Smart Images

Figure CN122926728A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of combat simulation and artificial intelligence technology, and in particular to an unmanned urban combat system. Background Technology
[0002] With the widespread application of unmanned combat platforms in modern warfare, manned / unmanned collaborative training in urban warfare environments has become a key focus and challenge in military training. Existing technologies mainly suffer from the following problems:
[0003] First, the urban combat environment is complex and ever-changing, with dense buildings, severe line of sight obstruction, strong electromagnetic interference, and difficulties in indoor positioning. Existing simulation systems are unable to realistically simulate these complex conditions.
[0004] Second, live-action drills are costly and difficult to repeat, while pure virtual simulation systems lack sufficient physical credibility and sensor realism, thus limiting training effectiveness.
[0005] Third, the existing system lacks sufficient positioning support for indoor combat environments and cannot meet the high-precision positioning requirements for urban warfare, such as street fighting and counter-terrorism operations.
[0006] Therefore, there is an urgent need for a combat system that can integrate domestically produced environments, high-fidelity simulation, indoor positioning, and manned / unmanned collaborative capabilities. Summary of the Invention
[0007] This invention addresses the technical problems existing in the background art by proposing an unmanned urban combat system.
[0008] To solve the technical problem, the technical solution of the present invention is as follows: An unmanned urban combat system, the system comprising: A digital twin model library for outputting model data of characters, equipment, weapons, fortifications, and buildings; An integrated simulation framework loads model data from the digital twin model library, receives location data sent by the indoor positioning module to update the combat unit status, performs simulation simulations, generates battlefield situation data, and generates engagement event data when engagement events occur. The combat effectiveness evaluation module receives the combat event data sent by the integrated simulation framework, calculates and outputs combat effectiveness indicators to the three-dimensional visual rendering module and / or cross-platform integrated development environment. An indoor positioning module is used to generate high-precision position data of combat units in an indoor environment, and send the position data to the integrated simulation framework and the three-dimensional visual rendering module respectively. The three-dimensional visual rendering module receives battlefield situation data from the integrated simulation framework, location data from the indoor positioning module, model data from the digital twin model library, and combat effectiveness indicators from the combat effectiveness evaluation module, and renders and visualizes the battlefield scene and effectiveness data in real time. The cross-platform integrated development environment establishes data connections with the digital twin model library, integrated simulation framework, combat effectiveness evaluation module, indoor positioning module, and 3D visual rendering module, which are used to schedule the operation of each module and manage data interaction between modules.
[0009] Furthermore, the system also includes: The domestically developed basic operating environment is configured to be built on a domestically developed operating system and a domestically developed intelligent processing platform. It uses cross-platform middleware to port and adapt software and hardware modules. The domestically developed basic operating environment is located at the bottom layer of the system and includes a hardware adaptation layer, an operating system abstraction layer, and cross-platform middleware. It is used to provide underlying support for the digital twin model library, integrated simulation framework, combat effectiveness evaluation module, indoor positioning module, 3D visual rendering module, and cross-platform integrated development environment, as well as to facilitate data exchange between heterogeneous hardware.
[0010] Furthermore, the digital twin model library dynamically adjusts the model based on multi-source data fusion and model updates, and calibrates the model parameters in real time using actual sensor data to ensure a high degree of consistency between the simulation model and the real equipment; the model data output by the digital twin model library includes character models, equipment models, weapon models, fortification models, and building models.
[0011] Furthermore, the integrated simulation framework is formed by secondary development and plugin extraction and reconstruction of the AFSIM simulation framework on a domestic platform, wherein: The integrated simulation framework retains the native class hierarchy and event scheduling mechanism of AFSIM, and extracts and encapsulates simulation business plugins to form a lightweight and scalable simulation engine; the simulation business plugins are divided into independent functional units according to the business domain, and encapsulate standard interfaces for timing synchronization, data interaction and lifecycle management. The integrated simulation framework also includes a plugin registry center, a dynamic loading engine, and a fault circuit interruption mechanism for the scanning, verification, loading, isolation, and unloading of plugins. During simulation execution, the integrated simulation framework promotes state updates and event processing through clock synchronization, timing scheduling, data bus and log fault tolerance capabilities, and invokes communication network modeling, electronic warfare modeling and battlefield environment modeling capabilities through general scripts.
[0012] Furthermore, the indoor positioning module generates high-precision location data based on a multi-source sensor fusion method, wherein: The multi-source sensors include UWB, Wi-Fi, IMU, and visual SLAM; The indoor positioning module uses extended Kalman filtering or unscented Kalman filtering algorithms to dynamically adjust the fusion weights of each sensor according to the characteristics of the indoor environment. When the combat unit enters the indoor environment, the indoor positioning module is activated, outputting centimeter-level accurate position data, and sending the position data to the integrated simulation framework and the three-dimensional visual rendering module respectively.
[0013] Furthermore, the 3D visual rendering module specifically includes: Large-scale 3D city scenes are constructed based on GIS data and rapid feature modeling methods, and spatial matching, geographic alignment and collision detection of people, equipment, weapons, buildings and fortifications are completed. It supports rendering in multiple modes, including global view, first-person view, and drone view, and presents the battlefield situation, combat effects, and location information in real time.
[0014] Furthermore, the combat effectiveness evaluation module integrates a ballistic model, a damage model, and a comprehensive evaluation model; After receiving the engagement event data sent by the integrated simulation framework, the combat effectiveness evaluation module sequentially performs weapon ballistic calculation and target damage calculation, and generates combat effectiveness indicators including exchange ratio, mission completion rate, and ammunition consumption. The combat effectiveness evaluation module outputs the generated combat effectiveness indicators to the three-dimensional visual rendering module for visualization, or outputs them to the cross-platform integrated development environment for training evaluation and scheme optimization.
[0015] Furthermore, the cross-platform integrated development environment includes: The script management module provides the ability to edit simulation scripts; The plugin management module is used for the dynamic loading, upgrading, and uninstallation of simulation business plugins; The interface data management module is used to define the data interaction format and protocol between various modules; Heterogeneous platform management module, used for cross-hardware resource scheduling; The communication model module is used for real-time data distribution; The dependency library linking library management module is used to provide library dependency resolution; The cross-platform integrated development environment schedules the operation of the digital twin model library, integrated simulation framework, combat effectiveness evaluation module, indoor positioning module, and 3D visual rendering module, and uniformly manages the data interaction and communication between the modules.
[0016] This application has the following advantages: Built on a domestically developed software and hardware platform, the system achieves complete independent control over the core simulation environment. The digital twin model library includes five categories of models: personnel, equipment, weapons, fortifications, and buildings. It supports dynamic calibration of real-world sensor data, ensuring a high degree of consistency between simulation and real equipment. By extracting and lightweighting the AFSIM simulation framework, it retains high-fidelity simulation capabilities and enables cross-platform migration, supporting hot-swapping and fault isolation. A cross-platform integrated development environment unifies the management of scripts, plugins, interfaces, heterogeneous hardware, and communication libraries, facilitating the addition of new models and algorithms. The 3D visual rendering module rapidly constructs urban environments based on GIS, achieving precise spatial matching between entities and the environment. The combat effectiveness evaluation module integrates ballistics, damage, and comprehensive evaluation models, automatically outputting quantitative indicators such as exchange ratio and mission completion rate. The indoor positioning module integrates UWB, Wi-Fi, IMU, and visual SLAM, employing extended Kalman filtering to address indoor occlusion and signal attenuation issues, filling the gap in urban indoor combat simulation positioning. The system supports joint simulations involving UAVs, unmanned vehicles, and combat personnel, making it suitable for manned / unmanned collaborative combat training in complex urban environments. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a schematic diagram of the overall system architecture; Figure 2 A schematic diagram of the module structure for a cross-platform integrated development environment; Figure 3 A schematic diagram illustrating the extraction and reconstruction of the AFSIM integrated simulation framework plugin; Figure 4 Flowchart of the anti-simulation method. Detailed Implementation
[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0020] Example 1: This embodiment provides an unmanned urban combat system, according to... Figure 1The architecture shown consists of the following seven modules. All modules communicate using a unified data distribution service protocol, with the topic naming convention being / sys / <module name> / <data type>, and the quality of service configured for reliable transmission and a history depth of 10.
[0021] 1. Domestically produced basic operating environment; Hardware platform: Huawei Ascend 310 smart station is selected as the edge computing node, or Phytium FT-2000 / 4 CPU + Kylin system is selected as the simulation server.
[0022] Operating systems: Galaxy Kylin V10 or UnionTech UOS V20, both of which have passed security and reliability assessments.
[0023] Cross-platform middleware: Based on the QPA abstraction layer of Qt 5.15, it encapsulates the hardware adaptation layer and provides unified interfaces for file system, network stack, thread scheduling, and memory management. For the Ascend NPU, it encapsulates the AscendCL C++ library to enable cross-platform calls for inference tasks.
[0024] Hardware Abstraction Layer Interface: cpp class IHardwareAdapter { public: virtual bool initDevice(DeviceType type) = 0; virtual void allocMemory(size_t size, MemAlign align) = 0; virtual bool transferData(void dst, void src, size_t len, Directiondir) = 0; }; Resource initialization process: After the system starts, the middleware scans the PCIe, USB and other buses in sequence, loads the preset drivers, creates a shared memory pool, and starts the DDS global domain participants.
[0025] 2. Digital twin model library; Model classification and format: Character model: FBX format, including LOD0, LOD1, and LOD2, skeletal rigging, supporting 34 joint movements.
[0026] Equipment models: including unmanned vehicles, drones, tanks, etc., with parametric dynamic descriptions.
[0027] Weapon model: ballistic coefficient, initial velocity, rate of fire, dispersion circle radius, etc. are stored in an SQLite database.
[0028] Fortification models: bunkers, bunkers, roadblocks, with collision-body meshes.
[0029] Architectural model: CityGML format, LOD1, LOD2, LOD3.
[0030] Dynamic calibration mechanism: Data access: Subscribe to CAN bus data of the actual equipment via MQTT protocol, including GPS / BeiDou position, attitude angle, motor current, etc.
[0031] Kalman filter calibration: Key parameters of the model are identified online using an extended Kalman filter, with an update cycle of 5 minutes.
[0032] Consistency verification: Automatic recalibration is triggered when the root mean square error between the model output and the actual data exceeds a threshold.
[0033] 3. Integrated simulation framework (AFSIM refactoring); Refactoring baseline: AFSIM version 2.9, original code approximately 1.2 million lines. After refactoring, the core base is approximately 450,000 lines, and the plugins total approximately 750,000 lines.
[0034] Retained native capabilities: Class hierarchy: SimObject -> Platform / Weapon / Sensor.
[0035] Event scheduling mechanism: event queue based on min-heap, with configurable time step.
[0036] The list of separated business plugins, totaling 23 plugins, is shown in Table 1: Table 1 - List of Separated Business Components
[0037] Plugin registry configuration: Each subfolder under the plugin directory . / plugins must contain a manifest.json file. Example: json { "name": "WeaponPlugin", "version": "2.0.1", "dependencies": ["PlatformPlugin>=2.0"], "entry_point": "libWeaponPlugin.so", "init_timeout_ms": 5000 } 4. Cross-platform integrated development environment; like Figure 2 As shown, the development framework is Electron 22 + Node.js 18, the front end uses React 18, and the back end service uses the C++ Node-API plugin.
[0038] Implementation details of the six sub-modules: Script management module: Integrates the Monaco editor, supporting syntax highlighting and auto-completion for Lua 5.4 and Python 3.9. Scripts are loaded into the simulation engine's Lua state machine via luaL_loadstring.
[0039] Plugin Management Module: The graphical interface displays a list of loaded plugins and supports drag-and-drop installation, enabling / disabling.
[0040] Interface Data Management Module: Uses Protobuf v3 to define all data messages and automatically generates C++ / Python binding code.
[0041] Heterogeneous platform management module: Distributes simulation tasks via SSH and RoCE v2 protocols, and supports dynamic discovery of new nodes.
[0042] Communication Model Module: Includes three built-in templates: TCP, UDP, and DDS. Users can design communication topology diagrams by dragging and dropping, and the corresponding QoS configuration files are automatically generated.
[0043] Dependency management module: Parses CMakeLists.txt or requirements.txt and automatically downloads pre-compiled libraries for the corresponding architecture from the private Artifactory repository.
[0044] 5. 3D visual rendering module; GIS data sources: Gaode Map API, SRTM 30m resolution elevation data, and OpenStreetMap road data.
[0045] Rapid modeling process: Obtain vector data for the target region.
[0046] LOD1 building blocks are generated using the CityEngine rule package, and textures are automatically mapped using satellite images.
[0047] Import Unreal Engine 5.1, generate terrain using the Landscape tool, and add instantiated meshes such as vegetation and streetlights.
[0048] Spatial matching and collision detection: Geographic alignment: Use the Proj4 library to convert WGS84 coordinates to UE world coordinates, with the origin at the center of the region.
[0049] Collision detection: The UE's built-in UWorld::LineTraceSingleByChannel is used, with channels ECC_GameTraceChannel1 and ECC_GameTraceChannel2.
[0050] Multi-mode rendering: Global view: static camera, line of sight 2km, using dynamic LOD.
[0051] First-person perspective: Attached to a single soldier or vehicle, with head shaking effect.
[0052] Drone perspective: Simulates DJI M300 gimbal control, with switchable visible light / infrared thermal imaging.
[0053] 6. Combat effectiveness assessment module; Ballistic model: An improved point mass trajectory, considering air density, Magnus force, and Coriolis force. The differential equations are solved using the fourth-order Runge-Kutta method with a step size of 1 ms.
[0054] Damage model: Based on the penetration formula of JMEM, the remaining kinetic energy and kill probability are calculated for concrete walls, armor plates and human tissue respectively.
[0055] Comprehensive evaluation model: The weighted TOPSIS method is adopted, and the indicators are shown in Table 2; Table 2 - Indicator and Weight Allocation Table
[0056] Output interface: Generate a JSON report after each battle and publish it through the DDS topic / sys / assessment / report.
[0057] 7. Indoor positioning module; Sensor configuration:
[0058] Fusion algorithm: Adaptive Extended Kalman Filter. The state vector is:
[0059] The state vector has 16 dimensions, and the measurement vector... The state transition matrix is dynamically adjusted based on available sensors. Quaternion kinematic equations are used.
[0060] Measurement noise covariance matrix Based on signal quality adaptation: when the number of UWB nodes is ≥3 When the Wi-Fi matching score is >0.8, When the visual SLAM reprojection error is greater than 2 pixels, its noise is increased.
[0061] Output: Smoothed position, velocity, and attitude, sent to the data bus via serial port or UDP at a frequency of 100Hz.
[0062] Through the detailed configuration described above, a fully deployable, unmanned urban combat system with complete parameters has been constructed.
[0063] Example 2: like Figure 2 As shown, this embodiment details the plugin extraction and reconstruction process of the AFSIM integrated simulation framework, such as... Figure 3 As shown. The reconstruction follows three stages: "modular decoupling → interface standardization → dynamic governance", ultimately forming a layered architecture of a lightweight core base + hot-swappable plug-in layer.
[0064] 2.1 Stripping away business logic code (Phase 1); In the original AFSIM 2.9, the simulation business logic directly inherited from SimObject and was embedded in the main program's event loop. The refactoring steps are as follows: Domain segmentation: Seven business domains were identified: Platform, Weapons, Sensors, Communications, Electronic Warfare, Environment, and Mission.
[0065] Extract common interfaces: Define standardized plugin interfaces (C++ pure virtual classes) for each domain: cpp class IPlugin { public: virtual ~IPlugin() = default; virtual bool init(const PluginContext&ctx) = 0; virtual bool update(double deltaTime) = 0; virtual bool onEvent(const Event&e) = 0; virtual void shutdown() = 0; virtual PluginInfo getInfo() const = 0; }; Code migration: Move the .cpp files for each domain to a separate directory and encapsulate them as factory functions for a dynamic library. cpp extern "C" IPlugin createPlugin() { return new WeaponPlugin();} extern "C" void destroyPlugin(IPlugin p) { delete p;} 2.2 Lightweight Refactoring of the Main Program (Phase Two); The refactored main program retains only the following core functional modules, and the number of lines of code has been reduced from 800,000 to 120,000, as shown in Table 3. Table 3 - Function Table of the Reconstructed Main Program
[0066] 2.3 Building a plug-in middleware layer (Phase 3); Plugin Registry: Upon startup, it scans all subfolders under the plugins / directory, reads manifest.json, builds a dependency graph, and checks version compatibility. If a dependency is missing or the version is incompatible, it refuses to load the plugin and logs the error.
[0067] Dynamic loading engine: It uses dlopen() to load the .so file of each plugin, obtains the createPlugin symbol via dlsym(), and then calls it to get the IPlugin. Example. Each plugin instance runs on an independent thread (std::jthread) and asynchronously waits for initialization to complete via std::promise.
[0068] Fault circuit breaker mechanism: Monitor the update() call time of each plugin. If it exceeds the threshold three times in a row, it is marked as "sub-healthy". If it exceeds 100ms, a circuit breaker is triggered.
[0069] When the circuit breaker is triggered, the plugin thread is requested to stop, the main thread sends a PluginFaultEvent, then removes the plugin from the scheduling queue and attempts to reload it (up to 3 times).
[0070] Fault isolation: Plugin crashes do not cause the main program to crash because the plugin runs in a separate process or uses a seccomp sandbox.
[0071] 2.4 Final form of layered architecture; Layer 1 (Lightweight Core Foundation): Contains no business logic, only provides basic services such as clock, scheduling, bus, logging, and configuration.
[0072] Layer 2 (Unified Bus): Based on ZeroMQ's publish / subscribe mechanism, all data interactions are conducted through Topics.
[0073] Layer 3 (Business Plug-in Layer): 23 independent plug-ins, which are hot-swappable, fault-isolated, and can be upgraded independently.
[0074] Layer 4 (Third-Party Extension Access Layer): Provides C API and Python bindings, allowing external algorithms to be accessed as plugins without modifying the kernel.
[0075] Verification results: After reconstruction, the time to load all plugins was reduced from 15 seconds to 4 seconds; adding an electronic interference plugin only requires writing 200 lines of code and placing it in the plugin directory, without recompiling the main program; after a single plugin crashes, the remaining plugins continue to run, and the system recovery time is less than 2 seconds.
[0076] Example 3: This embodiment addresses the issue of poor positioning signals in indoor environments such as buildings, underground parking lots, and tunnels during urban warfare by providing a detailed implementation of multi-source sensor fusion positioning.
[0077] 3.1 Sensor deployment and data preprocessing; UWB: Four base stations with known coordinates are deployed in a grid within the building. The mobile tag uses a Decawave DWM1001 module, and a bilateral two-way ranging protocol is used to obtain the distance to each base station. The raw distance data is smoothed using a Kalman filter to remove outliers exceeding three standard deviations.
[0078] Wi-Fi: Pre-collected offline fingerprint maps divide buildings into... A grid is used, with each grid cell recording the mean and standard deviation of the RSSI for all access points (APs). During online localization, real-time RSSI vectors are obtained through scanning, and a weighted K-nearest neighbor algorithm is used. Calculate the approximate location.
[0079] IMU: BMI160 chip, sampling rate 200Hz. Raw data is zero-bias calibrated, attitude is updated using quaternions, and velocity and position increments are obtained by integration. Zero-velocity correction is used to compensate for divergence errors in track extrapolation, detecting the stationary phase during the walking cycle.
[0080] Visual SLAM: A monocular OV5640 camera, 30fps, running a simplified version of ORB-SLAM3, retaining only monocular mode. ORB features are extracted, including Fast corner points and rBRIEF descriptors, and matched with a pre-built 3D building point cloud map to obtain 6-DOF poses. The number of feature matches... At that time, it was considered that the vision was impaired.
[0081] 3.2 Fusion Algorithm: Adaptive Unscented Kalman Filter (AUKF); Due to the high nonlinearity of the system, an unscented Kalman filter is used instead of the EKF. The algorithm steps are as follows: State vector (16 dimensions):
[0082] in: :Location ,unit ; :speed ,unit ; Quaternions This indicates a rotation from the vehicle coordinate system to the navigation coordinate system; : Gyroscope bias (three axes), unit ; Accelerometer bias (three axes), units .
[0083] State prediction (IMU driven): Using the angular velocity of the IMU and acceleration The state is updated based on the kinematic equations. The UKF Sigma point generation strategy is adopted, with a proportional correction parameter of [parameter value missing]. , , ,common Sigma points.
[0084] Measurement Update: Dynamically construct measurement vectors based on available sensors. : When the number of UWB base stations At that time, the measurement vector is The observation equation for each distance observation is defined as follows:
[0085] : Moving tag (target to be located) and the first Ranging values between UWB base stations, in units This value is acquired in real time through a bilateral two-way ranging protocol and is the raw observation data directly output by the sensor (after Kalman filtering smoothing and outlier removal).
[0086] The three-dimensional position vector of the moving label in the navigation coordinate system is represented as: ,unit This vector is precisely the state vector. The position component in the equation is also one of the core states to be estimated in Kalman filtering.
[0087] : No. The known three-dimensional coordinates of a UWB base station in the navigation coordinate system are represented as follows: ,unit The precise location of the base station is pre-marked during deployment.
[0088] The Euclidean norm is used to calculate the straight-line distance between two three-dimensional points; this observation equation establishes the position in the state vector. Compared with sensor measurement value The nonlinear relationship between them. In the measurement update step of adaptive unscented Kalman filtering, this equation is used to calculate the expected observation value corresponding to the Sigma point and compare it with the actual measurement value, thereby completing the update of state and covariance.
[0089] Measurement updates (Wi-Fi and visual SLAM); 1. Wi-Fi fingerprint positioning measurement; When the Wi-Fi fingerprint match is trusted and the nearest neighbor distance is... At that time, the measurement vector is:
[0090] in: : Two-dimensional position observation vector provided by Wi-Fi sensor.
[0091] The estimated eastward coordinates output by the Wi-Fi fingerprint matching algorithm, in units of... .
[0092] The estimated north-facing coordinates output by the Wi-Fi fingerprint matching algorithm, in units of... .
[0093] 2. Visual SLAM pose measurement; When visual SLAM is effective, the measurement vector is:
[0094] in: The six-degree-of-freedom pose observation vector provided by visual SLAM.
[0095] : Eastward coordinates output by visual SLAM, in units .
[0096] North coordinates output by visual SLAM, in units .
[0097] : The celestial coordinates output by visual SLAM, in units .
[0098] : Roll angle output by visual SLAM, rotation about the east axis, in units .
[0099] The pitch angle output by visual SLAM, and the rotation about the north axis, in units. .
[0100] : Yaw angle output by visual SLAM, rotation about the yaw axis, in units .
[0101] Adaptive noise conditioning; The measurement noise covariance matrix is adjusted in real time based on the sensor confidence level. : 1. UWB ranging noise covariance;
[0102] in: The measurement noise covariance matrix for UWB distance observation is a diagonal matrix, with the diagonal elements being the expected values of the ranging variance of each base station.
[0103] : No. Standard deviation of distance measurements to UWB base stations, in units .
[0104] : The standard deviation function of distance measurement determined by the number of effective base stations.
[0105] The number of UWB base stations that the mobile tag can effectively measure distances at the current moment. The more visible base stations, the better. The closer to The smaller the quantity, The larger the value, the lower the confidence level in the ranging value.
[0106] 2. Wi-Fi positioning noise covariance;
[0107] in: : Measurement noise variance of Wi-Fi location observations. Since Wi-Fi only provides two-dimensional planar location, this scalar variance is also applied to... and Two dimensions.
[0108] : The normalized similarity score between the RSSI vector of the online scan and the best-matching fingerprint in the fingerprint database, with values typically ranging from 0 to 10. The higher the score, The smaller the value, the higher the confidence level in the observation.
[0109] 3. Visual SLAM pose noise covariance;
[0110] in: : Measurement noise covariance matrix for visual SLAM six-DOF pose observation, which is a diagonal matrix.
[0111] The first three diagonal elements Corresponding to , , Measurement noise variance, in units This value is based on reprojection error. Under the premise of pixels.
[0112] The last three diagonal elements Corresponding to , , The standard deviation of measurement noise. This value is also based on reprojection error. Under the premise of pixels.
[0113] If reprojection error pixels, then All diagonal elements were increased to 10 times their original size to significantly reduce the weight of visual observations in the fusion.
[0114] If a sensor remains unavailable for more than 5 seconds, its measurement dimension will be temporarily removed from the state update until it is re-included in the fusion once the signal is restored.
[0115] 3.3 Coordinate system synchronized with time; The navigation coordinate system uses ENU, with the origin set at the building entrance, and GPS coordinates are used for recording.
[0116] All sensor data frames are synchronized to the global clock using the IEEE 1588 PTP protocol, with a maximum error. UWB and IMU data are aligned using interpolation.
[0117] 3.4 Positioning Output and Integration; The fused position, velocity, and attitude data are broadcast to the simulation computer on the local area network via UDP. The data packet format is as follows: protobuf message IndoorPosition { double timestamp = 1; / / Unix timestamp, microseconds float x = 2; / / meters float y = 3; float z = 4; float qw = 5; / / Quaternion float qx = 6; float qy = 7; float qz = 8; uint32_t source_mask = 9; / / bit0:UWB, bit1:WiFi, bit2:Visual, bit3:IMU } In the simulation system, when a combat unit enters an indoor area, it is triggered by the predefined building boundaries in GIS data, automatically routing the positioning request to the indoor positioning module and switching the visualization rendering to indoor map mode.
[0118] Actual test results: Tested in a typical office building (50m x 30m, three floors), the root mean square error of dynamic positioning was [value missing]. Maximum error at the corner of the staircase Heading angle error To meet the accuracy requirements of urban combat simulation .
[0119] Example 4: This embodiment uses the scenario of "Red Team reconnaissance squad cooperating with drones to raid Blue Team stronghold" as a specific example, and demonstrates in detail the entire process of the system from initialization to visualization, and provides the data flow and calculation results of key links.
[0120] like Figure 4 As shown, the scenario is described; Area: A city block, including two office buildings, Building A (6 floors) and Building B (4 floors), and a surrounding plaza. Map size: [Map dimensions not specified] .
[0121] Red Team: 1 quadcopter drone, 1 unmanned reconnaissance vehicle, and 2 soldiers equipped with assault rifles.
[0122] Blue Team: 1 sniper, hidden inside a window on the 3rd floor of Building B; 1 heavy machine gun, located on the roof of Building A.
[0123] Mission: The Red Team must scout and destroy the Blue Team's heavy machine gun within 15 minutes. Snipers are free to fire.
[0124] S1 System initialization; The domestically produced server is equipped with a Kylin V10 processor and a Phytium S2500 processor, and starts the main system process SimCore upon power-up.
[0125] The cross-platform middleware detected three connected simulation terminals and one 3D visualization workstation. The simulation terminals included a drone terminal, an unmanned vehicle terminal, and a soldier terminal, all of which were Huawei Atlas 500 boxes; the workstation was equipped with an RTX 4090 graphics card and ran UnionTech UOS.
[0126] Assign DDS domain ID 101, create a global participant, and publish the topic / sys / status / heartbeat.
[0127] The indoor positioning module is activated, and four UWB base stations inside the building are online, awaiting mobile tag registration.
[0128] S2 model loading and calibration; Load the following resources from the digital twin model library: model: / / drone / m300.fbx, dynamic parameters: maximum speed It lasts for 25 minutes.
[0129] model: / / ugv / rcv9.fbx, size It is equipped with photoelectric and infrared sensors.
[0130] The model is located at model: / / soldier / assault.fbx. The weapon is a Type 95 rifle with a ballistic coefficient of 0.3.
[0131] Building models: citygml / A_building.gml and citygml / B_building.gml.
[0132] Calibration: By reading the previous day's actual training data via MQTT, it was found that the rolling resistance coefficient of RCV-9 on actual gravel roads was 15% higher than the nominal value. Therefore, rolling_resistance = 0.12 was corrected in the model parameters.
[0133] Once loading is complete, the object IDs of all instantiated models are uniformly assigned by the model library and registered to the data bus.
[0134] S3 combat scenario loading; A scenario file named mission.lua was written using the Lua scripting language of AFSIM. The summary of its contents is as follows: lua RedTeam:addUnit("UAV", "M300", pos={35.678, 139.765, 80}) RedTeam:addUnit("UGV", "RCV9", pos={35.679, 139.764, 0}) RedTeam:addUnit("Infantry", "Soldier1", pos={35.680, 139.763, 0}) BlueTeam:addUnit("Sniper", "M24", pos={35.685, 139.770, 12}) -- 3rd floor BlueTeam:addUnit("HMG", "W85", pos={35.682, 139.768, 18}) -- Roof Environment:setTime("2025-05-20 14:00:00") Environment:setWeather("Cloudy", visibility=3000) Comms:createLink("Red_UAV_to_UGV", type="LTE", bandwidth=10) EW:addJammer("Blue_Jammer", pos={35.683,139.769,10}, power=5, freq=2400) Mission:setObjective("Red", "Destroy", "Blue_HMG", within=900) The simulation framework parses the script, instantiates red and blue cells, and creates communication links and electromagnetic interference models. After initialization, the main scheduler sets the simulation start time to the system time plus 2 seconds for synchronized visualization.
[0135] S4 simulation execution; Simulated step size Event-driven.
[0136] 0~100s: The drone takes off and ascends to an altitude of 80m for reconnaissance. The unmanned vehicle moves along the street toward Building B, with individual soldiers providing alternating cover behind the vehicle.
[0137] 100s: The drone's infrared sensor detects a heat source on the roof of Building A, namely a heavy machine gun, triggering a report event. The report is sent to the unmanned vehicle and individual soldier via the DDS topic / tactical / intel.
[0138] 120s: The unmanned vehicle enters the plaza in front of Building B. The blue team sniper spots the target through the window, triggering a combat event, but the sniper waits for instructions and does not fire immediately.
[0139] 200s: The Red team decides to act: the drone descends to 50m and launches a small missile; the unmanned vehicle releases smoke grenades for cover; the individual soldier advances from the flank.
[0140] Data bus load: Approximately 23,000 messages per second are generated during the simulation, covering location updates, sensor detections, and engagement events, with ZeroMQ latency of less than 5ms.
[0141] S5 Combat Calculation; Engagement 1: Drone versus heavy machine gun, t=205s Trajectory model calculation for drone launching air-to-ground missile: muzzle velocity Range 400m, air density .
[0142] The flight time was calculated to be 1.8 s using the Runge-Kutta method, and the radius of the impact dispersion circle (CEP) was [value missing]. .
[0143] Damage model: The missile warhead is 3kg of high-energy explosive, with an equivalent penetration radius of 3.5m against unarmored targets. The heavy machine gun model is classified as "destroyed".
[0144] Performance evaluation output: The exchange ratio is updated to 0 losses for the Red team and 1 heavy machine gun loss for the Blue team, and the mission completion rate is increased to 60%.
[0145] Engagement 2: Blue team sniper against Red team lone soldier, t=210s; The sniper's firing distance is 220m, using 7.62mm bullets. The ballistic model takes into account the effect of wind deflection due to a crosswind speed of 3m / s.
[0146] Hit probability calculation: Considering the marksman's skill level of 0.8, weapon accuracy of 0.95, target exposure time of 2 seconds, and aiming error of 0.5 mil, the final hit probability is 0.72.
[0147] Random number determination: If the probability is 0.72, it is determined to be a hit. The soldier's health is reduced to zero and the status changes to CASUALTY.
[0148] Performance evaluation: The exchange ratio changes to Red team losing 1 person and Blue team losing 0, the ratio drops to 0; the mission completion rate remains at 60%, the heavy machine gun has been destroyed, but points are deducted due to personnel losses.
[0149] In the TOPSIS calculation of the assessment module, the number of friendly fire incidents was 0, but personnel losses caused the overall score to drop from 0.82 to 0.61.
[0150] S6 Indoor Positioning; t=230s: The remaining Red team soldier decides to enter Building B to eliminate the sniper. When the soldier crosses the building entrance: The GPS signal strength dropped sharply from 80% to 10%, triggering the indoor positioning activation signal.
[0151] The UWB tag carried by the soldier measures the distance between the soldier and four base stations in the building, obtaining four distance values.
[0152] The IMU begins trajectory calculation, and the visual SLAM loads the pre-stored point cloud map of Building B, which contains approximately 50,000 feature points.
[0153] Adaptive UKF fusion: The initial position is determined by UWB with an error of 0.15m; subsequent positioning is mainly based on IMU, with visual SLAM assisting in the correction of the rotation angle.
[0154] The output position is displayed in real time in the 3D view, and the interior of the building is presented in a semi-transparent floor switching mode.
[0155] At the stairwell, at t=280s, only two base stations are visible due to wall obstruction of UWB. The system automatically reduces the UWB weight and relies on visual SLAM to match the features of the window outline to keep the positioning error less than 0.3m.
[0156] Finally, the sniper was found in the corridor on the 3rd floor. After a firefight, he was eliminated, and the positioning module recorded the last combat position.
[0157] S7 Visualization; Presented from multiple perspectives: The main window provides a global view, overlooking the entire street and displaying red and blue icons, trajectory lines, and combat effects such as explosion light effects and bullet trails.
[0158] Sub-window 1 provides the first-person view of the drone, transmits simulated video streams in real time, and generates thermal images based on sensor models.
[0159] Sub-window 2 is an indoor single-soldier perspective, using UE5 character animation driven by positioning data, and displays corridors, room doors, and enemy highlighted markers.
[0160] Performance Panel: The floating panel on the right side of the screen refreshes dynamically, displaying the following content: Current simulation time: 320s / 900s; Mission completion rate: 60%, the heavy machine gun has been destroyed, the mission is not completely over; Exchange ratio: Red team loses 1 player, Blue team loses heavy machine gunner + sniper → 1:2, Red team has the advantage; Ammunition consumption: 1 missile, 30 rifle bullets; Overall assessment score: 0.73, out of 1; Termination condition: When t=350s, the Red team completes all tasks, namely, the heavy machine gun is destroyed and the sniper is killed. The system will then automatically stop and generate a final evaluation report.
[0161] The above complete process verifies the high fidelity, seamless indoor and outdoor positioning capability, and effectiveness of quantitative evaluation of the system proposed in this invention in unmanned urban combat simulation.
[0162] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.
[0163] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. An unmanned urban combat system, characterized in that, The system includes: A digital twin model library for outputting model data of characters, equipment, weapons, fortifications, and buildings; An integrated simulation framework loads model data from the digital twin model library, receives location data sent by the indoor positioning module to update the combat unit status, performs simulation simulations, generates battlefield situation data, and generates engagement event data when engagement events occur. The combat effectiveness evaluation module receives the combat event data sent by the integrated simulation framework, calculates and outputs combat effectiveness indicators to the three-dimensional visual rendering module and / or cross-platform integrated development environment. An indoor positioning module is used to generate high-precision position data of combat units in an indoor environment, and send the position data to the integrated simulation framework and the three-dimensional visual rendering module respectively. The three-dimensional visual rendering module receives battlefield situation data from the integrated simulation framework, location data from the indoor positioning module, model data from the digital twin model library, and combat effectiveness indicators from the combat effectiveness evaluation module, and renders and visualizes the battlefield scene and effectiveness data in real time. The cross-platform integrated development environment establishes data connections with the digital twin model library, integrated simulation framework, combat effectiveness evaluation module, indoor positioning module, and 3D visual rendering module, which are used to schedule the operation of each module and manage data interaction between modules.
2. The unmanned urban combat system according to claim 1, characterized in that, The system also includes: The domestically developed basic operating environment is configured to be built on a domestically developed operating system and a domestically developed intelligent processing platform. It uses cross-platform middleware to port and adapt software and hardware modules. The domestically developed basic operating environment is located at the bottom layer of the system and includes a hardware adaptation layer, an operating system abstraction layer, and cross-platform middleware. It is used to provide underlying support for the digital twin model library, integrated simulation framework, combat effectiveness evaluation module, indoor positioning module, 3D visual rendering module, and cross-platform integrated development environment, as well as to facilitate data exchange between heterogeneous hardware.
3. The unmanned urban combat system according to claim 1, characterized in that, The digital twin model library dynamically adjusts the model based on multi-source data fusion and model updates, and calibrates the model parameters in real time using real-world sensor data to ensure a high degree of consistency between the simulation model and the real equipment. The model data output by the digital twin model library includes character models, equipment models, weapon models, fortification models, and building models.
4. The unmanned urban combat system according to claim 1, characterized in that, The integrated simulation framework is formed by secondary development and plugin extraction and reconstruction of the AFSIM simulation framework on a domestic platform, wherein: The integrated simulation framework retains the native class hierarchy and event scheduling mechanism of AFSIM, and extracts and encapsulates simulation business plugins to form a lightweight and scalable simulation engine; the simulation business plugins are divided into independent functional units according to the business domain, and encapsulate standard interfaces for timing synchronization, data interaction and lifecycle management. The integrated simulation framework also includes a plugin registry center, a dynamic loading engine, and a fault circuit interruption mechanism for the scanning, verification, loading, isolation, and unloading of plugins. During simulation execution, the integrated simulation framework promotes state updates and event processing through clock synchronization, timing scheduling, data bus and log fault tolerance capabilities, and invokes communication network modeling, electronic warfare modeling and battlefield environment modeling capabilities through general scripts.
5. The unmanned urban combat system according to claim 1, characterized in that, The indoor positioning module generates high-precision location data based on a multi-source sensor fusion method, wherein: The multi-source sensors include UWB, Wi-Fi, IMU, and visual SLAM; The indoor positioning module uses extended Kalman filtering or unscented Kalman filtering algorithms to dynamically adjust the fusion weights of each sensor according to the characteristics of the indoor environment. When the combat unit enters the indoor environment, the indoor positioning module is activated, outputting centimeter-level accurate position data, and sending the position data to the integrated simulation framework and the three-dimensional visual rendering module respectively.
6. The unmanned urban combat system according to claim 1, characterized in that, The 3D visual rendering module specifically includes: Large-scale 3D city scenes are constructed based on GIS data and rapid feature modeling methods, and spatial matching, geographic alignment and collision detection of people, equipment, weapons, buildings and fortifications are completed. It supports rendering in multiple modes, including global view, first-person view, and drone view, and presents the battlefield situation, combat effects, and location information in real time.
7. The unmanned urban combat system according to claim 1, characterized in that, The combat effectiveness evaluation module integrates a ballistic model, a damage model, and a comprehensive evaluation model. After receiving the engagement event data sent by the integrated simulation framework, the combat effectiveness evaluation module sequentially performs weapon ballistic calculation and target damage calculation, and generates combat effectiveness indicators including exchange ratio, mission completion rate, and ammunition consumption. The combat effectiveness evaluation module outputs the generated combat effectiveness indicators to the three-dimensional visual rendering module for visualization, or outputs them to the cross-platform integrated development environment for training evaluation and scheme optimization.
8. The unmanned urban combat system according to claim 1, characterized in that, The cross-platform integrated development environment includes: The script management module provides the ability to edit simulation scripts; The plugin management module is used for the dynamic loading, upgrading, and uninstallation of simulation business plugins; The interface data management module is used to define the data interaction format and protocol between various modules; Heterogeneous platform management module, used for cross-hardware resource scheduling; The communication model module is used for real-time data distribution; The dependency library linking library management module is used to provide library dependency resolution; The cross-platform integrated development environment schedules the operation of the digital twin model library, integrated simulation framework, combat effectiveness evaluation module, indoor positioning module, and 3D visual rendering module, and uniformly manages the data interaction and communication between the modules.