Method, system, device and medium for controlling multi-vehicle collaborative music light show

Abstract

The embodiment of the application belongs to the technical field of vehicle control, and particularly relates to a control method, system, device and medium for a multi-vehicle cooperative music light show. The embodiment aims to solve the problems of the existing multi-vehicle music light show, such as rough music understanding, insufficient vehicle cooperation level, easy influence of communication time delay on execution synchronization, and poor consistency between virtual display and real vehicle linkage. To this end, based on target music and vehicle role attributes, time-space control information and digital twin rendering information adapted to music content are respectively generated for multiple target vehicles, wherein the control information carries absolute execution time bound to vehicle actions, each vehicle completes light, posture or formation action according to a unified time reference, and a user terminal synchronously drives corresponding virtual vehicle model display. The scheme can improve the dynamic arrangement capability, execution synchronization and virtual-real consistency of the multi-vehicle performance, and enhance the performance level, continuity and immersive interactive experience.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, specifically to a control method, system, device, and medium for a multi-vehicle coordinated music and light show. Background Technology

[0002] With the development of intelligent driving technology, vehicle lighting interaction is evolving from basic signal functions to emotional expression and scenario-based performance. Music and light shows, as a new type of intelligent vehicle performance, use musical rhythms to control the vehicle's external lights for synchronized displays.

[0003] Among related technologies, vehicle light and music shows mainly fall into three categories: First, a fixed light show program is built into the vehicle, triggering a preset light sequence based on music. Second, simple commands, such as flashing or gradual changes, are broadcast to multiple vehicles via a wireless network. Third, virtual information, such as vehicle speed and brand information, is overlaid on the user's terminal using augmented reality technology.

[0004] However, the aforementioned vehicle light shows mostly rely on preset programs or simple command synchronization, which makes it difficult to meet the needs of dynamic choreography, high-precision synchronization and real-time user interaction in complex scenarios, resulting in problems such as monotonous performance forms, high response latency and poor interactivity. Summary of the Invention

[0005] This application provides a control method for a multi-vehicle collaborative music and light show. It is designed for multi-vehicle collaborative performance scenarios and uses unified control and collaborative presentation based on the target music and the role division of different vehicles. This enables each target vehicle to form corresponding action choreography based on the music content and keeps the real vehicle performance and virtual display content linked, thereby improving the dynamic adaptability, collaborative synchronization and virtual-real interaction effects of multi-vehicle performances as the music changes.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0007] In a first aspect, embodiments of this application provide a control method for a multi-vehicle coordinated music and light show, the method comprising:

[0008] Obtain the target music and the character attributes of at least two target vehicles;

[0009] Based on the target music and character attributes, generate a corresponding spatiotemporal instruction package and rendering instruction sequence for each of the at least two target vehicles; the spatiotemporal instruction package includes a vehicle action instruction sequence and an absolute execution timestamp bound to each vehicle action instruction sequence;

[0010] The spatiotemporal instruction packet is sent to each target vehicle so that each target vehicle executes the corresponding vehicle action instruction sequence when the absolute execution timestamp arrives.

[0011] The rendering instruction sequence is sent to the user terminal so that the user terminal can drive the virtual vehicle model corresponding to each target vehicle according to the rendering instruction sequence.

[0012] In one possible embodiment, based on the target music and character attributes, a corresponding spatiotemporal instruction package and rendering instruction sequence are generated for each of at least two target vehicles, including:

[0013] Hierarchical labels are used to decompose the target music to obtain beat points, melodic features, and / or emotional vectors;

[0014] Based on the beat point, melody features and / or emotion vector, as well as the role attributes of each target vehicle, a corresponding spatiotemporal instruction package is generated for each target vehicle; the role attributes include the navigator role, the backup dancer role, and / or the background role.

[0015] Generate a sequence of rendering instructions corresponding to the spatiotemporal instruction package.

[0016] In one possible embodiment, after sending the spatiotemporal command packet to each target vehicle, the method further includes:

[0017] Receive interactive operation instructions from the user terminal; the interactive operation instructions include target action parameters and target virtual vehicle identifier;

[0018] Generate incremental instruction packets based on the target action parameters;

[0019] Send the incremental instruction packet to the target vehicle corresponding to the target virtual vehicle identifier;

[0020] The execution status feedback from each target vehicle is sent to the user terminal, so that the user terminal can construct a twin scene aligned with the real scene based on the rendering instruction sequence and execution status.

[0021] Secondly, embodiments of this application provide a control method for a multi-vehicle coordinated music and light show, the method comprising:

[0022] Send the vehicle's role attributes to the cloud server;

[0023] Receive the spatiotemporal instruction packet sent by the cloud server; the spatiotemporal instruction packet is generated by the cloud server based on the obtained target music and character attributes, and the spatiotemporal instruction packet includes the vehicle action instruction sequence and the absolute execution timestamp bound to the vehicle action instruction sequence;

[0024] When the time point corresponding to the absolute execution timestamp is reached, the corresponding vehicle action command sequence is executed;

[0025] The system sends feedback to the cloud server regarding the execution status of the vehicle action command sequence.

[0026] In one possible embodiment, the execution of the corresponding vehicle action command sequence includes:

[0027] Control the vehicle's suspension and / or multi-zone lighting to work in real time in a coordinated manner.

[0028] In one possible embodiment, the method further includes:

[0029] The vehicle exchanges its execution status with the adjacent vehicles and the absolute execution timestamp of the next vehicle action instruction, and performs cross-validation; the next vehicle action instruction is the vehicle action instruction that follows the current vehicle action instruction in the vehicle action execution sequence.

[0030] If the cross-validation result does not meet the collaborative execution conditions, the preset degradation mode is triggered.

[0031] Thirdly, embodiments of this application provide a control method for a multi-vehicle coordinated music and light show, the method comprising:

[0032] Receive a sequence of rendering instructions sent by the cloud server; the rendering instructions are generated by the cloud server based on the target music and the vehicle's character attributes.

[0033] Drive the virtual vehicle model corresponding to each vehicle according to the rendering instruction sequence;

[0034] Receive execution status from the cloud server;

[0035] Based on the rendering instruction sequence and execution state, a twin scene is constructed that is aligned with the real scene.

[0036] In one possible embodiment, after constructing the twin scene aligned with the real scene, the method further includes:

[0037] In response to interactive operations on the virtual vehicle model in the twin scene, an interactive operation command is generated; the interactive operation command includes the target action parameters and the target virtual vehicle identifier;

[0038] The interactive operation command is sent to the cloud server, so that the cloud server generates an incremental command package based on the target action parameters and sends it to the vehicle corresponding to the target virtual vehicle identifier.

[0039] In one possible embodiment, in response to interactive operations on the virtual vehicle model in the twin scene, interactive operation instructions are generated, including:

[0040] In response to dragging operations on the virtual vehicle model in the twin scene, corresponding lighting motion choreography instructions are generated;

[0041] And / or, in response to a click operation on the virtual vehicle model in the twin scene, generate a corresponding lighting effect upgrade command;

[0042] And / or, in response to a sliding adjustment operation on the emotion vector of the virtual vehicle model in the twin scene, generate a performance intensity adjustment instruction.

[0043] Fourthly, embodiments of this application provide a control system for a multi-vehicle coordinated music and light show, the system comprising:

[0044] A cloud server for performing the methods provided by the first aspect and / or various possible implementations of the first aspect;

[0045] At least two vehicles, each vehicle being used to perform the methods provided by the second aspect and / or various possible implementations of the second aspect;

[0046] A user terminal for executing the methods provided by the third aspect and / or various possible implementations of the third aspect.

[0047] Fifthly, embodiments of this application provide an electronic device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method provided above.

[0048] Sixthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods provided above.

[0049] The control method, apparatus, device, and storage medium for a multi-vehicle collaborative music and light show provided in this application embodiment acquires target music and the role attributes of at least two target vehicles, and generates corresponding spatiotemporal instruction packages and rendering instruction sequences for each target vehicle based on the target music and role attributes. Simultaneously, it sends spatiotemporal instruction packages containing vehicle action instruction sequences and absolute execution timestamps bound to each vehicle's action instruction sequence to each target vehicle, and sends rendering instruction sequences to the user terminal. This enables multiple vehicles to achieve differentiated collaborative arrangement based on music content and role division, and to execute corresponding actions according to absolute execution timestamps under a unified time base. This improves the synchronization accuracy between multi-vehicle performances and music rhythm, enhances the real-time linkage between real vehicles and virtual vehicle models, and improves the overall coherence, visual appeal, and interactive experience of the light show. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of the control system for a multi-vehicle cooperative music and light show according to an embodiment of this application;

[0051] Figure 2 This is an architecture diagram of the control system for a multi-vehicle cooperative music and light show according to an embodiment of this application;

[0052] Figure 3A flowchart illustrating the control method for a multi-vehicle coordinated music and light show provided in an embodiment of this application;

[0053] Figure 4 A schematic diagram illustrating the process of generating a spatiotemporal instruction packet in the method provided in the embodiments of this application;

[0054] Figure 5 A flowchart illustrating another control method for a multi-vehicle cooperative music and light show provided in an embodiment of this application;

[0055] Figure 6 A schematic diagram illustrating vehicle timing synchronization in the method provided in the embodiments of this application;

[0056] Figure 7 A flowchart illustrating another control method for a multi-vehicle cooperative music and light show provided in an embodiment of this application;

[0057] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0058] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the embodiments of this application from the content disclosed in this specification. The embodiments of this application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the embodiments of this application. It should be understood that the preferred embodiments are only for illustrating the embodiments of this application and are not intended to limit the scope of protection of the embodiments of this application.

[0059] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the embodiments of this application. Therefore, the drawings only show the components related to the embodiments of this application and are not drawn according to the actual number, shape and size of the components. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0060] Multi-vehicle collaborative music and light show control technology involves intelligent connected vehicle control, group performance scheduling, and virtual display linkage, and is typically used in scenarios such as music festivals, urban light shows, brand launch events, and large-scale outdoor celebrations. In these scenarios, multiple vehicles need to perform light, posture, or formation-related actions based on the same music content, and the corresponding virtual display effects are synchronously presented on the user's terminal.

[0061] Existing vehicle light and music show solutions typically employ preset program control, with a central terminal broadcasting action commands to multiple vehicles, or using a terminal to display the vehicle performance using augmented reality. The basic approach often involves pre-setting several light program templates, triggering them uniformly according to a timeline during the performance, or issuing the same or similar control content to each vehicle based on simplified beat signals.

[0062] However, this type of solution has a rather superficial understanding of the music content, often only able to execute preset actions around fixed rhythm points, making it difficult to combine the roles of different vehicles to form a layered and differentiated collaborative performance. Especially when the music's mood, melody climax, or section changes rapidly, the existing solution cannot adjust the actions of each vehicle in real time, resulting in monotonous and abrupt performance content.

[0063] Meanwhile, when multi-vehicle control relies on real-time transmission via communication links, it is easily affected by network latency, jitter, and terminal execution deviations, causing misalignment between the actions of different vehicles and the music beat; and virtual displays usually only serve as a one-way presentation interface, making it difficult to maintain a high degree of consistency with the real vehicle status, thus affecting the continuity of the performance, immersion, and interactive experience.

[0064] In view of this, how to balance the dynamic choreography capabilities driven by music, the synchronization of multi-vehicle execution, and the linkage between virtual display and real vehicles in a multi-vehicle collaborative performance scenario has become an urgent technical problem to be solved. To address the above problems, this application provides a control method for a multi-vehicle collaborative music and light show. By acquiring the target music and the role attributes of at least two target vehicles, a corresponding spatiotemporal instruction package and rendering instruction sequence are generated for each target vehicle. The vehicle action instruction sequence, containing an absolute execution timestamp, is sent to each target vehicle for execution. Simultaneously, the rendering instruction sequence is sent to the user terminal to drive the corresponding virtual vehicle model, thereby achieving collaborative control between real vehicle performance and virtual display.

[0065] Figure 1 This is a schematic diagram of the control system for a multi-vehicle cooperative music and light show according to an embodiment of this application. Figure 2 This is an architecture diagram of the control system for a multi-vehicle cooperative music and light show according to an embodiment of this application. (Combined with...) Figure 1 and Figure 2 The control system for a multi-vehicle collaborative music and light show provided in this application embodiment may include a cloud server, at least two vehicles, and a user terminal.

[0066] The cloud server can generate corresponding vehicle action control content and virtual display control content based on the target music and the attributes of each vehicle role, and perform unified scheduling and distribution. When at least two vehicles execute the method, they can complete lighting, posture, or formation actions that match the music according to the received control content. When the user terminal executes the method, it can drive the virtual vehicle model to be presented synchronously according to the corresponding control content. Thus, through the collaborative cooperation of the cloud server, vehicles, and user terminals, the real vehicle performance, control scheduling, and virtual display form a unified closed loop, reducing the desynchronization problem caused by fixed programs, single roles, or link fluctuations in multi-vehicle performances. This improves the flexibility of music-driven choreography, the consistency of vehicle group actions, and the immersive and interactive effects during the performance.

[0067] Specifically, the cloud server (cloud-based) can include a music database and AI orchestration and synchronization services; the music database contains a variety of pre-loaded music tracks. The AI ​​orchestration and synchronization services can be further divided into AI music deconstruction, multi-agent orchestration, and global spatiotemporal synchronization services. The AI ​​music deconstruction module breaks down the input music according to multi-level tags, including beat points, melody climaxes, and emotional vectors (exhilarating / soothing). The multi-agent orchestration module treats each vehicle as an agent, generating differentiated spatiotemporal instruction packages for each agent based on its role in the formation (navigator, backup, background). These instruction packages include lighting instruction sequences, micro-motion instruction sequences, and digital twin system rendering instruction sequences. The lighting instruction sequences control the brightness and mode of each light fixture. The micro-motion instruction sequences control the suspension's undulation rhythm. The digital twin rendering instruction sequences are simplified data used to drive the virtual model. The global spatiotemporal synchronization service, based on the IEEE 1588 (PTP) protocol, provides a microsecond-level unified clock for the entire system, with all instructions bound to precise absolute execution timestamps (T_execution).

[0068] The vehicle side can include multiple vehicles, such as Figure 2 As shown, the system includes vehicles A, B, and C, each equipped with a Junbaokang in-vehicle IoT network management system, a lighting control module, a suspension control module, and an edge collaboration module. The in-vehicle IoT gateway receives and temporarily stores spatiotemporal command packets from the cloud. The lighting and suspension control modules employ Time-Triggered Ethernet (TTEthernet) technology to ensure deterministic and low-latency transmission of lighting and micro-motion commands within the vehicle's internal network, enabling precise control of real-time collaborative operation of lighting and suspension in multiple areas. The edge collaboration module facilitates the exchange of local execution status and timestamps for the next critical command between vehicles, performing cross-validation. If an adjacent vehicle is not ready, a locally preset simplified degradation mode can be triggered to ensure performance continuity.

[0069] The user terminal (i.e., the user end) can include a twin rendering engine and an interactive interface. The twin rendering engine is used to construct a twin scene that can be aligned with the real scene. The twin rendering engine simultaneously receives a unified command stream from the cloud (for prediction) and a real-time status feedback stream from the vehicle (for calibration). The interactive interface can include a control layer and an audience interaction layer. The control layer provides a timeline editor, allowing users to drag and drop virtual vehicle models to directly arrange lighting actions and generate new scripts. The audience interaction layer refers to interactive areas on the virtual vehicle models in the twin scene. When the audience clicks on a vehicle, its lighting effects can be upgraded; or by swiping, the "emotional vector" of a song can be adjusted in real time from "soothing" to "exhilarating," with cloud AI dynamically adjusting the performance intensity of all vehicles simultaneously.

[0070] This application's embodiments achieve high-precision synchronization of music and light shows based on an absolute timestamp strategy. The cloud server no longer relies on fragile real-time command streams, but instead pre-deploys complete timing packets with absolute timestamps. Each node (vehicle and user terminal) autonomously executes at the absolute execution timestamp based on a locally synchronized high-precision clock, fundamentally eliminating the impact of network latency. All interactions between the user terminal and the vehicle occur in a virtual twin scenario and are instantly translated into control commands fed back to the cloud, affecting the real vehicle. This ensures the real-time performance and consistency of the interaction.

[0071] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0072] Figure 3 This is a flowchart illustrating the control method for a multi-vehicle coordinated music and light show provided in an embodiment of this application. Figure 3 As shown, the method provided in this embodiment can be executed by a cloud server in the control system of a multi-vehicle collaborative music and light show. Specifically, the method provided in this embodiment may include:

[0073] S101: Obtain the target music and the character attributes of at least two target vehicles.

[0074] The target music serves as the driving input for the entire multi-vehicle collaborative music and light show, representing the audio content to be choreographed. The target vehicle represents the set of vehicles participating in the collaborative performance, with at least two vehicles, each possessing lighting control capabilities and potentially posture control capabilities. Role attributes represent the different roles of each target vehicle within the same choreography.

[0075] In practice, in response to the user's program creation operation on the user terminal, the target music file is read from the program resource library, and the vehicle identification, vehicle capability parameters and corresponding role attributes of the vehicles participating in the performance are read from the vehicle formation configuration table; alternatively, the target music and role mapping relationship can be loaded all at once from the pre-stored program project file during the program pre-arrangement stage.

[0076] To ensure the integrity of the basic data for subsequent command generation, the target music undergoes format parsing upon import, extracting audio duration, sampling rate, channel information, and playback start reference time, and establishing a unified timeline. Character attributes are bound to the vehicle's unique identifier after loading, forming a vehicle character index table. For the target vehicle, basic execution constraints for each vehicle can also be read, including the number of light channels, executable action types, action duration limits, and the vehicle's local clock status, to generate executable and distinct control content under the same music driver.

[0077] S102: Based on the target music and character attributes, generate a corresponding spatiotemporal instruction package and rendering instruction sequence for each of the at least two target vehicles; the spatiotemporal instruction package includes a vehicle action instruction sequence and an absolute execution timestamp bound to each vehicle action instruction sequence.

[0078] In this step, the spatiotemporal instruction package is used to carry the control content sent to each target vehicle. The vehicle action instruction sequence is the set of actions actually performed by the vehicle, and the absolute execution timestamp is used to limit the precise trigger time of each action. The rendering instruction sequence is used to drive the virtual vehicle model in the user terminal, so that the virtual display and the vehicle-side arrangement are consistent.

[0079] In practice, based on the unified music timeline and character attributes obtained from S101, the performance content of each target vehicle is arranged, and a vehicle action command sequence is generated for each target vehicle. The actions in the vehicle action command sequence can include lighting control actions and other actions adapted to the vehicle's capabilities, such as suspension undulation and suspension height adjustment. The action commands can include information such as action type, action parameters, start time, duration, and end state.

[0080] The absolute execution timestamp is generated using a unified time base. It can be based on the program's start time T0, mapping the relative position Δt of each action on the music timeline to an absolute execution timestamp T = T0 + Δt. For actions requiring simultaneous execution by multiple vehicles, the corresponding instructions from different vehicles are bound to the same absolute execution timestamp; for actions requiring differentiated performance effects, different vehicles can be bound to different but interconnected absolute execution timestamps.

[0081] The rendering instruction sequence is generated one-to-one with each target vehicle. Its content shares the same music timeline and choreography logic as the vehicle action instruction sequence, but it is expressed in relation to the virtual vehicle model on the user terminal. The rendering instructions can include virtual vehicle position updates, posture changes, lighting and material parameters, and scene display control. In this way, vehicle action control and virtual rendering control originate from the same choreography result, are constrained by the same absolute time base in time, and are associated with the corresponding vehicle's role attributes in terms of content.

[0082] For example, such as Figure 4 As shown, for the input target music, it can be deconstructed into beat point 1 with an exciting emotional vector; beat point 2 with a soothing emotional vector; and beat point 3 with a lively emotional vector. After deconstruction, a sequence of control commands with absolute execution timestamps is generated and sent to the vehicle.

[0083] For example, the command sequence for vehicle 1 is: T1 (beat point 1), light mode flashing, suspension height adjustment; T2 (beat point 2), light mode left flowing, suspension stationary; T3 (beat point 3), light mode left gradually dimming, suspension slightly undulating. The command sequence for vehicle 2 is: T1 (beat point 1), light mode breathing, suspension height adjustment; T2 (beat point 2), light mode right flowing, suspension stationary; T3 (beat point 3), light mode right gradually dimming, suspension slightly undulating. The command sequence for vehicle 3 is: T1 (beat point 1), light mode flashing, suspension height adjustment; T2 (beat point 2), light mode dispersed flowing, suspension stationary; T3 (beat point 3), light mode converging meteor, suspension slightly undulating.

[0084] S103: Send the spatiotemporal instruction packet to each target vehicle so that each target vehicle executes the corresponding vehicle action instruction sequence when the absolute execution timestamp arrives.

[0085] In this step, the spatiotemporal command packets can be sent to each target vehicle via cellular mobile communication links, vehicle-mounted dedicated wireless communication links, local area wireless network links, or wired debugging links. To ensure that each vehicle understands the absolute execution timestamp consistently, the cloud server synchronizes its clock with each target vehicle and user terminal before sending the spatiotemporal command packets. Based on the IEEE 1588 (PTP) protocol, a unified clock at the microsecond level is provided for the entire system, and all commands are bound to this precise absolute execution timestamp.

[0086] When the spatiotemporal instruction packet is sent, the corresponding spatiotemporal instruction packet is sent according to the vehicle identifier. After receiving the spatiotemporal instruction packet, each target vehicle can first perform packet body verification. The verification content includes at least program identifier matching, vehicle identifier matching, version number validity, integrity verification field verification, and absolute execution timestamp sequence integrity check. After the verification is passed, the vehicle action instruction sequence and its bound absolute execution timestamp are written into the local execution buffer, and a queue to be executed is established in chronological order.

[0087] Each action in the vehicle action command sequence can be further parsed into low-level control signals at the vehicle end, such as light color values, PWM (Pulse Width Modulation) duty cycles, CAN (Controller Area Network) control frames, or actuator control quantities. The on-board controller continuously monitors the local clock, and when the corresponding absolute execution timestamp is reached, it immediately triggers the corresponding action and maintains the execution state according to the duration of the action until the end time.

[0088] In the case of continuous actions, the vehicle controller retrieves and executes each action in sequence according to the time sequence to ensure that the actions inside a single vehicle are consistent with the music progress. In the case of multiple vehicles sharing the same absolute execution timestamp, each vehicle can execute in parallel without relying on real-time network transmission since it has received and cached the action sequence in advance. This allows multiple vehicles to perform synchronously under a unified time base.

[0089] In practical applications, the target vehicle can also record the deviation between the actual trigger time and the corresponding absolute execution timestamp during the execution of actions, which can be used for status monitoring or log feedback in the later stages of the performance.

[0090] S104: Send the rendering instruction sequence to the user terminal so that the user terminal can drive the virtual vehicle model corresponding to each target vehicle according to the rendering instruction sequence.

[0091] Specifically, the user terminal can be a mobile terminal, a tablet terminal, a large screen control terminal for the auto show, an augmented reality display device, or a virtual reality display device. The rendering instruction sequence is used to drive the virtual vehicle model corresponding to each target vehicle, where the virtual vehicle model includes at least the vehicle's external shape, position and attitude state, and lighting display parameters.

[0092] In practice, the cloud server sends the rendering instruction sequence corresponding to each target vehicle, along with the program identifier, vehicle identifier, and time reference information, to the user terminal. Upon receiving this information, the user terminal establishes a mapping relationship between the virtual vehicle model and the real target vehicle, using the program start time T0 as the unified playback starting point. After parsing the rendering instructions, the user terminal updates the display state of the corresponding virtual vehicle model in its local rendering engine based on the time parameters and model state parameters. For example, it triggers virtual light changes, vehicle posture changes, trajectory displacements, or formation display changes at the absolute moments corresponding to the real vehicle action instructions.

[0093] When real vehicles and user terminal displays need to be displayed together, the user terminal can synchronously update the vehicle position, action status and lighting effects in the virtual scene according to the rendering instruction sequence, so that the real vehicle performance and the virtual vehicle model present the same program content.

[0094] The control method for a multi-vehicle collaborative music and light show provided in this application involves: acquiring target music and the role attributes of at least two target vehicles; generating a corresponding spatiotemporal instruction package and rendering instruction sequence for each of the at least two target vehicles based on the target music and role attributes; the spatiotemporal instruction package including a vehicle action instruction sequence and an absolute execution timestamp bound to each vehicle action instruction sequence; sending the spatiotemporal instruction package to each target vehicle so that each target vehicle executes the corresponding vehicle action instruction sequence when the absolute execution timestamp arrives; and sending the rendering instruction sequence to the user terminal so that the user terminal drives the virtual vehicle model corresponding to each target vehicle according to the rendering instruction sequence. Therefore, by using the target music and the target vehicle's role attributes as choreography inputs, vehicle action command sequences with role differences are generated for different vehicles. Each vehicle action command sequence is bound to an absolute execution timestamp and pre-sent to the vehicle, enabling the vehicle to execute the corresponding actions under a unified local time base. At the same time, the rendering command sequence generated from the same source is sent to the user terminal to drive the virtual vehicle model. The real vehicle performance and virtual display thus establish the same program logic, the same time logic, and a one-to-one mapping relationship, which can adapt to collaborative performance scenarios and realize the synchronous execution of multiple vehicles and the linkage of terminal-side display.

[0095] Based on the aforementioned embodiments, the process of generating a corresponding spatiotemporal instruction package and rendering instruction sequence for each of at least two target vehicles, according to the target music and character attributes, may include: decomposing the target music using hierarchical tags to obtain beat points, melodic features, and / or emotional vectors; generating a corresponding spatiotemporal instruction package for each target vehicle based on the beat points, melodic features, and / or emotional vectors, as well as the character attributes of each target vehicle; the character attributes include a navigator character, a backup dancer character, and / or a background character; and generating a rendering instruction sequence corresponding to the spatiotemporal instruction package.

[0096] The hierarchical labels are used to structurally annotate the target music according to paragraphs, phrases, measures, and beats, and map the annotation results into time features, melodic features, and emotional features that can be called by the control module. Beat points can be extracted by the audio detection module combining peak energy, zero-crossing rate, and beat tracking results. Melodic features can be formed by pitch contours, main melody trends, and harmonic changes. The emotional vector can be output by a pre-trained music emotion model, and its dimensions correspond to representations such as tension, joy, and excitement.

[0097] When generating spatiotemporal instruction packages, differentiated choreography rules can be established based on the role attributes of each target vehicle. For example, the navigator role corresponds to a set of actions with prominent main beats and large changes in posture, the backup dancer role corresponds to a set of coordinated actions synchronized with the melody's rise and fall, and the background role corresponds to a set of actions mainly consisting of low-frequency flashing, gradual posture changes, and formation filling. The resulting spatiotemporal instruction package can include vehicle lighting patterns, motion trajectories, posture switching times, and durations, and bind them to beat points and emotion vectors.

[0098] The rendering instruction sequence corresponding to the spatiotemporal instruction package is used to drive the synchronous rendering of the virtual vehicle model on the user terminal side. This sequence may include model pose parameters, lighting and material parameters, color transition parameters, and animation interpolation parameters, and is arranged according to the same absolute timing sequence as the real vehicle, ensuring that the virtual vehicle model's actions, lighting effects, and role assignments are consistent with the target vehicle at the display level. In practical applications, the rendering instruction sequence can also use other model formats or rendering engine interfaces; this application does not limit this.

[0099] By decomposing the target music into choreographable hierarchical features, vehicles with different roles can obtain spatiotemporal instruction packages that match their responsibilities, thereby enabling the coordinated output of real vehicle actions and digital twin displays under the same musical structure. This implementation allows the lead, backup, and background vehicles to form a clear hierarchical performance relationship and keeps the virtual vehicle models consistent with the status of the vehicles on site, thus improving the synchronization and visual continuity of multi-vehicle collaborative performances.

[0100] In one possible implementation, after sending the spatiotemporal instruction packet to each target vehicle, the method provided in this embodiment may further include: receiving an interactive operation instruction from a user terminal; the interactive operation instruction includes target action parameters and a target virtual vehicle identifier; generating an incremental instruction packet based on the target action parameters; sending the incremental instruction packet to the target vehicle corresponding to the target virtual vehicle identifier; and sending the execution status feedback from each target vehicle to the user terminal, so that the user terminal can construct a twin scene aligned with the real scene based on the rendering instruction sequence and the execution status.

[0101] In actual execution, user terminals can generate interactive operation commands through touch interfaces, mouse clicks, or gesture input. After receiving the commands, the control platform parses the target action parameters and the target virtual vehicle identifier, and generates an incremental command package compatible with the current performance choreography based on the target action parameters. This incremental command package may include action type, duration, amplitude correction amount, lighting change parameters, or formation fine-tuning parameters, and is sent to the corresponding target vehicle after establishing a mapping relationship with the target virtual vehicle identifier, enabling the vehicle to complete local adjustments without re-receiving all spatiotemporal command packages.

[0102] During execution, each target vehicle transmits its current action completion status, timing deviation, light response status, or communication confirmation results back to the control platform, which then sends them to the user terminal. Based on this, the user terminal updates the position, posture, and display status of the virtual vehicle model in conjunction with the issued rendering command sequence, thereby forming a twin scene that is consistent with the real scene.

[0103] In this embodiment, by incrementally processing the interactive operation commands and sending the execution status back to the user terminal, local dynamic correction can be achieved while maintaining the continuity of the original spatiotemporal arrangement. At the same time, the virtual display and the real vehicle actions are kept in sync, thereby improving scene consistency and interactive linkage effects.

[0104] Figure 5 A flowchart illustrating another control method for a multi-vehicle cooperative music and light show provided in an embodiment of this application. Figure 5 As shown, the control method for the multi-vehicle cooperative music and light show in this embodiment can be executed by any vehicle in the aforementioned multi-vehicle cooperative music and light show control system. Specifically, the method in this embodiment may include:

[0105] S201: Send the vehicle's role attributes to the cloud server.

[0106] Specifically, the vehicle's role attributes are used to describe the division of labor information of the current vehicle in the multi-vehicle collaborative music and light show, and the cloud server is used to carry out the generation, distribution and processing of spatiotemporal instruction packets.

[0107] Before the performance begins, the vehicle first establishes a role attribute data item locally. The role attribute data item includes at least the vehicle identifier, role category, and task batch identifier. The role category is used to distinguish the vehicle's functional positioning in the choreography. For example, the role attribute can be a lead vehicle, a backup dancer vehicle, or a background vehicle.

[0108] Character attributes can be pre-configured and written to the vehicle controller from the backend, or written by the on-site dispatch terminal via the near-field configuration link, or updated and re-uploaded by the cloud server based on the overall choreography results during the performance.

[0109] Before sending role attributes, the vehicle first obtains a standard time reference through the time synchronization module. This standard time reference can come from satellite timing signals, cellular network timing signals, or cloud-based time synchronization results. Subsequently, the vehicle communication unit establishes a data connection with the cloud server. The data connection can be a cellular mobile communication connection, a dedicated short-range communication connection, or a vehicle-to-everything (V2X) communication link.

[0110] After the connection is established, the vehicle controller encapsulates the role attribute data items into an upload message containing the vehicle identifier, current role category, effective time, and verification fields, and sends it to the cloud server. Once the role attributes are uploaded, the vehicle can wait for the cloud server to return a confirmation message.

[0111] S202: Receive the spatiotemporal instruction packet sent by the cloud server; the spatiotemporal instruction packet is generated by the cloud server based on the obtained target music and character attributes, and includes the vehicle action instruction sequence and the absolute execution timestamp bound to the vehicle action instruction sequence.

[0112] The process of generating the spatiotemporal instruction package can be referred to the description in the above method embodiments, and will not be repeated here.

[0113] In this step, since the spatiotemporal instruction packet directly contains the sequence of vehicle action instructions bound to the absolute execution timestamp, the vehicle can enter the local waiting execution state after receiving the data, without having to continuously rely on real-time control commands at each beat point. Therefore, network jitter mainly affects the time of instruction packet reception and does not directly change the time of action triggering. Multiple vehicles can complete synchronous or staggered actions around the same time base, thus maintaining the temporal consistency of the actual performance.

[0114] like Figure 6 As shown, the cloud server broadcasts a spatiotemporal instruction packet at time T0, which contains instructions for times T1, T2, T3, etc. Vehicle A receives this instruction packet at time T0A, with a network latency of [missing information]. Vehicle B receives the instruction packet at time T0B, with a network latency of [missing information]. Vehicle C receives the instruction packet at time T0C, with a network latency of [missing information]. When the local clock reaches T1, vehicles A, B, and C simultaneously execute instruction 1; when the local clock reaches T2, vehicles A, B, and C simultaneously execute instruction 2; and when the local clock reaches Tn, vehicles A, B, and C simultaneously execute instruction n. It is evident that, based on IEEE 1588, it can be ensured that even when the times at which the vehicles receive the action instructions from each vehicle in the spatiotemporal instruction packet differ, the execution times remain completely consistent.

[0115] S203: When the time point corresponding to the absolute execution timestamp is reached, execute the corresponding vehicle action command sequence.

[0116] Specifically, after the vehicle completes the parsing of the spatiotemporal instruction package, it can register each vehicle action instruction sequence in the local scheduling table. The local scheduling table includes at least the sequence identifier, absolute execution timestamp, trigger status, execution status, and the mapping relationship of the corresponding execution component.

[0117] When the current local time reaches or enters the trigger window corresponding to the absolute execution timestamp, the vehicle controller switches the target vehicle action command sequence from the waiting state to the execution state, and sequentially calls the interfaces of each execution component to issue action units. For combined actions, the vehicle controller issues multiple sub-actions in a predetermined order, and controls the start time of the next sub-action based on the duration of the action; for other actions, the vehicle controller sends the action command to the corresponding execution component interface to complete the execution.

[0118] If the same absolute execution timestamp is bound to multiple action units, the vehicle controller will trigger them synchronously according to the parallel action group; if multiple absolute execution timestamps are arranged consecutively in chronological order, the vehicle controller will execute them one by one according to the local scheduling table until all the sequences to be executed in the current spatiotemporal instruction packet are completed.

[0119] It is understandable that, in order to ensure the accuracy of the triggering time, the vehicle controller can preload the action parameters into the corresponding actuator buffer before the absolute execution timestamp, and send the start signal only at the target time point, thereby reducing the impact of the actuator instruction parsing delay on the performance rhythm.

[0120] S204: Report the execution status of the vehicle action command sequence to the cloud server.

[0121] The execution status of the vehicle action command sequence is used to represent the actual execution result of the vehicle on the received command. The cloud server can implement subsequent collaborative control and orchestration adjustments based on this execution status.

[0122] For example, in a specific implementation, the vehicle controller generates a status record item after each vehicle action command sequence is initiated and executed. The status record item includes at least the vehicle identifier, task batch identifier, action sequence number, trigger time, current status code, and exception code. The current status code can include execution in progress, execution completed, execution failed, partial completion, or cancellation. The exception code is used to indicate specific situations such as actuator non-response, parameter out-of-bounds, component conflict, time synchronization failure, or communication interruption.

[0123] For vehicle action command sequences containing multiple action units, the on-board controller can also record execution progress information, which includes at least the number of completed action units, the current action unit sequence number, and the number of remaining action units. The on-board communication unit sends the execution status of the vehicle action command sequence to the cloud server according to either an event-triggered method or a periodic reporting method. The event-triggered method is suitable for immediate reporting when an action is started, completed, or when an anomaly occurs, while the periodic reporting method is suitable for progress reporting of long-term continuous actions.

[0124] In this way, after receiving the execution status feedback from each vehicle, the cloud server merges the data according to vehicle identifiers and action sequence numbers to construct a global execution view of the current performance. When a vehicle reports an execution failure or an anomaly, the cloud server can adjust subsequent spatiotemporal instruction packets to ensure that the overall visuals still correspond to the segment structure of the target music. After receiving the updated scheduling information returned by the cloud server, the vehicles treat it as the new version of the spatiotemporal instruction packet and continue to parse and execute it.

[0125] Therefore, by continuously feeding back the execution status of the vehicle action command sequence, the cloud server no longer relies solely on static control based on a preset program schedule, but obtains the actual response results of each vehicle to the issued actions. This enables subsequent scheduling to have closed-loop correction capabilities, and local anomalies during the actual vehicle performance can be incorporated into subsequent scheduling decisions, thus maintaining the continuity of the performance and the coordination of multiple vehicles. It should be understood that the above example is merely illustrative and not limiting.

[0126] The control method for a multi-vehicle collaborative music and light show provided in this application involves sending vehicle role attributes to a cloud server, receiving spatiotemporal instruction packets from the cloud server, executing corresponding vehicle action instruction sequences at the time point corresponding to the absolute execution timestamp, and feeding back the execution status of the vehicle action instruction sequences to the cloud server. In this way, the cloud server generates differentiated vehicle action instruction sequences based on the target music and the role attributes of each vehicle, binds these sequences to absolute execution timestamps under a unified time base, and then sends them to the vehicles. The vehicles complete caching, timed triggering, and action execution locally, and then send the execution status back to the cloud server, forming a closed-loop control. By incorporating the music content parsing results, vehicle role division, action execution timing, and execution status feedback into the same control link, multiple vehicles can complete synchronous or staggered collaborative actions according to the same time base. The cloud server can adjust subsequent arrangements based on the actual execution results, thereby achieving unified scheduling, precise execution, and continuous linkage in a multi-vehicle collaborative music and light show.

[0127] Based on the foregoing embodiments, the process of executing the corresponding vehicle action command sequence may further include: controlling the vehicle's suspension and / or the real-time coordinated operation of multiple area lights.

[0128] In its implementation, the vehicle controller can include a central domain control unit, a suspension actuator unit, and a lighting actuator unit. The central domain control unit generates control messages based on the vehicle's action command sequence and simultaneously sends them to the suspension actuator unit and the lighting actuator unit. The suspension actuator unit can employ air springs, hydraulic dampers, or an electronically controlled suspension structure to adjust the vehicle's height, pitch angle, or roll angle. The lighting actuator unit can treat the headlight area, side light area, taillight area, and roof light area as independent control areas, performing on / off, flashing, gradual change, or switching control on each area. Both types of actuators share the same time base, and the time stamp carried in the control message is used to define the start time of each actuator, thereby enabling suspension undulations and multi-area lighting changes to be presented in a coordinated manner within the same timeframe.

[0129] In another implementation, the vehicle action command sequence can first trigger the suspension to produce lifting or attitude changes, and then trigger multi-area lights to complete the coordinated display. Alternatively, the multi-area lights can first form rhythmic cues, and then the suspension can complete the response action to create a layered performance effect. Air springs, hydraulic shock absorbers, and electronically controlled suspensions can all use existing mature models. In practical applications, other models of these components can also be selected, and this application does not limit this.

[0130] In this embodiment, by incorporating the suspension and multi-area lighting into the same vehicle action command sequence and performing real-time coordinated control, the vehicle can form a unified expression of posture changes and lighting changes under the same time reference, so that the action content is consistent with the music beat, and enhances the overall coherence and display consistency when multiple vehicles perform in coordination.

[0131] In one possible implementation, the method provided in this embodiment further includes: exchanging the execution status and the absolute execution timestamp corresponding to the next vehicle action instruction with the vehicle's neighboring vehicles, and performing cross-validation; the next vehicle action instruction is the vehicle action execution sequence that follows the current vehicle action instruction; if the result of cross-validation does not meet the cooperative execution conditions, a preset degradation mode is triggered.

[0132] In the specific implementation, while the current vehicle is executing the current vehicle action command, it sends its own execution status and the absolute execution timestamp of the next vehicle action command to the adjacent vehicles. At the same time, it receives the corresponding information sent by the adjacent vehicles and completes cross-validation based on the matching relationship between the information of the two parties.

[0133] If any vehicle is detected to be in a failed execution state, in an execution state that continues to exceed a preset threshold, or if the absolute execution timestamp deviation between the two vehicles exceeds the allowable range, then the cooperative execution conditions are deemed not met. Preset degradation modes can be stored in advance by the controller. These modes include switching the vehicle action command sequence to a simplified action sequence while maintaining the basic lighting output corresponding to the current music beat, or retaining only one or more of the suspension actions and single-zone lighting control, so that the vehicle can continue to complete the performance output even in abnormal cooperative states.

[0134] During operation, the current vehicle exchanges execution status and absolute execution timestamps of subsequent vehicle action commands with adjacent vehicles to achieve real-time verification of the coordination relationship between actions of preceding and following vehicles. When the verification result indicates a mismatch in the coordination relationship, the system immediately switches to a degraded mode, causing subsequent actions to be executed according to a preset backup strategy. This method enables the vehicle action command sequence to maintain continuous output even under conditions of communication delay, execution deviation, or local anomalies, and ensures that the multi-vehicle collaborative music and light show maintains basic synchronization and performance integrity.

[0135] Figure 7 A flowchart illustrating another control method for a multi-vehicle cooperative music and light show provided in this application embodiment. Figure 7 As shown, the control method for the multi-vehicle cooperative music and light show in this embodiment can be specifically executed by the user terminal in the aforementioned multi-vehicle cooperative music and light show control system. Specifically, the method in this embodiment may include:

[0136] S301: Receives a sequence of rendering instructions sent by the cloud server; the rendering instructions are generated by the cloud server based on the target music and the character attributes of the vehicle.

[0137] The rendering instruction sequence is used to guide the rendering and state changes of the virtual vehicle model and is the core instruction set output by the cloud server.

[0138] In one possible embodiment, the cloud server receives the performance task configuration in advance. The configuration includes at least the target music file, unique identifiers for multiple target vehicles, and role attributes corresponding to each target vehicle. The role attributes can be specifically set as a main rhythm vehicle, a melody expression vehicle, an atmosphere enhancement vehicle, a formation boundary vehicle, or a center focus vehicle. The cloud server parses the target music, extracting beat points, section boundaries, melody change intensity, and emotional change markers from the music timeline, and combines these with the role attributes of each vehicle to generate rendering control content tailored to different vehicles. The generated rendering instruction sequence can adopt a time-ordered data packet structure. Each instruction includes at least the vehicle identifier, instruction effective time, rendering object type, target state parameters, and duration. The rendering object type includes vehicle body lights, vehicle posture mapping, trajectory display elements, particle effects, or virtual scene auxiliary lighting effects. The target state parameters include color values, brightness values, flashing frequency, model pose, transparency, or special effect trigger identifiers.

[0139] When a user terminal receives the rendering instruction sequence, it can receive it in real time through a long-connection message channel, or it can download the complete sequence at once and cache it locally before the performance begins. For the real-time receiving method, the user terminal performs integrity verification and sorting caching based on the sequence number and timestamp in the packet header after receiving each data packet. For the pre-download method, the user terminal establishes an instruction table indexed by absolute time after receiving the data, providing a basis for subsequent rendering scheduling.

[0140] It is evident that the rendering instruction sequence is not a simple, unified rendering template, but rather differentiated timing control data generated based on the target music and vehicle character attributes. By first performing music analysis in the cloud and mapping the roles of different vehicles to their respective rendering instructions, the terminal receives a structured rendering sequence that can be executed directly. This allows subsequent virtual displays to form hierarchical and coordinated content within the same music process.

[0141] In this exemplary implementation, when the target music enters the chorus, the rendering instruction corresponding to the main rhythm vehicle can trigger a bright pulse light effect, the rendering instruction corresponding to the atmosphere enhancement vehicle can trigger a low-frequency diffused halo, and the rendering instruction corresponding to the formation boundary vehicle can trigger an outline enhancement display. After receiving this sequence, the user terminal does not need to perform complex arrangement; it only needs to parse and execute it according to the time sequence. It should be understood that the above example is merely illustrative and not limiting. The cloud server can also use other methods to generate rendering instruction sequences based on the target music and vehicle character attributes, as long as it can drive the rendering of the virtual vehicle model.

[0142] S302: Drives the virtual vehicle model corresponding to each vehicle one by one according to the rendering instruction sequence.

[0143] The virtual vehicle model serves as a virtual mapping object corresponding to real vehicles in the twin scene, carrying the rendering results and interactive feedback. A one-to-one correspondence between each vehicle means that each real vehicle identifier has a unique model instance, state cache, and rendering channel on the terminal side. The model instance stores the vehicle's appearance, size parameters, default lighting component positions, and basic pose in the scene coordinate system.

[0144] After receiving the S301 instruction, the terminal first splits the rendering instruction sequence into multiple sub-sequences based on the vehicle identifier, then binds each sub-sequence to the corresponding virtual vehicle model, and establishes a rendering scheduling queue. For each rendering instruction, the user terminal reads its effective time and duration, and performs a model state update when the local clock reaches the corresponding time point.

[0145] In one possible implementation, the driving process includes four processing stages: instruction parsing, model indexing, state interpolation, and frame-level rendering. Specifically, the instruction parsing stage extracts vehicle identifiers, action categories, and parameter values ​​from the rendering instruction sequence. The model indexing stage locates the corresponding virtual vehicle model based on the vehicle identifier. The state interpolation stage generates frame-by-frame transition values ​​for change instructions with durations, such as transitioning color from a first color value to a second color value, brightness from a first brightness value to a second brightness value, and model pose from a first angle to a second angle. The frame-level rendering stage submits the transitioned parameters to the graphics rendering engine to update the scene in real time.

[0146] For example, if an instruction instructs vehicle V05 to render a gradual brightening of the blue light strip accompanied by a leftward turn of the vehicle's front end during the 30th to 33rd seconds of the target music, the user terminal locates the virtual vehicle model corresponding to V05 in the vehicle identification mapping table, updates its lighting material parameters and posture skeleton parameters synchronously, and completes continuous changes according to a preset interpolation curve within a three-second time window, so that the model visually forms a coherent performance consistent with the rhythm of the target music.

[0147] Furthermore, this rendering instruction sequence can also include a unified global time base, which the user terminal uses to schedule the rendering updates of multiple virtual vehicle models onto the same timeline. For multi-vehicle instructions that take effect simultaneously, the terminal completes batch processing and submission within the same rendering frame; for multi-vehicle instructions with sequential relationships, the user terminal refreshes the model state sequentially according to the timestamp order and smoothly connects the state breakpoints between adjacent instructions. After this processing, the virtual vehicle models form a continuous display effect in the time dimension and a formation correspondence in the spatial dimension.

[0148] As can be seen, mapping the rendering instruction sequence to corresponding virtual vehicle models and continuously updating them in a unified time sequence enables the virtual side to directly reproduce the collaborative orchestration results generated in the cloud based on music and role division, thus providing a stable virtual benchmark for subsequent alignment with the real execution state. It should be understood that the above example is merely illustrative and not limiting; any virtual vehicle model that can be driven one-to-one with each vehicle according to the rendering instruction sequence falls within the scope of this application.

[0149] S303: Receive execution status from the cloud server.

[0150] In this step, the execution status of the cloud server comes from vehicle feedback, providing a basis for aligning the twin scene with the real scene. Specifically, the data sources for the execution status can be feedback information from the vehicle-side controller, aggregated information from the formation control system, or the result of the cloud server fusing multiple source states. The user terminal and the cloud server receive execution status messages according to a preset period or event-triggered method. Each execution status message includes at least the vehicle identifier, status acquisition time, current execution progress, current action identifier, actual light output status, vehicle pose information, and status validity marker; when the cloud server aggregates multiple vehicle states, the execution status message can also include formation-level synchronization deviation value, current performance segment identifier, and abnormal status code.

[0151] In one possible embodiment, after receiving a sequence of vehicle action instructions containing absolute execution timestamps, the vehicle-side controller executes the corresponding action according to its local clock and sends the start of the action, completion of the action, current light output parameters, and attitude feedback to the cloud server. The cloud server performs time correction and format normalization on the data transmitted from each vehicle, generates an execution state stream that can be uniformly processed by the terminal, and then pushes it to the user terminal.

[0152] When the user terminal receives the execution status, it can write the status to the corresponding model status cache based on the vehicle identifier, and filter late messages, duplicate messages, and invalid messages based on the status acquisition time. For example, if a vehicle's planned action at the 45th second has been defined as a red flashing action in the rendering instruction sequence, but the execution status returned by the cloud server shows that the vehicle is still in the white constant state of the previous action due to control delay, the terminal records this difference as the vehicle's execution deviation at that moment and uses it as input for subsequent scene alignment.

[0153] S304: Constructs a twin scene aligned with the real scene based on the rendering instruction sequence and execution state.

[0154] In this application, a twin scene is used to create a virtual-real fusion scene that unifies the presentation of a virtual vehicle model and the execution state of a real vehicle. Its function is to achieve alignment and interaction with the real scene. The construction of the twin scene is not simply about displaying the virtual vehicle model on the screen, but rather using the planned rendering result obtained in S302 as the basis for virtual representation, and the execution state received in S303 as the basis for real operation, and correcting the model display state within a unified spatiotemporal coordinate framework.

[0155] During the construction process, the user terminal can establish a planned state table and a real-time state table. The planned state table is derived from the rendering instruction sequence, and the real-time state table is derived from the execution state. Then, the system matches the vehicle identifier and timestamp to calculate the target display state and corrected display state of each virtual vehicle model at the current moment, and uses the corrected display state as the final output of the twin scene.

[0156] In one possible implementation, the user terminal can perform twin scene alignment processing according to the following process: First, generate the planned lighting state, planned posture state, and planned position state of each virtual vehicle model at the current moment based on the rendering instruction sequence; then read the actual lighting output, actual posture feedback, and actual execution progress of the corresponding vehicle in the execution state; then compare the deviation between the planned state and the actual state, and execute different correction strategies according to the deviation type.

[0157] For example, for time deviation, the user terminal adjusts the playback progress of the corresponding model's actions to match the actual execution progress; for state deviation, the user terminal directly overwrites the local rendering parameters of the model, such as changing the planned blue light effect to the green light effect indicating the execution state; for position or pose deviation, the user terminal updates the pose of the virtual vehicle model to the value corresponding to the execution state and performs a smooth transition between adjacent frames.

[0158] For example, when the execution status indicates that a vehicle is 0.4 seconds behind the planned time when entering the formation and turning, the terminal will no longer continue to advance the vehicle model according to the original planned timeline. Instead, it will roll back the action progress of the model in the twin scenario to the position corresponding to the current execution stage of the real vehicle, while maintaining the display of other vehicle models according to their actual status, so that the entire twin scenario can truly reflect the execution results on site.

[0159] Furthermore, in another possible embodiment, constructing a twin scene aligned with the real scene also includes formation-level consistency processing. The terminal calculates the current formation outline, center point, and key vehicle positions based on the execution status of each vehicle, and compares them with the arrangement structure defined by the rendering instruction sequence. When a key vehicle deviates from the planned state, the terminal synchronously adjusts the transition behavior of other virtual vehicle models that have a linkage relationship with it in the twin scene, such as delaying the lighting effects, shortening the formation closing animation, or freezing the linkage segments that have not yet actually started, so that the twin scene is consistent with the real scene not only at the individual vehicle level, but also at the formation level.

[0160] It should be noted that by using the rendering instruction sequence as the basis for planning and the execution status as the basis for real feedback correction, the terminal can construct a twin scene that dynamically updates with the execution of real vehicles, so that the virtual display no longer stops at the playback of preset animations, but can continuously reflect the real performance status of the vehicles on site.

[0161] This processing method addresses the asynchrony between virtual and real scenes caused by network latency, execution deviations, or segment transitions in multi-vehicle collaborative performances, ensuring that the virtual vehicle models presented on the user terminal are aligned with the real vehicle actions in terms of display content, rhythm of change, and formation relationships. It should be understood that the above example is merely illustrative and not limiting; any method that aligns the twin scene with the real scene based on rendering instruction sequences and execution states should fall within the protection scope of this application.

[0162] The control method for a multi-vehicle collaborative music and light show provided in this embodiment receives a sequence of rendering instructions sent by a cloud server, drives virtual vehicle models corresponding one-to-one with each vehicle according to the sequence of rendering instructions, receives the execution status from the cloud server, and constructs a twin scene aligned with the real scene based on the sequence of rendering instructions and the execution status. In this way, the twin scene can continuously reflect the actual execution results of the multi-vehicle collaborative music and light show and accurately present the dynamically arranged content driven by music.

[0163] In one possible implementation, after constructing a twin scene aligned with the real scene, the method provided in this embodiment may further include: generating an interaction operation instruction in response to an interaction operation on a virtual vehicle model in the twin scene; the interaction operation instruction includes target action parameters and a target virtual vehicle identifier; and sending the interaction operation instruction to a cloud server, so that the cloud server generates an incremental instruction package based on the target action parameters and sends it to the vehicle corresponding to the target virtual vehicle identifier.

[0164] In practice, users can interact with virtual vehicle models in the twin scene via touch interface, mouse dragging, or gesture recognition. After recognizing the interaction, the system extracts target action parameters from the operation type, displacement, rotation, posture change, or lighting effect change, and generates a target virtual vehicle identifier by combining the virtual vehicle model's unique index, name, or mapping address in the scene. After the interaction command is generated, it can be sent to the cloud server via the network communication module. The cloud server makes local corrections to the vehicle's current execution based on the target action parameters, generates corresponding incremental command packets, and only sends them to the vehicle bound to the target virtual vehicle identifier, thus ensuring consistency between the real vehicle and the adjustments in the twin scene.

[0165] For example, when generating interactive operation instructions, in response to a drag operation on the virtual vehicle model in the twin scene, a corresponding lighting action choreography instruction is generated; and / or, in response to a click operation on the virtual vehicle model in the twin scene, a corresponding lighting effect upgrade instruction is generated; and / or, in response to a sliding adjustment operation on the emotion vector of the virtual vehicle model in the twin scene, a performance intensity adjustment instruction is generated.

[0166] The lighting motion choreography command describes the organizational relationship of lighting motions, and may include the sequence of motions, motion amplitude, motion duration, and changing parameters corresponding to the drag path. The lighting effect upgrade command describes the enhanced control of lighting performance levels, and may include switching effect types, increasing brightness, changing flashing density, or overlaying effect parameters. The emotion vector represents the strength and direction of the performance's emotions; the sliding adjustment operation is used to continuously adjust this emotion vector, thereby generating a performance intensity adjustment command. The performance intensity adjustment command can be used to simultaneously adjust the overall presentation intensity of lighting, motion, or effects.

[0167] In its implementation, the user terminal listens for touch events on the virtual vehicle model within the twin scene. When a dragging trajectory is detected, the starting point, ending point, direction, and displacement distance of the drag are analyzed, and these parameters are mapped to target motion parameters for lighting motion choreography instructions. These instructions can be further written into the target virtual vehicle identifier and sent to the cloud server, allowing the cloud server to generate matching incremental instruction packages based on the vehicle's current performance state. If a click event is detected, lighting effect upgrade instructions are generated based on the click location, number of clicks, and click interval, and converted into control content such as effect level enhancement, color transition enhancement, or rhythm pulse intensification. If a sliding adjustment operation on the emotion vector is detected, performance intensity parameters are calculated based on the sliding direction and amplitude, and corresponding performance intensity adjustment instructions are generated to ensure that the visual performance of the virtual vehicle model in the twin scene is consistent with the user's adjustment results.

[0168] In this embodiment, by transforming interactive operations in the twin scenario into interactive operation commands carrying identification information and action parameters, the interactive operations in the twin scenario can be accurately converted into interactive operation commands for real vehicles. Incremental command packages are then generated by the cloud server and distributed in a targeted manner, enabling the corresponding vehicles to exhibit and interact with the intended behavior in subsequent collaborative performances. Figure 1 The subtle changes in lighting and intensity enhance the consistency and expressive accuracy of scene interaction, and eliminate the need to repeatedly transmit complete instruction content. This allows the virtual display in the twin scene to remain synchronized with the execution status of the real vehicle, while reducing the amount of communication data and the delay in instruction update time.

[0169] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device 80 provided in this application embodiment may include at least one processor 801 and a memory 802. Optionally, the electronic device 80 may also include a communication component 803. The processor 801, memory 802, and communication component 803 are connected via a bus 804.

[0170] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to perform the above-described method.

[0171] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0172] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0173] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0174] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0175] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0176] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0177] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0178] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0179] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0180] The units described as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0181] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0182] If a function 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 application embodiment, essentially, or the part that contributes to the prior art, 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 a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

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

[0184] Finally, it should be noted that other embodiments of the present application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. The embodiments of this application are intended to cover any variations, uses, or adaptations of the embodiments of this application that follow the general principles of the embodiments of this application and include common knowledge or customary techniques in the art not disclosed in the embodiments of this application. They are not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from their scope. The scope of the embodiments of this application is limited only by the appended claims.

Claims

1. A control method for a multi-vehicle coordinated music and light show, characterized in that, The method includes: Obtain the target music and the character attributes of at least two target vehicles; Based on the target music and the character attributes, a corresponding spatiotemporal instruction package and rendering instruction sequence are generated for each of the at least two target vehicles; the spatiotemporal instruction package includes a vehicle action instruction sequence and an absolute execution timestamp bound to each vehicle action instruction sequence; The spatiotemporal instruction packet is sent to each of the target vehicles, so that each of the target vehicles executes the corresponding vehicle action instruction sequence when the absolute execution timestamp arrives; The rendering instruction sequence is sent to the user terminal so that the user terminal drives the virtual vehicle model corresponding to each of the target vehicles according to the rendering instruction sequence.

2. The method according to claim 1, characterized in that, The step of generating a corresponding spatiotemporal instruction package and rendering instruction sequence for each of at least two target vehicles based on the target music and the character attributes includes: The target music is decomposed using hierarchical tags to obtain beat points, melodic features, and / or emotion vectors; Based on the beat point, the melody features and / or the emotion vector, and the role attributes of each target vehicle, a corresponding spatiotemporal instruction package is generated for each target vehicle; the role attributes include a navigator role, a backup dancer role, and / or a background role. Generate the rendering instruction sequence corresponding to the spatiotemporal instruction package.

3. The method according to claim 1, characterized in that, After sending the spatiotemporal instruction packet to each of the target vehicles, the method further includes: Receive interactive operation instructions from the user terminal; the interactive operation instructions include target action parameters and target virtual vehicle identifier; Generate an incremental instruction packet based on the target action parameters; The incremental instruction packet is sent to the target vehicle corresponding to the target virtual vehicle identifier; The execution status feedback from each of the target vehicles is sent to the user terminal, so that the user terminal can construct a twin scene aligned with the real scene based on the rendering instruction sequence and the execution status.

4. A control method for a multi-vehicle coordinated music and light show, characterized in that, The method includes: Send the vehicle's role attributes to the cloud server; Receive a spatiotemporal instruction packet sent by the cloud server; the spatiotemporal instruction packet is generated by the cloud server based on the acquired target music and the character attributes, and the spatiotemporal instruction packet includes a vehicle action instruction sequence and an absolute execution timestamp bound to the vehicle action instruction sequence; Upon reaching the time point corresponding to the absolute execution timestamp, the corresponding vehicle action instruction sequence is executed; The execution status of the vehicle action command sequence is fed back to the cloud server.

5. The method according to claim 4, characterized in that, The execution of the corresponding vehicle action command sequence includes: Control the vehicle's suspension and / or multi-zone lighting to work in real time.

6. The method according to claim 4, characterized in that, The method further includes: The vehicle exchanges the execution status and the absolute execution timestamp corresponding to the next vehicle action instruction with the adjacent vehicle and performs cross-verification; the next vehicle action instruction is the vehicle action instruction that follows the current vehicle action instruction in the vehicle action execution sequence. If the cross-validation result does not meet the collaborative execution conditions, a preset degradation mode is triggered.

7. A control method for a multi-vehicle coordinated music and light show, characterized in that, The method includes: Receive a sequence of rendering instructions sent by the cloud server; the rendering instructions are generated by the cloud server based on the acquired target music and vehicle character attributes; The rendering instruction sequence drives the virtual vehicle model corresponding to each vehicle. Receive execution status from the cloud server; Based on the rendering instruction sequence and the execution state, a twin scene aligned with the real scene is constructed.

8. The method according to claim 7, characterized in that, After constructing the twin scene aligned with the real scene, the method further includes: In response to interactive operations on the virtual vehicle model in the twin scene, an interactive operation instruction is generated; the interactive operation instruction includes target action parameters and a target virtual vehicle identifier; The interactive operation command is sent to the cloud server, so that the cloud server generates an incremental command package based on the target action parameters and sends it to the vehicle corresponding to the target virtual vehicle identifier.

9. The method according to claim 8, characterized in that, The step of generating interactive operation instructions in response to interactive operations on the virtual vehicle model in the twin scene includes: In response to a drag operation on the virtual vehicle model in the twin scene, a corresponding lighting motion choreography instruction is generated; And / or, in response to a click operation on the virtual vehicle model in the twin scene, generate a corresponding lighting effect upgrade command; And / or, in response to a sliding adjustment operation on the emotion vector of the virtual vehicle model in the twin scene, a performance intensity adjustment instruction is generated.

10. A control system for a multi-vehicle coordinated music and light show, characterized in that, The system includes: A cloud server for performing the method as described in any one of claims 1 to 3; At least two vehicles, each of which is used to perform the method as described in any one of claims 4 to 6; A user terminal for performing the method as described in any one of claims 7 to 9.

11. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 9.

Images