Planning Decision Engineer

Planning & Decision Engineer

§ 1 · System Prompt

[Code block moved to code-block-1.md]

§ 10 · Common Pitfalls & Anti-Patterns

Anti-Pattern 1: Treating Safety as a Soft Cost

Name: The Weighted Safety Engineer

❌ BAD:

# Safety encoded as soft cost — can be traded away by efficiency gain
cost = 10.0 * safety_proximity_cost + 1.0 * speed_cost + 0.5 * comfort_cost
# A high-speed, risky trajectory can have lower total cost than a safe slow one

✅ GOOD:

# Safety is a hard constraint — infinite cost for violation
if min_clearance_to_obstacles < 0.5:   # safety radius violation
    return np.inf                      # trajectory immediately rejected
# Only feasible trajectories participate in soft cost comparison
cost = 1.0 * speed_cost + 0.5 * comfort_cost  # optimize over safe set only

Why it matters: With soft costs, the planner can trade safety margin for speed in dense traffic. This is unacceptable — safety margins must be absolute constraints.

Anti-Pattern 2: Planning Against Single-Mode Prediction

Name: The Most-Likely-Future Planner

❌ BAD:

# Only use the highest-probability prediction mode
predicted_traj = predictor.predict(agent)[0]  # mode with highest prob
plan_path_around(predicted_traj)

✅ GOOD:

# Plan against all modes above probability threshold
predicted_modes = predictor.predict_multimodal(agent, num_modes=6)
safety_violated = False
for mode in predicted_modes:
    if mode.probability > 0.05:  # consider modes with > 5% probability
        if trajectory_collision_check(ego_plan, mode.trajectory):
            safety_violated = True
            break
if safety_violated:
    ego_plan = replan_conservative()  # give way to ambiguous agent

Why it matters: A vehicle with 70% probability of going straight and 30% probability of turning left requires a plan that is safe for both cases. Optimizing only for the 70% case produces a plan that collides 30% of the time.

Anti-Pattern 3: Frenet Frame Used Beyond Its Valid Domain

Name: The Curved-Road Frenet Abuser

❌ BAD:

# Using Frenet planner on sharp curves without curvature correction
# At κ = 0.1 m⁻¹, Frenet-to-Cartesian projection has significant error
frenet_planner.plan(ego_state, target_speed=15.0)  # valid up to κ ≈ 0.05 m⁻¹

✅ GOOD:

# Check curvature before applying Frenet planner; switch to Cartesian for sharp curves
max_kappa = max(abs(kappa) for kappa in reference_path.curvature_profile)
if max_kappa > 0.05:  # 20m radius of curvature
    # Switch to Cartesian-space optimization (e.g., Apollo's open-space planner)
    plan = cartesian_space_planner.plan(ego_state, reference_path)
else:
    plan = frenet_planner.plan(ego_state, reference_path, target_speed)

Why it matters: Frenet frame assumes small curvature. At κ > 0.1 m⁻¹ (radius < 10m, tight parking lots), the projection error causes the planner to generate trajectories that violate drivable area boundaries when converted back to Cartesian coordinates.

Anti-Pattern 4: IDM Parameters Not Tuned for Platform

Name: The Default-Parameter Driver

❌ BAD:

# Default academic IDM parameters — not tuned for production vehicle
idm = IDM(desired_speed=33.3, time_headway=1.0, min_gap=2.0,
          max_accel=0.73, comfortable_decel=1.67)
# Result: follows too closely, harsh braking in dense traffic

✅ GOOD:

# Tuned for robotaxi comfort and safety; validated on nuPlan
idm = IDM(
    desired_speed=target_speed,
    time_headway=1.8,        # 1.8s headway for comfort and safety (> ADAS minimum 1.5s)
    min_gap=3.0,             # 3m minimum gap (larger than academic default 2m)
    max_accel=1.5,           # moderate acceleration for passenger comfort
    comfortable_decel=2.5,   # comfortable braking (not harsh 3.5+ m/s²)
    accel_exponent=4.0,      # sharpness of free-road-vs-jam transition
)
# Validate: measure avg jerk in following scenarios; target < 1 m/s³ mean

Why it matters: Default IDM parameters are tuned for traffic flow studies, not passenger comfort. Time headway of 1.0s causes harsh acceleration/braking cycles that fail comfort gates.

Anti-Pattern 5: Missing Fallback When Planner Returns No Solution

Name: The Null-Return Planner

❌ BAD:

def plan(ego_state, obstacles, target_speed):
    trajectories = generate_candidates(ego_state, obstacles, target_speed)
    feasible = [t for t in trajectories if t.cost < np.inf]
    if not feasible:
        return None   # DANGEROUS: caller must handle None somehow
    return min(feasible, key=lambda t: t.cost)

# Caller:
traj = planner.plan(state, obs, speed)
if traj is None:
    pass  # nothing — vehicle maintains last trajectory, potentially stale

✅ GOOD:

def plan(ego_state, obstacles, target_speed):
    trajectories = generate_candidates(ego_state, obstacles, target_speed)
    feasible = [t for t in trajectories if t.cost < np.inf]
    if feasible:
        return min(feasible, key=lambda t: t.cost), 'OPTIMAL'

    # ALWAYS return a safe fallback: comfortable deceleration to stop in current lane
    fallback = generate_fallback_deceleration(ego_state, decel=2.0)
    return fallback, 'SAFETY_FALLBACK'

Why it matters: A planner that returns None in a constraint-infeasible situation forces the caller to maintain a stale trajectory from N cycles ago. As time passes, the stale trajectory becomes increasingly dangerous. The planner must always return something safe.

Anti-Pattern 6: Not Checking Kinematic Feasibility Post-Planning

Name: The Geometrically Smooth, Physically Impossible Plan

❌ BAD:

# Return mathematically smooth trajectory without kinematic check
trajectory = optimize_smooth_path(waypoints)
return trajectory  # could require steering rate of 50 deg/s — impossible

✅ GOOD:

[Code block moved to code-block-2.md]

Why it matters: Trajectory optimizers can produce geometrically smooth paths that require physically impossible steering angles at speed. Sending such trajectories to the controller causes oscillatory tracking errors and potential loss of control.

§ 11 · Integration with Other Skills

§ 12 · Scope & Limitations

Use when:

• Designing trajectory planning or motion planning algorithms for autonomous vehicles in structured or semi-structured environments.
• Implementing or tuning Frenet-frame planners, MPC controllers, IDM/MOBIL models, or MPDM/POMDP decision systems.
• Debugging comfort regressions (jerk, lateral acceleration violations) or planning oscillation in production AV systems.
• Benchmarking planning stacks on nuPlan, CommonRoad, or CARLA and interpreting results.
• Selecting planning architecture for a new ODD (highway, urban, parking, intersection).

Do NOT use when:

• Designing the perception or prediction modules that feed the planner — use perception-algorithm-engineer or end-to-end-autonomous-researcher skills respectively.
• Safety certification work (ISO 26262, SOTIF HARA) — use autonomous-driving-engineer skill with formal safety framework.
• V2X cooperative driving protocol design — use v2x-system-engineer skill for RSU/OBU communication stack.

Alternatives:

• For full AV stack architecture including safety case: autonomous-driving-engineer skill.
• For learned end-to-end planning without classical decomposition: end-to-end-autonomous-researcher skill.
• For simulation validation harness setup: simulation-platform-engineer skill.

§ 14 · Quality Verification

→ See references/standards.md §7.10 for full checklist

References

Detailed content:

• ## § 2 · What This Skill Does
• ## § 3 · Risk Disclaimer
• ## § 4 · Core Philosophy
• ## § 6 · Professional Toolkit
• ## § 7 · Standards & Reference
• ## § 8 · Workflow
• ## § 9 · Scenario Examples
• ## § 20 · Case Studies

Examples

Example 1: Standard Scenario

Input: Design and implement a planning decision engineer solution for a production system Output: Requirements Analysis → Architecture Design → Implementation → Testing → Deployment → Monitoring

Key considerations for planning-decision-engineer:

• Scalability requirements
• Performance benchmarks
• Error handling and recovery
• Security considerations

Example 2: Edge Case

Input: Optimize existing planning decision engineer implementation to improve performance by 40% Output: Current State Analysis:

• Profiling results identifying bottlenecks
• Baseline metrics documented

Optimization Plan:

1. Algorithm improvement
2. Caching strategy
3. Parallelization

Expected improvement: 40-60% performance gain

Workflow

Phase 1: Requirements

• Gather functional and non-functional requirements
• Clarify acceptance criteria
• Document technical constraints

Done: Requirements doc approved, team alignment achieved Fail: Ambiguous requirements, scope creep, missing constraints

Phase 2: Design

• Create system architecture and design docs
• Review with stakeholders
• Finalize technical approach

Done: Design approved, technical decisions documented Fail: Design flaws, stakeholder objections, technical blockers

Phase 3: Implementation

• Write code following standards
• Perform code review
• Write unit tests

Done: Code complete, reviewed, tests passing Fail: Code review failures, test failures, standard violations

Phase 4: Testing & Deploy

• Execute integration and system testing
• Deploy to staging environment
• Deploy to production with monitoring

Done: All tests passing, successful deployment, monitoring active Fail: Test failures, deployment issues, production incidents