Helmet abnormity processing method and device for shared vehicle

Abstract

The invention provides a helmet exception handling method and device for a shared vehicle, and relates to the technical field of shared vehicle management, and the method comprises the steps: monitoring helmet exception state information; acquiring a report record of the abnormal state information of the helmet in a preset time period; and if the reported record meets the pre-configured operation and maintenance state, creating operation and maintenance task information, and sending the operation and maintenance task information to an operation and maintenance terminal to notify operation and maintenance personnel to execute the operation and maintenance task. According to the helmet exception handling method and device for the shared vehicle, the helmet exception state information is generated when it is monitored that the helmet currently configured for the shared vehicle is in the exception state, so that operation and maintenance personnel can know the exception of the helmet in time and conduct manual inspection in time, it can be guaranteed that a user normally uses the vehicle, and the user experience is improved. And the situation that the user cannot return the bicycle normally can be avoided to a certain extent, so that the bicycle using experience of the user is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of shared vehicle management, and in particular to a method and device for handling helmet anomalies of a shared vehicle. Background Art

[0002] With the popularization of shared vehicles, such as shared bicycles, shared electric motorcycles, shared cars, etc., more and more users are enjoying convenient travel services.

[0003] Usually, in order to ensure the safety of users, especially those who use shared electric motorcycles and shared bicycles, in order to ensure safe riding, shared bicycles, especially shared electric motorcycles, are usually equipped with helmets. If the helmet fails, the user cannot use the helmet, or cannot return the helmet normally after riding, which will cause problems in returning the vehicle, which not only affects the normal use of other users, but also reduces the user's experience of using the vehicle. Summary of the invention

[0004] In view of this, an object of the present invention is to provide a method and device for handling helmet abnormalities in a shared vehicle to alleviate the above-mentioned technical problems.

[0005] In the first aspect, an embodiment of the present invention provides a method for handling helmet abnormalities of a shared vehicle, the method comprising: monitoring abnormal status information of the helmet; wherein the abnormal status information of the helmet is generated when it is monitored that the helmet currently configured for the shared vehicle is in an abnormal state; obtaining a reporting record of the abnormal status information of the helmet within a preset time period; if the reporting record meets a pre-configured operation and maintenance status, creating operation and maintenance task information, and sending the operation and maintenance task information to an operation and maintenance terminal to notify the operation and maintenance personnel to perform the operation and maintenance task.

[0006] In combination with the first aspect, an embodiment of the present invention provides a first possible implementation method of the first aspect, wherein the above-mentioned step of monitoring the abnormal status information of the helmet includes: monitoring the usage status of the shared vehicle; when the shared vehicle is not in use, receiving the helmet status information reported by the shared vehicle at a preset time interval; if it is monitored that the helmet status information includes the abnormal status information of the helmet, it is determined that the abnormal status information of the helmet of the shared vehicle is received.

[0007] In combination with the first possible implementation of the first aspect, an embodiment of the present invention provides a second possible implementation of the first aspect, wherein the above-mentioned step of monitoring abnormal status information of the helmet also includes: if the shared vehicle is in use, responding to the user's return operation for the shared vehicle; when performing the return operation, receiving abnormal status information of the helmet sent by the shared vehicle and / or the user terminal corresponding to the shared vehicle.

[0008] In combination with the first possible implementation of the first aspect, an embodiment of the present invention provides a third possible implementation of the first aspect, wherein the above method also includes: when the shared vehicle is not in use, if within a preset time period, the number of reports of the abnormal status information of the helmet recorded in the reporting record exceeds a pre-configured number threshold, then it is determined that the reporting record meets the pre-configured operation and maintenance status; or, when the shared vehicle is in use, if the abnormal status information of the helmet is received, then it is determined that the reporting record meets the pre-configured operation and maintenance status.

[0009] In combination with the first aspect, an embodiment of the present invention provides a fourth possible implementation method of the first aspect, wherein the above-mentioned operation and maintenance task information includes at least the following information: the abnormal state information of the helmet, the vehicle identification of the shared vehicle, and the location information of the shared vehicle; the method also includes: responding to the helmet test information sent by the operation and maintenance terminal, the helmet test information carries the vehicle identification of the shared vehicle; based on the vehicle identification, issuing a helmet unlocking instruction to the shared vehicle; if the helmet unlocking information of the shared vehicle is not received, determining that the helmet is abnormal; if the helmet unlocking information of the shared vehicle is received, determining the helmet type, and testing the helmet based on the helmet type; wherein the helmet type includes an induction helmet type and a non-induction helmet type.

[0010] In combination with the fourth possible implementation of the first aspect, an embodiment of the present invention provides a fifth possible implementation of the first aspect, wherein the step of testing the helmet based on the helmet type comprises: if the helmet type is an induction helmet type, wearing the helmet according to preset wearing instructions to perform induction detection on the helmet; if the induction detection passes, monitoring the locking information of the helmet, wherein the locking information is generated when the operation and maintenance personnel performs a locking operation on the helmet after the induction detection passes; if the locking information of the helmet is monitored, determining that the helmet test has passed; or, if the helmet type is a non-induction helmet type, monitoring the locking information of the helmet, wherein the locking information is generated when the operation and maintenance personnel performs a locking operation on the helmet; if the locking information of the helmet is monitored, determining that the helmet test has passed.

[0011] In combination with the fifth possible implementation of the first aspect, an embodiment of the present invention provides a sixth possible implementation of the first aspect, wherein the above method also includes: if the induction detection fails, or the locking information of the helmet is not monitored, determining that the helmet is abnormal.

[0012] In a second aspect, an embodiment of the present invention also provides a method for handling helmet abnormalities in a shared vehicle, the method comprising: responding to a user's return operation to a shared vehicle, determining whether helmet locking status information reported by the shared vehicle is monitored; if not, determining that the helmet status of the shared vehicle is abnormal, and generating helmet abnormal status information.

[0013] In combination with the second aspect, an embodiment of the present invention provides a first possible implementation of the second aspect, wherein the method further includes: sending the abnormal status information of the helmet to a user terminal, displaying the abnormal status information of the helmet and a helmet return control corresponding to the abnormal status information of the helmet through a graphical user interface of the user terminal; in response to a touch operation acting on the helmet return control, displaying an image acquisition port and a standard helmet image example on the graphical user interface; receiving a helmet image acquired by the user terminal through the image acquisition port; determining whether the posture of the helmet in the helmet image matches the standard helmet image example; if so, prompting the user that the vehicle has been returned successfully.

[0014] In the third aspect, an embodiment of the present invention also provides a helmet abnormality processing device for a shared vehicle, the device comprising: a receiving module for receiving helmet abnormal status information; wherein the helmet abnormal status information is generated when the shared vehicle detects that the currently configured helmet is in an abnormal state; an acquisition module for obtaining the reporting record of the helmet abnormal status information within a preset time period; a creation module for creating operation and maintenance task information if the reporting record meets the pre-configured operation and maintenance status, and sending the operation and maintenance task information to the operation and maintenance terminal to notify the operation and maintenance personnel to perform the operation and maintenance task.

[0015] In a fourth aspect, an embodiment of the present invention further provides a helmet abnormality processing device for a shared vehicle, the device comprising: a judgment module, for responding to a user's return operation to a shared vehicle, and determining whether helmet locking status information reported by the shared vehicle is monitored; a processing module, for determining that the helmet status of the shared vehicle is abnormal when the judgment result of the judgment module is no, and generating helmet abnormal status information.

[0016] In a fifth aspect, an embodiment of the present invention further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method described in the first aspect is implemented.

[0017] In a sixth aspect, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method described in the first aspect is implemented.

[0018] The embodiments of the present invention bring the following beneficial effects:

[0019] The helmet abnormality processing method and device for a shared vehicle provided in an embodiment of the present invention can monitor the abnormal status information of the helmet; and obtain the reporting record of the abnormal status information of the helmet within a preset time period; if the reporting record meets the pre-configured operation and maintenance status, then create operation and maintenance task information, and send the operation and maintenance task information to the operation and maintenance terminal to notify the operation and maintenance personnel to perform the operation and maintenance task. In addition, the helmet abnormal status information is generated when it is monitored that the helmet currently configured for the shared vehicle is in an abnormal state. Therefore, the operation and maintenance personnel can be informed of the helmet abnormality in time and conduct manual inspection in time, which can not only ensure the normal use of the user, but also avoid the situation where the user cannot return the vehicle normally to a certain extent, thereby improving the user's car experience.

[0020] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention are realized and obtained by the structures particularly pointed out in the description, claims and drawings.

[0021] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0023] Figure 1 A flowchart of a method for handling helmet anomalies in a shared vehicle provided by an embodiment of the present invention;

[0024] Figure 2 A schematic diagram of an induction detection interface provided by an embodiment of the present invention;

[0025] Figure 3 A flowchart of another method for handling helmet anomalies in a shared vehicle provided by an embodiment of the present invention;

[0026] Figure 4 A schematic diagram of the structure of a helmet abnormality processing device for a shared vehicle provided by an embodiment of the present invention;

[0027] Figure 5 A schematic diagram of the structure of another helmet abnormality processing device for a shared vehicle provided by an embodiment of the present invention;

[0028] Figure 6 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0030] Generally, for shared vehicles equipped with helmets, such as shared electric motorcycles and shared bicycles, when no one is using the shared vehicle, the normal state of the helmet should be: the helmet is inserted into the helmet lock, and the helmet lock is locked. If other states occur, such as (1) there is a problem with the helmet / lock; (2) the helmet is not put away properly due to human reasons; (3) the helmet has intermittent state changes; then helmet abnormal information will be generated and reported to the backend server. At this time, if the user encounters the above problems while using the vehicle, the user will not be able to use the helmet or will not be able to return the helmet normally after using the vehicle, which will cause problems in returning the vehicle, thereby affecting the user's travel.

[0031] Based on this, an embodiment of the present invention provides a method and device for handling helmet anomalies in a shared vehicle, in the hope of timely discovering helmet failures, such as discovering helmet failures before the user uses the vehicle, thereby ensuring the user's normal use of the vehicle.

[0032] To facilitate understanding of this embodiment, a method for handling helmet abnormalities in a shared vehicle disclosed in an embodiment of the present invention is first introduced in detail.

[0033] In a possible implementation, an embodiment of the present invention provides a method for handling helmet exceptions of a shared vehicle, which can be applied to a background server of a shared vehicle, and the background server communicates with the shared vehicle. At the same time, the background server can also communicate with a user terminal and an operation and maintenance terminal, wherein the user terminal refers to a smart terminal used by a user of a shared vehicle, and the operation and maintenance terminal refers to a smart terminal used by operation and maintenance personnel, and the smart terminal can be a smart phone, a tablet computer, a handheld computer, etc., and both the user terminal and the operation and maintenance terminal are usually installed with an application APP that matches the shared vehicle. The user can start the application APP, identify the logo of the shared vehicle through the identification port of the application, and then establish communication with the shared vehicle to use the vehicle, and the operation and maintenance terminal is also installed with an application APP that matches the shared vehicle. When the operation and maintenance terminal identifies the logo of the shared vehicle through the identification port of the application and then establishes communication with the shared vehicle, the shared vehicle can be repaired, tested, etc. in the operation and maintenance mode.

[0034] Furthermore, the shared vehicles in the embodiments of the present invention may be shared bicycles, shared electric cars, shared electric motorcycles, etc., and the embodiments of the present invention are not limited to this.

[0035] For ease of understanding, Figure 1 A flowchart of a method for handling helmet abnormalities in a shared vehicle is shown. Figure 1 As shown, the method comprises the following steps:

[0036] Step S102, monitoring abnormal status information of the helmet;

[0037] The abnormal status information of the helmet is generated when an abnormal status is detected in the helmet currently configured in the shared vehicle;

[0038] Step S104, obtaining a report record of abnormal status information of the helmet within a preset time period;

[0039] Step S106: If the reported record meets the pre-configured operation and maintenance status, operation and maintenance task information is created and sent to the operation and maintenance terminal to notify the operation and maintenance personnel to perform the operation and maintenance task.

[0040] In actual use, the process of monitoring the abnormal status information of the helmet in the above step S102 can be performed when the shared vehicle is returned, or can be performed when the shared vehicle is not in use, that is, the background server can monitor the abnormal status information of the helmet in real time. For example, when the shared vehicle is not in use, only the abnormal status information of the helmet reported by the shared vehicle is accepted. When the shared vehicle is in use, the abnormal status information of the helmet reported by the shared vehicle and the user terminal can be monitored when the shared vehicle is returned, so as to avoid the situation where the user is unable to return the vehicle due to an abnormal helmet. No matter in which use state, as long as the abnormal status information of the helmet is monitored, the helmet abnormality handling method for the shared vehicle provided by the embodiment of the present invention can be executed.

[0041] Therefore, in the above step S102, the process of monitoring the abnormal status information of the helmet specifically includes: monitoring the usage status of the shared vehicle; when the shared vehicle is not in use, receiving the helmet status information reported by the shared vehicle at a preset time interval; if the monitored helmet status information includes the abnormal status information of the helmet, it is determined that the abnormal status information of the helmet of the shared vehicle has been received.

[0042] Furthermore, if the shared vehicle is in use, the device responds to the user's return operation for the shared vehicle; when executing the return operation, the device receives abnormal helmet status information sent by the shared vehicle and / or the user terminal corresponding to the shared vehicle.

[0043] Furthermore, the usage status of the monitored shared vehicle, such as whether the shared vehicle is not in use or the shared vehicle is in use, under different usage statuses, the pre-configured operation and maintenance status that the reporting record satisfies is also different.

[0044] Specifically, when the shared vehicle is not in use, if the number of reports of abnormal status information of the helmet recorded in the reporting record exceeds a pre-configured threshold number within a preset time period, it is determined that the reporting record meets the pre-configured operation and maintenance status; or, when the shared vehicle is in use, if abnormal status information of the helmet is received when performing a return operation, it is determined that the reporting record meets the pre-configured operation and maintenance status.

[0045] That is, for a shared vehicle in use, as long as the abnormal status information of the helmet is received during the return operation, it can be determined that the pre-configured operation and maintenance status is met, that is, it is confirmed that the shared vehicle currently in use needs to be repaired or processed to avoid affecting the user's normal use of the vehicle or normal return of the vehicle. If the shared vehicle is not in use, it is necessary to record the number of reports of the abnormal status information of the helmet. For example, after the background server detects that the abnormal status information of the same helmet is reported X times in a certain period of time, it is considered that the helmet of the shared vehicle is abnormal, and relevant business documents are created, such as the operation and maintenance task information in the embodiment of the present invention, and then the operation and maintenance personnel intervene to handle such shared vehicles with abnormal helmets.

[0046] Furthermore, the operation and maintenance task information in the embodiment of the present invention includes at least the following information: abnormal status information of the helmet, the vehicle identification of the shared vehicle, the location information of the shared vehicle, etc. In this way, after the operation and maintenance personnel receive the operation and maintenance task information through the operation and maintenance terminal, they can find the shared vehicle based on the location information of the shared vehicle and the vehicle identification of the shared vehicle, and carefully check the problems with the helmet of the shared vehicle based on the abnormal status information of the helmet.

[0047] Specifically, for the background server, it can respond to the helmet test information sent by the operation and maintenance terminal, and the helmet test information carries the vehicle identification of the shared vehicle; then based on the vehicle identification, it sends a helmet unlocking instruction to the shared vehicle; if the helmet is normal, the helmet of the shared vehicle is unlocked, and the helmet unlocking information is fed back to the background server. If the helmet unlocking information of the shared vehicle is not received, the helmet is determined to be abnormal.

[0048] Further, if helmet unlocking information of the shared vehicle is received, the type of the helmet is determined to test the helmet based on the helmet type.

[0049] Furthermore, the types of helmets in the embodiments of the present invention include an induction helmet type and a non-induction helmet type.

[0050] As for the induction helmet type helmet, when testing the helmet, you can wear the helmet according to the preset wearing instructions to perform induction detection on the helmet; if the induction detection passes, the locking information of the helmet is monitored, wherein the locking information at this time is generated when the operation and maintenance personnel perform the locking operation on the helmet after the induction detection passes; if the locking information of the helmet is monitored, it is determined that the helmet test has passed.

[0051] Furthermore, if the helmet type is a non-sensing helmet type, the locking information of the helmet is monitored, wherein the locking information at this time is generated when the operation and maintenance personnel perform a locking operation on the helmet; if the locking information of the helmet is monitored, it is determined that the helmet test has passed.

[0052] Furthermore, for the above-mentioned sensing helmet type, if the sensing detection fails, or the locking information of the helmet is not monitored, the helmet is determined to be abnormal, while for the non-sensing helmet type, the helmet is determined to be abnormal only when the locking information of the helmet is not monitored.

[0053] In actual use, in the above step S106, after the operation and maintenance task information is sent to the operation and maintenance terminal, the operation and maintenance terminal can display the operation and maintenance task information, such as displaying the vehicle identification included in the operation and maintenance task information, the location information of the shared vehicle, etc. in the graphical user interface of the operation and maintenance terminal. In addition, the graphical user interface of the operation and maintenance terminal can further display image controls and description controls, etc., which can be used by operation and maintenance personnel to upload real-time on-site images of shared vehicles, as well as to describe and record the actual situation of shared vehicles, etc. The specific settings can be made according to the actual usage situation, and the embodiments of the present invention are not limited to this.

[0054] Furthermore, for ease of understanding, the following describes the operation and maintenance tasks performed by the operation and maintenance personnel, including the following:

[0055] The graphical user interface of the operation and maintenance terminal can also display a helmet test control. For example, when the operation and maintenance personnel arrive at the location of the shared vehicle, they can check the condition of the shared vehicle's helmet and other conditions. When the operation and maintenance personnel clicks the helmet test control, the operation and maintenance terminal sends the helmet test information to the background server. At this time, the background server responds to the helmet test information and then sends a helmet unlock command to the shared vehicle.

[0056] At this time, the graphical user interface of the operation and maintenance terminal can display that the command to open the helmet lock has been issued. If the helmet lock is not opened within the preset time range, the operation and maintenance personnel can try multiple times. If the helmet lock still cannot be opened, it is determined that there is an abnormality in the shared vehicle helmet. At this time, the operation and maintenance personnel can describe this abnormal information in the description control of the graphical user interface of the operation and maintenance terminal for record and subsequent maintenance.

[0057] If the helmet lock is opened normally within a preset time range, the helmet type is further determined, i.e., the above-mentioned helmet type.

[0058] In actual use, for shared vehicles deployed in some areas, the helmets are equipped with induction sensors, that is, the helmets have the function of wearing induction, which can detect whether the user wears the helmet normally. For such shared vehicles, the helmet type is the induction helmet type, otherwise it is the non-induction helmet type. Since the non-induction helmet type cannot perform induction detection, after determining that the helmet lock is not opened within the preset time range, the helmet abnormality can be confirmed. For the induction helmet type helmet, after determining that the helmet lock is opened normally within the preset time range, it will automatically switch to induction detection.

[0059] At this time, the induction detection interface may pop up on the graphical user interface of the operation and maintenance terminal. At the same time, the induction detection interface may display the detection requirements of the induction detection and the corresponding detection controls, etc.

[0060] Specifically, for ease of understanding, Figure 2 A schematic diagram of an induction detection interface is shown, wherein the induction detection may include Figure 2 The detection process on the left side (a) and the detection process on the right side (b) in the figure, that is, the helmet with wearing sensing function needs to be tested whether the wearing function is normal, mainly whether the helmet can normally sense wearing and taking off. If it can, it means that the wearing sensing function of the helmet is normal; otherwise, it is considered that the helmet is faulty and a corresponding maintenance order needs to be created to indicate that the helmet is abnormal for subsequent maintenance processing.

[0061] in, Figure 2 The detection process on the left side (a) represents the helmet wearing detection. At this time, the operation and maintenance personnel can click the detection control in (a), and the operation and maintenance terminal can broadcast the detection requirements to prompt the operation and maintenance personnel to perform the corresponding sensing detection and maintain the preset time, such as "Please put on the helmet and keep it for 5 seconds", etc. When the wearing sensing function of the helmet is normal, the helmet can send a normal sensing signal to the background server. At this time, the background server can send a normal sensing signal to the operation and maintenance terminal, or the shared vehicle directly sends a normal sensing signal to the operation and maintenance terminal to prompt the operation and maintenance personnel that the sensing is normal.

[0062] If the operation and maintenance terminal or the background server does not detect a normal sensing signal within the specified time, it means that the helmet wearing sensing function is abnormal, that is, the helmet is abnormal.

[0063] Further, if Figure 2 If the detection result of the left side (a) is a normal sensing signal, the detection process of the right side (b) is further executed. Specifically, the detection process of (b) represents the helmet removal detection. At this time, the operation and maintenance personnel can click the detection control in (b), and the operation and maintenance terminal can broadcast the detection requirements to prompt the operation and maintenance personnel to perform the corresponding sensing detection and maintain the preset time, such as "Please remove the helmet and keep it for 5 seconds", etc. When the wearing sensing function of the helmet is normal, after the helmet is removed, a signal indicating that the removal sensing is normal can be sent to the background server. At this time, the background server can forward the signal indicating that the removal sensing is normal to the operation and maintenance terminal, or the shared vehicle directly sends a signal indicating that the removal sensing is normal to the operation and maintenance terminal to prompt the operation and maintenance personnel to remove the sensing normally.

[0064] If the operation and maintenance terminal or the backend server does not detect a normal signal of removal sensing within the specified time, it may also indicate that the helmet wearing sensing function is abnormal, that is, the helmet is abnormal.

[0065] Furthermore, for the above Figure 2 After the wearing sensing function shown is normal, you can further detect whether the helmet can be locked normally when it is returned. If it can be locked normally, it means that the helmet function of the shared vehicle is normal and the helmet can continue to be used. At this time, the operation and maintenance personnel can complete the business document for this time, that is, the operation and maintenance task information is completed, and the final result shows that the helmet is normal. If the helmet cannot be locked, it means that the helmet function of the shared vehicle is abnormal, and a maintenance order needs to be created and wait for further maintenance.

[0066] Therefore, in the above process, no matter at which stage, as long as there is an abnormality with the helmet, a repair order needs to be created and wait for further repairs.

[0067] In actual use, considering that shared vehicles are in use, the abnormal status information of the helmet is usually monitored when the vehicle is returned. Therefore, on the operation and maintenance terminal side, the abnormal helmet can be repaired after the user returns the vehicle; on the user side, the helmet locking status information of the shared vehicle can be monitored through the user terminal, so that after the user terminal monitors the helmet locking status information, the user can return the vehicle first, and then the operation and maintenance personnel can perform further maintenance.

[0068] Therefore, based on the above embodiment, the embodiment of the present invention also provides another method for handling helmet abnormalities in a shared vehicle, which is applied to a user terminal. Figure 3 The flowchart of another method for handling helmet abnormalities in a shared vehicle shown includes the following steps:

[0069] Step S302, in response to the user's return operation for the shared vehicle, determining whether the helmet locking status information reported by the shared vehicle is monitored;

[0070] Step S304: if not, determine that the helmet status of the shared vehicle is abnormal, and generate helmet abnormal status information.

[0071] In actual use, since the user terminal has established communication with the shared vehicle, when the user returns the vehicle, if the helmet of the shared vehicle is normal, the user needs to put the helmet in the preset helmet lock position when returning the vehicle. At this time, the sensor of the helmet lock senses that the helmet is placed in the preset helmet lock position, and generates helmet lock status information, and sends it to the controller of the shared vehicle. The controller of the shared vehicle further forwards it to the user terminal and the backend server to determine that the user has returned the vehicle normally, that is, the helmet is locked normally. If the user terminal does not monitor the helmet lock status information reported by the shared vehicle within the preset time range, it can be determined that the helmet status of the shared vehicle is abnormal at this time, and then the helmet abnormal status information is generated. The helmet abnormal status information can be further forwarded to the backend server to execute the above-mentioned embodiments of the present invention. Figure 1The helmet exception handling method for the shared vehicle is shown.

[0072] Furthermore, since the abnormal state information of the helmet generated in the above step S304 in the embodiment of the present invention is generated when the user returns the vehicle, the user at this time will be unable to return the vehicle normally. In order to ensure that the user can return the vehicle normally, in the embodiment of the present invention, after the abnormal state information of the helmet appears, the user can be guided to return the vehicle quickly, specifically, the following process is included:

[0073] (1) The shared vehicle further sends the abnormal state information of the helmet to the user terminal, and displays the abnormal state information of the helmet and a helmet return control corresponding to the abnormal state information of the helmet through a graphical user interface of the user terminal;

[0074] (2) in response to a touch operation on a helmet return control, displaying an image acquisition port and a standard helmet image example on a graphical user interface;

[0075] (3) receiving the helmet image collected by the user terminal through the image acquisition port;

[0076] (4) Determine whether the posture of the helmet in the helmet image matches the standard helmet image example;

[0077] (5) If yes, the user is prompted that the vehicle has been returned successfully.

[0078] In actual use, the graphical user interface of the user terminal can be displayed in the form of a pop-up window, and the user can be guided to perform normal operations to return the helmet first, such as displaying the helmet lock position and prompting the user to place the helmet in the helmet lock position. If the helmet locking status information is still not detected, the user can click the helmet return control to continue returning the vehicle.

[0079] Furthermore, the above-mentioned standard helmet image refers to a reference image when the user performs a car return operation in the current car return environment. Therefore, the standard helmet image usually shows the placement position of the helmet and the placement posture of the helmet, for example, an image of a helmet placed in a car frame, etc. When the user operates the user terminal to call the graphics acquisition module through the image acquisition port, the above-mentioned standard helmet image and the corresponding image acquisition standard can be displayed, for example, placing the helmet in the car frame and shooting from top to bottom at the front of the car, etc., to prompt the user and obtain the matching helmet posture.

[0080] When the user image is collected and submitted for upload, the user terminal or the background server can call a pre-configured detection algorithm to detect whether the posture of the helmet in the helmet image matches the standard helmet image example. For example, a graphic similarity detection algorithm is used. After detecting that the helmet image uploaded by the user is consistent with the standard helmet image example, it can be confirmed that the user has returned the helmet normally, and then the return process can be continued to lock the car, and the user is prompted that the car has been returned successfully.

[0081] At this time, the generated abnormal status information of the helmet can be further processed in the background server, such as executing the above Figure 1 The corresponding helmet exception handling process, etc., finally creates the operation and maintenance task information and sends it to the operation and maintenance terminal to notify the operation and maintenance personnel to perform the operation and maintenance tasks.

[0082] In summary, the method for handling helmet abnormalities in shared vehicles provided in the embodiments of the present invention can, when the shared vehicle is not in use, detect helmet abnormalities in advance and confirm them through manual inspection by monitoring the abnormal status information of the helmet, thereby avoiding helmet problems encountered by users during use of the vehicle and improving user experience. At the same time, for users riding shared vehicles with abnormal helmets, photos can be used to confirm that the helmets have been returned, thereby avoiding the problem of having to pay helmet fees to return the vehicle or long-term attempts to return the vehicle, which may lead to poor user experience.

[0083] Further, corresponding to the above Figure 1 The embodiment of the present invention also provides a method for handling helmet anomalies in a shared vehicle, such as Figure 4 The schematic diagram of the structure of a helmet abnormality processing device for a shared vehicle shown in the figure includes:

[0084] The receiving module 40 is used to receive the abnormal state information of the helmet; wherein the abnormal state information of the helmet is generated when the shared vehicle detects that the currently configured helmet is in an abnormal state;

[0085] An acquisition module 42 is used to acquire the reporting record of the abnormal status information of the helmet within a preset time period;

[0086] The creation module 44 is used to create operation and maintenance task information if the reporting record meets the pre-configured operation and maintenance status, and send the operation and maintenance task information to the operation and maintenance terminal to notify the operation and maintenance personnel to perform the operation and maintenance task.

[0087] Further, corresponding to the above Figure 3 The embodiment of the present invention also provides another method for handling helmet anomalies in a shared vehicle, such as Figure 5 The structural schematic diagram of another helmet abnormality processing device for a shared vehicle shown includes:

[0088] A determination module 50 is used to respond to a user's return operation to a shared vehicle and determine whether helmet locking status information reported by the shared vehicle is monitored;

[0089] The processing module 52 is used to determine that the helmet state of the shared vehicle is abnormal and generate helmet abnormal state information when the judgment result of the judgment module is no.

[0090] The helmet abnormality handling device for a shared vehicle provided in an embodiment of the present invention has the same technical features as the helmet abnormality handling method for a shared vehicle provided in the above embodiment, so it can also solve the same technical problems and achieve the same technical effects.

[0091] Furthermore, an embodiment of the present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0092] An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above method are executed.

[0093] Furthermore, an embodiment of the present invention also provides a structural diagram of an electronic device, such as Figure 6 As shown, it is a schematic diagram of the structure of the electronic device, wherein the electronic device includes a processor 61 and a memory 60, the memory 60 stores computer executable instructions that can be executed by the processor 61, and the processor 61 executes the computer executable instructions to implement the above method.

[0094] exist Figure 6 In the illustrated embodiment, the electronic device further includes a bus 62 and a communication interface 63 , wherein the processor 61 , the communication interface 63 and the memory 60 are connected via the bus 62 .

[0095] Among them, the memory 60 may include a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. The communication connection between the system network element and at least one other network element is realized through at least one communication interface 63 (which can be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. can be used. The bus 62 can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 62 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0096] The processor 61 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 61 or the instructions in the form of software. The above processor 61 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiment of the present invention can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor 61 reads the information in the memory and completes the above method in combination with its hardware.

[0097] The computer program product of the helmet exception handling method and device for a shared vehicle provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the method described in the previous method embodiments. The specific implementation can be found in the method embodiments, which will not be repeated here.

[0098] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0099] In addition, in the description of the embodiments of the present invention, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, and it can be the internal communication of two components. For those skilled in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0100] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.

[0101] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.

[0102] Finally, it should be noted that the above embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above embodiments, those skilled in the art should understand that any person skilled in the art can still modify the technical solutions recorded in the above embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A method for handling abnormalities of helmets in shared vehicles, characterized in that: The method comprises: Monitoring abnormal status information of the helmet; wherein the abnormal status information of the helmet is generated when an abnormal status is detected in the helmet currently configured for the shared vehicle; Obtaining a report record of abnormal status information of the helmet within a preset time period; If the reported record meets the pre-configured operation and maintenance status, operation and maintenance task information is created and sent to the operation and maintenance terminal to notify the operation and maintenance personnel to perform the operation and maintenance task.

2. The method according to claim 1, characterized in that The steps of monitoring abnormal status information of the helmet include: Monitoring the usage status of the shared vehicle; When the shared vehicle is not in use, receiving helmet status information reported by the shared vehicle at preset time intervals; If it is monitored that the helmet status information includes helmet abnormal status information, it is determined that the helmet abnormal status information of the shared vehicle is received.

3. The method according to claim 2, characterized in that The step of monitoring abnormal status information of the helmet also includes: If the shared vehicle is in use, responding to a user's return operation on the shared vehicle; When performing the vehicle return operation, receiving abnormal status information of the helmet sent by the shared vehicle and / or the user terminal corresponding to the shared vehicle.

4. The method according to claim 2, characterized in that: The method further comprises: When the shared vehicle is not in use, if within a preset time period, the number of reports of the abnormal status information of the helmet recorded in the reporting record exceeds a pre-configured number threshold, it is determined that the reporting record meets the pre-configured operation and maintenance status; or, When the shared vehicle is in use, if the abnormal status information of the helmet is received, it is determined that the reporting record meets the pre-configured operation and maintenance status.

5. The method according to claim 1, characterized in that The operation and maintenance task information includes at least the following information: abnormal status information of the helmet, vehicle identification of the shared vehicle, and location information of the shared vehicle; The method further comprises: Responding to the helmet test information sent by the operation and maintenance terminal, the helmet test information carries the vehicle identification of the shared vehicle; Sending a helmet unlocking instruction to the shared vehicle based on the vehicle identification; If the helmet unlocking information of the shared vehicle is not received, determining that the helmet is abnormal; If the helmet unlocking information of the shared vehicle is received, the helmet type is determined to test the helmet based on the helmet type; wherein the helmet type includes an induction helmet type and a non-induction helmet type.

6. The method according to claim 5, characterized in that The step of testing the helmet based on the helmet type comprises: If the helmet type is an induction helmet type, wearing the helmet according to a preset wearing instruction to perform an induction detection on the helmet; If the induction detection passes, monitoring the locking information of the helmet, wherein the locking information is generated when the operation and maintenance personnel performs a locking operation on the helmet after the induction detection passes; If the locking information of the helmet is monitored, it is determined that the helmet test has passed; or, If the helmet type is a non-sensing helmet type, monitoring the locking information of the helmet, wherein the locking information is generated when the operation and maintenance personnel performs a locking operation on the helmet; If the locking information of the helmet is monitored, it is determined that the helmet test has passed.

7. A method for handling abnormalities of helmets in shared vehicles, characterized in that: The method comprises: In response to a user's return operation for a shared vehicle, determining whether helmet locking status information reported by the shared vehicle is monitored; If not, it is determined that the helmet status of the shared vehicle is abnormal, and helmet abnormal status information is generated.

8. The method according to claim 7, characterized in that The method further comprises: Sending the abnormal state information of the helmet to a user terminal, and displaying the abnormal state information of the helmet and a helmet return control corresponding to the abnormal state information of the helmet through a graphical user interface of the user terminal; In response to a touch operation on the helmet return control, displaying an image acquisition port and a standard helmet image example on the graphical user interface; Receiving the helmet image acquired by the user terminal through the image acquisition port; Determining whether the posture of the helmet in the helmet image matches the standard helmet image example; If yes, the user is prompted that the vehicle has been returned successfully.

9. A helmet abnormality handling device for a shared vehicle, characterized in that: The device comprises: A receiving module, used to receive abnormal state information of the helmet; wherein the abnormal state information of the helmet is generated when the shared vehicle detects that the currently configured helmet is in an abnormal state; An acquisition module, used to acquire the reporting record of abnormal status information of the helmet within a preset time period; The creation module is used to create operation and maintenance task information if the reporting record meets the pre-configured operation and maintenance status, and send the operation and maintenance task information to the operation and maintenance terminal to notify the operation and maintenance personnel to perform the operation and maintenance task.

10. A helmet abnormality handling device for a shared vehicle, characterized in that: The device comprises: A judgment module, used to respond to a user's return operation for a shared vehicle and judge whether the helmet locking status information reported by the shared vehicle is monitored; The processing module is used to determine that the helmet state of the shared vehicle is abnormal and generate helmet abnormal state information when the judgment result of the judgment module is no.

Images