ViSP stack for ROS

vision_visp provides ViSP algorithms as ROS components. ViSP is the Visual Servoing Platform and ROS a robotics middleware.

These packages are released under the GPL-2 license.

Components documentation is hosted on the ros.org wiki.

Support is provided through ROS Answers .

Which branch should I use?

Branches come in two flavors:

• development branch,
• release branch

Package for each ROS release is maintained on separate branches. I.e. melodic-devel is the Melodic Morenia development branch whereas melodic is the Melodic Morenia release branch.

master means the next ROS release.

If you are a user you should use a release branch as they contain stable and tested versions of the packages. If you are a developper you must provide new patches against master. You may also provide version-specific bug fix again older releases.

• Never implement new features in old branches (i.e. not master). These Pull Requests will not be accepted. If you provide a bug fix then you may ask for it to be backported. ABI/API breakage prevent patches from being backported.
• The only action allowed in release branches is merging the development branch in the current branch.

Warning: the Fuerte branches still rely on the legacy rosbuild build system. We recommend you to update to a newer ROS release. Only minimum maintained will be done for this release.

Additional development guidelines are provided in CONTRIBUTING.md.

Build Status

This stack supports the following ROS releases:

• Hydro
• Groovy
• Fuerte
• Indigo
• Jade
• Kinetic
• Lunar
• Melodic
• Noetic

The master branch holds the development that will be available in the next ROS release.

ROS Release	Development Branch	Release Branch
Master		N/A
Melodic
Lunar
Kinetic

How to contribute

We’d love to accept your patches and contributions to this project. There are a just a few small guidelines you need to follow.

Submitting a patch

1. It’s generally best to start by opening a new issue describing the bug or feature you’re intending to fix. Even if you think it’s relatively minor, it’s helpful to know what people are working on. Mention in the initial issue that you are planning to work on that bug or feature so that it can be assigned to you.

2. Follow the normal process of forking the project, and setup a new branch to work in. It’s important that each group of changes be done in separate branches in order to ensure that a pull request only includes the commits related to that bug or feature.

3. Carefully check your commits by compiling and running the test suite on your machine. You should not break the API, if you have to, detail why in your commit message.

4. Any significant changes should always be accompanied by one ore more tests.

5. Do your best to have well-formed commit messages for each change. This provides consistency throughout the project, and ensures that commit messages are able to be formatted properly by various git tools. Please specify which project is concerned by your commit using the following syntax: [visp_tracker] file.cc: fix memory leak (close #N)

6. Finally, push the commits to your fork and submit a pull request.