search

robotology / human-dynamics-estimation

Software repository for estimating human dynamics
BSD 3-Clause "New" or "Revised" License
81 stars 28 forks source link

Initial refactoring of human-dynamics-estimation #243

Closed lrapetti closed 1 year ago

lrapetti commented 3 years ago

As discussed, we are planning a refactoring of the code contained in human-dynamics estimation. Initially, the code contained in this repo was meant to be a collection of YARP applications able to interface sensors data (in wearables format) with iDynTree algorithms. With time, however, some algorithms were progressively implemented directly in the devices. The main objective is to progressively move from a collection of applications to a library+applications. This change would lead to some improvements:

In order to do so, some initial steps have been detected:

An MVP for this activity might be the possibility to run kinematics and dynamics estimation offline in a single C++ module.

lrapetti commented 3 years ago

@Yeshasvitvs @kouroshD @diegoferigo @traversaro @S-Dafarra @prashanthr05 @GiulioRomualdi @DanielePucci @evalli-iit @claudia-lat please feel free to add any point I missed from the internal discussion, or any additional thought you had since.

diegoferigo commented 3 years ago

move from the interfaces to stand-alone objects that can be configured offline. (@diegoferigo maybe you can help with the definition of this task)

In my opinion things could be done in steps. Here below a proposal.

A. Standalone hde library with algorithm

  1. Create a new hde/ folder containing the files and (public) headers for the IK and Berdy. What do you think of using the hde:: namespace?
  2. Move the code from the devices to the library
  3. Optional: create bindings with pybind11 so that both Python and Matlab are supported

This would already be a great start. It does not touch the high-level architecture of hde but it would provide the desired refactoring.

B. Allow programmatic usage of devices

:warning: This step might need more brainstorming and prototyping :warning:

Currently, the devices are loaded by yarprobotinterface and quite complex configuration files are read. Something that is not 100% clear to me (I forgot with time and I should give a new careful look to the code) is whether all devices read from yarp ports or they always rely on interfaces that are attached. Can we do a list of devices that you'd like to call programmatically, and check their internal implementation?

If no yarp ports are involved, maybe a first tentative I'd try is to exploit what @traversaro kindly implemented last summer https://github.com/robotology/yarp/pull/2319, it seems a great match for the first prototype. It allows to operate programmatically on the devices without altering a single line or code. Bonus point, also the configuration files would be compatible with this approach.

Then, moving on, devices could be updated to simplify even further their usage, and maybe removing yarp from our feet in the public APIs.

Any comments / ideas?

diegoferigo commented 3 years ago

Thinking more about phase B above, if the desiderata is the following,

  • possibility to test the code out of the wearables+yarp online environment [...] An MVP for this activity might be the possibility to run kinematics and dynamics estimation offline in a single C++ module.

YARP should not be involved in any of the new libraries, not even privately. This means that, after stage A, some new high-level classes that provide all the functionality needed by the devices may be necessary. In this way, the online pipeline does not have to change. I think it's worth at first defining exactly what you want to achieve offline, and then decide the best phase B for the selected goals.

lrapetti commented 3 years ago

Hi @diegoferigo sorry for taking some times to answer.

I think we are aligned on starting addressing the point A you proposed in the comment above.

In line with this, I have added an additional first point to the list due to some requirements we are currently having (@prashanthr05 @Yeshasvitvs) and that will be soon addressed:

  • move the InverseVelocityKinematics and stateIntegrator in a separate library

Concerning the phase B, I think that can be further discussed after the phase A is achieved. In particular concerning what you commented above:

If no yarp ports are involved, maybe a first tentative I'd try is to exploit what @traversaro kindly implemented last summer robotology/yarp#2319, it seems a great match for the first prototype. It allows to operate programmatically on the devices without altering a single line or code. Bonus point, also the configuration files would be compatible with this approach.

I think that might be a parallel task, but somehow independent from the final objective of having the main functionalities exposed as a library, and independent from yarp.

lrapetti commented 1 year ago

We remove the activity on python bindings creation from this epic since it is left in icebox and close it

lrapetti commented 1 year ago
  • [ ] ~move from the interfaces to stand-alone objects that can be configured offline. (@diegoferigo maybe you can help with the definition of this task)~

This activity is still not clear so we have removed it