ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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.
2 | No.2 Revision |
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:
ros_control
controller as well (and combine it with the diff_drive_controller
)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).
3 | No.3 Revision |
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:
ros_control
controller as well (and combine it with the diff_drive_controller
)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).
4 | No.4 Revision |
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:
ros_control
controller as well (and combine it with the diff_drive_controller
gazebo_ros_control
, thereby guaranteeing it will run at exactly the same rate)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).