search

robotology / icub-main

The iCub Main Software Repository
Other
108 stars 103 forks source link

Port wholebodydynamics to the usage of MASserver/client #865

Closed Nicogene closed 1 year ago

Nicogene commented 1 year ago

Is your feature request related to a problem?

No response

The solution you would like to have available

We ought to port wholebodydynamics to the usage of multipleanalogsensorsclient in order to finalize the deprecation of analoSensor for publishing FT data (see https://github.com/robotology/robots-configuration/issues/470)

https://github.com/robotology/icub-main/blob/ec6123471ee3cf212ef45fdda772e2453ed97208/src/modules/wholeBodyDynamics/observerThread.cpp#L411-L433

Alternatives you have considered

No response

Additional context

No response

Nicogene commented 1 year ago

This activity will start as soon as we have completed https://github.com/robotology/robots-configuration/issues/485

Nicogene commented 1 year ago

PR:

Right now the changes are breaking for those who still use analog:o, but since we want to replace it w/ the idyntree wbd I would not spend too much effort to support any possible configuration.

cc @traversaro @pattacini

pattacini commented 1 year ago

There are CAN robots that we still need to maintain in terms of the red-ball demo and thus the current WBD.

The migration to the idyntree-based WBD is not straightforward as we'd need the URDF and thus won't happen any time soon.

traversaro commented 1 year ago

Probably we need to migrate CAN-based sensors from canBusAnalogSensor to canBusFTSensor (see https://github.com/robotology/icub-main/pull/813), so that the MAS interfaces are exposed?

pattacini commented 1 year ago

Probably we need to migrate CAN-based sensors from canBusAnalogSensor to canBusFTSensor (see #813), so that the MAS interfaces are exposed?

Yep, that's a good option. We could do that for those CAN robots that we decide to keep up-to-date. For the rest, we can say that they're covered up to a certain distro.

Nicogene commented 1 year ago

As reported here the current implementation is working fine, and if robots-configuration is up-to-date no robot is kept back, since this

Probably we need to migrate CAN-based sensors from canBusAnalogSensor to canBusFTSensor (see https://github.com/robotology/icub-main/pull/813), so that the MAS interfaces are exposed?

has been done here https://github.com/robotology/robots-configuration/pull/517.

My opinion is that keeping the implementation of reading from a port analog:o and the MAS client is not worthy, since this module is in a kind of "deprecation" state. It has several hardcoded parameters since it is not reading any urdf as the idyntree twin does, for this reason for new robots it has poor performances, independently of these changes.