Location-based entertainment mega-space multi-project system and data processing method

Abstract

The application discloses a kind of entertainment large space multi-project systems and data processing method based on position, the system includes: map sharing module, for storing uniform format venue map data, venue map data is generated based on unified space reference, and be shared by multiple location-based entertainment (LBE) project module;Logical origin adaptation module is set in LBE project module, for mapping the logical coordinate system of LBE project module to the venue coordinate system of venue map data according to the adaptation parameter of preestablished;Coordinate conversion optimization module is respectively connected with client and server side communication, for transmitting position information based on venue coordinate system;Platform deployment adaptation module is connected with map sharing module and external management platform respectively, for converting venue map data into the format compatible with external management platform and deploying.It is realized to reduce system development and operation cost and computing resource consumption, while improving user experience and deployment efficiency under the cooperation of multiple projects.

Description

Technical Field

[0001] This invention relates to the field of virtual reality technology, and in particular to a location-based entertainment large-space multi-project system and data processing method. Background Technology

[0002] Location-Based Entertainment (LBE) large-space experiences are an important application scenario for virtual reality and augmented reality technologies. Its core lies in allowing users to move freely within a real physical space and interact with virtual content. Under the existing multi-project operation model of LBE large spaces, each independent intellectual property (IP) content project typically requires separate mapping and construction of the physical site. Due to the lack of a unified site spatial benchmark and data sharing mechanism, the map data generated by each project are independent and incompatible in terms of coordinate system origin, positive direction definition, and storage format. This results in map data for the same physical site being unusable across different projects, leading to a significant amount of redundant scanning work and wasted time.

[0003] More importantly, this fragmented map-building approach leads to a lack of unified spatial coordinate systems. When users switch between different projects or interact across projects within the same venue, the system must perform complex matrix transformations to convert the player's location information from the independent coordinate systems of different projects to a unified physical spatial coordinate system to achieve location matching and interaction synchronization. This process not only significantly increases the computational load on both the client and server, reducing system efficiency, but also introduces additional latency due to dynamically loading independent map data and real-time matrix operations, easily causing screen stuttering or positioning drift, severely disrupting the user's immersive experience. Furthermore, because existing map data formats are incompatible with the batch deployment specifications of mainstream enterprise-level device management platforms (such as Pico Enterprise Device Management Platform), operators often cannot utilize the platform's automation capabilities for map distribution and must rely on manual management of map files and project correspondences across multiple devices, making the deployment and maintenance process for large-scale projects extremely cumbersome and error-prone. Therefore, there is an urgent need for a large-scale, multi-project collaborative system and method that can unify the venue's spatial benchmark, achieve efficient map data sharing, eliminate complex coordinate matrix transformations, and support platform-based automated deployment. Summary of the Invention

[0004] In view of this, this invention proposes a location-based entertainment large-space multi-project system and data processing method, which can reduce system development and maintenance costs and computing resource consumption, while improving user experience and deployment efficiency in multi-project collaboration. This invention provides the following technical solution: A location-based entertainment space with multiple attractions, the system comprising: The map sharing module is used to store site map data in a unified format. The site map data is generated based on a unified spatial reference and is shared by multiple location-based entertainment (LBE) project modules. The logical origin adaptation module, set in the LBE project module, is used to map the logical coordinate system of the LBE project module to the site coordinate system of the site map data according to preset adaptation parameters. The coordinate transformation optimization module communicates with both the client and the server, and is used to transmit location information based on the site coordinate system. The platform deployment adaptation module is connected to the map sharing module and the external management platform respectively, and is used to convert the site map data into a format compatible with the external management platform and deploy it.

[0005] Optionally, the spatial reference includes a uniformly defined site origin and site positive direction; The origin of the site is the geometric center of the physical site; The positive direction of the site is the direction from the origin of the site toward the shorter right side of the physical site. The site map data adopts a hierarchical storage structure, including a file header area, an enhanced data header area, a core map data area, and a file tail area; The enhanced data header area is stored in plaintext and is used to store the calibration information of the site origin and the positive direction of the site. The core map data area is encrypted and used to store SLAM feature point data and semantic label data.

[0006] Optionally, the adaptation parameters include the global origin coordinates of the site, the rotation offset angle around the vertical axis, the scene scaling factor, and the origin offset compensation component. The logical origin adaptation module is specifically used to map the logical coordinates in the logical coordinate system of the LBE project module to the site coordinates in the site coordinate system of the site map data based on the adaptation parameters and using a calculation method that combines linear operation with trigonometric function compensation. The calculation method involves linearly combining the trigonometric function value of the rotation offset angle with the logical coordinates, and then superimposing the global origin coordinates of the site and the origin offset compensation component to obtain the site coordinates.

[0007] Optionally, the coordinate transformation optimization module is configured as follows: Receive native device location and attitude data collected by the client; The device's native position and attitude data are encapsulated according to a preset standard data format and then transmitted to the server. The server performs spatial calibration on the received data based on the site origin anchor point and relative offset, and performs linear superposition calculation during the calibration process; Furthermore, the control commands generated by the server are sent to the client in accordance with the standard data format. The control commands carry native local data so that the client can directly parse and execute them.

[0008] Optionally, the platform deployment adaptation module is configured as follows: Metadata is extracted from the site map data, and a configuration file is generated according to the specifications of the external management platform; The site map data and the configuration file are packaged together to generate a compressed file, and a request signature for authentication is generated. The system calls the authentication interface of the external management platform to obtain an access token, and uploads the compressed file in chunks to the external management platform through the upload interface. After the upload is completed, the system calls the device group management interface to associate the uploaded map task with the target device group. Additionally, it calls the deployment interface to send deployment instructions to the associated target device group and queries the deployment status to verify the deployment results.

[0009] Optionally, the site map data is generated using an optimized SLAM algorithm, which includes: The weak texture feature enhancement step is used to reduce the extreme value detection threshold in weak texture regions to supplement feature points; The dynamic object filtering step is used to fuse depth data and IMU motion detection data to remove dynamic feature points whose movement speed exceeds a preset threshold. Additionally, a multi-sensor fusion optimization step is used to adjust the fusion weights of visual data and IMU data under different motion scenarios.

[0010] This embodiment further discloses a location-based method for processing multi-item data in large entertainment spaces, including: The system stores site map data in a unified format, which is generated based on a unified spatial reference and shared by multiple location-based entertainment (LBE) project modules. The logical coordinate system of the LBE project module is mapped to the site coordinate system of the site map data according to the preset adaptation parameters. Transmit location information based on the site coordinate system; The site map data is converted into a format compatible with the external management platform and then deployed.

[0011] Optionally, the spatial reference includes a uniformly defined site origin and site positive direction; The origin of the site is the geometric center of the physical site; The positive direction of the site is the direction from the origin of the site toward the shorter right side of the physical site. The site map data adopts a hierarchical storage structure, including a file header area, an enhanced data header area, a core map data area, and a file tail area; The enhanced data header area is stored in plaintext and is used to store the calibration information of the site origin and the positive direction of the site. The core map data area is encrypted and used to store SLAM feature point data and semantic label data.

[0012] Optionally, the adaptation parameters include the global origin coordinates of the site, the rotation offset angle around the vertical axis, the scene scaling factor, and the origin offset compensation component. The logical origin adaptation module is specifically used to map the logical coordinates in the logical coordinate system of the LBE project module to the site coordinates in the site coordinate system of the site map data based on the adaptation parameters and using a calculation method that combines linear operation with trigonometric function compensation. The calculation method involves linearly combining the trigonometric function value of the rotation offset angle with the logical coordinates, and then superimposing the global origin coordinates of the site and the origin offset compensation component to obtain the site coordinates.

[0013] Optionally, converting the site map data into a format compatible with the external management platform and deploying it includes: Metadata is extracted from the site map data, and a configuration file is generated according to the specifications of the external management platform; The site map data and the configuration file are packaged together to generate a compressed file, and a request signature for authentication is generated. The system calls the authentication interface of the external management platform to obtain an access token, and uploads the compressed file in chunks to the external management platform through the upload interface. After the upload is completed, the system calls the device group management interface to associate the uploaded map task with the target device group. Additionally, it calls the deployment interface to send deployment instructions to the associated target device group and queries the deployment status to verify the deployment results.

[0014] According to the technical solution of the present invention, a large-space multi-project system comprising a map sharing module, a logical origin adaptation module, a coordinate transformation optimization module, and a platform deployment adaptation module is constructed. This system utilizes a unified spatial benchmark to generate and store site map data that can be shared by multiple LBE projects, avoiding resource waste and experience interruptions caused by repeated scanning and dynamic loading. Simultaneously, the logical origin adaptation module accurately maps the independent logical coordinate systems of each project to a unified site coordinate system using preset parameters. The coordinate transformation optimization module then directly transmits native location information based on this unified coordinate system, avoiding the cumbersome matrix transformation calculations of traditional solutions and significantly reducing the computational load and communication latency of the client and server. Furthermore, the platform deployment adaptation module automatically converts the unified map data into an external management platform-compatible format and completes batch deployment, replacing manual management processes. This achieves efficient reuse and secure sharing of map data while significantly improving system operating efficiency, user immersive experience, and the convenience of large-scale operational deployment under multi-project collaboration. Attached Figure Description

[0015] For illustrative and not limiting purposes, the present invention will now be described in conjunction with embodiments and accompanying drawings, wherein: Figure 1 This is a schematic diagram of the constituent modules of a location-based entertainment large-space multi-item system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the location-based entertainment space multi-item data processing method in an embodiment of the present invention. Figure 3 This is a schematic diagram of the structure of the electronic device in an embodiment of the present invention. Detailed Implementation

[0016] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0017] It should be noted that, where there is no conflict, the embodiments and features of the embodiments in this application can be combined with each other. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0018] refer to Figure 1This embodiment discloses a location-based entertainment large-space multi-project system. The system includes a map sharing module 11, a logical origin adaptation module 12, a coordinate transformation optimization module 13, and a platform deployment adaptation module 14. The modules are connected through a communication network or internal bus and work together to achieve map reuse, coordinate adaptation, data transmission optimization, and platform deployment for multi-IP projects in large-space scenarios. The following is a detailed description: The map sharing module 11 is used to store site map data in a unified format. The site map data is generated based on a unified spatial reference and is shared by multiple location-based entertainment (LBE) project modules.

[0019] In this embodiment, the map sharing module 11 relies on a specific scanning terminal to generate high-precision site map data. For example, a Pico4 Ultra Enterprise Edition device is used as the core scanning terminal. This device is equipped with a depth camera (resolution 2160×2160×2, frame rate 60fps) and an IMU (sampling rate 100Hz) to ensure the accuracy of spatial feature point acquisition.

[0020] To address the issues of location loss in weak texture areas and interference from dynamic objects in existing technologies, the map sharing module 11 performs secondary optimization based on the Pico native SLAM (Simultaneous Localization and Mapping) algorithm when generating site map data. Specific optimization measures include: (1) Feature point extraction and matching optimization To address the issues of low feature point density (<5 points / m²) and dynamic object interference in weakly textured regions, the native SLAM algorithm adopts the following measures: Weak texture feature enhancement: The scale-space extremum detection logic of the SIFT algorithm is introduced to replace the native ORB feature extraction. The extremum detection threshold is reduced by 50% in the low-scale layer of the DoG pyramid (σ=0.5 / 1.0), and feature points in weak texture regions are forcibly supplemented. In the instance verification, the feature point density in weak texture regions is increased from 5 / ㎡ to 15 / ㎡.

[0021] Dynamic object filtering: By fusing distance data from depth cameras and motion detection data from IMUs, a static background model is constructed to remove dynamic feature points with a moving speed exceeding a preset threshold (e.g., 0.5 m / s) in real time, with a dynamic feature point removal rate of more than 90%.

[0022] Adaptive matching threshold: To address the issue of poor adaptability caused by a fixed matching threshold, the threshold is relaxed to 0.8 in weak texture regions (gradient variance < 0.1) and kept at 0.75 in strong texture regions, thereby increasing the feature point matching success rate from 65% to 90%.

[0023] (2) Pose estimation and drift suppression optimization To address the issues of large cumulative pose drift error (>5cm) and pose jitter during long-distance scanning in large spaces (>10m), this implementation method adopts the following measures: Multi-sensor fusion optimization: Adjust the fusion weights of visual data and IMU data under different motion scenarios. Specifically, in translation scenarios, the visual weight is adjusted to 0.8 (originally 0.6), and in rotation scenarios, the IMU weight is adjusted to 0.7 (originally 0.5), thereby reducing the pose jitter amplitude from ±1.5° to ±0.5°.

[0024] Enhanced closed-loop detection: Added site markers to assist in closed-loop detection. Preset visual markers (AR QR codes) at key locations on the site (origin / boundary). When a marker is scanned, the pose is forcibly calibrated and the drift error is reset.

[0025] Sliding window optimization: The original 5-frame sliding window is expanded to 8 frames, increasing the temporal dimension constraint of pose estimation, reducing the impact of single-frame error, and reducing the cumulative drift error of large-space scanning from 5cm to less than 2cm.

[0026] (3) Map construction and fusion optimization To address the issues of large point cloud registration errors (>3cm) and the lack of semantic information in native maps during multi-device collaborative scanning, this implementation method adopts the following measures: Point cloud registration optimization: The RANSAC algorithm is used to replace the original least squares method for multi-device point cloud registration, increasing the number of iterations from 100 to 200, and controlling the registration error within 2cm.

[0027] Semantic map extension: Based on the original feature point map, a semantic label layer (wall / ground / pillar / boundary) is added. The scanned point cloud is classified through a deep learning model (lightweight CNN) and the site boundary is automatically labeled. The semantic boundary recognition accuracy is greater than 95%.

[0028] Map compression and storage: Redundant point clouds are downsampled to retain key feature points, reducing map file size by 40%, while being compatible with Pico platform .pmap format and other platform file formats, improving map loading speed by 30%.

[0029] (4) Real-time performance and hardware adaptation optimization To address the issues of the native algorithm's single-frame processing time exceeding 80ms and its underutilization of hardware computing power, this embodiment adopts the following measures: Computing power scheduling optimization: For example, operator-level optimization is performed on the Pico4 Ultra's XR2Gen2 chip, and the feature extraction and matching process adopts GPU parallel computing to replace the native CPU serial computing.

[0030] Depth data reuse: Incorporate distance data from depth cameras into feature point filtering in advance, remove invalid feature points with a distance >10m, and reduce subsequent computation.

[0031] Adaptive frame rate: When the scanning scene is complex (feature points > 1000 / frame), the precision of non-core computing steps is automatically reduced to ensure that the frame rate is stable at 60fps, and the processing time per frame is reduced from 80ms to 55ms.

[0032] Furthermore, to ensure the consistency of site map data shared by all LBE project modules, the site map data generated by the map sharing module 11 is based on a unified spatial reference. This spatial reference includes a uniformly set site origin and positive site direction.

[0033] The origin of the site is set based on the geometric center of the physical site, and its precise coordinates are determined through calibration using a laser rangefinder. For rectangular sites, the origin coordinates are calculated using the following formulas: Origin X = (Start point X of the longest side + End point X of the longest side) / 2, Origin Z = (Start point Z of the shortest side + End point Z of the shortest side) / 2, and Origin Y = Site elevation (default setting is 0m). For irregular sites, the origin is determined using the polygon centroid calculation method to ensure that the origin is located in the core area of ​​the site. The positive direction of the site is uniformly set as the Z-axis positive direction, pointing from the origin towards the short right side of the site, determined through a combination of compass calibration and a laser pointer, with the direction deviation controlled within 0.5°. After setting, the origin and positive direction markers are marked on the site surface as visual references during scanning. The unified coordinate system is defined as using the Unity standard left-handed coordinate system. Wherein, the X-axis is horizontal to the right as the positive direction, in meters (m); the Y-axis is vertical upward as the positive direction, in meters (m), with the ground surface as the Y=0 reference plane; the Z-axis is forward as the positive direction (i.e., the set positive direction of the site), in meters (m). All coordinate values ​​are rounded to two decimal places to ensure that the spatial positioning accuracy error is ≤5cm.

[0034] Finally, the site map data stored in the map sharing module 11 adopts a hierarchical storage structure, including a file header area, an enhanced data header area, a core map data area, a metadata area, and a file tail area. The specific structure is as follows: (1) File header area (16 bytes): contains magic number (4 bytes, 0x504D4150, i.e. "PMAP"), version number (2 bytes, 0x0100), scanning device identifier (2 bytes) and reserved fields (8 bytes). The first 4 bytes of the reserved fields are used to store the AES encrypted IV vector.

[0035] (2) Enhanced Data Header Area (48 bytes, plaintext storage): Used to store the calibration information of the site origin and positive direction for easy reading. Specifically, it includes the site index number (VenueIndex, 4 bytes), map offset (MapOffset, 12 bytes), site origin coordinates (WorldOriginPosition, 12 bytes), and site positive direction rotation parameters (WorldOriginRotation, 16 bytes, Quaternion type).

[0036] (3) Core Map Data Area (AES-256-CBC Encrypted Storage): Used to store SLAM feature point data and semantic label data. Specifically, it includes point cloud data (each point contains X / Y / Z coordinates and RGB color information), grid data (triangular grid modeling), semantic label data (such as classification labels for walls, ground, columns, etc.), and boundary information data. This area is encrypted using the AES-256-CBC algorithm. The encryption key is bound to the device serial number of the scanning device or dynamically issued by the server. The encryption initialization vector (IV) is randomly generated and stored in the file header area.

[0037] (4) Metadata area (plaintext): includes scan time (Unix timestamp), site size (Vector3 type) and data volume statistics (total number of points in point cloud data).

[0038] (5) File tail area (4 bytes): Stores CRC32 checksum, which is calculated for all bytes of the file header area, enhanced data header area, core map data area and metadata area. It is used to verify the integrity of the file during transmission and storage. If the check fails, the map will not be loaded.

[0039] Regarding storage media, the map sharing module 11 employs a distributed file server, supporting file backup and off-site disaster recovery. The map files are compressed using ZIP format, and file access utilizes the HTTP / 2 protocol, supporting resumeable downloads. Through this layered storage and encryption strategy, the map sharing module 11 achieves both visual configuration and secure storage of map data, while ensuring that multiple LBE project modules can efficiently and securely share the same site map data without requiring repeated scanning.

[0040] The logical origin adaptation module 12 is set in the LBE project module and is connected to the map sharing module 11 for data interaction. It is used to map the logical coordinate system of the LBE project module to the site coordinate system of the site map data according to the preset adaptation parameters, thereby realizing the accurate matching of virtual scenes of different IP content projects with a unified physical site.

[0041] Specifically, the logical origin adaptation module 12 defines a standardized parameter system. All parameters are independent scalars or three-dimensional vectors, with no matrix dependencies, and support dynamic configuration. The specific parameter definitions are as follows: (1) Global origin coordinates of the site O(x), O(y), O(z): Data type is Vector3, unit is meters (m). Represents the reference origin of the unified map, that is, the geometric center coordinates of the site set in the map sharing module 11. For example, for a rectangular site, O=(5.0,0.0,8.0) represents the origin X=5m, Y=0m, Z=8m.

[0042] (2) Project logical coordinate components , , The data type is Vector3, and the unit is meters (m). This represents the player's original coordinates (before conversion) within the project's virtual scene, directly collected by the LBE project module's internal engine. For example, the player's position within the project. , , .

[0043] (3) Mapped global coordinate components of the site , , The data type is Vector3, and the unit is meters (m). It represents the unified site coordinates after conversion, used for cross-project interaction and location reporting.

[0044] (4) Rotation offset angle θ about the vertical axis: data type is float, unit is radians (rad). Used to correct the angle between the positive direction of the project and the positive direction of the site. In actual engineering, the configuration file often uses angles (such as 30°), and the module automatically completes the conversion from angle to radians.

[0045] (5) Scene scaling factor K: The data type is float, dimensionless. It represents the scale ratio between the virtual scene and the physical site, with a default value of 1.0 (i.e., 1:1 mapping). If the virtual scene needs to be enlarged or shrunk to fit the physical site, this factor can be adjusted.

[0046] (6) Origin offset compensation component , , The data type is float, and the unit is meters (m). It is used to dynamically correct the origin deviation. For example, ΔO=(0.2,0.0,0.1) represents X-axis compensation of 0.2m and Z-axis compensation of 0.1m.

[0047] Furthermore, the logical origin adaptation module 12 is specifically used to map the logical coordinates in the logical coordinate system of the LBE project module to the site coordinates in the site coordinate system of the site map data based on the adaptation parameters, using a calculation method that combines linear operations with trigonometric function compensation. The calculation method obtains the site coordinates by linearly combining the trigonometric function value of the rotation offset angle with the logical coordinates, superimposing the global origin coordinates of the site and the origin offset compensation component, and does not perform matrix transformation operations during the mapping process.

[0048] The specific mapping formula is as follows: (1) Forward mapping is used to convert the logical coordinates of players in the virtual scene of a project into unified field coordinates, facilitating cross-project interaction. The formula is as follows: , , .

[0049] (2) Reverse mapping, used to convert the site coordinate instructions issued by the server back to the project logical coordinates so that the client can execute them. The formula is as follows: , , .

[0050] Furthermore, to adapt to different development and operation scenarios, the logic origin adaptation module 12 supports three engineering configuration methods, specifically including: (1) Offline static configuration Write the adaptation parameters into a JSON configuration file located in the Config folder of the project's root directory. The file will be automatically loaded when the project starts. An example configuration file is shown below: { "logic_origin_config": { "venue_origin": {"x": 5.0,"y": 0.0,"z": 8.0}, "local_origin": {"x": 0.0,"y": 0.0,"z": 0.0}, "offset_compensate": {"x": 0.2,"y": 0.0,"z": 0.1}, "rotation_compensate": {"y_angle": 30.0}, "scale_factor": 1.0} }

[0051] (2) Dynamic distribution from the server The server sends parameter update commands to the specified device via the TCP protocol. The commands are in the same JSON format as the location reporting. The device updates its parameters and takes effect immediately upon receiving the command, without requiring a project restart. An example command is shown below: { "cmd_id":"CMD-ORIGIN-UPDATE-20250101001", "target_device_id":"LBE-PICO-00189", "cmd_type":"ORIGIN_CONFIG", "config_data": { "offset_compensate": {"x": 0.3,"y": 0.0,"z": 0.2}, "rotation_compensate": {"y_angle": 28.5}, "execute_time": 1735689600000 } }

[0052] (3) Manual calibration at the end The device has a built-in calibration mode, allowing operators to manually adjust the offset and rotation angle using the Pico device's touch handle or an external keyboard. During adjustment, the mapping effect is previewed in real-time (by comparing with site markers), and once confirmed to be correct, the parameters are saved locally and synchronized to the server.

[0053] In this embodiment, the logical origin adaptation module 12 is specifically implemented in the Unity engine based on the node hierarchy structure. The site logical origin is based on the virtual scene. The content of the virtual scene needs to be offset as a whole in some scenes. This is achieved by adding a CameraOffset node on the parent node of MainCamera and setting the offset and rotation of the CameraOffset node. An example of the node structure is as follows: [Pico Real-World Coordinate System]: Maintained by the Pico SDK.

[0054] ↑ MainCamera: Controlled by the Pico SDK, representing the user's physical movement.

[0055] ↓ CameraOffset: The origin adjustment layer controlled by the logical origin adaptation module. It sets the Position (corresponding to MapOffset) and Rotation (corresponding to WorldOriginRotation).

[0056] ↓ Root: The root node of the entire virtual scene, and the parent node of all game content, lighting, and special effects.

[0057] ↓ [Game World]: User-defined "site logical coordinates".

[0058] Therefore, by adjusting the Transform property of the CameraOffset node, alignment with the site coordinate system can be achieved without modifying the internal logical coordinates of the project.

[0059] In summary, this implementation provides a specific calculation example to verify the effectiveness of the above mapping formula: Known parameters: Origin of the site: , , ; Offset compensation: , , ; Rotation angle: (Engine automatically rotates in radians ≈ 0.5236). , ; Scaling factor: K=1.0; Project logical coordinates: , , ; Substitute into the forward mapping formula to calculate: ; ; .

[0060] Through the above calculations, the logical origin adaptation module 12 can accurately convert the logical coordinates within the project into unified site coordinates, and the entire process only involves addition, subtraction, multiplication, division and trigonometric function operations, avoiding complex matrix transformations and significantly reducing the computational load.

[0061] The coordinate transformation optimization module 13 communicates with both the client and server, and is used to transmit position information based on the field coordinate system. The coordinate transformation optimization module 13 optimizes the transmission of player position information and solves the problem of increased computational load caused by inconsistent coordinate systems in existing technologies through a matrix-free communication mechanism.

[0062] Specifically, the core function of the coordinate transformation optimization module 13 on the client side is to collect native device data and report it directly, without needing to perform coordinate system transformation. The specific implementation is as follows: (1) Data acquisition object: The client acquires localPosition and localRotation data of the MainCamera node in the Unity engine. These data represent the position and orientation of the device in its native local coordinate system, which is directly maintained by the Pico SDK.

[0063] (2) No-conversion principle: The raw data collected by the device does not need to undergo the matrix transformation of "local coordinates to world coordinates" and can be used directly as effective location information. Compared with the traditional solution, this mechanism saves more than 95% of the computational power consumption for coordinate transformation, while completely avoiding the problems of precision loss and delay superposition caused by matrix transformation.

[0064] (3) Reporting strategy: The basic reporting frequency is set to 100ms / time. To reduce network load, an incremental reporting mechanism is adopted: reporting is triggered when the position offset is ≥0.01m or the attitude angle change is ≥0.5°. The transmission channel uses UDP protocol as the main transmission channel to ensure low latency; TCP protocol is used as the secondary backup channel for reliable retransmission of critical data to ensure that data is not lost.

[0065] For data format encapsulation, the coordinate transformation optimization module 13 encapsulates the device's native position and attitude data according to a preset standard data format before transmitting it to the server. This embodiment supports both JSON and binary versions to adapt to different transmission scenarios.

[0066] (1) JSON format (debugging and cross-platform interaction) Suitable for debugging phases and cross-platform interaction scenarios, offering high data readability. Specific field definitions are as follows: device_id: A unique identifier for the device, globally unique (e.g., "LBE-PICO-00189").

[0067] report_time: The reporting timestamp, in milliseconds (e.g., 1751289600258), used for timing calibration.

[0068] device_status: Core data of device's native location and attitude.

[0069] local_position: The device's native local coordinates (Unity left-handed coordinate system, origin of itself), containing x, y, and z components (float type).

[0070] local_rotation: The device's native pose Euler angles (Unity left-handed system, no transformation), containing x, y, and z components (float type).

[0071] move_speed: Device movement speed (native data acquisition value, unit: m / s).

[0072] device_state: Device state (RUNNING / IDLE / FAULT).

[0073] app_list: Status data of multiple applications running on a single device (no conversion required), including app_id, app_name, run_status, bind_local_pos, frame_rate, etc.

[0074] sign: Data signature, using MD5 encryption, to prevent tampering and ensure data integrity.

[0075] (2) Binary format (production environment, lightweight) Suitable for production environments, this format uses a fixed-length packet design with a total length of 64 bytes, no redundant characters, and offers 70% higher transmission efficiency compared to JSON. The specific byte allocation is as follows: 1-16 bytes: device_id (string converted to binary, padded with 0s if necessary).

[0076] 17-24 bytes: report_time (8-byte long integer, Unix timestamp).

[0077] 25-40 bytes: local_position (4 bytes each of x / y / z float type, totaling 12 bytes).

[0078] Bytes 41-56: local_rotation (4 bytes each of x / y / z float type, totaling 12 bytes).

[0079] 57-60 bytes: move_speed (4-byte float).

[0080] Bytes 61-62: device_state (2-byte status code: 01=RUNNING / 02=IDLE / 03=FAULT).

[0081] Bytes 63-64: sign (2-byte MD5 signature digest).

[0082] Extension package: Multi-application status data, fixed at 32 bytes per application, appended as needed, including information such as app_id (4 bytes), run_status (2 bytes), bind_local_pos (12 bytes), frame_rate (4 bytes).

[0083] The server performs spatial calibration on the received data based on the site origin anchor point and relative offset, and performs linear superposition calculations during the calibration process without performing matrix transformation operations. The specific processing flow is as follows: (1) Raw data parsing: After receiving the data reported by the client, the server parses it directly according to the preset format. Verify the validity of device_id, the integrity of sign signature, and the validity of report_time. Filter abnormal data (such as sudden location changes, abnormal frame rate). If the verification fails, return an error code (0x001 = illegal device, 0x002 = invalid signature, 0x003 = data timeout) and trigger retransmission.

[0084] (2) Global spatiotemporal calibration: Time calibration: Based on the NTP (Network Time Protocol) time synchronization service, all client timestamps are unified, and deviations of ≤50ms are considered as the same time slice data.

[0085] Spatial calibration: An alignment method using "site origin anchor point + relative offset" is employed. No matrix transformation is required; the global alignment reference for the device is calculated solely through linear superposition. The calculation formula is as follows: Equipment global alignment reference = equipment native local coordinates + site origin offset; This method achieves spatial consistency across multiple devices, ensuring that all device data logically belongs to a unified site coordinate system.

[0086] (3) Business logic processing: Based on the parsed and calibrated data, perform operations such as device status monitoring, multi-application scheduling decision-making (such as automatically suspending low-priority applications when the device load is ≥80%), and cross-project permission control.

[0087] Finally, the coordinate transformation optimization module 13 sends the control instructions generated by the server to the client according to the standard data format. The control instructions carry native local data so that the client can directly parse and execute them.

[0088] (1) Command Format: The issued commands use the same native local data format as the reported format, requiring no matrix conversion. An example of the command format is as follows: { "cmd_id":"CMD-APP-CONTROL-20250101001", "target_device_id":"LBE-PICO-00189", "cmd_type":"APP_SWITCH", "cmd_content": { "target_app_id":"APP-STYS-03", "operate_type":"START", "bind_local_pos": {"x": 0.0,"y": 0.0,"z": 0.0}, "priority": 1, "execute_deadline": 1751289605258, "sign":"e7d2c3f1b5a9 } }

[0089] (2) Client execution: The client directly parses the received instruction without matrix calculation. If the instruction contains location information, the client converts the site coordinates in the instruction into the project logical coordinates using the mapping formula of the logical origin adaptation module 12, and performs the corresponding operation.

[0090] Furthermore, to verify the effectiveness of the coordinate transformation optimization module 13, this embodiment provides an interactive example of running multiple projects in parallel on a single device: Scenario: A single device (LBE-PICO-00189) runs "Journey to the West: A Dream" (ACTIVE) and "Cosmic Adventure" (PAUSE) in parallel, enabling cross-project switching between "Cosmic Adventure" and "Journey to the West: A Dream" without matrix conversion.

[0091] Step 1 (Client Acquisition): The device acquires native coordinates (2.56, 1.20, 8.92), attitude angles (0.02, 15.36, 0.18), and application status data, and reports them to the server in a standard format without conversion.

[0092] Step 2 (Server Processing): The server parses the raw data, performs time-space calibration, determines that the device resources are sufficient (CPU usage 35%), generates cross-project switching instructions, and issues them in the raw format.

[0093] Step 3 (Client Execution): After receiving the instruction, the client directly parses it without matrix calculation and executes the "Journey to the West: A Dreamlike Dream" suspension and "Cosmic Adventure" startup operations.

[0094] Step 4 (Status Synchronization): The device collects new application running status, incrementally reports it to the server, and the server updates the global status and synchronizes it to the management and control backend.

[0095] Results: The entire process takes ≤80ms, and the cross-project position deviation is ≤0.01m, perfectly supporting the real-time requirements of parallel operation of multiple projects on a single device.

[0096] As can be seen from the above implementation method, the coordinate transformation optimization module 13 realizes a closed loop of standardized raw data direct transmission, terminal-side autonomous calculation and server-side unified calibration. Under the premise of ensuring that the location information is logically consistent based on the site coordinate system, it significantly reduces data transmission latency and computing power consumption.

[0097] The platform deployment adaptation module 14 is connected to both the map sharing module and the external management platform, and is used to convert the site map data into a format compatible with the external management platform and deploy it. In this embodiment, the external management platform is specifically an example of the Pico Enterprise Device Management Platform (V3.0), but the present invention is not limited to this and can also be adapted to other AR / VR device management platforms with similar functions. This solves the problem in existing solutions that cannot utilize enterprise platforms for batch deployment and require manual management of map and project relationships. The specific implementation of the platform deployment adaptation module 14 is described in detail below.

[0098] First, to ensure that the map data can be recognized by the external management platform and distributed to the target device, the platform deployment adaptation module 14 conforms to the interface specifications of the external management platform. In this embodiment, the compatible format must meet the following core requirements: (1) File format specifications: Only .zip compressed package format is supported, and the size of the compressed package is limited to ≤2GB. The compressed package must contain the main map file (.pmap format, i.e., the unified format map generated by the map sharing module 11) and the configuration description file (.json format).

[0099] (2) Map metadata specifications: The configuration file must include information such as map name, venue index number, map size, scan time, and encryption type. The fields must conform to the JSON Schema specifications defined by the platform. For example, it must include required fields such as map_name, venue_index, map_size, scan_time, and encryption_type.

[0100] (3) Transmission protocol specifications: HTTPS protocol is used for map file upload, and chunked upload is supported (chunk size ≤ 5MB). Platform authentication (AppKey + signature verification) is required.

[0101] (4) Compatibility Specifications: The map data must be compatible with the SDK version of the enterprise version device ≥ v2.10.0, and support the platform to distribute the data to the specified device group in batches. The device can load the data without additional configuration after receiving it.

[0102] Furthermore, the platform deployment adaptation module 14 core implements the conversion of the unified map data of the map sharing module 11 to a format compatible with the external management platform. The conversion process specifically includes the following steps: (1) Metadata extraction and configuration file generation The platform deployment and adaptation module 14 extracts metadata from the site map data and generates a configuration file according to the specifications of the external management platform. Specifically, the module reads the "enhanced data header area" and "metadata area" of the map file in the map sharing module 11 to obtain key information such as the site index number (VenueIndex), site dimensions (Vector3), and scan time (Unix timestamp). Subsequently, it reorganizes the data according to the field names and data types required by the platform to generate a configuration specification file (config.json).

[0103] The configuration file example is as follows: { "map_name":"Field A-15x13m", "venue_index": 1, "map_size": {"x": 15.0,"y": 3.0,"z": 13.0}, "scan_time": 1751289600000, "encryption_type":"AES-256-CBC", "sdk_version":"v2.10.0" }

[0104] (2) File compression and signature generation The platform deployment and adaptation module 14 packages the site map data and the configuration file into a compressed file and generates a request signature for authentication.

[0105] Packaging: The unified map file (.pmap) and configuration specification file (config.json) are packaged into a .zip archive according to platform requirements. The compression algorithm used is Deflate, and the compression level is set to 6 to balance compression ratio and speed.

[0106] Signature: Generate a request signature according to the platform's authentication rules. The signature algorithm formula is: Sign = MD5(AppKey + timestamp + compressed file name + AppSecret). The timestamp is valid for 30 minutes, and the AppKey and AppSecret are application credentials pre-registered on the platform.

[0107] (3) Format pre-validation Before the actual upload, the pre-verification interface provided by the external management platform (e.g., / api / v3 / map / precheck) is called to upload the metadata and signature of the compressed package. If the verification passes, an upload credential (upload_token) is obtained; if the verification fails, specific error information is returned (such as missing fields or incorrect format), and the module automatically triggers a re-conversion process.

[0108] Finally, the platform deployment adaptation module 14 is configured to perform the following automated deployment steps to achieve batch and efficient map deployment: (1) Platform authentication: The platform deployment adaptation module 14 calls the authentication interface of the external management platform (e.g., / api / v3 / auth) through AppKey and AppSecret to obtain an access token. This token is used for authentication of all subsequent interface calls and is usually valid for 2 hours.

[0109] (2) Creating map tasks and uploading in chunks: Creating a task: Call the platform's map creation interface (e.g., / api / v3 / map / create), upload the converted map compressed package metadata and upload credentials, create a map deployment task, and obtain the task ID (task_id). Uploading in chunks: Divide the compressed package into chunks (5MB each) according to platform requirements, call the chunk upload interface (e.g., / api / v3 / map / upload), and upload in chunk order. After the upload is complete, call the merge interface (e.g., / api / v3 / map / merge) to complete file integration. This mechanism supports resuming interrupted uploads, ensuring the stability of large file transfers.

[0110] (3) Device group association: After the upload is completed, the device group management interface (e.g., / api / v3 / device / group / map / bind) is called to associate the uploaded map task with the target device group. It supports batch binding of multiple device groups, such as binding "Site A Map" to both "Beijing Store Device Group" and "Shanghai Store Device Group" at the same time, so as to achieve one-time upload and multi-location deployment.

[0111] (4) Issuance of deployment instructions and verification of results. Issuance of instructions: Call the deployment interface (e.g., / api / v3 / map / deploy) to issue deployment instructions to the associated target device group. After receiving the instructions, the devices automatically download and store the map files to the local storage area.

[0112] Result Verification: After deployment, the status query interface (e.g., / api / v3 / map / deploy / status) is called to verify the deployment result. The module polls the deployment status of all devices in the device group to ensure that the deployment success rate of all devices in the device group is ≥99%. If the deployment of a device fails, the module automatically records the error log and triggers the retry mechanism.

[0113] Therefore, it is evident that the platform deployment adaptation module 14 achieves seamless integration with external management platforms. Compared to existing solutions that require access to a specific operations SDK and manual map management, this solution eliminates the need for an operations SDK. Projects no longer need to integrate the bulky Pico operations SDK; they only need to interact with the platform through a standard HTTP interface, reducing development costs and package size. Simultaneously, it supports batch automated deployment, allowing the same location to be deployed automatically. Figure 1 Deploying maps to multiple device groups in a single step avoids the tedious process of manually copying map files to each device. Furthermore, the deployment status is traceable; through a deployment result verification mechanism, operators can monitor the map distribution status in real time, ensuring that all operational devices have the same map version and avoiding location anomalies caused by inconsistent map versions.

[0114] Through the collaborative work of the map sharing module 11, the logical origin adaptation module 12, the coordinate transformation optimization module 13, and the platform deployment adaptation module 14, this implementation provides a complete LBE large-space multi-project solution, realizing the reuse of multiple projects with a single map scan, lightweight coordinate adaptation, matrix-free data transmission, and automatic platform deployment of maps.

[0115] refer to Figure 2 This embodiment further discloses a location-based method for processing multi-item data in a large entertainment space, including: S100: Stores site map data in a unified format, which is generated based on a unified spatial reference and shared by multiple location-based entertainment (LBE) project modules.

[0116] Specifically, before generating site map data, a unified spatial benchmark is first established. This benchmark includes a uniformly defined site origin and positive direction. The site origin is set as follows: the geometric center of the physical site is used as the benchmark. For rectangular sites, the start and end coordinates of the longest and shortest sides are measured using a laser rangefinder. The origin coordinates are calculated using the formulas: Origin X = (Start point X of longest side + End point X of longest side) / 2, Origin Z = (Start point Z of shortest side + End point Z of shortest side) / 2. The default origin Y is set to 0m. For irregular sites, the origin is determined using the polygon centroid calculation method. The positive direction is set as follows: the positive Z-axis is uniformly defined as the direction from the origin towards the shortest side of the site on the right. This is determined by a combination of compass calibration and a laser pointer, with the direction deviation controlled within 0.5°. The coordinate system is defined as follows: the Unity standard left-handed coordinate system is used, with the X-axis horizontal to the right, the Y-axis vertically upward, and the Z-axis forward. Coordinate values ​​are retained to two decimal places.

[0117] The site map data was generated using an optimized SLAM algorithm. During the scanning process, optimizations were performed on feature point extraction and matching (reducing the extreme value detection threshold in weak texture areas and removing dynamic feature points), pose estimation and drift suppression (adjusting sensor fusion weights and using site markers to assist in loop closure), map construction and fusion (RANSAC algorithm registration and semantic label expansion), and real-time and hardware adaptation (GPU parallel computing). The generated map data has a cumulative drift error of less than 2 cm and a pose jitter amplitude of less than ±0.5°.

[0118] The site map data employs a hierarchical storage structure, including a file header, an enhanced data header, a core map data area, and a file footer. The file header stores the magic number, version number, and device identifier. The enhanced data header, stored in plaintext, stores the calibration information for the site origin and positive direction, including the site index number, map offset, site origin coordinates, and site positive direction rotation parameters. The core map data area is encrypted, storing SLAM feature point data and semantic label data. Specifically, it uses the AES-256-CBC algorithm for encryption, with the encryption key bound to the scanning device's serial number or dynamically distributed by the server. The file footer stores a CRC32 checksum for verifying file integrity.

[0119] Through the above steps, map data can be scanned once and shared by multiple projects, avoiding repetitive scanning work. Furthermore, the structure of plaintext and encrypted partitions ensures data reading efficiency and security.

[0120] S200: Map the logical coordinate system of the LBE project module to the site coordinate system of the site map data according to the preset adaptation parameters.

[0121] Specifically, the adaptation parameters include the global origin coordinates O(x), O(y), and O(z) of the site, the rotation offset angle θ around the vertical axis (Y-axis), the scene scaling factor K, and the origin offset compensation component. , , The parameters can be configured in three ways: by loading an offline static configuration file, by dynamically issuing commands from the server, or by manually calibrating on the client side.

[0122] The mapping calculation process involves a step based on the adaptation parameters, performed using a linear operation combined with trigonometric function compensation. Specifically, the site coordinates are obtained by linearly combining the trigonometric function value of the rotation offset angle with the logical coordinates, and then superimposing the global origin coordinates of the site and the origin offset compensation component. No matrix transformation operations are performed during the mapping process.

[0123] The formula for the forward mapping is as follows: , , ,in, , , These are the logical coordinate components in the logical coordinate system of the LBE project module. , , These are the global coordinate components of the site in the site coordinate system of the site map data.

[0124] Reverse mapping: When it is necessary to convert site coordinate commands into project logical coordinates, a reverse mapping formula is used. This also involves only linear operations and trigonometric function compensation, without matrix inversion operations. The formula is as follows: , , .

[0125] This step achieves precise matching between the logical spaces of different IP projects and the unified physical site space, with a computational load far lower than that of traditional matrix transformation schemes.

[0126] S300: Transmitting position information based on the site coordinate system. Specifically, this includes: native data acquisition and encapsulation: The client acquires the device's native position and attitude data (such as the localPosition and localRotation of the MainCamera node in the Unity engine). This native data has not undergone matrix transformation between the local and world coordinate systems. After acquisition, it is encapsulated according to a preset standard data format (JSON or binary format). Server-side spatial calibration: After receiving the data, the server performs spatial calibration based on the site origin anchor point and relative offset. During calibration, only linear superposition calculations are performed (device global alignment reference = device native local coordinates + site origin offset), without matrix transformation operations. Command issuance and execution: Control commands generated by the server are issued to the client according to the standard data format, carrying native local data. The client receives and directly parses and executes the command. If the command contains position information, it is converted to project logical coordinates through the above logical coordinate system mapping steps before taking effect.

[0127] S400: Convert the site map data into a format compatible with the external management platform and deploy it. In this embodiment, the external management platform is exemplified by the Pico Enterprise Equipment Management Platform. Specifically, this includes: The process involves format conversion and packaging. Metadata (such as site index number, map size, and scan time) is extracted from the site map data, and a configuration file (config.json) is generated according to the specifications of the external management platform. The site map data (.pmap file) and the configuration file are packaged into a compressed file (.zip format), and a request signature for authentication (Sign=MD5(AppKey+timestamp+filename+AppSecret)) is generated. Platform authentication and upload are performed by calling the authentication interface of the external management platform to obtain an access token. The compressed file is uploaded to the external management platform in chunks (each chunk ≤ 5MB) via the upload interface, and a merge interface is called after the upload is complete to integrate the files. Device group association and deployment are performed after the upload is complete by calling the device group management interface to associate the uploaded map task with the target device group, supporting batch binding of multiple device groups. Additionally, a deployment interface is called to issue deployment instructions to the associated target device group and query the deployment status to verify the deployment results, ensuring a deployment success rate of ≥ 99% for all devices within the device group.

[0128] This step enables seamless integration of map data with external management platforms, replacing manual deployment processes and significantly improving the efficiency of large-scale project operations.

[0129] Figure 3A schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention, such as... Figure 3 As shown, the electronic device 50 includes: a processor 501, a memory 502, and a bus 503; The processor 501 and the memory 502 communicate with each other via the bus 503; the processor 501 is used to call the program instructions in the memory 502 to execute the methods provided in the above-described embodiments.

[0130] This embodiment provides a non-transitory computer-readable storage medium that stores computer instructions that cause a computer to execute the methods provided in the above-described embodiments.

[0131] Those skilled in the art will understand that all or part of the steps of the above-described method implementation can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above-described method implementation. The aforementioned storage medium includes various storage media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0132] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0133] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of each embodiment or some parts of the embodiments.

[0134] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A location-based entertainment system with multiple attractions in a large space, characterized in that, The system includes: The map sharing module is used to store site map data in a unified format. The site map data is generated based on a unified spatial reference and is shared by multiple location-based entertainment (LBE) project modules. The logical origin adaptation module, set in the LBE project module, is used to map the logical coordinate system of the LBE project module to the site coordinate system of the site map data according to preset adaptation parameters. The coordinate transformation optimization module communicates with both the client and the server, and is used to transmit location information based on the site coordinate system. The platform deployment adaptation module is connected to the map sharing module and the external management platform respectively, and is used to convert the site map data into a format compatible with the external management platform and deploy it.

2. The large-space multi-project system according to claim 1, characterized in that, The spatial reference includes a uniformly defined site origin and positive site direction; The origin of the site is the geometric center of the physical site; The positive direction of the site is the direction from the origin of the site toward the shorter right side of the physical site. The site map data adopts a hierarchical storage structure, including a file header area, an enhanced data header area, a core map data area, and a file tail area; The enhanced data header area is stored in plaintext and is used to store the calibration information of the site origin and the positive direction of the site. The core map data area is encrypted and used to store SLAM feature point data and semantic label data.

3. The large-space multi-project system according to claim 1, characterized in that, The adaptation parameters include the global origin coordinates of the site, the rotation offset angle around the vertical axis, the scene scaling factor, and the origin offset compensation component. The logical origin adaptation module is specifically used to map the logical coordinates in the logical coordinate system of the LBE project module to the site coordinates in the site coordinate system of the site map data based on the adaptation parameters and using a calculation method that combines linear operation with trigonometric function compensation. The calculation method involves linearly combining the trigonometric function value of the rotation offset angle with the logical coordinates, and then superimposing the global origin coordinates of the site and the origin offset compensation component to obtain the site coordinates.

4. The large-space multi-project system according to claim 1, characterized in that, The coordinate transformation optimization module is configured as follows: Receive native device location and attitude data collected by the client; The device's native position and attitude data are encapsulated according to a preset standard data format and then transmitted to the server. The server performs spatial calibration on the received data based on the site origin anchor point and relative offset, and performs linear superposition calculation during the calibration process; Furthermore, the control commands generated by the server are sent to the client in accordance with the standard data format. The control commands carry native local data so that the client can directly parse and execute them.

5. The large-space multi-project system according to claim 1, characterized in that, The platform deployment adaptation module is configured as follows: Metadata is extracted from the site map data, and a configuration file is generated according to the specifications of the external management platform; The site map data and the configuration file are packaged together to generate a compressed file, and a request signature for authentication is generated. The system calls the authentication interface of the external management platform to obtain an access token, and uploads the compressed file in chunks to the external management platform through the upload interface. After the upload is completed, the system calls the device group management interface to associate the uploaded map task with the target device group. Additionally, it calls the deployment interface to send deployment instructions to the associated target device group and queries the deployment status to verify the deployment results.

6. The large-space multi-project system according to claim 2, characterized in that, The site map data is generated using an optimized SLAM algorithm, which includes: The weak texture feature enhancement step is used to reduce the extreme value detection threshold in weak texture regions to supplement feature points; The dynamic object filtering step is used to fuse depth data and IMU motion detection data to remove dynamic feature points whose movement speed exceeds a preset threshold. Additionally, a multi-sensor fusion optimization step is used to adjust the fusion weights of visual data and IMU data under different motion scenarios.

7. A location-based method for processing multi-item data in a large entertainment space, characterized in that, include: The system stores site map data in a unified format, which is generated based on a unified spatial reference and shared by multiple location-based entertainment (LBE) project modules. The logical coordinate system of the LBE project module is mapped to the site coordinate system of the site map data according to the preset adaptation parameters. Transmit location information based on the site coordinate system; The site map data is converted into a format compatible with the external management platform and then deployed.

8. The multi-project data processing method according to claim 7, characterized in that, The spatial reference includes a uniformly defined site origin and positive site direction; The origin of the site is the geometric center of the physical site; The positive direction of the site is the direction from the origin of the site toward the shorter right side of the physical site. The site map data adopts a hierarchical storage structure, including a file header area, an enhanced data header area, a core map data area, and a file tail area; The enhanced data header area is stored in plaintext and is used to store the calibration information of the site origin and the positive direction of the site. The core map data area is encrypted and used to store SLAM feature point data and semantic label data.

9. The multi-project data processing method according to claim 7, characterized in that, The adaptation parameters include the global origin coordinates of the site, the rotation offset angle around the vertical axis, the scene scaling factor, and the origin offset compensation component. The logical origin adaptation module is specifically used to map the logical coordinates in the logical coordinate system of the LBE project module to the site coordinates in the site coordinate system of the site map data based on the adaptation parameters and using a calculation method that combines linear operation with trigonometric function compensation. The calculation method involves linearly combining the trigonometric function value of the rotation offset angle with the logical coordinates, and then superimposing the global origin coordinates of the site and the origin offset compensation component to obtain the site coordinates.

10. The multi-project data processing method according to claim 7, characterized in that, The step of converting the site map data into a format compatible with the external management platform and deploying it includes: Metadata is extracted from the site map data, and a configuration file is generated according to the specifications of the external management platform; The site map data and the configuration file are packaged together to generate a compressed file, and a request signature for authentication is generated. The system calls the authentication interface of the external management platform to obtain an access token, and uploads the compressed file in chunks to the external management platform through the upload interface. After the upload is completed, the system calls the device group management interface to associate the uploaded map task with the target device group. Additionally, it calls the deployment interface to send deployment instructions to the associated target device group and queries the deployment status to verify the deployment results.

Images