Automatic discrtimestep?

[stephane-caron]

We need to find a way to compute a reasonable ds (discrtimestep) dynamically, since good values for this parameter are both system and trajectory dependent. For instance, in torques_pendulum_rave.py:

sdbeg_min, sdbeg_max = 0.0 , 0.0001
trajectorystring = """1.000000
2
0.0 0.0 -1.04335890092 0.547353298841
0.0 0.0 -2.24856384056 1.36915743417"""

Says "no solution" for discrtimestep=1e-3, but finds solutions (sd_end = [0.0, 2.80]) for discrtimestep=1e-4.

[aorthey]

Hi guys, is there any progress on this issue? I ran into a similar problem, where i can find a solution for discrtimestep=0.01, no solution for discrtimestep=0.02 and again a solution for discrtimestep=0.05, which seems very paradoxically. attached is a minimal example for an omnidirectional point robot in 2d, dots are waypoints, vertical lines are the sampled timesteps and blue are forces acting on the trajectory (forces are lower than control, so the trajectory should be statically stable). A green trajectory means success with TOPP, red means failure. On top of that i get different end speeds for different successful discrtimesteps:

discrtimestep=0.01: sd_end = [ 0.0 , 0.16 ] discrtimestep=0.02: failure discrtimestep=0.05: sd_end = [ 0.0 , 0.095 ]

sdbeg_min, sdbeg_max = 0.0 , 0.0
trajectorystring = """0.181818
2
-8.60663863714e-19 2.19999381518 0.000102049482337 -0.000374181435274
0.0 -1.36189708232e-05 0.000224713018583 -0.000823947734803
0.090909
2
0.4 2.19999381518 -0.000102049482358 0.0018709071768
-4.23516473627e-22 -1.36189708232e-05 -0.000224713018583 0.00411973867401
0.090909
2
0.6 2.20002164686 0.000408197929498 -0.00710944727209
4.23516473627e-22 4.76663978811e-05 0.00089885207433 -0.0156550069613
0.090909
2
0.8 2.19991959738 -0.00153074223562 0.0265668819108
-1.69406589451e-21 -0.000177046620701 -0.00337069527874 0.058500289171
0.090909
2
1.0 2.20029996363 0.00571477101278 -0.0991580803692
0.0 0.000660520084924 0.0125839290406 -0.218346149723
0.090909
2
1.2 2.1988805481 -0.0213283418152 0.370065439564
2.71050543121e-20 -0.002465033719 -0.0469650208838 0.81488430972
0.090909
2
1.4 2.20417784396 0.0795985962476 -1.38110367788
-5.42101086243e-20 0.00919961479106 0.175276154494 -3.04119108916
0.090909
2
1.6 2.18440807606 -0.297066043175 5.15434927197
2.16840434497e-19 -0.0343334254452 -0.654139597094 11.3498800469
0.181818
2
1.8 2.25818985181 1.10866557645 -19.23629341
0.0 0.12813408699 2.44128223388 -42.3583290985"""

[quangounet]

Hi Andreas, it's noted, I will investigate this issue with your minimal example. Meanwhile, let me note that it's not recommended to use time step > 0.01 since the discretized velocity profile can be quite far away from the real one at some key points, causing it to overshoot the limit (and make the algorithm fail). Have you tested with time step = 0.001, 0.002, 0.005?

[aorthey]

I just tested with timesteps 1e-3 and 1e-4, both reported failure. It is a little difficult to give a complete minimal example since i am sampling dynamics at each point, but i can send the abc-vectors for the quadratic constraints for certain timesteps if that would be helpful.

[quangounet]

Yes, that would definitely help!

[aorthey]

I prepared a small script where i just dumped the ABC vectors + trajectorystring for the three cases i mentioned: https://raw.githubusercontent.com/orthez/openrave-forcefields/master/test_topp_standalone.py Hope that helps.