matteolucchi
commented
3 years ago Hi @TheGreatLudini and thank you for your interest in robo-gym!
As it seems, if an action, in your case a joint trajectory, should be executed, the ROS bridge publishes this action to the command handler. The rate of this publisher almost equals the $action_cycle_rate (which is 25Hz by default), as the sleep time of this publisher is 1/action_cycle_rate - 0.01. Then, the command handler fills a queue with this action and publishes the traj_controller/command topic with a rate of $action_cycle_rate.
Yes exactly, you got this right.
I would guess that the action cycle time is represented by the variable $action_cycle_rate. But I cannot see an implementation of the robot-actuation cycle time.
This is also correct. The reason why in this case there is no implementation of the robot-actuation cycle time it's because the CH publishes a command to the JointTrajectory controller. The JointTrajectory controller keeps executing the last received command until a new command is received. In other words the JointTrajectory controller is the one that publishes low level control inputs with the robot-actuation cycle time, and given that this controller is part of already of the UR ROS Driver you don't see an implementation of the robot-actuation cycle time in the robot-server.
Should there be another variable that represents the robot-actuation cycle time, and then the command handler should use the specified rate from this variable to publish the command in traj_controller/command?
Exactly, I would suggest adding a second parameter, implemented like the action_cycle_rate, then I would calculate the ratio between the action_cycle_rate and the robot_actuation_cycle_rate. Let's assume action_cycle_rate=25 and robot_actuation_cycle_rate=125, this produces a ratio of 5, meaning that the CH should publish robot actuation commands at a frequency of 125 Hz repeating each action command 5 times.
Looking at the current implementation: https://github.com/jr-robotics/robo-gym-robot-servers/blob/bd00e4662a1af59384c8d5049450f9a0179711e7/ur_robot_server/scripts/joint_trajectory_command_handler.py#L10-L11
would be calculated based on the robot_actuation_cycle_rate:
ac_rate = rospy.get_param("~action_cycle_rate")
rc_rate = rospy.get_param("~robot_actuation_cycle_rate")
self.rate = rospy.Rate(rc_rate)and in the publisher loop
add a loop to publish the same robot actuation for the 'cycle ratio' number of times (5 in the example)
if self.queue.full():
for i in range(cycle_ratio):
self.jt_pub.publish(self.queue.get())
self.stop_flag = FalseI hope this helps to clarify the doubts :) If you any further questions don't hesitate to ask!
Cheers,
Matteo
Hello,
I am trying to implement my own command handler for a cartesian controller, but there are some things that I don't quite understand. I am using robo gym for a real robot (UR10e). As it seems, if an action, in your case a joint trajectory, should be executed, the ROS bridge publishes this action to the command handler. The rate of this publisher almost equals the $action_cycle_rate (which is 25Hz by default), as the sleep time of this publisher is 1/action_cycle_rate - 0.01. Then, the command handler fills a queue with this action and publishes the traj_controller/command topic with a rate of $action_cycle_rate.
The thing that confuses me is the following statement from the paper:
I would guess that the action cycle time is represented by the variable $action_cycle_rate. But I cannot see an implementation of the robot-actuation cycle time. Furthermore:
In the current implementation, it rather seems like the command handler retrieves the command from the queue, publishes it once and then empties the queue. How can I set the number of times this command should be published? Should there be another variable that represents the robot-actuation cycle time, and then the command handler should use the specified rate from this variable to publish the command in traj_controller/command?
Thank you very much in advance.