Announcing Full Coverage Path Planner and Tracking PID packages

General
, ,
1

Dear ROS users,

We are happy to announce the release of two packages as result of the ROS-Industrial Focused Technical Project “Coverage Path Planning and Control”:

The Full Coverage Path Planner provides an implementation of the Backtracking Spiral Algorithm (BSA). The package provides a global planner plugin to the Move Base package .

The Tracking PID offers a tuneable PID control loop to accurately follow a trajectory for high and predictable performance.

If you are interested, tomorrow we will be presenting the packages at this ROSIN FTP Webinar.

7 Likes
2

Nice, I’m looking forward to try it on a real robot, also thanks for publishing.

However there are a few things I do not understand, e.g.

  • test_full_coverage_path_planner.launch: What is the meaning of these remaps?
    <remap from="move_base/cmd_vel" to="/move_base/cmd_vel"/>
    <remap from="odom" to="/odom"/>
    <remap from="scan" to="/scan"/>

  • Is it supposed to drive outside the map when tool_radius > robot_radius?

    image
    image902×861 20 KB

    I admit, after thinking about it, setting tool_radius > robot_radius is probably a bad idea…

Also to be honest I’ve hard time to understand what happens there when e.g. the controller publishes to /move_base/cmd_vel (Also the documentation for tracking_pid seems to say /cmd_vel).

Also I have some questions:

  • Is there a way to limit the area to cover inside the map? (x,y,width,height)
  • What is the reason the test is done with move_base_flex instead of move_base? Is it because it can run without a local planner to save resources?
  • Does it react to obstacles in the local_costmap which are not in the global_costmap?
3

  • The remaps are an artifact of when we used a simulator which enforced absolute topics, this was the workaround. We will remove them as they are no longer required I think.

  • Not sure that was within our scope since we considered the tool part of the robot and can thus not be smaller. Interesting that it leaves the map though… Any thoughts @cesar-lopez-mar?

  • Maybe this will be solved when we look into the remappings. We should simply use cmd_vel as per convention.

  • It should be compatible with move_base and move_base_flex. I think the reason we use mbf is because it separates MoveBase into GetPath and ExePath which is convenient.

  • No, it explicitly does not do so. This local plugin is about tracking performance of the global path. There are lots of local planners available which do avoid local obstacles. If that is a requirement you are probably better off with one of those.