T265 frame didn't arrive within 5000

Hi all,

I fly in Loiter mode with an T265, everything worked yesterday. But today when I try to flight (same condition same place at yesterday) maybe 10s after taking off, I got this error coming from t265 python script “Frame didn’t arrive within 5000” and at this time my drone is hard to fly, what’s the problem? All my wires are good, I’ve read on GitHub a solution should be reset usb before runing python script any ideas?

And I have an another question, if I lose my camera when I’m flying in loiter mode, what happened ? My drone is like in AltHold ? Because today when I got my frame issue, for me the drone stay in loiter and he becomes get out of control.


1 Like

HI @simon1,

If the vehicle has an RPI companion computer with the recommended APSync image loaded (as mentioned on the wiki) then it will power off/on the USB ports soon after startup to resolve the T265 issue that I think you’re referring to. If the arming-checks have been left enabled (ARMING_CHECK = 1) then it should not have been possible to takeoff without the camera working and the issue should not be related to the “reset USB” issue.

If the camera stops sending updates (which is what I think the “Frame didn’t arrive” message means) then the EKF should lose its position estimate, the EKF failsafe should trigger and the vehicle should switch to Land mode. All of this should happen by default if the standard RPI image and AP setup are done as per the wiki.

If you have an onboard log file we can have a peek and maybe we can figure out what the issue is. My guess is that the T265 sent bad position estimates and there’s not much we can do on the AP side. The camera works really well when it works but when it loses its estimate it does not reliably tell AP.

By the way, the camera is mounted on a vibration isolated mount? There is a 3D printed design on the wiki page that we recommend. If you use that then it is also best to put vibration isolation foam between the edges of the mount and the camera. Sorry the setup is difficult but we’ve all been down this road already with the camera and so the mount really is required for good reliable performance… the camera has weaknesses and without Intel putting more effort into resolving them, these workarounds are all we have.

Hi @rmackay9

First of all thanks for your precise answer :smiley: :smiley:
Yes I used RPI companion but I don’t know if the image write on it is the APSync image give on the wiki because it’s not me who did this stage. Is it possible to know if the image is good or not maybe with uname or other command ?

Ok so if I understand well, if AP lose EKF due to camera error, the drone should land automatically ? Land mode is switched in the APSync image directly so how it is done ?

I’ll looking for the log file and I’ll post it here :slight_smile:.

By the way the camera is mount with foam for vibration but I can try to print the design give in the wiki.

EDIT: here is bin file for log BIN file

In my RPI I have for etc/debian_version 10.10 and for uname -r : 5.10.17-v7l+

Just an update, I’ve tested today with APSync image and this is works better, I haven’t got errors. ANd I’ve tried to kill the python script during fly and the drone has landed alone immediatly like you said @rmackay9
But I’ve searched where auto landing has done because I’m interrested about thaht, unfnonrtunaly I didn’t find, I thought I can find it in Libraries directory and in AP_NavEKF3 but I didn’t find any test or try to pass the vehicule in Land mode if VisualOdom failled. Do you know where, or could you guide me where I can search to find this part please? I’m newbie in Ardupilot source code :blush: :blush:


Great news that it’s working better.

The EKF failsafe code is here. It is not directly tied to the visual odometry feature, instead it is a general purpose failsafe to catch any case where the EKF loses its position estimate.

1 Like