[ros-users] Avoiding Collisions between robots
Eitan Marder-Eppstein
eitan at willowgarage.com
Mon Dec 27 17:48:03 UTC 2010
David,
On Sat, Dec 25, 2010 at 7:53 PM, <davidbsp at iol.pt> wrote:
>
> Hello everyone,
>
> I have been making some experiments on ROS together with Stage, using
> multiple mobile robots in the same environment.
> All robots run the navigation stack. However, sometimes they collide
> with each other.
>
So, its true that the navigation stack doesn't do a great job of handling
the multi-robot case, but I'd expect you to get reasonable results in Stage
as long as the laser mounted on each robot is capable of seeing the body of
the other robot. Have you verified that each robot in stage sees the other
in its entirety?
A problem that we have when running in real life with multiple robots is
that the laser on one robot can't actually see the body of another, because
the lasers are mounted on top of the body and this allows the robots to
collide. One solution to this would be to have each robot publish a point
cloud of obstacle data to the navigation stack corresponding to its position
in the world. That way, both robots would be aware of each other in the
world.
>
> As far as I understood, the navigation stack assumes a static
> environment. I have tried to stop one robot when two robots are
> crossing each other (by sharing their positions in a common topic) and
> still the moving robot often drives into the stopped robot. I also get
> collisions by stopping both of them and resetting their goals.
The navigation stack doesn't assume a static environment. It takes in
information from the robot's sensors and uses that information to react to
dynamic obstacles in the environment. I'd suggest sharing information about
the robot's positions using the technique of publishing an observation I
mentioned above.
>
> Should I redefine the parameters of the local planner or this is not
> the way to go? I have tried both DWA and Trajectory Roll Out with
> different parameters and had no luck.
>
I don't think that this is a parameter issue. I think it probably has more
to do with the robots not seeing each other.
>
> I also have tried to set intermediate goals when robots are close, in
> order to keep them away from each other. However using the navigation
> stack in tight places with two robots, a "repelling force" effect on
> the robots seems to prevent them to achieve their intermediate goals.
>
> I had better luck by giving the robots velocity commands in opposite
> directions when they are close to each other, however this is a
> solution that i was not willing to use, since it bypasses the
> navigation stack and it highly depends on the free space around the
> robots.
>
Yeah, this doesn't sound like a great solution if you want to avoid
obstacles.
>
> I was wondering if there is any mechanism to prevent robots from
> colliding with each other. If not, can you give me hints on how to
> create such a mechanism?
>
As I alluded to above. First, verify that the robots can see each other
fully in their laser scans. If this isn't the case, you'll want to create a
"sensor" for each robot that publishes obstacle information corresponding to
the robot's current position. Then, configure the navigation stack on each
robot to use the information from the other robot when it builds its
costmap.
If the robots can see each other fully in their laser scans already, I'll
have to think a little more about what's going on.
Hope this helps,
Eitan
>
> Thank you in advance,
>
>
> David Portugal
>
> Mobile Robotics Laboratory
> Institute of Systems and Robotics
> University of Coimbra
>
>
> ________________________________________________________________________________
> Junte todos os seus créditos no Único da Capital Mais...
> ...reduza as suas despesas mensais.
> Saiba mais em http://www.iol.pt/correio/rodape.php?dst=0901051
> _______________________________________________
> 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/20101227/209bcdc4/attachment-0003.html>
More information about the ros-users
mailing list