When splitting trajectories at stop points, solve the pieces in parallel for faster solves

[calcmogul]

Each piece would be solved on a separate thread, then merged once all are complete.

[laviRZ]

Not only would this enable multithreading, but it would greatly simplify the problem given to the solver. Currently when playing with Choreo I find that as the path gets longer the solve time gets exponentially longer, making very long and complicated paths, especially when using obstacles, unsolvable most of the time. tl;dr would love to see this implemented.

[calcmogul]

it would greatly simplify the problem given to the solver. Currently when playing with Choreo I find that as the path gets longer the solve time gets exponentially longer, making very long and complicated paths

This is false. The problem's dimensionality alone has no effect on the problem's difficulty. Furthermore, the time per iteration only increases linearly for direct transcription problems due to the sparsity pattern, and the number of iterations to solve is the same if you don't invoke feasibility restoration (which should be the case for well-formulated problems) because each decision variable takes its own step toward optimality during each iteration.

especially when using obstacles

This is what causes the solve time to drastically increase. Obstacles are a beta feature that aren't well-conditioned, so either the duals diverge or the solver enters feasibility restoration more often. Dual unboundedness must be fixed by SleipnirGroup/Sleipnir#483.

Basically, implementing this feature alone won't fix your problem.

[laviRZ]

...so either the duals diverge or the solver enters feasibility restoration more often. Dual unboundedness must be fixed by SleipnirGroup/Sleipnir#483.

I don't quite understand what's going on here, although,

Basically, implementing this feature alone won't fix your problem.

Maybe it won't solve it completely, but it would help tremendously (and it seems much easier to implement?). All you need is to play around with Choreo for a few minutes to see this happen. As the path gets longer, the solve time (with no entry zones, yes...) scales horribly, even when the path is split between many stop points - but if each section of it would be in a different path, it would be solved without a problem.

[spacey-sooty]

but it would help tremendously

Not for obstacles

[laviRZ]

Why not?
I can attach an example project if you'd like, but the way things are right now, if you have a trajectory on one side of the field, and a tiny obstacle on the other side not interfering at all, depending on the length of the existing trajectory, it might be unsolvable because of that obstacle.

[spacey-sooty]

Why not?
I can attach an example project if you'd like, but the way things are right now, if you have a trajectory on one side of the field, and a tiny obstacle on the other side not interfering at all, depending on the length of the existing trajectory, it might be unsolvable because of that obstacle.

Because the issue there is with the way the solver handles the obstacles. Tyler could explain this better but to my knowledge keep out constraints make the problem formulation significantly more complex compared to other constraints. This is what caused the feasibility issues, slow generation etc the fix for the solvers handling of those problems is replacing feasibility restoration with One phase IPM

[laviRZ]

the fix for the solvers handling of those problems is replacing feasibility restoration with One phase IPM

Sure, but as I said:

Maybe it won't solve it completely, but it would help tremendously

You didn't explain why splitting it won't help... In my experience, it doesn't mitigate the issue completely, but at least makes it solvable.

[calcmogul]

You didn't explain why splitting it won't help...

It's a poor workaround for a fundamental issue with the solver (I already explained what that issue is earlier). I'd rather fix the solver properly.

[laviRZ]

You didn't explain why splitting it won't help...

It's a poor workaround for a fundamental issue with the solver (I already explained what that issue is earlier). I'd rather fix the solver properly.

Great but if a half measure that's already planned to be implemented and easier to implement could help in the meantime...

[calcmogul]

It's not actually planned to be implemented. We have other priorities right now.

[shueja]

Obsolete by improved workflow for segmented trajectories as separate paths.