Closed isherman closed 3 years ago
Hi @isherman, this is an internal error of Ruckig. Can you share your InputParameter for a typical failing case?
By the way, you can print the current input parameters (and let ruckig throw on errors) by using Ruckig<DoFs, true>
.
By the way, you can print the current input parameters (and let ruckig throw on errors) by using
Ruckig<DoFs, true>
.
Great tip, thanks!
terminate called after throwing an instance of 'std::runtime_error'
what(): [ruckig] error in step 1, dof: 4 input:
inp.current_position = [-0.843763019702056, -1.26164314329262, 1.62592703780797, -1.26322670514057, -0.900133529360832, 1.09819107359504]
inp.current_velocity = [-0.0303436943534115, 0.0371785718477563, -0.0294029319779939, -0.0129669308625882, -0.030242580748223, 0.00636710830722948]
inp.current_acceleration = [0.0941203950600968, -0.152313813731685, 0.134100351460333, 0.0630571844324987, 0.0116214644247746, -0.0622068786789912]
inp.target_position = [-0.847254234340315, -1.25777615061367, 1.62279392916203, -1.26518389118862, -0.90368278625599, 1.09921788488865]
inp.target_velocity = [0, 0, 0, 0, 0, 0]
inp.target_acceleration = [0, 0, 0, 0, 0, 0]
inp.max_velocity = [1.30899693899575, 0.98174770424681, 1.43989663289532, 1.5707963267949, 1.5707963267949, 1.88931891528386]
inp.max_acceleration = [4, 4, 4, 4, 4, 4]
inp.max_jerk = [2, 2, 2, 2, 2, 2]
My issue #20 seems to be related to this. Here is my runtime_error:
terminate called after throwing an instance of 'std::runtime_error'
what(): [ruckig] error in step 1, dof: 2 input:
inp.current_position = [0, 0, 19.7358068624528]
inp.current_velocity = [0, 0, 0.397522631063786]
inp.current_acceleration = [0, 0, -0.398759391645531]
inp.target_position = [0.312597038921652, 5.46143591026349, 20]
inp.target_velocity = [0, 0, 0]
inp.target_acceleration = [0, 0, 0]
inp.max_velocity = [3, 3, 3]
inp.max_acceleration = [0.5, 0.5, 0.5]
inp.max_jerk = [0.2, 0.2, 0.2]
The latest commit on the master branch should fix some errors (due to numerical issues), but it still needs more automated testing...
In my particular case, I don't have the error anymore with the latest commit. I will keep you updated if I run into anything similar again.
Thanks for the help @pantor.
I am still getting similar errors at 1b06ce4937bd35773ba3b41c1ae5a6a4371cd888:
terminate called after throwing an instance of 'std::runtime_error'
what(): [ruckig] error in step 1, dof: 5 input:
inp.current_position = [-0.8494117653618009, -1.254984898711493, 1.623547625912817, -1.264314589439878, -0.9070599831444599, 1.096081438096845]
inp.current_velocity = [-0.007588234821168835, 0.005538054540119678, 0.01208997929687014, 0.008184453287068091, -0.01307583605190736, -0.02330031757673159]
inp.current_acceleration = [0.01787718749228191, -0.03686086688015895, 0.121368265848752, 0.0901853690259044, 0.007706614114261729, -0.08989353127954892]
inp.target_position = [-0.8510605112929079, -1.253856391337919, 1.626531478684011, -1.262269584825345, -0.909530762083901, 1.092124618222708]
inp.target_velocity = [0, 0, 0, 0, 0, 0]
inp.target_acceleration = [0, 0, 0, 0, 0, 0]
inp.max_velocity = [1.308996938995747, 0.9817477042468103, 1.439896632895322, 1.570796326794897, 1.570796326794897, 1.889318915283862]
inp.max_acceleration = [4, 4, 4, 4, 4, 4]
inp.max_jerk = [2, 2, 2, 2, 2, 2]
I don't know if it's still useful for you to get as many runtime_error logs as possible. I don't want to be spamming here.. In any case, I ran into this one today:
terminate called after throwing an instance of 'std::runtime_error'
what(): [ruckig] error in step 1, dof: 2 input:
inp.current_position = [0.002790767530717088, 0.00192073758242831, -6.010800000000007]
inp.current_velocity = [0.0007082281005476234, 0.0004861770142931825, -2.424000000000002]
inp.current_acceleration = [0, 0, -0.4799999999999994]
inp.target_position = [0, -0.007643113887548852, -28.25836181640625]
inp.target_velocity = [0, 0, 0]
inp.target_acceleration = [0, 0, 0]
inp.max_velocity = [3, 3, 3]
inp.max_acceleration = [0.5, 0.5, 0.5]
inp.max_jerk = [0.2, 0.2, 0.2]
With the latest commits, the situation due to numerical issues should improve. It is not perfect yet, so please report if you encounter any errors.
With the latest changes I've been running all day without a -110 error. Thank you! Feel free to close this issue, or keep it open for a few more days of hands-on testing if you'd prefer. 🙇
I'm using Ruckig in a 6-DOF visual servoing application, updating
input.target_position
at a rate similar to the control cycle. I find that often when setpoints (updates totarget_position
) are quite close to each other, Ruckig will return a-110
status. Can you help me understand what causes this error? Are there any workarounds you'd suggest? Thank you.