Skip to content

Latest commit

 

History

History
116 lines (87 loc) · 5.02 KB

rep-I0002.rst

File metadata and controls

116 lines (87 loc) · 5.02 KB
::
REP: I0002 Title: Industrial Systems Calibration Methods/Routine Author: Christina Gomez Status: Draft Type: Standards Track Created: 14-January-2014

Outline

  1. Abstract
  2. Motivation
  3. Definitions
  4. Requirements
  5. Design Assumptions
  6. Specification
  7. Rationale
  8. Todo's
  9. Reference Implementation
  10. References
  11. Copyright

Abstract

This REP describes the draft version of the ROS-Industrial extrinsic calibration package. It is relevant to anyone using an industrial system in which the relative position(extrinsics) of multiple pieces of equipment must be determined. Common equipment examples include positioning systems(i.e. robots, cartesian gantries), measurement/sensor systems (i.e. camera(s), laser scanner/trackers, radio) and fixturing(accurately produced parts for referencing objects of interest). This package will provide an optimal solution for the pose (extrinsics) by including system properties and biases using the measurement of generalized targets.

Motivation

Every industrial system with a measurement component or multiple pieces of equipment requires their poses to be known/calibrated relative to a common coordinate frame(s). While there have been many approaches to solve this problem, most have been very specific to the calibration problem at hand (i.e. camera to robot, robot to fixture). A generalized approach that is publically available(open source) does not exist. Furthermore, the google ceres[https://code.google.com/p/ceres-solver/] tool provides a powerful library for generalized optimization and is an enabling technology for the industrial extrinsic calibration package.

Definitions

The following definitions are used throughout:
  • extrinsics - 6 pose parameters defining the position in space, specificially with rotation as a Rodriques’ axis-angle vector[ax, ay, az], and translation as vector [x, y, z]
  • intrinsics(camera) - 9 camera parameters defining the internal structure of the camera, specifically focal lengths (fx, fy), pixel centers (cx, cy) and 5 distortion parameters (k1, k2, k3, p1, p2)
  • parameter blocks - a structure used to interface with google ceres
  • target - The pattern (checkerboard/circle grid) with known point positions (checkerboard corners, circle grid circle centers, etc.)

Requirements

To control for each scenario there are several variables, such as the number of sensors, whether or not they are moving, the number and types of targets and whether or not they are moving, the number of targets within view, the number of sensors that can view a single target, and whether or not any of the positions of the targets are known. This package must take these variations in scenario into account to provide a generalized solution for various industrial systems

Example of such systems are as follows:
  • A camera setup to view a robot workspace requires the camera and the robot to share a common frame;
  • A system of cameras controls a process and are required to be continuously calibrated;
Scenerios where extrinsic calibration can be used
  • Camera to camera
  • Camera to Robot
  • Camera to reference system
  • Robot to reference system
  • Camera to fixture
  • Robot to fixture
Sensor Types
  • Cameras
  • Range finders
  • Laser trackers
  • Robot/Positioning system (Forward Kinematics)
  • TODO: Complete list

When appropriate (i.e. if it drastically improves calibration) a sensor model should be utilized as part of the optimization process. For example, including the camera projection and it's associated error model can greatly increase the accuracy of a calibration. Under such a model targets closer to the camera can be measure more accruatley than those that are further away. By including this "model" in the optimization, a better calibration results.

Target types
  • Fiducials(spheres, LEDs)
  • AR tags
  • Checkerboards
  • Circle patterns
  • TODO: Complete list

The desired package should be implemented in a ROS agnostic fashion, such that it could be generically used in any piece of software(i.e with minimal dependencies).

Design Assumptions

Specification

The calibration executables will take three input yaml files. These files define the sensors(s), target(s) and job parameters. The target.yaml file contains a list of static and/or moving targets. The static target is defined by a name, it's pose (angle axis format of rotation ax, ay, az, and translations x, y, and z), the number of measurable points, and a list of those points locations within that target. The moving target requires all the same information specified as the static target, but also a scene_id.

TODO: More details on camera and cal_job yaml input files to go here.

Rationale

Todo's

Reference Implementation

References

Copyright

This document has been placed in the public domain.