BEHAVIOR
ISAT User's Guide Table of Contents
Contents
Behavior
The ADO behavior is derived from a sophisticated autonomous driver model that exhibits several driving behaviors similar to those exhibited by human drivers. Once an ADO is placed in a scenario, it will travel along a random navigation path in the road network while following all the rules of the road and interacting with other ADOs and the simulator driver. The ADO contains an extensive set of dials and buttons that allows the orchestration of complicated events, despite the highly autonomous nature of its behavior.
The remainder of this section describes ADO behavior in detail. The description is broken down in many sections. First, the overview covers general aspects of ADO’s, and then is followed by sections that focus on specific driving behaviors. Keep in mind that at the time of this writing, the driver model used by the ADO is still evolving through the addition of new behaviors, and the fine- tuning of existing behaviors. As a result, the description focuses on general principles and avoids specific implementation details.
Overview
An ADO can be initialized as a random navigator or given a specific path to follow. When initialized as a random navigator, the ADO builds a path by using its start position as the beginning of a path and then adding intersections and roads. The direction taken when crossing an intersection is selected at random. When initialized with a pre-specified path, the ADO will follow that path and, once it reaches the path's end, it will become a random navigator. In either case, when the term path is used in this section, it refers to the current path of an ADO independent of how this path was defined.
The ADO will use its turn signals as necessary when performing lane changes and turns. In addition, the brake lights will turn on when an ADO decelerates at a rate that would require the use of brakes. At this point ADOs will not use their horns, although they can be forced to produce sound effects through their dials.
An ADO can be associated with various SOL objects, each of which have different physical properties, such as dimension or engine characteristics. In order to provide realistic movement when turning, braking, and accelerating, a multi-body dynamic model is used to simulate the motion of the vehicle. Use of a realistic dynamic model also implies that objects controlled by an ADO cannot have supernatural performance. This is in contrast to DDOs whose speed is computed kinematically, allowing it to achieve any specified performance.
The formalism used for modeling the ADO's behavior is designed to accommodate concurrent implementation of goal seeking. In effect, all behaviors are active at the same time, but only the most important ones are used to guide the vehicle. This allows the ADO to react seamlessly to new circumstances by exhibiting the behaviors as dictated by the current conditions. Currently, the behaviors included in this model include Following, Lane Tracking, Free Drive Speed Control, Lane Change, and Intersection Navigation.
Following
The algorithm currently used by ADOs for following other vehicles is a simple controller that maintains some distance behind a lead vehicle. The actual value of this distance varies between ADOs and can vary from time to time within an ADO through a randomization function utilized to provide variation in traffic. Input parameters can also be used to modify the actual value of the target following distance. In addition, it can be overridden through buttons and dials.
The actual controller responsible for maintaining the distance is tuned aggressively so that vehicles will react quickly when their desired distance is disturbed. This is to ensure that vehicles do not collide with each other or with the simulator driver. However, it is still possible to have collisions if vehicles are forced to change their speed drastically or if their paths are obstructed in a way that makes stopping in time impossible. At the same time, the aggressiveness of the controller often leads to low-frequency oscillations when the speed of a car within traffic changes for whatever reason. To some degree, this oscillation is similar to spring-like oscillations observed in real traffic patterns.
Currently ADOs will not react in any manner to a DDO.
Lane Tracking
The lane tracking behavior is responsible for steering control. The ADO will track the current lane by using a simple steering controller that is tuned to minimize lane incursions during sharp turns. In general, the ADO will track the center of the lane plus or minus a small random perturbation for variability. The controller also attempts to keep the whole vehicle body within the lane boundaries at all times.
Free drive speed control
The speed at which an ADO travels through the network when not following another vehicle is controlled by many factors, including the type of road, the posted speed limit, the road's curvature, and external commands through buttons and dials. In general, if no speed limit is posted, the ADO first computes an estimate of the current speed limit based on the type of road. For example, when on an interstate, a 65-mph speed limit is assumed. If a speed limit sign is passed, the ADO will obey the speed limit and remember it until the next intersection. Finally, the ADO will use the curvature of the road to compute an upper bound on its velocity. The upper bound is computed by calculating the maximum speed around the curve that would expose the vehicle to no more than a threshold lateral acceleration. The actual threshold varies depending on the input parameters, but, in general, it cannot exceed the traction limit of the dynamic model. A typical value is 0.25 Gs.
Once all speeds have been computed (i.e., road default, speed limit, curvature), the smallest is used to guide the vehicle after taking into account the setting of the TargetVelocity dial. Figure 5-51 illustrates the block diagram used for calculating speed control. The illustration is focused on the Free Driving Speed Control logic, but does include the logic used to combine velocity control signals from other behaviors and external inputs.
Lane Change
The ADO looks for opportunities to perform lane change maneuvers. Currently, ADOs change lanes for various reasons. It changes lanes to stay on its path, and it changes lanes to the left if it encounters a slower vehicle in front of it. However, it only changes lanes if slower vehicle’s velocity is less than 90% of the ADO’s velocity. On multi-lane roads, ADOs try to drive in the right lane, although they will change lanes when conditions necessitate traveling in another lane. On a highway, an ADO will change lanes to yield to merging traffic. Finally, an ADO changes lanes due to an external command from the user. This command forces the ADO to change lanes regardless of its current path.
An ADO is relatively intelligent in how it performs lane changes. For example, if an ADO has to turn right at the next intersection and there is a slow moving vehicle in front of it, the ADO will only change lanes to pass if there is enough distance to the intersection to move back into the right lane to make the turn at the intersection. In addition, an appropriate gap must exist between vehicles in the target lane before a lane change maneuver is initiated. The lane change behavior acts dynamically. It continuously re-evaluates the current situation and, if conditions change enough, a lane change maneuver can be aborted.
The intersection navigation logic used by the ADO is designed to accommodate most types of intersections encountered in actual road networks. The general principle used for intersection navigation is to first identify the intersection corridor that will be used to traverse the intersection, then find all vehicles whose corridors intersect the ADO's corridors. Having found the other conflicting vehicles, the ADO uses the rules of the road, including any traffic signs or lights to prioritize all vehicles. At any given time, all vehicles other than the one with the highest priority will stop at the designated hold offset, typically indicated by a solid white line. Once the highest priority vehicle has cleared the part of the corridor that intersects the other corridors, the vehicle that was second in priority becomes the highest priority and proceeds.
It often happens that according to the rules of the road two vehicles have similar priorities, in other words it is not clear which one should go first. When this happens, a random selection is made among the equal-priority vehicles for who will be first. This coordination requires communication between vehicles to ensure that all have a consistent view of who has the right of way. The problem is that given N ADOs trying to negotiate an intersection, this approach requires N2 messages. To avoid this explosion in communication, the intersection navigation logic utilizes a single controller that uses the same decision-making process to explicitly assign priorities to all ADOs. The single controller approach reduces the messages to 2*N, (N messages for the ADOs to communicate their path and another N messages for the controller to send back their priorities), thus minimizing the need for vehicles to communicate with each other. Although this is a centralized approach, the algorithm used still depends on simulating a distributed decision-making typical of real life.
Another challenging complication in intersection navigation is integrating the simulator driver in the traffic. Whereas ADOs can coordinate with each other by declaring their intended path and then obeying the controller's priority assignment, the simulator driver does neither. To address this problem, there is a specialized coordinator, called the Driver Mirror, which is responsible for looking at the simulator driver placement and turn signals and trying to predict the corridor followed by the driver. This information is then communicated to the rest of the ADOs for consideration in their decision-making. As far as priority assignment, because there is no way to tell the driver what to do, the ADOs have explicit logic to deal with the simulator driver. This involves computing the priority of the driver using a similar method as other ADOs, but then acting somewhat different
- When the driver is the highest priority vehicle, ADOs yield to it as usual.
- When the driver has equal priority as other ADOs, the driver always wins the toss.
- When the driver has a lower priority than the other ADOs, the highest priority ADO proceeds as usual.
To ensure that there are no deadlocks (for example, when the ADOs think that the driver is the highest priority, but the driver thinks that another ADO should proceed); the ADOs will use a time- out value for how long to wait. If the time-out expires, the ADOs get new priorities that have the driver at a lower priority level.
To ensure that there are no collisions if the driver decides to move after an ADO has begun crossing the intersection, each ADO uses a forward-looking cone to detect vehicles immediately ahead of it. If the driver appears in that cone, the vehicle stops until the cone area clears.
The intersection navigation logic runs concurrently with other behaviors. If other behaviors dictate a slower speed, then that speed is selected. That way, when multiple vehicles are queued on an intersection, the follow logic of all vehicles but the first would override any intersection navigation commands, thus stopping the vehicle behind the queue leader.
Keep in mind that the intersection navigation logic is continuously being updated to enhance its computation performance and to fix problems that arise when new types of intersections are added to the NADS tiles.
External Commands
During execution, the ADO can be instructed to perform certain actions through buttons and dials. They are listed below along with their definitions.
| ChangeLaneLeft | This parameter causes the ADO to change lanes to the left. The ADO will not change lanes if it is inside an intersection. When this button is pushed, the ADO does not check the lane for gap acceptance. It is up to the user, to guarantee that left lane is clear of traffic. |
| TurnLeft | This parameter causes the ADO to turn to the left-most road at the next intersection. |
| TurnRight | This parameter causes the ADO to turn to the right-most road at the next intersection.. |
| TargetVelocity | If specified, the ADO tries to achieve this velocity whenever possible. The ADO ignores speed limits, but does not ignore road curvatures. |
| ForcedVelocity | If specified, the ADO tries to achieve this velocity as quickly as possible. The ADO ignores speed limits and road curvatures. |
| AudioState | When set, the ADO continuously generates the specified sound(s). The sound will only be audible on the NADS. |
| VisualState | When set, the ADO continuously activates the specified light(s). |
