ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org
ROS Index
  1. Home
  2. Repos
  3. vision_visp
 

vision_visp repository

Repository Summary

Checkout URI https://github.com/lagadic/vision_visp.git
VCS Type git
VCS Version rolling
Last Updated 2023-04-24
Dev Status MAINTAINED
CI status No Continuous Integration
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

Name Version
vision_visp 0.13.1
visp_auto_tracker 0.13.1
visp_bridge 0.13.1
visp_camera_calibration 0.13.1
visp_hand2eye_calibration 0.13.1
visp_tracker 0.13.1

README

ViSP stack for ROS

GPL-2

1. Introduction

ROS 2 vision_visp contains packages to interface ROS 2 with ViSP which is a library designed for visual-servoing and visual tracking applications. This repository contains:

  • visp_bridge: Bridge between ROS 2 image and geometry messages and ViSP image and 3D transformation representation.
  • visp_tracker: ViSP model-based tracker interfaced in ROS 2 and initialized from a client that requires user interaction.
  • visp_auto_tracker: ViSP model-based tracker interfaced in ROS 2 and initialized thanks to a marker (AprilTag, QRcode, flashcode). Recovers when tracking fails.
  • visp_camera_calibration: ViSP based tool to calibrate camera intrinsic parameters.
  • visp_handeye_calibration: ViSP based tool to estimated the robot end-effector to camera geometric transformation.

2. Install dependencies

2.1. Install ROS 2

Firstly, it assumes that the ROS 2 core has already been installed, please refer to ROS 2 installation to get started.

2.2. Install ViSP

Please refer to the official installation guide from ViSP installation tutorials.

3. Build vision_visp

Fetch the latest code and build

$ cd <YOUR_ROS2_WORKSPACE>/src
$ git clone https://github.com/lagadic/vision_visp.git -b rolling
$ cd ..
$ colcon build --symlink-install

If ViSP is not found, use VISP_DIR to point to $VISP_WS/visp-build folder like:

$ colcon build --symlink-install --cmake-args -DVISP_DIR=$VISP_WS/visp-build

4. Usage

  • To run visp_auto_tracker launch:
  $ ros2 launch visp_auto_tracker tutorial_launch.xml
  • To run visp_tracker launch:
  $ ros2 launch visp_tracker tutorial_launch.xml

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

Name Version
vision_visp 0.13.1
visp_auto_tracker 0.13.1
visp_bridge 0.13.1
visp_camera_calibration 0.13.1
visp_hand2eye_calibration 0.13.1
visp_tracker 0.13.1

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

Name Version
vision_visp 0.13.0
visp_auto_tracker 0.13.0
visp_bridge 0.13.0
visp_camera_calibration 0.13.0
visp_hand2eye_calibration 0.13.0
visp_tracker 0.13.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. 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

Name Version
vision_visp 0.10.0
visp_auto_tracker 0.10.0
visp_bridge 0.10.0
visp_camera_calibration 0.10.0
visp_hand2eye_calibration 0.10.0
visp_tracker 0.10.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. 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)

Packages

Name Version
vision_visp 0.9.1
visp_auto_tracker 0.9.1
visp_bridge 0.9.1
visp_camera_calibration 0.9.1
visp_hand2eye_calibration 0.9.1
visp_tracker 0.9.1

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

Name Version
vision_visp 0.10.0
visp_auto_tracker 0.10.0
visp_bridge 0.10.0
visp_camera_calibration 0.10.0
visp_hand2eye_calibration 0.10.0
visp_tracker 0.10.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. 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)

Packages

Name Version
vision_visp 0.7.3
visp_auto_tracker 0.7.3
visp_bridge 0.7.3
visp_camera_calibration 0.7.3
visp_hand2eye_calibration 0.7.3
visp_tracker 0.7.3

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

Name Version
vision_visp 0.11.0
visp_auto_tracker 0.11.0
visp_bridge 0.11.0
visp_camera_calibration 0.11.0
visp_hand2eye_calibration 0.11.0
visp_tracker 0.11.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. 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.