![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged move_base_swp at Robotics Stack Exchange
![]() |
move_base_swp package from move_base_swp repomove_base_swp |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.16.7 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/ihadzic/move_base_swp.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2022-04-19 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Ilija Hadzic
Authors
- Eitan Marder-Eppstein
- contradict
gmail.com - Ilija Hadzic
Movebase with Sparse-Waypoint Goals
This package has been derived from the original move_base node from
ROS Navigation package. It implements
the move_base_swp
node, which extends the interface of the the original
move_base
node to include the sparse waypoints that the robot must
visit along its route to the goal.
‘move_base_swp’ is a drop-in replacement for move_base
,
designed to work with all existing plugins (e.g. DWA planner, navfn,
costmap2d) from the Navigation package. The interface is fully compatible
with move_base
and will accept single-pose goals and behave
just as regular move_base
with a couple of improvements listed below.
The new interface accepts the sparse-waypoint goals which specifies a
list of poses, with last pose being the final goal. If a single-waypoint
goal is provided the goal reduces to a final goal with no waypoints only
issued over the new interface. All other components will work, so
move_base_swp
is simply a better move_base
.
Feature Overview
In this section, we describe the improvements that move_base_swp
implements on the top of original move_base
node.
Sparse-waypoint goals
move_base_swp
implements a new actionlib
interface, which allows
the caller to define the goal in form of a list of waypoints. Unlike dense
waypoints generated by the global planner, this list is sparse. Typical size
of this list will include no more than 5-10 waypoints, sometimes just one.
The path between sparse waypoints is still within the responsibility
of the global planner. In other words, the input to move_base_swp
is a list of sparse waypoints that represent an the goal along with
a list of interim checkpoints that the robot must visit along its path.
The global planner produces a list of dense waypoints in the same
manner as in the original move_base
, which are fed to the local planner,
which, in turn, produces the velocity vector that creates the motion.
While it is theoretically possible to supply a dense set of waypoints
over the interface and effectively override the global planner, this is
not intended usage. Such usage will likely result in poor performance
because of frequent calls to the global planner. The intended usage is
for situations when the robot must get from point A to point B, but the
application requires that it visits point C along the way. Simply issuing
the goal at point B would result in finding the shortest path within the
constraints of the cost map which may or may not include point C. If the
point C is on a “detour” path it will not be visited. Using move_base_swp
allows the application to specify this additional constraint.
While it is possible to achieve the described behavior by first issuing the goal to point C and then as the robot approaches that goal issue the new goal to point B, this will likely result in unwanted slowdown or even complete stop at the interim waypoint. Further, an application would have to constantly monitor the progress of the first goal and issue the next goal “just in time” to ensure smooth transition. Often the “just in time” would imply using ill-defined heuristics that heavily depend on local and global planner tuning parameters.
move_base_swp
solves the problem by first calling the global planner
for each segment of the path (A-to-C segment, followed by C-to-B segment
in our example) and then concatenating the two plans into one global-planner
solution before feeding it to the local planner. The result is a smooth
motion at the concatenation point without the need for application
to intervene in any way. The application simply follows the progress
towards the specified goal which includes the specified sparse waypoints.
Windowed global plan
move_base_swp
provides an option to feed the horizon of the global
plan that is being fed into the local planner. Instead of feeding
an entire global plan, move_base_swp
has an option to feed only
a specified number of plan waypoints starting from the present location
and load additional plan waypoints as the robot progresses towards the goal.
This feature can improve motion behavior in general and can stand on its own regardless of whether sparse-waypoint plan is used or not. However, the problem that the windowed global plan solves is exacerbated by the usage of sparse waypoints.
An example of the problem that exists even in the original move_base
package is illustrated in this video:
https://youtu.be/7vnxZ25MzEk
The robot is moving from one side to the other of an X-shaped obstacle. Notice how at 0:57 it enters the state where it is not making progress. This happens because the entire area of interest is within the local planner window (we used DWA planner for this experiment). The local planner has the choice to either produce the velocity vector that takes it along the route prescribed by the global plan (the top path shown in green) or to deviate from the global plan and move the robot down the bottom path. From the local planner’s perspective, both paths have equal cost for the set of parameters it is using and the solver is bouncing back and forth between two options without making much progress.
While one motion may eventually prevail, the time it will take for this to happen, is not bounded. Changing the weight factors in the DWA planner to prefer sticking to the global plan more than advancing towards the target (i.e. cutting corners) would resolve this case, but there is always another case for which the same phenomena would happen. Triggering the
File truncated at 100 lines see the full file
Changelog for package move_base
1.16.7 (2020-08-27)
-
move_base: Add options for make_plan service (#981) Adds the following two parameters for the ~make_plan service:
1. make_plan_clear_costmap Whether or not to clear the global costmap on make_plan service call.
2. make_plan_add_unreachable_goal Whether or not to add the original goal to the path if it is unreachable in the make_plan service call.
-
Contributors: nxdefiant
1.16.6 (2020-03-18)
1.16.5 (2020-03-15)
1.16.4 (2020-03-04)
- [Windows][melodic] Navigation (except for map_server and amcl) Windows build bring up (#851)
- Contributors: Sean Yen
1.16.3 (2019-11-15)
- Merge branch 'melodic-devel' into layer_clear_area-melodic
- Added publishZeroVelocity() before starting planner (#751) Edit for Issue #750
- Merge pull request #831 from ros-planning/feature/remove_slashes [melodic] Remove leading slashes from default frame_id parameters
- Remove leading slashes from default frame_id parameters
- Contributors: David V. Lu, Michael Ferguson, SUNIL SULANIA, Steven Macenski
1.16.2 (2018-07-31)
1.16.1 (2018-07-28)
1.16.0 (2018-07-25)
- Switch to TF2 #755
- Merge pull request #723 from moriarty/melodic-buildfarm-errors Melodic buildfarm errors
- Merge pull request #719 from ros-planning/lunar_711 adding mutex locks to costmap clearing service
- Contributors: Alexander Moriarty, Michael Ferguson, Vincent Rabaud, stevemacenski
1.15.2 (2018-03-22)
- Merge pull request #673 from ros-planning/email_update_lunar update maintainer email (lunar)
- Merge pull request #649 from aaronhoy/lunar_add_ahoy Add myself as a maintainer.
- Rebase PRs from Indigo/Kinetic
(#637)
- Respect planner_frequency intended behavior (#622)
* Only do a getRobotPose when no start pose is given (#628) Omit the unnecessary call to getRobotPose when the start pose was already given, so that move_base can also generate a path in situations where getRobotPose would fail. This is actually to work around an issue of getRobotPose randomly failing.
- Contributors: Aaron Hoy, David V. Lu!!, Michael Ferguson
1.15.1 (2017-08-14)
1.15.0 (2017-08-07)
File truncated at 100 lines see the full file