Patent Description:
<CIT> describes planning a feasible vehicle trajectory to reach a target state that is both reachable under vehicle constraints, and allowable on a road segment.

<CIT> describes drive envelope determination.

<CIT> describes a system which generates a driving trajectory from a starting point to a destination point for an ADV.

The invention, as defined by the appended claims, is described with reference to the accompanying figures.

Techniques and methods described herein are directed to a planning architecture of an autonomous vehicle that is able to maintain a smooth trajectory as the vehicle follows a planned path or route. The autonomous vehicle operates using two coordinate frames. The first coordinate frame may be relative to the vehicle (e.g., a vehicle body-centric coordinate frame), such that a position of the vehicle in the first coordinate frame remains substantially smooth or stable as the vehicle traverses the planned route. The vehicle may also maintain a second coordinate frame that is based on a location of the vehicle on the surface of the Earth (e.g., a Euclidian coordinate frame), such as Universal Transverse Mercator (UTM) coordinate frame or a longitudinal/latitudinal coordinate frame. Although discussed herein with respect to such body-centric and Euclidian coordinate frames, the disclosure is not meant to be so limiting and any combination of one or more coordinate systems (including a same coordinate system) is contemplated.

In an example process, the planning architecture of the autonomous vehicle may compensate for differences between an estimated state and a planned path without the use of a separate system. In this example process, the planning architecture may include a mission planning system, a decision system, and a tracking system that together output a trajectory for a drive system. In general, the mission planning system may generate a planned route of the vehicle from a first location to a second location. The decision system may maintain, adjust, or generate planned trajectories of the vehicle based on the planned route and the estimated state or position of the vehicle and taking into account any objects that may be proximate the vehicle, and the tracking system may generate correction trajectories to compensate for variances between the planned route and the planned trajectory (e.g., to assist with keeping the vehicle on the planned trajectory). In some cases, the example process may also include projecting the estimated state onto the planned trajectory within the first (e.g., body-centric) frame and then converting the projected state or position into the second (e.g., Euclidian) coordinate frame prior to the tracking system generating the correction trajectory.

To provide an illustrative example of a difference in estimated state or position, assume an autonomous vehicle may be initially at an estimated position of (<NUM>, <NUM>) within the first coordinate frame and at an estimated position of (<NUM>, <NUM>) in the second coordinate frame. In this illustrative example, the previous planning decision may include a planned trajectory that starts at (<NUM>, <NUM>) in the first coordinate frame and at (<NUM>, <NUM>) in the second frame, such that there is zero distance between the position of the vehicle and the decision trajectory (e.g., both are at (<NUM>, <NUM>) first coordinate frame and (<NUM>, <NUM>) second coordinate frame during the first period of time.

In this example, the estimated state of the vehicle received from the position sensors is at (<NUM>, <NUM>) in second coordinate frame, e.g., the estimated state is <NUM> unit of measure different than the expected state or position. Thus, the vehicle, either due to error in the position sensor or drift by the vehicle (and/or any associated algorithms), is no longer along the planned trajectory or the planned route.

As the vehicle receives the estimated state, the vehicle may project, in the first coordinate frame, the estimated state onto the previous planned trajectory to determine a projected state or position along the previous planned trajectory. In some examples, the vehicle may first convert the estimated state, which is received in the second coordinate frame, into the first coordinate frame. However, it should be understood, since the first coordinate frame is relative to the vehicle (e.g., body-centric), both the expected state and the estimated state of the vehicle are the same.

In some cases, such as the current example, the projected state may be a distance from the estimated position of the vehicle. The projected state may be transformed into the second coordinate frame using transformations determined with respect the state of the vehicle during a previous period of time and a new planned trajectory may be determined using the projected state and the planned route. The estimated state and the new planned trajectory may be provided to the tracking system. The tracking system may then generate a correction trajectory to further compensate for any discrepancies between the estimated state and the newly planned trajectory, as well as to compensate for any detected nearby objects.

The techniques described herein can be implemented in a number of ways. Example implementations are provided below with reference to the following figures. Although discussed in the context of an autonomous vehicle, the methods, apparatuses, and systems described herein can be applied to a variety of systems (e.g., a sensor system or a robotic platform), and are not limited to autonomous vehicles. In one example, similar techniques may be utilized in driver-controlled vehicles in which such a system may provide an indication of whether it is safe to perform various maneuvers. In another example, the techniques can be utilized in a manufacturing assembly line context, in an aerial surveying context, or in a nautical context. Additionally, the techniques described herein can be used with real data (e.g., captured using sensor(s)), simulated data (e.g., generated by a simulator), or any combination of the two.

<FIG> is an example pictorial diagram <NUM> illustrating transformations associated with a planning architecture, as described herein. In the current example, the vehicle may have an expected state or position <NUM> and a position system of the vehicle may return an estimated state <NUM>. In the illustrated example, both the expected state or position <NUM> and the estimate state or position <NUM> are shown in both a first coordinate frame <NUM> (e.g., a body centric coordinate frame) and a second coordinate frame <NUM> (e.g., a Euclidian coordinate frame). Similar to the example provided above, in the illustrated example, it should be noted that the expected state <NUM> and the estimated state <NUM> in the first coordinate frame is the same as the coordinate frame is relative to a position of the vehicle.

In the current example, the vehicle has a planned route <NUM> from a planning system and a previously planned trajectory <NUM> from a decision system. As shown, the expected state <NUM> differs from the previously planned trajectory <NUM> by a first distance and the estimated state <NUM> differs from the expected state <NUM> by an additional or second distance.

In this example, the estimated state <NUM> and the previously planned trajectory <NUM> are transformed into the first coordinate frame <NUM> and the estimated state <NUM> is projected <NUM> in the first coordinate frame <NUM> as shown to determine a projected state or position <NUM> along the previously planned trajectory <NUM>. In some cases, such as the current instance, the projected state or position <NUM> may be a distance <NUM> from the position estimate <NUM> in the first coordinate frame <NUM> as shown. The projected state <NUM> is then transformed into the second coordinate frame <NUM>. The vehicle may then plan from the projected state <NUM> in the second coordinate frame (e.g., the Euclidian coordinate frame) to determine a new planned trajectory <NUM>. Thus, by projecting in the first coordinate frame that is relative to the vehicle's position and then transforming the projected state <NUM> into the second coordinate frame, the vehicle may plan from a position <NUM> that is closer to the vehicle, than if a projection between the estimated state <NUM> and the previously planned trajectory <NUM> was determined in the second coordinate frame. By having the vehicle plan from a position <NUM> that is closer to the estimated state <NUM>, the vehicle is better able to plan around nearby obstacles.

The new planned trajectory <NUM> may then be provided to a tracking system to generate the correction trajectory <NUM> to compensate for the distance <NUM> between the projected state <NUM> and the estimated state <NUM>. Again, since the newly planned trajectory <NUM> is closer to the estimated state <NUM> than the previously planned trajectory <NUM>, the correction trajectory <NUM> generated by the tracking system may be calculated using fewer processing resources and in less time, thereby improving decision and reaction time of the vehicle which ultimately improves the operational safely of the vehicle.

<FIG> is an example timing <NUM> diagram in a Euclidian coordinate system illustrating an autonomous vehicle utilizing a planning architecture, as described herein. In the current example, a vehicle <NUM> traversing a planned route <NUM> via a first planned trajectory <NUM> is shown. For instance, at a first period of time, t<NUM>, the vehicle <NUM> may be at a first position <NUM> along the first planned trajectory <NUM>(A). As illustrated, such a first planned trajectory <NUM>(A) may be determined in order to promote the vehicle <NUM> to follow the planned route <NUM> based on various data (distance from the route <NUM>, obstacles, etc.).

At a second period of time t<NUM>, the vehicle <NUM> may have shifted (e.g., either due to error in the position system (sensor discrepancy, algorithm discrepancy, and/or otherwise) or drift during navigation) to a position <NUM>. Thus, the vehicle <NUM> may be a first distance <NUM> from the first planned trajectory <NUM>(A). During the second period of time, the vehicle <NUM> may generate a first correction trajectory <NUM> and, thus, have an expected state or position <NUM>, during a third period of time t<NUM>.

However, in the current example, during the third period of time, the vehicle <NUM> is actually at an estimated state <NUM> not at the expected state <NUM>. In this example, the planning architecture of the vehicle <NUM> may transform the first planned trajectory <NUM>(A) and the estimated state <NUM> into the first coordinate frame, causing the first planned trajectory <NUM>(A) to be positioned relative to the vehicle <NUM> as shown by first transformed planned trajectory <NUM>(B). The vehicle <NUM> may then perform a projection <NUM> to determine a projected state <NUM> along the first planned trajectory <NUM>(A) within the first coordinate frame.

The projected state <NUM> may then be transferred back into the second coordinate frame at the position shown. The vehicle <NUM> may then determine a second planned trajectory <NUM> based on the projected state <NUM> within the second coordinate frame. Such a second planned trajectory may represent a trajectory for the vehicle <NUM> to return to the route <NUM> from the first transformed planned trajectory <NUM>(B) in a similar fashion as if the planning had been performed at the first transformed trajectory <NUM>(A). In this manner, the current planning process allows the vehicle <NUM> to determine the second planned trajectory <NUM> from the projected state <NUM> that is closer to the estimated state <NUM> of the vehicle <NUM> than the position <NUM> along the first planned trajectory <NUM>(A) thereby improving safety over convectional planning systems. For instance, as shown an object <NUM> (e.g., the tree) may be in the path of the vehicle <NUM> but would not be accommodated for in a planned trajectory (not shown) determined from position <NUM>, but is easily avoided in the current process, described herein.

In some instances, such as the illustrated example, the vehicle <NUM> may still be offset or may be a distance from the second planned trajectory <NUM>. In these cases, the vehicle <NUM> may determine a correction trajectory <NUM> to bring the vehicle <NUM> closer to or onto the planned trajectory <NUM>. Again, since the planned trajectory <NUM> is physical closer to the estimated state <NUM>, the calculations to determine the correction trajectory <NUM> are reduced and, as such, reduce time periods associated with decision and planning, thereby improving overall safety of the vehicle <NUM>.

<FIG> is an example pictorial diagram <NUM> of an autonomous vehicle <NUM> utilizing a planning architecture, described above with respect to <FIG> and <FIG>. In the current example, the vehicle <NUM> is traveling within a planned path or route <NUM> having a route reference <NUM> (e.g., a side or center of a lane). The vehicle <NUM> also has a previous planned trajectory <NUM>(A) in the second coordinate system (e.g., within the Euclidian coordinate frame illustrated in <FIG>). In the current example, the previous planned trajectory <NUM>(A) may be in the form of an arc (e.g., the vehicle <NUM> is not moving in a straight line as in <FIG> and <FIG>). As discussed above, an actual state of the vehicle <NUM> (position, velocity, yaw, heading, etc.) represented by <NUM> may differ from an expected state <NUM>, which may also be offset from the planned trajectory <NUM>(A) as shown.

In this example, the previously planned trajectory <NUM>(A) may be transformed into the first coordinate frame (e.g., the vehicle or body-centric coordinate frame) as shown as previously planned trajectory <NUM>(B). It should be noted, that as <FIG> is shown in the second coordinate frame and the previously planned trajectory <NUM>(B) in the first coordinate frame, the location of the previously planned trajectory <NUM>(B) relative to the estimated state reflects the position of the previously planned trajectory <NUM>(A) relative to the expected state <NUM> of the vehicle <NUM>.

The vehicle <NUM> may then project the estimated state <NUM> onto the previous planned trajectory <NUM>(B), generally indicated by projection <NUM>, to identify the projected state <NUM>. In some cases, such as the illustrated example, the projection <NUM> is based on a shortest distance between the estimated state <NUM> of the vehicle <NUM> and the previous decision trajectory <NUM>(B). The projected state <NUM> may then transformed into the second coordinate frame using transformations determined with respect the state of the vehicle during a current period of time. The vehicle <NUM> may then determine a new planned trajectory <NUM> starting from the projected state <NUM> in the second coordinate frame and returning the vehicle <NUM> to the planned path <NUM>, as shown. However, in some cases, the vehicle <NUM> may still be offset from the new planned trajectory <NUM>. In these cases, the vehicle <NUM>, or a tracking system of the vehicle <NUM>, may determine a correction trajectory <NUM> to bring the vehicle <NUM> onto the planned trajectory <NUM>. Again, since the planned trajectory <NUM>(B) is physical closer to the estimated state <NUM>, the calculations to determine the correction trajectory <NUM> are reduced and, as such, reduce time periods associated with decision and planning, thereby improving overall safety of the vehicle <NUM>.

In the examples, above the estimated state <NUM> of the vehicle <NUM> is shown as at the midpoint of the vehicle <NUM>, however, the point <NUM> may be at any fixed position on the vehicle <NUM>. For example, the point <NUM> may be along the front or rear axle as well as other positions.

<FIG> is a flow diagram illustrating example process <NUM> associated with the planning architecture according to some implementations. The processes are illustrated as a collection of blocks in a logical flow diagram, which represent a sequence of operations, some or all of which can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions stored on one or more computer-readable media that, which when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, encryption, deciphering, compressing, recording, data structures and the like that perform particular functions or implement particular abstract data types.

The order in which the operations are described should not be construed as a limitation. Any number of the described blocks can be combined in any order and/or in parallel to implement the processes, or alternative processes, and not all of the blocks need be executed. For discussion purposes, the processes herein are described with reference to the frameworks, architectures and environments described in the examples herein, although the processes may be implemented in a wide variety of other frameworks, architectures or environments.

As discussed above, in some instances, an estimated state of an autonomous vehicle may move or jump due to changes in data received from various position sensors. The jumps in estimated state may result in back and forth or jerky movement of the vehicle without proper compensation by the planning architecture or systems of the vehicle.

<FIG> is a flow diagram illustrating an example process <NUM> associated with the planning architecture, as described herein. The process <NUM> may be used by, for instance, an autonomous vehicle to compensate for differences between an estimated state and a planned path by projecting the estimated state on to a planned trajectory within a first (body-centric) coordinate frame and then converting the projected state into the second (e.g., Euclidian) coordinate frame prior to the tracking system generating the correction trajectory.

At <NUM>, the system may receive or access a planned trajectory. In some cases, the planned trajectory may be associated with a previous period of time. The planned trajectory may be in the first coordinate frame, the second coordinate frame, or both.

At <NUM>, the system may receive or determine transforms associated with the planned trajectory between the first coordinate frame and a second coordinate frame. In some cases, the transforms may be determined during a previous period of time, such as during the period of time in which the planned trajectory was determined. In some examples, the transforms may be stored at a location that is accessible by the systems of the planning architecture.

At <NUM>, the system may receive an estimated state. The estimated state may be received from one or more position sensors or systems associated with the position sensors. For example, the position sensors may include an inertial measurement unit (IMU), Global Position System (GPS) sensors or Global Navigation Satellite System (GNSS) sensors as well as other types of position sensors. In some examples, the position may be estimated based on captured image, lidar, or radar data of a physical environment surrounding the vehicle as well as one or more stored environment maps. For example, the operation <NUM> may include localizing a vehicle in an environment based on a captured data (e.g., lidar, radar, image) with respect to a map (e.g., a mesh or data structure comprising multi-resolution covariance data). The estimated state may be within the second coordinate frame.

At <NUM>, the system may transform the estimated state into the first coordinate frame (e.g., the body-centric coordinate frame). Thus, the estimated state and the planned trajectory may be compared within the first coordinate frame. Additionally, it should be understood, that as the first coordinate frame is relative to the vehicle, a position of the vehicle does not move even with the corresponding jump in the estimated state.

At <NUM>, the system may project the estimated state onto the planned trajectory in the first coordinate frame. For example, as discussed above with respect to <FIG>, the system may project the estimated state onto the planned trajectory by determining a shortest distance between the planned trajectory and the estimated state.

At <NUM>, the system may determine a projected state in the first coordinate frame. For example, the position on the planned trajectory that is the shortest distance from the estimated state may be selected or used as the projected state.

At <NUM>, the system may then determine a new planned trajectory in the second coordinate frame based at least in part on the projected state. For example, the system may determine a new trajectory to return the vehicle from the projected state to the planned path accommodating for any nearby objects.

At <NUM>, the system may output the new planned trajectory and the estimated state to a tracker system. For example, some offset between the estimated state and the new planned trajectory may still exist, as the new planned trajectory is determined from the projected state. In these cases, the tracker system may determine a correction trajectory between the estimated state and the new planned trajectory that avoids any nearby objects, as discussed above.

<FIG> is a block diagram illustrating an example planning architecture <NUM>, as described herein. In the current example, the planning architecture <NUM> may include a planning system <NUM>, a decision system <NUM>, and a tracking system <NUM>. The planning system <NUM> may generate a planned path <NUM> for the vehicle from a first location to a second location. The decision system <NUM> may maintain, adjust, or generate planned trajectories, such as planned trajectories <NUM>(A) and <NUM>(B), of the vehicle based on the planned path <NUM> and an estimated state <NUM> of the vehicle taking into account any objects that may be proximate the vehicle. For example, the decision system <NUM> may receive the estimated state <NUM> of the vehicle and project the estimated state <NUM> onto a previously planned trajectory <NUM>(A) to determine a projection position <NUM>, as discussed above. The decision system <NUM> may then generate a new planned trajectory <NUM>(C) based on the projected state <NUM> and the planned path <NUM> as shown. The tracking system <NUM> may generate correction trajectories <NUM> to be followed by a drive system <NUM> to compensate for variances between the planned path <NUM> and the planned trajectory <NUM>(C) (e.g., to assist with keeping the vehicle on the planned trajectory <NUM>(C).

<FIG> is a block diagram of an example system <NUM> for implementing the techniques described herein, in accordance with embodiments of the disclosure. In some examples, the system <NUM> may include one or multiple features, components, and/or functionality of embodiments described herein with reference to <FIG>. In some embodiments, the system <NUM> may include a vehicle <NUM>. The vehicle <NUM> may include a vehicle computing device <NUM>, one or more sensor systems <NUM>, one or more communication connections <NUM>, and one or more drive systems <NUM>.

The vehicle computing device <NUM> may include one or more processors <NUM> and computer readable media <NUM> communicatively coupled with the one or more processors <NUM>. In the illustrated example, the vehicle <NUM> is an autonomous vehicle; however, the vehicle <NUM> could be any other type of vehicle, or any other system (e.g., a robotic system, a camera enabled smartphone, etc.). In the illustrated example, the computer readable media <NUM> of the vehicle computing device <NUM> stores a planning system <NUM> and system controllers <NUM> as well as trajectories <NUM>, position data <NUM>, coordinate frames <NUM>, and transforms <NUM> between the coordinate frames <NUM>. Though depicted in <FIG> as residing in computer readable media <NUM> for illustrative purposes, it is contemplated that the planning system <NUM> and the system controllers <NUM> as well as the trajectories <NUM>, the position data <NUM>, the coordinate frames <NUM>, and the transforms <NUM> may additionally, or alternatively, be accessible to the vehicle <NUM> (e.g., stored on, or otherwise accessible by, computer readable media remote from the vehicle <NUM>).

In at least one example, the planning system <NUM> may be configured to implement one or more processes for compensating for deviations between measured and desired states of the vehicle as described with respect to any of <FIG> herein.

In at least one example, the vehicle computing device <NUM> can include one or more system controllers <NUM>, which can be configured to control steering, propulsion, braking, safety, emitters, communication, and other systems of the vehicle <NUM>. These system controller(s) <NUM> may communicate with and/or control corresponding systems of the drive system(s) <NUM> and/or other components of the vehicle <NUM>. In some instances, aspects of some or all of the components discussed herein can include any models, algorithms, and/or machine learning algorithms.

In at least one example, the sensor system(s) <NUM> can include lidar sensors, radar sensors, ultrasonic transducers, sonar sensors, location sensors (e.g., GPS, compass, etc.), inertial sensors (e.g., inertial measurement units (IMUs), accelerometers, magnetometers, gyroscopes, etc.), cameras (e.g., RGB, IR, intensity, depth, time of flight, etc.), microphones, wheel encoders, environment sensors (e.g., temperature sensors, humidity sensors, light sensors, pressure sensors, etc.), and one or more time of flight (ToF) sensors, etc. The sensor system(s) <NUM> can include multiple instances of each of these or other types of sensors. For instance, the lidar sensors may include individual lidar sensors located at the corners, front, back, sides, and/or top of the vehicle <NUM>. As another example, the camera sensors can include multiple cameras disposed at various locations about the exterior and/or interior of the vehicle <NUM>. The sensor system(s) <NUM> may provide input to the vehicle computing device <NUM>. Additionally, or alternatively, the sensor system(s) <NUM> can send sensor data, via the one or more networks, to the one or more computing device(s) at a particular frequency, after a lapse of a predetermined period of time, in near real-time, etc..

The vehicle <NUM> can also include one or more communication connection(s) <NUM> that enable communication between the vehicle <NUM> and one or more other local or remote computing device(s). For instance, the communication connection(s) <NUM> may facilitate communication with other local computing device(s) on the vehicle <NUM> and/or the drive system(s) <NUM>. Also, the communication connection(s) <NUM> may allow the vehicle <NUM> to communicate with other nearby computing device(s) (e.g., other nearby vehicles, traffic signals, etc.). The communications connection(s) <NUM> also enable the vehicle <NUM> to communicate with remote teleoperations computing device or other remote services.

The communications connection(s) <NUM> may include physical and/or logical interfaces for connecting the vehicle computing device <NUM> to another computing device (e.g., computing device(s) <NUM>) and/or a network, such as network(s) <NUM>. For example, the communications connection(s) <NUM> may enable Wi-Fi-based communication such as via frequencies defined by the IEEE <NUM> standards, short range wireless frequencies such as Bluetooth®, cellular communication (e.g., <NUM>, <NUM>, <NUM>, <NUM> LTE, <NUM>, etc.) or any suitable wired or wireless communications protocol that enables the respective computing device to interface with the other computing device(s).

In at least one example, the vehicle <NUM> can include one or more drive systems <NUM>. In some examples, the vehicle <NUM> may have a single drive system <NUM>. In at least one example, if the vehicle <NUM> has multiple drive systems <NUM>, individual drive systems <NUM> can be positioned on opposite ends of the vehicle <NUM> (e.g., the front and the rear, etc.). In at least one example, the drive system(s) <NUM> can include one or more sensor systems <NUM> to detect conditions of the drive system(s) <NUM> and/or the surroundings of the vehicle <NUM>, as discussed above. By way of example and not limitation, the sensor system(s) <NUM> can include one or more wheel encoders (e.g., rotary encoders) to sense rotation of the wheels of the drive systems, inertial sensors (e.g., inertial measurement units, accelerometers, gyroscopes, magnetometers, etc.) to measure orientation and acceleration of the drive system, cameras or other image sensors, ultrasonic sensors to acoustically detect objects in the surroundings of the drive system, lidar sensors, radar sensors, etc. Some sensors, such as the wheel encoders may be unique to the drive system(s) <NUM>. In some cases, the sensor system(s) <NUM> on the drive system(s) <NUM> can overlap or supplement corresponding systems of the vehicle <NUM>.

In at least one example, the components discussed herein can process sensor data, such as position data <NUM>, as described above, and may send their respective outputs, over the one or more network(s) <NUM>, to one or more computing device(s) <NUM>. In at least one example, the components discussed herein may send their respective outputs to the one or more computing device(s) <NUM> at a particular frequency, after a lapse of a predetermined period of time, in near real-time, etc..

As described herein, an exemplary neural network is a biologically inspired algorithm which passes input data through a series of connected layers to produce an output. Each layer in a neural network can also comprise another neural network or can comprise any number of layers (whether convolutional or not). As can be understood in the context of this disclosure, a neural network can utilize machine learning, which can refer to a broad class of such algorithms in which an output is generated based on learned parameters.

Although discussed in the context of neural networks, any type of machine learning can be used consistent with this disclosure. For example, machine learning algorithms can include, but are not limited to, regression algorithms (e.g., ordinary least squares regression (OLSR), linear regression, logistic regression, stepwise regression, multivariate adaptive regression splines (MARS), locally estimated scatterplot smoothing (LOESS)), instance-based algorithms (e.g., ridge regression, least absolute shrinkage and selection operator (LASSO), elastic net, least-angle regression (LARS)), decisions tree algorithms (e.g., classification and regression tree (CART), iterative dichotomiser <NUM> (ID3), Chi-squared automatic interaction detection (CHAID), decision stump, conditional decision trees), Bayesian algorithms (e.g., naive Bayes, Gaussian naive Bayes, multinomial naive Bayes, average one-dependence estimators (AODE), Bayesian belief network (BNN), Bayesian networks), clustering algorithms (e.g., k-means, k-medians, expectation maximization (EM), hierarchical clustering), association rule learning algorithms (e.g., perceptron, back-propagation, hopfield network, Radial Basis Function Network (RBFN)), deep learning algorithms (e.g., Deep Boltzmann Machine (DBM), Deep Belief Networks (DBN), Convolutional Neural Network (CNN), Stacked Auto-Encoders), Dimensionality Reduction Algorithms (e.g., Principal Component Analysis (PCA), Principal Component Regression (PCR), Partial Least Squares Regression (PLSR), Sammon Mapping, Multidimensional Scaling (MDS), Projection Pursuit, Linear Discriminant Analysis (LDA), Mixture Discriminant Analysis (MDA), Quadratic Discriminant Analysis (QDA), Flexible Discriminant Analysis (FDA)), Ensemble Algorithms (e.g., Boosting, Bootstrapped Aggregation (Bagging), AdaBoost, Stacked Generalization (blending), Gradient Boosting Machines (GBM), Gradient Boosted Regression Trees (GBRT), Random Forest), SVM (support vector machine), supervised learning, unsupervised learning, semi-supervised learning, etc. Additional examples of architectures include neural networks such as ResNet50, ResNet101, VGG, DenseNet, PointNet, and the like.

The processor(s) <NUM> of the vehicle <NUM> and the processor(s) <NUM> of the computing device(s) <NUM> may be any suitable processor capable of executing instructions to process data and perform operations as described herein. By way of example and not limitation, the processor(s) <NUM> and <NUM> can comprise one or more Central Processing Units (CPUs), Graphics Processing Units (GPUs), or any other device or portion of a device that processes electronic data to transform that electronic data into other electronic data that can be stored in registers and/or computer readable media. In some examples, integrated circuits (e.g., ASICs, etc.), gate arrays (e.g., FPGAs, etc.), and other hardware devices can also be considered processors in so far as they are configured to implement encoded instructions.

Computer readable media <NUM> and <NUM> are examples of non-transitory computer-readable media. The computer readable media <NUM> and <NUM> can store an operating system and one or more software applications, instructions, programs, and/or data to implement the methods described herein and the functions attributed to the various systems. In various implementations, the computer readable media can be implemented using any suitable computer readable media technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of computer readable media capable of storing information. The architectures, systems, and individual elements described herein can include many other logical, programmatic, and physical components, of which those shown in the accompanying figures are merely examples that are related to the discussion herein.

As can be understood, the components discussed herein are described as divided for illustrative purposes. However, the operations performed by the various components can be combined or performed in any other component.

It should be noted that while <FIG> is illustrated as a distributed system, in alternative examples, components of the vehicle <NUM> can be associated with the computing device(s) <NUM> and/or components of the computing device(s) <NUM> can be associated with the vehicle <NUM>. That is, the vehicle <NUM> can perform one or more of the functions associated with the computing device(s) <NUM>, and vice versa. Further, aspects of machine learning component <NUM> can be performed on any of the devices discussed herein.

Claim 1:
A method comprising:
determining (<NUM>) a projected state (<NUM>, <NUM>, <NUM>, <NUM>) of an autonomous vehicle by projecting, within a first coordinate frame, an estimated state (<NUM>, <NUM>, <NUM>, <NUM>) associated with the autonomous vehicle onto a first planned trajectory (<NUM>, <NUM>, 308B, 510A, 510B) of the autonomous vehicle (<NUM>, <NUM>), wherein projecting the estimated state onto the first planned trajectory comprises determining a shortest distance between the first planned trajectory and the estimated state, and selecting the position on the first planned trajectory which is the shortest distance from the estimated state as the projected state;
determining (<NUM>), based at least in part on a second coordinate frame, a second planned trajectory (<NUM>, <NUM>, <NUM>, 510C) associated with the autonomous vehicle based at least in part on the projected state and a planned path associated with the autonomous vehicle; and
controlling the autonomous vehicle based at least in part on the second planned trajectory.