Disable auto screen rotation
jesusramondovale opened this issue · comments
| Required Info | |
|---|---|
| Camera Model | D435i |
| Firmware Version | 5.16.0.1 |
| Operating System & Version | Linux Ubuntu 22.04 |
| Kernel Version (Linux Only) | 6.5.0-35-generic |
| Platform | Single Board Computer |
| SDK Version | 2.55.1 |
| Language | - |
| Segment | Robot |
I need my screen 180º rotated (horizontal inverse) but I see that few times and randomly my screen appears rotated (at 0º original) and I discovered that if I boot my Ubuntu without the Camera plugged in, it never does it until I plug it again.
I know that I can turn off screen rotation on Ubuntu tab menu, but if I do this my screen can't appear 180º rotated anymore, so I was wondering if is there any way to turn off this feature from
Hi @jesusramondovale The screen can be rotated in Ubuntu because of the IMU component inside the D435i camera that is equipped with a gyroscope. It is reported to occur very rarely but when it does, disabling screen rotation in Ubuntu is the only known way to deal with it.
Thank you for your quick response!
My problem is that I cannot turn off screen rotation on Ubuntu so my question was if its possible to turn off this from camera settings or something
SDK 2.55.1 added support for variable gyro sensitivity with the instruction RS2_OPTION_GYRO_SENSITIVITY. Turning down gyro sensitivity might reduce the chances of screen rotation occurring in Ubuntu. As this is a new feature there is not yet an example of implementing it in code though. The supported gyro sensitivity values are listed at the link below.
That gyro sensitivy value is a parameter or must I modify and recompile the sources? Thx
If you already have the 2.55.1 version of the SDK installed then you should be able to access the gyro sensitivity parameter from a script without having to recompile the SDK from source again.
I don't understand. I'm launching ROS2 Wrapper on Ubuntu 22 (ros2 launch realsense2_camera rs_launch.py)
I have the SDK installed on my Linux Ubuntu 22 via apt-get
I'm having another problem too related to orientation on a ROS2 system using the gyro. On a complete stopped camera, ROS2 system says its rotating (super slow)
There is a new ROS wrapper (4.55.1) for use with librealsense 2.55.1. Support for the new gyro sensitivity feature is not listed in the wrapper's features though.
Fluctuation of the IMU values when the camera is stationary may occur if the camera has not had a calibration of the IMU performed and saved to the camera using the SDK's rs-imu-calibration.py software tool.
https://github.com/IntelRealSense/librealsense/tree/master/tools/rs-imu-calibration
The problem is that I've already calibrated it several times using th rs-imu-calibration.py script (on the Linux SBC itself) :(
EDIT: I've seen I don't have the last ROS2 Wrapper that you're telling me (4.55) I have the 4.54 but doing apt update && apt install doesn't get me the last version, it gives me again the 4.54
My understanding is that if the camera is already calibrated then in ROS you can use a parameter called enable_motion_correction to perform a correction of the raw IMU data. This should work with older wrapper versions.
Does it make a difference if you add to your launch instruction enable_motion_correction:=true
I can use the enable_motion_correction:=true parameter, but nothing changes
I would finally suggest setting unite_imu_method:=1 to set unite_imu_method to 'copy' mode instead of 'linear_interpolation', as copy mode can make IMU data more stable.
If that does not help then I do not have further methods that I can suggest to stabilize the IMU values when the camera is stationary, unfortunately, other than to make certain that the camera is rested on a completely flat and level surface.
Tomorrow I'll try that. Thank you!
But .. is it normal that there's always an small angular_velocity on the 3 axes (± 0.00X m/s² aprox.) even though the camera is completely stationary?
The fact of not being completely horizontal could influence on the angular velocity data?
I'm still using the 4.54 version of ROS Wrapper (couldnt update to 4.55 yet)
Yes, the IMU values could change if the camera is not on a completely flat surface when stationary.
unite_imu_method:=1 will work with the 4.54 wrapper.
Parameter unite_imu_method:=1 does not change anything. As you can see in the image, the camera is completely stationary but the robot is slightly turning around. The pink zone is all the angle that has travelled in aproximately 1 minute
How can I update my ROS Wrapper to 4.55 version?
EDIT: I made a python node who calculates the summation of the angular velocity on axe Y and it's not zero:
If you built the 4.54 wrapper from source code then delete the entire /ros2_ws/src catkin workspace folder and build the wrapper from source again to install 4.55.1.
Is not possible to upgrade to 4.55 ROS Wrapper without building from source? I mean installing it via apt install
Yes you can update packages.
If you are using ROS2 Humble then you can install the latest wrapper with the command below.
sudo apt install ros-humble-realsense2-*
Ok, thank you! And do you think that 4.55 version will "repair"this?
Do you think it is a calibration problem?
You can get a general idea about the quality of your IMU calibration by looking at the Y Accel value. The ideal target value when calibrated with the Python rs-imu-calibration.py IMU calibration tool is -9.80, so if Y Accel was in the -9.4 to -9.6 range when the camera was stationary then this would indicate that it was a less than good calibration.
There was recently a RealSense user with a different IMU related problem who found that it was fixed when they updated their librealsense SDK version to 2.55.1. So whilst I cannot provide a guarantee that it will resolve your own issue, it is certainly worth attempting an update to SDK 2.55.1 and wrapper 4.55.1 to see whether it makes a positive difference.
I cannot update the ROS Wrapper :(
(Already the last version available)
ros-humble-realsense2-camera-dbgsym ya está en su versión más reciente (4.54.1-1jammy.20240517.191635).
ros-humble-realsense2-camera-msgs ya está en su versión más reciente (4.54.1-1jammy.20240517.160706).
ros-humble-realsense2-camera-msgs-dbgsym ya está en su versión más reciente (4.54.1-1jammy.20240517.160706).
ros-humble-realsense2-description ya está en su versión más reciente (4.54.1-1jammy.20240517.190807).````
The package repository for the wrapper at the link below indicates that the packages are the 4.55.1 version.
https://index.ros.org/r/realsense2_camera/github-IntelRealSense-realsense-ros/
I updated my ROS Wrapper to 4.55 (building from source) but it does the same. With completely horizontal and stationary camera, the angular_velocity.y summation over time does not tend to zero. It just continue growing and growing.
If you have access to the RealSense Viewer tool, please next try resetting your camera to its factory-new default calibration in the Viewer using the instructions at #10182 (comment)
Hi! When resetting to factory defaults, does any message appear on the Realsense-Viewer? I click on Write but nothing "happens" at first view, just the Calibration Data dialog disappears
No, there is not a confirmation message. The window simply closes when Write Table is clicked.
I did reset the calibration data to factory defaults but nothing changed. It does the same thing.
As the problem occurs as soon as the camera is plugged in and without running a RealSense program, I suspect that the screen rotation is unrelated to the librealsense SDK and that Ubuntu is detecting and accessing the camera's IMU hardware component directly. If that is the case then there may unfortunately be nothing that can be done to prevent the camera from affecting screen rotation on the random occasions when the problem occurs.
Hi @jesusramondovale Do you require further assistance with this case, please? Thanks!
No. I had to make a ROS node to filter this noise when robot's not moving
About screen rotation, I made a script which forces screen orientation.
Okay, thanks very much for the update about your workaround. As you do not require further assistance, I will close this case. Thanks again!