Increase minimum front object sensor length from 0.2m to 2m

[helgehelge123]

At low speeds, the dynamic lookahead box of frontSensorDynamicShort for static objects shrinks down to minDynamicLength = 0.2 (VirtualSensors.lua), so thin obstacles like lamp posts are effectively only detected on contact. Vehicles already use a 2 m minimum (minDynamicLengthForVehicles).

This applies the same 2 m minimum to static objects, so obstacles are detected early enough to stop in front of them even at crawl speed.

One-line change, no behavior change at normal driving speeds (there the speed-based lookahead is larger anyway).

🤖 Generated with Claude Code

[Axel32019]

In the past we had 2.0m for this, but changed to 0.2m and additional to dynamic front sensors to enable drive in tight situations with obstacles.
We will not change back to a more poor "solution".
@Iwan1803 @Williwillswisse Any more comments to this? Otherwise we close.

[Iwan1803]

With the old settings, vehicles would brake unnecessarily and detect an obstacle that wasn't actually one, because they could have simply driven right past it. Why would we want to undo this advantage now? I see no reason or need for that.
Maybe @helgehelge123 cann tell us...

[helgehelge123]

Thanks for the context — I wasn't aware the 0.2 m was a deliberate change to make tight maneuvering work, that explains it.

The case that triggered this PR: a vehicle approaching at crawl speed pushed into a lamp post directly in its line instead of stopping in front of it. With the dynamic length formula (speed * 15.5/40, clamped to the minimum), the static-object box shrinks to 0.2 m below ~5 km/h — at that distance a hit is only registered on contact. Vehicles already use a 2 m minimum in the split sensor, so this only concerns static objects.

I understand a global 2 m minimum would bring back exactly the unnecessary stops you fixed, since below 5 km/h is precisely the tight-maneuvering range. Two less invasive alternatives:

1. Make the static minimum a setting (default 0.2, so no behavior change for anyone; users who see crawl-speed collisions with thin obstacles can raise it).
2. A middle value like 0.75–1.0 m — enough to stop from crawl speed, much less intrusive than 2 m in tight spots.

Happy to rework the PR to option 1 or 2 — or if you don't see the need, closing is fine too.

[KeilerHirsch]

Read through the existing discussion before looking at this purely as a diff — glad I did, because a flat "LGTM" here would have been wrong. Axel32019/Iwan1803 are right that a blanket 2 m minimum reintroduces the exact unnecessary-stop behavior the 0.2 m change was deliberately fixing, and @helgehelge123 already conceded that and put two better alternatives on the table:

1. Make the static minimum a setting, default 0.2 (zero behavior change for anyone until they opt in).
2. A fixed middle value (0.75–1.0 m).

Between the two, option 1 seems clearly stronger to me. The whole point of the original 0.2 m change was to enable genuinely tight maneuvering around obstacles — and 0.75–1.0 m is still a ~4-5x jump from 0.2 m, so there's no real guarantee it wouldn't reintroduce false-positive stops in exactly the tight spots that motivated the original fix, just to a lesser degree. It'd be trading one poorly-characterized default for another. A per-user setting has no regression risk for the existing (larger) userbase who rely on the tight-maneuvering behavior, and gives the people actually hitting the crawl-speed-lamppost case in this PR a real lever, without the project having to pick a single "correct" number for everyone.

Not approving this as-is since it's the exact behavior the thread already flagged as a regression — following up here mainly to help push the settings-based rework forward rather than repeat what's already been said.

[Iwan1803]

A distance of 1 or 2 meters does not provide enough space to bring fast-moving and/or heavily loaded vehicles to stop right in time. Otherwise, we would have to install anchors for braking 😂