ifm3d-ros is a wrapper around ifm3d enabling the usage of ifm pmd-based ToF cameras from within ROS software systems.
| ifm3d-ros version | ifm3d version | ROS distribution(s) |
|---|---|---|
| 0.1.0 | 0.1.0 | Kinetic |
| 0.2.0 | 0.2.0 | Kinetic, Indigo |
| 0.3.0 | 0.2.0 | Kinetic, Indigo |
| 0.4.0 | 0.2.0, 0.3.0, 0.3.1, 0.3.2 | Kinetic, Indigo |
| 0.4.1 | 0.3.3, 0.4.0, 0.5.0, 0.6.0, 0.7.0, 0.8.1 | Kinetic, Indigo |
| 0.4.2 | 0.9.0 | Kinetic |
| 0.5.0 | 0.9.0, 0.9.1 | Kinetic |
| 0.5.1 | 0.9.2 | Kinetic, Melodic |
| 0.6.0 | 0.9.2, 0.9.3, 0.10.0, 0.11.0, 0.11.2 | Kinetic, Melodic |
| 0.6.1 | 0.11.2, 0.12.0 | Kinetic, Melodic |
- Preparing your system: Kinetic, Melodic
- Installing the ROS node
The core ifm3d-ros sensor interface is implemented as a ROS nodelet. This
allows for lower-latency data processing vs. the traditional out-of-process
node-based ROS interface for applications that require it. However, we ship a
launch file with this package that allows for using the core ifm3d-ros driver
as a standard node. To launch the node, the following command can be used:
$ roslaunch ifm3d camera.launch
We note, the above command is equivalent to the following and is used for
purposes of providing a backward compatible interface to versions of
ifm3d-ros prior to the conversion to a nodelet architecture:
$ roslaunch ifm3d nodelet.launch __ns:=ifm3d
Regardless of which command line you used from above, the launch file(s) encapsulate several features:
- It exposes some of the
camera_nodeletparameters as command-line arguments for ease of runtime configuration. - It instantiates a nodelet manager which the
camera_nodeletwill be loaded into. - It launches the camera nodelet itself.
- It publishes the static transform from the camera's optical frame to a
traditional ROS sensor frame as a tf2
static_transform_publisher.
You can either use this launch file directly, or, use
it as a basis for integrating ifm3d-ros into your own robot software system.
We note: due to the change in architecture from a standalone node to a nodelet,
we have seen one behavior whose solution is not clear to have us provide
backward compatible behavior with older versions of ifm3d-ros. Specifically,
if you plan to run the camera in software triggered mode, you should lanch the
node as follows:
$ GLOG_minloglevel=3 roslaunch ifm3d camera.launch assume_sw_triggered:=true
The incomatibility here is that in prior versions, one would not need to
explicitly set the GLOG_ environment variable. While not strictly necessary,
it is recommended for keeping the noise level of the ifm3d logs low.
| Name | Data Type | Default Value | Description |
|---|---|---|---|
| ~assume_sw_triggered | bool | false | This provides a hint to the driver that the camera is configured for software triggering (as opposed to free running). In this mode, certain default values are applied to lessen the noise in terms of timeouts from the framegrabber. |
| ~frame_id_base | string | ifm3d/camera | This string provides a prefix into the `tf` tree for `ifm3d-ros` coordinate frames. |
| ~frame_latency_thresh | float | 60.0 | Time (seconds) used to determine that timestamps from the camera cannot be trusted. When this threshold is exceeded, when compared to system time, we use the reception time of the frame and not the capture time of the frame. |
| ~ip | string | 192.168.0.69 | The ip address of the camera. |
| ~password | string | The password required to establish an edit session with the camera. | |
| ~schema_mask | uint16 | 0xf | The pcic schema mask to apply to the active session with the frame grabber. This determines which images are available for publication from the camera. More about pcic schemas can be gleaned from the ifm3d project. |
| ~timeout_millis | int | 500 | The number of milliseconds to wait for the framegrabber to return new frame data before declaring a "timeout" and to stop blocking on new data. |
| ~timeout_tolerance_secs | float | 5.0 | The wall time to wait with no new data from the camera before trying to establish a new connection to the camera. This helps to provide robustness against camera cables becoming unplugged or other in-field pathologies which would cause the connection between the ROS node and the camera to be broken. |
| ~soft_on_timeout_millis | int | 500 | If using the `SoftOn` service call, when turning the camera back `on` this is the setting that will be used for `timeout_millis`. |
| ~soft_on_timeout_tolerance_secs | float | 5.0 | If using the `SoftOn` service call, when turning the camera back `on` this is the setting that will be used for `timeout_tolerance_secs`. |
| ~soft_off_timeout_millis | int | 500 | If using the `SoftOff` service call, when turning the camera `off` this is the setting that will be used for `timeout_millis`. |
| ~soft_off_timeout_tolerance_secs | float | 600.0 | If using the `SoftOff` service call, when turning the camera `off` this is the setting that will be used for `timeout_tolerance_secs`. |
| ~sync_clocks | bool | false | Attempt to sync the camera clock to the system clock at start-up. The side-effect is that timestamps on the image should reflect the capture time as opposed to the receipt time. |
| ~xmlrpc_port | uint16 | 80 | The TCP port the camera's xmlrpc server is listening on for requests. |
| Name | Data Type | Description |
|---|---|---|
| amplitude | sensor_msgs/Image | The normalized amplitude image |
| cloud | sensor_msgs/PointCloud2 | The point cloud data |
| confidence | sensor_msgs/Image | The confidence image |
| distance | sensor_msgs/Image | The radial distance image |
| extrinsics | ifm3d/Extrinsics | The extrinsic calibration of the camera with respect to the camera optical frame. The data are mm and degrees. |
| good_bad_pixels | sensor_msgs/Image | A binary image indicating good vs. bad pixels as gleaned from the confidence data. |
| raw_amplitude | sensor_msgs/Image | The raw amplitude image |
| unit_vectors | sensor_msgs/Image | The rotated unit vectors |
| xyz_image | sensor_msgs/Image | A 3-channel image encoding of the point cloud. Each of the three image channels respesent a spatial data plane encoding the x, y, z cartesian values respectively. |
None.
| Name | Service Definition | Description |
|---|---|---|
| Dump | ifm3d/Dump | Dumps the state of the camera parameters to JSON |
| Config | ifm3d/Config | Provides a means to configure the camera and imager settings, declaratively from a JSON encoding of the desired settings. |
| SoftOff | ifm3d/SoftOff | Sets the active application of the camera into software triggered mode which will turn off the active illumination reducing both power and heat. |
| SoftOn | ifm3d/SoftOn | Sets the active application of the camera into free-running mode. Its intention is to act as the inverse of `SoftOff`. |
| SyncClocks | ifm3d/SyncClocks | Synchronizes the camera clock to the system time. The side-effect is that images can be stamped with the capture time of the frame as opposed to the reception time. |
| Trigger | ifm3d/Trigger | Requests the driver to software trigger the imager for data acquisition. |
Please see the file called LICENSE.