Fix the motor temperature spike filtering in embObjMotionControl

[valegagge]

Bug description

In embObjMotionControl, a temperature monitor has been implemented to provide a warning to the user when the temperature goes beyond the warning threshold defined in the configuration file. Since the motor temperature reading suffers from disturbance there are some spikes that have not be take in consideration in the check of the warning threshold.

In addition, the current fw sends some negative values to encode some error cases. Also, this should be removed from the warning check.

Steps to reproduce

Just read the motor temperature. (In some motors the readings are noisier than others)

Expected behavior

In the log, there are any warnings related to the spikes of temperature

Example repository

No response

Additional context

No response

[valegagge]

Just a tip: for debugging and making the work, you can create an ad hoc fw that sometimes sends a spike. Of course, the final test has to be done on the robot

[MSECode]

After developing a first version of the filtering in the sw I've tested it by generating synthetic data with the aim of simulating a continuous rising of the temperatures with a pyramidal pattern. Basically, starting from 0 degree I've then risen the temperature of about 10 degree, so that the threshold between temperature at time interval i and i-1 (20 degree) it is not overcome. Then, after some steps I've instead increment the temperature to a higher value (around 110/120 degree in order to simulate a spike). And finally I've decreased again the temperature value. Part of the described behavior is shown in this image

Doing so, and looking at the logs of the YRI, it is possible to see that we do not have any warning related to the generated spike but the warning are just related to the overcoming of the warning temperature limit (set now to 40 degree just for test purposes) when the delta between current and previous temperature is lower than a defined threshold.

cc: @valegagge

[MSECode]

/reminder May, 21, 2024

Test on ROBOT ergoCub SN001 this day @valegagge @MSECode

[octo-reminder[bot]]

⏰ Reminder Tuesday, May 21, 2024 10:00 AM (GMT+02:00)

er

[octo-reminder[bot]]

🔔 @MSECode

er

[MSECode]

Tests on ergoCubSN001 robot

Today I've tested the feature related to this issue on ergoCubSN001. I tried to use the docker container but the image I've created was based on a version of icub_firmware_shared way newer than the one on the robot. So I couldn't use my docker image, otherwise it would have necessary to update all the boards due the different protocol versions between boards and torso cpu. Anyways, I managed to complete my tests by adding my branch of icub-main to the superbuild directory and temporarily recompiling icub-main and its dependencies in the robotology-suoerbuild using the command make ICUB from the build directory. Then I restored everything at the end of the tests and checked it was working fine.

Considering the result of the tests instead here follows a couple of images showing the logs in the YRI when running my changes and when instead running the robot at the current state. It is clear just from those screenshots that using a sw filtering for not taking into account the spikes in the temperature the terminal in not flood anymore with warning messages. It should be noted that for testing purposes I've temporarily reduced the value of the warning threshold, which has been then restored to its previous state.

Using filter on spikes

Screen 1

Screen 2

In the current local devel on the robot

Screen 1

Screen 2

NOTE 1 While calibrating I've noticed that there was some noise around the upper torso part of the robot. It seemed coming from the fan (something similar to coil whining ) on the torso or from the motors in the shoulder. I'm not sure. I suggest to check it if it is not known yet.

NOTE 2 I've commented out this line _temperatureSensorErrorWatchdog.at(motor).clear();

in the code since it was not correct generating a flooding of errors in yri.

[MSECode]

PR opened here:

https://github.com/robotology/icub-main/pull/961

[pattacini]

PR merged ✅ Probably, this issue can be closed as complete.

cc @MSECode @valegagge