MBD-MC-E - Study model for calibrator of absolute encoders

[marcoaccame]

Task description 📑

In the C implementation of the MC of ETH boards the file Calibrators.c contains several types of calibrators.
The simplest is surely the calibration of an absolute encoder that follows calibration type 12. See the calibration types in here.

In here we want to study how this simple calibrator can be modeled in Simulink, verified by a test and how we can generate code from it that will be placed inside the file Calibrators.c.

This activity will continue in another issue with the actual deployment of the generated code inside the ETH boards (ems, mc4plus, mc2plus, amc, amcfoc) and with its test on the lego setup and possibly on the new iCub head.

Useful links and documents 🔖

For code generation it can be useful to follow https://github.com/icub-tech-iit/four/issues/35

Definition of Done 🏁

To have a model for the calibrator, its test and the generate code.

[mfussi66]

In here we want to study how this simple calibrator can be modeled in Simulink

To do so, we can start a little Matlab project with a small dictionary that can be progressively enriched as the feature set growa, or if we want to implement more calibration sequences.

[RaffaelePumpo]

First Implementation of Calibrator with Calibration Type 12

Implementation Details

• Calibration parameters:
  • calibration1: Raw position at zero
  • calibration2 - calibration5: Not used
  • calibrationZero: 0.0 (only corrected value)
  • calibrationDelta: User-defined in degrees

Simulink Models:

• Implemented a dedicated model for Calibration Type 12

• Created a general model that supports multiple calibration types

Dictionary:

A dictionary has been created to store calibration-related parameters. It can be expanded progressively to accommodate additional calibration sequences.

Code Generation:

• The generated C code for the calibrator is included

  // SwitchCase: '<Root>/Switch Case' incorporates:
  //   Inport: '<Root>/calibrationParameters'

  tmp = std::trunc(Calibration_U.calibrationParameters.calibrationType);
  if (std::isnan(tmp) || std::isinf(tmp)) {
    tmp = 0.0;
  } else {
    tmp = std::fmod(tmp, 4.294967296E+9);
  }

  if (tmp < 0.0) {
    tmp_0 = -static_cast<int32_T>(static_cast<uint32_T>(-tmp));
  } else {
    tmp_0 = static_cast<int32_T>(static_cast<uint32_T>(tmp));
  }

  if (tmp_0 == 12) {
    // Outputs for IfAction SubSystem: '<Root>/type_12' incorporates:
    //   ActionPort: '<S1>/Action Port'

    // Outport: '<Root>/Out1' incorporates:
    //   Sum: '<S1>/Add'

    Calibration_Y.Out1 = Calibration_U.calibrationParameters.calibration1 +
      Calibration_U.calibrationParameters.calibrationDelta;

    // End of Outputs for SubSystem: '<Root>/type_12'
  }

  // End of SwitchCase: '<Root>/Switch Case'
}

Data Handling Architecture:

This first implementation is based on a bus structure created using parameters extracted from the .xml file. The calibrator outputs the calculated numerical value.

Should we expect different input/output formats or data structures?

F2F discussion

After a discussion with @marcoaccame and @mfussi66 , we noted that the calibrators are currently distributed across multiple files for the actual c++ implementation. To improve clarity and organization, we will conduct a deeper analysis of how calibrators are used in the architecture.

For now, this first implementation will be used to handle the calibration of a single joint, and later, it will be expanded to support more complex joint types requiring multi-joint calibration.