Sachin, It is tricky to get through there, but the planner can do it. I moved it using the sbpl_lattice_planner from the default starting point through that narrow hallway to the red arrow pose, but have to do it with a halfway point in the the hallway or it just goes all the way around (most likely due to running out of time). Here's the console output for a run reproducing the problem: > [ INFO] [1283887074.606435759, 208.900000000]: [sbpl_lattice_planner] > getting fresh copy of costmap [ INFO] [1283887074.610865752, 208.900000000]: [sbpl_lattice_planner] robot > footprint cleared [ INFO] [1283887074.612990975, 208.900000000]: [sbpl_lattice_planner] > getting start point (28.1542,30.7675) goal point (17.6406,21.6356) env: setting start to 28.154 30.768 0.023 (1126 1230 0) planner: setting start to 83014 X=1126 Y=1230 Theta=0 env: setting goal to 17.641 21.636 1.591 (705 865 4) planner: setting goal to 2815354 the state is a goal state X=705 Y=865 Theta=4 planner: forceplanfromscratch set [ INFO] [1283887074.783733829, 209.100000000]: allocated:5.000000, init > eps:3.000000 > planner: search mode set to 0 [ INFO] [1283887074.783796810, 209.100000000]: [sbpl_lattice_planner] run > planner planner: replan called (bFirstSol=0, bOptSol=0) 2D search with sliding buckets and term_factor=0.500 # of expands during 2dgridsearch=810061 time=250 msecs 2Dsolcost_inmm=83105 > largestoptfval=164175 (start=1126 1230 goal=705 865) 2dsolcost_infullunits=207762 search exited with a solution for eps=3.000 eps=3.000000 expands=1913 g(searchgoal)=288955 time=0.010 search exited with a solution for eps=2.800 eps=2.800000 expands=41 g(searchgoal)=288316 time=0.000 search exited with a solution for eps=2.600 eps=2.600000 expands=13 g(searchgoal)=288316 time=0.000 search exited with a solution for eps=2.400 eps=2.400000 expands=16 g(searchgoal)=288316 time=0.000 search exited with a solution for eps=2.200 eps=2.200000 expands=98 g(searchgoal)=288310 time=0.000 search exited with a solution for eps=2.000 eps=2.000000 expands=157 g(searchgoal)=288298 time=0.000 search exited with a solution for eps=1.800 eps=1.800000 expands=42 g(searchgoal)=288030 time=0.000 search exited with a solution for eps=1.600 eps=1.600000 expands=8 g(searchgoal)=287652 time=0.000 search exited with a solution for eps=1.400 eps=1.400000 expands=279 g(searchgoal)=277977 time=0.000 search exited with a solution for eps=1.200 eps=1.200000 expands=28424 g(searchgoal)=220488 time=0.090 expands so far=100000 expands so far=200000 expands so far=300000 expands so far=400000 expands so far=500000 expands so far=600000 expands so far=700000 expands so far=800000 expands so far=900000 expands so far=1000000 expands so far=1100000 expands so far=1200000 search exited because it ran out of time eps=1.200000 expands=1205210 g(searchgoal)=220488 time=4.630 MaxMemoryCounter = 327575612 solution is found total expands this call = 1236201, planning time = 5.000 secs, solution > cost=218924 Solution is found [ INFO] [1283887079.275728992, 213.600000000]: size of solution=484 checks=1139182 [ INFO] [1283887079.276301971, 213.600000000]: Plan has 4347 points. Looks like it ran out of time to keep searching. I shoulda looked at the console output before :). I'll play around with the planning time parameter a bit once I get it up and running on my own bot, since I definitely need it to be able to go through narrow doorways. Thanks for taking a look at that. - Eric On Tue, Sep 7, 2010 at 3:13 PM, Sachin Chitta wrote: > At first glance: > > The little hallway that you would expect the robot to go through is > actually quite narrow. If you look in the static map, there are noisy > obstacles right in its entrance. Since the planner lays down a full > footprint it may not be finding a feasible path through that area, Its > also a function of the kind of motion primitives used. Can you send me > the text output that you see from the sbpl planner as well. > > BTW, I might be a little tardy in replying until we get over a > deadline middle of next week but after that I would like to push and > get this working. > > Regards, > Sachin > > > > On Tue, Sep 7, 2010 at 12:01 PM, Eric Perko > wrote: > > 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 < > gerkey@willowgarage.com> > >> >> 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 > > > > > > _______________________________________________ > > 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 >