Method and device for changing a user-defined driving mode based on an occurring situation

Abstract

The present disclosure relates to a method and apparatus for a user-defined driving mode to change based on an occurring condition. A system includes a processor configured to receive a first set of user-selected parameters including a user-defined first parameter value, the first set of user-selected parameters defining a condition for enabling a user-selected particular vehicle driving mode. The processor is further configured to receive data indicative of a current parameter value, and in response to the current parameter value matching the user-defined first parameter value, automatically enabling the user-selected particular vehicle driving mode.

Description

TECHNICAL FIELD

[0001] Illustrative embodiments relate generally to methods and apparatuses for user-defined driving modes that change based on occurring conditions. BACKGROUND

[0002] Vehicles often provide different driving modes that change not only traction, but also elements such as, but not limited to, steering, handling, suspension, powertrain, calibration, and exhaust. These driving modes provide a customized driving experience that can change based on factors such as speed or road conditions and produce different results with the settings changes. Essentially, under similar conditions, a customer can select a mode to change the way the vehicle feels to drive compared to other modes.

[0003] These driving modes are often not as conveniently activated as other functions in the vehicle. For example, a customer can have to manually reach behind the shifter to press a button and this can be inconvenient in a manual drive vehicle because one hand is typically on or near the shifter and the other hand is on the steering wheel. Thus, it is often difficult to change the driving mode at any time the road conditions change to produce a desired change, or even just when a new driving experience change is desired. SUMMARY

[0004] In a first illustrative embodiment, a system includes a processor configured to receive a first set of user-selected parameters including a user-defined first parameter value, the first set of user-selected parameters defining a condition for enabling a user-selected particular vehicle driving mode. The processor is further configured to receive data indicative of a current parameter value and, in response to the current parameter value matching the user-defined first parameter value, automatically enable the user-selected particular vehicle driving mode.

[0005] In a second illustrative embodiment, a system includes a processor configured to determine that a vehicle has entered an area defined by user-specified geographic coordinates. The processor is further configured to determine that a secondary condition parameter associated with a user-selected driving mode has been satisfied, the user-selected driving mode also being associated by a user with the user-specified geographic coordinates, and, in response to the vehicle being located in the area and the secondary condition parameter being satisfied, automatically enable the user-selected driving mode.

[0006] In a third illustrative embodiment, a system includes a processor configured to determine that a vehicle is entering or is located within a user-defined geo-fence region, the user-defined geo-fence region having a user-specified driving mode associated with the user-defined geo-fence region. The processor is further configured to automatically enable the user-specified driving mode in response to the determination. BRIEF DESCRIPTION OF DRAWINGS

[0007] Figure 1 An illustrative vehicle computing system is shown;

[0008] Figure 2 An illustrative example of driving mode enablement configuration processing is shown;

[0009] Figure 3 An illustrative example of driving mode enablement processing is shown. DETAILED DESCRIPTION

[0010] Detailed embodiments are disclosed herein; however, it is to be understood that the disclosed embodiments are merely illustrative of the claimed subject matter and can be practiced in various and alternative forms. The figures are not necessarily drawn to scale; some features can be exaggerated or minimized for the sake of clarity. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to utilize the claimed subject matter in a variety of

[0011] Figure 1 An example block topology diagram of a vehicle-based computing system (VCS) 1 for a vehicle 31 is shown. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by Ford Motor Company. A vehicle provided with a vehicle-based computing system can include a visual front end interface 4 located in the vehicle. If the interface is provided with, for example, a touch sensitive screen, a user is also able to interact with the interface. In another illustrative embodiment, interaction is through button presses, a spoken dialogue system with automatic speech recognition and speech synthesis.

[0012] In Figure 1In the illustrative embodiment 1 shown, the processor 3 controls at least some of the operation of the vehicle-based computing system. The processor, which is disposed within the vehicle, allows for on-board processing of commands and routines. In addition, the processor is connected to both a non-persistent memory 5 and a persistent memory 7. In this illustrative embodiment, the non-persistent memory is random access memory (RAM) and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-transitory) memory can include all forms of memory that save data when a computer or other device is powered down. These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid state drives, portable USB drives, and any other suitable form of persistent memory.

[0013] The processor is also provided with a number of different inputs that allow a user to interact with the processor. In this illustrative embodiment, a microphone 29, auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which can be a touch screen display), and a Bluetooth input 15 are all provided. An input selector 51 is also provided to allow the user to switch between the various inputs. The inputs for both the microphone and the auxiliary connector are analog to digital converted by a converter 27 before being passed to the processor. Although not shown, numerous vehicle components and auxiliary components that communicate with the VCS can use the vehicle network (such as, but not limited to, a CAN bus) to pass data to and from the VCS (or components thereof).

[0014] The outputs of the system can include, but are not limited to, the visual display 4 and a speaker 13 or stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 through a digital to analog converter 9. Output to a remote Bluetooth device (such as a personal navigation device (PND) 54) or a USB device (such as a vehicle navigation device 60) can also be generated along the bidirectional data streams shown at 19 and 21, respectively.

[0015] In one illustrative embodiment, the system 1 uses the Bluetooth transceiver 15 to communicate (17) with a user's mobile device 53 (e.g., a cell phone, smart phone, PDA (personal digital assistant), or any other device with wireless remote network connectivity capabilities). The mobile device can then be used to communicate (59) with a network 61 outside of the vehicle 31 through, for example, communication (55) with a cell tower 57. In some embodiments, the cell tower 57 can be a Wi-Fi access point.

[0016] Exemplary communication between the mobile device and the Bluetooth transceiver is represented by signal 14.

[0017] Pairing of the mobile device 53 with the Bluetooth transceiver 15 can be indicated by a button 52 or similar input. Accordingly, the CPU is instructed that the on-board Bluetooth transceiver is to pair with the Bluetooth transceiver in the mobile device.

[0018] Data can be transferred between the CPU 3 and the network 61 using, for example, a data plan associated with the mobile device 53, voice over data, or DTMF tones. Alternatively, it can be desirable to include an on-board modem 63 with antenna 18 to transfer data between the CPU 3 and the network 61 over the voice band (16). The mobile device 53 can then be used to communicate (59) with the network 61 outside the vehicle 31 by, for example, communicating (55) with a cell tower 57. In some embodiments, the modem 63 can establish communication (20) with the cell tower 57 to communicate with the network 61. As a non-limiting example, the modem 63 can be a USB cellular modem and the communication 20 can be a cellular communication.

[0019] In one illustrative embodiment, the processor is provided with an operating system that includes an API (application program interface) for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to accomplish wireless communication with a remote Bluetooth transceiver (such as found in a mobile device). Bluetooth is a subset of the IEEE 802 PAN (personal area network) protocol. The IEEE 802 LAN (local area network) protocol includes Wi-Fi and has considerable overlap with the IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Another mode of communication that can be used in the art is free space optical communication (such as IrDA) and non-standardized consumer infrared (IR) protocols.

[0020] In another embodiment, the mobile device 53 includes a modem for voice band or broadband data communications. In a voice over data embodiment, when the owner of the mobile device can speak through the device while data is being transferred, a technique known as frequency division multiplexing can be implemented. At other times, when the owner is not using the device, the data transfer can use the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although frequency division multiplexing would be common for analog cellular communications between a vehicle and the Internet, and is still used, it has largely been replaced by a mixture of code division multiple access (CDMA), time division multiple access (TDMA), and space division multiple access (SDMA) for digital cellular communications. If the user has a data plan associated with the mobile device, the data plan can allow broadband transmission, and the system can use a much wider bandwidth (speed up data transfer). In another embodiment, the mobile device 53 is replaced by a cellular communication device (not shown) installed to the vehicle 31. In another embodiment, the mobile device (ND) 53 can be a wireless local area network (LAN) device capable of communicating over, for example, but not limited to, an 802.11g network (i.e., Wi-Fi) or a WiMax network.

[0021] In one embodiment, incoming data can pass through the mobile device via voice over data or a data plan, through the on-board Bluetooth transceiver, and into the vehicle's internal processor 3. In the case of certain temporary data, for example, the data can be stored on the HDD or other storage medium 7 until the data is no longer needed.

[0022] Other sources that can interface with the vehicle include a personal navigation device 54 with, for example, a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 with a USB 62 or other connection, an on-board GPS device 24, or a remote navigation system (not shown) with connectivity to a network 61. USB is a type of serial networking protocol. IEEE 1394 (Firewire™ (Apple), i.LINK™ (Sony), and Lynx™ (Texas Instruments)), EIA (Electronic Industries Association) serial protocols, IEEE 1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Developer Forum) form the backbone of device-to-device serial standards. Most protocols can be implemented for electrical or optical communications.

[0023] In addition, the CPU can communicate with various other auxiliary devices 65. These devices can be connected by a wireless connection 67 or a wired connection 69. Auxiliary devices 65 can include, but are not limited to, a personal media player, a wireless health device, a portable computer, etc.

[0024] Additionally or alternatively, the CPU can be connected to a vehicle-based wireless router 73 using, for example, a Wi-Fi (IEEE 803.11) transceiver 71. This can allow the CPU to connect to remote networks within range of the local router 73.

[0025] In addition to the exemplary processes being performed by a vehicle computing system located in a vehicle, in certain embodiments, the exemplary processes can also be performed by a computing system in communication with the vehicle computing system. Such systems can include, but are not limited to, a wireless device (such as, but not limited to, a mobile phone) or a remote computing system (such as, but not limited to, a server) connected through the wireless device. Such systems can be collectively referred to as a vehicle-associated computing system (VACS). In certain embodiments, particular components of the VACS can perform particular portions of the processes depending on the particular implementation of the system. By way of example and not limitation, if a process has a step of sending or receiving information with a paired wireless device, it is likely that the wireless device does not perform that portion of the process since the wireless device does not "send and receive" information with itself. One of ordinary skill in the art will understand when it is inappropriate to apply a particular computing system to a given solution.

[0026] In each of the illustrative embodiments discussed herein, an exemplary, non-limiting example of a process that can be performed by a computing system is shown. For each process, the computing system performing the process can become a special purpose processor configured to perform the process for the limited purpose of performing the process. All processes need not be performed and are understood to be examples of the type of processes that can be performed to implement elements of the application. Additional steps can be added to the exemplary processes or additional steps can be removed from the exemplary processes as desired.

[0027] With respect to the illustrative embodiments described in the figures showing illustrative process flows, it should be noted that a general purpose processor can temporarily act as a special purpose processor for the purpose of performing some or all of the exemplary methods shown by these figures. When code providing instructions to perform some or all of the steps of the method is executed, the processor can temporarily change its intent to act as a special purpose processor until the method is complete. In another example, to the extent appropriate, firmware operating according to a preconfigured processor can cause the processor to act as a special purpose processor provided for the purpose of performing the method or some reasonable variation of the method.

[0028] Many modern vehicles have multiple options for driving modes that engage different vehicle systems in different ways to provide improved speed, improved handling, better traction control, etc. Most of these driving modes are context-specific and the driver often does not know when the mode will be engaged, or otherwise occupied, or has no time or foresight to engage a particular mode.

[0029] Even when a driver electively uses a particular mode, the driver can want to always use the mode in certain situations. However, because driving requires attention and because the driver is often distracted by other concerns, the driver can find it annoying to constantly enable the mode when needed and disable the mode when not needed. For some situations that occur frequently but also change when the driver enters and leaves a particular road (such as highway driving), the driver can find the mode switching too cumbersome and can simply use the basic mode that the vehicle normally operates in.

[0030] Illustrative embodiments allow a driver to assign parameters to a particular driving mode so that when the parameters are met, the vehicle automatically enables the driving mode. In the presented example, the driver can draw a perimeter for specifying a driving mode (i.e., the mode is enabled when entering an area through the perimeter and disabled when leaving the area defined by the perimeter). Alternatively, for example, the driver can specify an object and a proximity, and a particular mode can be enabled when within the defined proximity of the object. In other instances, the driver can specify particular driving conditions under which the mode is enabled, which would allow for automatic mode enabling when these conditions are encountered. For example, even if the driver is within a perimeter, the mode enabling can (based on settings) require that certain parameters be met, and for example, unless the driver is within the perimeter and driving over 40 miles per hour, a mode change will occur.

[0031] Figure 2 An illustrative example of the process of driving mode enabling configuration is shown. In this example, the driver configures one or more driving mode scenarios. This can be done through a vehicle display that allows parameter definition, a phone, a computer, or any other interactive object, and ultimately the parameter sets can be stored in a manner accessible to the vehicle.

[0032] Here, at 201, the process receives a configuration request and begins the process of mode configuration. At 203, the driver specifies a particular driving mode (e.g., sport, off-road, track, normal). Changing the driving mode can control multiple aspects of the vehicle, such as but not limited to, powertrain, steering, suspension, effective exhaust, etc. Then, at 205, the process determines whether a geographic or non-geographic parameter is associated with the mode. Notably, both types of parameters can be associated with a single mode change.

[0033] If the parameter is a geographic property, at 207 the process can display a map including selectable regions so that the driver can select a region for which the mode will apply. For example, the driver can also enter a coordinate, building, location, or city name for which the mode will apply. For example, if a city is known to have strict limits on noise for a particular aspect, the driver can specify the city and the vehicle will limit noise output while in the city. Here, at 209, the process receives a set of coordinates selected by the driver from the map. Then, at 211, the process associates the selected mode with the coordinates.

[0034] If the mode has non-geographic parameters associated with it, at 213 the process can present a set of definable parameters that can be associated with the mode change. For example, the set of parameters can include speed, weather detection, night driving, road conditions, etc. The driver selects any particular parameters relevant to the mode selection, and at 215 the process receives driver-defined values for those parameters. Then, the process associates the values with the particular driving mode at 217, and saves the indicated changes at 219.

[0035] Thus, for example, the driver can select an off-road mode for a stretch of unpaved road on the way to work. This can be a purely geographic parameter, and the vehicle will transition to the off-road mode whenever it is within a defined set of coordinates constituting the unpaved road. The driver can also select a sports mode for all highways, with an additional parameter setting a minimum vehicle speed of 50 mph. Thus, if the map data indicates a highway and the driver is still driving above 50 mph, the vehicle will enable the sports mode. If the vehicle speed drops below 50 mph, the vehicle can disable the sports mode even if still on a highway, and revert to normal or standard mode.

[0036] Figure 3 An illustrative example of the driving mode enablement process is shown. In this example, at 301 the process receives an indication that driving has begun and / or an indication that the GPS coordinates for a mode change are within a predefined distance. The process can execute in the background while driving is in progress, or can set a trigger state associated with at least one parameter (GPS, time, weather, etc.) for any defined mode change, so that if any of these parameters are met, the process executes and begins tracking any other required parameters for performing the mode change.

[0037] Once the process is executing, at 303 the process loads any mode settings associated with one or more of the driving modes that can be changed. This can include loading all mode parameters for tracking, or for example, all parameters within a predefined distance of the current vehicle location (for GPS-enabled modes) and / or any set of parameters that satisfy at least one variable condition.

[0038] Then, using vehicle sensor data (GPS, weather, speed, etc.) and / or remote data (weather, traffic, etc.), the process can start tracking current parameter values at 305 to determine when a set of parameters associated with a driving mode is matched at 307. Once a match occurs, the process can enable the driving mode associated with that particular matched set of parameters at 309.

[0039] Parameters can be defined for both mode enablement and mode termination, and different sets of parameters can be defined for the opening and closing of a driving mode instance. For example, a driver can set the process to enable a sport mode on a particular highway whenever the vehicle speed reaches 55, the weather is no precipitation within ten miles, and there is an indication of no slow traffic for at least five miles. The same mode can be disabled based on the speed dropping below 55, which would be a "reverse" of that trigger condition. But the weather trigger to disable the mode can be "precipitation within two miles," and the traffic trigger to disable the mode can be "slow traffic within one mile."

[0040] This essentially establishes a mode that is triggered when the driver can be able to enjoy using the mode for at least a certain period of time (represented by the extended weather and traffic parameters), and then enjoy it up until the point in time that the mode should actually be disabled (for the restricted parameters of weather and traffic). An alternative example is to disable the mode only when the driver slows down below 55, but requiring all of the parameters for mode enablement (indicating not just different values, but even different sets of parameters) can represent the trigger and disable conditions.

[0041] Using illustrative embodiments, a driver can establish a quasi-smart mode change setting for a vehicle that allows the driver to improve performance or experience improved use of a mode, while not distracting the driver's attention from the driving task. In addition to this, this can result in a more interesting driving experience and an improved customer experience.

[0042] While the foregoing describes exemplary embodiments, it is not intended to describe all possible forms of the application. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes can be made without departing from the spirit and scope of the application. Further, features of the various implemented embodiments can be combined in a logical manner to produce variations of the embodiments described herein that are appropriate for a particular implementation.

Claims

1. A system for changing a vehicle driving mode, comprising: a processor configured to: receive a first set of user-selected parameters, the first set of user-selected parameters comprising user-defined first parameter values, the first set of user-selected parameters defining conditions for enabling a user-selected particular vehicle driving mode; receive data indicative of current parameter values; in response to the current parameter values matching the user-defined first parameter values, automatically enabling the user-selected particular vehicle driving mode, wherein the particular vehicle driving mode is a vehicle driving mode used in particular circumstances defined by the first set of user-selected parameters, and the particular vehicle driving mode is selected from a sport mode, an off-road mode, a track mode, and a standard mode, wherein the first set of user-selected parameters comprises GPS coordinates, weather, traffic data, vehicle speed, time.

2. The system of claim 1, wherein, the user-defined first parameter values define a geofenced area.

3. The system of claim 2, wherein, the user-defined first parameter values comprise weather conditions.

4. The system of claim 2, wherein, the user-defined first parameter values comprise traffic levels.

5. The system of claim 2, wherein, the user-defined first parameter values comprise vehicle speed values.

6. The system of claim 2, wherein, the user-defined first parameter values comprise a time of day or a day of week.

7. The system of claim 1, wherein, the processor is further configured to: receive a second set of user-selected parameters, the second set of user-selected parameters comprising user-defined second parameter values, the second set of user-selected parameters defining conditions for disabling a previously automatically enabled user-selected vehicle driving mode.

8. The system of claim 7, wherein, the user-defined second parameter values are different from the user-defined first parameter values.

9. The system of claim 7, wherein, at least one of the first set of user-selected parameters and the second set of user-selected parameters comprises a parameter different from the other set.

10. A method for changing a vehicle driving mode, comprising: receiving a first set of user-selected parameters, the first set of user-selected parameters comprising user-defined first parameter values, the first set of user-selected parameters defining conditions for enabling a user-selected particular vehicle driving mode; receiving data indicative of current parameter values; in response to the current parameter values matching the user-defined first parameter values, automatically enabling the user-selected particular vehicle driving mode, wherein the particular vehicle driving mode is a vehicle driving mode used in particular circumstances defined by the first set of user-selected parameters, and the particular vehicle driving mode is selected from a sport mode, an off-road mode, a track mode, and a standard mode, wherein the first set of user-selected parameters comprises GPS coordinates, weather, traffic data, vehicle speed, time.

11. The method of claim 10, wherein, the user-defined first parameter values define a geofenced area.

12. The method of claim 11, wherein, the user-defined first parameter values comprise weather conditions.

13. The method of claim 11, wherein, the user-defined first parameter values comprise traffic levels.

14. The method of claim 11, wherein, the user-defined first parameter values comprise vehicle speed values.

15. The method of claim 11, wherein, the user-defined first parameter values comprise a time of day or a day of week.

16. The method of claim 10, further comprising: receiving a second set of user-selected parameters, the second set of user-selected parameters including a user-defined second parameter value, the second set of user-selected parameters defining a condition for disabling a previously automatically enabled user-selected vehicle driving mode.

17. The method of claim 16, wherein, The user-defined second parameter value is different from the user-defined first parameter value.

18. The method of claim 16, wherein, At least one of the first set of user-selected parameters and the second set of user-selected parameters includes a parameter that is different from the other set.

Images