Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

disabling hardware depth registration leads to error #66

Open
130s opened this issue Nov 4, 2017 · 9 comments
Open

disabling hardware depth registration leads to error #66

130s opened this issue Nov 4, 2017 · 9 comments

Comments

@130s
Copy link
Member

130s commented Nov 4, 2017

Issue by bit-pirate
Monday Sep 23, 2013 at 02:59 GMT
Originally opened as ros-drivers/openni2_launch#9


When I deactivated depth registration via rqt_reconfigure, I get the following error:

[ERROR] [1379904975.770528069]: Depth image frame id [sensor_3d_depth_optical_frame] doesn't match RGB image frame id [sensor_3d_rgb_optical_frame]

Can anyone confirm this? What's different to the old version (openni1)?

@130s
Copy link
Member Author

130s commented Nov 4, 2017

Comment by bit-pirate
Monday Sep 23, 2013 at 03:05 GMT


Maybe @piyushk knows what's going wrong.

@130s
Copy link
Member Author

130s commented Nov 4, 2017

Comment by piyushk
Monday Sep 23, 2013 at 16:56 GMT


@bit-pirate I don't have anything other than a kinect at hand at the moment, so I can't test this directly. Can you try and locate which nodelet is generating this error?

@130s
Copy link
Member Author

130s commented Nov 4, 2017

Comment by bit-pirate
Tuesday Sep 24, 2013 at 04:15 GMT


It's the registration nodelet (PointCloudXyzrgbNodelet) complaining:

Depth image frame id [sensor_3d_depth_optical_frame] doesn't match RGB image frame id [sensor_3d_rgb_optical_frame]

Location:
/tmp/buildd/ros-hydro-depth-image-proc-1.11.2-0precise-20130909-1058/src/nodelets/point_cloud_xyzrgb.cpp:PointCloudXyzrgbNodelet::imageCb:167

Looks to me like the driver is outputting images or point clouds with different reference frames, when not using hardware registration.

@130s
Copy link
Member Author

130s commented Nov 4, 2017

Comment by piyushk
Tuesday Sep 24, 2013 at 15:32 GMT


I suspect the s/w registration pipeline is broken somehow. Once s/w
registered, the depth image should have the RGB image frame id. I'm not
sure how the driver could make this mistake.

On Mon, Sep 23, 2013 at 11:15 PM, Marcus Liebhardt <[email protected]

wrote:

It's the registration nodelet (PointCloudXyzrgbNodelet) complaining:

Depth image frame id [sensor_3d_depth_optical_frame] doesn't match RGB image frame id [sensor_3d_rgb_optical_frame]

Location:
/tmp/buildd/ros-hydro-depth-image-proc-1.11.2-0precise-20130909-1058/src/nodelets/point_cloud_xyzrgb.cpp:PointCloudXyzrgbNodelet::imageCb:167

Looks to me like the driver is outputting images or point clouds with
different reference frames, when not using hardware registration.


Reply to this email directly or view it on GitHubhttps://github.com/ros-drivers/openni2_launch/issues/9#issuecomment-24973657
.

@130s
Copy link
Member Author

130s commented Nov 4, 2017

Comment by mikeferguson
Wednesday Sep 25, 2013 at 18:35 GMT


@bit-pirate you mention "disable via rqt" -- does software registration work correctly if you start up in that mode?

@130s
Copy link
Member Author

130s commented Nov 4, 2017

Comment by liborw
Tuesday Oct 01, 2013 at 08:07 GMT


I have the same problem when started without the hardware registration (not using the dynamic reconfigure).

@130s
Copy link
Member Author

130s commented Nov 4, 2017

Comment by liborw
Tuesday Oct 01, 2013 at 08:46 GMT


The problem is, that one must also set hw_registered_processing to false and sw_registered_processing to true along with the depth_registration to false. That way everything works fine.

@saikishor
Copy link

@130s @liborw I am having the same issue, but when setting the depth registration to false via rqt_reconf. If I set it directly when I run my node, there is no such issue. I would like to know whether this issue has been resolved or not?.

@130s
Copy link
Member Author

130s commented Sep 22, 2018

Assuming from the last update on this ticket was back in 2013, very few people have had either experienced this issue or been interested in tracking this down. So it'd be great if you @saikishor can look into it deeper, and come up with a workaround to the least (or open a fix via pull request to the best).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants