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.
Software/Firmware/Hardware:
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.
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.
