loco-3d / crocoddyl Goto Github PK

In GitLab by @proyan on Nov 13, 2018, 15:41

In GitLab by @cmastalli on Nov 15, 2018, 10:45

This unit-test uses the spring-damper system. So first we need to work on issue #3.

In GitLab by @cmastalli on Nov 16, 2018, 12:31

null

In GitLab by @cmastalli on Nov 9, 2018, 14:34

This feature was partially developed in the previous code structure, and it completely removed in the ongoing one.
Having these data classes will allow us to have additionally improvements such as zero computation of Jacobian or Hessian which are constant.

@rbudhira Do you have any feedback regarding this topic?

Hi, I try to run example in crocoddyl, but the library seems outdated in python.

Can you check?

No actionmodelimpact model appears.

Traceback (most recent call last):
File "walk.py", line 5, in
from crocoddyl import (ActionModelImpact, ActivationModelWeightedQuad, ActuationModelFreeFloating, CallbackDDPLogger,
ImportError: cannot import name ActionModelImpact

In GitLab by @proyan on Oct 11, 2018, 16:30

Create class structure for storing contact information.

In GitLab by @cmastalli on Nov 15, 2018, 17:34

This defines addition and difference operators of the geometrical manifold of a given system. advanceConfiguration is typically used to integrate the geometrical system, instead differenceConfiguration to differentiate a geometrical system (for instance for computing a state feedback).

In GitLab by @proyan on Nov 14, 2018, 08:44

I have started moving the dynamics class, since it is the most independent one. I will create the python bindings and keep the current API

In GitLab by @nmansard on Dec 19, 2018, 11:05

I pushed a new branch topic/refact. The name is possibly not properly chosen. It contains a DDP and a KKT solver developed from scratch with the complete unittest (without regularization yet). Here is a description of the work.

• Dynamic and cost functions are merged into a single class, named ActionModel and ActionData. The class is mostly able to compute the transition function (xnext = f(x,u)) and the cost function (cost = l(x,u)): this is a the calc(x,u) method, returning both the next state and the cost ; and a calcDiff(x,u) method which computes the useful derivatives of calc. A LQR and a unicycle model are implemented, as well as a num-diff extension of existing models.

• The current DDP class is divided into the problem formulation (SingleShootingProblem) and the solver (SolverDDP and SolverKKT). The problem class is composed of running action models RunningModels and terminal action model TerminalModel, with corresponding data. It is able to calc(xs,us) and calcDiff(xs,us) along the trajectory.

• Both solvers respect the same organization: computeDirection (equivalent to inverting the KKT or backward DDP pass), tryStep(stepLength) (equivalent to x+dx for KKT and forward pass for DDP), and test a step (expectedImprovement) and the algo stop (stoppingCriteria). The main method is solver.solve(maxiter,init_xs,init_us,isFeasible=[True|False]). Note that both solvers are able to warm start from a non feasible trajectory (i.e x(t+1) != f(xt,ut)).

• Unitest are proving the DDP and KKT have the exact same behavior for a LQR system (for both feasible and unfeasible init guess), and same behavior on NLP when warm-started from a feasible guess. An integrative test also shows that KKT and LQR converges to the same solution on the unicycle problem.

In GitLab by @nmansard on Nov 28, 2018, 09:43

In GitLab by @cmastalli on Nov 15, 2018, 10:50

Analytic derivatives of the constrained forward dynamics (i.e. floating-base dynamics).

In GitLab by @cmastalli on Nov 19, 2018, 19:25

Currently, these vectors are updated inside the DynamicsModel.

In GitLab by @cmastalli on Dec 24, 2018, 14:28

Extend #45 for multiple-phases.

In GitLab by @cmastalli on Nov 9, 2018, 14:06

We need to have the same behaviour for the HyQ and Talos arm problems. So first we need to work on issue #5.

In GitLab by @cmastalli on Nov 15, 2018, 11:06

An user should be able to change only two main things:

1. the computation of f(x,v,u), and
2. the linear approximation of f(x,v,u).

The current names are forwardCalc and backwardCalc. This names have a sense for DDP but no meaning inside the concept of the dynamics. Indeed DDP during its forward-pass needs to update the dynamics and its backward-pass to update the linear approximation of the dynamics.

Therefore these methods should be renamed as:

1. updateDynamics
2. updateLinearAppr

In GitLab by @cmastalli on Nov 15, 2018, 17:27

Instead the integrator class depends on dynamicModel and dynamicData. This task requires to solve first #20.

In GitLab by @proyan on Nov 2, 2018, 04:47

Currently during backward pass the pinocchioData is being changed because of the finite differences.

In GitLab by @cmastalli on Nov 15, 2018, 10:49

In GitLab by @cmastalli on Nov 15, 2018, 11:00

All dynamic problem as the form of:
[v; a] = [v; f(x,v,u)]

and its linearise model is:

[dv; da] = [0, I; fx, fv]*[dx; dv] + [0; fu]*du

where dx is the linearised configuration point. Note that the linearised point belongs to the tangential space.

This abstraction allows us to implement ABA dynamics, constrained forward dynamics, linear systems, etc. Both are implement in f(x,u,v).
Furthermore we can reuse the numerical differentiation (NumDiff) routines. Indeed, we just need to NumDiff only in the lower-block (see linearised dynamics)

In GitLab by @cmastalli on Nov 15, 2018, 11:26

cddp isn't a good name, it's not fun neither.

I put few keywords and generate the different options. @rbudhira and @nmansard please feel free to have a feedback/opinion.

These are some examples. Please let discuss about it

In GitLab by @cmastalli on Nov 15, 2018, 10:44

This unit-test uses the spring-damper system. So first we need to work on issue #3.

I followed the procedure of instructions in GitHub, but it doesn't work on Mac

In GitLab by @nmansard on Dec 21, 2018, 16:05

Here is a quick list of the main tasks for the next 15 days.

Make sure the solver run good and nice.

1. unittest the regularization auto setup (#18, #35).
2. validate with integrative tests on the manipulator arm (#43).

Implement the phased dynamics on the quadruped

3. validate the solver for tracking a COM on fixed contact.
4. validate the solver on a single phase with terminal contact constraint. The constraint can be modeled by any possible mean, although we should first validate that penalty based method with simple gain tuning is sufficient (#44).
5. validate the solver with two phases: first phase with a flying contact and a terminal "constraint" and a a second phase with only fixed constraint (#45).
6. extend the previous system with several phases (#46).
7. introduce the analytical derivatives for the dynamics in contact (#16,#52).
8. formally study the meaning of KKT dynamics, with respect to introducing a state constraint in the OCP. It is possible that the two problems are equivalent. In such a case, it might be better to directly handle the contact constraint as a state constraint, either with penalty or aug-lag (#47).

Implement on the biped.

9. introduce the biped model (#23).
10. introduce flat foot contact constraint (#50).
11. make a OCP with the humanoid and flat foot (#23).

Refactoring.

12. understand the refact code, and discuss it (#48,#39).
13. possibly start to implement the refact structure in the main tree.

In GitLab by @cmastalli on Nov 23, 2018, 12:45

This integrator and discretizer were defined in the previous software structure. You can see the code here:

• integrator: https://gepgitlab.laas.fr/loco-3d/cddp/blob/master/cddp/math/integrator.py#L134
• discretizer: https://gepgitlab.laas.fr/loco-3d/cddp/blob/master/cddp/math/discretizer.py#L152

In GitLab by @cmastalli on Nov 15, 2018, 10:42

This unit-test uses the spring-damper system. So first we need to work on issue #3.

In GitLab by @nmansard on Dec 20, 2018, 10:47

The DDP solver is an SQP solver which optimize with the decision variables xs,us, so that F(xs,us) = 0, with F a stack of dynamic constraints f(x,u) - xnext = 0. The main difference between a DDP solver and a classical SQP solver (for example KKT based) is that in DDP there is a explicit way to project a candidate xs,us on the constraint (by making a rollout). Indeed, we tend to produce the initial guess by using this explicit projection. I believe that this is a mistake, because finding a us that does not make the xs very bad is difficult and expensive.

On the other hand, the DDP solver, like any SQP solver, should be able to find a good feasible candidate pair x1s,u1s from a bad unfeasible pair xs,us. But does that make a sense to run a backward pass from an unfeasible pair xs,us ?

In term of implementation: yes it is acceptable: all derivatives are computable, hence the backward pass can be run. But then the Value derivatives Vx' are computed at xguess', and xguess' is not f(xguess,uguess). So we need to "relinearize" to move Vx' computed at xguess' to Vx' computed at f(xguess,ugess).

The trick (well mathematically it is exact, so not exactly a trick) is easy. But I was not able to find this trick in the literature. I also double check that we have the exact same behavior than a KKT in case of LQR problem and infeasible initial guess.

I've installed crocoddyl from the robotpkg binaries and it is correctly sourced. The package robotpkg-example-robot-data is installed. However, I get:

Traceback (most recent call last):
  File "bipedal_walking_from_foot_traj.py", line 6, in <module>
    import example_robot_data
ImportError: No module named example_robot_data

In GitLab by @cmastalli on Dec 6, 2018, 17:33

Job #8702 failed for f45792a:

@nim65s I think we need to include numpy block.

In GitLab by @cmastalli on Nov 9, 2018, 14:08

This abstract class will help to implement both quadruped and manipulator task. This was a previous feature that it has been removed

In GitLab by @cmastalli on Nov 15, 2018, 11:10

We should provide an abstraction for computing the NumDiff, so the users can quickly test a system. NumDiff routines are needed to compute the linear approximation of the dynamics (see issue #19). Having solved the issue #19 and #20, we can defined by default the updateLinearAppr by running a NumDiff routine.

The user can still deploy its analytical derivatives or potentially other methods such as automatic differentiation.

In GitLab by @cmastalli on Nov 27, 2018, 10:04

null

In GitLab by @proyan on Nov 2, 2018, 04:46

The API of the dynamic class has been changed. We need to put back the equations this system in the new code structure.

In GitLab by @proyan on Oct 4, 2018, 13:36

• Do no more than one computation per time step.
• Collect system-data and cost-data elements

In GitLab by @cmastalli on Dec 24, 2018, 14:17

null

In GitLab by @cmastalli on Dec 24, 2018, 14:22

First phase with a flying contact and a terminal "constraint" and a a second phase with only fixed constraint.

In GitLab by @cmastalli on Dec 24, 2018, 14:18

The constraint can be modeled by any possible mean, although we should first validate that penalty based method with simple gain tuning is sufficient.

In GitLab by @proyan on Nov 13, 2018, 15:40

Relate to #8

In GitLab by @nmansard on Nov 28, 2018, 09:52

The unit test list should be as follows:

1. DDP converges in 1 step for LQR systems
2. DDP and KKT for LQR matches
3. num-diff versus algo diff
4. stopping criteria unit test (tbf, possibly compare with KKT)
5. regularization unit test (test that backward pass with regularization or with control cost is equal)
6. regularization tuning test (tbf)

We may also want to add an integrative test with the arm (and later with legged robots), i.e. comparing the numerical results of the test with a reference execution.

Unit-test validation before merge-request, implemented by @nim65s should be active.

When all that points are matched, close the milestone unittest.

In GitLab by @cmastalli on Nov 9, 2018, 14:03

An important benchmarking task is the manipulation one. It also help us to debug the performance of the new code structure

In GitLab by @cmastalli on Nov 21, 2018, 17:55

The FloatingBaseMultibodyEuler(Integrator/ExpDiscretizer) classes describes general integration or discretization rules. This is possible thanks to task #29. However, before doing such kind of generalization, we need deal with #26.

In GitLab by @cmastalli on Nov 15, 2018, 10:51

In GitLab by @cmastalli on Nov 15, 2018, 17:35

null

In GitLab by @cmastalli on Dec 19, 2018, 16:58

Before incorporating any logo, we should have first few proposals. Feel free to make your contribution :)

In GitLab by @nmansard on Nov 15, 2018, 11:45

In GitLab by @cmastalli on Nov 15, 2018, 10:51

In GitLab by @nmansard on Dec 3, 2018, 07:57

In GitLab by @cmastalli on Nov 23, 2018, 13:14

I suggest to have different level of printing, and follows the same rules of Ipopt.

In GitLab by @nmansard on Nov 15, 2018, 11:56

As we are not using a trello-like board (not available in gitlab), we have to play with labels to obtain a similar effect. I suggest using "assignee" to "book" a task, which means you intend to work on this task now or in the future. Then, label a task as "on-going" if you are effectively working on the task. It is intended that you have only ONE task on-going, and that results about this task should be delivered at the end of the day.
Every task should be feasible in 10 hours of work. Otherwise, the task should be subdivided. In that case, by hierarchical: keep the task open, and open subtasks that should be referred to the initial task.
If for some reasons you are not able to deliver the work by the end of the day, commit it to a dedicated branch topic/ongoing_taskid . The last commit may be labeled as partial with the initial keyword [PARTIAL]. Once the task done, the commits may be refactored and the branch topic/ongoing_taskid should be destroyed. In this case, it is acceptable that the the last commit contains craps, as it is only used to backup. Providing partial commit is useful in case of delay (personal latency for example) that allows coworker to take over the lead on an ongoing task.

In case you open such a temporary branch, dont hesitate to comment it in the issue thread.

In GitLab by @nim65s on Nov 27, 2018, 15:57

Hi,

JFYI, @nmansard asked me to launch python unit tests in merge requests. This will be done soon.