[ros-users] Base Local Planner function visualization
Eitan Marder-Eppstein
eitan at willowgarage.com
Mon Dec 13 22:26:50 UTC 2010
Eric,
Thanks for the ticket and the work. I'm a little busy at the moment, but
I'll try to take a look at it sometime in the next week or so with the
intention of getting this into DTurtle.
I'll post to the ticket when I start working on this.
Hope all is well and thanks again... this is super cool,
Eitan
On Sat, Dec 11, 2010 at 10:37 PM, Eric Perko <wisesage5001 at gmail.com> wrote:
> On Tue, Dec 7, 2010 at 7:29 PM, Eitan Marder-Eppstein <
> eitan at willowgarage.com> wrote:
>
>> Eric,
>>
>> On Tue, Dec 7, 2010 at 3:27 PM, Eric Perko <wisesage5001 at gmail.com>wrote:
>>
>>> Eitan,
>>>
>>> On Tue, Dec 7, 2010 at 1:43 PM, Eitan Marder-Eppstein <
>>> eitan at willowgarage.com> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> I like the idea of just providing a way for a local planner to basically
>>> register an arbitrary cost function with the visualizer. Heck, it would even
>>> be a quick and easy way to prototype new cost functions and see what sort of
>>> effects they have on the potential field. I'll play around with this tonight
>>> or tomorrow and see how it goes. Thanks for the idea.
>>>
>>
>> Sounds good. Let me know when you've got something and I'll take a look at
>> it.
>>
>
> Took longer than I expected to get a chance to work on it, but I did
> finally get a chance to change to using a boost::function and moving the
> visualizer to TrajectoryPlannerROS. Changes are again available in my github
> repository mentioned above.
>
> I've also created a ticket to track getting this committed to the nav stack
> (https://code.ros.org/trac/ros-pkg/ticket/4620) so that any further
> discussion about the particulars can be discussed there.
>
> - Eric
>
>
>>
>> Hope all is well,
>>
>> Eitan
>>
>>
>>
>>>
>>>
>>>> Let me know what you think, and thanks for passing this along,
>>>> definitely cool,
>>>>
>>>
>>> Glad you also think it will be useful :)
>>>
>>> - Eric
>>>
>>>
>>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> 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/20101213/bcf66ee2/attachment-0003.html>
More information about the ros-users
mailing list