Method and system for judging whether helmet of shared vehicle is in place

Abstract

The embodiment of the invention provides a method for judging whether a helmet of a shared vehicle is in place or not, and the method comprises the steps: obtaining verification data of the helmet of the shared vehicle from a server, the verification data comprising verification code information and position verification information; acquiring a vehicle image including a helmet code and a basket code of the shared vehicle; obtaining actual helmet data based on the vehicle image, wherein the actual helmet data comprises helmet code actual information and helmet position actual information; judging whether the helmet of the shared vehicle is in place or not based on the actual helmet data and the verification data; and in response to the helmet of the shared vehicle being in place, allowing vehicle returning.

Description

Technical Field

[0001] This specification relates to the field of shared transportation, and particularly to a method and system for determining whether a helmet of a shared vehicle is in place. Background Art

[0002] Based on the safety requirements of users, currently, the use of some shared vehicles (such as shared electric vehicles) requires the equipped with helmets. Helmets, like shared vehicles, are also products shared by users. However, during the use process, there may be behaviors such as users not returning helmets in a timely manner or cheating in the return, which affect the normal use of the helmets of shared vehicles.

[0003] Therefore, this specification provides a method for determining whether a helmet of a shared vehicle is in place, which can accurately determine whether the helmet is in place, and the judgment process has a low cost, meeting the requirements of wide application. Summary of the Invention

[0004] One embodiment of this specification provides a method for determining whether a helmet of a shared vehicle is in place. The method includes: obtaining verification data of the helmet in place of the shared vehicle from a server, where the verification data includes verification code information and position verification information; obtaining a vehicle image including the helmet code and the basket code of the shared vehicle; obtaining actual helmet data based on the vehicle image, where the actual helmet data includes actual helmet code information and actual helmet position information; determining whether the helmet of the shared vehicle is in place based on the actual helmet data and the verification data; and allowing vehicle return in response to the helmet of the shared vehicle being in place.

[0005] In some embodiments, determining whether the helmet of the shared vehicle is in place based on the actual helmet data and the verification data includes: obtaining actual basket data based on the vehicle image, where the actual basket data includes actual basket code information and actual basket position information; determining whether the actual helmet code information and the actual basket code information meet a first preset condition; determining whether the actual helmet position information and the actual basket position information meet a second preset condition; and determining that the helmet of the shared vehicle is in place in response to both the first preset condition and the second preset condition being met.

[0006] In some embodiments, the helmet code and the basket code are at least one of a two-dimensional code and a bar code.

[0007] In some embodiments, in response to one of the first preset condition and the second preset condition not being met, the method further includes: performing image analysis on the vehicle image based on an image analysis model to obtain an image analysis result; and determining whether the helmet of the shared vehicle is in place based on the image analysis result.

[0008] In some embodiments, based on the image analysis result, one of the following operations is performed: generating a prompt to adjust the position of the helmet; or generating a prompt to replace the helmet.

[0009] In some embodiments, the helmet is provided with a first metal contact, and the basket is provided with a second metal contact. When the actual information of the helmet code and the actual information of the basket code meet the first preset condition, the method further includes: determining whether the first metal contact and the second metal contact are aligned; in response to the first metal contact and the second metal contact being aligned, determining that the helmet of the shared vehicle is in place.

[0010] In some embodiments, the helmet or the basket is provided with at least two triggers. When the actual information of the helmet code and the actual information of the basket code meet the first preset condition, the method further includes: determining the triggering states of the at least two triggers; in response to all of the at least two triggers being triggered, determining that the helmet of the shared vehicle is in place.

[0011] In some embodiments, the method further includes: when the helmet is replaced, updating the binding data between the helmet code and the basket code in the server.

[0012] One embodiment of this specification provides a system for determining whether the helmet of a shared vehicle is in place. The system includes: a first acquisition module for acquiring verification data on the helmet in place of the shared vehicle from a server, where the verification data includes verification code information and position verification information; a second acquisition module for acquiring a vehicle image including the helmet code and the basket code of the shared vehicle; an image analysis module for obtaining actual helmet data based on the vehicle image, where the actual helmet data includes actual helmet code information and actual helmet position information; a judgment module for judging whether the helmet of the shared vehicle is in place based on the actual helmet data and the verification data; and a return vehicle module for allowing the vehicle to be returned in response to the helmet of the shared vehicle being in place.

[0013] One embodiment of this specification provides a device for determining whether the helmet of a shared vehicle is in place. The device includes: at least one storage medium storing computer instructions; and at least one processor executing the computer instructions to implement a method for determining whether the helmet of a shared vehicle is in place. Description of the Drawings

[0014] This specification will be further described by way of exemplary embodiments, which will be described in detail through the drawings. These embodiments are not restrictive. In these embodiments, the same numbers represent the same structures, where:

[0015] Figure 1It is a schematic diagram of the application scenario of the system for determining whether the helmet of a shared vehicle is in place according to some embodiments of this specification;

[0016] Figure 2 It is an exemplary structural diagram of the system for determining whether the helmet of a shared vehicle is in place according to some embodiments of this specification;

[0017] Figure 3 It is an exemplary flowchart of the method for determining whether the helmet of a shared vehicle is in place according to some embodiments of this specification;

[0018] Figure 4 It is an exemplary flowchart of the method for determining whether the helmet of a shared vehicle is in place according to some embodiments of this specification;

[0019] Figure 5 It is another exemplary flowchart of the method for determining whether the helmet of a shared vehicle is in place according to some embodiments of this specification;

[0020] Figure 6 It is another exemplary flowchart of the method for determining whether the helmet of a shared vehicle is in place according to some embodiments of this specification;

[0021] Figure 7 It is a schematic diagram of a shared vehicle according to some embodiments of this specification;

[0022] Figure 8 It is an exemplary flowchart of the process of a user returning the helmet according to some embodiments of this specification. Detailed implementation manners

[0023] To more clearly illustrate the technical solutions of the embodiments of this specification, the accompanying drawings required for the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some examples or embodiments of this specification. For those of ordinary skill in the art, without creative efforts, this specification can also be applied to other similar scenarios based on these drawings. Unless obvious from the language context or otherwise stated, the same reference numerals in the figures represent the same structure or operation.

[0024] It should be understood that the "system", "device", "unit" and / or "module" used herein is a way to distinguish different components, elements, parts, portions or assemblies at different levels. However, if other words can achieve the same purpose, the said words can be replaced by other expressions.

[0025] As shown in this specification and the claims, unless the context clearly indicates otherwise, words such as "a", "an", "one", and / or "the" are not specifically singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of the steps and elements that have been clearly identified, and these steps and elements do not constitute an exclusive list. The method or device may also include other steps or elements.

[0026] Flowcharts are used in this specification to illustrate the operations performed by the system according to the embodiments of this specification. It should be understood that the previous or subsequent operations do not necessarily need to be executed precisely in sequence. On the contrary, the steps can be processed in reverse order or simultaneously. At the same time, other operations can also be added to these processes, or one or more steps can be removed from these processes.

[0027] Figure 1 It is a schematic diagram of the application scenario of a system for determining whether the helmet of a shared vehicle is in place as shown in some embodiments of this specification.

[0028] The systems and methods in this application can be applied to scenarios for determining whether the helmet of a shared vehicle is in place, such as the scenario of returning a shared vehicle after use, the scenario of order settlement for a shared vehicle, the scenario of helmet return, etc.

[0029] In some embodiments, as Figure 1 shown, the system 100 for determining whether the helmet of a shared vehicle is in place may include a processing device 110, a shared vehicle 120, a user terminal 130, a storage device 140, a network 150, and a helmet 160.

[0030] The processing device 110 can be used to process data and / or information from at least one component of the system 100 for determining whether a helmet of a shared vehicle is in place or an external data source (e.g., a cloud data center). For example, the processing device 110 can obtain verification data indicating that the helmet of the shared vehicle is in place from a server, where the verification data includes verification code information and location verification information; obtain a vehicle image including the helmet code and basket code of the shared vehicle; obtain actual helmet data based on the vehicle image, where the actual helmet data includes actual helmet code information and actual helmet location information; determine whether the helmet of the shared vehicle is in place based on the actual helmet data and the verification data; and allow the return of the vehicle in response to the helmet of the shared vehicle being in place. In some embodiments, the processing device 110 can include a central processing unit (CPU), a digital signal processor (DSP), a system on a chip (SoC), a microcontroller unit (MCU), a computer, a user console, etc., or any combination thereof. In some embodiments, the processing device 110 can include a single server or a server group. The server group can be centralized or distributed. In some embodiments, the processing device 110 can be local or remote. In some embodiments, the processing device 110 can be implemented on a cloud platform. By way of example only, the cloud platform can include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an internal cloud, a multi-layer cloud, etc., or any combination thereof. In some embodiments, the processing device 110 can be integrated or included in one or more other components (e.g., the shared vehicle 120, the user terminal 130) of the system 100 for determining whether a helmet of a shared vehicle is in place.

[0031] The shared vehicle 120 is a vehicle that can be used through rental or other means. It can include shared bicycles, shared motorcycles, etc. In some embodiments, the shared vehicle 120 can include sensors, such as positioning components (e.g., GPS modules), pressure sensors, communication components (e.g., GPS communication modules, short-range wireless communication modules, etc.). In some embodiments, the shared vehicle 120 can communicate with at least one component of the system 100 for determining whether a helmet of a shared vehicle is in place through the network 150. For example, the shared vehicle 120 can send the current location information of the vehicle to the processing device 110 and / or the user terminal 130 through the network 150.

[0032] The client 130 can implement the interaction between the user and the system 100 for determining whether the helmet of the shared vehicle is in place. The client 130 can be the terminal device used by the user when using the vehicle service. In some embodiments, the client 130 can generate a prompt for the user to adjust the position of the helmet; or generate a prompt to replace the helmet. In some embodiments, the client 130 can include a mobile device, a tablet computer, a laptop computer, other devices with input and / or output functions, etc. or any combination thereof. In some embodiments, the client 130 can also be represented as an application program (such as an APP, etc.) installed in the above devices. When the user needs to return the shared vehicle and the helmet, the interaction with the system can be carried out through the client 130. For example, obtaining a vehicle image through the client 130 and uploading it to the processing device 110 through the network 150, etc.

[0033] The storage device 140 can be used to store data, instructions, and / or any other information. For example, the storage device can store the obtained verification data, vehicle images, etc. In some embodiments, the storage device can include a random access memory (RAM), a read-only memory (ROM), a mass storage device, a removable storage device, a volatile read-write memory, etc. or any combination thereof. In some embodiments, the storage device can be integrated or included in one or more other components of the system 100 for determining whether the helmet of the shared vehicle is in place (such as the processing device 110, the shared vehicle 120, the client 130).

[0034] The network 150 can facilitate the exchange of information and / or data. In some embodiments, one or more components of the system 100 for determining whether the helmet of the shared vehicle is in place (such as the processing device 110, the shared vehicle 120, the client 130, the storage device 140) can send information and / or data to other components of the system 100 for determining whether the helmet of the shared vehicle is in place through the network 150. In some embodiments, the network 150 can include any one or more of a wired network or a wireless network. In some embodiments, the network 150 can include a cable network, an optical fiber network, a telecommunications network, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public switched telephone network (PSTN), a Bluetooth network, a ZigBee network, near field communication (NFC), an in-device bus, an in-device line, a cable connection, etc. or any combination thereof. In some embodiments, the network connection between the components of the system 100 for determining whether the helmet of the shared vehicle is in place can adopt one of the above methods or multiple methods. In some embodiments, the network can be various topological structures such as point-to-point, shared, centralized, etc. or a combination of multiple topological structures.

[0035] The helmet 160 can correspond one-to-one with the shared vehicle. For example, the helmet 160 can be bound to the shared vehicle 120. In some embodiments, the helmet 160 can include sensors. For example, a positioning sensor, a pressure sensor, etc.

[0036] It should be noted that the system 100 for determining whether the helmet of the shared vehicle is in place is provided for illustrative purposes only and is not intended to limit the scope of this specification. Those of ordinary skill in the art can make various changes and modifications according to the description of this specification. However, these changes and modifications will not deviate from the scope of this specification.

[0037] Figure 2 It is an exemplary structural diagram of the system for determining whether the helmet of the shared vehicle is in place shown in some embodiments of this specification. The system 200 for determining whether the helmet of the shared vehicle is in place can be implemented by the processing device 110.

[0038] In some embodiments, the system 200 for determining whether the helmet of the shared vehicle is in place can include a first acquisition module 210, a second acquisition module 220, an image analysis module 230, a judgment module 240, and a return vehicle module 250.

[0039] The first acquisition module 210 can be used to obtain the verification data of the helmet in place of the shared vehicle from the server, and the verification data includes verification code information and position verification information;

[0040] The second acquisition module 220 can be used to obtain a vehicle image including the helmet code and the basket code of the shared vehicle;

[0041] The image analysis module 230 can be used to obtain actual helmet data based on the vehicle image, and the actual helmet data includes actual helmet code information and actual helmet position information;

[0042] The judgment module 240 can judge whether the helmet of the shared vehicle is in place based on the actual helmet data and the verification data;

[0043] The return vehicle module 250 can be used to allow the return of the vehicle in response to the helmet of the shared vehicle being in place.

[0044] It should be noted that the above description of the system for determining whether the helmet of the shared vehicle is in place and its modules is only for convenience of description and does not limit this specification to the scope of the embodiments given. It can be understood that for those skilled in the art, after understanding the principle of the system, they may, without departing from this principle, make any combination of the various modules, or form a subsystem and connect it with other modules.

[0045] Figure 3is an exemplary flowchart of a method for determining whether a helmet of a shared vehicle is in place as shown in some embodiments of this specification. As Figure 3 shown, process 300 includes the following steps. In some embodiments, process 300 may be executed by a processing device (such as processing device 110) and its components.

[0046] Step 310, obtain verification data on the helmet in place of the shared vehicle from the server. In some embodiments, step 310 may be executed by the first acquisition module 210.

[0047] The verification data is the verification information required for data matching verification. The verification data can reflect the data when the shared vehicle and the corresponding helmet are properly matched (i.e., the helmet is in place). By comparing the verification data with the actual data, it can be known whether the actual data meets the proper matching. In some embodiments, the verification data may be pre-stored in the server, and the verification data may be preset data. In some embodiments, the verification data includes verification code information and position verification information.

[0048] The verification code information is the identification code information when the shared vehicle and the corresponding helmet are matched. By way of example only, the verification code may be a two-dimensional code or a bar code. The verification code information includes basket code verification information and helmet code verification information. The verification codes are respectively located at a certain position on the helmet and the basket of the shared vehicle. The content of the verification code information may include information such as the pattern of the verification code and the size of the verification code.

[0049] The position verification information is the position placement information of the shared vehicle and the helmet when they are matched. In some embodiments, the position placement of the shared vehicle and the helmet can be reflected by the positions of their verification codes. For example, the geometric center coordinates of the basket of the shared vehicle, the geometric center coordinates of the helmet, or the geometric center coordinates of the basket code, the geometric center coordinates of the helmet code, etc. can represent the position placement of the shared vehicle and the helmet.

[0050] Step 320, obtain a vehicle image including the helmet code and basket code of the shared vehicle. In some embodiments, step 320 may be executed by the second acquisition module 220.

[0051] The vehicle image is an image reflecting the real-time situation of the helmet and the basket. The vehicle image includes the helmet code and basket code of the shared vehicle. Among them, the helmet code may be located at the top of the helmet, and the basket code may be located at a certain position on the bottom surface of the basket. An exemplary vehicle image is as Figure 7As shown. In some embodiments, the vehicle image can be an image taken by the user through the user terminal 130. When the user needs to return the vehicle, the user can take and upload the vehicle image through the user terminal 130 (or the application included therein) and send it to the processing device 110 through the network 150. When the vehicle image taken by the user does not completely include the helmet code and the basket code, the processing device 110 can remind the user to take a new photo through the user terminal 130.

[0052] The helmet code can be used as the unique identifier of a certain helmet. That is, one helmet corresponds to a unique helmet code. After knowing the helmet code, the helmet (or its number) corresponding to the helmet code can be further known. The basket code can be used as the unique identifier of a certain shared vehicle. That is, one shared vehicle corresponds to a unique basket code. Similar to the helmet code, after knowing the basket code, the shared vehicle (or its number) corresponding to the basket code can be further known. In some embodiments, the helmet code and the basket code also have a uniquely corresponding binding relationship. For example, a helmet code and a basket code can be bound to each other through a preset mapping relationship, that is, shared vehicle A corresponds to helmet a, shared vehicle B corresponds to helmet b... In some embodiments, the helmet code and the basket code can be the same code or different codes. In some embodiments, the helmet code and the basket code are at least one of a two-dimensional code and a bar code. Only as an example, the helmet code and the basket code can be drawn or adhered to the helmet / basket. Through the helmet code and the basket code, batch management of shared vehicles and helmets can be realized.

[0053] Step 330, obtaining actual helmet data based on the vehicle image. In some embodiments, step 330 can be executed by the image analysis module 230.

[0054] The actual helmet data is the real-time information related to the helmet in the vehicle image. The actual helmet data reflects the placement of the helmet in the basket. Such as the placement position, whether it is the helmet bound to the shared vehicle, etc. In some embodiments, the actual helmet data includes the actual information of the helmet code and the actual information of the helmet position.

[0055] The actual information of the helmet code can include information such as the actual pattern of the helmet code and the size of the helmet code. The actual pattern of the helmet code can reflect the unique identification of the helmet code, while the size of the helmet code can reflect the distance between the camera of the user terminal and the helmet code when the user takes the photo. The size of the helmet code can be expressed in terms of the number of pixel points (unit: piece), actual length (unit: millimeter), etc.

[0056] The actual information of the helmet position may include the coordinates of the geometric center of the helmet or the geometric center of the helmet code. By way of example only, the processing device 110 may use the helmet code, the basket code, or any other arbitrary point as the origin of the coordinate system to determine the coordinates of the geometric centers of the helmet code and the basket code. In some embodiments, the processing device 110 may obtain actual helmet data through image recognition technology. For example, through image recognition, first identify the helmet and the basket in the vehicle image; then identify the two-dimensional code of the helmet as the helmet code and the two-dimensional code of the basket as the basket code; identify the two-dimensional code pattern of the helmet code and determine the coordinates of the geometric center of the helmet code.

[0057] Step 340, based on the actual helmet data and the verification data, determine whether the helmet of the shared vehicle is in place. In some embodiments, step 340 may be executed by the determination module 240.

[0058] The helmet of the shared vehicle being in place means that the helmet of the shared vehicle is the pre-bound helmet and the helmet is placed in the correct position in the basket. The above-mentioned being in place can be reflected by the basket code and the helmet code, that is, the actual helmet code must be the identification code pre-bound by the basket code, and the distance between the basket code and the helmet code meets the preset conditions. In some embodiments, the processing device 110 may compare the patterns of the actual helmet code and the verification code to determine whether the helmet is the pre-bound helmet of the vehicle. In some embodiments, the processing device 110 may compare the positional relationship between the actual helmet code and the actual basket code to determine whether the helmet is placed in the correct position in the basket. For the description of determining whether the helmet of the shared vehicle is in place, see Figure 4 And its related description. The helmet of the shared vehicle not being in place can be understood as the helmet of the shared vehicle not being the pre-bound helmet, or the helmet being placed in the wrong position in the basket.

[0059] Step 350, in response to the helmet of the shared vehicle being in place, allow the return of the vehicle. In some embodiments, step 350 may be executed by the vehicle return module 250.

[0060] When the helmet of the shared vehicle is in place, the processing device 110 may send an indication to the user through the user terminal 130 to allow the return of the vehicle, and complete the order in response to the user's vehicle return operation.

[0061] In response to the helmet of the shared vehicle not being in place, the processing device 110 may send an indication to the user through the user terminal 130 that the vehicle cannot be returned. Further, the reason why the vehicle cannot be returned may be informed to the user. Such as the actual helmet not being the pre-bound helmet, the helmet not being placed in the correct position, etc.

[0062] The method for determining whether a helmet of a shared vehicle is in place according to some embodiments of this specification realizes helmet detection through a helmet code and a basket code, and can be achieved through image recognition. Moreover, the unique identification of the helmet code can prevent the helmet from being replaced; by determining the positions of the helmet code and the basket code, fraud in return can be avoided.

[0063] Figure 4 is an exemplary flowchart for determining whether a helmet of a shared vehicle is in place according to some embodiments shown in this specification. As Figure 4 shown, process 400 includes the following steps. In some embodiments, process 400 can be executed by a processing device (such as processing device 110) or its components.

[0064] Step 410, obtaining actual basket data based on a vehicle image.

[0065] The actual basket data is real-time information related to the basket in the vehicle image. The actual basket data reflects the situation of the basket. Such as the specific shared vehicle corresponding to the basket, the position of the basket, etc. In some embodiments, the actual basket data includes actual basket code information and actual basket position information.

[0066] The actual basket code information can include information such as the actual pattern of the basket code and the size of the basket code. The actual pattern of the basket code can reflect the unique identification of the basket code, while the size of the basket code can reflect the distance between the camera of the user terminal and the basket code when the user takes a photo. The size of the basket code can be expressed in terms of the number of pixels (unit: piece), actual length (unit: millimeter), etc.

[0067] The actual basket position information can include the coordinates of the geometric center of the basket or the geometric center of the basket code. Only as an example, processing device 110 can use the helmet code, basket code, or any other point as the origin of the coordinate system to determine the coordinates of the geometric centers of the helmet code and the basket code. In some embodiments, processing device 110 can obtain the actual basket data through image recognition technology.

[0068] Step 420, determining whether the actual helmet code information and the actual basket code information meet a first preset condition.

[0069] The first preset condition is that the basket code, the actual helmet code information, and the verification data are the same. That is, when the actual basket code is the same as the verification code of the basket, the actual helmet code is the same as the verification code of the helmet, and the size of the actual basket code and the size of the actual helmet code meet a preset size ratio, it is determined that the first preset condition is met. Among them, the preset size ratio can be 1, 0.5, 2, etc. The satisfaction of the first preset condition means that both the basket code and the helmet code can meet the preset shared vehicle-helmet binding relationship, and the fact that the sizes of the basket code and the helmet code meet the preset size ratio means that the helmet is in the state of helmet return.

[0070] Step 430: Determine whether the actual information of the helmet position and the actual information of the basket position meet the second preset condition.

[0071] The second preset condition is that the actual information of the basket code position, the actual information of the helmet code position, and the verification data are the same. That is, when the actual position of the basket code is at the preset basket verification code position and the actual position of the helmet code is at the preset helmet verification code position, it is determined that the second preset condition is met. The satisfaction of the second preset condition means that the helmet is placed at the preset return position in the basket.

[0072] In some embodiments, it is also possible to determine whether the helmet code and the basket code meet the third preset condition. The third preset condition is a preset perspective angle. Due to the perspective principle, when the shooting angle is different, the helmet code and the basket code are not rectangles but different quadrilaterals. The perspective angles of the helmet code and the basket code can reflect their relative positional relationship. The preset perspective angle can be used to perform perspective correction on the helmet code and the basket code.

[0073] It should be noted that according to different models of shared vehicles and helmets, the above first preset condition, second preset condition, and third preset condition can be adaptively changed, and this specification does not limit this.

[0074] Step 440: In response to both the first preset condition and the second preset condition being met, determine that the helmet of the shared vehicle is in place.

[0075] In some embodiments, in response to one of the first preset condition and the second preset condition not being met, it further includes: performing image analysis on the vehicle image based on an image analysis model to obtain an image analysis result; based on the image analysis result, determining whether the helmet of the shared vehicle is in place.

[0076] The image analysis model can be a machine learning model. For example, models such as convolutional neural network, U-Net, YOLO, etc. The input of the image analysis model can include the vehicle image, and the output can include the image analysis result. The image analysis result is whether the helmet code and the basket code are the same as the verification data; and whether the positions of the helmet code and the basket code are the same as the verification data. In some embodiments, the image analysis model can directly output the result of whether the helmet is in place or not.

[0077] In some embodiments, the image analysis model can be trained using multiple labeled training samples. For example, multiple labeled training samples can be input into the initial image analysis model, and a loss function can be constructed using the labels and the results of the initial image analysis model. The parameters of the initial image analysis model can be iteratively updated based on the loss function using gradient descent or other methods. When the preset conditions are met, the model training is completed, and a trained image analysis model is obtained. The preset conditions may include convergence of the loss function, the number of iterations reaching a threshold, etc. The training samples include multiple vehicle images containing helmets and baskets, and the labels may be "helmet in place" or "helmet not in place."

[0078] In some embodiments, the processing device 110 can perform one of the following operations based on the image analysis results: generate a prompt to adjust the helmet position; or generate a prompt to replace the helmet. If the image analysis result indicates that either the helmet code or the basket code is inconsistent with the verification data, a prompt to replace the helmet can be generated; if the position of either the helmet code or the basket code is inconsistent with the verification data, a prompt to adjust the helmet position can be generated. These generated prompts can be displayed to the user via the user terminal 130. Prompts include, but are not limited to, text prompts, voice prompts, and other forms.

[0079] In some embodiments, when a helmet is replaced, the processing device 110 may update the binding data between the helmet code and the basket code in the server. For example, when a helmet is damaged and needs to be replaced with a new one, the processing device 110 may first unbind the binding relationship between the helmet code of the old helmet and the basket code, and then bind the helmet code of the new helmet to the basket code, thereby updating the binding relationship between the helmet code and the basket code.

[0080] In this implementation, image analysis can also be used to determine whether the helmet is in place; image analysis can further improve the accuracy of the judgment, avoid situations where the user correctly returns the helmet but the system makes a wrong judgment, and improve the user experience.

[0081] Figure 5 This is another exemplary flow chart of determining whether a helmet is in place in a shared vehicle according to some embodiments of this specification. Figure 5 As shown, process 500 includes the following steps: In some embodiments, process 500 may be performed by a processing device (such as processing device 110) or a component thereof.

[0082] On the premise that the actual information of the helmet code and the actual information of the basket code meet the first preset condition, this embodiment provides an example of determining the actual information of the helmet and basket positions.

[0083] Step 510: Determine whether the first metal contact matches the second metal contact.

[0084] In some embodiments, the helmet is provided with a first metal contact, and the basket is provided with a second metal contact.

[0085] The first metal contact and the second metal contact can be metal sheets made of conductive metals such as copper, aluminum, and iron. The first metal contact can be located on the plane of the contact part between the helmet and the basket. For example, the first metal contact can be located on the lower plane of the helmet close to the human ear side, and when the helmet is correctly returned, this plane can contact the bottom surface of the basket. The second metal contact can be located on the plane of the bottom surface of the basket. In some embodiments, the number of both the first metal contact and the second metal contact is two. The two first metal contacts are electrically connected through a conductive material, and the two second metal contacts are electrically connected through a conductive material. In some embodiments, one of the basket or the helmet includes a small power supply. When the first metal contact coincides with the second metal contact, the small power supply, the first metal contact, and the second metal contact form a closed circuit and thus current is generated. The processing device 110 can determine whether current passes through by means of devices such as an ammeter, so as to determine whether the first metal contact coincides with the second metal contact. When the first metal contact coincides with the second metal contact but no current passes through, the processing device 110 can report an abnormal circuit and prompt the maintenance personnel to perform troubleshooting.

[0086] In some embodiments, the first metal contact and the second metal contact can be snap bump-shaped contacts. For example, concave and convex contacts in shapes such as circular, triangular, and hexagonal. The concave and convex contacts can further increase the fixing effect when the metal contacts coincide, and improve the uniqueness of the helmet position, that is, it can be determined that the helmet of the shared vehicle is in place only when the first metal contact and the second metal contact coincide (the concave and convex contacts are fitted).

[0087] In some embodiments, the bottom of the basket is provided with a groove matching the helmet for fixing the placement position of the helmet. The width of the groove can be determined based on the side thickness of the helmet, and the depth of the groove can be determined based on the height of the helmet. By way of example only, the groove can be two grooves, or a C-shaped groove. Two second metal contacts are arranged on the surface of the groove. When the helmet is inserted into the groove and correctly placed in the groove, the first metal contact coincides with the second metal contact.

[0088] Step 520, in response to the coincidence of the first metal contact and the second metal contact, determine that the helmet of the shared vehicle is in place. In response to the non-coincidence of the first metal contact and the second metal contact, determine that the helmet of the shared vehicle is not in place.

[0089] In this embodiment, the structure of the metal contact and the groove is adopted, which can facilitate the user to quickly achieve the correct positioning of the helmet; by detecting whether the circuit is conducting instead of image recognition, the versatility of the method can be improved, and the positions of the helmet and the basket can also be determined in situations such as at night and in shaded places with dim light.

[0090] Figure 6 is another exemplary flowchart for determining whether the helmet of a shared vehicle is in place as shown in some embodiments of this specification. As Figure 6 shown, process 600 includes the following steps. In some embodiments, process 600 may be executed by a processing device (such as processing device 110) or its components.

[0091] On the premise that the actual information of the helmet code and the actual information of the basket code meet the first preset condition, based on Figure 5 this embodiment provides an example of determining the actual information of the position of the helmet and the basket.

[0092] Step 610, determine the trigger states of at least two triggers.

[0093] In some embodiments, at least two triggers are provided on the helmet or the basket. Among them, the trigger can be a metal contact sensor, a magnetic sensor, a pressure sensor, etc. At least two triggers can be arranged on the contact surface between the helmet and the basket. In some embodiments, at least two triggers can be arranged at intervals on the above contact surface, such as at an interval of 3 centimeters. The trigger state can include triggered and untriggered. When all the triggers are triggered, it means that the lower plane of the helmet close to the human ear side is perfectly attached to the bottom surface of the basket; when some triggers are triggered and some triggers are not triggered, it means that there is a gap between the helmet and the basket and the helmet is not placed correctly.

[0094] Step 620, in response to all of the at least two triggers being triggered, determine that the helmet of the shared vehicle is in place. In response to at least one of the at least two triggers not being triggered, determine that the helmet of the shared vehicle is not in place.

[0095] In this embodiment, by using triggers instead of metal contacts, the in-place judgment of the helmet can also be realized; the triggers do not require circuit conduction, avoiding abnormal conduction of metal contacts due to reasons such as rain and short circuits, and improving the accuracy of the in-place judgment process of the helmet.

[0096] Figure 7 is a schematic diagram of a shared vehicle as shown in some embodiments of this specification. As Figure 7 shown, the shared vehicle includes a basket 710, a basket code 711, a helmet 720, and a helmet code 721.

[0097] Only as an example, a coordinate system is established with the geometric center of the helmet code 721 as the origin, and the geometric center coordinates of the helmet code are obtained as (0, 0), and the geometric center coordinates of the basket code 711 are (X1, Y1). The above coordinates can reflect the relative position relationship between the helmet and the basket. By simply comparing the geometric center coordinates of the basket code 711 with the geometric center coordinates of the basket code in the verification data, it can be determined whether the actual helmet is in place.

[0098] Figure 8 is an exemplary flowchart of the user helmet-returning process shown in some embodiments of this specification. As Figure 8 shown, process 800 includes the following steps:

[0099] Step 810, the user clicks on helmet-return verification. Helmet-return verification can be an application in the user terminal 130.

[0100] Step 820, the application opens the camera of the user terminal.

[0101] Step 830, collect vehicle image information. Among them, the vehicle image information includes the two-dimensional code patterns, two-dimensional code positions, two-dimensional code sizes, and two-dimensional code angles of the helmet and the basket.

[0102] Step 840, request verification data from the server. Step 840 can be synchronized with the above steps 820 and 830.

[0103] Step 850, summarize the information. For example, the above information can be stored in the storage device 140.

[0104] Step 860, determine whether the actual two-dimensional code pattern is consistent with the verification data. In response to yes, execute step 870; in response to no, execute step 890.

[0105] Step 870, determine whether the actual two-dimensional code distance, size, and verification data are consistent. In response to yes, execute step 880; in response to no, execute step 890.

[0106] Step 880, the helmet is in place, and the vehicle can be returned.

[0107] Step 890, the helmet is not in place. Further, the processing device 110 can prompt the user to adjust the helmet position or replace the helmet.

[0108] Some embodiments of this specification also provide a device for determining whether the helmet of a shared vehicle is in place. The device includes at least one processor and at least one memory; at least one memory is used to store computer instructions; at least one processor is used to execute at least some of the computer instructions to implement the method for determining whether the helmet of a shared vehicle is in place.

[0109] The beneficial effects of the method provided in this specification for determining whether a helmet of a shared vehicle is in place include, but are not limited to: 1) Helmet detection is achieved through the helmet code and the basket code. Detection can be realized through image recognition, and the unique identifiability of the helmet code can prevent the helmet from being replaced. By determining the positions of the helmet code and the basket code, fraud in return is avoided; 2) The determination of whether the helmet is in place can also be achieved through image analysis. The accuracy of the determination is further improved through image analysis, avoiding the situation where the system misjudges when the user returns the helmet correctly, and improving the user experience; 3) The structural setting of metal contacts and grooves is adopted, which can facilitate the user to quickly achieve the correct positioning of the helmet. By detecting whether the circuit is conducting instead of image recognition, the versatility of the method can be improved, and the determination of the positions of the helmet and the basket can also be achieved in situations such as at night or in shaded areas with dim light; 4) The use of a trigger instead of a metal contact can also achieve the determination of the helmet being in place. The trigger does not require the circuit to conduct, avoiding abnormal conduction of the metal contact caused by reasons such as rain and short circuit, and improving the accuracy of the helmet in-place determination process; 5) The cost of the determination process is low, and batch determination can be carried out.

[0110] The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only an example and does not constitute a limitation to this specification. Although not explicitly stated here, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification, so such modifications, improvements, and corrections still fall within the spirit and scope of the exemplary embodiments of this specification.

[0111] At the same time, this specification uses specific terms to describe the embodiments of this specification. Such as "one embodiment", "an embodiment", and / or "some embodiments" mean a certain feature, structure, or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "an embodiment" or "one embodiment" or "an alternative embodiment" mentioned twice or more at different positions in this specification does not necessarily refer to the same embodiment. In addition, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0112] In addition, unless clearly stated in the claims, the order of the processing elements and sequences, the use of numerical and alphabetical characters, or the use of other names described in this specification are not used to limit the order of the processes and methods in this specification. Although some currently useful embodiments of the invention are discussed through various examples in the above disclosure, it should be understood that such details are for illustrative purposes only. The appended claims are not limited to the disclosed embodiments. On the contrary, the claims are intended to cover all modifications and equivalent combinations that conform to the essence and scope of the embodiments of this specification. For example, although the system components described above can be implemented by hardware devices, they can also be implemented only through software solutions, such as installing the described system on existing servers or mobile devices.

[0113] Similarly, it should be noted that, in order to simplify the presentation of the disclosure in this specification and thus help the understanding of one or more embodiments of the invention, in the foregoing description of the embodiments of this specification, sometimes multiple features are merged into one embodiment, drawing, or description thereof. However, this method of disclosure does not mean that the features required by the subject matter of this specification are more than those mentioned in the claims. In fact, the features of the embodiments are fewer than all the features of the individual embodiments disclosed above.

[0114] In some embodiments, numbers are used to describe components and the quantity of attributes. It should be understood that such numbers used to describe the embodiments are modified by the modifiers "about", "approximate", or "substantially" in some examples. Unless otherwise stated, "about", "approximate", or "substantially" indicate that the stated number allows a variation of ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, and such approximate values may change according to the characteristics required by individual embodiments. In some embodiments, the numerical parameters should consider the specified significant digits and adopt the method of retaining the general number of digits. Although the numerical ranges and parameters used to confirm the breadth of the scope in some embodiments of this specification are approximate values, in specific embodiments, such numerical settings are as precise as possible within the feasible range.

[0115] For each patent, patent application, patent application publication, and other materials cited in this specification, such as articles, books, specifications, publications, documents, etc., their entire contents are hereby incorporated into this specification as references. Except for the application history documents that are inconsistent with or conflict with the content of this specification, and except for the documents that limit the broadest scope of the claims of this specification (currently or subsequently appended to this specification). It should be noted that if there are inconsistencies or conflicts between the descriptions, definitions, and / or the use of terms in the supplementary materials of this specification and the content described in this specification, the descriptions, definitions, and / or the use of terms in this specification shall prevail.

[0116] Finally, it should be understood that the embodiments described in this specification are only used to illustrate the principles of the embodiments of this specification. Other variations may also fall within the scope of this specification. Therefore, by way of example and not limitation, alternative configurations of the embodiments of this specification may be regarded as consistent with the teachings of this specification. Accordingly, the embodiments of this specification are not limited to the embodiments explicitly presented and described in this specification.

Claims

1. A method for determining whether a helmet of a shared vehicle is in place, characterized in that, The method includes: Obtaining the verification data of the helmet being in place of the shared vehicle from the server, where the verification data includes verification code information and position verification information; Obtaining a vehicle image including the helmet code and the basket code of the shared vehicle; Obtaining actual helmet data based on the vehicle image, where the actual helmet data includes actual helmet code information and actual helmet position information; Judging whether the helmet of the shared vehicle is in place based on the actual helmet data and the verification data; And in response to the helmet of the shared vehicle being in place, allowing the vehicle to be returned.

2. The method according to claim 1, wherein The judging whether the helmet of the shared vehicle is in place based on the actual helmet data and the verification data includes: Obtaining actual basket data based on the vehicle image, where the actual basket data includes actual basket code information and actual basket position information; Judging whether the actual helmet code information and the actual basket code information meet a first preset condition; Judging whether the actual helmet position information and the actual basket position information meet a second preset condition; In response to both the first preset condition and the second preset condition being met, judging that the helmet of the shared vehicle is in place.

3. The method according to claim 1, characterized in that, The helmet code and the basket code are at least one of a two-dimensional code and a bar code.

4. The method according to claim 2, wherein In response to one of the first preset condition and the second preset condition not being met, the method further includes: Performing image analysis on the vehicle image based on an image analysis model to obtain an image analysis result; Judging whether the helmet of the shared vehicle is in place based on the image analysis result.

5. The method according to claim 4, wherein Based on the image analysis result, performing one of the following operations: Generating a prompt to adjust the helmet position; or Generating a prompt to replace the helmet.

6. The method according to claim 2, characterized in that The helmet is provided with a first metal contact, and the basket is provided with a second metal contact. When the actual helmet code information and the actual basket code information meet the first preset condition, the method further includes: Judging whether the first metal contact and the second metal contact are in conformity; In response to the first metal contact and the second metal contact being in conformity, judging that the helmet of the shared vehicle is in place.

7. The method according to claim 2, characterized in that The helmet or the basket is provided with at least two triggers. When the actual helmet code information and the actual basket code information meet the first preset condition, the method further includes: Judging the triggering states of the at least two triggers; In response to all of the at least two triggers being triggered, judging that the helmet of the shared vehicle is in place.

8. The method according to claim 5, wherein The method further includes: When the helmet is replaced, updating the binding data between the helmet code and the basket code in the server.

9. A system for determining whether a helmet of a shared vehicle is in place, characterized in that, The system includes: A first obtaining module, configured to obtain the verification data of the helmet being in place of the shared vehicle from the server, where the verification data includes verification code information and position verification information; A second obtaining module, configured to obtain a vehicle image including the helmet code and the basket code of the shared vehicle; An image analysis module, configured to obtain actual helmet data based on the vehicle image, where the actual helmet data includes actual helmet code information and actual helmet position information; A judging module, configured to judge whether the helmet of the shared vehicle is in place based on the actual helmet data and the verification data; A vehicle return module, configured to allow vehicle return in response to the helmet of the shared vehicle being in place.

10. A device for judging whether a helmet of a shared vehicle is in place, characterized in that, The device includes: At least one storage medium storing computer instructions; At least one processor executing the computer instructions to implement the method according to any one of claims 1 to 8.

Images