In many cases it may happen that some FT sensors can be offset-calibrated, while other no, and it would be convenient to just calibrate them. For example, when a humanoid robot is standing on its leg, the FT sensors on the legs cannot be offset-calibrated, while the one on the arms yes (assuming no force is excerted on the arms).
O2: Define new calib** functions (or at least for calib, as all other calibration methods are not really relevant for the arms use case) in which the list of sensors to calibrate is explicitly passed when the RPC function is called.
In general I would prefer O1, even if it has the downside to put even more complexity in the configuration files that it is definetly something not desirable, so from that point of view O2 has the advantage that we would not need to put more complexity in the config files.
In many cases it may happen that some FT sensors can be offset-calibrated, while other no, and it would be convenient to just calibrate them. For example, when a humanoid robot is standing on its leg, the FT sensors on the legs cannot be offset-calibrated, while the one on the arms yes (assuming no force is excerted on the arms).
For a specific application, I implemented an hardcoded implementation of this in https://github.com/robotology/whole-body-estimators/commit/ac0cd227b67aee4fa2170148970e2752cf38bd7c . However, it would be good to have a model agnostic implementation. Possible way of implementing this:
calib_code
in the RPC calls tocalib***
RPC calls (see https://github.com/robotology/whole-body-estimators/blob/c46c1852974776038a75b7c0e542ccb2917d7c7f/idl/wholeBodyDynamics_IDLServer/wholeBodyDynamics_IDLServer.thrift#L18).calib**
functions (or at least forcalib
, as all other calibration methods are not really relevant for the arms use case) in which the list of sensors to calibrate is explicitly passed when the RPC function is called.In general I would prefer O1, even if it has the downside to put even more complexity in the configuration files that it is definetly something not desirable, so from that point of view O2 has the advantage that we would not need to put more complexity in the config files.