>250.

In another approach, the detection module may receive routine paths via communication system 180. For example, if a bus is reassigned from its regular route to another, a transportation operator may provide a replacement set of routine paths for the bus to follow via its dispatch system. As another example, a construction zone may have an infrastructure device that provides different sets of routine paths for vehicles to follow through the construction zone as lanes are closed or opened. In such an embodiment, detection module 220 may receive routine paths via communication system 180 and store such routine paths in sensor data 250. In some embodiments, detection module 220 may perform validation to ensure that the routine paths apply to the vehicle, operator, occupant, task/purpose, and so on. Where validation fails, detection module 220 may provide a notification instructing the reason for failure and the routine path at issue.

In one embodiment, the command module 230 generally includes instructions that function to control the processor 110 or collection of processors in the cloud-computing environment 300 to aid in the avoidance of mode confusion, such as where automated driving assistance does not engage after a manual control intervention.

In some embodiments, based on a given location, command module 230 may determine if it is within the scope of one or more routine paths. In some embodiments, command module 230 may select a routine path based in part on the extent to which the vehicle or its contents (e.g., operator, occupant(s), load), or a combination thereof fit characteristics associated with a routine path. In some embodiments, command module 230 may select a routine path based in part on the extent to which the current time, date, weather, traffic, or other characteristics associated with a routine path exhibits consistency or lack thereof with a routine path. In some embodiments, command module 230 may be instructed to use a routine path, such as one provided via communication system 180 for use in a particular context (e.g., navigating construction zone traffic). In some embodiments, command module 230 may evaluate a routine path to determine if it remains valid in the current context. For example, if a routine path is not currently possible due to road closures, traffic conditions, weather conditions, or other intervening factors, command module 230 may determine that a different routine path or no routine path is suitable.

In some embodiments, command module 230 may detect an interruption to automated driving assistance for a vehicle. For example, an operator may have undertaken manual control in order to make a lane change, pass another vehicle, etc. As another example, an event external to the vehicle may have caused a disengagement, such as traffic or weather conditions. In some embodiments, external control of the vehicle (e.g., by V2V, V2I, V2X) may cause an interruption to automated driving assistance of a vehicle, while in some embodiments the cessation of external control may constitution an interruption to automated driving assistance of a vehicle (e.g., due to a communication failure).

In some embodiments, command module 230 may detect that a potential mode confusion condition exists. For example, a potential mode confusion condition may arise when an automated driving assistance fails to re-engage, such as after manual driving has ceased. For instance, after changing lanes under manual control, a lane-keeping assist system may fail to reengage because the lane markings are not sufficiently visible to the system. As another example, a failure of automated driving assistance to re-engage may occur because of water spray from other vehicles affecting a vehicle's cameras.

As another example, a cessation of manual control that does not result in the resumption of an automated driving assistance in effect prior to manual control event may be sufficient for a potential mode confusion condition to exist. For example, if a vehicle operator disabled an aspect of automated driving assistance, such as the lane-keeping assist system, then ceases to provide any manual inputs relevant to the disabled feature at some point while under manual control (e.g., steering inputs), a potential mode confusion condition may be determined to exist.

In some embodiments, command module 230 may determine whether a resting state exists. For example, a driver who has engaged in manual control, then ceased driving in expectation of a return to automated driving assistance, may nonetheless keep their hands on the steering wheel. In such a context, the operator's hands may transmit various changes to the steering wheel even though it is not the operator's intent to manually control the vehicle. Accordingly, command module 230 may analyze steering, braking, acceleration, or other inputs to determine if they exhibit active manual control or a resting state. For example, command module 230 may analyze the steering signal in terms of frequency, amplitude, periodicity, aperiodicity, or other measurements through methods known in the art to determine if the steering signal is representative of active manual control or a resting state. As another example, command module 230 may analyze the acceleration input (e.g., gas pedal) to determine if acceleration signal is representative of active manual control or a resting state. For example, a driver who has entered a resting state may no longer be exerting sufficient pressure on the pedal to maintain the speed limit or the usual expected speed recorded along the path of travel. In some embodiments, if command module 230 detects a resting state it may be treated the same as a cessation of manual control.

In some embodiments, command module 230 may determine the likelihood that a vehicle would be expected to perform automated driving assistance at a given point within the path of travel, along a portion of the path of travel, or the entire length of the path of travel. In some embodiments, command module 230 may use data regarding the usage of automated driving assistance contained within the routine path, information from sensor data 250, or other sources to generate or adjust the likelihood of expected automated driving assistance at any point along the path of travel in the routine path. In some embodiments, a likelihood of expected automated driving assistance may be determined with respect to each automated driving assistance function or a subset thereof (e.g., only available functions).

In some embodiments, command module 230 may also further evaluate any information regarding the disabling of any automated driving assistance, including the extent to which vehicle parameters or the surrounding environment exhibits consistency or inconsistency with the routine path, to adjust the likelihood of expected automated driving assistance. For example, if the operator disabled an automated driving assistance function in weather conditions that typically don't exist along the routine path, command module 230 may reduce the likelihood of expected automated driving assistance based on such an inconsistency.

In some embodiments, command module 230 may also further evaluate any information regarding a failure to re-engage any automated driving assistance, including the extent to which vehicle parameters or the surrounding environment exhibits consistency or inconsistency with the routine path, to adjust the likelihood of expected automated driving assistance. For example, where traffic conditions are the reason for a failure to re-engage any automated driving assistance, the likelihood of expected automated driving assistance may be adjusted downward until the traffic condition ceases to exist.

In some embodiments, command module 230 may also further evaluate any information regarding ongoing manual control or lack thereof, including the extent to which any manual control exhibits consistency or inconsistency with the routine path, in estimating the likelihood of expected automated driving assistance. For example, where an operator is clearly actively engaged in manual driving or engaged in a significant departure from a routine path that is not covered by another routine path, command module 230 may estimate the likelihood of expected automated driving assistance at or near zero. As another example, where the operator has ceased engaging in manual driving, command module 230 may apply a function of time, such as a ramp up function, to adjust the estimate of the likelihood of expected automated driving assistance. In one embodiment, where command module 230 determines a resting state has come into existence, command module 230 may treat such a resting state as equivalent to a cessation of manual control and adjust the estimate of the likelihood of expected automated driving assistance the same as described herein with respect to a cessation of manual control.

In some embodiments, command module 230 may generate a notification if a likelihood of expected automated driving assistance exceeds a threshold, such as when any automated driving assistance associated with the likelihood of expected automated driving assistance remains disabled after a manual control event ends. In various embodiments, the notification may take form of an audio notification, a visual notification, a text notification, and so on. In some embodiments, the notification may display a graphical representation of automated driving assistance typically expected to be in effect (e.g., such as those whose likelihood of expected automated driving assistance exceeds a threshold) with color or other visual indicators to denote whether they are in effect (e.g., green for operative, blinking red for inoperative). In some embodiments, such a visual representation may also operate during manual control with the graphical representation of automated driving assistance exhibiting further or different visual indicators to indicate which functions are disabled or suppressed as appropriate (e.g., blinking green with a red line through it).

It should be appreciated that the command module 230 in combination with the prediction model 270 can form a computational model such as a machine learning logic, deep learning logic, a neural network model, or another similar approach. In one embodiment, the prediction model 270 is a statistical model such as a regression model that estimates the conditional expectation of automated driving assistance along a routine path. Accordingly, the model 270 can be a polynomial regression (e.g., least weighted polynomial regression), least squares or another suitable approach.

Moreover, in alternative arrangements, the prediction model 270 is a probabilistic approach such as a hidden Markov model. In either case, the command module 230, when implemented as a neural network model or another model, in one embodiment, electronically accepts the sensor data 250 as an input. Accordingly, the command module 230 in concert with the prediction model 270 produce various determinations/assessments as an electronic output that characterizes the noted aspect as, for example, a single electronic value. Moreover, in further aspects, the mode confusion avoidance system 170 can collect the noted data, log responses, and use the data and responses to subsequently further train the model 270.

Additional aspects of avoiding mode confusion will be discussed in relation to FIG. 5. FIG. 5 illustrates a flowchart of a method 500 that is associated with avoiding mode confusion. Method 500 will be discussed from the perspective of the mode confusion avoidance system 170 of FIGS. 1 and 2. While method 500 is discussed in combination with the mode confusion avoidance system 170, it should be appreciated that the method 500 is not limited to being implemented within the mode confusion avoidance system 170 but is instead one example of a system that may implement the method 500.

At 510, the command module 230 may select a routine path for use with a vehicle. For example, command module 230 may select one or more routine paths associated with a given location of the vehicle. In some embodiments, command module 230 may further select between routine paths based on the direction of travel, the destination of travel, the vehicle, the vehicle operator, an occupant, a task, a purpose, and so on. In various embodiments, command module 230 may also select between routine paths based on vehicle parameters, surrounding environment conditions, date, time, weather, traffic, and so on. For example, command module 230 may select a routine path on how the information contained within a routine path best matches the current location of the vehicle, the identity of the vehicle operator, the identity of an occupant, the type of task/purpose, vehicle parameters, surrounding environment conditions, date, time, weather, traffic, other factors, or a combination thereof.

At 520, the command module may determine a likelihood of expected autonomous driving assistance based on a location within the routine path. For example, command module 230 may determine the likelihood that a vehicle would be expected to perform automated driving assistance at the location, along a portion of the path of travel encompassing the location, or the entire length of the path of travel encompassing the location. In some embodiments, command module 230 may use data regarding the usage of automated driving assistance contained within the routine path, information from sensor data 250, or other sources to generate or adjust the likelihood of expected automated driving assistance based on the location within a selected routine path. In some embodiments, a likelihood of expected automated driving assistance may be determined with respect to each automated driving assistance function or a subset thereof (e.g., only available functions) for the location. In some embodiments a likelihood of expected automated driving assistance may be determined based on information from more than one routine path, such as where the vehicle is transitioning from one routine path to another.

At step 530, command module 230 may generate a notification if autonomous driving assistance has not been enabled and the likelihood exceeds a threshold. In various embodiments, the notification may take form of an audio notification, a visual notification, a text notification, and so on. In some embodiments, the notification may display a graphical representation of automated driving assistance typically expected to be in effect (e.g., such as those whose likelihood of expected automated driving assistance exceeds a threshold) with color or other visual indicators to denote whether they are in effect (e.g., green for operative, blinking red for inoperative). In some embodiments, such a visual representation may also operate during manual control with the graphical representation of automated driving assistance exhibiting further or different visual indicators to indicate which functions are disabled or suppressed as appropriate (e.g., blinking green with a red line through it).

In some embodiments, command module 230 may only generate notification if the likelihood of expected autonomous driving assistance exceeds a threshold after a potential mode confusion condition is determined to exist. For example, if an autonomous driving assistance fails to re-engage after a cessation of manual control or upon the detection of a resting state, command module 230 may determine that a potential mode confusion condition exists. As another example, if an autonomous driving assistance function is disabled and not resumed after ceasing relevant manual control or upon the detection of a resting state with respect to a relevant manual control.

In some embodiments, the notification may be given with higher intensity, additional repetitions, more frequently, or so on relative to a notification that would occur if the likelihood of expected autonomous driving assistance does not exceed a threshold. In some embodiments, the intensity of the notification or any other adjustments thereof may depend on the extent to which the likelihood of expected autonomous driving assistance exceeded the threshold. In some embodiments, the notification may be delayed until the likelihood of expected autonomous driving assistance exceeds the threshold for a pre-determined period of time.

FIG. 6 illustrates an example of how the systems and methods described herein can be used to avoid mode confusion where a driver expects resumption of an autonomous driving assistance that did not occur. As shown in FIG. 6, a vehicle operator may be using autonomous driving assistance along a typical route used by the vehicle operator. Accordingly, command module 230 may select a routine path associated with the route and estimate a likelihood of expected autonomous driving assistance along the routine path. While travelling along the routine path, vehicle operator may then initiate a lane change though manual control. Upon completing the lane change, the driver may assume that the autonomous driving assistance has resumed. However, autonomous driving assistance may have failed to resume, such as due to road conditions. Upon the autonomous driving assistance having failed to resume, command module 230 may estimate a likelihood of expected autonomous driving assistance based on the routine path and if it exceeds a threshold generate a notification to the driver indicating that the autonomous driving assistance has not resumed as may be expected. Such a notification may be more intense, more frequent, or repeated more often as compared to any notification that would have occurred had the likelihood of expected autonomous driving assistance not exceeded the threshold.

FIG. 1 will now be discussed in full detail as an example environment within which the system and methods disclosed herein may operate. In some instances, the vehicle 100 is configured to switch selectively between an autonomous mode, one or more semi-autonomous operational modes, and/or a manual mode. Such switching can be implemented in a suitable manner, now known, or later developed. “Manual mode” means that all of or a majority of the navigation and/or maneuvering of the vehicle is performed according to inputs received from a user (e.g., human driver). In one or more arrangements, the vehicle 100 can be a conventional vehicle that is configured to operate in only a manual mode.

In one or more embodiments, the vehicle 100 is an autonomous vehicle. As used herein, “autonomous vehicle” refers to a vehicle that operates in an autonomous mode. “Autonomous mode” refers to navigating and/or maneuvering the vehicle 100 along a travel route using one or more computing systems to control the vehicle 100 with minimal or no input from a human driver. In one or more embodiments, the vehicle 100 is highly automated or completely automated. In one embodiment, the vehicle 100 is configured with one or more semi-autonomous operational modes in which one or more computing systems perform a portion of the navigation and/or maneuvering of the vehicle along a travel route, and a vehicle operator (i.e., driver) provides inputs to the vehicle to perform a portion of the navigation and/or maneuvering of the vehicle 100 along a travel route.

The vehicle 100 can include one or more processors 110. In one or more arrangements, the processor(s) 110 can be a main processor of the vehicle 100. For instance, the processor(s) 110 can be an electronic control unit (ECU). The vehicle 100 can include one or more data stores 115 for storing one or more types of data. The data store 115 can include volatile and/or non-volatile memory. Examples of suitable data stores 115 include RAM (Random Access Memory), flash memory, ROM (Read Only Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), registers, magnetic disks, optical disks, hard drives, or any other suitable storage medium, or any combination thereof. The data store 115 can be a component of the processor(s) 110, or the data store 115 can be operatively connected to the processor(s) 110 for use thereby. The term “operatively connected,” as used throughout this description, can include direct or indirect connections, including connections without direct physical contact.

In one or more arrangements, the one or more data stores 115 can include map data 116. The map data 116 can include maps of one or more geographic areas. In some instances, the map data 116 can include information or data on roads, traffic control devices, road markings, structures, features, and/or landmarks in the one or more geographic areas. The map data 116 can be in any suitable form. In some instances, the map data 116 can include aerial views of an area. In some instances, the map data 116 can include ground views of an area, including 360-degree ground views. The map data 116 can include measurements, dimensions, distances, and/or information for one or more items included in the map data 116 and/or relative to other items included in the map data 116. The map data 116 can include a digital map with information about road geometry. The map data 116 can be high quality and/or highly detailed.

In one or more arrangements, the map data 116 can include one or more terrain maps 117. The terrain map(s) 117 can include information about the ground, terrain, roads, surfaces, and/or other features of one or more geographic areas. The terrain map(s) 117 can include elevation data in the one or more geographic areas. The map data 116 can be high quality and/or highly detailed. The terrain map(s) 117 can define one or more ground surfaces, which can include paved roads, unpaved roads, land, and other things that define a ground surface.

In one or more arrangements, the map data 116 can include one or more static obstacle maps 118. The static obstacle map(s) 118 can include information about one or more static obstacles located within one or more geographic areas. A “static obstacle” is a physical object whose position does not change or substantially change over a period of time and/or whose size does not change or substantially change over a period of time. Examples of static obstacles include trees, buildings, curbs, fences, railings, medians, utility poles, statues, monuments, signs, benches, furniture, mailboxes, large rocks, hills. The static obstacles can be objects that extend above ground level. The one or more static obstacles included in the static obstacle map(s) 118 can have location data, size data, dimension data, material data, and/or other data associated with it. The static obstacle map(s) 118 can include measurements, dimensions, distances, and/or information for one or more static obstacles. The static obstacle map(s) 118 can be high quality and/or highly detailed. The static obstacle map(s) 118 can be updated to reflect changes within a mapped area.

The one or more data stores 115 can include sensor data 119. In this context, “sensor data” means any information about the sensors that the vehicle 100 is equipped with, including the capabilities and other information about such sensors. As will be explained below, the vehicle 100 can include the sensor system 120. The sensor data 119 can relate to one or more sensors of the sensor system 120. As an example, in one or more arrangements, the sensor data 119 can include information on one or more LIDAR sensors 124 of the sensor system 120.

In some instances, at least a portion of the map data 116 and/or the sensor data 119 can 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 the sensor data 119 can be located in one or more data stores 115 that are located remotely from the vehicle 100.

As noted above, the vehicle 100 can include the sensor system 120. The sensor system 120 can include one or more sensors. “Sensor” means any device, component and/or system that can detect, and/or sense something. The one or more sensors can be configured to detect, and/or sense in real-time. As used herein, the term “real-time” means a level of processing responsiveness that a user or system senses as sufficiently immediate for a particular process or determination to be made, or that enables the processor to keep up with some external process.

In arrangements in which the sensor system 120 includes a plurality of sensors, the sensors can work independently from each other. Alternatively, two or more of the sensors can work in combination with each other. In such case, the two or more sensors can form a sensor network. The sensor system 120 and/or the one or more sensors can be operatively connected to the processor(s) 110, the data store(s) 115, and/or another element of the vehicle 100 (including any of the elements shown in FIG. 1). The sensor system 120 can acquire data of at least a portion of the external environment of the vehicle 100 (e.g., nearby vehicles).

The sensor system 120 can include any suitable type of sensor. Various examples of different types of sensors will be described herein. However, it will be understood that the embodiments are not limited to the particular sensors described. The sensor system 120 can include one or more vehicle sensors 121. The vehicle sensor(s) 121 can detect, determine, and/or sense information about the vehicle 100 itself. In one or more arrangements, the vehicle sensor(s) 121 can be configured to detect, and/or sense position and orientation changes of the vehicle 100, such as, for example, based on inertial acceleration. In one or more arrangements, the vehicle sensor(s) 121 can 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 sensor(s) 121 can be configured to detect, and/or sense one or more characteristics of the vehicle 100. In one or more arrangements, the vehicle sensor(s) 121 can include a speedometer to determine a current speed of the vehicle 100.

Alternatively, or in addition, the sensor system 120 can include one or more environment sensors 122 configured to acquire, and/or sense driving environment data. “Driving environment data” includes data or information about the external environment in which an autonomous vehicle is located or one or more portions thereof. For example, the one or more environment sensors 122 can be configured to detect, quantify and/or sense obstacles in at least a portion of the external environment of the vehicle 100 and/or information/data about such obstacles. Such obstacles may be stationary objects and/or dynamic objects. The one or more environment sensors 122 can be configured to detect, measure, quantify and/or sense other things in the external environment of the vehicle 100, such as, for example, lane markers, signs, traffic lights, traffic signs, lane lines, crosswalks, curbs proximate the vehicle 100, off-road objects, etc.

Various examples of sensors of the sensor system 120 will be described herein. The example sensors may be part of the one or more environment sensors 122 and/or the one or more vehicle sensors 121. However, it will be understood that the embodiments are not limited to the particular sensors described.

As an example, in one or more arrangements, the sensor system 120 can include one or more radar sensors 123, one or more LIDAR sensors 124, one or more sonar sensors 125, and/or one or more cameras 126. In one or more arrangements, the one or more cameras 126 can be high dynamic range (HDR) cameras or infrared (IR) cameras.

The vehicle 100 can include an input system 130. An “input system” includes any device, component, system, element or arrangement or groups thereof that enable information/data to be entered into a machine. The input system 130 can receive an input from a vehicle passenger (e.g., a driver or a passenger). The vehicle 100 can include an output system 135. An “output system” includes any device, component, or arrangement or groups thereof that enable information/data to be presented to a vehicle passenger (e.g., a person, a vehicle passenger, etc.).

The vehicle 100 can include one or more vehicle systems 140. Various examples of the one or more vehicle systems 140 are shown in FIG. 1. However, the vehicle 100 can include more, fewer, or different vehicle systems. It should be appreciated that although particular vehicle systems are separately defined, each or any of the systems or portions thereof may be otherwise combined or segregated via hardware and/or software within the vehicle 100. The vehicle 100 can include a propulsion system 141, a braking system 142, a steering system 143, throttle system 144, a transmission system 145, a signaling system 146, and/or a navigation system 147. Each of these systems can include one or more devices, components, and/or a combination thereof, now known or later developed.

The navigation system 147 can include one or more devices, applications, and/or combinations thereof, now known or later developed, configured to determine the geographic location of the vehicle 100 and/or to determine a travel route for the vehicle 100. The navigation system 147 can include one or more mapping applications to determine a travel route for the vehicle 100. The navigation system 147 can include a global positioning system, a local positioning system or a geolocation system.

The processor(s) 110, the mode confusion avoidance system 170, and/or the automated driving module(s) 160 can be operatively connected to communicate with the various vehicle systems 140 and/or individual components thereof. For example, returning to FIG. 1, the processor(s) 110 and/or the automated driving module(s) 160 can be in communication to send and/or receive information from the various vehicle systems 140 to control the movement, speed, maneuvering, heading, direction, etc. of the vehicle 100. The processor(s) 110, the mode confusion avoidance system 170, and/or the automated driving module(s) 160 may control some or all of these vehicle systems 140 and, thus, may be partially or fully autonomous.

The processor(s) 110, the mode confusion avoidance system 170, and/or the automated driving module(s) 160 can be operatively connected to communicate with the various vehicle systems 140 and/or individual components thereof. For example, returning to FIG. 1, the processor(s) 110, the mode confusion avoidance system 170, and/or the automated driving module(s) 160 can be in communication to send and/or receive information from the various vehicle systems 140 to control the movement, speed, maneuvering, heading, direction, etc. of the vehicle 100. The processor(s) 110, the mode confusion avoidance system 170, and/or the automated driving module(s) 160 may control some or all of these vehicle systems 140.

The processor(s) 110, the mode confusion avoidance system 170, and/or the automated driving module(s) 160 may be operable to control the navigation and/or maneuvering of the vehicle 100 by controlling one or more of the vehicle systems 140 and/or components thereof. For instance, when operating in an autonomous mode, the processor(s) 110, the mode confusion avoidance system 170, and/or the automated driving module(s) 160 can control the direction and/or speed of the vehicle 100. The processor(s) 110, the mode confusion avoidance system 170, and/or the automated driving module(s) 160 can cause the vehicle 100 to accelerate (e.g., by increasing the supply of fuel provided to the engine), decelerate (e.g., by decreasing the supply of fuel to the engine and/or by applying brakes) and/or change direction (e.g., by turning the front two wheels). As used herein, “cause” or “causing” means to make, force, compel, direct, command, instruct, and/or enable an event or action to occur or at least be in a state where such event or action may occur, either in a direct or indirect manner.

The vehicle 100 can include one or more actuators 150. The actuators 150 can be any element or combination of elements operable to modify, adjust and/or alter one or more of the vehicle systems 140 or components thereof to responsive to receiving signals or other inputs from the processor(s) 110 and/or the automated driving module(s) 160. Any suitable actuator can be used. For instance, the one or more actuators 150 can include motors, pneumatic actuators, hydraulic pistons, relays, solenoids, and/or piezoelectric actuators, just to name a few possibilities.

The vehicle 100 can include one or more modules, at least some of which are described herein. The modules can be implemented as computer-readable program code that, when executed by a processor 110, implement one or more of the various processes described herein. One or more of the modules can be a component of the processor(s) 110, or one or more of the modules can be executed on and/or distributed among other processing systems to which the processor(s) 110 is operatively connected. The modules can include instructions (e.g., program logic) executable by one or more processor(s) 110. Alternatively, or in addition, one or more data store 115 may contain such instructions.

In one or more arrangements, one or more of the modules described herein can include artificial or computational intelligence elements, e.g., neural network, fuzzy logic, or other machine learning algorithms. Further, in one or more arrangements, one or more of the modules can be distributed among a plurality of the modules described herein. In one or more arrangements, two or more of the modules described herein can be combined into a single module.

The vehicle 100 can include one or more autonomous driving modules 160. The automated driving module(s) 160 can be configured to receive data from the sensor system 120 and/or any other type of system capable of capturing information relating to the vehicle 100 and/or the external environment of the vehicle 100. In one or more arrangements, the automated driving module(s) 160 can use such data to generate one or more driving scene models. The automated driving module(s) 160 can determine position and velocity of the vehicle 100. The automated driving module(s) 160 can determine the location of obstacles, obstacles, or other environmental features including traffic signs, trees, shrubs, neighboring vehicles, pedestrians, etc.

The automated driving module(s) 160 can be configured to receive, and/or determine location information for obstacles within the external environment of the vehicle 100 for use by the processor(s) 110, and/or one or more of the modules described herein to estimate position and orientation of the vehicle 100, vehicle position in global coordinates based on signals from a plurality of satellites, or any other data and/or signals that could be used to determine the current state of the vehicle 100 or determine the position of the vehicle 100 with respect to its environment for use in either creating a map or determining the position of the vehicle 100 in respect to map data.