A helmet centralized voice control multi-device cycling system and operation control method

Abstract

This invention belongs to the field of IoT technology for intelligent cycling equipment. It discloses a helmet-based centralized voice control system for multiple devices and its operation control method. The system includes an intelligent helmet terminal and at least one external device, which may include extended cycling equipment, a mobile terminal, and / or an intelligent vehicle. The intelligent helmet terminal serves as the centralized control center of the system. This invention constructs a collaborative architecture with the intelligent helmet as the centralized control center, achieving data interconnection and interoperability between core cycling equipment (vehicle and helmet) and breaking down data barriers with extended cycling equipment. A vehicle condition acquisition module collects core data such as vehicle operating conditions and fault codes in real time. Riders can check vehicle status at any time via voice commands, and the helmet's voice broadcast module provides real-time feedback. It also supports voice control of helmet warning lights and automatic brake light detection, enabling completely touchless voice operation. Riders do not need to take their hands off the handlebars or their eyes off the road, eliminating distraction driving hazards from the source of operation.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology for intelligent cycling equipment, and more specifically, to a cycling system and operation control method that allows centralized voice control of multiple devices via helmet. Background Technology

[0002] With the rapid and large-scale development of same-city instant delivery, daily commuting, and outdoor recreational cycling industries, high-frequency cyclists face complex road conditions, leading to increasingly prominent demands for touchless operation of cycling equipment, real-time vehicle status feedback, proactive safety warnings, and anti-theft and safekeeping of goods. The core demands focus on improving cycling safety, ease of operation, and overall user experience. Simultaneously, operators face challenges such as difficulties in managing dispersed equipment, untimely data synchronization, and delayed anomaly warnings, making centralized equipment management, standardized data reporting, and knowledge base updates extremely urgent. However, existing technologies struggle to simultaneously meet the dual core needs of both cyclists and operators.

[0003] Currently available cycling equipment and publicly available patented technologies generally suffer from the following prominent defects: First, core cycling equipment data is fragmented, lacking collaborative management. Existing smart helmets only have basic functions and struggle to acquire core vehicle operating data; onboard sensors cannot synchronize data to the helmet or backend, failing to form a system architecture with the smart helmet as the centralized control center. Second, there is a lack of a dedicated touchless voice interaction system. Existing devices mostly rely on physical button operation, which can easily distract attention and increase safety hazards while cycling, and the voice solutions are not optimized for wind noise, resulting in limited recognition accuracy. Third, the extended functions of cycling equipment linkage are limited, and the level of intelligence is low. Existing technologies do not cover all types of devices such as smart tailgates and car audio systems, making it impossible to achieve unified voice control and data collaboration across multiple devices. Fourth, backend management capabilities are lacking. Existing solutions mostly focus on single devices or partial linkages, failing to meet the operator's centralized management needs for device status monitoring, anomaly warnings, and knowledge base updates.

[0004] In view of this, the present invention proposes a helmet-mounted voice-controlled riding system and operation control method for multiple devices to solve the above problems. Summary of the Invention

[0005] In order to overcome the above-mentioned defects of the prior art and to achieve the above objectives, the present invention provides the following technical solution: a helmet-mounted voice-controlled multi-device cycling system includes: a smart helmet terminal and at least one external device, wherein the external device includes extended cycling equipment, a mobile terminal and / or a smart vehicle, and the smart helmet terminal serves as the centralized control center of the system for centralized control of the external device through voice commands; The smart helmet terminal and the external device establish a bidirectional data transmission link using at least one of the following communication methods: direct helmet connection transmission, mobile terminal APP relay transmission, background relay transmission, device cascade relay transmission, and multi-path split transmission, in order to realize command issuance and status feedback.

[0006] Furthermore, the extended cycling equipment includes one or more of the following: a vehicle condition acquisition module, a smart tail box, cycling lights, cycling warning devices, vehicle audio equipment, vehicle imaging equipment, a dashcam, a smart dashboard, and a vehicle power supply.

[0007] Furthermore, the smart helmet terminal integrates a voice acquisition module, a local voice command parsing module, a voice broadcasting module, and a data transceiver module, and has built-in local functional hardware; the smart helmet terminal is also optionally configured with an intelligent processing unit for local noise reduction processing.

[0008] Furthermore, the vehicle condition acquisition module includes at least an external independent sensing unit, which is mounted on a non-intelligent cycling vehicle in a purely mechanical manner without electrical connection, and is used to independently collect vehicle operation and status data.

[0009] Furthermore, the vehicle condition acquisition module is also compatible with both in-vehicle OBD plug-in mode and smart vehicle wireless docking mode, making it suitable for various cycling vehicles or smart vehicles.

[0010] Furthermore, the smart tailgate integrates a lock control unit, a temperature control unit, and an anti-theft monitoring unit, which are used to respond to voice commands to lock / unlock, adjust the temperature, and provide abnormal warnings.

[0011] Furthermore, it also includes a backend system, which is used to receive vehicle and peripheral device status data, determine the scene, and send status broadcasts or safety warning information to the smart helmet terminal; the external device can directly connect to the backend system, or connect to the backend system through a mobile terminal APP to realize data reporting and backend management; the mobile terminal APP only serves as a data transmission channel and does not participate in voice recognition and command parsing.

[0012] Furthermore, the back-end system adopts a horizontal collaborative architecture, including an AI cloud platform and optional model training back-end, a general business back-end and its subordinate device management back-end, main business back-end, early warning management back-end, and customer service management back-end; data communication between each back-end or subsystem is achieved through an API gateway, and there is no hierarchical relationship between them.

[0013] Furthermore, the AI ​​cloud platform and optional model training backend are used to receive complex semantic instructions uploaded by the smart helmet terminal, complete deep semantic understanding and intent recognition, and return the parsed user intent to the main business backend; the main business backend is used to complete instruction conversion and collaborative scheduling, and forward the instruction to the corresponding vehicle condition collection module or extended riding device for execution according to the instruction type; the execution result is synchronously fed back to the smart helmet terminal for voice broadcast.

[0014] To achieve the above objectives, the present invention provides the following technical solution: a method for operating a helmet-mounted centralized voice-controlled multi-device riding system, comprising the following steps: Step S1: System initialization and device binding, the smart helmet terminal establishes a communication connection with at least one external device; the connection method is a direct wireless connection, or a relay connection between the mobile terminal APP and the backend. Step S2: Voice acquisition and command recognition. The smart helmet terminal acquires the user's voice commands and performs offline recognition on the helmet itself. Based on the recognition results, local commands are executed directly, while commands requiring backend collaboration are uploaded to the backend for processing. Step S3: Command distribution and device control. The smart helmet terminal generates control commands based on the recognition results, and directly or indirectly controls the external device to perform corresponding operations. Step S4: Status transmission and feedback. After the external device performs the operation, it transmits the execution status or running data back to the smart helmet terminal, which then provides voice feedback.

[0015] The technical effects and advantages of the helmet-mounted centralized voice control system and operation control method for multiple devices are as follows: 1. This invention constructs a collaborative architecture with a smart helmet as the centralized control center, realizing data interconnection and interoperability among core cycling equipment (bike and helmet), and breaking down and expanding data barriers between cycling equipment. The vehicle status acquisition module collects core data such as vehicle operating conditions and fault codes in real time. Riders can check vehicle status at any time via voice commands, and the helmet's voice broadcast module provides real-time feedback. It also supports voice control of helmet warning lights and automatic brake light detection, enabling completely touchless voice operation. Riders do not need to take their hands off the handlebars or look away from the road, eliminating distracted driving hazards from the source. The system has all-time vehicle status monitoring and tiered proactive warning capabilities, covering multiple scenarios such as driving hazards, vehicle theft, and abnormal cargo loading. Combined with active and passive dual emergency assistance (SOS) functions, it can quickly upload assistance information and vehicle location to the backend system, comprehensively ensuring the safety of riders and vehicles. 2. This invention adopts a three-mode compatibility solution: vehicle monitor, onboard OBD plug-in, and wireless docking with smart vehicles. It is compatible with all types of bicycles. The vehicle monitor mode uses a purely mechanical assembly method, which does not require damage to the vehicle body structure or any electrical connection wiring, allowing ordinary non-smart vehicles to quickly achieve intelligent upgrades without modification. The onboard OBD plug-in mode is compatible with smart bicycles with built-in standard OBD data interfaces, which can read the original vehicle's core operating data. The wireless docking mode is compatible with smart vehicles with built-in wireless communication modules, which do not require additional hardware installation. The three modes complement each other to form a complete all-vehicle compatibility system. The entire process does not require complex vehicle body modifications or professional installation operations, making it easy for various users to get started quickly. It meets the needs of both civilian daily commuting and commercial large-scale fleet use, effectively reducing the barriers to equipment implementation and popularization. 3. This invention uses a smart helmet as a centralized control center, dividing the extended cycling equipment into three categories: important optional (vehicle condition data collection module), core optional (smart tail box), and general optional (cycling lights, cycling warning devices, vehicle audio equipment, etc.). It achieves integrated voice control of multiple devices. Through simple and easy-to-use voice commands, all extended cycling equipment can be fully controlled, and the operating status of each device can be monitored in real time. There is no need for manual operation or learning complicated procedures, truly realizing a convenient experience of speaking without lifting a finger. In particular, the smart tail box integrates a lock control execution unit, temperature control adjustment, and anti-theft monitoring functions. It supports voice setting of the internal heating temperature and customizing the warning temperature threshold. It can also ask about the current internal temperature in real time by voice and receive voice reminders when the temperature exceeds the standard. It takes into account the needs of anti-theft, heat preservation, and convenient access, meeting the application needs of daily commuting, outdoor leisure, and instant delivery. 4. A peer-to-peer collaborative back-end management architecture has been constructed, including but not limited to the main business back-end, equipment management back-end, early warning management back-end, customer service management back-end, AI cloud platform, and optional model training back-end. Data communication between the back-ends is achieved through API gateways, with no hierarchical relationship. Rider terminal business and back-end system are efficiently integrated, riders can quickly execute business tasks, and the back-end can conduct macro-control throughout the process, effectively improving work efficiency and business and financial security. The mobile terminal APP serves as an optional data relay node, only responsible for data transmission and system capability calls, and does not participate in voice recognition and command parsing, ensuring the independence and stability of the system's core logic. This back-end architecture has the ability to receive, store, control, and provide early warnings for data from core riding equipment and extended riding equipment, fully meeting the operator's core needs for centralized equipment control, standardized data reporting, and abnormal early warning management. 5. Furthermore, it adopts an innovative architecture featuring centralized helmet control, multi-device collaboration, and a manageable backend, distinguishing it from existing conventional cloud-based voice and single-peripheral linkage technologies. This results in a higher level of intelligence. The system supports various communication methods, including direct transmission, mobile terminal APP relay transmission, device cascading relay transmission, and multi-path distribution transmission. The optimal communication path can be flexibly selected according to different usage scenarios. Basic commands are executed locally on the helmet, ensuring rapid response and independence from network signals. Complex semantic commands undergo deep semantic understanding and intent recognition by the AI ​​cloud platform, and are then coordinated and executed by the overall business backend. Voice interaction is natural and smooth. The dual-radio independent communication architecture physically separates data and audio communication, avoiding scheduling conflicts and improving system concurrency stability. A multi-mode noise reduction adaptation mechanism effectively suppresses wind noise during riding, ensuring accurate voice recognition even at high speeds. The system also supports offline availability, multi-path communication, and multi-device collaboration, making intelligent riding technology truly suitable for daily use and achieving a dual improvement in safety and convenience. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the overall operating architecture of the cycling system of the present invention; Figure 2 This is a schematic diagram of the cycling system architecture of the present invention; Figure 3 This is a schematic diagram of the voice control architecture of the cycling system of the present invention; Figure 4 This is a schematic diagram of the parallel collaborative architecture of the cycling system backend of the present invention; Figure 5 This is a schematic diagram showing the overall communication path of the cycling system of the present invention; Figure 6 This is a schematic diagram of the direct communication path between the helmet and the cycling system of the present invention. Figure 7 This is a schematic diagram of the communication path between the cycling system APP and the present invention. Figure 8 This is a schematic diagram of the relay communication path of the cascaded cycling system of the present invention; Figure 9 This is a schematic diagram of the appearance and interactive components of the smart helmet terminal of the cycling system of the present invention; Figure 10 This is a schematic diagram illustrating the multi-model vehicle condition data collection and adaptation of the cycling system of the present invention; Figure 11 This is a schematic diagram of the vehicle monitor structure of the cycling system of the present invention; Figure 12 This is a schematic diagram of the onboard OBD plug-in structure of the cycling system of the present invention; Figure 13 This is a schematic diagram of the intelligent tail box structure of the cycling system of the present invention; Figure 14This is a schematic diagram of the vehicle equipment assembly of the cycling system of the present invention; Figure 15 This is a schematic diagram of the helmet binding process for the cycling system of the present invention; Figure 16 This is a schematic diagram of the cycling system APP device binding process of the present invention; Figure 17 This is a schematic diagram of the binding process for the cascaded devices in the cycling system of the present invention; Figure 18 This is a schematic diagram of the SOS emergency mechanism of the cycling system of the present invention.

[0017] In the diagram: 1. Smart helmet body; 3. Helmet taillight; 4. Main microphone; 5. Noise-canceling microphone; 6. Speaker; 18. Cycling vehicle; 19. Extended cycling equipment; 20. Smart tail box; 21. Vehicle OBD plug-in; 22. Mobile terminal; 23. Mobile terminal APP; 24. Backend system; 25. AI cloud platform and optional model training backend; 26. Main business backend; 28. AI cloud platform; 29. ​​Optional model training backend; 30. Equipment management backend; 31. Main business backend; 32. Early warning management backend; 33. Customer service management backend; 34. Vehicle monitor; 35. Vehicle condition monitoring module; 36. Positioning module; 37. Data upload module; 38. OBD data reading module; 39. Control execution unit; 40. Wireless communication module; 41. Electronic lock; 42. Temperature control module; 43. Smart vehicle. Detailed Implementation

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

[0019] like Figure 9 As shown in the illustration, this embodiment provides a hardware implementation diagram of a universal smart helmet 1 terminal as the centralized control center of the system. The main body of the smart helmet 1 is equipped with a helmet smart control box, which integrates core components such as the main control chip, local control module, and independent Bluetooth audio module, serving as the voice interaction entry point and command distribution center of this system.

[0020] This embodiment adopts the same collaborative architecture as Embodiment 4: the helmet and the extended cycling device are connected to the backend system 24 through the mobile terminal APP 23, and the device operation data is uploaded to the backend system 24 for unified management through the mobile terminal APP 23; the control commands of the helmet's local functional hardware are directly driven and executed by the main control chip, without relying on the APP or network connection.

[0021] Figure 9 This illustration only shows the appearance of the smart helmet 1 and its user interaction components (main microphone 4, noise-canceling microphone 5, speaker 6, helmet taillight 3), serving as the hardware carrier for the centralized control center of this system. As the centralized control center, the smart helmet 1 should at least possess the capabilities for voice acquisition and playback, local command parsing, data transmission and reception, and multi-mode communication with external devices. Its specific hardware implementation can take many forms; this embodiment only illustrates one preferred implementation as an example and is not intended to limit the invention.

[0022] 1. Configuration of main control and communication modules This embodiment uses the AC7911B chip as the main control processor. This chip integrates BLE low-power Bluetooth and WiFi communication capabilities and is responsible for local voice command parsing, AI intelligent processing, and data transmission and reception coordination.

[0023] 2. Voice Acquisition and Noise Reduction Module Configuration This embodiment uses the built-in noise reduction processing module of AC7911B to achieve voice noise reduction processing in cycling scenarios through software algorithms.

[0024] 3. Local Function Hardware Configuration The local hardware functions of the smart helmet include the helmet taillight 3, wear detection sensors, etc., which are directly driven by the AC7911B locally and do not rely on external devices or network connections. Example 2:

[0025] Optimal communication architecture and noise reduction mechanism for the system: This embodiment provides a system-level optimized solution for the high-speed riding requirements and multi-task concurrent stability requirements of high-frequency instant delivery scenarios. This embodiment focuses on the collaborative application and optimized configuration of the communication and noise reduction capabilities of the smart helmet 1 as a centralized control center at the riding system level. The smart helmet 1 terminal should at least have voice acquisition and playback, local command parsing, data transmission and reception, and multi-mode communication capabilities with external devices. Its specific hardware implementation can take various forms, and this invention is not limited to a specific implementation form.

[0026] 1. Dual-RF independent communication architecture This embodiment adopts a dual-RF independent operating architecture:

[0027] Technical benefits: The main control communication unit ensures the long-term connection keep-alive of the AI ​​cloud platform and real-time upload of BLE data, while the audio communication unit ensures the quality and real-time performance of voice calls. The two are physically separated and work in parallel, avoiding scheduling conflicts caused by the time division multiplexing of the AC7911B single antenna and improving the system's concurrent stability.

[0028] 2. Dual-mode compatible noise reduction mechanism This embodiment employs a multi-mode noise reduction adaptation mechanism in the smart helmet terminal to ensure accurate recognition of voice commands in windy cycling environments. (1) Basic noise reduction processing: It is completed locally by the smart helmet terminal. It adopts a software algorithm and hardware collaboration approach, and makes special optimizations for cycling wind noise scenarios to achieve low-latency noise reduction processing. (2) Optional hardware enhancement: The smart helmet terminal can be equipped with a hardware-level noise reduction enhancement module according to the actual scenario requirements. It works in conjunction with the local noise reduction processing to adapt to different riding speeds and environmental noise conditions.

[0029] (3) Working mode: The noise reduction processing module and the optional hardware noise reduction enhancement module can operate independently or work together.

[0030] (4) Key Definitions: The specific noise reduction implementation method is configured autonomously by the smart helmet terminal. The optional hardware noise reduction enhancement module is an optional additional technical feature and is not a necessary technical feature of this system. Regardless of the noise reduction configuration adopted, local command parsing and local hardware control are executed offline on the helmet terminal and do not affect the core control process of this system.

[0031] 3. Offline execution capability of local functional hardware In this embodiment, the following functions do not rely on the mobile terminal APP23 or network connection, but are executed directly by the AC7911B local driver:

[0032] The offline execution capability of the aforementioned local functions ensures that the basic security functions can still be used normally in scenarios with weak network, network outage, or abnormal mobile phone. Example 3:

[0033] Backend system architecture: This embodiment provides two implementation methods for the backend system. Method A: Physically independent deployment (parallel microservice architecture)

[0034] like Figure 4 As shown in Method A, the main business backend 31, equipment management backend 30, early warning management backend 32, customer service management backend 33, AI cloud platform 28, and optional model training backend 29 are deployed as independent microservices. Data communication between the backends is achieved through a standard API gateway, with no hierarchical relationship.

[0035] Method B: Logical horizontal integration (subsystem architecture) like Figure 4 As shown in Method B, the device management backend 30, the early warning management backend 32, and the customer service management backend 33 are integrated as functional subsystems into the existing business backend 26 (such as the food delivery APP backend). The AI ​​cloud platform 28 and the optional model training backend 29 are integrated through interface docking with a third-party AI capability platform (such as AIUI).

[0036] Key definition Regardless of whether method A or method B is used, all backend / subsystems maintain a peer-to-peer collaborative relationship at the functional logic level, that is: (1) Each backend / subsystem can independently receive data uploaded by the smart helmet 1; (2) Each backend / subsystem can independently send instructions or warnings to the smart helmet 1; (3) There is no single central node for overall scheduling, and the data flow is a many-to-many network structure. Example 4:

[0037] System integration in on-demand delivery scenarios This embodiment uses a same-city instant delivery service scenario as an example to illustrate a preferred system deployment scheme. This embodiment corresponds to the preferred system communication architecture of Embodiment 2 and Method B of Embodiment 3.

[0038] 1. System Deployment Architecture (1) Smart Helmet The preferred implementation method of Embodiment 2 is adopted: AC7911B (main control communication unit) + independent Bluetooth audio module (audio communication unit) + optional hardware noise reduction enhancement unit. For the high-speed riding characteristics of on-demand delivery scenarios, this embodiment enables a multi-mode noise reduction adaptation mechanism.

[0039] (2) Expand cycling equipment Vehicle condition acquisition module (on-board OBD plug-in 21): Adopting the on-board OBD plug-in 21 mode, the core components include OBD data reading module 38, sensor module (six-axis acceleration + Beidou dual-frequency positioning), and data upload module 37.

[0040] Smart tailgate 20: such as Figure 13 As shown, it integrates a lock control execution unit (electronic lock 41 + structural lock), a temperature control adjustment unit (temperature control module 42), a status display unit, and a Bluetooth master control module.

[0041] (3) Backend system (Method B: Subsystem architecture)

[0042] (4) Mobile terminal APP (data relay node) It runs on the delivery person's smartphone (in the case of instant delivery, it can be specifically implemented as a food delivery APP), and is responsible for device binding, data transfer, and system capability calling functions, but does not participate in core processing such as voice recognition and command parsing.

[0043] 2. Implementation of core control methods (1) Step S1: System initialization and device binding A unified binding mode using a mobile terminal APP (23) as a transit point is adopted: Helmet binding: BLE binding (data channel) → WiFi information transmission (AI semantic channel) → BT binding (audio channel); External device binding: The smart tailgate 20 and the vehicle OBD plug-in 21 are bound to the mobile terminal APP 23 respectively, and the binding relationship is synchronized to the device management sub-backend 30.

[0044] (2) Step S2: Layered processing of voice commands (Note: The APP in the table below refers to the mobile terminal APP23)

[0045] Key design: L1 / L2 layer instructions are completely localized and do not depend on mobile terminal APP23, background or network connection.

[0046] (3) Step S3: Data acquisition and synchronization of all equipment During system operation, all data is continuously synchronized via the path "Device → App → Backend": Smart helmet data includes voice commands, wearing status (if equipped with a wearing detection module), movement posture (if equipped with a posture recognition module), location information (if equipped with a positioning module 36), battery information, etc. Vehicle condition acquisition module (OBD plug-in 21) data: including vehicle speed, motor speed, voltage / battery level, fault codes, charging status, tipping events, collision events, location information, etc.; Smart tailgate data includes tailgate lock status, temperature / humidity, voltage / battery level, charging status, etc.

[0047] After preprocessing, all collected data is uploaded to the backend system 24 via mobile terminal APP23 for unified storage and management, providing data support for backend control and intelligent early warning.

[0048] (4) Step S4: Back-end horizontal collaborative management The backend system, with its 24 / 7 collaborative architecture, receives all data uploaded from various devices in real time, completing data cleaning, classification, aggregation, and hazardous scenario assessment, distinguishing between two types of logic: proactive query response and automatic early warning trigger. Proactive query scenario: Delivery personnel initiate queries via voice commands (such as "Is my vehicle malfunctioning?" "What is the temperature in the trunk?"). The back-end system quickly retrieves the corresponding vehicle condition information, equipment operating status, trunk temperature control, and other data, and provides real-time feedback via voice broadcast through the mobile terminal APP 23 → smart helmet 1.

[0049] Automatic warning scenario: The back-end system 24 continuously compares vehicle operating parameters, equipment working indicators, tail box temperature control and other data and preset warning thresholds (such as battery <20%, temperature exceeding preset threshold, vehicle tipping, etc.). When the relevant indicators reach the predetermined threshold, the rider does not need to actively initiate the command. The warning management back-end (32) actively pushes the graded warning information to the smart helmet 1, and the helmet automatically completes the voice reminder. At the same time, the back-end records abnormal data to provide the operator with equipment status monitoring and warning management basis.

[0050] (5) Step S5: SOS emergency mechanism like Figure 18 As shown, it supports both active and automatic triggering modes: Active Trigger Mode: When a user encounters danger or needs help, they can actively issue an SOS voice command. The smart helmet 1 will ask the user, "Are you sure there is danger?" If the user replies that they are sure there is a risk, the SOS will take effect immediately; if the user replies that they are not sure there is a risk, the SOS will automatically deactivate; if the smart helmet 1 asks three times in a row (within 30 seconds) and the user does not respond, the SOS will automatically take effect.

[0051] Automatic Trigger Mode: When the system comprehensively judges that there is a risk to the rider or vehicle (such as detecting vehicle tipping or collision through the six-axis inertial sensor, or detecting abnormal vehicle status through OBD plug-in 21), the SOS system reminder mechanism is automatically triggered (same as the active trigger mode above).

[0052] SOS cancellation mechanism: Users can cancel SOS via voice command. The system will ask a voice confirmation, "Are you sure you want to cancel SOS?" If the user replies "yes," the SOS will be canceled immediately; otherwise, the SOS will remain in effect. The background system can be configured to send multiple reminders within 24 hours.

[0053] After the SOS is activated: quickly upload the help request information and vehicle location to the backend system 24, and the backend system 24 will activate the emergency mechanism (such as notifying the emergency contact person, contacting the operator, etc.).

[0054] (6) Step S6: Smart helmet wearing detection and smart tailgate coordination Smart helmet wearing detection: A triple-fusion wearing detection system is used, employing a six-axis inertial sensor (including a three-axis accelerometer and a three-axis gyroscope), a capacitive sensor, and an infrared sensor. The six-axis inertial sensor detects the wearing direction and motion posture, the capacitive sensor detects the contact state with the human body, and the infrared sensor detects human proximity signals. By fusing data from these three sensors, the wearing status is comprehensively determined, categorized into three outcomes: properly worn, incorrectly worn, and not worn.

[0055] Smart tailgate 20 control: near field detection → voice command → switch to BLE direct connection control → electronic lock 41 unlock → manual unlocking mechanism lock.

[0056] (7) Step S7: Intelligent Power Management

[0057] 3. Verification of typical business scenarios Scenario: Nighttime delivery at relatively high speeds, the delivery person is riding at a speed of 45km / h: (1) Voice prompt: "Navigate to the next order" The smart helmet 1 uses a noise reduction processing module and an optional hardware noise reduction enhancement module to work together to effectively suppress wind noise while riding, accurately recognize voice commands, and launch navigation applications.

[0058] (2) Before turning left, the voice prompt will say "Turn on your left turn signal". The local hardware control layer commands are recognized locally by the main control chip and then directly drive the helmet taillight 3 to perform the left turn signal operation through GPIO. The response time is less than 100ms, and it does not rely on the network or mobile terminal APP 23.

[0059] (3) Taillights are bright when braking. When the six-axis inertial sensor of the smart helmet detects that the deceleration exceeds a preset threshold, the system automatically triggers a high-brightness warning light on the smart helmet's taillights to alert vehicles behind to take evasive action.

[0060] (4) Both hands remained on the handlebars throughout the entire process, and the eyes did not stray from the road surface.

[0061] (5) After arriving at the destination, park the car and say "Open the trunk" via voice prompt. Upon receiving a command from the external device control layer and local recognition by the smart helmet 1, a near-field determination is first performed (confirming that the helmet, mobile terminal APP 23, and tail box are all within Bluetooth connection range). If the determination is successful, the helmet can be unlocked using one of the following methods: BLE direct connection control: The helmet directly sends an unlocking command to the smart tail box 20. After the electronic lock 41 is unlocked, the structural lock is manually opened. APP connection method: The helmet sends the unlocking command to the mobile terminal APP23 via Bluetooth, and the mobile terminal APP23 forwards it to the smart tail box 20 via Bluetooth to execute the unlocking. The command transmission can be completed locally via Bluetooth and does not rely on the cellular network. Mechanical unlocking: In case of system malfunction (such as helmet damage or phone battery failure), mechanical unlocking with a key can be used as a backup method.

[0062] Example 5

[0063] Communication path This embodiment combines Figures 5-8 The system provides a detailed description of the various communication paths it supports.

[0064] 1. Overview of Communication Paths ( Figure 5 ) like Figure 5 As shown, this system supports four communication paths: direct helmet connection, APP relay, background relay, and cascading relay. Each path can run independently or be used in combination to form a flexible system communication topology.

[0065] 2. Helmet direct communication path ( Figure 6 ) like Figure 6 As shown, the smart helmet 1 establishes a data interaction channel directly with the extended riding device 19 (including the smart tail box 20 and the vehicle OBD plug-in 21) via BLE, and at the same time establishes an audio channel with the mobile terminal 22 via BT, and establishes a network channel with the back-end system 24 via cellular / WiFi.

[0066] This approach is applicable to scenarios where the extended cycling device 19 has BLE communication capabilities and is within Bluetooth range of the helmet.

[0067] 3. APP relay communication path ( Figure 7 ) like Figure 7 As shown, the smart helmet 1 connects to the mobile terminal APP 23 via BLE / BT, and the mobile terminal APP 23 connects to the extended cycling device 19 via BLE, while also connecting to the backend system 24 via cellular / WiFi. The backend system 24 includes an AI cloud platform and optional model training backend 25 and general business backend 26.

[0068] This path is suitable for scenarios where mobile terminal APP23 is required to participate in device management, data transfer, or business collaboration.

[0069] 4. Communication path for cascaded devices ( Figure 8 ) like Figure 8As shown, the vehicle-mounted OBD plug-in 21 is used as an example of a cascaded device: the OBD plug-in 21 has a built-in BLE communication unit and network communication module, which connects to the smart helmet 1 through BLE and to the backend system 24 through the network; at the same time, the OBD plug-in 21 connects to the smart tail box 20 through BLE to realize the cascade transfer of data from the tail box 20.

[0070] This path is applicable to scenarios where an extended cycling device 19 has multi-mode communication capabilities and can serve as a data aggregation or relay node.

[0071] Example 6

[0072] Device binding process This embodiment combines Figures 14-17 The system provides an explanation of the device binding process it supports.

[0073] 1. Vehicle equipment assembly ( Figure 14 ) like Figure 14 As shown, the bicycle 18 serves as the system carrier, providing an OBD interface and a tail box mounting position. The vehicle monitor 34 is fixed to the inside or outside of the vehicle body using a purely mechanical assembly method; the on-board OBD plug-in 21 connects to the vehicle via an OBD plug-in; and the smart tail box 20 is fixed to the vehicle through structural assembly.

[0074] 2. Helmet binding process ( Figure 15 ) like Figure 15 As shown, the active binding process centered on smart helmet 1: (1) Press and hold the pairing button on the smart helmet 1 to enter pairing mode (indicator light flashes). (2) Press and hold the pairing buttons of the vehicle monitor 34, the vehicle OBD plug-in 21, and the smart tailgate 20 in sequence to enter their respective pairing modes; (3) If both indicator lights on the devices are off, it means the binding is successful; (4) Turn on Bluetooth on mobile terminal 22, search for smart helmet 1 to pair, and the pairing interface will indicate that the pairing is successful; (5) The binding relationship is synchronized to the device management backend 30.

[0075] 3. APP device binding process ( Figure 16 ) like Figure 16 As shown, the unified binding process uses mobile terminal APP23 as an intermediary: (1) Open the mobile terminal APP23 and enter the device binding interface; (2) Press and hold the helmet pairing button to enter pairing mode; (3) The mobile terminal APP23 is bound to the helmet BLE and transmits WiFi information; (4) The mobile terminal APP23 prompts "Helmet binding successful"; (5) The mobile terminal APP23 binding interface loads the external device binding option; (6) Press and hold the trunk / OBD plug pairing button to enter pairing mode; (7) The mobile terminal APP23 prompts that the corresponding device binding is successful; (8) The binding relationship is synchronized to the device management backend 30.

[0076] 4. Cascading device binding process ( Figure 17 ) like Figure 17 The binding process, with the vehicle OBD plugin 21 as the cascading center, is shown below: (1) Press and hold the pairing button on vehicle OBD plugin 21 to enter pairing mode; (2) Press and hold the pairing buttons on the vehicle monitor 34, smart tail box 20 and smart helmet 1 in sequence to enter their respective pairing modes; (3) If both indicator lights on the devices are off, it means the binding is successful; (4) Turn on Bluetooth on mobile terminal 22 and search for smart helmet 1 to pair; (5) The binding relationship is synchronized to the device management backend 30.

[0077] Example 7

[0078] Description of Alternative Implementation Methods To demonstrate the flexibility of the technical solution of this invention, several alternative embodiments are provided below:

[0079] The above embodiments demonstrate that the helmet-based centralized control multi-device voice interaction system of the present invention can be implemented in various specific ways, and all implementation methods fall within the protection scope of the claims. The instant delivery scenario solution described in Embodiment 4 is a preferred implementation method. The dual-radio frequency independent communication architecture and multi-mode noise reduction adaptation mechanism described in the preferred implementation method of Embodiment 2 are optimized implementations for high-speed scenarios, but should not be construed as limiting the protection scope of the present invention.

[0080] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0081] In the several embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only one method, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0082] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

[0083] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A helmet-mounted voice-controlled riding system for multiple devices, characterized in that, The helmet-mounted voice-controlled multi-device cycling system includes: a smart helmet terminal and at least one external device, the external device including extended cycling equipment, a mobile terminal and / or a smart vehicle, the smart helmet terminal serving as the centralized control center of the system, used to centrally control the external device through voice commands; The smart helmet terminal and the external device establish a bidirectional data transmission link using at least one of the following communication methods: direct helmet connection transmission, mobile terminal APP relay transmission, background relay transmission, device cascade relay transmission, and multi-path split transmission, in order to realize command issuance and status feedback.

2. The helmet-mounted centralized voice control system for multiple devices as described in claim 1, characterized in that, The extended cycling equipment includes one or more of the following: vehicle condition acquisition module, smart tail box, cycling lights, cycling warning device, vehicle audio equipment, vehicle imaging equipment, dashcam, smart dashboard, and vehicle power supply.

3. A helmet-mounted centralized voice control system for multiple devices as described in claim 2, characterized in that, The smart helmet terminal integrates a voice acquisition module, a local voice command parsing module, a voice broadcasting module, and a data transceiver module, and has built-in local functional hardware; the smart helmet terminal is also optionally configured with an intelligent processing unit for local noise reduction processing.

4. The helmet-mounted centralized voice control system and operation control method for multiple devices as described in claim 3, characterized in that, The vehicle condition acquisition module includes at least an external independent sensing unit. The external independent sensing unit is mounted on a non-intelligent cycling vehicle in a purely mechanical manner without electrical connection, and is used to independently collect vehicle operation and status data.

5. A helmet-mounted centralized voice control system for multiple devices as described in claim 4, characterized in that, The vehicle condition acquisition module is also compatible with in-vehicle OBD plug-in mode and smart vehicle wireless docking mode, and can be used to adapt to various cycling vehicles or smart vehicles.

6. A helmet-mounted centralized voice control system for multiple devices as described in claim 5, characterized in that, The intelligent tailgate integrates a lock control unit, a temperature control unit, and an anti-theft monitoring unit, which are used to respond to voice commands to lock / unlock, adjust the temperature, and provide abnormal warnings.

7. A helmet-mounted centralized voice control system for multiple devices as described in claim 6, characterized in that, It also includes a backend system, which is used to receive vehicle and peripheral status data, determine the scene, and send status broadcasts or safety warning information to the smart helmet terminal; the external device can directly connect to the backend system, or connect to the backend system through a mobile terminal APP to realize data reporting and backend management; the mobile terminal APP only serves as a data transmission channel and does not participate in voice recognition and command parsing.

8. A helmet-mounted centralized voice control system for multiple devices as described in claim 7, characterized in that, The back-end system adopts a horizontal collaborative architecture, including an AI cloud platform and an optional model training back-end, a general business back-end and its subordinate device management back-end, main business back-end, early warning management back-end, and customer service management back-end; data communication between each back-end or subsystem is achieved through an API gateway, and there is no hierarchical relationship between them.

9. A helmet-mounted centralized voice control system for multiple devices and its operation control method according to claim 8, characterized in that, The AI ​​cloud platform and optional model training backend are used to receive complex semantic instructions uploaded by the smart helmet terminal, complete deep semantic understanding and intent recognition, and return the parsed user intent to the main business backend; the main business backend is used to complete instruction conversion and collaborative scheduling, and forward the instruction to the corresponding vehicle condition collection module or extended riding device for execution according to the instruction type; the execution result is synchronously fed back to the smart helmet terminal for voice broadcast.

10. A method for operating a helmet-mounted centralized voice-controlled multi-device riding system according to any one of claims 1 to 9, characterized in that, Includes the following steps: Step S1: System initialization and device binding, the smart helmet terminal establishes a communication connection with at least one external device; the connection method is a direct wireless connection, or a relay connection between the mobile terminal APP and the backend. Step S2: Voice acquisition and command recognition. The smart helmet terminal acquires the user's voice commands and performs offline recognition on the helmet itself. Based on the recognition results, local commands are executed directly, while commands requiring backend collaboration are uploaded to the backend for processing. Step S3: Command distribution and device control. The smart helmet terminal generates control commands based on the recognition results, and directly or indirectly controls the external device to perform corresponding operations. Step S4: Status transmission and feedback. After the external device performs the operation, it transmits the execution status or running data back to the smart helmet terminal, which then provides voice feedback.

Images