Log uploading method and system, terminal equipment, self-moving equipment and medium

Abstract

The invention relates to the technical field of data transmission, and provides a log uploading method and system, terminal equipment, self-moving equipment and a medium, and the method comprises the steps: uploading a local file to a preset log receiving end, and triggering the log receiving end to generate form information corresponding to the local file; a log uploading instruction is generated and sent to a preset self-moving device, so that the self-moving device is triggered to respond to the log uploading instruction and upload the vehicle-mounted log; obtaining a file uploading result corresponding to the local file, a form creating result corresponding to the form information and uploading progress information fed back by the self-moving device in the vehicle-mounted log uploading processing process; and generating a log uploading result according to the file uploading result, the form creation result and the uploading progress information. According to the method, the accuracy and the reliability of log uploading state display are improved, and the problem of asynchronous double-end message states in a communication instability scene is effectively solved.

Description

Technical Field

[0001] This application relates to the field of data transmission technology, and in particular to a log uploading method, system, terminal device, self-moving device, and medium. Background Technology

[0002] In the scenario of log upload between self-mobile devices and terminal devices with applications, when the self-mobile device cannot actively upload logs and needs the terminal device to send a command to notify it to upload, unstable communication may cause the terminal device to be unable to accurately obtain the log upload status of the self-mobile device, resulting in a discrepancy between the log progress displayed by the terminal device and the log progress actually transmitted by the self-mobile device to the log receiving end. Summary of the Invention

[0003] This application provides a log upload method, system, terminal device, self-moving device, and medium, aiming to solve the problem that in the prior art, the traditional method for verifying the qualification of sensor data relies on decompressing the compressed dataset and verifying the frame rate of each sensor data point one by one. However, the decompression process consumes a large amount of disk space and memory, and the dataset often occupies several gigabytes of storage. After decompression, the data volume expands, placing a huge burden on computing resources. At the same time, the verification process relies on manual intervention, which is difficult to adapt to the needs of automated processing of large-scale data.

[0004] Firstly, this application provides a log uploading method applied to a terminal device, the method comprising: Upload a local file to a preset log receiving terminal, and trigger the log receiving terminal to generate form information corresponding to the local file; Generate and send a log upload command to a preset self-mobile device to trigger the self-mobile device to respond to the log upload command and perform vehicle log upload processing; Obtain the file upload result corresponding to the local file, the form creation result corresponding to the form information, and the upload progress information fed back by the self-mobile device during the process of uploading the vehicle log; A log upload result is generated based on the file upload result, the form creation result, and the upload progress information.

[0005] In some embodiments, before generating the log upload result based on the file upload result, the form creation result, and the upload progress information, the method further includes: receiving the upload progress information sent by the self-mobile device during the self-mobile device's vehicle log upload processing; and sending a progress confirmation instruction to the self-mobile device after receiving the upload progress information, so that the self-mobile device performs the vehicle log upload processing corresponding to the upload progress information after receiving the progress confirmation instruction.

[0006] In some embodiments, the method further includes: when it is confirmed that the log upload result is an upload failure based on the file upload result, the form creation result, and the upload progress information, generating a cleanup instruction and sending it to the log receiving end, so that the log receiving end performs cleanup processing on the form information and / or vehicle logs corresponding to the log upload result.

[0007] In some embodiments, generating a log upload result based on the file upload result, form creation result, and upload progress information includes: if the file upload result, form creation result, and vehicle log upload are all confirmed to be successful based on the file upload result, form creation result, and upload progress information, then the log upload result is confirmed to be successful; if the file upload result, form creation result, or vehicle log upload is confirmed to be unsuccessful based on the file upload result, form creation result, and upload progress information, then the log upload result is confirmed to be unsuccessful.

[0008] In some embodiments, obtaining the file upload result corresponding to the local file and the form creation result corresponding to the form information includes: generating upload flag information corresponding to the local file; generating creation flag information corresponding to the form information; and confirming the file upload result and the form creation result based on the upload flag information and the creation flag information.

[0009] In some embodiments, when obtaining the upload progress information fed back by the self-mobile device during the vehicle log upload process, the method further includes: if the upload progress information is not received within a preset first timeout period, resending the log upload instruction to the self-mobile device; if the number of times the log upload is resent exceeds a preset threshold and / or the time corresponding to obtaining the upload progress information corresponding to the vehicle log is greater than a preset second timeout period, generating a communication abnormality warning and stopping the acquisition of the upload progress information.

[0010] In some embodiments, the method further includes: acquiring historical communication data and historical upload results corresponding to the log receiving end, terminal device, and self-moving device; constructing a communication quality prediction model based on the historical communication data and historical upload results; acquiring current communication data corresponding to the log receiving end, terminal device, and self-moving device; inputting the current communication data into the communication quality prediction model; and outputting communication stability prediction results corresponding to the log receiving end, terminal device, and self-moving device, so as to adjust the sending interval time corresponding to the log upload instruction based on the communication stability prediction results.

[0011] In some embodiments, the method further includes: obtaining network status parameters of the self-moving device; the network status parameters include at least one of bandwidth and latency jitter; calculating the theoretical upload speed versus expected progress curve of the self-moving device based on the network status parameters; obtaining deviation information corresponding to the theoretical upload speed versus expected progress curve and the upload progress information; if the deviation information does not meet preset deviation conditions, resending the log upload command to the self-moving device.

[0012] In some embodiments, before uploading the local file to the preset log receiving terminal, the method further includes: uploading the local file to the preset log receiving terminal after receiving the log upload request; and / or uploading the local file to the preset log receiving terminal according to preset log upload rules.

[0013] Secondly, this application provides a log uploading method applied to self-removable devices, the method comprising: Upload the vehicle logs to a preset log receiving terminal and obtain the upload progress information corresponding to the vehicle logs; Obtain the file upload result of the terminal device uploading a local file to the log receiving end; Obtain the form creation result from the log receiver based on the form information created from the local file; The log upload result is generated based on the file upload result, form creation result, and upload progress information.

[0014] Thirdly, this application also provides a log uploading system, including a log receiving end, a self-moving device, and a terminal device; The terminal device uploads a local file to the log receiving end, and the log receiving end generates form information corresponding to the local file. The terminal device generates and sends a log upload command to the self-moving device. The self-moving device responds to the log upload command and uploads the vehicle log to the log receiving end. The terminal device obtains the upload progress information corresponding to the vehicle log. The terminal device obtains the file upload result corresponding to the local file and the form creation result corresponding to the form information; The terminal device generates a log upload result based on the file upload result, form creation result, and upload progress information.

[0015] Fourthly, this application also provides a terminal device, characterized in that it includes a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor performs the steps of the log upload method described in the first aspect above.

[0016] Fifthly, this application also provides a self-moving device, characterized in that it includes a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor performs the steps of the log uploading method as described in the second aspect above.

[0017] Sixthly, this application also provides a computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, wherein when the computer-readable instructions are executed by the processor, one or more processors perform the steps of the log upload method as described in the first or second aspect above.

[0018] This application addresses the issue of inconsistent message states between the terminal device and the backend by sequentially uploading local files to the log receiving end, generating form information, sending instructions to trigger log upload on the vehicle end, and obtaining progress information after the terminal device receives a log upload request. Simultaneously, it obtains the local file upload result and the form creation result, and finally combines multiple results to generate the log upload result. This ensures that the log progress displayed on the terminal device is synchronized with the actual status in the backend, improves the accuracy and reliability of the log upload status display, and effectively solves the problem of inconsistent message states between the two ends in unstable communication scenarios.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic flowchart illustrating the steps of a first log upload method provided in an embodiment of this application; Figure 2 This is a schematic flowchart illustrating the steps of a second log upload method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a log upload device provided in an embodiment of this application; Figure 4 This is a schematic flowchart illustrating the steps of a third log upload method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a log transmission device provided in an embodiment of this application; Figure 6 This is a schematic block diagram of the structure of a log upload system provided in an embodiment of this application; Figure 7 This is a schematic block diagram of the structure of a terminal device provided in an embodiment of this application; Figure 8 This is a schematic block diagram of the structure of a self-moving device provided in an embodiment of this application.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0025] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0026] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0027] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0028] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0029] In the scenario of log upload between self-mobile devices and terminal devices with applications, when the self-mobile device cannot actively upload logs and needs the terminal device to send a command to notify it to upload, unstable communication may cause the terminal device to be unable to accurately obtain the log upload status of the self-mobile device, resulting in a discrepancy between the log progress displayed by the terminal device and the log progress actually transmitted by the self-mobile device to the log receiving end.

[0030] Therefore, a method is urgently needed to solve at least one of the above problems.

[0031] To resolve the above issues, please refer to [link / reference]. Figure 1 , Figure 1 This is a schematic flowchart illustrating a log upload method provided in one embodiment of this application. This log upload method can be implemented by a terminal device, which can be any type of smart terminal; this embodiment does not limit the type of terminal device.

[0032] To solve the above problem, please refer to Figure 1 Specifically, such as Figure 1 As shown, the provided log upload method includes steps S101 to S104. Details are as follows: Step S101. Upload a local file to a preset log receiving terminal, and trigger the log receiving terminal to generate form information corresponding to the local file.

[0033] Specifically, the terminal device selects a file from its own storage that needs to be associated with the vehicle-side logs for reporting. This file can be: a log file generated by the terminal device itself; a configuration file containing metadata for this report (such as task ID, timestamp, and device information); or a lightweight "tag file" (the content of which may be very simple, such as a JSON string) used to establish synchronization relationships.

[0034] The terminal device uploads selected local files to a pre-configured cloud server, i.e., the log receiver, via HTTP / HTTPS, FTP, or other file transfer protocols. It should be noted that the log receiver can also be any of the following: a backend system, a local gateway / maintenance platform, or a relay node; this embodiment of the application does not impose any limitations on this.

[0035] In the upload request, or via another API call after successful file upload, the log receiver is notified to create a unique database record or form for the newly uploaded file. Form information typically includes file identifiers such as the file's unique cloud storage path, URL, or File ID. Task / Session Identifier: A globally unique ID used to associate terminal uploads and vehicle uploads to the same "log reporting task." Metadata: Upload time, terminal device ID, file size, hash value, etc. Status Field: Initial status is either pending association or the terminal file is ready.

[0036] For example, the terminal device (such as a mobile app, referred to as "APP terminal" in this specification) first uploads the locally stored log file to a preset server (log receiving end), and triggers the server to generate corresponding form information for the file. The form information is typically used to record file metadata (such as file ID, upload time, user identifier, etc.) for subsequent management and querying.

[0037] After detecting a user-triggered log upload operation or a log upload operation performed at a preset time interval, the terminal device reads local log files (such as APP running logs, error records, etc.). It then calls a server interface (such as HTTP POST) to upload the file to the server and requests the creation of an associated form. The server receives the file, stores it in a specified path, and generates a unique form ID and metadata, returning it to the APP. The APP records the file upload status (e.g., "Uploading") and waits for a server response. If the upload is successful, the file upload status is marked as "Successful"; if it fails, it is marked as "Failed".

[0038] Step S102. Generate and send a log upload command to a preset self-moving device to trigger the self-moving device to respond to the log upload command and perform vehicle log upload processing.

[0039] Specifically, the terminal device assembles an instruction message. This instruction must contain a unique task identifier corresponding to the form created in step S101, so that the mobile device knows to associate its logs with this operation on the terminal. The instruction may also include: the address of the log receiving end; the type or path of the vehicle log to be uploaded; and control parameters such as timeout.

[0040] Instructions are sent to the self-moving device via a communication link between the vehicle's infotainment system and the terminal device (such as Bluetooth, Wi-Fi Direct, or cellular socket connection). Upon receiving the instructions, the agent or SDK on the self-moving device parses the task ID and cloud address, begins collecting the specified vehicle log file, and initiates an upload to the same log receiver. The upload request carries the same task ID, allowing the cloud to identify it as part of the same vehicle-side task.

[0041] For example, after completing the local file upload, the app sends a command to the mobile device (such as the in-vehicle infotainment system) to start uploading the vehicle logs to the same log receiving terminal. Since the vehicle cannot upload files proactively, the command must be initiated by the app.

[0042] The app sends structured instructions (such as JSON format) to the vehicle's infotainment system via wireless communication (e.g., Bluetooth, Wi-Fi, or cellular network). These instructions include the operation type ("upload log"), server address, form ID, and other information. Upon receiving the instructions, the vehicle's infotainment system begins reading local vehicle logs (such as vehicle sensor data and system logs) and uploads them to the server in batches. Simultaneously, the app initiates a monitoring mechanism, waiting for the vehicle to return upload progress information.

[0043] Step S103. Obtain the file upload result corresponding to the local file, the form creation result corresponding to the form information, and the upload progress information fed back by the self-mobile device during the process of uploading the vehicle log.

[0044] Specifically, the terminal device collects status information from three independent sources, which forms the basis for synchronous judgment. These include: File upload result: a direct result of the operation itself in step S101 (success / failure). Form creation result: the response from the log receiver to the form creation request (success / failure, and details such as form ID). Vehicle-side upload progress information: this is asynchronous feedback. During the upload process, the self-moving device needs to periodically or in stages report its progress to the terminal device through the communication link between the vehicle and the terminal. The progress information should include: Task ID. Current status: such as "Collecting logs", "Uploading (30%)", "Upload complete", "Upload failed (reason: network disconnection)". Timestamp.

[0045] For example, the APP needs to monitor three aspects of status simultaneously: (1) local file upload result; (2) server form creation result; (3) real-time progress information of vehicle log upload.

[0046] The system monitors local file and form status by maintaining flags corresponding to file upload and form creation statuses via the app. These flags are updated based on the server's response (success / failure).

[0047] Monitoring vehicle-side upload progress: During the upload process, the vehicle's infotainment system periodically sends progress information (e.g., "30% uploaded") to the app. Upon receiving the progress, the app updates its interface in real time and sends a confirmation command to the vehicle. The vehicle then sends the next batch of progress information after receiving confirmation. If the app does not receive progress information from the vehicle within 3 minutes, it determines a communication timeout and sends a "Terminate Upload" command to the vehicle. If the vehicle does not receive confirmation from the app, it also times out and terminates the upload, notifying the app.

[0048] Step S104. Generate a log upload result based on the file upload result, the form creation result, and the upload progress information.

[0049] Specifically, the terminal device integrates information from three aspects and uses a set of rules to synthesize the final, reliable "log upload result." This result no longer relies solely on unstable direct feedback from the vehicle end, but is based on its own successful operation as a foundation of trust.

[0050] If either the file upload or form creation fails, the entire task is immediately deemed a failure because the synchronization anchor point was not successfully established. The task itself is considered successful, awaiting feedback from the vehicle: If the vehicle upload progress information is "Upload Complete" and the form is confirmed to be associated, the final result is "Success." If the vehicle upload progress information is "Upload Failed," the final result is "Failure (Vehicle-side Reason)." If no vehicle progress update is received for an extended period (timeout), the final result is "Failure (Vehicle-side No Response or Communication Interruption)." At this point, the terminal can actively query the log receiver, using the task ID to inquire whether the cloud has received the vehicle's log file. If received, the status can be corrected to "Success"; if not received, it is confirmed as "Failure."

[0051] The terminal can periodically poll the log receiver to query the form status corresponding to the task ID. If the cloud form status is successfully updated to "Vehicle log associated" or "Completed" by the vehicle, then even if the feedback from the vehicle to the terminal is lost, the terminal can still know the final success status from the trusted source of the cloud.

[0052] For example, based on all the status information obtained in step S103, it is determined whether the overall log upload was successful, and corresponding operations are performed.

[0053] The judgment criteria include checking whether the local file upload and form creation were both successful when the upload progress on the vehicle side reaches 100%. If all three are successful (successful file upload + successful form creation + 100% vehicle progress), a "Log upload successful" result is generated. If any step fails, a "Log upload failed" result is generated.

[0054] In case of exception handling, if file or form creation fails, the app must send a request to the server to delete the created form (to avoid residual invalid data). If the upload is interrupted or times out on the vehicle side, the app will display "Upload Timeout" and stop updating the progress, while simultaneously notifying the vehicle side to terminate the upload.

[0055] The status synchronization mechanism ensures consistency between the two ends through two-way confirmation communication (the vehicle sends the next progress only after the APP confirms receipt of the progress). Timeout control (e.g., 3 minutes) prevents infinite waiting; both parties terminate the operation synchronously after the timeout.

[0056] In some embodiments, such as Figure 2As shown, before generating the log upload result based on the file upload result, the form creation result, and the upload progress information, steps S105 and S106 are also included.

[0057] Step S105. During the process of the self-mobile device uploading the vehicle log, receive the upload progress information sent by the self-mobile device; Step S106. After receiving the upload progress information, a progress confirmation instruction is sent to the self-moving device, so that the self-moving device performs the vehicle log upload process corresponding to the upload progress information after receiving the progress confirmation instruction.

[0058] Before generating log upload results, a progress information receiving and confirmation mechanism is used to ensure that the upload status of the terminal device and the self-moving device are synchronized.

[0059] Progress information reception involves continuously monitoring the upload progress information (such as the amount of data uploaded, percentage, etc.) sent by the self-moving device during the upload of vehicle logs.

[0060] After receiving the progress information through the terminal device, the progress confirmation feedback immediately sends a "progress confirmation instruction" (such as an ACK message containing a timestamp) to the self-moving device to inform the self-moving device that it has correctly received the current progress.

[0061] After the mobile device receives the confirmation instruction, it continues to execute the upload task based on the current progress, avoiding duplicate uploads or progress jumps due to information loss.

[0062] In some embodiments, the method further includes: when it is confirmed that the log upload result is an upload failure based on the file upload result, the form creation result, and the upload progress information, generating a cleanup instruction and sending it to the log receiving end, so that the log receiving end performs cleanup processing on the form information and / or vehicle logs corresponding to the log upload result.

[0063] When log upload fails, invalid data on the log receiver is automatically cleaned up to release resources and prevent dirty data residue.

[0064] If step S104 confirms that the log upload result is "upload failed" (e.g., local file upload failed, form creation failed, or vehicle log upload failed), the cleanup process is triggered. The terminal device sends a "cleanup instruction" to the log receiver, which includes the identifiers of the form information to be cleaned (e.g., form ID) and / or the vehicle log identifiers (e.g., device number + timestamp). After receiving the instruction, the log receiver deletes the corresponding form information (e.g., upload task metadata) and / or incompletely uploaded vehicle log files to ensure clean storage resources.

[0065] In some embodiments, generating a log upload result based on the file upload result, form creation result, and upload progress information includes: if the file upload result, form creation result, and vehicle log upload are all confirmed to be successful based on the file upload result, form creation result, and upload progress information, then the log upload result is confirmed to be successful; if the file upload result, form creation result, or vehicle log upload is confirmed to be unsuccessful based on the file upload result, form creation result, and upload progress information, then the log upload result is confirmed to be unsuccessful.

[0066] By clearly defining the criteria for successful log upload, all three elements—local file, form information, and vehicle log—must be successfully uploaded / created; otherwise, the upload is considered a failure.

[0067] If the local file upload is successful, the local file in step S101 is successfully transmitted to the log receiver, and the receiver returns a success response. If the form is successfully created, the log receiver generates valid form information (such as metadata including file hash value and upload time) based on the uploaded local file. If the vehicle log upload is successful, the upload progress information fed back by the self-moving device finally reaches 100%, and the log receiver confirms that it has completely received the vehicle log data.

[0068] If all the above conditions are met, the log upload result is successful; if any condition is not met (such as file upload timeout, form creation failure, vehicle log interruption), the result is upload failure.

[0069] In some embodiments, obtaining the file upload result corresponding to the local file and the form creation result corresponding to the form information includes: generating upload flag information corresponding to the local file; generating creation flag information corresponding to the form information; and confirming the file upload result and the form creation result based on the upload flag information and the creation flag information.

[0070] By generating flag information (such as status codes and timestamps), the status of local file uploads and form creation can be accurately tracked.

[0071] When uploading a local file in step S101, the terminal device generates a unique upload identifier (such as UUID + timestamp) and sends it to the log receiver along with the file. After processing, the receiver returns a success / failure status containing this identifier.

[0072] When the log receiver generates form information, it simultaneously generates "creation flag information" (such as the form ID) and returns it to the terminal device. The terminal device confirms the form creation result by checking the existence and status of this flag. Based on the returned status of the upload flag and the creation flag, the terminal device determines whether the file upload and form creation were successful.

[0073] In some embodiments, when obtaining the upload progress information fed back by the self-mobile device during the vehicle log upload process, the method further includes: if the upload progress information is not received within a preset first timeout period, resending the log upload instruction to the self-mobile device; if the number of times the log upload is resent exceeds a preset threshold and / or the time corresponding to obtaining the upload progress information corresponding to the vehicle log is greater than a preset second timeout period, generating a communication abnormality warning and stopping the acquisition of the upload progress information.

[0074] To address communication delays or interruptions, a timeout retransmission mechanism and anomaly warnings are designed to avoid indefinite waiting.

[0075] When obtaining upload progress information in step S103, if no progress feedback is received from the self-moving device within the preset first timeout period (e.g., 30 seconds), the terminal device resends the log upload command to attempt to wake up or re-trigger the upload task of the self-moving device.

[0076] If the number of retransmissions exceeds a preset threshold (e.g., 3 times) or the total waiting time exceeds a preset second timeout (e.g., 5 minutes), the terminal device will generate a communication anomaly warning (e.g., pop-up notification or log record) and stop acquiring progress information to avoid wasting resources.

[0077] In some embodiments, the method further includes: acquiring historical communication data and historical upload results corresponding to the log receiving end, terminal device, and self-moving device; constructing a communication quality prediction model based on the historical communication data and historical upload results; acquiring current communication data corresponding to the log receiving end, terminal device, and self-moving device; inputting the current communication data into the communication quality prediction model; and outputting communication stability prediction results corresponding to the log receiving end, terminal device, and self-moving device, so as to adjust the sending interval time corresponding to the log upload instruction based on the communication stability prediction results.

[0078] A predictive model is built based on historical communication data to dynamically adjust the sending interval of log upload commands and optimize communication stability.

[0079] Collect historical communication data (such as latency, packet loss rate, and transmission rate) and historical upload results (success / failure) from log receivers, terminal devices, and self-moving devices. Use machine learning algorithms (such as regression models and time series prediction) to build a "communication quality prediction model" and train the model to predict current communication stability. Obtain current communication data (such as current network latency and signal strength) from the three-party devices in real time.

[0080] Input the current data into the model. If the predicted communication is unstable (e.g., high packet loss rate), increase the sending interval of log upload commands (e.g., from 10 seconds to 30 seconds) to reduce command loss due to network congestion. If the prediction is stable, shorten the interval to improve efficiency.

[0081] In some embodiments, the method further includes: obtaining network status parameters of the self-moving device; the network status parameters include at least one of bandwidth and latency jitter; calculating the theoretical upload speed versus expected progress curve of the self-moving device based on the network status parameters; obtaining deviation information corresponding to the theoretical upload speed versus expected progress curve and the upload progress information; if the deviation information does not meet preset deviation conditions, resending the log upload command to the self-moving device.

[0082] By combining the real-time network status of the mobile device (such as bandwidth and latency jitter), the upload progress is dynamically calibrated and abnormal deviations are handled in a timely manner.

[0083] The terminal device obtains network status parameters of the self-moving device via protocols (such as SNMP, HTTP API), including bandwidth (such as currently available upload bandwidth) and latency jitter (such as RTT fluctuation range). It calculates the "theoretical upload speed" (such as bandwidth × 80% utilization) based on the bandwidth and generates an "expected progress curve" (such as the amount of data to be uploaded every 10 seconds). The actual upload progress information reported by the self-moving device is compared with the expected curve. If the deviation exceeds a preset threshold (such as actual progress lagging by 20%), it is judged as abnormal, and the log upload command is resent to trigger retransmission or adjust the upload strategy.

[0084] In some embodiments, before uploading the local file to the preset log receiving terminal, the method further includes: uploading the local file to the preset log receiving terminal after receiving the log upload request; and / or uploading the local file to the preset log receiving terminal according to preset log upload rules.

[0085] By defining the trigger conditions for local file uploads, manual requests or automatic rule triggers can be supported, improving flexibility.

[0086] After receiving a log upload request from a user or an upper-layer system (such as when a user clicks the "Upload Log" button in the APP), the terminal device executes step S101 to upload the local file to the log receiving end.

[0087] Terminal devices can also automatically trigger local file uploads based on preset "log upload rules" (such as 1 AM every day, when the device battery level is above 80%, or when the cumulative log volume exceeds 1GB), without manual intervention. This embodiment supports both manual and automatic rules, prioritizing manual requests and using automatic rules as a fallback mechanism.

[0088] In some embodiments, by introducing reinforcement learning (RL) algorithms, the sending strategy of log upload instructions is automatically optimized based on the real-time communication status, thereby reducing synchronization deviations caused by network latency or packet loss.

[0089] Environmental modeling abstracts the communication interactions between the terminal device (APP), the self-moving device (vehicle), and the log receiver into a "state-action-reward" model: State includes current network latency, packet loss rate, vehicle battery level, and log file size. Actions are defined by adjusting command sending intervals (e.g., 10 seconds, 30 seconds, dynamic intervals), retransmission thresholds, and packet size. Rewards include a +100 bonus for successful uploads, a -50 penalty for timeouts or failures, and a +20 bonus for stable communication.

[0090] Train RL agents (such as DQN and PPO algorithms) using historical communication data and uploaded results to learn the optimal command sending strategy under different network conditions.

[0091] When the log upload command is sent in step S102, the agent selects the optimal action based on the current state (such as increasing the interval or reducing the packet size when the packet loss rate is high), and dynamically adjusts the strategy based on feedback in step S103. For example, if the vehicle-side progress information is received three times in a row, the communication is determined to be stable, and the command interval is shortened to speed up the upload; if a timeout occurs, the intelligent retransmission strategy is triggered, and the timing of the next retransmission is automatically adjusted based on the predicted network recovery time.

[0092] In some embodiments, by utilizing Long Short-Term Memory (LSTM) networks to predict the network connection quality between the vehicle and the app, log upload tasks can be pre-distributed to avoid communication bottlenecks.

[0093] Time-series data modeling collects historical network status data from the vehicle (such as bandwidth, latency, and signal strength in the past hour) and uses an LSTM model to predict the network stability score for the next 5 minutes (0-100 points, with scores below 50 points considered unstable).

[0094] If the network is stable, in step S102, the APP communicates directly with the vehicle and uploads logs according to the normal procedure. If the network is unstable, the "edge traffic splitting strategy" is triggered. The vehicle first uploads the logs to the edge node through a nearby edge server (such as a parking lot WiFi hotspot or a roadside unit RSU) as a relay node, and then the edge node synchronizes the logs to the log receiving end, reducing the direct communication pressure between the APP and the vehicle.

[0095] In step S103, the prediction results are monitored in real time. If the network score suddenly drops, the system automatically switches to the edge routing path and notifies the user via the APP that the current relay upload is being used to ensure progress synchronization.

[0096] In some embodiments, federated learning is used to train a communication optimization model by combining data from multiple user devices without sharing the original data, thereby improving the universality of cross-device communication.

[0097] Each terminal device (APP) and self-moving device locally collects communication data (such as latency and command response time), trains a lightweight neural network model (such as a CNN-LSTM hybrid model) locally, and only uploads the model parameters to the central server for updates. The central server aggregates the parameters from multiple devices, generates a globally optimized model, and then distributes it to each device to update its local model.

[0098] Before sending the instruction in step S102, the local model predicts the reliability probability of the current communication link (e.g., if 90% reliable, it sends directly; if less than 70%, it first sends a "heartbeat packet" to test connectivity). When receiving progress information in step S103, the model automatically identifies abnormal data patterns (e.g., progress jumps, long periods without updates) and triggers intelligent retransmission or status verification instructions (e.g., requiring the vehicle to return the hash value of the current uploaded bytes for comparison with the server). Data is processed only locally on the device, preventing the leakage of user log data and communication information, and complying with privacy regulations such as GDPR.

[0099] In some embodiments, a fuzzy logic system is employed to handle uncertainties in communication, dynamically adjusting the retransmission strategy to balance efficiency and reliability.

[0100] Fuzzy rule definition: Input variables: Number of timeouts (low / medium / high): The number of consecutive times that no progress information is received in step S103; Network latency change rate (negative / zero / positive): The ratio of the difference between the current latency and the historical average latency; Output variables: Retransmission interval multiple (1x / 2x / 5x): Dynamically adjusted based on the number of timeouts and latency changes; Instruction priority (high / medium / low): High-priority instructions can preempt network resources of low-priority tasks.

[0101] Example of a rule engine: If "timeout count = high" and "latency change rate = positive", then network congestion is determined, the retransmission interval multiplier = 5 times, and the command priority is reduced to avoid aggravating congestion; if "timeout count = low" and "latency change rate = negative", then network recovery is determined, the retransmission interval multiplier = 1 times, and the priority is increased to speed up uploading.

[0102] In the timeout processing of step S105, the optimal retransmission strategy is calculated in real time through the fuzzy logic system to avoid the "avalanche effect" caused by traditional fixed-interval retransmission (such as network congestion caused by multiple devices retransmitting at the same time).

[0103] In some embodiments, by utilizing generative adversarial networks to simulate extreme communication anomalies (such as high packet loss rate or intermittent network outages), a more robust upload strategy is pre-trained to improve the system's fault tolerance.

[0104] Data generation: The generator learns the distribution of real communication data and generates simulated abnormal communication sequences (such as a virtual network environment with 70% random packet loss and a 10-fold increase in latency); the discriminator distinguishes between real data and generated data, forcing the generator to output data that is closer to the extreme scenarios in reality.

[0105] The strategy pre-training uses generated abnormal data to train the fault tolerance logic of the upload process. For example, in the scenario of simulating "five consecutive lost commands", the training system automatically switches to Bluetooth Low Energy (BLE) as a backup communication channel; in the scenario of simulating "intermittent vehicle network", the training system caches unconfirmed progress information on the vehicle side and resends it in batches after the network is restored.

[0106] In the normal process of steps S102-S103, if the actual communication status is detected to match the pre-trained abnormal pattern (such as packet loss rate > 60%), the pre-trained fault tolerance strategy is automatically activated. For example, the vehicle end encrypts the logs in blocks and temporarily stores them locally. After each block is successfully uploaded, the local cache is deleted immediately to avoid storage backlog. The APP end maintains a "heartbeat" with the vehicle end through a WebSocket long connection and synchronizes a minimized progress summary in real time (such as transmitting only the increment of the current progress percentage every 5 seconds).

[0107] Please see Figure 3 As shown, Figure 3 This is a schematic diagram of the structure of the log upload device 200 provided in this application embodiment. The log upload device 200 is used to execute the steps of the log upload method shown in the above embodiments. The log upload device 200 can be a single server or a server cluster, or it can be a terminal, such as a handheld terminal, a laptop computer, a wearable device, or a terminal device.

[0108] like Figure 3 As shown, the log upload device 200 includes: The form generation unit 201 is used to upload a local file to a preset log receiving terminal and trigger the log receiving terminal to generate form information corresponding to the local file. The instruction generation unit 202 is used to generate and send a log upload instruction to a preset self-mobile device to trigger the self-mobile device to respond to the log upload instruction and perform vehicle log upload processing. The result acquisition unit 203 is used to acquire the file upload result corresponding to the local file, the form creation result corresponding to the form information, and the upload progress information fed back by the self-mobile device during the process of uploading the vehicle log. The result generation unit 204 is used to generate a log upload result based on the file upload result, the form creation result, and the upload progress information.

[0109] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the log upload device and its modules described above can be referred to the corresponding processes in the log upload method embodiments described above, and will not be repeated here.

[0110] The above-described log upload method can be implemented as a computer program, which can be used in various ways, such as... Figure 3 It runs on the device shown.

[0111] Please see Figure 4 , Figure 4 This is a schematic flowchart of a log upload method provided in one embodiment of this application. This log upload method can be implemented by a self-moving device, which can be of any type. This embodiment of the application does not limit the type of terminal device.

[0112] To solve the above problem, please refer to Figure 1 Specifically, such as Figure 1 As shown, the provided log upload method includes steps S301 to S304. Details are as follows: Step S301. Upload the vehicle log to the preset log receiving terminal and obtain the upload progress information corresponding to the vehicle log; Step S302. Obtain the file upload result of the terminal device uploading local files to the log receiving end; Step S303. Obtain the form creation result of the log receiving end based on the form information created by the local file; Step S304. Generate log upload results based on the file upload results, form creation results, and upload progress information.

[0113] In some embodiments, generating a log upload result based on the file upload result, form creation result, and upload progress information includes: if the file upload result, form creation result, and vehicle log upload are all confirmed to be successful based on the file upload result, form creation result, and upload progress information, then the log upload result is confirmed to be successful; if the file upload result, form creation result, or vehicle log upload is confirmed to be unsuccessful based on the file upload result, form creation result, and upload progress information, then the log upload result is confirmed to be unsuccessful.

[0114] In some embodiments, obtaining the form creation result of the log receiving end based on the form information created by the local file includes: generating upload flag information corresponding to the local file; generating creation flag information corresponding to the form information; and confirming the file upload result and the form creation result based on the upload flag information and the creation flag information.

[0115] In some embodiments, the method further includes: acquiring historical communication data and historical upload results corresponding to the log receiving end, terminal device, and self-moving device; constructing a communication quality prediction model based on the historical communication data and historical upload results; acquiring current communication data corresponding to the log receiving end, terminal device, and self-moving device; inputting the current communication data into the communication quality prediction model; and outputting communication stability prediction results corresponding to the log receiving end, terminal device, and self-moving device, so as to adjust the sending interval time corresponding to the log upload instruction based on the communication stability prediction results.

[0116] In some embodiments, the method further includes: obtaining network status parameters of the self-moving device; the network status parameters include at least one of bandwidth and latency jitter; calculating the theoretical upload speed versus expected progress curve of the self-moving device based on the network status parameters; obtaining deviation information corresponding to the theoretical upload speed versus expected progress curve and the upload progress information; if the deviation information does not meet preset deviation conditions, resending the log upload command to the self-moving device.

[0117] In some embodiments, before uploading the local file to the preset log receiving terminal, the method further includes: uploading the local file to the preset log receiving terminal after receiving the log upload request; and / or uploading the local file to the preset log receiving terminal according to preset log upload rules.

[0118] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the log upload method and the specific working process of each step described above can be referred to the corresponding process in the log upload method embodiments described above, and will not be repeated here.

[0119] Please see Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of the log transmission device 400 provided in the embodiments of this application. The log transmission device 400 is used to perform the steps of the log upload method shown in the above embodiments. The log transmission device 400 can be a single server or a server cluster, or the log transmission device 400 can be a terminal, such as a handheld terminal, a laptop computer, a wearable device, or a terminal device.

[0120] like Figure 5 As shown, the log transmission device 400 includes: The progress acquisition unit 401 is used to upload the vehicle log to a preset log receiving terminal and acquire the upload progress information corresponding to the vehicle log. The upload acquisition unit 402 is used to acquire the file upload result of the terminal device uploading a local file to the log receiving end; The form acquisition unit 403 is used to acquire the form creation result of the log receiving end creating form information based on the local file; The result transmission unit 404 is used to generate a log upload result based on the file upload result, form creation result, and upload progress information.

[0121] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the log transmission device and each module described above can be referred to the corresponding processes in the log upload method embodiments described above, and will not be repeated here.

[0122] The above-described log upload method can be implemented as a computer program, which can be used in various ways, such as... Figure 5 It runs on the device shown.

[0123] Please see Figure 6 As shown, this application also provides a log upload system 100, including a terminal device 10, a log receiving end 20, and a self-moving device 30; the terminal device uploads a local file to the log receiving end, and the log receiving end generates form information corresponding to the local file; the terminal device generates and sends a log upload command to the self-moving device, and the self-moving device responds to the log upload command by uploading a vehicle log to the log receiving end; the terminal device obtains the upload progress information corresponding to the vehicle log; the terminal device obtains the file upload result corresponding to the local file and the form creation result corresponding to the form information; the terminal device generates a log upload result based on the file upload result, the form creation result, and the upload progress information.

[0124] In some embodiments, before generating the log upload result based on the file upload result, the form creation result, and the upload progress information, the method further includes: during the process of the self-mobile device performing vehicle log upload processing, the terminal device receives the upload progress information sent by the self-mobile device; after receiving the upload progress information, the terminal device sends a progress confirmation instruction to the self-mobile device, so that the self-mobile device performs vehicle log upload processing corresponding to the upload progress information after receiving the progress confirmation instruction.

[0125] In some embodiments, the method further includes: when the log upload result is confirmed to be an upload failure based on the file upload result, the form creation result, and the upload progress information, the terminal device generates a cleanup instruction and sends it to the log receiving end, so that the log receiving end performs cleanup processing on the form information and / or vehicle logs corresponding to the log upload result.

[0126] In some embodiments, generating a log upload result based on the file upload result, form creation result, and upload progress information includes: if the local file upload is confirmed to be successful, the form information creation is confirmed to be successful, and the vehicle log upload is confirmed to be successful based on the file upload result, form creation result, and upload progress information, the terminal device confirms that the log upload result is a successful upload; if the upload of the local file, the creation of the form information, or the upload of the vehicle log is confirmed to be a failed upload based on the file upload result, form creation result, and upload progress information, the terminal device confirms that the log upload result is a failed upload.

[0127] In some embodiments, obtaining the file upload result corresponding to the local file and the form creation result corresponding to the form information includes: the terminal device generating upload flag information corresponding to the local file; generating creation flag information corresponding to the form information; and the terminal device confirming the file upload result and the form creation result based on the upload flag information and the creation flag information.

[0128] In some embodiments, when obtaining the upload progress information fed back by the self-mobile device during the vehicle log upload process, the method further includes: if the upload progress information is not received within a preset first timeout period, the terminal device resends the log upload instruction to the self-mobile device; if the number of times the log upload is resent exceeds a preset threshold and / or the time corresponding to obtaining the upload progress information corresponding to the vehicle log is greater than a preset second timeout period, the terminal device generates a communication abnormality warning and stops obtaining the upload progress information.

[0129] In some embodiments, the method further includes: the terminal device acquiring historical communication data and historical upload results corresponding to the log receiver, the terminal device, and the self-moving device, and constructing a communication quality prediction model based on the historical communication data and historical upload results; the terminal device acquiring current communication data corresponding to the log receiver, the terminal device, and the self-moving device; the terminal device inputting the current communication data into the communication quality prediction model, and outputting communication stability prediction results corresponding to the log receiver, the terminal device, and the self-moving device, so as to adjust the sending interval time corresponding to the log upload instruction based on the communication stability prediction results.

[0130] In some embodiments, the method further includes: the terminal device acquiring network status parameters of the self-moving device; the network status parameters including at least one of bandwidth and latency jitter; the terminal device calculating the theoretical upload speed versus expected progress curve corresponding to the self-moving device based on the network status parameters; the terminal device acquiring deviation information corresponding to the theoretical upload speed versus expected progress curve and the upload progress information; if the deviation information does not meet preset deviation conditions, resending the log upload instruction to the self-moving device.

[0131] In some embodiments, before uploading the local file to the preset log receiving terminal, the method further includes: after receiving a log upload request, the terminal device uploads the local file to the preset log receiving terminal; and / or, the terminal device uploads the local file to the preset log receiving terminal according to preset log upload rules.

[0132] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the log upload system and its modules described above can be referred to the corresponding processes in the log upload method embodiments described above, and will not be repeated here.

[0133] Please see Figure 7 , Figure 7 This is a schematic block diagram of the structure of a terminal device provided in an embodiment of this application. The terminal device includes a processor, a memory, and a network interface connected via a device bus, wherein the memory may include a storage medium and internal memory.

[0134] The storage medium may store operating devices and computer programs. The computer program includes program instructions that, when executed, cause the processor to perform any log-uploading method.

[0135] The processor provides computing and control capabilities to support the operation of the entire terminal device.

[0136] Internal memory provides an environment for the execution of computer programs on non-volatile storage media, which, when executed by a processor, enable the processor to perform any log uploading method.

[0137] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the solution of this application and does not constitute a limitation on the terminal to which the solution of this application is applied. Specific terminal devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0138] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0139] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Upload a local file to a preset log receiving terminal, and trigger the log receiving terminal to generate form information corresponding to the local file; Generate and send a log upload command to a preset self-mobile device to trigger the self-mobile device to respond to the log upload command and perform vehicle log upload processing; Obtain the file upload result corresponding to the local file, the form creation result corresponding to the form information, and the upload progress information fed back by the self-mobile device during the process of uploading the vehicle log; A log upload result is generated based on the file upload result, the form creation result, and the upload progress information.

[0140] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the steps described above can be referred to the corresponding process in the log upload method embodiments described above, and will not be repeated here.

[0141] Please see Figure 8 , Figure 8 This is a schematic block diagram of the structure of a self-moving device provided in an embodiment of this application. The terminal device includes a processor, a memory, and a network interface connected via a device bus, wherein the memory may include a storage medium and internal memory.

[0142] The storage medium may store operating devices and computer programs. The computer program includes program instructions that, when executed, cause the processor to perform any log-uploading method.

[0143] The processor provides computing and control capabilities to support the operation of the entire terminal device.

[0144] Internal memory provides an environment for the execution of computer programs on non-volatile storage media, which, when executed by a processor, enable the processor to perform any log uploading method.

[0145] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the solution of this application and does not constitute a limitation on the terminal to which the solution of this application is applied. Specific terminal devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0146] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0147] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Upload a local file to a preset log receiving terminal, and trigger the log receiving terminal to generate form information corresponding to the local file; Generate and send a log upload command to a preset self-mobile device to trigger the self-mobile device to respond to the log upload command and perform vehicle log upload processing; Obtain the file upload result corresponding to the local file, the form creation result corresponding to the form information, and the upload progress information fed back by the self-mobile device during the process of uploading the vehicle log; A log upload result is generated based on the file upload result, the form creation result, and the upload progress information.

[0148] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the steps described above can be referred to the corresponding process in the log upload method embodiments described above, and will not be repeated here.

[0149] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the steps of the method provided in any embodiment of this application.

[0150] The computer-readable storage medium can be an internal storage unit of the terminal device described in the foregoing embodiments, such as the hard disk or memory of the terminal device. Alternatively, the computer-readable storage medium can be an external storage device of the terminal device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., provided on the terminal device.

[0151] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A log upload method, characterized in that, Applied to a terminal device, the method includes: Upload a local file to a preset log receiving terminal, and trigger the log receiving terminal to generate form information corresponding to the local file; Generate and send a log upload command to a preset self-mobile device to trigger the self-mobile device to respond to the log upload command and perform vehicle log upload processing; Obtain the file upload result corresponding to the local file, the form creation result corresponding to the form information, and the upload progress information fed back by the self-mobile device during the process of uploading the vehicle log; A log upload result is generated based on the file upload result, the form creation result, and the upload progress information.

2. The method according to claim 1, characterized in that, Before generating the log upload result based on the file upload result, the form creation result, and the upload progress information, the method further includes: During the process of uploading vehicle logs by the self-mobile device, the upload progress information sent by the self-mobile device is received; After receiving the upload progress information, a progress confirmation command is sent to the self-mobile device, so that the self-mobile device can perform the vehicle log upload process corresponding to the upload progress information after receiving the progress confirmation command.

3. The method according to claim 2, characterized in that, The method further includes: When the log upload result is confirmed to be a failure based on the file upload result, the form creation result, and the upload progress information, a cleanup instruction is generated and sent to the log receiving end, so that the log receiving end performs cleanup processing on the form information and / or vehicle logs corresponding to the log upload result.

4. The method according to claim 1, characterized in that, The step of generating log upload results based on the file upload result, form creation result, and upload progress information includes: If the local file is successfully uploaded, the form is successfully created, and the vehicle log is successfully uploaded based on the file upload result, the form creation result, and the upload progress information, then the log upload result is confirmed as a successful upload. If, based on the file upload result, form creation result, and upload progress information, it is confirmed that any one of the following has failed: the upload of the local file, the creation of the form information, or the upload of the vehicle log, then the log upload result is confirmed as an upload failure.

5. The method according to claim 1, characterized in that, The step of obtaining the file upload result corresponding to the local file and the form creation result corresponding to the form information includes: Generate upload flag information corresponding to the local file; Generate the creation flag information corresponding to the form information; The file upload result and the form creation result are confirmed based on the upload flag information and the creation flag information.

6. The method according to claim 1, characterized in that, When obtaining the upload progress information fed back by the self-mobile device during the vehicle log upload process, the method further includes: If the upload progress information is not received within the preset first timeout period, the log upload command is resent to the self-moving device; If the number of times the log upload is resent exceeds a preset threshold and / or the time corresponding to obtaining the upload progress information of the vehicle log is greater than a preset second timeout, a communication abnormality warning is generated and the acquisition of the upload progress information is stopped.

7. The method according to claim 1, characterized in that, The method further includes: Obtain historical communication data and historical upload results corresponding to the log receiving end, terminal device and self-moving device, and construct a communication quality prediction model based on the historical communication data and historical upload results; Obtain the current communication data corresponding to the log receiving end, terminal device, and self-moving device; The current communication data is input into the communication quality prediction model, and the communication stability prediction results corresponding to the log receiver, terminal device and self-moving device are output, so as to adjust the sending interval time corresponding to the log upload command according to the communication stability prediction results.

8. The method according to claim 1, characterized in that, The method further includes: Obtain the network status parameters of the self-mobile device; the network status parameters include at least one of bandwidth and latency jitter. Calculate the theoretical upload speed and expected progress curve corresponding to the self-moving device based on the network status parameters; Obtain the deviation information corresponding to the theoretical upload speed and the expected progress curve and the upload progress information. If the deviation information does not meet the preset deviation conditions, resend the log upload command to the self-moving device.

9. The method according to claim 1, characterized in that, Before uploading the local file to the preset log receiver, the following is also included: Upon receiving a log upload request, upload the local file to the preset log receiver; and / or, Upload local files to the preset log receiving end according to the preset log upload rules.

10. A log upload method, characterized in that, Applied to self-moving devices, the method includes: Upload the vehicle logs to a preset log receiving terminal and obtain the upload progress information corresponding to the vehicle logs; Obtain the file upload result of the terminal device uploading a local file to the log receiving end; Obtain the form creation result from the log receiver based on the form information created from the local file; The log upload result is generated based on the file upload result, form creation result, and upload progress information.

11. A log upload system, characterized in that, This includes log receivers, self-moving devices, and terminal devices; The terminal device uploads a local file to the log receiving end, and the log receiving end generates form information corresponding to the local file. The terminal device generates and sends a log upload command to the self-moving device. The self-moving device responds to the log upload command and uploads the vehicle log to the log receiving end. The terminal device obtains the upload progress information corresponding to the vehicle log. The terminal device obtains the file upload result corresponding to the local file and the form creation result corresponding to the form information; The terminal device generates a log upload result based on the file upload result, form creation result, and upload progress information.

12. A terminal device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 9.

13. A self-moving device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, cause the processor to perform the steps of the method as described in claim 10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer-readable instructions of which, when executed by the processor, cause one or more processors to perform the steps of the method as described in any one of claims 1 to 9, or to perform the steps of the method as described in claim 10.

Images