Accuracy of cmd_vel message

asked 2021-03-01 12:10:14 -0500

MadeleineP gravatar image

updated 2022-07-13 09:57:00 -0500

lucasw gravatar image

I have tried the following short program to control a Turtlebot 2 in both Gazebo and on a real Turtlebot 2.
The final position of the robot in both cases is far from that which I had expected. I apply a 1 rad/sec rotation for 3.14 seconds. I would expect very close to 1/2 a turn (pi radians) each cycle. But the result is about 20% farther. So in 5 cycles, I get about 3 full rotations. This is consistent with both the Gazebo simulation and with my physical Turtlebot.

So the question is: am I mis-understanding something? Or is this simply a case where relying on twist messages for a certain amount of time is just very inaccurate?

Regards, Madeleine.

int main(int argc, char** argv)
  ros::init(argc, argv, "simple_nav");

  const double rotVelocity = 1.0;         //radians / sec
  const double finalRotation = PI;

  ros::NodeHandle node;
  ros::Publisher cmdVelPub = node.advertise<geometry_msgs::Twist>("/mobile_base/commands/velocity", 1);
  ros::Rate loopRate(0.1);

  //Set up the message
  geometry_msgs::Twist msg;
  msg.angular.z = rotVelocity;

    double t0 = ros::Time::now().toSec();
    double t1 = ros::Time::now().toSec();
    double currentRot = 0.0;
    while((t1-t0) <= PI) {
      t1 = ros::Time::now().toSec();
      currentRot = rotVelocity * (t1-t0);
      std::cout << "Current rotation: " << currentRot << std::endl;


  return 0;
edit retag flag offensive close merge delete



Accuracy of cmd_vel message

The title is a bit strange after reading your question: cmd_vel is a topic. But it carries geometry_msgs/Twist messages, so the question is probably "Accuracy of Twist messages".

But a Twist encodes velocities, not positions, so accuracy would relate to how accurate it can encode a specific velocity (which isn't really that interesting).

I'm not an expert, but:

is this simply a case where relying on twist messages for a certain amount of time is just very inaccurate?

anything open-loop when friction and numerical uncertainties come into play seems like it could result in wildly different results from the expected outcome, so my first reaction would be: "yes, probably".

gvdhoorn gravatar image gvdhoorn  ( 2021-03-01 12:36:59 -0500 )edit