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

Revision history [back]

In order for your cmd_vel callback to be called, you will have to have some node actually publishing to the cmd_vel topic. This could be a teleoperation node if you are driving around manually with a joystick or an autonomous controller like move_base.

To really simply test your code, you could try the following in another terminal while your base controller is running:

rostopic pub /cmd_vel geometry_msgs/Twist -r 20 '[1,0,0]' '[0,0,0.5]'

That will publish a Twist message corresponding to 1 meter/s of forwards motion and 0.5 rad/s of yaw at a rate of 20Hz.

You can also verify that a publisher is working by doing:

rostopic echo /cmd_vel

If you don't see any output from rostopic echo, then you should not expect a callback on the topic you echoed to be called.

In order for your cmd_vel callback to be called, you will have to have some node actually publishing to the cmd_vel topic. This could be a teleoperation node if you are driving around manually with a joystick or an autonomous controller like move_base., which is part of the ROS Navigation stack.

To really simply test your code, you could try the following in another terminal while your base controller is running:

rostopic pub /cmd_vel geometry_msgs/Twist -r 20 '[1,0,0]' '[0,0,0.5]'

That will publish a Twist message corresponding to 1 meter/s of forwards motion and 0.5 rad/s of yaw at a rate of 20Hz.

You can also verify that a publisher is working by doing:

rostopic echo /cmd_vel

If you don't see any output from rostopic echo, then you should not expect a callback on the topic you echoed to be called.

In order for your cmd_vel callback to be called, you will have to have some node actually publishing to the cmd_vel topic. This could be a teleoperation node if you are driving around manually with a joystick or an autonomous controller like move_base, which is part of the ROS Navigation stack.

To really simply test your code, you could try the following in another terminal while your base controller is running:

rostopic pub /cmd_vel geometry_msgs/Twist -r 20 '[1,0,0]' '[0,0,0.5]'

That will publish a Twist message corresponding to 1 meter/s of forwards motion and 0.5 rad/s of yaw at a rate of 20Hz.

You can also verify that a publisher is working by doing:

rostopic echo /cmd_vel

If you don't see any output from rostopic echo, then you should not expect a callback on the topic you echoed to be called.

Update to address followup questions

I'll address each individually:

  1. A properly configured move_base setup will output commands on the cmd_vel topic, as I'm guessing you expected. However, you have some tf errors that I'll address later that likely are preventing the navigation stack from getting very far in it's initialization process (or otherwise causing it to not output velocity commands). To check if the navigation stack is outputting velocity commands, you use rostopic echo as mentioned above. If I recall correctly, you'll also have to give the navigation stack a goal before it will output any commands. You can do that from rviz pretty easily; see the tutorial Using rviz with the Navigation Stack for details on how to setup a good visualization to use while running navigation.

  2. A geometry_msgs/Twist contains 6 fields (once expanded; see the online documentation for exact field names), hence the 6 different input values for rostopic pub (details on that command line syntax can be found at the YAML Commandline wiki page). Since you only output 3 of those 6 values in your callback (linear.x, linear.y, angular.z), you only see 3 values per message in the output from your node.

  3. It means that, as you have it configured, the navigation stack (specifically the costmaps) expect there to be a transform available between the /odom reference frame and the /base_footprint frame. If you are using different names for either of those reference frames, your configuration files will need to be updated to reflect that. You can see what available paths there are in the transform tree by running

    rosrun tf view_frames
    

    in a terminal while the rest of your code (that should be providing your required tf frames) is running. If you are still unsure about how to fix it after looking at the output of view_frames (a file called frames.pdf in the directory you ran view_frames from), please update your answer to include both frames.pdf and your config files (or links to those files).