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@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 > >> 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@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@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 < >>> 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:* 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 listros-users@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@servicerobotics.eu > > Geschäftsführer: Dr. Christian Verbeek > Registergericht: AG München (HRB 154463) > ____________________________________________ > > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >