T265: Old issue: Frame didn't arrived within 5000

[neilyoung]

Required Info
Camera Model	T265
Firmware Version	0.1.0.279
Operating System & Version	Raspbian Buster, Ubiquity - all the same
Kernel Version (Linux Only)
Platform	Raspberry PI
SDK Version	2.2.9.0
Language
Segment	others

Issue Description

I know, this issue has already been discussed (but no solution so far). I can easily reproduce it by letting the T265 starr to a white wall w/o features or covering it with a towel or letting it run in a dark room.

Most the time the T265 recovers from that by reverting the initiating situation. But this helps not all the time. If it doesn't recover, it starts to deploy NaN coordinates at 200 Hz and there is no way to convince the cam to be in "save" areas again :)

What would be the suggested procedure then? Not even restart of the script seems to help. Only unplug/re-plug of USB, which is a little problem IMHO for robots :)

[harville]

@neilyoung We are working to resolve this, and expect to have a significant improvement around this issue in a near-term (possibly next) release. In the meantime, however, it would be good to have a better way to reset after nan pose output begins, as you point out. In our testing, we have found that calling pipe.stop() followed by pipe.start() will restore normal pose tracking. This starts a new tracking session, which is not desirable in many application contexts, but it's better than having to physically unplug and replug the device.

Does re-starting your script effectively result in calls to pipe.stop() and start()? I'm imagining that it likely just does start() at the beginning, which would not fix the problem. One thing you could try is modifying your application to check for a first nan pose output, and when it occurs, call stop(), start(), and continue with your application as best you can. Can you please let us know the outcome, if you try this (or if you've already tried it)?

[neilyoung]

@harville thanks, yes meanwhile I also came to this conclusion, that an auto restart of my main loop (resulting in pipe.stop()/pipe.start()) does work.

[harville]

Thanks for the helpful feedback, @neilyoung . It would be great to get some clarifications on your issue:

• What exactly does the title of this ticket mean: Were you seeing no pose data at all being sent by the device for some time? Or was the data being sent, but was NaNs? 5000 is seconds, msec, samples?
• You mention you can reproduce by pointing camera at a white wall, in a dark room, or covering camera. Is the camera static in these cases? Or what sort of sequence of motions is it undergoing?
• What does "reverting the initiating situation" mean?

It would be great to get your additional feedback on the above, to better guide our efforts to improve in these areas.

Also, the new librealsense release 2.30.0 contains some improvements that may help address the NaN pose issues. If you are able to try it out, we would be interested in hearing about whether it helps to improve the issues you are reporting on here.

That last comment applies more generally to the community - any feedback on whether release 2.30.0 reduces NaN occurrence would be appreciated. We are actively working on this topic, but it can occur in a variety of ways, and there is a lot of randomness to it. Also, as indicated in the release notes, you might consider creating a raw data recording of the issue. We feed these into our debugging and analysis tools internally. We already have some recordings, but could use more.

[neilyoung]

@harville Sorry for being not specific enough. I didn't mention the specific situation and context, which produces this error.

First of all: The problem is still existent in 2.30.0 pre-release

OK, start over. There is a python example called t256_example.py. I replaced the for _ in range loop by a while (true): in order to let it run for a while.

After the initialisation phase the script waits for frames in frames = pipe.wait_for_frame() This sometimes excepts with the error mentioned in the title, especially in the mentioned situations (white wall, dark room, covered lenses). My camera is mounted on either a laptop or a Raspberry PI, so it is portable :), but always static. Even if I move the camera while covering the lenses the problem occurs.

The script terminates, if you don't catch the exception. In most cases the script recovers if the "initiating situation" is reverted (you move away from white walls, uncover the lenses, switch the light on) everything goes as it went before.

Then there is sometimes the situation, that - even though there is a frame - an attempt to get out things like translation or rotation ends up in a "NaN" exception (not a number). Other environments say "Null pointer exception" or so. I haven't seen that much "NaN" anymore with 2.30.0, but it might be, that I'm now prepared and catching every exception. Not sure.

Basically this is a non issue for me meanwhile. You can close it.