Pinocchio: Support for getting velocities and accelerations?

[gabrielebndn]

Hi,
traditionally, in Pinocchio, we compute forwardKinematics() and then we get the results directly from data.v[i] or data.a[i]. These are expressed in the LOCAL frame, and are defined according to Spatial algebra style.

However, not everybody works this way. Many people prefer to employ the "traditional" velocities, corresponding to LOCAL_WORLD_ALIGNED. We can see it here:

1140

773

904

I wonder whether it might be interesting to add some explicit support for common transformations.

Specifically, I am thinking about the following methods:

getJointVelocity(model, data, jointId, referenceFrame);
getJointAcceleration(model, data, jointId, referenceFrame);
getClassicJointAcceleration(model, data, jointId, referenceFrame);

where the default referenceFrame is LOCAL, and also modifying

getFrameVelocity(model, data, jointId);
getFrameAcceleration(model, data, jointId);

to

getFrameVelocity(model, data, jointId, referenceFrame);
getFrameAcceleration(model, data, jointId, referenceFrame);

and adding

getClassicFrameAcceleration(model, data, jointId, referenceFrame);

This would create a nice symmetry between joints and frames.
The "classic" acceleration is inspired to an already-existing implementation inside RobotWrapper:
https://github.com/stack-of-tasks/pinocchio/blob/cd452efbeb3f04dc980def5fe0fc4a14edc197b7/bindings/python/pinocchio/robot_wrapper.py#L135-139

Is there any interest in this? I may contribute, it will be very quick

[jcarpent]

Yes, for sure. I had the same suggestion in mind for a while ago.
You can implement these signatures and their Python bindings.
Do you want to contribute before the next release? I will do it tonight or tomorrow morning.

[cmastalli]

I think more importantly it is to have a proper documentation. But this is nice as well.

The drawback of providing eatable food to our users is then they will be not able to write similar code which is needed when you want to retrieve a velocity / acceleration in a generic frame (not inside the model).

[gabrielebndn]

Sorry, closed by mistake

[jcarpent]

@gabrielebndn Should I wait for your contribution for the next release?

[gabrielebndn]

@jcarpent, as you want. I hadn't the time to do it yesterday, but I think I might have it today. Anyhow, I think there is no reason to block a release for this :)

[EnricoMingo]

Hi all, I don't want to interfere with your decisions but I strongly believe that a _high layer_ of _classical_ kinematics and dynamics quantities computation may encourage new users which are not familiar with Featherstone formalism, to use your library. Also consider that spatial quantities sometimes are difficult to handle for practical problems, being instead super good for computation purposes. This is only a personal opinion of course and again I do not want to interfere with the development of the library (I am just a user :) ).

[jcarpent]

Thanks @EnricoMingo for your opinion. I think such feedback is very useful.

[jcarpent]

Solved by #1186.

[mfocchi]

@gabrielebndn will these changes be incorporated also in the package robotpkg-py27-pinocchio?

[cmastalli]

@gabrielebndn will these changes be incorporated also in the package robotpkg-py27-pinocchio?

All version are always released into Python 2.7 as well, (at least until the team decides to do not support anymore Python 2). The release of new feature might take between few hours to weeks. You can always check the available versions by typing:

sudo apt update
apt-cache madison robotpkg-py27-pinocchio

If you want to be faster than this, then I suggest you to install Pinocchio by source.

[gabrielebndn]

@mfocchi, I am not responsible for managing the packages, so I have no voice on the subject and only limited information :) It certainly _will_ be included, but I cannot say _when_.

I can tell you the changes have been accepted in the devel branch, which means you can already use them, and that they will denfinitely be included in next source release (when they will also be merged to the master branch), and source releases are quite frequent. After this, the release will certainly be shipped on apt packages too, and yes, it will be on robotpkg-py27-pinocchio, as Python 2 is still supported. However, between a version being released by source and its being shipped on apt packages there can be a considerable time lag, and I cannot give you a time estimate

[mfocchi]

ok thanks, I will keep checking the https://github.com/stack-of-tasks/pinocchio/releases site

[jcarpent]

@mfocchi If you need it soon, I can provide a release of course. I'm not making too many releases normally if it is not necessary, as it implies a lot of works to valid it.
But for collaborators, we can push a new one on demand.

By the way, you can install Pinocchio from conda which a Python package manager which allows us to release fastly Pinocchio (much faster than using robotpkg, where all the packages that use Pinocchio have to be tested and fixed).

[mfocchi]

@jcarpent no worries I will need by beginning of June for some letures. In the meanwhile I will try the conda installation.