Systems and methods for transferring automatic control of vehicle using virtual markings

Abstract

To provide systems and methods relating to transferring automatic control of a vehicle through emulating virtual markings and estimating a buffer zone.SOLUTION: In one embodiment, a method includes estimating a position for a takeover by a vehicle that is directly controlling driving maneuvers. The method also includes predicting an automated region from a transition time and the position for the takeover by an operator. The method also includes generating virtual markings for the takeover using the automated region and the position, wherein the virtual markings exist within the automated region and the position indicates an area for manual feedback to the vehicle.SELECTED DRAWING: Figure 3A

Description

[Technical Field]

[0001] The subject matter described herein relates generally to transferring automatic control to an operator, and more particularly to transferring automatic control of a vehicle using virtual marks and buffer zones. [Background technology]

[0002] The system coordinates automated vehicle takeovers, including transferring vehicle control from an automated system to an operator. In one approach, the system perceives the vehicle's surroundings using sensor data from cameras, light detection and ranging (LiDAR), radar, ultrasonic sensors, etc. For example, a vehicle may be equipped with a light detection and ranging (LIDAR) sensor that uses light to scan the surrounding environment, while logic associated with the LIDAR analyzes the acquired data to detect the presence of objects and other features in the environment. In a further example, additional / alternative sensors, such as cameras, may be implemented to acquire information about the surrounding environment from which the system derives perception of aspects of the surrounding environment. Perception may include monitoring the environment for potential hazards, obstacles, and situations in which the automated system may find it difficult to safely navigate. The system may also assess the risk level of the potential hazard and, depending on data quality, determine whether transferring control to the operator is safe. The system notifies the operator when intervention can mitigate collision risk through a warning. Nevertheless, a system that assesses risk levels and generates warnings may impact safety if the data is inaccurate and the warning is poorly timed.

[0003] In various implementations, the system plans a takeover rather than using sensor data to monitor the environment for situational risk. For example, an automated system for a vehicle has capabilities for situations within a highway environment. Therefore, the automated system coordinates with other systems to schedule a takeover to an operator when outside the highway environment. However, a planned system-coordinated takeover encounters difficulties in preparing the operator and calculating thresholds from data availability to gracefully transfer control. Therefore, a system-managed takeover for an automated vehicle faces challenges related to safety and timeliness from analyzing the situation and planning. Summary of the Invention

[0004] In one embodiment, an exemplary system and method relates to transferring automated control of a vehicle using estimated virtual marks and buffer zones. In various implementations, the automated vehicle has operational thresholds set by the manufacturer. The operational thresholds can be for situations where a scenario is overly complex for the vehicle's capabilities and equipment. Other thresholds are, for example, conditions such as operation during poor visibility or inclement weather. The system considers the operational thresholds when evaluating the need to change control of the automated vehicle, such as a takeover from an automated system. Here, a takeover can be when the automated vehicle transfers vehicle control (e.g., steering, braking, acceleration, etc.) from the automated system to an operator. Takeovers that the system predicts and adjusts for can face challenges from the transfer of control associated with the takeover, such as the operator being insufficiently attentive to the driving environment and ignoring transition warnings (e.g., audible alarms).

[0005] Thus, in one embodiment, the estimation system predicts an end point for automated driving and assists the operator with taking over to a state involving manual commands using a virtual mark. Here, the automated region may exist geographically between the current location and the end point. When the vehicle transitions to a state beyond the end point known through prediction (e.g., leaving the mapping zone), the estimation system notifies the operator of the takeover using the virtual mark and feedback before the transition time. In particular, the transition time may serve as a buffer zone for the transition requiring manual control from the operator. For example, a head-up display outputs a virtual mark as a caution zone within the automated region. Furthermore, the estimation system emulates physical effects (e.g., an audible alarm, a vibrating component) associated with the virtual mark at a point within the caution zone. In one approach, the estimation system automatically stops the vehicle if the operator's takeover and manual control of the vehicle during the transition time are insufficient. The estimation system therefore prepares the operator for the takeover by predicting the end point and virtually emulating road markings, thereby improving the comfort and safety associated with automated driving.

[0006] In one embodiment, an estimation system is disclosed for transferring automatic control of a vehicle through emulating virtual marks and estimating a buffer zone. The estimation system includes a memory storing instructions that, when executed by a processor, cause the processor to estimate a position for takeover by a vehicle directly controlling the driving maneuver. The instructions also include instructions for predicting an automatic region from a transition time and a position for takeover by an operator. The instructions also include instructions for generating a virtual mark for takeover using the automatic region and the position, the virtual mark being within the automatic region and the position indicating an area for manual feedback to the vehicle.

[0007] In one embodiment, a non-transitory computer-readable medium is disclosed that transfers automatic control of a vehicle through emulating virtual marks and estimating a buffer zone, and that includes instructions that, when executed by a processor, cause the processor to perform one or more functions. The instructions include instructions for estimating a position for takeover by a vehicle directly controlling the driving maneuver. The instructions also include instructions for predicting an automatic region from a transition time and a position for takeover by an operator. The instructions include instructions for generating a virtual mark for takeover using the automatic region and the position, the virtual mark being within the automatic region and the position indicating an area for manual feedback to the vehicle.

[0008] In one embodiment, a method for transferring automatic control of a vehicle through emulating a virtual mark and estimating a buffer zone is disclosed. In one embodiment, the method includes estimating a position for takeover by a vehicle directly controlling the driving maneuver. The method also includes predicting an automatic region from a transition time and a position for takeover by an operator. The method also includes generating a virtual mark for takeover using the automatic region and the position, the virtual mark being within the automatic region and the position indicating an area for manual feedback to the vehicle. [Brief explanation of the drawings]

[0009] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate various systems, methods, and other embodiments of the present disclosure. It will be understood that the boundaries of elements shown in the figures (e.g., boxes, groups of boxes, or other shapes) represent one embodiment of the boundaries. In some embodiments, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some embodiments, an element shown as an internal component of another element may be implemented as an external component, and vice versa. Additionally, elements may not be drawn to scale.

[0010] [Figure 1]FIG. 1 illustrates an embodiment of a vehicle in which the systems and methods disclosed herein may be implemented. [Figure 2] FIG. 1 illustrates an embodiment of an estimation system associated with transferring automatic control of a vehicle using estimated virtual marks and buffer zones. [Figure 3A] 3 illustrates an embodiment of the estimation system of FIG. 2 generating virtual marks for takeovers, as well as diagrams including automatic regions and positions. [Figure 3B] 3 illustrates an embodiment of the estimation system of FIG. 2 generating virtual marks for takeovers, as well as diagrams including automatic regions and positions. [Figure 4] FIG. 1 illustrates one embodiment of a method associated with predicting transition time and autonomous region for a vehicle from a position relative to operator takeover. DETAILED DESCRIPTION OF THE INVENTION

[0011] Systems, methods, and other embodiments associated with transferring automatic control of a vehicle through the emulation of virtual marks and estimation of buffer zones are disclosed herein. In various implementations, a vehicle has geographical limitations for primarily automatically controlling driving maneuvers without manual oversight. For example, a vehicle may drive autonomously on freeways and in areas with high-definition (HD) maps, and in other cases, hand over control to an operator through a takeover procedure. Here, the vehicle may display the driving situation, its perceived surroundings, and notify the operator of changes associated with autonomous driving. Thus, the operator may develop situational awareness from the driving situation that informs the operator about safe behavior, upcoming hazards, and reasons for takeover from autonomous driving. However, the vehicle's warning of the situational awareness to the operator may be loud and unpleasant, especially when hazards are imminent. Furthermore, systems using subtle warnings may be inadequate in informing the operator about driving conditions. Therefore, systems that assist the operator with situational awareness for autonomous driving for takeover may experience surprise and delays, thereby reducing safety.

[0012] Therefore, in one embodiment, the estimation system generates an interface and warnings through virtual marks to develop situational awareness and gently inform the operator of the takeover from autonomous driving. Here, the estimation system can predict the autonomous region from the transition time and location relative to the takeover. The autonomous region can be an area where the vehicle remains in primary control of the operation with minimal manual feedback (e.g., fully automated) according to changing conditions, automation level, geography, etc. For example, the autonomous region is an area changing from a high-speed area to a local area. The estimation system can calculate the location to determine the autonomous region from map data (e.g., road edges, road boundaries, etc.), vehicle speed, and inferred perception of the surrounding area from sensor data. The transition time can be a buffer zone scheduled for when the vehicle 100 requires manual feedback from the time when capability becomes insufficient for autonomous driving. Therefore, the vehicle can share control with the operator during the transition time, so that the operator inputs primary commands and the vehicle assists with secondary commands.

[0013] Furthermore, in one embodiment, the estimation system generates virtual markers for takeover using the autonomous region and location. For example, the vehicle displays the virtual markers on a head-up display (HUD) through the overlay of an image that augments the scene around the vehicle. Here, the virtual markers may emulate caution zones on the road using warning points. For example, the estimation system vibrates vehicle elements (e.g., steering wheel, seat, etc.) in response to warning points in the caution zone that mimic rumble strips to indicate the end of the autonomous region and an upcoming takeover. In another approach, if the operator's takeover and manual control during the transition time are insufficient, the vehicle automatically stops. In this way, the estimation system develops situational awareness for the operator while preventing dangerous scenarios in which autonomous driving is not possible after the buffer zone. Therefore, the estimation system assists the operator in developing an understanding of the operating region associated with the vehicle's capabilities, thereby improving reliability and safety for autonomous driving.

[0014] Referring to FIG. 1 , an example of a vehicle 100 is shown. As used herein, a “vehicle” is any form of motorized transportation. In one or more implementations, the vehicle 100 is an automobile. While mechanisms related to automobiles are described herein, it will be understood that the embodiments are not limited to automobiles. In some implementations, the estimation system 170 uses roadside units (RSUs), consumer electronics (CEs), mobile devices, robots, drones, etc. that benefit from the functionality described herein associated with transferring automatic control of the vehicle using estimated virtual marks and buffer zones.

[0015] Vehicle 100 also includes various elements. It will be understood that in various embodiments, vehicle 100 may have fewer elements than those shown in FIG. 1 . Vehicle 100 may have any combination of the various elements shown in FIG. 1 . Furthermore, vehicle 100 may have additional elements to those shown in FIG. 1 . In some arrangements, vehicle 100 may be implemented without one or more of the elements shown in FIG. 1 . While various elements are shown as being located within vehicle 100 in FIG. 1 , it will be understood that one or more of the elements may be located external to vehicle 100. Furthermore, the elements shown may be physically separated by large distances. For example, as discussed, one or more components of the system of the present disclosure may be implemented within the vehicle, while additional components of the system are implemented in a cloud computing environment or other system remote from vehicle 100.

[0016] Some of the possible elements of vehicle 100 are shown in FIG. 1 and described in conjunction with subsequent figures. However, a description of many of the elements of FIG. 1 is provided following the description of FIGS. 2-4 for brevity of this description. Furthermore, it will be understood that, for simplicity and clarity of illustration, reference numerals have been appropriately repeated among different figures to indicate corresponding or similar elements. Additionally, the description outlines numerous specific details to provide a thorough understanding of the embodiments described herein. However, those skilled in the art will appreciate that the embodiments described herein may be implemented using various combinations of such elements. In either case, vehicle 100 includes an estimation system 170, which is implemented to perform the methods and other functions as disclosed herein related to transferring automatic control of the vehicle using estimated virtual marks and buffer zones.

[0017] Referring to FIG. 2 , one embodiment of the estimation system 170 of FIG. 1 is further illustrated. The estimation system 170 is illustrated as including the processor 110 of the vehicle 100 of FIG. 1 . Thus, the processor 110 may be part of the estimation system 170, the estimation system 170 may include a processor separate from the processor 110 of the vehicle 100, or the estimation system 170 may access the processor 110 through a data bus or another communication path. In one embodiment, the estimation system 170 includes a memory 210 that stores an emulation module 220. The memory 210 may be a random access memory (RAM), a read-only memory (ROM), a hard disk drive, a flash memory, or other suitable memory that stores the emulation module 220. The emulation module 220 may be, for example, computer-readable instructions that, when executed by the processor 110, cause the processor 110 to perform various functions disclosed herein.

[0018] 2 is generally an abstract form of the inference system 170 as may be implemented between the vehicle 100 and a cloud computing environment. Furthermore, the inference system 170 and the emulation module 220 generally include instructions that function to control the processor 110 to receive data input from one or more sensors of the vehicle 100. In one embodiment, the input is observations of one or more objects and / or other aspects of the surroundings in an environment proximate the vehicle 100. As provided herein, in one embodiment, the inference system 170 acquires sensor data 250 including at least camera images. In a further mechanism, the inference system 170 acquires sensor data 250 from additional sensors, such as the radar sensor 123, the lidar sensor 124, and other sensors, as may be suitable for identifying the vehicle and its location.

[0019] Thus, in one embodiment, estimation system 170 controls each sensor to provide data input in the form of sensor data 250. Furthermore, although estimation system 170 is described as controlling various sensors to provide sensor data 250, in one or more embodiments, estimation system 170 may employ other techniques, either active or passive, for acquiring sensor data 250. For example, estimation system 170 may passively discover sensor data 250 from streams of electronic information provided by various sensors to additional components within vehicle 100. Furthermore, estimation system 170 may perform various techniques to fuse data from multiple sensors when providing sensor data 250 and / or from sensor data acquired over wireless communication links. Thus, in one embodiment, sensor data 250 represents a combination of perceptions acquired from multiple sensors.

[0020] In addition to the locations of surrounding vehicles, sensor data 250 may also include, for example, information about lane markings, etc. Of course, in alternative embodiments, estimation system 170 may obtain sensor data for only the forward direction, for example, when vehicle 100 does not have additional sensors to include additional areas around the vehicle and / or the additional areas are not scanned for other reasons.

[0021] Additionally, in one embodiment, estimation system 170 includes data store 230. In one embodiment, data store 230 is a database. In one embodiment, a database is an electronic data structure stored in memory 210 or another data store that is comprised of routines that can be executed by processor 110 to analyze the stored data, present the stored data, organize the stored data, etc. Thus, in one embodiment, data store 230 stores data used by emulation module 220 in performing various functions. In one embodiment, data store 230 includes sensor data 250 along with metadata that characterizes various aspects of sensor data 250, for example. For example, the metadata may include location coordinates (e.g., longitude and latitude), relative map coordinates or tile identifiers, time / date stamps from when the separate sensor data 250 was generated, etc.

[0022] In another embodiment, data store 230 further includes transition time 240, which represents a buffer zone during which vehicle 100 requires the operator to assume primary control of the driving maneuver after takeover. Transition time 240 may factor in operator attentiveness derived from sensor data 250, the stopping distance of vehicle 100, and the level of automation associated with the driving maneuver. For example, transition time 240 is longer than the stopping distance and buffer time. In this manner, if the operator performs insufficient action during transition time 240, inference system 170 and vehicle 100 may trigger a safety action.

[0023] 3A and 3B, an embodiment of the inference system 170 of FIG. 2 that generates virtual markers for takeover, as well as diagrams including an automatic region and location, is shown. FIG. 3A ameliorates the challenge of alerting the operator to a takeover through increased situational awareness and knowledge of the vehicle's 100 operating region, where the takeover may be triggered by a changing condition (e.g., weather), a scheduled event, or the like on the road 310. Rather than suddenly presenting the operator of the vehicle 100 with an impending event-triggered transition through escalating alerts, the inference system 170 generates an environment and feedback 300 that gradually naturalizes the takeover. As explained further below, the environment and feedback 300 reduces operator stress by gently assisting the operator in the takeover with an automatic region 320 and transition time 330 using visual and haptic feedback, thereby improving the system experience and comfort. With respect to automated region 320, the region may be an area where the vehicle remains in a state where it primarily controls operation with limited manual feedback (e.g., full automation) according to changing conditions, automation level, geography, etc. For example, an automated region is an area where a highway ends at upcoming intersection 350.

[0024] 3A , in one embodiment, estimation system 170 is further configured to perform additional tasks beyond controlling each sensor to obtain and provide sensor data 250. For example, estimation system 170 includes instructions that cause processor 110 to estimate a position 340 for takeover by vehicle 100 directly controlling driving maneuvers within roadway 310. Here, position 340 may represent a planned location and geographic boundaries for the takeover using map data (e.g., road edges, road boundaries, etc.) as the geography changes from highway areas to local areas. Furthermore, the operator and estimation system 170 may negotiate a planned location for transfer from automated control, such as through route planning. For example, scheduling a takeover may include comparing position 340 to map data to indicate that vehicle 100 cannot autonomously control driving maneuvers beyond automated region 320 and that the operator may manage the takeover.

[0025] Furthermore, geographic boundaries may exist during automated driving, from when the automation level is unable to primarily control the vehicle 100, for example, at reduced speeds. The automation level may be one of levels 0 to 5 defined by the Society of Automotive Engineers (SAE). The automation level may classify the degree to which the vehicle 100 can operate with limited or no human input. Level 0 is a lack of automation, whereby the operator controls the vehicle 100. Level 1 is driver assistance, such as cruise control and lane keeping, where the vehicle 100 assists the operator with limited driving commands. Level 2 includes partial automation, where the vehicle 100 controls steering and speed under certain conditions while requiring operator attention (e.g., Autopilot by Tesla). Level 3 is conditional automation, whereby the vehicle 100 can handle primary driving tasks under certain conditions while requiring the operator to be ready to take over when prompted. Level 4 is high automation, where vehicle 100 can operate automatically in predetermined conditions or areas while requiring operator intervention during limited scenarios. Level 5 involves full automation, whereby vehicle 100 performs driving tasks under most conditions without operator intervention (e.g., steering, pedal use, etc.).

[0026] Along with the automation level, in one approach, the estimation system 170 triggers a takeover at location 340 due to driving conditions that conflict with the automation level. For example, when another vehicle 1002, as shown in the virtual representation, is maneuvering aggressively, the vehicle 100 cannot operate under level 5. Similarly, when the road 310 is icy, the vehicle 100 cannot operate under level 4. Thus, the estimation system 170 may use map data, automation level, driving conditions, etc. to estimate locations for scheduled and unscheduled takeovers of the vehicle 100.

[0027] Further, in one embodiment, the estimation system 170 may predict the automated region 320 from the transition time 330 and the location 340 for operator takeover. For example, the estimation system 170 calculates the location to determine the automated region 320 from map data, the vehicle speed toward the location 340, and an estimated perception of the surrounding area from the sensor data 250. The transition time may be a buffer zone scheduled for when the vehicle 100 requires manual feedback from when capabilities become insufficient for autonomous driving. In one approach, the transition time 330 is predetermined according to the automation level and the automation level's capability for autonomously controlling the vehicle 100 within the area. For example, the transition time 330 is a buffer zone required for the vehicle 100 to transfer control from Level 5 to Level 1 to the operator when approaching an intersection 350. A transfer and takeover may be required from when the Level 5 specification for the vehicle 100 is unable to safely navigate the intersection 350 and the operator should primarily control the vehicle 100 for safety reasons.

[0028] In various implementations, the emulation module 220 generates a virtual mark for takeover using the automated region 320 and the location 340. For example, the virtual mark resides within the automated region 320, and the location 340 indicates an area where manual feedback of the vehicle 100 begins. Here, the vehicle 100 may use the output system 135 to display the virtual mark, the virtual twin 1001 of the vehicle 100, and the vehicle 1002 ahead on the road 310. The display of the virtual mark may assist the operator in understanding the operational region and automation level capabilities, as well as situational awareness. Thus, the virtual mark may reduce stress and increase comfort when the vehicle 100 transitions under automated control during the automated region 320 and the transition time 330 (e.g., a few seconds) when operator control resumes.

[0029] 3B , in one approach, the emulation module 220 and output system 135 display a virtual mark 360 on the road 310 beyond the virtual twin 1001 to clearly indicate the upcoming transition time 330. Here, the location 340 may be a region edge where automated control of the vehicle 100 will end due to a change in geography, driving conditions, perceptual predictions, position predictions, etc., requiring manual input. The virtual mark 360 may be feedback generated in the HUD through the overlay of an image that augments the scene around the vehicle 100. For example, the virtual mark 360 may emulate a caution zone, painted line, slow speed zone, etc., on the road 310 in the scene. Thus, the virtual mark 360 may warn of the end of automated control due to, for example, an upcoming toll booth, a school entrance / exit, etc. In another approach, the emulation module 220 color-codes the virtual mark 360 and the automated region 320 according to, for example, automation level, automation status, etc. This may include using defined colors (e.g., yellow, white, etc.) to indicate proximity to transition time 330 and location 340. In this way, the operator becomes familiar with transitions between areas requiring automatic control and manual input.

[0030] The automatic region 320 with the virtual mark 360 and the transition time 330 may define a release zone for the vehicle 100. The automatic region 320 may be associated with a distance and time (e.g., seconds) until the takeover at the location 340. In one approach, the virtual mark 360 is accompanied by an audible, tactile, or other warning of the takeover prior to the transition time 330. Here, one or more actuators 150 may vibrate vehicle elements corresponding to points within the attention zone. The one or more actuators 150 may be one of a dedicated electromagnetic suspension and a haptic motor. The vehicle elements may be one of a seat base, a holster, a chassis, and a steering wheel. For example, the haptic motor may progressively vibrate the steering wheel along the points of the virtual mark 360 as the vehicle 100 approaches the location 340 and the transition time 330. The vibrations triggered as the vehicle 100 passes points along the virtual mark 360 may also mimic rumble strips. Similarly, the vehicle 100 controls the electromagnetic suspension to move, oscillate, pivot, etc., the chassis in a manner that replicates the feel of virtual markings 360 and rumble strips along the road 310. Additionally, the automatic region 320 and transition time 330 may be visually distinct within the release zone. In one approach, the emulation module 220 displays the transition time 330 in a more prominent color (e.g., red) than the automatic region 320. In this way, the operator cognitively understands and builds awareness regarding different areas and stages of takeover, thereby improving driving comfort and safety.

[0031] Upon reaching transition time 330, estimation system 170 further assists the operator in transferring vehicle 100 from automatic control. Here, transition time 330 may begin at a location 340 that estimation system 170 predicts prior to the actual transition. Transition time 330 may provide the operator with sufficient time for gradual takeover and manual input by factoring vehicle speed and operator preference (e.g., full manual, level 1 automation, etc.). During transition time 330, vehicle 100 and operator may share control, such that during transition time, the operator inputs primary commands and vehicle 100 assists with secondary commands. For example, primary commands may be steering and speed, while secondary commands may be headlight adaptation, brake assist (i.e., pre-charge braking), etc. Thus, unlike in automatic region 320, the operator has primary control of vehicle 100 during transition time 330.

[0032] Additionally, transition time 330 may factor in the current stopping distance for vehicle 100 and the operator-related response time. Stopping distance is a factor in the event that takeover fails if transition time 330 expires. Response time may be an indicator of operator cognitive alertness derived from sensor data 250 associated with driver monitoring. Response time may also be predetermined by the National Highway Traffic Safety Administration (NHTSA), SAE, or the like. For example, NHTSA sets 10 seconds for scheduling transfer of control from Level 3 following cognitive study plus a buffer period. In one approach, estimation system 170 calculates transition time 330 using current speed, stopping distance, position 340, etc. In this manner, transition time 330 is at least as long as the stopping distance plus additional time for safety.

[0033] If the operator's takeover and manual control of vehicle 100 during the transition time includes insufficient behavior, emulation module 220 and output system 135 may generate additional warnings (e.g., visual, audible, etc.). For example, the additional warnings escalate visually, audibly, tactilely, etc. until sensor data 250 indicates sufficient awareness by the operator. If behavior after the additional warnings is still insufficient, autonomous driving module 160 automatically stops and pulls over vehicle 100 near the end of transition time 330. Thus, estimation system 170 uses virtual marks to improve the transition and takeover of vehicle 100 from automatic control while maintaining safety when the operator's manual control is insufficient.

[0034] Referring now to FIG. 4 , a flowchart of a method 400 associated with transferring automatic control of a vehicle using estimated virtual marks and buffer zones is shown. Method 400 is described in terms of estimation system 170 of FIGS. 1 and 2 . While method 400 is described in conjunction with estimation system 170, it should be understood that method 400 is not limited to implementation within estimation system 170, but is merely an example of a system in which method 400 may be implemented. Furthermore, method 400 reduces unnecessary stress and feelings of urgency from reliance on automatic control through the use of virtual marks to improve takeover and manual control. Method 400 also enhances the operator's understanding of system capabilities, availability, and limitations regarding automatic control that establish operating boundaries. In this way, estimation system 170 also prevents difficult and unavailable automatic control by encouraging the operator to heed warnings rather than ignore them.

[0035] At 410, the estimation system 170 estimates a location for the takeover. Here, the location may represent a geographic boundary for the planned takeover estimated using map data (e.g., road edges, road boundaries, etc.). For example, the geography may change from a highway area to a local area, and the vehicle 100 may not be able to perform automatic control for a particular automation level between local areas. As previously described, the operator and the estimation system 170 may also negotiate a plan for transitioning from automatic control through route planning, operator preferences (e.g., manual driving in highway areas), etc. Furthermore, the estimation system 170 may schedule a takeover by comparing the location with map data and indicating that the vehicle is unable to autonomously control certain driving maneuvers beyond the automated region and that the operator may manage manual control during the takeover.

[0036] In one embodiment, estimation system 170 triggers takeover at locations depending on driving conditions that conflict with the automation level. For example, vehicle 100 cannot operate under Level 3 when the vehicle ahead is maneuvering aggressively, using perceptions predicted by sensor data 250. Similarly, vehicle 100 cannot operate under Level 5 when the road is icy. In this manner, estimation system 170 considers scheduled and unscheduled takeovers of vehicle 100 using map data, automation level, driving conditions, etc., thereby improving system reliability and robustness.

[0037] At 420, estimation system 170 predicts an automated area from the transition time and location for operator takeover. As previously described, the transition time can be a buffer zone where vehicle 100 gradually switches from automated driving to manual driving, which requires feedback, when capabilities become insufficient for automated driving. The transition time can be predetermined according to the automation level and the automation level's capability to autonomously control vehicle 100 within the area. For example, a takeover from Level 5 to Level 0-3 is requested by estimation system 170 when vehicle 100 is unable to safely navigate the area without the operator primarily controlling vehicle 100 with manual input.

[0038] At 430, the emulation module 220 generates virtual markers for the takeover using the automation region and location. In one approach, the emulation module 220 displays the virtual markers and location within the automation region along with a virtual twin of the vehicle 100 and the vehicle ahead on the road. The virtual markers may emulate caution zones, painted lines, slow speed zones, etc. on the road. Thus, the display of the virtual markers may assist the operator in understanding the capabilities of the operating region and automation level, enhancing situational awareness. In another example, the virtual markers may be feedback generated in the HUD through the overlay of an image using augmented reality that includes the scene around the vehicle 100.

[0039] In yet another approach, the emulation module 220 color-codes the virtual marks and automated regions to indicate the level of automation, status, etc. This can assist the operator in becoming familiar with transitions between scenarios requiring automated control and manual input. Furthermore, automated regions can be associated with distance and time (e.g., seconds) until takeover, where the virtual marks provide insightful feedback for a smooth transition. In addition to visuals, the virtual marks can include audible, tactile, or other warnings of the takeover prior to the transition time. For example, one or more actuators 150 can vibrate vehicle elements corresponding to points within the automated region. In one approach, the one or more actuators 150 are one of a dedicated electromagnetic suspension and a haptic motor. The vehicle element can be one of a seat base, a holster, a chassis, and a steering wheel. For example, the haptic motor can gradually vibrate the steering wheel along the virtual marks as it approaches a location, e.g., to virtually mimic the feel of rumble strips. Thus, the estimation system 170 improves operator knowledge, awareness, and perception of automation capabilities, reducing stress associated with takeovers and thereby improving vehicle safety and automation reliability.

[0040] 1 will now be described in greater detail as an exemplary environment in which the systems and methods disclosed herein may operate. In some examples, vehicle 100 is configured to selectively switch between different modes of operation / control according to the orientation of one or more modules / systems of vehicle 100. In one approach, the modes include 0, no automation; 1, driver assistance; 2, partial automation; 3, conditional automation; 4, high automation; and 5, full automation. In one or more mechanisms, vehicle 100 may be configured to operate in a subset of the possible modes.

[0041] In one or more embodiments, vehicle 100 is an automated or autonomous vehicle. As used herein, "autonomous vehicle" refers to a vehicle capable of operating in an autonomous mode (e.g., Level 5, fully automated). "Autonomous mode" or "autonomous mode" refers to using one or more computing systems to control vehicle 100 with minimal or no input from a human driver to navigate and / or steer vehicle 100 along a travel route. In one or more embodiments, vehicle 100 is highly automated or fully automated. In one embodiment, vehicle 100 is configured with one or more semi-autonomous operating modes in which one or more computing systems perform a portion of the navigation and / or steering of the vehicle along a travel route, and a vehicle operator (i.e., the driver) provides input to the vehicle to perform a portion of the navigation and / or steering of vehicle 100 along the travel route.

[0042] Vehicle 100 may include one or more processors 110. In one or more arrangements, processor 110 may be the main processor of vehicle 100. For example, processor 110 may be an electronic control unit (ECU), an application specific integrated circuit (ASIC), a microprocessor, etc. Vehicle 100 may include one or more data stores 115 that store one or more types of data. Data store 115 may include volatile memory and / or non-volatile memory. Examples of suitable data stores 115 include RAM, flash memory, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, magnetic disks, optical disks, and hard drives. Data store 115 may be a component of processor 110, or data store 115 may be operably connected to processor 110 for use by processor 110. As used throughout this specification, the term "operably connected" includes direct or indirect connections, and can include connections without direct physical contact.

[0043] In one or more arrangements, one or more data stores 115 may include map data 116. The map data 116 may include maps of one or more geographic areas. In some examples, the map data 116 may include information or data about roads, traffic control devices, road markings, structures, features, and / or landmarks within one or more geographic areas. The map data 116 may be in any suitable form. In some examples, the map data 116 may include aerial photographs of an area. In some examples, the map data 116 may include ground photographs of an area, which may include 360-degree ground photographs. The map data 116 may include measurements, dimensions, distances, and / or information about one or more features included in the map data 116 and / or for other features included in the map data 116. The map data 116 may include digital maps with information about road geometry.

[0044] In one or more arrangements, map data 116 may include one or more terrain maps 117. The terrain maps 117 may include information about the terrain, roads, surfaces, and / or other features of one or more geographic areas. The terrain maps 117 may include elevation data for one or more geographic areas. The terrain maps 117 may define one or more ground surfaces, which may include paved roads, unpaved roads, land, and other surfaces that define a ground surface.

[0045] In one or more arrangements, the map data 116 may include one or more stationary obstacle maps 118. The stationary obstacle map 118 may include information about one or more stationary obstacles located within one or more geographic areas. A "stationary obstacle" is a physical object whose position does not change or does not substantially change over a period of time and / or whose size does not change or does not substantially change over a period of time. Examples of stationary obstacles may include trees, buildings, curbs, fences, rails, centerlines, utility poles, statues, monuments, signs, benches, furniture, mailboxes, large rocks, or hills. A stationary obstacle may be an object that extends above ground level. One or more stationary obstacles included in the stationary obstacle map 118 may have location data, size data, dimension data, material data, and / or other data associated therewith. The stationary obstacle map 118 may include measurements, dimensions, distances, and / or information about one or more stationary obstacles. The stationary obstacle map 118 may be of high quality and / or high definition. The static obstacle map 118 may be updated to reflect changes in the mapped area.

[0046] One or more data stores 115 may include sensor data 119. In this context, "sensor data" means any information related to sensors equipped on vehicle 100, including capabilities and other information related to those sensors. As described below, vehicle 100 may include sensor system 120. Sensor data 119 may relate to one or more sensors of sensor system 120. As an example, in one or more arrangements, sensor data 119 may include information related to one or more LIDAR sensors 124 of sensor system 120.

[0047] In some examples, at least a portion of the map data 116 and / or sensor data 119 may be located in one or more data stores 115 located onboard the vehicle 100. Alternatively or in addition, at least a portion of the map data 116 and / or sensor data 119 may be located in one or more data stores 115 located remotely from the vehicle 100.

[0048] As described above, vehicle 100 may include sensor system 120. Sensor system 120 may include one or more sensors. A "sensor" refers to a device that can detect and / or sense something. In at least one embodiment, one or more sensors detect and / or sense in real time. As used herein, the term "real time" refers to a level of processing responsiveness that allows a user or system to sense quickly enough a particular process or decision to be made or a processor to keep up with some external process.

[0049] In arrangements where sensor system 120 includes multiple sensors, the sensors may function independently or two or more of the sensors may function in combination. Sensor system 120 and / or one or more sensors may be operatively connected to processor 110, data store 115, and / or another element of vehicle 100. Sensor system 120 may generate observations regarding a portion of the environment of vehicle 100 (e.g., nearby vehicles).

[0050] The sensor system 120 may include any suitable type of sensor. Various examples of different types of sensors are described herein. However, it will be understood that embodiments are not limited to the particular sensors described. The sensor system 120 may include one or more vehicle sensors 121. The vehicle sensors 121 may detect information about the vehicle 100 itself. In one or more arrangements, the vehicle sensors 121 may be configured to detect changes in the position and orientation of the vehicle 100, for example, based on inertial acceleration. In one or more arrangements, the vehicle sensors 121 may include one or more accelerometers, one or more gyroscopes, an inertial measurement unit (IMU), a dead reckoning system, a global navigation satellite system (GNSS), a global positioning system (GPS), a navigation system 147, and / or other suitable sensors. The vehicle sensors 121 may be configured to detect one or more characteristics of the vehicle 100 and / or the manner in which the vehicle 100 is operating. In one or more arrangements, the vehicle sensors 121 may include a speedometer to determine the current speed of the vehicle 100.

[0051] Alternatively or additionally, sensor system 120 may include one or more environmental sensors 122 configured to acquire data regarding the environment surrounding vehicle 100 in which vehicle 100 is operating. "Ambient environmental data" includes data regarding the external environment in which the vehicle is located or one or more portions thereof. For example, one or more environmental sensors 122 may be configured to detect obstacles and / or data regarding such obstacles in at least a portion of vehicle 100's external environment. Such obstacles may be stationary objects and / or dynamic objects. One or more environmental sensors 122 may be configured to detect other objects in vehicle 100's external environment, such as lane markers, signs, traffic lights, traffic signals, lane lines, crosswalks, curbs near vehicle 100, off-road objects, etc.

[0052] Described herein are various examples of sensors for sensor system 120. Example sensors may be part of one or more environmental sensors 122 and / or one or more vehicle sensors 121. However, it will be understood that embodiments are not limited to the particular sensors described.

[0053] By way of example, in one or more arrangements, sensor system 120 may include one or more of radar sensors 123, LIDAR sensors 124, sonar sensors 125, weather sensors, tactile sensors, position sensors, and / or one or more cameras 126. In one or more arrangements, one or more cameras 126 may be high dynamic range (HDR) cameras, stereo cameras, or infrared (IR) cameras.

[0054] Vehicle 100 may include input system 130. An "input system" includes a component or mechanism, or group thereof, that allows various entities to input data into a machine. Input system 130 may receive input from a vehicle occupant. Vehicle 100 may include output system 135. An "output system" includes one or more components that facilitate presenting data to a vehicle occupant.

[0055] Vehicle 100 may include one or more vehicle systems 140. Various examples of one or more vehicle systems 140 are shown in FIG. 1 . However, vehicle 100 may include more, fewer, or different vehicle systems. While certain vehicle systems are defined separately, it should be understood that any of the systems or portions thereof may otherwise be combined or separated via hardware and / or software within vehicle 100. Vehicle 100 may include a propulsion system 141, a braking system 142, a steering system 143, a throttle system 144, a transmission system 145, a signaling system 146, and / or a navigation system 147. Any of these systems may include one or more devices, components, and / or combinations thereof, now known or later developed.

[0056] Navigation system 147 may include one or more devices, applications, and / or combinations thereof, now known or later developed, configured to determine the geographic location of vehicle 100 and / or determine travel routes for vehicle 100. Navigation system 147 may include one or more mapping applications that determine travel routes for vehicle 100. Navigation system 147 may include a global positioning system, a local positioning system, or a geolocation system.

[0057] Processor 110, estimation system 170, and / or autonomous driving module 160 may be operatively connected to communicate with various vehicle systems 140 and / or their individual components. For example, returning to FIG. 1 , processor 110 and / or autonomous driving module 160 may be in communication with various vehicle systems 140 to send and / or receive information from them to control the movement of vehicle 100. Processor 110, estimation system 170, and / or autonomous driving module 160 may control some or all of vehicle systems 140 and, therefore, may be partially or fully autonomous as defined by SAE Levels 0-5.

[0058] Processor 110, estimation system 170, and / or autonomous driving module 160 may be operably connected to communicate with various vehicle systems 140 and / or their individual components. For example, returning to FIG. 1 , processor 110, estimation system 170, and / or autonomous driving module 160 may be in communication to send and / or receive information from various vehicle systems 140 to control the movement of vehicle 100. Processor 110, estimation system 170, and / or autonomous driving module 160 may control some or all of vehicle systems 140.

[0059] Processor 110, inference system 170, and / or autonomous driving module 160 may be operable to control the navigation and steering of vehicle 100 by controlling vehicle systems 140 and / or one or more of its components. For example, when operating in an autonomous mode, processor 110, inference system 170, and / or autonomous driving module 160 may control the direction and / or speed of vehicle 100. Processor 110, inference system 170, and / or autonomous driving module 160 may cause vehicle 100 to accelerate, decelerate, and / or change direction. As used herein, "cause" or "causing" means to make, force, compel, direct, command, order, command, and / or enable an event or action to occur, either directly or indirectly, or to make, force, compel, direct, command, order, and / or enable the event or action to come to be in a state in which such event or action can occur.

[0060] Vehicle 100 may include one or more actuators 150. Actuator 150 may be an element or combination of elements operable to modify vehicle system 140 or one or more of its components in response to receiving signals or other inputs from processor 110 and / or autonomous driving module 160. For example, one or more actuators 150 may include motors, pneumatic actuators, hydraulic pistons, relays, solenoids, and / or piezoelectric actuators, just to name a few possibilities.

[0061] Vehicle 100 may include one or more modules, at least some of which are described herein. The modules may be implemented as computer-readable program code that, when executed by processor 110, implements one or more of the various processes described herein. One or more of the modules may be components of processor 110, or one or more of the modules may execute on and / or be distributed among other processing systems to which processor 110 is operatively connected. The modules may include instructions (e.g., program logic) executable by one or more processors 110. Alternatively, or in addition, one or more data stores 115 may include such instructions.

[0062] In one or more arrangements, one or more of the modules described herein may include artificial intelligence elements, such as neural networks, fuzzy logic, or other machine learning algorithms. Further, in one or more arrangements, one or more of the modules may be distributed among multiple modules described herein. In one or more arrangements, two or more of the modules described herein may be combined into a single module.

[0063] Vehicle 100 may include one or more autonomous driving modules 160. Autonomous driving module 160 may be configured to receive data from sensor system 120 and / or from any other type of system capable of capturing information about vehicle 100 and / or the environment external to vehicle 100. In one or more mechanisms, autonomous driving module 160 may use the data to generate one or more driving scene models. Autonomous driving module 160 may determine the position and speed of vehicle 100. Autonomous driving module 160 may determine the location of obstacles, obstacles, or other environmental features, including traffic signs, trees, shrubs, nearby vehicles, pedestrians, etc.

[0064] The autonomous driving module 160 may be configured to receive and / or determine location information regarding obstacles in the external environment of the vehicle 100 for use by the processor 110 and / or one or more of the modules described herein, and to estimate the position and orientation of the vehicle 100, the vehicle's position in global coordinates, based on signals from multiple satellites or any other data and / or signals that may be used to determine the current state of the vehicle 100 or the position of the vehicle 100 relative to the vehicle's 100 environment used in creating a map or determining the position of the vehicle 100 relative to the map data.

[0065] Autonomous driving module 160 may be configured, independently or in combination with estimation system 170, to determine a travel path, a current autonomous driving maneuver for vehicle 100, a future autonomous driving maneuver, and / or a modification to the current autonomous driving maneuver based on data from any other suitable sources, such as data acquired by sensor system 120, a driving scene model, and / or determinations from sensor data 250. A "driving maneuver" refers to one or more actions that affect the movement of the vehicle. Examples of driving maneuvers include accelerating, decelerating, braking, turning, moving vehicle 100 laterally, changing lanes of travel, merging into lanes of travel, and / or reversing, just to name a few possibilities. Autonomous driving module 160 may be configured to implement the determined driving maneuvers. Autonomous driving module 160 may implement such autonomous driving maneuvers directly or indirectly. As used herein, "cause" or "causing" means, either directly or indirectly, to make, command, command to occur, and / or enable an event or action to occur, or to make, command, command, and / or at least enable an event or action to be in a state in which such event or action can occur. Autonomous driving module 160 may be configured to perform various vehicle functions and / or send data to, receive data from, interact with, and / or control vehicle 100 or one or more of its systems (e.g., one or more of vehicle systems 140).

[0066] Detailed embodiments are disclosed herein. However, it should be understood that the disclosed embodiments are intended as examples. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to variously employ the aspects of the present specification in substantially any suitable detailed configuration. Furthermore, the terms and phrases used herein are not intended to be limiting, but rather to provide an understandable description of possible implementations. While various embodiments are shown in FIGS. 1-4, the embodiments are not limited to the structures or applications shown.

[0067] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, blocks in the flowcharts or block diagrams may represent modules, segments, or portions of code comprising one or more executable instructions that implement the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved.

[0068] The systems, components, and / or processes described above may be implemented in hardware or a combination of hardware and software, and may be implemented in a centralized manner within one processing system, or in a distributed manner where different elements are spread across several interconnected processing systems. Any type of processing system or other apparatus configured to perform the methods described herein is suitable. A typical combination of hardware and software may be a processing system having computer-usable program code that, when loaded and executed, controls the processing system such that the processing system performs the methods described herein.

[0069] The systems, components, and / or processes may also be embodied in computer-readable storage, such as a computer program product or other data program storage device, readable by a machine, tangibly embodying a program of instructions executable by a machine to perform the methods and processes described herein. These elements may also be embodied in an application product with features that enable implementation of the methods described herein and that can execute those methods when loaded into a processing system.

[0070] Furthermore, the mechanisms described herein may take the form of a computer program product having computer-readable program code embodied in, e.g., stored on, one or more computer-readable media. Any combination of one or more computer-readable media may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The phrase "computer-readable storage medium" refers to a non-transitory storage medium. A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include the following: a portable computer diskette, a hard disk drive (HDD), a solid-state drive (SSD), a ROM, EPROM, or flash memory, a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this specification, a computer-readable storage medium may be any tangible medium that may contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0071] Generally, as used herein, a module includes a routine, program, object, component, data structure, etc. that performs a particular task or implements a particular data type. In a further aspect, a memory generally stores the noted modules. The memory associated with a module may be a buffer or cache integrated within a processor, RAM, ROM, flash memory, or another suitable electronic storage medium. In still further aspects, a module contemplated by the present disclosure is implemented as an ASIC, as a hardware component of a system-on-chip (SoC), as a programmable logic array (PLA), or as another suitable hardware component incorporating a defined configuration set (e.g., instructions) to perform the functions of the present disclosure.

[0072] Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including, but not limited to, wireless, wired, fiber optic, cable, radio frequency (RF), etc., or any suitable combination thereof. Computer program code for carrying out operations for aspects of the present mechanism may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java®, Smalltalk™, C++, or the like, and conventional procedural programming languages ​​such as the “C” programming language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be made (e.g., through the Internet using an Internet Service Provider).

[0073] The terms "a" and "an," as used herein, are defined as one or more than one. The term "plurality," as used herein, is defined as two or more than two. The term "another," as used herein, is defined as at least a second or more. The terms "including" and / or "having," as used herein, are defined as comprising (i.e., open language). The phrase "and at least one of," as used herein, refers to and includes any and all combinations of one or more of the associated listed items. As an example, the phrase "at least one of A, B, and C" includes A, B, C, or any combination thereof (e.g., AB, AC, BC, or ABC).

[0074] Aspects of the present specification may be embodied in other forms without departing from the spirit or essential attributes thereof, and reference should accordingly be made to the following claims, rather than the foregoing specification, as indicating the scope of the present specification.

Claims

1. 1. An estimation system comprising: a memory storing instructions, The instructions, when executed by a processor, cause the processor to: Estimating a position for takeover by a vehicle directly controlling the driving operation; predicting an automatic region from the transition time and the position relative to the takeover by an operator; An estimation system that uses the automatic region and the location to generate a virtual mark for the takeover, the virtual mark being within the automatic region and the location indicating an area for manual feedback to the vehicle.

2. 2. The estimation system of claim 1, further comprising instructions for automatically stopping the vehicle by an automated driving module if the takeover and manual control of the vehicle by the operator during the transition time is insufficient.

3. The instructions for generating the virtual mark include:

2. The estimation system of claim 1, further comprising instructions for displaying the virtual markings on a head-up display (HUD) through an overlay of an image that augments a scene around the vehicle, the virtual markings emulating caution zones on a road in the scene.

4. scheduling the takeover by comparing the location with map data to indicate that the vehicle is unable to autonomously control the driving maneuver beyond the autonomous region and that the operator is available to take over; 4. The estimation system of claim 3, further comprising instructions for sharing control between the vehicle and the operator during the transition period, wherein during the transition period, the operator inputs primary commands and the vehicle assists with secondary commands.

5. 4. The estimation system of claim 3, further comprising instructions to vibrate a vehicle element by a component in response to a point within the attention zone, the component being one of an electromagnetic suspension and a haptic motor, and the vehicle element being one of a seat base, a holster, a chassis, and a steering wheel.

6. the transition time is predetermined according to an automation level and a capability of the automation level to autonomously control the vehicle within the area; The estimation system of claim 5 , wherein the automation regions are color-coded according to the automation level.

7. The estimation system of claim 1 , further comprising instructions for planning the location according to a change in a geography associated with the area, the geography changing from a high speed area to a local area.

8. The estimation system of claim 1 , wherein the transition time factors in the attentiveness of the operator derived from sensor data, the stopping distance of the vehicle, and a level of automation associated with the driving maneuver.

9. The estimation system of claim 1 , wherein the instructions for predicting the automated area further comprise instructions for factoring in a speed of the vehicle toward the location.

10. A non-transitory computer-readable medium containing instructions, The instructions, when executed by a processor, cause the processor to: Estimating a position for takeover by a vehicle directly controlling the driving operation; predicting an automatic region from the transition time and the position relative to the takeover by an operator; A non-transitory computer-readable medium that generates a virtual mark related to the takeover using the automated region and the location, the virtual mark being within the automated region and the location indicating an area related to manual feedback for the vehicle.

11. 11. The non-transitory computer-readable medium of claim 10, further comprising instructions for automatically stopping the vehicle by an automated driving module if the takeover and manual control of the vehicle by the operator during the transition time is insufficient.

12. estimating a position for takeover by a vehicle directly controlling the driving maneuver; predicting an automatic region from the transition time and the position relative to the takeover by an operator; and generating a virtual mark for the takeover using the automated region and the location, the virtual mark being within the automated region and the location indicating an area for manual feedback to the vehicle.

13. 13. The method of claim 12, further comprising automatically stopping the vehicle by an automated driving module if the takeover and manual control of the vehicle by the operator during the transition time is insufficient.

14. generating the virtual mark 13. The method of claim 12, further comprising displaying the virtual markings on a head-up display (HUD) through an overlay of an image that augments a scene around the vehicle, the virtual markings emulating caution zones on a road in the scene.

15. scheduling the takeover by comparing the location to map data and indicating that the vehicle is unable to autonomously control the driving maneuver beyond the autonomous region and that the operator is available to take over; 15. The method of claim 14, further comprising: sharing control between the vehicle and the operator during the transition time, wherein during the transition time, the operator inputs primary commands and the vehicle assists with secondary commands.

16. 15. The method of claim 14, further comprising vibrating a vehicle element by a component in response to a point within the attention zone, the component being one of an electromagnetic suspension and a haptic motor, and the vehicle element being one of a seat base, a holster, a chassis, and a steering wheel.

17. the transition time is predetermined according to an automation level and a capability of the automation level to autonomously control the vehicle within the area; The method of claim 16 , wherein the automation regions are color-coded according to the automation level.

18. The method of claim 12 , further comprising planning the location according to a change in a geography associated with the area, the geography changing from a high speed area to a local area.

19. The method of claim 12 , wherein the transition time factors in the attentiveness of the operator derived from sensor data, the stopping distance of the vehicle, and a level of automation associated with the driving maneuver.

20. The method of claim 12 , wherein predicting an automated region further comprises factoring in a speed of the vehicle toward the location.

Images