vision_visp repository

Repository Summary

Checkout URI https://github.com/lagadic/vision_visp.git
VCS Type git
VCS Version noetic-devel
Last Updated 2022-11-18
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

README

ViSP stack for ROS

GPL-2

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 Build Status N/A
Melodic Build Status Build Status
Lunar Build Status Build Status
Kinetic Build Status Build Status

CONTRIBUTING

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.


Repository Summary

Checkout URI https://github.com/lagadic/vision_visp.git
VCS Type git
VCS Version lunar-devel
Last Updated 2019-07-03
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

README

ViSP stack for ROS

GPL-2

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. lunar-devel is the Lunar Loggerhead development branch whereas lunar is the Lunar Loggerhead 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

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

ROS Release Development Branch Release Branch
Master Build Status N/A
Lunar Build Status Build Status
Kinetic Build Status Build Status
Jade Build Status Build Status
Indigo Build Status Build Status
Hydro Build Status Build Status
Groovy Build Status Build Status
Fuerte Build Status Build Status

CONTRIBUTING

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.


Repository Summary

Checkout URI https://github.com/lagadic/vision_visp.git
VCS Type git
VCS Version jade-devel
Last Updated 2017-02-17
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

README

ViSP stack for ROS

GPL-2

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. jade-devel is the Jade development branch whereas jade is the Jade 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

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

ROS Release Development Branch Release Branch
Master Build Status N/A
Jade Build Status Build Status
Indigo Build Status Build Status
Hydro Build Status Build Status
Groovy Build Status Build Status
Fuerte Build Status Build Status

CONTRIBUTING

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.


Repository Summary

Checkout URI https://github.com/lagadic/vision_visp.git
VCS Type git
VCS Version indigo-devel
Last Updated 2019-07-03
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

README

ViSP stack for ROS

GPL-2

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. indigo-devel is the Indigo development branch whereas indigo is the Indigo 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

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

ROS Release Development Branch Release Branch
Master Build Status N/A
Indigo Build Status Build Status
Hydro Build Status Build Status
Groovy Build Status Build Status
Fuerte Build Status Build Status

CONTRIBUTING

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.


Repository Summary

Checkout URI https://github.com/lagadic/vision_visp.git
VCS Type git
VCS Version hydro-devel
Last Updated 2015-11-03
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

README

ViSP stack for ROS

GPL-2

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. hydro-devel is the Hydro development branch whereas hydro is the hydro 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

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

ROS Release Development Branch Development branch (ros.org) Release Branch Documentation (ros.org)
Master Build Status N/A N/A N/A
Indigo Build Status Build Status Build Status Build Status
Hydro Build Status Build Status Build Status Build Status
Groovy Build Status Build Status Build Status Build Status
Fuerte Build Status N/A Build Status N/A

CONTRIBUTING

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.


Repository Summary

Checkout URI https://github.com/lagadic/vision_visp.git
VCS Type git
VCS Version kinetic-devel
Last Updated 2019-10-30
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

README

ViSP stack for ROS

GPL-2

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

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

ROS Release Development Branch Release Branch
Master Build Status N/A
Melodic Build Status Build Status
Lunar Build Status Build Status
Kinetic Build Status Build Status
Indigo Build Status Build Status

CONTRIBUTING

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.


Repository Summary

Checkout URI https://github.com/lagadic/vision_visp.git
VCS Type git
VCS Version melodic-devel
Last Updated 2022-02-21
Dev Status MAINTAINED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

README

ViSP stack for ROS

GPL-2

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 Build Status N/A
Melodic Build Status Build Status
Lunar Build Status Build Status
Kinetic Build Status Build Status

CONTRIBUTING

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.