Ros rate is overwritten by action client and is not restored

[nakane11]

When running a loop in roseus_smach, I noticed that the loop rate becomes faster than the initially specified 10Hz after executing (send *ri* :angle-vector) in one of the nodes.

(setq sm (instance state-machine :init))
．．．
(ros::rate 10)
(do-until-key
  (ros::spin-once)
  (ros::sleep)
  (send sm :execute userdata :step -1))

I found that this is because the wait-for-result method of the controller-action-client overwrites the rate to 100Hz as seen here:

jsk_roseus/roseus/euslisp/actionlib.l

Line 203 in 71bc6fd

(ros::rate wait-rate)

I was able to resolve the issue by manually resetting the rate after the angle-vector call.

[mqcmd196]

Wow.

What is the best way to fix this?

Storing the rate variable at first, then restore it after getting the result?

[nakane11]

Here are two ways we could implement that solution. I think Method 1 is the more straightforward fix, but Method 2 is a significant change to the roseus.cpp specification and could potentially affect existing code that relies on the old "one global rate" behavior.

Method 1: Save & Restore

1. Add to roseus.cpp: We first need a way to get the current rate. We'd add a new function, ROSEUS_GET_RATE, that returns the current frequency (Hz) of the global s_rate.
2. Modify actionlib.l: We would wrap the wait-for-result.

;; In actionlib.l's wait-for-result method
(let ((original-rate (ros::get-rate))) ;; 1. Get the current global rate (e.g., 10Hz)
  (unwind-protect
       ;; --- Main logic ---
       (progn
         (ros::rate wait-rate) ;; 2. Set the desired local rate (e.g., 100Hz)
         ...
         (while (not (send self :wait-for-result-duration ...))
           (ros::sleep) ;; This sleep now uses 100Hz
           ))
     
     ;; --- Cleanup (this always runs) ---
     (ros::rate original-rate) ;; 3. Restore the original rate (10Hz)
  ))

Method 2: Group-Specific Rates

Instead of one global s_rate, we would change roseus.cpp to maintain a map of rates (s_mapRate), one for each NodeHandle group, just like it already does with s_mapHandle.

1. Modify roseus.cpp:

• s_rate becomes s_mapRate (a map<string, ...>).
• (ros::create-nodehandle "mygroup") would also create s_mapRate["mygroup"].
• (ros::rate HZ) would be updated to (ros::rate HZ &optional groupname).
• (ros::sleep) would be updated to (ros::sleep &optional groupname).

2. The smach code would become simpler and more robust. You would assign your loop to its own group:

(ros::create-nodehandle "smach_loop")
(ros::rate 10 "smach_loop") ;; Sets the rate *only* for "smach_loop"

;; Your loop
(do-until-key
  (ros::spin-once)
  (ros::sleep "smach_loop") ;; Sleeps using the 10Hz "smach_loop" rate
  (send sm :execute userdata :step -1))

Now, when actionlib.l calls (ros::rate 100) (with no groupname), it only changes the global rate. Your loop's rate, "smach_loop", is completely separate and remains untouched at 10Hz.