tuw-robotics / tuw_multi_robot

BSD 3-Clause "New" or "Revised" License
233 stars 113 forks source link

Multi Robot Lanes #2

Closed wzli closed 5 years ago

wzli commented 5 years ago

Hi, First I'd like to say thanks for open-sourcing your MRRP implementation and contributing to the ROS environment. I'm currently testing different options for warehouse robot path planning, and this projects seems very promising. We are working with real robots, so the proof of concept has to be practical. One caveat for my scenario is that the width of some of the paths through the test environment is relatively wide compared to the size of the bots, so the constraint that only one robot may pass through a "vertex" at a time doesn't always hold and should ideally be a function of the width of the path segment instead. Are there any suggestions on how to incorporate this into the system? I can potentially contribute towards this if it isn't too paramount.

maxbader commented 5 years ago

Hi

Actually it is allready implemented. If the graph is generated by a voronoi we compute the free space next to each segments. It is also used by the mrrp because the graph keeps that information and each vehicle must have a defined radius. But it is still work in progress. If you are interested I will be next week at the IROS and ROSCon. By the way we are using it already on real robots and we have a gazebo simulation.

Greetings Markus

Von meinem Samsung Gerät gesendet.

-------- Ursprüngliche Nachricht -------- Von: wzli notifications@github.com Datum: 28.09.18 11:54 (GMT+01:00) An: tuw-robotics/tuw_multi_robot tuw_multi_robot@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Betreff: [tuw-robotics/tuw_multi_robot] Multi Robot Lanes (#2)

Hi, First I'd like to say thanks for open-sourcing your MRRP implementation and contributing to the ROS environment. I'm currently testing different options for warehouse robot path planning, and this projects seems very promising. We are working with real robots, so the proof of concept has to be practical. One caveat for my scenario is that the width of some of the paths through the test environment is relatively wide compared to the size of the bots, so the constraint that only one robot may pass through a "vertex" at a time doesn't always hold and should ideally be a function of the width of the path segment instead. Are there any suggestions on how to incorporate this into the system? I can potentially contribute towards this if it isn't too paramount.

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/tuw-robotics/tuw_multi_robot/issues/2, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAre-OwBLhMRKrOqpxLXpeb2D9R7o1cQks5uffHPgaJpZM4W-M71.

wzli commented 5 years ago

Awesome. I'm not at ROSCon ATM but some of my colleagues are, though I imagine they are probably very busy with their own presentations. By any chance do you have links to the code where this is implemented? So I can go through the interfaces and how it's supposed to work etc.

I tested the voronoi graph generation on a gmapping SLAM map of our test environment, it works. Though moving forwards, I think it would make sense to manually CAD the overlaying search graph instead, since the environment is relatively static, there are places that we don't want the bots to go, and sometime's the auto-generated graph isn't so robust to noisy laser measurements manifesting in the gridmap. Something as simple as manually supplying the widths the segments file would suffice.

maxbader commented 5 years ago

Be aware that I published yesterday minor changes on the graph generation. The graph should be smoother have a look at the map_invlation parameter.