Repository navigation
Bind the VehicleSim front brake bias to brake.front_bias - #158
Merged
raorjun merged 2 commits intoOct 29, 2026
Merged
Conversation
vehicle.yml brake.front_bias never reached Modelica. BaseVehicleSim binds only brakes.maxTorque, so BasicVCUBrakes ran its own 0.55 front bias while dynpy and the envelope used the YAML value (0.84 for the BobSim car). The generated VehicleSim template now adds brakes(frontBrakeBias = ...) to the BaseVehicleSim extends clause, from brake.front_bias. A missing key fails with KeyError. A non-numeric value fails with TypeError. A value outside 0 to 1, NaN or infinity fails with ValueError. Each failure happens before any write. The FourPost template is unchanged because BaseFourPostSim has no brakes. This changes executed VehicleSim braking physics for any regenerated template. No regression baseline is changed here.
The previous commit made brake.front_bias required. None of the 9 shipped common/vehicle_templates files has a brake section, so Modelica generation failed for each of them and for the app apply-template flow. No source names a value to add to those templates. A missing brake section, a missing key or a null value now binds nothing. The generated VehicleSim template is then the same as before this branch, and BobLib BasicVCUBrakes keeps its own default. The status payload reports the case under front_brake_bias, and the CLI prints a brake line. A set value still binds brakes.frontBrakeBias. A value that is not a number, is out of 0 to 1, or a brake entry that is not a mapping still fails before any write. Test fixtures no longer copy the brake block from vehicle.yml into template-based cars. A new test plans each shipped template. The docs now say when DynPy and the envelope use the same value, and that they use 0.84 when the key is missing.
rhorvath02
approved these changes
Oct 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
vehicle.ymlbrake.front_biasnever reached Modelica. BaseVehicleSim binds onlybrakes.maxTorque, so BasicVCUBrakes ran its own 0.55 front bias, while DynPy and the envelope used 0.84 for the BobSim car.Changes
brake.front_biasis set, the generated VehicleSim template addsbrakes(frontBrakeBias = ...).How to check
New tests in
tests/test_modelica_generator.py. A VehicleSim build from a generated template showsbrakes.frontBrakeBiasstart 0.84 in the init XML, against 0.55 on main.Notes
Risk
This changes the executed VehicleSim braking physics once a template is regenerated. The default car's checked-in templates still run 0.55 until its records are regenerated, which today is blocked by the records-versus-YAML initialization mismatch. No baseline is changed.
Stack
7 of 7, kept last.