Add opt-in per wheel acceleration limits to the ER-Force simulator

[Andrewyx]

Description

WIP Claude Template

Last of four stacked PRs porting upstream ER-Force simulator changes (#3912). Stacked on #3949.

Ports upstream's per wheel acceleration limit (upstream 3ad65ad6, 7388a292), which bounds how fast each wheel of a simulated robot may accelerate instead of bounding the acceleration of the robot as a whole. Upstream hardcodes their own wheel geometry and specifies the limits per wheel rotation; ours takes the coupling matrix from EuclideanToWheel so the limit reflects our drivetrain, and specifies the limits in m/s² at the wheel to match motor_max_acceleration_m_per_s_2 in our robot constants.

This is off by default, both in the ErForceSimulator constructor and behind --enable_wheel_acceleration_limits on er_force_simulator_main. It composes with our existing wheel ramping (#3805) rather than replacing it: ramping limits the commands we send, this limits the robot inside the physics simulation.

It is off for a reason worth knowing before anyone turns it on, which I found while writing the tests: the limit is applied to whatever the simulator's internal velocity controller asks for, and that controller asks for far more acceleration than any robot can deliver (hundreds of m/s²). The clamp therefore ends up starving whichever of translation and rotation demands less of the wheels, and a robot told to drive and spin at the same time barely spins. That is upstream's behaviour too, not something introduced here, but it means this feature is not ready to be switched on without more work — reviewers may reasonably prefer we drop it.

Also records in the extlib README which upstream commit this fork is synced with (38563d11, 2026-07-27), and what was deliberately left unported, so the next sync is a git log away.

Testing Done

• Two new er_force_simulator_test cases: with the limits off a robot accelerates exactly as before and with them on it accelerates more slowly, and with them on acceleration depends on the driving direction (diagonal is slower than straight, which is the per wheel limit binding in wheel space).
• The defaults path is unchanged, so the rest of the suite is the regression guard for "off by default".
• Same full suite runs as Fix ER-Force simulator dribbling physics and reported ball model #3947.

Stack testing summary

For the stack as a whole: 121/121 of the CI software tests pass, the 3 minute autoref'd AI vs AI game completes, and the simulated gameplay suite shows no regression. That last one deserves a caveat: across three full runs of the suite with the stack applied, 2, 0 and 1 test failed, a different test each time, and a baseline run on master also failed a fourth different test. Every individual failure passes 2–3 out of 3 times when run on its own, so this looks like the suite's known load sensitivity (CI runs it with --flaky_test_attempts=3), not a regression from these changes.

Resolved Issues

resolves #3912

Length Justification and Key Files to Review

323 lines. Key files: src/extlibs/er_force_sim/src/amun/simulator/simrobot.cpp and src/software/simulation/er_force_simulator.cpp.

Review Checklist

• Function & Class comments
• Remove all commented out code
• Remove extra print statements
• Resolve all TODO's