Sachin, Thanks for the info. I did get a chance to checkout sbpl_lattice_planner and poke it a bit using the included launch files. I did see some really odd behavior out of it though, as more than once it generated some really suboptimal paths. I'm attaching a screenshot from nav_view of one example from the launch file that loads up the WG map. The robot started at the orientation marked by the red arrow and I gave it a goal orientation of the blue arrow. You can see the planned path in green. Definitely not anywhere close to the path I expected. Is this just due to needing to play with the suboptimality bound for the anytime planning algorithms? I would have expected suboptimal paths, but not quite as suboptimal as "the long way around" :) I'll see about getting it set up within my existing nav stack setup sometime this week and let you know what problems (if any) I run into. - Eric On Tue, Sep 7, 2010 at 3:26 AM, Sachin Chitta wrote: > 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 > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >