Feasible trajectory misclassified as infeasible

Drivability Checker
1

Dear CommonRoad team,

it seems that that optimization problem used to reconstruct the inputs for a given trajectory in line 232 of feasability_checker.py (https://commonroad.in.tum.de/forum/c/drivability-checker/14) often fails to find the correct solution, which results in feasible trajectories getting misclassified as infeasible (see for example solution file https://drive.google.com/file/d/1p7wpGJccGSRjC_XAQJHLT5DNh3-a3ehX/view?usp=sharing).

Couldn’t the inputs simply be reconstructed as steering_angle_speed = (x1.steering_angle - x0.steering_angle)/dt and acceleration = (x1.velocity - x0.velocity)/dt? Or one could maybe at least use these values as warm start for the optimization problem to increase the chances that the correct solution is found.

I also tried uploading solution trajectories consisting of the inputs directly to the CommonRoad website, but then I get the errors “InputState has not attribute position” or “InputState has not attribute velocity”.

Thank you in advance!

2

Dear ReliableSystemsLab Team,

Thank you for bringing this to our attention. Indeed, we find similar issues with the drivability/feasibility checker with our own example solutions.
Unfortunately we currently still don’t know exactly what causes the issues, however we are eagerly investiagting the situation.

We will keep you updated about any progress!

Thanks again for participating in this years competition
- The CommonRoad Competition Team

3

I noticed it was actually my own mistake: I did not realize that the x,y entries for KSstate have to be the position of the vehicle center rather than the position of the vehicle rear axis as in the dynamics. After fixing this it now works.

Sorry for bothering you about this.