Bug report

Required Info:

• Operating System:
  Ubuntu 24.04
• Computer:
  Ryzen 9 7940
• ROS2 Version:
  Jazzy
• Version or commit hash:
  97de6f2
• DDS implementation:
  Cyclone

Steps to reproduce issue

I was trying to among others to play with prediction horizon (changing from 1.75s to 3.75s for a robot with maximal speed: 0.3 m/s and 0.3 rad/s) but the result doesn't change. Footprint is the same for local and global costmap:
footprint: "[ [0.28638, 0.274], [0.28638, -0.274], [-0.39762, -0.274], [-0.39762, 0.274] ]"

time_steps: 35
model_dt: 0.05
batch_size: 2000
ax_max: 3.0
ax_min: -3.0
ay_max: 3.0
ay_min: -3.0
az_max: 3.5
vx_std: 0.2
vy_std: 0.2
wz_std: 0.9
vx_max: 0.3
vx_min: -0.1
vy_max: 0.5
wz_max: 0.3
iteration_count: 1
prune_distance: 0.8
enforce_path_inversion: True
transform_tolerance: 0.1
temperature: 0.3
gamma: 0.015
motion_model: "DiffDrive"
#...
CostCritic:
  enabled: true
  cost_power: 1
  cost_weight: 2.5
  near_collision_cost: 253
  critical_cost: 300.0
  consider_footprint: true
  collision_cost: 1000000.0
  near_goal_distance: 0.0
  trajectory_point_step: 2

Expected behavior

Cost Critic could cause the robot to choose safer motion (reverse a bit parallel to the obstacle instead of forcing colliding rotation). I would like that the robot is able to get close to the obstacle but if it has the possibility to maneuver later, let it do it more safely.

Actual behavior

Cost Critic doesn't penalize when rear part of footprint is getting closer to the obstacle during presented rotation.

I'm happy to investigate this further and dig into the code, but I'd appreciate some guidance/directions where to look for the cause.
My first thoughts are directed towards these lines. For a long platform, the center-point cost is checked (in my case base_link is shifted frame from the robot's center into rotation center).

Reproduction instructions

Additional information