Questions about some details of the solver

[lrchit]

Hi,

Thanks for your incredible work! Crocoddyl is really fast! I'm using Crocoddyl for some trajectory optimization of quadruped robot and I still have some questions about the process.

I notice that in your example, problem->quasiStatic() is called before calling solver->solve(). I wonder if this should be done every time before calling of solver. If not, what should init_xs and init_us be as initial guess? My understanding is that x_init should be the current state replicated n+1 times, and u_init should be the solution produced from the previous iteration. I'm not sure if I should do "rollout" to obtain a feasible trajectory here.

Moreover, in forward dynamics mpc, the intuitive approach would be using contact forces and joint torques as inputs, but in Crocoddyl contact forces are implicitly considered as constraints through pinocchio::forwardDyanmics(). What are the benefits of doing this?

Lastly, can I customize the dynamics and their discretization modules and then use the FDDP solver in Crocoddyl? I would like to do some other forward dynamics mpcs, in which contact impulse might be determined by states and inputs and thus the motion function is used to obtain qdd, like this: https://arxiv.org/pdf/2312.08961.

Thanks in advance for your response!

Best,
Ruochen

[cmastalli]

Hi @lrchit,

When solving nonlinear optimal control problems, passing an initial guess of the solution is convenient. This is what your question is about. For instance, the quasiStatic function computes quasi-static inputs for given system configurations. This function is generally expensive to run as it requires a pseudo-inverse for contact dynamics.

As you can see in our examples, these simple initialization strategy leads to good convergence in plenty of practical problems in robotics. However, we can implement more appropriate strategies in model predictive control (MPC). For instance, one classical approach is to use the previous MPC solution. Other alternatives can be done via leveraging learning such as demonstrated in one of our works:

• paper: https://arxiv.org/pdf/2001.11751
• video: https://www.youtube.com/watch?v=Io0B0ReDkkE

In forward dynamics cases, the contact forces are implicitly optimized and indeed store them and compute the analytical derivatives as explained at https://arxiv.org/pdf/2203.07554. The benefit of doing this is reducing the number of decision variables, which reduces the computation time.

You can develop your dynamics and solvers; however, these could be unlikely to be merged as Crocoddyl v3 (under development in my lab) has already significant changes in the dynamics and solver API. This is because Crocoddyl will handle optimal estimation problems in the future, as we recently reported in this paper:

• https://arxiv.org/pdf/2403.17161v1

Regards,
Carlos

[lrchit]

Hi, @cmastalli,

Thank you for your prompt reply. I will take a look at your paper. Looking forward to the release of your new version.

Best,
Ruochen