[ros-users] navigation stack bare minimums

[Eitan Marder-Eppstein]

Mike,

On Tue, Jun 8, 2010 at 7:36 AM, Mike Purvis
<mpurvis at clearpathrobotics.com>wrote:

> If you're doing a lot of multi-robot navigation and you want the robot's to
>> be aware of each other's positions, you'll probably need a map frame. You
>> don't necessarily need to run a map_server, but you will need to have your
>> localization source, whether that be GPS, camera-based localization, or
>> other, publish a transform from the map frame to the odom (or if you don't
>> have odom, base_link) frame of your robot. In the case where you don't have
>> a map_server... you'd still set the "static_map" parameter on the
>> global_costmap to be false.
>
>
> This is very helpful, thanks.
>
>
> With the parameters that you posted, you should no longer receive this
>> error. Can you take a look at the parameters you have set with "rosparam
>> dump" to make sure that the parameters for the global_costmap are being set
>> correctly? They should fall under the move_base_node/global_costmap/
>> namespace.
>>
>
> Okay, yes, I've played with the namespaces, and I believe all of the pieces
> are now seeing the proper parameters. Thanks for the tip about rosparam
> dump.
>
> I have a few remaining questions about global_costmap and local_costmap. I
> have the navigation stack talking to my simulator, but when I send a goal, I
> get the following output:
>
> [ WARN] 1276006631.337854000: The goal sent to the navfn planner is off the
> global costmap. Planning will always fail to this goal.
> [ WARN] 1276006631.425825000: The goal sent to the navfn planner is off the
> global costmap. Planning will always fail to this goal.
> [ WARN] 1276006631.704455000: The robot's start position is off the global
> costmap. Planning will always fail, are you sure the robot has been properly
> localized?
> [ WARN] 1276006631.825804000: The goal sent to the navfn planner is off the
> global costmap. Planning will always fail to this goal.
> [ WARN] 1276006631.904408000: The robot's start position is off the global
> costmap. Planning will always fail, are you sure the robot has been properly
> localized?
> [ERROR] 1276006631.949307000: Aborting because a valid plan could not be
> found. Even after executing all recovery behaviors
>

You shouldn't be receiving the "robot's start position is off the global
costamp" error if you have the "rolling_window" parameter set to true. It
should automatically center the robot in a costmap that has an origin
appropriate for the robot's position. It may take an update cycle to do
this, but it should work. Can you try setting the publish_frequency
parameter to something non zero on your global_costmap and viewing it in
rviz? You should see the costmap with its associated obstacles and the robot
footprint in the center of it. You can find information on using rviz with
the navigation stack here:
http://www.ros.org/wiki/navigation/Tutorials/Using%20rviz%20with%20the%20Navigation%20Stack


>
> Now, I'm using raw UTM coordinates for my position, so the numbers are
> large. My odometry messages (and corresponding transforms) look like so:
>
> header:
>   seq: 4657
>   stamp: 1276006871180577039
>   frame_id: odom
> child_frame_id: base_link
> pose:
>   pose:
>     position:
>       x: 596506.594977
>       y: 4956355.18823
>       z: 0.0
>     orientation:
>       x: 0.0
>       y: 0.0
>       z: 0.922148700667
>       w: 0.386835590217
>   covariance: [0.0 ...
>
> And my goal, accordingly, was sent like so:
>
> rostopic pub /clearpath/robots/0/move_base_simple/goal
> geometry_msgs/PoseStamped '{ header: { frame_id: "odom" }, pose: { position:
> { x: 596505, y: 4956355 }, orientation: { x: 0, y: 0, z: 0.62, w: 0.78 } }
> }'
> publishing and latching message. Press ctrl-C to terminate
>
> Now, I've tried to center the global costmap over this region, like so:
>
> global_costmap:
>   global_frame: odom
>   robot_base_frame: base_link
>   update_frequency: 5.0
>   static_map: false
>   rolling_window: true
>   width: 100
>   height: 100
>   origin_x: 596500
>   origin_y: 4956350
>   map_type: costmap
>
> Is this a correct approach? Alternatively, I could put a local origin in my
> odometry and tf broadcasters. Would that be better? Or is there something
> else entirely?
>

Setting the origin for the costmap is a reasonable thing to do when
rolling_window is not set, but having the rolling_window parameter set to
true will actually override your original origin setting every update cycle
to center the robot in the costmap. I'm surprised that setting the origin
makes things work for you, but leaving it at (0, 0) causes things to break.
Looking at what is going on in rviz may clear things up, however.

Hope this helps,

Eitan


>
> Thanks again.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100608/fd548f07/attachment-0003.html>