Multi-ship real-time remote driving control and self-adaptive split-screen monitoring method and system

Abstract

The invention provides a multi-ship real-time remote driving control and self-adaptive split-screen monitoring method and system, and relates to the technical field of navigation simulation. The core mapping data container is used for packaging a unique identifier, entity object reference, physical control component reference and automatic navigation script reference for each ship in a simulation scene; synchronously executing dual-mode control switching and adaptive split-screen monitoring for a target ship based on the core mapping data container; wherein the dual-mode control switching comprises mutual exclusion switching between an automatic driving mode and a manual control mode, and thermal synchronization of ship power state parameters is carried out through a reflection mechanism at the switching moment; the self-adaptive split-screen monitoring comprises the steps of detecting the number of physical display devices, executing viewport segmentation when a single display device is used, and executing multi-target display mapping when a plurality of display devices are used.

Description

Technical Field

[0001] This invention relates to the field of navigation simulation technology, and in particular to a method and system for real-time remote control and adaptive split-screen monitoring of multiple ships. Background Technology

[0002] Existing ship driving simulation systems typically employ a distributed architecture or a rendering mode where a single viewpoint is bound to specific hardware. These systems manage multiple ship entities directly within the scene through scattered script references. Regarding display output, the systems usually rigidly bind camera components to ship entities and employ fixed single-screen splitting or preset multi-screen output strategies, lacking the ability to dynamically detect the runtime hardware environment. At the control logic level, automatic and manual control modes often operate independently, with switching between the two modes achieved only through simple component enabling / disabling, lacking a coordination mechanism for underlying state parameters.

[0003] However, existing solutions are isolated from each other in terms of the three core modules of display adaptation, control logic and data management, and lack a unified collaborative architecture. This makes it impossible for the system to achieve dynamic collaborative allocation and seamless connection of hardware resources, control signals and display output when facing multiple requirements such as changes in hardware environment and switching of operating modes, resulting in the overall system's shortcomings in adaptability, continuity and scalability. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for real-time remote control and adaptive split-screen monitoring of multiple ships, in order to solve the problem mentioned in the background art that the existing solutions are isolated in the three core modules of display adaptation, control logic and data management, and cannot achieve dynamic collaborative allocation and seamless connection of hardware resources, control signals and display output.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for real-time remote control and adaptive split-screen monitoring of multiple ships, comprising the following steps: creating a core mapping data container, wherein the core mapping data container is used to encapsulate the unique identifier, entity object reference, physical control component reference, and automatic navigation script reference for each ship in the simulation scenario; synchronously executing dual-mode control switching and adaptive split-screen monitoring for the target ship based on the core mapping data container; wherein, the dual-mode control switching includes mutually exclusive switching between automatic and manual control modes, and hot synchronization of ship dynamic state parameters through a reflection mechanism at the moment of switching; the adaptive split-screen monitoring includes detecting the number of physical display devices, and performing viewport segmentation when there is a single display device, and performing multi-target display mapping when there are multiple display devices.

[0006] Optionally, the step of mutually exclusive switching between automatic and manual control modes, and achieving hot synchronization of ship dynamic state parameters through a reflection mechanism at the moment of switching, specifically includes: for the mode switching command of the target ship, mutually exclusive switching is performed by controlling the activation status of the physical control component and the automatic navigation script component referenced in the core mapping data container to ensure that only one component applies control commands to the ship at any time; when switching from automatic to manual control, the dynamic state parameters inside the automatic navigation script component are accessed and read through a reflection mechanism, and the dynamic state parameters are converted into control parameters that the physical control component can recognize. Then, the converted control parameters are directly written into the non-public state field inside the physical control component again using the reflection mechanism, so that the manual control mode seamlessly inherits the ship's dynamic state before the switch.

[0007] Optionally, it also includes inertial smoothing of user input signals in manual control mode, specifically including: converting discrete input commands into continuous target input values; using a scalar interpolation algorithm based on frame interval time, with a preset sensitivity coefficient as the maximum change step size, to smooth the current input value so that the output value cannot change instantaneously but changes linearly; and converting the smoothed input value into the ship's thrust command.

[0008] Optionally, the steps of performing viewport segmentation on a single display device and performing multi-target display mapping on multiple display devices specifically include: when a single display device is detected, dynamically calculating the segmentation ratio based on the length of the ship instance list in the core mapping data container, configuring the normalized viewport rectangle of the camera component associated with each ship to achieve viewport segmentation rendering on a single screen; when multiple display devices are detected, binding the camera component associated with different ships to the index of the physical display one-to-one, so that the view of each ship is independently output to the corresponding physical display for full-screen monitoring.

[0009] Optionally, the adaptive split-screen monitoring uses external shadow camera synchronization technology for visual output, specifically including: allocating an independent external rendering camera for each display area or physical display; at the end of the rendering loop of each frame, obtaining the real-time spatial pose parameters of the local camera selected by the current target ship through the core mapping data container; calculating the position of the external rendering camera based on the real-time spatial pose parameters of the local camera using a progressive damping smoothing algorithm, and by introducing a dynamic weight coefficient based on the frame interval time, enabling the external rendering camera to smoothly approach the target position in a non-linear progressive manner; using a spherical linear interpolation algorithm to synchronize the rotation attitude of the external rendering camera, performing interpolation transition by calculating the shortest path between the current attitude and the target attitude in the quaternion space, and switching the spherical linear interpolation algorithm to the standard linear interpolation algorithm when the minimum angle between the two is detected, and normalizing the standard linear interpolation calculation results.

[0010] Optionally, the adaptive split-screen monitoring also includes interactive panoramic monitoring, specifically including: automatically selecting and executing two different camera parameter adjustment modes based on the comparison result of the real-time input zoom coefficient and the preset switching threshold: when the real-time zoom coefficient is lower than the switching threshold, it enters the optical zoom mode, keeps the physical position of the camera in world space unchanged, and dynamically adjusts its field of view attribute so that the observation angle continuously changes between the preset maximum wide-angle and minimum close-up field of view; when the real-time zoom coefficient exceeds the switching threshold, it switches to the physical displacement mode, locks the camera field of view to the maximum value, and smoothly shifts the position along the camera optical axis based on the proportion exceeding the threshold.

[0011] Optionally, it also includes: acquiring the velocity vector of the ship's rigid body in the world coordinate system in real time, and decomposing the velocity vector into longitudinal and lateral velocity components in the local coordinate system of the ship; setting independent fluid drag coefficients for the longitudinal and lateral velocity components respectively, and setting the lateral drag coefficient to be significantly higher than the longitudinal drag coefficient, so as to simulate the anisotropic characteristics of the ship's motion in the fluid; calculating the coordinates of the geometric pivot point at the stern of the ship in real time when simulating ship turning; applying lateral thrust at the geometric pivot point at the stern of the ship through the physical engine interface, thereby generating a steering torque based on the lever arm, so that the ship produces a drift trajectory and turning characteristics that conform to physical laws when turning.

[0012] On the other hand, the present invention also provides a multi-ship real-time remote control and adaptive split-screen monitoring system, comprising: a creation module for creating a core mapping data container, wherein the core mapping data container is used to encapsulate each ship in the simulation scenario with its unique identifier, entity object reference, physical control component reference, and automatic navigation script reference; and a control and monitoring module for synchronously executing dual-mode control switching and adaptive split-screen monitoring for target ships based on the core mapping data container; wherein the dual-mode control switching includes mutually exclusive switching between automatic driving and manual control modes, and hot synchronization of ship dynamic state parameters through a reflection mechanism at the moment of switching; and the adaptive split-screen monitoring includes detecting the number of physical display devices, and performing viewport segmentation when there is a single display device, and performing multi-target display mapping when there are multiple display devices.

[0013] On the other hand, the present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method for real-time remote control and adaptive split-screen monitoring of multiple ships.

[0014] On the other hand, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described method for real-time remote control and adaptive split-screen monitoring of multiple ships.

[0015] Compared with the prior art, the beneficial effects of the present invention are: This application achieves centralized management and collaborative scheduling of ship data, control logic, and display resources by creating a unified core mapping data container architecture. This fundamentally solves the core problems of rigid hardware adaptation, abrupt mode switching, and difficulty in functional expansion in existing technologies at the system level. The system can automatically identify the physical display environment and dynamically allocate appropriate rendering strategies, ensuring optimal visual output in both single-screen and multi-screen hardware topologies. Utilizing parameter thermal synchronization technology based on reflection mechanisms, it achieves seamless inheritance of dynamic states between automatic and manual control modes, completely eliminating motion jumps during control transfer. Its highly decoupled design brings excellent hardware compatibility, smooth operation, and functional scalability to the system, significantly improving the immersion, continuity, and application value of multi-ship collaborative simulation. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the method steps of the present invention.

[0017] Figure 2 This is a schematic diagram of the single-screen multi-ship control of the present invention.

[0018] Figure 3 This is a schematic diagram of the dual-screen multi-ship control system of the present invention.

[0019] Figure 4 This is a schematic diagram of the three-screen multi-ship control system of the present invention.

[0020] Figure 5 This is a schematic diagram of the ship perspective switching of the present invention.

[0021] Figure 6 This is a schematic diagram of the system structure of the present invention.

[0022] In the diagram: 10 - Creation module, 20 - Control and monitoring module. Detailed Implementation

[0023] The present invention will now be clearly and completely described in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be used interchangeably where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] Those skilled in the art will understand that, unless explicitly stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in the specification of this application means the presence of features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0026] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0027] It should be understood that the sequence number and size of each step in this embodiment do not imply the order of execution. The execution order of each process is determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0028] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0029] Please refer to Figures 1-5 This invention discloses a method for real-time remote control and adaptive split-screen monitoring of multiple ships, comprising the following steps: creating a core mapping data container, wherein the core mapping data container is used to encapsulate the unique identifier, entity object reference, physical control component reference, and automatic navigation script reference for each ship in the simulation scenario; synchronously executing dual-mode control switching and adaptive split-screen monitoring for the target ship based on the core mapping data container; wherein, the dual-mode control switching includes mutually exclusive switching between automatic and manual control modes, and hot synchronization of ship dynamic state parameters through a reflection mechanism at the moment of switching; the adaptive split-screen monitoring includes detecting the number of physical display devices, and performing viewport segmentation when there is a single display device, and performing multi-target display mapping when there are multiple display devices.

[0030] Specifically, this application is developed based on the Unity3D engine architecture and designs a custom data class named ShipInstance as the core mapping data container for ship logical entities in the memory stack. This custom data class adopts the direct memory reference encapsulation design pattern and is explicitly defined as a serializable object to support visual debugging and data persistence in the editor environment. Each core mapping data container contains the following key fields: Unique identifier shipID: The system first defines an integer variable named shipID as a unique index identifier. This variable does not depend on the random ID generated by the engine, but is assigned consecutive index values ​​by the system management module during the initialization phase. It is specifically used to establish a deterministic mapping relationship between the rendered texture and the target physical display in the multi-screen rendering pipeline.

[0031] Entity object reference: The model holds a core reference field of type GameObject, which is the ship entity shipObject. This field directly points to the ship's root node in the 3D scene graph, allowing the upper-level logic to directly access the ship's transformation components without traversing the scene tree, thereby efficiently obtaining the ship's real-time world coordinates and rotation quaternions.

[0032] The physics control component includes a dynamic model of the ship. It calculates the forces and torques acting on the ship based on input commands and drives the ship's physical movement using Unity's physics engine, simulating a realistic manual driving feel. In dual-mode control, this component is enabled when the system switches to manual mode, becoming the sole driving force for the ship's movement. When switched to automatic mode, this component is disabled to ensure that manual input signals are not received, fundamentally avoiding control conflicts.

[0033] Automatic navigation script reference: This script is responsible for processing preset waypoint data, automatically calculating the ship's required course and speed through a PID control algorithm to enable the ship to navigate along the predetermined path, and acting as the driver in autopilot mode, continuously issuing motion commands to the ship's physical systems. In dual-mode control, this script is activated when the system switches to autopilot mode. It also plays a crucial role in the instant of mode switching: when switching to manual mode is required, the system reads the current operating status from this script via reflection and thermally synchronizes it to the manual controller, ensuring a smooth power transition.

[0034] The core mapping data container packages all relevant ship data and functions together, achieving a highly cohesive and loosely coupled architecture. The upper-level management system does not need to concern itself with the specific implementation details of each ship; it only needs to operate the unified ShipInstance interface to achieve complex multi-ship control, display adaptation, and mode switching, greatly improving the system's maintainability, scalability, and stability. It overcomes the scattered reference problem in existing technologies, achieving dynamic collaborative allocation and seamless integration of hardware resources, control signals, and display outputs.

[0035] Based on this unified data architecture, the system initially calls the Display.displays interface to detect the number of physical displays connected. When the number is one, it enters single-screen mode, setting a normalized viewport rectangle for each ship camera. When the number is greater than one, it enters multi-screen mode, activating extended displays and binding different ship cameras to different display indices. Simultaneously, the system uses an event delegation mechanism to bind the operation buttons on the UI control panel to the corresponding control components in the core mapping data container, achieving mutually exclusive switching between dual-mode operation: at the moment of switching, seamless hot synchronization from automatic navigation state to manual control state is achieved through C# reflection mechanisms.

[0036] This application achieves centralized management and collaborative scheduling of ship data, control logic, and display resources by creating a unified core mapping data container architecture. This fundamentally solves the core problems of rigid hardware adaptation, abrupt mode switching, and difficulty in functional expansion in existing technologies at the system level. The system can automatically identify the physical display environment and dynamically allocate appropriate rendering strategies, ensuring optimal visual output in both single-screen and multi-screen hardware topologies. Utilizing parameter thermal synchronization technology based on reflection mechanisms, it achieves seamless inheritance of dynamic states between automatic and manual control modes, completely eliminating motion jumps during control transfer. Its highly decoupled design brings excellent hardware compatibility, smooth operation, and functional scalability to the system, significantly improving the immersion, continuity, and application value of multi-ship collaborative simulation.

[0037] In some embodiments, the step of mutually exclusive switching between automatic and manual control modes, and achieving hot synchronization of ship dynamic state parameters through a reflection mechanism at the moment of switching, specifically includes: for the mode switching command of the target ship, mutually exclusive switching is performed by controlling the activation status of the physical control component and the automatic navigation script component referenced in the core mapping data container to ensure that only one component applies control commands to the ship at any time; when switching from automatic to manual control, the dynamic state parameters inside the automatic navigation script component are accessed and read through a reflection mechanism, and the dynamic state parameters are converted into control parameters that the physical control component can recognize. Then, the converted control parameters are directly written into the non-public state field inside the physical control component again using the reflection mechanism, so that the manual control mode seamlessly inherits the ship's dynamic state before the switch.

[0038] Specifically, to fundamentally resolve the signal conflict between autonomous driving algorithms and user-input commands at the physical level, this application designs a strict mutual-exclusion component activation mechanism at the architecture level. The system uses the ShipInstance data instance as the state context and maintains references to two core control components: the rigid body physical controller ShipController, which handles keyboard / hardware peripheral signals, and the automatic navigation script PathMoveScript, which is responsible for spline curve tracing.

[0039] When switching to autopilot mode, the system will force `PathMoveScript.enabled = true` and immediately execute `ShipController.enabled = false`. This operation has fundamental implications: disabling the `ShipController` component means the Unity engine will stop calling the `Update` function within the script, thus directly cutting off the polling path of input interfaces such as `Input.GetAxis` at the source of logic, ensuring that no manual control signals can flow into the physics engine. Conversely, when switching to manual mode, the system immediately suspends the execution logic of the path-following script and reactivates the physics controller to resume responding to hardware input. This lifecycle-based management method of Unity components ensures that in any physics refresh frame, the ship's rigid body components only receive thrust and torque from a single source, thus completely eliminating the risk of physical motion jitter and logic races caused by the superposition of multiple control signals.

[0040] At the critical moment of switching from automatic navigation mode to manual takeover mode, in order to eliminate the sudden drop in ship speed or abrupt change in attitude caused by control logic reset, the system implements a dynamic parameter hot synchronization algorithm based on C# reflection mechanism. Specifically, when the system captures the switching command but before executing the component activation state change, it immediately starts the synchronization subroutine. In the step of hot synchronization of ship dynamic state parameters through reflection mechanism, the dynamic state parameter is the current speed vector calculated by the automatic navigation script component; the control parameter that the physical control component can recognize is the throttle percentage calculated based on the current speed vector using the ship dynamics model.

[0041] First, initialize the public interface of the logic call path following the component to extract the scalar speed of the ship at the current moment. Subsequently, based on the ship's hydrodynamic configuration, the system introduces a normalized mapping function to convert the speed value into an equivalent manual throttle percentage parameter. Its core calculation formula is: ,in, Representing the ship's design maximum speed, the Clamp function ensures that the input value is strictly limited to a valid range. Given that critical state variables within the ShipController script, such as the current throttle position, are typically designed as private or protected fields to ensure code encapsulation security, conventional external calls cannot write to them. Therefore, this system utilizes the metadata access interface under the System.Reflection namespace, dynamically searching for and retrieving the metadata handle of this private field in memory by specifying the BindingFlags.NonPublic|BindingFlags.Instance flags. Then, the program bypasses object-oriented access checks and calculates the... The values ​​are directly injected into the memory domain of the physical controller instance. This low-level memory operation ensures that the internal dynamic parameters of the manual controller remain strictly consistent with the autonomous driving state of the previous frame in the first frame when it is activated, thereby achieving continuity of momentum and acceleration at the physical simulation level and achieving true seamless soft switching.

[0042] This application fundamentally eliminates the risk of physical-level conflicts between autonomous driving and manual control commands through a component-level mutual exclusion switching mechanism, ensuring that the ship's dynamics system is driven by only a single control source at any given time, thereby eliminating motion jitter and logic disorder caused by signal superposition. At the same time, the dynamic state parameter thermal synchronization technology implemented using the reflection mechanism breaks through the encapsulation limitations of object-oriented programming at the moment of control transfer, seamlessly injecting the real-time motion state in the automatic navigation mode into the manual controller. This perfectly solves the motion abrupt changes such as sudden speed drops and attitude jumps caused by control logic reset in traditional systems, ultimately achieving a truly smooth, continuous, and natural transition between different driving modes, greatly enhancing the realism and immersion of ship handling simulation.

[0043] In some embodiments, the method further includes inertial smoothing of the user input signal in manual control mode, specifically including: converting discrete input commands into continuous target input values; using a scalar interpolation algorithm based on frame interval time with a preset sensitivity coefficient as the maximum change step size to smooth the current input value so that the output value does not change instantaneously but changes linearly; and converting the smoothed input value into the ship's thrust command.

[0044] Specifically, in manual takeover mode, to reproduce the unique maneuvering lag and large-mass inertia characteristics of large ships in a fluid environment, the system did not use a simple rigid body position setting. Instead, it designed a virtual axis accumulation algorithm based on time steps. In practice, the physical controller first polls the state of the input hardware in the logic update loop of each frame, converting discrete switching signals, such as the pressing and releasing of keyboard I / K keys, into target state values: the target is set to 1.0 or -1.0 when the key is pressed, and 0.0 when it is released.

[0045] Subsequently, instead of directly using the target value to drive the rigid body, the system introduces an intermediate layer called the input damper. Utilizing the Mathf.MoveTowards scalar interpolation function provided by the Unity engine, the system calculates the real-time input axis values ​​for the current frame with a preset response sensitivity coefficient as the maximum step size. The calculation logic is described as follows: ;in, The frame interval time. This is the current input value. The input value from the previous frame. Input the target value. This is the sensitivity coefficient. The algorithm ensures that the input value cannot undergo instantaneous abrupt changes, but rather exhibits a linear, gradual change. This means that even if the user releases the button momentarily... The actual output It will still decay slowly according to the laws of physics, thus simulating the mechanical delay during the return of the servo motor to center or the propeller to stop.

[0046] Finally, during the physical refresh phase, the system will calculate the smoothing axis values. With the ship's maximum thrust parameters The thrust vector is generated by multiplying the forces. To ensure that the motion conforms to the principles of ship dynamics, the system calls the Rigidbody.AddRelativeForce interface to apply the thrust strictly along the Z-axis of the ship's local coordinate system, i.e., the bow direction, rather than the world coordinate system. This two-layer processing architecture based on input buffering and local force application successfully recreates the heavy feel of slow start-up and difficult stopping of a real ship in the virtual environment, avoiding the inertia-free floating phenomenon commonly found in traditional game controllers.

[0047] This application introduces a frame-time-based inertial smoothing algorithm to convert rigid discrete input signals into continuous control commands that conform to physical laws, effectively eliminating the control abrupt changes and step responses caused by traditional digital input devices. This mechanism uses a gradual model constructed with sensitivity coefficients and time increments to successfully simulate the mass inertia and maneuvering system delays unique to large ships in a fluid environment, making the acceleration, deceleration, and steering responses of the virtual ship exhibit realistic slow start and slow stop characteristics. This fundamentally overcomes the lack of inertia and floating sensation commonly found in traditional simulations, greatly enhancing the physical realism and immersive experience of manual control mode.

[0048] In some embodiments, the steps of performing viewport segmentation on a single display device and performing multi-target display mapping on multiple display devices specifically include: when a single display device is detected, dynamically calculating the segmentation ratio based on the length of the ship instance list in the core mapping data container, configuring the normalized viewport rectangle of the camera component associated with each ship to achieve viewport segmentation rendering on a single screen; when multiple display devices are detected, binding the camera components associated with different ships to the index of the physical display one-to-one, so that the view of each ship is independently output to the corresponding physical display for full-screen monitoring.

[0049] Specifically, this application integrates a display adaptation module called DualScreenManager, which is configured to execute hardware handshake logic during the Awake initialization phase of the application lifecycle. The program first accesses the Unity engine's underlying Display.displays interface to obtain an array of monitors physically connected to the current workstation, and immediately executes a necessary activation loop. The system iterates through all extended display devices with indices greater than zero in the array and explicitly calls the Display.Activate method to wake up the rendering buffer of the secondary screen, thereby preventing black screen anomalies caused by uninitialized buffers in multi-screen output mode.

[0050] After completing the hardware handshake, the module executes a branch rendering strategy based on the detected number of active displays. If the system detects a single-display environment, it automatically switches to viewport splitting mode. In this mode, the module iterates through the global ShipInstance list, dynamically calculates the normalized coordinates (range 0.0 to 1.0) of the screen space based on the total number of ships, and modifies the ViewportRect property of each ship's main camera component (which includes X, Y, Width, and Height components) to proportionally compress and tile multiple independent viewpoints onto a single physical screen. Conversely, if the detection result is greater than one, the system automatically switches to multi-target index mapping mode. In this mode, the module ignores the viewport compression logic and directly uses the shipId of each ship instance as the mapping key, hard-binding the TargetDisplay index property of the corresponding ship camera component to the ID of the physical display. This adaptive logic based on runtime hardware topology allows the same compiled software program to seamlessly adapt to both single-screen teaching environments on portable laptops and multi-screen practical environments on professional simulation platforms without requiring manual modification of configuration files or recompilation of code.

[0051] When the system detects two or more physical displays connected, it automatically activates the multi-target display mode. In this mode, the management module activates the rendering channel of the extended display and iterates through the list of ship instances, mapping the camera components bound to different ships to different target display indices. For example, the view of the first ship is directed to the main display at index 0, and the view of the second ship is directed to the extended display at index 1, achieving full-screen monitoring at the physical screen level. Conversely, when only one physical display is detected, the system switches to viewport splitting mode. In this mode, the system no longer distinguishes outputs by display index, but instead modifies the normalized viewport attributes of the camera components. In practice, the system calculates the screen splitting ratio, for example, setting the viewport rectangles of the two ship cameras to the left half (0, 0, 0.5, 1) and right half (0.5, 0, 0.5, 1) of the screen, respectively, thereby achieving logical screen splitting within a single rendering pipeline.

[0052] This application achieves intelligent multi-viewport segmentation under a single device and independent full-screen mapping between multiple devices by dynamically detecting the number of display devices and adaptively selecting the optimal rendering strategy. This enables the same simulation system to be seamlessly compatible with various hardware environments, from portable single screens to professional multi-screens. This hardware topology-based automatic adaptation mechanism not only significantly improves the flexibility of system deployment and the utilization rate of hardware resources, but also fundamentally enhances the operator's situational awareness and operational efficiency in multi-ship monitoring scenarios by ensuring that each ship view can obtain the most suitable display space.

[0053] In some embodiments, the adaptive split-screen monitoring uses external shadow camera synchronization technology for visual output, specifically including: allocating an independent external rendering camera for each display area or physical display; at the end of the rendering loop of each frame, obtaining the real-time spatial pose parameters of the local camera selected by the current target ship through the core mapping data container; calculating the position of the external rendering camera based on the real-time spatial pose parameters of the local camera using a progressive damping smoothing algorithm, and by introducing a dynamic weight coefficient based on the frame interval time, enabling the external rendering camera to smoothly approach the target position in a non-linear progressive manner; using a spherical linear interpolation algorithm to synchronize the rotation attitude of the external rendering camera, performing interpolation transition by calculating the shortest path between the current attitude and the target attitude in the quaternion space, and switching the spherical linear interpolation algorithm to the standard linear interpolation algorithm when the minimum angle between the two is detected, and normalizing the standard linear interpolation calculation results.

[0054] Specifically, to further decouple the high-frequency physical motion calculations of the ship from the screen rendering pipeline, the system introduces an external shadow camera synchronization technology called EnhancedShipCameraSystem. Under this architecture, each ship entity does not directly mount resource-intensive active camera components; instead, it has a pre-defined set of virtual viewpoint anchor points containing only transformation components, corresponding to spatial positions such as the bow, stern, and global viewpoint. The system maintains an independent set of external rendering cameras in the scene, matching the number of screen splits. These cameras do not belong to any ship sub-object but exist as global singletons.

[0055] At the end of each frame, the system executes a progressively damped smoothing algorithm to calculate the target pose of the externally rendered camera. This algorithm introduces a damping coefficient, allowing the camera to gently approach the target position in a non-linear manner, simulating the following effect of a soft spring in the physical world. The core calculation formula for position synchronization is as follows: ; In the formula: The final position vector of the externally rendered camera in the world coordinate system, calculated for the current frame; This is the position vector of the camera when the previous frame ended rendering; The real-time world coordinates of the ship's virtual anchor point in the current frame; The dynamic weighting coefficients are based on the frame interval time, and the calculation formula is: .in This is the preset follower sensitivity constant. It represents the time increment from the previous frame to the current frame.

[0056] Meanwhile, for rotational attitude synchronization, the system employs the shortest path spherical linear interpolation algorithm. Unlike linear position calculations, the spherical linear interpolation algorithm aims to find the quaternion connecting the current rotation on a four-dimensional unit sphere. Rotation Quaternion with Target The shortest great circle path.

[0057] In practice, the system first calculates the dot product of the two quaternions to determine their included angle. ,Right now If the dot product is negative, reverse it. This ensures interpolation follows the shortest path. A smoothing factor, with values ​​ranging from 0 to 1, is used. The rotation quaternion of the next frame The calculation formula is as follows: ; In the formula: and These constitute the dynamic weighting coefficients for the current attitude and the target attitude, respectively.

[0058] Furthermore, to ensure the robustness of numerical calculations, a small angle determination mechanism is integrated into the system: when two rotational attitudes are detected to be extremely close, i.e. To prevent floating-point overflow errors caused by the denominator approaching zero in the formula, the system automatically degenerates the algorithm into simple linear interpolation and normalizes the results. This approach, which combines strict geometric definitions with engineering boundary protection, not only theoretically avoids the inherent gimbal lock problem of Euler angle rotation systems, but also ensures that even when the ship undergoes severe turning or turbulence under multi-screen high frame rate rendering, the monitoring screen maintains mathematical continuity and visual smoothness.

[0059] This application achieves separation of high-frequency physical motion calculation and final screen rendering through an architecture that decouples the external shadow camera from the ship's physical form, effectively improving the stability of the rendering pipeline and the smoothness of the output. By employing a damped smoothing algorithm and spherical linear interpolation technology, it ensures the smoothness and naturalness of the camera's perspective switching when tracking the ship's movement, completely eliminating the gimbal lock-up problem that may be caused by traditional Euler angle rotation. At the same time, by intelligently switching linear interpolation and supplementing it with normalization processing, it ensures the robustness of numerical calculations under extreme conditions, ultimately providing operators with a consistently stable, jitter-free, and highly immersive monitoring view in complex and ever-changing navigation scenarios.

[0060] In some embodiments, the adaptive split-screen monitoring further includes interactive panoramic monitoring, specifically including: automatically selecting and executing two different camera parameter adjustment modes based on the comparison result of the real-time input scaling factor and the preset switching threshold: when the real-time scaling factor is lower than the switching threshold, entering the optical zoom mode, keeping the physical position of the camera in world space unchanged, and dynamically adjusting its field of view attribute so that the viewing angle continuously changes between the preset maximum wide-angle and minimum close-up field of view; when the real-time scaling factor exceeds the switching threshold, switching to the physical displacement mode, locking the camera's field of view to the maximum value, and smoothly shifting the position along the camera's optical axis based on the proportion exceeding the threshold.

[0061] Specifically, to achieve both global situational awareness and detailed observation of a single vessel within a single viewport, the monitoring module integrates a hybrid viewpoint scaling engine based on state segmentation. This engine abandons the traditional single physical push-pull mode, instead maintaining a normalized target scaling coefficient Z ranging from 0.0 to 1.0. The system first captures the user's input increment in each frame's update cycle and performs smoothing damping on the coefficient Z. Then, the engine automatically determines the current scaling state based on a preset optical-physical switching threshold T.

[0062] When the real-time zoom factor Z is less than the threshold T, the system keeps the camera's physical position locked and only performs optical zoom calculations on the camera's field of view. The calculation formula is as follows: ; In the formula: Represents the field of view value of the final output of the current frame; and These represent the preset minimum, i.e., close-up mode, and maximum, i.e., wide-angle mode, respectively; while This represents the normalization progress of the current state within the optical zoom range. This strategy, by shrinking the angle of the viewing cone, simulates the zoom effect of a DSLR lens, effectively avoiding clipping collisions between the camera's clipping plane and the ship model when observing at extremely close distances.

[0063] Conversely, when the scaling factor Z exceeds the threshold T, the system automatically locks the field of view to its maximum value and activates the physical displacement logic, pushing or pulling the coordinates along the camera's optical axis. The position calculation formula is as follows: ; In this formula, The target world coordinate vector representing the camera; Represents the initial base viewpoint coordinates of the camera; The unit direction vector representing the direction the camera is facing; This represents the maximum physical distance at which the camera can be moved back; while This represents the relative travel ratio within the physical displacement range. This hybrid strategy of zooming first and then shifting ensures that the user maintains visual continuity and geometric stability throughout the entire process of smoothly transitioning from the microscopic deck details to the macroscopic global view of the sea.

[0064] This application achieves seamless integration of macro-level situational awareness and micro-level detail observation through a threshold-based hybrid viewpoint scaling engine. It employs a two-stage control strategy that prioritizes optical zoom and supplements it with physical displacement. During close-range observation, it dynamically adjusts the field of view to prevent geometric penetration between the camera and the ship model. During long-range monitoring, it maintains the stability of the perspective relationship in the image through physical displacement. This perfectly balances the breadth of the global field of view with the clarity of local details within a single viewport, significantly enhancing the operator's ability to continuously monitor the dynamics of multiple ships and perceive spatial depth in complex marine environments.

[0065] In some embodiments, the method further includes: acquiring the velocity vector of the ship's rigid body in the world coordinate system in real time, and decomposing the velocity vector into longitudinal and lateral velocity components in the local coordinate system of the ship; setting independent fluid drag coefficients for the longitudinal and lateral velocity components respectively, and setting the lateral drag coefficient to be significantly higher than the longitudinal drag coefficient, so as to simulate the anisotropic characteristics of the ship's motion in the fluid; calculating the coordinates of the geometric pivot point at the stern of the ship in real time when simulating ship turning; applying lateral thrust at the geometric pivot point at the stern of the ship through the physical engine interface, thereby generating a steering torque based on the lever arm, so that the ship produces a drift trajectory and turning characteristics that conform to physical laws when turning.

[0066] Specifically, to overcome the limitations of general-purpose physics engines in simulating fluid medium motion, this application designs and implements a dedicated anisotropic hydrodynamic simulation algorithm. Traditional rigid body drag models typically assume that environmental drag is uniform in all directions, which prevents them from accurately representing the fluid characteristics of ships, where longitudinal drag is low and lateral sideslip drag is high. Therefore, in each frame's physics calculation step, this embodiment first obtains the instantaneous velocity vector of the ship's rigid body in the world coordinate system. Using the inverse rotation transformation matrix of the rigid body, it is projected onto the local coordinate system of the hull and decomposed into longitudinal velocity components along the bow direction. lateral velocity component along the starboard direction .

[0067] Subsequently, the system applies differentiated drag coefficients to these two independent velocity components. Let the longitudinal fluid damping coefficient be... The lateral damping coefficient is ,set up > Then the vector of local fluid resistance experienced by the hull Calculation formula: ; In this formula, and These represent the unit vectors of the horizontal and vertical axes of the local coordinate system, respectively. The negative sign indicates that the direction of resistance is opposite to the direction of motion. The calculated... It is then transformed back to the world coordinate system and superimposed onto the rigid body, thus constructing a non-uniform fluid resistance field at the physical level.

[0068] Furthermore, in the simulation of steering mechanics, the system abandons the simplistic approach of directly applying the rotational torque to the center of mass, and instead adopts a dynamic model based on the lever arm. The system calculates the displacement vector of the virtual rudder blade relative to the ship's center of gravity in real time. When a steering command is generated, the system applies lateral thrust at the stern geometric pivot point via the AddForceAtPosition interface. According to the principles of rigid body mechanics, the yaw moment generated by this thrust... The following cross product relationship must be satisfied: ; This lever arm-based torque generation method not only drives the rotation of the hull, but its component force also produces a reverse lateral thrust effect on the hull, enabling the ship to naturally generate a realistic drift trajectory, roll attitude, and turning radius that conforms to the laws of fluidity during turning, greatly improving the physical realism of the virtual control feel.

[0069] This application successfully simulates the real physical characteristics of ships in fluids by constructing an anisotropic hydrodynamic model, which has low longitudinal resistance and significantly increased lateral resistance. This effectively overcomes the motion distortion problem caused by isotropic resistance in general physics engines. At the same time, based on the steering torque generation mechanism of geometric pivot, the drift trajectory and turning radius of the ship during turning are realistically reproduced through the lever arm effect. This makes the handling feel of the virtual ship highly consistent with the dynamic characteristics of real large ships, such as inertial response and rudder delay, which greatly improves the physical realism and operational immersion of maritime simulation training.

[0070] Please refer to Figure 6On the other hand, the present invention also provides a multi-ship real-time remote control and adaptive split-screen monitoring system, comprising: a creation module 10, used to create a core mapping data container, wherein the core mapping data container is used to encapsulate the unique identifier, entity object reference, physical control component reference, and automatic navigation script reference for each ship in the simulation scenario; a control and monitoring module 20, used to synchronously execute dual-mode control switching and adaptive split-screen monitoring for the target ship based on the core mapping data container; wherein, the dual-mode control switching includes mutually exclusive switching between automatic driving and manual control modes, and hot synchronization of ship dynamic state parameters through a reflection mechanism at the moment of switching; the adaptive split-screen monitoring includes detecting the number of physical display devices, and performing viewport segmentation when there is a single display device, and performing multi-target display mapping when there are multiple display devices.

[0071] On the other hand, the present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method for real-time remote control and adaptive split-screen monitoring of multiple ships.

[0072] On the other hand, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described method for real-time remote control and adaptive split-screen monitoring of multiple ships.

[0073] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0074] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, database, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0075] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for real-time remote control and adaptive split-screen monitoring of multiple ships, characterized by the following steps: include: Create a core mapping data container, which is used to encapsulate the unique identifier, entity object reference, physical control component reference, and automatic navigation script reference for each ship in the simulation scenario; Based on the core mapping data container, dual-mode control switching and adaptive split-screen monitoring for the target ship are executed synchronously. The dual-mode control switching includes mutually exclusive switching between automatic and manual control modes, and thermal synchronization of ship dynamic state parameters through a reflection mechanism at the moment of switching. The adaptive split-screen monitoring includes detecting the number of physical display devices, performing viewport splitting when there is a single display device, and performing multi-target display mapping when there are multiple display devices.

2. The method for real-time remote control and adaptive split-screen monitoring of multiple ships according to claim 1, characterized in that, The steps of mutually exclusive switching between automatic and manual control modes, and achieving thermal synchronization of ship dynamic state parameters through a reflection mechanism at the moment of switching, specifically include: In response to the mode switching command for the target vessel, the activation status of the physical control component and the automatic navigation script component referenced in the core mapping data container is mutually exclusive to ensure that only one component applies control commands to the vessel at any given time. When switching from automatic driving to manual control, the power state parameters inside the automatic navigation script component are accessed and read through the reflection mechanism, and the power state parameters are converted into control parameters that can be recognized by the physical control component. Then, the converted control parameters are directly written into the non-public state field inside the physical control component through the reflection mechanism again, so that the manual control mode can seamlessly inherit the ship's power state before the switch.

3. The method for real-time remote control and adaptive split-screen monitoring of multiple ships according to claim 2, characterized in that, This also includes inertial smoothing of user input signals in manual control mode, specifically including: Convert discrete input instructions into continuous target input values; A scalar interpolation algorithm based on frame interval time is adopted, with a preset sensitivity coefficient as the maximum change step size, to smooth the current input value so that the output value does not change instantaneously but changes linearly. The smoothed input values ​​are converted into thrust commands for the ship.

4. The method for real-time remote control and adaptive split-screen monitoring of multiple ships according to claim 1, characterized in that, The steps of performing viewport segmentation on a single display device and performing multi-target display mapping on multiple display devices specifically include: When a single display device is detected, the segmentation ratio is dynamically calculated based on the length of the list of ship instances in the core mapping data container, and the normalized viewport rectangle of the camera component associated with each ship is configured to achieve viewport segmentation rendering on a single screen. When multiple display devices are detected, the camera components associated with different ships are bound one-to-one with the indexes of the physical displays, so that the visual view of each ship is independently output to the corresponding physical display for full-screen monitoring.

5. The method for real-time remote control and adaptive split-screen monitoring of multiple ships according to claim 4, characterized in that, The adaptive split-screen monitoring uses external shadow camera synchronization technology for visual output, specifically including: Assign a separate external rendering camera to each display area or physical monitor; At the end of each frame's rendering loop, the real-time spatial pose parameters of the local camera selected by the target ship are obtained through the core mapping data container. The position of the external rendering camera is calculated using a progressive damping smoothing algorithm based on the real-time spatial pose parameters of the local camera. By introducing a dynamic weight coefficient based on the frame interval time, the external rendering camera smoothly approaches the target position in a non-linear progressive manner. The spherical linear interpolation algorithm is used to synchronize the rotation posture of the externally rendered camera. The interpolation transition is performed by calculating the shortest path between the current posture and the target posture in the quaternion space. When the minimum angle between the two is detected, the spherical linear interpolation algorithm is switched to the standard linear interpolation algorithm, and the standard linear interpolation calculation results are normalized.

6. The method for real-time remote control and adaptive split-screen monitoring of multiple ships according to claim 5, characterized in that, The adaptive split-screen monitoring also includes interactive panoramic monitoring, specifically including: Based on the comparison between the real-time input scaling factor and the preset switching threshold, two different camera parameter adjustment modes are automatically selected and executed: When the real-time zoom factor is lower than the switching threshold, the optical zoom mode is entered, keeping the camera's physical position in world space unchanged and dynamically adjusting its field of view attribute so that the observation angle changes continuously between the preset maximum wide angle and minimum close-up field of view. When the real-time scaling factor exceeds the switching threshold, the system switches to physical displacement mode, locks the camera's field of view to its maximum value, and smoothly shifts the position along the camera's optical axis based on the proportion exceeding the threshold.

7. The method for real-time remote control and adaptive split-screen monitoring of multiple ships according to claim 1, characterized in that, Also includes: Real-time acquisition of the velocity vector of the ship's rigid body in the world coordinate system, and decomposition of the velocity vector into longitudinal and transverse velocity components in the local coordinate system of the ship hull; Independent fluid drag coefficients are set for the longitudinal velocity component and the lateral velocity component, and the lateral drag coefficient is set to be significantly higher than the longitudinal drag coefficient, in order to simulate the anisotropic characteristics of the ship's motion in the fluid. When simulating ship turning, the coordinates of the geometric pivot points at the stern of the hull are calculated in real time; Lateral thrust is applied at the geometric pivot point at the stern of the hull via the physical engine interface, thereby generating a steering torque based on the lever arm, so that the ship produces a drift trajectory and turning characteristics that conform to physical laws when turning.

8. A multi-ship real-time remote control and adaptive split-screen monitoring system, characterized in that, include: A creation module is used to create a core mapping data container, which is used to encapsulate each ship in the simulation scenario with its unique identifier, entity object reference, physical control component reference, and automatic navigation script reference; The control and monitoring module is used to synchronously execute dual-mode control switching and adaptive split-screen monitoring for the target ship based on the core mapping data container. The dual-mode control switching includes mutually exclusive switching between automatic and manual control modes, and thermal synchronization of ship dynamic state parameters through a reflection mechanism at the moment of switching. The adaptive split-screen monitoring includes detecting the number of physical display devices, performing viewport splitting when there is a single display device, and performing multi-target display mapping when there are multiple display devices.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the multi-ship real-time remote driving and adaptive split-screen monitoring method according to any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-ship real-time remote driving and adaptive split-screen monitoring method according to any one of claims 1 to 7.

Images