Initial-World-Transform Yaw always 0.0

When using the ZED SDK to get the orientation from the camera, a yaw of “0” is always set to whichever direction the camera was facing when it/the code was run. I have tried setting the yaw of the initial-world-transform to its true value (i.e. rotate camera 45degrees South of true-East and give it 45 degrees (also tried -45 degrees)), but that does not work either, the camera publishes its first yaw as “0”. We have noticed this behavior for as long as we have used the SDK (v3.6.0). We were hoping the new set_gravity_as_origin might have helped to resolve this, but it does not appear to have.


  • Camera: ZED2i
  • SDK Version: 3.8.1
  • Code Language: CPP

Init Parameters used:

  • camera_resolution: sl::RESOLUTION::HD1080
  • camera_fps: 30
  • camera_image_flip: sl::FLIP_MODE::OFF
  • coordinate_system: sl::COORDINATE_SYSTEM::IMAGE
  • depth_mode: sl::DEPTH_MODE::PERFORMANCE
  • depth_minimum_distance: 300.0
  • depth_maximum_distance: 20000.0
  • depth_stabilization: 1

Positional Trackings used:

  • enable_area_memory: 0
  • enable_pose_smoothing: 1
  • enable_imu_fusion: 1
  • set_as_static: 0
  • set_floor_as_origin: 0
  • set_gravity_as_origin: 1
  • depth_min_range: 1000.0

We have tried toggling enable_area_memory on, but that did not work either. Our use case is having the camera mounted on a drone, however the testing for this issue is being done on the ground, separate from the drone.

Hi @penguin
I just tested the behavior of the ZED ROS2 Wrapper and the Positional Tracking example and they work as expected.

Can you post the code that you use to set the initial position of the camera?

During our testing with a second ZED2i, we discovered that we were setting the sl::Rotation with setEulerAngles(sl::float3(roll, pitch, yaw), true) while it should’ve been setEulerAngles(sl::float3(pitch, yaw, roll), true) since that is the order returned from zed.getOrientation().getRotationMatrix().getEulerAngles()

However, the reason we assumed the first input order was that when looking for a reference/example of how to set the initial transform, we looked at the zed-gstreamer source code. If you look at zed-gstreamer/gstzedsrc.cpp at 7315ad896f9970d91ab0f4a40e968b3cbcbce32d · stereolabs/zed-gstreamer · GitHub, there is a bug in the plugin that inputs the angles in the wrong order (which explains why we have never gotten this to work while using zed-gstreamer). We are actually currently working on creating a fork off the zed-gstreamer for the SDK 3.8 release since we wanted to immediately use the new features so I can add this bugfix into our fork before doing a pull request.

Hi @penguin
don’t tell anyone, but I made the same mistake this morning by testing the function before replying to you.
Please do not hesitate to send a PR that fixes the issue for the GStreamer plugin if you already tested it.

Haha, let me do some more testing on the fork today to verify the changes and then I’ll make the PR.

I also corrected myself above about what the order of the euler angles input should be, is that correct? (sl::float3(pitch, yaw, roll))

That’s correct because as long as you are in COORDINATE_SYSTEM_IMAGE

1 Like