ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Which is the operational frequency of the diff_drive_controller?

This is a slightly ambiguous question, as it's actually the driver node (ie: the one that hosts the hardware_interface) that determines this. It's not a property of the controller.

Which is the operational frequency of the diff_drive_controller?

This is a slightly ambiguous question, as it's actually the driver node (ie: the one that hosts the hardware_interface) that determines this. It's not a property of the controller.

In the case of the Tiago simulation, gazebo_ros_control is used, which is added to the simulation here and is configured with a control rate of 1 kHz here.

So if the diff_drive_controller is loaded there, it should be updated at the same rate.

Plus, once I know it, in order to execute the desired trajectory, is it enough to do something like that?

cmd_vel_pub_ = nh.advertise<geometry_msgs::Twist>("cmd_vel", 1);
...
cmd_vel_pub.publish(cmd_vel_msg);
ros::Rate(controller_frequency).sleep();

where controller_frequency is, of course, the controller frequency.

You can certainly try this as a first approach.

Thing is: doing it this way won't time-synchronise your node with the Gazebo simulation, which complicates things (ie: there is no lock-step between your script and Gazebo's dynamics).

If time-synchronisation is important, afaik there are two possible approaches:

  • implement your controller as a ros_control controller as well (and combine it with the diff_drive_controller)
  • setup a lock-step setup with Gazebo

Neither of those are necessarily easy, but both should be doable. The latter has been discussed a few times both here on ROS Answers as well as on Gazebo Answers and might require a custom Gazebo plugin (but I'm not a Gazebo expert so I may be wrong).

Which is the operational frequency of the diff_drive_controller?

This is a slightly ambiguous question, as it's actually the driver node (ie: the one that hosts the hardware_interface) that determines this. It's not a property of the controller.

In the case of the Tiago simulation, gazebo_ros_control is used, which is added to the simulation here and is configured with a control rate of 1 kHz here.

So if the diff_drive_controller is loaded there, it should be updated at the same rate.

Plus, once I know it, in order to execute the desired trajectory, is it enough to do something like that?

cmd_vel_pub_ = nh.advertise<geometry_msgs::Twist>("cmd_vel", 1);
...
cmd_vel_pub.publish(cmd_vel_msg);
ros::Rate(controller_frequency).sleep();

where controller_frequency is, of course, the controller frequency.

You can certainly try this as a first approach.

Thing is: doing it this way won't time-synchronise your node with the Gazebo simulation, which complicates things (ie: there is no lock-step between your script and Gazebo's dynamics).

If time-synchronisation is important, important (and because of the potential for Gazebo simulations to run at a slower rate than Wallclock it probably is), afaik there are two possible approaches:

  • implement your controller as a ros_control controller as well (and combine it with the diff_drive_controller)
  • setup a lock-step setup with Gazebo

Neither of those are necessarily easy, but both should be doable. The latter has been discussed a few times both here on ROS Answers as well as on Gazebo Answers and might require a custom Gazebo plugin (but I'm not a Gazebo expert so I may be wrong).

Which is the operational frequency of the diff_drive_controller?

This is a slightly ambiguous question, as it's actually the driver node (ie: the one that hosts the hardware_interface) that determines this. It's not a property of the controller.

In the case of the Tiago simulation, gazebo_ros_control is used, which is added to the simulation here and is configured with a control rate of 1 kHz here.

So if the diff_drive_controller is loaded there, it should be updated at the same rate.

Plus, once I know it, in order to execute the desired trajectory, is it enough to do something like that?

cmd_vel_pub_ = nh.advertise<geometry_msgs::Twist>("cmd_vel", 1);
...
cmd_vel_pub.publish(cmd_vel_msg);
ros::Rate(controller_frequency).sleep();

where controller_frequency is, of course, the controller frequency.

You can certainly try this as a first approach.

Thing is: doing it this way won't time-synchronise your node with the Gazebo simulation, which complicates things (ie: there is no lock-step between your script and Gazebo's dynamics).

If time-synchronisation is important (and because of the potential for Gazebo simulations to run at a slower rate than Wallclock it probably is), afaik there are two possible approaches:

  • implement your controller as a ros_control controller as well (and combine it with the diff_drive_controller)): it will then run in the same execution context as gazebo_ros_control, thereby guaranteeing it will run at exactly the same rate)
  • setup a lock-step setup with Gazebo

Neither of those are necessarily easy, but both should be doable. The latter has been discussed a few times both here on ROS Answers as well as on Gazebo Answers and might require a custom Gazebo plugin (but I'm not a Gazebo expert so I may be wrong).