human-forces-provider about human-dynamics-estimation HOT 6 CLOSED

Nice diagram. Good job guys @claudia-lat @francesco-romano. Probably, it would have been nice to specify where the inputs $q,\dot{q}$ go into the internal blocks (I assume that some of the internal blocks do not use them).

from human-dynamics-estimation.

Just a notation note: we tipically use $q, \dot{q}$ to indicate the full state of the multibody model (i.e. internal joint positions/velocity and base position velocity. If I understand everything correctly, the human-state-provider only provides the internal joint position/configuration of the human model, and we recently started indicated this variables as $s, \dot{s}$ (s because they represent the shape of the model, as opposed to its absolute position). In the past we also indicated them with $q_J, \dot{q}_J$, but in general the important part is to distinguish them from the full state $q, \dot{q}$.

from human-dynamics-estimation.

Just to recap: as things stand now we have a polydriver that handles the driver of the force plates. The idea is to have a similar behaviour for handling the robot.

from human-dynamics-estimation.

The internal structure of the module could be something like this:

• FTForceReader: generic class for reading forces coming from devices (this because the devices will be handled by a polydriver). This is exactly the case of the force plates.
• PortForceReader: generic class for reading forces from a port (case of the robot).
• ConstFrameTransformation: (if and when required) transforms (eventual) forces coming from the previous interface into a new reference frame. The rotation matrix in this case is set manually and therefore constant (case of the const transformation between a fixed human foot and the reference frame of the force plate).
• RobotFrameTransformation: (if and when required) transforms (eventual) forces coming from the previous interface as specified in then comment of @traversaro (by requiring therefore the human state given by human-state-provider and the robot state). Here it will be implemented kinDyn computations.

Thanks @francesco-romano for helping me in defining this structure.

from human-dynamics-estimation.

The inputs $q,\dot{q}$ are required by the FrameTransformer interface (and more precisely by the RobotFrameTransformation block) since here the forces coming from force plates and the robot (that are still in the devices reference frames) are converted into the human frames.

Indeed we introduced an intermediate base class between the ForceReader interface and the two derived classes.

from human-dynamics-estimation.

I realised that for the FrameTransformer interface can be handled in this way:

• a GenericFrameTransformer that implements the interface: it is in charge of applying a transformation to a given force;
• a specialised RobotFrameTransformer for the specific case in which the transformation is not constant and needs to be updated at each timestamp.

from human-dynamics-estimation.