Re: [ros-users] Navigation Stack on tight places

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
Delete this message
Reply to this message
Author: User discussions
Date:  
To: User discussions
Subject: Re: [ros-users] Navigation Stack on tight places
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 <
> <mailto:goncabrita@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
>     <
>     <mailto:s34.martin@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 <http://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:* 
>         <mailto:ros-users-bounces@code.ros.org>
>         [
>         <mailto:ros-users-bounces@code.ros.org>] on behalf of Gonçalo
>         Cabrita [ <mailto:goncabrita@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
>         <
>         <mailto:s34.martin@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:* 
>             <mailto:ros-users-bounces@code.ros.org>
>             [
>             <mailto:ros-users-bounces@code.ros.org>] on behalf of
>             Gonçalo Cabrita [
>             <mailto:goncabrita@gmail.com>]
>             *Sent:* Thursday, 18 November 2010 11:51 PM
>             *To:*  <mailto:ros-users@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
>              <mailto:ros-users@code.ros.org>
>             https://code.ros.org/mailman/listinfo/ros-users

>
>
>
>         _______________________________________________
>         ros-users mailing list
>          <mailto:ros-users@code.ros.org>
>         https://code.ros.org/mailman/listinfo/ros-users

>
>
>
>     _______________________________________________
>     ros-users mailing list
>      <mailto:ros-users@code.ros.org>
>     https://code.ros.org/mailman/listinfo/ros-users

>
>
>
> _______________________________________________
> ros-users mailing list
>
> https://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: 


Geschäftsführer: Dr. Christian Verbeek
Registergericht: AG München (HRB 154463)
____________________________________________