JP7279206B2 - In-vehicle device, inter-vehicle communication system, and program - Google Patents

Description

An embodiment of the present invention relates to an in-vehicle device, an inter-vehicle communication system, and a program.

Vehicle-to-vehicle communication has been under constant investigation for a long time. In the study, for example, use of the 700 MHz band was proposed. However, it cannot be said that the degree of realistic spread is sufficient even at present. Main reasons for this are as follows.
(1) There is a dilemma that early spread does not progress because users cannot enjoy benefits unless spread progresses to a certain extent. In other words, there is a <wall of diffusion> until the number of spread exceeds a certain number.
(2) The car replacement cycle is getting longer, and it takes time for new technology to penetrate.
(3) Standardization on a national scale or international standardization is difficult, standardization work takes time, and standardization itself has not progressed.
(4) Clear benefits of vehicle-to-vehicle communication have not permeated society.
(5) The practicality of safety support functions using in-vehicle radar/cameras has been widely recognized by society, and the value of vehicle-to-vehicle communication has declined relatively.

Japanese Patent No. 4040441 Japanese Patent No. 6447749

“RECAIUS (Registered Trademark) Voice Creator/Speech Synthesis Service”, [online], [searched on November 8, 2019], Internet, <URL: https://www.toshiba-sol.co.jp/pro /recaius/lineup/creator.html> “coestation (registered trademark)”, [online], [searched on November 8, 2019], Internet, <URL: https://coestation.jp/>

Techniques for efficiently selecting information to be transmitted in inter-vehicle communication are known, but inter-vehicle communication methods and practical applications are still under study. For the coming society, which is also called Society 5.0, it is desired to disseminate devices and various infrastructures related to vehicle-to-vehicle communication.
Therefore, the object is to promote the spread of inter-vehicle communication systems.

According to an embodiment, an in-vehicle device includes a receiver and a speech synthesizer. The receiving unit receives message data including at least a command code corresponding to the intention of the driver of the other vehicle and positional information of the other vehicle from the other vehicle. The speech synthesizer generates a voice message from the command code included in the message data when it is determined that the destination of the message data is the vehicle based on the location information included in the message data and the location information of the vehicle. Synthesize.

FIG. 1 is a functional block diagram showing an example of an in-vehicle system according to an embodiment. FIG. 2 is a diagram showing an example of the usage environment of the in-vehicle device 2. As shown in FIG. FIG. 3 is a functional block diagram showing an example of the in-vehicle device 2. As shown in FIG. FIG. 4 is a diagram showing an example of the format of message data used in inter-vehicle communication according to the embodiment. FIG. 5 is a flow chart for explaining the function of the travel information calculator 24i. FIG. 6 is a flow chart for explaining the function of the receiver 24g. FIG. 7 is a flowchart for explaining the functions of the transfer unit 24d. FIG. 8 is a flowchart for explaining the function of the retweet section 24c. FIG. 9 is a flow chart for explaining the function of the transmission section 24b. FIG. 10 is a flowchart for explaining the function of the relative position calculator 24f. FIG. 11 is a diagram showing an example of correspondence between communication partner codes and relative positional relationships. FIG. 12 is a flowchart for explaining the functions of the speech recognition section 24a. FIG. 13 is a diagram showing an example of a voice command format. FIG. 14 is a diagram showing an example of a keyword and an encoded string for designating a conversation partner. FIG. 15 is a diagram showing an example of voice commands and encoded strings. FIG. 16 is a conceptual diagram showing speech synthesized and output by the speech synthesizing unit 24e. FIG. 17 is a flow chart for explaining the function of the speech synthesizing section 24e. FIG. 18 is a diagram showing an example of the correspondence between character strings for voice phrase generation and command codes. FIG. 19 is a diagram showing an example of voice quality data defined for each vehicle type. FIG. 20 is a diagram showing an example of voice quality data defined for each vehicle color. FIG. 21 is a diagram showing an example of voice quality data defined for a driving history. FIG. 22 is a diagram showing an example of keywords expressing the relative positions of the own vehicle and the opponent vehicle. FIG. 23 is a diagram showing an example of voice message data for the dialect of Hiroshima Prefecture. FIG. 24 is a diagram showing an example of voice message data for dialect of Osaka prefecture.

<Configuration>
FIG. 1 is a functional block diagram showing an example of an in-vehicle system according to an embodiment. A vehicle-to-vehicle communication system may include various infrastructures such as hardware such as an in-vehicle device and a program that implements a function executed by the hardware.
The in-vehicle system is formed with an in-vehicle device 2 mounted in the vehicle as a core. The in-vehicle device 2 can be mounted in a vehicle equipped with the car navigation system 3 . A GPS (Global Positioning System) antenna 1 for a car navigation system 3 and a microphone 5 for acquiring voice data of a driver 6 are connected to an in-vehicle device 2 . A plurality of vehicle speakers 4 , 7 , 8 , 9 are connected to the car navigation system 3 . Speakers 4, 7, 8, and 9 are installed in front left (front L), front right (front R), rear left (rear L), and rear right (rear R) of driver 6, respectively.

That is, the embodiment assumes a vehicle with an audio installation with so-called four-channel speakers. With the speakers 4, 7, 8, 9, the audio equipment can localize the sound image at any position in the vehicle interior space.

The in-vehicle device 2 is a so-called embedded computer including a CPU (Central Processing Unit) 24 and a memory 25 . The in-vehicle device 2 further includes a GPS module 21 , a built-in antenna 22 and a wireless module 23 . The GPS module 21 takes in the signal from the GPS antenna 1 , branches it internally and outputs it to the car navigation system 3 . On the other hand, the built-in antenna 22 is used for the wireless module 23 to communicate with the in-vehicle device of another vehicle.

FIG. 2 is a diagram showing an example of the usage environment of the in-vehicle device 2. As shown in FIG. As shown in FIG. 2, the in-vehicle device 2 is attached to, for example, a dashboard. This is so-called ponting. Preferably, it should be mounted below the rear-view mirror so that it does not interfere with the driver's field of vision. A vehicle-to-vehicle communication system of the embodiment is formed by communicating with each other among a plurality of vehicles equipped with the in-vehicle device 2 .
In the embodiment, it is assumed that the in-vehicle device 2 of each vehicle exchanges message data in a predetermined format with each other. A plurality of in-vehicle devices 2 can exchange message data with each other, for example, using an existing specific low-power wireless communication infrastructure. A typical example of this kind of infrastructure is the smart meter communication infrastructure in Japan. As is well known, the smart meter communication infrastructure in Japan uses the 900 MHz band to transfer data between devices.

The driver of the vehicle issues a voice command to the in-vehicle device 2, for example, "Tell me the average vehicle speed!" (voice command). Then, the in-vehicle device 2 automatically responds that "the average vehicle speed is 0 km/h in the left lane and 0 km/h in the right lane" (automatic response). In response to this, the driver can make a decision as to whether or not it is necessary to change lanes, for example, "If the difference is only one minute, let's continue as is."

FIG. 3 is a functional block diagram showing an example of the in-vehicle device 2. As shown in FIG. The in-vehicle device 2 includes a voice recognition unit 24a, a transmission unit 24b, a retweet unit 24c, a transfer unit 24d, a voice synthesis unit 24e, a relative position calculation unit 24f, a reception unit 24g, a speaker connection unit 24h, a travel information calculation unit 24i, and A GPS receiver 24j is provided. These functional blocks are implemented as processing functions of the CPU 24 . The voice synthesizing section 24e is connected to the speakers 4, 7, 8 and 9 via the speaker connecting section 24h.

The in-vehicle device 2 also includes a keyword storage unit 25a, a dialect data storage unit 25b, a voice quality definition data storage unit 25c for each vehicle type, a voice quality definition data storage unit 25d for each driver attribute, a command definition data storage unit 25e, and an own vehicle running information storage. 25f, other vehicle travel information storage unit 25g, host vehicle setting information storage unit 25h, and driver setting information storage unit 25i. These can be understood as storage areas provided in the memory 25 . The memory 25 also stores programs including instructions for realizing each function of the CPU 24 .

The receiving unit 24g receives message data transmitted from other vehicles. The message data includes at least a command code corresponding to the intention of the driver of the other vehicle and position information of the other vehicle.

FIG. 4 is a diagram showing an example of the format of message data used in inter-vehicle communication according to the embodiment. The command code is written in, for example, the tenth field of the message data. The location information of the other vehicle is described in each of a plurality of (eg, (1) to (N)) other vehicle travel history information.

The other vehicle travel history information is data having a structure in which a plurality of pieces of history data (1) to (m) of the other vehicle are associated with identification information (for example, manufacturing number) of the other vehicle. Each piece of history data is information having a structure in which position information represented by latitude and longitude, moving direction, and moving speed are associated with time stamps. This information is called travel information. The traveling information is extracted from the message data by the receiving section 24g and stored in the other vehicle traveling information storage section 25g.
The message data also includes fields such as a retweet flag, sender's identification information, sender's latitude/longitude, sending time stamp, communication partner code, and so on.

The transmission vehicle type in the eighth field indicates the attributes of the vehicle that transmitted the message data. Vehicle attributes include, for example, vehicle type, color, model year, and type. Vehicle types include heavy-duty trucks, medium-duty trucks, ordinary vehicles, and light vehicles. Colors are classified into, for example, red series, blue series, and so on. These pieces of information are stored in advance in the own vehicle setting information storage unit 25h, for example, when the in-vehicle device 2 is initialized.

The attribute of the driver of the originating vehicle in the ninth field indicates the attribute of the driver of the vehicle that has transmitted the message data (driver's attribute). Driver attributes are information that indicates characteristics of drivers, such as male, female, age, veteran, and beginner. These pieces of information are stored in advance in the driver setting information storage unit 25i, for example, when the in-vehicle device 2 is initialized.

Note that the configuration of the message data shown in FIG. 4 is just an example, and does not necessarily indicate the specific contents of the communication message in actual communication, and the correspondence between the number and each field is also just an example. In actual communication, for example, data compression processing or the like is appropriately performed from the viewpoint of efficiency or the like.

The voice synthesizing unit 24e determines whether the destination of the message data is the own vehicle based on the location information of the other vehicle as the transmission source included in the received message data and the location information of the own vehicle acquired from the GPS receiving unit 24j. determine whether or not Then, when it is determined that the destination of the message data is the own vehicle, the voice synthesizing unit 24e synthesizes a voice message from the command code of the received message data. The synthesized voice message is loudly output from speakers 4, 7, 8, and 9. FIG.

The transmission unit 24b transmits the message data to other vehicles. As shown in FIG. 4, the message data includes at least a command code corresponding to the intention of the driver of the vehicle (sender) and position information (latitude and longitude) of the vehicle. Of course, the message data also includes the identification information of the originating vehicle and the time stamp at the time of origination.

Here, the transmission unit 24b and the reception unit 24g use the smart meter communication infrastructure 100 to transmit and receive message data between the own vehicle and the other vehicle. Each electric power company in Japan is promoting the introduction of smart meters, and from fiscal 2020 to 2023, the introduction to almost all domestic households will be completed. Most of the means of communication use 920 MHz band specified low-power radio, and the range of application is expected to reach 30 to 50 million households. Therefore, it is possible to use a highly reliable and inexpensive smart meter communication infrastructure 100 .

The 920 MHz band specified low-power radio further has the following features.
(1) A radio station license is not required for outputs up to 20 mW.
(2) The frequency band is equivalent to the so-called platinum band used in mobile phones, and has relatively good wraparound characteristics into buildings.
(3) Since radio waves do not travel too far, it should be suitable for relatively short distance communication such as vehicle-to-vehicle communication.
Due to these features, the smart meter communication infrastructure 100 is also suitable for inter-vehicle communication. By making use of these features and using highly reliable and inexpensive communication functions, it is expected that the <barrier to popularization> will be overcome.

The speech recognition unit 24a recognizes the speech uttered by the driver of the vehicle. The recognition result is sent to the transmitter. The transmission unit stores a command code based on the voice recognition result in message data and transmits the message data to another vehicle.

The travel information calculation unit 24i acquires the position information of the own vehicle from the GPS reception unit 24j, and calculates the travel information of the own vehicle in which the time stamp is associated with the position information, moving direction, and moving speed of the own vehicle. The own vehicle running information is stored in the own vehicle running information storage unit 25f, and is stored in message data and transmitted by the transmitting unit 24b.

The transfer unit 24d transfers the message data received from another vehicle to another vehicle by one hop (HOP).
The retweet unit 24c further forwards the message data received from the other vehicle to another other vehicle according to the intention of the driver of the own vehicle.

Based on the position information included in the message data received from the other vehicle and the position information of the own vehicle, the relative position calculation unit 24f calculates the relative position of the communication partner (sender) that sent the message data to the own vehicle. calculate. When the relative position is calculated, the voice synthesizing unit 24e determines whether or not the destination of the message data transmitted from the transmission source is the own vehicle based on this relative position.

<Action>
Next, the operation of the above configuration will be described. In the following description, the vehicle equipped with the in-vehicle device 2, which is the subject of the function, is referred to as "own vehicle". Vehicles other than the own vehicle are referred to as [other vehicles]. First, the travel information calculator 24i will be described.

<Regarding Travel Information Calculation Unit 24i>
FIG. 5 is a flow chart for explaining the function of the travel information calculator 24i. The travel information calculator 24i periodically acquires the position information of the own vehicle from the GPS receiver 24j (step S91), and adds a time stamp (step S92). Next, the travel information calculation unit 24i reads the previous value of the vehicle position information from the vehicle travel information storage unit 25f (step S93), and compares it with the position information acquired this time. Then, the speed and moving direction of the own vehicle are calculated based on the change of the position information with respect to time (step S94). Next, the travel information calculation unit 24i adds a time stamp to the obtained result, and cyclically saves it as [own vehicle travel information] in the own vehicle travel information storage unit 25f (step S95). That is, by erasing old information and storing new information, a certain number of pieces of information are stored in order from the newest information. The above procedure is repeated within a processing loop (LOOP).

The cyclically stored history information of [vehicle running information] is inserted into the message data shown in FIG. 4, and information is exchanged between vehicles. The travel information of the own vehicle is received by the other vehicle, and is cyclically recorded as [other vehicle travel information] in the receiving vehicle, and becomes history information of [other vehicle travel information]. As a matter of course, all the information received from other vehicles in the own vehicle is given with the [Own vehicle driving information] of the information transmission vehicle, so it is possible to collect and store [Other vehicle driving information] from various vehicles. can be done.

A collection of such travel information can be information indicating traffic conditions in the vicinity. For example, it is possible to extract and provide the following added-value information. Moreover, this information can be collected and provided in an autonomous distributed manner, which is a great advantage in that it does not require a system for overall management such as a traffic control center system.

(1) Average running speed and speed variance for each road, lane, and time period (2) Length of forward and rearward lines centered on own vehicle (3) Around (4) Evidence data of the movement of cars in the vicinity at the time of the accident (5) Objection data when unreasonable traffic violations were exposed (6) Provision of basic data for appropriate review of speed limits These value-added information It can be a powerful driving force for overcoming the <wall of popularization>.

<Regarding the receiving unit 24g>
FIG. 6 is a flow chart for explaining the function of the receiver 24g. The receiving unit 24g acquires message data exchanged through inter-vehicle communication, stores necessary information, and executes necessary actions.

In the processing loop of FIG. 6, the receiver 24g waits for arrival of reception data (message data) from other vehicles (step S1). When the message data arrives (YES), the receiving unit 24g reads the received message data from the [Own vehicle running information], [Other vehicle running information], [Communication partner code], [Command code], Alternatively, various information such as [retweet flag] is extracted.

Next, if the [vehicle travel information] is successfully extracted, that is, if there is [vehicle travel information] in the message data (step S2: YES), the receiving unit 24g stores the other vehicle travel information storage unit 25g. The content is recorded (step S3). Also, if the message data includes [other vehicle traveling information] (step S4: YES), the reception unit 24g records the contents in the other vehicle traveling information storage unit 25g (step S5). In other words, for the own vehicle, both [Own vehicle traveling information of other vehicle] and [Other vehicle traveling information of other vehicle] are other vehicle traveling information.

Next, the receiving unit 24g determines whether or not the [retweet flag] of the message data is a value (0) indicating the 0th hop (step S6). and forwarded by one hop (step S7). A value indicating the first hop is described in the [retweet flag] of the transferred message data.

If NO in step S6, the receiving unit 24g determines whether or not the command described in the received message data is a retweet target (step S8). If NO, the receiving section 24g sends the message data to the relative position calculating section 24f to calculate the relative position of the other vehicle as the transmission source (step S11). If YES in step S8, the receiving unit 24g determines whether or not the value (2) indicating (retweeted) is described in [retweet flag] (step S9). If NO, the receiving unit 24g sends the message data to the retweeting unit 24c, and further forwards (retweet) by one hop (step S10). If YES in step S9, the reception unit 24g sends the message data to the relative position calculation unit 24f to calculate the relative position of the other vehicle as the transmission source (step S11). The above procedure is repeated within a processing loop (LOOP).

<Regarding the transfer unit 24d>
FIG. 7 is a flowchart for explaining the functions of the transfer unit 24d. In the processing loop of FIG. 7, the transfer unit 24d waits for the arrival of message data (step S21), and when the message data arrives (YES), the transfer unit 24d sets the [retweet flag] of the received message data to 1. Set the value (1) to indicate the hop number. After that, the transfer unit 24d sends the message data to the transmission unit 24b (step S23), and causes the message data to be transmitted by one hop toward the other vehicle. The above procedure is repeated within a processing loop (LOOP).

Limiting forwarding to only one hop has the following effects. In other words, it is possible to avoid the following problems that occur when a large number of transfers of two hops or more are repeated.
(a) Repeating a transfer multiple times causes an infinite loop of transfers. Under such circumstances, the amount of transfer data increases explosively, causing a so-called broadcast storm and making practical communication impossible.
(b) Even in cases where an infinite transfer loop does not occur, there are cases where the number of communication nodes (vehicles) participating in the transfer increases exponentially, and only a small portion of those communication nodes (vehicles) transfer information. There may be cases where you don't need In other words, there are cases where CPU resources and radio wave resources are wasted in transferring information that is not originally required.
(c) Currently, the multi-hop communication method between smart meters in Japan is not standardized. Therefore, it cannot be applied as is to vehicle-to-vehicle communication on a nationwide scale.

By limiting the number of transfer hops to only one hop, the system can be implemented extremely easily and simply to deal with problems such as (a) to (c). A simple and inexpensive in-vehicle device that can be so-called "pop-up" can be easily realized, and it will help to overcome the <wall of popularization>.

Note that the above concept does not change greatly even if only two hops are transferred. Although two-hop communication enables communication in a wider range than one-hop communication, there is a trade-off in that the possibilities of (a) and (b) are higher than in the case of only one hop. However, with only one-hop transfer, the reachable distance of data is limited, and communication over a wide area cannot be realized. Therefore, in the embodiment, by providing the retweet section 24c, communication over a wide area is realized. In other words, in the embodiment, simplicity is prioritized, one-hop transfer is adopted, and a process called "retweet" is applied so that information can be spread according to the intention of the driver.

<Regarding the retweet section 24c>
FIG. 8 is a flowchart for explaining the function of the retweet section 24c. When the message data is sent from the receiving unit 24g (step S31: YES), the retweeting unit 24c temporarily stores the message data in a buffer memory (not shown) or the like (step S32), and transmits the message to the voice synthesizing unit 24e. After sending the data (step S33), the procedure of step S34 is executed. If there is no received data (step S31: NO), the process proceeds directly to step S34.

In step S34, the retweet unit 24c acquires the recognition result of the voice recognition unit 24a, and determines whether or not the recognition result is "retweet" (step S34). By providing this step, it is determined whether or not to transfer the message data to the other vehicle (that is, retweet) according to the intention of the driver of the own vehicle.

If YES in step S34, the retweet unit 24c sends the message data buffered in step S32 to the transmission unit 24b, and transmits the message data to an unspecified number of other vehicles (vehicles within the wireless zone) (step S35). . That is, when the driver expresses his/her intention to retweet, the retweet unit 24c passes the message data received from the other vehicle to the transmission unit 24b, and causes the transmission unit 24b to transmit the message data to another vehicle. The above procedure is repeated within a processing loop (LOOP).

Such a processing procedure enables the information that is truly necessary for the driver to spread quickly over a wide area. In addition, it is possible to incorporate the culture of SNS (Social Networking Service), which can be expected to attract young people in particular, and it will also help to overcome the <wall of popularization>.

<Regarding the transmission unit 24b>
FIG. 9 is a flow chart for explaining the function of the transmission section 24b. Upon receiving a data transmission request from the transfer unit 24d, the voice recognition unit 24a, or the retweet unit 24c, the transmission unit 24b creates message data and transmits it to the other vehicle.
As shown in FIG. 9, the processing procedure of the transmission unit 24b has three decision blocks (steps S41, S43, S48) in a loop. In step S41, the transmission unit 24b waits for a transmission request from the transfer unit 24d. Further, in step S43, the transmission unit 24b waits for a transmission request from the voice recognition unit 24a. Also, in step S48, the transmission unit 24b waits for a transmission request from the retweet unit 24c. If a send request is caught at any step, the process jumps to processing according to each step.

If there is a transmission request from the transfer unit 24d in step S41 (YES), the transmission unit 24b requests the smart meter communication base 100 to transmit data (step S42).
If there is a transmission request from the voice recognition unit 24a in step S43 (YES), the transmission unit 24b reads own vehicle running information from the own vehicle running information storage unit 25f (step S44), Other vehicle travel information is read (step S45), and message data to be transmitted is created (step S46). Then, the transmission unit 24b requests the smart meter communication infrastructure 100 to transmit this message data (step S47).

If there is a transmission request from the retweet unit 24c in step S48 (YES), the transmission unit 24b creates message data with the retweet flag set (that is, set to 1) (step S49), and transmits this message data. A request is made to the smart meter communication base 100 (step S50).

<Regarding the relative position calculator 24f>
FIG. 10 is a flowchart for explaining the function of the relative position calculator 24f. In the processing loop, the relative position calculator 24f waits for arrival of message data from other vehicles (step S61). When the message data arrives (YES), the relative position calculator 24f reads the [vehicle travel information] shown in FIG. S62).

Next, the relative position calculation unit 24f acquires the position, speed, and direction of the vehicle from the vehicle travel information storage unit 25f (step S63). When the positions, velocities, and directions of the own vehicle and the other vehicle have been acquired so far, the relative position calculator 24f calculates the relative position between the own vehicle and the vehicle of the communication partner to which the message data has been transmitted. positional relationship, relative speed, and relative moving direction are calculated (step S64).

Next, the relative position calculator 24f determines whether the position of the caller described in the communication partner code (fifth field in FIG. 4) of the received message data matches the calculated relative positional relationship. (step S65). If both match (YES), the relative position calculator 24f determines that this message data is data sent to the own vehicle. The relative position calculator 24f then sends the message data and various information acquired from the message data to the speech synthesizer 24e (step S66). The above procedure is repeated within a processing loop (LOOP).

FIG. 11 is a diagram showing an example of correspondence between communication partner codes and relative positional relationships. The positional relationship with the receiver as seen from the sender of the message data is distinguished in detail, for example, [All], [All in front], [All in back], ..., [Left rear], [Left rear]. A communication partner code is associated in advance with each position. Based on the information sent from the relative position calculator 24f, the voice synthesizing unit 24e expresses the command content of the message data and the relative position centering on the own vehicle by voice, and conveys it to the driver of the own vehicle.

<Regarding the voice recognition unit 24a>
FIG. 12 is a flowchart for explaining the functions of the speech recognition section 24a. The voice recognition unit 24a acquires voice data uttered by the driver of the vehicle from the microphone 5 (FIG. 1) and performs voice recognition. As for speech recognition, existing techniques as shown in Non-Patent Documents 1 and 2 can be applied.

In the loop of FIG. 12, the voice recognition unit 24a determines whether or not the voice acquired from the microphone 5 has a keyword for designating the communication partner (step S81). Here, in the embodiment, in order to ensure that the keyword can be identified, the format of the voice command is fixed in advance.

FIG. 13 is a diagram showing an example of a voice command format. The voice command includes two fields, 'keyword specifying conversation partner' and 'command'. By stylizing the voice command format, it becomes possible to extract the appropriate communication partner and the appropriate command from the sound data in the company where various voices and noises fly.

FIG. 14 is a diagram showing an example of a keyword and an encoded string for designating a conversation partner. For example, for keywords such as ``all'', ``everything in general'', ``everything in this way'', etc. as seen from the own vehicle, codes ``0'', ``1'', and ``2'' for identifying each keyword are used. , . . . are associated. This information is stored in advance in the keyword storage unit 25a (FIG. 3).

FIG. 15 is a diagram showing an example of voice commands and encoded strings. Commands correspond to common codes "1", "2", "11", "12", etc. for each of multiple categories such as "gratitude", "response", "encouragement", "direction", etc. attached information. This information is stored in advance in the command definition data storage unit 25e (FIG. 3).

For example, the category "gratitude" is associated with words such as "thank you", "domo", "thank you", etc., all of which express gratitude, and any one of these commands is recognized. are coded to a common code "1". On the side receiving this command code "1", a speech expressing gratitude is synthesized and output.

Returning to FIG. 12, the description continues. When a keyword specifying a communication partner is found in the voice (step S81: YES), the speech recognition unit 24a reads a code (communication partner code) for identifying the communication partner corresponding to the keyword from the keyword storage unit 25a. (Step S82). Next, the voice recognition unit 24a determines whether or not the voice following the communication partner identification code is a command (step S83). read from

Then, the speech recognition unit 24a notifies the transmission unit 24b of the read communication partner code and command code, and requests transmission of a data message containing both codes (step S85). The communication partner code and command code are stored in each field of the format shown in FIG. The above procedure is repeated within a processing loop (LOOP).

For example, suppose that the driver of his/her own car wants to send a message to the car that is running immediately after, saying, "Please go ahead." In this case, if the driver utters a voice consisting of two phrases, ``Please go ahead,'' the speech recognition unit 24a recognizes that the other party of the communication is [following vehicle]. And it is identified that the message to be conveyed is "Please go ahead". In this way, the message data reflecting the intention of the driver is transmitted from the own vehicle.

<Regarding the voice synthesizing unit 24e>
Next, the voice synthesizing unit 24e will be described. In the embodiment, the speech synthesizing unit 24e has three main functions. That is, a function to inform the driver of the vehicle of the meaning of the received command, a function to inform the driver of the vehicle of the location of the other party who sent the message, and a function to synthesize anthropomorphic voice. The voice synthesized and output by the voice synthesizing unit 24e includes roughly two parts, as shown in FIG. 16, for example.

FIG. 16 is a conceptual diagram showing speech synthesized and output by the speech synthesizing unit 24e. A voice message loudly output within the vehicle has a [keyword part] for designating the recipient and a [phrase part] for expressing the meaning of the voice command.

FIG. 17 is a flow chart for explaining the function of the speech synthesizing section 24e. In the processing loop of FIG. 17, the speech synthesis unit 24e determines whether or not there is message data received from another vehicle (step S71). A command code included in the data is extracted (step S72).

Next, the voice synthesizing unit 24e acquires a character string for voice phrase generation corresponding to the acquired command code from the command definition data saving unit 25e (step S73). If, for example, the command code "1" is extracted in step S72, the message expresses "thank you", so the corresponding character string "thank you" is acquired.

FIG. 18 is a diagram showing an example of the correspondence between character strings for voice phrase generation and command codes. This information is stored in advance in the command definition data storage unit 25e. As shown in FIG. 18, a character string of a predetermined pattern is assigned to each command code. In other words, no matter what kind of sound is produced by the originating vehicle, only a specific pattern of sound is produced by the receiving vehicle. By doing so, it is possible to prevent slanderous messages and message exchanges that encourage incitement. In addition, a function of conveying the meaning of the received command to the driver of the own vehicle is realized. In FIG. 17, next, the voice synthesizing unit 24e reads the calling vehicle type from the received message data (step S74). Information indicating the type of caller vehicle is described in the eighth field of the message data as shown in FIG. Next, the voice synthesizing unit 24e reads out the voice quality definition data corresponding to each vehicle type from the vehicle type voice quality definition data storage unit 25c (step S75).

FIG. 19 is a diagram showing an example of voice quality data defined for each vehicle type. For example, for a large truck, information such as [height] (low), [blur] (large), [harmonics] (small), . . . is defined in advance.

FIG. 20 is a diagram showing an example of voice quality data defined for each vehicle color. For example, for reddish colors, information that makes people imagine young people is defined in advance, such as [height] is (high), [blur] is (none), [harmonics] is (low), and so on. .

While the vehicle is running, the driver makes a rough image of the driver based on the model and color of the other vehicle. For example, if you see a black heavy-duty truck, you may imagine a large male driver with a deep voice, and if you see a pink light car, you may imagine a small female driver with a thin voice. deaf.

Therefore, the vehicle type and external color of the own vehicle are registered in the on-vehicle device 2, and these information are transmitted as originating vehicle attribute information for inter-vehicle communication. On the receiving side receiving this, by synthesizing the voice of the impression corresponding to the vehicle type and exterior color, it becomes possible to support the identification of the vehicle that originated the communication.

For example, if a message is played in a slender female voice while only one pink mini vehicle is driving around the driver, the driver can easily recognize that the message is from that mini vehicle. can recognize.

Returning to FIG. 17, the description continues. Next, the speech synthesizing unit 24e reads the driver attributes from the ninth field (FIG. 4) of the received message data (step S76). Next, the voice synthesizing unit 24e reads the voice quality definition data corresponding to the driver attribute from the voice quality definition data storage unit 25d for each driver attribute (step S77).

FIG. 21 is a diagram showing an example of voice quality data defined for a driving history. For example, for a veteran driver, information that gives a feeling of calmness is defined in advance, such as [height] (medium), [blur] (none), [harmonics] (low), and so on. .

Finally, the voice synthesizing unit 24e synthesizes the voice generating character string according to the combination of the read voice quality definition data (step S78), so to speak, <personification> of the calling car. The above procedure is repeated within a processing loop (LOOP).

<About the function to transmit the location of the receiving party>
A function for transmitting the location of the receiving party will be described. The voice synthesizing unit 24e synthesizes and outputs a keyword (FIG. 14) designating a recipient from the relative position information between the own vehicle and the recipient vehicle sent from the relative position calculator 24f. As a result, the driver of the own vehicle can be accurately informed of the relative position of the other vehicle.

FIG. 22 is a diagram showing an example of keywords expressing the relative positions of the own vehicle and the opponent vehicle. For example, a keyword designating the other party such as "previous car" is associated with a vehicle whose relative position is immediately before or in front of the own vehicle. Keywords are not limited to the terms shown in FIG. Any term may be used as long as the keyword is associated with the positional relationship between the own vehicle and the other vehicle when heard as a voice.

Furthermore, the speech synthesizing unit 24e forms a three-dimensional sound field in the passenger space of the own vehicle. That is, the voice synthesizing unit 24e synthesizes a three-dimensional sound image at a position corresponding to the position of the communication partner as seen from the driver, based on the relative positional relationship between the communication partner and the own vehicle. Thereby, it is possible to support the driver to specify the communication partner.

For example, for a message received from a vehicle running behind, the sound image is localized behind the driver so that the driver can easily recognize that the message is from the vehicle behind the driver. . The same applies to the front and sides.

Furthermore, when synthesizing a three-dimensional sound image based on the speed and direction of movement of the communication partner, temporal changes in sound image position and Doppler effect may be given according to the movement of the communication partner. In other words, the position and pitch of the sound image may be changed to reflect the relative speed and relative movement direction of the communication partner. By doing so, it becomes easier for the driver to identify the communication partner.

For example, by synthesizing a message from a car in the oncoming lane as a sound image that moves from the right front to the right rear with the Doppler effect, the driver can easily recognize that the message is coming from the oncoming car. It is possible to

<About the function to synthesize anthropomorphic voice>
Personification can be realized, for example, by parameterizing the sound quality for speech synthesis and implementing an adjustable function in the speech synthesizing unit 24e. Anthropomorphization can help the driver to identify the communication partner from another aspect.

It should be noted that the term anthropomorphic in the embodiment means giving voice a virtual personality by controlling the voice quality used for voice synthesis. As shown in Non-Patent Document 1, recent advances in speech synthesis technology have made it possible to select speakers of a wide range of ages and genders to create speech data, combine emotions of joy, anger, sorrow, and comfort, and create voice data. By adjusting the intonation, speed, etc., it has become possible to synthesize speech with rich expressiveness. Alternatively, as described in Non-Patent Document 2, it is also possible to synthesize speech based on voice data of a specific person. By repeatedly conducting communication using anthropomorphism, it is possible for the driver to identify the communication partner only from the sound quality of the voice, and it is possible to recognize that it is the usual person. Become.

<Personification by driver attributes>
Anthropomorphization by driver attributes will be described in detail. For example, consider the following three driver attributes.
(1) Driving history (2) Gender/age (3) Home prefecture <Personification according to driving history>
While driving, the driver drives while changing his consciousness according to the driving experience of the other driver. For example, when a beginner or an elderly person is driving, they are conscious of maintaining a distance between vehicles and smooth lane changes.
Therefore, when the in-vehicle device 2 is initialized, the driving history of the driver of the own vehicle is registered, and the driving history is exchanged between vehicles as driver attribute information. The vehicle that receives the message data synthesizes voice with a timbre that gives an impression according to the driving history of the driver of the communication partner, thereby supporting the identification of the driving history of the vehicle that originated the communication. For example, it is possible to express the driving history of the originating vehicle by synthesizing a soft and calm voice for a veteran driver and a timid and timid voice for a beginner. The definition data in FIG. 21 reflects such attributes. It is also conceivable to classify the driving level into beginner, intermediate, and advanced according to, for example, one month's running distance, and use voice quality corresponding to each driving level.

In an example of an actual driving scene, if a message with a timid and timid voice is played while only one car with a beginner's mark is running around the driver, the driver will It is possible to easily recognize that the message is from a beginner's car.

<Personification according to gender and age>
While driving, the driver drives while changing his consciousness according to the gender and age of the other driver. For example, even if a middle-aged and elderly female driver is traveling at a significantly slower speed than the traffic around her, she thinks "it can't be helped..." and drives. Or, even if a young man is driving a sports car at a speed faster than the surrounding traffic, he may drive thinking, "It can't be helped, let's not get too close...". Such information can be effective information for preventing driving frustration, and has the effect of reducing the risk of traffic accidents.

Therefore, when initializing the in-vehicle device 2, the sex and age of the driver of the own vehicle are registered, and the information is transmitted as driver attribute information for inter-vehicle communication. The vehicle that receives this can synthesize voice with tone colors that give an impression according to the gender and age of the driver of the other party, thereby supporting driving according to the other party. For example, by synthesizing a young female driver with a thin, high-pitched voice and an elderly male with a calm and dandy voice, it is possible to express the gender and generation of the calling vehicle.

<Personification according to home prefecture>
While driving, drivers sometimes drive while changing their consciousness according to the prefecture of origin, which can be known from the license plate of the other car. For example, cars with out-of-prefecture license plates may behave unpredictably and erratically, or, based on empirical rules, drivers in specific prefectures drive rough.

Therefore, when the in-vehicle device 2 is initialized, the registration prefecture of the own vehicle is registered, and the information is transmitted as driver attribute information for inter-vehicle communication. When the vehicle receives the message data, it can synthesize voice with a tone using a (famous) dialect according to the registered prefecture of the other party, thereby supporting driving according to the other party. In addition, by repeating such communication repeatedly, it becomes possible for the drivers to recognize each other as "that same person."

Dialects can be easily switched by preparing message data for speech synthesis corresponding to commands for each prefecture.

FIG. 23 is a diagram showing an example of voice message data for the dialect of Hiroshima Prefecture. The character string for generating a spoken phrase in the standard language shown in FIG.
FIG. 24 is a diagram showing an example of voice message data for dialect of Osaka prefecture. It is an expression that clearly shows the characteristics of the Kansai dialect. Local information to which the dialect should be applied can also be inferred to some extent from the license plate of the vehicle.

By anthropomorphizing, for example, the following effects can be obtained.

(1) It makes it easier for the driver to identify the communication partner.
(2) Mutual recognition between drivers will improve, and mutual consideration will lead to a reduction in accidents.
(3) Mutual understanding between drivers will be deepened, leading to a reduction in accidents due to less frustration.
(4) Familiarity is gained, so it helps to overcome the <wall of popularization>.
In this way, personification can support communication between drivers.

<effect>
As described above, according to the embodiment, by exchanging message data through inter-vehicle communication, it becomes possible to promote the spread of inter-vehicle communication systems from various aspects. Moreover, information sharing among vehicles can be promoted by autonomous decentralized processing among a plurality of vehicles without requiring a central device.

Also, since the number of transfer hops is limited to one hop, there is no fear of communication congestion such as a broadcast storm. In addition to this, by providing a process called retweet, important information can be spread not in one hop, but in two hops, three hops, and so on, and the intention of the driver can be reflected in information transmission. can be done.

By implementing both the one-hop transfer function and the retweet function as an application layer by software, the scale of the in-vehicle device 2 can be reduced and realized as a so-called "pong-attached" type in-vehicle device. By using the smart meter communication infrastructure 100, the communication function can be further simplified, and the reduction in size and weight can be further promoted.

Furthermore, by forming a three-dimensional sound image using 4-channel speakers, and controlling the localization position of the sound image and freely moving it, it becomes easy to grasp the vehicle of the communication partner.

In addition, according to the embodiment, information such as position information, moving speed, moving direction, etc. of each vehicle is exchanged as [own vehicle driving information] and [other vehicle driving information], so that traffic information can be shared locally. environment can be formed.

Furthermore, by using [Own vehicle driving information] and [Other vehicle driving information] and managing the history, it is possible to obtain statistical information such as the average value and variance of the driving speed of the driving lane. become. Based on such information, for example, the number of vehicles in front of and behind the own vehicle is calculated, and if the difference between the speed of the own vehicle and the average speed of the current lane is below a specified value, An application such as notifying a traffic jam warning alarm to a driver when the conditions are satisfied that there are a number of cars in a line and that a car is running in the lead can also be considered.

In addition, average vehicle speed information for each lane, the number of vehicles in front of and behind the own vehicle, a means to collect witness vehicle data when a traffic accident occurs, or bird's-eye view data including the movement of surrounding vehicles when a traffic accident occurs The in-vehicle device 2 can also be applied as a means for providing In other words, the in-vehicle device 2 can be used as a complement to the drive recorder.

While several embodiments of the invention have been described, these embodiments are provided by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and modifications can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the scope of the invention described in the claims and equivalents thereof.

Claims (18)

a receiving unit that receives from the other vehicle message data including at least a command code corresponding to the intention of the driver of the other vehicle and position information of the other vehicle;
When it is determined that the destination of the message data is the vehicle based on the position information contained in the message data and the position information of the vehicle, a voice message is synthesized from the command code contained in the message data. a speech synthesizer that
a transfer unit that transfers the received message data by one hop;
and a retweet unit that further forwards the received message data according to the intention of the driver of the vehicle . Receiving from the other vehicle message data including at least a command code corresponding to the intention of the driver of the other vehicle, position information of the other vehicle, and code information identifying a communication partner when viewed from the other vehicle. Department and
When it is determined that the destination of the message data is the vehicle based on the position information and the code information contained in the message data and the position information of the vehicle, a command code contained in the message data is voiced. a speech synthesizer that synthesizes a message;
In- vehicle device. 3. A relative position calculator for calculating a relative position of a communication partner to which the message data is transmitted based on the position information included in the message data and the position information of the vehicle. In-vehicle device according to . 4. The in-vehicle device according to claim 3, wherein said speech synthesizer determines whether or not the destination of said message data is said vehicle based on said calculated relative position. 4. The method according to claim 3, wherein, when the own vehicle has a plurality of speakers, the voice synthesizing unit localizes a sound image at a position reflecting the calculated relative position of the communication partner and outputs the voice message in loud voice. In-vehicle device. The relative position calculation unit calculates a relative speed and a relative movement direction of the communication partner to the own vehicle based on the position information included in the message data and the position information of the own vehicle,
6. The in-vehicle device according to claim 5, wherein said speech synthesizer changes the position and pitch of said sound image so as to reflect the calculated relative speed and relative movement direction of said communicating party. 6. The in-vehicle device according to claim 5, wherein said voice synthesizing unit outputs a personified voice message according to the vehicle type of said communication partner . 6. The in-vehicle device according to claim 5, wherein said voice synthesizing unit outputs an anthropomorphic voice message according to attributes of a driver of said communication partner vehicle. 3. The in-vehicle device according to claim 1, further comprising a transmission unit that transmits message data including at least a command code corresponding to the intention of the driver of the own vehicle and position information of the own vehicle. Further equipped with a voice recognition unit that recognizes the voice uttered by the driver of the vehicle,
The in-vehicle device according to claim 9, wherein said transmission unit includes said command code based on said recognition result in said message data and transmits said message data . further comprising a travel information calculation unit that acquires position information of the own vehicle and calculates travel information of the own vehicle;
The in-vehicle device according to claim 9, wherein said transmission unit includes said travel information in said message data and transmits said message data . The travel information calculation unit calculates travel history information of the own vehicle including history data in which the location information, moving direction, and moving speed of the own vehicle are associated with the identification information of the own vehicle together with a time stamp,
12. The in-vehicle device according to claim 11 , wherein said transmission unit includes said vehicle's travel history information in said message data and transmits the message data. 13. The in-vehicle device according to claim 12, wherein the transmission unit further includes travel history information of the other vehicle received from the other vehicle in the message data and transmits the message data. When the number of convoys behind the own vehicle calculated based on the travel history information of the own vehicle and the travel history information of the other vehicle included in the received message data exceeds a specified number, the speech synthesis is performed. 14. The in-vehicle device of claim 13, wherein the unit generates a warning message . 10. The in-vehicle device according to claim 9 , wherein said receiving unit and said transmitting unit transmit and receive said message data using a specified low-power wireless communication infrastructure. an in-vehicle device according to claim 15;
A vehicle-to-vehicle communication system comprising a specific low-power wireless communication infrastructure that mediates transmission and reception of the message data between vehicles. A program writable in the memory of an in-vehicle device comprising a processor and a memory,
a command for causing the processor to receive from the other vehicle message data including at least a command code corresponding to the intention of the driver of the other vehicle and position information of the other vehicle;
When the processor determines that the destination of the message data is the own vehicle based on the position information included in the message data and the position information of the own vehicle, from the command code included in the message data instructions for synthesizing a voice message ;
instructions for causing the processor to forward the received message data by one hop;
and a command for causing the processor to further transfer the received message data according to the intention of the driver of the own vehicle . A program writable in the memory of an in-vehicle device comprising a processor and a memory,
The processor is provided with message data including at least a command code corresponding to the intention of the driver of the other vehicle, location information of the other vehicle, and code information identifying a communication partner when viewed from the other vehicle. an instruction to receive from
When the processor determines that the destination of the message data is the own vehicle based on the position information and the code information included in the message data and the position information of the own vehicle, the code information is included in the message data. and instructions for synthesizing voice messages from command codes.

Images