Specific test case yields ErrorExecutionTimeCalculation

[AndyZe]

I'm trying to bring Ruckig into MoveIt but have had some trouble. Usually the first waypoint fails. I'll give a specific test case here.

The MoveIt PR is here and the Ruckig-related code is here.

A spreadsheet of the parameters that cause this failure is attached. Let me know if any more info is needed to reproduce the issue.

The failure code is -110 (ErrorExecutionTimeCalculation). Currently using the default Time synchronization (have also tried None) and Interface::Position (have also tried Velocity).

I've tried to manually check the input parameters and they seem fine to me ¯_(ツ)_/¯

On the bright side, I have seen a few successful calculations when the target vel/accel are very low.

ruckig_issue.ods

[pantor]

Hi! Ruckig currently does not really support very high jerk and acceleration constraints (in the limit of -> infinity), because the equations get numerical unstable and violate the guarantees mentioned here. So what we probably want is to disable jerk and acceleration constraints and switch to a Type II or linear interface instead. The good news is that this is already implemented for the velocity controller, but I'll need to add this as a fallback to the position controller.

[AndyZe]

You are right, it works great with reasonable vel/accel/jerk limits :+1:

(Thought I had tested that previously, but I guess there was a different bug at the time).

Cool, I'll try to get this merged.

[AndyZe]

Actually that particular case works but I still get a lot of failures for other cases, e.g. with (vel/accel/jerk) limits set to (5/10/20) :(

[AndyZe]

Here's another failure case with reasonable vel/accel/jerk limits this time.

ruckig_issue.ods

[pantor]

I'm unfortunately not able to reproduce these specific issues, so could you provide the parameters with higher precision? By the way, when using Ruckig<6, true> (with the second parameter set to true), Ruckig will throw an error with all relevant information, so you can just copy&paste that.

In general, Ruckig still has some numerical issues that I'm aware of, but I'm confident that I'm able to fix them soon.

[AndyZe]

I put a video of the performance here. IMO this is good enough to merge and make optional for MoveIt.

Ruckig is running after TOTG. There are some issues there:

• There can be backwards motion. This is a consequence of running TOTG first (non-jerk-limited) then running jerk-limited Ruckig. Unavoidable, I think.
• Sometimes the goal pose isn't 100% achieved. Another consequence of running TOTG first (non-jerk-limited) then running jerk-limited Ruckig. Unavoidable, I think.
• Sometimes Ruckig fails to solve. Hopefully that can be fixed on your end.

Got any suggestions?

[pantor]

The recent video with the fix for the backward motion looks great! Regarding the goal pose: Isn't it possible to set the goal pose as the last target pose for Ruckig (when updating the input parameters the final time), so that the goal pose is always reached exactly?

With the recent commits, the numeric stability in particular for high limits (tested with |x| < 1e6) should have improved. The preferred and tested numeric range for (current and target) position, velocity, and acceleration values is currently kept at |x| < 1e2. If you get any more errors, please report the input parameters so I can check what's going on exactly. By the way, I've added a ruckig::DynamicDOFs constant to replace the <0> for dynamic DoFs to improve the readability of the code.

[AndyZe]

Yes, I think we are getting close to a good solution. Thanks for the idea on setting the final waypoint exactly - that's a good one.

Would you mind copy/pasting your comment above to the MoveIt discussion? It would show that the lead developer is interested in supporting Ruckig as well as lending some technical support to the PR. The toughest battle with MoveIt PR's sometimes is convincing the group of maintainers to merge something.

[AndyZe]

I'm going to close this issue now because I believe it's resolved.