Revision history [back]

Edit: Ah, looks like both drivers are actually doing things right, see REP 118: Depth Images. Either INT encodings should be used with millimetres or FLOAT encodings with metres.

And depth_image_proc/convert_metric is a nodelet that can be used to convert between the different encodings.

Original answer: I haven't checked at all, so take this with a bag of salt, but: the ratio you mention (1000) seems like it could be the difference between millimetres and metres. ROS uses metres for distances (REP 103), so it would make sense to have depth images use metres for distance-per-pixel as well. I don't know whether that is actually the case (ie: whether REP 103 is adhered to in that context), but if it is, then the Zed's values would seem to be OK, while the Kinect's seem off.

Again: it could be that it's the other way around (depth images are supposed to use mm, not metres) and then the converse of what I wrote above would be true.

Edit: Ah, looks like both drivers are actually doing things right, see REP 118: Depth Images. Either INT encodings should be used with millimetres or FLOAT encodings with metres.

And depth_image_proc/convert_metric is a nodelet that can be used to convert between the different encodings.

Original answer: I haven't checked at all, all (I'm not into computer vision), so take this with a bag of salt, but: the ratio you mention (1000) seems like it could be the difference between millimetres and metres. ROS uses metres for distances (REP 103), so it would make sense to have depth images use metres for distance-per-pixel as well. I don't know whether that is actually the case (ie: whether REP 103 is adhered to in that context), but if it is, then the Zed's values would seem to be OK, while the Kinect's seem off.

Again: it could be that it's the other way around (depth images are supposed to use mm, not metres) and then the converse of what I wrote above would be true.