You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@isorrentino opened #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 #813 (comment), 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.
The text was updated successfully, but these errors were encountered:
GiulioRomualdi
changed the title
Understand how to handle rpc reading in YarpSensorbridge
Understand how to handle rpc readings (e.g., the motor temperature) in YarpSensorbridge
Mar 13, 2024
@isorrentino opened #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 #813 (comment), 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.
The text was updated successfully, but these errors were encountered: