Eric, I will let Eitan reply to your other questions about the navigation stack. My response is in particular about the sbpl_global_planner. There is a new version of the ROS interface for the planner in the sbpl_lattice_planner package which will soon supersede the sbpl_global_planner package. The underlying sbpl library is maintained by one of our collaborators. On that note, I am curious to get any feedback you have on the performance of that planner with the aim of eventually fixing the bugs and releasing it. There are a few (undocumented) modifications that can be made to the planner to help it function better that need to be flushed out into tutorials/documentation before a release can be made. So, any feedback you can provide will be useful. Regards, Sachin On Mon, Sep 6, 2010 at 11:34 PM, Eric Perko wrote: > Eitan, > Here's a quick summary of my current experience with the navigation stack. > I'll see if I can clean up some simulation that reproduces the behavior > later this week. > First off, my current platform is about 3 feet long by 2 feet wide (power > wheelchair base) with diff-drive. I've seen behavior that may be similar to > Christian's. Namely, parameters that were fine in an outdoor environment > where there was a lot of clearance fail horribly indoors. Even after > changing parameters around, indoor environments are still tricky. When there > is at least a foot of clearance between the robot and any obstacle, > navigation seems to work okay (minus poor choices of direction to rotate in > when spinning in place once in a while). > When attempting to navigate in a much more constrained space, the local > planner can be pretty bad. For example, one of the tasks our platform needs > to be able to do is navigate through tight doorways where clearance may be > at most 6-7 centimeters on either side and we've found base_local_planner to > have pretty poor performance in this situation. For example, we've seen the > robot get partway through the doorway and then be unable to get out of the > doorway (and that is when it even manages to get into the doorway at all). > After experimenting with the trajectory checking code, we found that the > costmap resolution needed to be increased to ensure that there would always > be a clear grid cell between the robot and doorway; at the default 5 cm > resolution and only 7 cm of clearance, we were encountering overlap due to > the mapping between continuous position coordinates and discrete map cells. > I haven't gotten a chance to play with updated cost scoring parameters for > this new resolution - the defaults failed pretty badly, most likely because > the costs are in map_cells, not meters, so they need updated each time the > map resolution is changed. > To address these problems with the base_local_planner and precision paths, > we're currently experimenting with a number of trajectory planning and path > following algorithms to achieve precise navigation in constrained > environments. > I believe there are also a few problems I've seen due to the global planner > (navfn) not planning very well for a rectangular bot, especially a > diff-drive one. A good example is the following: when I manually drove the > robot along the global path to get a feel for it, another guy watched and > said that at one point, the backend of our robot had only 1-2 cm of > clearance, which is a bit scary - and prolly something that would make the > base_local_planner unhappy. I did try the sbpl_global_planner briefly in > simulation a few weeks back, but couldn't get it working very reliably - > guess there is a good reason that it's unreleased :) > Well that ended up a bit longer than I originally planned, but hopefully it > will lead to some insights that will improve the navigation stack's > performance for everyone. > - Eric > On Tue, Sep 7, 2010 at 1:15 AM, Eitan Marder-Eppstein > wrote: >> >> Christian, >> First off, its true that navigation is not fully "solved" for real world >> environments. We're trying to provide a system that improves the navigation >> capabilities of a large number of robots, but there's still a lot of work to >> be done. We do try to test the navigation stack as often as possible on our >> PR2, and have had mostly positive results, but that doesn't necessarily mean >> it will work well in all cases. As far as the problems you're having, I'd be >> curious to see the launch files that you're using to bring up the navigation >> stack on your robot. I've looked at those parameters a lot, and might be >> able to give some insight into what's going on. >> I'd also be curious to see if you experience the same problems with the >> navigation stack in simulation. If you can create launch files that show a >> simulated version of your robot having the problems you described, it would >> allow us to reproduce the behavior your seeing and give us a better shot at >> fixing things. We could even add these tough cases as tests for the >> navigation stack so that others with diff-drive robots don't have to >> experience the pain you've been through. If you want, you can check out the >> navigation_stage package for a template of how to run navigation in a >> simulated environment. >> I'm sorry that it hasn't been a pleasant experience so far, but hopefully >> we'll figure out what's going on. >> Are other diff-drive folks experiencing these kinds of problems with their >> setups? >> Hope all is well, >> Eitan >> >> On Mon, Sep 6, 2010 at 10:27 AM, Brian Gerkey >> wrote: >>> >>> On Sat, Sep 4, 2010 at 12:12 AM, Christian Verbeek >>> wrote: >>> >  I am using move_base for driving a robot with non holonomic drive. I >>> > found the performance to be poor to wholly unacceptable. I played >>> > around >>> > with the parameters for quite a time and was not able to find a >>> > satisfactory setting. The problem with the parameters is that I most of >>> > the time I can not see a difference at all when changing something. >>> > >>> > My impression is that the navigation stack works in tidy and roomy >>> > environments. But in real world settings with narrow passages and stuff >>> > standing around performance drops dramatically. I tried this both woth >>> > boxturtle and latest cturtle and can not see any improvements. The >>> > navigation (which is in my eyes the most basic behaviour) is so to say >>> > still unsolved for real world environments. >>> >>> hi Christian, >>> >>> Hmm, that's a less than glowing assessment of the navigation stack. >>> I'd be interested to find out exactly what's going wrong.  We use the >>> navigation stack all the time on the PR2 in our office, which is >>> neither tidy nor roomy.  It frequently avoids many small obstacles, >>> and squeezes through tight openings.  Of course, the PR2 is an >>> omni-drive robot, and we test less often on differential-drive robots. >>>  But the navigation stack is intended to support differential-drive >>> robots, and there's no reason that it shouldn't work well in that >>> situation. >>> >>> Can someone who's had more success with the navigation stack on >>> differential-drive robots suggest a good set of parameters? >>> >>>        brian. >>> _______________________________________________ >>> 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 > > -- Sachin Chitta Research Scientist Willow Garage