0dc8002c6d
Three independent changes bundled together. Revert hyundai canfd steering torque limits to comma stock defaults (270 / 2 / 3 / 112) in both panda safety and openpilot CarControllerParams. The 270->324 bump caused overcorrection on turns and weaving on straights. Web research turned up no public reports of any 4th gen Tucson NX4 owner bumping STEER_MAX — the documented Tucson tuning effort is entirely on lateralTuning (latAccelFactor ~2.9-3.1, friction ~0.095), not the cap. hoomoose's EV6/Ioniq 5 PR #25723 is the canonical "raise STEER_MAX without dropping latAccelFactor causes overcorrection" data point — and even that change was reverted upstream. Right next move for this car is to tune latAccelFactor / friction, not the torque ceiling. plannerd: keep publishing longitudinalPlan at the normal cadence in park, but skip update() compute. Skipping publishes entirely caused longitudinalPlan to time out the alive flag at controlsd, which fired a real commIssue ("not_alive") on park->drive. Stale published values are fine because controlsd's own park short-circuit ignores the longitudinalPlan content while parked. Also gate publish_ui_plan on not-parked: it reads longitudinal_planner.a_desired_trajectory_full which is only set inside update(), so calling it without a prior update crashes plannerd with AttributeError (which fires "Process Not Running" on screen). uiPlan is UI-only, not on controlsd's commIssue check list, so going silent in park is fine. frogpilot_process: same idea — keep publishing frogpilotPlan in park to keep alive, skip the heavy update() compute. dashcamd: close the trip immediately on gear shift to PARK (was: 10-min idle timer before close). User wants the dashcam idle in park and a fresh trip on every drive engagement; brief drive-thru / fuel-stop across-trip continuity isn't valued. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>