DE112022003731T5 - METHOD AND SYSTEM FOR CONFIGURING VARIATIONS IN TRAINING SIMULATIONS OF AN AUTONOMOUS VEHICLE - Google Patents

Abstract

A method includes receiving a base simulation scenario comprising features of a scene through which a vehicle may travel and receiving a simulation variation for an object in the scene. The simulation variation defines multiple values for a property of the object. The method includes adding the simulation variation to the base simulation scenario to yield an augmented simulation scenario and applying the augmented simulation scenario to a planning model of motion of an autonomous vehicle to train the planning model. The planning model iteratively simulates variations of the object based on values for the property of the object. In response to each simulated variation of the object, the planning model selects a continued trajectory for the vehicle, where the continued trajectory is either the planned trajectory or an alternate trajectory.

Description

CROSS-REFERENCE AND PRIORITY CLAIM

This patent application claims priority to US patent application Nos. 17/387,922 and 17/387,927 , each filed on July 28, 2021, and U.S. patent application No. 17/468,600 , filed September 7, 2021. All priority applications are fully incorporated herein by reference.

BACKGROUND

Many vehicles today, including but not limited to autonomous vehicles (AVs), use motion planning systems to decide or help the driver make decisions about where and how to move in an environment. Motion planning systems rely on artificial intelligence models to analyze moving actors that the vehicle's sensors can perceive, make predictions about what those actors may do, and select or recommend a course of action for the vehicle that takes into account the actor's likely action.

To make predictions and determine courses of action, the vehicle's motion planning model must be trained on data that the vehicle may encounter in an environment. The more unique the scenarios used to train a vehicle's motion planning model, the better the model can be at making motion planning decisions. However, the range of possible scenarios a vehicle may encounter is limitless. Manually developing a large number of unique simulation scenarios would require a significant investment in time and manpower, as well as ongoing costs to update individual scenarios as the motion planning model improves and vehicle behavior changes.

Although systems are available to randomly develop simulation scenarios, the number of possible random scenarios is limitless. A purely random simulation would require the motion planning model to consider an extremely large number of events that may not be relevant or that would at least be extremely unlikely to occur in the real world. This causes a significant waste of computational resources and time. In addition, it may require the vehicle to be trained on a large number of less relevant scenarios well before the random process yields more relevant scenarios.

Therefore, methods for identifying and developing an effective set of relevant simulation scenarios and training the vehicle model on such scenarios are required.

This document describes procedures and systems that address problems such as those discussed above and/or other problems.

SUMMARY

In various embodiments, a method for generating a scenario for simulating a planning model of motion of a vehicle is disclosed. The method may be embodied in computer programming instructions and/or implemented by a system comprising a processor. The method includes receiving, from a data store containing a plurality of simulation scenarios, a base simulation scenario comprising features of a scene through which a vehicle may travel. The method includes receiving, from the data store, a simulation variation for an object in the scene, the simulation variation defining a plurality of values for a property of the object. The method further includes adding the simulation variation to the base simulation scenario to yield an extended simulation scenario, and applying the extended simulation scenario to a planning model of motion of an autonomous vehicle to train the planning model of motion. The planning model simulates the movement of the vehicle along a planned trajectory and iteratively simulates variations of the object based on the multiple values for the property of the object. In response to each simulated variation of the object, the planning model selects a continued trajectory for the vehicle, either the planned trajectory or an alternative trajectory, and causes the vehicle to move along the continued trajectory.

In other embodiments, a method for generating training scenario variations is disclosed. The method may be embodied in a scenario variation generation system configured to receive a base scenario with objects in a scene and execute a user interface configured to display data associated with properties of the objects in the scene. The property may include a dimension, a position, a speed, an acceleration, or a behavior-triggering distance of the object. The user interface may further be configured to display a Receive variation input related to properties of the objects. In response to the user interface receiving variation input defining a plurality of values for properties of the objects, the scenario variation generation system may store a scenario variation in a data store containing simulation scenarios, the scenario variation based on the plurality of values and configured to augment one or more of the simulation scenarios.

BRIEF DESCRIPTION OF THE DRAWINGS

• 1A shows example elements of a vehicle simulation scenario, while 1B a modified version of the simulation scenario of 1A represents.
• 2 shows example subsystems of an autonomous vehicle.
• 3A and 3B are flowcharts that represent a process by which a system for training a planning model of a vehicle's movement can generate an extended simulation scenario.
• 4A and 4B represent certain elements of the process of 3A and 3B in an alternative format.
• 5A and 5B present the development of a simulation scenario extension using an example set of candidate object data.
• 6 is a flowchart that represents a process by which a system for training a planning model of a vehicle's motion can identify interaction zones in which the system can modify a base simulation scenario.
• 7 represents an extended example simulation scenario in which a hindering object behavior has been introduced into the scenario.
• 8th represents an extended example simulation scenario in which a different object behavior has been introduced into the scenario.
• 9 illustrates how a system can accommodate element distributions in different segments of an interaction zone when multiple extended simulation scenarios have been generated.
• 10 shows a sample input form for configuring simulated variations.
• 11 shows another example input form for configuring simulated variations.
• 12 shows calculated values for a property of an object.
• 13 shows another example input form for configuring simulated variations.
• 14 shows calculated values for two properties of an object.
• 15 shows another example input form for configuring simulated variations.
• 16 shows calculated values for two properties of an object.
• 17 shows another example input form for configuring simulated variations.
• 18 shows calculated values for a property of an object.

DETAILED DESCRIPTION

As used in this document, the singular forms "a", "an" and "the" include plural references unless the context clearly indicates otherwise. Unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by one of ordinary skill in the art. As used in this document, the term "comprising" (or "comprising") means "including (or including), but not limited to." Definitions for additional terms relevant to this document are included at the end of this Detailed Description.

An autonomous vehicle (AV) software stack includes various software platforms that handle different tasks that help the AV move through an entire environment. These tasks include tasks such as perception, motion planning, and motion control. An AV stack may reside in a software archive (in the physical form of computer-readable storage) that is available to an original equipment manufacturer (OEM) and/or suppliers to the OEM. An AV stack may also be deployed directly on a vehicle. However, to be effective, before being deployed on a vehicle, an AV stack must be trained on multiple simulation scenarios. Training is a process that applies a simulation scenario definition to one or more of the AV stack's systems so that the AV stack can process the simulation scenario and generate a response. Supplemental training can also be conducted after an AV stack is deployed on a vehicle, with additional simulation scenarios that further enhance the operation of the AV stack and help the AV to handle an increased variety of conditions recognizes and reacts when it encounters them in the real world.

A simulation scenario definition is a set of parameters and/or programming instructions that identify one or more objects in a scene, the initial locations, dimensions, and other configuration parameters of the objects. For such objects, the simulation scenario definition may include acceleration profiles or other profiles that guide possible movements of the object in the scene. Some objects may be actors that are moving or that could move, such as vehicles, pedestrians, or animals. Other objects may also be static objects that may obscure the field of view of the AV's perception system, such as vegetation or buildings. 1A is a graphical representation of an example simulation scenario for a vehicle 101 moving along a first roadway 117 according to a planned trajectory 102 past an intersection with a second roadway 118. The simulation scenario definition includes actors that are a parked vehicle 113 and pedestrians 114 and 115. The configuration for the parked vehicle 113 may define that the vehicle is not currently moving, but that it may begin to move forward and/or into the vehicle's lane. The configuration for the pedestrian 114 may define that the pedestrian is moving parallel to the first roadway 117 and toward the second roadway 118, and is equally likely to cross either the first roadway 117 or the second roadway 118 when reaching the intersection. The configuration for the pedestrian 115 may define that the pedestrian moves parallel to the first road 117 and that he has a higher probability of continuing to move forward than turning and crossing the first road 117. The simulation scenario of 1A can be stored in a training system database for use in training one or more subsystems of an AV stack.

This document describes methods and systems for extending basic simulation scenarios such as the one in 1A shown by introducing one or more variations into the base scenario. The variation may involve introducing one or more new actors into the base scenario, changing the configuration for one or more of the actors already existing in the scenario, or both. 1B shows, for example, a variation of the simulation scenario of 1A , in which an additional actor - in this case a parked car 119 - is added to the scene. A system for training a planning model of a movement of a vehicle may use an extended simulation scenario such as that of 1B in addition to the base scenario of 1A store and use to train the AV stack. Extending base scenarios using such variations may reduce the number of base scenarios required to effectively train the AV stack. Furthermore, simulation variations, which typically focus on a subset of a scenario, may generally be easier for the user to manage than a base scenario and may use fewer resources such as memory or storage than base scenarios. By reducing the number of base scenarios and extending this smaller number of base scenarios with more easily managed (or automatically generated) simulation variations, the overall management burden may be significantly reduced. For example, the user may no longer need to create a new base scenario simply to add an object or modify a behavior or property of an existing object in the base scenario. And the user may be able to perform a management update on a large number of scenarios by performing the management update on the relatively smaller number of base scenarios, each of which is augmented by associated simulation variations. Furthermore, simulation variations that prove valuable when applied to one base scenario can be easily applied to other base scenarios without incurring the burden of updating or reconfiguring the other base scenarios. Moreover, using fewer resources can increase the total number of scenarios available to train the AV stack.

Before further exploring the details of the present embodiments, we provide some background information about AV systems. 2 shows a high-level overview of subsystems of an AV stack that may be relevant to the discussion below. Certain components of the subsystems may be embodied in processor hardware and computer-readable programming instructions that are part of a computing system 201 that is either onboard the vehicle or that is external and stored on one or more storage devices. The subsystems may include a perception system 202 that includes sensors that capture information about moving actors and other objects that exist in the immediate vicinity of the vehicle. Example sensors include cameras, LiDAR sensors, and radar sensors. The data captured by such sensors (such as digital images, LiDAR point cloud data, or radar data) is known as perception data. The perception Perception data may include data representing one or more objects in the environment.

The perception system may include one or more processors and computer-readable memory with programming instructions and/or trained artificial intelligence models that, during a trip of the AV, process the perception data to identify objects and assign categorical labels and unique identifiers to each object detected in a scene. Categorical labels may include categories such as vehicle, bicyclist, pedestrian, building, and the like. Methods for identifying objects and assigning categorical labels to objects are well known in the art, and any suitable classification process may be used, such as those that perform bounding box predictions for detected objects in a scene and use convolutional neural networks or other computer vision models. Some such processes are described in Yurtsever et al., “A Survey of Autonomous Driving: Common Practices and Emerging Technologies” (published in IEEE Access, April 2020).

The vehicle's perception system 202 may provide perception data to the vehicle's prediction system 203. The prediction system (which may also be referred to as a prognostic system) includes processors and computer-readable programming instructions configured to process data received from the perception system and predict actions of other actors that the perception system detects.

The vehicle's perception system 202 and the vehicle's prediction system 203 provide data and information to the vehicle's motion planning system 204 and motion control system 205 so that the receiving systems can evaluate such data and initiate any number of responsive movements to such data. The motion planning system 204 and the motion control system 205 include and/or share one or more processors and computer-readable programming instructions configured to process data received from the other systems, calculate a trajectory for the vehicle, and issue commands to the vehicle hardware to move the vehicle according to the determined trajectory. Example actions that such commands may cause include causing the vehicle's braking control system to apply, causing the vehicle's acceleration control subsystem to increase the vehicle's speed, or causing the vehicle's steering control subsystem to turn the vehicle. Various motion planning techniques are well known, for example as described in Gonzalez et al., “A Review of Motion Planning Techniques for Automated Vehicles,” published in IEEE Transactions on Intelligent Transportation Systems, Volume 17, No. 4 (April 2016).

The subsystems described above may be implemented as components of an AV stack that can be trained on various simulation scenarios. As described above, the system 201 on which the subsystems may be installed may be computer processing hardware of the vehicle, or it may be one or more storage devices located external to the vehicle. The system 201 may be in communication with a remote server 206 that provides updates and/or commands or that receives data from the AV stack. Additionally, in the present embodiments, the system 201 on which the AV stack is installed is in electronic communication with a system for training a planning model of movement of a vehicle 209. The system 209 includes a processor 211, a data store 212 containing a variety of stored simulation scenarios, and a memory containing programming instructions 213 for creating, modifying, and using simulation scenarios to train the system 201.

Optionally, the system 209 may also include a user interface 214 for presenting information to a user and receiving information and/or commands from the user. The user interface 214 may, for example, include a display through which the system can output graphical representations of simulation scenarios and one or more menus or forms representing features or options for enhancing the scenario. The user interface may also include an input device, such as a mouse, keyboard, keypad, microphone, and/or touch screen elements of the display, through which the outputter can select variations for a displayed scenario. The variations may include new actors, configuration parameters for new or existing actors, or other information.

10 shows a sample input form 1000 for configuring simulated variations of an object in a scene. The form displays several properties 1001 of the object that can be varied. Here, the variable properties 1001 include dimensions of the object such as its height or its position in the scene (shown here as longitudinal distance and lateral offset with respect to a reference in the scene such as the starting position of the AV in the simulation). Other variable properties 1001 may be related to time and/or motion, such as the transition time for a traffic light to change or the acceleration of an object. Other variable properties 1001 may be related to the behavior of the object such as the distance from the vehicle to the object that triggers a behavior of the object. For example, when the vehicle comes within the trigger distance of an object simulating a pedestrian, the pedestrian may begin to cross the street. Likewise, a parked car such as the one shown in the input form 1000 of 10 configured to begin moving forward and/or into the vehicle's path when the vehicle comes within the configured trigger distance. The example input form includes an edit button (such as button 1002) for each variable property, allowing the user to configure aspects of each variation. For example, the user can change the value 1003 of the corresponding property.

11 shows a sample input form 1100 for configuring the variation of a property 1001 of the object in the scene. Here, the property 1001 is the lateral offset of the object with respect to the reference in the scene. The sample input form presents the user with several discrete options 1101 for configuring the variation, including locking the variation of the property. The sample input form also presents the user with fields 1102 that allow the user to enter numerical values related to the configuration. Here, the user has configured the lateral offset to cycle through values between -2.5 meters and -3.4 meters in increments of -0.1 meters without repeating the immediately preceding value (repeat = 0). With reference to 12 in response to the user configuring the variation, the user interface 214 may display a form 1200 with a table of values 1201 for the configured variation. Optionally, the user interface may include fields that enable a user to select a specific value 1202, 1202a-n from the table 1201 to use for the property 1001 of the object instead of the value for the base scenario property 1001. The user may select a button 1203 to indicate that the selected value 1202 should be used in a modified scenario. In response, the user interface may output a graphical display of the modified scenario using the selected value 1202 for the property 1001 of the object. The user interface includes fields (e.g., of the input form 1100) through which a user can enter data to refine the variation configuration based on the displayed scenario, e.g., e.g., to provide a good range of scenarios to train the AV stack. When the user is satisfied with the variation configuration, the user enters an indication (e.g., button 1103 of input form 1100) that the configuration is complete. In response, the system may, e.g., store the variation configuration in a training system database where the variation configuration may be applied to other base scenarios.

13 shows an example input form 1300 that configures the initial longitudinal distance of the object from the reference in the scene. Here, the user has configured the longitudinal distance to step through a number of defined values (in this example, five values) without repeating the immediately preceding value (repetition = 0). With reference to 14 in response to the user configuring the variation, the user interface 214 may display a form 1400 with a first table 1201 of values 1202a-n for the first configured variation and a second table 1401 of values 1402a-n for the second configured variation. Although each variation of the property 1001a, 1001b is configured separately, the system for training a planning model of a movement of a vehicle may consider the variations together as a simulation scenario is expanded. Here, the lateral offset is configured to go through ten values, but the longitudinal distance is configured to go through only five defined values. In some examples, when the final defined value for each property 1001a, 1001b is reached, the final value is maintained while values for other properties 1001a-n continue to vary according to each variation configuration. Here, the sequence of values for each property 1001b repeats, while values for other properties 1001a continue to vary. The example shown includes many possible combinations of values for both properties 1001a, 1001b, but does not include every combination of values.

15 shows a sample configuration form 1500 similar to the sample input form 1100 of 11 , with the repetition parameter set to four instead of zero, which configures the lateral offset to cycle through values between -2.5 meters and -3.4 meters in increments of -0.1 meters, with each value repeated four additional times in each step for a total of 50 values. With reference to 16 In response to the user configuring the variation, the user interface 214 may display a form 1600 with a first table 1201 of values 1202a-n for the first configured variation and a second table 1401 of values 1402a-n for the second configured variation (the table 1401 shown is truncated at the first twelve values). Here, the user has set the repetition parameter such that the total number of times the value occurs in each step is equal to the number of defined values of the variation configuration of the other properties 1001a or 1001b. Therefore, all combinations of values for variation configurations of both properties 1001a, 1001b can be simulated. As disclosed above, the user can select a pair of values 1202a-n, 1402a-n from the table 1201, 1401 to use for the properties 1001 of the objects instead of the values for the property 1001 of the base scenario. In response to the selection, the user interface may output a graphical display of the scenario modified by the selected values for the object's properties 1001. The user may further refine the variation configurations based on the displayed scenario.

The user can configure the variation of additional properties 1001 of objects in the scene. 17 shows a sample configuration form 1700 with the trigger distance for the object. Here, the user has configured the trigger distance to pass through 10 pseudorandom values between 4 and 15. With reference to 18 in response to the user configuring the variation, the user interface 214 may display a form 1800 with a table of values 1201 for the configured variation. Here, the values 1202 include the pseudorandom values between 4 and 15. The user interface may generate a seed value for the random number generator so that the same values for the trigger distance are used during each subsequent simulation. Alternatively, the user may choose to enter a new seed number to generate a new set of ten pseudorandom values to be used in subsequent simulations. The user may also configure variations in the motion profile of an object. For example, the user may configure the braking performance of the vehicle (or all vehicles, e.g., in a simulation of roads covered with snow or ice). In this example, the user may configure the braking performance to step through a certain number of random values with a Gaussian distribution (e.g., with a configurable mean and a configurable standard deviation) to simulate varying levels of degraded braking performance, e.g., due to varying degrees of simulated snow or ice on the road. In some examples, when the user is satisfied with the variation configuration for an object (e.g., the range of degraded braking performance), the user enters an indication (e.g., button 1103 of input form 1100) that the configuration is complete. In response, the system may, e.g., store the variation configuration in a training system database, where the variation configuration may be applied to any or all other objects within the base scenario, or any or all objects in other base scenarios. Other distributions of random numbers may be used, including Poisson distributions (e.g., with a configurable mean).

For example, the user may save the variation of the degraded braking performance so that it can be applied to the AV in other baseline scenarios. Likewise, the user may save variation configurations related to other properties 1001 of the AV, such as a starting speed or position, so that the other properties 1001 can also be used in other baseline scenarios. Moreover, variation configurations may be applied to an actual or live test of an AV, e.g., on a test track or other controlled environment. In this way, the user may test the actual performance of the AV (e.g., using the trained AV stack) against any or all variation configurations without having to manually set up configuration changes. In some examples, the user may decide that it is unnecessary to simulate every combination of values for every variable property 1001 of multiple objects in the scene. For example, certain combinations of properties 1001 of one or more objects may not result in a reasonable scenario. The user interface may display additional configuration forms and menus that allow the user to remove invalid or unnecessary combinations of object properties 1001 from the variation configurations.

3A is a flow chart that represents a process by which a system for training a planning model of a movement of a vehicle (such as the system 209 in 2 ) can generate an extended simulation scenario for training an AV stack. 4A presents certain elements of the process in an alternative format. With reference to 3A and 4A the system selects a base simulation scenario from its set of stored simulation scenarios at 301. Simulation scenarios may include data obtained from actual trips of vehicles in the real world, data generated by manual or automated simulation processes or both. The system may select the base simulation scenario, which is performed in response to user input received via a user interface. Alternatively, the selection may occur automatically through processes such as random selection, choosing the next scenario in a ranked order, or applying a set of rules such as one that selects a base scenario that satisfies one or more conditions. The system then generates an extension element for the simulation scenario at 401. Generation of the extension element includes various subprocesses as described below.

• - eine Position, die sich in oder innerhalb eines Schwellenabstandes von der Kreuzung befindet;
• - ein Zeitbereich und eine Position, entlang derer das Fahrzeug einen Spurwechsel durchführt; oder
• - ein Zeitbereich und eine Position, entlang derer das Fahrzeug ein geschütztes oder ungeschütztes Linksabbiegen oder Rechtsabbiegen an einer Kreuzung durchführt.
• Zusätzliche Aspekte des Interaktionszonenauswahlprozesses werden nachstehend im Zusammenhang mit 6 beschrieben.

Optionally, the subprocesses may include identifying an interaction zone within the base simulation scenario (step 302). An interaction zone is a time and distance range in the base simulation scenario into which the system introduces an augmentation element. The interaction zone may include a physical location in the scene, a time in the simulation, or both a physical location and a time. The locations and times may be specific points or areas. In some embodiments, the system may identify the interaction zone as one that a user enters via a user interface. In others, the system may automatically select the interaction zone based on one or more rules. Example rules may include rules to select a time and/or a location that meets one or more conditions, such as:

• - a position located at or within a threshold distance from the intersection;
• - a time range and a position along which the vehicle performs a lane change; or
• - a time range and a position along which the vehicle performs a protected or unprotected left turn or right turn at an intersection.
• Additional aspects of the interaction zone selection process are discussed below in connection with 6 described.

At 303, the system chooses whether to add a new object to the scene or to modify the behavior of an existing actor in the scene. This choice may be received: (a) from a user via the user interface; (b) automatically and randomly; or (c) automatically based on one or more rules. If received via the user interface, the choice may be received in response to a set of options that the system outputs to the user via the user interface. If the system has identified an interaction zone at 302 and if the simulation scenario does not include a suitable object within the interaction zone, the system may require that the choice be a new object because no existing object whose behavior can be modified is available in the interaction zone.

If the choice at 303 is to select a new object, or if the choice at 303 is to modify the behavior of an existing object, and multiple candidate objects are available, then the system may select an object class at 304 to use in the extension element. Example object classes may include, for example, pedestrian, vehicle, cyclist, vegetation, building, and/or other object classes. If the choice at 303 was to modify the behavior of an existing object, then the candidate object classes for selection may be limited to those present in the scene (or interaction zone, as applicable). The selection of the object class at 304 may: (a) be received from a user via the user interface; (b) be automatically and randomly selected by the system; or (c) be automatically selected by the system based on one or more rules. If received via the user interface, the choice may be received in response to a set of options that the system outputs to the user via the user interface.

Once the object class is selected, the system may select one or more classification parameters for the selected object class at 305. Classification parameters are type labels for each object class. The system may store the type labels in a data store with a mapping of each type to a probability that the object is one that matches the type. For example, for the "vehicle" object class, the system may store type labels and mapped probabilities that include [sedan, 0.8] and [truck, 0.2]. (In practice, the system would maintain several additional type labels for this class). The system then uses the probabilities to apply a weighted randomization function to select one of the available types. An example randomization function would be one that calculates the sum of all the weights, selects a random number that is less than the sum, and subtracts the weight of each type from the random number until the system finds a type for which the random number is less than the weight of the type. Other randomization functions can be used, including functions that take other parameters into account.

At 306, the system selects a behavior from a positional distribution of candidate behaviors for the object type along with mapped probabilities of each candidate behavior. For example, for an object that is a bus, which is a type of vehicle, the positional distribution may be [static, 0.8] and [dynamic, 0.2]. The system may then use a randomization function as described above to select one of these behaviors and determine whether or not the bus is moving in the simulation scenario. Behaviors may be dynamic behaviors, such as one or more properties 1001 of a motion, as described above as an example. Alternatively, they may be static properties 1001 of the object, such as a size or position of an occlusion such as vegetation or a building. The system may select a single behavior or multiple behaviors to apply to an object in the extended simulation scenario.

As described above in step 302 in 3A noted, the system may select the interaction zone early in the process. However, if this is not done early in the process, then after the system selects the actor class, classification parameters, and position distribution for the extension element, then at 307 after selecting the extension element (object and behavior), then the system may identify the interaction zone into which the extension element will be introduced, whether by adding a new actor or modifying the behavior of an existing actor. The identification of the interaction zone in this step is performed according to any of the processes described above for step 302 or below.

5A and 5B depict the steps of object class selection, classification parameter selection, and behavior selection using a sample set of candidate actor data. In 5A and 5B The candidate object classes 504 are vehicle, pedestrian, cyclist and vegetation. 5A shows that in response to the selection of the “vehicle” object class, the system then considers the classification parameters and mapped probabilities 505 of [car, 0.5], [truck, 0.2], [bus, 0.2], and [emergency vehicle, 0.1]. Position distributions are shown in 5A not yet known, as they may vary depending on the selected classification parameter. 5B However, shows that after the system selects the "bus" classification parameter, the system can then look at the position distribution for behaviors and mapped probabilities 506 of [static, 0.8] and [dynamic, 0.2] for buses and select one of these behaviors to apply to a bus in the extension element.

In practice, the system may add any number of additional classification parameters, behaviors, or both for any object class. For example, for additional sub-parameters of the "vehicle/car" class, the parameter may include "parked car", which may be associated with various yaw range behaviors that indicate not only whether the parked car remains static or is moving, but also whether the vehicle is parallel to the lane or canted into the drivable portion of the lane. The system may therefore determine any number of behaviors to apply to an object when modifying a base simulation scenario.

With return to 3A and 4A Once the system creates the augmentation element for the simulation scenario at 401, the system applies the augmentation element to the base simulation scenario to create the augmented simulation scenario at 308. To apply the augmentation element, the system adds the object to the base simulation scenario or (if it already exists) modifies the behavior of the object therein to include the selected behavior(s) for the designated object in the interaction zone. Unlike adding the augmentation element, the system leaves the base simulation scenario relatively intact so that training and evaluation (discussed later) can focus on changes in vehicle response that the augmentation element may cause.

3B is a flow chart representing another process by which a system for training a planning model of a movement of a vehicle (such as the system 209 in 2 ) can generate an extended simulation scenario for training an AV stack. 4B presents certain elements of the process in an alternative format. With reference to 3B and 4B at 301, the system selects a base simulation scenario from its set of stored simulation scenarios. Simulation scenarios may include data obtained from actual trips of vehicles in the real world, data generated by manual or automated simulation processes, or both. The system may select the base simulation scenario in response to a user input provided via a user interface. Alternatively, the selection may occur automatically through processes such as random selection, by choosing a next scenario in a ranked order, or by applying a set of rules such as one that selects a base scenario that satisfies one or more conditions. The system then creates an extension element for the simulation scenario at 421. Creation of the extension element includes various subprocesses as described below.

At 322, the system identifies objects in the scene having one or more variable properties. The variable properties 1001 may be configured by a user via a user interface. At 323, the system may determine values to apply to the object's properties 1001 based on a set of defined values or a range or distribution of values defined for the property. The system may determine values to apply to the object's property 1001 based on user-configured parameters for varying the property. The system may apply the values to modify the object's property 1001 to generate the extension element for the simulation scenario. Once the system generates the extension element for the simulation scenario at 421, the system applies the extension element to the base simulation scenario to yield the extended simulation scenario at 308. Aside from adding the augmentation element, the system leaves the base simulation scenario relatively intact so that training and evaluation (discussed below) can focus on changes in vehicle response that the augmentation element may cause.

Once the system generates an augmented simulation scenario, at 311 the system may test the augmented simulation scenario by applying the augmented simulation scenario to the AV stack, optionally over multiple iterations and optionally with modified parameters. To test the augmented simulation scenario, the system applies a planned trajectory of the vehicle to the scene in the augmented simulation scenario. The vehicle's perception system detects the augmentation element in the simulation and the vehicle's motion planning system calculates a continued trajectory in response to the detected augmentation element. The continued trajectory may not change the trajectory, in which case it causes the vehicle to continue along the planned trajectory in the simulation. Alternatively, the continued trajectory may be an alternative trajectory, such as one that ensures that the vehicle avoids movement within a threshold distance of the object in the simulation. Optionally, in the iteration process at 311, the system may access an evaluation data set 411, which is a set of data describing an expected behavior for the vehicle in response to a simulation scenario. The expected behavior may be as simple as an expectation that the vehicle will not collide with another object, or it may include other parameters such as acceleration and/or deceleration limits.

At 312, the system may store details of the simulation, including the augmentation element (object and behavior) and the vehicle's response (calculated continued trajectory), in a simulated vehicle log for further analysis.

The system then stores the extended simulation scenario in a data store at 313. The data store may be that which includes the base simulation scenario (in which case the extended scenario may be used as a new base scenario in the future), a separate data store, or both.

Optionally, at 314, a human operator may label the response of the vehicle in the simulation as a desired response or undesirable response to help train the planning model of a movement of the AV. Alternatively, at 314, if the system has captured an evaluation dataset 411, the system may automatically label the response of the vehicle as desired or undesirable depending on whether the simulated performance of the vehicle meets the expected parameters contained in the evaluation dataset. As yet another alternative, at 314, the system may help facilitate and/or enhance a human labeling process by extracting data from the evaluation dataset 411 and using that data to suggest a label for the vehicle's response, in which case the human operator may either accept the suggested label or enter an alternative label. After the AV stack is trained with the enhanced simulation scenario, the trained model may then be deployed in an AV to operate the vehicle at 315.

The above-discussed and in 3A , 3B , 4A and 4B The process shown can be repeated for additional extension elements, thus allowing massive exploration of the state space by adding a wide variety of extension elements to a base simulation scenario, while keeping the base scenario relatively intact Although the number of potential augmentation elements is potentially very large, however, the system limits processing requirements by restricting the addition of augmentation elements to those that appear in specified interaction zones. This allows the training process to be configurable to focus on specific scene features 1001 selected by the operator of the system for training a planning model of a vehicle's movement, such as intersections, lane change events, left turns, or the like.

As stated above, either before or after selecting the augmentation element, the system defines an interaction zone in the base simulation scenario. The interaction zone includes elements of both position and time at which a new object is inserted or at which the behavior of an existing object is modified to yield the augmented simulation scenario. The position of an interaction zone is typically one that bears a relationship to the planned trajectory of the vehicle. For example, locations of an interaction zone may include lanes through which the planned trajectory of the vehicle passes, lanes that are within threshold distances of the planned trajectory of the vehicle, sidewalks or crosswalks that are within threshold distances of the planned trajectory of the vehicle, intersections that exist along the planned trajectory of the vehicle, or other locations within the scene.

• - eine Position und eine Zeit in der geplanten Trajektorie, bei denen das Fahrzeug ein Spurwechselmanöver implementiert;
• - eine Position und Zeit in der geplanten Trajektorie, bei denen das Fahrzeug ein Linksabbiegen oder ein Rechtsabbiegen implementiert;
• - eine Position und eine Zeit in der geplanten Trajektorie, bei denen das Fahrzeug in eine Kreuzung einfährt; oder
• - eine Position und eine Zeit in der geplanten Trajektorie, bei denen das Fahrzeug sich einer Kreuzung nähert (d. h. einen Schwellenabstand von dieser erreicht).

In some situations, the system may define the interaction zone as one specified by a user through user input in a user interface. In some situations, the system may automatically define the interaction zone in a base simulation scenario using a process such as that described in 6 described. To automatically define the interaction zone, the system may perform a base simulation at 601 by simulating movement of the vehicle along a planned trajectory in the base simulation scenario. While doing so, the system identifies a trigger event at 602. A trigger event is an event of interest that the system identifies as a candidate for additional training data, or that an operator of the system designates as such. Each trigger event includes a start position and/or a start time, and optionally an end position and/or an end time. Trigger events may include, for example:

• - a position and a time in the planned trajectory at which the vehicle implements a lane change maneuver;
• - a position and time in the planned trajectory at which the vehicle implements a left turn or a right turn;
• - a position and a time in the planned trajectory at which the vehicle enters an intersection; or
• - a position and a time in the planned trajectory at which the vehicle approaches an intersection (i.e. reaches a threshold distance from it).

The system makes these determinations by receiving an intent signal from the AV's motion planning system. The intent signal is a communication from the motion planning system that identifies a motion that the AV plans to implement in the simulation.

In some situations, when identifying trigger events at 602, the system may identify multiple candidate trigger events and filter out any trigger events that do not meet one or more specified criteria, such as events with a route length or time that exceeds a specified value. In this manner, the system may help generate interaction zones that are a relatively small segment of the entire base simulation scenario. The filter may also remove trigger events for which the system has already generated a threshold number of extension elements. In this manner, the system may devote processing resources to trigger events that are most required for motion planning model training and avoid using processing resources to train the model on events for which the system already has at least a threshold among training data.

At 603, the system identifies the position(s) of the trigger event (including, for example, start position and end position). At 604, the system identifies the time of the trigger event, which may be a single time or a time window that includes a start time and stop time in the simulation scenario (In this disclosure, “time” does not necessarily require determining time according to a world clock in any particular time zone. Although world time may be used, “time” may also refer to a time position measured with respect to a start time of the simulation, a time measured by a computer clock, or other time). In response to identifying the trigger event while simulating the motion of the vehicle in the base simulation scenario, the system then defines the interaction zone at 605 as a position (or positions) and time (or time window) that are relative to the location and time of the trigger event. trigger event. For example, the system may define the interaction zone as: (a) equal to the locations and times of the trigger event; (b) a range of positions along the planned trajectory that includes the location of the trigger event and a time window that includes the time of the trigger event; (c) including a position (or range of positions) along the planned trajectory that begins a specified distance before the location of the trigger event; or (d) including a time window in the simulation that begins a specified amount of time after the time of the trigger event. Other interaction zone definitions may be used in various embodiments.

As stated above, an extension element comprises an object and one or more behaviors for the object. The selection of behaviors introduces an element of randomness by selecting behavior elements, as discussed above in the discussion of 3A and 4A which helps the system to explore a very large state space and accommodate events that may rarely be encountered in the real world. For behaviors of objects that are actors, in addition to simple behavioral elements such as "remain static" or "are dynamic" (i.e., move), the system can define other behavioral elements such as posture or attitude, acceleration profile, and even "noise" elements that are more difficult for the vehicle's perception system to detect, such as depicting a vehicle with its right turn signal flashing while it continues to move straight through an intersection. These behaviors may include behavioral definitions that follow base definitions of an obstructive extension element, an ambiguous extension element, a deviant extension element, or behavior that conforms to a combination of any of these. Features of these base definitions are described below.

An obstructive extension element is an object with a location that at least partially blocks the planned path of the vehicle. An example of this is in 7 717, in which the vehicle 701 is moving on a road 717 along a planned trajectory 702. A parked vehicle 719 is obstructive because its position is oblique, not parallel to the road, and therefore it is partially within a threshold distance from the centerline of the vehicle's planned trajectory 702. In the augmented simulation, when the vehicle's perception system detects the parked vehicle 719, the vehicle's motion planning system may alter the trajectory of the vehicle 701: (a) to veer slightly to the left to maintain a threshold distance between the vehicle 701 and the parked vehicle 719; and/or (b) to move more slowly when approaching the parked vehicle 719 if the parked vehicle begins moving and veers into the lane in front of the vehicle 701. In various embodiments, an obstructive augmentation element may include any known class of object, such as a vehicle 701, a parking space, a building, or a vehicle. E.g., vehicle, pedestrian, cyclist, animal, vegetation, or even unknown/unidentifiable. The system may include a mapping for each object class with potential behaviors/states along with probabilities of each behavior or state. As an example, potential states of a vehicle may include parked, moving forward, turning left, turning right, accelerating, decelerating, among other states. Potential states of a pedestrian may include examples such as walking into the lane, walking parallel to the lane, facing the lane, facing away from the lane, among other states.

An ambiguous extension element is an object that exhibits a behavior or combination of behaviors that is not common for that class of object, and therefore a perception system of the vehicle is expected to assign substantially equal probabilities to the behavior being one of at least two candidate behaviors. (In this document, “substantially equal” means that the values of the two probabilities are within 10 percent or less of each other). Examples include a combination of behaviors that are inconsistent with each other, such as (i) a vehicle exhibiting a flashing turn signal while continuing to move straight through an intersection; (ii) a parked vehicle exhibiting a flashing turn signal while continuing to remain parked for more than a threshold amount of time; or (iii) an object that randomly changes its classification from a first classification to a second classification (such as changing from pedestrian to unknown). Other examples include behaviors that are not associated with the class of the object, such as vegetation that moves. Other examples include an object that flickers in and out of existence, or that appears for no more than a finite number of cycles in the simulation, or a vehicle that randomly activates and deactivates its brake lights. Each of these states can make one or more properties 1001 of the object ambiguous to the vehicle's perception system.

A different extension element is an object that provides a behavior or combination of behaviors that are both dynamic (ie, result in the object moving) and cause the vehicle's motion planning system to respond by modifying its trajectory. An example of this is shown in 8th , in which a vehicle 801 is moving on a road 817 along a planned trajectory 802. The parked vehicle 819 is deviant because it is swerving from its position and not only moving forward, but it is following a trajectory 822 that crosses both the vehicle's planned trajectory 802 and the road 817. In the extended simulation, when the vehicle's perception system detects that the parked vehicle 819 begins to move along this deviating trajectory 822, the vehicle's motion planning system may alter the trajectory of the vehicle 801 by causing the vehicle 801 to stop until the (previously) parked vehicle 819 completely crosses the road 817, or takes another evasive action. Other deviant behaviors include, for example, movements that violate one or more traffic laws.

In some embodiments, the system may generate extension elements, and it may introduce different categories of extension elements within different segments of the interaction zone. To promote the random generation of extension elements in situations for which the system may require more data, the system may optionally assign weights to different segments of the interaction zone. In addition, it may assign different weights to different categories of extension elements and/or different classes of objects within each segment. The system may then incorporate these distributions into its randomization function when generating objects and behaviors to use as extension elements. An example of this is shown in 9 shown in which the area in front of the vehicle 901 comprises a first interaction zone segment 902 comprising four subregions that cross the road and extend into a cross street. Each subregion is assigned an object behavior distribution, which in this case may be a distribution for the placement of deviant vehicles in each subregion such that randomly generated deviant vehicle behaviors in the interaction zone segment are distributed across the subregions in sets substantially equal to the distributions shown. The area also includes a second interaction zone segment 903 comprising three subregions that cross the road and which in this case correspond to new pedestrian objects. Each subregion is assigned an object/behavior distribution, which in this case may be a distribution for the placement of new pedestrians in each subregion such that randomly generated simulated pedestrians are distributed across the subregions in sets substantially equal to the distributions shown. The area also includes a third interaction zone segment 904 that includes two subregions along the road, and which in this case correspond to static vehicle locations (one in the travel lane and one in a parking lane). Each subregion is assigned an object/behavior distribution, which in this case may be a distribution for the placement of new parked or otherwise non-moving vehicles in each subregion such that randomly generated simulated static vehicles are distributed across the subregions in amounts substantially equal to the distributions shown.

With return to 3A and 3B Finally, in some embodiments, the system at 316 may employ advanced simulation scenarios on board the vehicle while the vehicle is operating in a real-world environment such as a test track. In this case, with reference to 2 the system for training a planning model of a vehicle's motion 209 may be onboard the vehicle and may provide enhanced simulation scenarios to the vehicle's prediction system 203 and/or motion planning system 204. These systems combine the combined data received from the vehicle's perception system 202 with the enhanced simulation scenarios to expose the vehicle to additional scenarios that it may encounter in the real world but has not yet encountered. Example methods for combining real world perception data with simulation data are described in the US Patent Application Number 17/074,807 the disclosure of which is incorporated in its entirety by reference into this document.

The features and functions disclosed above, as well as alternatives, may be combined into many other different systems or applications. Various components may be implemented in hardware or software or embedded software. Various presently unforeseen or unexpected alternatives, modifications, variations, or improvements may be made by those skilled in the art, each of which is also intended to be encompassed by the disclosed embodiments.

• Eine „automatisierte Vorrichtung“ oder eine „Robotervorrichtung“ bezieht sich auf eine elektronische Vorrichtung, die einen Prozessor, Programmieranweisungen und eine oder mehrere physikalische Hardwarekomponenten umfasst, die in Reaktion auf Befehle vom Prozessor sich mit minimalem oder ohne menschlichen Eingriff bewegen können. Durch eine solche Bewegung kann eine Robotervorrichtung eine oder mehrere automatische Funktionen oder Funktionssätze durchführen. Beispiele von solchen Operationen, Funktionen oder Aufgaben können ohne Begrenzung das Betreiben von Rädern oder Propellern, um Fahr-, Flug- oder andere Transporthandlungen zu bewirken, das Betreiben von Roboterliften zum Laden, Entladen, auf Medizin bezogene Prozesse, auf den Bau bezogene Prozesse und/oder dergleichen umfassen. Beispielrobotervorrichtungen können ohne Begrenzung autonome Fahrzeuge, Drohnen und andere autonome Robotervorrichtungen umfassen.

Terminology relevant to the disclosure provided above includes:

• An “automated device” or a “robotic device” refers to an electronic device that includes a processor, pro programming instructions and one or more physical hardware components that can move in response to commands from the processor with minimal or no human intervention. Through such movement, a robotic device can perform one or more automated functions or sets of functions. Examples of such operations, functions, or tasks may include, without limitation, operating wheels or propellers to effect driving, flying, or other transporting actions, operating robotic lifts for loading, unloading, medical-related processes, construction-related processes, and/or the like. Example robotic devices may include, without limitation, autonomous vehicles, drones, and other autonomous robotic devices.

The term “vehicle” refers to any moving form of conveyance capable of carrying either one or more human occupants and/or cargo and powered by some form of energy. The term “vehicle” includes, but is not limited to, cars, trucks, vans, trains, autonomous vehicles, an airplane, aerial drones, and the like. An “autonomous vehicle” is a vehicle having a processor, programming instructions, and powertrain components controllable by the processor without requiring a human driver. An autonomous vehicle may be fully autonomous in that it does not require a human driver for most or all driving conditions and functions. Alternatively, it may be semi-autonomous in that a human driver may be required under certain conditions or for certain operations, or in that a human driver may override the vehicle’s autonomous system and assume control of the vehicle. Autonomous vehicles also include vehicles in which autonomous systems augment the human operation of the vehicle, such as a human-operated vehicle. E.g. vehicles with driver-assisted steering, cruise control, braking, parking and other advanced driver assistance systems.

The term “object,” when referring to an object detected by a vehicle perception system or simulated by a simulation system, is intended to include both stationary objects and moving (or potentially moving) actors, unless specifically indicated otherwise by the use of the term “actor” or “stationary object.”

When used in the context of motion planning of an autonomous vehicle, the term “trajectory” refers to the plan that the vehicle’s motion planning system generates and that the vehicle’s motion control system follows when controlling the vehicle’s motion. A trajectory includes the planned position and orientation of the vehicle at multiple points in time over a time horizon, as well as the vehicle’s planned steering wheel angle and steering wheel angular rate over the same time horizon. A motion control system of an autonomous vehicle consumes the trajectory and sends commands to the vehicle’s steering control unit, brake control unit, accelerator pedal control unit, and/or other motion control subsystem to move the vehicle along a planned path.

A “trajectory” of an actor, which a vehicle’s perception or prediction systems can generate, refers to the predicted path that the actor follows over a time horizon, along with the actor’s predicted velocity and/or the actor’s position along the path at various points along the time horizon.

In this document, the terms “roadtrain,” “lane,” “road,” and “intersection” are all illustrated as examples with vehicles traveling on one or more roads. However, embodiments are intended to include lanes and intersections in other locations, such as parking areas. Additionally, for autonomous vehicles designed to be used indoors (such as automated pickup devices in warehouses), a roadtrain may be a corridor of the warehouse, and a lane may be a portion of the corridor. If the autonomous vehicle is a drone or other aircraft, then the term “roadtrain” or “road” may represent an airway, and a lane may be a portion of the airway. If the autonomous vehicle is a watercraft, then the term “roadtrain” or “road” may represent a waterway, and a lane may be a portion of the waterway.

An "electronic device" or a "computing device" refers to a device that includes a processor and a memory. Each device may have its own processor and/or memory, or the processor and/or memory may be shared with other devices, such as in a virtual machine or container arrangement. The memory contains or receives programming instructions that, when executed by the processor, cause the electronic device to perform one or more operations in accordance with the programming instructions.

The terms "memory,""storagedevice,""computer-readablemedium,""datastorage,""data storage device," and the like each refer to a non-transitory device on which computer-readable data, programming instructions, or both are stored. Unless specifically stated otherwise, the terms "memory,""storagedevice,""computer-readablemedium,""datastorage,""data storage device," and the like are intended to include single device embodiments, embodiments in which multiple storage devices together or collectively store a set of data or instructions, and individual sectors within such devices. A computer program product is a storage device on which programming instructions are stored.

The terms "processor" and "processing device" refer to a hardware component of an electronic device configured to execute programming instructions, such as a microprocessor or other logic circuit. A processor and memory may be elements of a microcontroller, a custom-configurable integrated circuit, a programmable system on a chip, or other electronic device that can be programmed to perform various functions. Unless specifically stated otherwise, the singular term "processor" or "processing device" is intended to encompass both single processing device embodiments and embodiments in which multiple processing devices perform a process together or collectively.

A "machine learning model" or a "model" refers to a set of algorithmic routines and parameters that can predict an output(s) of a real-world process based on a set of input features (e.g., predicting an object trajectory, diagnosing or treating a patient, making an appropriate recommendation based on a user search query, etc.) without being explicitly programmed. A structure of the software routines (e.g., number of subroutines and the relationship between them) and/or the values of the parameters can be determined in a training process that may use actual results of the real-world process being modeled. Such systems or models are understood to be necessarily rooted in computer technology and, in fact, cannot be implemented or even exist in the absence of computational technology. Although machine learning systems use various types of statistical analysis, machine learning systems are distinguished from statistical analysis by the ability to learn without explicit programming and by being rooted in computer technology.

A typical machine learning pipeline may include building a machine learning model from a sample dataset (referred to as a "training set"), evaluating the model against one or more additional sample datasets (referred to as a "validation set" and/or "test set") to decide whether to keep the model and evaluate how good the model is, and using the model in "manufacturing" to make predictions or decisions against live input data captured by an application service. The training set, validation set, and/or test set, and the machine learning model are often difficult to obtain and should be kept confidential. The current disclosure describes systems and methods for providing a secure machine learning pipeline that preserves the privacy and integrity of datasets and machine learning models.

In this document, when relative ordering terms such as "first" and "second" are used to modify a noun, such use is intended to simply distinguish one element from another and is not intended to require sequential order unless specifically stated.

In addition, terms of relative position, such as "front" and "back" or "in front of" and "behind", when used, are intended to be relative to each other and need not be absolute, and refer only to one possible position of the device associated with those terms depending on the orientation of the device.

In a first set of embodiments, a method for generating a scenario for simulating a planning model of a movement of a vehicle is disclosed. The method may be embodied in computer programming instructions and/or implemented by a system comprising a processor. The method includes receiving, from a data store containing a plurality of simulation scenarios, a base simulation scenario comprising features of a scene through which a vehicle may travel. The method includes receiving, from the data store, a simulation variation for an object in the scene, the simulation variation defining a plurality of values for a property of the object. The method further includes adding the simulation variation to the base simulation scenario to yield an extended simulation scenario, and applying the extended simulation lation scenarios to a motion planning model of an autonomous vehicle to train the planning model. The motion planning model simulates the movement of the vehicle along a planned trajectory and iteratively simulates variations of the object based on the multiple values for the property of the object. In response to each simulated variation of the object, the motion planning model selects a continued trajectory for the vehicle, either the planned trajectory or an alternative trajectory, and causes the vehicle to move along the continued trajectory.

Implementations of the first set of embodiments may include one or more of the following optional features. In some examples, the method includes defining the simulation variation by outputting the property of the object via a user interface comprising a display device, and receiving one or more variations for the property of the object via the user interface. The method may further include outputting a revised simulation scenario in which the object exhibits the one or more variations of the property via the display device and storing, in the data store, the one or more variations for the property as a simulation variation. The property may include a dimension, a position, a velocity, an acceleration, or a behavior-triggering distance of the object. In some examples, the method further includes receiving, from the data store, a second base simulation scenario comprising features of a second scene through which a vehicle may travel. The method may include receiving, from the data store, the simulation variation, adding the simulation variation to the second base simulation scenario to result in a second enhanced simulation scenario, and applying the second enhanced simulation scenario to the motion planning model of the autonomous vehicle to train the motion planning model.

In some variations of the first set of embodiments, the method includes receiving, from the data store, a second simulation variation for a second object in the scene, the second simulation variation defining a plurality of values for a property of the second object. The method may further include adding the second simulation variation to the base simulation scenario to yield a second augmented simulation scenario and applying the second augmented simulation scenario to the motion planning model of the autonomous vehicle to train the motion planning model. The motion planning model may iteratively simulate variations of the object and the second object based on the plurality of values for the property of the object and the plurality of values for the property of the second object, and select the continued trajectory for the vehicle in response to each variation of the object or the second object.

In some variations of the first set of embodiments, the method further comprises receiving, from the data store, a second simulation variation for the object in the scene, the second simulation variation defining a plurality of values for a second property of the object. The method may further comprise adding the simulation variation and the second simulation variation to the base simulation scenario to yield the extended simulation scenario. The method may further comprise generating an extension element comprising a second object and a behavior for the second object and adding the simulation variation and the extension element to the base simulation scenario to yield the extended simulation scenario.

In some variations of the first set of embodiments, simulating movement of the vehicle along the planned trajectory includes operating the vehicle on a test track where perception data from one or more vehicle sensors is augmented by simulated variations in the object. In some examples, a variation in the simulated object partially disrupts the planned trajectory of the vehicle and the continued trajectory is an alternate trajectory that keeps the vehicle at least a threshold distance from the object.

In a second set of embodiments, a method for generating training scenario variations is disclosed. The method may be embodied in a scenario variation generation system configured to receive a base scenario with objects in a scene and execute a user interface configured to display data associated with properties of the objects in the scene. The property may include a dimension, position, velocity, acceleration, or behavior-triggering distance of the object. The user interface may be further configured to receive a variation input related to properties of the objects. In response to the user interface receiving a variation input defining a plurality of values for properties of the objects, the scenario variation generation system may store a scenario variation in a data store that simulation scenarios, wherein the scenario variation is based on the plurality of values and is configured to extend one or more of the simulation scenarios.

In some variations of the second set of embodiments, the method further comprises, after receiving input regarding the properties of the objects, displaying, through the user interface, the plurality of values, receiving, through the user interface, a selection including one or more of the values, augmenting the base scenario with the selected values, and displaying, through the user interface, the augmented scenario.

In some variations of the second set of embodiments, the plurality of values comprise evenly spaced values in a range, a Gaussian distribution of values in a range, a uniform distribution of values in a range, or user-configured discrete values. The method may further comprise receiving, through the user interface, a variation input relating to two or more properties of one or more objects, the variation input defining a plurality of values for the two or more properties of the one or more objects. After receiving the input relating to the two or more properties, the method may comprise receiving a selection of values to remove from the scenario variation.

In other embodiments, a system for training a planning model of motion of a vehicle includes a processor, a data store having simulation scenarios, and a memory storing programming instructions configured to cause the processor to train a planning model of motion of a vehicle. The system receives from the data store a base simulation scenario comprising features of a scene through which a vehicle may travel. The system also receives from the data store a simulation variation for an object in the scene, the simulation variation defining a plurality of values for a property of the object. The system then adds the simulation variation to the base simulation scenario to yield an enhanced simulation scenario and applies the enhanced simulation scenario to a planning model of motion of an autonomous vehicle to train the planning model. The motion planning model simulates the movement of the vehicle along a planned trajectory and iteratively simulates variations of the object based on the plurality of values for the property of the object. In response to each simulated variation of the object, the motion planning model selects a continued trajectory for the vehicle, either the planned trajectory or an alternative trajectory, and causes the vehicle to move along the continued trajectory.

Implementations of the disclosure may include one or more of the following optional features. In some examples, the system for training a planning model of motion of a vehicle outputs the property of the object via a user interface comprising a display device and receives one or more variations for the property of the object via the user interface. The system may output a revised simulation scenario in which the object exhibits the one or more variations of the property via the display device and store the one or more variations for the property in the data store as a simulation variation. The property may include a dimension, a position, a velocity, an acceleration, or a behavior-triggering distance of the object. In some examples, the system for training a planning model of motion of a vehicle receives from the data store a second base simulation scenario including features of a second scene through which a vehicle may travel. The system may receive the simulation variation from the data store, add the simulation variation to the second base simulation scenario to result in a second enhanced simulation scenario, and apply the second enhanced simulation scenario to the planning model of motion of the autonomous vehicle to train the planning model. The system for training a planning model of motion of a vehicle may receive from the data store a second simulation variation for a second object in the scene, the second simulation variation defining a plurality of values for a property of the second object. The system for training a planning model of motion of a vehicle may add the second simulation variation to the base simulation scenario to result in a second enhanced simulation scenario, and apply the second enhanced simulation scenario to the planning model of motion of the autonomous vehicle to train the planning model. The system for training a planning model of a movement of a vehicle may iteratively simulate variations of the object and the second object based on the plurality of values for the property of the object and the plurality of values for the property of the second object, and select the continued trajectory for the vehicle in response to each variation of the object or the second object.

The system for training a planning model of motion of a vehicle may receive from the data store a second simulation variation for the object in the scene, the second simulation variation defining a plurality of values for a second property of the object. The system for training a planning model of motion of a vehicle may add the simulation variation and the second simulation variation to the base simulation scenario to yield the extended simulation scenario. The system for training a planning model of motion of a vehicle may generate an extension element comprising a second object and a behavior for the second object and add the simulation variation and the extension element to the base simulation scenario to yield the extended simulation scenario.

In some examples, simulating movement of the vehicle along the planned trajectory includes operating the vehicle on a test track where perception data from one or more vehicle sensors is augmented by simulated variations in the object. In some examples, a variation in the simulated object partially disrupts the planned trajectory of the vehicle and the continued trajectory is an alternate trajectory that keeps the vehicle at least a threshold distance from the object.

In other embodiments, a computer program product is disclosed. The computer program product includes a memory storing programming instructions configured to cause a processor to train a planning model of motion of a vehicle. The computer program product receives from the data store a base simulation scenario comprising features of a scene through which a vehicle may travel. The computer program product also receives from the data store a simulation variation for an object in the scene, the simulation variation defining a plurality of values for a property of the object. The computer program product then adds the simulation variation to the base simulation scenario to yield an extended simulation scenario and applies the extended simulation scenario to a planning model of motion of an autonomous vehicle to train the planning model. The planning model of motion simulates the movement of the vehicle along a planned trajectory and iteratively simulates variations of the object based on the plurality of values for the property of the object. In response to each simulated variation of the object, the motion planning model selects a continued trajectory for the vehicle, either the planned trajectory or an alternative trajectory, and causes the vehicle to move along the continued trajectory.

Implementations of the disclosure may include one or more of the following optional features. In some examples, the computer program product optionally outputs the property of the object via a user interface comprising a display device and receives one or more variations for the property of the object via the user interface. The computer program product may output, via the display device, a revised simulation scenario in which the object exhibits the one or more variations of the property and store the one or more variations for the property in the data store as a simulation variation. The property may include a dimension, a position, a velocity, an acceleration, or a behavior-triggering distance of the object. In some examples, the computer program product receives from the data store a second base simulation scenario including features of a second scene through which a vehicle may travel. The computer program product may receive the simulation variation from the data store, add the simulation variation to the second base simulation scenario to yield a second enhanced simulation scenario, and apply the second enhanced simulation scenario to the planning model of a movement of the autonomous vehicle to train the planning model. The computer program product may receive a second simulation variation for a second object in the scene from the data store, the second simulation variation defining a plurality of values for a property of the second object. The computer program product may add the second simulation variation to the base simulation scenario to yield a second enhanced simulation scenario, and apply the second enhanced simulation scenario to the planning model of a movement of the autonomous vehicle to train the planning model. The motion planning model may iteratively simulate variations of the object and the second object based on the multiple values for the property of the object and the multiple values for the property of the second object, and select the continued trajectory for the vehicle in response to each variation of the object or the second object.

The computer program product may receive from the data store a second simulation variation for the object in the scene, the second simulation variation defining a plurality of values for a second property of the object. The computer program product may combine the simulation variation and the second simulation variation into the base si simulation scenario to yield the extended simulation scenario. The computer program product may generate an extension element comprising a second object and a behavior for the second object, and add the simulation variation and the extension element to the base simulation scenario to yield the extended simulation scenario.

In some examples, simulating movement of the vehicle along the planned trajectory includes operating the vehicle on a test track where perception data from one or more vehicle sensors is augmented by simulated variations in the object. In some examples, a variation in the simulated object partially disrupts the planned trajectory of the vehicle and the continued trajectory is an alternate trajectory that keeps the vehicle at least a threshold distance from the object.

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions.

Cited patent literature

• US17/387922 [0001]
• US17/387927 [0001]
• US17/468600 [0001]
• US17074807 [0052]

Claims (17)

A method of generating a scenario for simulating movement of a vehicle, the method comprising, by a processor: receiving, from a data store containing a plurality of simulation scenarios, a base simulation scenario comprising features of a scene through which a vehicle may travel; receiving, from the data store, a simulation variation for an object in the scene, the simulation variation defining a plurality of values for a property of the object; adding the simulation variation to the base simulation scenario to yield an enhanced simulation scenario; and applying the enhanced simulation scenario to a planning model of movement of an autonomous vehicle to train the planning model, wherein the planning model: simulates movement of the vehicle along a planned trajectory, iteratively simulates variations of the object based on the plurality of values for the property of the object, in response to each simulated variation of the object, selects a continued trajectory for the vehicle, the continued trajectory being either the planned trajectory or an alternative trajectory, and causes the vehicle to move along the continued trajectory. Procedure according to Claim 1 , further comprising defining the simulation variation by: outputting the property of the object via a user interface comprising a display device; receiving one or more variations for the property of the object via the user interface; outputting, via the display device, a revised simulation scenario in which the object exhibits the one or more variations of the property; and storing, in the data store, the one or more variations for the property as a simulation variation. Procedure according to Claim 2 , where the property includes a dimension, a position, a velocity, an acceleration, or a behavior-triggering distance of the object. Procedure according to Claim 1 , further comprising: receiving, from the data store, a second base simulation scenario comprising features of a second scene through which a vehicle can travel; receiving, from the data store, the simulation variation; adding the simulation variation to the second base simulation scenario to result in a second enhanced simulation scenario; and applying the second enhanced simulation scenario to the planning model of the autonomous vehicle to train the planning model. Procedure according to Claim 1 , further comprising: receiving, from the data store, a second simulation variation for a second object in the scene, the second simulation variation defining a second plurality of values for a property of the second object; adding the second simulation variation to the base simulation scenario to result in a second extended simulation scenario; and applying the second extended simulation scenario to the planning model of motion of the autonomous vehicle to train the planning model, wherein the planning model iteratively simulates variations of the object and the second object based on the plurality of values for the property of the object and the plurality of values for the property of the second object, and selecting the continued trajectory for the vehicle in response to each variation of the object or the second object. Procedure according to Claim 1 further comprising: receiving, from the data store, a second simulation variation for the object in the scene, the second simulation variation defining a second plurality of values for a second property of the object; and adding the simulation variation and the second simulation variation to the base simulation scenario to yield the enhanced simulation scenario. Procedure according to Claim 1 , further comprising: creating an extension element comprising a second object and a behavior for the second object; and adding the simulation variation and the extension element to the base simulation scenario to yield the extended simulation scenario. Procedure according to Claim 1 , wherein simulating movement of the vehicle along the planned trajectory comprises operating the vehicle on a test track, wherein perception data from one or more vehicle sensors is augmented by simulated variations of the object. Procedure according to Claim 1 , wherein: at least one variation of the simulated object at least partially disrupts the planned trajectory of the vehicle; and the continued trajectory is an alternate trajectory that keeps the vehicle at least a threshold distance from the object. A system for training a planning model of motion of a vehicle, comprising: a processor; a data store containing a plurality of simulation scenarios; and a memory storing programming instructions configured to cause the processor to train a planning model of motion of a vehicle by: receiving, from the data store, a base simulation scenario comprising features of a scene through which a vehicle may travel; receiving, from the data store, a simulation variation for an object in the scene, the simulation variation defining a plurality of values for a property of the object; adding the simulation variation to the base simulation scenario to yield an extended simulation scenario; and applying the enhanced simulation scenario to a planning model of movement of an autonomous vehicle to train the planning model, wherein the planning model: simulates movement of the vehicle along a planned trajectory, iteratively simulates variations of the object based on the plurality of values for the property of the object, in response to each simulated variation of the object, selects a continued trajectory for the vehicle, the continued trajectory being either the planned trajectory or an alternative trajectory, and causes the vehicle to move along the continued trajectory. System according to Claim 10 , the instructions further configured to cause the processor to define the simulation variation by: outputting the property of the object via a user interface comprising a display device; receiving one or more variations for the property of the object via the user interface; outputting a revised simulation scenario in which the object exhibits the one or more variations of the property via the display device; and storing, in the data store, the one or more variations for the property as a simulation variation. System according to Claim 11 , where the property includes a dimension, a position, a velocity, an acceleration, or a behavior-triggering distance of the object. System according to Claim 10 , the instructions further configured to cause the processor to: receive from the data store a second base simulation scenario comprising features of a second scene through which a vehicle may travel; receive from the data store the simulation variation; add the simulation variation to the second base simulation scenario to result in a second enhanced simulation scenario; and apply the second enhanced simulation scenario to the planning model of the autonomous vehicle to train the planning model. System according to Claim 10 , the instructions further configured to cause the processor to: receive from the data store a second simulation variation for a second object in the scene, the second simulation variation defining a second plurality of values for a property of the second object; add the second simulation variation to the base simulation scenario to result in a second enhanced simulation scenario; and apply the second enhanced simulation scenario to the planning model of the autonomous vehicle to train the planning model, wherein the planning model iteratively simulates variations of the object and the second object based on the plurality of values for the property of the object and the plurality of values for the property of the second object, and select the continued trajectory for the vehicle in response to each variation of the object or the second object. A computer program product comprising: a memory storing programming instructions configured to cause a processor to train a planning model of movement of a vehicle by: receiving, from a data store containing a plurality of simulation scenarios, a base simulation scenario comprising features of a scene through which a vehicle may travel; receiving, from the data store, a simulation variation for an object in the scene, the simulation variation defining a plurality of values for a property of the object; adding the simulation variation to the base simulation scenario to yield an extended simulation scenario; and applying the extended simulation scenario to a planning model of movement of a vehicle nomen vehicle to train the planning model, wherein the planning model: simulates movement of the vehicle along a planned trajectory, iteratively simulates variations of the object based on the plurality of values for the property of the object, responsive to each simulated variation of the object, selects a continued trajectory for the vehicle, the continued trajectory being either the planned trajectory or an alternative trajectory, and causes the vehicle to move along the continued trajectory. Computer program product according to Claim 15 , the instructions further configured to cause the processor to define the simulation variation by: outputting the property of the object via a user interface comprising a display device; receiving one or more variations for the property of the object via the user interface; outputting a revised simulation scenario in which the object exhibits the one or more variations of the property via the display device; and storing, in the data store, the one or more variations for the property as a simulation variation. Computer program product according to Claim 16 , where the property includes a dimension, a position, a velocity, an acceleration, or a behavior-triggering distance of the object.

Images