[ros-users] Navigation Stack on tight places

[Steven Martin]

Yep see that one all the time. I think the implementation of DWA is flawed for tank steer robots.

Its not a failure case but do you also see the one where it turns a little bit away from the path then does loop around to rejoin it.?

I started implementing just pure pursuit path follower to replace DWA but haven't quite got it working and been too busy with other stuff. I think we need to implement some other local planners or just path followers.

Also what are you using for the localization? I haven't been able to get AMCL to work reliably on the iCreates.
________________________________
From: ros-users-bounces at code.ros.org [ros-users-bounces at code.ros.org] on behalf of Gonçalo Cabrita [goncabrita at gmail.com]
Sent: Thursday, 18 November 2010 11:51 PM
To: ros-users at code.ros.org
Subject: [ros-users] Navigation Stack on tight places

Hi everyone!

We've been using the nav stack on our Roombas for quite a while now, mostly on the corridors of ISR without any problems.

However we have a small 4mx3m arena we built specifically for testing odor search algorithms in which we recently started to run some experiments. We quickly found out that the nav stack has some problems moving the robot around in tight places. Quite often we get the behavior that can be seen in the following video...

http://www.youtube.com/watch?v=vy9xoNvmktg

In the video we are running a Roomba inside our arena in Stage with perfect odometry. The robot stalls against a wall and stays there for 30mins until we stop it. On occasion the robot eventually gets out after a while.

At first I thought this could be happening because of the poor performance of the EeePCs the Roombas carry around or because of the Roomba's crappy odometry, but in Stage on a Core2Duo laptop we were able to see the same behavior.

Has anyone experienced this behavior before?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101118/ec552aef/attachment-0003.html>