[ros-users] Navigation Stack on tight places
Eitan Marder-Eppstein
eitan at willowgarage.com
Thu Nov 18 21:01:28 UTC 2010
Gonçalo,
Thanks for the package, I'll take a look at things.
To run a different local planner, you'll want to change the plugin that
move_base loads. The relevant parameters are documented here:
http://www.ros.org/wiki/move_base#Parameters
<http://www.ros.org/wiki/move_base#Parameters>You'll set base_local_planner
to be something like dwa_local_planner/DWAPlannerROS.
You'll also need to make sure the dwa_local_planner library is made before
running move_base as it'll be loaded at runtime.
Hope this helps,
Eitan
2010/11/18 Gonçalo Cabrita <goncabrita at gmail.com>
> Sorry Eitan!
>
> I should have sent everything compressed the first time! I compressed the
> pkg. To run it just put it on your ROS_PACKAGE_PATH, roscore, roscd
> roomba_stage and then open stage, launch move_base and open rviz (also
> sending a roomba_stage.vcg file):
>
> rosrun stage stageros roomba_lse_arena.world
> roslaunch roomba_stage move_base_lse_arena.launch
>
> Just send the robot to the top right corner and it will likely stall on the
> wall.
>
> Anyways I just downloaded navigation_experimental! So dwa_local_planner
> seems to be a lib, how should I use it to get the robot up and running with
> it? Just give me some quick pointers.
>
> Cheers,
>
> Gonçalo Cabrita
> ISR - University of Coimbra
> Portugal
>
> On Thu, Nov 18, 2010 at 7:02 PM, Eitan Marder-Eppstein <
> eitan at willowgarage.com> wrote:
>
>> Gonçalo,
>>
>> It looks like you missed a file called "arena_obstalces.pgm" in what you
>> sent which is needed by the roomba_ise_arena.world file. Is there any way
>> you can just tar up the package you use to bring things up? Ideally this
>> would include all the configuration files and launch files you're using to
>> bring up stage and the navigation stack and would save a bit of grief in me
>> recreating the same package on my end.
>>
>> Thanks a bunch,
>>
>> Eitan
>>
>> 2010/11/18 Gonçalo Cabrita <goncabrita at gmail.com>
>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/9d22d6da/attachment-0004.html>
More information about the ros-users
mailing list