Joint model outputs when using output delays

[geez0x1]

At the moment when output delays are set >0, all fields are delayed. However, for seeing how well something is tracked you might want to have the non-delayed field (e.g. the noNoise fields).

[geez0x1]

On this note, I have updated all controllers to use the TorqueFiltered field as opposed to the Torque field, which architecturally makes more sense.

However the point w.r.t. output delays still stands. One can manually shift the signal in post-processing, but that is laborious.

[joernmalzahn]

Hmm, does it make more sense? If I just want to see how the controllers behave in the ideal case, what would I do now? I am not perfectly happy with the different clones of the same signal in the joint bus, actually. I would prefer to e.g. have only one torque signal in the bus and have it ideal, delayed, noisy or delayed and noisy by configuration of the mechanical subsystem block.

[geez0x1]

For example, PD controllers would not have access to a clean torque signal (one can only set derivative filtering in the controller itself). Assuming there's noise available there is no situation you would give the controller an unfiltered signal. If you want to test the ideal case, currently you'd set delays to zero, noise off, and filter frequency to a "very large" value. This last bit I think we can improve, by having a checkbox which effectively removes the filter from the path entirely. Agreed?

With regards to having different clones, I agree to some extent. There are many cases where one would want multiple - e.g. the 'polluted' (noisy, delayed, filtered, etc) signal needs to be passed to the controller, whereas you'd want to have the perfect torque signal to accurately judge obtained performance.

[geez0x1]

Towards this end I have updated the mechanical joint model block to have all NoNoise output variables denote physical quantities, i.e. unaffected by noise, delays, or filtering. I have also improved the block's help to properly explain all inputs and outputs:

This block implements the mechanical dynamics of the actuator. Depending on the configuration in which the joint class was built, its dynamics are given by one of the variants provided by the toolbox (see model/linear/). If provided, the linear dynamics are enhanced with nonlinear components.

Inputs motorTorque: Electromechanical motor torque provided on the rotor. An input delay can be added to this input (e.g. due to communication delays or a very simplified representation of electrical dynamics). tau_e or q_l_dot: External interaction torque. Depending on the selected linear dynamics model of the joint, this is either the external torque acting on the load or the imposed load velocity (for fixed-output models).

Outputs jointBus: The various variables and their measurements, with optional delays/noise/quantisation etc. For most outputs, several instances exist. Output variables ending in "NoNoise" denote physical quantities, without noise, filtering, or delays. All other variables are affected by noise and delays (if enabled). Lastly, variables ending in "Filtered" are also low-pass filtered, with cut-off frequency set in the mask.

This fixes this issue. What it however does not fix is #47: I believe when we redefine the jointBus in a future version we should have some clear distinction between "sensed" and "physical" variables. Sensed variables obviously 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 #47 this means that the "sensed" torque would include only the spring-part of the torque (as well as optional noise, delays, filtering), and the physical quantity would include both stiffness and damping terms of the element.