Push flow control method and device and electronic equipment

Abstract

The application provides a push stream control method and device and electronic equipment, and relates to the technical field of automatic driving. The method comprises the following steps: subscribing to a push stream switch topic published by a remote control platform based on a preconfigured robot operating system (ROS) node; obtaining push stream control information issued by the remote control platform from the push stream switch topic; the push stream control information comprises a push stream total switch and a target address; the push stream total switch is used to represent a push stream on state or a push stream off state; updating a current push stream parameter in the ROS node according to the push stream control information to generate a new push stream parameter; and controlling camera push stream to a target server according to the new push stream parameter; the target server is a device corresponding to the target address. The method can realize dynamic updating of the push stream parameter in the ROS node, thereby adapting to the dynamic scheduling requirements of multiple vehicles and multiple tasks in a vehicle-mounted scene.

Description

Technical Field

[0001] This application belongs to the field of autonomous driving technology, specifically relating to a push flow control method, device, and electronic equipment. Background Technology

[0002] With the development of intelligent connected vehicles and autonomous driving technology, pushing streaming media collected by multiple in-vehicle cameras to servers (referred to as in-vehicle streaming) has become a core support for remote monitoring and environmental perception data feedback.

[0003] However, traditional vehicle-mounted streaming systems typically use statically fixed settings for core parameters such as streaming switches, device identifiers, and streaming addresses, either through configuration files or hard-coded settings on the vehicle terminal. Switching vehicles, adjusting streaming target addresses, or starting / stopping streaming requires restarting the program, which cannot meet the dynamic scheduling needs of multiple vehicles and multiple tasks in a vehicle-mounted environment. Therefore, further optimization is needed. Summary of the Invention

[0004] The technical problem to be solved by this application is to provide a streaming control method, device and electronic device to address the above-mentioned shortcomings of the existing technology. Using the streaming control method, there is no need to restart the program, and it can be applied to the dynamic scheduling needs of multiple vehicles and multiple tasks in the vehicle scenario.

[0005] In a first aspect, embodiments of this application provide a streaming control method applied to a target vehicle, the target vehicle being used in a communication system, the communication system including a remote control platform and multiple vehicles, the target vehicle being one of the multiple vehicles; the target vehicle is equipped with multiple cameras; the streaming control method includes: Based on the pre-configured robot operating system ROS node, subscribe to the push-stream switch topic published by the remote control platform; From the topic of streaming switch, obtain streaming control information issued by the remote control platform; the streaming control information includes the streaming master switch and the target address; the streaming master switch is used to indicate whether streaming is on or off. Update the current streaming parameters in the ROS node based on the streaming control information, and generate new streaming parameters; The new streaming parameters control the streaming of camera feeds to the target server; the target server is the device corresponding to the target address.

[0006] In some implementations of the first aspect, the target address includes the streaming address of each camera; the new streaming parameters include the streaming master switch and each streaming address; The step of controlling the camera stream to the target server according to the new streaming parameters includes: If the main push stream switch is on and there is a non-empty push stream address, then push the camera stream to the target server based on the non-empty push stream address. If the main streaming switch is off or all streaming addresses are empty, then streaming from the camera to the target server will stop.

[0007] In some implementations of the first aspect, pushing a camera stream to a target server based on a non-empty streaming address includes: The target camera to be streamed is determined based on the non-empty streaming address; The corresponding streaming thread of the target camera is invoked to stream all the latest valid frames to the target server according to the corresponding streaming address; the latest valid frames are generated in real time by the acquisition thread corresponding to the target camera.

[0008] In some embodiments of the first aspect, the target server is a Simple Real-Time Server (SRS) server. Before invoking the streaming thread corresponding to the target camera and streaming all the latest valid frames to the target server according to the corresponding streaming address, the process also includes: Create an audio / video communication connection instance based on the WebRTC protocol stack for real-time web communication; Generate a local session description using audio / video communication connection instances; The local session description is negotiated with the SRS server, and a push stream connection is established after the encoding format parameters of both parties are adapted.

[0009] In some implementations of the first aspect, before invoking the streaming thread corresponding to the target camera and streaming all the latest valid frames to the target server according to the corresponding streaming address, the method further includes: Build a global resource dictionary; the global resource dictionary is used to store the configuration information and real-time status of each camera. Within the ROS node, an independent resource management unit is created for each camera; each independent resource management unit is used to independently control the acquisition and streaming process of the corresponding camera based on the configuration information in the global resource dictionary; The corresponding streaming thread for the target camera is invoked to stream all the latest valid frames to the target server according to the corresponding streaming address, including: An independent resource management unit corresponding to the target camera is used to push all the latest valid frames to the target server according to the corresponding push address.

[0010] In some implementations of the first aspect, prior to subscribing to the push-stream switch topic published by the remote control platform based on the pre-configured robot operating system ROS node, the following is also included: Call the environment variable persistence function to configure environment variables to adapt to the on-board computing power environment of the target vehicle; After completing the environment adaptation, create a ROS node in the current running environment to subscribe to the push stream switch topic.

[0011] In some embodiments of the first aspect, the method further includes: When the push connection with the SRS server is abnormally disconnected, an automatic reconnection process will be executed after a preset time.

[0012] In some embodiments of the first aspect, the method further includes: Create a push stream switch feedback topic; The push status is based on the push switch feedback topic to send the push status back to the remote control platform; the push status includes at least the current push address and the push enabled status.

[0013] Based on the same inventive concept, in a second aspect, embodiments of this application also provide a streaming control device applied to a target vehicle, the target vehicle being used in a communication system, the communication system including a remote control platform and multiple vehicles, the target vehicle being one of the multiple vehicles; the target vehicle is equipped with multiple cameras; the streaming control device includes: The receiving module is used to subscribe to push-stream switch topics published by the remote control platform based on the pre-configured robot operating system ROS node; The acquisition module is used to obtain streaming control information issued by the remote control platform from the streaming switch topic; the streaming control information includes the streaming master switch and the target address; the streaming master switch is used to indicate the streaming on or off status; The update module is used to update the current streaming parameters in the ROS node based on the streaming control information and generate new streaming parameters. The control module is used to control the camera streaming to the target server according to the new streaming parameters; the target server is the device corresponding to the target address.

[0014] In some implementations of the second aspect, the target address includes the streaming address of each camera; the new streaming parameters include the master streaming switch and each streaming address; The control module is specifically used for: If the main streaming switch is on and there is a non-empty streaming address, then the camera stream will be sent to the target server based on the non-empty streaming address; if the main streaming switch is off or all streaming addresses are empty, then the camera stream to the target server will stop.

[0015] In some implementations of the second aspect, when the control module pushes a camera stream to the target server based on a non-empty streaming address, it is specifically used for: The target camera to be streamed is determined based on the non-empty streaming address; the streaming thread corresponding to the target camera is invoked, and all the latest valid frames are streamed to the target server according to the corresponding streaming address; the latest valid frames are generated in real time by the acquisition thread corresponding to the target camera.

[0016] In some embodiments of the second aspect, the target server is a Simple Real-Time Server (SRS) server; The device also includes: The connection establishment module is used to create audio and video communication connection instances based on the WebRTC protocol stack; generate local session descriptions through the audio and video communication connection instances; negotiate session descriptions with the SRS server based on the local session descriptions; and establish a push streaming connection after the encoding format parameters of both parties are adapted.

[0017] In some embodiments of the second aspect, the apparatus further includes: The module is used to build a global resource dictionary; the global resource dictionary is used to store the configuration information and real-time status of each camera; an independent resource management unit is created for each camera within the ROS node; each independent resource management unit is used to independently control the acquisition and streaming process of the corresponding camera according to the configuration information in the global resource dictionary; When the control module calls the streaming thread corresponding to the target camera and streams all the latest valid frames to the target server according to the corresponding streaming address, it is specifically used for: An independent resource management unit corresponding to the target camera is used to push all the latest valid frames to the target server according to the corresponding push address.

[0018] In some embodiments of the second aspect, the apparatus further includes: The configuration module is used to call the environment variable solidification function to configure environment variables to adapt to the on-board computing environment of the target vehicle; after the environment adaptation is completed, a ROS node is created in the current running environment to subscribe to the push stream switch topic.

[0019] In some embodiments of the second aspect, the apparatus further includes: The reconnection module is used to automatically reconnect after a preset time when the push connection with the SRS server is abnormally disconnected.

[0020] In some embodiments of the second aspect, the apparatus further includes: The feedback module is used to create a push stream switch feedback topic; publish the push stream status based on the push stream switch feedback topic to send the push stream status back to the remote control platform; the push stream status includes at least the current push stream address and the push stream on status.

[0021] Based on the same inventive concept, in a third aspect, embodiments of this application also provide an electronic device, including: a memory and a processor; The memory stores instructions that the computer executes; The processor executes computer-executable instructions stored in memory to implement a push flow control method as described in any of the first aspects.

[0022] Based on the same inventive concept, in a fourth aspect, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the push flow control method as described in any of the first aspects.

[0023] According to the streaming control method, apparatus, and electronic device provided in this application, a pre-configured robot operating system (ROS) node subscribes to streaming switch topics published by a remote control platform to obtain streaming control information issued by the remote control platform in real time. Simultaneously, the current streaming parameters in the ROS node are updated based on the streaming control information, generating new streaming parameters and achieving dynamic updating of the streaming parameters in the ROS node without restarting the program or involving configuration files or hard coding. This allows it to adapt to the dynamic scheduling needs of multiple vehicles and multiple tasks in vehicle-mounted scenarios. Attached Figure Description

[0024] Figure 1 This illustration shows a flowchart of a streaming control method provided in an embodiment of this application. Figure 2 This illustration shows another flowchart of the push-stream control method provided in an embodiment of this application; Figure 3 This diagram illustrates the flow architecture of the streaming control method provided in an embodiment of this application. Figure 4 This diagram illustrates the environment deployment and initialization of the push stream control method provided in this application embodiment. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions of this application, the application will be further described in detail below with reference to the accompanying drawings and embodiments.

[0026] The features and exemplary embodiments of various aspects of this application will now be described in detail. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only configured to explain this application and are not configured to limit this application. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples of this application.

[0027] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0028] As described in the background section, core parameters of traditional vehicle-mounted streaming systems, such as streaming switches, device identifiers, and streaming addresses, are generally set using a static, fixed method: First, they are directly hard-coded into the program source code, making them impossible to modify dynamically after compilation and execution; second, they are stored in a local static configuration file on the vehicle terminal, supporting only local manual modification; and third, they are manually entered through the vehicle's local touch interface or background configuration page, failing to achieve remote batch distribution and dynamic scheduling. Switching vehicles, adjusting streaming addresses, or starting / stopping streaming requires restarting the program, which cannot meet the dynamic scheduling needs of multiple vehicles and multiple tasks in vehicle-mounted scenarios. Therefore, further optimization is needed.

[0029] To address this, this application provides a streaming control method. A pre-configured robot operating system (ROS) node subscribes to streaming switch topics published by a remote control platform to obtain streaming control information from the platform in real time. Simultaneously, the current streaming parameters in the ROS node are updated based on the streaming control information, generating new streaming parameters and achieving dynamic updates of the streaming parameters in the ROS node without restarting the program or involving configuration files or hard coding. This allows for adaptation to the dynamic scheduling needs of multiple vehicles and multiple tasks in vehicle-mounted scenarios.

[0030] The streaming control method of this application embodiment is applied to a system including a remote control platform, multiple vehicles, and a server. The remote control platform is communicatively connected to the multiple vehicles, and each vehicle is also communicatively connected to a corresponding server. Each vehicle subscribes to streaming on / off topics published by the remote control platform to obtain streaming control information issued by the remote control platform in real time to control camera streaming, such as starting / stopping streaming and updating streaming, as described in the following embodiments.

[0031] Example 1

[0032] The propulsion control method provided in this application is applied to a propulsion control device, which is applied to a target vehicle (the target vehicle refers to any one of the multiple vehicles in the above system), and this application does not specifically limit this. The target vehicle to which the propulsion control method of this embodiment is applied is equipped with multiple cameras.

[0033] like Figure 1 As shown, the push stream control method provided in this application embodiment may include steps S101 to S104.

[0034] S101. Based on the pre-configured Robot Operating System (ROS) node, subscribe to the push switch topic published by the remote control platform.

[0035] For example, the remote control platform can be a ground-based central platform, such as a ground-based central platform in a mining area, used to control the operation of vehicles in the mining area.

[0036] For example, the "Streaming Switch" topic is used to publish streaming control information, which includes the main streaming switch and the streaming addresses of each camera. The main streaming switch is used to indicate whether streaming is turned on or off, and the streaming addresses of each camera are used to indicate the destination address information for streaming.

[0037] Depending on the specific application scenario, vehicle cameras can be configured as two-channel (front and rear), four-channel (front, rear, left, and right), etc., and this application embodiment does not impose a specific limitation on this. In mining areas, vehicles generally use four-channel cameras (front, rear, left, and right).

[0038] S102. Obtain streaming control information from the remote control platform from the streaming switch topic. The streaming control information includes the streaming master switch and the target address. The streaming master switch is used to indicate whether streaming is on or off.

[0039] For example, different controls can be implemented depending on the different push stream control information. For instance, if the push stream control information is to update the push stream information, such as changing the target server for the push stream or changing the camera used for the push stream, then the corresponding push stream update process will be performed subsequently.

[0040] For example, when switching vehicles for streaming, the remote control platform will simultaneously change the vehicle number in the streaming address to switch the corresponding vehicle for streaming.

[0041] S103. Update the current push parameters in the ROS node according to the push control information, and generate new push parameters.

[0042] For example, the current streaming parameters and streaming control information both include the main streaming switch and the streaming addresses of each camera.

[0043] During the update, the master switch for streaming control information and the streaming addresses of each camera are overwritten with the current streaming parameters to generate new streaming parameters.

[0044] S104. Control the camera stream to be pushed to the target server according to the new streaming parameters. The target server is the device corresponding to the target address.

[0045] If the new streaming parameters indicate that the master stream switch is enabled, then the corresponding stream enabling procedure will be executed. If the new streaming parameters indicate that the master stream switch is disabled, then the corresponding stream disabling procedure will be executed.

[0046] According to the streaming control method provided in this application, a pre-configured robot operating system (ROS) node subscribes to streaming switch topics published by a remote control platform to obtain streaming control information issued by the remote control platform in real time. Simultaneously, the current streaming parameters in the ROS node are updated based on the streaming control information, generating new streaming parameters and achieving dynamic updating of the streaming parameters in the ROS node without restarting the program or involving configuration files or hard coding. This allows it to adapt to the dynamic scheduling needs of multiple vehicles and multiple tasks in vehicle-mounted scenarios.

[0047] Example 2

[0048] like Figure 2 As shown, the streaming control method provided in this application embodiment is based on the streaming control method provided in embodiment 1 of this application, and is further described. It may include steps S201 to S205.

[0049] S201, Based on the pre-configured robot operating system ROS node subscription remote control platform published push stream switch topic.

[0050] In some implementations, an environment configuration process is included before S201, as follows: Call the environment variable persistence function to configure environment variables to adapt to the on-board computing environment of the target vehicle.

[0051] After completing the environment adaptation, create a ROS node in the current running environment to subscribe to the push stream switch topic.

[0052] For example, the `fix_env()` environment variable fixing function is called to uniformly configure environment variables (e.g., depending on the actual application, V4L2 (Video for Linux 2, Linux video device version 2) priority, H264 encoding parameters, etc.) to adapt to the vehicle computing environment. `fix_env()` is the environment variable fixing function during the initialization phase of the vehicle streaming solution. Its core purpose is to uniformly configure system-level / encoding library-level environment variables to force constraints on the underlying hardware driver and video encoding library's operating logic, ensuring precise adaptation to the vehicle terminal's computing environment.

[0053] For example, the created ROS node can be named a camera_webrtc_pusher node to subscribe to the push stream switch topic.

[0054] S202. Obtain streaming control information from the remote control platform from the streaming switch topic.

[0055] S203. Update the current push parameters in the ROS node according to the push control information and generate new push parameters.

[0056] It should be noted that the streaming control information includes: the master streaming switch and the target address; whereby the target address includes the streaming addresses of each camera. The new streaming parameters include the master streaming switch and each streaming address.

[0057] S204. If the main push stream switch is on and there is a non-empty push stream address, then push the camera stream to the target server according to the non-empty push stream address.

[0058] For example, by using dual verification of the main streaming switch and the streaming address, streaming will only proceed if both conditions are met, thus ensuring the accuracy and stability of the streaming.

[0059] Correspondingly, only cameras with non-empty streaming addresses will be streamed, while other cameras with empty streaming addresses will not be streamed.

[0060] In some implementations, the process of pushing camera streams to the target server based on a non-empty streaming address can be as follows: The target camera to be streamed is determined based on the non-empty streaming address.

[0061] The system invokes the streaming thread corresponding to the target camera to stream all the latest valid frames to the target server according to the corresponding streaming address. These latest valid frames are generated in real-time by the acquisition thread corresponding to the target camera.

[0062] For example, the target camera to be streamed is the camera whose corresponding streaming address is not empty. The streaming thread corresponding to the target camera can be a thread that has a corresponding relationship in this streaming. If there are multiple target cameras to be streamed, each streaming thread is independent of the others when streaming.

[0063] Similar to the streaming thread, the acquisition thread is a thread that corresponds to a target camera during acquisition. The acquisition thread may correspond to a different camera for each acquisition session.

[0064] The latest valid frame can be stored in a frame buffer, which can correspond to the camera.

[0065] For example, the target server can be a streaming media server, such as a Simple Real-Time Server (SRS) server.

[0066] In some implementations, the target server is a Simple Real-Time Server (SRS) server.

[0067] Before invoking the streaming thread corresponding to the target camera and streaming all the latest valid frames to the target server according to the corresponding streaming address, the process also includes establishing a streaming connection, as detailed below: Create an audio and video communication connection instance based on the Web Real-Time Communication (WebRTC) protocol stack.

[0068] Generate a local session description from the audio / video communication connection instance.

[0069] The local session description is negotiated with the SRS server, and a push stream connection is established after the encoding format parameters of both parties are adapted.

[0070] For example, the audio / video communication connection instance is used to carry the network connection and media transmission for this push stream. The local session description offer is used to negotiate the session description with the remote server, i.e., the SRS server. If the local session description offer does not contain the H264 encoding identifier in SDP (Session Description Protocol), then the SDP parameters are specified to complete the adaptation of the encoding format parameters of both parties and ensure compatibility with the SRS server encoding.

[0071] Establishing a connection can be achieved by sending an Offer command to the SRS API (Application Programming Interface) via the asynchronous communication module, along with the streaming address and supplemented SDP parameters. Simultaneously, the system receives the Answer response from the SRS server and invokes the audio / video communication connection instance to complete the WebRTC streaming connection establishment, with a streaming latency of ≤100ms.

[0072] In some implementations, before calling the streaming thread corresponding to the target camera and streaming all the latest valid frames to the target server according to the corresponding streaming address, a global resource dictionary construction process is also included, as follows: Build a global resource dictionary. The global resource dictionary is used to store the configuration information and real-time status of each camera.

[0073] Within the ROS node, an independent resource management unit is created for each camera. Each independent resource management unit is used to independently control the acquisition and streaming process of the corresponding camera based on the configuration information in the global resource dictionary.

[0074] The process of calling the push thread corresponding to the target camera and pushing all the latest valid frames to the target server according to the corresponding push address can be specifically described as follows: An independent resource management unit corresponding to the target camera is used to push all the latest valid frames to the target server according to the corresponding push address.

[0075] For example, independent resource management units (RMUs) are created within a ROS node. During streaming and data acquisition, these independent RMUs operate independently, without interfering with each other. Each independent RMU includes frame storage, status flags, resource locks, thread objects, etc., enabling independent data acquisition, streaming, and status identification.

[0076] For example, a configuration lock + resource lock can be used. The configuration lock protects global configuration information (such as the streaming switch and the streaming addresses of each camera), while the resource lock protects specific resources (such as the frame buffer of each camera and audio / video communication connection instances). This dual-lock mechanism ensures cross-thread data security, prevents frame corruption and device occupancy conflicts, and resolves resource contention issues and thread contention issues associated with multi-stream streaming.

[0077] S205. If the main streaming switch is off or all streaming addresses are empty, then stop streaming the camera to the target server.

[0078] In some implementations, the method further includes: When the push connection with the SRS server is abnormally disconnected, an automatic reconnection process will be executed after a preset time.

[0079] For example, the preset duration can be set dynamically, such as according to network conditions, or it can be set to a fixed duration, such as 5 seconds.

[0080] If the streaming thread crashes due to a sudden failure, the streaming conditions (main switch on + streaming address valid) can be verified. If both are met, the automatic reconnection process will be executed after a preset time to avoid permanent interruption of streaming.

[0081] In some implementations, the method further includes: Create a push stream switch feedback topic.

[0082] The streaming status is published based on the streaming switch feedback topic, and the streaming status is sent back to the remote control platform. The streaming status includes at least the current streaming address and the streaming start status.

[0083] For example, the push stream switch feedback topic is used to report the push stream status to the remote control platform, so that the remote control platform can know the push stream status, such as whether the push stream is enabled, the push stream address, and the push stream network status.

[0084] The streaming control method in this embodiment updates the streaming switch and multiple streaming addresses in real time via ROS subscription, adapting to different vehicles and task scenarios without requiring program restarts, and achieving dynamic control of core streaming parameters. By constructing an independent resource management unit, it achieves isolation between the acquisition and streaming threads of each camera. By enhancing the anomaly recovery capability of the in-vehicle environment, it achieves automatic reconnection after streaming anomalies, ensuring streaming continuity. By constructing a closed-loop feedback mechanism for streaming status, it can collect and publish the specific status of each streaming stream in real time.

[0085] To better understand the streaming control method provided in the embodiments of this application, a more detailed description will be given below through specific application examples.

[0086] The streaming control method of this application embodiment is applied to mining areas. The overall solution is built around "dynamic management and control - resource isolation - protocol optimization - anomaly recovery - state closure". The core modules are as follows: 1) ROS-Driven Dynamic Parameter Management Module: As the core driver of the entire vehicle-mounted multi-camera WebRTC streaming system, this module initializes a ROS node named `camera_webrtc_pusher`, subscribes to the `platform / camera / remote_stream_switch` topic (i.e., the streaming switch topic, where `platform / camera` refers to the platform and camera), and is issued by the ground control platform. This enables real-time reception of the master streaming switch and the four streaming addresses (front / rear / left / right). Core mechanisms include: configuring a global configuration lock to ensure the atomicity of multi-threaded parameter updates; setting dual verification conditions for streaming startup (master streaming switch is on, and the corresponding streaming address is not empty); if either condition is not met, streaming for that channel is automatically stopped and a clear reason is output. All core streaming parameters are initialized to empty / default false, relying entirely on ROS subscription for dynamic assignment, with no hard-coded default parameters. After completing the dynamic reception and verification of parameters, this module provides the core basis for subsequent multi-camera resource isolation management and enters the resource allocation phase.

[0087] 2) Multi-Camera Resource Isolation Management Module: After the above parameter verification and dynamic assignment, independent management of multi-camera resources is implemented. This module constructs a global resource dictionary `camera_resources`, allocating independent resource management units for the four cameras (front / rear / left / right, corresponding to numbers 0-3). Each unit includes: data storage (latest_frame), status identifiers (camera_running acquisition status, push_running streaming status, push_success streaming success identifier), and control components (lock resource lock, cam_thread acquisition thread, push_thread streaming thread). The acquisition and streaming threads of each camera run independently, and thread-safe access to frame data is achieved through resource locks to avoid cross-camera resource contention. This module provides an independent resource carrier for subsequent acquisition optimization and protocol adaptation. After resource allocation is completed, the vehicle-mounted camera acquisition optimization phase begins.

[0088] 3) Vehicle-mounted camera acquisition optimization module: Based on the independent resource management unit and the above parameter verification results, this module performs refined configuration and data verification for camera acquisition. This module initializes the camera using the V4L2 interface and forces the configuration of acquisition parameters: MJPG (Motion Joint Photographic Experts Group) image format, 1280×720 resolution, 30fps frame rate, and a buffer size of 1. The acquisition thread continuously verifies the validity of the ROS subscription parameters in step 1). If a parameter becomes invalid, the camera resources are immediately released to prevent device resource usage leakage.

[0089] In addition, a frame data verification mechanism is designed so that the `latest_frame` in the independent resource management unit (2) is updated only when the frame is successfully read, not empty, and has a valid size; invalid frames are skipped and logged. Valid frames are synchronized to the independent resource management unit (2) for storage, providing a data source for subsequent WebRTC streaming. After completing the acquisition optimization, the WebRTC protocol adaptation phase begins.

[0090] 4) WebRTC Protocol Forced Adaptation and Optimization Module: Receives valid frame data from the independent resource management unit in section 2) and, in conjunction with the corresponding push stream address in section 1), performs customized adaptation of the push stream protocol. This module forces constraints on the encoding logic through environment variables: AV_PREFER_H264=1 forces the AV library to use H264 encoding. Simultaneously, it configures core H264 video encoding configuration items, AV_CODEC_H264_PROFILE=baseline and AV_CODEC_H264_LEVEL=4.1, to constrain the functional scope and performance limits of the encoding logic. It supplements SDP protocol parameters; if the locally generated SDP lacks an H264 encoding identifier, it automatically inserts parameters such as a=rtpmap:96 H264 / 90000, packetization-mode=1, and level-asymmetry-allowed=1, forcibly standardizing the video transmission protocol in WebRTC and aligning with SDP parameters. SDP stands for "protocol agreement" between WebRTC parties before they establish a connection. Only when both parties align based on consistent SDP parameters can normal transmission and decoding of audio and video data be completed. The core purpose of automatically inserting these SDP parameters is to enforce standardized transmission protocol rules for H.264 video in WebRTC, and to solve problems such as negotiation failure between the streaming end and the receiving end, abnormal video decoding, and unstable P2P (Peer-to-Peer) connections caused by missing or inconsistent SDP parameters in automotive scenarios, thus ensuring the real-time performance and compatibility of automotive streaming.

[0091] STUN (Session Traversal Utilities for NAT, where NAT (Network Address Translation)) server is used to build ICE (Interactive Connectivity Establishment) configuration, improving the success rate of P2P connections. After protocol adaptation is completed, the push_thread based on step 2) performs push operations, entering the intelligent anomaly recovery phase.

[0092] 5) Intelligent Anomaly Recovery Module: This module performs end-to-end anomaly monitoring and automatic recovery for the operational status of the acquisition and streaming stages (3) and (4) respectively. It listens to the WebRTC `iceconnectionstatechange` event. When the status is failed / closed / disconnected, it marks the `push_success` event in the resource unit of step 2) as failed and triggers a reconnection. The `iceconnectionstatechange` event is the core event in WebRTC for real-time monitoring of ICE connection status changes. Essentially, it is a callback event proactively triggered by the WebRTC underlying layer during the ICE connection lifecycle when the connection status changes. It provides accurate connection status awareness for automotive streaming scenarios, supporting the real-time performance and effectiveness of the anomaly recovery mechanism.

[0093] The automatic reconnection logic involves closing the current PeerConnection resource (an instance created and maintained by the WebRTC core library to establish an end-to-end audio and video communication connection), waiting 5 seconds, and then re-executing the Offer generation and SDP interaction process until the stream is successfully pushed or the streaming condition in step 1) fails. For scenarios where the streaming thread crashes, the streaming condition in step 1) is verified; if the condition is met, the thread is automatically restarted to prevent permanent interruption of a single streaming stream. An exception recovery mechanism ensures streaming continuity; after exception handling, the streaming status closed-loop feedback loop is entered.

[0094] 6) Push Stream Status Closed-Loop Feedback Module: Receives the push stream status after anomaly recovery (5), aggregates the push_success flags from the four cameras in (2), and simultaneously collects full-process operation data to achieve real-time feedback of push stream status and closed-loop resource management. The core functions of this module include: aggregating the four push stream statuses through the update_push_result function (update_push_result is the core data aggregation function of the push stream status closed-loop feedback module, specifically responsible for "centralized collection, verification, storage, and output" of the push stream statuses from the four cameras, and is the core entry point for achieving unified management of multiple statuses) to achieve unified management of multiple statuses.

[0095] The system generates global push results (success / failure) based on the `any()` logic (a built-in Python function that iterates through an iterable object (e.g., a four-way `push_success` list), returning `True` if any element is `True` and `False` if all elements are `False`. This avoids the unreasonable requirement of "only valid if all paths succeed," ensuring the basic needs of vehicle monitoring are met.

[0096] Using a 1Hz frequency, the global streaming results and four streaming addresses are published via the `camera / platform / remote_stream_switch_back` topic (i.e., the streaming switch feedback topic). The status is transmitted back to the ground control platform in real time, achieving a closed-loop "command-feedback" service and avoiding invalid streaming. The system listens for the SIGINT (Signal Interrupt) exit signal, automatically shutting down all acquisition / streaming threads (2), releasing camera resources (3), and shutting down the ROS node (1). Through status feedback and resource reclamation, closed-loop management of the entire link is achieved.

[0097] The following explanation uses a specific application example. Taking the scenario of a smart mining dump truck with four-way camera remote monitoring of the feed flow as an example, such as... Figure 3 As shown, for the scenario of remote monitoring and streaming from four cameras on a mining dump truck, a highly stable and low-latency dynamic streaming is achieved through a complete closed loop of "adaptation-control-collection-streaming-recovery-feedback-control". The core process is as follows: Environment Deployment and Initialization (Adapting to Automotive Hardware + ROS Ecosystem): like Figure 4 As shown, the environment deployment and initialization include: completing the deployment and adaptation of the vehicle hardware (4 smart cameras + embedded Linux terminal) and software dependency libraries, and initializing the ROS node, multi-channel resource dictionary and acquisition / pushing thread.

[0098] Hardware Adaptation: The autonomous vehicle is equipped with four Senyun intelligent cameras (device IDs 0 / 1 / 2 / 3, corresponding to front / rear / left / right), and the onboard terminal uses an embedded Linux system (supporting V4L2 camera driver). Software Deployment: Dependency libraries are installed on the onboard terminal to ensure the core modules of the technical solution are operational. Video Acquisition: OpenCV (cv2) (Open Source Computer Vision Library), with V4L2 interface enabled to adapt to the onboard camera. Streaming Core: aiortc (WebRTC protocol implementation), av (H264 encoding adaptation). Communication Interaction: rospy (ROS node communication), aiohttp (HTTP interaction with SRS server).

[0099] Solution Initialization: The `fix_env()` function is called to solidify environment variables and uniformly configure them (forcing V4L2 priority and H264 encoding parameter baseline 4.1) to adapt to the vehicle-mounted computing environment. ROS nodes are initialized, creating `camera_webrtc_pusher` nodes, subscribing to the `platform / camera / remote_stream_switch` topic (to receive parameters published by the ground center), and creating the `camera / platform / remote_stream_switch_back` topic (to send back the push stream status to the ground center). A multi-channel resource dictionary is constructed: `camera_resources` is initialized, allocating independent resource management units (including `latest_frame` storage, `camera_running` status flags, `lock` resource locks, and `cam_thread / push_thread` thread objects) to each of the four cameras to achieve resource isolation. Threads are started: a data acquisition thread (non-daemon thread, ensuring normal resource reclamation) and a push stream thread (daemon thread, exiting with the main process) are started for each camera, initially in the state of "waiting for ROS parameter subscription".

[0100] ROS dynamic parameter subscription (parameter delivery - validation - condition determination): By subscribing to ROS topics, the system receives streaming parameters (switches and streaming addresses of four cameras) from the ground control platform, and initiates the data acquisition process of compliant cameras after security verification and condition determination.

[0101] The ground monitoring center sends streaming control parameters to the dump truck via the ROS streaming switch topic name: platform / camera / remote_stream_switch, which can be dynamically adjusted according to requirements. The streaming control parameters include: the main streaming switch being on (switch:True) and the streaming addresses for the front, rear, left, and right cameras.

[0102] The front camera stream URLs are `front_stream_url` ("webrtc: / / 10.56.3.12 / live / mine_truck_08_front"), the rear camera stream URLs are `rear_stream_url` ("webrtc: / / 10.56.3.12 / live / mine_truck_08_rear"), the left camera stream URLs are `left_stream_url` ("webrtc: / / 10.56.3.12 / live / mine_truck_08_left"), and the right camera stream URL is `right_stream_url` ("webrtc: / / 10.56.3.12 / live / mine_truck_08_right"). Parameters are received through the `stream_switch_callback` function, triggering the "ROS dynamic parameter management mechanism" to ensure secure parameter updates.

[0103] Enable `config_lock` to prevent conflicts caused by multiple threads simultaneously reading and writing parameters. Check the validity of the push stream address format. If an address is empty (e.g., the left camera address is missing), mark `push_running=False` for that address and output "Left camera push stream address is empty, stop push stream". Perform parameter validity verification. Each camera must meet the dual conditions of "main switch on + push stream address valid" to allow the start of the data acquisition and push stream condition determination logic.

[0104] Multi-camera acquisition (resource isolation + frame optimization acquisition): The acquisition thread obtains valid frames according to optimized parameters and ensures data security through resource locks.

[0105] The acquisition thread executes, with the cam_thread acquisition threads of the front / rear / right cameras triggering the camera_worker function (a worker class used to asynchronously process camera capture requests in an independent thread). Camera initialization calls cv2.VideoCapture (a class used to read video frames from a camera, video file, or network video stream), forcibly configuring acquisition parameters (MJPG format, 1280×720 resolution, 30fps frame rate, buffer size = 1) to reduce frame latency (≤10ms).

[0106] Enable the `res["lock"]` resource lock to prevent errors caused by simultaneous reading of frame data by the streaming threads. Update `latest_frame` only when `ret=True`, the frame is not empty, and the size is valid; invalid frames are skipped to ensure streaming data quality (frame read success rate ≥ 99.9%). Left-side camera handling: Because the streaming address is empty, the acquisition thread continuously checks the parameter `can_run=False` and does not start the camera to avoid device conflict.

[0107] WebRTC streaming startup (protocol adaptation + low-latency connection): The streaming thread uses the WebRTC protocol to perform H264 encoding adaptation, SDP parameter supplementation, and connection establishment with the SRS server.

[0108] The push stream execution threads: The push_threads of the front / rear / right cameras call the start_single_push_thread function (the function that starts the push stream thread corresponding to a single camera), starting the single_webrtc_push asynchronous push stream logic. A PeerConnection end-to-end audio / video communication core instance object (i.e., the audio / video communication connection instance) is created to carry the network connection and media transmission for this push stream.

[0109] Based on the ICE configuration (integrated with the STUN server), the success rate of NAT traversal in the mining area network is improved. A MultiVideoTrack object is created (used to bind video frame data from one camera and encapsulate it into a transmittable video track object), and the corresponding camera's latest_frame is bound to ensure synchronization between the streaming data and the acquired data. After generating a local offer, the H264 encoding identifier in the SDP is checked. If it is not included, the specified SDP parameters are added (a=rtpmap:96H264 / 90000. a=fmtp:96profile-level-id=42e029;packetization-mode=1;level-asymmetry-allowed=1) to ensure encoding compatibility with the SRS server. The asynchronous HTTP (Hypertext Transfer Protocol) communication module aiohttp sends an Offer command to the SRS API interface (http: / / 10.56.3.12:1985 / rtc / v1 / publish / ), along with the streaming address and supplemented SDP parameters. It then receives the Answer returned by the SRS server and calls the core method pc.setRemoteDescription of the PeerConnection instance to establish the WebRTC streaming connection. The streaming latency is ≤100ms.

[0110] Intelligent recovery from anomalies (self-healing from network fluctuations / thread crashes): In the event of network fluctuations or thread crashes, the system automatically triggers a reconnection or thread restart mechanism.

[0111] If a temporary network outage in the mining area causes the ICE status to become failed, the exception is captured via the pc.on("iceconnectionstatechange") event, and push_success=False is set for that path. The current PeerConnection resource is closed, and the Offer generation and SDP interaction process is re-executed after 5 seconds (RECONNECT_INTERVAL=5) until the ICE status becomes connected (exception recovery time ≤ 5 seconds). If the push stream thread crashes due to a sudden failure, the push stream conditions are verified (main switch on + push stream address valid). If these conditions are met, the push stream thread is automatically restarted after 5 seconds to prevent permanent interruption of a single push stream.

[0112] State closed-loop feedback (state aggregation - real-time feedback - monitoring): The streaming status is transmitted back to the ground center in real time via ROS topic 1Hz, enabling full-process monitoring.

[0113] The update_push_result function aggregates the status of the three push streams (front / back / right all successful, left stream not started), adopting the logic of "any success of any one stream determines global success", push_result="success". At the same time, the ROS timer triggers the publish_stream_result function at a frequency of 1Hz to publish the status (result:"success", four push stream addresses) to the camera / platform / remote_stream_switch_back topic. The ground center subscribes to this topic to obtain the status of each push stream in real time and confirm that "front / back / right push streams are normal, left stream not started due to missing address", improving operation and maintenance efficiency by 80%.

[0114] Dynamic adjustment and stopping of streaming (parameter update / resource reclamation): It supports dynamic adjustment of streaming parameters and two exit methods: normal / forced stop, to ensure orderly resource recovery.

[0115] Dynamically adjust parameters: The ground center switches the right camera push address to webrtc: / / 10.56.3.12 / live / mine_truck_08_right_new, republishes ROS parameters, receives the new address through stream_switch_callback, updates the right camera push address global_stream_urls[3] under the protection of config_lock, and disconnects the established PeerConnection after the right push thread detects the address change, and re-executes the WebRTC push protocol adaptation and connection establishment logic according to the new address.

[0116] Stop streaming: The unmanned vehicle completes the takeover operation, the ground center platform issues switch:False (master switch off), sets all camera push_running and camera_running to False, the acquisition thread executes cap.release() to release camera resources, and the streaming thread executes PeerConnection closing operation.

[0117] Forced exit handling: Triggers Ctrl+C (interrupting the currently running program), calls the signal_handler function (a callback function used to capture and process signals sent by the operating system to the process), closes all acquisition / pushing threads, releases resources, and calls rospy.signal_shutdown (a function to actively shut down the node) to shut down the ROS node and avoid resource leaks.

[0118] The push-stream control method in this embodiment has the following effects: 1) Breakthrough in dynamic adaptability: The streaming parameters are updated in real time through ROS subscription, with a response latency of ≤1 second. Vehicles can be switched and streaming addresses can be adjusted without restarting the program, adapting to multi-vehicle scheduling scenarios.

[0119] 2) Significantly improved stability: The dual-lock mechanism (configuration lock + resource lock) completely solves the thread contention problem, reducing the program crash rate to 0. Automatic reconnection + thread self-healing mechanism reduces exception recovery time to ≤5 seconds and improves streaming continuity by 99%. Optimized acquisition parameters reduce frame latency to ≤10ms and frame read success rate to ≥99.9%, meeting the requirements of real-time vehicle monitoring.

[0120] 3) Significantly enhanced compatibility: Forced H264 encoding adaptation + SDP parameter supplementation ensures a connection success rate of ≥99.9% with the SRS server, resolving the protocol compatibility issues of traditional streaming.

[0121] It is understood that the various method embodiments mentioned above in this application can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this application will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0122] Example 3

[0123] This application provides a streaming control device applied to a target vehicle. The target vehicle is connected to a communication system, which includes a remote control platform and multiple vehicles, with the target vehicle being one of the vehicles. The target vehicle is equipped with multiple cameras. The streaming control device includes: The receiving module is used to subscribe to push-stream switch topics published by the remote control platform based on the pre-configured robot operating system ROS node.

[0124] The acquisition module is used to obtain streaming control information issued by the remote control platform from the streaming switch topic; the streaming control information includes the streaming master switch and the target address; the streaming master switch is used to indicate the streaming on or off status.

[0125] The update module is used to update the current push parameters in the ROS node based on the push control information and generate new push parameters.

[0126] The control module is used to control the camera streaming to the target server according to the new streaming parameters; the target server is the device corresponding to the target address.

[0127] In some implementations, the target address includes the streaming addresses of each camera. New streaming parameters include a master streaming switch and individual streaming addresses.

[0128] The control module is specifically used for: If the main streaming switch is on and there is a non-empty streaming address, then the camera stream will be sent to the target server based on the non-empty streaming address. If the main streaming switch is off or all streaming addresses are empty, then the camera stream to the target server will stop.

[0129] In some implementations, when the control module pushes a camera stream to the target server based on a non-empty streaming address, it specifically performs the following functions: The target camera to be streamed to is determined based on the non-empty streaming address. The streaming thread corresponding to the target camera is invoked, and all the latest valid frames are streamed to the target server according to the corresponding streaming address. The latest valid frames are generated in real time by the acquisition thread corresponding to the target camera.

[0130] In some implementations, the target server is a Simple Real-Time Server (SRS) server.

[0131] The propulsion control device also includes: The connection establishment module is used to create audio and video communication connection instances based on the WebRTC protocol stack. A local session description is generated from the audio and video communication connection instance. Based on the local session description, a session description negotiation is performed with the SRS server, and a streaming connection is established after both parties have completed the adaptation of their encoding format parameters.

[0132] In some embodiments, the propulsion control device further includes: The module is used to build a global resource dictionary. This dictionary stores the configuration information and real-time status of each camera. Within the ROS node, an independent resource management unit is created for each camera. Each independent resource management unit independently controls the acquisition and streaming process of its corresponding camera based on the configuration information in the global resource dictionary.

[0133] When the control module calls the streaming thread corresponding to the target camera and streams all the latest valid frames to the target server according to the corresponding streaming address, it is specifically used for: An independent resource management unit corresponding to the target camera is used to push all the latest valid frames to the target server according to the corresponding push address.

[0134] In some embodiments, the propulsion control device further includes: The configuration module is used to call the environment variable persistence function to configure environment variables to adapt to the onboard computing power environment of the target vehicle. After completing the environment adaptation, a ROS node is created in the current running environment to subscribe to the push stream switch topic.

[0135] In some embodiments, the propulsion control device further includes: The reconnection module is used to automatically reconnect after a preset time when the push connection with the SRS server is abnormally disconnected.

[0136] In some embodiments, the propulsion control device further includes: The feedback module is used to create push stream switch feedback topics. Push stream status is published based on these feedback topics to send the push stream status back to the remote control platform. The push stream status includes at least the current push stream address and the push stream being enabled status.

[0137] The propulsion control device provided in this application has the beneficial effects and implementation methods of the propulsion control methods provided in Embodiments 1 and 2 of this application. For details, please refer to the specific descriptions of the propulsion control methods in Embodiments 1 and 2 above. This embodiment will not repeat them here.

[0138] Example 4

[0139] This application also provides an electronic device, which is intended to be various forms of devices with data processing capabilities, such as servers, terminals, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0140] The electronic device, located in the target vehicle, specifically includes a processor and memory. The various components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processor can process instructions executed within the electronic device.

[0141] The memory is the non-transitory computer-readable storage medium provided in this application. The memory stores instructions executable by at least one processor to cause at least one processor to perform the push-stream control method provided in this application. The non-transitory computer-readable storage medium of this application stores computer instructions for causing a computer to perform the push-stream control method provided in this application.

[0142] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the push-stream control method in the embodiments of this application. The processor executes various functional applications and data processing of the electronic device by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the push-stream control method in the above method embodiments.

[0143] The electronic device provided in this application has the beneficial effects and implementation methods of the streaming control method provided in Embodiments 1 and 2 of this application. For details, please refer to the specific description of the streaming control method in Embodiments 1 and 2 above. This embodiment will not repeat the description here.

[0144] Example 5

[0145] This embodiment also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the push stream control method in Embodiment 1 or Embodiment 2 above.

[0146] The computer-readable storage medium provided in this application has the beneficial effects and implementation methods of the streaming control method in Embodiments 1 and 2 of this application. For details, please refer to the specific description of the streaming control method in Embodiments 1 and 2 above. This embodiment will not repeat the description here.

[0147] As is known to those skilled in the art, computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0148] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0149] It is understood that the above embodiments are merely exemplary implementations used to illustrate the principles of this application, and this application is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this application, and these modifications and improvements are also considered to be within the scope of protection of this application.

Claims

1. A method for controlling the flow of water, characterized in that, The system is applied to a target vehicle, which is used in a communication system that includes a remote control platform and multiple vehicles, with the target vehicle being one of the multiple vehicles. The target vehicle is equipped with multiple cameras; The push flow control method includes: Based on the pre-configured robot operating system ROS node, subscribe to the push-stream switch topic published by the remote control platform; The streaming control information issued by the remote control platform is obtained from the streaming switch topic; the streaming control information includes the streaming master switch and the target address; the streaming master switch is used to indicate the streaming on or off state; Update the current streaming parameters in the ROS node according to the streaming control information, and generate new streaming parameters; The camera stream is controlled to be pushed to the target server according to the new streaming parameters; the target server is the device corresponding to the target address.

2. The method according to claim 1, characterized in that, The target address includes the streaming addresses of each camera; the new streaming parameters include the streaming master switch and each of the streaming addresses; The step of controlling the camera stream to the target server according to the new streaming parameters includes: If the main push stream switch is on and there is a non-empty push stream address, then push the camera stream to the target server according to the non-empty push stream address; If the main streaming switch is off or all streaming addresses are empty, then streaming from the camera to the target server will stop.

3. The method according to claim 2, characterized in that, The step of pushing the camera stream to the target server based on the non-empty push address includes: The target camera to be streamed is determined based on the non-empty streaming address; The push thread corresponding to the target camera is invoked to push all the latest valid frames to the target server according to the corresponding push address; wherein, the latest valid frames are generated in real time by invoking the acquisition thread corresponding to the target camera.

4. The method according to claim 3, characterized in that, The target server is a Simple Real-Time Server (SRS) server. Before invoking the streaming thread corresponding to the target camera and streaming all the latest valid frames to the target server according to the corresponding streaming address, the method further includes: Create an audio / video communication connection instance based on the WebRTC protocol stack for real-time web communication; A local session description is generated using the audio / video communication connection instance; Based on the local session description, the session description is negotiated with the SRS server, and a push stream connection is established after the encoding format parameters of both parties are adapted.

5. The method according to claim 3, characterized in that, Before invoking the streaming thread corresponding to the target camera and streaming all the latest valid frames to the target server according to the corresponding streaming address, the method further includes: Construct a global resource dictionary; the global resource dictionary is used to store the configuration information and real-time status of each camera. Within the ROS node, an independent resource management unit is created for each camera; wherein each independent resource management unit is used to independently control the acquisition and streaming process of the corresponding camera according to the configuration information in the global resource dictionary; The step of calling the streaming thread corresponding to the target camera and streaming all the latest valid frames to the target server according to the corresponding streaming address includes: The independent resource management unit corresponding to the target camera pushes all the latest valid frames to the target server according to the corresponding push address.

6. The method according to claim 1, characterized in that, Before the pre-configured Robot Operating System (ROS) node subscribes to the push-stream switch topic published by the remote control platform, the following steps are also included: The environment variable persistence function is called to configure the environment variables to adapt to the on-board computing power environment of the target vehicle; After completing the environment adaptation, create the ROS node in the current operating environment to subscribe to the push stream switch topic.

7. The method according to claim 4, characterized in that, The method further includes: When the push connection with the SRS server is abnormally disconnected, an automatic reconnection process is executed after a preset time.

8. The method according to claim 1, characterized in that, The method further includes: Create a push stream switch feedback topic; Based on the push switch feedback topic publishing push status, the push status is transmitted back to the remote control platform; the push status includes at least the current push address and push enabled status.

9. A flow control device, characterized in that, The system is applied to a target vehicle, which is used in a communication system that includes a remote control platform and multiple vehicles, with the target vehicle being one of the multiple vehicles. The target vehicle is equipped with multiple cameras; The propulsion control device includes: The receiving module is used to subscribe to push-stream switch topics published by the remote control platform based on a pre-configured robot operating system ROS node; The acquisition module is used to acquire streaming control information issued by the remote control platform from the streaming switch topic; the streaming control information includes a streaming master switch and a target address; the streaming master switch is used to indicate whether streaming is on or off. The update module is used to update the current streaming parameters in the ROS node according to the streaming control information and generate new streaming parameters; The control module is used to control the camera streaming to the target server according to the new streaming parameters; the target server is the device corresponding to the target address.

10. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the push stream control method as described in any one of claims 1 to 8.

Images