However, as @traversaro noticed, the motor temperature reading is done via an RPC call. Moreover, as @valegagge and @MSECode suggested https://github.com/ami-iit/bipedal-locomotion-framework/pull/813#discussion_r1511339493, we should use getTemperature instead of getTemperatures since the second method returns a non-complete vector if one of the motor temperature reading returns an error.
This has the consequence of needing to make n RPC calls, where n is the number of motors (e.g., 23), every 100ms (for the logger) - 500ms (for the walking controller). This may lead to unexpected behavior in the entire pipeline.
The desired approach would be to add the temperature reading in the stream, similar to the joint encoders or the motor PWM. In the meantime, we may consider splitting the reading of the RPC messages into a separate thread that runs at a lower frequency (e.g., once per second), but still, I think we should keep using getTemperatures and modify the logic there.
This issue aims to find a solution to enable correct temperature reading within the framework so the walking controller can react in case of issues with the motors.
@isorrentino opened https://github.com/ami-iit/bipedal-locomotion-framework/pull/813 to add the motor temperature reading in the sensor bridge and the associated YarpRobotLoggerDevice.
However, as @traversaro noticed, the motor temperature reading is done via an RPC call. Moreover, as @valegagge and @MSECode suggested https://github.com/ami-iit/bipedal-locomotion-framework/pull/813#discussion_r1511339493, we should use
getTemperature
instead ofgetTemperatures
since the second method returns a non-complete vector if one of the motor temperature reading returns an error.This has the consequence of needing to make
n
RPC calls, wheren
is the number of motors (e.g., 23), every100ms
(for the logger) -500ms
(for the walking controller). This may lead to unexpected behavior in the entire pipeline.The desired approach would be to add the temperature reading in the stream, similar to the joint encoders or the motor PWM. In the meantime, we may consider splitting the reading of the RPC messages into a separate thread that runs at a lower frequency (e.g., once per second), but still, I think we should keep using
getTemperatures
and modify the logic there.This issue aims to find a solution to enable correct temperature reading within the framework so the walking controller can react in case of issues with the motors.