TWI824316B - Encoding device and encoding method for state of traffic light - Google Patents

Abstract

An encoding device and an encoding method for a state of a traffic light are provided. The encoding method includes: receiving state information, wherein the state information includes a direction and at least one traffic light state of at least one traffic light; generating a state group identifier corresponding to the state information according to the direction and the at least one traffic light state; and outputting the state group identifier.

Description

Encoding device and encoding method for light status of signal lights

The invention relates to a coding device and a coding method for the light status of a signal lamp.

When self-driving vehicles pass through signalized intersections on urban roads, they should use on-board sensing equipment to confirm the traffic signal status at the intersection to ensure the safety of themselves and other passers-by. Currently, some self-driving car manufacturers have provided solutions based on traffic signal light state image recognition. However, due to the lack of good urban and traffic planning and the dense population in China, urban road patterns are more complex than those in Europe and the United States, and the density of traffic lights is also higher. Therefore, the technical difficulty of image recognition will be A substantial increase. In addition, environmental factors such as numerous signboards, weather, and strong light will also affect the image quality of the vehicle-mounted camera and the accuracy of light status recognition. On the other hand, other types of vehicle-mounted sensing equipment, such as radar or lidar, are mainly used for obstacle detection and cannot effectively identify signal light status. Therefore, self-driving cars alone cannot actively solve this problem. Currently, the international trend is to adopt the vehicle-to-everything (V2X) communication architecture, with the roadside end actively broadcasting the intersection sign and light status information to assist self-driving vehicles in safely passing the intersection.

Referring to Figure 1, Figure 1 is a schematic diagram of a communication system based on V2X architecture. The concept of the communication system is to wirelessly communicate map (MAP) messages containing information such as intersection lanes and signals, as well as signal phase and timing (SPAT) messages corresponding to the traffic signal controllers on the roadside. technology (such as IEEE 802.11p, DSRC or 3GPPC-V2X) is transmitted to the vehicle-mounted device (such as a driving computer with communication functions), and then the vehicle-mounted device (on board unit, OBU) performs self-driving operations based on the MAP message and SPAT message. Control. The above-mentioned MAP message or SPAT message is in a format that complies with the international SAE J2735 standard.

As traffic volume increases, in order to meet functional requirements such as peak and peak hours, green light continuation of arterial roads, priority vehicle triggering, or information reporting required for central monitoring, the Ministry of Transportation promulgated the Urban Traffic Control Communication Protocol Version 3.0 in 1993 ( Hereinafter referred to as both 3.0). Currently, all new or replaced traffic signal controllers under local governments must comply with the functional and communication interface protocol requirements specified in the City 3.0 Agreement. Therefore, the traffic control center can connect to the communication interface of the traffic signal controller (such as RS-232 serial port or RJ-45 network port) through mobile communication or fixed-line modem for remote signal operation.

Currently, the light broadcast based on the V2X communication architecture mainly converts the 3.0 signals broadcast by the traffic signal controller into SPAT messages that comply with the J2735 specification, so that the road-side communication equipment (road-side unit, RSU) can pass the SPAT messages. Communicates with various types of vehicle-mounted devices. The conversion process of Du3.0 signals into SPAT messages can be performed through customized roadside communication equipment or embedded computers. Taking the architecture of an embedded computer as an example, the roadside communication device needs to obtain the information corresponding to the traffic signal controller. SPAT information, and obtain MAP information of the intersection where the vehicle travels from the traffic control center. After obtaining the SPAT message and the MAP message, the roadside communication device can forward the SPAT message and the MAP message to the vehicle-mounted device. The vehicle-mounted device can perform related operations such as self-driving control based on this information. The above-mentioned conversion process of converting Dudu 3.0 signals into SPAT messages involves issues such as standard format conversion, synchronous conversion, or field parameter definition, and these issues will also involve interoperability and regional standardization between V2X devices.

Regarding the issue of standard format conversion, the current information format of V2X technology mainly adopts the information set of the SAE J2735 standard, of which the parts related to the signal light status are MAP messages and SPAT messages. MAP messages are mainly used to describe intersection and lane attributes, such as intersection coordinates, lane indexes, permitted types of pedestrians in the lane, permitted turns in the lane, or light status groups corresponding to the lane, etc. The SPAT message is a timing plan description of various light states of an intersection light state group, such as describing the start and end time information of a green light, yellow light or red light of a light state group. On the other hand, the description method of light status in Du 3.0, such as the 5F03 command (the hexadecimal code of the first two bytes in the active reporting message of the step light status) can be divided into two parts: First, the vehicle needs The round green light or arrow green light (turn left, go straight or turn right) and its corresponding yellow light and red light, the second is the pedestrian green light and its corresponding pedestrian green flashing and pedestrian red light. In other words, both 3.0 signals describe the current on and off status of lights in the direction that allows vehicles or pedestrians to travel. The timing plan consists of parameters such as the arrangement and combination of phases and steps, as well as step second information. Different timing plans mean different arrangements and combinations of timing steps. In the implementation method of filling in the light status information of the Du3.0 signal into the SPAT message, it is common to fill in the real-time light status and remaining seconds of the 5F03 message. Or it may be necessary to further analyze the phase arrangement of the time plan to extract the start and end times of the complete cycle to fill in the corresponding light event fields of the SPAT message.

Regarding the issue of synchronous conversion, self-driving vehicles have high data update frequency and low latency requirements for road information due to their high-speed movement. For example, the vehicle application may require the data update frequency to be 10Hz, which means the traffic signal controller on the roadside needs to broadcast messages 10 times per second. However, in practice, it can be found that such a demand cannot be achieved with the current domestic signaling equipment and specifications. For example, the 5F03 command of the Du3.0 protocol can be set to report at a fixed number of seconds or at step transition. The fixed number of seconds can be set to report once per second at the earliest. Therefore, other intermediary software or equipment must be used between the traffic signal controller and the roadside communication equipment. In addition to converting data formats of different standards, intermediary software or devices also perform synchronous filling of data. In addition, the signal may be triggered due to events (for example: buses, railways or police vehicles have priority) or other reasons, and the actual operation of the signal deviates from the time plan set by the center. When a set threshold is reached, the traffic signal controller will synchronize the center's timing plan by temporarily adjusting the timing planning cycle of the current equipment operation (ie: timing compensation). The compensation mechanism will have manufacturer differences. In addition, there may be hundreds of milliseconds of changes when the traffic signal controller executes the light status switching instructions. As the number of devices on the light status information transmission path increases, the light status information received by the vehicle-mounted device will change. There is a gap of hundreds of milliseconds or even seconds between the remaining seconds contained and the actual light state transition seconds. To sum up, if it is necessary to ensure that the vehicle terminal receives the light status information synchronized with the intersection light head, the intermediary software or device must also incorporate a dynamic time compensation mechanism to facilitate synchronous conversion.

Regarding the issue of field parameter definition, V2X that complies with the SAE J2735 standard In the message, all fields are given functional descriptions and appropriate variable types. However, in order to retain the application flexibility required by different regions, some fields lack clear parameter value range definitions. For example, fields such as the intersection identification code (IntersectionReferenceID) or light status group (SignalGroup) in the MAP message or SPAT message related to the signal light status lack clear definitions. When this international standard is cited in China, equipment manufacturers must make customized adjustments to the use of messages (field selection or definitions, etc.) in domestic test sites, resulting in ambiguities in the interpretation of the same V2X message between individual equipment manufacturers. Therefore, Derived interoperability and domestic standardization issues.

In the signal light status message part, the vehicle-mounted device must retrieve the relevant information in the SPAT message through the location of the vehicle in the MAP message, the approaching intersection in the driving direction, and the identification code of the signal light status group corresponding to the driving lane. After receiving the action event information (including event light status and time field, etc.) of the corresponding intersection or signal light status group, automatic driving is executed based on the action event. In situations where there are a large number of intersections and lanes, the vehicle-mounted device needs to spend a lot of computing resources or time to retrieve the correct SPAT information. Regarding the implementation of the identification code of the signal light state group, the National Intelligent Transportation System Standard Communication Protocol (NTCIP) adopts the method of encoding all light state groups of the road sign in sequence starting from index 1. V2X equipment vendors or operators in various domestic demonstration sites manually analyze all current light state combinations at intersections, and then use the above method to code the light state group to fill in the V2X roadside communication equipment. When the intersection sign reaches off-peak hours, triggers operations, or even changes lanes, the change in the phase arrangement of the timing plan means a change in light status combination. At this time, manual adjustment of V2X message content will be inefficient. In addition, when the vehicle-mounted device receives the V2X MAP and SPAT When receiving a message, all lane information and applicable signal light status groups at the intersection must be determined one by one based on the current location and direction of travel of the vehicle. When an intersection has complex lanes or the vehicle's own positioning accuracy cannot lock the correct lane, it will affect and reduce the accuracy and efficiency of the vehicle-mounted device's signal light state analysis.

The present invention provides a coding device and a coding method for the lighting status of a traffic light, which can automatically code the lighting status of a traffic light, thereby generating coding information that can improve the accuracy of analysis of the traffic light status by a vehicle-mounted device.

The invention provides a device for encoding the light status of a signal light, including a processor, a storage medium and a transceiver. Storage media stores multiple modules. The processor is coupled to the storage medium and the transceiver, and accesses and executes multiple modules, where the multiple modules include a data collection module, a computing module, and an output module. The data collection module receives light state information through the transceiver, where the light state information includes direction and at least one signal light state of at least one signal light. The computing module generates a light state group identification code corresponding to the light state information based on the direction and the light state of at least one indicator light. The output module outputs the light status group identification code through the transceiver.

In an embodiment of the present invention, the above-mentioned light group identification code includes a lane orientation code, wherein the lane orientation code corresponds to one of the first lane entering the intersection according to the direction and the second lane leaving the intersection according to the direction.

In an embodiment of the present invention, the above-mentioned light status information includes a flash indicator, and the computing module responds to the light status information including a flash indicator and at least one number. The indicator light state corresponds to the yellow light and the light state in the encoded light state group identification code is the flashing yellow light state, wherein the computing module responds to the light state information including the flash indicator and at least one indicator light state corresponds to Red light and the light state in the coded light state group identification code is the flashing red light state.

In an embodiment of the present invention, the above-mentioned light status information includes a flash indicator, wherein the computing module encodes the light status in response to the light status information including the flash indicator and the at least one signal light status corresponds to the pedestrian green flashing light. The light state in the group identification code is a flashing yellow light state, wherein the computing module encodes the light state in the group identification code in response to the light state information including the flashing indicator and at least one signal light state corresponding to the pedestrian red light. The light state is flashing red light state.

In an embodiment of the present invention, the above-mentioned computing module determines whether the light state of at least one signal light corresponds to a round green light, wherein the computing module encodes the light in response to the light state of the at least one signal light corresponding to a round green light. The light status in the status group identification code is the round green light status.

In an embodiment of the present invention, the above-mentioned computing module determines whether the light state of at least one traffic light corresponds to a three-way green light in response to the light state of at least one traffic light not corresponding to a round green light, wherein the computing module responds At least one signal light state corresponds to a three-way green light and the light state in the encoded light state group identification code is a three-way green light state.

In an embodiment of the present invention, the above-mentioned computing module determines whether the lighting state of the at least one traffic light corresponds to the two-way green light in response to the light state of the at least one traffic light not corresponding to the three-way light state, wherein the computing module responds At least one signal light state corresponds to a two-way green light and the light state in the encoded light state group identification code is a two-way green light state.

In an embodiment of the present invention, the above-mentioned computing module determines whether the lighting state of at least one traffic signal corresponds to a one-way green light in response to the lighting state of at least one traffic light not corresponding to a two-way green light, wherein the computing module responds to At least the light state of the signal light 1 corresponds to the one-way green light and the light state in the encoded light state group identification code is the one-way green light state.

In an embodiment of the present invention, the above-mentioned computing module determines whether the light state of at least one signal lamp corresponds to a green light for pedestrians, wherein the computing module encodes the light state group in response to the light state of at least one signal lamp corresponding to a green light for pedestrians. The light state in the group identification code is the pedestrian green light state.

In an embodiment of the present invention, the above-mentioned light status group identification code includes a byte, half of the byte records the lane position code, and the other half of the byte records the light status, and half of the byte contains the most significant bits, and the other half contains the least significant bits.

A method for encoding the light state of a signal light of the present invention includes: receiving light state information, wherein the light state information includes a direction and at least one light state of at least one signal light; according to the direction and at least one signal light state The light state generates a light state group identification code corresponding to the light state information; and outputs the light state group identification code.

Based on the above, the present invention can automatically convert the information obtained from the Capital 3.0 signal into a light group identification code that complies with the SPAT message format of the J2735 standard. The light group identification code can include a lane position code and a signal light. Status and other information.

100: Encoding device

110: Processor

120:Storage media

121:Data collection module

122:Operation module

123:Output module

130:Transceiver

S100, S200, S300, S400, S501, S502, S503, S504, S505, S506, S507, S601, S602, S603, S604, S605, S606, S607, S608, S609, S610, S611, S612, S613, S614 , S615, S616, S617, S618, S701, S702, S703, S704, S705, S706, S707, S708, S709, S801, S802, S803: Steps

Figure 1 shows a schematic diagram of a communication system based on V2X architecture.

FIG. 2 is a schematic diagram illustrating the mapping relationship between the lane direction defined by the Du3.0 signal and the lane direction defined by the MAP message according to an embodiment of the present invention.

FIG. 3 is a schematic diagram of an encoding device for the light state of a signal light according to an embodiment of the present invention.

FIG. 4 illustrates a flow chart of a coding device generating a light state group identification code according to an embodiment of the present invention.

FIG. 5 illustrates a flowchart of step S300 according to an embodiment of the present invention.

FIG. 6 illustrates a flowchart of step S511 according to an embodiment of the present invention.

FIG. 7 illustrates a flowchart of step S400 according to an embodiment of the present invention.

FIG. 8 illustrates a flow chart of a method for encoding the light status of a signal light according to an embodiment of the present invention.

In the aforementioned signal light status group field parameter definition issue, the vehicle-mounted device must first retrieve the location and direction of the vehicle in the MAP message to confirm the identification code of the intersection that the vehicle is approaching and the lane corresponding to the vehicle's driving lane. Signal light status group. Then, the vehicle-mounted device must retrieve the corresponding intersection identification code and the light status event information of the signal light status group in the SPAT message before using it.

For example, in the MAP message, each direction of an intersection may have a left turn lane, one or more through lanes, and a right turn lane. In addition, there may be lanes and applicable vehicle type information such as motorcycle lanes and pedestrian lanes. When the vehicle-mounted device passes through the V2X vehicle When the on-board communication unit (OBU) receives MAP messages and SPAT messages from multiple intersections in the nearby area from the roadside communication unit (RSU), the vehicle-mounted device needs to filter the intersection coordinates of many MAP messages based on the current vehicle position. The intersection identification code belonging to the intersection near the middle road in the outgoing message is obtained, and the MAP message and SPAT message corresponding to the intersection identification code are obtained. Then, the vehicle-mounted device must filter out the lane the vehicle is driving and its corresponding signal light status group based on all lane coordinates in the MAP message. Next, the vehicle-mounted device must retrieve the light event data from the applicable signal light group in the SPAT message. The vehicle-mounted device can operate the vehicle based on the light state event data. For example, it can determine whether to decelerate based on the remaining seconds of the green light state, or determine whether the vehicle starts to accelerate based on the remaining seconds of the red light state. For a vehicle, it may be necessary to sequentially screen the coordinates and directions of all lanes at the intersection before determining the lane to which it belongs. The above-mentioned screening mechanism will cause a huge computing load on the vehicle-mounted device.

In view of this, the present invention proposes a coding method for converting Dual 3.0 signals into MAP messages or SPAT messages. The encoded message (for example, MAP message or SPAT message) generated according to the present invention can include information such as lane orientation and allowed steering. The vehicle-mounted device can select an appropriate light group based on this information, and then determine whether the vehicle is driving in the correct lane. . The lane bearing may include the direction of the lane and may indicate whether the lane is a lane heading toward the intersection or a lane heading away from the intersection.

For the lane direction, the signal group (SignalGroup) in the MAP and SPAT messages of the SAE J2735 standard is a one-tuple type parameter, and its value range is 0~255 (decimal) or 0x00~0xFF (hexadecimal). system). The present invention can convert the 3.0 signal into a light state group identification code containing one byte data, wherein the light state group identification code The high half byte of the alias (bits 7-4), that is, the half of the byte containing the most significant bit (msb), can record the lane location code. The lower half of the byte (bits 3-0) of the light status group identification code, that is, the other half of the byte containing the least significant bit (lsb), can record the light status of the intersection sign. The light status group identification code generated by the present invention can be included in the MAP and SPAT messages.

The upper half byte (bits 7-4) in the light status group identification code of the present invention is based on the 8 directions of a meter-shaped intersection, starting from the north side and clockwise in order: north, northeast, east, southeast, and south. Eight directions, including , southwest, west and northwest, represent the possible lane directions. The lanes in each direction of an intersection can be divided into two categories: entering the intersection and leaving the intersection, and are coded in order, as shown in Table 1.

When filling the lane orientation into the MAP message or SPAT message, the lane orientation represents the relative orientation of the lane to the center of the intersection. For traffic signal controllers, the light state direction field (SignalMap) of the 3.0 phase data management command (such as 5F03) uses 8 bits of a byte to define the light state activation in 8 directions of a one-meter-shaped intersection. Status, the bits from low to high are north, northeast, east, southeast, south, southwest, west and northwest. The direction is the direction of traffic flow, that is, the definition of lane direction between Du3.0 and MAP has two sides. The mirror conversion relationship is shown in Figure 2. FIG. 2 is a schematic diagram illustrating the mapping relationship between the lane direction defined by the Du3.0 signal and the lane direction defined by the MAP message according to an embodiment of the present invention. In Figure 2, the outer ring is the traffic flow direction defined by the SignalMap field of the Intersection Sign City 3.0 signal, and the inner ring is the lane where the high half byte of the identification code of the MAP message light group at the intersection is stored. Direction code, among which the signal light status of Dudu 3.0 signal is mainly used to control the traffic flow entering the intersection, so the lane direction code corresponding to the inner ring intersection uses the lane direction code entering the intersection.

Regarding allowed turns, in the traffic signal controller of Metropolis 3.0, the time-based plan of No. 1 sign is based on the time period (for example: ordinary day or special day), plan number, reference direction, time phase arrangement, and time-based plan content (For example: defining green light and cycle seconds) or basic parameters of time-based planning (for example: defining yellow, red light seconds, etc.) and many other data definitions, and accessed through multiple instructions. On the other hand, the combination of light status on and off of the intersection signal light is arranged through a phase step sequence corresponding to a phase type code (PhaseOrder) index, which is the logical state of the light status on and off in a complete cycle. To describe, one step is a logical combination of light status on and off in all directions of an intersection, and the next step is another different logical combination of light status on and off.

The light status information of Du 3.0 signals can include direction (i.e., the driving direction of the vehicle), time phase, and the signal light corresponding to each step ("O" represents the light, "Δ" represents the flashing light) and flash indicators. Take Table 2 as an example. Table 2 shows the light status information corresponding to the direction "east". Step 1 of phase I corresponds to the first green light split in the "early opening two phases" (that is, the lane in the same direction has an early green light, and the opposite lane has not yet had a green light). Steps 2-6 of phase I correspond to the second green light split in the "early opening two phases" (ie: two-way green lights for the same direction lane and the opposite lane). Steps 7-11 of phase II correspond to the third green light split in the "early opening phase II" (ie: two-way red lights in the same direction and opposite direction).

In the Metropolis 3.0 signal, the one-step signal light status in one direction can be described by the SignalStatus parameter of the one-tuple (ie: the 5F*3 command of the Metropolis 3.0 protocol). The high-to-low bits represent pedestrian red lights respectively. , pedestrian green light, right turn green light, straight green light, left turn green light, round green light, yellow light, red light and other light states ("1" means on, "0" means off). Taking step 1 in Table 2 as an example, the value of the SignalStatus parameter included in the light status information of the 3.0 signal is "0x44", which means that at step 1, the pedestrian green light and the round green light are on. In other words, the light status information of Du3.0 signal can describe the step-by-step light status in the direction of entering an intersection, and mixes two types of information, such as traffic lights and pedestrian lights. In the J2735 standard, the lane's applicable pedestrian classification As described in the MAP message, and in the SPAT message definition, a light state group can contain one or more signal operation events (MovementEvent). A signal operation event defines an event state and its operation time information, and one of the event states (eventState) lists a certain signal state of the lane. Corresponding to the current domestic situation, there are the following signal states: 0 (fault), 1 (not enabled), 2 (flash red light), 3 (red light), 4 (prediction green light/red light countdown), 5 (round green light), 6 (arrow green light), 7 (corresponding to non-protection phase circle (yellow light corresponding to the green head light), 8 (yellow light corresponding to the green light of the arrow), 9 (flash yellow light).

The applicable light status of a lane is composed of a group of signal operation events and is indexed by the signal light status group in the MAP message. Since the two specifications, such as Du3.0 and J2735, describe the light status of the traffic signal controller in different ways, a simple one-to-one conversion cannot be performed directly. The present invention can arrange all possible combinations of the low half byte (bit 3-0) of the light state group identification code of the signal light that supports the J2735 standard according to the 3.0 single-step phase, as shown in the table 3 is the coding method, which represents the steering suitable for passers-by.

The upper half byte of the light status group identification code defined in the present invention is a conceptual description of the applicable direction of the intersection lane group on the signal controller side. When the traffic signal controller applies the present invention to generate a light group identification code that can be used by the V2X device, the traffic signal controller can ensure the orientation information in the light group identification code when setting the light direction ( For example: the direction indicated by the lane location code) is consistent with the actual road location at the intersection. Theoretically speaking, the eight directions shown in Figure 2 are respectively 0 degrees, 45 degrees, 90 degrees, 135 degrees, and 180 degrees that circle clockwise from the north (ie: -179 to 180 degrees). degrees, -135 degrees, -90 degrees and -45 degrees. In practice, the position of a lane group relative to the intersection will not fall exactly on these angles. Accordingly, the present invention can define the lane orientation of a lane whose direction falls within ±22.5 degrees of one of the above-mentioned eight angles as corresponding to one of the above-mentioned angles. If the angle is calculated If it exceeds the value range of -179~180 degrees, the present invention can segment the angle or convert it to a continuous value range variable. The direction of the lane group at the intersection can be defined. For example, a line connecting the two-point coordinates of the center line of the inner lane can be used to indicate the intersection angle, or a line connecting the two-point coordinates of the center line of each lane in the group can be used to indicate the average intersection angle. value.

For example, if the azimuth angle of a lane group is 30 degrees, the lane group falls within the range of 45±22.5 degrees covered by the northeast direction, so the 3.0 traffic signal controller sets the light status accordingly (i.e. :SignalMap parameter), the direction is "Northeast". If the direction of the lane group falls on the boundary of two adjacent directions, you can choose one of the definitions. For example, if the direction of the lane group falls at 22.5 degrees, the light direction in the 3.0 signal can be set to "North" or "Northeast". Then, the vehicle-mounted device determines the most suitable light direction. For example, when the vehicle-mounted device can retrieve the light status group identification code of the SPAT message at an intersection, if the SPAT message has four orientation codes: 0x0* on the north side, 0x4* on the east side, 0x6* on the south side, and 0x8* on the west side, the vehicle-mounted device can retrieve the light status group identification code based on the SPAT message. The absolute values of the angle differences between the direction of travel (for example: 22.5 degrees) and the four azimuth angles (0, 90, 180, -90 degrees) of north, east, south, and west mentioned above are 22.5, 67.5, 157.5, and 112.5 degrees respectively. After sorting, it can be found that the direction closest to the traveling direction of the vehicle-mounted device (that is, the one with the smallest angle difference) is the north side. The vehicle-mounted device can also check and verify whether it is correct through the light status group of the corresponding lane in the MAP message. The following will explain how the present invention converts from the light state description of Du 3.0 to the generation method of the light state group identification code defined by the present invention. The light state group identification code can be included in the MAP message or SPAT message of the SAE J2735 standard. middle.

Figure 3 illustrates an arrangement of light states of a signal light according to an embodiment of the present invention. Schematic diagram of the coding device 100. The encoding device 100 may include a processor 110, a storage medium 120, and a transceiver 130.

The processor 110 is, for example, a central processing unit (CPU), or other programmable general-purpose or special-purpose micro control unit (MCU), microprocessor, or digital signal processing unit. Digital signal processor (DSP), programmable controller, application specific integrated circuit (ASIC), graphics processing unit (GPU), image signal processor (ISP) ), image processing unit (IPU), arithmetic logic unit (ALU), complex programmable logic device (CPLD), field programmable gate array (field programmable gate array) , FPGA) or other similar components or a combination of the above components. The processor 110 can be coupled to the storage medium 120 and the transceiver 130, and access and execute multiple modules and various applications stored in the storage medium 120.

The storage medium 120 is, for example, any type of fixed or removable random access memory (RAM), read-only memory (ROM), or flash memory. , hard disk drive (HDD), solid state drive (SSD) or similar components or a combination of the above components, and are used to store multiple modules or various application programs that can be executed by the processor 110 . In this embodiment, the storage medium 120 can store multiple modules such as the packet data collection module 121, the computing module 122, and the output module 123, and their functions will be as follows: Follow-up instructions.

The transceiver 130 transmits and receives signals in a wireless or wired manner. Transceiver 130 may also perform, for example, low noise amplification, impedance matching, mixing, up or down frequency conversion, filtering, amplification, and similar operations.

FIG. 4 illustrates a flow chart of the encoding device 100 generating the light group identification code according to an embodiment of the present invention. In step S100, the data collection module 121 may receive the light status information through the transceiver 130. For example, the data collection module 121 can be communicatively connected to the traffic signal controller through the transceiver 130, and receive the 5F5F command, 5FDF message or 5F signal contained in the 3.0 signal from the traffic signal controller. 5F03 step message) light status information. The light state information may include a direction and at least one signal light state of at least one signal light. In addition, the light status information can also include information such as phase, step, and flash indicator. For example, the light status information includes the content recorded in Table 2. The data collection module 121 can sequence the one-step SignalStatus according to the direction sequence corresponding to the bit order of the SignalMap, and read out the data sequentially. For example, the data collection module 121 can convert the light status information into a SignalStatus byte array with steps as columns and lane directions as rows, and temporarily store the SignalStatus byte array in the storage medium 120 .

After obtaining the light state information, the computing module 122 can generate a light state group identification code corresponding to the light state information according to the direction recorded in the light state information and at least one signal light state. The light status group identification code may include one byte of data, where half of the byte (for example: bits 7-4 including the most significant bit) may record the lane orientation code as shown in Table 1, and The other half of the byte (i.e. the bits containing the least significant bit code Yuan 0-3) can record the light status of at least No. 1 sign lamp at each step. The output module 123 can output the light state group identification code through the transceiver 130 after the light state group identification code is generated.

Specifically, in step S200, the computing module 122 can encode the lane orientation code in the light status group identification code according to the direction in the light status information and the lane orientation lookup table shown in Table 1, where the lane orientation code can be Corresponds to one of the lanes entering the intersection in that direction and the lane leaving the intersection in that direction. In other words, the computing module 122 can generate two lane orientation codes corresponding to two light status group identification codes respectively according to the directions in the light status information, wherein the lane orientation codes recorded in the two light status group identification codes are may be different, but the lighting status of the recorded signal lights may be the same.

Taking Tables 1 to 2 and Figure 2 as an example, assuming that the light status information shown in Table 2 received by the data collection module 121 indicates the direction of "east", the computing module 122 can adjust the first light according to the direction of "east". The lane orientation code in the status group identification code is coded as "C" as shown in Table 1.

After completing the encoding of the lane orientation code in the light state group identification code, in step S300, the computing module 122 may perform light state encoding related to traffic flow according to at least one signal light state in the light state information, thereby Generate light state group identification codes related to traffic flow. On the other hand, in step S400, the computing module 122 may perform pedestrian-related light state encoding according to at least one signal light state in the light state information, thereby generating a pedestrian-related light state group identification code.

In step S300 or step S400, the computing module 122 may encode the light status of at least one signal light corresponding to a single direction. The computing module 122 can be based on The loop method repeatedly reads the light state information to obtain the light states corresponding to all steps in a single direction, and performs light state encoding for at least one signal light based on the light states of all steps to generate a light corresponding to a single direction. status group identification code.

On the other hand, the computing module 122 can also repeatedly execute step S300 and step S400 in a loop manner to sequentially encode the light group identification codes corresponding to different directions, thereby generating light group identification codes corresponding to a single intersection. Multiple light status group identification codes in multiple directions. Taking the intersection in FIG. 2 as an example, the computing module 122 can repeatedly execute steps S300 and S400 to sequentially complete the eight lane directions corresponding to entering the intersection (that is, corresponding to the lane location codes 0, 2, and 4 respectively). , 6, 8, A, C and E) encoding of light states.

FIG. 5 illustrates a flowchart of step S300 according to an embodiment of the present invention. In step S501, the computing module 122 may determine whether the light status information includes a flash indicator. If the light status information includes a flashing indicator, it means that the traffic signal at the intersection corresponding to the light status information is a flashing light, and the computing module 122 may then perform step S502. If the light status information does not include a flashing indicator, it means that the traffic signal at the intersection corresponding to the light status information is not a flashing light, and the computing module 122 may then execute step S507.

In step S502, the computing module 122 may determine whether at least one signal light state in the light state information corresponds to a yellow light. If the light state of at least one signal light corresponds to the yellow light, step S503 is entered. If the light state of at least one signal light does not correspond to the yellow light, step S504 is entered.

In step S503, the computing module 122 may encode the light state in the lower half byte of the light state group identification code, and encode the light state as the flashing yellow light state "0x0A", as shown in the table 3 shown.

In step S504, the computing module 122 may determine whether at least one signal light state in the light state information corresponds to a red light. If the light state of at least one signal light corresponds to the red light, step S505 is entered. If the light state of at least one signal light does not correspond to the red light, step S506 is entered.

In step S505, the computing module 122 may encode the light state in the lower half byte of the light state group identification code, and encode the light state into the flashing red light state "0x0B", as shown in Table 3.

In step S506, the computing module 122 may determine that the encoding fails. The output module 130 can output a warning message through the transceiver 130 in response to the encoding failure, thereby reminding the user that the light status information (for example, the 3.0 signal broadcast by the traffic signal controller) is incorrect.

In step S507, the computing module 122 may execute a green light state encoding process, thereby encoding at least one traffic light state into a green light state.

FIG. 6 illustrates a flowchart of step S511 according to an embodiment of the present invention. In step S601, the computing module 122 may detect the green light state type corresponding to at least one signal light state in the light state information.

In step S602, the computing module 122 may determine whether at least one sign light state corresponds to a round green light according to the green light state type. If at least one signal light state corresponds to the round green light, step S603 is entered. If at least one signal light state does not correspond to the round green light, step S604 is entered. For example, if the light status information includes multiple steps corresponding to round green lights, yellow lights, and red lights, the computing module 122 can determine at least one sign. The light state corresponds to the round-headed green light.

In step S603, the computing module 122 may encode the light state in the lower nibble of the light state group identification code, and encode the light state into the round green light state "0x01", as shown in Table 3.

In step S604, the computing module 122 may determine whether at least one signal light state corresponds to a three-way green light according to the green light state type. If at least one signal light state corresponds to the three-way green light, step S605 is entered. If at least one signal light state does not correspond to the three-way green light, step S606 is entered. For example, if the light state information includes multiple steps corresponding to three-way green light, yellow light, and red light, the computing module 122 may determine that at least one light state corresponds to the three-way green light.

In step S605, the computing module 122 may encode the light state in the lower nibble of the light state group identification code, and encode the light state into the three-way green light state "0x02", as shown in Table 3.

If at least one signal light state does not correspond to a three-way green light, the computing module 122 may determine whether at least one signal light state corresponds to a two-way green light. If at least one of the signal light states corresponds to the two-way green light, the computing module 122 may encode the light state in the lower half byte of the light state group identification code to encode the light state as the two-way green light state.

Specifically, in step S606, the computing module 122 may determine whether the light state of at least one signal corresponds to a left green light and a straight green light. If at least one signal light state corresponds to the left green light and the straight green light, step S607 is entered. If at least one signal light state does not correspond to the left green light and the straight green light, step S608 is entered. For example, if the light status information includes multiple steps corresponding to a left green light, a straight green light, a yellow light, and a red light, level, the computing module 122 can determine that the at least one signal light state corresponds to the left green light and the straight green light.

In step S607, the computing module 122 may encode the light state in the lower half byte of the light state group identification code, and encode the light state into the left green light and the straight green light state "0x03", as shown in Table 3 .

In step S608, the computing module 122 may determine whether at least one signal light state corresponds to a right green light and a straight green light. If at least the first signal light state corresponds to the right green light and the straight green light, step S609 is entered. If at least one signal light state does not correspond to the right green light and the straight green light, step S610 is entered. For example, if the light state information includes multiple steps corresponding to a right-turn green light, a straight-going green light, a yellow light, and a red light, the computing module 122 may determine that at least one signal light state corresponds to a right-turn green light and a straight-going green light. .

In step S609, the computing module 122 can encode the light state in the lower nibble of the light state group identification code, and encode the light state into the right green light and straight green light state "0x04", as shown in Table 3 .

In step S610, the computing module 122 may determine whether at least one signal light state corresponds to a left green light and a right green light. If at least one signal light state corresponds to a left green light and a right green light, step S611 is entered. If at least one signal light state does not correspond to the left green light and the right green light, step S612 is entered. For example, if the light state information includes multiple steps corresponding to a left green light, a straight green light, a yellow light, and a red light, the computing module 122 may determine that at least one signal light state corresponds to a left green light and a straight green light. .

In step S611, the computing module 122 may encode the light state in the lower half byte of the light state group identification code, and encode the light state into a left green light state and a right green light state. "0x05", as shown in Table 3.

If at least one signal light state does not correspond to a two-way green light, the computing module 122 may determine whether at least one signal light state corresponds to a one-way green light. If at least one of the signal light states corresponds to the one-way green light, the computing module 122 may encode the light state in the lower half byte of the light state group identification code to encode the light state as the one-way green light state.

Specifically, in step S612, the computing module 122 may determine whether at least one signal light state corresponds to a straight green light. If at least one signal light state corresponds to the straight green light, step S613 is entered. If at least the first signal light state does not correspond to the straight green light, step S614 is entered. For example, if the light state information includes multiple steps corresponding to a straight green light, a yellow light, and a red light, the computing module 122 may determine that at least one of the light states corresponds to a straight green light.

In step S613, the computing module 122 may encode the light state in the lower half byte of the light state group identification code, and encode the light state as the straight green light state "0x06", as shown in Table 3.

In step S614, the computing module 122 may determine whether at least one signal light state corresponds to a left green light. If at least one signal light state corresponds to the left green light, step S615 is entered. If at least one signal light state does not correspond to the left green light, step S616 is entered. For example, if the light state information includes a plurality of steps corresponding to a left green light, a yellow light, and a red light, the computing module 122 may determine that at least one of the light states corresponds to a left green light.

In step S615, the computing module 122 may encode the light state in the lower half byte of the light state group identification code, and encode the light state as the left green light state "0x07", as shown in Table 3.

In step S616, the computing module 122 may determine whether at least one signal light state corresponds to a right green light. If at least one signal light state corresponds to a right green light, step S617 is entered. If at least one signal light state does not correspond to the right green light, step S618 is entered. For example, if the light state information includes multiple steps corresponding to right-turning green lights, yellow lights, and red lights, the computing module 122 may determine that at least one light state corresponds to right-turning green lights.

In step S617, the computing module 122 may encode the light state in the lower nibble of the light state group identification code, and encode the light state as the right green light state "0x08", as shown in Table 3.

In step S618, the computing module 122 may determine that the encoding fails. The output module 130 can output a warning message through the transceiver 130 in response to the encoding failure, thereby reminding the user that the light status information (for example, the 3.0 signal broadcast by the traffic signal controller) is incorrect.

FIG. 7 illustrates a flowchart of step S400 according to an embodiment of the present invention. In step S701, the computing module 122 may determine whether the light status information includes a flash indicator. If the light status information includes a flash indicator, step S702 is entered. If the light status information does not include the flash indicator, step S707 is entered.

In step S702, the computing module 122 may determine whether at least one signal light state corresponds to a pedestrian green flashing light. If at least one signal light state corresponds to the pedestrian green flashing light, step S703 is entered. If at least one signal light state does not correspond to the pedestrian green flashing light, step S704 is entered.

In step S703, the computing module 122 may encode the light state in the lower half byte of the light state group identification code, and encode the light state as the flashing yellow light state "0x0A", as shown in the table 3 shown.

In step S704, the computing module 122 may determine whether at least one signal light state corresponds to a red pedestrian light. If at least one signal light state corresponds to a pedestrian red light, step S705 is entered. If at least one signal light state does not correspond to the pedestrian red light, step S706 is entered.

In step S705, the computing module 122 may encode the light state in the lower nibble of the light state group identification code, and encode the light state into the flashing red light state "0x0B", as shown in Table 3.

In step S706, the computing module 122 may determine that the encoding fails. The output module 130 can output a warning message through the transceiver 130 in response to the encoding failure, thereby reminding the user that the light status information (for example, the 3.0 signal broadcast by the traffic signal controller) is incorrect.

In step S707, the computing module 122 may determine whether at least one signal light state corresponds to a green light for pedestrians. If at least one signal light state corresponds to the pedestrian green light, step S708 is entered. If at least one signal light state does not correspond to the pedestrian green light, step S709 is entered.

In step S708, the computing module 122 may encode the light state in the lower nibble of the light state group identification code, and encode the light state as the pedestrian green light state "0x09", as shown in Table 3.

In step S709, the computing module 122 may determine that the encoding fails. The output module 130 can output a warning message through the transceiver 130 in response to the encoding failure, thereby reminding the user that the light status information (for example, the 3.0 signal broadcast by the traffic signal controller) is incorrect.

Figure 8 illustrates an arrangement of light states of a signal light according to an embodiment of the present invention. A flow chart of a coding method, wherein the coding method can be implemented by the coding device 100 as shown in FIG. 3 . In step S801, light state information is received, where the light state information includes a direction and at least one signal light state of at least one signal light. In step S802, a light state group identification code corresponding to the light state information is generated according to the direction and at least one signal light state. In step S803, the light status group identification code is output.

To sum up, the present invention can automatically convert the information obtained from the Capital 3.0 signal into a light group identification code that complies with the SPAT message format of the J2735 standard. Users no longer have to manually code the light status of each intersection. The light status group identification code of the present invention may include information such as lane location code and signal light status. After the vehicle-mounted device receives multiple light group identification codes broadcast by the traffic signal controller at the intersection, the vehicle-mounted device only needs to detect its own driving direction to determine which light group identification code is applicable based on the driving direction. without detecting a very precise location (for example: detecting the lane where the vehicle is located). The vehicle-mounted device can perform autonomous driving with the assistance of applicable light status group identification codes. In addition, the present invention can significantly reduce the time it takes for the vehicle-mounted device to query the SPAT information corresponding to the lane according to the lane position, so that the vehicle-mounted device can obtain the information needed to perform automatic driving more quickly.

S801, S802, S803: steps

Claims (10)

A device for encoding the light status of a traffic light, including: a transceiver; a storage medium that stores a plurality of modules; and a processor that couples the storage medium and the transceiver, and accesses and executes the plurality of modules. A module, wherein the plurality of modules includes: a data collection module that receives light state information through the transceiver, wherein the light state information includes a direction and at least one signal light state of at least one signal light; The computing module generates a lane orientation code based on the direction and lane orientation lookup table encoding, and generates a light status based on the coding of the at least one signal light status, and forms a corresponding correspondence based on the lane orientation code and the light status. a light state group identification code in the light state information; and an output module that outputs the light state group identification code through the transceiver; wherein the light state group identification code can be a byte, The upper half byte of the light state group identification code records the lane orientation code, and the lower half byte of the light state group identification code records the light state, wherein the upper half byte includes The most significant bit, and the lower nibble includes the least significant bit. The encoding device as claimed in claim 1, wherein the lane orientation code corresponds to one of a first lane entering the intersection in the direction and a second lane leaving the intersection in the direction. The encoding device according to claim 1, wherein the light state information includes a flash indicator, wherein The computing module encodes the light state in the light state group identification code as flashing in response to the light state information including the flash indicator and the at least one signal light state corresponding to a yellow light. Yellow light state, wherein the computing module encodes the light state group identification code in response to the light state information including the flash indicator and the at least one signal light state corresponding to a red light. The light state is a flashing red light state. The encoding device of claim 1, wherein the light status information includes a flash indicator, wherein the computing module responds to the light status information including the flash indicator and the at least one signal light status The light state in the light state group identification code is encoded corresponding to the pedestrian green flashing light as a flashing yellow light state, wherein the computing module includes the flash indicator in response to the light state information and the The light state of the at least one signal light corresponds to a red pedestrian light and the light state encoded in the light state group identification code is a flashing red light state. The encoding device according to claim 1, wherein the operation module determines whether the light state of the at least one signal light corresponds to a round green light, and the operation module responds to the light state of the at least one signal light. The light state in the light state group identification code encoded corresponding to the round-head green light is a round-head green light light state. The encoding device according to claim 5, wherein the computing module determines whether the at least one signal light state corresponds to the three-dimensional green light in response to the light state of the at least one signal light not corresponding to the round green light. to green light, which The computing module encodes the light state in the light state group identification code as the three-way green light state in response to the at least one signal light state corresponding to the three-way green light. The encoding device of claim 6, wherein the computing module determines whether the at least one signal light state corresponds to the three-way light state in response to the at least one signal light state not corresponding to the three-way light state. A two-way green light, wherein the computing module encodes the light state in the light state group identification code as a two-way green light state in response to the at least one signal light state corresponding to the two-way green light. The encoding device of claim 7, wherein the computing module determines whether the at least one signal light state corresponds to the one-way green light in response to the at least one signal light state not corresponding to the two-way green light. Green light, wherein the computing module encodes the light state in the light state group identification code as the one-way green light state in response to the at least one signal light state corresponding to the one-way green light. The encoding device of claim 1, wherein the computing module determines whether the at least one signal light state corresponds to a pedestrian green light, and the computing module responds to the at least one signal light state corresponding to The light state in the light state group identification code encoded in the pedestrian green light is a pedestrian green light state. A method for encoding the light status of a traffic light, including: receiving light status information, wherein the light status information includes a direction and at least one traffic light status of at least one traffic light; and looking up a table according to the direction and lane orientation. Encoding to generate a lane position code, and encoding according to the at least one signal light state to generate a light state, based on the lane The orientation code and the light state constitute a light state group identification code corresponding to the light state information; and output the light state group identification code, wherein the light state group identification code includes a byte, wherein One half of the bytes records the lane orientation code, and the other half of the bytes records the light state, with the half including the most significant bits and the other half including the least significant bits.

Images