Becomes obvious when running NLOC_MPCTest with single-precision or in debug mode.

Some users reported the following behavior:

• when the ct_rbd unit tests are run with --this --no-deps on Ubuntu 18.04, the operating system freezes after a few seconds.
• there is likely a race-condition hidden somewhere, since it works perfectly when setting the additional flag -j1
• interestingly, this behaviour does not show on Ubuntu 16.04 and 14.04.

TODO:

• verify issue

check out gtest from remote rather than requiring local installation.
Use approach 4 as described here.

In order to get this done, there are 2 options

• download gtest as external project in all 4 ct - modules. This does not seem clean.
• create a large ct cmake-metaproject and install gtest only once. In this case, all ct modules would share most information, i.e. gtest. It remains to be discussed of this is a good direction to take, since it may affect the independence of the modules in the long term.

remove legacy documentation (v2.3) from bitbucket.io to avoid confusion

Problem 1: kindr assert-macros in kindr/common. Affected are both assert_macros and assert_macros_eigen. Proposed short-term solution: the assert macros are subject to the "NDEBUG"-flag , which can for example be set by compiling in Release mode (-DCMAKE_BUILD_TYPE=Release)

Problem 2: many rotation types in kindr feature a so-called "fix()" method, for example to normalize a RotationMatrix or a RotationQuaternion. This fix() method may break JIT. Proposed long-term solution: introduce a flag into kindr which allows to skip all fix() methods.

Problem 3: conditionals and methods in Eigen3 that behave undeterministically at JIT compile-time. Example: constructing an Eigen::Quaternion from a rotation matrix, e.g. when doing something like Eigen::Quaternion<SC> q (Eigen::Matrix<SC, 3, 3>) . Potential long-term solution: specialize these conversions for CppAD.

In other words:

large range of methods available in kindr and Eigen rotation types are currently not JIT compatible. Note that they are still compatible with normal CppAD automatic differentiation, which is a strong argument for also bringing back the normal CppAD procedures into CT.

the current implementation of the TaskSpaceCost functions avoids Quaternions. A limitation is that RobCoGen only produces Homogenous transforms, therefore we are currently limited to using rotation matrices in there.

Examples for failures:

all Task-Space cost functions will fail when not built in Release-Mode

a number of unit tests will fail when not built in release mode, see rbdJITtests in ct_rbd

the following kindr and Eigen JIT tests fail in any case (see kindrJITtest.h) :

KindrJitTest.EigenRotationMatrixToEigenEulerAnglesTest

KindrJitTest.EigenRotationMatrixToAngleAxisTest

KindrJitTest.RotationMatrixToKindrRotationQuatTest

KindrJitTest.KindrRotationMatrixToEigenRotationQuatTest

KindrJitTest.KindrRotationMatrixToEulerAnglesXyzTest

KindrJitTest.EigenRotationMatrixToEigenEulerAnglesTest

KindrJitTest.EigenRotationMatrixToAngleAxisTest

KindrJitTest.RotationMatrixToKindrRotationQuatTest

KindrJitTest.KindrRotationMatrixToEigenRotationQuatTest They are currently _DISABLED

Earlier versions of the CPPAD-interface explicitly include the CppAD header
#include <cppad/example/eigen_mat_inv.hpp>
This header got moved around in the recent releases of CppAD causing version incompatibility.

In the current version a 1-1-0-0-double system does not compile.
How to handle P_DIM and V_DIM properly internally for SISO systems?

change it to something like this:
UniformNoise(const double mean = 0.0, const double r = 1.0) : rd_(), eng_(rd_()), distr_(mean - r, mean + r) {}

Does this codebase need a specific version of the cppad library?
When I build the repository, it fails because a file is not found:

In file included from ~/ws/ct_ws/src/control-toolbox/ct_models/include/ct/models/InvertedPendulum/codegen/InvertedPendulumActDynLinearizedForward.h:8:0,
                 from ~/ws/ct_ws/src/control-toolbox/ct_models/include/ct/models/InvertedPendulum/codegen/InvertedPendulumActDynLinearizedForward.cpp:6:
~/ws/ct_ws/devel/include/ct/core/core.h:15:10: fatal error: cppad/cg.hpp: No such file or directory
 #include <cppad/cg.hpp>

I can't find that file in the latest version of the CppAD repo.

old libraries accumulate in workspace

Forward hpipm and blasfeo interface to release 0.1.2 (upcoming)

in order to allow for finding IPOPT after it's been installed as a debian package.

• users may install ipopt via sudo apt-get install coinoir-libipopt-dev

In order to achieve this:

• add find-script for IPOPT

On v2.2 @hamzamerzic had reported the following:

The settings files are quite cluttered and confusing right now.

Looking at the example in NLOC_MPC example in ct_optcon there are three types of settings mentioned there:

NLOptConSettings ilqr_settings;
NLOptConSettings ilqr_settings_mpc;
ct::optcon::mpc_settings mpc_settings;

I think this could be done in a nicer and more systematic way. Maybe implementing methods like

void setFromFile(const std::string& filename, const std::string& ns, bool verbose)

in each class for which we wish to have this functionality.

@jcarius had reported the following:

Some configurations* of Clang++ cannot compile parts of the cppad cg code:

/home/USERNAME/catkin_ws/src/ct/ct_core/include/external/cppad/cg/patterns/iter_equation_group.hpp:253:68: error: default initialization of an object of const type 'const std::map<size_t, std::set<size_t> >' (aka 'const map<unsigned long, set<unsigned long> >') without a user-provided default constructor const std::map<size_t, std::set<size_t> > IterEquationGroup<Base>::EMPTYMAPSETS;
The issue is summarized in this Stackoverflow Question

(*) Yet unclear what causes this, on another machine clang worked fine.

I would like to use a very fast C++ library for DDP (differential dynamic programming) but I couldn't find one online. I was hoping the toolbox has it, but I couldn't find it here either. If you guys are familiar with any C++ DDP implementations out there, could you recommend them to me?

In any case, I believe adding DDP to the control-toolbox would be a great feature. Especially if it utilizes Auto-Diff codegen.

Currently im trying to compille my code external workspace after installing the library using CMake adding ct library. But I keep getting the below error :
`In file included from /usr/local/include/ct/core/core.h:18:0,
from simple_oscillator.cpp:1:
/usr/local/include/cppad/example/cppad_eigen.hpp:16:11: fatal error: Eigen/Core: No such file or directory

include <Eigen/Core>

       ^~~~~~~~~~~~

`
Is there a template CMake that can be used to use ct_core library externally?

• in oder to avoid the issue that ct-v2 hpipm and blasfeo versions do not provide an installation routine. Exporting dependencies is therefore not solid.

To check:

• licensing issues may occur. The current releases of hpipm and blasfeo are GPL 3.0, while our currently used version was released under L-GPL.

Currently, the DMS-package does not distinguish between box constraints of form

u_lb <= u <= u_ub and x_lb <= x <= x_ub,

and general constraints of form

d_lb <= g(x,u) <= d_ub

When setBoxConstraints() is called in the DMS Constraint Discretizer, all box constraints are mapped back to general inequality constraints.

Treating them explicitly as box constraints might be advantageous in some cases.

On v2.2 @hamzamerzic had reported the following:

In the current implementation in order to control the system, we need to create a controlled system that holds a controller as a member. In practical scenarios, we often wish to evaluate f(x, u), where f is the system dynamics. In order to do that, every time we need to create a new controlled system, or change the controller on the actual system, which IMHO can be quite tedious and bug prone. Also, having the system completely stateless keeps it thread safe, in case the same system is used on different threads - e.g. control and estimation. My proposal would be to restructure the code in such a way that the integrator takes in the controller or controller action as a parameter.

This is just an idea, but I am curious what you think.

First occurrence: ct_core (where it should be!) second occurrence: ct/rbd/internal/ ...

code already developed but needs refactoring and cleanup

@jcarius has proposed the following inspiration

std::default_random_engine generator;
SCALAR mu(0.0);
SCALAR sigma(1.0);
std::normal_distribution<SCALAR> distribution(mu, sigma);
auto normal = [&] (SCALAR)->SCALAR {return distribution(generator);}; // dummy argument required by Eigen

Eigen::Vector3d randVec = Eigen::Vector3d::NullaryExpr(normal);

First off, great job on this project and thank you for developing it! It pleases me to see such a toolbox available openly.

I was wondering if there are plans for creating python bindings for this C++ project. It would increase the appeal of this project and increase its ease of use. Using something like https://github.com/pybind/pybind11 would go a long way.

Except for the numerical system linearizer, the time or index is ignored => Assumes that the system is not time-dependent.

In a prior version, a user reported issues with NLOC-linesearch when using nThreads > 1. It seems that the behaviour was sometimes not deterministic.

• introduce test case which covers this bug

Todo:

• in sensitivity integrator, all threads are writing on the same A,B?

Catch up and adapt interfaces to results of giaf/hpipm#76 once applicable.

The LQOC Problen and the HPIPM Interface have settled on the convention that the box constraints are always given in the order [u, x]. Box constraints must be added according to this order. In case the order is not fulfilled, the NLOC Backend throws an exception (as of v2.3 onwards).

Todo:

• come up with clean solution

We use very few kindr-methods only, it may be worth considering dropping the kindr dependency totally.

• packages would become more lean
• users would not have to install kindr separately

Todo: decouple summary computation and retrieval. Note that computing the summary is not for free, so maybe introduce two settings: "computeSummary" and "printSummary".

@johuber had reported the following for v2.3

When I try to compile with either of the in the explicit_templates.cfg file, several compile errors occur.

Config:

STATE_DIM=4, CONTROL_DIM=2, POS_DIM=0, VEL_DIM=0, SCALAR=double STATE_DIM=4, CONTROL_DIM=2, POS_DIM=0, VEL_DIM=0, SCALAR=ct::core::ADScalar STATE_DIM=4, CONTROL_DIM=2, POS_DIM=0, VEL_DIM=0, SCALAR=ct::core::ADCGScalar

Errors:

/ct/ct/ct_core/include/external/cppad/local/ad_ctor.hpp:172:10: error: no matching conversion for functional-style cast from 'const CppAD::AD<double>' to 'CppAD::cg::CG<double>'

/ct/ct/ct_optcon/include/ct/optcon/constraint/term/StateConstraint-impl.h:99:9: error: no matching member function for call to 'setConstant'
    jac.setConstant(1.0);

/ct/ct/ct_optcon/include/ct/optcon/constraint/term/ControlInputConstraint-impl.h:118:9: error: no matching member function for call to 'setConstant'
    jac.setConstant(1.0);

Hello

I'm facing several compilation errors :

/usr/local/include/ct/external/cppad/cg/patterns/index/index_pattern_impl.hpp:41:60: error: no matching function for call to ‘max(long unsigned int, std::map<unsigned int, unsigned int>::size_type)’ size_t maxCount = std::min(std::max(3ul, x2y.size() / 4), 8ul);

/usr/local/include/ct/external/cppad/local/pod_vector.hpp:58:25: error: redefinition of ‘bool CppAD::is_pod() [with Type = unsigned int]’ template <> inline bool is_pod<size_t>(void) { return true; }

/usr/local/include/ct/external/cppad/cg/model/functor_generic_model.hpp:439:35: error: invalid conversion from ‘size_t*’ {aka ‘unsigned int*’} to ‘long unsigned int*’ [-fpermissive] (*_forwardOneSparsity)(j, &pos, &nnz);

Here is my g++ version
ros@raspi:~/control-toolbox/ct $ g++ --version g++ (Raspbian 8.3.0-6+rpi1) 8.3.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I don't really know why it doesn't works for me but works for other... Is there a specific version of g++ of some flags to give him ?

Thanks in advance

I just updated to v3.0.2 and had an error compiling my catkin workspace. The CT core still tries to include files from the "cppad/examples/" folder you guys had a while back. Lines 21 and 22 in this file point to files that do not exist: core.h

For the time being, version 3.0.1 works for me. When you can, please look into this.
FYI: On my system, I am running Ubuntu 16.04 with ROS Kinetic, and I installed cppad separately.

(avoid iterative solution using the Dynamic Riccati Equation)

@jcarius had reported the following:

It would be helpful if one can quickly identify if generated code is outdated and should be updated. An easy fix is to include a time-stamp in the file as a comment or possibly the complete original file (in case of system linearizations for example)

porting ct_ros to github has been started. First examples can be found here

Todo:

• clean up docu and add instructions for minimal examples

For example : costfunction-impl.h vs Costfunction-impl.h
resolve by renaming.

List of potentially affected headers:
./ct_core/include/ct/core/common
./ct_core/include/ct/core/control
./ct_core/include/ct/core/geometry
./ct_core/include/ct/core/integration
./ct_core/include/ct/core/internal
./ct_core/include/ct/core/math
./ct_core/include/ct/core/simulation
./ct_core/include/ct/core/switching
./ct_core/include/ct/core/systems
./ct_core/include/ct/core/types
./ct_optcon/include/ct/optcon/costfunction/costfunction.hpp
./ct_optcon/include/ct/optcon/costfunction/costfunction-impl.hpp
./ct_optcon/include/ct/optcon/dms/constraints
./ct_rbd/include/ct/rbd/common
./ct_rbd/include/ct/rbd/internal
./ct_rbd/include/ct/rbd/nloc
./ct_rbd/include/ct/rbd/robot
./ct_rbd/include/ct/rbd/state
./ct_rbd/include/ct/rbd/systems

• currently only catkin cools (with ROS kinetic) is tested in travis
• builds get cancelled after 50 min runtime, i.e. we cannot test both building with catkin and building with cmake due to time constraints.
• builds get cancelled after too many printouts. It is difficult to find the right level of verbosity to prevent travis from cancelling while still getting out useful information.

The example robot arm model should be replaced by something more convenient to users, i.e. UR10, Franka Panda, etc.

@jcarius has reported the following:

The method void push_back(const T& data, const SCALAR& time, const bool timeIsAbsolute) is unsafe in DiscreteTrajectoryBase:

if the user specifies timeIsAbsolute=false, access to time_.back() might segfault or cause undefined behavior because time vector could still be empty.

@jcarius had reported the following

Many classes use their own typedefs such as

typedef Eigen::Matrix<SCALAR, STATE_DIM, STATE_DIM> state_matrix_t;

This will lead to implicit conversions between Eigen::Matrix and ct::core::StateMatrix.

Proposed solution As much as possible, re-use base-class typedef

typedef typename Base::state_matrix_t state_matrix_t;

If not available, use the CT type.

and are not usable with rosrun.

It works fine with -DCMAKE_BUILD_TYPE=Relwithdebinfo and Release.

• probably coming from DerivativesJIT

###Expected benefits:

• cross-platform applications
• avoid overhead required catkin tools and ros installations

Goals:

• enable pure cmake support while keeping ros-integration and allowing to build via
  catkin build <ct_package...>

Todo notes:

• prespec-libraries in ct_core do not yet get properly linked
• prespec-libraries in ct_core currently do not get installed using pure cmake
• export plotting dependencies from ct_core properly
• ct_rbd and ct_models have not been touched yet
• current version only works when using "sudo make install" on every package. Libraries do not yet get propagated locally.

See "convex optimization" by Boyd et al.

the term quadratic of a cost function currently takes non-symmetric matrices. There is probably hardly any use case for this.

For example, StateVector extends Eigen::Matrix but includes nothing at all.
It shouldn't be required for the user of a header to include it's dependencies.

I know that there are collective headers that include everthing needed, but they also include a lot of unneeded stuff that just increases compile time.