Vehicle routing control based on user-provided travel constraints

Abstract

The present invention is entitled "Vehicle route control based on user-provided trip constraints". The present invention discloses a system and method for determining a vehicle route based on user-provided trip constraints. The method includes the following steps: receiving user trip parameters of a vehicle trip from a vehicle user via a human-machine interface, wherein the vehicle trip includes a starting location and an ending location, and wherein the user trip parameters include a nausea reduction option; accessing geographic road map data corresponding to an area of ​​the vehicle trip; determining multiple potential routes for the vehicle trip based on the user trip parameters and the geographic road map data; determining a cumulative nausea index score for each potential route; and selecting one of the potential routes as the vehicle route for the vehicle trip based on the cumulative nausea index score.

Description

Background Art

[0001] The present invention relates to automatic route planning for vehicle navigation systems.

[0002] The vehicle includes hardware and software that can obtain and process various information, including information obtained by the vehicle system module (VSM). In addition, the vehicle includes networking capabilities and can connect to a vehicle backend server that provides information to the vehicle. Moreover, many vehicles include navigation capabilities for which the vehicle user can input information, such as the starting location and / or ending location of a trip to be taken by the vehicle user. Summary of the invention

[0003] According to one aspect of the present invention, a method for determining a vehicle route based on a trip constraint provided by a user is provided. The method comprises the following steps: receiving user trip parameters of a vehicle trip from a vehicle user via a human-machine interface, wherein the vehicle trip includes a starting location and an ending location, and wherein the user trip parameters include a nausea reduction option; accessing geographic road map data corresponding to an area of ​​the vehicle trip; determining a plurality of potential routes of the vehicle trip based on the user trip parameters and the geographic road map data; determining a cumulative nausea index score for each potential route; and selecting one of the potential routes as the vehicle route of the vehicle trip based on the cumulative nausea index score.

[0004] According to various embodiments, the method may also include any of the following features or any technically feasible combination of some or all of these features:

[0005] The HMI is the vehicle user interface, which is installed on the vehicle as part of the vehicle electronics.

[0006] Determining a plurality of potential routes based on at least some user travel parameters;

[0007] each cumulative nausea index score comprises a score or value calculated based on a plurality of nausea index scores determined for a plurality of potential nausea inducing events that are part of the potential route;

[0008] Determining a cumulative nausea index score for each potential route includes performing at least one nausea index score determination process for each potential route;

[0009] The nausea index score determination process is an iterative process that is performed for each of a number of potential nausea inducing events for each potential route;

[0010] a nausea index score determination process comprising identifying each potential nausea inducing event, determining a nausea index score for each potential nausea inducing event, and then updating a cumulative nausea index score based on the nausea index score for each potential nausea inducing event;

[0011] the nausea index score for at least some of the potentially nausea inducing events is based on a turn angle of the potentially nausea inducing event and an acceleration of the potentially nausea inducing event; and / or

[0012] • The nausea index score for at least some of the potentially nausea inducing events is based on the velocity of the potentially nausea inducing event.

[0013] According to another aspect of the present invention, a method for determining a vehicle route based on a trip constraint provided by a user is provided. The method comprises the following steps: receiving user trip parameters of a vehicle trip from a vehicle user via a human-machine interface, wherein the vehicle trip includes a starting location and an ending location; obtaining geographic road map data corresponding to an area of ​​the vehicle trip; determining multiple potential routes of the vehicle trip based on the user trip parameters and the geographic road map data, wherein each potential route includes one or more road segments geographically connecting the starting location and the ending location; filtering the multiple potential routes of the vehicle trip based on the compatibility of the vehicle with each potential route to obtain one or more filtered potential routes; and selecting one or more filtered potential routes to present to the vehicle user.

[0014] According to various embodiments, the method may also include any of the following features or any technically feasible combination of some or all of these features:

[0015] The method further comprises the step of determining a cumulative nausea index score for each filtered potential route;

[0016] · performing a vehicle compatibility assessment process for each road segment of each of a plurality of potential routes of the vehicle's journey;

[0017] The vehicle compatibility evaluation process includes obtaining, using the vehicle compatibility evaluation process, a road attribute of a current road segment being evaluated for compatibility with the vehicle;

[0018] The vehicle compatibility evaluation process further includes obtaining vehicle compatibility information of the vehicle, and comparing the vehicle compatibility information with a road attribute of a current road section to determine whether the current road section is compatible with the vehicle;

[0019] at least some of the vehicle compatibility information includes or is based on onboard sensor data obtained by one or more onboard sensors of the vehicle;

[0020] After determining the road attributes, obtaining vehicle sensor data from one or more vehicle sensors;

[0021] at least some of the vehicle compatibility information is based on vehicle specification information obtained from a remote server;

[0022] At a time prior to executing the method, obtaining at least some vehicle compatibility information from a remote server;

[0023] At a time subsequent to the receiving step, obtaining at least some vehicle compatibility information from a remote server; and / or

[0024] • All filtered potential routes are presented to a vehicle user, and wherein the method further comprises the step of receiving a user selection of one of the filtered potential routes as the vehicle route. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] One or more embodiments of the present invention will be described below with reference to the accompanying drawings, wherein like reference numerals represent like elements, and wherein:

[0026] Figure 1 is a block diagram illustrating an embodiment of a communication system capable of utilizing the methods disclosed herein;

[0027] Figure 2 is a flow chart of an embodiment of a method for determining a vehicle route based on human and machine constraints;

[0028] Figure 3 Can be used as Figure 2 A flow chart of an embodiment of a vehicle compatibility assessment process of a portion of a method;

[0029] Figure 4 depicts a map showing two route options for a trip between a starting location and an ending location;

[0030] Figure 5 Can be used as Figure 2 A flowchart of an embodiment of a nausea index score determination process as part of a method;

[0031] Figure 6 is a diagram showing turning angles for a regular or typical four-way intersection; and

[0032] Figure 7 1 is a diagram showing turning angles at a four-way intersection on a roundabout. DETAILED DESCRIPTION

[0033] The systems and methods described below enable determination of a vehicle route for a vehicle trip based on human and machine constraints. Human constraints are user-provided trip constraints that are received as input via a human-machine interface, and machine constraints are constraints that are automatically determined by an electronic vehicle system without user input. Machine constraints are used to determine or indicate whether a particular vehicle is compatible with a particular route. Such compatibility determination may be based on vehicle specification information and / or on-board sensor information (e.g., diagnostic information, fluid level information, state of charge (SoC) information). Human constraints may include a nausea reduction option that may be selected by a vehicle user. When the nausea reduction option is selected, a route determined to cause the least amount of nausea may be selected as the vehicle route for the vehicle trip.

[0034] In one scenario, an autonomous vehicle (AV) may be used as a vehicle to perform a vehicle trip. In the case of a fully autonomous vehicle, the vehicle user and passengers may wish to use a mobile device, such as a laptop or smart phone. Many people experience motion sickness while riding in a vehicle. Motion sickness may worsen when the vehicle user does not look up at the road or out the window. Motion sickness may worsen when the vehicle is traveling along a vehicle route that includes many potential nausea-inducing events, such as vehicle turns (including curves along the road), stops, acceleration events (e.g., entering a highway via an entrance ramp), and other events that cause the direction and / or speed of the vehicle to change. In order to help avoid motion sickness, the methods and systems discussed herein provide a nausea reduction option, which can be selected by a vehicle user who wishes to take a vehicle route that causes (or is determined to cause) less motion sickness or nausea, even if, for example, the vehicle route may require more time and / or vehicle energy (e.g., gasoline, battery power).

[0035] refer to Figure 1 , an operating environment is shown that includes a communication system 10 and that can be used to implement the methods disclosed herein. The communication system 10 generally includes a vehicle 12 having a wireless communication device 30 and other VSMs 22-66, a constellation of global navigation satellite system (GNSS) satellites 68, one or more wireless carrier systems 70, a land communication network 76, a computer or server 78, a vehicle backend service facility 80, and a handheld wireless device (HWD) 90. It should be understood that the disclosed methods can be used with any number of different systems and are not specifically limited to the operating environment shown herein. In addition, the architecture, construction, setup, and general operation of the system 10 and its various components are well known in the art. Therefore, the following paragraphs only provide a brief overview of such a communication system 10; however, other systems not shown here may also employ the disclosed methods.

[0036] The wireless carrier system 70 may be any suitable cellular telephone system. The carrier system 70 is shown as including a cellular tower 72; however, the carrier system 70 may include one or more of the following components (e.g., depending on the cellular technology): a cellular tower, a base transceiver station, a mobile switching center, a base station controller, an evolved node (e.g., eNodeB), a mobility management entity (MME), a serving gateway, and a PGN gateway, etc., as well as any other networking components required to connect the wireless carrier system 70 to a land network 76 or to connect the wireless carrier system to a user equipment (UE, which may include, for example, a telematics device in the vehicle 12). The carrier system 70 may implement any suitable communication technology, including GSM / GPRS technology, CDMA or CDMA2000 technology, LTE technology, etc. In general, the wireless carrier system 70, its components, the arrangement of its components, the interaction between the components, etc. are well known in the art.

[0037] In addition to using wireless carrier system 70, a different wireless carrier system in the form of satellite communications may be used to provide one-way or two-way communications with the vehicle. This may be accomplished using one or more communications satellites (not shown) and an uplink transmitter (not shown). For example, one-way communications may be a satellite radio service, where program content (news, music, etc.) is received by an uplink transmitter, packaged for upload, and then sent to a satellite, which broadcasts the programming to subscribers. Two-way communications may be, for example, a satellite telephone service, which uses one or more communications satellites to relay telephone communications between vehicle 12 and an uplink transmitter. If used, the satellite telephone may be used in addition to or as an alternative to wireless carrier system 70.

[0038] Land network 76 may be a conventional land-based telecommunications network that is connected to one or more landline telephones and connects wireless carrier system 70 to vehicle backend service facilities 80. For example, land network 76 may include a public switched telephone network (PSTN), such as that used to provide hardwired telephone, packet-switched data communications, and Internet infrastructure. One or more portions of land network 76 may be implemented using standard wired networks, fiber optic or other optical networks, cable networks, power lines, other wireless networks such as wireless local area networks (WLANs), or networks that provide broadband wireless access (BWA), or any combination thereof.

[0039] Computers 78 (only one shown) may be some of a plurality of computers accessible via a private or public network such as the Internet. In one embodiment, each such computer 78 may be used for one or more purposes, such as for providing navigation services and / or geographic road map data to a plurality of vehicles and other electronic network computing devices (including the vehicle 12 and / or the HWD 90). Other such accessible computers 78 may be, for example: a service center computer, where diagnostic information and other vehicle data may be uploaded from the vehicle; a client computer used by a vehicle owner or other subscriber for purposes such as accessing or receiving vehicle data or setting or configuring subscriber preferences or controlling vehicle functions; a car sharing server that coordinates registrations from a plurality of subscribers requesting to use a vehicle as part of a car sharing service; or a third-party repository to which vehicle data or other information is provided, whether through communication with the vehicle 12, with the backend facility 80, or with both. Computers 78 may also be used to provide Internet connectivity such as DNS services, or to serve as a network address server that assigns IP addresses to vehicles 12 using DHCP or other suitable protocols.

[0040] The vehicle backend service facility 80 is a backend facility and is located at a physical location located away from the vehicle 12. The vehicle backend service facility 80 (or simply "backend facility 80") can be designed to provide many different system backend functions for the vehicle electronic device 20 by using one or more electronic servers 82, and in many cases, can provide navigation-related services to multiple vehicles. In one embodiment, the backend facility 80 provides route suggestions, as described in more detail below. The vehicle backend service facility 80 includes a vehicle backend service server 82 and a database 84, which can be stored on multiple memory devices. The vehicle backend service facility 80 may include any one or all of these various components, and preferably, each of the various components is coupled to each other via a wired or wireless local area network. The backend facility 80 can receive and transmit data via a modem connected to the land network 76. Data transmission can also be performed by wireless systems such as IEEE 802.11x, GPRS, etc. It will be understood by those skilled in the art that although only one backend facility 80 and one computer 78 are shown in the illustrated embodiment, many backend facilities 80 and / or computers 78 can be used. Furthermore, as will be appreciated by those skilled in the art, multiple backend facilities 80 and / or computers 78 may be geographically distributed and may each coordinate information and services with one another.

[0041] The server 82 may be a computer or other computing device including at least one processor and including a memory. The processor may be any type of device capable of processing electronic instructions, including a microprocessor, a microcontroller, a host processor, a controller, a vehicle communication processor, and an application-specific integrated circuit (ASIC). The processor may be a dedicated processor used only for the server 82, or may be shared with other systems. The at least one processor may execute various types of digital storage instructions such as software or firmware, which enable the server 82 to provide a variety of services, such as performing one or more method steps as described below. The software may be stored in a computer-readable memory and may be any suitable non-transient computer-readable medium. For example, the memory may be any of many different types of RAM (random access memory, including various types of dynamic RAM (DRAM) and static RAM (SRAM)), ROM (read-only memory), solid-state drive (SSD) (including other solid-state storage devices, such as solid-state hybrid drive (SSHD)), hard disk drive (HDD), disk or optical drive. For network communications (e.g., intra-network communications, inter-network communications including Internet connections), the server may include one or more network interface cards (NICs) (including wireless NICs (WNICs)) that can be used to transmit data to and from a computer. These NICs may allow one or more servers 82 to connect to each other, to a database 84, or to other networking devices (including routers, modems, and / or switches). In a specific embodiment, the NICs (including WNICs) of the servers 82 may allow for the establishment of SRWC connections and / or may include Ethernet (IEEE 802.3) ports to which Ethernet cables may be connected, which may provide data connections between two or more devices. The backend facilities 80 may include a number of routers, modems, switches, or other network devices that may be used to provide networking capabilities, such as connecting to a land network 76 and / or a cellular carrier system 70.

[0042] The database 84 may be stored on a plurality of memories, such as power-on temporary memory or any suitable non-transitory computer-readable medium. For example, the memory may be any of many different types of RAM (random access memory, including various types of dynamic RAM (DRAM) and static RAM (SRAM)), ROM (read-only memory), solid-state drive (SSD) (including other solid-state storage devices, such as solid-state hybrid drive (SSHD)), hard disk drive (HDD) and / or magnetic or optical disk drive. The one or more databases at the back-end facility 80 may store a variety of information and may include a road information database and / or a vehicle information database.

[0043] The road information database may include road information related to multiple road segments. As used herein, a road segment is a segment or portion of a road. In some cases, a vehicle may travel off-road or on the ground along an unspecified road; this information may be stored in a road information database, and at least in one embodiment, these paths may be considered as road segments. The road information may include geographic information (e.g., geographic coordinates), physical road attributes (e.g., road type, road geometry information), road operation attributes (e.g., speed limits, weight / mass limits, permitted vehicle types, proximity or presence of gas stations and / or electric vehicle charging stations, permitted driving directions, lane information, traffic signal information, energy usage information (i.e., information for predicting or estimating the amount of gasoline and / or electrical energy used during travel along a road segment)), road conditions (e.g., current or estimated traffic conditions, predicted and / or observed weather conditions along the road), and / or other information related to the road. Any road information may include (or at least be associated with) geographic coordinates or other location identification information, which may be used to bind data to a specific geographic point or area, such as a specific road segment. The road information database may also store geographic road map data, which includes data representing geographic regions and roads in one or more geographic regions. In some embodiments, the geographic road map data may include or be associated with physical road attributes, road operating attributes, and / or other road information.

[0044] The vehicle information database may include vehicle specification information, which is information about vehicle specifications, such as make, model, model year, standard features, optional features, aftermarket features, propulsion system type (e.g., electric, hybrid, internal combustion engine (ICE)), battery type, number of battery cells, other vehicle system module (VSM) information (e.g., vehicle sensor information), vehicle network information, vehicle mass, vehicle length, vehicle width, vehicle height, other physical vehicle attributes, and various other information related to a fleet or a specific vehicle (such as vehicle 12). It should be understood that any or all of the information stored in the vehicle information database or the road information database may be stored in one or more databases at one or more locations or facilities and may be operated and / or managed by one or more relevant entities (including the OEM of the vehicle).

[0045] The handheld wireless device (HWD) 90 is a mobile device and a SRWC device (i.e., a device with SRWC capabilities) and may include: hardware, software and / or firmware that enable cellular telecommunications and SRWC and other mobile device applications (such as, vehicle management applications). The hardware of the HWD 90 may include: a processor and a memory for storing software, firmware, etc. The processor and memory of the HWD 90 may be any of those types discussed with respect to the processor 36 and memory 38 of the wireless communication device 30. The HWD processor and memory may enable a variety of software applications that may be pre-installed or installed by the user (or manufacturer) (e.g., with a software application or a graphical user interface (GUI)). In one embodiment, the HWD 90 includes applications that enable a vehicle user to communicate with the vehicle 12 (e.g., such as entering route or trip parameters), and / or control various aspects or functions of the vehicle, some of which are listed above. In addition, one or more applications may allow a user to connect with a backend facility 80 or a call center advisor at any time.

[0046] In one specific embodiment, the HWD 90 can be a personal cellular SRWC device that includes a cellular chipset and / or cellular connectivity capabilities and SRWC capabilities. For example, using a cellular chipset, the HWD can be connected to various remote devices (including a computer 78 and a backend facility 80) via a wireless carrier system 70. As used herein, a personal SRWC device is a mobile device capable of SRWC that can be carried by a user, and where the portability of the device depends at least in part on the user, such as a wearable device (e.g., a smart watch), an implantable device, or a handheld device (e.g., a smartphone, a tablet computer, a laptop computer). As used herein, a short-range wireless communication (SRWC) device is a device capable of SRWC. In some embodiments, the HWD 90 is a personal SRWC device.

[0047] The processor of the HWD 90 may be any type of device capable of processing electronic instructions, including a microprocessor, a microcontroller, a host processor, a controller, a vehicle communication processor, and an application specific integrated circuit (ASIC). The processor executes various types of digitally stored instructions, such as software or firmware programs stored in the memory of the HWD 90, which enable the device 90 to provide a variety of functions. For example, in one embodiment, the processor may execute programs or process data. In some embodiments, the HWD 90 may be a computer that includes an operating system (such as Android). TM 、iOS TM 、MicrosoftWindows TMand / or other operating systems). The memory of the HWD 90 may include any suitable non-transitory computer-readable medium; these include different types of RAM (random access memory, including various types of dynamic RAM (DRAM) and static RAM (SRAM)), ROM (read-only memory), a solid-state drive (SSD) (including other solid-state storage devices such as a solid-state hybrid drive (SSHD)), a hard disk drive (HDD), or a magnetic or optical disk drive.

[0048] HWD 90 may also include short range wireless communication (SRWC) circuitry and / or chipsets and one or more antennas that allow it to perform SRWC, such as IEEE 802.11 protocols, Wi-Fi TM 、WiMAX TM 、ZigBee TM 、Wi-Fi Direct TM 、Bluetooth TM or near field communication (NFC). The SRWC circuitry and / or chipset may allow the HWD 90 to connect to another SRWC device. Additionally, as described above, the HWD 90 may include a cellular chipset, allowing the device to communicate via one or more cellular protocols, such as GSM / GPRS technology, CDMA or CDMA2000 technology, and LTE technology. The HWD 90 may use the cellular chipset and antenna to transmit data through the wireless carrier system 70.

[0049] In the illustrated embodiment, the vehicle 12 is depicted as a passenger car, but it should be understood that any other vehicle including motorcycles, trucks, sport utility vehicles (SUVs), recreational vehicles (RVs), boats, airplanes, etc. may be used. Some vehicle electronics 20 are generally located in Figure 1, and includes a global navigation satellite system (GNSS) receiver 22, a body control module or unit (BCM) 24, other vehicle system modules (VSM) 28, a wireless communication device 30, an autonomous vehicle (AV) controller 40, a vehicle user interface 50-56, and a battery system 60. In the illustrated embodiment, the vehicle 12 is an electric vehicle that primarily uses the battery system 60 for propulsion, such as a battery electric vehicle (BEV). However, in other embodiments, the vehicle 12 can be a hybrid (e.g., a plug-in hybrid electric vehicle (PHEV)) or an internal combustion engine (ICE) vehicle. Some or all of the different vehicle electronic devices can be connected via one or more communication buses (such as bus 58) for communication with each other. The communication bus 58 provides network connections for the vehicle electronic devices using one or more network protocols. Examples of suitable network connections include a controller area network (CAN), a media-oriented system transport (MOST), a local interconnect network (LIN), a local area network (LAN), and other suitable connections, such as Ethernet or other suitable connections that comply with known ISO, SAE and IEEE standards and specifications, to name a few. In other embodiments, each VSM may communicate using a wireless network and may include appropriate hardware, such as short range wireless communication (SRWC) circuitry.

[0050] The vehicle 12 may include a plurality of vehicle system modules (VSMs) as part of the vehicle electronics 20, such as a GNSS receiver 22, a BCM 24, a wireless communication device 30, an AV controller 40, a vehicle user interface 50-56, and a battery system 60, which will be described in detail below. The vehicle 12 may also include other VSMs 28 in the form of electronic hardware components located throughout the vehicle that may receive input from one or more sensors and use the sensed input to perform diagnostic, monitoring, control, reporting, and / or other functions. Each VSM 28 is connected to the other VSMs and to the wireless communication device 30 via a communication bus 58. One or more VSMs 28 may have their software or firmware updated periodically or occasionally, and in some embodiments, such vehicle updates may be over-the-air (OTA) updates received from a computer 78 or a backend facility 80 via a land network 76 and a communication device 30. As will be appreciated by those skilled in the art, the above-described VSMs are merely examples of some of the modules that may be used in the vehicle 12, as many other modules are possible.

[0051] The global navigation satellite system (GNSS) receiver 22 receives radio signals from a constellation of GNSS satellites. The GNSS receiver 22 may be configured to comply with and / or operate in accordance with specific regulations or laws of a given geopolitical region (e.g., a country). The GNSS receiver 22 may be configured to be used with various GNSS implementations, including the United States' Global Positioning System (GPS), China's BeiDou Navigation Satellite System (BDS), Russia's Global Navigation Satellite System (GLONASS), the European Union's Galileo, and various other navigation satellite systems. For example, the GNSS receiver 22 may be a GPS receiver that may receive GPS signals from a constellation of GPS satellites 68. And, in another example, the GNSS receiver 22 may be a BDS receiver that receives multiple GNSS (or BDS) signals from a constellation of GNSS (or BDS) satellites 68. In any one implementation, the GNSS receiver 22 may include at least one processor and memory, including a non-transitory computer-readable memory storing instructions (software) that may be accessed by the processor to perform processing performed by the receiver 22.

[0052] The GNSS receiver 22 may be used to provide navigation and other location-related services to the vehicle operator. Navigation information may be presented on the display 50 (or other display within the vehicle such as an application on the HWD 90), or may be presented verbally, such as is done when providing turn-by-turn navigation. Navigation services may be provided using a dedicated onboard navigation module (which may be part of the GNSS receiver 22 and / or incorporated as part of the wireless communication device 30 or other VSM), or some or all of the navigation services may be accomplished via a vehicle communication device (or other telematics-enabled device) installed in the vehicle, wherein the location or positioning information is sent to a remote location to provide navigation maps, map annotations (points of interest, restaurants, etc.), route calculations, etc. for the vehicle. The location information may be provided to a vehicle backend service facility 80 or other remote computer system, such as computer 78, for other purposes, such as fleet management and / or for vehicle energy usage prediction applications discussed below. In addition, new or updated map data, such as geographic road map data stored on a database 84, may be downloaded to the GNSS receiver 22 from the backend facility 80 (or computer 78) via the vehicle communication device 30.

[0053] A body control module (BCM) 24 may be used to control the various VSMs of the vehicle, as well as obtain information about the VSMs, including their current state or condition, and sensor information. Figure 158 is shown as being electrically coupled to the communication bus 58 in the exemplary embodiment of the BCM 24. In some embodiments, the BCM 24 may be integrated with a central stack module (CSM) or a portion thereof and / or integrated with the wireless communication device 30. Alternatively, the BCM may be a separate device connected to other VSMs via the bus 58. The BCM 24 may include a processor and / or memory, which may be similar to the processor 36 and memory 38 of the wireless communication device 30, as described below. The BCM 24 may communicate with the wireless device 30 and / or one or more vehicle system modules, such as the HVAC system, various vehicle sensors (e.g., level sensors including gasoline or fuel level sensors, wiper level sensors, and brake fluid level sensors), the audio system 56, the battery system 60, or other VSMs 28. Software stored in the memory and executable by the processor enables the BCM to direct one or more vehicle functions or operations, including, for example, controlling central locking, air conditioning (or other HVAC functions), electric mirrors, controlling vehicle prime movers (e.g., engines, main propulsion systems), and / or controlling various other vehicle modules. For example, the BCM 24 may send signals to other VSMs, such as requests to perform specific operations or requests for sensor information, and in response, the sensors may then send back the requested information. The BCM 24 may also be used to determine or obtain diagnostic information about one or more VSMs of the vehicle, which may be in the form of diagnostic trouble codes (DTCs), for example.

[0054] In addition, the BCM 24 may provide vehicle status information corresponding to the vehicle status or certain vehicle components or systems (including the VSM discussed herein). For example, the BCM 24 may provide information to the device 30 indicating whether the vehicle's primary propulsion system is engaged or in an active (or ready) state (or when receiving an ignition switch from an engine control module in an ICE vehicle), battery information from the battery system 60, vehicle fluid levels, and / or other information about the vehicle. This information may be sent to the wireless communication device 30 (or other central vehicle computer) automatically upon receiving a request from the device / computer, automatically when certain conditions are met, upon request from another VSM, or periodically (e.g., at set time intervals).

[0055] In an alternative embodiment, the vehicle 12 may include an internal combustion engine (ICE), and in such cases, may be referred to as an ICE vehicle. These ICE vehicles may use the ICE alone for propulsion, or may use a combination of another energy storage (e.g., a traction battery) and the ICE. In the case of an ICE vehicle, the vehicle may include an engine control module (ECM), which controls various aspects of engine operation, such as fuel ignition and ignition timing. The ECM may be connected to a communication bus 58 and may receive operating instructions from the BCM 24 or other vehicle system modules such as a wireless communication device 30 or a VSM 28. In one scenario, the ECU may receive a command from the BCM to start the ICE. The ECM may also be used to obtain sensor information of the vehicle engine.

[0056] The vehicle 12 includes various onboard sensors, and some vehicle user interfaces 50-54 can be used as onboard sensors. Generally speaking, sensors can obtain information related to the operating state of the vehicle ("vehicle operating state") or the environment of the vehicle ("vehicle environmental state"). Sensor information can be sent to other VSMs, such as BCM 24 and vehicle communication devices 30 via communication bus 58. In addition, in some embodiments, sensor data can be sent together with metadata, which may include data identifying the sensor (or sensor type) that captures the sensor data, timestamps (or other time indicators) and / or other data related to the sensor data but not constituting the sensor data itself. "Vehicle operating state" refers to the vehicle state with respect to the operation of the vehicle, which operation may include the operation of the prime mover (e.g., vehicle engine, vehicle propulsion motor). In addition, the vehicle operating state may include vehicle states related to the mechanical operation of the vehicle or the electrical state of the vehicle. "Vehicle environmental state" refers to the vehicle state with respect to the interior of the cabin and the nearby external areas around the vehicle. The vehicle environmental state includes the behavior of the driver, operator or passenger, as well as traffic conditions, road conditions and characteristics, and the state of the area near the vehicle.

[0057] The autonomous vehicle (AV) controller 40 is a controller that controls the operation of the autonomous vehicle and can be used to execute AV logic to perform AV operations. The AV controller 40 may include a processor and a memory, which may include any of the types of processors or memories discussed below with respect to the processor 36 and memory 38 of the wireless communication device 30. The AV controller 40 may be a separate and / or dedicated module that performs AV operations, or may be integrated with one or more other VSMs of the vehicle electronics 20. The AV controller 40 is connected to the vehicle bus 58 and may receive information from one or more on-board sensors or other VSMs (such as BCM24 or GNSS receiver 22). In one embodiment, the vehicle is a fully autonomous vehicle. And, in other embodiments, the vehicle may include some AV functions, but may rely on the vehicle operator to perform at least some driving of the vehicle. In other embodiments, the vehicle 12 is not an AV vehicle and does not include an AV controller. Therefore, according to the National Highway Traffic Safety Administration (NHSTA), the vehicle 12 may be a vehicle with an autonomous driving level of 0 to 5.

[0058] The battery system 60 is included as part of the vehicle electronics 20 and includes a battery pack 62, a battery state of charge (SoC) sensor 64, and a battery temperature sensor 66. The battery pack 62 can be a traction battery or an electric vehicle battery that is used to provide propulsion for the vehicle 12. As described above, the vehicle 12 can be an electric vehicle or a hybrid vehicle, and in such cases, the vehicle 12 can include a battery pack 62. In other embodiments using an ICE vehicle, the vehicle may not include a battery for propulsion. In the case of an ICE vehicle, a hybrid vehicle, or an electric vehicle, the vehicle may include a separate low-voltage battery (e.g., 12V) for powering various VSMs and other components of the vehicle electronics 20. The battery pack 62 can be a lithium-ion battery pack including a plurality of lithium-ion batteries. As will be appreciated by those skilled in the art, other types of batteries may be used.

[0059] The battery state of charge (SoC) sensor 64 is an on-board sensor and can be any of a variety of electrical components capable of measuring the state of charge of the battery pack 62. In one embodiment, the battery SoC sensor 64 can use (or can be) a voltage sensor, such as a dedicated voltmeter attached at the positive terminal of the battery pack 62 and attached at the negative terminal of the battery pack 62. In another embodiment, the battery SoC sensor 64 can use other technologies, such as a chemical method that can be used to measure the specific gravity of the pH of the electrolyte contained in the battery pack 62, a coulomb counting method, a Kalman filtering process (e.g., using voltage and battery temperature in the Kalman filtering process), a pressure method, or a combination thereof. As understood by those skilled in the art, the battery SoC sensor 64 can be configured in various ways. The battery SoC sensor 64 can provide sensor information to a computing device of the vehicle 12, such as the wireless communication device 30, in order to determine the SoC level, which can be expressed as a percentage of the full charge capacity of the battery pack 62.

[0060] The battery temperature sensor 66 may be a digital thermometer coupled to the battery pack 62 such that the battery temperature sensor 66 may measure the temperature of the battery pack 62. In one embodiment, the battery temperature sensor 66 may be used to obtain the SoC of the battery pack 62, or may be part of the battery SoC sensor 64 and used in combination with other sensors such as a voltmeter.

[0061] Additionally, the vehicle 12 may include other sensors not mentioned above, including cameras, wheel speed sensors, yaw rate sensors, orientation sensors (e.g., accelerometers), parking sensors, lane change and / or blind spot sensors, lane assist sensors, ranging sensors (i.e., sensors for detecting the distance between the vehicle and another object, such as by using radar or lidar), other radars, other lidars, tire pressure sensors, fluid level sensors (e.g., fuel or oil level sensors, wiper fluid level sensors), brake pad wear sensors, V2V communication units (which may be integrated into the wireless communication device 30), rain or precipitation sensors (e.g., infrared light sensors directed toward the windshield (or other window of the vehicle 12) to detect rain or other precipitation based on the amount of reflected light), and interior or exterior temperature sensors.

[0062] The wireless communication device 30 is capable of transmitting data via short-range wireless communication (SRWC) and / or via cellular network communication using a cellular chipset 34, as depicted in the illustrated embodiment. In one embodiment, the wireless communication device 30 is a central vehicle computer for performing at least a portion of the method discussed below. In the illustrated embodiment, the wireless communication device 30 includes an SRWC circuit 32, a cellular chipset 34, a processor 36, a memory 38, and antennas 33 and 35. In one embodiment, the wireless communication device 30 can be a stand-alone module, or in other embodiments, the device 30 can be incorporated or included as part of one or more other vehicle system modules (such as a center stack module (CSM), a body control module (BCM) 24, an infotainment module, a head unit, and / or a gateway module). In some embodiments, the device 30 can be implemented as an OEM-installed (embedded) or aftermarket device installed in a vehicle. In some embodiments, the wireless communication device 30 is a telematics unit (or telematics control unit) capable of performing cellular communications using one or more cellular carrier systems 70. The telematics unit may be integrated with the GNSS receiver 22 such that, for example, the GNSS receiver 22 and the wireless communication device (or telematics unit) 30 are directly connected to each other rather than being connected via the communication bus 58 .

[0063] In some embodiments, the wireless communication device 30 may be configured to communicate with the user in accordance with one or more short range wireless communications (SRWC) protocols such as Wi-Fi. TM 、WiMAX TM 、Wi-Fi Direct TM , other IEEE 802.11 protocols, ZigBee TM 、Bluetooth TM 、Bluetooth TM Low Energy (BLE) or Near Field Communication (NFC) for wireless communication. As used herein, Bluetooth TM Bluetooth TM Any of the technologies, such as Bluetooth Low Energy TM (BLE), Bluetooth TM 4.1 Bluetooth TM 4.2 Bluetooth TM 5.0, and other Bluetooth TM Technology. As used herein, Wi-Fi TM or Wi-Fi TM Technology refers to Wi-Fi TMThe wireless communication device 30 may be a wireless communication device that is configured to communicate with one or more cellular protocols, such as IEEE 802.11b / g / n / ac or any other IEEE 802.11 technology. The short range wireless communication (SRWC) circuit 32 enables the wireless communication device 30 to transmit and receive SRWC signals, such as BLE signals. The SRWC circuit may allow the device 30 to connect to another SRWC device. Additionally, in some embodiments, the wireless communication device may include a cellular chipset 34, allowing the device to communicate via one or more cellular protocols, such as those used by the cellular carrier system 70. In this case, the wireless communication device becomes a user equipment (UE) that can be used to perform cellular communications via the cellular carrier system 70.

[0064] The wireless communication device 30 may enable the vehicle 12 to communicate with one or more remote networks (e.g., one or more networks at the backend facility 80 or the computer 78) via packet-switched data communications. The packet-switched data communications may be performed using a non-vehicle wireless access point connected to a land network via a router or modem. When used for packet-switched data communications such as TCP / IP, the communication device 30 may be configured with a static IP address or may be set to automatically receive an assigned IP address from another device on the network, such as a router, or from a network address server.

[0065] Packet-switched data communications may also be performed using a cellular network accessible by the device 30. The communication device 30 may transmit data via the wireless carrier system 70 via the cellular chipset 34. In such embodiments, radio transmissions may be used to establish a communication channel, such as a voice channel and / or a data channel, with the wireless carrier system 70 so that voice and / or data transmissions may be sent and received over the channel. Data may be sent via a data connection, such as via packet data transmission on a data channel, or via a voice channel using techniques known in the art. For combined services involving both voice and data communications, the system may utilize a single call on a voice channel and switch between voice and data transmission on the voice channel as needed, and this may be accomplished using techniques known to those skilled in the art.

[0066] Processor 36 can be any type of device capable of processing electronic instructions, including microprocessors, microcontrollers, host processors, controllers, vehicle communication processors, and application-specific integrated circuits (ASICs). It can be a dedicated processor used only for communication device 30, or it can be shared with other vehicle systems. Processor 36 executes various types of digital storage instructions, such as software or firmware programs stored in memory 38, which enable device 30 to provide a variety of services. For example, processor 36 can execute programs or process data to perform at least a portion of the methods discussed herein. Memory 38 can be active temporary memory, any non-transient computer-readable medium, or other types of memory. For example, memory can be any of many different types of RAM (random access memory, including various types of dynamic RAM (DRAM) and static RAM (SRAM)), ROM (read-only memory), solid-state drive (SSD) (including other solid-state storage devices, such as solid-state hybrid drive (SSHD)), hard disk drive (HDD), disk or optical drive. Components similar to those previously described (processor 36 and / or memory 38, as well as SRWC circuit 32 and cellular chipset 34) may be included in body control module 24 and / or various other VSMs that typically include such processing / storage capabilities.

[0067] The wireless communication device 30 is connected to the bus 58 and can receive sensor data from one or more onboard sensors, and thereafter the vehicle can send the data (or other data derived from or based on the data) to other devices or networks including the vehicle backend service facility 80. And, in another embodiment, the wireless communication device 30 can be combined with or at least connected to a navigation system that includes geographic map information including geographic road map data. The navigation system can be communicatively coupled to the GNSS receiver 22 (directly or via the communication bus 58) and can include an onboard geographic map database that stores local geographic map information. The local geographic map information (e.g., geographic road map data) can be provisioned in the vehicle and / or downloaded to a geographic map database / server such as a computer 78 and / or a backend facility 80 (including a server 82 and a database 84) via a remote connection. The onboard geographic map database can store geographic road map data corresponding to the location or area of ​​the vehicle so as not to include a large amount of data, most of which may never be used. In addition, when the vehicle 12 enters a different location or area, the vehicle can notify the vehicle backend service facility 80 of the location of the vehicle (e.g., obtained using the GNSS receiver 22), and in response to receiving the new location of the vehicle, the server 82 can query the database 84 to obtain the corresponding geographic map information, which can then be sent to the vehicle 12. Alternatively, in another embodiment, the vehicle can request geographic map information from one or more remote networks based on the trip information entered by the user (e.g., the starting location and / or the ending location of the trip). In response to the request, the remote network (e.g., the backend facility 80, the computer 78) can send the requested information to the vehicle 12.

[0068] The vehicle electronics 20 also include a number of vehicle user interfaces that provide a means of providing and / or receiving information to the vehicle occupants, including a visual display 50, a button 52, a microphone 54, and an audio system 56. As used herein, the term "vehicle user interface" broadly includes any suitable form of electronic equipment, including both hardware and software components, which is located on the vehicle and enables the vehicle user to communicate with or through the vehicle components. The vehicle user interfaces 50-54 are also on-board sensors that can receive input or other sensory information from the user. The button 52 allows manual user input into the communication device 30 to provide other data, response or control input. The audio system 56 provides audio output to the vehicle occupants and can be a dedicated stand-alone system or part of the main vehicle audio system. According to the specific embodiment shown here, the audio system 56 is operatively coupled to both the vehicle bus 58 and the entertainment bus (not shown), and can provide AM, FM and satellite radio, CD, DVD and other multimedia functions. This function can be provided with the infotainment module or independently of the infotainment module. Microphone 54 provides audio input to wireless communication device 30 to enable the driver or other occupant to provide voice commands and / or conduct hands-free calls via wireless carrier system 70. To this end, it can be connected to an onboard automatic voice processing unit using human machine interface (HMI) technology known in the art. Visual display or touch screen 50 is preferably a graphical display and can be used to provide a variety of input and output functions. Display screen 50 can be a touch screen on the instrument panel, a heads-up display reflected on the windshield, or a projector that can project graphics for viewing by vehicle occupants. Various other human machine interfaces, such as applications executed on HWD 90, are used to provide input from a person to the vehicle as Figure 1 The interface is only an example of one specific implementation.

[0069] The user of the vehicle 12 can use one or more human-machine interfaces (e.g., vehicle user interface, HWD 90) to input a destination or other information. In one embodiment, the user can operate one or more vehicle user interfaces 50-56, which can then deliver the input information to other VSMs, such as wireless communication devices 30. The wireless communication device 30 can then use the cellular chipset 34 or other communication devices to send the information to the backend facility 80. For example, the user can use the touch screen display 50 to enter the desired destination that the user wants to go to. The destination can include a physical address (e.g., 1234 Main Street, Central City, Michigan) or can include a point of interest or other geographic indicator. The destination can be represented in a variety of forms, such as by geographic coordinates or text data embodied in a vehicle navigation request message. The departure location can also be specified in the vehicle navigation request message. The departure location can be specified by the user via the vehicle user interface, or can be determined or preset to the current location of the vehicle, which can be determined using the GNSS receiver 22 or by using other location services. The vehicle navigation request message may then be sent using the wireless communication device 30 (e.g., via the SRWC circuit 32 or cellular chipset 34) to a backend facility 80 or other remote computing system (e.g., computer 78), which may then provide navigation information to the vehicle 12. Alternatively, navigation information may be determined at the vehicle 12 using onboard road map data, or using data at the vehicle without any remote data access via the wireless communication device 30, or based in part on remotely accessed data such as dynamic traffic or road closure information. The navigation information may be displayed on the display 50, or may be presented via the use of other vehicle user interfaces that may be used to present output.

[0070] refer to Figure 2 , a method 200 for determining a vehicle route based on human and machine constraints is shown. In one embodiment, the method 200 (or any steps thereof) is performed by the vehicle 12, such as by the wireless communication device 30, the AV controller 40, other onboard computers or computer systems, other VSMs, and / or other vehicle electronics. Although the steps of the method 200 are described as being performed in a particular order, it is contemplated that the steps of the method 200 may be performed in any suitable order as would be appreciated by one skilled in the art.

[0071] Method 200 begins at step 210, where user trip parameters for a vehicle trip are received from a vehicle user via a human-machine interface. User trip parameters are parameters of a vehicle trip specified by a vehicle user using a human-machine interface. In many embodiments, the trip parameters may be input by a user using one or more vehicle user interfaces (such as a touch screen display 50). Additionally or alternatively, the user trip parameters may be input by a vehicle user using an application executed on the HWD 90. For example, the HWD 90 may be connected to the vehicle 12 (and communication information) via an SRWC connection and / or connected to the backend facility 80 via cellular communication. In at least some embodiments, the user trip parameters include a user-specified or indicated end location of the vehicle trip. In one embodiment, the user trip parameters may include a user-specified or indicated start location of the vehicle trip. In at least one embodiment, as a default value, the start location may be automatically set to the current location of the vehicle 12, which may be determined using the GNSS receiver 22. If desired, the vehicle user may modify the default value (or automatically set to the start location of the current vehicle location).

[0072] In one embodiment, the user trip parameters may include the vehicle user selecting one or more of the following: a nausea reduction option, an optimal time option, an optimal energy usage option, and / or a scenic route option. The nausea reduction option is an option indicating a vehicle user's preference for a route determined to cause the least amount of nausea or motion sickness, which may be determined by determining which route has the lowest nausea index score, as will be discussed in more detail below with respect to method 400. The nausea reduction option may be selected by a vehicle user who prefers a vehicle route determined to cause the least amount of nausea compared to other potential or potential routes of the vehicle trip. Additionally, in some embodiments, the vehicle user may set a nausea tolerance that indicates the degree to which the vehicle user can tolerate nausea-inducing events. The optimal time option is an option indicating that the vehicle user wishes to take a route that takes the shortest amount of time. The optimal energy usage option is an option indicating that the vehicle user wishes to take a route that uses the least amount of energy (e.g., electric power for an electric vehicle (or hybrid vehicle), gasoline for an ICE vehicle (or hybrid vehicle)) The scenic route option is an option indicating that the vehicle user desires to take a route that is considered scenic, which may be determined based on the number and / or type of points of interest along a particular route.

[0073] In one embodiment, the vehicle user can select one of the nausea reduction option, the best time option, the best energy usage option, or the scenic route option. In another embodiment, the vehicle user can select multiple of these options. In one embodiment, the user can specify a preference level (e.g., 1 to 10, with 10 being the highest preference level) for each of these options. For example, the vehicle user can enter 8 for the nausea reduction option, 7 for the best time option, and 1 for both the scenic route option and the best energy usage option. The subsequent determination of method 200 can be based on the determination of the route (or vehicle route) of the vehicle trip based on these preference levels. In another embodiment, the vehicle user can specify the amount of time, energy, and / or maximum nausea index score that should be used when generating and / or selecting the route (or vehicle route) of the vehicle trip.

[0074] Any of these human constraint inputs / options may be provided to the vehicle as explicit values ​​or selections, or may be provided by the user via a natural language interface that helps maximize simplicity and convenience for the user. For example, a user may say "Take me to the corner of Main and Oak Streets in Center City. I need to be there in 45 minutes, and I want to read along the way." Using known automatic speech recognition (ASR) processing and neural networks or other artificial intelligence, the user's natural language command may be interpreted by the vehicle as providing a destination, a maximum allotted travel time (which may allow for several alternative routes), and a requirement for the vehicle to use nausea reduction options to select the least nausea-inducing route that meets the travel time requirement. This determination of the user's constraints may be done at the vehicle 12 using the vehicle electronics 20, or remotely (e.g., at the backend facility 80) in whole or in part through communication via the wireless communication device 30. Those determined constraints may then be used in subsequent steps to select an appropriate navigation route.

[0075] In addition to being directly input / selected by the user, or obtained from an interpreted process of the user's trip request (e.g., via natural language processing), nausea reduction options may be obtained from the user in other ways, such as from a user profile stored on the vehicle 12 or accessed from the backend facility 80 or other remote location. Thus, nausea reduction options may be provided by the user when specifying a particular trip, or as a previously specified option for route planning.

[0076] In step 220, geographic road map data corresponding to the area of ​​the vehicle's journey is obtained. In many embodiments, the geographic road map data can be obtained from a remote server, such as a computer 78 or server 82 at a backend facility 80. In one embodiment, the geographic road map data is collected from one or more databases and sent to the vehicle 12 via the cellular carrier system 70 and / or the land network 76. For example, the vehicle 12 can send travel parameters (including any one or more user travel parameters obtained in step 210) to the remote server as part of a request for geographic road map data related to the vehicle's journey. The geographic road map data can be stored in a memory of the vehicle, such as memory 38. In another embodiment, all or a portion of the geographic road map data may have been stored in a memory of the vehicle's electronics, such as memory 38. The geographic road map data can be stored in a memory of the vehicle. The method 200 continues to step 230.

[0077] In step 230, multiple potential routes are determined based on user travel parameters and geographic road map data. Potential routes can be routes between the starting location and the ending location of the vehicle journey. In at least some embodiments, potential routes can be determined based on one or more options or preferences (except the starting and / or ending location) selected by the vehicle user. For example, the vehicle user can indicate the maximum travel time (e.g., 35 minutes), the maximum route distance (e.g., 20 miles), the maximum energy use, the requirement that the route includes a gas station or an electric vehicle charging station, or various other parameters, which can be specified by the vehicle user via one or more human-machine interfaces (e.g., vehicle user interface 50-56, HWD 90) Any one or all of them. Then, multiple potential routes can be determined based on these travel parameters. Potential routes can each include one or more road sections, wherein one or more road sections geographically connect the starting location and the ending location of the vehicle journey. Method 200 continues to step 240.

[0078] In step 240, potential routes are filtered based on vehicle compatibility. In some scenarios, some vehicles are not suitable for traveling along certain roads due to certain physical properties of the vehicle, the operating characteristics of the vehicle, or both. For example, when the vehicle height of vehicle 12 is V H and the clearance height of the potential route segments is R H When the vehicle height V H Must be smaller than the gap height R H (V H <R H ). When determining the vehicle height R H Not less than the gap height R H, then the vehicle is determined to be incompatible (and specifically, physically incompatible) with the road segment. As another example, when the vehicle is towing a heavy load, the road segment may be evaluated based on the slope (and / or other geometric attributes) of the road. Figure 3 In one embodiment, this step includes executing Figure 3 The vehicle compatibility assessment process 300 is described below.

[0079] In one embodiment, the compatibility of the vehicle may depend on trip parameters, such as one or more user trip parameters. For example, a vehicle user may indicate a desire to stop at a gas station along a route, and thus, potential routes may be filtered based on whether a gas station is located along the route (or may be modified to include a stop at a gas station). As another example, the time at which the vehicle trip is made (which may be specified by the user or selected by default to be the current time of the specified vehicle trip (step 210)) may be used to determine that sections of road that are unlit (or otherwise unlit) may be avoided when the vehicle's headlights are broken or inoperable. Method 200 continues to step 250.

[0080] In step 250, a nausea index score is determined for each potential route or filtered potential routes. Step 250 may be performed when the nausea reduction option is selected or when it is indicated during a vehicle trip that nausea reduction is under consideration. In one embodiment, including the illustrated embodiment, step 250 is performed after step 240, and a nausea index score may be determined for each filtered potential route. The filtered potential routes are those routes that are potential routes and are determined to be compatible (or determined to be incompatible) with the vehicle (step 240). In another embodiment, a nausea index score may be performed for each potential route, and then after the nausea index score is determined, the route with the lowest nausea index score may be checked for compatibility with the vehicle 12, such as by using Figure 3 Vehicle compatibility assessment process 300. In at least one embodiment, Figure 5 The nausea index score determination process 400 may be used to determine a nausea index score for each potential route or filtered potential routes. The method 200 then continues to step 260 .

[0081] In step 260, one of the potential routes is selected based on the determinations of steps 240 and / or 250. In at least some embodiments, Figure 3The vehicle compatibility assessment process 300 (or in step 240) filters potential routes. In addition, a nausea index score is determined for each of these (filtered) potential routes. Based on travel parameters or preferences, such as those input by a vehicle user, a potential route can be selected as a route for the vehicle trip (or a vehicle route). In another embodiment, more than one route can be selected to be presented to the vehicle user (step 270), and then the vehicle user can select one of the suggested routes. In one embodiment, the filtered potential route associated with the lowest nausea index score (when compared to the nausea index scores of other (filtered) potential routes) can be selected as the route for the vehicle trip. Alternatively, three filtered potential routes associated with the three lowest nausea index scores can be selected as suggested routes and presented to the vehicle user.

[0082] As described above, the vehicle user can specify a number of user trip parameters that will be considered for determining the route of the vehicle trip. In one scenario, the vehicle user can select a nausea reduction option as a user trip parameter for the vehicle trip. In such cases, the route with the lowest cumulative nausea index score (as determined in process 400) can be selected as the route of the vehicle trip. As described above, the potential routes for calculating the cumulative nausea index score only include those routes that meet or conform to other user trip parameters and the constraints of the vehicle (i.e., the vehicle is determined to be compatible with the route). Moreover, in some embodiments, the nausea reduction option can be set to a value instead of a binary option (i.e., yes / true, no / false). In such cases, the nausea reduction option (or level) specified by the vehicle user can be used in combination with the cumulative nausea index of the potential route to provide a weighted cumulative nausea index score (which is based on the cumulative nausea index score and the nausea reduction level). Other options can also be used in combination with the weighted cumulative nausea index score to determine which potential route is selected as the route of the vehicle trip. The route of the selected vehicle trip can then be stored in a memory of the vehicle 12, such as a memory 38 or a memory of another VSM of the vehicle 12. The method 200 continues to step 270 .

[0083] In step 270, the selected potential route is presented to the vehicle user. The selected potential route can then be presented to the vehicle user. In one embodiment, as described above, a single route can be selected as the vehicle route (or vehicle route) of the vehicle journey. In another embodiment, multiple suggested routes can be selected for the vehicle journey. The selected route can then be presented to the vehicle user via one or more vehicle user interfaces or on the display of HWD 90. With respect to a vehicle presenting multiple suggested routes, the vehicle user can then select one of the suggested routes as the route of the vehicle journey. In some embodiments, the vehicle 12 is an autonomous vehicle (AV) and includes an AV controller, such as AV controller 40. In one embodiment, the route of the vehicle journey can be used by the vehicle electronics 20 including the AV controller 40 to autonomously propel or drive the vehicle along the route of the vehicle journey. Then the method 200 ends.

[0084] In one embodiment, any one or more of steps 220 to 260 are performed by a remote facility or server, such as backend facility 80 or computer 78. For example, in such embodiments, vehicle 12 may send vehicle trip parameters (including user trip parameters) to a remote facility, which may then determine a route for the vehicle trip or a suggested route for the vehicle trip. The route for the vehicle trip or the suggested route for the vehicle trip may then be sent to vehicle 12 via land network 76 and / or wireless carrier system 70.

[0085] refer to Figure 3 , a vehicle compatibility evaluation process 300 is shown, which includes steps 310-360. Process 300 can be performed by the vehicle electronics 20, or can be performed by a remote facility (such as a backend facility 80 and / or a computer 78). In one embodiment, at step 240, process 300 is performed as part of method 200. Process 300 can be used to filter potential routes based on the compatibility of the vehicle with the route (e.g., compatibility with one or more road segments along the route). Although the steps of process 300 are described as being performed in a particular order, it is contemplated that the steps of process 300 can be performed in any suitable order that will be understood by those skilled in the art.

[0086] In many embodiments, process 300 can be performed for each potential route. In another embodiment, process 300 can be performed for each road section of each potential route. When determining that the vehicle is incompatible with the road section, the road section mark or indication can be incompatible, and the potential route comprising the incompatible road section can be recalculated to not include the incompatible road section. However, in some embodiments, the whole route can be indicated as incompatible, and other potential routes can be used for vehicle travel instead. In some scenes, the first potential route comprises at least one road section, which is also included as a part for the second potential route. Therefore, redundant processing can be removed using process 300 to process the road section. Process 300 is discussed below with reference to potential route i and / or road section j.

[0087] In step 310, road attributes are determined based on road information. As described above, road information may include geographic information, geographic road map data, physical road attributes, road operation attributes, road conditions, or other information related to the road. In one embodiment, road information related to the route can be obtained. As described above, in step 220, geographic road map data is obtained, and in steps 230-240, potential routes are determined. Geographic road information includes the geographic coordinates of the road segments of the potential routes. This information can be used as road information for determining or identifying one or more road attributes. For example, for road segment j, the geographic coordinates of road segment j can be obtained, and then the road attributes can be determined based on the road information stored at the vehicle (such as the memory of the vehicle electronic device 20). In one embodiment, the vehicle 12 can query a remote server, such as a computer 78 or server 82 of a back-end facility 80. This information can be queried based on the geographic coordinates of road segment j. In another embodiment, multiple road segments, one or more potential routes, and / or road information of an area containing and / or surrounding any number of one or more potential routes can be obtained at once, for example, to reduce remote communications. Process 300 continues to step 320.

[0088] In step 320, vehicle compatibility information is determined. Vehicle compatibility information is any information about a vehicle that is relevant to determining whether the vehicle is compatible with a particular road or road segment. Whether vehicle information is considered vehicle compatibility information may depend on certain requirements of the road or road segment being evaluated by process 300, as this may vary based on different requirements (including laws, regulations, etc.) and the properties of different roads. Vehicle compatibility information may be obtained from a variety of sources - vehicle compatibility information may include static information (information that does not (or generally does not) change, such as physical vehicle attributes (e.g., vehicle height)) pre-programmed in the vehicle electronics and / or pre-stored in the memory of the vehicle electronics or dynamic information that may be determined from one or more VSMs or obtained from a remote server. In one embodiment, vehicle compatibility information may be retrieved from a remote server, such as server 82 and / or computer 78 of backend facility 80. The information may be periodically retrieved and saved to a memory of the vehicle electronics, such as memory 38. Alternatively or additionally, the information (or portions thereof) may be retrieved when process 300 as part of method 200 is performed.

[0089] Moreover, in some embodiments, at least some vehicle compatibility information can be obtained from one or more VSMs of the vehicle. For example, BCM 24 can include information about whether certain components of the vehicle are functional, and / or certain measurements related to those components. For example, information related to whether the vehicle headlights are operable (e.g., the light source is damaged) can be determined. Or, as another example, BCM 24 can determine the level of wiper fluid - in one scenario, potential roads can include one or more sections that are muddy (or dusty), and therefore, when it is determined that the wiper fluid is low, those muddy roads or sections can be avoided. In one embodiment, this step includes obtaining sensor information (or sensor data) from one or more on-board sensors (e.g., wiper level sensors). Process 300 continues to step 330.

[0090] In step 330, a vehicle compatibility check is performed. The compatibility check includes determining whether the vehicle is compatible with the road or road segment. In many embodiments, the road attributes obtained in step 310 are compared with the vehicle attributes obtained in step 320. For example, when it is determined that the road segment j is a mud road, the wiper level can be compared with the wiper level threshold, and when the wiper level is below the threshold, it can be determined that the vehicle is incompatible with the road segment. In one embodiment, the threshold (e.g., the wiper level threshold) can be determined based on road information, such as the length of the road segment is mud-for example, a longer mud road can result in a higher wiper level threshold for checking vehicle compatibility. For another example, it can be determined that the road is not lit (or may not be lit) based on, for example, whether the road is in a rural location. In such cases, the vehicle can be checked to see whether the vehicle headlights are operational and whether the vehicle journey is conducted at night or after sunset. When it is determined that one or more headlights of the vehicle are inoperable (or faulty) (and it is nighttime), it can be determined that the vehicle 12 is incompatible with the unlit road or road segment. As another example, the mass of the vehicle may be determined, and when the mass exceeds a certain threshold, steep roads may be avoided by indicating that the vehicle is incompatible with steep roads or long inclines (e.g., long hill climbs).

[0091] As another example, the maximum speed capability of the vehicle may be checked against a typical or recommended speed for a particular road (or lane of a road, such as a fast lane of a highway) to determine whether the vehicle is able to reach and maintain a safe speed. And, as another example, when the vehicle's SoC (for EV) is low (or the fuel level is low), the route may be checked for EV charging stations (or gas stations) along the route - in such examples, the entire route (or a portion of the route, such as the first 15 miles) of EV charging stations (or gas stations) may be checked, and compatibility may be evaluated on the basis of the entire route (or portion of the route), rather than evaluating the compatibility of each individual segment. For example, when the SoC indicates that the vehicle has 15 miles of battery remaining (for an EV), the route may be checked to determine whether there is a charging station within the first 15 miles of the route, which may be a portion of the route that includes multiple segments. In another embodiment, the end location of the route may be checked to determine whether the vehicle's parking location or docking location is compatible with the vehicle. For example, when the end location of the route includes a steep hill, the parking brake or the electric transmission range select (ETRS) may be checked to determine if it is faulty, and if so, the end location (or parking location) may be deemed incompatible with the vehicle, and a new end location (or parking location) may be determined and / or suggested. In such cases, the end location may (and in many cases is) the same for each potential route, and therefore, a new end location (or parking location) may be determined and suggested for each potential route. Process 300 proceeds to step 340.

[0092] In step 340, when it is determined that the vehicle is not compatible (or incompatible) with the road segment (or route), process 300 continues to step 360; otherwise, process 300 continues to step 350. In step 350, an indication indicating that the road segment (or route) is compatible with the vehicle can be generated or stored. The indicator can be stored in a memory of the vehicle electronics 20, such as in a memory 38 or a memory of another VSM. In step 360, an indication indicating that the road segment (or route) is not compatible (incompatible) with the vehicle can be generated or stored. The indicator can be stored in a memory of the vehicle electronics 20, such as in a memory 38 or a memory of another VSM. In this case, the potential route that is incompatible with the vehicle (or it includes a road segment that is incompatible with the vehicle) can be eliminated as a potential route. Alternatively, in another embodiment, a new potential route that is similar to the current potential route i and does not include a road segment that is incompatible with the vehicle can be determined. In one embodiment, the new potential route may be determined after determining that the first road segment is incompatible with the vehicle, or may be determined after performing process 300 for all road segments of potential route i or for all road segments of all potential routes. As described above, in at least one embodiment, after process 300 ends, method 200 proceeds to step 250.

[0093] As described above with reference to method 200 ( Figure 2 ), a nausea index score is determined for each filtered potential vehicle route. In other embodiments, filtering step 240 may not be performed, and a nausea index score may be determined for each potential route (since it is not filtered). In either embodiment, the nausea index score may be determined using Figure 5 The nausea index score determination process 400 is used to determine a nausea index score. Figure 4 , a map 100 is shown depicting two potential routes, route 110 and route 120, each route including a plurality of road segments connecting a starting location 102 to an ending location 104. Route 110 includes 21 stop lights, while route 120 includes 1 stop light. The following discussion with reference to these potential routes 110, 120 Figure 5 of process 400.

[0094] refer to Figure 5, a nausea index score determination process 400 is shown, which includes steps 410-450. Process 400 can be performed by the vehicle electronics 20, or can be performed by a remote facility (such as backend facility 80 and / or computer 78). In one embodiment, at step 250, process 400 is performed as part of method 200. Process 400 can be used to determine a nausea index score for one or more routes, such as potential routes (or filtered potential routes). Although the steps of process 400 are described as being performed in a particular order, it is contemplated that the steps of process 400 can be performed in any suitable order that will be understood by those skilled in the art.

[0095] Process 400 begins at step 410, where the next potential nausea-inducing event is identified along the potential route. A potential nausea-inducing event is referred to as the current potential nausea-inducing event k. A potential nausea-inducing event is an event that is identified as likely to cause nausea (or motion sickness) or increase the likelihood or degree of nausea (or motion sickness) in a vehicle occupant. A portion or point of a route may be considered a potential nausea-inducing event when the portion or point may cause an acceleration (or deceleration) or a change in direction above a certain threshold, which may be set based on specific vehicle specifications and / or user settings. For example, a stop sign or stop light, such as stop light 112 of route 110, may be considered a potential nausea-inducing event because vehicle 12 may have to slow down to stop at a traffic signal, such as when the signal is red. As another example, turn 122 or turn 124 of route 120 may both be considered a potential nausea-inducing event because the vehicle direction will change (more than a predetermined threshold amount, which may be based on a change in the angle and / or speed (or possible speed) that the vehicle will travel through the turn). In step 410 , stop light 112 may be determined as the first potential nausea-inducing event of route 110 , and turn 122 may be determined as the first potential nausea-inducing event of route 120 . Process 400 continues to step 420 .

[0096] In step 420, a nausea index factor for the current turn k is determined. A nausea index factor is any factor or attribute of a potential nausea inducing event k that can be used to measure the extent and / or effect that the potential nausea inducing event will (or may) have on a vehicle occupant. For example, exemplary nausea index factors include turn angle, angle factor, average speed, angular g factor, change in acceleration (or Δ) through the turn, and acceleration factor. The turn angle represents the angle at which the vehicle is driven when completing the turn. For example, referring to Figure 6 and Figure 7 , two graphs 500 and 600 are shown, where graph 500 represents the turning angle of vehicle 12 for a regular four-way intersection, and graph 600 represents the turning angle of vehicle 12 for a roundabout intersection. Figure 6 ) and 602( Figure 7) indicates the approach of vehicle 12, at 504 ( Figure 6 ) and 604( Figure 7 ) indicates a right turn at 506( Figure 6 ) and 606( Figure 7 ) indicates a straight path (or no turns), and at 508 ( Figure 6 ) and 608( Figure 7 ) indicates a left turn. As shown, the right turn for both turn types is 90°. However, when the vehicle 12 travels around a semicircular path, the straight path (or no turn) of a regular intersection is 0°, and the roundabout intersection is 180°. The left turn at a regular intersection is 90°, and the roundabout intersection is 270° because the vehicle 12 must travel around three-quarters of the circular path of the roundabout.

[0097] In one embodiment, these nausea index factors can be obtained from a remote server, such as a server 82 at a computer 78 or backend facility 80. In this case, these factors can be calculated at the remote server and then sent to the vehicle 12, for example, via a land network 76 and / or a wireless carrier system 70. In another embodiment, these factors can be determined based on road information obtained at the vehicle 12, such as the information obtained in step 220. In one embodiment, the road information can be used in conjunction with AV operation information, which is information related to the operation of the vehicle when it is in AV mode. For example, the vehicle can be an AV, where the vehicle determines the speed and travel path of the vehicle along the road. In such cases, when the vehicle is in or near a current potential nausea-inducing event, the vehicle can determine (or predict) the speed, direction, and / or various other operating parameters of the vehicle. The AV operation information can then be based on the road information and / or can be used in conjunction with the road information to determine one or more road factors, such as the average speed and / or the change in acceleration through the turn. Once these factors are determined, the process 400 continues to step 430.

[0098] In step 430, a nausea index value of the current potential nausea inducing event is determined. The nausea index value is determined based on the one or more nausea index factors obtained in step 420. As described above, the potential nausea inducing event may be a turn. When the potential nausea inducing event is a turn, according to one embodiment, the nausea index value N of the current potential nausea inducing event k may be determined using the following formula: k :

[0099] N k =β*(f β +v avg 2 *f g +Δa*f a )

[0100] Where β is the turning angle, f β is the angle factor, v avg is the average speed, f g is the angular g factor, Δa is the change in acceleration, and f a is the acceleration factor. The turning angle is the angle at which the vehicle is driven to complete the turn. The turning angle factor f β is a calibration constant used to amplify / dampen the effect of turn angle on the nausea index value. Average speed v avg is the average linear speed of the vehicle through the turn. Angle g (or speed) factor f g is a calibration constant used to amplify / suppress the effect of velocity on the nausea index value. The change in acceleration Δa is the change in acceleration from the time before event k to the time after event k. The acceleration factor f a is a calibration constant used to amplify / suppress the effect of acceleration changes on the nausea index value. Turn angle factor f β , angle g factor f g and / or acceleration factor f a The factors may be predetermined values ​​stored in a memory of the vehicle electronics and may be modified and / or based on current vehicle operating conditions and / or environmental conditions, such as, in at least one embodiment, vehicle operating state and / or vehicle environmental state. In one embodiment, different values ​​for each of these factors may be stored in a table, and specific values ​​for the above formulas may be selected from the table based on the vehicle operating state and / or vehicle environmental state, which may include driver settings (e.g., a particular driver's nausea tolerance), cabin temperature, cabin humidity, and other environmental factors.

[0101] This formula represents one example of a nausea index value that may be used to calculate the current potential nausea inducing event; however, it should be understood that a variety of different methods, formulas, etc. may be developed and used to calculate or determine the nausea index score for the current potential nausea inducing event. For example, any suitable combination of the components of the above formula may be considered when determining the nausea index score. For another example, when the potential nausea inducing event is a stop, such as a stop sign or stop light, deceleration, (possible) stopping distance, and the curve of the road near the stop may be considered when determining the nausea index score for the current potential nausea inducing event. Process 400 continues to step 440.

[0102] In step 440, a cumulative nausea index score is determined based on the nausea index value and the previous cumulative nausea index score. Initially, the cumulative nausea index score can be set to zero, and thus, in the first instance of step 440, for route 110 (for example), the nausea index score for the current iteration of process 400 can be set to the cumulative nausea score. In other embodiments, different initial cumulative nausea scores can be used, as the exact calculation of the cumulative nausea index score can be adjusted based on the specific calculations and models used. In at least some embodiments, the time (e.g., number of minutes) since a previous potential nausea inducing event k-1 can be considered when determining (or updating) the cumulative nausea index score. For example, when a previous potential nausea inducing event k-1 is ten minutes before a current potential nausea inducing event k, then the impact of these nausea inducing events may be less than if the previous potential nausea inducing event k-1 was thirty seconds before the current potential nausea inducing event k.

[0103] In one embodiment, the following formula may be used to calculate or otherwise determine a cumulative nausea index score for a route:

[0104] C r =C r，prev +γ(t)*N k

[0105] Among them C r is the cumulative nausea index score of the route, C r，prev is the previous cumulative nausea index for the route, γ(t) is the decay time factor (which is a function of time t), and N k is the nausea index of the current nausea inducing event k. Although this formula may be used, those skilled in the art will appreciate that other formulas and calculations may be used. Process 400 continues to step 450.

[0106] In step 450, it can be determined whether there is another potential nausea inducing event to be processed. When it is determined that there is another potential nausea inducing event to be processed, process 400 continues back to step 410, where process 400 can be performed again for the next potential nausea inducing event k+1. When it is determined that there is not another potential nausea inducing event to be processed, process 400 then ends. The cumulative nausea index score of this last iteration can then be considered the final nausea index score for the route. This value can be stored in a memory of the vehicle electronics 20, such as in memory 38. In an embodiment in which process 400 is executed at a system external to the vehicle (e.g., remote computer 78), the final value can be sent to the vehicle 12 and then stored in the memory of the vehicle 12. As described above, in at least one embodiment, when process 400 ends, method 200 ( Figure 2 ) then proceed to step 260.

[0107] In one embodiment, after selecting the route as the vehicle route for the vehicle trip, method 200 may include the steps of: detecting that the vehicle is approaching (or within a predetermined distance or time) a potential nausea-inducing event; and, upon detecting that the vehicle is approaching (or within a predetermined distance or time) a potential nausea-inducing event, then notifying the vehicle user that the vehicle is approaching the potential nausea-inducing event. The notification may be provided via audio system 56 or via a speaker on HWD 90 to notify the vehicle user to look up and / or take another action to reduce the change or degree of motion sickness or nausea caused (or likely to be caused) by the potential nausea-inducing event.

[0108] In one embodiment, method 200 and / or parts thereof (e.g., processor 300, processor 400) may be implemented in one or more computer programs (or "applications" or "scripts") that are embodied in one or more computer-readable media and include instructions that can be used (e.g., executable) by one or more processors of one or more computers of one or more systems. A computer program may include one or more software programs consisting of program instructions in source code, object code, executable code, or other formats. In one embodiment, any one or more computer programs may include one or more firmware programs and / or hardware description language (HDL) files. In addition, the computer programs may each be associated with any program-related data, and in some embodiments, the computer programs may be packaged with program-related data. Program-related data may include data structures, lookup tables, configuration files, certificates, or other related data represented in any other suitable format. Program instructions may include program modules, routines, programs, functions, processes, methods, objects, components, etc. A computer program may be executed on one or more computers, such as on multiple computers that communicate with each other.

[0109] The computer program may be embodied on a computer-readable medium (e.g., a memory at the server 82, a memory of the vehicle 12 (e.g., memory 38), a combination thereof), which may be non-transitory and may include one or more storage devices, articles of manufacture, etc. Exemplary computer-readable media include computer system memory, such as RAM (random access memory), ROM (read-only memory); semiconductor memory, such as EPROM (erasable programmable ROM), EEPROM (electrically erasable programmable ROM), flash memory; magnetic or optical disks or tapes, etc. Computer-readable media may also include computer-to-computer connections, such as when data is transmitted or provided over a network or another communication connection (wired, wireless, or a combination thereof). Any combination of the above examples is also included within the scope of computer-readable media. Therefore, it should be understood that the method may be performed, at least in part, by any electronic article and / or device capable of executing instructions corresponding to one or more steps of the disclosed method.

[0110] It should be understood that the foregoing is a description of one or more embodiments of the present invention. The present invention is not limited to the specific embodiments disclosed herein, but is limited only by the claims below. In addition, unless it is a term or phrase clearly defined above, the statements contained in the foregoing description relate to specific embodiments and should not be interpreted as limitations on the scope of the present invention or on the definitions of the terms used in the claims. Various other embodiments and various changes and modifications to the disclosed embodiments will be obvious to those skilled in the art. All such other embodiments, changes and modifications are intended to fall within the scope of the appended claims.

[0111] As used in this specification and claims, the terms "such as," "for example," "for example," "such as," and "like," and the verbs "comprise," "have," "include," and their other verb forms, when used in conjunction with a list of one or more components or other items, are each to be understood as open-ended, meaning that the list should not be viewed as excluding other additional components or items. As with other terms, unless these terms are used in a context that requires a different interpretation, these terms should be interpreted using their broadest reasonable meaning. In addition, the term "and / or" should be understood as an inclusive "or." Thus, for example, the phrase "A, B, and / or C" should be interpreted to include all of the following: "A"; "B"; "C"; "A and B"; "A and C"; "B and C"; and "A, B, and C."

Claims

1. A method for determining a vehicle route, wherein the method comprises the following steps: receiving user trip parameters for a vehicle trip from a vehicle user via a human-machine interface, wherein the vehicle trip includes a starting location and an ending location, and wherein the user trip parameters include a nausea tolerance set by the vehicle user as part of the user trip parameters for the vehicle trip; accessing geographic road map data corresponding to an area of ​​travel of the vehicle; determining a plurality of potential routes for the vehicle trip based on the user trip parameters and the geographic road map data; A cumulative nausea index score is determined for each potential route, wherein each cumulative nausea index score comprises a nausea index value calculated based on a plurality of nausea index scores, each of the nausea index values ​​being determined for a potential nausea inducing event that is part of the potential route using the following formula: N k =β*(f β +v avg 2 *f g +Δa*f a ) where k represents the kth potential nausea-inducing event, N k is the nausea index value for the kth potential nausea-inducing event, β is the turning angle, and f β is the turning angle factor, v avg is the average speed of the vehicle through the turn, f g is the angular g factor, Δa is the change in acceleration from the time before event k to the time after event k, and f a is the acceleration factor, The turning angle factor f β is a calibration constant used to amplify / dampen the effect of turning angle on the nausea index value, the angular g factor f g is a calibration constant used to amplify / suppress the effect of speed on the nausea index value, the acceleration factor f a is a calibration constant used to amplify / suppress the effect of acceleration changes on the nausea index value. The turning angle factor f β , angle g factor f g , acceleration factor f a is selected based on a nausea tolerance set by the vehicle user; as well as One of the potential routes is selected as a vehicle route for the vehicle trip based on the cumulative nausea index score and further based on a nausea tolerance set by a vehicle user as part of user trip parameters for the vehicle trip. 2 . The method of claim 1 , wherein the human-machine interface is a vehicle user interface installed on the vehicle as part of vehicle electronics. The method of claim 1 , wherein the plurality of potential routes are determined based on at least some of the user travel parameters. 4 . The method of claim 1 , wherein determining a cumulative nausea index score for each potential route comprises performing at least one nausea index score determination process for each potential route.

5. The method of claim 4, wherein the nausea index score determination process is an iterative process that is performed for each of a number of potential nausea inducing events for each potential route.

6. The method of claim 5, wherein the nausea index score determination process comprises identifying each potential nausea inducing event, determining a nausea index score for each potential nausea inducing event, and then updating the cumulative nausea index score based on the nausea index score for each potential nausea inducing event.

7. The method of claim 6, wherein the nausea index scores for at least some of the potentially nausea inducing events are based on a turn angle of the potentially nausea inducing event and an acceleration of the potentially nausea inducing event.

8. The method of claim 6, wherein the nausea index score for at least some of the potentially nausea inducing events is based on the velocity of the potentially nausea inducing events.

Images