Closed Cfather closed 7 months ago
Can you share the changes you made to collision_table.yml
so that we can reproduce this?
We only check if planning time has exceeded timeout after each motion generation attempt. There are two steps inside a motion generation attempt which can have varied compute times, the first is graph planner and second is fine-tuning trajectory optimization.
Since it's not possible to exactly estimate the time taken during these steps, we would have to maintain a planning time instance that we pass around to all planning steps and use this to exit planning when we reach the timeout in any of the steps in a motion generation attempt. We are working on other improvements currently and can revisit this at a later time.
Do share a world model so that we can at least reproduce this.
Thanks for the reply!
I simply changed the size (dim) to 500, so that the table covers the entire reachable region of the robot.
Please provide the below information in addition to your issue:
Issue Details
I used
examples/motion_gen_example.py
to test timeout. I change the world yaml (collision_table.yml
) that the obstacle is so large that there won't be a feasible solution for whatever start and goal poses. I settimeout
inMotionGenPlanConfig
to be 10.0 seconds by default. I setmax_attempts
inMotionGenPlanConfig
to be a very large number (1000 or 10000) so that it will keep trying since the problem is always infeasible. Ideally, it should trigger the timeout condition and exit early before it reachesmax_attempts
. The solve time should approximately be equal to 10.0 seconds. But instead, curobo takes a longer time to return the infeasible result. The output is attached below:21.21181082725525
is the actual solve time. Other parameters inMotionGenPlanConfig
:parallel_finetune=True, enable_finetune_trajopt=True