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@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@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
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.
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...
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