[ros-users] Navigation Stack on tight places

Thu Nov 18 18:55:02 UTC 2010

Christian,

I remember the issues you had with the local planner. I did try to get the
gazebo simulation you sent running but didn't have immediate success. I
think there was some boxturtle/cturtle issue that wasn't easily resolved,
and I wanted to make sure to run the CTurtle version of the navigation
stack. In the end, it sort of fell off my plate and I apologize for that. I
guess this is a chance for me to make amends.

Hope all is well,

Eitan

On Thu, Nov 18, 2010 at 10:20 AM, Christian Verbeek <
verbeek at servicerobotics.eu> wrote:

>  Eitan,
>
> I send you a complete package including gazebo simulation for our diff
> drive F5 platform some time ago. You remember? I had similar problems ending
> up for me kicking out the local planner completely.
>
> Regards
> Christian
>
> Am 18.11.2010 18:54, schrieb Eitan Marder-Eppstein:
>
> 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 listros-users at code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users
>
>
>
> --
> ___________________________________________
> REC GmbH
> Dr. Christian Verbeek
> Robert-Koch-Str. 2, 82152 Planegg
>
> Tel:    +49 89 85689672
> Fax:    +49 89 85902327
> Mobile: +49 160 7056589
> e-mail: verbeek at servicerobotics.eu
>
> Geschäftsführer: Dr. Christian Verbeek
> Registergericht: AG München (HRB 154463)
> ____________________________________________
>
>
>
> _______________________________________________
> 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/1bba7408/attachment-0003.html>