USB camera binding and recovering method based on Android system

Abstract

The invention provides a USB camera binding and recovery method based on an Android system, relates to the technical field of camera binding and recovery, and realizes fixed serial number binding, exception recovery and concurrent access functions of a USB camera through system-level configuration management. When the system is started, system attribute parameters are generated by loading preset GPIO and USB port configuration files, and ordered access of the camera is ensured. Meanwhile, by means of a cloud platform communication mechanism, binding configuration synchronization between the devices is achieved, and the configuration process is simplified. By monitoring the insertion state of the USB equipment in real time, automatic identification can be realized, a user can be prompted to bind the camera, and manual input and configuration modification are supported. Besides, when the cameras are abnormal, the power reset operation can be triggered through a broadcast mechanism, the camera function can be quickly recovered, concurrent access of multiple cameras is supported, and the operation efficiency and stability of the equipment in a complex application scene are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of camera binding and recovery, and in particular to a USB camera binding and recovery method based on an Android system. Background Art

[0002] With the widespread use of smart devices, USB cameras play a vital role in various scenarios, especially in devices like unmanned vending machines. The stability and access efficiency of the camera directly affect the overall performance of the device and the user experience. However, existing USB camera applications in Android systems face many challenges.

[0003] In unmanned vending machines, merchandise is stored in layers, each layer imaged by a weight sensor and a different USB camera. Product identification and transaction settlement typically rely on multiple USB cameras for imaging and AI analysis. Due to randomness during USB camera power-up initialization and registration, camera access is subject to a degree of randomness, with no fixed order. Furthermore, the Android system API limits access to only one camera at a time, requiring the system to individually traverse and identify all cameras before settlement. This process is not only time-consuming but also consumes significant system resources.

[0004] In addition to access efficiency issues, USB camera stability is also a key concern. Due to USB wiring, device failure, or other hardware issues, the camera may become inaccessible, leading to transaction settlement failures. In these cases, the system lacks an effective recovery mechanism, severely impacting device stability and significantly reducing the user experience.

[0005] In summary, existing USB camera applications in Android systems suffer from issues such as low access efficiency, excessive system resource usage, and insufficient device stability (the camera cannot recover from abnormalities). These issues not only limit the widespread application of devices such as unmanned vending machines, but also urgently require new technical solutions to optimize the management and use of USB cameras to improve overall device performance and user experience.

[0006] In view of this, this application is filed. Summary of the Invention

[0007] The present invention provides a USB camera binding and recovery method based on the Android system, which can at least partially improve the above problems.

[0008] To achieve the above object, the present invention adopts the following technical solutions: A USB camera binding and recovery method based on Android system, comprising: The default configuration file is packaged according to the hardware information, and the restriction of only accessing one camera at a time is lifted. After receiving the startup signal, it communicates with the remote cloud platform, registers the device, synchronizes the binding configuration file, and restarts the cameraServer service program; Detect the device inserted into the USB port of the current Android device, obtain the device information, and broadcast it to the system UI when it is determined that the device is not bound; When the binding configuration program receives a broadcast or UI interaction operation, it adjusts the configuration parameters or configuration functions according to the device information and notifies the cameraServer service program to update the configuration; When the cameraServer service program starts, it scans the Android system's camera devices according to the binding configuration file, reads the information, and matches and binds the camera devices based on the read information.

[0009] In summary, the Android-based USB camera binding and recovery method aims to address existing issues such as inefficient USB camera access, insufficient recovery capabilities, and limited concurrent access to multiple cameras. By preconfiguring the correspondence between the USB power reset GPIO pin and the USB physical port via system firmware and loading the relevant configuration file at system startup, system property parameters corresponding to the IO are generated, providing basic support for orderly camera access. Furthermore, the system establishes a connection with the cloud platform through the cloud platform communication service program, queries and synchronizes camera binding configuration files, enabling configuration sharing across multiple devices and greatly simplifying the configuration process.

[0010] Regarding camera management, the cameraServer service program loads the binding configuration file upon startup, scans the system for camera devices, matches and binds them based on the device's PID:VID information or USB port information, and generates a camera access serial number. Furthermore, the system launches a USB camera device detection program to monitor newly inserted USB camera devices in real time and broadcast notifications to the binding configuration program to initiate binding operations. The binding configuration program allows users to manually enter or modify binding configurations through UI interaction and upload configuration files to the cloud platform for multi-device synchronization.

[0011] In the event of a camera anomaly, the present invention uses a reset broadcast listener to receive the reset broadcast, invokes the GPIO interface to control the power reset operation of the corresponding USB port, restores normal camera operation, and notifies the cameraServer to reinitialize the bound camera. If the camera access program detects an anomaly while accessing the camera, it automatically sends a reset broadcast, waits for the reset to complete, and then reattempts access, thus achieving an anomaly recovery function. Furthermore, the present invention supports concurrent access to multiple cameras, significantly improving the system's operational efficiency and stability.

[0012] Overall, this method significantly improves camera access efficiency and device stability through orderly USB camera binding, exception recovery, and concurrent access capabilities, optimizing the user experience in multi-camera application scenarios such as unmanned vending machines. This invention is particularly suitable for complex scenarios requiring multi-camera collaboration, possessing broad application prospects and significant innovation. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 This is a flowchart of a method for binding and restoring a USB camera based on an Android system provided by an embodiment of the present invention; Figure 2 This is a flow chart of device registration and configuration file synchronization provided by an embodiment of the present invention; Figure 3 is a flow chart of camera detection and configuration provided by an embodiment of the present invention; Figure 4 This is a business flow chart of the UI configuration program provided by an embodiment of the present invention; Figure 5 This is a camera binding flow chart provided by an embodiment of the present invention; Figure 6 This is a flowchart of an application resetting a camera provided by an embodiment of the present invention; Figure 7 This is a camera reset flow chart provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0014] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0015] refer to Figure 1 As shown, the first embodiment of the present invention discloses a USB camera binding and recovery method based on the Android system, which can be executed by a USB camera binding and recovery device based on the Android system (hereinafter referred to as the binding and recovery device). In particular, it is executed by one or more processors in the binding and recovery device to implement the following method: S1, packages the configuration file by default according to the hardware information, and removes the restriction that only one camera can be accessed at a time. After receiving the start signal, it communicates with the remote cloud platform, registers the device, synchronizes the binding configuration file, and restarts the cameraServer service program; Preferably, the binding configuration file is a binding configuration file in which the USB power reset GPIO pins correspond to the USB physical ports on a one-to-one basis, wherein the order of the USB physical port information in the binding configuration file is the same as the order of the device physical ports.

[0016] Specifically, step S1 further includes: when a start signal is received, loading the GPIO driver, and at the same time, loading the binding configuration file, generating system attribute parameters corresponding to the GPIO pin, wherein the system attribute parameters correspond to the cameraid serial number accessed by the camera; Based on the binding configuration file, after the Android system is successfully connected to the Internet, the cloud platform communication service program is started, and a connection is established with the remote cloud platform using the TCP protocol. When the connection is successful, the device SN number and the device module IMEI number are submitted to the cloud platform for registration; After registration is complete, a signaling message is sent to the cloud platform to check whether there is a binding configuration file for the camera that can be downloaded; If so, download the binding configuration file and restart the cameraServer service program of the Android system after the download is successful.

[0017] In this embodiment, the Android system pre-packages a configuration file based on hardware information at the factory. This file details the one-to-one binding relationship between the USB power reset GPIO pins and the USB physical ports (e.g., the physical ports USB1, USB2, USB3, and USB4 correspond to the port information in the configuration file in the order devices / 4-1.1, devices / 4-1.2, devices / 4-1.3, and devices / 4-1.4). This pre-packaging approach ensures that the system can quickly load and apply these configurations at startup, providing basic support for subsequent camera management. At the same time, the system also removes the default Android system restriction of only being able to access one camera at a time. Camera access programs can use the Android system API to concurrently access multiple cameras, thus making concurrent access to multiple cameras possible.

[0018] When the device receives the startup signal, the system first loads the GPIO driver and the pre-packaged configuration files. Through these configuration files, the system generates system property parameters corresponding to the GPIO pins (such as cameraid_power=gpio1). These parameters correspond to the cameraid serial number accessed by the camera. In this way, during subsequent camera accesses, the system can quickly locate the corresponding GPIO address through the cameraid serial number and control it, thereby achieving a power reset operation for the USB camera. For example, when resetting the power of the port corresponding to cameraid, the gpio address can be obtained through the cameraid serial number, and the GPIO can be controlled to reset the power of the USB port.

[0019] After the device boots up and successfully connects to the internet, the system launches the cloud platform communication service. This service establishes a stable connection with the remote cloud platform via the TCP protocol. Once connected, the system submits the device's serial number and module IMEI number to the cloud platform for registration. Once registration is complete, the system sends a signal to the cloud platform to inquire about the availability of a camera-binding configuration file. If the configuration file is available on the cloud platform, the system downloads it and, after successful download, restarts the Android system's cameraServer service.

[0020] This interaction mechanism with the cloud platform has significant beneficial effects. On the one hand, by synchronizing and binding configuration files through the cloud platform, configuration sharing can be achieved among multiple devices, which greatly simplifies the configuration process and improves the scalability and management efficiency of the device. On the other hand, when a device malfunctions or requires a configuration update, downloading the latest configuration file from the cloud platform and restarting the cameraServer service program can quickly restore the normal operation of the camera, improving the stability and reliability of the system. Among them, the cameraServer service program is a standard service program of the Android system, which is used to handle the access of the Android system upper-layer API to the camera device and call the initialization, binding, parameter configuration, access control and other operations of the Android system HAL layer camera.

[0021] S2, detect the device inserted into the USB port of the current Android device, obtain device information, and broadcast it to the system UI when it is determined that the device is not bound; Specifically, step S2 further includes: detecting whether a USB device is inserted into the USB port under the Android system / sys / bus / usb / devices / directory; If so, check the Android system / sys / class / video4linux directory to determine whether the inserted USB camera is a USB camera; If the device is not a USB camera, continue to detect whether a USB device is inserted; If a USB camera is inserted, obtain the PID:VID information and USB port information of the USB camera device; When it is determined that the matching binding configuration file is not bound, the AM command is called to send a broadcast to the UI process, and a pop-up window prompts to continue writing the configuration. The broadcast information contains the PID: VID and USB port information of the USB camera.

[0022] In this embodiment, during the operation of the Android device, the system monitors the insertion status of the USB port in real time. This process is achieved by detecting the USB port under the / sys / bus / usb / devices / directory. The system will continue to check this directory to determine whether there is a new USB device inserted. This real-time monitoring mechanism ensures that the system can detect newly inserted devices in a timely manner, thereby providing basic support for subsequent device identification and binding operations. When a USB device is detected to be inserted, the system will further check the / sys / class / video4linux directory. This directory contains information about all video devices in the system. By detecting this directory, the system can determine whether the inserted device is a USB camera. If the inserted device is not a USB camera, the system will ignore the device and continue to monitor other USB ports to wait for the next device to be inserted.

[0023] When a USB camera is confirmed to be plugged in, the system will retrieve the camera's PID:VID information and USB port information. The PID:VID information uniquely identifies the camera and distinguishes different camera devices, while the USB port information is used to determine the specific location of the camera connection. By obtaining this information, the system can provide accurate device parameters for subsequent binding operations.

[0024] After obtaining the USB camera's PID:VID and USB port information, the system checks the current binding profile to determine whether the camera has been bound. If a matching binding profile is not yet bound, the system calls the AM command to send a broadcast to the UI process. This broadcast contains the USB camera's PID:VID and USB port information. Using the USB camera's PID:VID or the device's USB port to bind the USB camera's serial number ensures orderly access to the USB camera, improving device system efficiency and allowing the UI process to obtain these key device parameters.

[0025] S3: When the binding configuration program receives a broadcast or UI interaction operation, it adjusts the configuration parameters or configuration functions according to the device information and notifies the cameraServer service program to update the configuration; Specifically, step S3 further includes: when the binding configuration program receives the broadcast, obtaining the UVC device PID: VID and USB port information index from the broadcast parameters, starting the camera binding configuration function page and displaying the device PID: VID and USB port information of the inserted USB camera to prompt the user whether to bind the corresponding camera; When the user chooses to bind the corresponding camera, the configuration parameters are saved to the binding configuration file, and the cameraServer service program is notified to update the configuration; When the user chooses to cancel the binding of the corresponding camera, no processing is performed when exiting the UI process.

[0026] When the binding configuration program starts the camera binding configuration function page through UI interaction, enter the device PID: VID or USB port serial number of the USB camera through UI interaction to enter the USB camera binding configuration and save it to the binding configuration file; Alternatively, you can modify or delete the binding content of an existing binding configuration file through UI interaction, and then update the parameters in the binding configuration file again. After the binding configuration file is updated, a pop-up window will prompt the user whether to upload the configuration file to the cloud platform; If so, call the cloud platform's http protocol interface to upload the current binding configuration file to the cloud platform. The cloud platform can synchronize the binding configuration file to other devices and write the synchronization flag into the platform database. When the device designated for synchronization is registered and online, and the flag indicating that the binding configuration file needs to be synchronized is queried, the binding configuration file is actively downloaded to the device and the cameraServer service program is notified to update the configuration.

[0027] In this embodiment, when the binding configuration program receives a system broadcast or an operation triggered by the user through UI interaction, the camera binding configuration function will be started. This process first involves obtaining the PID:VID and USB port information index of the UVC device from the broadcast parameters. This information is the key identifier of the camera device and is used to distinguish different cameras and the specific ports to which they are connected. After obtaining this information, the binding configuration program will start a function page to display the device PID:VID and USB port information of the inserted USB camera. This display process provides the user with an intuitive interface, allowing the user to clearly understand the specific information of the currently inserted camera device. The program will then prompt the user whether to bind the camera. This prompt mechanism not only improves the flexibility of user operation, but also avoids configuration errors caused by misoperation.

[0028] If the user chooses to bind the camera, the binding configuration program will save the relevant configuration parameters to the binding configuration file. These parameters include the camera's PID: VID, USB port information, and other necessary configuration information. After saving, the program will notify the cameraServer service program to update the configuration. This update operation ensures that the cameraServer can correctly manage the camera device according to the latest configuration file, thereby improving the stability and reliability of the system. Conversely, if the user chooses to cancel the binding operation, the binding configuration program will exit the UI process without making any changes to the current configuration file. This design allows users to flexibly exit the operation when they are unsure or do not need to bind, without causing unnecessary impact on the system configuration.

[0029] The binding configuration program also supports manual entry of the USB camera's device PID:VID or USB port number (e.g., USB1, USB2, USB3, USB4) through UI interaction. This feature is particularly useful for scenarios where a camera needs to be configured before it's plugged in. Users can enter this information through the UI to complete the USB camera binding configuration and save it to the binding configuration file. Existing binding configuration files can also be modified or deleted through UI interaction. This allows users to manually enter the PID:VID or USB port number for binding, allowing them to modify or remove binding configurations even when no USB camera is connected. This flexibility allows users to adjust camera binding configurations at any time based on their needs, further improving system adaptability and user experience. After updating the binding configuration file, the program will prompt the user to upload the configuration file to the cloud platform. Automatic USB camera device detection and broadcast-activated pop-up configuration make camera binding more convenient, simple, and intuitive. If the user chooses to upload, the binding configuration program will use the cloud platform's HTTP protocol interface to upload the current binding configuration file to the cloud platform. The cloud platform not only stores configuration files but also synchronizes them with other devices. By transferring the configured binding configuration file to the cloud platform for synchronization, USB camera binding configuration only needs to be performed on one device, and other devices can also be bound by synchronizing the configuration file, achieving the goal of configuring one device and running multiple devices. In this way, users can share the same camera configuration on different devices, greatly improving configuration efficiency and consistency.

[0030] The cloud platform writes the synchronization flag to the platform database. When a device designated for synchronization registers and comes online, the system will query the binding configuration file for synchronization. The device will then proactively download the binding configuration file from the cloud platform and notify the cameraServer service program to update the configuration. This synchronization mechanism ensures configuration consistency across multiple devices and is particularly useful in scenarios where the same camera configuration is required across multiple devices, such as multi-camera applications like unmanned vending machines. It should be noted that once the UI program updates the parameters in the binding configuration file, it will notify the cameraServer service program to update the configuration.

[0031] S4, when the cameraServer service program is started, it scans the camera device of the Android system according to the binding configuration file, reads the information, and matches and binds the camera device according to the read information.

[0032] Specifically, step S4 further includes: when the cameraServer service program is started, initializing and loading the binding configuration file for camera binding, scanning the video camera node in the / dev / directory of the Android system, and reading the minor device number X of the video node; Obtain the Android system device path based on the minor device number X, and obtain the device PID:VID information from the modalias node under the device path. Obtain the device's corresponding USB port information from the driver node under the device path and match it with the parameters of the binding configuration file to generate the / dev / videoX path corresponding to the camera's access serial number Cameraid; Among them, when the parameters of the binding configuration file are PID:VID, it is matched and bound with the PID:VID of the obtained camera device; when the parameters of the binding configuration file are USB port information, it is matched and bound with the USB port information of the obtained camera device.

[0033] In this embodiment, when the cameraServer service program starts, the system first initializes and loads the camera binding configuration file. This configuration file contains key camera device information, such as the PID:VID (product ID and vendor ID) or USB port information, which is used for subsequent matching and binding operations. Loading the configuration file is a fundamental step in ensuring correct camera identification and management, and ensures stable system operation. The cameraServer service program then scans the video camera nodes in the Android system's / dev / directory. This directory contains node information for all camera devices in the system. By scanning these nodes, the system obtains the minor device number X for each camera node. Minor device number X is a key identifier for the system to identify camera devices, helping it distinguish between different camera devices. After obtaining minor device number X, the system uses it to retrieve the corresponding device path (e.g., / sys / class / video4linux / videoX / device / ). The device path is typically located in the / sys / class / video4linux / videoX / device / directory. Within this path, the system further reads the modalias node to obtain the device's PID:VID information and obtains the corresponding USB port information from the driver node. This information is the unique identifier of the camera device and is used for subsequent matching operations.

[0034] Next, the acquired PID:VID information or USB port information is matched against the parameters in the binding configuration file. If the binding configuration file's parameters are based on PID:VID, the system compares the camera device's PID:VID with the PID:VID in the configuration file. If a match is successful, the system generates an access code, CameraID, for the camera and associates it with the corresponding / dev / videoX path. Similarly, if the binding configuration file's parameters are based on USB port information, the system matches the camera device's USB port information with the port information in the configuration file. If successful, CameraID is also generated and the path associated. This binding method based on PID:VID or USB port information ensures accurate identification and access to camera devices. This method allows the system to assign a unique access code to each camera device, enabling orderly camera access. This orderly access mechanism not only improves camera access efficiency but also avoids access errors caused by random device initialization order.

[0035] This matching and binding mechanism also offers significant benefits. First, it improves system stability and reliability. By accurately matching and binding camera devices, the system avoids access failures or anomalies caused by device identification errors. Second, this mechanism enhances system flexibility and scalability. When adding or replacing camera devices, simply update the binding configuration file, and the system will automatically identify and bind the new device, eliminating the need for complex system reconfiguration.

[0036] Preferably, it also includes: when it is determined that the device has been bound, directly starting the cameraServer service program, scanning the camera device of the Android system according to the binding configuration file, reading the information, and matching and binding the camera device according to the read information.

[0037] Specifically, in this embodiment, when the system detects that a device is inserted into the USB port, it will first determine whether the device has been bound. This judgment process is achieved by checking the binding configuration file. The binding configuration file records the PID:VID information or USB port information of all bound cameras. The system determines whether the inserted device already exists in the configuration file by comparing this information. If the judgment result shows that the device has been bound, the system will directly start the cameraServer service program. This direct startup method avoids repeated binding operations, saves system resources and time, and significantly improves the operating efficiency of the system. When the cameraServer service program starts, it will initialize and load the binding configuration file, which is a basic step to ensure that the camera can be correctly identified and managed.

[0038] Preferably, the method further comprises: using the Android system API and the cameraaid serial number of the camera to access the corresponding bound camera, and determining whether the camera is abnormal; If not, perform image capture or video acquisition; If so, send a camera reset broadcast with the corresponding serial number and wait for the camera reset to be completed. When it is determined that the reset is completed, call the API again to continue accessing the camera.

[0039] Specifically, in this embodiment, after the camera is bound and the cameraServer service is successfully started, the system accesses the bound camera using the Android system API and the camera's CameraID serial number. This approach utilizes the standardized interface provided by the Android system and, combined with the camera's unique CameraID identifier, ensures precise access to the camera. This access method not only improves system compatibility but also simplifies development and maintenance.

[0040] When the system attempts to access the camera, it first determines whether the camera is in an abnormal state. If the USB camera is abnormal, it will be powered off and recovered to ensure the stable operation of the device system. This determination process is achieved by calling the Android system API and checking the returned status code. If the API returns a status code indicating that the camera is working normally, the system will continue to perform image capture or video capture operations. This normal access process ensures that the camera can efficiently complete its functions in a stable state and provide users with clear images or smooth videos.

[0041] However, if the API returns a status code indicating that the camera is abnormal, the system will immediately take measures to recover; that is, the bound camera supports concurrent access and concurrent reset operations. Specifically, the system will send a camera reset broadcast corresponding to the serial number. This broadcast signal will trigger a reset operation, which controls the power-on and power-off of the corresponding USB port through the GPIO interface, thereby resetting the abnormal camera. This automatic reset mechanism can quickly restore the normal operation of the camera and avoid system interruption or data loss caused by camera failure.

[0042] After sending the reset broadcast, the system will enter a delay waiting state to wait for the camera reset to complete. This delay is to ensure that the reset operation has enough time to take effect. When the reset is complete, the system will call the Android system API again to attempt to access the camera. This automatic retry mechanism further improves the reliability of the system and ensures that the camera can quickly resume work after reset.

[0043] Based on this step, the method introduces an abnormality detection and automatic reset mechanism during camera access. This mechanism not only improves the access efficiency of the camera, but also enhances the stability and reliability of the system. In normal cases, the system can efficiently complete image capture or video capture tasks; in abnormal cases, the system can automatically restore the normal operation of the camera, avoiding system interruption caused by camera failure. This optimized access and abnormality handling mechanism is particularly suitable for scenarios that require long-term stable operation, such as multi-camera applications such as unmanned vending machines, and can significantly improve user experience and overall system performance.

[0044] Preferably, it further comprises: when the reset broadcast listener receives the camera reset broadcast, obtaining the broadcast parameters, calling the GPIO interface to control the power-on and power-off of the corresponding interface USB power to reset the USB camera, wherein the broadcast parameters have the cameraId serial number of the camera; After successful reset, notify the cameraServer service program to reinitialize the bound camera and mark the reset success system attribute; Among them, the judgment conditions for whether the reset is successful include: when the USB interface power is turned off, detecting that the corresponding USB port device has been removed, and after the USB interface power is turned on, detecting that the USB camera of the corresponding USB port has been recognized and reinserted.

[0045] Specifically, in this embodiment, after receiving the reset broadcast, the reset broadcast listening program will extract the cameraId serial number of the camera from the broadcast parameters. This serial number is the unique identifier of the camera and is used to determine the specific camera that needs to be reset. Subsequently, the program will call the GPIO interface to control the power supply of the USB interface corresponding to the camera to perform power on and off operations. Specifically, the GPIO interface will first turn off the power supply of the USB interface, and then turn on the power supply again after a certain delay. This power on and off operation can effectively reset an abnormal USB camera. Simply put, the reset broadcast listening program obtains the corresponding gpio address from the system properties according to the camera serial number and calls the gpio interface to control the power on and off reset of the USB interface (such as controlling the 5V power output of the USB interface when the gpio enable is high, and turning off the 5V power output of the USB interface when the gpio enable is low).

[0046] During the reset process, the system uses two key criteria to determine whether the reset was successful. First, when the USB port is powered off, the system checks to see if the device in the corresponding USB port has been removed. This detection process is performed by checking the device status in the system device manager. If the device has been removed, it indicates that the power-off operation has taken effect. Second, after the USB port is powered back on, the system checks to see if the USB camera in the corresponding USB port has been re-identified and inserted. This detection process is also performed by checking the device status in the system device manager. If the camera has been re-identified and inserted, the reset operation is successful.

[0047] When the reset is successful, the reset broadcast listener will notify the cameraServer service program to reinitialize the bound camera. This notification process is implemented through the system's internal communication mechanism to ensure that the cameraServer can respond to the reset operation in a timely manner and reload the camera's configuration information. At the same time, the system will set a flag to indicate that the reset operation has been successfully completed. This flag can be used for subsequent system status checks and log records. In summary, the USB camera binding and recovery method based on the Android system realizes the binding of the serial number of the camera according to the PID:VID or the order of the hardware physical port of the USB camera, and locally saves and uploads the binding configuration parameters to the platform, so as to realize the synchronous configuration of the online device by the platform. When the USB camera is abnormal, a broadcast reset can be sent to the corresponding camera to realize the abnormal recovery function of the USB camera, so as to ensure the ordered access and stable access of the USB camera and realize the efficient and stable operation of the device system. In short, the method can bind a fixed serial number to the USB camera under the Android system, and can realize the concurrent access of multiple cameras, and when the corresponding serial number camera is abnormal, the camera can be reset and recovered individually, so as to improve the access efficiency of the camera and the stability of the device.

[0048] Specifically, first, the system firmware preconfigures the correspondence between the USB power reset GPIO pin and the USB physical port, and loads the related configuration file when the system starts, to generate the system attribute parameters corresponding to the GPIO pin. This process provides basic support for the ordered access of the camera. At the same time, the system establishes a connection with the cloud platform through the cloud platform communication service program, queries and synchronizes the camera binding configuration file, and realizes the configuration sharing among multiple devices. This synchronization mechanism of the configuration file not only simplifies the configuration process, but also improves the scalability and management efficiency of the device.

[0049] In terms of camera management, the application loads the binding configuration file through the cameraServer service program, and scans the camera devices in the system. By reading the modalias node under the device path to obtain the PID:VID information, and obtaining the USB port information from the driver node, the cameraServer can match these information with the parameters in the binding configuration file to generate the access serial number Cameraid of the camera. This binding method based on PID:VID or USB port information ensures the ordered access of the camera and avoids the low access efficiency problem caused by the random initialization order of the camera in the traditional method.

[0050] In addition, the application also introduces a USB camera device detection program to monitor whether there is a new USB camera inserted in the system in real time. Once a new device is detected, the system will obtain its PID:VID and USB port information, and notify the binding configuration program through broadcast. The binding configuration program supports users to manually enter or modify the binding configuration through UI interaction, and saves the configuration file locally or uploads it to the cloud platform. This automatic detection and binding prompting mechanism enables users to more conveniently complete the binding operation of the camera, and improves the usability of the system.

[0051] Regarding camera exception handling, this invention uses a reset broadcast listener to receive reset broadcasts and invoke the GPIO interface to control the power cycle of the corresponding USB port, thereby quickly resetting the abnormal camera. Upon successful reset, the system notifies the cameraServer to reinitialize the bound camera and sets a reset success flag. This automatic reset mechanism quickly restores normal camera operation, avoids system interruptions caused by camera failures, and significantly improves system stability and reliability.

[0052] This invention also supports concurrent access to multiple cameras, improving system efficiency by removing the Android system's default restriction of only accessing one camera at a time. In practical applications, this feature is particularly suitable for scenarios such as unmanned vending machines that require multiple cameras to work together, significantly improving the user experience.

[0053] In summary, this invention significantly improves camera access efficiency and device stability by optimizing USB camera binding, exception recovery, and concurrent access mechanisms. The cloud platform's configuration file synchronization function further simplifies the multi-device management process. This invention is not only applicable to multi-camera application scenarios such as unmanned vending machines, but also has broad applicability and significant innovation, providing important support for technological development in related fields.

[0054] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A USB camera binding and recovery method based on Android system, characterized in that: include: The default configuration file is packaged according to the hardware information, and the restriction of only accessing one camera at a time is lifted. After receiving the startup signal, it communicates with the remote cloud platform, registers the device, synchronizes the binding configuration file, and restarts the cameraServer service program; Detect the device inserted into the USB port of the current Android device, obtain the device information, and broadcast it to the system UI when it is determined that the device is not bound; When the binding configuration program receives a broadcast or UI interaction operation, it adjusts the configuration parameters or configuration functions according to the device information and notifies the cameraServer service program to update the configuration; When the cameraServer service program starts, it scans the Android system's camera devices according to the binding configuration file, reads the information, and matches and binds the camera devices based on the read information.

2. The method for binding and restoring a USB camera based on an Android system according to claim 1, wherein: The binding configuration file is a binding configuration file that corresponds one-to-one between USB power reset GPIO pins and USB physical ports, wherein the order of USB physical port information in the binding configuration file is the same as the order of device physical ports.

3. The method for binding and restoring a USB camera based on an Android system according to claim 1, wherein: After receiving the start signal, it communicates with the remote cloud platform, registers the device, synchronizes the binding configuration file, and restarts the cameraServer service program, specifically: When a start signal is received, the GPIO driver is loaded, and at the same time, the binding configuration file is loaded to generate system property parameters corresponding to the GPIO pin, wherein the system property parameters correspond to the cameraaid serial number accessed by the camera; Based on the binding configuration file, after the Android system is successfully connected to the Internet, the cloud platform communication service program is started, and a connection is established with the remote cloud platform using the TCP protocol. When the connection is successful, the device SN number and the device module IMEI number are submitted to the cloud platform for registration; After registration is complete, a signaling message is sent to the cloud platform to check whether there is a binding configuration file for the camera that can be downloaded; If so, download the binding configuration file and restart the cameraServer service program of the Android system after the download is successful.

4. The method for binding and restoring a USB camera based on an Android system according to claim 1, wherein: Detect the device plugged into the USB port of the current Android device, obtain the device information, and broadcast it to the system UI when it is determined that the device is not bound. Specifically: Check whether there is a USB device plugged into the USB port under the Android system's / sys / bus / usb / devices / directory; If so, check the Android system / sys / class / video4linux directory to determine whether the inserted USB camera is a USB camera; If the device is not a USB camera, continue to detect whether a USB device is inserted; If a USB camera is inserted, obtain the PID:VID information and USB port information of the USB camera device; When it is determined that the matching binding configuration file is not bound, the AM command is called to send a broadcast to the UI process, and a pop-up window prompts to continue writing the configuration. The broadcast information contains the PID: VID and USB port information of the USB camera.

5. The method for binding and restoring a USB camera based on an Android system according to claim 1, wherein: When the binding configuration program receives a broadcast or UI interaction operation, it adjusts the configuration parameters or configuration functions according to the device information and notifies the cameraServer service program to update the configuration. Specifically: When the binding configuration program receives the broadcast, it obtains the UVC device PID: VID and USB port information index from the broadcast parameters, starts the camera binding configuration function page and displays the device PID: VID and USB port information of the inserted USB camera to prompt the user whether to bind the corresponding camera; When the user chooses to bind the corresponding camera, the configuration parameters are saved to the binding configuration file, and the cameraServer service program is notified to update the configuration; When the user chooses to cancel the binding of the corresponding camera, no processing is performed when exiting the UI process.

6. The method for binding and restoring a USB camera based on the Android system according to claim 5, wherein: Also includes: When the binding configuration program starts the camera binding configuration function page through UI interaction, enter the device PID: VID or USB port serial number of the USB camera through UI interaction to enter the USB camera binding configuration and save it to the binding configuration file; Alternatively, you can modify or delete the binding content of an existing binding configuration file through UI interaction, and then update the parameters in the binding configuration file again. After the binding configuration file is updated, a pop-up window will prompt the user whether to upload the configuration file to the cloud platform; If so, call the cloud platform's http protocol interface to upload the current binding configuration file to the cloud platform. The cloud platform can synchronize the binding configuration file to other devices and write the synchronization flag into the platform database. When the device designated for synchronization is registered and online, and the flag indicating that the binding configuration file needs to be synchronized is queried, the binding configuration file is actively downloaded to the device and the cameraServer service program is notified to update the configuration.

7. The method for binding and restoring a USB camera based on an Android system according to claim 1, wherein: When the cameraServer service program starts, it scans the Android system's camera devices according to the binding configuration file, reads information, and matches and binds the camera devices based on the read information. Specifically: When the cameraServer service program starts, it initializes and loads the binding configuration file for the camera, scans the video camera node in the Android system's / dev / directory, and reads the minor device number X of the video node; Obtain the Android system device path based on the minor device number X, and obtain the device PID:VID information from the modalias node under the device path. Obtain the device's corresponding USB port information from the driver node under the device path and match it with the parameters of the binding configuration file to generate the / dev / videoX path corresponding to the camera's access serial number Cameraid; Among them, when the parameters of the binding configuration file are PID:VID, it is matched and bound with the PID:VID of the obtained camera device; when the parameters of the binding configuration file are USB port information, it is matched and bound with the USB port information of the obtained camera device.

8. The method for binding and restoring a USB camera based on an Android system according to claim 1, wherein: Also includes: When it is determined that the device has been bound, the cameraServer service program is directly started, the camera device of the Android system is scanned according to the binding configuration file, the information is read, and the camera device is matched and bound according to the read information.

9. The method for binding and restoring a USB camera based on an Android system according to claim 1, wherein: Also includes: Use the Android system API and the camera's cameraid serial number to access the corresponding bound camera and determine whether the camera is abnormal; If not, perform image capture or video acquisition; If so, send a camera reset broadcast with the corresponding serial number and wait for the camera reset to be completed. When it is determined that the reset is completed, call the API again to continue accessing the camera.

10. The method for binding and restoring a USB camera based on the Android system according to claim 8, wherein: Also includes: When the reset broadcast listener receives the camera reset broadcast, it obtains the broadcast parameters and calls the GPIO interface to control the USB power supply of the corresponding interface to reset the USB camera. The broadcast parameters contain the cameraId serial number of the camera. After the reset is successful, notify the cameraServer service program to reinitialize the bound camera and mark the reset success system properties; Among them, the judgment conditions for whether the reset is successful include: when the USB interface power is turned off, detecting that the corresponding USB port device has been removed, and after the USB interface power is turned on, detecting that the USB camera of the corresponding USB port has been recognized and reinserted.

Images