Not having the comparable optimization result with Theseus compared to CasADi?
Jeff09 opened this issue · comments
❓ Questions and Help
I'm currently using CasADi with the following parameters:
optimizer.solver("ipopt", {"ipopt.print_level": 0, "print_time": 0, "ipopt.sb": "yes", "ipopt.max_cpu_time": 0.35})
Its optimization error log looks like the following.
While I change it to Theseus using the following parameters.
layer = th.TheseusLayer(
optimizer=th.LevenbergMarquardt(
self.objective,
linear_solver_cls=th.CholmodSparseSolver,
vectorize=False,
max_iterations=max_iter,
step_size=step_size,
abs_err_tolerance=abs_err_tolerance,
adaptive_damping=True
),
)
The optimization error log looks like the following.
It can tell that the theseus optimizer is not as efficient as CasADi. And also the theseus optimizer can take longer time to converge even though it's already on GPU.
Do you have any ideas on what could be causing this issue? And is there any other possible methods to have the comparable performance as CasADi?
Thank you so much.
Hi @Jeff09. There are a number of hyperparameters to try. When using LevenbergMarquardt
, you can also try ellipsoidal_damping=True
and also play a bit with the following keywords (all of type float
):
step_size
damping
down_damping_ratio
up_damping_ratio
damping_accept
Ideally, if you can share some minimal code that reproduces this error, it would help us give you better advice, or debug our implementation.
@luisenp Thank you for your advices. I have tried ellipsoidal_damping=True
and different step_size
and different damping
, and also set adaptive_damping=True
. However, those results still can't have the comparable performance as CasADi optimization.
The main reason might be there's no hard constraints in the theseus optimization. The solutions optimized from theseus look like not as smoothing as those from CasADi. And it's very important to add some dynamic constraints when finding the best solution for motion planning task.
Do you have any advices on how to add hard constraints in the optimization?
Unfortunately, we don't have yet support for constraints. We started working on this in #457, but other priorities have slowed down development of this feature.
Two things you can try are:
- For constraints that try to set an optim vars to a target, you can try adding a
th.Difference
cost between the optim var and the target value. - For inequality constraints affecting a single optim var, you can use HingeCost.
In both cases you should set the associate weight to be a very large value relative to all other weights. The tricky part is balancing the weights of all the different cost functions. In my experience in motion planning, this can affect the quality of results significantly.
Can you share what form do your constraints take?
@luisenp Thank you for you advices.
The constraints I used is mostly equality constraints, like maximum curvature turning rate, maximum acceleration, maximum speed, maximum yaw rate, initial position constraints, and also some dynamic constraints. Do you suggest using th.Difference
cost to handle equality constraints?
I have tried using HingeCost
to transform those above equality constraints to inequality constraints with a large associate weight relative to all other weights. However, it doesn't have better performance.
Would it be possible for you to share a small problem where the output you get with Theseus doesn't match the output you get with CasADi, and also share the reference solution? It doesn't have to be your full application; just anything that results in similar behavior to what you are seeing. I'm really interested in taking a deeper look at this, but it's hard w/o being able to easily reproduce your error.
Hi @luisenp, Thank you for your advices.
Could you give me your email where I can sent the sample code?
Sorry for the delay, it was a long weekend here. You can use my email listed in this paper.
As a quick comment, a couple of days ago I solved some issues in some motion planning experiments I'm doing, which were caused by instabilities around near-zero log maps in SE2 data (with 64-bits). Not sure if that's the case for you, although I was getting paths that were visually similar to yours. The solution was to add these lines at the top of my script
th.constants._SE2_NEAR_ZERO_EPS = th.constants.EPSDict(
float32_eps=3e-2, float64_eps=1e-3
)
Could you try this to see if it makes any difference for you?
Apologies, the email filtered out the attachment due to security reasons. Considering that you are only sending a single notebook, could you make a PR to our repo with the file?
It this is not possible, perhaps you can create a Colab and share it privately?
There're multiple files that are used at the single notebook. I have uploaded them to the shared drive and also send the shared link to your email. Hopefully, you can have access to the code.