T265 Horizontal drift | and Altitude drift upon landing

[07hokage]

Platform | NVIDIA Jetson

I'm facing the camera at 45 degree angle to the horizon.

It flew well indoors the first few times at altitude of nearly 7-10m. While in the same environment now, the position is starting to drift sometimes and sometimes difference between the ground truth and actual measurement is large( about 1-2m difference ). I keep getting the position jumped messages frequently.

Some observations made are, as soon as the vehicle lands, the altitude goes to negative values like -1.5m, -2m. Even after takeoff the estimation is starting from the negative value and sometimes it starts drifting in altitude axis.

When i had first such issue #3117 , it was due to vibrations. i corrected it this time and it also flew well first few times. Any inference and suggestions on how to mitigate this ?
PS: I disabled the relocalization parameter to avoid robot actually jumping around abruptly.

[thien94]

It seems clear that the issue is on the T265's side. The code in this repo only does post-processing without imposing any correction to the pose data itself, so a better place to ask for suggestions is https://github.com/IntelRealSense/librealsense.

That being said, the first potential issue would be vibration, which as you said have taken care of. I would still suggest adding additional isolation for vibration and see if it helps.

The next issue would be the environment. Lighting conditions, availability of visual features, moving objects, how fast you are moving etc. can affect the VISLAM algorithm onboard the T265 negatively, but differently, in each run. For this type of problem there is not much I can suggest since they are inherent to the device. Here is a related issue that might provide some helpful pointers IntelRealSense/librealsense#4176

Beyond this, if you are familiar with other open-source VISLAM systems such as OpenVINS or VINS-Fusion, you can change the approach and use the T265 as a sensor rig (camera + IMU) to run VISLAM. The benefit being you are in control of the system and can pinpoint where the problem lies, as opposed to dealing with the "symptom" (drift, jump, scale issues) without any hints for what to do.

[07hokage]

Thanks @thien94 for the detailed information. Before closing the issue i would like to hear from your experience, is it because of the IMU in T265 that at any other angle other than forward facing causes this jumps/drifts. Because we had never such experience when facing forward even after hard landing.

[thien94]

Some observations made are, as soon as the vehicle lands, the altitude goes to negative values like -1.5m, -2m. Even after takeoff the estimation is starting from the negative value and sometimes it starts drifting in altitude axis.

For this specifically, the problem might be that the acceleration happens to exceed the limit of the T265's IMU (±4g) which cannot be changed. If you have the log, you can compare the acceleration values of the flight controller's IMU vs the T265.

[07hokage]

Some observations made are, as soon as the vehicle lands, the altitude goes to negative values like -1.5m, -2m. Even after takeoff the estimation is starting from the negative value and sometimes it starts drifting in altitude axis.

For this specifically, the problem might be that the acceleration happens to exceed the limit of the T265's IMU (±4g) which cannot be changed. If you have the log, you can compare the acceleration values of the flight controller's IMU vs the T265.

But given that t265 is much sensitive to vibrations while facing downwards or at 45 degree, than forward facing, is it best to operate forward facing always?

[thien94]

@07hokage so far I can say that forward-facing is more reliable and predictable than down-facing configuration. I think forward-facing is the default as well as the most tested use case, so that makes sense.

The 45-degree configuration is not something I have tested extensively so I can't say anything for sure, but there are others who have used this configuration successfully.

Another thing to consider is how close is the camera to the ground since the T265 tends to work better if the cameras can see abundant features in the environment, especially at the start.

[FPSychotic]

If you allow me help a little. Is not possible get solid results with only Realsense t265 and any other sensor, normally you need 3 or more.
The sensors that you use normally in UAVs are very limited in precision as GPS, or they dont give enough odometry data as optical flow, or they have hardware or software limitations as t265, or any other camera as ZED, Steucture Core etc.
In indoors with a UAV you are losing the GPS, wheel odometry, and you have Flow (only speed) and IMU (that drift). In outdoors is more or less the same, compass and GPS dont help many in a setup or environment on which you need a VIO support, is more a gps,.compass, flow will damage the VIO odometry if you fuse them.
As your main sensor is VIO and it has limitations, every setup, in every environment, with every setup will perform different and even if you get ideal behaviour, in the moment you change a variable, as light, features available, sensor precision or its availability, fps,. movement, the result can be very different.
You need fuse VIO with Slam, instead with GPS, flow, etc.
Some options perform SLAM+VIO available, but the most solid is a lidar, and in second place a array of stereo cameras (as Skydio)
In rovers is more easy get reliable odometry, but is more difficult in avoidance, rute planning etc.
Ardupilot with a t265 (python integration) without SLAM support cannot be trusted. But totally valid foe R&D, development, etc which is the use that the team is giving here and because for some place you need start, the python thing, the ros imtegration and the hardware they chosen are the better possible approach, but it cannot be a navigation solution for UAVs

Thien94 won't be able to help you in your specific case as he cannot reproduce your same setup, environment etc.