ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
You need to publish your odometry on the /odom topic (or whatever you remap it as) as well as via tf.
base_local_planner
subscribes to /odom to get it's velocity information. Not publishing it will cause base_local_planner
to always output something near the min velocities (which is why the output changed when you changed your min vels), since it never receives feedback that the base has started moving, so it can't accelerate past the min velocity.
I'm a bit surprised that it didn't output something at least slightly greater than the set min_vel, since your acceleration is pretty high (compared to your min and max vels). Then again, I'm not 100% how base_local_planner
treats not receiving /odom updates at all, but I know for certain it won't work correctly without them.
2 | No.2 Revision |
You need to publish your odometry on the /odom topic (or whatever you remap it as) as well as via tf.
base_local_planner
subscribes to /odom to get it's velocity information. Not publishing it will cause base_local_planner
to always output something near the min velocities (which is why the output changed when you changed your min vels), since it never receives feedback that the base has started moving, so it can't accelerate past the min velocity.
I'm a bit surprised that it didn't output something at least slightly greater than the set min_vel, since your acceleration is pretty high (compared to your min and max vels). Then again, I'm not 100% how base_local_planner
treats not receiving /odom updates at all, but I know for certain it won't work correctly without them.them. I'm a little surprised you don't get any kind of warning for something like "no odom updates in the last N secs" or something... if this does turn out to be the problem, you should file a bug report against base_local_planner
to throw a warning if no odom is received for some amount of time.
3 | No.3 Revision |
You need to publish your odometry on the /odom topic (or whatever you remap it as) as well as via tf.
base_local_planner
subscribes to /odom to get it's velocity information. Not publishing it will cause base_local_planner
to always output something near the min velocities (which is why the output changed when you changed your min vels), since it never receives feedback that the base has started moving, so it can't accelerate past the min velocity.
I'm a bit surprised that it didn't output something at least slightly greater than the set min_vel, since your acceleration is pretty high (compared to your min and max vels). Then again, I'm not 100% how base_local_planner
treats not receiving /odom updates at all, but I know for certain it won't work correctly without them. I'm a little surprised you don't get any kind of warning for something like "no odom updates in the last N secs" or something... if this does turn out to be the problem, you should file a bug report against base_local_planner
to throw a warning if no odom is received for some amount of time.
EDIT: Here's the relevant callback from the base_local_planner source, trajectory_planner_ros.cpp
341 void TrajectoryPlannerROS::odomCallback(const nav_msgs::Odometry::ConstPtr& msg){
342 //we assume that the odometry is published in the frame of the base
343 boost::recursive_mutex::scoped_lock lock(odom_lock_);
344 base_odom_.twist.twist.linear.x = msg->twist.twist.linear.x;
345 base_odom_.twist.twist.linear.y = msg->twist.twist.linear.y;
346 base_odom_.twist.twist.angular.z = msg->twist.twist.angular.z;
347 ROS_DEBUG("In the odometry callback with velocity values: (%.2f, %.2f, %.2f)",
348 base_odom_.twist.twist.linear.x, base_odom_.twist.twist.linear.y, base_odom_.twist.twist.angular.z);
349 }