[ros-users] Navigation Stack on tight places

Gonçalo Cabrita goncabrita at gmail.com
Thu Nov 18 18:14:11 UTC 2010


Hi Eitan!

Thanks for your reply.

I'm attaching the files needed to run the sim on Stage. It is the same setup
we have on the real arena right now, and the results on the real robot
are pretty similar to the simulation.

I'll most definitely take a look at the experimental nav stack. I'd like to
try the dwa_local_planner on the roomba to see what happens! I'll be posting
some feedback and most likely a bunch of questions!

Gonçalo Cabrita
ISR - University of Coimbra
Portugal

On Thu, Nov 18, 2010 at 5:54 PM, Eitan Marder-Eppstein <
eitan at willowgarage.com> wrote:

> Hey guys,
>
> So, to join in the discussion. From the video, it looks like the
> base_local_planner gets stuck in a local minimum with the parameters
> configured as they are. Is there any way that you can post the package used
> to create that video so that I can play around a little bit? I've wanted to
> have a case in simulation where a diff drive robot behaves badly and it
> seems like this is a simple one that could help me track down some issues
> the navigation stack has with diff drive robots. With that said, its true
> that no one local planner is going to fit all robots.
>
> We've started development of some other local planners in the
> navigation_experimental stack that might also be worth checking out. One is
> called dwa_local_planner and is a much cleaner version of the
> base_local_planner that includes things like scaling the robot's footprint
> based on speed, allowing for holonomic robots to explore more of the y
> velocity space, and exposing parameters via dynamic reconfigure to make
> tuning them a lot easier... we're testing it on the PR2 right now, not sure
> how it'll work on a diff-drive robot. There's also the pose_follower which
> attempts to follow a plan exactly, stopping in the presence of obstacles.
> This also hasn't been tested on diff-drive robots and I'd expect it could
> use a few tweaks to really work well, but it might be something to look at.
> One thing to keep in mind with all this, however, is that the packages in
> navigation_experimental are, well, experimental, so you're likely to run
> into some issues from time to time, there are no guarantees about API
> stability yet, and documentation isn't great.
>
> Hope all is well and please do post the simulation package as I'd love to
> take a look at things,
>
> Eitan
>
> 2010/11/18 Gonçalo Cabrita <goncabrita at gmail.com>
>
> We've been a bit busy porting everything that moves around here to ROS!
>> We'll update our repository in the next week with everything we've got!
>>
>> I'm attaching the param files we use for the roombas.
>>
>> I'm surprised the creates don't have decent odometry since they were
>> design for research. We have considered using cheap webcams with visual
>> odometry to replace the roomba's odometry, but I haven't had time to look
>> into it. If my memory serves me when we opened a roomba we found a hall
>> sensor with 4 magnets tied to the motor shaft. So I'm guessing direction is
>> determined by the motor speed. And that why when you push the roomba the
>> odometry doesn't count back!
>>
>> I'm really interested in solving this matter. If the problem really is
>> from the nav stack we're in big trouble since everything here is diff drive!
>> We have roombas, erratics and scouts!
>>
>> Gonçalo Cabrita
>> ISR - University of Coimbra
>> Portugal
>>
>>
>> On Thu, Nov 18, 2010 at 3:45 PM, Steven Martin <
>> s34.martin at connect.qut.edu.au> wrote:
>>
>>>  Yeh I think my problem is related to odometry, the iCreates don't have
>>> any encoders. I thought they did but after looking closer at the driver I am
>>> pretty sure its just openloop. Do you have the parameters for amcl in your
>>> repository? I had a look but couldn't see them anywhere.
>>>
>>> I have the code for the pursuit path follower checked in @
>>> launchpad.net/cmr but its very incomplete. It will compile, you can
>>> launch it and it will try and follow a path but it doesn't have any obstacle
>>> avoidance and I think I have one of my signs wrong in the code as it  didn't
>>> appear to do much following  from the very limited testing I have done.
>>>
>>> Have a look, its basically as stripped down as I could make a local path
>>> planner while still fitting in the ROS framework. Also due to the pretty
>>> well useless iCreate odometry I chose to implement this in the global frame
>>> and this may have some adverse affects if you are only running localiser @
>>> 3Hz.
>>>
>>> I will probably have time to look at this next week but I think this is a
>>> problem for anybody using nonholonomic robots with the Nav Stack so I would
>>> be surprised if someone else hasn't already got a better solution.
>>>
>>> Steve
>>>
>>>  ------------------------------
>>> *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:* Friday, 19 November 2010 12:52 AM
>>> *To:* User discussions
>>> *Subject:* Re: [ros-users] Navigation Stack on tight places
>>>
>>>  Hi Steven!
>>>
>>>  "ts 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.?"
>>>
>>>  You we also get that a lot! The robot never sticks to the path the
>>> planner outputs, it wonders around a lot.
>>>
>>>  We are using Roombas 560 with Eee PCs and Hokuyo lasers. We launch the
>>> Roomba the laser and the tf broadcaster on one file and map server, amcl and
>>> move base on another one. We have the map updaters running at 3Hz and the
>>> path planner at 5Hz. Still sometimes the EeePC skips a loop! Furthermore, I
>>> dunno how the Create is but our Roombas have nasty odometry! The encoders
>>> have only 1 channel with 4 pulses per motor turn!
>>>
>>>  Anyways, I'm not familiar with the nav stack code, but I would like to
>>> help if possible!
>>>
>>>  Gonçalo Cabrita
>>> ISR - University of Coimbra
>>> Portugal
>>>
>>> On Thu, Nov 18, 2010 at 2:35 PM, Steven Martin <
>>> s34.martin at connect.qut.edu.au> wrote:
>>>
>>>>  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?
>>>>
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101118/e0fe97f4/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lse_arena.pgm
Type: image/x-portable-graymap
Size: 4852 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101118/e0fe97f4/attachment-0005.pgm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lse_arena.yaml
Type: application/octet-stream
Size: 133 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101118/e0fe97f4/attachment-0010.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: roomba_lse_arena.world
Type: application/octet-stream
Size: 1970 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101118/e0fe97f4/attachment-0011.obj>


More information about the ros-users mailing list