This article is part of the Open-World Player Vehicle Driving series. It follows P5, which discussed GPS, route life cycles, and dynamic replanning. P5 answered where the vehicle should go and how a route remains valid while the road world changes. This article asks a different question: when two vehicles have the same destination and the same road sequence, why do they still differ in speed, following distance, lane acceptance, waiting behavior, and risk tolerance?
The central claim is: the route determines which road context the vehicle should follow; driving strategy determines behavioral preference within that route context; local avoidance determines which actions are geometrically feasible. Strategy inputs include driving ability, behavioral tendency, vehicle state, and current context. Strategy results can operate only inside the hard boundaries supplied by missions, traffic rules, local geometry, and vehicle capability. The final motion is still produced by vehicle tasks, type-specific executors, and physics.
This article is based on source-reading notes related to GTA5. Public names are anonymized. The article distinguishes direct code evidence, architectural abstractions derived from call relationships, and migration proposals. P7’s local avoidance geometry and P8’s executor and physics seam are deliberately left for later articles.
Introduction: The Same Route, Different Driving Behavior
Previous article: Open-World Player Vehicle Driving P5: How Player Goals Become Navigation — GPS, Route Life Cycle, and Dynamic Replanning
Imagine two vehicles leaving the same location for the same destination. The road graph is identical and the route contains the same road sequence: leave the current segment, cross the next junction, follow the arterial road, and turn toward the destination area. From the navigation layer, there is no difference between the two vehicles.
Their behavior can still diverge:
- one begins braking earlier, leaves a larger gap, and abandons a lane change when another vehicle approaches;
- another maintains a higher approach speed and brakes only when the stop condition becomes clear;
- one keeps a larger buffer when the vehicle ahead slows down;
- another searches for a gap earlier and accepts a smaller, still valid interval;
- one changes its risk response after repeated collisions or road hazards;
- another changes its speed profile even though the route itself is unchanged because the mission or driver context has changed.
Calling all of this randomness cannot explain stable behavioral tendencies. Calling all of it “personality” can also lead to an unsupported assumption: a permanent manager owns the behavior of every vehicle. A more useful runtime model is:
Route and target context
↓
Driving policy query
↓
Traffic context and mission constraints
↓
Local candidate and execution parameters
↓
Vehicle executor
The strategy layer does not move a vehicle to a coordinate and does not own the global route. It changes how the vehicle chooses among permitted alternatives. This is the boundary between P5, P6, P7, and P8: P5 owns route life cycles, P6 modulates behavior, P7 evaluates immediate geometry, and P8 turns the accepted intent into executor output and physical motion.
Players rarely see risk parameters directly. They see whether traffic feels cautious, hesitant, or assertive. For AI vehicles, these differences shape local traffic flow. For player vehicles, related states are more likely to appear as traffic warnings, risk observation, assistance, or statistics. The two paths may share road context, but they do not share one command chain.
1. The Route Provides a Planned Corridor; Strategy Changes the Trade-Off
P5 established that a route is not a static polyline. The vehicle maintains a consumable path result across target state, road data, junction context, and route life cycle. The route layer handles global reachability and road sequence: which road connections can bring the vehicle toward the target and which junction relationships form a usable path.
Driving strategy handles a different problem. Even after the planned corridor is known, the vehicle must decide:
- how much speed to retain while approaching a junction;
- how much distance to preserve behind the vehicle ahead;
- whether to accept a usable but narrow lane-change interval;
- whether to slow down, wait, or continue when right of way is uncertain;
- when to favor the target lane if several lanes are compatible with the route;
- how to price waiting against progress when traffic blocks the intended movement;
- whether a degraded vehicle state should reduce the strength of the intended behavior.
These decisions do not replace the route and do not generate the final steering angle. They are behavioral preferences and evaluation biases applied to route execution.
If the route layer also owns cautiousness and aggressiveness, it becomes responsible for road topology, traffic behavior, and driver inputs at the same time. If the strategy layer writes physics directly, it bypasses the executor seam and cannot explain why the same abstract intent needs different motion rules for a car, boat, aircraft, or train.
A Commonly Confused Scenario
A vehicle is following an arterial road and encounters a slower vehicle. The route is valid and the target has not changed. A conservative policy may reduce speed and preserve distance; an assertive policy may evaluate an adjacent lane earlier; a context with high risk may assign a larger penalty to lateral movement. The route layer has not changed. The local task and executor still own the immediate action.
2. Driver Personality Is Better Described as an On-Demand Policy Query
From the currently traced call relationships, several driving tasks query ability, aggressiveness, and traffic-context parameters on demand, and the calling tasks consume the results. This article uses DriverPolicyCalculator as a public alias for that group of policy-query responsibilities. The alias does not claim that the source contains a class with that name or that it is the only calculation entry point.
The important property is that the query responsibility can remain lightweight while its inputs may contain several contextual layers. A “near-stateless query” here means only that the traced calculation responsibility does not own driver identity, route progress, or mission life cycle. It does not prove that no internal cache exists elsewhere. Historical information can remain in the caller or in a context object and be supplied to the next query.
This differs from giving every vehicle a permanent policy component. Such a component would introduce additional questions about creation, modification, control transfer, distant-vehicle retention, and reconstruction. If the source evidence supports a shared query surface, it should not be expanded into a persistent manager or global traffic personality table.
Why a Lightweight Query Can Produce Stable Behavior
Stable behavior comes from stable inputs, not necessarily from a mutable state held inside the query function. If ability and aggressiveness are supplied by durable driver or model data, and the vehicle context supplies current traffic information, repeated queries can return a stable range of results. When history is required, the history can be maintained by driver intelligence, vehicle intelligence, or player state and supplied as an input to the next query.
The result is reusable across tasks. Cruise, junction handling, following, and lane-change preparation can ask for policy values without duplicating the same personality calculation. The task still owns its phase, route, and completion conditions; policy only supplies modulation values.
3. Where Strategy Inputs Come From: Defaults, Overrides, and Context
Driving strategy should not be reduced to a single Aggressiveness field. The inputs can be separated into durable defaults, explicit overrides, and short-lived contextual values.
3.1 Durable Defaults
Driver or model data can provide stable tendencies such as ability, risk tolerance, rule compliance, or response smoothness. These are priors for the policy query, not current-frame commands. Keeping them stable gives behavior temporal continuity.
3.2 Explicit Overrides
From the call relationships, task- or state-related policy overrides can be abstracted as an additional input source. They may come from a mission requirement, a character state, a vehicle context, or a temporary correction to the default ability value. An override changes the current input within a bounded range; it does not rewrite the driver’s durable identity.
3.3 Contextual Values
Junction distance, traffic signal state, vehicle-ahead speed, road width, adjacent-lane state, current route segment, and highway context can affect how the same ability and aggressiveness values are interpreted. These values have a short life cycle and should not be written back into the permanent driver profile.
3.4 Vehicle-Side Approximation
Some distant or simplified traffic entities may not have a complete driver object. A vehicle-side context can supply approximate policy input so that the vehicle remains behaviorally compatible at a lower cost. This is an approximation path, not proof that the vehicle owns a complete driver intelligence object.
Defaults, overrides, and context should not be reduced to one universal priority stack. Different parameters may merge differently: an explicit override may replace a default, a value may be clamped to a range, a mission may impose a direct limit, or a context value may participate only while a condition is active.
Default driver input
+ task override
+ context modifier
+ vehicle limit
↓
Effective policy parameters
4. What Strategy Outputs: Preferences, Soft Limits, and Candidate Evaluation
The strategy layer turns behavioral tendencies into parameters that downstream tasks can consume. Its outputs can be grouped into behavior preferences, soft limits, and candidate-evaluation weights. Traffic rules, mission restrictions, local geometry, and vehicle capability remain external hard boundaries.
Soft Limits: The Driver’s Preferred Operating Range
Soft limits may express a preferred speed range, observation lead time, buffer distance, and waiting cost. A conservative policy usually requests more margin. An assertive policy may reduce the weight of some soft costs, but it cannot bypass a red light, a forbidden area, a collision boundary, or a vehicle capability limit.
A soft limit is not a control quantity. A request for a lower approach speed is not a brake-pedal value. The executor still calculates braking from current speed, slope, grip, target point, and vehicle state.
Preference Bias
A preference can affect lane preference, target direction, following distance, or willingness to wait. It does not directly choose the action; it changes the evaluation of available alternatives.
Candidate-Evaluation Weights
Traffic tasks often compare several temporarily possible choices. Strategy can supply risk penalties, progress preference, lateral-movement cost, or waiting cost. Candidate generation and geometric validation remain local-task responsibilities.
| Policy result | Type | Final owner or excluded responsibility |
|---|---|---|
| Following-distance bias | Preference | Final braking is interpreted by the executor |
| Junction stopping tendency | Preference | Signal phase belongs to the traffic system |
| Lane-change acceptance | Evaluation weight | Collision geometry belongs to P7 |
| Speed bias | Soft limit | Vehicle capability belongs to executor and physics |
| Warning or horn tendency | Behavior preference | Actual presentation belongs to its consumer |
| Risk penalty weight | Evaluation weight | Candidate generation belongs to P7 |
This is the authority boundary of P6: strategy can change trade-offs, but it cannot turn an infeasible candidate into a feasible one.
5. Why the Same Junction Produces Different Decisions
A junction makes policy differences visible. The route tells the vehicle which junction it must cross; the traffic system supplies right-of-way context; the vehicle task approaches the stop line and manages speed. Strategy changes the timing and margin used during approach, waiting, and recovery.
Conservative Policy
A conservative policy begins observation earlier, prepares to slow sooner, and preserves more distance when right of way is uncertain. It may enter a low-speed state before the final stop condition is confirmed. The traffic signal remains owned by the junction system; policy only affects how the vehicle approaches and waits.
Baseline Policy
A baseline policy balances route progress, traffic rules, and moderate margins. It provides a reference for testing because special behavior cannot be evaluated without a stable baseline.
Assertive Policy
An assertive policy assigns greater value to progress and time cost. It may maintain a higher approach speed, evaluate a lane-change gap earlier, or reduce waiting preference inside the allowed range. It still cannot bypass local geometry or vehicle capability checks.
Policy differences should not become frame-to-frame noise. Stable inputs and explicit context should produce stable ranges, while short-term variation should come from road context rather than an uncontrolled random source.
6. How Policy Enters Vehicle Tasks Without Crossing the Executor Boundary
P5’s route holder maintains route life cycle. P6 provides modulation values for route execution. P7 owns local geometric evaluation. P8 owns type-specific execution and the physics seam.
Route holder
↓ road segment, junction and target context
Driving policy query
↓ speed bias, distance preference, risk weight
Local traffic task
↓ local target and execution conditions
Vehicle executor
↓ control quantities
Physics feedback
The arrows describe information consumption, not necessarily synchronous calls. The implementation may use task fields, shared context, query helpers, or events. The public article should preserve this level of abstraction rather than turn an inferred data relationship into a definite call sequence.
P6 can change preferred speed range, following-distance bias, candidate-evaluation weights, waiting cost, and mission-stage behavior. It does not own route validity, signal phase, collision geometry, final steering or throttle values, rigid-body state, network authority, or control-source transfer.
7. Policy Inputs and Driver Ability Are Different Parameters
Ability and aggressiveness are often compressed into a single “driving level”, but they affect different questions.
Ability affects whether a behavior can be executed consistently. A lower-ability driver may require more stopping margin, smoother speed changes, or lower candidate-switch frequency. Ability does not mean simply faster or slower.
Aggressiveness affects the trade-off between progress, time, distance, and risk. A highly capable but conservative driver may be slower than a less capable but highly assertive driver. One difference concerns execution stability; the other concerns accepted cost.
| Ability | Aggressiveness | Possible behavior |
|---|---|---|
| High | Low | Stable, deliberate, large margins |
| High | High | Assertive progress with coherent actions |
| Low | Low | Slow, cautious, long waiting periods |
| Low | High | Aggressive choices with unstable corrections |
Vehicle capability is a separate input. A driver may correctly identify a route opportunity while the vehicle’s current grip, braking state, or load prevents continued progress. Vehicle intelligence and the executor provide that limit; policy input cannot assume that the vehicle can always satisfy the preferred behavior.
8. Risk Is a Set of Contextual Judgments, Not a Global Switch
“Reckless driving” is often represented as bReckless = true. That can work as a display or statistics label, but it cannot carry the meaning of traffic violations, near misses, route deviation, collision history, and highway context at the same time. A risk model should distinguish source, observer, duration, and consumer.
Risk Sources
Risk may come from a red light, wrong-way travel, road-edge contact, sudden braking ahead, a near miss, a collision, wheel slip, highway context, or a mission that emphasizes approach speed. These sources do not imply the same response.
Risk Observer
In the traced call path, some road-risk states are written on the player-information side. This article calls those player-side observation states PlayerDrivingContext. They do not represent an AI personality object and do not automatically enter AI policy calculation.
The states may be consumed by player feedback, statistics, or other systems; the exact consumer must be confirmed through call sites. Player risk observation and AI policy can share classifications, but they remain different runtime paths.
Duration and Consumer
Some risk states are instantaneous events, such as a near miss or horn trigger. Others persist for a short window, such as a highway context. Long-term statistics have another life cycle. A UI label, a mission condition, and an executor limit need different precision and ownership.
9. Player Risk Observation Must Remain Separate from AI Policy
AI vehicles use policy parameters to choose automated speed, spacing, waiting, and local behavior. A player vehicle receives its main command source from player input. The system can still observe road risk, collision history, near misses, and traffic-rule context, but observation must not replace the player’s command.
AI vehicle: policy query → driving task → local execution
Player vehicle: player input → player control chain
↓
risk observation
| Path | Primary responsibility | Submits driving command? |
|---|---|---|
| AI policy query | Modulates automated driving behavior | Indirectly |
| Player risk observation | Records road risk and events | No |
| Player input chain | Submits player driving intent | Yes |
The paths share road context and some risk categories, but they do not share one command submitter. P4 covers control-source handoff; P6 only defines risk observation as an independent path.
Near Misses
A near miss is not the same as a collision. A runtime may detect high closing speed, a short-lived spatial overlap risk, or rapidly changing relative position without actual contact. In migration and verification, the semantic requirements may include thresholds, spatial relations, deduplication, and time windows. Collision prediction remains P7; damage caused by physical contact belongs to P8 or a later damage article.
10. How Strategy Affects Signals, Following, Lane Changes, and Horns
Signal Response
Policy can affect approach speed, preparation distance, and waiting tendency. The signal phase and right-of-way state remain owned by the traffic system.
Following Response
Policy can affect desired distance, speed matching, and smoothing preference. The executor still calculates the final braking response from vehicle state.
Lane-Change Response
Policy can affect waiting cost, route-preservation preference, and the penalty assigned to lateral movement. It does not generate the geometric lane-change curve or bypass collision checks; those responsibilities belong to P7.
Horns and Warnings
Policy can affect the tendency to request a warning. The traffic context determines whether a trigger is meaningful, while the presentation system controls playback and timing. A horn request is not a route change or a physical control command.
11. Driving Strategy and Local Avoidance Are Adjacent but Different
Both layers discuss distance and risk, but they answer different questions.
Policy asks whether the driver is more willing to wait, how much time cost matters, how much spacing is preferred, and how strongly a candidate should be penalized. Local avoidance owns obstacle scanning, collision prediction, road-boundary checks, and geometric candidate generation. P7 will cover those details.
If policy stores local avoidance results, it begins to own geometry and recovery state. A cleaner boundary is for policy to provide risk weight, spacing preference, and time cost while the local task creates and consumes its own avoidance result within its own life cycle.
An upstream layer may provide preferences; a downstream layer applies hard checks and type-specific interpretation. Influence does not imply life-cycle transfer.
12. Driving Strategy and Physical Execution
Policy output should not be mapped directly to rigid-body control quantities. It provides interpretable behavior parameters; the executor interprets them within the capability and kinematic limits of the vehicle. The same policy input may therefore be shared across vehicle types without producing one shared control law.
Slip, wet surfaces, damage, load, tilt, and collision feedback can reduce the effective control strength. Policy influences the desired behavior; executor and physics provide feasibility feedback. If the target cannot be satisfied for a sustained period, the vehicle task may reduce speed, select a new local target, or report the failure to the route or mission layer. Recovery algorithms are outside P6.
13. One Route, Three Driving Configurations
To isolate policy variables, assume three vehicles use the same vehicle type, the same road sequence, and the same initial traffic snapshot. Only the driver defaults and policy overrides differ. Their local targets and speed curves may diverge after execution begins, while route ownership remains unchanged.
Configuration A: Conservative
The policy requests a larger following distance, lower approach speed, higher lane-change waiting cost, and earlier stop preparation. If the target lane is temporarily unavailable, the vehicle is more likely to wait for another opportunity.
Configuration B: Baseline
The baseline balances progress, traffic rules, and moderate margins. It acts as the reference configuration for testing whether assertive or conservative values actually changed behavior.
Configuration C: Assertive
The policy assigns higher value to progress and lower waiting cost within the allowed range. The vehicle may evaluate the target lane earlier and maintain a higher approach speed. Local geometry and executor limits still apply. If the gap is not feasible, the policy can continue waiting or provide blockage and reevaluation information to the route holder; the route owner decides whether a replanning request should be submitted.
The three vehicles share the target, road graph, route, junction state, and task interface. They differ in policy input, candidate evaluation, local-target timing, and the movement produced by their executor. This is why three route systems are unnecessary.
14. Failure Design: A Centralized Object with Too Many Responsibilities
Failure 1: Policy Owns the Route
If policy stores target, route, local progress, and driving style together, every route update must synchronize with the policy object. Control transfer, distant-vehicle reduction, task replacement, and reconstruction become harder. Route life cycle should remain with the route task or navigation holder.
Failure 2: Policy Writes Control Quantities
Writing throttle, brake, and steering directly from aggressiveness bypasses vehicle-type executors and physical feedback. The policy should return preferred speed, risk weight, spacing, and candidate bias; the executor interprets them.
Failure 3: Global Mutable Policy Table
If all vehicles share one mutable table, a temporary mission override or player risk state can leak into unrelated vehicles. Default inputs, individual overrides, and contextual modifiers should remain distinguishable.
Failure 4: One Boolean for Every Risk
bReckless may be useful as a presentation label, but it cannot carry signal state, near-miss events, route deviation, collision history, and highway context at once. Consumers require different precision and life cycles.
Failure 5: Player Risk Is Treated as AI Driving
Player risk observation can record road state without replacing player input. The observation path and command path must remain distinct.
15. Source Evidence: Locating the Policy Responsibility
Names containing Driver, Personality, or Traffic can be misleading. A better reading method is to inspect four kinds of evidence:
- Input providers — which objects supply ability, aggressiveness, vehicle state, and road context?
- Result storage — does the function return values, or does a task store them across a phase?
- Call timing — which task or update path decides when the query runs?
- Output consumers — do the values enter speed limits, stopping distance, lane evaluation, warnings, or player statistics?
Only after these relationships are stable should the result be described as a policy-query responsibility. Direct code evidence supports statements about parameters, calls, and return values. Architectural abstraction should use “can be observed” or “can be abstracted”. Migration design must be marked as a proposal.
16. Policy Diagnostics: Do Not Inspect Only the Final Position
A strategy defect is often mistaken for an abnormal final movement result. A diagnostic record should include:
Policy Query
├ Driver / Vehicle Context
├ Route Segment
├ Traffic Context
├ Default Inputs
├ Temporary Overrides
├ Policy Outputs
├ Consumer Task
└ Effective Time / Version
Check the source of ability and aggressiveness, the validity of vehicle-side approximation, the lifetime of task overrides, and whether the downstream task consumed the new value. Final movement is also affected by P7 safety checks and P8 executor and physics feedback, so the diagnostic chain must continue beyond the policy query.
17. Policy Life Cycle: Query, Apply, Invalidate, Recover
The query may be lightweight, but its inputs and outputs still have life cycles:
Context established
↓
Read defaults and overrides
↓
Calculate current policy values
↓
Apply to task or local execution
↓
Receive execution feedback
↓
Release temporary modifiers
Context must be invalidated when the driver, vehicle, route segment, control source, or mission changes. A temporary risk window or mission override must not survive into the next control context. During player takeover, old AI policy caches must not be treated as the player’s command source.
18. Compatibility Across Vehicle Types
Policy can share behavioral semantics while executors retain vehicle-specific motion rules.
| Vehicle | Shared policy meaning | Type-specific interpretation |
|---|---|---|
| Car | Progress, stopping tendency, spacing | Steering, braking, traction |
| Boat | Target keeping, propulsion preference, risk weight | Rudder, propulsion, water resistance |
| Aircraft | Direction, speed, risk trade-off | Attitude, thrust, flight envelope |
| Helicopter | Target keeping, approach and hover preference | Rotor, lift, attitude stabilization |
| Train | Speed, braking, mission phase | Track constraints, consist, braking distance |
If policy emits a wheel angle or brake percentage, it becomes tied to a car. If it emits progress preference, desired spacing, and risk cost, each executor can interpret the same semantic contract within its own limits. Shared semantics do not mean shared control laws.
19. Migration Guidance: Preserve Boundaries, Not Source Types
This article does not prescribe engine APIs, component layouts, or a completed implementation. A migration should preserve:
- route ownership of target and route life cycle;
- policy queries that read durable inputs and temporary context;
- outputs represented as preferences, soft limits, and evaluation weights;
- local avoidance ownership of geometric prediction and candidates;
- type-specific executor interpretation;
- separate player risk observation and AI driving command paths;
- explicit expiration for temporary overrides;
- diagnostics that record input, output, consumer, and feedback.
The central design principle is that policy is a modulation layer, not the owner of the entire vehicle runtime.
20. Interim Summary: Strategy Changes Trade-Offs
Why can the same global route produce different behavior? Because the route describes which road context the vehicle should follow, while it does not decide how each driver trades speed, spacing, waiting, lane changes, and risk. Policy converts stable ability and tendency inputs plus current context into parameters that downstream tasks can consume.
Route state, signal phase, local collision geometry, and physical control quantities remain owned by their respective systems. Strategy changes behavior through explicit seams while each life cycle remains with its owner.
21. Policy Validity Must Follow the Mission Phase
Policy values may be valid for one query, one phase, or one mission. Approach, waiting, following, lane-change preparation, and recovery should not reuse the same interpretation blindly. When a phase ends, its temporary modifiers must be released or replaced.
This avoids a common failure in which an aggressive pursuit override survives into ordinary cruising, or an AI policy cache is reused after player takeover. The source of every effective value should remain visible.
22. From Source Reading to Article: Do Not Turn Behavior into a Unique Mechanism
Early braking can result from policy stopping preference, junction context, current speed, road limit, or executor deceleration. A class name alone cannot identify the owner. The reliable method is to trace callers, inputs, result storage, consumers, and invalidation conditions before creating an architectural label.
The same rule applies to player risk states. A state written on the player-information path may serve feedback or statistics, but its exact consumers must be confirmed from call sites rather than inferred from its name.
23. Minimal Verification Matrix
P6 verification should not only ask whether a vehicle reaches the destination.
- Keep route, vehicle, and traffic snapshot fixed while changing policy inputs.
- Keep policy fixed while changing mission overrides, and verify release after task completion.
- Change traffic context and confirm that temporary context does not become durable driver data.
- Keep policy fixed while changing local obstacles, confirming P7 still owns geometric feasibility.
- Apply the same abstract policy input to different vehicle executors and verify semantic compatibility rather than identical trajectories.
- During player driving, confirm that risk observation records events without replacing player input.
Each result should record the source of the parameter, its effective period, the consumer task, and whether P7 or P8 imposed a downstream limit.
P5 explains how a vehicle continues to know where it should go. P6 explains why vehicles following the same global route can still exhibit different speed, distance, waiting, lane-choice, and risk behavior.
The strategy layer is valuable precisely because it changes decisions without absorbing route ownership, local geometry, or physical execution. Its inputs have sources, its outputs have consumers, and its temporary modifiers have expiration conditions.
The next article moves to the immediate local problem: when a pedestrian, object, vehicle, or road boundary appears in front of the vehicle, how does the runtime predict conflict, generate local candidates, and pass strategy bias into local avoidance?
AI Collaboration Review: Turning Behavioral Difference into Traceable Boundaries
AI is useful here not for inventing a complete vehicle AI, but for comparing source notes and extracting relationships:
- which values are durable driver inputs;
- which values are temporary task overrides;
- which states belong only to player risk observation;
- which task decides when the policy query runs;
- which consumer uses speed, distance, and risk weights;
- which details belong to P7 local avoidance;
- which details belong to P8 executors and physics.
The final decision about what is directly supported, what is an architectural abstraction, and what remains a migration proposal still belongs to the human author. The useful output is a traceable mapping from input to consumer and life cycle, not a larger list of systems.
Strategy can change how the vehicle chooses, but it cannot become the sole owner of the vehicle runtime.
Series navigation
P5: Player Goals and Navigation · P7: Local Avoidance and Immediate Risk