/request_axis_service is taking a long time to respond

[yushi-minemura]

Hello @samuelsadok,

I am using the odrive_can_node to rotate the botwheel. By starting the odrive_can_node and executing ros2 service call /request_axis_state odrive_can/srv/AxisState "axis_requested_state: 8", I was able to change to CLOSED LOOP mode. However, there was a delay of about 1 second in the response of the service after execution.

Upon checking the source code at

ros_odrive/odrive_node/src/odrive_can_node.cpp

Line 174 in 5e4dfe9

(std::chrono::steady_clock::now() - call_time >= std::chrono::seconds(1)); // wait for minimum one second

, I noticed that there is a 1-second wait process, and I believe this might be the cause of the delay.

Is the 1-second wait here because it takes 1 second for the response to be correct? Would it be difficult to change the axis_state without waiting for 1 second?

Best regards

[samuelsadok]

This is due to a limitation with the protocol which boils down to the fact that the status+error response ("heartbeat") doesn't echo a sequence number or similar. As a consequence, we don't know if a given status+error response was emitted before or after the request went through, and the ROS node could be returning the wrong result if it doesn't ignore too early responses. Note that the request could be delayed due to bus congestion, while the heartbeat is normally sent every 100ms.

The one second delay is a workaround for this, since it's unlikely that the request would be delayed by one second or more. You can probably reduce this and still get reliable results. However to fix it properly, a protocol change is required which we didn't get to yet. I'll make a note to revisit this.

[yushi-minemura]

Thank you for your response.

I now have a better understanding of the current situation, and I look forward to seeing improvements in this matter.