![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
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
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged pipeline_planner at Robotics Stack Exchange
![]() |
pipeline_planner package from pipeline_planner repopipeline_planner |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 1.6.4 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/SeaosRobotics/pipeline_planner_open.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2019-07-04 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- t-ogata
Authors
- seaos
pipeline_planner ROS Package
summary
pipeline_planner is a kind of global planner. It is designed to be used for a robot, especially nonholonomic robot, in a warehouse. We assume a robot to follow a fixed route which is determined in advance for the warehouse. We construct the fixed route by a series of checkpoints. Connected checkpoints and radii of pipeline segments make “pipeline”. pipeline_planner makes a global path in the pipeline. For making the path, the planner veils the area out of the pipeline and call the global planner NavFn on the edited global map. So we need NavFn planner for dependency. We explain them in detail in the next section.
This planner is described for kinetic version of ROS now.
function
We can construct a pipeline by a series of checkpoints, an open close flag and radii for pipeline segments. We cast these information by the service server “receive_checkpoints”. Each pipeline segment is constructed by connecting sequential checkpoints together with the pipeline segment radius for it. We can set the pipeline radii for pipeline segments as a positive value from 0.001 to 50 metre. If we set values for some pipeline segments as 0.0, the radii uses a default value. The default value is indicated by the dynamic parameter “pipe_radius”. If we change the value “pipe_radius”, then radii for default set pipeline segments will change. When we want to change a radius of a pipline segment, we can do it by calling the “set_a_radius” service. A pipeline has a direction and a robot can’t go backwards in the pipeline. A series of checkpoints is an ordered points in a global map. It must be in the global map. It mustn’t have a crossing after these checkpoints are connected to be a route. A pipeline might be an open route or a close route. Probably we use an open route as a one time only route because a robot can’t go backwards in the route.
When we cast checkpoints with an open close flag, there might be an error. So the planner has the status for reading checkpoints. The status for reading checkpoints is immediately published on the topic “read_checkpoints” when the planner receives the checkpoints. And we can inquire the state at any time by the service “get_read_status”. We can use the planner when the value of the state is 3 or 5. The list of the status will be described later.
After the planner receives proper checkpoints and open close flag, a robot is ready to move. When the planner receives a global planning order from move_base, it is, move_base calls makePlan function of the global planner, the planner veils the costmap with “lethal_cost” other than that in the pipeline and it makes a global path by calling the NavFn planner. We can set “lethal_cost” by the parameter of the same name. It is not expected for a robot to move in one pipeline segment, it is, a region between two neighbouring checkpoints. We can avoid the situation by making enough checkpoints. We can adjust the parameter “centre_weight” so as a robot to go in the middle of a pipeline. If we want a robot to go in a little right hand side or in a little left hand side from the middle of a pipeline segment, then we can set it by the poses.orientation.y variables of a request in receive_checkpoints service. We can change the right shift or left shift parameter by the service “set_a_rightshift”. A robot might stop by an error. We can gain the state of the robot by calling the service “get_robot_status”. 2 or 3 is the welcome value. The list of the robot status will be described later.
When makePlan is called start of calculation is informed by the topic “inform_status” with the value 12. If the calculation completed normally, the end of calculation is informed by the same topic with the value 3. In a case of an error, the termination of the calculation is informed by the same topic with the robot status value (again, it will be described later).
When makePlan calculation takes too much time, we can use torch model. With the torch model, we can restrict the manipulation region, id est, the region in which we veil a cost or add a cost. We can change the torch area by dynamic parameters, “torch_area_x” and “torch_area_y”.
Two main functions are PipelinePlanner::initialize and PipelinePlanner::makePlan. ‘initialize’ is called when move_base is launched or pipeline_planner is set to move_base’s global planner dynamically. ‘makePlan’ is called when global planner is called from move_base. This system uses nav_core as a interface with move_base. These are common for any global planner.
pipeline_planner can use CUDA for GPU calculation. If we use CUDA, we need CUDA for dependency. How to use CUDA is described in the Usage chaper.
specification
The list for the status of reading checkpoints. (unsigned int)
- not yet read
- reading now
- OK
- read but empty
- route overlaps obstacle (permitted)
- a part of the pipeline is out of costmap
- openclose flag error
- received pipeline has a crossing
- the radius of a pipe segment is not valid
- some sequential checkpoints are too close
others. unknown error
If a status is one other than 3 or 5, it is error status.
The list for the status of robot after makePlan was called. (unsigned int)
- global planner is not yet initialised
- the robot is ready to receive makePlan
- global plan was made normally
- the start is out of pipeline
- all pipeline segments include start point
- the goal is out of pipeline
- all pipeline segments include goal point
- goal is behind start (in the case of open pipeline only)
File truncated at 100 lines see the full file
Changelog for package global_planner
0.1.3.4 (1.6.4) (2019-07-04) -------------------* Bugfix for checkpoints crossing validity.
0.1.3.3 (1.6.3) (2019-06-24) -------------------* Deletion of fix_pipe_radius parameter. * Addition of set_a_radius service. * Addition of set_a_rightshift service.
0.1.3.2 (1.6.2) (2019-06-17) -------------------* Addition of pipeline visualisation function for rviz. * Addition of a code for a robot to run in the right hand side from the pipeline segment centre.
0.1.3.1 (1.6.1) (2019-05-29) -------------------* Addition of latch flag on initialised publication.
0.1.3.0 (1.6.0) (2019-05-28) -------------------* Addition of initialisation notification as a topic * Addition of reception of checkpoints as a service
0.1.2.5 (1.5.5) (2019-05-10) -------------------* Change of output format for robot_position topic. * Addition of inquire_segments service.
0.1.2.4 (1.5.4) (2019-04-22) -------------------* Modification of main function for melodic version
0.1.2.3 (1.5.3) (2019-04-19) -------------------* Modification of torch model
0.1.2.2 (1.5.2) (2019-04-17) -------------------* Bug fix about back veil in order not to go back
0.1.2.1 (1.5.1) (2019-03-28) -------------------* Slight bug fix for checkpoints reception * Slight change of specification for robot_position publication * Addition of "get_numof_checkpoints" service
0.1.2.0 (1.5.0) (2019-03-25) -------------------* Addition of informing robot position function
0.1.1.1 (1.4.1) (2019-03-25) -------------------* Bug fix for unexpected short cut
0.1.1.0 (1.4.0) (2019-03-19) -------------------* Addition of torch model * Making thread number dynamic * Addition of thread number checking issue: dynamic parameter for "num_threads" doesn't change * Making DistanceFromCentre function CUDA based
0.1.0.2 (1.3.3) (2019-03-13) -------------------* Slight change about costmap for fast calculation
0.1.0.1 (1.3.2) (2019-03-13) -------------------* Modification of consuming time and addition of time consuming publishing on topic. * Slight bug fix for SubscribeCheckpoints function.
0.1.0.0 (1.3.1) (2019-02-28) -------------------* Addition of charge param.
1.3.0 (2019-02-13)
- Addition of CUDA calculation function.
1.2.0 (2019-02-12)
- Addition of informing start and end of makePlan to tablet by a topic.
1.1.0 (2019-02-08)
- Addition of not fix radius mode.
- Addition of use straight line mode.
1.0.0 (2018-12-12)
- Change of README.md for public release.
0.1.4 (2018-07-26)
- * Addition of centre_weight parameter. A robot goes in the middle with the
-
parameter.
- Replacement from global_planner into navfn for base planner.
0.1.3 (2018-06-27)
- Addition of getCheckpoints as a service
0.1.2 (2018-06-13)
- getReadStatus and getRobotStatus as a service
- Change of the default value of pipe_radius
- Addition of the crossing check routine for pipeline
0.1.1 (2018-03-27)
- Addition of getStatus function as a service server
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
Deps | Name |
---|---|
costmap_2d | |
std_msgs | |
geometry_msgs | |
nav_core | |
nav_msgs | |
navfn | |
move_base_msgs | |
roscpp | |
tf | |
dynamic_reconfigure | |
message_generation | |
message_runtime | |
catkin |