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 wrote: > On Tue, Dec 7, 2010 at 7:29 PM, Eitan Marder-Eppstein < > eitan@willowgarage.com> wrote: > >> Eric, >> >> On Tue, Dec 7, 2010 at 3:27 PM, Eric Perko wrote: >> >>> Eitan, >>> >>> On Tue, Dec 7, 2010 at 1:43 PM, Eitan Marder-Eppstein < >>> eitan@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 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@code.ros.org >>>>> https://code.ros.org/mailman/listinfo/ros-users >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> ros-users mailing list >>>> ros-users@code.ros.org >>>> https://code.ros.org/mailman/listinfo/ros-users >>>> >>>> >>> >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >>> >>> >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> >> > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >