Skip to content

Add software rotation fallback for devices without hardware rotate (e.g. DaBai DCW)#197

Open
T-Lemmel wants to merge 1 commit into
orbbec:mainfrom
T-Lemmel:feat/dabai-dcw-sw-rotation
Open

Add software rotation fallback for devices without hardware rotate (e.g. DaBai DCW)#197
T-Lemmel wants to merge 1 commit into
orbbec:mainfrom
T-Lemmel:feat/dabai-dcw-sw-rotation

Conversation

@T-Lemmel

Copy link
Copy Markdown

Summary

Adds a software image-rotation fallback so color_rotation / depth_rotation
work on devices whose firmware does not implement the hardware rotate property
(OB_PROP_COLOR_ROTATE_INT / OB_PROP_DEPTH_ROTATE_INT), e.g. the DaBai DCW.

Problem

On the DaBai DCW, setting color_rotation:=180 / depth_rotation:=180 has no
effect. In setupDevices() the rotation is only applied when the device reports
isPropertySupported(OB_PROP_*_ROTATE_INT, ...). The DaBai DCW does not support
that property, so the requested rotation is silently dropped and the image is
published upside-down.

Solution

  • Keep the existing hardware path unchanged.
  • When the hardware rotate property is not supported, record the requested
    angle in dedicated members (color_rotation_sw_ / depth_rotation_sw_).
  • In the image callback, apply cv::rotate(image, image, cv::ROTATE_180) when
    the software fallback is set.

Only 180° is handled in software because it preserves the image dimensions, so
step and the camera_info intrinsics remain valid. color_rotation_ /
depth_rotation_ keep their original meaning (the hardware request).

Reproduction

ros2 launch orbbec_camera dabai_dcw.launch.py depth_rotation:=180 color_rotation:=180

Devices whose firmware does not support the hardware rotate property
(e.g. DaBai DCW) silently ignored color_rotation/depth_rotation. Add a
software fallback: in setupDevices(), when OB_PROP_*_ROTATE_INT is not
supported, record the requested angle in dedicated *_sw_ members and
apply cv::rotate(ROTATE_180) in the image path. Only 180 deg is handled
in software since it preserves image dimensions (step / camera_info stay
valid). Hardware rotation behaviour is unchanged.

Also expose color_rotation / depth_rotation launch args in
dabai_dcw.launch.py.
@obshenlanzhou

Copy link
Copy Markdown
Collaborator

@codex review

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6191a29835

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +2208 to +2209
if (rotation_deg == 180) {
cv::rotate(image, image, cv::ROTATE_180);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Keep camera info consistent with software rotation

When the fallback is active, e.g. DaBai DCW with color_rotation/depth_rotation:=180, this rotates the published image after the CameraInfo was already published above, so the message still describes the unrotated pixel coordinates (cx/cy and P). Consumers that rectify, register, or project the rotated image with that CameraInfo will compute rays for the wrong pixels, especially with non-centered principal points. The software path needs to publish matching calibration/frame data along with the rotated image.

Useful? React with 👍 / 👎.

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

Successfully merging this pull request may close these issues.

2 participants