Not having the comparable optimization result with Theseus compared to CasADi?

[Kun Li]

❓ 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.

[Luis Pineda]

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.

[Kun Li]

@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.

Here's some result figures.

Do you have any advices on how to add hard constraints in the optimization?

[Luis Pineda]

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?

[Kun Li]

@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.

[Luis Pineda]

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.

[Kun Li]

Hi @luisenp, Thank you for your advices.

Could you give me your email where I can sent the sample code?

[Luis Pineda]

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?

[Luis Pineda]

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?

[Kun Li]

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.