industrial_moveit repository

Repository Summary

Checkout URI https://github.com/ros-industrial/industrial_moveit.git
VCS Type git
VCS Version melodic-devel
Last Updated 2019-10-17
Dev Status DEVELOPED
CI status No Continuous Integration
Released UNRELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

README

Industrial MoveIt

Note:: the STOMP packages were recently removed from this repository. They are hosted over at ros-industrial/stomp_ros now.

ROS Distro Support

Indigo Jade Kinetic
Branch indigo-devel indigo-devel kinetic-devel
Status supported supported supported
Version version version version

Travis - Continuous Integration

Status: Build Status

License

License License

ROS Buildfarm

Indigo Source Indigo Debian Jade Source Jade Debian Kinetic Source Kinetic Debian
industrial_moveit not released not released not released not released not released not released

Build

  • Build the workspace:
    • Cd into the catkin workspace directory and type the following command:
catkin build

Unit Test

  • Run all of industrial_moveit unit tests:
    • Cd into the catkin workspace directory and type the following command:
catkin run_tests 

  • Run the stomp_core unit tests:
catkin run_tests stomp_core

Stomp Moveit Demo

  • Run the demo
    • Run the demo.launch file
  roslaunch industrial_moveit_test_moveit_config demo.launch

  • In the Rviz Motion Planning planel, select rail_start_pose from the dropdown menu under "Select Start State" and click Update
  • In Rviz, select rail_end_pose from the dropdown menu under "Select Goal State" and click Update
  • Click Plan in order to generate a motion plan.

Configure Stomp

  • Locate the the stomp planner configuration file
    • roscd into the industrial_moveit_test_moveit_config package and locate the "stomp_config.yaml" file under the config directory
  • Rerun demo.launch file and plan once again to see how the changes affect the planner's behavior.

Seeding Stomp

The STOMP planner works through optimization: it starts with a given trajectory, called the seed, and iteratively attempts to improve it. This seed is set: 1. By default, it is set to the joint interpolated path between the start and end joint configurations. 2. If you wish, you can set your own seed trajectory.

The StompPlanner class works off of the moveit_msgs/MotionPlanRequest message type which does not provide an interface for seeds. Until that is added, we bastardize the unused MotionPlanRequest::trajectory_constraints field to serve this purpose. Use the StompPlanner::encodeSeedTrajectory(const trajectory_msgs::JointTrajectory& seed) static function to do this:


StompPlanner planner = makeStompPlanner(); // However you initialize
planning_interface::MotionPlanRequest request;

// set your nominal goals, start conditions, etc...

trajectory_msgs::JointTrajectory seed_traj; // Look up your seed traj
request.trajectory_constraints = StompPlanner::encodeSeedTrajectory(seed_traj);

// Call the planning service or the planner itself
planner.setMotionPlanRequest(request)

MotionPlanResponse res;
planner.solve(res);

There is no current way to set this through the MoveGroupInterface class.

========================================================================

CONTRIBUTING

ROS-Industrial is a community project. We welcome contributions from any source, from those who are extremely active to casual users. The following sections outline the steps on how to contribute to ROS-Industrial. It assumes there is an existing repository to which one would like to contribute (item 1 in the figure above) and one is familiar with the Git "Fork and Branch" workflow, detailed here.

  1. Before any development is undertaken, a contributor would communicate a need and/or issue to the ROS-Industrial community. This can be done by submitting an issue on the appropriate GitHub repo, the issues repo, or by posting a message in the ROS-Industrial category on ROS Discourse. . Doing so may save you time if similar development is underway and ensure that whatever approach you take is acceptable to the community of reviewers once it is submitted.
  2. The second step (item 2) is to implement your change. If you are working on a code contribution, we highly recommend you utilize the ROS Qt-Creator Plug-in. Verify that your change successfully builds and passes all tests.
  3. Next, push your changes to a "feature" branch in your personal fork of the repo and issue a pull request (PR)(item 3). The PR allows maintainers to review the submitted code. Before the PR can be accepted, the maintainer and contributor must agree that the contribution is implemented appropriately. This process can take several back-and-forth steps (see example). Contributors should expect to spend as much time reviewing/changing the code as on the initial implementation. This time can be minimized by communicating with the ROS-Industrial community before any contribution is made.
  4. Issuing a Pull Request (PR) triggers the Travis Continuous Integrations (CI) step (item 4) which happens automatically in the background. The Travis CI performs several operations, and if any of the steps below fail, then the PR is marked accordingly for the maintainer.
    • Travis Workflow:
    • Installs a barebones ROS distribution on a fresh Ubuntu virtual machine.
    • Creates a catkin workspace and puts the repository in it.
    • Uses wstool to check out any from-source dependencies (i.e. other repositories).
    • Resolves package dependencies using rosdep (i.e. install packages using apt-get).
    • Compiles the catkin workspace.
    • Runs all available unit tests.
  5. If the PR passes Travis CI and one of the maintainers is satisfied with the changes, they post a +1 as a comment on the PR (item 5). The +1 signifies that the PR is ready to be merged. All PRs require at least one +1 and pass Travis CI before it can be merged.
  6. The next step (item 6) is for the PR to be merged into the main branch. This is done through the GitHub web interface by selecting the “Merge pull request” button. After the PR is merged, all status badges are updated automatically.
  7. Periodically, the maintainer will release the package (item 7), which then gets sent to the ROS Build Farm for Debian creation.
  8. The publishing of the released packages (item 8) is managed by OSRF and is not on a set schedule. This usually happens when all packages for a given distro are built successfully and stable. The current status for the distro kinetic can be found here . Navigating to other distros can be done by changing the distro name in the link.
  9. Once the package has been published, it is available to be installed by the developer (item 9).
  10. After the install of a new version, the developer may have questions, experience issues or it may not have the necessary functionality which should all be reported on the packages GitHub repository as an issue (item 10). If an issue is identified or there is missing functionality that the developer requires, the cycle starts back at (item 2).

For more details, please refer to the ROS-I wiki.


Repository Summary

Checkout URI https://github.com/ros-industrial/industrial_moveit.git
VCS Type git
VCS Version kinetic-devel
Last Updated 2019-02-14
Dev Status DEVELOPED
CI status No Continuous Integration
Released UNRELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

README

Industrial MoveIt

ROS Distro Support

Indigo Jade Kinetic
Branch indigo-devel indigo-devel kinetic-devel
Status supported supported supported
Version version version version

Travis - Continuous Integration

Status: Build Status

ROS Buildfarm

Indigo Source Indigo Debian Jade Source Jade Debian Kinetic Source Kinetic Debian
industrial_moveit not released not released not released not released not released not released

Build

  • Build the workspace:
    • Cd into the catkin workspace directory and type the following command:
catkin build

Unit Test

  • Run all of industrial_moveit unit tests:
    • Cd into the catkin workspace directory and type the following command:
catkin run_tests 

  • Run the stomp_core unit tests:
catkin run_tests stomp_core

Stomp Moveit Demo

  • Run the demo
    • Run the demo.launch file
  roslaunch stomp_test_kr210_moveit_config demo.launch

  • In the Rviz Motion Planning planel, select rail_start_pose from the dropdown menu under "Select Start State" and click Update
  • In Rviz, select rail_end_pose from the dropdown menu under "Select Goal State" and click Update
  • Click Plan in order to generate a motion plan.

Configure Stomp

  • Locate the the stomp planner configuration file
    • roscd into the stomp_test_kr210_moveit_config package and locate the "stomp_config.yaml" file under the config directory
  • Rerun demo.launch file and plan once again to see how the changes affect the planner's behavior.

Seeding Stomp

The STOMP planner works through optimization: it starts with a given trajectory, called the seed, and iteratively attempts to improve it. This seed is set: 1. By default, it is set to the joint interpolated path between the start and end joint configurations. 2. If you wish, you can set your own seed trajectory.

The StompPlanner class works off of the moveit_msgs/MotionPlanRequest message type which does not provide an interface for seeds. Until that is added, we bastardize the unused MotionPlanRequest::trajectory_constraints field to serve this purpose. Use the StompPlanner::encodeSeedTrajectory(const trajectory_msgs::JointTrajectory& seed) static function to do this:


StompPlanner planner = makeStompPlanner(); // However you initialize
planning_interface::MotionPlanRequest request;

// set your nominal goals, start conditions, etc...

trajectory_msgs::JointTrajectory seed_traj; // Look up your seed traj
request.trajectory_constraints = StompPlanner::encodeSeedTrajectory(seed_traj);

// Call the planning service or the planner itself
planner.setMotionPlanRequest(request)

MotionPlanResponse res;
planner.solve(res);

There is no current way to set this through the MoveGroupInterface class.

========================================================================

CONTRIBUTING

ROS-Industrial is a community project. We welcome contributions from any source, from those who are extremely active to casual users. The following sections outline the steps on how to contribute to ROS-Industrial. It assumes there is an existing repository to which one would like to contribute (item 1 in the figure above) and one is familiar with the Git "Fork and Branch" workflow, detailed here.

  1. Before any development is undertaken, a contributor would communicate a need and/or issue to the ROS-Industrial community. This can be done by submitting an issue on the appropriate GitHub repo, the issues repo, or by posting a message in the ROS-Industrial category on ROS Discourse. . Doing so may save you time if similar development is underway and ensure that whatever approach you take is acceptable to the community of reviewers once it is submitted.
  2. The second step (item 2) is to implement your change. If you are working on a code contribution, we highly recommend you utilize the ROS Qt-Creator Plug-in. Verify that your change successfully builds and passes all tests.
  3. Next, push your changes to a "feature" branch in your personal fork of the repo and issue a pull request (PR)(item 3). The PR allows maintainers to review the submitted code. Before the PR can be accepted, the maintainer and contributor must agree that the contribution is implemented appropriately. This process can take several back-and-forth steps (see example). Contributors should expect to spend as much time reviewing/changing the code as on the initial implementation. This time can be minimized by communicating with the ROS-Industrial community before any contribution is made.
  4. Issuing a Pull Request (PR) triggers the Travis Continuous Integrations (CI) step (item 4) which happens automatically in the background. The Travis CI performs several operations, and if any of the steps below fail, then the PR is marked accordingly for the maintainer.
    • Travis Workflow:
    • Installs a barebones ROS distribution on a fresh Ubuntu virtual machine.
    • Creates a catkin workspace and puts the repository in it.
    • Uses wstool to check out any from-source dependencies (i.e. other repositories).
    • Resolves package dependencies using rosdep (i.e. install packages using apt-get).
    • Compiles the catkin workspace.
    • Runs all available unit tests.
  5. If the PR passes Travis CI and one of the maintainers is satisfied with the changes, they post a +1 as a comment on the PR (item 5). The +1 signifies that the PR is ready to be merged. All PRs require at least one +1 and pass Travis CI before it can be merged.
  6. The next step (item 6) is for the PR to be merged into the main branch. This is done through the GitHub web interface by selecting the “Merge pull request” button. After the PR is merged, all status badges are updated automatically.
  7. Periodically, the maintainer will release the package (item 7), which then gets sent to the ROS Build Farm for Debian creation.
  8. The publishing of the released packages (item 8) is managed by OSRF and is not on a set schedule. This usually happens when all packages for a given distro are built successfully and stable. The current status for the distro kinetic can be found here . Navigating to other distros can be done by changing the distro name in the link.
  9. Once the package has been published, it is available to be installed by the developer (item 9).
  10. After the install of a new version, the developer may have questions, experience issues or it may not have the necessary functionality which should all be reported on the packages GitHub repository as an issue (item 10). If an issue is identified or there is missing functionality that the developer requires, the cycle starts back at (item 2).

For more details, please refer to the ROS-I wiki.


Repository Summary

Checkout URI https://github.com/ros-industrial/industrial_moveit.git
VCS Type git
VCS Version indigo
Last Updated 2017-03-24
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

README

Industrial MoveIt

Build

  • Build the workspace:
    • Cd into the catkin workspace directory and type the following command:
catkin_make --jobs=4

Unit Test

  • Run stomp_core Unit Test:
    • Cd into the catkin workspace directory and type the following command:
catkin_make run_tests_stomp_core_gtest

  • Inspect the Unit test
    • roscd into the stomp_core package and go locate the "stomp_3dof.cpp" file inside the test directory.

Stomp Moveit Demo

  • Run the demo
    • Run the demo.launch file
  roslaunch stomp_test_kr210_moveit_config demo.launch

  • In the Rviz Motion Planning planel, select rail_start_pose from the dropdwown menu under "Select Start State" and click Update
  • In Rviz, select rail_end_pose from the dropdwown menu under "Select Goal State" and click Update
  • Click Plan in order to generate a motion plan.

Configure Stomp

  • Locate the the stomp planner configuration file
    • roscd into the stomp_test_kr210_moveit_config package and locate the "stomp_config.yaml" file under the config directory
  • Rerun demo.launch file and plan once again to see how the changes affect the planner's behavior.

============================================================================================== ROS-Industrial move it meta-package. See the ROS wiki page for more information.

CONTRIBUTING

No CONTRIBUTING.md found.