SERVICE_CALL_TIMEOUT = 1 second is harsh 🥵

[ymollard]

Description

For some reason, maybe over loaded network or CPU, listing the ros2 controllers of my robot is quite slow, a bit more than 1.0 second in average:

$ time ros2 control list_controllers
arm_controller          joint_trajectory_controller/JointTrajectoryController         active  
[...]
real    0m1.349s
user    0m0.658s
sys     0m0.144s

In consequence, the MoveIt ROS interface fails at executing the trajectory while the controller is actually ready to work.

I propose to increase the 1.0 second timeout to 10.0 seconds because 1.0 is really harsh, especially on slow computers.

Maybe a lower timeout would be more acceptable, as you prefer.

[sea-bass]

I would say "why not?"

Even better (if you're up for it), since this manager contains a ROS node, you could consider making this a ROS parameter so that users have the ability to control their timeouts. I can imagine in some cases if the system is this slow, it would be preferable to cause failures.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 45.87%. Comparing base (660175c) to head (e816fcc).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3382      +/-   ##
==========================================
- Coverage   46.24%   45.87%   -0.36%     
==========================================
  Files         717      717              
  Lines       62614    62593      -21     
  Branches     7571     7570       -1     
==========================================
- Hits        28949    28709     -240     
- Misses      33498    33717     +219     
  Partials      167      167              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ymollard]

if you're up for it

Not now ;) Can we maybe keep track of it in a CFC list somewhere?

[sea-bass]

Not now ;) Can we maybe keep track of it in a CFC list somewhere?

Yep, can just make a new Git issue for that.

In that case, would you mind reducing the timeout in this PR from 10 seconds to like 2 or 3, then? And just adding a TODO comment in the code for now?

[ymollard]

Done @sea-bass

[sea-bass]

Created #3405 to track the parameter thing...