Frequently Commited Errors by new users. #1082

I have been dealing with certain bugs that are frequently being committed by new users around me. Here I'll try to make a list of those. I will keep editing this issue to add new questions/bugs as they arrive. If you feel there is certain bug that happens frequently in crocoddyl, please don't hesitate to add it here.

1)[shootingProblem]: Default timeStep in terminalModel, for an integrator.

IntegratedActionModelEuler has a default time of 1e-3. So users are creating runningModels without specifying the time, and in the same vein, terminalModel without specifying the time (since it is a default in the constructor). However, terminalModel needs the time to be zero in the formulation they have in mind.

2)[shootingProblem]: Default timeStep=0 in runningModel for an integrator.

In crocoddyl API, setting timeStep=0 automatically assumes that the model is a terminalModel. The user intent is to do an integration with dt=0, however, what happens is that integration is disabled.

3)[shootingProblem]: runningModels contains pointers to the same memory.

Very often in python, and sometimes in c++ as well, user creates an ActionModel, and creates a shootingproblem like this:

model = crocoddyl.SomeActionModel()
problem = crocoddyl.ShootingProblem(init_state, [model]*T, model)

What is expected is that the list runningModels inside the shootingProblem would contain different memories, and changing problem.runningModels[0] would not affect problem.runningModels[1]. What is actually happening is that the same pointer is being copied, and changing any one model changes all models.

Same issue in c++, where new users don't realise that very often what they are providing to the shootingProblem is not a list of ActionModels, but a list of pointers pointing to the same memory location containing an ActionModel.

4) math behind activationModels, costModels .

There is no cheat-sheet that we can refer to quickly see which function implements what mathematical formula.