dan's profile - activity

I have a robot that senses and moves in reverse just as well as in forward. However, move_base trajectories are highly biased toward turning the robot around and moving forward. I tried setting prefer_forward_cost_function to 0.0 and also tied turning on and off DWA, but these have no apparent effect.

Is there some way to remove the forward bias in move_base?

Revised:

I tried the excellent suggestion of making min_vel_x negative and initially thought it worked, but in fact, it does not.

The output from move_base still does not generate negative x velocities. When given a goal to the rear, with a blank map, it turns 180 degrees and goes there. If I set max_vel_x = 0.0, then it just turns in place. Here is base_local_planner_params.yaml

Second revise: I swapped from TrajectoryPlanner to DWAPlanner (param file and move_base output shown below) but it does not seem to make any difference.

Third revise: I was entering DWAPlanner parameters, but did not select DWAPlanner as the local planner, so it was defaulting to TrajectoryPlanner. Adding this line to the parameter list fixed that and the bot now goes backwards.

base_local_planner: "DWAPlannerROS"

Many thanks to David Lu for his help with this.

controller_frequency: 4.0
recovery_behavior_enabled: true
clearing_rotation_allowed: false

DWAPlannerROS:
   max_vel_x: 0.3
   min_vel_x: -0.5
   max_rotational_vel: 0.5
   min_vel_theta: -0.5
   min_in_place_vel_theta: 0.2
   escape_vel: -0.1
   acc_lim_x: 2.3
   acc_lim_y: 2.3
   acc_lim_theta: 1.5

   holonomic_robot: false
   yaw_goal_tolerance: 0.1 # about 6 degrees
   xy_goal_tolerance: 0.2  # 20 cm
   latch_xy_goal_tolerance: false
   pdist_scale: 0.8
   gdist_scale: 0.6
   meter_scoring: true
   prefer_forward_cost_function: 0.0

   heading_lookahead: 1.0
   heading_scoring: false
   heading_scoring_timestep: 0.8
   occdist_scale: 0.1
   oscillation_reset_dist: 0.05
   publish_cost_grid_pc: false
   prune_plan: true

   sim_time: 1.5
   sim_granularity: 0.025
   angular_sim_granularity: 0.025
   vx_samples: 8
   vtheta_samples: 20
   dwa: true
   simple_attractor: false

Just in case it is useful, here is the output from move_base startup. Note that it is using rangefinders as sources and I thought maybe the rear sensors were creating an obstacle, but the behavior is unchanged with the hokuyo sensors removed.

SUMMARY
========

PARAMETERS
 * /map_server/frame_id: map
 * /move_base/DWAPlannerROS/acc_lim_theta: 1.5
 * /move_base/DWAPlannerROS/acc_lim_x: 2.3
 * /move_base/DWAPlannerROS/acc_lim_y: 2.3
 * /move_base/DWAPlannerROS/angular_sim_granularity: 0.025
 * /move_base/DWAPlannerROS/dwa: True
 * /move_base/DWAPlannerROS/escape_vel: -0.1
 * /move_base/DWAPlannerROS/gdist_scale: 0.6
 * /move_base/DWAPlannerROS/heading_lookahead: 1.0
 * /move_base/DWAPlannerROS/heading_scoring: False
 * /move_base/DWAPlannerROS/heading_scoring_timestep: 0.8
 * /move_base/DWAPlannerROS/holonomic_robot: False
 * /move_base/DWAPlannerROS/latch_xy_goal_tolerance: False
 * /move_base/DWAPlannerROS/max_rotational_vel: 0.5
 * /move_base/DWAPlannerROS/max_vel_x: 0.3
 * /move_base/DWAPlannerROS/meter_scoring: True
 * /move_base/DWAPlannerROS/min_in_place_vel_theta: 0.2
 * /move_base/DWAPlannerROS/min_vel_theta: -0.5
 * /move_base/DWAPlannerROS/min_vel_x: -0.5
 * /move_base/DWAPlannerROS/occdist_scale: 0.1
 * /move_base/DWAPlannerROS/oscillation_reset_dist: 0.05
 * /move_base/DWAPlannerROS/pdist_scale: 0.8
 * /move_base/DWAPlannerROS/prefer_forward_cost_function: 0.0
 * /move_base/DWAPlannerROS/prune_plan: True
 * /move_base/DWAPlannerROS/publish_cost_grid_pc: False
 * /move_base/DWAPlannerROS/sim_granularity: 0.025
 * /move_base/DWAPlannerROS/sim_time: 1.5
 * /move_base/DWAPlannerROS/simple_attractor: False
 * /move_base/DWAPlannerROS/vtheta_samples: 20
 * /move_base/DWAPlannerROS/vx_samples: 8
 * /move_base/DWAPlannerROS/xy_goal_tolerance: 0.2
 * /move_base/DWAPlannerROS/yaw_goal_tolerance: 0.1
 * /move_base/clearing_rotation_allowed: False
 * /move_base/controller_frequency: 4.0
 * /move_base/global_costmap/footprint: [[0 ...

I am trying to publish an odometry message from an arduino using rosserial. I have it publishing a tf message fine. But the odom message first required increasing the buffer_size and now gives this error:

[INFO] [WallTime: 1376950638.665497] ROS Serial Python Node
[INFO] [WallTime: 1376950638.671086] Connecting to /dev/ttyACM0 at 57600 baud
[INFO] [WallTime: 1376950641.232339] Note: publish buffer size is 1024 bytes
[INFO] [WallTime: 1376950641.232938] Setup publisher on tf [tf/tfMessage]
[INFO] [WallTime: 1376950641.242256] Setup publisher on odom [nav_msgs/Odometry]
Traceback (most recent call last):
  File ".../catkin_ws/src/rosserial/rosserial_python/nodes/serial_node.py", line 82, in <module>
    client.run()
  File ".../catkin_ws/install/lib/python2.7/dist-packages/rosserial_python/SerialClient.py", line 425, in run
    self.callbacks[topic_id](msg)
  File ".../catkin_ws/install/lib/python2.7/dist-packages/rosserial_python/SerialClient.py", line 99, in handlePacket
    m.deserialize(data)
  File "/opt/ros/groovy/lib/python2.7/dist-packages/nav_msgs/msg/_Odometry.py", line 220, in deserialize
    raise genpy.DeserializationError(e) #most likely buffer underfill
genpy.message.DeserializationError: unpack requires a string argument of length 288

Sometimes, about one in three, there is also this error right after the INFO messages shown above. I suspect it is just some sort of lost sync, since I just installed the latest version of rosserial on a new build of Groovy.

[ERROR] [WallTime: 1376951210.467803] Mismatched protocol version in packet: lost sync or rosserial_python is from different ros release than the rosserial client
[INFO] [WallTime: 1376951210.468270] Protocol version of client is Rev 0 (rosserial 0.4 and earlier), expected Rev 1 (rosserial 0.5+)

Here is the code:

/* 
 * rosserial Planar Odometry Example
 */

#include <ros.h>
#include <ros/time.h>
#include <tf/tf.h>
#include <tf/transform_broadcaster.h>
#include <nav_msgs/Odometry.h>

ros::NodeHandle  nh;

geometry_msgs::TransformStamped t;
tf::TransformBroadcaster broadcaster;
nav_msgs::Odometry myOdom;
ros::Publisher odom_pub("odom", &myOdom);

double x = 1.0;
double y = 0.0;
double theta = 1.57;

char base_link[] = "/base_link";
char odom[] = "/odom";

void setup()
{
  nh.initNode();
  broadcaster.init(nh);
  nh.advertise(odom_pub);
  myOdom.pose.covariance = {0.001, 0, 0, 0, 0, 0, // covariance on x
                        0, 0.001, 0, 0, 0, 0,  // covariance on y
                        0, 0, 0.001, 0, 0, 0,  // covariance on z
                        0, 0, 0, 99999, 0, 0,  // large covariance on rot x
                        0, 0, 0, 0, 99999, 0,  // large covariance on rot y
                        0, 0, 0, 0, 0, 0.001};  //covariance on rot z

}

void loop()
{  
  // drive in a circle
  double vx = 0.2, vy = 0.2;
  double vtheta = 0.18;
  x += cos(theta)*vx*0.1;
  y += sin(theta)*vy*0.1;
  theta += vtheta*0.1;
  if(theta > 3.14)
    theta=-3.14;

  /* 
  Serial.print("x , y, theta = ");
  Serial.print(x);
  Serial.print(", ");
  Serial.print(y);
  Serial.print(", ");
  Serial.println(theta);
  */

  // tf odom->base_link
  t.header.frame_id = odom;
  t.child_frame_id = base_link;

  t.transform.translation.x = x;
  t.transform.translation.y = y;

  t.transform.rotation = tf::createQuaternionFromYaw(theta);
  t.header.stamp = nh.now();

  broadcaster.sendTransform(t);
  nh.spinOnce();

  myOdom.header.stamp = nh.now();
  myOdom.header.frame_id ...