Open geez0x1 opened 6 years ago
Some changes were made to the jointBus (in the "NoNoise" variables) following #45.
That fix does not solve this issue however: I believe when we redefine the jointBus in a future version we should have some clear distinction between "sensed" and "physical" variables. Sensed variables are the ones controllers have at their disposal, but for analysis we obviously want to be able to have the physical quantities.
In the context of this issue this means that the "sensed" torque would include only the spring-part of the torque (as well as optional noise, delays, filtering), as that is the way real hardware measures/estimates torque. In our case, at least (maybe some people include the damping component?). The physical quantity would include both stiffness and damping terms of the element.
Sounds reasonable to me.
OK. Added enhancement label to this to be included in future refactoring.
To mostly fix this issue before future refactoring, in 1046504:
Added the damping component of the flexible element to the "TorqueNoNoise" output of the jointBus, as all "NoNoise" output variables are said to be physical quantities. Also updated Help of the Simulink library block accordingly. Partially fixes #47.
Cool!
This should be open for the refactoring part!
I've fixed a few issues with regards to this in ef5ab51da217727e6611bbbf8bbc86b2a138432b. The output_fixed
model had an issue in how the damping term was computed in state-space, and in construction of the jointBus
the damping component was incorrectly included in TorqueFiltered (which is a sensed signal of the torque, and as we consider deflection/stiffness measurements for torque it should not know about the damping component of the flexure). A minor issue as generally we have d_gl==0 (flexure damping negligible).
Following some testing with internal component damping where I set
d_gl > 0
I found that the current jointBus does not allow to get the true torque in these cases. In the block the torque fields are computed using only the stiffness contributionk_b * (q_g - q_l)
.Combined with #45 , we should probably consider redefining the jointBus.