4 Commits

Include renames

Author	SHA1	Message	Date
brianhansonxyzandClaude Opus 4.6	cf2b3fc637	modeld: revert to constant 20fps (except standby at standstill) ... Disabled the variable-rate (4/10/20fps) logic — it caused persistent downstream freq/valid cascades that broke paramsd's angle-offset learner, calibrationd, and locationd's one-shot filterInitialized latch. Symptom: user's "TAKE CONTROL IMMEDIATELY / Communication Issue" banner during engaged driving, plus subtle right-pull (paramsd's fast angle-offset adaptation was frozen all session). Simpler model now: standstill → standby (0fps, paused) otherwise → 20fps (no variable rate) Republish-caching and FPCC.latRequested/noLatLaneChange plumbing left in place so re-enabling variable rate later is a one-line change (full_rate = True → the original full_rate expression). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-17 18:21:46 -05:00
brianhansonxyzandClaude Opus 4.6	5b67d4798b	fix: update services.py rates to match new thermald/gpsd publish rates ... Root cause of "TAKE CONTROL IMMEDIATELY / Communication Issue Between Processes" during driving: our 4Hz thermald and 2Hz gpsd changes pushed deviceState, managerState, and gpsLocation above their declared rate ceilings in cereal/services.py. SubMaster's freq_ok check requires observed rate within [0.8*min, 1.2*max]; publishing faster than max also fails the check — which trips all_freq_ok(), raises EventName.commIssue, and fires the banner. - deviceState: 2Hz → 4Hz (matches thermald DT_TRML=0.25) - gpsLocation: 1Hz → 2Hz (matches gpsd 2Hz polling) - managerState: 2Hz → 4Hz (gated on deviceState arrival, inherits rate) Also: - Re-enabled dashcamd in process_config.py (was disabled for the diagnostic test — dashcamd was innocent). - Added a CLAUDE.md section documenting this class of bug so the next rate change updates services.py too. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-17 16:28:55 -05:00
brianhansonxyzandClaude Opus 4.6	4dae5804ab	feat: 4Hz fan control with gear/cruise-aware clamps; move hot signals to cereal ... Fan control rework (thermald → 4Hz): - DT_TRML 0.5s → 0.25s (thermald loop + fan PID now at 4Hz) - New clamp rules based on (gear, cruise_engaged, standstill): parked → 0-100% in drive + cruise engaged (any speed) → 30-100% in drive + cruise off + standstill → 10-100% in drive + cruise off + moving → 30-100% - thermald now reads gearShifter (via carState) and controlsState.enabled, passes them to fan_controller.update() - Removed BENCH_MODE special case — new rules cover bench automatically - Removed ignition-based branches — gear is the correct signal System health overlay: - Subscribed UI to peripheralState so we can read fanSpeedRpm - Added FAN row: actual fan% (RPM / 65) to sit alongside LAG/DROP/TEMP/CPU/MEM. Shows the real fan output vs. what the PID is asking for. Migrate hot signals from paramsMemory to cereal (frogpilotCarControl): - Added latRequested @3 and noLatLaneChange @4 to FrogPilotCarControl schema - controlsd sets FPCC.latRequested / FPCC.noLatLaneChange (send-on-change already gates the IPC) - modeld reads from sm['frogpilotCarControl'] (added to its subscribers) instead of paramsMemory (saves ~20 file-read syscalls/sec) - carcontroller reads from frogpilot_variables (set in-process by controlsd) instead of paramsMemory (saves ~100 file-read syscalls/sec in 100Hz path). Dropped carcontroller's now-unused Params instance and import. - UI (ui.cc, onroad.cc) reads from sm['frogpilotCarControl'].noLatLaneChange - Removed LatRequested and no_lat_lane_change param registrations + defaults Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-17 16:01:39 -05:00
brianhansonxyz	e2a0c1894a	clearpilot: initial commit of full source	2026-04-11 06:25:25 +00:00