Parameter file using reflected inertia?

[joernmalzahn]

At the moment the parameter files list the ineratia and friction values reflected to the output.

As a result, if we wish to simulate the same motor with another transmission ratio, we would have to manually account for the updated inertia and friction values as well.

Question: wouldn't it make sense to put the inertia and friction values on the motor side into the datasheet?

To maintain backwards compatibility, we can introduce new names for the input reflected parameters. The parameter names that we are currently using become functions of the genericJoint class and output the output referred parameter values. That should have minimal impact on the rest of the code.

Opinions?

[joernmalzahn]

I proposed a parameter renaming scheme that can now be found in the branch parameter_renaming. The parameters are now the fixed physical parameters. That means e.g. for the rotor and gearbox inertia, it is the true inertia of the rotating object. The parameters are called Im_m and Im_g now. The apparent load side reflected inertias are still named I_m and I_g and provided through public genericJoint class methods. So code behavior does not really change. Analogously, the physical load inertia parameter is I_l. A public genericJoint class method provides the load inertia Im_l reflected to the motor side.

The friction and ripple parameters are treated in the same way.

As one major benefit: the transmission ratio value can now be subject to analysis without necessity to manually adjust inertia, friction and ripple parameters, each time the ratio is altered.

Will merge parameter_renaming branch, if no objections are present.

[geez0x1]

I just had a look at this. There is one issue; handleMatlabFunctionBlock does not call the functions required for d_cm etc, but only looks at members. This breaks e.g. Coulomb friction. This function can be modified to call those functions, but perhaps a better solution is to give genericJoint a function updateDependentParameters (or something) that calculates all of those fields, and either 1. returns them as a struct or 2. sets them as members.

What do you think?