Difficulty pacing is a loss on blended routes

[Onwcan]

What is wrong

CartesianOptions::pace_by_difficulty gives a large improvement on individual moves.

Current measurements include:

• 50 mm through a near-singular wrist: 8.15 s -> 3.27 s
• ordinary 250 mm move: 3.52 s -> 2.23 s

The same feature is a regression on blended routes.

For the three-legged staircase case:

1.44 s -> 2.31 s

The regression is currently asserted by a test so that it remains visible and so that the feature cannot accidentally become the default.

The flag therefore defaults to false.

Nothing is broken for callers using the default configuration, but a feature that must remain disabled for an entire class of paths is incomplete.

Diagnosis

The difficulty schedule is computed from the curvature of the joint path.

Applying the schedule then changes that curvature.

Concentrating the path parameter where the robot struggles makes the parameter vary more rapidly with respect to distance in those regions.

That variation becomes additional curvature in the new parameterisation.

One pacing pass is therefore effectively a single step of a fixed-point iteration that has not been shown to converge.

On a smooth path the change is small and the result improves.

At a blended corner the change is larger and the reparameterisation can manufacture more curvature than it removes.

Damping was also tried by partially moving the schedule from even spacing toward difficulty-based spacing.

At every tested setting, the blended route remained slower than even spreading.

Adding another tuning parameter without a principled value is therefore not justified.

Options

Option 1 — Iterate to a fixed point

Recompute difficulty after reparameterisation and repeat.

This needs:

• a convergence criterion
• evidence that it actually converges

If blended corners cause oscillation rather than convergence, that is also a useful result.

Option 2 — Detect and decline

Compute the difficulty-paced schedule and check whether it increased total duration.

If it did, fall back to even spreading.

This costs one additional schedule evaluation but ensures the feature either improves the path or breaks even.

This is the recommended option.

Option 3 — Exclude corner regions

Use difficulty pacing on straight or smooth portions while leaving blended corners evenly parameterised.

This targets the observed mechanism directly, but "corner region" needs a definition that is not merely another tuned constant.

Acceptance criteria

• Choose one of the approaches rather than implementing all three experimentally in the public interface.
• The three-legged staircase case must no longer be slower than even spreading.
• Replace the existing regression assertion with a test for the new property rather than deleting the test.
• Preserve the current single-move gains to within a few percent.
• Re-report chord_deviation.
• Compare against the current figures:
  • even spreading: 5.5e-05 m
  • difficulty pacing: 2.6e-04 m
  • 65 knots instead of 33: 8.8e-05 m
• Re-measure planning cost.
• Compare against the current 78 us -> 149 us pacing cost.
• If pace_by_difficulty becomes default-true, re-check every README measurement that was produced with it disabled.
• Update ADR-0016 with a new decision section or supersede it with a new ADR.

References

docs/adr/0016-spending-the-path-parameter-by-difficulty.md, Decisions 2-3 and "Why blending defeats it".