Silvio Traversaro
Silvio Traversaro
cc @lrapetti this is the main issue regarding the InverseKinematics. See also all other issues with the IK label: https://github.com/robotology/idyntree/labels/Component%3A%20InverseKinematics .
I see.. I am just delaying all the fixes that are not immediate to finally get travis back to green.
Similar error in GitHub Actions: https://github.com/robotology/idyntree/pull/568/checks?check_run_id=206937776 / related commits: e03f88a . .
Note, this was happening on Ubuntu 18.04 with the system installed ipopt. This issues seems related to https://projects.coin-or.org/Ipopt/ticket/285, that was migrated to https://github.com/coin-or/Ipopt/issues/285 . The issue was closed on the...
Previous related comment that provides a bit more background: > By definition, all BLAS and LAPACK implementation share the same headers as they have the same ABI, so compiling against...
I think https://www.astro.rug.nl/software/kapteyn/_downloads/attitude.pdf could be a good reference document to refer to for implementing the different Euler angles / RPY conventions.
Relevant YARP issue : https://github.com/robotology/yarp/issues/635 . One problem not addressed in https://www.astro.rug.nl/software/kapteyn/_downloads/attitude.pdf that in the past caused problem when working with [Eigen eulerAngles function](https://eigen.tuxfamily.org/dox/group__Geometry__Module.html#gad118fececd448d7485ffea4858775e5a) is that to fully define a...
As far I understood @CarlottaSartore is using it well (I guess on apt with irrlicht 1.8.4), so it may be indeed a Irrlicht 1.8.4 vs 1.8.5 regression.
Probably it is sufficient to add a `name` attribute with `getName` `setName` accessors in https://github.com/robotology/idyntree/blob/a52e9240df154bcc752f438b73a67baabbebaaf9/src/model/include/iDynTree/Model/Model.h#L151 , and then use the `setName` in https://github.com/robotology/idyntree/blob/db312bfe9f490f991250603f05cea84a8c156899/src/model_io/urdf/src/RobotElement.cpp, as done for example for the `link`...
> Perhaps we could solve by adding to all types that could be spann-able a {to/as}Span() method? cc @GiulioRomualdi Personally if the alternative is the need to add `.asSpan` to...