bip-team / humoto Goto Github PK

Currently, QP solvers can only be used to solve optimization problems with two levels. We need to add support for solving hierarchies consisting of larger number of levels using sequences of QP's.

The log file format is parsable by Matlab/Octave. Consider alternative formats, e.g., python.

We should investigate possibility of adding support of LP problems in the framework. They can be useful in some cases.

Some of our collaborators use JSON format for configuration files. It may be a good idea to add support for this format in Humoto.

Remove assumption on alignment of the feet in the initial / final DS.

After first installation of humoto with make all. test_000 returns:
./test_000
In readNestedConfig() // Failed to parse node in the configuration file: In readScalar() // Configuration file does not contain entry 'solve_two_levels_as_qp'.

Result of 'A^T * A' can be reused if the task is not modified from one iteration ot another.

In order to enable implementation of hotstarting with precomputed factorizations we have to

• keep track of modifications in the tasks
• keep track of modifications in the hierarchy
• store factorization of Hessian obtained on the preceding iteration

Currently, angular velocity changes abruptly, e.g., it may intantly increase from 0.0 to the given constant value. It would be nice to smooth such changes. May be even introduce additional MPC problem for rotations.

• Remove limit on the number of steps.
• Support online change of reference velocities.

We can drop dependency on GoogleTest and use Boost.Test instead -- we already depend on Boost anyway.

We have recently experienced a problem with CI service provided by INRIA: our virtual machines with their configurations were lost.

It is therefore important to consider a possibility of using of other free CI services. The main obstacle for this is that we also have to test non-public code and we don't want it to leak. If we decide to use some external CI service for public code only, the maintenance costs increase.

In any case we must find a way to backup configurations of the virtual machines.

Currently, the compilation of the whole project is rather slow. For this reason, testing of the code may be time consuming. We can address this by compiling the core/modules to static/shared libraries.

Controllers based on Humoto often have to receive commands/parameters from other software. Static configuration files are not always suitable for this purpose. We should decide if we want to add functionality to enable online/remote interaction with modules, and, if yes, how exactly it must be implemented.

I've already sent a brief review of possible options in the mailing list, it can be a starting point.

Project web-page branch (gh-pages) is quite heavy. Consequently, cloning and pulling (after update of gh-pages) takes time and space.

We may want to create a separate project for documentation, or find some other workaround.

WPG03 is currently unsupported. It is unlikely that we will invest resources in its further development. This could be a good reason for creation of a separate repository for this module to reduce maintenance costs.

Bounds on the translational velocities imposed in the MPC do not properly reflect the actual limitations of the wheel motors, especially when rotation is performed in addition to translation. We need to improve the bounds.

Current approach to handling of time intervals, when the same interval is often stored using separate variables in seconds and milliseconds, is unsatisfactory and must be revised. We may also want to use microseconds.

Currently, configurable classes are reset before a configuration file is read. We may want to avoid this, i.e., to set only those parameters, which are specified in the configuration file.

It is possible to solve a hierarchy of two levels with inequality tasks on the second level as a QP. This can be done by introducing slack variables explicitly and pushing the inequalities to the first level. Some architectural changes are necessary for this to work: weighting of the tasks must be handled differently, handling of solution vector must be changed, etc.

We hardly need this feature, consider this issue as a note.

Guys, I guess the problem that you have is that you are not using GNU linker on MAC OS. Note that "HUMOTO_SHARED_GNU_LINKER_FLAGS" was intended to be used with GNU linker only (as suggested by the name of the variable). If the linker is different, don't use these flags at all.

Ideally, we should identify the linker and set flags accordingly -- configuration must be specific to a linker, not a platform.

Consider implementation of our own spatial vector class with basic operations.