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 > > > 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 > > 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@code.ros.org > > [ros-users-bounces@code.ros.org > ] on behalf of Gonçalo > Cabrita [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 > > 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@code.ros.org > > [ros-users-bounces@code.ros.org > ] on behalf of > Gonçalo Cabrita [goncabrita@gmail.com > ] > *Sent:* Thursday, 18 November 2010 11:51 PM > *To:* 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 > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > 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: verbeek@servicerobotics.eu Geschäftsführer: Dr. Christian Verbeek Registergericht: AG München (HRB 154463) ____________________________________________