Don't perform catch-up behavior in ros2_control_node

[tylerjw]

Signed-off-by: Tyler Weaver tyler@picknik.ai

[bmagyar]

Could you please add a little bit of detail to this? 2 graphs if that's convenient or just a few numbers to illustrate why one wants to have no catch-up. It's mostly for future generations

[tylerjw]

I created this quickly when trying to help someone where when running with sim time and gazebo this loop ran at an uncontrolled rate. This cut the runaway behavior down but did not produce the expected result. This should probably just be closed and we should investigate how to make this loop work when running with sim time.

[destogl]

I created this quickly when trying to help someone where when running with sim time and gazebo this loop ran at an uncontrolled rate. This cut the runaway behavior down but did not produce the expected result. This should probably just be closed and we should investigate how to make this loop work when running with sim time.

Should we open an issue with description before closing this?

[JayHerpin]

I created this quickly when trying to help someone where when running with sim time and gazebo this loop ran at an uncontrolled rate. This cut the runaway behavior down but did not produce the expected result. This should probably just be closed and we should investigate how to make this loop work when running with sim time.

out of curiosity, is there a reason this code cant just use rclcpp::Rate with the node's clock? It seems like that would handle using sim time correctly. That also implements the "no catchup" behavior implemented here