Multi-mode beacon light and third-party signal light control system based on automatic control

Abstract

The invention discloses a multi-mode beacon light and third-party signal light control system based on automatic control. Comprising a cover, clothes, a rain gear, a helmet and the like which are used as personnel wearing parts, a bicycle, an electric bicycle and the like which are used as mobile carriers, and an STM32 main control template, a signal acquisition module, a serial port communication module, a light-emitting unit driving module and a third-party signal lamp driving module which are used as core control assemblies. The reverse control of synchronous linkage of the beacon light is triggered, the serial port communication module receives an instruction of the peripheral module, and the forward control of starting and stopping of the beacon light and a riding signal lamp is controlled, so that automatic linkage and external active control between the beacon light of the wearable part and the third-party signal lamp are realized. The system solves the problems of shielding of a riding signal lamp, single control mode and the like, has the characteristics of forward and reverse linkage, high scene adaptability and real-time response, and can be widely applied to riding scenes such as daily commuting, travel on rainy days, professional competition and the like.

Description

Technical Field

[0001] This invention relates to the field of intelligent device technology, specifically to a control system for multi-mode beacon lights and third-party traffic lights based on automatic control. Background Technology

[0002] In urban short-distance travel and commuting scenarios, bicycles, electric bicycles, and other ride-on mobile vehicles are widely used due to their convenience and low energy consumption. To improve riding safety, these bicycles are usually equipped with turn signals, brake lights, and other signal lights to convey key information such as turning and slowing down to surrounding road users. However, in actual use, these bicycle signal lights often suffer from insufficient signal display and poor usage standardization.

[0003] On the one hand, when riding in the rain, commuting at night, or in low-visibility environments, cyclists usually wear protective clothing such as raincoats and jackets. The structure of such clothing can easily obstruct the turn signals at the rear or side of the vehicle, making it difficult to transmit turn or brake signals that should be clearly visible to traffic participants behind or to the side in a timely manner, thereby increasing the risk of rear-end collisions or collisions. At the same time, bicycle turn signals are prone to getting dirty and damaged after long-term use, which further exacerbates the risk of signal transmission failure, especially in complex road conditions, which can easily lead to traffic accidents. On the other hand, in daily travel, some users fail to turn on their turn signals in time, keep them on for a long time, or operate them incorrectly, which makes the bicycle's original signal lights unable to accurately reflect the true driving intentions and reduces the effectiveness of the signal lights as a safety warning device.

[0004] Current solutions for improving cycling safety mainly focus on adding or modifying the signal light structure on the vehicle itself, such as increasing the size of the light body, increasing the brightness, and adopting different flashing modes; some solutions also involve adding independent warning lights to helmets, backpacks and other wearable devices to enhance the rider's visibility.

[0005] However, its control mode is simple and lacks flexibility. Specifically, it relies on the rider to manually start and stop, lacking an automated linkage mechanism. Some auxiliary warning lights (such as externally attached lights) can only be constantly lit or flash at a fixed frequency, and cannot be synchronized with the bike's original signal lights. They also do not support flexible external control, making it difficult to adapt to diverse scenarios such as daily commuting, rainy weather travel, and professional competitions.

[0006] Furthermore, the existing technology lacks a unified control core, making it impossible to achieve reverse linkage between "signal light status → auxiliary device", and it also lacks the forward control capability between "external command → signal light + auxiliary device". At the same time, when there are automatic detection signals and external control commands, control conflicts are prone to occur, and there is no clear priority mechanism, resulting in chaotic system response.

[0007] Meanwhile, in certain professional cycling events or group riding scenarios, a higher level of signal expression capability is often required. For example, the lights need to be uniformly controlled according to the race rules, route planning, or lead rider instructions. Ordinary cycling signal light systems are difficult to achieve stable and real-time interaction with external devices (such as mobile phones, navigation terminals, or race control systems), and cannot meet the above-mentioned complex application requirements.

[0008] Furthermore, in real-world urban cycling environments, road conditions are complex and varied, and unexpected situations are highly random. These include emergency pedestrian avoidance, sudden obstacle encounters, temporary lane changes, and equipment malfunctions causing stops, often exceeding the processing range of preset algorithms or navigation logic. In such scenarios, cyclists typically need to rely on their own judgment to manually intervene with the traffic lights on the mobile vehicle to quickly and clearly convey their immediate driving intentions to surrounding road users. However, in these emergency manual intervention scenarios, cyclists' attention is highly focused on the avoidance maneuver itself, and they usually lack sufficient time or operational conditions to actively interrupt the communication connection between the peripheral module and the traffic light control system, such as turning off navigation, disconnecting Bluetooth, or stopping data services. Therefore, even if cyclists have changed the state of a third-party traffic light through physical buttons or onboard operations, the peripheral module may still continuously send automated commands to the control system via serial communication. Currently, existing cycling traffic light control systems only consider a single control source or employ simple "peripheral priority" or "human priority" logic, lacking a sophisticated mechanism to handle the conflict between "continuous output of automatic peripheral commands" and "real-time human operation signals." When both exist simultaneously and the instructions are inconsistent, it can easily lead to frequent switching of traffic lights, response delays, or discrepancies between the displayed status and the rider's true intentions. It may even transmit incorrect driving signals to the outside world in a short period of time, thereby causing secondary safety hazards. Especially when serial communication is in continuous operation, there is still a lack of mature and reliable engineering implementation methods for distinguishing between external automatic instructions and real signal changes caused by manual operation, and for achieving smooth switching when the two tend to be consistent or separate again in a short period of time.

[0009] To address this, a control system is proposed that enables automatic linkage between wearable beacon lights and third-party traffic lights without altering or making minor modifications to the original traffic light structure of the bicycle, and supports active intervention from external devices. This system aims to solve the technical problems of existing bicycle traffic lights in terms of obstruction, insufficient linkage, and control conflicts. Summary of the Invention

[0010] The purpose of this invention is to provide a control system for multi-mode beacon lights and third-party traffic lights based on automatic control, so as to solve the problems mentioned in the background art.

[0011] To achieve the above objectives, the present invention provides the following technical solution: a control system for multi-mode beacon lights and third-party signal lights based on automatic control, comprising a wearable device for personnel and a mobile carrier independent of the wearable device, capable of carrying people and moving. The mobile carrier carries the third-party signal lights. The wearable device integrates at least a light-emitting unit, and may also integrate a sound-emitting component to form a sound-light unit. Moreover, the mobile carrier is not limited to electric vehicles, motorcycles, or other vehicles with active power units, but can also be used on auxiliary power mobile carriers such as bicycles. It should be noted that "third party" here is only a nominal designation and does not indicate a unit with three or more control modes. The light-emitting unit can trigger linkage actions according to the operating status changes of third-party traffic lights. At the same time, the light-emitting unit supports receiving control commands from peripheral modules to execute preset working modes. That is, the wearable device can synchronize the status of the relevant traffic lights on the mobile carrier, and can also be flexibly controlled by peripheral modules, which can be computers, mobile phones or other network facilities. The preset working modes include not only the usual methods based on pre-set navigation or riding habits, but also real-time traffic condition judgments connected to big data. For example, based on the current traffic scene, intelligent judgment can be made, and the rider should actively brake or turn to make corresponding light changes.

[0012] Preferably, the wearable device includes one or more combinations of covers, clothing, rain gear, shoes, and hats. It can be shoes, hats, and trousers worn for daily travel, or raincoats, umbrellas, etc. used for wind and rain protection. In addition to regular travel activities, it can also be used in professional competitions, such as in cycling competitions, with the use of special helmets, cycling shoes, etc. The cover can be rain gear to protect the cycling vehicle.

[0013] Specifically, depending on the actual situation, the wearable device is equipped with one or more light-emitting units, including one that can be used as a cruise / brake warning, multiple indicator lights that can be attached to the driving direction, and each light-emitting unit includes at least one or more colors and a number of beacon lights greater than or equal to one. Different states can be distinguished by different colors, and different warning patterns can be formed by increasing the number of lights.

[0014] Preferably, the system includes a main control module, a signal acquisition module, a serial communication module, and a light-emitting unit driving module. The main control module is electrically connected to the signal acquisition module, the serial communication module, and the light-emitting unit driving module. The main control module communicates with the peripheral module through the serial communication module, and the signal acquisition module acquires the status data of the third-party traffic lights and feeds it back to the main control module.

[0015] The main control module, as the core control unit, is responsible for the unified scheduling of signal acquisition, communication, and light-emitting control tasks. The signal acquisition module is used to detect the working status of third-party traffic lights in real time or periodically, ensuring that the system can perceive the status of third-party traffic lights and display them synchronously to meet the needs of actual use. The serial communication module is used to realize data interaction between the main control module and peripheral modules to support external control commands or parameter configuration. The light-emitting unit driver module is used to convert the control commands of the main control module into actual driving signals for the light-emitting units, thereby realizing multi-mode display of the beacon lights.

[0016] Preferably, the system further includes a third-party traffic light driver module, and the main control module communicates with the third-party traffic light driver. By setting the third-party traffic light driver module, the main control module can not only obtain the status information of the third-party traffic light, but also directly control the third-party traffic light when necessary, thereby forming a two-way management capability for the third-party traffic light and enhancing the linkage and control flexibility of the system in complex application scenarios. The specific communication method can be a wired connection or wireless (Bluetooth, RFID, etc.) data interaction. It should be noted that the third-party traffic light driver module can be directly intervened by connecting to the circuit of the third-party traffic light on the mobile carrier through a physical cable, or it can be controlled wirelessly. Of course, for wireless control, the third-party traffic light itself is required to have a corresponding wireless control module.

[0017] Preferably, the main control module executes commands to the light-emitting unit driving module based on the data fed back by the serial communication module and the signal acquisition module, and the data from the serial communication module has a higher priority than that from the signal acquisition module. By setting priorities for different data sources, when the system receives communication data from peripheral modules and feedback data from the signal acquisition module at the same time, it can prioritize responding to control commands issued by humans or external systems, thereby avoiding control conflicts and improving the system's response reliability in emergency or remote control scenarios.

[0018] Preferably, the main control module can use the STM32F103 series chip, which is cost-effective and has sufficient computing and storage capabilities. The serial communication module is a USART1 module that connects PA9 and PA10 of the main control module and is used to receive communication data from the peripheral module. Each light-emitting unit contains at least one light, and can also be a group of multiple common-pole indicator lights, or multiple groups of indicator lights. The indicator lights in a group are common-pole (the color is not limited and can be configured according to the actual situation). This can achieve multiple light-emitting states while ensuring structural simplification. The signal acquisition module communicates with the main control module through a DMA channel.

[0019] The control logic of a control system for a multi-mode beacon light and third-party traffic light based on automatic control includes the following operation process: dividing the system operation process so that the system has a clear execution path under power-on, initialization, standby and different triggering conditions. M0, System power-on. M001, Initialization, M002, the main control module is in standby mode. The signal acquisition module continuously acquires status data. Serial communication module standby state; M1, signal acquisition module triggered operation M101, the signal acquisition module, works continuously to acquire and assign the status of various third-party traffic lights, and then transfer them to the buffer array via the DMA channel. M102. Determine the value of the priority parameter adc_enable. If adc_enable=1, the main control module controls the status of the light-emitting unit through the light-emitting unit driver module. M2, serial communication module triggers operation The M201 serial communication module receives data from peripheral modules and assigns data values. M202: The main control module controls the state of the light-emitting unit through the light-emitting unit driver module according to the assigned value. M203: The main control module controls the status of the third-party traffic lights through the third-party traffic light driver module based on the assigned values. M204. Modify the priority parameter adc_enable to set adc_enable=0. Steps M1 and M2 are parallel steps with no specific order. After steps M1 and M2 are executed, the process jumps to step M002. By setting the parallel steps M1 and M2, it is ensured that signal acquisition and peripheral communication do not block each other. At the same time, combined with the priority parameter adc_enable, dynamic switching between different control sources is achieved.

[0020] Preferably, the initialization in step M001 includes at least: turning off all third-party semaphores, which allows the system to be in a recognizable and safe default state at startup. During the initialization process in step M001, adc_enable is set to 1 to ensure that the system prioritizes control based on the data from the acquisition module in the initial stage, thus avoiding accidental triggering of peripheral commands.

[0021] Preferably, in step M2, the value assigned is blink_flag, and the parameter of blink_flag includes a reset value. If the value assigned is a reset value, then adc_enable is assigned the value 1. By introducing blink_flag and its reset value judgment mechanism, the system can quickly exit the current control state and restore the automatic control mode based on the acquisition module when it receives a specific reset command, thereby improving the system's fault tolerance in abnormal or erroneous situations.

[0022] Preferably, the main control module sets and updates the reference parameter flag, and assigns a value of 0 or 1. After the acquisition module completes the acquisition, it assigns the value of falg to 1 through the HAL_ADC_ConvCpltCallback callback function. After the main control module accesses the cache array, it assigns the value 0 to falg.

[0023] By setting the flag parameter and combining it with a callback function, the update status of the collected data can be effectively identified. The main control module can then determine whether the data in the cache array needs to be updated, thereby improving the reliability and consistency of the control logic and increasing efficiency.

[0024] Preferably, riders may encounter special situations while cycling that cannot be handled using the preset operating mode. In such cases, riders may manually change third-party traffic lights on the mobile device according to their needs. However, they may not be able to promptly stop the communication connection between the serial communication module and the peripheral module, thus halting the peripheral module's data intervention (e.g., in an emergency where there is no time to stop navigation or change the route). To address this situation, the following logical control process is proposed. It should be noted that this logical process is predicated on the system currently being in serial data reception mode. The following steps are also included when the system is in the state where the serial communication module is triggered to work: MB1 and DMA channels are configured with a ring buffer mode to provide a data foundation for continuous acquisition. Generally, two areas (two cells) can be set up to store two adjacent data entries. MB2, the signal acquisition module continuously acquires data and transfers it via the DMA channel. MB3, the main control module compares two consecutive data transfers from the DMA channel. MB31: If the data is the same or does not exceed the threshold, then proceed according to step M2, where the serial communication module is triggered and runs. This step is interrupted, and the system continues to run according to the data instructions from the serial communication module. Of course, the specific threshold can be set according to the actual situation; for example, the illumination of taillights or driving lights may not be used as the sole criterion. MB32. If the data change exceeds the threshold, the main control module will control the state of the light-emitting unit based on the changed data, meaning that the operator's actions are still the primary factor. The MB321 main control module compares the changed data with the data received from the peripheral module by the current serial communication module, in order to compare the constantly changing data from the previous serial communication module. If the MB3211 is the same, the status control of the light-emitting unit is performed according to the data received from the peripheral module by the current serial communication module, and this step ends upon interruption. MB3211, if different, the main control module controls the status of the light-emitting unit according to the changed data, issues a warning, and loops back to step MB1, that is, it runs in a loop.

[0025] Compared with existing technologies, the beneficial effects of this invention are as follows: By integrating a light-emitting unit into the wearable device and establishing a linkage relationship with a third-party signal light on the mobile carrier, the signal display position is extended from the vehicle body to the outside of the rider's body. This effectively avoids the problem of rain gear, clothing, mud, etc., obstructing the vehicle's signal lights and improves the visibility of key signals such as steering and braking in the actual riding environment. The system introduces a signal acquisition module to detect the working status of the third-party signal light in real time or periodically, enabling the beacon light on the wearable device to automatically and synchronously display the corresponding signal status. This achieves "reverse linkage" display of riding signals without additional user operation, reducing the probability of misoperation. Furthermore, by setting up a serial communication module and communicating with peripheral modules, the system supports external devices to actively control the beacon light and third-party signal lights, forming a "forward control" path. This allows the system to not only passively respond to the vehicle's signal light status but also actively express riding intentions according to external commands, significantly improving the flexibility of use.

[0026] Furthermore, this system adopts a dual-mode control mechanism based on priority parameters, which allows manual or system commands issued by peripheral modules to take precedence over automatic acquisition logic when necessary, effectively avoiding conflicts between different control sources and improving the system's response reliability in emergency or complex scenarios.

[0027] This application continuously samples the status of third-party traffic lights and utilizes a DMA ring buffer and a data difference judgment mechanism. This allows the system to quickly identify real signal changes caused by manual operation by the cyclist without interrupting serial communication. This avoids external automatic commands overriding manual decisions, ensuring that critical signals such as emergency braking and temporary lane changes are expressed preferentially and accurately. Furthermore, it introduces comparison logic between the collected data and serial port data. When inconsistencies are detected, the system automatically switches its working data source and triggers corresponding warning or prompt mechanisms. This effectively prevents traffic lights from flashing incorrectly, erroneously, or switching frequently due to command conflicts, reducing the risk of incorrect safety warnings during riding. Simultaneously, by employing a continuous ADC conversion mode, a DMA ring buffer, and flag-driven control logic, the system can complete signal change detection and decision-making without frequently consuming CPU resources. This allows the main control module to complete control tasks with low power consumption and short response time, meeting the real-time requirements of riding scenarios.

[0028] In addition, this application system can be shaped into various forms such as a cover, clothing, rain gear, helmet, and cycling shoes, making it suitable for scenarios such as rainy day travel (raincoat integration), nighttime commuting (clothing integration), and professional competitions (helmet integration). The mobile carrier is compatible with bicycles, electric bicycles, and other auxiliary or active power carriers. Through the combination design of multiple colors and quantities of beacon lights, it can realize multiple warning or display modes. With the help of peripheral modules supported by the system (such as GPS-equipped mobile phones), it can issue turning commands through pre-planned routes to achieve intelligent automatic control. The serial communication module is compatible with multiple communication methods such as Bluetooth and network, which facilitates access to intelligent transportation systems. It has good scalability, which not only meets the daily cycling safety needs, but can also be extended to professional competitions or specific management scenarios. Attached Figure Description

[0029] Figure 1 A schematic diagram of an STM32 chip applicable to this application; Figure 2 This is a schematic diagram of a signal acquisition module that can be applied to this application. Detailed Implementation

[0030] 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.

[0031] Please see Figure 1-2This invention provides a technical solution: a control system for multi-mode beacon lights and third-party signal lights based on automatic control. The initial design purpose of this control system was to solve the problem that wearing rain gear while riding would obstruct the vehicle's signal lights, as well as the problem that ordinary people do not use electric vehicle signal lights properly and cannot switch lights as needed. As the solution was developed, it was realized that this system can not only be used for riding while wearing rain gear, but also for the automatic switching and display of signal lights on mobile carriers (vehicles), and for use in professional competitions.

[0032] Specifically, the mobile carrier in this application refers to bicycles, electric bicycles and other riding vehicles. The third-party signal lights are the left and right turn lights, brake lights and reversing lights originally configured on the riding vehicle (i.e. "riding vehicle signal lights"). The light-emitting units correspond one-to-one with the riding vehicle signal lights (e.g., the light-emitting unit on the left side of the wearable device corresponds to the left turn light of the riding vehicle and the light-emitting unit on the back corresponds to the brake light of the riding vehicle). The wearable components include one or more combinations of clothing, rain gear, shoes, and hats, that is, the diversity of wearable components can adapt to different cycling scenarios, such as rain gear integration for rainy days, clothing integration for nighttime, and relevant situations in races, and of course, it can also be a cover for a mobile vehicle, etc. The wearable device is provided with one or more light-emitting units, each light-emitting unit including at least one or more colors and a number greater than or equal to one beacon light. This design, which includes multiple colors and multiple quantities, can meet different signal types (such as warnings and lighting), and the beacon light serves as a basic component for signal expression as a light-emitting unit.

[0033] It should also be noted that the beacon light includes at least red (for warning signals linked with bicycle signal lights), and white (optional, for daily auxiliary lighting and daytime lighting). The white beacon light is a non-core component; even if the hardware connection of the white beacon light is completely removed, the system's forward and reverse control core logic and hardware / program operation will not be affected in any way. The white beacon light is only used to improve ease of use. The beacon light adopts a waterproof encapsulation design, which is suitable for outdoor use of bicycles, and the installation position does not interfere with human activities (such as clothing cuffs, back shoulder blades, or on hats or shoe lights).

[0034] The system of this application, depending on the mobile carrier it is paired with, must at least be able to achieve linkage including "reverse control" logic, that is, when the bicycle signal light (left turn / right turn / brake) is activated, the corresponding light-emitting unit (beacon light) responds synchronously, solving the problem of signal transmission failure caused by mud obstruction and poor user operation habits of traditional bicycle signal lights; Meanwhile, the preset working mode also includes "positive control" logic - directly controlling the start and stop of beacon lights and bicycle signal lights through peripheral module instructions, thus realizing active signal expression.

[0035] The system includes a main control module, a signal acquisition module, a serial communication module, and a light-emitting unit driving module. The main control module is electrically connected to the signal acquisition module, the serial communication module, and the light-emitting unit driving module. The main control module also communicates with peripheral modules through the serial communication module. The signal acquisition module acquires the status data of third-party traffic lights and feeds it back to the main control module.

[0036] Considering both functionality and cost, the STM32 microcontroller is chosen as the core carrier for implementing "dual-mode control," with the STM32F103 series chip being the preferred choice. Figure 1 The diagram shown is of an STM32 chip and can be used as a reference.

[0037] Taking a typical electric scooter equipped with three traffic lights (left turn, right turn, and brake) as an example, the signal acquisition module is an ADC analog signal acquisition module (such as...). Figure 2 The ADC acquisition circuit module shown in the diagram acquires the status signals of the left turn signal, right turn signal, and brake light of the bicycle through three independent ADC channels (there are various acquisition methods without special restrictions, such as acquiring voltage values ​​or setting up photoresistors), corresponding to pins PA1, PA2, and PA3 respectively; the serial communication module is implemented through USART1 on pins PA9 (TX) and PA10 (RX). Specific peripheral modules include handheld remote control, mobile phone Bluetooth adapter module, or remote network platform, etc. The serial communication module is a dual-mode control "manual intervention" channel, which complements the "automatic monitoring" channel of the signal acquisition module to improve system flexibility.

[0038] For example, the peripheral module is a Bluetooth adapter module for mobile phones. The mobile phone itself is equipped with GPS and can call third-party maps. It can transmit data commands on whether a turn is needed and whether it is a left or right turn based on the pre-planned route and the movement status of the mobile vehicle, based on the real-time or current location. This data is then expressed to the outside through the main control module, thereby realizing intelligent automatic control.

[0039] Furthermore, the system also includes a third-party traffic light driver module, and the main control module communicates with the third-party traffic light driver module (not limited to wired and wireless connections). That is, based on the original "sensing-controlling beacon lights", a positive drive path of "main control module controlling third-party traffic lights" is added, so that the system can not only "passively respond" to third-party traffic lights, but also "actively control" their start and stop, thus improving the hardware closed loop of "positive control" and adapting to scenarios where users actively operate traffic lights.

[0040] Specifically, the third-party traffic light driver module, namely the bicycle traffic light driver module, adopts an NPN transistor (such as the PN2222) amplifier circuit design. The GPIO pin of the main control module is connected to the base of the transistor through a 1kΩ current-limiting resistor. The collector of the transistor is connected to the negative terminal of the bicycle traffic light, and the emitter is grounded. The positive terminal of the bicycle traffic light is connected to the 12V power supply of the bicycle. This driver module supports the main control module to directly drive the bicycle traffic light to start and stop through "forward control", and also supports the beacon light linkage to respond to the status of the bicycle traffic light through "reverse control". It has an overcurrent protection function and is suitable for bicycle 12V power supply scenarios. Of course, the power supply voltage is not limited to this depending on the actual situation.

[0041] Because data acquisition via the signal acquisition module and the serial communication module may conflict, to ensure that manual commands can immediately override automatic logic, guaranteeing timely and safe operation, and meeting the practical requirement of "human decision-making priority" in cycling scenarios, the data from the serial communication module has a higher priority than that from the signal acquisition module. Specifically, this priority is achieved through conflict isolation using the "adc_enable flag," forming the core conflict resolution mechanism of dual-mode control: when the serial communication module receives a valid control command (forward control), the main control module sets adc_enable to 0, disabling the automatic control logic of the signal acquisition module; when the serial command is executed or a reset command is received, adc_enable is set to 1, restoring the automatic control of the signal acquisition module (reverse control); the priority determination response delay can reach ≤10ms, ensuring real-time signal switching during bicycle operation and avoiding safety hazards caused by command conflicts.

[0042] Specifically, the serial communication module is the USART1 module that connects PA9 and PA10 of the main control module. It is used to receive communication data from the peripheral module. Its default parameters are a baud rate of 9600bps, 8 data bits, 1 stop bit, and no parity bit. During debugging, the CH340 USB to TTL module can be used to connect the peripheral module to the computer via its serial / USB interface.

[0043] Each light-emitting unit contains at least one set of common-cathode red LEDs and one set of common-cathode white LEDs. The "common-cathode red and white LEDs" configuration of the light-emitting unit is to simplify the driving circuit (the common cathode can share the ground terminal, reducing pin occupation). Specifically, there is a first group (red LED PA5, white LED PA4), a second group (red LED PB14, white LED PB13), and a third group (red LED PA7, white LED PA6). Each group is connected in series with a 1kΩ current-limiting resistor for protection. The signal acquisition module communicates with the main control module through the DMA channel. In the case of three light-emitting units, the DMA channel of the signal acquisition module is DMA1_Channel1, configured as peripheral to memory direction, loop mode, half-word data alignment, and the acquired data is transmitted to the cache array ADC1_Values[3] in real time. The DMA transmission does not occupy CPU resources throughout the process. The time taken for a single round of 3-channel signal acquisition is ≤5μs. Here, ADC1 refers to occupying one ADC interface of STM32, that is, using a single signal acquisition module to acquire 3-channel signals.

[0044] The control logic of the control system in this application during actual operation is as follows.

[0045] First, the modules of this application are arranged in the corresponding positions according to the actual situation, and the power supply can be from the mobile carrier or a mobile power supply can be arranged by itself. At the same time, if there is a situation where the modules that communicate with each other cannot be connected in space, they can use the existing interface and the existing wireless communication method to communicate data. The operation process consists of three parts: the system startup foundation in stage M0, the scope of the automatic control process in stage M1 (i.e., signal acquisition → data transmission → condition judgment → execution control), and the "manual control process" in stage M2 (instruction reception → assignment → bidirectional control → priority locking). It should be noted that steps M1 and M2 are parallel steps with no specific order, ensuring that the two modes can be switched at any time.

[0046] Furthermore, after steps M1 and M2 are completed, the system jumps to step M002. This "jump standby" design keeps the system in a ready state, adapting to scenarios where signals change dynamically during cycling.

[0047] Specific process Step M0: Power on the system. M001 Initialization, specifically includes system clock configuration (HSE external crystal oscillator 72MHz, ADC clock frequency division 12MHz), GPIO initialization (beacon light / cyclist signal light driver pins are push-pull output mode, ADC acquisition pins PA1-PA3 are analog input mode), DMA initialization, ADC initialization (signal acquisition module is scan mode, continuous conversion, software trigger, right alignment), USART1 initialization (enable receive interrupt), while simultaneously turning off all cyclist signal lights (i.e., third-party signal lights), turning on white lights (no special restrictions on red lights, can be adjusted according to actual needs), and setting adc_enable to 1 (default enables automatic control mode, i.e., default synchronization with third-party signal lights). Specifically, the signal light is activated by comparing the ADC acquisition value with the threshold ADC_THRESHOLD (default 8). If the acquisition value is greater than 8 and greater than the noise value (the noise value can be set according to the operation, and the purpose of the signal acquisition module adopting continuous conversion mode is to quickly detect changes in the status of the bicycle signal light, and continuous acquisition can filter out occasional noise). M002, the main control module is in standby mode. The signal acquisition module continuously acquires status data. Serial communication module standby state; M1, signal acquisition module triggered operation M101, the signal acquisition module works continuously, acquiring and assigning the status of multiple third-party traffic lights and transmitting them to the cache array, namely ADC1_Values[3], through the DMA channel. Of course, depending on the actual situation, if there are more third-party traffic lights, the data content can be more. M102. Determine the value of the priority parameter adc_enable. If adc_enable=1, the main control module controls the status of the light-emitting unit through the light-emitting unit driver module. Specifically, when the third signal light at a certain position is activated, the red light in the corresponding light-emitting unit flashes (at 500ms intervals) and the white light goes out; when the third signal light is deactivated, the red light goes out and the white light comes on. M2, serial communication module triggers operation The M201 serial communication module receives data from peripheral modules and assigns values ​​(to the blink control flag). Specifically, the parameter for setting the blink control flag is `blink_flag`. Taking a three-position third-party signal light as an example, the values ​​for `blink_flag` are: 0 - reset value, 1 - left turn signal light, 2 - right turn signal light, and 3 - brake signal light. Several modes are also set for the serial communication module's commands. These modes are specifically parsed and executed through the `HAL_UART_RxCpltCallback` callback function. Instructions 1-3 correspond to activating the red light of the LED unit by flashing it and deactivating the white light by setting adc_enable=0. Command 0 corresponds to stopping the red light of the light-emitting unit, turning on the white light, and setting adc_enable=1, which restores the automatic control interrupt serial port processing and realizes seamless switching between dual modes. That is, after adc_enable is set to 1, the signal acquisition module immediately resumes work, and the main control module prioritizes calling the latest acquired data in the cache array to perform reverse control, ensuring the real-time linkage of the signal after reset and avoiding the signal "vacuum period" during riding.

[0048] If the blink_flag value is not a reset value, continue with the following steps: M202: The main control module controls the state of the light-emitting units through the light-emitting unit driver module according to the assigned values, that is, it makes the beacon lights in the corresponding light-emitting units operate according to the requirements of the peripheral modules. M203: The main control module controls the status of the third-party traffic lights through the third-party traffic light driver module based on the assigned values, thereby achieving reverse control of the third-party traffic lights on the mobile carrier. M204. Modify the priority parameter adc_enable to set adc_enable=0.

[0049] To improve system efficiency and reduce the load and energy consumption of the main control module, the update flag is used as a signal bridge between "acquisition completion" and "main control call". Specifically, it is set to 1 after acquisition (notifying the main control module of new data) and set to 0 after the call (marking that the data has been processed). In addition, to avoid conflicts, the HAL_ADC_ConvCpltCallback callback function is set as the interrupt trigger entry point for ADC (acquisition module) acquisition completion. That is, the flag=1 assignment operation is only executed when adc_enable=1 (automatic control mode). If adc_enable=0 (manual control mode), the callback function only performs an empty check and does not modify the flag value to avoid invalid data triggering control logic. flag=1 only indicates that the buffer array has completed one data update. The main control module uses "flag==1 &&" in the main loop. The double condition "adc_enable==1" triggers the control logic call, and the flag is immediately reset to 0 after the call is completed. This mechanism ensures that the main control module only processes valid data. By combining interrupts and flags, the CPU usage is reduced. The execution time of the single-wheel control logic is ≤1ms, which meets the real-time requirements of the dynamic driving scenario of the bicycle.

[0050] In addition, it should be noted that the initialization in step M001 also includes clearing the cache array ADC1_Values[3] (assigning it to an empty set), resetting the data update flag flag=0, resetting the blink control flag blink_flag=0, and the overall white light is only a daytime light or auxiliary lighting light, not a core functional component of the system - even if the white light hardware is removed, the initialization process only skips the white light lighting step, and the main control module can still complete the core configurations such as clock, GPIO, DMA normally, and the forward and reverse control logic of the system is not affected.

[0051] In actual travel scenarios where riders operate mobile vehicles (such as electric bicycles and electric scooters), the complex and ever-changing urban road conditions and the highly unpredictable nature of unexpected situations mean that riders cannot completely avoid various unforeseen special circumstances. These special circumstances often exceed the scope of the mobile vehicle's preset operating modes—for example, the preset modes only cover traffic light control logic for routine straight-ahead, turning, and deceleration scenarios, while there are no corresponding automated control strategies for actual emergency avoidance, temporary lane changes, and breakdowns.

[0052] In scenarios exceeding pre-defined logic, cyclists need to manually adjust the operation of third-party traffic lights mounted on the mobile vehicle based on real-time road conditions and their own hazard avoidance needs. This is to convey precise driving intention signals to surrounding vehicles and pedestrians (e.g., switching to constant hazard warning lights during emergency braking, or switching to flashing turn signals in the corresponding direction during temporary lane changes). However, it's important to note that in emergency situations, cyclists' core attention is focused on the hazard avoidance operation itself, often lacking sufficient reaction time and operational conditions to actively stop the data connection between the mobile vehicle's serial communication module and the peripheral module. Consequently, they cannot stop the peripheral module's automated data intervention on the traffic lights by severing the communication link.

[0053] Peripheral modules operating via serial communication (such as navigation systems on mobile phones) typically transmit data continuously to the traffic light control unit via serial communication, automatically adjusting the lighting units and third-party traffic lights accordingly. For example, the navigation module sends turning signals based on the planned route, and the speed detection module sends deceleration warning signals based on vehicle speed. However, in emergency manual intervention scenarios, if the serial communication link is not disconnected in time, the automated data commands from the peripheral modules will conflict with the rider's manual operation commands. This can cause the third-party traffic lights to fail to accurately respond to human control intentions, and may even transmit incorrect driving signals, leading to secondary safety hazards. To meet the precise control requirements of traffic lights in such emergency manual intervention scenarios, the signal control logic of the mobile vehicle needs to be optimized.

[0054] Specifically, this part of the logic is based on the premise that the system is currently in serial port data receiving mode, and uses the data transmitted through the serial port as the core working data.

[0055] In order to optimize the process and reduce the load on the main control module, the signal acquisition module configures the STM32F103 ADC to continuous conversion mode (i.e., step MB1), configures the DMA channel controller to ring buffer mode and sets the transmission threshold to 2, and opens a uint16_t adc_buf [2] array as a sampling data buffer (i.e., step MB2). The ADC single sampling result is stored in the buffer in 16-bit half-word format to meet the continuous storage and updating of continuous data. After the signal acquisition module completes two data transmissions, it triggers an interrupt. The main control module reads adc_buf[0] (previous sample value) and adc_buf[1] (current sample value) in the interrupt service function and calculates the absolute value of the difference between the two. If the absolute value of the difference is greater than the preset threshold, it is determined that the ADC sampling value has changed, and adc_buf[1] is assigned to the temporary variable adc_valid_val, and the flag bit adc_change_flag is set to 1; If the absolute value of the difference does not exceed the preset threshold, the adc_change_flag flag is cleared, and the DMA continues to collect and overwrite the old data in the adc_buf array. The main program continuously checks adc_change_flag. When it is assigned a value of 1, the main control module controls the state of the light-emitting unit based on the changed data.

[0056] Meanwhile, since the rider may have misoperated and was completely unaware of the operation that differed from that of the serial communication module, in order to avoid such a blunder, and since the data received by the serial communication module from the peripheral module is constantly changing, it is possible that after running for a period of time (a period that can be manually set), the two will become the same again.

[0057] To this end, an additional comparison logic is set up, and the update data flag bit uart_update_flag of the serial communication module is configured. When valid data is received, a serial port receive interrupt is triggered. In the interrupt, the data is parsed and assigned to the variable uart_ref_val, and the flag bit uart_update_flag is set to 1. Furthermore, the values ​​of adc_valid_val and uart_ref_val in the above process are compared (i.e., step MB321). If the two values ​​are not equal: trigger the system warning mechanism and temporarily switch the system working data source to adc_valid_val; If the two values ​​are equal: disable the system warning mechanism and keep the system using uart_ref_val as working data (the actual data is the same, using uart_ref_val is only to improve data consistency); After the comparison is completed, the adc_change_flag and uart_update_flag flags are cleared, and the process returns to step MB1. The system maintains the serial port working mode, the acquisition module continues to collect data in a loop, the serial port remains in interrupt receiving state, and the main program repeatedly executes the detection and comparison logic.

[0058] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A control system for multi-mode beacon lights and third-party traffic lights based on automatic control, comprising a wearable device for personnel and a mobile carrier independent of the wearable device, capable of carrying people and moving, wherein the mobile carrier carries a third-party traffic light, characterized in that: The wearable device integrates at least one light-emitting unit; The light-emitting unit can trigger linkage actions according to the operating status changes of third-party traffic lights. At the same time, the light-emitting unit supports receiving control commands from peripheral modules to execute preset working modes.

2. The control system for multi-mode beacon lights and third-party traffic lights based on automatic control according to claim 1, characterized in that: The wearable device includes one or more combinations of hoods, clothing, rain gear, shoes, and hats; The wearable device is provided with one or more light-emitting units, each light-emitting unit including at least one or more colors, and the number of beacon lights is greater than or equal to one.

3. The control system for multi-mode beacon lights and third-party traffic lights based on automatic control according to claim 2, characterized in that: The system includes a main control module, a signal acquisition module, a serial communication module, and a light-emitting unit driver module. The main control module is electrically connected to the signal acquisition module, the serial communication module, and the light-emitting unit driver module, and the main control module communicates with the peripheral modules through the serial communication module. The signal acquisition module collects the status data of the third-party traffic lights and feeds it back to the main control module.

4. The control system for multi-mode beacon lights and third-party traffic lights based on automatic control according to claim 3, characterized in that: The system also includes a third-party traffic light driver module, and the main control module communicates with the third-party traffic light driver module.

5. The control system for multi-mode beacon lights and third-party traffic lights based on automatic control according to claim 3, characterized in that: The main control module executes commands to the light-emitting unit driving module based on the data fed back by the serial communication module and the signal acquisition module, and the data from the serial communication module has a higher priority than that from the signal acquisition module.

6. The control system for multi-mode beacon lights and third-party traffic lights based on automatic control according to claim 3, characterized in that: The serial communication module is a USART1 module that connects PA9 and PA10 of the main control module. It is used to receive communication data from peripheral modules, and the signal acquisition module communicates with the main control module through a DMA channel.

7. The control logic of the control system for multi-mode beacon lights and third-party traffic lights based on automatic control according to claim 6, characterized in that, The following processes are included: M0, System power-on. M001, Initialization, M002, the main control module is in standby mode. The signal acquisition module continuously acquires status data. Serial communication module standby state; M1, signal acquisition module triggered operation M101, the signal acquisition module, works continuously, acquiring and assigning the status of multiple third-party traffic lights, and transferring them to the buffer array via the DMA channel. M102. Determine the value of the priority parameter adc_enable. If adc_enable=1, the main control module controls the status of the light-emitting unit through the light-emitting unit driver module. M2, serial communication module triggers operation The M201 serial communication module receives data from peripheral modules and assigns data values. M202: The main control module controls the state of the light-emitting unit through the light-emitting unit driver module according to the assigned value. M203: The main control module controls the status of the third-party traffic lights through the third-party traffic light driver module based on the assigned values. M204. Modify the priority parameter adc_enable to set adc_enable=0. Steps M1 and M2 are parallel steps with no specific order, and after steps M1 and M2 are executed, the process jumps to step M002.

8. The control logic of the control system for multi-mode beacon lights and third-party traffic lights based on automatic control according to claim 7, characterized in that: The initialization in step M001 includes at least: turning off all third-party traffic lights. During the initialization process in step M001, adc_enable is assigned the value 1.

9. The control logic of the control system for multi-mode beacon lights and third-party traffic lights based on automatic control according to claim 7, characterized in that: In step M2, the value assigned is blink_flag, and the parameters of blink_flag include a reset value. If the value assigned is a reset value, then adc_enable is set to 1, and serial port processing is directly interrupted. The main control module sets and updates the reference parameter flag, and assigns it a value of 0 or 1. After the acquisition module completes the acquisition, it assigns the value of falg to 1 through the HAL_ADC_ConvCpltCallback callback function. After the main control module accesses the cache array, it assigns the value 0 to falg.

10. The control logic of the control system for multi-mode beacon lights and third-party traffic lights based on automatic control according to claim 7, characterized in that: The following steps are also included when the system is in the state where the serial communication module is triggered to work: MB1 and DMA channels are configured with a ring buffer mode. MB2, the signal acquisition module continuously acquires data and transfers it via the DMA channel. MB3, the main control module compares two consecutive data transfers from the DMA channel. MB31. If the data is the same or does not exceed the threshold, then proceed to step M2, where the serial communication module is triggered to run, and this step ends upon interruption. MB32. If the data change exceeds the threshold, the main control module will control the status of the light-emitting unit based on the changed data. MB321: The main control module compares the changed data with the data received by the peripheral module from the current serial communication module. If the MB3211 is the same, the status control of the light-emitting unit is performed according to the data received from the peripheral module by the current serial communication module, and this step ends upon interruption. MB3211, if different, the main control module controls the state of the light-emitting unit according to the changed data, issues a warning, and loops back to step MB1.

Images