Eric,<div><br></div><div>I'll reply in-line below:<br><br><div class="gmail_quote">On Mon, Sep 6, 2010 at 11:34 PM, Eric Perko <span dir="ltr"><<a href="mailto:wisesage5001@gmail.com">wisesage5001@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Eitan,<div><br></div><div>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. </div>
<div><br></div><div>
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).</div>
</blockquote><div><br></div><div>I'd expect to see some poor choices for in-place rotation from time to time due to the way that trajectories are simulated and scored. Specifically, since a fixed time is used for rolling out trajectories, there are cases that a velocity that goes the long way around will score better than one that goes the short way around if they are both applied for something like 1 second. This hasn't been a huge problem for us, though we do see it happen, but I can put some thought into possible solutions. The only one that's coming to me off the top of my head is to have a different time threshold for forward simulating in-place rotations, but there's probably a better way.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div> </div>
<div><br></div><div>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.</div>
</blockquote><div><br></div><div>The PR2 has similar, if not more restrictive, clearance requirements. I believe we get 5cm on each side going through certain doorways. A 5cm map is definitely not high enough resolution to operate in these environments, so we use a 2.5cm map. In practice, that seems to work well. We do have the advantage that our base can strafe when moving through these tight spaces, so its possible that we just don't encounter the same kind of sticky situations that your robot gets into.</div>
<div><br></div><div>As far as costs go, I haven't had to change parameters when moving between resolutions, but you do have a point about the costs for path_distance and goal_distance being in map cells. The costmap actually moved away from representing costs based on cell distance and instead uses Euclidean distance for propagation, but the base_local_planner never made the switch. I think this was an oversight, and I've created a ticket to explore moving to meters from cells for the base_local_planner: <a href="https://code.ros.org/trac/ros-pkg/ticket/4410">https://code.ros.org/trac/ros-pkg/ticket/4410</a>.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div>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.</div>
</blockquote><div><br></div><div>That's great. The more planning approaches out there, the better as far as I'm concerned. Its unlikely that one kind of local planner will work for everything, and it would be nice for people to have some options out there. We've also played around with different approaches internally, especially when doing things like pushing a cart around the office. One local planner that might be of interest to you is the pose_follower. It lives in the navigation_experimental stack and is designed to follow a global path as closely as possible and to stop when the path is blocked by an obstacle. Obviously, its experimental code, and we've only tested it on a holonomic robot, but it might work out if you do get a different global planner up and running.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div>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 :)</div>
</blockquote><div><br></div><div>One thing that isn't always so clear about navfn, though it is documented on the wiki page for the planner, is that navfn assumes a circular robot. This means that as your robot gets more and more non-circular, navfn's plans will be progressively worse. This causes all sorts of problems and we'd like to move to something that considers the full footprint in the future. To this end, and as Sachin mentioned, you may want to check out the sbpl_lattice_planner package and see if that works out for you.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div>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.</div></blockquote><div><br>
</div><div>Thanks for the feedback, its always appreciated and will help to improve the navigation stack in the long term. Do let me know when you have some simulation stuff set up, as that will be really useful for testing.</div>
<div><br></div><div>Hope all is well,</div><div><br></div><div>Eitan</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br></div><font color="#888888"><div>
- Eric</div></font><div><div></div><div class="h5">
<div>
<br><div class="gmail_quote">On Tue, Sep 7, 2010 at 1:15 AM, Eitan Marder-Eppstein <span dir="ltr"><<a href="mailto:eitan@willowgarage.com" target="_blank">eitan@willowgarage.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Christian,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>I'm sorry that it hasn't been a pleasant experience so far, but hopefully we'll figure out what's going on. </div><div><br></div><div>Are other diff-drive folks experiencing these kinds of problems with their setups?</div>
<div><br></div><div>Hope all is well,</div><div><br></div><div><font color="#888888">Eitan</font><div><div></div><div><br><br><div class="gmail_quote">On Mon, Sep 6, 2010 at 10:27 AM, Brian Gerkey <span dir="ltr"><<a href="mailto:gerkey@willowgarage.com" target="_blank">gerkey@willowgarage.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Sat, Sep 4, 2010 at 12:12 AM, Christian Verbeek<br>
<<a href="mailto:verbeek@servicerobotics.eu" target="_blank">verbeek@servicerobotics.eu</a>> wrote:<br>
> I am using move_base for driving a robot with non holonomic drive. I<br>
> found the performance to be poor to wholly unacceptable. I played around<br>
> with the parameters for quite a time and was not able to find a<br>
> satisfactory setting. The problem with the parameters is that I most of<br>
> the time I can not see a difference at all when changing something.<br>
><br>
> My impression is that the navigation stack works in tidy and roomy<br>
> environments. But in real world settings with narrow passages and stuff<br>
> standing around performance drops dramatically. I tried this both woth<br>
> boxturtle and latest cturtle and can not see any improvements. The<br>
> navigation (which is in my eyes the most basic behaviour) is so to say<br>
> still unsolved for real world environments.<br>
<br>
</div>hi Christian,<br>
<br>
Hmm, that's a less than glowing assessment of the navigation stack.<br>
I'd be interested to find out exactly what's going wrong. We use the<br>
navigation stack all the time on the PR2 in our office, which is<br>
neither tidy nor roomy. It frequently avoids many small obstacles,<br>
and squeezes through tight openings. Of course, the PR2 is an<br>
omni-drive robot, and we test less often on differential-drive robots.<br>
But the navigation stack is intended to support differential-drive<br>
robots, and there's no reason that it shouldn't work well in that<br>
situation.<br>
<br>
Can someone who's had more success with the navigation stack on<br>
differential-drive robots suggest a good set of parameters?<br>
<font color="#888888"><br>
brian.<br>
</font><div><div></div><div>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>