No version for distro humble showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro jazzy showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro kilted showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro rolling showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro ardent showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro bouncy showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro crystal showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro eloquent showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro dashing showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro galactic showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro foxy showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro iron showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro lunar showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro jade showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro indigo showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro hydro showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
melodic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange

No version for distro noetic showing kinetic. Known supported distros are highlighted in the buttons above.
Package symbol

pipeline_planner package from pipeline_planner repo

pipeline_planner

ROS Distro
kinetic

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

The pipeline_planner package

Additional Links

No 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)

  1. not yet read
  2. reading now
  3. OK
  4. read but empty
  5. route overlaps obstacle (permitted)
  6. a part of the pipeline is out of costmap
  7. openclose flag error
  8. received pipeline has a crossing
  9. the radius of a pipe segment is not valid
  10. 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)

  1. global planner is not yet initialised
  2. the robot is ready to receive makePlan
  3. global plan was made normally
  4. the start is out of pipeline
  5. all pipeline segments include start point
  6. the goal is out of pipeline
  7. all pipeline segments include goal point
  8. goal is behind start (in the case of open pipeline only)

File truncated at 100 lines see the full file

CHANGELOG

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

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Dependant Packages

No known dependants.

Recent questions tagged pipeline_planner at Robotics Stack Exchange