feat(sim): enable DIR rotor-offset/resolver learning on the sim bench #21
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/dir-learn-bench-enable"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
Enable the DIR rotor-offset and resolver / resolver-error learning procedures to run on the sim bench, by answering the MCU-published CID gates they need from CAN — the way the car does — instead of hand-maintaining each mapping.
How
vapi_registry.py, new) — emulatelibQtCarVAPI'sinit_arrayunder Unicorn and extract the firmware's ownDataValueregistration table (name ← ETH source signal, render kind: enum/bool/num).BenchBackend._derive_cidnow resolves aliases (VAPI_shiftState ← DI_gearviaShiftStateNameMap, plus ~300 more) from it; the hand-writtenDI_gearmap is deleted. The table is cached per-rev (gitignored); an empty registry (no MCU libs) falls back to seeds, so a firmware-less bench still runs.VAPI_{drive,acc,hvac}RailOnfromVCFRONT_vehiclePowerState(0x221);GUI_tractionControlModeRequestfromDI_tractionControlMode.UI_serviceModeon 0x284, driven by a per-procedure session that toggles vehicle_sim's service mode. That is the DIR's learn-routine start gate (FAILED_INCORRECT_CONDITIONSwithout it).GTW_timecarries a real clock on the 2022 variant so the brake-temp estimator does not tripDI_a228.odj_codecfix — a negative value on auintODJ field now wraps to two's complement (ROTOR_TEMPERATURE−40 →0xD8) instead of raisingOverflowError, which unblocks the ROTOR-OFFSET start request.Readiness
Resolver and resolver-error learning were already fully wired (extended session, TesterPresent keepalive, SecurityAccess L5
tesla_hash, routines decode to named results). This makes rotor-offset work too. Remaining dependencies are physical, not code: the DIR must be in dyno mode and actually spinning for a routine to complete.Tests
318 pass — new
tests/test_vapi_registry.py; extendedtest_cid.py,test_odj_codec.py,test_vehicle_sim_nodes.py. Ruff clean, LF endings.🤖 Generated with Claude Code
Answer the MCU-published CID gates these procedures need from CAN, the way the car does, instead of hand-maintaining each mapping: - vapi_registry: extract libQtCarVAPI's DataValue alias table by emulating its init_array under Unicorn (name + ETH source + render kind per DataValue). The bench's _derive_cid now resolves VAPI_shiftState <- DI_gear and ~300 more from the firmware's own table; the hand DI_gear map is gone. Cached per-rev (gitignored); empty when the MCU libs are absent, so it degrades to seeds. - Computed values (no single-signal alias) stay explicit: VAPI_{drive,acc,hvac} RailOn from VCFRONT_vehiclePowerState (0x221); GUI_tractionControlModeRequest from DI_tractionControlMode. - Service mode on the bus: UI_serviceMode in 0x284, driven by a per-procedure session that toggles vehicle_sim's service mode -- the DIR's learn start gate. - GTW_time carries a real clock on 2022 so the brake-temp estimator does not trip DI_a228. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>ROTOR_LEARNING's ROTOR_TEMPERATURE is typed uint in the ODJ, but the DIR learn script sends a signed degC (-40) and the ECU reads it as two's complement. Wrap a negative value into the field width instead of raising OverflowError, so -40 packs as 0xD8. Signed ('int') fields and non-negative values are unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>1dccacb884f9a70b9b91