Implement iDynTree base type `type_caster` for pybind11 bindings #931

GiulioRomualdi · 2021-11-06T14:36:36Z

In the past few days, I discussed with @traversaro about the possibility to install also pybind11 bindings with the superbuild.
This will simplify the usage of iDynTree bindings along with bipedal-locomotion-framework. In the end, we can use the same approach of manifpy ami-iit/bipedal-locomotion-framework#238 (comment)

Given that it would be nice to automatically convert iDynTree base types (VectorDynSize, VectorFixSize, MatrixDynSize and MatrixFixSize) to NumPy objects. Accordingly to pybind11 documentation this can be done implement a custom type_caster.
This PR introduces the machinery to automatically convert iDynTree matrices and vectors to numpy.

Furthermore, this PR introduces:

The raw buffer constructor for the Position class. This is required to implement the type_caster
Make rotation and position properties readable and writable in the pybind11 Transform bindings
The rotation matrix is not automatically converted to NumPy since I would like to avoid the user setting a random matrix that is not a rotation one. Furthermore, if it is converted into a NumPy matrix when the inverse is computed python will not exploit the rotation matrix properties (inverse == transpose)

Thanks to this PR we can do something like

Before

Now

material = iDynTree.Material()
color = iDynTree.Vector4()
color[0] = 1.0
color[1] = 0.0
color[2] = 0.0
color[3] = 1.0
material.color = color
print(type(material.color))                                                                  
<class 'idyntree.pybind.Vector4'>

material = iDynTree.Material()
material.color = [1.0, 0.0, 0.0, 1.0]
print(type(material.color))                                                                  
<class 'numpy.ndarray'>

position = iDynTree.Position(1, 2, 3)
rotation = iDynTree.Rotation(0, 0, 1,
                             1, 0, 0,
                             0, 1, 0)
transform = iDynTree.Transform(rotation, position)

rotation = iDynTree.Rotation(0, 0, 1,
                             1, 0, 0,
                             0, 1, 0)
transform = iDynTree.Transform(rotation, [1,2,3])

TODO

Update the tests
Update the CHANGELOG

cc @Giulero

diegoferigo · 2021-11-06T15:17:06Z

Awesome work @GiulioRomualdi, I'd love to see idyntree pybind11 bindings on par with those autogenerated by SWIG. As we understood in this last period, it's a very effective way to implement interoperability between different projects (modulo some edge case ami-iit/bipedal-locomotion-framework#386).

I put this PR in my review list, I also add @francesco-romano as reviewer since he was the original author of the pybind11 version of the bindings.

…nd11 Transform bindings

GiulioRomualdi · 2021-11-08T15:38:39Z

The PR is ready to be reviewed. I'm pretty sure that it is possible to improve the performances of the type_caster functions since NumPy and iDynTree store the matrices in row-major mode. But I am not an expert of that

traversaro · 2021-11-08T18:35:19Z

The change seems to be nice, however from what I understand it is a breaking change, right?
I mean, now the code:

material = iDynTree.Material()
color = iDynTree.Vector4()
color[0] = 1.0
color[1] = 0.0
color[2] = 0.0
color[3] = 1.0
material.color = color

is not working anymore?

It may be worth to clearly document this in the CHANGELOG then. I would also want to make sure that this is ok for @francesco-romano that originally contributed the pybind11 bindings, and I guess is mantaining an internal use of iDynTree/pybind11 code that he may need to migrate. To clarify, this will only be released as iDynTree 5, iDynTree releases <= 4 will keep the non-numpy API.

traversaro · 2021-11-08T18:39:26Z

bindings/pybind11/tests/test_idyntree_model.py

@@ -167,7 +161,7 @@ def test_attached_links(self):
    self.assertEqual(joint.get_second_attached_link(), 2)

  def test_rest_transform(self):
-    position = iDynTree.Position(1, 2, 3)
+    position = (1, 2, 3)


Just to understand, why in the test the 3D vectors are sometimes a list and sometimes a tuple?

It's actually the same, position can be a tuple or a list. pybind11 does the magic to convert it in a iDynTree::Position when required

GiulioRomualdi · 2021-11-09T08:51:17Z

The change seems to be nice, however from what I understand it is a breaking change, right? I mean, now the code:
material = iDynTree.Material()
color = iDynTree.Vector4()
color[0] = 1.0
color[1] = 0.0
color[2] = 0.0
color[3] = 1.0
material.color = color
is not working anymore?

It may be worth to clearly document this in the CHANGELOG then. I would also want to make sure that this is ok for @francesco-romano that originally contributed the pybind11 bindings, and I guess is mantaining an internal use of iDynTree/pybind11 code that he may need to migrate. To clarify, this will only be released as iDynTree 5, iDynTree releases <= 4 will keep the non-numpy API.

Yes, this is an important topic that we should discuss. iDynTree.Vector4 does not exist anymore. Indeed iDynTree.Vector4 == np.array The same is valid for all the other types.

Indeed if a vector of type Type satisfies is_idyntree_vector_fix_size<Type>::value the following type_caster is used

template <typename Type>
struct type_caster<Type, enable_if_t<is_idyntree_vector_fix_size<Type>::value>>

This struct has two methods, load and cast. The load is used to automatically convert a python default constructible pybind11::array_t into a C++ Type vector. On the other hand cast convert a C++ Type vector into a Python np vector.

For example, given the following c++ class

class Foo
{
    void setVector(iDynTree::VectorFixSize<3>& v);
    iDynTree::VectorFixSize<3> getVector();
}

and the associated pybind11 code

PYBIND11_MODULE(example, m) {
    py::class_<Foo>(m, "Foo")
        .def("set_vector", &Foo::setVector)
        .def("get_vector", &Foo::getVector);

when you call

foo = Foo()
foo.set_vector([1,2,3])

The python list is [1,2,3] is converted by pybind into a pybind11::array_t then since the following type_caster has been implemented

template <typename Type>
struct type_caster<Type, enable_if_t<is_idyntree_vector_fix_size<Type>::value>>

pybind knows how to convert a pybind11::array_t into a iDynTree::VectorFixSize<3> using the load method

The same approach is valid for the get_vector() python method

@traversaro, Let me know if it is more clear know

francesco-romano · 2021-11-09T17:12:14Z

Before going into details in the review / testing the changes, I would like to understand better if this is what we really want or not.

Focusing on the vector / matrices class only, the change will, in practice, remove those classed from Python.
On one side I see the advantage of this. On the other side, we lose explicit typing. See this as implicit vs explicit conversion.
Are we ok with this?

(the alternative approach, to be tested, is to add conversion functions into the vector classes, something like

.def(py::init([](py::buffer const b) {
            py::buffer_info info = b.request();
            if (info.format != py::format_descriptor<double>::format()
                || info.ndim != 1
                || info.shape[0] != size)
                throw std::runtime_error("Incompatible buffer format!");
            VectorFixSize<size> v;
            memcpy(v.data(), info.ptr, sizeof(double) * size);
            return v;
        }));

A second question, related to above: If we are ok with implicit conversion. how do we decide Fixed vs Dynamic version when casting? (I am referring to overloads taking both versions). We do not have control on this anymore. (Maybe we could probably order the cast to try Fixed first?)

Third: we would probably lose the ability to resize in-place vectors and matrices. Is this something that might be useful? It is definitely in C++, not sure in Python?

traversaro · 2021-11-11T14:21:02Z

On the other side, we lose explicit typing. See this as implicit vs explicit conversion.
Are we ok with this?

I think that the evaluation done by @GiulioRomualdi is that we sacrifice explicit typing to the altar of convenience of numpy, but perhaps @GiulioRomualdi can elaborate more. I am not a big user of Python bindings so I would trust users on the choice of this tradeoff.

A second question, related to above: If we are ok with implicit conversion. how do we decide Fixed vs Dynamic version when casting? (I am referring to overloads taking both versions). We do not have control on this anymore. (Maybe we could probably order the cast to try Fixed first?)

Not sure on this, what is happening in the version proposed by this PR @GiulioRomualdi ?

Third: we would probably lose the ability to resize in-place vectors and matrices. Is this something that might be useful? It is definitely in C++, not sure in Python?

I guess also this is something that we sacrifice for using natively numpy.

GiulioRomualdi · 2021-11-22T13:08:23Z

Hi, @francesco-romano and @traversaro sorry for replying late.

On the other side, we lose explicit typing. See this as implicit vs explicit conversion.
Are we ok with this?

I think that the evaluation done by @GiulioRomualdi is that we sacrifice explicit typing to the altar of convenience of numpy, but perhaps @GiulioRomualdi can elaborate more. I am not a big user of Python bindings so I would trust users on the choice of this tradeoff.

The idea is exactly this one, we could use directly numpy arrays instead of iDynTree one.

A second question, related to above: If we are ok with implicit conversion. how do we decide Fixed vs Dynamic version when casting? (I am referring to overloads taking both versions). We do not have control on this anymore. (Maybe we could probably order the cast to try Fixed first?)

Not sure on this, what is happening in the version proposed by this PR @GiulioRomualdi ?

In this case, if you try to call a function that takes as input a FixedSizeVector with a NumPy vector of the wrong size you will get an error.

Third: we would probably lose the ability to resize in-place vectors and matrices. Is this something that might be useful? It is definitely in C++, not sure in Python?

I guess also this is something that we sacrifice for using natively numpy.

This conversion is exactly the same as what is happening with the eigen vectors in pybind11. An eigen vector becomes a NumPy array. So you cannot call anymore the methods of the eigen vectors because they are actually numpy arrays. Here it is exactly the same

francesco-romano · 2021-11-22T16:07:34Z

Sounds good on everything. Just one last question here:

A second question, related to above: If we are ok with implicit conversion. how do we decide Fixed vs Dynamic version when casting? (I am referring to overloads taking both versions). We do not have control on this anymore. (Maybe we could probably order the cast to try Fixed first?)

Not sure on this, what is happening in the version proposed by this PR @GiulioRomualdi ?

In this case, if you try to call a function that takes as input a FixedSizeVector with a NumPy vector of the wrong size you will get an error.

Maybe it does not matter at all but my question is the following. What if you have the following method:

void Foo(iDynTree::VectorDynSize& v) {
   // Do something with the vector
}

template <int size N>
void Foo(iDynTree::VectorFixedSize<N>& v) {
 // Very optimised method!
}

Which of the two is taken from Python?

GiulioRomualdi · 2021-11-23T08:12:46Z

Sounds good on everything. Just one last question here:

A second question, related to above: If we are ok with implicit conversion. how do we decide Fixed vs Dynamic version when casting? (I am referring to overloads taking both versions). We do not have control on this anymore. (Maybe we could probably order the cast to try Fixed first?)

Not sure on this, what is happening in the version proposed by this PR @GiulioRomualdi ?

In this case, if you try to call a function that takes as input a FixedSizeVector with a NumPy vector of the wrong size you will get an error.

Maybe it does not matter at all but my question is the following. What if you have the following method:
void Foo(iDynTree::VectorDynSize& v) {
   // Do something with the vector
}

template <int size N>
void Foo(iDynTree::VectorFixedSize<N>& v) {
 // Very optimised method!
}
Which of the two is taken from Python?

Regarding this I can write a simple test, by the way I think the easiest way in this case is to create two python functions that have different names

CHANGELOG.md

Co-authored-by: Silvio Traversaro <silvio.traversaro@iit.it>

GiulioRomualdi · 2021-11-23T09:32:53Z

Hi @francesco-romano, this is the outcome

void foo(iDynTree::VectorDynSize&v)
{
    std::cout << "vectordynsize"<< std::endl;
}


void foo(iDynTree::VectorFixSize<4>& v)
{
    std::cout << "vectorfixedsize"<< std::endl;
}

namespace py = ::pybind11;
PYBIND11_MODULE(pybind, m) {
    m.def("foo",  py::overload_cast<VectorFixSize<4>&>(::foo))
     .def("foo",  py::overload_cast<VectorDynSize&>(::foo));
}

import idyntree.pybind as idyn                                                                                                              

In [2]: idyn.foo([1,1,1])                                                                                                                           
vectordynsize

In [3]: idyn.foo([1,1,1,1])                                                                                                                         
vectorfixedsize

However, I noticed that the order in the definition of the bindings matters. Indeed if the order is the following one

    m.def("foo",  py::overload_cast<VectorDynSize&>(::foo))
     .def("foo",  py::overload_cast<VectorFixSize<4>&>(::foo));

I got

In [1]: import idyntree.pybind as idyn                                                                                                              

In [2]: idyn.foo([1,1,1])                                                                                                                           
vectordynsize

In [3]: idyn.foo([1,1,1,1])                                                                                                                         
vectordynsize

So in conclusion I would define two different python function such as

    m.def("foo_vectordynsize",  py::overload_cast<VectorDynSize&>(::foo))
     .def("foo_vectorfixsize",  py::overload_cast<VectorFixSize<4>&>(::foo));

to avoid confusion

francesco-romano · 2021-11-23T09:45:29Z

Thanks for the test. I think this should be good enough.
Let me start the proper review :)

francesco-romano

Please add a test for all the caster functionalities

bindings/pybind11/idyntree_type_caster.h

francesco-romano · 2021-11-23T10:11:25Z

bindings/pybind11/idyntree_type_caster.h

+    /**
+     * Conversion from C++ to Python
+     */
+    static handle cast(Type src, return_value_policy policy, handle parent)


return_value_policy policy this partially answer my previous question, at least for the C++->Python side.

This side is good. We copy the object into Python

bindings/pybind11/idyntree_type_caster.h

bindings/pybind11/idyntree_core.cpp

src/core/include/iDynTree/Core/Position.h

bindings/pybind11/idyntree_type_caster.h

This reverts commit c46a4bf.

…TANDALONE is ON

This reverts commit c955175.

…ybind11/idyntree_core.cpp

GiulioRomualdi · 2021-11-25T22:55:46Z

I implemented the tests and I fixed some bugs in the type_caster.
Let me know if I should do something else

traversaro · 2021-11-26T07:40:14Z

@GiulioRomualdi sorry, devel was not updated with the latest CI fix. Feel free to merge again now, thanks!

diegoferigo · 2021-11-26T11:54:06Z

Sorry for jumping in so late but this PR stayed in my backlog for too long. Thanks @francesco-romano for the thorough review, and @GiulioRomualdi for iterating over it. I do not currently have any downstream code that uses the previous version of the pybind11 bindings, so I fully trust the judgement of @francesco-romano since he is the (only?) user -and original author- of these bindings version, and for sure he's the person with most interest in preserving compatibility / minimizing changes.

I went through you comments, and yes, I confirm that in the Python side, when there are multiple binded methods / functions that could cast the same time, their C++ definition order matters as you found out from your tests.

What's not 100% clear to me without directly testing the code of this PR is how memory ownership is dealt. The default Eigen / NumPy conversion has two different modalities for input data: pass-by-value that always involves a copy, and pass-by-reference that shares the memory. Instead, for output data, this is the relevant documentation.

@GiulioRomualdi, can you please comment about what this PR currently implements? At this first stage, I would not mind on optimizing performances by reducing copies, it can be done in the future if not yet supported, I'd like just to understand what to expect especially from the data returned to Python from the bindings.

Also, storage order (column-major vs row-major) is another advanced feature to double check.

GiulioRomualdi · 2021-11-26T16:59:07Z

@GiulioRomualdi, can you please comment about what this PR currently implements? At this first stage, I would not mind on optimizing performances by reducing copies, it can be done in the future if not yet supported, I'd like just to understand what to expect especially from the data returned to Python from the bindings.

Only the copy is implemented

Also, storage order (column-major vs row-major) is another advanced feature to double check.

iDynTree stores the matrices in row-major like numpy so it shouldn't be a problem

francesco-romano · 2021-11-26T19:00:50Z

Also, storage order (column-major vs row-major) is another advanced feature to double check.

iDynTree stores the matrices in row-major like numpy so it shouldn't be a problem

To be precise, this

py::array_t<double, py::array::c_style

is where you specify the row-major ordering. So you are correctly setting it as row-major.

francesco-romano · 2021-11-26T19:01:51Z

I will need to go over the PR again next week. I lost track of what is pending or not (no longer used to GitHub sorry )

francesco-romano · 2021-11-30T16:19:06Z

bindings/pybind11/CMakeLists.txt

+set(libraryname idyntree-pybind11)
+
+add_library(${libraryname} INTERFACE)
+target_link_libraries(${libraryname} INTERFACE idyntree-core)
+
+# Specify include directories for both compilation and installation process.
+# The $<INSTALL_PREFIX> generator expression is useful to ensure to create
+# relocatable configuration files, see https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html
+# creating-relocatable-packages
+target_include_directories(${libraryname} INTERFACE
+  "$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>"
+  "$<INSTALL_INTERFACE:$<INSTALL_PREFIX>/${CMAKE_INSTALL_INCLUDEDIR}>")
+
+# Specify installation targets, typology and destination folders.
+install(TARGETS        ${libraryname}
+  EXPORT               ${PROJECT_NAME})
+
+install(FILES "${CMAKE_CURRENT_SOURCE_DIR}/include/iDynTree/pybind11/VectorCasters.h"
+  DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/iDynTree/pybind11")
+
+add_library(iDynTree::${libraryname} ALIAS ${libraryname})
+set_property(GLOBAL APPEND PROPERTY ${VARS_PREFIX}_TARGETS ${libraryname})
+


tl;dr; Why these changes?

If I understood correctly, you want to create a separate library for the caster? Then

The name is very confusing. It does not explain what the library is for and it is a permutation of the other library name.

INTERFACE library, no sources? I know this is ok, but I think adding the (single) header file and setting it as public header you can skip the install FILES command and make it more clear

Which should probably be 0): Why? Why do you need the header file outside the build directory? Do you have C++ libraries that depend on this?

INTERFACE library, no sources? I know this is ok, but I think adding the (single) header file and setting it as public header you can skip the install FILES command and make it more clear

In this specific case you can't as there destination path is iDynTree/pybind11, while the PUBLIC header stuff only support one folder as destination path.

The name is very confusing. It does not explain what the library is for and it is a permutation of the other library name.

We can change it, what do you suggest?

INTERFACE library, no sources? I know this is ok, but I think adding the (single) header file and setting it as public header you can skip the install FILES command and make it more clear

I will need it to import it in a different project that uses idyntree types in the interface. Having an exported interface library simplifies importing it. It is exactly the same as #include <pybind11/eigen.h>

We can change it, what do you suggest?

What about idyntree-pybind11-vector-casters?

Also, can you remove
set(libraryname idyntree-pybind11) and use explicitly the new library name?

Can you also:

move the install part down together with the install of the module?

What is the purpose of the ALIAS?

@GiulioRomualdi what do you think of idyntree-pybind11-vector-casters @GiulioRomualdi ? It seems a nice name to me.

francesco-romano · 2021-11-30T16:25:19Z

bindings/pybind11/tests/test_idyntree_core.py

+    position = np.array([1., 2., 3.])
+    rotation = np.array([[0., 0., 1.], [1., 0., 0.], [0., 1., 0.]])
+    transform = iDynTree.Transform(rotation, position)


This is pending the other discussion

The one on implicit vs explicit conversion

bindings/pybind11/idyntree_core.cpp

francesco-romano · 2021-12-01T12:41:12Z

bindings/pybind11/tests/test_idyntree_vector_casters.py

+import numpy as np
+
+
+class TestClassTest(unittest.TestCase):


[Question]
I am trying to understand what we are testing with this test case.

What we want is to check that Python List/Numpy objects are converted to the corresponding iDynTree classes and vice versa.
Is this test enough for testing this?

Let's take the first test:

def test_vector_fix(self): obj = TestClass() vector = [1., 2., 3.] obj.vector_fix = vector self.assertEqual(len(obj.vector_fix), 3) self.assertEqual(list(obj.vector_fix), list(vector))

obj.vector_fix = vector tests that the conversion into a fix<3> works.
The other two lines are then testing the conversion back into Python.
But, can we add a test that if we have a C++ method operating on the vector it is happy? e.g. summing 1 on all elements.

But, can we add a test that if we have a C++ method operating on the vector it is happy? e.g. summing 1 on all elements.

@GiulioRomualdi any toughts? Also for this I think we can merge in this state and eventually propose new PRs.

francesco-romano · 2021-12-01T12:42:47Z

bindings/pybind11/CMakeLists.txt

@@ -19,7 +43,7 @@ set_target_properties(pybind11_idyntree PROPERTIES

 # if compile tests execute also python tests
 if(IDYNTREE_COMPILE_TESTS)
-    add_subdirectory(tests)
+    add_subdirectory(tests idyntree_pybind11_test)


Do you think there is a way to avoid this and avoid modifying the test Cmake working directory variable?

@GiulioRomualdi any thoughts on this? Note that if it is difficult I prefer to merge the PR in the current form, it is not particularly problematic to have this.

GiulioRomualdi · 2022-12-13T09:37:31Z

We can close since #1037 implements already one of the key feature designed by this PR

Implement raw buffer constructor for the Position class

8a40642

GiulioRomualdi requested review from diegoferigo and traversaro November 6, 2021 14:36

GiulioRomualdi self-assigned this Nov 6, 2021

diegoferigo requested a review from francesco-romano November 6, 2021 15:17

GiulioRomualdi force-pushed the pybind11/type_caster branch from 1fef829 to de0c48f Compare November 7, 2021 18:33

GiulioRomualdi added 4 commits November 8, 2021 16:32

Implement pybind11 type_caster for iDynTree core types

f2f6237

Use pybidn11 typecaster in the already existing bindings

c46a4bf

Make rotation and position property readable and writable in the pybi…

030066e

…nd11 Transform bindings

Update the pybind11 tests

c955175

GiulioRomualdi force-pushed the pybind11/type_caster branch from de0c48f to c955175 Compare November 8, 2021 15:32

Update the CHANGELOG

a6c3058

traversaro reviewed Nov 8, 2021

View reviewed changes

traversaro reviewed Nov 23, 2021

View reviewed changes

CHANGELOG.md Outdated Show resolved Hide resolved

Update CHANGELOG.md

899643b

Co-authored-by: Silvio Traversaro <silvio.traversaro@iit.it>

francesco-romano requested changes Nov 23, 2021

View reviewed changes

francesco-romano requested changes Nov 25, 2021

View reviewed changes

bindings/pybind11/idyntree_type_caster.h Outdated Show resolved Hide resolved

GiulioRomualdi added 2 commits November 25, 2021 15:05

Improve the idyntree_type_caster structs

ecc64ad

Revert "Use pybidn11 typecaster in the already existing bindings"

f60121c

This reverts commit c46a4bf.

Define the iDynTreeBindings project only if IDYNTREE_BINDINGS_BUILD_S…

0b3b349

…TANDALONE is ON

GiulioRomualdi force-pushed the pybind11/type_caster branch from 52f51c4 to 0b3b349 Compare November 25, 2021 17:31

GiulioRomualdi added 2 commits November 25, 2021 18:48

Fix style in VectorCasters.h file

7552d12

Fix style in bindings/pybind11/idyntree_core.cpp file

c746633

GiulioRomualdi force-pushed the pybind11/type_caster branch from 729ca28 to c746633 Compare November 25, 2021 17:51

Revert "Update the pybind11 tests"

376690f

This reverts commit c955175.

This comment has been minimized.

Sign in to view

GiulioRomualdi added 2 commits November 25, 2021 21:15

Update of the python tests

a7522fe

Implement baseVectorDefinition and baseMatrixDefinition in bindings/p…

f04e844

…ybind11/idyntree_core.cpp

GiulioRomualdi force-pushed the pybind11/type_caster branch from 25d757b to f04e844 Compare November 25, 2021 20:16

GiulioRomualdi added 3 commits November 25, 2021 23:53

Bugfix in VectorCasters.h

c16496f

Uniform pybind11 target_link_libraries

609923d

Implement the test for pybind11 type_caster

25d5728

Merge remote-tracking branch 'origin/devel' into pybind11/type_caster

ec7c8f6

GiulioRomualdi force-pushed the pybind11/type_caster branch from f4ab83b to ec7c8f6 Compare November 26, 2021 10:43

GiulioRomualdi added 3 commits November 26, 2021 21:47

Fix typo in pybind11/CMakeLists.txt

9258e6b

Fix style in VectorCasters.h

58f5fca

Fix WORKING_DIRECTORY of pybind11 tests

10658f3

francesco-romano requested changes Nov 30, 2021

View reviewed changes

francesco-romano reviewed Dec 1, 2021

View reviewed changes

Base automatically changed from devel to master February 8, 2022 17:50

GiulioRomualdi closed this Dec 13, 2022

Implement iDynTree base type type_caster for pybind11 bindings #931

Implement iDynTree base type type_caster for pybind11 bindings #931

Conversation

GiulioRomualdi commented Nov 6, 2021 • edited Loading

TODO

diegoferigo commented Nov 6, 2021 • edited Loading

GiulioRomualdi commented Nov 8, 2021

traversaro commented Nov 8, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GiulioRomualdi commented Nov 9, 2021 • edited Loading

francesco-romano commented Nov 9, 2021 • edited Loading

traversaro commented Nov 11, 2021

GiulioRomualdi commented Nov 22, 2021

francesco-romano commented Nov 22, 2021

GiulioRomualdi commented Nov 23, 2021

GiulioRomualdi commented Nov 23, 2021 • edited Loading

francesco-romano commented Nov 23, 2021

francesco-romano left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

GiulioRomualdi commented Nov 25, 2021 • edited Loading

traversaro commented Nov 26, 2021

diegoferigo commented Nov 26, 2021

GiulioRomualdi commented Nov 26, 2021

francesco-romano commented Nov 26, 2021

francesco-romano commented Nov 26, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GiulioRomualdi Dec 1, 2021 • edited Loading

Choose a reason for hiding this comment

francesco-romano Dec 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GiulioRomualdi commented Dec 13, 2022

Implement iDynTree base type `type_caster` for pybind11 bindings #931

Implement iDynTree base type `type_caster` for pybind11 bindings #931

GiulioRomualdi commented Nov 6, 2021 •

edited

Loading

diegoferigo commented Nov 6, 2021 •

edited

Loading

traversaro commented Nov 8, 2021 •

edited

Loading

GiulioRomualdi commented Nov 9, 2021 •

edited

Loading

francesco-romano commented Nov 9, 2021 •

edited

Loading

GiulioRomualdi commented Nov 23, 2021 •

edited

Loading

GiulioRomualdi commented Nov 25, 2021 •

edited

Loading

francesco-romano commented Nov 26, 2021 •

edited

Loading

GiulioRomualdi Dec 1, 2021 •

edited

Loading

francesco-romano Dec 1, 2021 •

edited

Loading