industrial_calibration

:warning: EXPERIMENTAL KINETIC-DEVEL branch :warning:

Contains libraries/algorithms for calibration industrial systems.

extrinsic_cal calibration nodes: service_node – peforms quiet a number of calbirations using very complex yaml files range_excal – performs extrinsic calibration of a 3D camera by finding the target points in the image and the xyz values from the depth image. wrist_cal_srv – performs extrinsic calibration when either the target or the camera is mounted on the end of arm tooling stereo_cal_srv – performs stereo extrinsic cal using a robot (target or pair mounted on end of arm tooling)

extrinsic_cal helper nodes: camera_observer_scene_trigger – provides a trigger for a scene when the camera can locate a target manual_calt_adjust – Allows using the keyboard to adjust a mutable transform. typing x or X increases or decreases translation in x etc mutable_joint_state_publisher – Publishes the joint states for all joints defined in the input yaml file, allows update and save. ros_robot_trigger_action_service – Service which triggers a scene by moving a robot (using Moveit!) to a new pose trigger_serice – A very simple example of a scene trigger. Set a parameter to trigger a scene target_display_node – publishes a marker array that looks like a modified circle grid target (no stl required)

intrinsic_cal calibration nodes: ical_srv – intrinsic calibration using basic services rail_cal – dedicated rail calibration robocyl_ical – intrinsic calibraton on the robocylinder robocyl_vcal – verifies the intrinsic calibration results using robocylinder robocyl_scal – uses robocylinder to perform stereo calibration robocyl_ical_8d – an improved version of ical_srv and robocyl_ical included determination of axis of motion for rail. Target on rail only!! robot_ical – intrinsic calibration on a robot. This is very useful if you don’t want to take the camera off the robot, but not as accurate.

caljob_creator nodes: caljob_creator – writes a yaml file using the current joint values to create a scene ( only use if you are trying to use extrinsic_cal/service_node joint_traj_node – A node that maintains a list of robot poses that works in conjuction with the basic calibration service interface to orchestrate calibrations

rgbd_depth_correction nodes: depth_calibration – calibrates a 3D camera using a rail (usually a manual rail because it has to be fairly long) depth_correctonNodelet – a nodelet that subscribes to a cloud and corrects the depth using the calibration found by the depth_calibration node

stand_alone_gui nodes: ical_gui – as stand alone gui that makes using the basic calibration service easy

target_finder nodes: target_locator_srv – finds the target in a camera image and computes the target to camera transform stereo_locator_srv – finds the target in a stereo pair and computes the target to left camera transform target_gen – generates a target yaml file (NO LONGER NEEDED) call_service – continuously calls the target locator service and publishes the transform results dual_call_service – continuously calls the target locator service for two different cameras and publishes the transform results for each stereo_pose_stats – calls the stereo_locator_srv 30 times and computes statistics on the results

calibration_guis: what is it? This package creates two plugin panels for rviz. The first is an interface to the joint_traj node in caljob creator. The second is an interface to the standard calibration call service.

The best place to start in using this set of packages is with one of the basic call service calibration routines. Each of these routines advertises the following services:

1. Start – resets all data
2. Obs – collects an observation
3. Run – runs the optimization
4. Save – save the results, For intrinsic calibration it pushes to camera_info_manager. For extrinsic, it pushes to the mutable joint state publisher.
5. Import – imports the data saved from a previous calibration.
6. Cov – computes and prints the covariance matrix

The following are basic service call calibration nodes: wrist_cal_srv – performs extrinsic calibration when either the target or the camera is mounted on the end of arm tooling stereo_cal_srv – performs stereo extrinsic cal using a robot (target or pair mounted on end of arm tooling) ical_srv – intrinsic calibration using basic services (depricated) robocyl_ical_8d – an improved version of ical_srv and robocyl_ical included determination of axis of motion for rail. Target on rail only!! robot_ical – intrinsic calibration on a robot. This is very useful if you don’t want to take the camera off the robot, but not as accurate.

ROS Distro Support

Travis - Continuous Integration

Status:

ROS Buildfarm

	Indigo Source	Indigo Debian	Jade Source	Jade Debian	Kinetic Source	Kinetic Debian
industrial_calibration

Contains libraries/algorithms for calibration industrial systems

Requires

Ceres Optimizer

• With apt: sudo apt install libceres-dev
• With rosdep: rosdep install industrial_extrinsic_cal or rosdep install --from-paths industrial_calibration/

Openni2

sudo apt-get install ros-kinetic-openni2-camera
sudo apt-get install ros-kinetic-openni2-launch

Moveit

sudo apt-get install ros-kinetic-moveit

Install other source dependencies

This requires using wstool and the .rosinstall file. From the workspace top level directory run the following

wstool init src src/industrial_calibration/.rosinstall
wstool update -t src

Examples

Single Basler on a rail

roslaunch robocyl_ical.launch
roslaunch robo_cylinder.launch
rosservice call /RobocylCalService "allowable_cost_per_observation: 0.25"

Build

mkdir -p cal_ws/src
cd cal_ws/src
git clone -b kinetic-devel https://github.com/ros-industrial/industrial_calibration.git
cd ..
catkin build

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.