this following the Instructions for desktop full install from source:

  [rosbuild] Building package map_server
  Failed to invoke /home/kruset/groovy_underlay/install_isolated/bin/rospack deps-manifests map_server
  [rospack] Error: package/stack 'map_server' depends on non-existent package 'common_rosdeps' and rosdep claims that it is not a system dependency. Check the ROS_PACKAGE_PATH or try calling 'rosdep update'

This not just for map_server, but several other packages in the nav stack:

./stack.xml
./rotate_recovery/manifest.xml
./dwa_local_planner/manifest.xml
./costmap_2d/manifest.xml
./base_local_planner/manifest.xml
./carrot_planner/manifest.xml
./move_slow_and_clear/manifest.xml
./move_base/manifest.xml
./clear_costmap_recovery/manifest.xml
./navfn/manifest.xml

I guess just removing the dependency from manifest.xml should be okay, though I am not 100% sure about its implications.

Hi, I wrote a problem with the last ros-fuerte update in ros answers, I copy the content:

Thanks!

Dear Ros community,

After the last update in ros fuerte, move_base and map_server die after launch them with launch apps [1][2] that used to work properly.

They doesn't give much information, for instance:

[move_base-3] process has died [pid 10283, exit code -4, [...]
I tried to find a solution and I haven't found any.

This is the configuration of the system:

Ubuntu 12.04 64bit
ROS Fuerte
ros-fuerte-navigation 1.8.3-s1367591379~precise
Has anybody found a similar problem? or have a clue of a possible problem/solution?

Thanks in advance,

see you saturday!

[1] http://devel.iri.upc.edu/pub/labrobotica/ros/iri-ros-pkg/stacks/iri_teaching/upc_mobrob/launch/fuerte/sim_stage_navigation.launch

[2] http://devel.iri.upc.edu/pub/labrobotica/ros/iri-ros-pkg/stacks/iri_teaching/upc_mobrob/launch/fuerte/sim_move_base.launch

ROS-ANSWERS: http://answers.ros.org/question/62453/several-died-after-update-ros-fuerte-navigation-version-183/

Costmap2DPublisher class publishes the contents of a Costmap2D in an OccupancyGrid message without changing the data values in the grid. OccupancyGrid says:

# The map data, in row-major order, starting with (0,0).  Occupancy
# probabilities are in the range [0,100].  Unknown is -1.
int8[] data

So the bytes are signed and go from -1 to 100. Costmap2DPublisher publishes values which are unsigned bytes and have meaningful values from 0 to 255.

I believe the right solution is to define a new message type, "Costmap" (and "CostmapUpdate") which specify the 0-255 value range, and make the new enhanced_nav_display rviz Costmap display plugin use those messages.

Since sometimes it is nice to use something based on messages instead of a service.

Background:

costmap_2d has a notion of "inflating" obstacles, first to the "inscribed radius" of the robot's footprint polygon with a value called "INSCRIBED_INFLATED_OBSTACLE" (253) and then down from there on a curve until it gets to the max inflation radius set in the parameters.

The idea with the inscribed radius is that once you inflate an obstacle, the center of the robot can't be on a point marked INSCRIBED_INFLATED_OBSTACLE because you know that is closer than the minimum radius of the robot to an obstacle. So then you can use that to make a really fast way of checking if the robot is allowed to be somewhere or not - first check the center of the robot for that value, if it is there, the answer is a quick "NO". If it is something less than that, you have to take the perimeter of the robot into account and the orientation of it, etc.

Bug:

The current version of costmap_2d inflates obstacles just a little bit too much. It uses the "ceil()" function to round UP to the nearest integer the robot's inscribed radius divided by the size of a map cell. The result is, when the robot's bounding polygon (at its inscribed radius) is immediately next to an obstacle cell in the costmap, the obstacle cell will inflate to cover the current center of the robot. Because it is over the current center, the local planner and global planner will never find any valid plan away from that point and the robot will be stuck forever. Just zero-ing out the current robot position after inflation is not sufficient, because the robot may be rectangular and have room to drive straight ahead, but it would still think it can't move off of that spot.

Image shows start and goal location dots with valid potential field defined between them, but the calcPath() function (drawn in cyan) does not get all the way between them. Looking at the path coordinates, it ends up oscillating between two points at the upper end of the cyan path.

The headers use angles/angles.h but the CMakeLists.txt does neither find_package() nor CATKIN_DEPENDS it.

https://github.com/ros-planning/navigation/blob/hydro-devel/fake_localization/CMakeLists.txt#L24 has a spelling error for the catkin include dirs.

[Originally posted by kluessen on kforge trac]

In base_local_planner/prefer_forward_cost_function.h line 60

penalty_ is declared as bool, but due to usage in .cppfile it should be declared as double instead.

--- a/base_local_planner/include/base_local_planner/prefer_forward_cost_function.h Wed Jul 04 12:08:58 2012 +0200
+++ b/base_local_planner/include/base_local_planner/prefer_forward_cost_function.h Tue Jul 17 14:46:03 2012 +0200
@@ -57,7 +57,7 @@
   }

 private:
-  bool penalty_;
+  double penalty_;
 };

 } /* namespace base_local_planner */

Not sure if this is bug... I posted as ros answer and someone suggested to open an issue. Looks like move_base action client's cancelGoal doesn't work while executing recovery behavior. That is, if I call cancelGoal or cancelAllGoals, the subsequent call to waitForResult doesn't return until all recovery fails. If I disable recovery behavior meanwhile with dynamic_reconfigure. doesn't returns until recovery fails (more than 2 minutes!). I suppose move_base gets somehow blocked when running recovery behavior and don't even attend reconfigure requests.

I'm using hydro-devel code, but I experienced the same with groovy package installation.

In groovy nav, you could put your footprint param in the costmaps and they would read it. In hydro nav, the costmaps subscribe to the footprint as a topic. The costmaps no longer read the rosparam. move_base now looks for a rosparam for the footprint and publishes it if it finds one. However it is looking in the move_base namespace and above, which misses the footprints described in the costmap namespaces.

Move the footprint-param-reading calls into costmap_2d_ros.

Setting clearing_rotation_allowed parameter as false doesn't prevent the robot to make in place rotations as it's supposed to do (to my understanding of the wiki documentation). In fact, it looks like the parameter value has no effect at all.

There'is any problem or I misunderstood the use of this parameter?

On the PR2 on Fuerte, the move_base uses 60-70% CPU while actively navigating, and performs very smoothly. On Groovy, move_base uses upwards of 110% CPU while actively navigating, and fails to meet the control loop speed of 10Hz, resulting in choppy motion and poor navigation.

A reset service call for robot_pose_ekf

the origin_* names are confusing. The parameters refer to where the ROBOT is.

I am running on Ubuntu 12.04, 64-bit, ROS Fuerte, and using rosbuild. I am using the navigation-1.8 branch from this repository. My rosinstall entry is:

- git:
    uri: https://github.com/ros-planning/navigation.git
    local-name: ros/navigation
    version: navigation-1.8

After running rosmake navigation in this workspace I run:

rosws status --untracked

and get the following output:

??      ros/navigation/amcl/bin/
??      ros/navigation/amcl/build/
??      ros/navigation/amcl/cfg/AMCL.cfgc
??      ros/navigation/amcl/cfg/cpp/
??      ros/navigation/amcl/docs/
??      ros/navigation/amcl/lib/
??      ros/navigation/amcl/src/amcl/
??      ros/navigation/base_local_planner/build/
??      ros/navigation/base_local_planner/cfg/BaseLocalPlanner.cfgc
??      ros/navigation/base_local_planner/cfg/LocalPlannerLimits.cfgc
??      ros/navigation/base_local_planner/cfg/cpp/
??      ros/navigation/base_local_planner/docs/
??      ros/navigation/base_local_planner/lib/
??      ros/navigation/base_local_planner/msg_gen/
??      ros/navigation/base_local_planner/point_grid
??      ros/navigation/base_local_planner/src/base_local_planner/
??      ros/navigation/base_local_planner/src/local_planner_limits.pyc
??      ros/navigation/carrot_planner/build/
??      ros/navigation/carrot_planner/lib/
??      ros/navigation/clear_costmap_recovery/build/
??      ros/navigation/clear_costmap_recovery/lib/
??      ros/navigation/costmap_2d/bin/
??      ros/navigation/costmap_2d/build/
??      ros/navigation/costmap_2d/cfg/Costmap2D.cfgc
??      ros/navigation/costmap_2d/cfg/cpp/
??      ros/navigation/costmap_2d/docs/
??      ros/navigation/costmap_2d/lib/
??      ros/navigation/costmap_2d/msg_gen/
??      ros/navigation/costmap_2d/src/costmap_2d/
??      ros/navigation/costmap_2d/test/costmap_tester
??      ros/navigation/dwa_local_planner/build/
??      ros/navigation/dwa_local_planner/cfg/DWAPlanner.cfgc
??      ros/navigation/dwa_local_planner/cfg/cpp/
??      ros/navigation/dwa_local_planner/docs/
??      ros/navigation/dwa_local_planner/lib/
??      ros/navigation/dwa_local_planner/src/dwa_local_planner/
??      ros/navigation/fake_localization/build/
??      ros/navigation/fake_localization/fake_localization
??      ros/navigation/map_server/bin/
??      ros/navigation/map_server/build/
??      ros/navigation/map_server/lib/
??      ros/navigation/move_base/bin/
??      ros/navigation/move_base/build/
??      ros/navigation/move_base/cfg/MoveBase.cfgc
??      ros/navigation/move_base/cfg/cpp/
??      ros/navigation/move_base/docs/
??      ros/navigation/move_base/src/move_base/
??      ros/navigation/move_base_msgs/build/
??      ros/navigation/move_base_msgs/msg/
??      ros/navigation/move_base_msgs/msg_gen/
??      ros/navigation/move_base_msgs/src/
??      ros/navigation/move_slow_and_clear/build/
??      ros/navigation/move_slow_and_clear/lib/
??      ros/navigation/nav_core/build/
??      ros/navigation/navfn/bin/
??      ros/navigation/navfn/build/
??      ros/navigation/navfn/lib/
??      ros/navigation/navfn/navtest
??      ros/navigation/navfn/src/navfn/
??      ros/navigation/navfn/srv_gen/
??      ros/navigation/robot_pose_ekf/bin/
??      ros/navigation/robot_pose_ekf/build/
??      ros/navigation/robot_pose_ekf/lib/
??      ros/navigation/robot_pose_ekf/src/robot_pose_ekf/
??      ros/navigation/robot_pose_ekf/srv_gen/
??      ros/navigation/rotate_recovery/build/
??      ros/navigation/rotate_recovery/lib/
??      ros/navigation/voxel_grid/bin/
??      ros/navigation/voxel_grid/build/
??      ros/navigation/voxel_grid/lib/

I would like to add a .gitignore file to the branch I am using.

[originally reported by kluessen on kforge trac]

the boolean latch_xy_goal_tolerance_, declared in Line 88 in latched_stop_rotate_controller.h,
is used a lot in the latched_stop_rotate_controller.

It is never initialized, but it is essential for the isGoalReached() function to return true.
Line 84, Line 88 in latched_stop_rotate_controller.cpp

MoveBase.action is a useful ROS interface to adhere to with any kind of navigation algorithm. Unfortunately even lightweight implementations need to depend on the "heavy" navigation stack for only the message / action declaration.

Ideally MoveBase.action would reside in common_msgs/nav_msgs so that it can be used without a large dependency (or even compilation) overhead.

From ROS Answers:
http://answers.ros.org/question/54467/is-amcls-implementation-of-the-odometry-model-correct/

I looked into this and found that AMCL does mix units:
At
https://github.com/ros-planning/navigation/blob/groovy-devel/amcl/src/sensors/amcl_odom.cpp#L119
and
https://github.com/ros-planning/navigation/blob/groovy-devel/amcl/src/sensors/amcl_odom.cpp#L181
It passes in alpha * delta*delta, which results in units^2 passed into pf_ran_gaussian

However, this conflicts with the implementation of pf_ran_gaussian:
https://github.com/ros-planning/navigation/blob/groovy-devel/amcl/src/pf/pf_pdf.c#L132

This generates a sampled normalized random gaussian number with zero_mean and standard deviation one (http://www.taygeta.com/random/gaussian.html), and then multiplies it by the standard_deviation passed into the function for the output in order to stretch the domain (http://en.wikipedia.org/wiki/Normal_distribution#General_normal_distribution). However, when we pass in a variance, we get a variance * gaussian out, which leaves us with unit^2. We then take this value and add it to the standard_deviation, thus mixing units of unit - unit^2.

The solution seems to be taking the square-root of the term we pass into pf_ran_gaussian.

When navfn is asked to make a plan which ends up being quite long, the plan that is returned starts somewhere between the start and goal and ends at the goal. Usually such plans are not usable because they don't tell the robot which way to go from their current location.

Attached image shows start location as a yellow square in upper right and goal location as a green square on left side. Generated path (in cyan) does not start at the start.

so client can react accordingly. I typically experience three kinds of failures. I didn't check the code, but I suppose there're some others:

• Oscillation timeout many times happen because the robot is physically blocked
• Plan failed, as a valid plan cannot be found
• Controller failed, as a safe velocity command cannot be found

This got commented out during the layered costmap conversion or possibly catkinization. Should be uncommented and tested.

[Originally posted by kluessen to kforge trac]

In obstacle_cost_function.cpp - Line 83 et seq.

You use this for loop to score every point from the given trajectory considering the footprint of the robot. But in every loop circle you overwrite the cost variable, so in the end it just contains the cost of last point of the trajectory.

Either you plan to integrate an aggregationType like LAST, SUM, PRODUCT as done in the MapGridCostFunction?, which is used to score trajectories (map_grid_cost_function.cpp - line 111 ). Otherwise the for loop is just a waste of computation time. Or did I get something wrong here?

Plugin dwa_local_planner uses path_distance_bias/goal_distance_bias/occdist_scale, but base_local_planner uses pdist_scale/gdist_scale/occdist_scale with the same semantics. I propose to unify using the latest on hydro.

The wiki page for base_local_planner was also wrong (I changed), as are the configuration for some robots, as Turtlebot: it uses base_local_planner but sets dwa_local_planner parameters.

Something similar happens with other parameters min_in_place_rotational_vel/min_in_place_vel_theta or max_rotational_vel/max_vel_theta: the dynamic parameter and the (old?) name differs.

[originally posted by corot to kforge trac]

Given that tf request a tree structure, in some cases is interesting to disable the amcl root level transforms broadcasting.
I set default value to true, so this change is innocuous for anyone not intentionally disabling transform broadcasting

[Download link for attached patch file]
https://kforge.ros.org/navigation/trac/raw-attachment/ticket/12/amcl_node.tf_bradcast.patch

While evaluating kidnap recovery through global_localization service, I have realized that almost never the best hypothesis points west-ward. After googling a bit, I found this in a player-stage project mailing list:

http://player-stage-gazebo.10965.n7.nabble.com/AMCL-problem-with-clustering-in-west-direction-td2731.html

Looks like an old, never solved problem.

Some time between Fuerte and Groovy this behavior was introduced.

PR2 drives from start to goal just fine if planned path initially takes PR2 forward away from present location.

However if planned path requires a turn-in-place at the start of the plan, the robot does not do the turn-in-place. Instead it strafes side to side, back and forth. It does this dance until either a new path is planned which is relatively forward from it, or until it times out and the nav goal is declared a failure.

[originally posted by kruset in kforge trac]

As suggested, I checked out the HEAD of the navigation stack and tried to run the dwa_local_planner.

I ran into a problem. The transformed plan of the local planner was empty. I figured out that there is a bug in line 116 in the goal_functions.cpp. You tried to transform the current robot position into the global_plan coordinate system ("map"). Therefor you use the global_frame of the local costmap ("odom") as source frame.

But you should use the base_frame of the costmap ("base_link") instead.

Comment:
Bug introduced in r828 (groovy branch), using bad frame to get robot pose in plan frame.

The make_plan service call to move_base is currently available only when move_base is in an inactive state, in other words when it is not driving the robot somewhere and not making a plan for someone else, etc.

The reason seems to be that the make_plan service call uses the same instance of the costmap and other data structures as the planner which directs the robot. This does not need to be the case however... the service call could copy the costmap and other relevant data and start work immediately. There may be CPU contention, but that can be managed by the caller.

A workaround until this is fixed may be to run a separate instance of move_base just for the service calls, but this duplicates the work of updating the costmaps.

Hi,

in our environment we notice occasional invalid plans created by move_base. I set up a tiny rosbuild package with a stage config and a move_base config based on the navigation_tutorials/navigation_stage package here:
https://github.com/tkruse/adream_stage

There are two failures occuring regularly enough to be reproduced, globals plans passing through walls (https://github.com/tkruse/adream_stage/blob/master/images/fail_wall.png) and global plans starting halfway to the goal (https://github.com/tkruse/adream_stage/blob/master/images/fail_halfway.png).

The images are contained in the github project, and the green line shows the invalid global path.

To reproduce, in fuerte, install all dependencies of the package, then run

roslaunch adream_stage adream_stage.launch

I could not get this to reproduce for every single time we plan, but i set the planning frequency to 10, so every time I run a fresh roscore and plan roughly like in the images, I can see the halfway plan bug, and every 2nd time or so I observe the plan going through the wall.

Note that in order to reproduce, I use to often kill all the roslaunch file and start again from the initial situation.

This might of course be a bad parameters issue, if so please advise which parameter may be causing this.

In Groovy, I could observe the planning through walls still, but not planning from a halfway position. in Hydro, I could not observe any problems, so maybe you'll close this issue as "fixed". Maybe you can still recommend some solution for fuerte users, e.g. using latest navigation stack from source in fuerte.

I get these on startup:

[ INFO] [1370991386.152623463]: Received a 1203 X 993 map at 0.050000 m/pix
process[slot_io-17]: started with pid [27776]
[ INFO] [1370991386.262703727]: Using plugin "obstacles"
[ INFO] [1370991386.268073389]:     Subscribed to Topics: head_cloud_marking head_cloud_clearing base_scan
[ERROR] [1370991386.392674340]: Tried to advertise a service that is already advertised in this node [/move_base/global_costmap/obstacles/set_parameters]
[ INFO] [1370991386.442401938]: Using plugin "inflater"
[ INFO] [1370991387.002144270]: Using plugin "obstacles"
[ WARN] [1370991387.113406247]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 0.6102 seconds
[ WARN] [1370991387.137904135]: The root link base_link has an inertia specified in the URDF, but KDL does not support a root link with an inertia.  As a workaround, you can add
 an extra dummy link to your URDF.
[ INFO] [1370991387.138267428]:     Subscribed to Topics: head_cloud_marking head_cloud_clearing base_scan
[ERROR] [1370991387.241637697]: Tried to advertise a service that is already advertised in this node [/move_base/local_costmap/obstacles/set_parameters]
...

Might not be a functional issue, but something seems to be wrong there.

Related discussion on SIG:
https://groups.google.com/forum/?fromgroups#!topic/ros-sig-navigation/dN3h8msTDzg

[Originally reported by moesenle on kforge trac]

It happens too often that people create a really large map (e.g. 200x200m, 2.5cm resolution ~ 64mb) that mostly contain unknown space. Such large maps actually caused rviz to eat up all my memory during the PR2 workshop last week. That makes be believe that it would be best if the map server actually crops everything that doesn't really contain any information, i.e. that's unknown space.

Find a patch for cropping the map attached.. I added a ros parameter crop that allows for enabling (currently default) or disabling that functionality.

[Download link for original attachment]
https://kforge.ros.org/navigation/trac/raw-attachment/ticket/5/map-server-crop-map.patch

amcl finds the pose of each laser rangefinder relative to base_link the first time it receives a scan from it, then stores that pose indefinitely, never updating it.

It should be relatively simple to switch to using a tf::MessageFilter and look up the relative pose every time.

For @chadrockey

Right now robot_pose_ekf is hard coded to transform from odom_combined to base_footprint, and relies on an external source to provide the tilt transform from base_footprint to base_link.

This should be pulled into robot_pose_ekf such that it just transforms from odom -> base_link including roll and pitch. And provides base_footprint as a backwards compatability option as a child of base_link.

This is probably an unintended consequence of my fix for #26, not sure. It's possible this is caused by a bug in costmap_2d, but regardless it is definitely a bug.

(Reported by Ming Gao via email)

I am using ros hydro, and my os is ubuntu precise 32bit. Recently I encountered a problem when using the costmap_2d package within ros hydro.
I tested it with costmap_2d_node using the proper parameters, but the program stopped because of the famous warning information from eigen:

/usr/include/eigen3/Eigen/src/Core/DenseStorage.h:69: Eigen::internal::plain_array<t, size,="" matrixorarrayoptions,="" 16="">::plain_array() [with T = float, int Size = 4, int MatrixOrArrayOptions = 0]: Assertion `(reinterpret_cast<size_t>(array) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/dox-devel/TopicUnalignedArrayAssert.html" " * READ THIS WEB PAGE !!! *"' failed.

And I tried to use gdb to get some more details about this crash, and it seems that the problem comes from the observation_buffer.cpp file in the costmap_2d package, as it deals with the pcl point cloud. The last several calls before the crash are shown below:

#1 0xb715f1df in raise () from /lib/i386-linux-gnu/libc.so.6

#2 0xb7162825 in abort () from /lib/i386-linux-gnu/libc.so.6

#3 0xb7158085 in ?? () from /lib/i386-linux-gnu/libc.so.6

#4 0xb7158137 in __assert_fail () from /lib/i386-linux-gnu/libc.so.6

#5 0xb76abff1 in ?? () from /opt/ros/hydro/lib/libcostmap_2d.so

#6 0xb76b4682 in costmap_2d::ObservationBuffer::bufferCloud(pcl::PointCloud<pcl::pointxyz> const&) () from /opt/ros/hydro/lib/libcostmap_2d.so

#7 0xb76b4a61 in costmap_2d::ObservationBuffer::bufferCloud(sensor_msgs::PointCloud2_<std::allocator<void> > const&) () from /opt/ros/hydro/lib/libcostmap_2d.so

#8 0xb2228421 in costmap_2d::ObstacleLayer::laserScanCallback(boost::shared_ptr<sensor_msgs::laserscan_<std::allocator<void> > const> const&, boost::shared_ptr<costmap_2d::observationbuffer> const&) () from /opt/ros/hydro/lib/liblayers.so

#9 0xb2231eb3 in boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf2<void,="" costmap_2d::obstaclelayer,="" boost::shared_ptr<sensor_msgs::laserscan_<std::allocator<void=""> > const> const&, boost::shared_ptr<costmap_2d::observationbuffer> const&>, boost::_bi::list3<boost::_bi::value<costmap_2d::obstaclelayer*>, boost::arg<1>, boost::_bi::value<boost::shared_ptr<costmap_2d::observationbuffer> > > >, void, boost::shared_ptr<sensor_msgs::laserscan_<std::allocator<void> > const> const&>::invoke(boost::detail::function::function_buffer&, boost::shared_ptr<sensor_msgs::laserscan_<std::allocator<void> > const> const&) () from /opt/ros/hydro/lib/liblayers.so

#10 0xb223a346 in boost::detail::function::void_function_obj_invoker1<boost::function<void (boost::shared_ptr<sensor_msgs::laserscan_<std::allocator<void=""> > const> const&)>, void, boost::shared_ptr<sensor_msgs::laserscan_<std::allocator<void> > const> >::invoke(boost::detail::function::function_buffer&, boost::shared_ptr<sensor_msgs::laserscan_<std::allocator<void> > const>) () from /opt/ros/hydro/lib/liblayers.so

#11 0xb225adae in message_filters::CallbackHelper1T<boost::shared_ptr<sensor_msgs::laserscan_<std::allocator<void> > const> const&, sensor_msgs::LaserScan_<std::allocator<void> > >::call(ros::MessageEvent<sensor_msgs::laserscan_<std::allocator<void> > const> const&, bool) () from /opt/ros/hydro/lib/liblayers.so

#12 0xb22455be in message_filters::SimpleFilter<sensor_msgs::laserscan_<std::allocator<void> > >::signalMessage(ros::MessageEvent<sensor_msgs::laserscan_<std::allocator<void> > const> const&) () from /opt/ros/hydro/lib/liblayers.so

I never had this problem in previous ros version (ros fuerte, I did not test this with ros groovy).

in groovy, one can

rosrun stage stageros

in hydro, that is

rosrun stage_ros stageros

This breaks launch files using stage (ROS tutorials and such). It would be nicer to have tick-tock deprecation of stage/stageros if that was intentional, meaning an executable in the stage package that reports an warning that launch files have to be migrated an such, one distro before the old executable is removed.

If this was not intentional, undo.

[Originally submitted to kforge trac by ben cohen]

From the sushi challenge, I realized that the point cloud from the tilt laser (and all sensors) is not filtered with the robot_self_filter. For mobile manipulation's sake, I think that it would be very helpful if the tilt laser was filtered so that the arms don't have to be completely tucked and we the robot can carry things.

I think this will become even more urgent in the near future as people start doing more mobile manipulation tasks with their robots.

Thanks a lot! I'd be more than happy to discuss this further...

(We used the stock Electric version of move_base)

Please keep support for TrajectoryPlannerROS after merging the layered-costmaps code mentioned in this ros-users announcement. It is essential for our getting navigation to work on our diff-drive, non-holonomic robot. The dwa_local_planner may be fine on a holonomic robot, but on non-holonomic robots it always ends up commanding a straight sideways motion (x and yaw vel = 0, y vel > 0), but our robot can't move sideways, so it gets stuck. (This is just one extreme case of problems caused by a y velocity planned by DWA, but ignored by our controller; we must have a local planner that only uses x and yaw).

I was testing the eband_local_planner against hydro-devel branch to give a shot at the layered_costmap feature. I've encountered a few problems trying to get it layered costmaps to work appropriately that I'll try and explain here:

Configuration:
Common Costmap Parameters
Global Costmap Parameters
Local Costmap Parameters
Map

Here's a video (75MB) showing rviz output. I first show the underlying map, then the local costmap (0:18) and then the global costmap (0:44). I had the following questions:

1. The global costmap looks as expected. However, it does not seem to be taking into account the new box I've placed in. I know that the global costmap is working fine, as navfn is taking that box into account, but I am not sure why the visualization is off.
2. The local costmap appears to be pretty broken. Whenever I query a cost in the local costmap, I always get a value of freespace unless I have run into an obstacle. There seem to be no interim values. This is problematic as the eband approach requires knowing the distance of a point to the closest obstacle (which works on the groovy debs). Consequently, the robot appears to be running blind.
3. The voxel grid seems to be correct at all times. There are a few spurious radings here or there, but I am not sure if those are simulation issues or not.

I'll try and provide whatever information is necessary to figure this out.

[Originally reported by kluessen on the kforge trac]

The setup_ variable is never initialized. This may prevent the planner from saving a default_config in the reconfigureCB() - line 55 dwa_local_planner_ros.cpp

I suggest initializing it with false in the constructor of the dwa_planner

--- a/dwa_local_planner/src/dwa_planner_ros.cpp Wed Jul 04 12:08:58 2012 +0200
+++ b/dwa_local_planner/src/dwa_planner_ros.cpp Fri Jul 13 13:37:30 2012 +0200
@@ -88,7 +88,8 @@
   }

   DWAPlannerROS::DWAPlannerROS() : initialized_(false),
-      odom_helper_("odom") {
+      odom_helper_("odom"),
+      setup_(false) {

   }

When setting the /move_base_node param to a low frequency above 0, e.g. 0.5, then this frequency delays replanning even when a new goal is set, which IMO it shouldn't.

To reproduce:
start navigation in stage:
$ roslaunch navigation_stage move_base_fake_localization_10cm.launch

set the param dynamically:
$ rosrun dynamic_reconfigure dynparam set /move_base_node planner_frequency 0.05

In rviz, set a nav goal, with mouse, robot should start moving towards goal.
Set another nav goal while robot is moving, and robot will stop moving,and global planning will be delayed by 0 to 20 secs.

I believe move_base should, upon receiving a new goal, immediately replan globally.

On hydro-devel

[FATAL] [1367287395.368348831]: ASSERTION FAILED
file = /home/turtlebot/cafe_solution/src/navigation/costmap_2d/src/voxel_costmap_2d.cpp
line = 102
cond = end_x > start_x && end_y > start_y
[move_base-29] process has died [pid 4576, exit code -5, cmd /home/turtlebot/cafe_solution/devel/lib/move_base/move_base cmd_vel:=navigation_velocity_smoother/raw_cmd_vel __name:=move_base __log:=/home/turtlebot/.ros/log/9bb59ce8-b139-11e2-892c-20689dee2463/move_base-29.log].

For instance, going through a 1 meter wide hallway with a 50 cm wide robot, the path should ideally go right down the center. As it is, the planned path will have the robot brush the near corner of the hall when entering and exiting, and potentially just slide right along the edge the whole way down the hall.

The incoming costmap has a sufficient inflation radius and cost function which falls off appropriately from obstacles, but inside NavFn::setCostmap() those cost values are rescaled per the needs of NavFn.

The problem is that the rescaling does not spread the input values nicely over the output range, it concentrates them at the max value. Therefore you get a wide plateau of high cost values around obstacles. In open environments with few obstacles, this is fine because it stays away from the plateau. In crowded environments, all the free map cells have equal costs on this plateau, so the planner just does strict shortest-path in this area.

There could easily be a script that reads a bag file and creates a map from the data within it, rather than following the steps here: http://www.ros.org/wiki/slam_gmapping/Tutorials/MappingFromLoggedData

If a low yaw acceleration limit is given, then TrajectoryPlannerROS::rotateToGoal() can generate a yaw velocity below the user-specified minimum for in-place rotation (trajectory_planner_ros.cpp:305):

//we also want to make sure to send a velocity that allows us to stop when we reach the goal given our acceleration limits
    double max_speed_to_stop = sqrt(2 * acc_lim_theta_ * fabs(ang_diff));

    v_theta_samp = sign(v_theta_samp) * std::min(max_speed_to_stop, fabs(v_theta_samp));

The planner should never violate the minimum in-place rotation velocity. The result might be overshoot of and oscillation about the desired angle. That's ok; it's up to the user to trade off three parameters: max yaw acceleration, min in-place rotation velocity, and yaw goal tolerance.

[Originally posted by ben cohen in kforge trac]

move_base likes getting its goals in the map frame(from /move_base_simple/goal) and that's very understandable. It won't plan to a goal in any frame on the robot and I don't think it will output some sort of roserr that can be viewed in rxconsole either.

I agree that your normal user would want to send a goal in the map frame but the only reason why I'm filing this ticket is because if a user is trying to set a "2DNav Goal" for their robot in rviz but the fixed frame is in a robot frame, then the user will be left wondering 'why isn't my robot moving?'. There won't be any negative feedback other than the robot isn't moving and if they have the proper visualizations displayed, then no path will be drawn.

I know that it would be very nice if rviz gave the user more feedback but I don't see why, the move_base simple action server can't just use TF to transform the goal into the map frame upon receiving it.

It's just a thought. I have a feeling this was brought up earlier but shot down for a reason that I'm not aware of.