search

NVlabs / curobo

CUDA Accelerated Robot Library
https://curobo.org
Other
798 stars 125 forks source link

Strange behavior of planning #122

Closed zoctipus closed 10 months ago

zoctipus commented 10 months ago

the plan_single, plan_batch, under some unsure conditions, behave strangely.

the result after plan_single, after get_full_js() has fixed length 31 the result after plan_batch, after get_paths() has fixed length of 131

Yes, no matter how far or close the target is, the result of the trajectory are also fixed 31 or 131. If the target is at the current ee, plan will output the fixed 31 or 131 length trajectory with all joint position having the same value. And if the the target is far and further than what can be reached in 31 or 131 step. A second plan or even third plan is need to continue reach the target.

I have attached a gif that demostrate this phenomenon, you can see that two plans/trajectories has been made to reach the target, both trajectory is of length 131, and the second one is slower because shorter distance Screencast from 01-22-2024 02_52_27 AM

I am not able to reproduce the same issue in a simpler, cleaner environment code so far(so far need orbit to be installed). But I'll keep doing that and post it here. While I am doing that, I also wonder if you know any clue, or is it a simple fix? because it also seems like some ill-parameter issue?

  1. cuRobo installation mode (choose from [python, isaac sim, docker python, docker isaac sim]): isaac sim
  2. python version: 3.10
  3. Isaac Sim version (if using): isaac sim 23.10

Issue Details

balakumar-s commented 10 months ago

Can you share the code that you use to initialize MotionGenConfig?

cuRobo will provide trajectories of varied length depending on the distance traveled. However, for very short trajectories, cuRobo will output a trajectory length equal to the optimization waypoints (32). You can avoid this by making interpolation_dt smaller. Before executing trajectories, do you check if result.success[idx] is True?

zoctipus commented 10 months ago

Thank you for you prompt Response!

Sorry It was my bad, after a closer examination tonight, I found it is my fault!! such behavior is caused by dt discrepancy between my simulation physic dt and curobo dt. the physic dt I had was 0.01 while the curobo dt was 0.05. That was why even if I set the decimation to 3 (3 physics step for every 1 curobo step), it still can't compelete the trajectory. I will take note of your insights as well Thank you Again!