stack-of-tasks / eiquadprog Goto Github PK

The original mention of the license of the code is largely missing.
The code is a copy paster or former code by Andrea.

This should be fixed before any formal release I would say.

Hello, could you please make the licensing of this package more clear ? It is containing both LGPL and GPL licenses, and I understand that it's based on previous work that was under GPL. But in the header files it is first declared as LGPL and then below GPL is mentionned. It looks like the GPL part about uquadprog only, but I would like to be sure about that.

Thanks

As stated by @proyan in stack-of-tasks/tsid#9 (comment) :

We should have benchmarks for the 3 solvers proposed here, and other similar projects available on the web.

Templates print and distance are defined both in

They should be put in one hxx file included in both hxx file.
A PR will follow with a test to check that it is working

Hello, what dose "EIQUADPROG_FAST_REDUNDANT_EQUALITIES = 4 " mean?

I am not sure why but two classes implementations are put in hxx files and not in cpp files.
Because they are not templates this create linking issues when doing a classical use such:
use the object eiquadprog-fast in class A to build the problem,
instanciate class A in a class B which is using A without knowing what A is doing.
A PR is following which implements a test showing the problem.

The solution is moving away the class implementation in a library.

Hi
I think there is a problem with the EIQGUADPROG_TRACE_SOLVER definition

It should be something like this right ?

if(TRACE_SOLVER)
   target_compile_definitions(${PROJECT_NAME} PRIVATE EIQGUADPROG_TRACE_SOLVER)
endif(TRACE_SOLVER)

otherwise it always trace the solver

I was trying to use EqiQuadProg for my example but it was difficult decoding it from test case. If you can add a minimal example with cmake, it will be of great help for understanding and implementation. Also in case we use it in academic setting,then please let us know how to cite the work.

Thanks

Hi, thanks for the sharing the solver.

I found the solution of eiquadprog is different from the one given in Quadratic Programming (Alberto Santini) from the example here.

The setup for eiquadprog is following:

  EiquadprogFast qp;
  qp.reset(3, 0, 3);

  Eigen::MatrixXd Q(2, 2);
  Q.setIdentity();

  Eigen::VectorXd C(3);
  C(0) = 0.0;
  C(1) = 5.0;
  C(2) = 0.0;

  Eigen::MatrixXd Aeq(0, 3);
  Eigen::VectorXd Beq(3);

  Eigen::MatrixXd Aineq(3, 3);
  Aineq(0, 0) = -4.0; Aineq(0, 1) = 2.0; Aineq(0, 2) = 0.0;
  Aineq(1, 0) = -3.0; Aineq(1, 1) = 1.0; Aineq(1, 2) = -2.0;
  Aineq(2, 0) =  0.0; Aineq(2, 1) = 0.0; Aineq(2, 2) = 1.0;

  Eigen::VectorXd Bineq(3);
  Bineq(0) = -8.0;
  Bineq(1) = 2.0.;
  Bineq(2) = 0.0;

  Eigen::VectorXd x(3);

  EiquadprogFast_status status = qp.solve_quadprog(Q, C, Aeq, Beq, Aineq, Bineq, x);

  //The solution found in x = [-3.6, -3.2, 0.0] which differ from the example [0.4762, 1.048, 2.095]

Is the setup of the formulation wrong ?

As this project is used by many other programs, it would be nice to setup a CI to test at least simple programes and the installation.

Best,

Justin

Hi

to compile on a mac with the boost installed by brew, I had to change the CMakeList.txt (line 61-62) to add boost (since it is in /usr/loca/include and not /usr/include):

TARGET_INCLUDE_DIRECTORIES(${PROJECT_NAME} SYSTEM PRIVATE ${EIGEN3_INCLUDE_DIR} ${Boost_INCLUDE_DIR})
TARGET_INCLUDE_DIRECTORIES(${PROJECT_NAME} SYSTEM INTERFACE ${EIGEN3_INCLUDE_DIR} ${Boost_INCLUDE_DIR})

As reported by @jmirabel in humanoid-path-planner/hpp-core#190 (comment), it would be nice to explain why do we have

• eiquadprog
• eiquadprog-fast
• eiquadprog-rt

This should probably go to the README.

@gabrielebndn: could you do that ? :)

@gabrielebndn I just saw that there is a version of Eiquadprog with warm-start capabilities and other juicy features here. It would be great to integrate their work into our version of the solver. This is a (partial) list of what they did on top of the version of eiquadprog I started from:

• Rewitre and optimize QuadProg++ to be fully based on Eigen. This leads to a more readable code, and significant speed up to compute step directons and add/delete constraints.
• Generalize QuadProg++ API to allow passing the inital guess, to export the resulting active-set, to pass a list of inequalities to satisfy first, and options and schedule the inequalities.
• Add various inequality scheduling heuristics:
  • WorstFirst : the default for QuadProg++
  • SlidingWindows: treat the worst of the current subset, and shift/grow the subset (the default for rational_quadprog)
  • WorstSetFirst: treat all the N worst before checking for the others
• Add new options for rational_quadprog:
  _scheduling_mode = args.get_string("scheduling-mode","SlidingWindows"); -> can also be "WorstFirt" or "WorstSetFirst"
  _scheduling_chunk_size = args.get_int("scheduling-chunk-size",-1); -> the default is usually very good
  _scheduling_grow_factor = args.get_float("scheduling-grow-factor",-1); -> not recommended
  _export_qp = args.is_defined("export-qp"); -> export QP problem to files for testing with other solvers
  _delta = args.get_float("delta", 1);
  _add_ls_energy = args.is_defined("add-ls-energy"); -> recommended
• Update rational_quadprog_parallel to reflect API changes