[ros-users] Base Local Planner function visualization

[Eitan Marder-Eppstein]

Eric,

First off, this is awesome! Its a great tool that I'd love to take back to
the navigation stack. To make it more useful for other local planners, it
might be nice to have the MapGridVisualizer take in something like a
boost::function or function ptr for computing the cost of a given cell. It
could call that function with x and y map coordinates and get back
goal_cost, path_cost, occ_cost, and total_cost. This would also mean that we
might get away with not making the MapGrid for the planners public. Instead,
each planner that wants to publish this information just implements this
function that the MapGridVisualizer can call. Another option would be to add
such a function to the BaseLocalPlanner interface instead, but requiring a
planner to implement it makes a lot of assumptions about the way it works
and I don't think it belongs there.

Let me know what you think, and thanks for passing this along, definitely
cool,

Eitan

On Mon, Dec 6, 2010 at 11:30 PM, Eric Perko <wisesage5001 at gmail.com> wrote:

> Hey all,
>
> So, last time I worked with tuning the cost scoring parameters of
> base_local_planner it was tricky due to no way to easily tell how each term
> in the cost function was influencing the scored trajectories. To address
> this problem, I've created a class that outputs a PointCloud2 on a topic
> called cost_cloud under the base_local_planner namespace that contains the
> cost information for each component of the cost function as well as the
> total cost for each point the MapGrid maintained by the TrajectoryPlanner
> class. You can find the code here:
> https://github.com/ericperko/ros_navigation . You can find some sample
> images from rviz at
> http://www.dropbox.com/gallery/1970299/1/BaseLocalPlannerVizSamples?h=885d40 ,
> files named by which cost value they are visualizing (hover over the
> thumbnails to see the filenames or click for the gallery view and it will be
> listed below the thumbnails at the top), to give you all an idea of what
> this code outputs (red is lowest cost).
>
> There are a few steps to actually being able to use this functionality:
>
>
>    1. Checkout the updated Nav Stack from
>    https://github.com/ericperko/ros_navigation or otherwise apply commit
>    https://github.com/ericperko/ros_navigation/commit/00ec9847100942767a80524b401fc8c26e652d02 to
>    your existing base_local_planner package & recompile it.
>    2. Update your base_local_planner_params.yaml file with two more
>    parameters:
>       1. "publish_cost_grid_pc" to true. Default is false so that people
>       who aren't interested in seeing the point cloud aren't wasting cycles making
>       & publishing it.
>       2. "global_frame_id" to whatever your local costmap's global frame
>       is. By default, this is "odom" to match the setup in the nav stack setup (
>       http://www.ros.org/wiki/navigation/Tutorials/RobotSetup ). This is
>       the frame id set for the output point cloud so will determine how it draws
>       in the map.
>    3. Now you should be able to verify that base_local_planner is
>    outputting a PointCloud using something like "rostopic hz
>    /move_base/TrajectoryPlannerROS/cost_cloud"
>    4. In order to visualize the PointCloud in a meaningful way, you will
>    have to apply the patch in
>    https://code.ros.org/trac/ros-pkg/ticket/4610 to RViz so that you can
>    treat arbitrary channels as intensity data. The visualization will be much
>    more readable if you also make sure to check the "Use full RGB spectrum" box
>    so that gradients are more apparent.
>    5. Have fun selecting different components of the cost function and
>    seeing what sort of affect they have on the potential field that
>    base_local_planner is sampling trajectories from! Note that we don't output
>    any points that have any cost component greater than max cost and would
>    therefore be illegal for the planner to try to execute.
>
> Feedback would be very welcome and I hope this comes in handy. I know it's
> already helped me out by letting me see that my obstacle cost field doesn't
> extend as far as I might like.
>
> Eitan, any feedback on changes that are required to make this more general
> for use in, for example, dwa_local_planner would be great. Also, the C++ API
> of TrajectoryPlanner would likely have to change slightly if we wanted to
> move the visualizer and it's use of ROS topics and parameters up to
> TrajectoryPlannerROS. Specifically, the MapGrid would either need to become
> public or we'd need to add a getter for it; currently it's private to the
> TrajectorPlanner, so that's where the MapGridVisualizer is instantiated.
> Either that or pass in a number of variables in the constructor/setter
> methods (especially the scaling values). Let me know what you think would be
> the best idea for improving it, as I was currently going for a minimally
> invasive patch to start with and would like to get a more finalized patch
> together before opening a ticket to add this to the nav_stack.
>
> - Eric
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101207/ffd2c8f6/attachment-0003.html>