Feature/temperature reading

[MSECode]

Description:

This PR brings the following changes:

• user can pass to the lower level the temperature sensor type used by the motor related to the specific joint
• user can pass to the lower level the temperature limits used by the motor related to the specific joint

Here follows the details about the implemented changes and an action diagram describing the flow of the calls and the entities that takes part in the workflow:

Parsing new configuration

1. we have introduced three new parameters as follows:

   • hardwareTemperatureLimits and warningTemperatureLimits in the hardware/motorControl section in the LIMITS group. The hardwareTemperatureLimits is the maximum temperature at which the motor can work, above which the motor is damaged. Instead the warningTemperatureLimits describes a warning temperature defined by the user to advise to reduce the current fed to the specific motor suggesting not increasing the temperature anymore, going to reach the hardware limit with the consequent fault of the robot. The warningTemperatureLimit must be at least 85% of the hardwareTemperatureLimit in order to have a secure gap before hitting the hardware temperature limit of the motor and thus to work in conditions that should be safe for not damaging the motors.
   • in the hardware/mechanical section in the FOC group we have introduced the TemperatureSensorType parameter, which is going to substitute the current HasTempSensor parameter, which is now still accepted if set to zero without adding the new group, but which will soon be fully deprecated. The possible values of TemperatureSensorType are PT100, PT1000 and NONE, depending on the temperature sensor mounted.

2. This feature is retro-compatible --> it is possible to use the robot without making any changes to the current configuration. Therefore, if we don't set the limits and if we leave the parameter HasTempSensor in the FOC group to zero everything works fine and the temperature reading on the FOC boards is not enabled.

Testing of the new configuration

We tested all possible configurations (at least we hope to have covered all cases 😸 ) both in dry-run and actively on the bench setup and on the robot ergoCub SN001 testing the correct parsing of the new configuration. At this comment it is possible to find the outcome of the tests done and here follows a brief summary of what the user should expect:
Perhaps it would be worth pointing out that, as said before, for retro-compatibility, if the user sets HasTempSensor to 0 then any temperature sensor is configured and the motor temperature will not read. Otherwise, if the user sets HasTempSensor to 1 then the parser returns an error related to an inconsistent configuration because the sensor type and limits parameters are missing.

embObjMotionControl device

1. implemented getTempeartures() and getTemperature(): first of all, it checks if a temperature sensor type has been enabled for the specific motor, otherwise it won't be possible to receive a certain temperature. Then it checks if the raw value is different from a specific error value -5000 that is used by the 2FOC boards to signal that it had I2C communication error. We chose -5000 because it is outside of the possible range of raw values. In the case of I2C communication errors, it returns false else converts from the raw value coming from the boards to a value in Celsius Degree and returns true.
2. implemented getTemperatureSensorType(): is quite strait-forward. It basically returns the type of sensor configured for each motor.
3. when the update function is called by the correct callback function we check if :
   • the temperature exceeds the warning threshold. If yes it gives a warning message to the user
   • the temperature values as the I2C error value (-5000). If yes gives an error.

In both cases, we use two watchdog objects to avoid flooding the log with the above-mentioned warning.

[pattacini]

Awaiting the following PR to be merged before putting this in ready for review:

• Started work for temperature reading icub-firmware-shared#89

[valegagge]

We need to keep this issue in draft until the temperature reading feature doesn't pass tests on robots.

[valegagge]

Hi @MSECode !
Good work! 💪
I put some suggestions in the review comments.

We can also discuss f2f :)

[CLAassistant]

All committers have signed the CLA.

[MSECode]

Hi @valegagge,
check latest commits, if everything is fine you can do final review and then we can merge.
Yesterday I also updated the icub-firmware-build with the latest working versions we tested together.
One doubt is: do I need also to update the foc versions for icub3 and r1 or we can leave them unchanged since they do not have the temperature sensors.

[pattacini]

robotology/icub-firmware-shared#89 merged ✅
Enabling CI here.

[valegagge]

I just merged the robotology/icub-firmware-shared#89.

@pattacini can you put this pr in ready? thanks

[pattacini]

@pattacini can you put this pr in ready? thanks

Already done 😄